Aller directement au contenu

Chiffrement

Capgo fournit une encryption robuste de bout en bout pour vos ensembles d'applications, vous assurant que vos scripts JavaScript code et vos actifs sont protégés pendant la transmission et le 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 direct.

Capgo's système d'encryption utilise des méthodes cryptographiques industrielles pour protéger vos ensembles de fichiers des accès non autorisés. Lorsque l'encryption est activé, vos ensembles de fichiers 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.

What Encryption Actually Protects: À la différence des systèmes OTA qui ne signent que les mises à jour, Capgo chiffre le bundle téléchargé avant stockage et livraison. Cela protège les contenus du bundle contre les accès non autorisés en stockage ou en transit et garantit que seuls les détenteurs de votre clé privée peuvent produire une mise à jour chiffrée valide. Il ne rend 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 bundle avec suffisamment d'effort. When You Need Encryption When You Need Encryption

Les applications déployées dans des secteurs réglementés

Les organisations avec des politiques de sécurité strictes

Capgo uses a hybrid encryption approach that combines RSA and AES encryption for optimal security and performance:

Capgo Encryption Flow

  • 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 l'encryption)
  • Clé Publique: Dérivée de votre clé privée et stockée dans la configuration de votre application Capacitor (utilisée pour la décryptage)
  • Clés de Session: Clés AES aléatoires générées pour chaque téléchargement de bundle
  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. The calcul du checksum du bundle est effectué
  4. Les deux clés 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 seuls votre clé privée RSA peut créer cette signature, et seuls la clé publique correspondante peut la déchiffrer, cela garantit que les deux clés de session AES et le checksum attendu sont authentiques et n'ont pas été modifiés par un attaquant.

  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 vérification d'intégrité

Ce processus 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.

FonctionnalitéCapgoAutres Platesformes OTA
Contenu du BundleChiffré en stockage/transport ; toujours inspectable par un ingénieur reverse qui a déterminé l'application binaireLisible par le public
Méthode de SécuritéChiffrement à la fin à finCode signature uniquement
Niveau de confidentialitéProtection de livraison/stockage solide; pas anti-décompilationLa plateforme peut accéder à votre code
ProtectionContenu + intégrité + authenticitéIntégrité + authenticité uniquement

Pourquoi Cela Compte :

  • Code signature ne vérifie que les mises à jour n'ont pas été altérées et proviennent de la bonne source
  • Capgo chiffrement protège le bundle pendant qu'il est stocké et livré et rend les mises à jour chiffrées contrefaites beaucoup plus difficiles à obtenir car l'attaquant aurait besoin de votre clé privée
  • Le 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

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

  • Utilise RSA-4096 pour une sécurité renforcée
  • Utilise AES-256-GCM pour un chiffrement authentifié
  • Fournit une vérification d'intégrité
  • Meilleure performance et sécurité
  • Utilise RSA-2048 pour le chiffrement des clés
  • AES-256-CBC pour le chiffrement des ensembles
  • Plus disponible actuellement dans le CLI
  • Les applications héritières utilisant V1 doivent migrer vers V2

Tout d'abord, générer vos clés d'encryption à l'aide du Capgo CLI:

Fenêtre de terminal
# 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.

Étape 2 : Enregistrez votre clé publique dans la configuration Capacitor (obligatoire)

Section intitulée « Étape 2 : Enregistrez votre clé publique dans la configuration Capacitor (obligatoire) »

Vous devez enregistrer votre clé publique dans la configuration Capacitor afin que votre application mobile puisse déchiffrer les ensembles :

Fenêtre de terminal
# 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"

Étape 3 : Synchroniser la plateforme Capacitor (obligatoire)

Section intitulée « Étape 3 : Synchroniser la plateforme Capacitor (obligatoire) »

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

Fenêtre de terminal
# Sync the platform to copy config to native
npx cap sync

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

Fenêtre de terminal
# Upload with automatic encryption
npx @capgo/cli@latest bundle upload --key-v2
# For external storage, you must encrypt first (see Manual Encryption Workflow below)

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

  1. Créer un bundle zip :

    Fenêtre de terminal
    npx @capgo/cli@latest bundle zip com.example.app --path ./dist --key-v2
  2. Chiffrer le bundle :

    Fenêtre de terminal
    npx @capgo/cli@latest bundle encrypt ./com.example.app.zip CHECKSUM_FROM_STEP_1
  3. Télécharger dans votre stockage (par exemple, S3) et enregistrer avec Capgo:

    Fenêtre de terminal
    # 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

Options de clé privée :

  1. Fichier (développement local) :

    Fenêtre de terminal
    # Key stored as .capgo_key_v2 file in project root
    npx @capgo/cli@latest bundle upload --key-v2
  2. Variable d'environnement (CI/CD) :

    Fenêtre de terminal
    # 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 (Requis) :

