一家医疗健康初创公司可能花数月设计安全的移动工作流，却发现越狱测试人员的手机通过截图和本地缓存泄露了患者记录。与此同时，团队 Electron 管理面板的 debug build 可能在 bundle 中嵌入了 API 密钥。这两起事件都涉及加密，但都不是加一个加密库就能解决的。
应用加密是一套决策体系。 团队必须决定：数据在存储时如何保护、如何在系统间传输、密钥存放在哪里、攻击者能从应用包中了解到什么、运行时如何应对篡改，以及签名更新如何维持这些保障。一个实用的切入点是： Capacitor 应用 OTA 安全检查清单 该清单梳理了敏感数据、信任边界、客户端能力以及可能的滥用路径。
移动端和跨平台应用面临异常高的暴露风险。设备会离开办公场所，构建产物可能被复制或侧载，本地文件可能被检查，逆向工程工具也随处可见。下文将逐步建立这一模型，从存储与传输，到平台密钥保护、客户端保密、合规及发布运维。
目录
- 为什么应用加密比以往任何时候都更重要
- 静态加密与传输加密对比
- 保护应用内的 Code、数据和机密
- iOS、Android、Capacitor 及 Electron 的平台考量
- 密钥管理与客户端保密性的局限
- 监管与合规影响
- 常见误区与加固最佳实践
- 构建完整的加密方案
为什么应用加密比以往任何时候都更重要
Web 应用通常将其大部分敏感逻辑和密钥存储在企业控制的基础设施上。而移动应用则需将 code、资源、配置和数据处理逻辑发送到属于他人的设备上。Electron 应用也面临类似问题，因为其 JavaScript、资源和打包文件都可以被运行该应用的终端用户查看。
这改变了安全边界。 客户端虽然有用，但它并不是保险库。 加密可以防止信息被随意查看，并降低被盗文件的利用价值，但应用在某些时刻仍需访问明文。控制了设备的攻击者可以观察输入、检查内存、拦截 API 或修改执行流程。
以医疗场景为例。加密数据库可以保护从磁盘拷贝的记录，但无法阻止被攻破的运行时将解密后的记录展示给恶意进程。加密网络流量可以保护临床医生发送至后端的请求，但无法保护应用将其保存到未受保护的缓存后的本地导出文件。如果应用必须使用某个隐藏在混淆 JavaScript 中的密钥，该密钥仍然是可以被找回的。
实战规则： 请将每种客户端防护都视为降低风险暴露的防御层，而不是设备可信的证明。
一个完整的方案通常结合了：
- 静态数据保护，涵盖数据库、文件、缓存、偏好设置及已下载文档。
- 传输中数据保护，涵盖请求、同步、更新分发及服务间通信。
- 平台级密钥存储，确保加密密钥不会留在普通应用文件中。
- Code 与运行时保护，包括代码混淆、完整性检查、反调试措施及适当的证书校验。
- 受控的更新通道，因为签名发布版本必须保留早期版本中内建的安全假设。
- 文档化的合规控制，包括责任归属、证据、监控及响应流程。
监管义务会带来压力，但也能提升工程规范性。GDPR、HIPAA、PCI DSS 和 SOC 2 并不会让加密变成一项万能勾选项。它们要求团队理解自己保护什么、密钥如何管控，以及如何证明防护措施按预期运行。
静态加密与传输加密对比
可以把这想象成通过挂号信发送机密文件：密封的信封在传输过程中保护了信息；而一旦收件人拆开信封，文件仍需要存放在带锁的文件柜中。 传输中加密（Encryption in transit）保护的是传输过程，静态加密（Encryption at rest）保护的是存储状态。 信封和文件柜解决的是不同的问题。
静态加密
当数据存储在设备、服务器磁盘、备份、数据库或可移动卷上时，就需要使用静态加密。在移动平台上，操作系统可能会自动加密部分设备内容，但你的应用仍需自行选择安全的存储位置、访问控制和密钥使用方式。敏感的应用文件应使用平台支持的加密技术，并将密钥保存在受保护的存储区中，而不是直接写在加密数据旁边。
在这里，认证加密（Authenticated encryption）至关重要。OWASP 建议使用平台提供的加密 API、硬件支持的密钥存储（如果可用），以及如下认证模式： AES-GCM 或 AES-CCM，这有助于检测篡改并隐藏内容。同样的指南建议对静态数据和传输中数据进行保护，将私密数据存放在内部存储中，并避免使用私有的加密算法，转而使用平台提供的实现（“OWASP 移动应用安全速查表).
具体的实现细节因平台而异。iOS 提供 Data Protection 和 Keychain 服务。Android 提供基于 Keystore 的选项以及可用于管理加密文件的库。桌面应用则更依赖操作系统凭据和本地访问控制。在 Chromium Embedded Framework 环境中处理文件的团队还可以参考 CEF 文档存储的最佳实践 以检查加密算法之外的存储边界。
传输加密
传输中加密保护跨网络传输的请求和响应。配置正确的 TLS 连接有助于防止中间人读取或篡改应用流量，但只有在客户端正确验证服务器且后端提供受信任证书时，TLS 才会生效。禁用证书检查、不安全的降级方案或意外的明文端点都会破坏预期的保护效果。
在特定的移动端场景下，证书固定（Certificate pinning）可以增加一层验证，特别是在团队能够自主管理证书操作并具备轮换恢复计划的情况下。它不能替代正确的 TLS 配置，且错误的固定配置可能会导致合法用户无法访问。使用 Capacitor 进行开发的团队可以研究 针对 Capacitor 应用的 SSL pinning 以评估其运维权衡是否符合应用需求。
这两者的失效模式是互补的。传输层安全无法保护从丢失设备中拷贝出的数据库；存储加密也无法保护通过受损连接提交的密码。应同时设计这两条路径，并测试所有出现明文的点，包括 logs、截图、临时文件、崩溃报告、剪贴板内容以及同步队列。
保护应用内的 Code、数据和机密
团队经常将“加密”、“混淆”和“加固”混为一谈，仿佛它们是同一种控制手段。其实不然。每种手段应对的是不同的攻击行为，混淆概念会带来虚假的安全感。
混淆（Obfuscation）与代码压缩（Minification） 会让 code 更难阅读。它们可以提高克隆应用或理解业务逻辑的成本，但无法让应用必须使用的密钥变得不可用。无论是 JavaScript bundle 中的 API 密钥、归档文件中的签名凭据，还是通过可预测函数重构出的值，仍然可以被提取。例如 Hermes bytecode 和 Electron asar 归档文件可能不如源码那样易于检查，但打包并不等同于保密。
数据加密 在存储时保护用户内容和本地凭据。应使用平台提供的加密 API，并将密钥保存在 Keychain、Keystore、Secure Enclave、StrongBox 或可用的同等操作系统设施中。OWASP 的加密测试指南警告不要将密码或密钥放在源码 code 中，并强调留在客户端的机密可能会被提取（OWASP MASTG 加密测试).
运行时保护 用于发现可能增加篡改或自动化滥用可能性的情况。越狱和 root 信号、调试器检测、应用完整性检查、attestation 以及证书校验可以增加攻击难度或提供响应信号。但没有任何手段能让设备绝对可信。坚定的攻击者可以修改检查逻辑，而合法用户也可能触发启发式规则。
| 保护层 | 保护对象 | 无法阻止的行为 |
|---|---|---|
| Code 代码混淆 | 应用逻辑的可读性与随意克隆 | 提取应用可访问的机密 |
| 数据加密 | 所选存储数据的机密性与完整性 | 合法解密后的明文泄露 |
| 运行时保护 | 部分篡改、调试及自动化滥用 | 控制运行时的资深攻击者 |
A safer design keeps high-value secrets on the server, gives the client narrowly scoped credentials, and encrypts only the local data that needs offline access. Token storage deserves its own review of expiry, revocation, refresh behavior, and platform binding. The 面向移动开发者的安全 Token 存储指南 有助于将这些决策转化为具体的实现需求。
幼稚的方法之所以失败，是因为它们保护的是“秘密的外观”而非“秘密的生命周期”。在源码 code 中对数值进行 XOR 操作、将密钥拆分到多个文件中，或依赖 JavaScript 代码混淆，都无法改变运行中的应用必须重构并使用该数值这一事实。
iOS、Android、Capacitor 及 Electron 的平台考量
相同的加密设计在不同运行时表现各异，因为每个平台提供的密钥库、API、隔离边界和恢复机制都不同。跨平台抽象层可以简化应用的 code，但无法消除这些差异。
原生移动平台
在 iOS 上，Keychain 提供了受保护的凭据存储，而 Secure Enclave 可以将某些密钥操作与主应用处理器隔离。应用仍需根据其可用性需求选择访问控制，例如数据是在设备验证后可用，还是仅在用户通过身份验证后才可用。
Android Keystore 在受支持的设备上提供了硬件级路径，且 StrongBox 在可用时可以提供更强的隔离环境。Android 开发团队还应考虑设备能力、备份行为、身份验证要求和证明信号（attestation signals）。由于硬件支持并不统一，应用需要定义明确的降级策略，而不是假设每台设备都提供相同的保护。
跨平台外壳
Capacitor 应用通过 bridge 将 Web code 与原生平台能力结合。这个 bridge 是一个安全边界，而不仅仅是一个便捷层。 localStorage，IndexedDB 和普通的 Web preferences 默认不应被视为加密的密钥存储。团队必须明确选择原生存储 plugin，或实现一个使用平台受保护密钥机制的原生 module。
Electron 的威胁模型有所不同。其 renderer 处理 Web 内容，而 main process 拥有更广泛的权限，因此敏感操作应远离暴露的 renderer。Electron 的 safeStorage 可以使用操作系统提供的凭据保护，但其安全性取决于宿主操作系统、用户账户、桌面配置以及进程隔离。其密钥不会像移动平台那样自动实现硬件级隔离。
| 平台 | 密钥存储 | 加密 API | 默认威胁模型 |
|---|---|---|---|
| iOS | Keychain 以及（在支持的情况下）Secure Enclave | Apple 平台加密技术与 Data Protection | 设备与 App 分离，但设备或运行时环境被攻破时可能被观测到使用情况 |
| Android | Keystore 以及（在支持的情况下）StrongBox | Android 平台加密技术与 Jetpack security 组件 | 硬件与软件能力因设备而异 |
| Capacitor | 通过插件或自定义 bridge 选用的 Native storage code | Web APIs 结合 Native 平台 APIs | Web assets 在 Native shell 中运行，不会自动继承安全存储 |
| Electron | 通过以下 API 使用 OS 凭据功能： safeStorage |
兼容 Node 和 Chromium 的应用 APIs | 渲染进程暴露与宿主级访问是核心关注点 |
团队应记录各目标平台的行为，而不是把产品描述成“在所有平台上都已加密”。 Capacitor 处理平台差异的方法 有助于把 bridge 定位为平台特定决策必须保持可见的环节。
密钥管理与客户端保密性的局限
加密能否保护数据，取决于密钥管理能否保护密钥。一个实用的生命周期包含五个阶段： 生成、分发、存储、轮换和撤销。每个阶段都会产生不同的故障模式。
使用受信任的平台或服务器加密 API 生成密钥。通过经过身份验证的协议分发密钥，而不是将其嵌入 bundle。尽可能将其存储在受保护的平台设施中。当策略、风险或加密要求需要时轮换密钥。当设备、账户或会话不应再解密数据时，通过服务器控制的授权撤销访问权限。
对于这些操作，客户端比基础设施更弱，因为用户控制着设备，并可能检查应用状态。对于由用户派生口令保护的离线数据，客户端持有密钥是合理的，前提是产品接受恢复和可用性方面的后果。但对于授予广泛后端访问权限的 API token 来说，这就远没那么合理了。如果攻击者提取了该 token，即便对本地数据库加密，也无法限制该 token 在远程能做什么。
信封加密将数据加密密钥与主密钥分离。应用程序可以使用短期数据密钥加密本地对象，而服务端密钥管理服务或基于 HSM 的系统则负责保护封装密钥。远程密钥释放设计可以在释放解密所需的材料之前，要求通过设备身份验证、用户验证、策略决策或证明信号。这些模式虽然不能保证客户端被攻破后依然安全，但它们减少了设备上永久存储的权限量。
OWASP 将本地敏感数据定义为包括个人身份信息、加密材料、机密信息以及 API 密钥。它还将加密与生命周期控制相结合，例如安全本地存储、密钥轮换以及使用后的清零。其架构原则非常明确：
将高价值机密保留在团队控制的系统中。仅向客户端授予其当前任务所需的最小权限。
对于发布系统，密钥管理同样适用于更新签名与交付。团队应明确谁可以对 bundle 进行签名、签名凭据存储在哪里、如何审计访问权限，以及在签名凭据泄露时如何进行更换。关于 通过密钥管理保障 OTA 更新安全 的指南，可以帮助将应用程序加密与更新生命周期结合起来。
监管与合规影响
合规团队通常不会仅凭“应用使用了加密”这句话就将其视为充分证据。他们会追问：覆盖了哪些数据？启用了哪些算法和协议？谁控制密钥？访问如何受限？组织又如何检测配置漂移？
欧盟 GDPR 条文体现了这一点：GDPR 第 32 条将加密视为降低风险的适当技术措施。该义务基于风险，因此组织仍需将防护措施与个人数据的性质及处理环境联系起来。处理医疗信息、身份数据或财务记录的移动应用，需要就本地存储、传输、访问和事件响应给出经得起推敲的说明。
HIPAA 安全规则将电子受保护健康信息的加密视为一项可寻址的保障措施，而不是通用的技术勾选项。这意味着受涵盖实体或业务伙伴应评估加密是否合理且适当，记录该决策，并在未实施该保障措施时采取替代措施。HHS 安全规则指南提供了相应的监管背景。
PCI DSS 将存储的持卡人数据与通过开放网络传输区分开来。团队应将加密决策对应到适用要求，并避免不必要地存储支付数据。PCI 安全标准委员会的文档库是核实当前措辞和范围的合适来源。
SOC 2 审计员关注的是控制措施是否实际运行的证据。这些证据可能包括密钥管理策略、TLS 配置、加密算法清单、访问日志、变更审批、事件记录、测试结果，以及已签名版本遵循既定流程的证明。缺乏监控的文档化控制措施可能无法证明其运行的有效性。
其中的共同点在于 可证明性。在实施 App 加密时就要建立证据链，而不是在审计前的一周才开始忙乱。
常见误区与加固最佳实践
大多数加密失效始于普通的工程决策。例如：开发者需要在启动时获取 token，团队希望离线搜索体验更流畅，或者发布流程需要一种快速分发 hotfix 的方式。当这些“捷径”变成了信任模型中永久的一部分时，风险便随之而来。
最近的一项移动端风险研究报告称， 超过 60% 的受测 App 在处理敏感数据时使用了不安全或过时的加密算法，而 约三分之一的 App 重用了初始化向量 (IV) 以及 20% 使用了硬编码的静态值. 这些发现将问题从“应用是否加密？”转向了“在实际使用中，该实现能否保证机密性和完整性？” (SC World 关于移动应用风险的报告)
| 常见误区 | 强化实践 |
|---|---|
| 在源码、字节码或 bundle 中硬编码 API 密钥或加密密钥 | 将高价值凭据保留在服务端，并使用受保护的平台存储来管理设备级素材 |
| 加密了 SQLite 数据库，却留下了明文缓存、导出文件、日志或备份 | 盘点敏感数据的每一份副本，并对临时产物应用相同的存储策略 |
| 将 refresh token 存储在普通的 web storage 中 | 使用平台级凭据存储，缩小 token 作用域，并支持服务端撤销 |
| 编写自定义加密算法或自创密钥混淆手段 | 使用经过验证的平台 API 和经身份验证的加密模式 |
| 通过禁用证书校验来解决连接问题 | 正确配置 TLS，并通过经过测试的恢复流程来评估 Pinning 方案 |
| 将代码混淆（Minification）误认为是一种密钥保护手段 | 从客户端 code 中移除密钥，仅使用混淆来提高逆向工程成本 |
| 忽略应用完整性检查和设备证明（Attestation）信号 | 在适当场景下验证发布身份，并利用信号来调整访问权限或触发审核 |
| 允许未经签名或受控较弱的更新 | 对发布产物进行签名，保护签名凭据，并监控更新结果 |
一份独立的威胁报告描述了间谍软件团伙如何通过伪造应用并利用底层手机，来针对 Signal 和 WhatsApp 账号进行攻击。该报告还引用了一项移动威胁评估，其中指出 2025 年上半年的 Android 智能手机攻击次数较 2024 年同期增长了 29% (The Register 对该 CISA 相关报告的报道). 这并不是说加密失败了。攻击者通常会选择设备、账户、会话或更新路径，因为这些层级可以绕过受保护的密文。
将每项加固实践转化为自动化发布规则。CI 可以拦截已知的密钥模式、标记自定义加密 code、验证签名步骤、检查 bundle 内容，并在存储或传输设置变更时要求安全审查。目标是在错误决策变成已发布的依赖项之前将其拦截。
在加密方案中整合所有要素
加密方案应像一份工程合同。它必须明确应用保护的内容、密钥存放位置、哪些组件可以查看明文，以及团队如何证明在每次发布后各项控制措施依然有效。
从这里开始 数据分类. 根据敏感度和保留需求，对记录、token、文档、logs、缓存、备份和 analytics 字段进行标记。在选择算法前，尽量减少本地副本。从未到达设备的数据无需设计设备存储方案。
然后记录存储和传输决策：
- 静态存储方案： 选择身份验证加密、平台管理的密钥存储、受保护的文件位置、备份行为，以及删除或数据擦除（zeroization）的处理方式。
- 传输协议： 定义 TLS 配置、证书验证、端点策略，以及根据威胁模型判断是否需要使用证书固定（pinning）。
- 密钥托管： 涵盖密钥的生成、访问、分发、轮换、撤销、恢复及紧急更换流程。
- Code 与运行时控制： 确定混淆、完整性检查、远程验证、调试器检测及敏感屏幕保护等措施的作用。
- 审计证据： 记录配置清单、访问日志、发布审批、测试结果、事件记录及异常情况。
顺序至关重要。数据分类决定了保护需求，进而决定了存储和密钥托管方式。传输与更新控制则负责维护受信任服务与客户端之间的路径。Capacitor 与 Electron 团队应针对不同目标平台重复此审查，因为 iOS 原生密钥库、Android 硬件级方案、浏览器存储 API 以及桌面端凭据设施提供的安全保障并不完全相同。
更新通道应包含在此方案之中，而非其后。签名发布可以维护 code 的完整性，而受控的目标发布、回滚保护及发布可观测性，则能帮助团队在存在漏洞的构建或配置触达用户时及时响应。每当 App 增加离线数据、更换存储 plugin、引入新的后端权限，或更改更新的签名与交付方式时，都应重新审查该方案。
Capgo 为 CapacitorJS 和 Electron 应用提供带签名的 Live Updates，支持对 JavaScript code 和资源使用加密 bundle，并提供受控发布渠道、回滚保护和按设备维度的更新可观测性。访问 Capgo 以评估受控更新路径如何支持你的应用加密与发布治理计划。
