跳过主要内容
解决方案

Capacitor 升级器的端到端加密,通过 Code 签名

使用 RSA + AES 加密更新,专为企业和高安全应用设计

Martin Donadieu

Martin Donadieu

内容营销

通过Code数字签名的Capacitor更新器实现端到端加密

Capacitor-updater code-updater现在支持端到端加密。Code数字签名确保用户设备上的更新未被篡改,并提供了Capacitor-updater的标准web级安全性之上的额外保护。

Capacitor-updater的默认安全性

默认情况下,Capgo的安全模型与web托管提供商类似。Capgo存储的更新 以加密形式存储 并使用现代加密算法通过HTTPS服务。同样,开发者从计算机发布更新时始终使用HTTPS。

Capgo在SSL Labs的HTTPS测试中得分A+

Capgo的默认安全性在SSL Labs的HTTPS测试中得分A+https://www.ssllabs.com2022年11月

像最好的网络主机一样,Capgo 使用 HTTPS 保护网络连接的隐私和完整性。这种安全级别在 web 和使用 Capgo 的 Ionic 应用程序中都很有效。

云基础设施供应链

Capgo 和大多数网络主机都有一个共同点:它们都运行在云基础设施的底层,通常来自 AWS、GCP 或其他流行的云提供商。这些云提供商和 Capgo 或其他网络主机运营的硬件和软件是云供应链的一部分。

云供应链及其安全模型适用于大量网站和应用。每个使用云提供商的 web 开发人员都信任该提供商,并期望上传的文件是运行或服务的文件,而没有被篡改。云提供商也努力保持其基础设施的安全性。

但是,显然,硬件和软件的漏洞会被发现。云提供商在预定时间内修复漏洞,预防恶意软件(例如 Google 的 SLSA),并在实践中构建了防御的多层次,云基础设施已经证明满足了大多数网站和应用的安全需求。然而,一些 Ionic 应用程序将受损的云基础设施纳入了其威胁模型。对于这些 __CAPGO_KEEP_0__ JS 应用程序,要求安全性高于 web 的,我们在 __CAPGO_KEEP_1__ 和 __CAPGO_KEEP_2__ 中构建了端到端的 __CAPGO_KEEP_0__ 签名。 __CAPGO_KEEP_0__), and build layers of defense in depth, and in practice, cloud infrastructure has shown to meet most websites and apps’ security needs. However, some Ionic apps include compromised cloud infrastructure in their threat models. For these Capacitor JS apps with the highest security requirements above the web, we built end-to-end code signing in to Capgo and the Capgo Updates标准协议.

End-to-end code签名使用Capgo

Capgo的End-to-end code签名使用公钥密码学来确保终端用户的设备只运行未修改的、原始的更新文件,从Capacitor应用开发者那里下载。

“End-to-end”表示此安全措施覆盖了从开发者发布更新到终端用户设备接收并运行更新的整个流程。“Code签名”是使用密码学和一个秘密的私钥来“签名”code,并且后来使用一个可信的公钥来验证签名。

以下是一个简单的*schema来解释它是如何工作的:

Capgo加密schema

  • 在实际应用中,密码学是复杂的

定义:

  • AES: 高级加密标准,一个对称加密算法,一个密钥用于加密和解密。
  • RSA: Rivest–Shamir–Adleman,一个非对称加密算法,两个密钥被使用:一个公钥和一个私钥。
  • 密文:加密的数据。
  • 会话密钥:一个AES密钥用于加密和解密数据。
  • 校验和:文件的哈希值
  • 签名:使用开发者私钥的RSA密钥加密的校验和。它可以使用开发者公钥进行验证

我们使用AES算法来加密更新。为每次上传生成一个随机AES密钥,然后使用开发者私钥加密AES密钥和校验和(后称“签名”)。开发者公钥在应用中用于解密AES密钥和签名(将其还原为校验和)。之后,解密的AES密钥用于解密更新;解密更新的校验和与解密的签名进行比较

我们使用两种不同的加密算法,因为RSA不能用于加密大量数据。AES用于加密更新,而RSA用于加密AES密钥和校验和

即使是Capgo也无法读取您的捆绑包内容。这是一个被许多企业客户使用的强大的安全模型

更新加密V2 2024-08-27:

  • 我们将存储在应用中的密钥类型切换了。这是为了防止从私钥(之前用于解密)推断出公钥(之前用于加密)。现在,应用存储的是用于解密的公钥
  • 我们将校验和从CRC32算法切换到了SHA256算法。我们还开始 签署捆绑包当配置了加密V2时,更新必须具有有效的签名。这是插件严格执行的
  • 我们现在强制实施了有效的签名加密 V2 已经配置。 这些 3 个更改是在社区成员进行安全分析之后完成的。它们旨在在更新期间防止加密攻击。

如果您使用了加密 V1,迁移到 V2 以利用新安全功能。按照 迁移指南.

通过端到端 code 签名,Capgo 成为一个“无信任”云基础设施。如果其中一个 Capgo 的云提供商或甚至 Capgo 自己修改了一个 code 签名的更新,终端用户的设备将拒绝该更新并运行之前的、已信任的更新,更新已经在设备上。

虽然 web 级别的 HTTPS 对于许多应用来说已经足够了,但一些大公司认为端到端 code 签名提供的额外安全层面很有吸引力。这些公司中的一些开发了发行高值、永久性交易的财务应用。其他公司的 CISOs 将受损的云基础设施纳入了他们的威胁模型中。我们在 Capgo 中为这些用例构建了端到端 code 签名,并希望从那些有更高级别安全需求的公司那里听到更多的反馈。

企业客户入门

对于那些对安全非常关心的大公司或项目,我们希望使 code 签名的设置和维护变得容易。为此,我们现在提供以下功能:

  • 快速证书设置和配置
  • 支持 code 签名的开发服务器,包括 Capgo 和开发构建
  • 生产 code 签名在每次更新中

Capgo code 签名功能对所有客户都可用。要开始使用,请遵循 安装指南.

版权信息

感谢 Ionic, 本文基于 本文 使用 chat-gpt-3 重写并适配。

从 E2E 加密的 Capacitor 更新器通过 Code 签名继续

如果您正在使用 E2E 加密的 Capacitor 更新器通过 Code 签名 来规划安全性和合规性,请将其与 加密 为加密的实现细节 合规 为合规的实现细节 Capgo 安全扫描器 为Capgo 安全扫描器的产品工作流程 Capgo 安全 为Capgo 安全的产品工作流程, 和 Capgo 信任中心 为Capgo 信任中心的产品工作流程

Capacitor应用的实时更新

当web层bug出现时,通过Capgo将修复直接推送给用户,而不是等待几天的app store审批。用户在后台接收更新,而原生代码的更改仍然在正常的审批路径中。

立即开始

最新博客文章

Capgo 为您提供创建真正专业的移动应用所需的最佳见解。