Verschlüsselung

Capgo bietet robuste Ende-zu-Ende-Verschlüsselung für Ihre App-Bundles, sodass Ihre JavaScript code und -Assets während der Übertragung und Speicherung geschützt sind. Diese Verschlüsselungssystem ist darauf ausgelegt, Ihnen die volle Kontrolle über die Sicherheit Ihrer App zu geben, während die Möglichkeit von Live-Updates beibehalten wird.

Übersicht

Capgo's Verschlüsselungssystem verwendet branchenstandardisierte kryptographische Methoden, um Ihre Bundles vor unbefugtem Zugriff zu schützen. Wenn die Verschlüsselung aktiviert ist, werden Ihre Bundles vor dem Verlassen Ihres Entwicklungsumgebungen verschlüsselt und bleiben verschlüsselt, bis sie von Ihrer App auf dem Gerät des Benutzers entschlüsselt werden.

Was Verschlüsselung tatsächlich schützt: Anders als OTA-Systeme, die nur Updates signieren, verschlüsselt Capgo das hochgeladene Bundle vor dem Speicher und der Lieferung. Dies schützt die Inhalte des Bundles vor zufälligem Zugriff im Speicher oder im Transit und stellt sicher, dass nur jemand mit Ihrem privaten Schlüssel ein gültig verschlüsseltes Update erstellen kann. Es macht geschickte

Wenn Sie Verschlüsselung benötigen

Wenn Sie ein Bundle ohne Verschlüsselung hochladen, behandeln Sie es als öffentliches Asset. Private Kanäle beschränken die Geräte, die ein Update erhalten, aber sie machen das hochgeladene Bundle nicht vertraulich. Die Verschlüsselung ist nützlich, wenn Sie eine bessere Schutz vor Speicherung und Transit benötigen und wenn Sie nur die Inhaber des privaten Schlüssels haben möchten, die gültig verschlüsselte Updates veröffentlichen können. Sie garantiert nicht, dass der gelieferte JavaScript-, HTML- oder CSS-Code nie inspiziert werden kann.

Gefahrenmodell

Capgo-Verschlüsselung schützt vor der Offenlegung des Bundles durch Capgo, Speicheranbieter, CDNs oder Personen, die nur den verschlüsselten Lieferartikel sehen. Sie verhindert auch, dass Dritte gültig verschlüsselte Updates ohne Ihren privaten Schlüssel generieren können. Da der öffentliche Schlüssel im verteilten App-Code eingebettet ist, damit der Client Updates entschlüsseln kann, kann jemand, der Ihr App-Binary und genügend Motivation hat, immer noch das erforderliche Schlüsselmaterial zur Inspektion des Bundles zurückgewinnen.

Tipp

Die Verschlüsselung ist insbesondere wichtig für:

• Apps, die sensible Daten oder Geschäftslogik verarbeiten
• Unternehmensanwendungen mit Compliance-Anforderungen
• Apps in regulierten Branchen
• Organisationen mit strengen Sicherheitsrichtlinien

Wie Verschlüsselung funktioniert

Capgo verwendet eine hybride Verschlüsselungsanordnung, die RSA- und AES-Verschlüsselung kombiniert, um eine optimale Sicherheit und Leistung zu gewährleisten:

1. Schlüsselgenerierung

• Privatschlüssel: Generiert und sicher gespeichert in Ihrem Entwicklungsumfeld (wird für die Verschlüsselung verwendet)
• Öffentlicher Schlüssel: Abgeleitet aus Ihrem privaten Schlüssel und in Ihrer App-Capacitor-Konfiguration gespeichert (wird für die Entschlüsselung verwendet)
• Sitzungschlüssel: Zufällige AES-Schlüssel generiert für jede Upload-Paket-Datei

2. Verschlüsselungsprozess

