了解如何在移动端和 Electron 应用中实现应用加密，包括静止和传输保护、密钥管理、合规性和常见问题。

A healthcare startup can spend months designing a secure mobile workflow, then discover that a jailbroken tester’s phone exposed patient records through screenshots and local caches. At the same time, a debug build of the team’s Electron administration panel might ship with an API key embedded in its bundle. Both incidents involve encryption, but neither is solved by adding one encryption library.

移动端 团队必须决定数据在存储时如何被保护，数据如何在系统之间移动，密钥存放的位置，攻击者从应用程序包中可以学习到的内容，运行时对篡改的响应，以及签名更新如何保留这些保证。一个有用的起点是将敏感数据、信任边界、客户端能力和可能的滥用路径映射到一个应用程序风险评估中。 应用程序风险评估 移动和跨平台应用程序面临着异常暴露的环境。设备离开办公室，构建可以被复制或侧载，局部文件可能被检查，逆向工程工具广泛可用。以下各节逐步构建模型，从存储和传输到平台密钥保护、客户端机密性、合规性和发布操作。

目录

为什么应用程序加密比以往更为重要

• 数据在存储时的加密与在传输时的加密
• 数据在存储时的加密
  • 数据在传输时的加密
  • 保护__CAPGO_KEEP_0__、数据和应用程序机密
• iOS、Android、Code和Electron的平台考虑
• Platform Considerations for iOS, Android, Capacitor, and Electron
  • __CAPGO_KEEP_0__
  • 跨平台壳
• 密钥管理和客户端保密性的局限性
• 法规和合规性影响
• 常见陷阱和加固的最佳实践
• 将所有内容整合到您的加密计划中

为什么应用加密比以往任何时候都更重要

一个Web应用通常将敏感逻辑和机密材料保存在组织控制的基础设施上。一个移动应用将code、资产、配置和数据处理逻辑发送到属于他人的设备上。一个Electron应用有一个类似的问题，因为它的JavaScript、资源和打包文件可以被运行该应用的用户检查。

这改变了安全边界。 客户端很有用，但它不是一个保险箱。 加密可以保护信息免受随意检查，并使被盗的文件更不值钱，但应用仍然需要访问某个时刻的明文。控制设备的攻击者可以观察输入、检查内存、.instrument API 或修改执行。

考虑医疗保健的例子。加密数据库可能会保护从磁盘复制的记录，但它不会阻止被破坏的运行时显示解密的记录给恶意进程。加密网络流量可能会保护临床人员的请求在它旅行到后端时，但它不会保护本地导出后应用将其保存在未受保护的缓存中。隐藏在混淆的JavaScript中的密钥仍然可以恢复，如果应用必须使用它。

实践规则： 每个客户端保护都应被视为减少暴露的层，而不是证明设备可信赖的证据。

一个完整的设计通常结合了以下几点：

• 静态保护，适用于数据库、文件、缓存、偏好设置和下载的文档。
• 传输保护，适用于请求、同步、更新传递和服务间通信。
• 平台密钥存储，以便加密密钥不被留在普通应用程序文件中。
• Code 和运行时保护，包括混淆、完整性检查、反调试措施和适当的证书验证。
• 受控的更新通道，因为签名的发布必须保留在早期版本中构建的安全假设。
• Documented compliance controls, including ownership, evidence, monitoring, and response procedures.

Regulatory obligations add pressure, but they also improve engineering discipline. GDPR, HIPAA, PCI DSS, and SOC 2 don’t turn encryption into a universal checkbox. They require teams to understand what they protect, how keys are controlled, and how they can demonstrate that safeguards operate as intended.

Encryption at Rest Versus in Transit

Think of a confidential document sent by registered mail. The sealed envelope protects the message while it travels between people. Once the recipient opens it, the document still needs a locked filing cabinet. Encryption in transit protects movement. Encryption at rest protects storage. The envelope and the cabinet solve different problems.

At-rest encryption

At-rest encryption applies when data sits on a device, server disk, backup, database, or removable volume. On mobile platforms, operating-system protections may encrypt parts of the device automatically, but your application still needs to choose safe storage locations, access controls, and key usage. Sensitive application files should use platform-supported cryptography and keys held in protected stores rather than a key written beside the encrypted data.

