1. 安全存储概述：为什么需要安全存储？

说实话，我做了十几年安全开发，见过太多产品因为「存储不当」被攻破。你想想看，一个 App 的核心逻辑写得再牛，密钥直接明文躺在内存里——那跟没锁门有什么区别？

安全存储，说白了就是保护敏感数据在「静止状态」下的机密性和完整性。这里的敏感数据包括：私钥、会话 Token、用户密码、支付凭证、加密密钥等等。

1.1 为什么不能依赖常规存储？

我遇到过不少团队，把密钥写在 SharedPreferences 里，或者硬编码在代码中。嗯，结果呢？逆向工程师用个反编译工具，三分钟就拿到了。

常规存储的问题在于：

• 文件系统无保护——任何有 root 权限的进程都能读
• 内存无隔离——同一个进程内的所有数据，其他线程/模块都能访问
• 持久化无加密——写入磁盘的数据就是原始明文

你可能会问：「那我用 AES 加密一下再存不就行了？」——问题是，加密密钥放哪？这就成了鸡生蛋蛋生鸡的问题。

1.2 常见的安全威胁

下面这三种威胁，是我在实战中遇到最多的。我一个个说。

1.2.1 逆向工程

逆向工程，说白了就是攻击者把你的二进制文件拆开，看你的代码逻辑。我见过最夸张的一次，对方直接用 IDA Pro 加载了我们的 so 文件，然后搜索字符串「key」——结果真让他找到了一个变量名叫 encrypt_key。

常见的逆向手段包括：

• 静态分析：反汇编、反编译，直接读源码级别的逻辑
• 动态调试：用 GDB、Frida 等工具在运行时修改流程、读取变量
• 符号恢复：通过未剥离的符号表直接定位关键函数

1.2.2 内存 dump

这个更直接。攻击者不需要理解你的代码逻辑，他只需要在某个时刻把进程的内存镜像 dump 下来，然后搜索密钥特征。

我参与过一个金融 App 的安全审计。对方团队说「我们密钥只在内存中使用 100 毫秒就擦除了」。听起来很安全对吧？结果我们用 gcore 在密钥使用期间 dump 了一次内存，然后 grep 了一下——密钥赫然在列。

为什么？因为 100 毫秒对于现代 CPU 来说太长了。攻击者可以精确地在那个时间窗口内触发 dump。

攻击方式	原理	防御难度
进程内存 dump	读取 /proc/pid/mem 或使用 ptrace	中
核心转储	触发 crash 后分析 core dump 文件	低
冷启动攻击	重启后从 DRAM 残留数据中恢复密钥	高
JTAG/SWD 调试	硬件级读取内存总线数据	极高

1.2.3 侧信道攻击

侧信道攻击，嗯，这个比较高级。攻击者不直接读你的数据，而是通过「旁路信息」来推断密钥。

常见的侧信道包括：

• 时序攻击：根据加密操作的执行时间差异，推断密钥位
• 功耗分析：通过芯片的功耗波形，还原加密操作中的中间值
• 电磁辐射：采集设备运行时的电磁信号，分析密钥
• 缓存侧信道：利用 CPU 缓存的命中/未命中时间差，推断其他进程的数据

我记得有一次帮客户做智能门锁的安全评估。他们的 AES 实现是标准的查表法，结果我们用简单的功耗分析，在示波器上直接看到了 S 盒查表的功耗特征——密钥的每一位都能对应到波形上。

1.3 安全存储的核心目标

综合上面的威胁，我们可以总结出安全存储需要达成的几个目标：

1. 机密性——密钥不能被未授权读取
2. 完整性——密钥不能被篡改而不被发现
3. 及时擦除——密钥使用完后，内存中不留痕迹
4. 隔离性——密钥存储区域与其他数据区域隔离
5. 抗侧信道——操作过程不泄露密钥信息

你可能会觉得，这么多要求，是不是太苛刻了？其实不然。后面我们会讲到，通过硬件安全模块（HSM）、TEE、安全元件（SE）等方案，这些目标是可以实现的。

1.4 本章知识体系

下面这张图，是我个人习惯用来梳理安全存储知识体系的框架。你可以先有个整体印象。

1.5 小结

这一章我们聊了为什么需要安全存储，以及常见的三种威胁：逆向工程、内存 dump、侧信道攻击。我个人觉得，理解威胁是防御的第一步。很多开发者一上来就想着怎么加密、怎么混淆，却忽略了「攻击者到底是怎么拿到密钥的」——这才是问题的根源。

后面的章节，我们会深入到具体的防御技术。从密钥的生命周期管理，到内存擦除的最佳实践，再到硬件隔离方案，一步步把安全存储这件事做扎实。