La cryptage

Capgo fournit une encryption robuste de bout en bout pour vos lots d'applications, garantissant que votre JavaScript code et vos actifs sont protégés pendant la transmission et la stockage. Ce système d'encryption est conçu pour vous donner un contrôle total sur la sécurité de votre application tout en maintenant la commodité des mises à jour en temps réel.

Vue d'ensemble

Le système d'encryption de Capgo utilise des méthodes cryptographiques industrielles pour protéger vos lots de toute accès non autorisé. Lorsque l'encryption est activé, vos lots sont chiffrés avant de quitter votre environnement de développement et restent chiffrés jusqu'à ce qu'ils soient déchiffrés par votre application sur le dispositif de l'utilisateur.

Ce que l'encryption protège réellement: À la différence des systèmes OTA qui ne signent que les mises à jour, Capgo chiffre le lot téléchargé avant stockage et livraison. Cela protège les contenus du lot contre l'accès non autorisé en stockage ou en transit et garantit que seuls ceux qui disposent de votre clé privée peuvent produire une mise à jour chiffrée valide. Cela ne fait pas les actifs web embarqués impossibles à décompiler : la clé publique utilisée par le client pour déchiffrer les mises à jour est distribuée dans l'application, donc un attaquant déterminé peut toujours l'extraire et inspecter les contenus du lot avec suffisamment d'effort.

Quand vous avez besoin d'encryption

Si vous téléchargez un bundle sans encryption, traitez-le comme un actif public. Les canaux privés limitent les appareils qui reçoivent une mise à jour, mais ils ne rendent pas le bundle téléchargé confidentiel. L'encryption est utile lorsque vous souhaitez une meilleure protection en stockage et en transit et lorsque vous souhaitez que seuls les détenteurs de la clé privée puissent publier des mises à jour chiffrées valides. Il ne garantit pas que le JavaScript, l'HTML ou le CSS expédiés ne peuvent jamais être inspectés.

Modèle de menace

Capgo encryption protège contre la divulgation du bundle par Capgo, les fournisseurs de stockage, les CDNs ou tout individu qui ne voit que l'artefact de livraison chiffré. Il empêche également les tiers de générer des mises à jour chiffrées valides sans votre clé privée. Puisque la clé publique est intégrée dans l'application distribuée afin que le client puisse déchiffrer les mises à jour, quelqu'un qui a votre binôme d'application et suffisamment de motivation peut toujours récupérer les éléments de clé nécessaires pour inspecter le bundle.

Conseil

L'encryption est particulièrement important pour :

• Les applications gérant des données sensibles ou des logiques métier
• Les applications d'entreprise avec des exigences de conformité
• Les applications déployées dans des industries réglementées
• Les organisations avec des politiques de sécurité strictes

Comment fonctionne l'encryption

Capgo utilise une approche de cryptage hybride qui combine la cryptage RSA et AES pour une sécurité et une performance optimales :

1. Génération de clés

• Clé privée: Générée et stockée de manière sécurisée dans votre environnement de développement (utilisée pour le cryptage)
• Clé publique: Dérivée de votre clé privée et stockée dans la configuration de votre application Capacitor (utilisée pour le déchiffrement)
• Clés de session: Clés AES aléatoires générées pour chaque téléchargement de bundle

2. Processus de cryptage

1. Une clé de session AES aléatoire est générée pour chaque téléchargement de bundle
2. Votre bundle est chiffré à l'aide de la clé de session AES
3. Le checksum du bundle est calculé
4. La clé de session AES et le checksum sont chiffrés ensemble à l'aide de votre clé privée RSA (créant la « signature »)
5. Le bundle chiffré et la signature chiffrée sont stockés

Le checksum est chiffré en même temps que la clé AES pour prévenir toute manipulation. Puisque seule votre clé privée RSA peut créer cette signature, et que seule la clé publique correspondante peut la déchiffrer, cela garantit que la clé de session AES et le checksum attendu sont authentiques et n'ont pas été modifiés par un attaquant.

3. Processus de déchiffrement

