Capacitor-更新器 现在支持端到端的code加密。Code签名确保更新在用户设备上运行时没有被篡改，并提供了额外的保护，高于Capacitor-更新器的标准网络级安全。
Capacitor-更新器的默认安全性
默认情况下，Capgo的安全模型与网络托管提供商类似。Capgo存储更新 以加密形式存储 并使用现代加密算法通过HTTPS服务。同样，开发者从计算机发布更新时始终使用HTTPS。
Capgo的默认安全性在SSL Labs的HTTPS测试中得分A+（https://www.ssllabs.com,2022年11月）
像网络托管提供商一样，Capgo使用HTTPS保护服务器与用户设备之间的网络连接的隐私和完整性。这是一种适用于网络和使用Capgo的Ionic应用的出色的安全级别。
云基础设施供应链
Another thing Capgo and most web hosts have in common is they run on lower-level cloud infrastructure, often from AWS, GCP, or another popular cloud provider. The hardware and software operated by these cloud providers and Capgo or other web hosts are part of the cloud supply chain.
云供应链及其安全模型适用于大量的网站和应用。每个使用云提供商的 web 开发人员都信任该提供商，并期望上传的文件是运行或服务的文件，而不会被篡改。云提供商也努力保持其基础设施的安全。
但是，显然，硬件和软件的漏洞会被发现。云提供商会按时修复漏洞，预防恶意软件（例如 Google 的 SLSA），并在实践中构建防御的多层次，云基础设施已经证明可以满足大多数网站和应用的安全需求。然而，一些 Ionic 应用程序将受损的云基础设施纳入其威胁模型。对于这些 __CAPGO_KEEP_0__ JS 应用程序，具有最高安全要求的 web 之上，我们在 __CAPGO_KEEP_2__ 和 __CAPGO_KEEP_1__ 上构建了端到端的 __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 和大多数 web 主机都共有的另一个东西是它们都运行在较低级别的云基础设施上，通常来自 AWS、GCP 或其他流行的云提供商。这些云提供商和 Capgo 或其他 web 主机运营的硬件和软件是云供应链的一部分。
Capgo’s end-to-end code signing uses public-key cryptography to ensure end users’ devices run only unmodified, original updates from the Capacitor app developer.
“从开发者发布更新到设备接收并运行更新的整个流程”都被这种安全性所覆盖。 “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 加密的 Capacitor 更新器通过 Code 签名继续。
如果您正在使用 E2E 加密的 Capacitor 更新器通过 Code 签名 来规划安全性和合规性，连接它与 加密 加密的实施细节在加密中 合规 合规的实施细节在合规中 Capgo 安全扫描器 在 Capgo 安全扫描器中产品工作流程 Capgo 安全 为产品工作流程中的 Capgo 安全, 和 Capgo 信任中心 为产品工作流程中的 Capgo 信任中心。
