在“第六篇：DICE”中提及DICE证明设备的完整性，用于设备标识和设备证明等应用场景。现在又出现一个ID Attestation来作为设备的凭证，也是用于设备身份证明，那么他们之间是什么关系？
后续还有一个“Identity Credential”，在第八篇来谈。
做个比较：我们手上的身份证用于证明我们个人的身份（出生年月日、长相、户口所在地），确保这个身份证上的信息不是伪造的关键是什么，是这个身份证介质中的安全芯片。即，ID Attestation给我们提供了可以看懂且得到防伪保护的设备名称、品牌名称以及制造商名称等信息，而DICE和TEE为这些信息的防伪性提供基础的安全保证。
注：ID Attestation，为了更好理解它的用意，我们就不用Android官方的“ID认证”的译文，而是用“设备身份凭证”来替换。
1、ID Attestation的介绍
根据Android官方资料，ID Attestation（设备身份凭证）是从Android8开始引入，为使用Keymaster3的设备提供了对ID认证的可选支持。通过ID认证，设备可以提供其硬件标识符的证明，例如序列号或IMEI。虽然这是可选功能，但强烈建议所有Keymaster3实现提供对该功能的支持，因为能够证明设备的身份可确保真正的零触摸（Zero-Touch）远程配置等用例更加安全（因为远程端可以确定与它进行对话的是这正确的设备，而非假冒其身份的设备）。
ID Attestation（设备身份凭证）的工作原理是：在设备出厂之前，创建只有可信执行环境（TEE）才能访问的设备硬件标识符的副本。
用户可以解锁设备的引导加载程序（BootLoader），并更改系统软件以及Android框架所报告的标识符。由TEE保存的标识符的副本不会以这种方式被操控，这样可确保设备ID Attestation（设备身份凭证）仅用于证明设备的原始硬件标识符，从而阻止尝试假冒身份的操作。
ID Attestation（设备身份凭证）支持如下硬件标识符：
（图1）
实际上，从我们的实际项目来看，在Android 13才有客户提出ID Attestation的导入。到了Android14，“设备身份凭证”的需求才开始增多。
2、ID Attestation的场景简述和意义
上文提及的的零触摸（“Zero-Touch”）在“Android Enterprise Security Whitepaper”资料中被提及，通常，是由公司IT管理员进行终端设备的配置设定，将设备交给雇员，雇员将设备开机后，设备进行自动的登记注册，这样确保雇员拿到的该设备是被企业认可的合法设备。
即，对于一台设备，不仅对于设备的物理上要进行防伪，更需要对该设备的系统软件进行防伪，以免设备上App应用的信息被非法的系统软件所截获。
从上述说明可以得出：为了确保一台设备的安全可信，是需要制造原厂的信息，也需要IT管理员的参与，才能确保一台设备从物理上和系统软件上（包含BootLoader、系统软件和Android框架）是没有被伪造的，而且这些设备标识符的信息是IT管理员和用户都可识别的。
那么，对于普通用户而言，在没有IT管理员的参与的情况下，很难确保系统软件的防伪性。即使有ID Attestation（设备身份凭证）这样的信息，只是确保这些设备的物理身份凭证是由某个设备原厂所提供的，无法保证在运输或交接的过程中该设备的系统软件是否被更换过。
所以，一方面，在过去，ID Attestation在消费市场很少被使用；另一方面，随着DICE的引入，解决了系统软件的防伪性（参考第六篇：DICE，或者TCG官方资料），从而ID Attestation会更多地登台，因为它容易被消费者看懂，确保设备的身份（包括硬件信息和系统软件）不是伪造或更换过的。
为此，有效地安全确保设备的身份凭证，需要设备底层的可信安全（DICE+TEE）的加持。
附录：实现ID Attestation的框架图
（图2）
以上实现，一定是在设备生产阶段完成的。
在运输途中和设备使用过程中，这些信息是无法被篡改的。
【参考资料】
1、https://source.android.com/docs/security/
2、https://source.android.com/static/docs/security/overview/
3、TCG官方资料：https://trustedcomputinggroup.org/