Authenticated encryption matters here. OWASP recommends platform cryptographic APIs, hardware-backed key storage where available, and authenticated modes such as 加密在设备上存储的数据（At-rest encryption）是指数据存储在设备、服务器磁盘、备份、数据库或可移动存储器上时的加密。移动平台上，操作系统可能会自动加密设备的一部分，但您的应用程序仍需要选择安全的存储位置、访问控制和密钥使用。敏感应用程序文件应使用支持的加密和密钥存储在受保护的存储器中，而不是将密钥写在加密数据旁边。，帮助检测篡改以及隐藏内容。同样的指南建议保护敏感数据在静止和传输时，放在内部存储中，并避免使用专有加密算法而是使用平台实现（OWASP移动应用安全速查表).

实践细节会根据平台不同而有所不同。iOS提供数据保护和钥匙串服务。Android提供基于Keystore的选项和可以帮助管理加密文件的库。桌面应用程序依赖于操作系统凭证和本地访问控制。使用Chromium嵌入式框架环境的团队也可以查看 最佳实践 用于CEF文档存储

来检查加密器之外的存储边界

传输加密保护请求和响应在网络中传输。配置好的TLS连接可以防止中间人读取或修改应用程序流量，但TLS只有在客户端正确验证服务器并后端呈现可信证书时才有效。禁用证书检查、不安全的回退或意外的明文端点都可以破坏预期的保护

证书固定可以在特定移动场景中添加另一个验证层，尤其是在团队控制证书操作并且有一个恢复计划的旋转时。它并不是正确的TLS的替代品，错误的固定值可以阻止合法用户。使用Capacitor构建的团队可以检查 固定SSL的Capacitor应用 在选择是否适合应用程序的运营折衷之前

失败模式是互补的。传输安全不会保护从丢失设备复制的数据库。存储加密不会保护通过被破坏的连接提交的密码。设计两条路径，然后测试明文出现的点，包括日志，截图，临时文件，崩溃报告，剪贴板内容和同步队列。

保护Code，数据和机密在应用程序中

团队经常使用“加密”、“混淆”和“加固”这三个词，好像它们描述的是同一个控制。它们并不是。每个控制都解决了不同的攻击者行为，混淆它们会造成错误的自信。

混淆和压缩 使code更难读。它们可以提高克隆应用程序或理解业务逻辑的成本，但它们并不会使一个秘密不可用给一个必须使用它的应用程序。API密钥在JavaScript包中，签名凭证在存档中，或者由可预测函数重构的值仍然可以被提取。Hermes字节码和Electron asar 档案可能不如源文件那样方便检查，但打包并不是同样的保密性。

数据加密 保护用户内容和本地凭据在存储时。它应该使用平台加密API和Keychain、Keystore、Secure Enclave、StrongBox或可用的操作系统等效设施中的密钥。OWASP的加密测试指南警告不要将密码或密钥放在源code中，并强调在客户端保留的秘密可以被提取（OWASP MASTG加密测试).

运行时保护 寻找提高窃取或自动滥用的可能性。Jailbreak和root信号、调试器检测、应用程序完整性检查、证明和证书验证可以使攻击更加困难或提供响应信号。没有一种方法可以使设备可信赖。一个决心的攻击者可以修改检查，而一个合法用户可能会触发一个启发式。

更安全的设计将高价值秘密保留在服务器上，给客户端提供有限的凭证，并只对需要离线访问的本地数据进行加密。token存储值得单独评估其过期、注销、刷新行为以及平台绑定。该 适用于移动开发者的安全token存储指南 在将这些决策转化为实现要求时有用。

天真方法失败，因为它们保护了机密性外观而不是机密的生命周期。将值用XOR在源code中混合、将密钥分散在几个文件中，或者依赖JavaScript压缩并不能改变事实：运行应用程序必须重建并使用值。

iOS、Android、Capacitor和Electron的平台考虑

相同的加密设计在不同运行时下表现不同，因为每个平台暴露不同的密钥存储、API、隔离边界和恢复机制。跨平台抽象可以简化应用code，但无法消除这些差异。

