Capacitor-更新器 现在支持端到端的code加密。Code签名确保更新在用户设备上运行时没有被篡改，并提供了Capacitor-更新器的标准web级安全性之上的额外保护层。
Capacitor-更新器的默认安全性
默认情况下，Capgo的安全模型与web托管提供商类似。Capgo存储更新 以加密形式存储 并使用现代加密算法通过HTTPS服务它们。同样，开发者从计算机发布更新时始终使用HTTPS。
Capgo的默认安全性在SSL Labs的HTTPS测试中得分A+（https://www.ssllabs.com，2022年11月）
像最好的web托管提供商一样，Capgo使用HTTPS保护服务器与用户设备之间的网络连接的隐私和完整性。这是一个适用于web和使用Capgo的Ionic应用的极好的安全级别。
供应链的云基础设施
另一个东西 Capgo 和大多数 web 主机都有共同之处是它们运行在较低级别的云基础设施上，通常来自 AWS、GCP 或其他流行的云提供商。这些云提供商和 Capgo 或其他 web 主机运营的硬件和软件是云供应链的一部分。
云供应链及其安全模型适用于大量的网站和应用。每个使用云提供商的 web 开发人员都信任该提供商，并期望上传的文件是运行或服务的文件，而不会被篡改。云提供商努力确保其基础设施的安全。
但是，显然，硬件和软件漏洞会被发现。云提供商在合理的时间内修复漏洞，预防恶意软件（例如 Google 的 SLSA），并构建防御在深度的层次，实际上，云基础设施已经证明满足了大多数网站和应用的安全需求。然而，一些 Ionic 应用程序将受损的云基础设施纳入其威胁模型中。对于这些 __CAPGO_KEEP_0__ JS 应用程序，具有最高安全要求的 web 之上，我们构建了从 __CAPGO_KEEP_2__ 到 __CAPGO_KEEP_1__ 的端到端签名。 __CAPGO_KEEP_0__ Updates 标准协议), 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 的端到端 __CAPGO_KEEP_1__ 签名使用公钥密码学来确保终端用户的设备只运行未修改的、原始的更新文件，从 __CAPGO_KEEP_2__ 应用程序开发人员那里下载。.
code 和 Capgo 是保留的关键词，__CAPGO_KEEP_2__ 是 Cloudflare
Capgo 和 code 是保留的关键词，Capacitor 是 GitHub
“从开发者发布更新到设备接收并运行更新的整个流程”都被这种安全性所覆盖。 “Code signing”是使用加密和开发者的私钥来“签名”code，并且后来使用一个可信的公钥来验证签名。”
这里是一个简单的*schema来解释它是如何工作的：
- 在实践中，密码学是复杂的
定义:
- AES: 高级加密标准，一个对称加密算法，一个密钥用于加密和解密。
- RSA: Rivest–Shamir–Adleman，一个非对称加密算法，两个密钥被使用：一个公钥和一个私钥。
- Cypher: 加密的数据。
- 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签名的更新，设备用户将拒绝该更新并运行之前的、信任的更新。
While web-level HTTPS is sufficient for many apps, some large companies find the extra level of security from end-to-end code signing appealing. Some of these companies make finance apps that issue high-value, permanent transactions. Other companies have CISOs who include compromised cloud infrastructure in their threat models. We built end-to-end code signing in to Capgo for these use cases and are interested in hearing more from companies with higher-level security needs.
企业客户入门
For large companies or projects who care deeply about security, we want to make code signing easy to set up and maintain. To that end, we now provide the following features:
- 快速证书设置和配置
- 支持code signing开发服务器，包括Capgo和开发版本
- 每次更新都进行code signing
Capgo code signing适用于所有客户。要开始使用，请遵循 设置指南.
致谢
感谢 Ionic, 本文基于 本文 使用Chat-GPT-3重写并适配。
从E2E Encryption for Capacitor Updater via Code Signing
如果您正在使用 E2E Encryption for Capacitor Updater via Code Signing 来规划安全性和合规性，连接它与 加密 加密的实施细节在加密中 合规 合规的实施细节在合规中 Capgo 安全扫描器 Capgo 安全扫描器的产品工作流程, Capgo 安全 为产品工作流程在 Capgo 安全中 Capgo 信任中心 为产品工作流程在 Capgo 信任中心中