1. Eine zufällige AES-Sitzungsschlüssel wird für jede Upload-Bundle generiert
2. Ihr Bundle wird mit dem AES-Sitzungsschlüssel verschlüsselt
3. Der Bundle-Prüfsummenwert wird berechnet
4. Beide der AES-Sitzungsschlüssel und Prüfsummenwert werden mithilfe Ihres RSA-Privatschlüssels (Erstellung der “Unterschrift”) verschlüsselt
5. Das verschlüsselte Bundle und die verschlüsselte Unterschrift werden gespeichert

Die Prüfsumme wird neben dem AES-Schlüssel verschlüsselt, um Manipulationen zu verhindern. Da nur Ihr RSA-Privatschlüssel diese Unterschrift erstellen kann und nur der entsprechende öffentliche Schlüssel sie entschlüsseln kann, stellt dies sicher, dass sowohl der AES-Sitzungsschlüssel als auch die erwartete Prüfsumme authentisch sind und nicht von einem Angreifer manipuliert wurden.

3. Entschlüsselungsprozess

1. Ihr App lädt das verschlüsselte Bundle und die verschlüsselte Unterschrift herunter
2. Der Capgo SDK verwendet Ihren RSA-öffentlichen Schlüssel (gespeichert im App) zur Entschlüsselung der Unterschrift
3. Dies offenbart den AES-Sitzungsschlüssel und die ursprüngliche Prüfsumme
4. Der AES-Sitzungsschlüssel wird verwendet, um das Bundle zu entschlüsseln
5. Ein Prüfsummenwert des entschlüsselten Bundles wird berechnet und mit der ursprünglichen Prüfsumme verglichen, um die Integrität zu überprüfen

Dieser Prozess stellt sicher, dass selbst wenn ein Angreifer das verschlüsselte Bundle abfangt, er das AES-Sitzungsschlüssel nicht ändern oder einen falschen Prüfsummenwert bereitstellen kann, weil er Ihre private Schlüssel benötigen würde, um einen gültigen Signatur zu erstellen, die der öffentliche Schlüssel entschlüsseln kann.

Tip

RSA kann große Datenmengen nicht effizient verschlüsseln, daher wird AES für die tatsächliche Bundle-Verschlüsselung verwendet, während RSA den AES-Schlüssel sichert und die Integrität durch Prüfsummen-Signierung überprüft.

Capgo vs Andere Plattformen

Funktion	Capgo	Andere OTA-Plattformen
Bundle-Inhalt	Verschlüsselt in Speicher/Übertragung; kann jedoch noch von einem bestimmten Reverse-Engineer mit dem App-Binary inspiziert werden	Öffentlich lesbar
Sicherheitsmethode	Wahre Ende-zu-Ende-Verschlüsselung	Code-Signierung nur
Vertraulichkeitsstufe	Starke Lieferung/Speicher-Schutz; kein Anti-Reverse-Engineering	Die Plattform kann auf Ihr code zugreifen
Schutz	Inhalt + Integrität + Authentizität	Nur Integrität + Authentizität

Warum das wichtig ist:

• Code Signierung nur überprüft, dass Updates nicht manipuliert wurden und vom richtigen Quellcode stammen
• Capgo Verschlüsselung schützt das Bundle während der Speicherung und des Transports und macht gefälschte verschlüsselte Updates viel schwieriger, da der Angreifer Ihre private Schlüssel benötigen würde
• Das Umgehen der Sicherheitsmaßnahmen ist immer noch möglich nachdem die App verschickt wurde, weil der Client den öffentlichen Schlüssel enthält, der zum Entschlüsseln und Laden des Updates benötigt wird

Verschlüsselungsmethoden

Capgo verwendet Verschlüsselung V2 als Standardverschlüsselungsmethode:

Verschlüsselung V2 (aktuelles Standardverfahren)

• Verwendet RSA-4096 für erhöhte Sicherheit
• AES-256-GCM für die authentifizierte Verschlüsselung
• Bietet eine Integritätsprüfung
• Bessere Leistung und Sicherheit

Verschlüsselung V1 (Veraltet)

