Passer au contenu principal
Solution

Chiffrement E2E pour le mises à jour de Capacitor via la signature de Code

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

Martin Donadieu

Martin Donadieu

Spécialiste du contenu

Chiffrement E2E pour le mises à jour de Capacitor via la signature de Code

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

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

Par défaut, le modèle de sécurité de Capgo est similaire à celui des fournisseurs de hébergement web. Capgo stocke les mises à jour stocké sous forme chiffrée 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's sécurité par défaut obtient une note A+ dans le 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 à la fois pour le 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 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 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 altérés. Et les fournisseurs cloud travaillent dur pour garder leur infrastructure sécurisée.

Mais évidemment, les vulnérabilités de matériel et de logiciel sont découvertes. Les fournisseurs cloud corrigent les vulnérabilités dans des horaires réguliers, préviennent proactivement le logiciel malveillant (par exemple Google's SLSAet 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 exigences de sécurité les plus élevées au-dessus du web, nous avons mis en place une signature code à bout portée dans Capgo et Capgo Protocole d'actualisation standard.

La signature code à bout portée avec Capgo

La signature Capgo à bout portée 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 depuis le 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 utilise ensuite une clé publique fiable pour vérifier l'empreinte numérique.

Voici un schéma simple* pour expliquer comment cela fonctionne :

Schéma de cryptage Capgo

  • Complexe en pratique, la cryptographie est difficile

Définition:

  • AES : Standard de cryptage avancé, un algorithme de cryptage symétrique, une clé pour la cryptage et la décryptage.
  • RSA : Rivest–Shamir–Adleman, un algorithme de cryptage 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 contrôle : Une somme calculée pour un fichier
  • Signature : Une somme calculée qui a été 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 (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). Plus tard, la clé AES déchiffrée est utilisée pour déchiffrer la mise à jour ; une somme de la mise à jour déchiffrée 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.

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.

Mise à jour de chiffrement 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 (maintenant utilisée pour le déchiffrement).
  • On a changé la somme de contrôle du algorithme CRC32 à l'algorithme 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 valide. L'encryption V2 est 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. Instructions de migration.

Avec la signature à bout de chaîne 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 page web est suffisant pour de nombreuses applications, certaines grandes entreprises trouvent l'extra niveau de sécurité de la signature à bout de chaîne code attractif. Certaines de ces entreprises créent des applications financières qui émettent des transactions de valeur élevée et permanente. D'autres entreprises ont des CISO qui incluent des infrastructures cloud compromis dans leurs modèles de menace. Nous avons intégré la signature à bout de chaîne 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 souhaitons rendre la signature code facile à configurer et à maintenir. À cette fin, nous fournissons désormais les fonctionnalités suivantes :

  • Configuration rapide de certificat et de configuration
  • Support de l'{code} de signature des serveurs de développement avec les deux {Capgo} et les builds de développement
  • La signature {code} en production sur chaque mise à jour

La signature {Capgo} {code} est disponible pour tous les clients. Pour commencer, suivez les instructions de configuration 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 {Capacitor} Mise à jour via la signature {Code}

Si vous utilisez E2E chiffrement pour le Capacitor Mise à jour via le Code Signage 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 le Capgo Scanner de sécurité, Capgo Sécurité pour le flux de travail du produit dans le Capgo Sécurité, et Capgo Centre de confiance pour le flux de travail du produit dans le Capgo Centre de confiance.

Mises à jour en temps réel pour les applications Capacitor

Quand un bug de la couche web est actif, expédiez la correction à travers Capgo au lieu 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 restent dans la voie de revue normale.

Un soutien humain de la part de Martin

Commencez maintenant

Dernières actualités de notre blog

Capgo vous donne les meilleures informations dont vous avez besoin pour créer une application mobile vraiment professionnelle.