在现代移动设备中，密钥管理和硬件安全构成了整个安全体系的基石。Android从早期版本开始就不断强化其密钥管理机制，从纯软件实现逐步演进到依赖专用硬件安全模块。本章将深入剖析Android Keystore系统、Trusty TEE（可信执行环境）、硬件密钥认证以及安全启动链的实现原理。我们将重点关注这些机制如何协同工作以保护用户数据和系统完整性，并与iOS的安全架构进行对比分析。通过本章学习，读者将掌握Android硬件安全的核心概念和实现细节，理解如何在应用开发中正确使用这些安全特性。
Android Keystore系统经历了多个重要演进阶段：
Keystore系统采用分层架构设计，从上到下包括：
应用层接口
系统服务层
HAL层
硬件层
Android支持多种密钥存储后端：
软件密钥存储
硬件密钥存储
密钥Blob格式
KeyBlob {
version: u8,
key_material: encrypted_bytes,
auth_tags: AuthorizationSet,
hw_enforced: AuthorizationSet,
sw_enforced: AuthorizationSet,
nonce: [u8; 12], // GCM nonce
tag: [u8; 16], // GCM authentication tag
}
密钥特征（Key Characteristics）
密钥生成流程
密钥使用授权
密钥销毁机制
密钥迁移与备份
| 特性 | Android Keystore | iOS Keychain |
|---|---|---|
| API设计 | Java密码学架构 | C/Objective-C API |
| 硬件支持 | Keymaster HAL标准化 | Secure Enclave专有 |
| 密钥类型 | 完整密码学算法支持 | 主要支持椭圆曲线 |
| 访问控制 | 基于UID和别名 | 基于entitlement |
| 云同步 | 不支持 | iCloud Keychain |
| 密钥认证 | Key Attestation | DeviceCheck |
| 跨应用共享 | 通过KeyChain API | Keychain Access Groups |
| 密钥迁移 | 不支持直接迁移 | iCloud同步迁移 |
| 默认安全级别 | 可选软/硬件 | 默认Secure Enclave |
密钥隔离
防回滚保护
侧信道防护
运行时安全检查
可信执行环境（Trusted Execution Environment）是与主操作系统隔离的安全执行环境：
硬件隔离机制
TEE与REE通信
安全监控器（Secure Monitor）
Google开发的Trusty是Android推荐的TEE操作系统：
Trusty内核特性
Trusty应用框架
Trusty应用开发
Keymaster是Trusty中最重要的可信应用：
Keymaster TA架构
Keymaster TA
├── 密钥生成模块
│ ├── RSA密钥生成 (2048/3072/4096位)
│ ├── ECC密钥生成 (P-256/P-384/P-521)
│ ├── AES密钥生成 (128/256位)
│ └── HMAC密钥生成
├── 密钥存储模块
│ ├── 密钥加密/解密
│ ├── 密钥导入/导出
│ ├── 密钥元数据管理
│ └── 密钥版本控制
├── 密码学操作模块
│ ├── 加密/解密 (AES-GCM/CBC/CTR/ECB)
│ ├── 签名/验证 (RSA-PSS/PKCS#1, ECDSA)
│ ├── 密钥协商 (ECDH, DH)
│ └── 消息认证 (HMAC-SHA256/512)
├── 认证模块
│ ├── 密钥认证生成
│ ├── 使用授权验证
│ └── 设备ID认证
└── 安全服务
├── 随机数生成 (TRNG)
├── 安全时钟
└── 防回滚计数器
安全密钥存储
Keymaster命令处理
Gatekeeper负责用户凭据验证：
功能设计
防暴力破解
| TEE方案 | 特点 | 应用场景 | 安全特性 |
|---|---|---|---|
| Trusty | Google开发，开源 | Pixel设备 | 微内核、完全隔离 |
| QSEE | 高通方案，闭源 | 骁龙平台 | 丰富的TA生态 |
| TrustedCore | 华为方案 | 麒麟平台 | 形式化验证 |
| Kinibi | 三星方案 | Exynos平台 | 实时操作系统 |
| OP-TEE | 开源参考实现 | 开发测试 | GlobalPlatform标准 |
各方案技术差异
QSEE（Qualcomm Secure Execution Environment）：
TrustedCore：
Kinibi（t-base）：
密钥认证（Key Attestation）是Android提供的一种机制，用于验证密钥确实存储在硬件安全模块中，并且具有特定的属性。这是建立设备信任链的关键技术。
认证目标
Key Attestation生成一个X.509证书链：
证书链组成
证书验证路径
用户密钥证书 ← 设备中间证书 ← Google根证书
↓ ↓ ↓
签名验证 签名验证 信任锚
认证扩展结构
KeyDescription ::= SEQUENCE {
attestationVersion INTEGER,
attestationSecurityLevel SecurityLevel,
keymasterVersion INTEGER,
keymasterSecurityLevel SecurityLevel,
attestationChallenge OCTET STRING,
uniqueId OCTET STRING,
softwareEnforced AuthorizationList,
teeEnforced AuthorizationList,
}
SecurityLevel ::= ENUMERATED {
Software(0),
TrustedEnvironment(1),
StrongBox(2),
}
AuthorizationList ::= SEQUENCE {
purpose [1] EXPLICIT SET OF INTEGER OPTIONAL,
algorithm [2] EXPLICIT INTEGER OPTIONAL,
keySize [3] EXPLICIT INTEGER OPTIONAL,
digest [5] EXPLICIT SET OF INTEGER OPTIONAL,
padding [6] EXPLICIT SET OF INTEGER OPTIONAL,
ecCurve [10] EXPLICIT INTEGER OPTIONAL,
rsaPublicExponent [200] EXPLICIT INTEGER OPTIONAL,
rollbackResistance [303] EXPLICIT NULL OPTIONAL,
activeDateTime [400] EXPLICIT INTEGER OPTIONAL,
originationExpireDateTime [401] EXPLICIT INTEGER OPTIONAL,
usageExpireDateTime [402] EXPLICIT INTEGER OPTIONAL,
userAuthType [504] EXPLICIT INTEGER OPTIONAL,
authTimeout [505] EXPLICIT INTEGER OPTIONAL,
allowWhileOnBody [506] EXPLICIT NULL OPTIONAL,
trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL,
trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL,
unlockedDeviceRequired [509] EXPLICIT NULL OPTIONAL,
creationDateTime [701] EXPLICIT INTEGER OPTIONAL,
origin [702] EXPLICIT INTEGER OPTIONAL,
rootOfTrust [704] EXPLICIT RootOfTrust OPTIONAL,
osVersion [705] EXPLICIT INTEGER OPTIONAL,
osPatchLevel [706] EXPLICIT INTEGER OPTIONAL,
attestationApplicationId [709] EXPLICIT OCTET STRING OPTIONAL,
attestationIdBrand [710] EXPLICIT OCTET STRING OPTIONAL,
attestationIdDevice [711] EXPLICIT OCTET STRING OPTIONAL,
attestationIdProduct [712] EXPLICIT OCTET STRING OPTIONAL,
vendorPatchLevel [718] EXPLICIT INTEGER OPTIONAL,
bootPatchLevel [719] EXPLICIT INTEGER OPTIONAL,
...
}
客户端认证请求
服务器验证流程
关键API调用
认证结果解析
// 解析认证扩展
AttestationExtension ext = parseAttestationExtension(cert);
// 验证安全级别
if (ext.attestationSecurityLevel == SecurityLevel.StrongBox) {
// 最高安全级别
} else if (ext.attestationSecurityLevel == SecurityLevel.TrustedEnvironment) {
// TEE级别安全
}
// 检查硬件强制属性
AuthorizationList hwEnforced = ext.teeEnforced;
verifyHardwareEnforcedProperties(hwEnforced);
Root of Trust包含设备启动状态信息：
RootOfTrust结构
RootOfTrust ::= SEQUENCE {
verifiedBootKey OCTET STRING,
deviceLocked BOOLEAN,
verifiedBootState VerifiedBootState,
verifiedBootHash OCTET STRING,
}
VerifiedBootState ::= ENUMERATED {
Verified(0),
SelfSigned(1),
Unverified(2),
Failed(3),
}
安全状态判断
验证实践
// 服务端验证逻辑
RootOfTrust rot = attestation.getRootOfTrust();
// 检查设备锁定状态
if (!rot.deviceLocked) {
// 设备已解锁，降低信任度
}
// 检查启动状态
switch (rot.verifiedBootState) {
case Verified:
// 完全可信
break;
case SelfSigned:
// 开发者设备，需要额外验证
break;
case Unverified:
case Failed:
// 不可信，拒绝服务
break;
}
// 验证启动密钥哈希
verifyBootKeyHash(rot.verifiedBootKey);
除了Key Attestation，Android还提供应用级的设备认证：
SafetyNet Attestation（已弃用）
Play Integrity API（推荐）
集成要点
判定标准层次：
1. 设备完整性：未root、官方系统
2. 基本完整性：可能已root但未主动攻击
3. 应用完整性：APK未被篡改
4. 账号可信度：非机器人账号
5. 环境安全性：无屏幕录制、辅助服务
API差异对比 | 特性 | SafetyNet | Play Integrity | |——|———–|—————-| | 发布时间 | 2013 | 2021 | | 状态 | 已弃用 | 推荐使用 | | 检测范围 | 设备状态 | 设备+应用+环境 | | 防篡改 | 中等 | 强 | | 性能影响 | 较大 | 优化 | | API限制 | 无 | 有配额限制 |
Android 9引入StrongBox，提供更高安全级别：
StrongBox要求
与TEE Keymaster对比 | 特性 | TEE Keymaster | StrongBox | |——|—————|———–| | 隔离级别 | 软件隔离 | 硬件隔离 | | 性能 | 较高 | 较低 | | 抗物理攻击 | 有限 | 强 | | 成本 | 低 | 高 | | 支持算法 | 完整 | 有限 | | 典型实现 | ARM TrustZone | Titan M/SE |
StrongBox限制
使用场景建议
iOS设备认证机制
主要差异
Android Verified Boot (AVB) 确保设备运行可信的软件：
启动链信任传递
ROM Boot → Bootloader → Kernel → System
↓ ↓ ↓ ↓
验证下级 验证下级 验证下级 验证应用
保护目标
ROM Boot阶段
Bootloader验证
Kernel验证
System验证
AVB元数据结构
AvbVBMetaImageHeader {
magic[4]: "AVB0"
version_major: u32
version_minor: u32
authentication_data_block_size: u64
auxiliary_data_block_size: u64
algorithm_type: u32
hash_offset: u64
hash_size: u64
signature_offset: u64
signature_size: u64
public_key_offset: u64
public_key_size: u64
...
}
分区验证方式
vbmeta分区
Device-Mapper Verity提供透明的块设备完整性检查：
工作原理
应用读取 → VFS → dm-verity → 块设备
↓
验证哈希树
哈希树结构
错误处理模式
版本管理机制
回滚攻击防护
if (image.rollback_index < stored_rollback_index) {
// 拒绝启动，防止降级到有漏洞的版本
boot_failed();
}
设备锁定状态
解锁影响
iOS Secure Boot
Windows Secure Boot
鸿蒙安全启动
本章深入探讨了Android密钥管理与硬件安全的核心机制：
Keystore系统提供了分层的密钥管理架构，从应用API到硬件安全模块，实现了密钥的安全生成、存储和使用。关键概念包括密钥生命周期管理、硬件密钥隔离、使用授权机制。
Trusty TEE作为可信执行环境，通过ARM TrustZone技术实现了与主系统的硬件隔离。Keymaster TA和Gatekeeper TA在TEE中提供关键的密码学服务和用户认证功能。
硬件密钥认证通过Key Attestation机制，生成包含设备安全状态的X.509证书链，使远程服务器能够验证密钥的硬件属性。StrongBox进一步提供了独立安全芯片级别的保护。
安全启动链通过Verified Boot确保从ROM到System的每一级启动组件都经过验证。dm-verity提供运行时的系统完整性保护，防回滚机制防止降级攻击。
关键公式和概念：
KEK = KDF(HUK, User_Credential)Verify(Cert[i], PublicKey[i+1])RootHash = Hash(Hash(Block1) || Hash(Block2) || ...)image.rollback_index ≥ stored_rollback_index1. Keystore密钥存储位置 Android Keystore中的密钥材料存储在哪里？软件密钥和硬件密钥的存储有何区别？
提示：考虑密钥材料的可访问性和安全边界。
2. TEE通信机制 普通世界（REE）的应用如何与TEE中的可信应用通信？描述基本的通信流程。
提示：思考CPU如何在两个世界之间切换。
3. Key Attestation证书链 描述Android Key Attestation生成的证书链结构，每个证书的作用是什么？
提示：类比HTTPS证书链的验证过程。
4. 侧信道攻击防护 设计一个密码学操作需要考虑哪些侧信道攻击？Android Keystore如何防护这些攻击？
提示：考虑攻击者可以观察到的物理特征。
5. 安全启动绕过场景 分析以下场景：攻击者物理接触设备并尝试刷入修改过的系统镜像。Verified Boot如何防止这种攻击？存在哪些可能的绕过方法？
提示：考虑攻击者的能力和系统的防护边界。
6. 跨平台密钥迁移 设计一个方案，允许用户在Android和iOS设备之间安全地迁移加密密钥。需要考虑哪些安全和技术挑战？
提示：硬件绑定的密钥设计初衷就是防止迁移。
7. TEE漏洞利用分析 假设在Trusty TEE的某个TA中发现了缓冲区溢出漏洞。分析这个漏洞的潜在影响和利用难度。
提示：TEE设计目标是即使REE被攻破也能保护关键资产。
8. 安全芯片设计权衡 比较集成在SoC中的安全子系统（如ARM TrustZone）与独立安全芯片（如Titan M）的优缺点。在什么场景下应该选择哪种方案？
提示：安全性、成本、性能的三角权衡。