Allez directement au contenu principal
Solution

Chiffrement E2E pour l'Capacitor Updater via la signature Code

En utilisant la cryptographie RSA + AES pour chiffrer les mises à jour, conçues pour les entreprises et les applications de sécurité élevée

Crédits de l'article

Martin Donadieu

Écrivain

Valeria

Réviseur

Jordan

Éditeur

Chiffrement E2E pour le Capacitor Updater via la signature Code

Capacitor-mises à jour Les mises à jour de code-updater disposent désormais d'un chiffrement E2E. La signature de Code garantit que les mises à jour exécutées par les appareils des utilisateurs finaux n'ont pas été modifiées et offrent un niveau de protection supplémentaire au-delà de la sécurité web standard du mises à jour de Capacitor-updater.

La sécurité par défaut du mises à jour de Capacitor

Par défaut, le modèle de sécurité de Capgo est similaire à celui des fournisseurs d'hébergement web. Capgo stocke les mises à jour chiffré en permanence et les sert sur HTTPS à l'aide de césars modernes. De même, la publication d'une mise à jour à partir d'un ordinateur d'un développeur utilise toujours HTTPS.

Capgo obtient une note A+ dans le test HTTPS de SSL Labs

Capgo obtient par défaut une note A+ lors du test HTTPS de SSL Labs (https://www.ssllabs.com, novembre 2022

Comme les meilleurs hôtes 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ôtes 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ôtes 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 démontré répondre à 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 mis en place une signature code à bout portée dans Capgo et Capgo Mise à jour protocole standard.

La signature code à bout portée avec Capgo

La signature Capgo de code utilise la cryptographie à clés publiques pour s'assurer que les appareils des utilisateurs finaux exécutent uniquement des mises à jour non modifiées, originales du développeur de l'application Capacitor.

“À bout portée” 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 Code” utilise la cryptographie et une clé privée secrète pour « signer » code, et plus tard utiliser une clé publique fiable pour vérifier la signature.

Ici est un schéma simple* pour expliquer comment ça marche:

Capgo schéma de chiffrement

  • Complexe en pratique, la cryptographie est difficile

Définition:

  • AES : Standard d'encryption avancé, un algorithme d'encryption symétrique, une seule clé pour l'encryption et la décryption.
  • RSA : Rivest–Shamir–Adleman, un algorithme de chiffrement asymétrique, deux clés sont utilisées : une clé publique et une clé privée.
  • Chiffre : 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 contrôle chiffrée avec une clé privée RSA. Elle peut être vérifiée avec une clé publique RSA

On utilise 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 contrôle (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 contrôle). Plus tard, la clé AES déchiffrée est utilisée pour déchiffrer la mise à jour ; une somme de contrôle du contenu déchiffré est calculée, et elle est comparée avec la signature déchiffrée.

On utilise 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 contrôle.

Avec cela, 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 entreprises.

Mise à jour de l'encryption V2 2024-08-27:

  • On a changé le type de clé stockée dans l'application. Cela a été fait pour empêcher l'inference de la clé publique (utilisée précédemment pour le chiffrement) à partir de la clé privée (utilisée précédemment pour le déchiffrement). Maintenant, l'application stocke la clé publique (utilisée maintenant pour le déchiffrement).
  • On a changé la somme de contrôle du CRC32 en SHA256. On a également commencé à signer le bundleQuand 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 pendant 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 la signature à bout de bout code, Capgo devient une infrastructure cloud « sans confiance ». Si l'un des fournisseurs de cloud de Capgo ou même Capgo modifiait une mise à jour signée par code, les appareils des utilisateurs finaux refuseraient cette mise à jour et exécuteraient la mise à jour précédente, déjà installée sur l'appareil et considérée comme fiable.

Même si HTTPS au niveau de la toile est suffisant pour de nombreuses applications, certaines grandes entreprises trouvent l'extra niveau de sécurité de la signature à bout de bout code séduisant. Certaines de ces entreprises créent des applications financières qui émettent des transactions de grande valeur permanentes. D'autres entreprises ont des CISO qui incluent des infrastructures de cloud compromis dans leurs modèles de menace. Nous avons intégré la signature à bout de bout code dans Capgo pour répondre à ces besoins et sommes intéressés par les commentaires de sociétés avec des besoins de sécurité plus élevés.

Demarrage pour les clients entreprises

Pour les grandes entreprises ou les projets qui s'intéressent profondément à la sécurité, nous voulons rendre la signature code facile à configurer et à maintenir. À cette fin, nous fournissons désormais les fonctionnalités suivantes :

  • Configuration et configuration rapide de certificats
  • Support pour la signature de serveurs de développement code avec les deux versions Capgo et de développement.
  • La signature de code en production sur chaque mise à jour

Capgo code signing is available for all customers. To get started, follow the Instructions de configuration.

Crédits

Nous remercions beaucoup Ionicce billet est basé sur ce billet réécrit avec chat-gpt-3 et adapté.

Continuez de l'encryption E2E pour le Capacitor Updater via la signature Code

Si vous utilisez E2E chiffrement pour Capacitor Mise à jour via Code Signature pour planifier la sécurité et la conformité, connectez-l’avec Chiffrement pour le détail d'implémentation en Chiffrement, Conformité pour le détail d'implémentation en 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.

Mises à jour instantanées pour les applications Capacitor

Lorsqu'un bug de la couche web est actif, expédiez la correction à travers Capgo plutôt que d'attendre des jours pour l'approbation de la boutique d'applications. Les utilisateurs reçoivent la mise à jour en arrière-plan tandis que les modifications natives suivent la voie de revue normale.

Dernières actualités

Capgo gives you the best insights you need to create a truly professional mobile app.