• Verwendet RSA-2048 für die Verschlüsselung der Schlüssel
• AES-256-CBC für die Verschlüsselung von Paketen
• Nicht mehr verfügbar in der aktuellen CLI
• Legacy-Anwendungen, die V1 verwenden müssen, migrieren zu V2

Gefahr

Die Verschlüsselung V1 ist in der aktuellen Capgo CLI nicht mehr unterstützt. Wenn Sie V1-Verschlüsselung verwenden, müssen Sie zu V2 migrieren. Siehe die Migrationsanleitung Zur detaillierten Anleitung.

Verschlüsselung einrichten

Schritt 1: Erstellen Sie Verschlüsselungsschlüssel

Erstellen Sie zunächst Ihre Verschlüsselungsschlüssel mit den Capgo CLI:

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

Dies erstellt:

• .capgo_key_v2: Ihre private Schlüssel (halten Sie dies sicher!)
• .capgo_key_v2.pub: Ihre öffentliche Schlüssel (wird von Ihrer App verwendet)

Aktuelle Dateien werden in dem Verzeichnis erstellt, in dem Sie den Befehl ausführen.

Vorsicht

Wichtige Speicherhinweise:

• Privater Schlüssel (.capgo_key_v2): Kommt diesen niemals in die Versionskontrolle. Diese Datei sollte sicher aufbewahrt und nur für die Verschlüsselung während der Uploads von Paketen verwendet werden.
• Öffentlicher Schlüssel (.capgo_key_v2.pub): Dies ist sicher in die Versionskontrolle zu committen, da es eine Sicherung Ihres öffentlichen Schlüssels ist.
• Datei-Ort: Schlüssel werden in dem Verzeichnis erstellt, in dem Sie den key create Befehl ausführen.
• Öffentlicher Schlüssel in der Konfiguration: Sie müssen ausführen key save Um die öffentliche Schlüssel in Ihrer Capacitor-Konfiguration für die mobile App zu speichern.

Für die Produktionsverwendung speichern Sie den privaten Schlüssel sicher (Umgebungsvariablen, Schlüsselmanagementdienste) und entfernen ihn aus Ihrem lokalen Projekt nach der Einrichtung.

Schritt 2: Speichern Sie Ihre öffentliche Schlüssel in der Capacitor-Konfiguration (Pflicht)

Sie müssen Ihre öffentliche Schlüssel in der Capacitor-Konfiguration speichern, damit Ihre mobile App Pakete entschlüsseln kann:

# 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"

Schritt 3: Synchronisieren Sie die Capacitor-Plattform (Pflicht)

Nachdem Sie die öffentliche Schlüssel gespeichert haben, müssen Sie müssen synchronisieren Sie das Capacitor-Plattform, um die aktualisierte Konfiguration auf die native Ebene zu kopieren:

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

Vorsicht

Erforderliche Schritte:

1. Der key save Befehl speichert die öffentliche Schlüssel in Ihrer Capacitor-Konfiguration
2. npx cap sync kopiert diese Konfiguration auf die native Ebene, wo die mobile App darauf zugreifen kann
3. Ohne beide Schritte kann Ihre App nicht verschlüsselte Updates entschlüsseln

Verschlüsselung von Bundles

Methode 1: Verschlüsseln während des Uploads

Der einfachste Weg besteht darin, während des Upload-Prozesses zu verschlüsseln:

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

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

Methode 2: Manuelle Verschlüsselungsworkflow

Für mehr Kontrolle können Sie Bundles manuell verschlüsseln:

1. Ein Zip-Bundle erstellen:

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

2. Das Bundle verschlüsseln:

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

3. Hochladen Sie es in Ihr Speicher (z.B. S3) und registrieren Sie es bei 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

Zugriff auf Schlüssel

Sichere Speicherung von Schlüsseln

Optionen für den privaten Schlüssel:

1. Datei-basiert (lokale Entwicklung):

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

