Capacitor-更新器 code-更新器现在支持端到端code加密。Code签名确保了用户设备上的更新未被篡改,并提供了额外的保护层,高于Capacitor-更新器的标准web级安全
Capacitor-更新器的默认安全
Capgo的安全模型默认与web托管提供商相同。Capgo存储的更新 __CAPGO_KEEP_0__-更新器 __CAPGO_KEEP_0__-更新器

Capgo-更新器__CAPGO_KEEP_0__-更新器,2022年11月)
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.
云基础设施供应链
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 JS应用,要求最高的安全性超过Web,我们在Capacitor和Capgo中实现了端到端的签名。 Capgo更新标准协议), 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 更新标准协议.
End-to-end code 加密签名与 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.
“End-to-end”意味着此安全性覆盖了从开发者发布更新到终端用户设备接收并运行更新的整个流程。 “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 以便益用新安全功能。 请遵循 迁移指南.
With end-to-end code signing, Capgo becomes a “trustless” cloud infrastructure. If one of Capgo’s cloud providers or even Capgo itself were to modify a code-signed update, end users’ devices would reject that update and run the previous, trusted update that’s already on the device.
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 签名
如果您正在使用 Capacitor 升级器使用 Code 数字签名实现端到端加密 以规划安全性和合规性,连接它 加密 为加密的实现细节 合规 为合规的实现细节 Capgo 安全扫描器 为Capgo 安全扫描器的产品工作流程 Capgo 安全 为Capgo 安全的产品工作流程, 和 Capgo 信任中心 为Capgo 信任中心的产品工作流程