我认为我不了解Key Attestation的一件事。似乎在随后的证明期间不可能将“证明挑战”（作为密钥生成器规范中的参数传递）更改为其他内容。这意味着虽然我可以在开始时验证密钥是在安全元素中创建的，但我以后无法验证它，因为如果应用程序被泄露，攻击者可以轻松地向我发送以前收到的有效证书链，这不是完全保密的，回应我的询问。 [注意：我的意思是很容易证明，如果安全元素确实安全并且密钥材料永远不会离开它，则收到的证书链始终有效。但请参阅我的其余部分。]
但是，让我们说这是安全的，我认为每个关键字的生命周期只能检查一次。这引出了另一个问题：在证明期间收到的证书中有一个字段KeyDescription（OID：1.3.6.1.4.1.11129.2.1.17），它应该包含AuthorizationList类型的字段，其中包括类型字段RootOfTrust，包括字段VerifiedBootState。我无法检查它，但是我们说它总是包含当前启动状态，而不是创建密钥时的启动状态。如果我无法改变认证挑战，我怎么能相信这个价值？
编辑：我确实意识到每次我想要验证启动状态并随后从SE中删除它时我都可以创建具有不同挑战的新密钥，但它看起来非常低效，不是很优雅，如果由于某种原因可能会出现问题将引入限制密钥创建尝试的策略。答案 0 :(得分：0)
我明白了。我只是在误会事情。单一挑战和无法改变现时背后的原因很可能是这样：
创建密钥后，可以要求提供证明。如果数据证明硬件存储并且安全启动报告设备处于绿色状态（设备未植根，则执行安全启动），则任何更改都将导致密钥被擦除。这意味着只要存在此密钥，我们就可以确定（当然在“合理程度”内）设备软件（和硬件）没有任何根本改变，并且如果我们的软件是安全的，那么它仍然是。
参考文献：