1. 数据保护组件设计总览

1.1 威胁模型驱动的设计起点

Android 数据保护组件的设计必须以威胁模型为起点。攻击面覆盖硬件、内核、框架、应用四个层级，攻击者可能通过物理访问、侧信道、提权、应用层漏洞等路径窃取或篡改数据。STRIDE 模型是威胁分析的基础框架，下表演示各层面临的典型威胁与对应的数据保护策略锚点。

1.2 组件设计目标

数据保护组件需达成四个核心目标，它们共同构成架构决策的评判标准：

• 机密性： 数据在存储、传输、处理过程中不被未授权实体读取。依赖加密算法强度与密钥隔离等级。
• 完整性： 检测并防止数据被篡改或回滚。依赖签名、HMAC、防回滚计数器。
• 可用性： 合法用户能在授权时限内可靠访问数据。依赖密钥备份、灾难恢复、降级策略。
• 可审计性： 所有数据访问操作可追溯、可归因。依赖安全日志、远程证明、访问记录。

四个目标之间存在权衡：强机密性可能降低可用性（如 TEE 密钥丢失后无法恢复），完整性校验会增加访问延迟。架构决策需根据业务场景确定优先级。

1.3 整体架构分层

数据保护组件采用四层纵深架构。下方 SVG 展示各层核心模块、层间数据流与信任链路方向：

1.4 关键设计原则

基于威胁模型与分层架构，数据保护组件必须遵循以下设计原则：

• 纵深防御： 不依赖单层安全机制。即使某一层被突破，下层仍能保护核心密钥与数据。
• 最小权限： 每个组件只拥有完成其功能所需的最小数据访问权限。密钥使用策略强制执行。
• 安全默认： 所有加密、签名、访问控制默认启用并采用推荐强度，不允许开发者在安全与便捷之间选择弱配置。
• 信任锚点硬件化： 根密钥必须锚定在硬件隔离区（TEE/SE），避免根密钥被软件提取。
• 可降级与可恢复： 组件需提供降级路径（如 TEE 不可用时降级到软件密钥容器）和灾难恢复机制，但降级必须经用户明确授权。

1.5 组件边界与信任链路

四层架构的组件边界由信任链路连接。下表演示各层间的信任关系与数据流约束：

1.6 选型权衡

数据保护组件的技术选型需在以下维度进行权衡：

• 硬件隔离 vs. 兼容性： TEE 提供最强隔离，但碎片化严重（OEM 实现差异）。软件 KeyStore 兼容性好但安全强度低。推荐策略：优先硬件锚定，不可用时降级并提示用户。
• 加密粒度 vs. 性能： 文件级加密（fscrypt）性能优于块级加密（dm-crypt），但可能泄露文件大小和访问模式。敏感元数据建议使用块级加密。
• 密钥可恢复 vs. 防泄漏： 云端备份密钥提升可用性，但增加攻击面。采用用户提供的密码派生密钥（非对称包装）可平衡两者。
• 远程证明 vs. 隐私： 远程证明可验证设备安全状态，但可能收集设备标识。使用匿名证明或选择性披露策略。

1.7 落地步骤

在企业级 Android 产品中落地数据保护组件，建议按以下阶段推进：

1. 威胁建模（第1-2周）： 识别资产、信任边界、攻击路径，输出 STRIDE 威胁清单与风险等级。
2. 架构决策（第3-4周）： 确定硬件安全锚点方案（TEE/SE/软件降级），定义层间接口契约与信任链路。
3. 核心组件实现（第5-10周）： 依次实现硬件适配层、内核 KeyStore 扩展、框架加密 API、应用 SDK。每层独立单元测试 + 安全测试。
4. 集成与审计（第11-12周）： 端到端数据流验证、权限审计、远程证明联调。
5. 灾难恢复演练（第13周）： 模拟 TEE 芯片损坏、密钥被锁、设备丢失等场景，验证降级与恢复流程。

1.8 验收标准

组件交付时须通过以下验收检查点：