Keystore 架构：Android Keystore 系统架构、硬件支持、安全环境
Keystore 这个组件，说白了就是 Android 系统里专门管密钥的「保险柜」。你 App 调用 KeyStore.getInstance() 的时候，背后其实是一整套分层架构在干活。我早期碰到过一个诡异问题：密钥明明存进去了，但用的时候却抛异常——查了半天，发现是底层硬件环境不支持，系统自己降级到了纯软件实现。嗯，从那以后我就养成一个习惯：先搞清楚当前设备的 Keystore 架构再动手。
1. 系统架构：四层金字塔
Android Keystore 从上层到底层分了四层，每层各司其职：
- 应用层 (Application Layer) – 你写的 App 通过
android.security.keystore包下的 API 发起请求。比如生成密钥、签名、加密。这里要注意：API 本身是异步的，但很多开发者习惯在 IO 线程调，结果还是堵了主线程。我建议直接使用KeyStore2或 Kotlin 协程包装一层。 - 框架层 (Framework Layer) – 系统服务
IKeystoreService负责管理密钥生命周期，包括绑定、认证、访问控制。我记得 Android 12 之后这里加了「冷启动隔离」机制，密钥在系统服务进程里完全不会暴露给 App。嗯，安全是到位了，但是回调变成异步后，老代码很容易 ANR。 - HAL 层 (Hardware Abstraction Layer) – 这是和硬件打交道的桥梁。Android 8.0 之后强制要求
keymasterHAL，分多个版本（V3/V4/V5）。每个版本支持的算法、安全级别都不同。你想想看，设备 A 可能只有 V3，设备 B 有 V5 还支持 Strongbox，写代码时必须动态判断。 - 硬件层 (Hardware Layer) – 真正的密钥存储和运算地点。可能是 TEE（Trusted Execution Environment）、SE（Secure Element）或者纯软件（Software-Only）。我踩过一个坑：某款手机明明标着「支持硬件密钥」，但底层实际跑在 CPU 的 TEE 里，性能极差，一个签名操作卡了 3 秒。
keyStore.entrySet() 调用，可能穿越了 4 个进程、2 个 IPC 通信、1 次硬件调用。异步化是必须的，否则 ANR 是迟早的事。
2. 硬件支持：TEE、SE、Strongbox 三兄弟
这部分是很多人的知识盲区。我亲自做过一个项目，产品经理说「我们要硬件级安全」，结果发现他根本分不清 TEE 和 SE 的区别。我这里给你画个清晰的对照表：
| 安全环境 | 实现方式 | 隔离级别 | 典型性能 | 常见设备 |
|---|---|---|---|---|
| TEE（TrustZone） | CPU 切换安全世界 | 中等（共享 CPU） | ~10ms/操作 | 大部分 Android 手机 |
| SE（eSE / iSE） | 独立安全芯片 | 高（物理隔离） | ~100ms/操作 | 高端手机、POS 机 |
| Strongbox | 专用安全协处理器 | 极高（独立 OS） | ~200ms/操作 | Pixel、三星旗舰 |
| 软件实现 | TEE 不可用时降级 | 无隔离 | ~1ms/操作 | 低端设备 |
你可能会问：「为什么不直接用 Strongbox 性能又慢？还要它干嘛？」
因为某些场景（比如支付、数字车钥匙）要求密钥不可被 root 进程读取。Strongbox 的密钥，连系统自己都拿不到。我当年做车联网项目，客户要求密钥生命周期内不能离开安全芯片一步，只能选 Strongbox。结果 ANR 频发——每个操作平均 200ms，主线程根本扛不住。后来我们做了异步队列 + 协程才解决。
3. 安全环境：隔离是怎么做到的？
Android Keystore 的核心思路是「密钥不出安全区」。无论你是用 TEE 还是 SE，密钥的明文永远留在硬件内部。App 发来的加密操作请求，会被框架层打包成命令，传给 HAL，再让硬件执行。返回的结果只是签名后的数据，而非密钥本身。
我见过最典型的错误：有人把密钥导出到 KeyStore 外部，然后自己用 AES/CBC/PKCS7Padding 加密文件——这完全失去了硬件保护的意义。密钥一旦离开安全环境，就等同于裸奔。正确的做法是利用 KeyStore 提供的 Signer / Encrypt 接口，在硬件里完成所有操作。
KeyStore.getEntry() 获取 PrivateKey 对象，然后手动做 RSA 加密。结果 Android 9 之后，这种操作直接抛 KeyStoreException。因为高版本 KeyStore 强制要求通过 Cipher 或 Signature 对象调用，不允许直接接触密钥引用。嗯，从此我对「密钥隔离」有了更深的认识。
4. 核心流程：一张图看懂
下面这张图总结了 Keystore 从应用层到硬件层的完整数据流。注意每个环节都可能成为 ANR 的源头：
5. 代码勘察：从 API 到硬件到底走了多远
光看图不够，我直接用一段伪代码还原调用链，你就明白异步化为什么这么重要了：
// 你的 App 里
val signature = Signature.getInstance("SHA256withRSA")
signature.initSign(privateKey) // ← 这里触发了 IPC 到 Keystore 系统服务
// 系统服务中：
// → Keymaster HAL 的 begin() 方法
// → 通过 HIDL 发给 TEE Driver
// → TEE OS 里的安全任务开始执行
// → 返回签名数据
// 整个链路，最慢的是硬件操作。TEE 大约 5-10ms，SE 约 50-100ms，Strongbox 甚至 200ms+
// 如果主线程直接调，卡顿是必然的。这就是 ANR 的根源。
initSign 超过 20ms，我就直接启用协程包装，把后续操作切到 Dispatchers.IO。实践证明，对于支持 Strongbox 的设备，没有异步化，ANR 几乎是 100%。
6. 关于「安全环境」你需要知道的坑
最后一个知识点：Android 设备不一定都有硬件安全环境。Google 要求 Android 9+ 必须支持 Keymaster HAL，但硬件实现可以很廉价。有些 OEM 直接把 TEE 跑在 CPU 的非安全世界，用软件模拟——这叫「伪硬件」。我在某款千元机上就遇到过：明明 isHardwareBacked() 返回 true，但密钥操作耗时超过 1 秒。后来测试发现，它所谓的硬件支持其实是纯软件模拟，每秒只能做 2 次 RSA 签名。这种情况下，你不做异步化，App 直接卡死。
怎么判断？我用一个土办法：调用 KeyGenParameterSpec.Builder.setIsStrongBoxBacked(true) 后，如果抛出 StrongBoxUnavailableException，说明该设备没有 Strongbox。然后通过 getFeature("android.hardware.strongbox_keystore") 进一步确认。记住，千万不要相信 isHardwareBacked() 的返回值，它可能骗你。