企业官网建设流程全解析

TEESimulator核心原理三：内嵌AOSP参考KeyMint TA（kmr-ta）为何让证明证书逐字段可信

【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator

TEESimulator是一款 Android 硬件密钥证明（Key Attestation）模拟器——它不伪造证书，而是把 AOSP 官方的参考 KeyMint 可信应用（kmr-ta）直接搬进 keystore 守护进程里运行，再用自己的密钥（keybox）来签名。正因如此，它生成的软件 KeyMint 证明证书，每一个字段都与真实安全环境内部一致：不是我们手工把上百个字段一个个调对，而是按构造（by construction）天然可信。

一、手工伪造证明证书，为什么总是"差一点"

要理解这个设计的价值，得先看清楚一张 KeyMint 证明证书里到底装了多少东西。证书的核心是一条证明扩展（OID 为1.3.6.1.4.1.11129.2.1.17），里面塞着一份KeyDescription，足足8 个字段，其中最关键的是两份"授权列表"：

• 软件强制列表（software-enforced）：应用请求的用途、算法、限制等；
• TEE 强制列表（tee-enforced）：root of trust（信任根）、OS 版本、OS/厂商/启动补丁级别、密钥安全级别……

每一个字段都有一个数字标签（tag）：信任根是[704]、OS 版本是[705]、OS 补丁级别是[706]、厂商补丁级别是[718]、启动补丁级别是[719]。这些值不但要对，它们的DER 编码、标签顺序、签名算法、版本字段也必须相互咬合。

手工伪造的困境在于：你必须在"没有真机"的情况下，同时把几十个字段调成自洽的一整套。任何一处对不上——标签号错一位、整数编码多一个字节、版本与标签不匹配——服务端（如 Play Integrity）做交叉校验时，矛盾立刻暴露。证书不是"看起来像"就行，而是"内部必须自洽"才行。这正是"逐字段可信"这四个字的分量。

二、解法：不伪造，而是直接运行 AOSP 官方的 kmr-ta

TEESimulator 的破题思路是：别去复刻证书，直接运行生成证书的原始机器。

项目内嵌了 AOSP 的参考 KeyMint TA，也就是kmr-ta——正是 Cuttlefish 官方模拟器在跑的那个软件 KeyMint（见 third_party/README.md）。它被驱动成一台真正的 KeyMint 状态机：generateKey、begin/update/finish、密钥特性查询，全流程照跑。

一句话概括架构：一个引擎，两个前端。加密引擎（Rust 静态库）负责造钥匙、跑运算、签证明；而 Android 12+ 的keymint/拦截器与 Android 10/11 的keystore/拦截器，只是把它包在里面的"管道"（详见 rust/teesim-km/README.md）。

三、"逐字段可信"从何而来

3.1 同一个状态机产出全部字段

证明扩展怎么组装、密钥使用授权怎么排、记录里标签的顺序怎么走——全部由真实 TEE 也在运行的那同一份代码产生。

这不是"我们努力把它做对了"，而是"它本来就是这么生成的"。字段之间的自洽关系，是官方状态机天然保证的，而不是靠人肉核对一百处。这就是 README.md 反复强调的那句话：internally consistent by construction。

3.2 标签号必须等于 KeyMint 的编码

更隐蔽的一致性藏在参数序列化里。KeyMint 的请求/响应走 CBOR，参数按标签号分派——解码器是靠 tag 来决定值类型的。一旦编号错一点，错误不会报错，而是"静默地变成错误类型"。

TEESimulator 在这里吸取了真实教训（源码注释点名的USER_SECURE_ID符号位 bug，见 rust/teesim-km/src/lib.rs）：不手工拼 CBOR。参数与kmr_wire::KeyParam的来回转换，一律走kmr_wire自带的AsCborValue编解码器（见 rust/teesim-km/src/capi.rs）。

好处是：标签号天然等于 KeyMint 的官方编号，因为用的是同一套编解码逻辑——错不了，也不必记住那张数字表。

