Capacitor-updater prend désormais en charge le chiffrement de bout en bout code. La signature Code garantit que les mises à jour exécutées sur les appareils des utilisateurs finaux n'ont pas été altérées et offre un niveau de protection supplémentaire par rapport à la sécurité web standard de l'updater Capacitor.
La sécurité par défaut de Capacitor-updater
Par défaut, le modèle de sécurité de Capgo est similaire à celui des hébergeurs web. Capgo stocke les mises à jour chiffrées au repos et les sert via HTTPS en utilisant des algorithmes modernes. De même, la publication d’une mise à jour depuis l’ordinateur d’un développeur utilise toujours HTTPS.
La sécurité par défaut de Capgo obtient la note A+ au test HTTPS de SSL Labs (https://www.ssllabs.com, novembre 2022)
Comme les meilleurs hébergeurs web, Capgo utilise HTTPS pour protéger la confidentialité et l’intégrité des connexions réseau entre le serveur et les appareils des utilisateurs finaux. C’est un excellent niveau de sécurité qui fonctionne aussi bien pour le web que pour les applications Ionic utilisant Capgo.
La supply chain de l'infrastructure cloud
Un autre point commun entre Capgo et la plupart des hébergeurs web est qu’ils s’appuient sur une infrastructure cloud de bas niveau, souvent fournie par AWS, GCP ou un autre fournisseur cloud populaire. Le matériel et le logiciel exploités par ces fournisseurs cloud, 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 très grand nombre de sites web et d’applications. Chaque développeur web qui utilise un fournisseur cloud lui fait confiance et s’attend à ce que les fichiers qu’il envoie soient exécutés ou servis sans avoir été altérés. Et les fournisseurs cloud s’efforcent de maintenir leur infrastructure en sécurité.
Mais bien sûr, des vulnérabilités matérielles et logicielles sont découvertes. Les fournisseurs cloud corrigent les failles selon des calendriers réguliers et préviennent activement les logiciels malveillants (p. ex. SLSA de Google), et en construisant des couches de défense en profondeur, l'infrastructure cloud s'est avérée répondre aux besoins de sécurité de la plupart des sites et applications. Cependant, certaines applications Ionic incluent une infrastructure cloud compromise dans leurs modèles de menace. Pour ces applications JS Capacitor aux exigences de sécurité les plus élevées au-delà du web, nous avons intégré la signature code de bout en bout dans Capgo et le Protocole standard de Capgo Updates.
Signature code de bout en bout 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 tout le flux, du moment où un développeur publie une mise à jour jusqu'au moment où l'appareil de l'utilisateur final la reçoit et l'exécute. « La signature Code » consiste à utiliser la cryptographie et une clé privée secrète pour « signer » code, puis à utiliser une clé publique de confiance pour vérifier la signature.
Voici un schéma simple* pour expliquer le fonctionnement :
- Complexe en pratique, la cryptographie est difficile
Définition:
- AES : Advanced Encryption Standard, un algorithme de chiffrement symétrique, une seule clé pour le chiffrement et le déchiffrement.
- RSA : Rivest–Shamir–Adleman, un algorithme de chiffrement 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.
- Checksum : un hash calculé pour un fichier
- Signature : un checksum chiffré avec une clé RSA privée. Il peut être vérifié avec une clé RSA publique
Nous utilisons l'algorithme AES pour chiffrer la mise à jour. Une clé AES aléatoire est générée à chaque upload, puis la clé AES et le checksum (ci-après la « signature ») sont chiffrés avec la clé RSA privée du développeur. La clé RSA publique du développeur est utilisée dans l'app pour déchiffrer la clé AES et la signature (en la convertissant à nouveau en checksum). Ensuite, la clé AES déchiffrée sert à déchiffrer la mise à jour ; un checksum de la mise à jour déchiffrée est calculé, puis comparé à la signature déchiffrée.
Nous utilisons deux algorithmes de chiffrement distincts car RSA ne peut pas chiffrer de grandes quantités de données. AES chiffre la mise à jour, tandis que RSA chiffre la clé AES et le checksum.
Ainsi, même Capgo ne peut pas lire le contenu de votre bundle. C'est un modèle de sécurité robuste utilisé par de nombreux clients d'entreprise.
Chiffrement des mises à jour V2 2024-08-27 :
- Nous avons changé le type de clé stockée dans l'application. Cela a été fait pour empêcher de déduire 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). Désormais, l'application stocke la clé publique (maintenant utilisée pour le déchiffrement).
- Nous avons remplacé le checksum par l'algorithme SHA256 au lieu de CRC32. Nous avons également commencé à signer le bundle. Lorsque le chiffrement V2 est configuré, une mise à jour doit comporter une signature valide. Le plugin applique cette règle strictement.
- Nous imposons désormais une signature valide lorsque le chiffrement V2 est configuré. Ces 3 changements font suite à une analyse de sécurité menée par un membre de la communauté. Ils visent à prévenir les attaques cryptographiques lors des mises à jour.
Si vous utilisiez le chiffrement V1, migrez vers la V2 pour bénéficier des nouvelles fonctionnalités de sécurité. Suivez les instructions de migration.
Avec la signature code de bout en bout, Capgo devient une infrastructure cloud « trustless ». Si l'un des fournisseurs cloud de Capgo, ou même Capgo lui-même, venait à modifier une mise à jour signée par code, les appareils des utilisateurs finaux rejetteraient cette mise à jour et exécuteraient la version précédente de confiance déjà présente sur l'appareil.
Bien que le HTTPS au niveau web soit suffisant pour de nombreuses applications, certaines grandes entreprises apprécient le niveau de sécurité supplémentaire offert par la signature code de bout en bout. Certaines de ces entreprises développent des applications financières effectuant des transactions permanentes de haute valeur. D'autres ont des RSSI qui incluent l'infrastructure cloud compromise dans leurs modèles de menace. Nous avons intégré la signature code de bout en bout dans Capgo pour ces cas d'usage et souhaitons échanger avec les entreprises ayant des besoins de sécurité accrus.
Premiers pas pour les clients entreprise
Pour les grandes entreprises ou les projets très exigeants sur la sécurité, nous voulons rendre la signature code facile à configurer et à maintenir. À cette fin, nous proposons désormais les fonctionnalités suivantes :
- Mise en place et configuration rapides des certificats
- Prise en charge des serveurs de développement signés code avec Capgo et les builds de développement
- Signature code de production pour chaque mise à jour
La signature Capgo code est disponible pour tous les clients. Pour commencer, suivez les instructions d’installation.
Crédits
Un grand merci à Ionic, cet article s'appuie sur cet article réécrit avec chat-gpt-3 et adapté.
Pour aller plus loin : chiffrement E2E pour Capacitor Updater via la signature Code
Si vous utilisez Chiffrement E2E pour Capacitor Updater via la signature Code pour planifier la sécurité et la conformité, connectez-l’à Chiffrement pour les détails d'implémentation du chiffrement, Conformité pour les détails d'implémentation de la conformité, Scanner de sécurité Capgo pour le workflow produit dans Capgo Security Scanner, Capgo et la sécurité pour le workflow produit dans Capgo Security, et Capgo Centre de confiance pour le workflow produit dans Capgo Trust Center.
