Capacitor-mise à jour Maintenant prend en charge le chiffrement E2E du code. Le Code signe s'assure que les mises à jour exécutées par les appareils des utilisateurs finaux n'ont pas été modifiées et fournit un niveau supplémentaire de protection au-dessus de la sécurité web standard de la mise à jour Capacitor-
La sécurité par défaut de Capacitor-mise à jour
Par défaut, le modèle de sécurité de Capgo est similaire à celui des fournisseurs d'hébergement web. Le Capgo stocke les mises à jour stocké sous forme chiffrée et les sert sur HTTPS en utilisant des ciphers modernes. De même, la publication d'une mise à jour à partir d'un ordinateur d'un développeur utilise toujours HTTPS.
La sécurité par défaut de Capgo obtient une note A+ dans le test HTTPS de SSL Labs (https://www.ssllabs.com, novembre 2022)
Comme les meilleurs hébergeurs web, Capgo utilise HTTPS pour protéger la vie privée et l'intégrité des connexions réseau entre le serveur et les appareils des utilisateurs finals. C'est un niveau de sécurité excellent qui fonctionne bien pour les sites web et les applications Ionic qui utilisent Capgo.
La chaîne d'approvisionnement cloud
Une autre chose que Capgo et la plupart des hébergeurs web ont en commun, c'est qu'ils fonctionnent sur une infrastructure cloud de niveau inférieur, souvent fournie par AWS, GCP ou un autre fournisseur cloud populaire. Le matériel et le logiciel exploités par ces fournisseurs de cloud et Capgo ou d'autres hébergeurs web font partie de la chaîne d'approvisionnement cloud.
La chaîne d'approvisionnement cloud et son modèle de sécurité fonctionnent pour un nombre immense de sites web et d'applications. Chaque développeur web qui utilise un fournisseur de cloud met sa confiance en ce fournisseur et s'attend à ce que les fichiers qu'il télécharge soient les fichiers qui sont exécutés ou servis sans être modifiés. Et les fournisseurs de cloud travaillent dur pour garder leur infrastructure sécurisée.
Mais évidemment, les vulnérabilités du matériel et du logiciel sont découvertes. Les fournisseurs de cloud corrigent les vulnérabilités dans des horaires réguliers, préviennent activement le logiciel malveillant (par exemple, Google's SLSA), et construire des couches de défense en profondeur, et en pratique, l'infrastructure cloud a montré qu'elle répondait à la plupart des besoins de sécurité des sites web et des applications. Cependant, certaines applications Ionic incluent une infrastructure cloud compromise dans leurs modèles de menace. Pour ces applications JS Capacitor avec les plus hautes exigences de sécurité au-dessus du web, nous avons conçu une signature de bout en bout code pour se connecter à Capgo et le Capgo Protocole d'actualisation standard.
La signature de bout en bout code avec 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.
“De bout en bout” signifie que cette sécurité couvre le flux du moment où un développeur publie une mise à jour jusqu'au moment où un appareil de l'utilisateur final reçoit et exécute la mise à jour. “La signature de Code” est l'utilisation de la cryptographie et d'une clé privée secrète pour « signer » code, et plus tard, utiliser une clé publique fiable pour vérifier l'empreinte digitale.
Voici un schéma simple* pour expliquer comment cela fonctionne :
- Difficile en pratique, la cryptographie est complexe
Définition:
- AES : Standard d'Encryption Avancée, un algorithme d'encryption symétrique, une clé pour l'encryption et la décryption.
- RSA : Rivest–Shamir–Adleman, un algorithme d'encryption asymétrique, deux clés sont utilisées : une clé publique et une clé privée.
- Cypher : Les données chiffrées.
- Clé de session : Une clé AES utilisée pour chiffrer et déchiffrer les données.
- Coche de somme : Une somme calculée pour un fichier
- Signature : Une somme de coche qui a été chiffrée avec une clé privée RSA. Elle peut être vérifiée avec une clé publique RSA
Nous utilisons l'algorithme AES pour chiffrer la mise à jour. Une clé AES aléatoire est générée pour chaque téléchargement, puis la clé AES et la somme de coche (désormais « signature ») sont chiffrées avec la clé privée RSA du développeur. La clé publique RSA du développeur est utilisée dans l'application pour déchiffrer la clé AES et la signature (la convertissant à nouveau en somme de coche). Plus tard, la clé AES déchiffrée est utilisée pour déchiffrer la mise à jour ; une somme de coche du contenu déchiffré est calculée, et elle est comparée avec la signature déchiffrée.
Nous utilisons deux algorithmes de chiffrement différents car RSA ne peut pas être utilisé pour chiffrer de grandes quantités de données. AES est utilisé pour chiffrer la mise à jour et RSA est utilisé pour chiffrer la clé AES et la somme de coche.
Avec cela, même Capgo ne peut pas lire le contenu de votre bundle. C'est un modèle de sécurité robuste qui est utilisé par de nombreux clients entreprises.
Chiffrement de la mise à jour V2 2024-08-27 :
- Nous avons changé le type de clé stockée dans l'application. Cela a été fait pour empêcher l'inference de la clé publique (précédemment utilisée pour le chiffrement) à partir de la clé privée (précédemment utilisée pour le déchiffrement). Maintenant, l'application stocke la clé publique (maintenant utilisée pour le déchiffrement).
- Nous avons changé la somme de coche du algorithme CRC32 à l'algorithme SHA256. Nous avons également commencé à signer le bundle Nous avons également commencé à signer le bundle avec la nouvelle clé.When l'encryption V2 est configuré, une mise à jour doit avoir une signature valide. Cela est strictement appliqué par le plugin.
- Nous appliquons désormais une signature d'encryption V2 configuré. Ces 3 changements ont été effectués après une analyse de sécurité d'un membre de la communauté. Ils sont conçus pour prévenir les attaques cryptographiques lors de la mise à jour.
Si vous avez utilisé l'encryption V1, migrez vers V2 pour bénéficier des nouvelles fonctionnalités de sécurité. Suivez les instructions de migration. Avec une signature __CAPGO_KEEP_0__ à bout de chaîne, __CAPGO_KEEP_1__ devient une infrastructure cloud sans confiance. Si l'un des fournisseurs de cloud de __CAPGO_KEEP_2__ ou même __CAPGO_KEEP_3__ modifiait une mise à jour signée par __CAPGO_KEEP_4__, les appareils des utilisateurs finaux refuseraient cette mise à jour et exécuteraient la mise à jour précédente, déjà enregistrée sur l'appareil..
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.
Pour les grandes entreprises ou les projets qui s'intéressent profondément à la sécurité, nous souhaitons rendre la signature __CAPGO_KEEP_0__ facile à configurer et à maintenir. À cette fin, nous fournissons désormais les fonctionnalités suivantes :
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:
- __CAPGO_KEEP_1__ devient une infrastructure cloud sans confiance
- Support for code signing development servers with both Capgo and development builds
- La signature de code en production sur chaque mise à jour
La signature de Capgo et code est disponible pour tous les clients. Pour commencer, suivez les instructions de configuration Instructions de configuration.
Crédits
Nous remercions beaucoup Ionic, cet article repose sur cet article a été réécrit avec chat-gpt-3 et adapté.
Continuez avec la cryptage E2E pour l'Capacitor Updater via la signature de Code
Si vous utilisez Chiffrement E2E pour l'Capacitor Mise à jour via l'Code Signature pour planifier la sécurité et la conformité, connectez-le à Chiffrement pour le détail d'implémentation dans Chiffrement, Conformité pour le détail d'implémentation dans Conformité, Capgo Scanner de Sécurité pour le flux de travail du produit dans Capgo Scanner de Sécurité, Capgo Sécurité pour le flux de travail du produit dans Capgo Sécurité, et Capgo Centre de Confiance pour le flux de travail du produit dans Capgo Centre de Confiance.