2. Umgebungsvariable (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"

Öffentlicher Schlüssel-Setup (erforderlich):

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

Produktionsumgebung:

• Sichere Schlüssel in einer sicheren Schlüsselverwaltungsdienstleistung (AWS KMS, Azure Key Vault usw.) speichern
• Verwenden Sie eine CI/CD-Schlüsselverwaltung für private Schlüssel
• Nie speichern Sie private Schlüssel im Versionskontrolle

Zugriff:

• Privater Schlüssel: Wird von CLI für die Verschlüsselung während der Upload des Bundles verwendet (sicherheitsrelevant)
• Öffentlicher Schlüssel: In der Anwendungs-Konfiguration gespeichert für die Entschlüsselung auf dem Gerät (sicher zum Commit)

Rotieren Sie nach einem privatschlüsselbedingten Kompromiss

Rotieren Sie das Schlüsselpaar, wenn der private Schlüssel verdächtigt oder bestätigt als kompromittiert angesehen wird. Eine routinemäßige Kalenderrotation ist nicht erforderlich. Dies ist eine native-Schlüsselmigration und keine nur-OTA-Änderung.

1. Ersatzschlüsselpaar generieren:

   npx @capgo/cli@latest key create

2. Speichern Sie die Ersatzöffentlichkeitsschlüssel in Ihrem Capacitor-Konfiguration:

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

3. Synchronisieren und liefern Sie eine native Version: Ausführen npx cap sync, dann verteilen Sie eine neue native App-Version, die den Ersatzöffentlichkeitsschlüssel enthält.

4. Ziel der neuen native Version: Geräte, die noch die alte native Binärdatei ausführen, können Updates verschlüsselt mit dem Ersatzschlüssel nicht entschlüsseln. Verwenden Sie Version-Zielsetzung um die Ersatzschlüssel-Bundles auf die neue native Version zu beschränken, während der Rest der Flotte über den Store oder MDM aktualisiert wird.

5. Wechseln Sie Ihr Upload-Geheimnis: Sobald diese native Version live ist, ersetzen Sie den privaten Schlüssel in CI und laden Sie nur Bundles hoch, die auf native Versionen abzielen, die den Ersatzöffentlichkeitsschlüssel enthalten.

Achtung

Wenn der private Schlüssel kompromittiert ist, verwenden Sie ihn sofort nicht mehr. Bestehende Installationen mit dem alten öffentlichen Schlüssel benötigen eine native Speicherplatz- oder MDM-Update, bevor sie Pakete verschlüsselt mit dem Ersatzschlüssel empfangen können.

Security Best Practices

Schlüsselsicherheit

• Teilen Sie niemals private Schlüssel zwischen Umgebungen oder Teammitgliedern
• Verwenden Sie unterschiedliche Schlüssel für unterschiedliche Umgebungen (Entwicklung, Staging, Produktion)
• Drehen Sie nach einer Kompromittierung: ersetzen Sie die Schlüsselpaar, wenn der private Schlüssel verdächtig oder bestätigt als kompromittiert ist; Eine routinemäßige Kalenderrotation ist nicht erforderlich
• Sicherheitsmaßnahmen für geschützte Daten Sicherheit durch geeignete Schlüsselverwaltungssysteme

Bundle-Sicherheit

• die Integrität des Bundles nach der Entschlüsselung immer wieder überprüfen Überwachung
• für ungewöhnliche Downloadmuster oder Fehler Verwendung von HTTPS
• für alle Bundle-URLs (erforderlich für mobile Apps) Implementierung
• Bundle-Sicherheit ordnungsgemäße Fehlerbehandlung bei Fehlschlägen der Entschlüsselung

Zugriffssteuerung

• Beschränken Sie den Zugriff auf Verschlüsselungsschlüssel nur auf autorisierte Personen Verwenden Sie eine rollenbasierte Zugriffssteuerung
• für die Verwaltung von Schlüsseloperationen Audit
• den Schlüsselverwendung und Zugriff regelmäßig Implementieren Sie
• ordnungsgemäße Sicherung und Wiederherstellungsverfahren Fehlersuche bei der Verschlüsselung

Implement proper backup and recovery procedures

Häufige Probleme

Fehler bei der Entschlüsselung:

• Überprüfen Sie, ob der private Schlüssel mit dem öffentlichen Schlüssel übereinstimmt, der für die Verschlüsselung verwendet wird
• Stellen Sie sicher, dass der ivSessionKey ist korrekt
• Stellen Sie sicher, dass Sie Encryption V2 (V1 wird nicht mehr unterstützt) verwenden

Schlüsselbezogene Fehler:

• Bestätigen Sie, dass die private Schlüsselformat korrekt ist (PEM-Format)
• Überprüfen Sie, ob der Schlüssel während der Speicherung/Übertragung nicht beschädigt wurde
• Stellen Sie sicher, dass der Schlüssel in Ihrer Anwendungs-Konfiguration die richtigen Berechtigungen hat

Performance issues:

• Größere Pakete können länger zum Verschlüsseln/Entschlüsseln benötigen
• Legen Sie bei großen Bundle-Größen Delta-Updates (Manifest) zur Reduzierung der Bundle-Größe an
• Überwachen Sie die Geräteleistung während der Entschlüsselung

Debug-Befehle

Überprüfen Sie den Verschlüsselungsstatus:

npx @capgo/cli@latest app debug

Testen Sie den Verschlüsselungs-/Entschlüsselungsworkflow:

# 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

Zuverlässigkeit und Standards

Capgo’s Verschlüsselungsimplementierung folgt Branchenstandards:

• AES-256: FIPS 140-2 genehmigte Verschlüsselungsalgorithmus
• RSA-4096: Starker asymmetrischer Verschlüsselungsalgorithmus für die Schutz von Schlüsseln
• GCM-Modus: Bietet sowohl Vertraulichkeit als auch Authentizität
• Sicherer Zufall: Kryptografisch sichere Zufallszahlengenerierung

Dies macht Capgo für Anwendungen geeignet, die die Einhaltung von Vorschriften erfordern:

• DSGVO (Datenschutzgrundverordnung)
• HIPAA (Gesetz über die Portabilität und Verantwortlichkeit von Gesundheitsversicherungen)
• SOC 2 (Service Organization Control 2)
• ISO 27001 (Informationssicherheitsmanagement)

Leistungsbetrachtungen

Verschlüsselungsüberhead

• Bundle-GrößeVerschlüsselte Pakete sind leicht größer (~1-2% Überhead)
• Verarbeitungszeit: Verschlüsselung/Entschlüsselung fügt minimalen Latenzverlust hinzu
• Speicherverbrauch: Temporäre Erhöhung während der Verschlüsselungs-/Entschlüsselungsoperationen

Optimierungstipps

• Verwenden Sie Delta (Manifest)-Updates, um den verschlüsselten Datenverkehr zu minimieren
• Optimieren Sie die Größe Ihres Bundles, indem Sie Bilder im WebP-Format umwandeln
• Minimieren Sie JavaScript- und CSS-Dateien, bevor Sie sie bündeln
• Entfernen Sie nicht benötigte Abhängigkeiten und code
• Überwachen Sie die Leistung Ihres Geräts auf älteren/Schnellereinheiten

Weitere Schritte

• Erfahren Sie mehr Benutzerdefinierte Speicherung um mit Ihrer eigenen Infrastruktur Verschlüsselung zu verwenden
• Entdecken Kanäle um verschlüsselte Pakete über Umgebungen zu verwalten
• Einrichten CI/CD-Integration um verschlüsselte Bereitstellungen zu automatisieren

Weitermachen von Verschlüsselung

Wenn Sie Verschlüsselung verwenden um Sicherheit und Compliance zu planen, verbinden Sie es mit Compliance für die Implementierungsdetails in Compliance, Capgo Sicherheits-Scanner für den Produktworkflow in Capgo Sicherheits-Scanner, Capgo Sicherheit für den Produktworkflow in Capgo Sicherheit, Capgo Trust Center für den Produktworkflow in Capgo Trust Center, und Organisations-Sicherheit für die Implementierungsdetails in Organisations-Sicherheit.