原生移动平台

在 iOS 上，Keychain 提供了保护凭证存储，而 Secure Enclave 可以将某些密钥操作隔离在主应用处理器之外。应用程序仍然需要选择与其可用性要求相匹配的访问控制，例如数据是否应在设备认证后可用，还是仅在用户已认证时可用。

Android Keystore 提供了支持设备上的硬件背后的路径，而 StrongBox 可以提供一个更强的隔离环境。Android 团队还应考虑设备能力、备份行为、认证要求和证明信号。硬件支持并不均匀，因此应用程序需要定义一个fallback策略，而不是假设每个设备都提供相同的保护。

跨平台壳

Capacitor 应用程序结合了 web code 与原生平台功能通过一个桥梁。这个桥梁是一个安全边界，而不是一个方便层。 localStorage, IndexedDB 和普通的 web 首选项不应默认被视为加密的机密存储。团队必须显式选择一个原生存储插件或实现一个原生模块，它使用平台的保护密钥设施。

Electron 有一个不同的威胁模型。其渲染器处理 web 内容，而主进程拥有更广泛的权限，因此敏感操作应避免在暴露的渲染器中。Electron 的 safeStorage 可以使用操作系统的凭据保护，但最终的安全性取决于宿主操作系统、用户账户、桌面配置和进程隔离。该密钥不会像移动平台那样自动将密钥隔离在硬件中。

团队应该根据目标平台来记录行为，而不是将产品描述为“所有平台都加密”。 Capacitor 帮助将桥接作为一个需要保持平台特定决策可见的地方

客户端密钥管理的局限性

加密保护数据的唯一方法是保护密钥。一个有用的生命周期有五个阶段: 生成、分发、存储、轮换和撤销每个阶段都有不同的故障模式。

使用可信的平台或服务器加密API生成密钥。通过认证的协议分发它们，而不是将它们嵌入到捆绑包中。将它们存储在保护的平台设施中，可能的话。轮换它们当政策、风险或加密要求需要时。通过服务器控制的授权撤销访问，当设备、帐户或会话不再应该解密数据时。

客户端比基础设施弱，因为用户控制设备并且可以潜在地检查应用程序状态。客户端保留的密钥在离线数据上保护由用户派生的口令时可能有意义，假设产品接受恢复和可用性后果。然而，对于一个API令牌，它使得广泛的后端访问的意义远远小于加密一个本地数据库。

数据加密分离了数据加密密钥和主密钥。应用程序可以使用一个短期的数据密钥来加密一个本地对象，而一个服务器端的密钥管理服务或HSM背后的系统保护了包装密钥。一个远程密钥释放设计可以要求一个经过身份验证的设备、用户、策略决策或证明信号在释放解密所需的材料之前。这些模式并不能使一个被破坏的客户端安全，但它们减少了设备上永久性权力的多少。

OWASP 将本地敏感数据识别为包括个人可识别信息、加密材料、机密和API密钥。它还将加密与生命周期控制联系起来，如安全的本地存储、密钥轮换和使用后零化。这个架构原则很简单：

保持高价值机密在团队控制的系统上。只给客户端提供当前任务所需的最少权力。

对于发布系统，密钥管理也适用于更新签名和交付。团队应该定义谁可以签署一个捆绑包、签名凭证存放在哪里、访问是如何审计的以及一个被破坏的签名凭证是如何替换的。关于 如何使用密钥管理来保护OTA更新 可以帮助将应用程序加密与更新生命周期联系起来。

合规和监管影响