Fenêtre de terminal
# 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 des 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é par CLI pour la cryptage lors de l'envoi du bundle (gardez sécurisé)
  • Clé publique: Stocké dans la configuration de l'application pour la décryptage sur le dispositif (sûr de commiter)

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 une modification OTA uniquement.

  1. Générez une nouvelle paire de clés :

    Fenêtre de terminal
    npx @capgo/cli@latest key create
  2. Enregistrez la clé publique de remplacement dans votre Capacitor config :

    Fenêtre de terminal
    npx @capgo/cli@latest key save --key ./.capgo_key_v2.pub
  3. Synchronisez et expédiez une mise à jour native : Exécutez npx cap sync, puis distribuez une nouvelle version d'application native contenant la nouvelle clé publique.

  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 nouvelle clé. Utilisez la fonctionnalité de "Version Targeting" pour limiter les ensembles de mises à jour contenant la nouvelle clé à la nouvelle version native tout en laissant le reste de la flotte se mettre à jour via l'App Store ou MDM. Changer votre secret d'upload : Dès que cette mise à jour native est en ligne, remplacez la clé privée dans CI et n'envoyez que des ensembles ciblés vers les versions natives contenant la nouvelle clé publique.

  5. Attention Attention

  • N'oubliez jamais de partager vos clés privées entre environnements ou membres de l'équipe
  • Utilisez des clés différentes pour différents environnements (dev, étape, production)
  • Rotafter une violation de sécurité: remplacez le paire de clés lorsque la clé privée est soupçonnée ou confirmée compromise; une rotation régulière du calendrier 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
  • Vérifiez toujours l'intégrité du bundle après décryptage
  • Surveillez les modèles de téléchargement inhabituels ou les échecs
  • Utilisez HTTPS pour toutes les URL du bundle (obligatoire pour les applications mobiles)
  • Implémentez une gestion des erreurs appropriée pour les échecs de décryptage
  • Accès limité à les clés de chiffrement uniquement aux personnels autorisés
  • Utilisez l'accès basé sur le rôle pour les opérations de gestion des clés
  • Audit l'utilisation et l'accès des clés régulièrement
  • Mettez en œuvre des procédures de sauvegarde et de récupération appropriées

Échecs de déchiffrement :

  • Vérifiez que la clé privée correspond à la clé publique utilisée pour la mise en forme
  • Vérifiez que le ivSessionKey est correct
  • Assurez-vous d'utiliser la version 2 de l'encryption (la version 1 n'est plus prise 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/transfer
  • Vérifiez que la clé a les bonnes permissions dans votre configuration d'application

Problèmes de performance :

  • Les gros bundles peuvent prendre plus de temps pour être chiffrés/déchiffrés
  • Considérez l'utilisation de mises à jour Delta (manifeste) pour réduire les tailles des bundles
  • Surveiller les performances du dispositif pendant la décryptage

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

Fenêtre de terminal
npx @capgo/cli@latest app debug

Tester le flux de chiffrement/décryptage :

Fenêtre de terminal
# 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

Capgo suit les normes de l'industrie dans son implémentation de chiffrement :

  • AES-256 : Algorithme d'encryption homologué FIPS 140-2
  • RSA-4096 : Forte encryption asymétrique pour la protection des clés
  • GCM Mode : fournit à la fois la confidentialité et l'authenticité
  • Secure Random : 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 de portabilité et de responsabilité dans l'assurance maladie (HIPAA)
  • Contrôle de service organisation 2 (SOC 2)
  • ISO 27001 (Gestion de la sécurité des informations)
  • Taille du paquetLes paquets chiffrés sont légèrement plus grands (~1-2% de surcharge)
  • Temps de traitementLa mise en cryptage/décryptage ajoute une latence minimale
  • Utilisation de la mémoireAugmentation temporaire pendant les opérations de cryptage/décryptage
  • 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 la mise en bundle
  • Supprimez les dépendances inutilisées et code
  • Surveillez les performances du dispositif sur les appareils plus anciens/lents
  • Apprenez à Stockage personnalisé pour utiliser l'encryption avec votre propre infrastructure
  • Explorez Canaux pour gérer les ensembles chiffrés à travers les environnements
  • Configurer l'intégration CI/CD pour automatiser les déploiements chiffrés

__CAPGO_KEEP_0__

Si vous utilisez

Chiffrement pour planifier la sécurité et la conformité, connectez-le avec Conformité pour les détails d'implémentation dans Conformité, Si vous utilisez le Chiffrement Capgo Scanner de sécurité pour le flux de travail du produit dans Capgo Scanner de sécurité, Capgo Centre de confiance pour le flux de travail du produit dans Capgo Centre de confiance, Capgo Centre de confiance pour le flux de travail du produit dans Capgo Centre de confiance, et Sécurité de l'organisation pour le détail d'implémentation dans Sécurité de l'organisation.