四、我们只动了窄窄的一片 🎯

嵌入官方 TA 后，改动被刻意压到最小。真正被替换的只有四处：

keybox 的解析在 rust/teesim-km/src/attest.rs：它从keybox.xml里取出 RSA 与 EC（NIST P-256）两把批次签名密钥及各自证书链，每条链至少两张证书。没有内置兜底密钥——keybox 缺失或格式不对，TA 直接报错、拦截器拒绝挂钩，让配置错误的模块"变成无害的哑弹，而不是隐患"。

五、补丁：让参考 TA 在进程内"诚实运行"

官方 TA 原本为 Soong 构建、且假定运行在真机安全世界里。要让它在一个普通进程里诚实跑起来，需要几处不碰加密的适配补丁（记录在 rust/patches/）。

5.1 安全级别与版本补丁

一台真设备对每个安全级别都跑独立的 KeyMint 实例。kmr-ta-seclevel.patch 让单个 TA 能按其请求到达的 HAL 级别来签名，并精确处理版本对应关系：

• 把原始attestationVersion映射到正确的keyMintVersion——Keymaster 3.0 是 3、4.0 是 4、4.1 是 41（KeyMint 版本则直接相等）；
• MODULE_HASH标签（724）只在版本 ≥ 400 时才写入，这样一台"TEE 报 v4、StrongBox 报 v3"的双级别设备，在两个级别上都能保持诚实，不会越级冒领。

5.2 认证 token 与重定时间戳

kmr-ta-authtoken.patch 处理生物识别 token：它由真机 Gatekeeper 用ISharedSecret密钥做 MAC，而进程内 TA 从不参与那次协商、没有密钥可验证——于是"无密钥可验时信任 token 的存在，其余绑定项照常强制"。kmr-ta-restamp则允许密钥 blob 的补丁时间戳双向重定（真实硬件只会往前走，而模拟器的级别可被用户调低）。

六、信任根为何必须"冻结" 🔒

最微妙的一处：证书里的root of trust（信任根）不可配置。

守护进程启动时，从真机硬件密钥里收割一次真实的 verified-boot 密钥、状态、锁定标志，然后冻结它。原因有二：

1. 让证明可信：信任根用设备真值，证明里那个字段才是"真实锁定/已验证"设备该有的样子；
2. 让密钥能用：这些字段同时是 KeyMint密钥加密密钥（KEK）派生的输入（见 rust/teesim-km/src/device.rs）。冻结它们，跨重启、跨 profile 派生出同一个 KEK，之前会话里创建的密钥才不会"解不开"。

换句话说：信任根既要对，又要稳。真实 + 冻结，两全其美。

七、两种工作模式：生成 vs 补丁

拦截器按 profile 决定每个请求走哪条路（路由逻辑见 keymint/keymint_router.cpp）：

• 生成模式：整个密钥连同证明都在这里铸造，完全出自 TA 之手；
• 补丁模式：保留真实的硬件密钥 blob（所以密钥仍"硬件支持"），只把证明叶交给 rust/teesim-km/src/resign.rs重签到 keybox 之下——把 root of trust 改成 profile 的 locked/Verified，把补丁级别换成 profile 的新鲜值，其余真实内容（challenge、版本字段、TEE 强制授权）原样保留。最终链 =[改过的叶, keybox 证书链…]。

小结

"逐字段可信"的秘诀，一句话就能说完：不去对齐一百个字段，而是让官方的 KeyMint 状态机自己跑。

TEESimulator 只替换了三样东西——加密后端、签名来源、少数身份字段——而让attestation extension、标签顺序、DER 编码、版本对应这些"最难人工对齐"的部分，全部交给 AOSP 自己的代码按构造产出。这就是内嵌kmr-ta的价值：它让一张软件签发的证明证书，在内部一致性上，与真机 TEE 的产物无从区分。

【免费下载链接】TEESimulatorSoftware simulation for Android hardware-backed key pairs with key attestation项目地址: https://gitcode.com/gh_mirrors/te/TEESimulator