[

GDPR Article 32 treats encryption as an appropriate technical measure for reducing risk, as reflected in the European Union’s GDPR text. The obligation is risk-based, so the organization still needs to connect its safeguards to the nature of the personal data and processing environment. A mobile app that handles medical information, identity data, or financial records needs a defensible explanation of local storage, transport, access, and incident response.

HIPAA’s Security Rule treats encryption for electronic protected health information as an addressable safeguard rather than a universal technical checkbox. That means a covered entity or business associate should assess whether encryption is reasonable and appropriate, document the decision, and apply alternative measures where it doesn’t implement the safeguard. The HHS Security Rule guidance provides the governing context.

GDPR第32条将加密视为减少风险的适当技术措施，反映在欧盟的GDPR文本中。义务是基于风险的，因此组织仍需要将其保障措施与个人数据和处理环境的性质联系起来。处理医疗信息、身份数据或财务记录的移动应用程序需要对本地存储、传输、访问和事件响应进行可辩护的说明。

SOC 2 审核人员关注的是控制是否正常运作的证据。 这些证据可能包括密钥管理政策、TLS 配置、加密算法库、访问日志、变更审批、事件记录、测试结果以及已签名的发布遵循的过程的证据。 一个没有监控的文档控制可能无法证明有效运作。

共同的线索是 可证明性. 在实施应用加密时，建立证据链，而不是在审计前一周。

常见陷阱和加固最佳实践

大多数加密失败都是普通工程决策的结果。 开发者需要在启动时可用一个令牌，团队希望离线搜索感觉快，或者发布过程需要快速分发一个热修复。 风险出现在捷径成为信任模型的永久部分时。

最近的移动风险研究报告指出 超过60%的评估应用程序使用了不安全或过时的加密算法来保护敏感数据而 大约三分之一的应用程序重新使用了初始化向量 并且 20% 使用了固定的静态值那些发现使问题从“应用是否加密？”转变为“实现是否能在实际使用中保留机密性和完整性？”移动应用风险的SC World报告)

一份独立的威胁报告描述了间谍软件团队针对Signal和WhatsApp账户的攻击，通过冒充应用程序并滥用手机底层 同一份报告指出，2025年上半年与2024年上半年相比，安卓智能手机攻击增加了29% (《The Register》对CISA相关报告的报道. 加密失败的教训并不是攻击者选择了设备、账户、会话或更新路径，因为这些层次可以绕过保护的密文。

将每个加固的实践转化为自动化的发布规则。CI可以拒绝已知的秘密模式、标记自定义加密code、验证签名步骤、检查包内容、要求安全审查当存储或传输设置发生变化时。目标是在依赖项被发布之前捕获坏的决定。

将所有内容整合到您的加密计划中

加密计划应该像工程合同一样读。它必须说明应用程序保护什么、密钥存放在哪里、哪些组件可以看到明文、以及团队如何证明控制措施在每次发布后仍然有效。

从以下开始 数据分类. 根据敏感性和保留需求对记录、令牌、文档、日志、缓存、备份和分析字段进行标记。尽量减少本地副本之前选择算法。数据从未到达设备就不需要设备存储设计。

然后记录存储和传输决策:

1. 休眠方案: . 选择认证加密、平台管理的密钥存储、保护文件位置、备份行为和删除或零化处理。
2. 传输方案: . 定义TLS配置、证书验证、端点策略和是否适合威胁模型的固定策略。
3. 密钥保管: 记录生成、访问、分发、轮换、撤销、恢复和紧急替换程序。
4. Code 和运行时控制: 决定混淆、完整性检查、证明、调试器检测和敏感屏幕保护的贡献。
5. 审计证据: 捕获配置清单、访问日志、发布批准、测试结果、事件记录和异常。

顺序很重要。数据分类决定需要保护什么。这个决定会影响存储和密钥保管。运输和更新控制然后会保留信任服务和客户端之间的路径。Capacitor 和 Electron 团队应该在每个目标上重复审查，因为一个本地 iOS 密钥存储、一个 Android 硬件背后的选项、一个浏览器存储 API 和一个桌面凭据设施不会提供相同的保证。

更新频道应该在这个计划中，而不是在之后。一个签名的发布可以保留 code 完整性，而控制的目标、回滚保护和发布可观察性可以帮助团队响应当一个脆弱的构建或配置到达用户时。每当应用程序添加离线数据、更改其存储插件、引入一个新的后端权限或改变如何签名和分发更新时，都应该审查计划。

Capgo 为 CapacitorJS 和 Electron 应用程序提供了签名的实时更新，支持 JavaScript code 和资产的加密捆绑包，控制发布渠道，回滚保护以及针对设备的更新可观察性。访问 Capgo 到评估如何控制的更新路径支持您的应用程序加密和发布管控计划。