Capacitor 升级器现在支持端到端加密。 __CAPGO_KEEP_1__ 签名确保用户设备上的更新未被篡改，并提供了额外的保护，高于 __CAPGO_KEEP_2__ 升级器的标准 web 安全性。 now supports end-to-end code encryption. Code signing makes sure the updates run by end users’ devices have not been tampered with and provides an extra level of protection above Capacitor-updater’s standard web-grade security.
Capacitor 的安全模型默认与 web 主机提供商类似。 __CAPGO_KEEP_1__ 存储更新
By default, Capgo’s security model is similar to that of web hosting providers. Capgo stores updates encrypted at rest and serves them over HTTPS using modern ciphers. Similarly, publishing an update from a developer’s computer always uses HTTPS.
Capgo 的默认安全设置在 SSL Labs 的 HTTPS 测试中得分 A+（https://www.ssllabs.com, November 2022)
像最好的网络主机一样，Capgo 使用 HTTPS 保护网络连接的隐私和完整性，保护服务器和终端用户设备之间的网络连接。这种安全级别适用于 web 和使用 Capgo 的 Ionic 应用程序。
云基础设施供应链
Capgo 和大多数网络主机都在使用较低级别的云基础设施，通常来自 AWS、GCP 或其他流行云提供商。这些云提供商和 Capgo 或其他网络主机所运营的硬件和软件是云供应链的一部分。
云供应链及其安全模型适用于大量网站和应用。每个使用云提供商的 web 开发人员都将信任该提供商，并期望上传的文件是运行或服务的文件，而不会被篡改。云提供商也在努力保持其基础设施的安全性。
显然，硬件和软件的漏洞会被发现。云提供商会按时修复漏洞，预防恶意软件（例如 Google 的 SLSA，并在实践中，云基础设施已经证明可以满足大多数网站和应用程序的安全需求。然而，一些Ionic应用程序将受损的云基础设施包含在其威胁模型中。对于这些Capacitor JS应用程序，其安全要求高于Web，我们构建了从头到尾的code签名，到Capgo和 Capgo更新标准协议.
从头到尾的code签名使用Capgo
Capgo的从头到尾的code签名使用公钥密码学来确保终端用户的设备只运行未修改的、原始的更新，从Capacitor应用程序开发者那里下载。
“从头到尾”意味着此安全性覆盖了从开发者发布更新到终端用户设备接收并运行更新的整个流程。“Code签名”是使用密码学和一个秘密的私钥来“签名”code，并且后来使用一个可信的公钥来验证签名。
以下是一个简单的*schema来解释它是如何工作的：
- 在实践中，密码学是复杂的
定义:
- AES：高级加密标准，一个对称加密算法，一个密钥用于加密和解密。
- RSA：里维斯特-沙米尔-阿德勒曼，一个非对称加密算法，两个密钥被使用：一个公钥和一个私钥。
- 密文：加密的数据。
- Session key: 使用 AES 算法对数据进行加密和解密的密钥。
- Checksum: 文件的哈希值。
- Signature: 使用开发者私钥加密的哈希值。它可以使用开发者公钥进行验证。
我们使用 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 签名对所有客户都可用。要开始，请遵循 设置指南.
贡献者
Keep going from E2E Encryption for Capacitor Updater via Code Signing
从 E2E 加密的 __CAPGO_KEEP_0__ 更新器通过 __CAPGO_KEEP_1__ 签名继续 E2E Encryption for Capacitor Updater via Code Signing 连接它以规划安全性和合规性 加密 加密的实现细节 合规 合规的实现细节 Capgo 安全扫描 在 Capgo 安全扫描中查看产品工作流程 Capgo 安全 在 Capgo 安全中查看产品工作流程 Capgo 信任中心 在 Capgo 信任中心中查看产品工作流程
