Capacitor-updater 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 升级器的默认安全性
By default, Capgo’s security model is similar to that of web hosting providers. Capgo stores updates __CAPGO_KEEP_0__采用了类似于web主机提供商的安全模型。__CAPGO_KEEP_1__负责更新存储 加密存储
Capgo在SSL Labs的HTTPS测试中得分A+__CAPGO_KEEP_0__的默认安全性在SSL Labs的HTTPS测试中得分A+（https://www.ssllabs.com
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.
像最好的web主机一样，__CAPGO_KEEP_0__使用HTTPS来保护网络连接的隐私和完整性，保护服务器和终端用户设备之间的网络连接。这种安全水平在web和Ionic应用中都很有效，使用__CAPGO_KEEP_1__。
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.
__CAPGO_KEEP_0__和大多数web主机都有一个共同点：它们都运行在云基础设施的底层，通常来自AWS、GCP或其他流行的云提供商。这些云提供商和__CAPGO_KEEP_1__或其他web主机所运营的硬件和软件是云供应链的一部分。
云供应链和其安全模型适用于大量的网站和应用。每个使用云提供商的web开发人员都信任该提供商，并期望上传的文件是运行或服务的文件，而不会被篡改。云提供商也在努力保持其基础设施的安全性。 Google的SLSA）和构建防御的多层次，实践中，云基础设施已经证明可以满足大多数网站和应用程序的安全需求。然而，一些Ionic应用程序将受损的云基础设施包含在其威胁模型中。对于这些Capacitor JS应用程序，具有最高安全要求的code和Capgo的安全需求，我们构建了端到端的Capacitor签名 Capgo Updates标准协议.
端到端的code签名使用Capgo
Capgo的端到端code签名使用公钥加密来确保终端用户的设备只运行未修改的、原始的更新，从Capacitor应用程序开发者那里获得。
“端到端”意味着此安全性覆盖从开发者发布更新到终端用户设备接收并运行更新的整个流程。“Code签名”是使用密码学和一个秘密的私钥来“签名”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 签名的更新，终端用户的设备将拒绝该更新并运行已经在设备上的可信的更新。
虽然 web 级别的 HTTPS 对于许多应用来说已经足够了，但一些大公司认为端到端 code 签名提供的额外安全层面很有吸引力。这些公司中的一些开发了发行高值、永久交易的财务应用。其他公司的 CISOs 将受损的云基础设施纳入了他们的威胁模型中。我们在 Capgo 中为这些用例构建了端到端 code 签名，并希望从更关注安全的公司那里听到更多的反馈。
企业客户入门
对于那些对安全非常关心的大公司或项目，我们希望使 code 签名的设置和维护变得容易。为此，我们现在提供以下功能：
- 快速证书设置和配置
- 支持使用code签名开发服务器，既支持Capgo又支持开发构建
- 每次更新都在生产环境中签名code
Capgocode签名功能对所有客户都可用。要开始使用，请遵循 设置指南.
