Capacitor-更新器 现在支持code端到端加密。Code签名确保更新在用户设备上运行时没有被篡改，并提供了Capacitor-更新器标准的Web级安全性之上的额外保护。
Capacitor-更新器的默认安全性
默认情况下，Capgo的安全模型与Web托管提供商类似。Capgo存储更新 __CAPGO_KEEP_0__在存储时使用加密 __CAPGO_KEEP_0__使用现代加密算法通过HTTPS服务更新
Capgo在SSL Labs的HTTPS测试中得分A+__CAPGO_KEEP_0__的默认安全性在SSL Labs的HTTPS测试中得分A+（https://www.ssllabs.com，2022年11月）像最好的Web托管提供商一样，__CAPGO_KEEP_0__使用HTTPS保护服务器与用户设备之间的网络连接的隐私和完整性。这是Web和使用__CAPGO_KEEP_1__的Ionic应用程序都适用的一个很好的安全级别。
Like best-in-class web hosts, Capgo uses HTTPS to protect the privacy and integrity of network connections between the server and end users’ devices. This is an excellent level of security that works well both for the web and Ionic apps that use Capgo.
__CAPGO_KEEP_0__-更新器
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 和 __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__ 应用程序开发人员那里获得。.
End-to-end code signing with Capgo
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 签名”是使用加密和开发者的私钥来“签名” code，然后使用受信任的公钥来验证签名。
以下是一个简单的*schema来解释它是如何工作的:
- 在实践中，密码学是复杂的
定义:
- AES: 高级加密标准，一个对称加密算法，一个密钥用于加密和解密。
- RSA: Rivest–Shamir–Adleman，一个非对称加密算法，两个密钥被使用：一个公钥和一个私钥。
- 密文：加密的数据。
- 会话密钥：一个用于加密和解密数据的AES密钥。
- 校验和：一个文件的哈希值。
- 签名：一个校验和，使用开发者的私钥进行加密。它可以使用开发者的公钥进行验证。
我们使用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.
企业客户入门
对于那些深深关心安全的大公司或项目，我们希望让 code 签名变得容易设置和维护。为此，我们现在提供以下功能:
- 快速证书设置和配置
- 支持 code 签名开发服务器，包括 Capgo 和开发构建
- 每次更新都进行生产 code 签名
Capgo code 签名对所有客户都可用。要开始，请遵循 设置指南.
致谢
感谢 Ionic本文基于 本文 使用 Chat-GPT-3 重写并适应。
从 E2E 加密的 Capacitor 更新器通过 Code 签名继续
如果您正在使用 E2E 加密的 Capacitor 更新器通过 Code 签名 来规划安全性和合规性，连接它 加密 加密的实施细节 合规 合规的实施细节 Capgo 安全扫描器 Capgo 安全扫描器的产品工作流程 Capgo 安全性 为Capgo 安全性中的产品工作流程 Capgo 信任中心 为Capgo 信任中心中的产品工作流程
