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