定制AOSP开发中如何安全存储应用所需第三方私钥

针对定制硬件+定制AOSP的开发场景，不需要受普通第三方应用的能力边界限制，以下是经过量产验证的软硬件落地方案，按落地成本和安全等级排序：

硬件级固化方案 #

这类方案中私钥完全不进入Android普通用户空间，设备被root、甚至被拆片读取闪存都无法提取私钥，安全等级最高：

• SoC内置eFuse/OTP烧录：主流量产SoC都预留了一次性可编程的eFuse/OTP存储区域，可在产线烧录环节将私钥写入该区域。该区域写入后无法篡改，用户空间（包括root权限进程）无法直接读取私钥明文，只需要在内核层加一个极简驱动，仅向目标应用开放私钥运算接口（比如签名、解密），接口只返回运算结果、不回传私钥本身即可。该方案无需额外硬件，开发量极小。
• 板载安全元件（SE）对接：如果硬件本身预留了SE芯片（常见于支付、工控类硬件），可直接将私钥存入SE的安全存储区，所有私钥相关运算全部在SE内部完成，对外仅暴露运算接口。只需要在定制AOSP时编译对应SE的HAL层服务，给目标应用开放对应调用权限即可，不需要改动核心业务逻辑。

TEE调用方案 #

你提到的TEE能力，普通无系统签名的第三方应用确实无法直接调用，但在定制AOSP场景下完全可以打通，不存在权限障碍：

• 核心实现逻辑是把私钥运算逻辑编译为可信应用（TA）部署到TEE侧，私钥在产线阶段直接写入TEE的安全存储区，普通Android系统侧（REE）全程接触不到私钥明文。
• 在AOSP系统层新增一个轻量Binder服务，仅对外暴露必要的私钥运算接口，给目标应用配置专属的signature级权限，只有和平台证书签名一致的目标应用才能调用该服务；服务收到请求后转发给TEE侧的TA执行运算，拿到结果后回传给应用即可。
• 目前主流ARM SoC都自带TrustZone支持TEE，如果使用开源OP-TEE这类通用TEE OS，TA开发门槛很低，整体开发量远低于搭建远端密钥服务。

低改造成本软件方案 #

如果不想改动硬件、TEE逻辑，可以直接复用Android原生安全能力，改造成本极低：

• 直接使用系统Keystore存储私钥，将目标应用配置为系统特权应用，导入私钥时开启强硬件绑定参数：setIsStrongBoxBacked(true)（硬件支持时优先选）、绑定设备硬件根密钥、可根据业务场景设置密钥使用时的身份校验规则。该方案下密钥存储在硬件安全区域，和设备硬件唯一标识绑定，就算设备被root，密钥被提取后换到其他设备也完全无法使用；如果root时解锁Bootloader触发数据分区擦除，密钥会被直接销毁。
• 注意不要用普通加密文件的方式存储密钥，这类方案root后可直接从内存或存储中拿到明文，安全等级和Keystore不在一个层级。

选型参考
安全等级从高到低：板载SE > eFuse/OTP烧录 > TEE存储 > 系统Keystore > 此前评估的三类方案
开发成本从低到高：系统Keystore < eFuse/OTP烧录 < TEE存储 < 板载SE < 远端拉取方案

内容的提问来源于stack exchange，提问作者ZenUser