1. Votre application télécharge le bundle chiffré et la signature chiffrée
2. Le Capgo SDK utilise votre clé publique RSA (stockée dans l'application) pour déchiffrer la signature
3. Cela révèle la clé de session AES et le checksum original
4. La clé de session AES est utilisée pour déchiffrer le bundle.
5. Un checksum du bundle déchiffré est calculé et comparé avec le checksum original pour la vérification de l'intégrité.

Cette procédure garantit que même si un attaquant intercepte le bundle chiffré, il ne peut pas modifier la clé de session AES ou fournir un checksum fictif, car il aurait besoin de votre clé privée pour créer une signature valide que la clé publique peut déchiffrer.

Conseil

Le RSA ne chiffrerait pas efficacement de grandes quantités de données, donc AES est utilisé pour le chiffrement réel du bundle tandis que le RSA sécurise la clé AES et fournit la vérification d'intégrité par signature de checksum.

Capgo vs Autres Plates-formes

Fonctionnalité	Capgo	Autres Plates-formes OTA
Contenu du Bundle	Chiffré en stockage/transport ; toujours inspectable par un ingénieur reverse avec le fichier binaire de l'application	Lisible par tous
Méthode de sécurité	Chiffrement de bout en bout réel	Code : signature uniquement
Niveau de confidentialité	Protection forte du déploiement/stockage ; pas anti-ingénierie reverse	La plateforme peut accéder à votre code
Protection	Contenu + intégrité + authenticité	Intégrité + authenticité uniquement

Pourquoi cela compte :

• Code signature seullement vérifie que les mises à jour n'ont pas été altérées et proviennent de la bonne source
• Capgo encryption protège le bundle pendant qu'il est stocké et livré et rend les mises à jour cryptées fabriquées plus difficiles car l'attaquant aurait besoin de votre clé privée
• La reverse engineering est toujours possible après que l'application soit déployée, car le client contient la clé publique nécessaire pour déchiffrer et charger la mise à jour

Méthodes de cryptage

Capgo utilise la méthode de cryptage V2 comme méthode de cryptage standard :

Méthode de cryptage V2 (Norme actuelle)

• Utilise RSA-4096 pour une sécurité renforcée
• AES-256-GCM pour l'authentification chiffrée
• Fournit la vérification de l'intégrité
• Meilleure performance et sécurité

Chiffrement V1 (Déprécié)

• Utilise RSA-2048 pour le chiffrement des clés
• AES-256-CBC pour le chiffrement des bundles
• Plus disponible actuellement dans le CLI
• Les applications légaciers utilisant V1 doivent migrer vers V2

Danger

Le chiffrement V1 n'est plus pris en charge actuellement dans le Capgo CLI. Si vous utilisez le chiffrement V1, vous devez migrer vers V2. Voir le guide de migration pour des instructions détaillées.

Configurer la cryptage

Étape 1 : Générez des clés de cryptage

Générez d’abord vos clés de cryptage à l’aide du Capgo CLI :

# Generate new encryption keys (creates files in current directory)
npx @capgo/cli@latest key create

Cela crée :

• .capgo_key_v2: Votre clé privée (gardez-la sécurisée !)
• .capgo_key_v2.pub: Votre clé publique (utilisée par votre application)

Ces fichiers sont créés dans le répertoire actuel où vous exécutez la commande.

Attention

Notes importantes sur le stockage :

• Clé privée (.capgo_key_v2) : N'oubliez jamais de ne pas la commiter dans le contrôle de version. Ce fichier doit être conservé en toute sécurité et utilisé uniquement pour la mise en cryptage lors des téléchargements de bundles.
• Clé publique (.capgo_key_v2.pub) : Cela est sécurisé pour être commis dans le contrôle de version car il s'agit d'une copie de sauvegarde de votre clé publique.
• Emplacement du fichier : Les clés sont créées dans le répertoire actuel où vous exécutez la key create commande.
• Clé publique dans la configuration: Vous devez exécuter key save pour stocker la clé publique dans votre Capacitor config pour que l'application mobile puisse l'utiliser.

Pour un usage en production, stockez la clé privée de manière sécurisée (variables d'environnement, services de gestion de clés) et supprimez-la de votre projet local après la mise en place.

Étape 2 : Sauvegardez votre clé publique dans la config Capacitor (obligatoire)

Vous context save your public key to the Capacitor config so your mobile app can decrypt bundles:

# Save public key from file to Capacitor config (required)
npx @capgo/cli@latest key save --key ./.capgo_key_v2.pub

# Or save public key data directly
npx @capgo/cli@latest key save --key-data "$CAPGO_PUBLIC_KEY"

Step 3: Sync Capacitor Platform (Required)

Après avoir enregistré la clé publique, vous devez synchroniser la plateforme Capacitor pour copier la configuration mise à jour vers la couche native :

# Sync the platform to copy config to native
npx cap sync

Attention

Étapes requises:

1. Le key save la commande enregistre la clé publique dans votre configuration Capacitor
2. npx cap sync copie cette configuration vers la couche native où l'application mobile peut y accéder
3. Sans les deux étapes, votre application ne pourra pas déchiffrer les mises à jour chiffrées

Chiffrage des Bundles

Méthode 1 : Chiffrage pendant l'upload

La méthode la plus simple consiste à chiffrer pendant le processus d'upload :

# Upload with automatic encryption
npx @capgo/cli@latest bundle upload --key-v2

# For external storage, you must encrypt first (see Manual Encryption Workflow below)

Méthode 2 : Flux de travail de chiffrage manuel

Pour plus de contrôle, vous pouvez chiffrer manuellement les bundles :

1. Créer un bundle zip :

   npx @capgo/cli@latest bundle zip com.example.app --path ./dist --key-v2

2. Chiffrer le bundle :

   npx @capgo/cli@latest bundle encrypt ./com.example.app.zip CHECKSUM_FROM_STEP_1

3. Télécharger sur votre stockage (par exemple, S3) et enregistrer avec Capgo :

   # First upload the encrypted bundle to your storage (e.g., AWS S3)
   aws s3 cp ./encrypted-bundle.zip s3://your-bucket/encrypted-bundle.zip
   
   # Then register with Capgo using the external URL
   npx @capgo/cli@latest bundle upload --external https://your-storage.com/encrypted-bundle.zip --iv-session-key IV_SESSION_KEY_FROM_STEP_2

Gestion des clés

Stockage des clés de manière sécurisée

Options de clés privées :

1. Chemin de fichier (développement local):

   # Key stored as .capgo_key_v2 file in project root
   npx @capgo/cli@latest bundle upload --key-v2

2. Variable d'environnement (CI/CD):

   # Store in environment variable for CI
   export CAPGO_PRIVATE_KEY="$(cat .capgo_key_v2)"
   npx @capgo/cli@latest bundle upload --key-data-v2 "$CAPGO_PRIVATE_KEY"

Configuration de la clé publique (obligatoire):

# Must save public key to Capacitor config for mobile app
npx @capgo/cli@latest key save --key ./.capgo_key_v2.pub

Environnement de production:

• Stockez les clés privées dans des services de gestion de clés sécurisés (AWS KMS, Azure Key Vault, etc.)
• Utilisez la gestion de secrets CI/CD pour les clés privées
• N'ajoutez jamais les clés privées au contrôle de version.

Utilisation de la clé :

• Clé privée: Utilisée par CLI pour la mise en cryptage lors de l'envoi du paquet (gardez-la sécurisée)
• Clé publique: Stockée dans la configuration de l'application pour la décryptage sur le dispositif (sécurisé pour la mise en version)

Rotafter une compromission de la clé privée

Rotez le paire de clés lorsque la clé privée est soupçonnée ou confirmée compromise. Une rotation calendaire régulière n'est pas requise. Il s'agit d'une migration de clé native, pas d'une mise à jour OTA uniquement.

1. Générez un nouveau paire de clés :

   npx @capgo/cli@latest key create

2. Enregistrez la clé publique de remplacement dans votre Capacitor de configuration :

   npx @capgo/cli@latest key save --key ./.capgo_key_v2.pub

3. Synchro et expédiez une mise à jour native : Exécuter npx cap sync, puis distribuez une nouvelle version d'application native contenant la clé publique de remplacement.

4. Ciblez la nouvelle version native : Les appareils qui exécutent toujours la version native ancienne ne peuvent pas déchiffrer les mises à jour chiffrées avec la clé de remplacement. Utilisez La ciblage de version context : Page/zone : Page de marketing de solutions Capgo. Rôle : En-tête de section ou de page. Vu dans : page solutions/version-targeting.astro. Clé de message `solutions_version_targeting_title` (Titre de la ciblage de version de solutions). | Page/zone : Page de marketing de solutions Capgo. Rôle : Étiquette de navigation ou courte étiquette UI. Vu dans : page solutions/version-targeting.astro. Clé de message `solutions_version_targeting` (Ciblage de version de solutions).

5. pour limiter les ensembles de fichiers de remplacement à la nouvelle version native tandis que le reste de la flotte met à jour via l'app store ou MDM. Changer votre secret d'upload :

Attention

Si la clé privée est compromise, arrêtez d'en faire usage immédiatement. Les installations existantes avec la clé publique ancienne nécessitent une mise à jour du magasin natif ou MDM avant de pouvoir recevoir des lots chiffrés avec la nouvelle clé.

Meilleures Pratiques de Sécurité

Sécurité des Clés

• N'envoyez jamais les clés privées entre environnements ou membres d'équipe
• Utilisez des clés différentes pour différents environnements (développement, étape de test, production)
• Rotez-les après une compromise: remplacez le couple de clés lorsque la clé privée est suspectée ou confirmée compromise ; une rotation de calendrier régulière n'est pas requise
• Stockez les clés de manière sécurisée en utilisant des systèmes de gestion de clés appropriés

Sécurité du Bundle

• Vérifiez toujours l'intégrité du bundle après déchiffrement
• Surveillez pour les modèles de téléchargement inhabituels ou les échecs
• Utilisez HTTPS pour toutes les URL du bundle (obligatoire pour les applications mobiles)
• Mettez en œuvre gestion des erreurs appropriée pour les échecs de déchiffrement

Contrôle d'accès

• Restreindre l'accès aux clés de chiffrement uniquement aux personnels autorisés
• Utiliser un contrôle d'accès basé sur les rôles pour les opérations de gestion de clés
• Vérification l'utilisation et l'accès aux clés régulièrement
• Mettre en œuvre des procédures de sauvegarde et de récupération appropriées

Résolution des problèmes de chiffrement

Problèmes courants

Échecs de déchiffrement :

• Vérifiez que la clé privée correspond à la clé publique utilisée pour l'encryption
• Vérifiez que le ivSessionKey est correct
• Assurez-vous d'utiliser l'Encryption V2 (V1 n'est plus pris en charge)

Erreurs liées aux clés :

• Confirmez que le format de la clé privée est correct (format PEM)
• Vérifiez que la clé n'a pas été corrompue lors de son stockage ou de son transfert
• Vérifiez que la clé a les permissions appropriées dans votre configuration d'application

Problèmes de performance :

• Les gros paquets peuvent prendre plus de temps pour s'encrypter/dérypter
• Considérez l'utilisation des mises à jour Delta (manifest) pour réduire les tailles des paquets
• Surveillez la performance du dispositif pendant la décryptage

Commandes de débogage

Vérifiez l'état de l'encryption :

npx @capgo/cli@latest app debug

Testez le flux de workflow d'encryption/déryption :

# Test the complete workflow: zip → encrypt → decrypt → unzip
npx @capgo/cli@latest bundle zip com.example.app --key-v2
npx @capgo/cli@latest bundle encrypt ./com.example.app.zip CHECKSUM --json
npx @capgo/cli@latest bundle decrypt ./encrypted-bundle.zip IV_SESSION_KEY

Conformité et Normes

La mise en œuvre d'Capgo de l'encryption suit les normes de l'industrie :

• AES-256: Algorithme d'encryption approuvé FIPS 140-2
• RSA-4096: Forte encryption asymétrique pour la protection des clés
• Mode GCM: fournit à la fois la confidentialité et l'authenticité
• Aléatoire Sûr: Génération de nombres aléatoires cryptographiquement sûrs

Cela rend Capgo adapté aux applications nécessitant le respect de :

• Règlement Général sur la Protection des Données (RGPD)
• Loi sur la Portabilité et la Responsabilité des Assurances de Santé (HIPAA)
• Contrôle de Service Organisation 2 (SOC 2)
• Gestion de la Sécurité de l'Information (ISO 27001)

Considérations relatives à la performance

Surcharge de chiffrement

• Taille du paquet: Les paquets chiffrés sont légèrement plus volumineux (~1-2% de surcharge)
• Temps de traitement: Le chiffrement/déchiffrement ajoute une latence minimale
• Utilisation de la mémoire: Augmentation temporaire pendant les opérations d'encryption/décryption

Conseils d'optimisation

• Utilisez les mises à jour Delta (manifest) pour minimiser les transferts de données chiffrées
• Optimisez la taille de votre bundle en convertissant les images au format WebP
• Minimisez les fichiers JavaScript et CSS avant bundling
• Supprimez les dépendances non utilisées et code
• Surveillez les performances du dispositif sur les appareils plus anciens/lents

Étapes suivantes

• Apprenez-en plus sur Stockage personnalisé pour utiliser l'encryption avec votre propre infrastructure
• Explorez Canaux Gérer les ensembles de fichiers chiffrés entre les environnements
• Configurer Intégration CI/CD automatiser les déploiements chiffrés

Continuez de la section Chiffrement

Si vous utilisez Chiffrement pour planifier la sécurité et la conformité, connectez-l’à Conformité pour les détails 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é Capgo Centre de confiance pour le flux de travail du produit dans Capgo Centre de confiance, et Sécurité de l'organisation pour les détails d'implémentation dans Sécurité de l'organisation