2. Android安全体系基础：系统安全机制概览、TEE/SE角色、KeyStore与硬件认证、安全启动链

本章作为架构方案型课程的安全基础篇，旨在为后续组件设计构筑完整的系统安全全景图。Android 的安全并非单一模块，而是一套从芯片到应用层、从开机到运行时的多层信任体系。理解组件边界、系统分层与信任链路，是正确选型与规避风险的前提。

2.1 系统安全机制分层

Android 安全体系自下而上可分为四层：硬件安全层、内核与平台层、框架层与应用层。每一层都对其上层提供明确的安全边界与保障假设。

分层核心机制组件/实体保护边界
硬件安全层安全启动链、TEE/SE、硬件密钥SoC熔丝、Boot ROM、TrustZone防回滚、物理防篡改
内核与平台层SELinux、dm-verity、文件级加密Linux内核、init进程、vold进程隔离、非授权访问阻断
框架层权限模型、Keystore API、Credential ManagerPackageManager、KeyStoreService应用间数据隔离、凭据安全
应用层签名验证、数据备份规则、App SandboxZygote启动、APK签名应用自身数据域保护

2.2 安全启动链与信任锚点

安全启动链（Secure Boot Chain）是 Android 信任模型的起点。从硬件熔丝（eFuse）到 Boot ROM，再到 Bootloader、内核、system 分区验证，形成一个不可逆的信任传递链条。任何一个环节被篡改，链条将被切断。

Android 安全启动链信任流 Android 安全启动信任链 SoC 熔丝 不可篡改信任根 Boot ROM 验证下一级公钥 Bootloader 校验 boot 分区 Linux 内核 加载 system 分区 ⚠ 每个阶段验证 下一阶段签名或哈希 ⚠ vbmeta/dm-verity 校验系统分区完整性 system / vendor / product 分区 哈希树验证（dm-verity）

2.3 KeyStore 与硬件认证

Android KeyStore 系统是应用层与硬件安全层之间的桥梁。它提供密钥生成、存储与使用接口，并与 TEE（Trusted Execution Environment）或 SE（Secure Element）交互，确保密钥材料不会暴露于 Android 主操作系统。

  • 组件边界：KeyStore API（框架层）→ KeyStore Service（系统服务层）→ TEE Client API（HAL 层）→ TEE/SE（硬件安全层）。
  • 关键能力：
    • 密钥仅在安全环境中生成，私钥永不离核。
    • 支持 Key attestation：返回由 TEE 签名的证书链，证明密钥在硬件安全环境中生成与存储。
    • 支持物理回滚防护（Rollback Protection）和用户身份绑定（User Authentication Binding）。
架构权衡点：
使用 TEE-backed KeyStore 相比纯软件实现，能够抵御应用的任意内存读取（如 Frida 注入），对敏感数据（如支付密钥、设备解锁凭证）是强依赖。但引入 TEE 会增加系统集成复杂性与调试难度。

2.4 TEE 与 SE 的角色区分

维度TEE（Trusted Execution Environment）SE（Secure Element）
硬件形态集成在 SoC 中的安全世界（如 ARM TrustZone）独立的智能卡级安全芯片（eSE / SIM）
隔离强度物理隔离但共享主存（部分架构）完全独立 CPU、RAM、ROM
典型应用KeyStore、DRM、支付 SIM 鉴权、NFC 支付、电子钱包
开发成本需要 TA（Trusted Application）开发与认证需要 GP（GlobalPlatform）或 OTA 部署
第三方集成厂商定制，可移植性稍弱标准化程度高（Java Card）

2.5 选型权衡与风险分析

  • 信任链路长度：每增加一层验证环节，启动时间增加 200~800ms，需在安全与体验之间平衡。
  • TEE vs. 软件 fallback：低端设备或不支持 TEE 的设备，必须设计软件 fallback 策略（如基于 StrongBox 的 Keystore），但需明确记录其安全等级降级。
  • 密钥生命周期管理：密钥到期、吊销、更新机制是常见忽略点。尤其 Key attestation 证书链需要定期刷新。
  • 攻击面：
    • Boot ROM 不可修复漏洞（如高通 LK 漏洞）可能导致整个信任链失效。
    • TEE 侧通道攻击（如 Cache 定时攻击）可能泄露密钥材料。
    • KeyStore API 误用（如未设置密钥目的 flag）会降低硬件安全性。
常见误判：默认认为所有 Android 设备都具备同级 TEE 能力。实际上，Android Go、部分智能电视、老旧设备可能仅有软件 Keystore。架构设计时应将 TEE 存在性作为运行时检测项，而非硬编码假设。

2.6 落地实施关键步骤

  1. 设备安全属性检查：运行时通过 KeyStore.getInstance().getSotwareBackedFlag() 或 KeyStore.getInstance().isHardwareBacked() 判断当前设备是否支持硬件 Keystore。
  2. 配置安全策略：在 AndroidManifest 中声明 <uses-feature android:name="android.hardware.keystore.app_attest_key" android:required="false"/>，避免在无硬件设备上崩溃。
  3. Key attestation 适配：实现 KeyStore.getCertificateChain() 并通过 DeviceAttestationService 验证证书链可信根。
  4. 安全启动验证：在启动流程中集成 avbctl 命令检查 /sys/kernel/security/avb 状态，确保设备未处于锁定状态。
  5. 密钥更新与回滚：设计密钥轮换机制，利用 KeyGenParameterSpec.Builder.setKeyValidityEnd() 设置过期时间，过期后强制重新生成。

2.7 验收标准

  • 基础验证：在支持 TEE 的设备上，对生成的密钥执行 KeyInfo.isInsideSecurityHardware() 返回 true。
  • 攻击模拟：尝试在 root 设备上导出已生成密钥，预期失败（错误码 KeyStoreException: UNSUPPORTED_KEY_PURPOSE 或 SECURITY_EXCEPTION）。
  • 启动链完整性：执行 adb shell verifyboot 或读取 boot_reason 属性，确认验证通过。
  • 证书链验证：调用 CertificateChainValidator.validate() 确认 attestation 证书链可信且未过期。
  • 跨版本兼容：在 Android 8.0～Android 14 多个 API 级别的模拟器与真机上验证 KeyStore 基础功能可用。
← 上一章 📖 返回目录 下一章 →