Verschlüsselung

Capgo bietet eine robuste Ende-zu-Ende-Verschlüsselung für Ihre App-Bundles, die sicherstellt, dass Ihr JavaScript code und Ihre Assets während der Übertragung und Speicherung geschützt sind. Dieses Verschlüsselungssystem ist so konzipiert, dass Sie die volle Kontrolle über die Sicherheit Ihrer App behalten, während die Lebendaktualisierungen bequem bleiben.

Übersicht

Capgo's Verschlüsselungssystem verwendet branchenstandardmäßige 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 die Verschlüsselung tatsächlich schützt: Im Gegensatz zu OTA-Systemen, die nur Updates signieren, verschlüsselt Capgo das hochgeladene Bundle vor dem Speichern und der Lieferung. Dies schützt die Bundle-Inhalte vor zufälligem Zugriff im Speicher oder in der Transit und stellt sicher, dass nur jemand mit Ihrem privaten Schlüssel ein gültig verschlüsseltes Update erstellen kann. Es macht keine

Wann 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 geliefertes JavaScript, HTML oder CSS nie inspiziert werden kann.

Gefährdungsmodell

Capgo-Verschlüsselung schützt vor der Offenlegung des Bundles durch Capgo, Speicheranbieter, CDNs oder Personen, die nur den verschlüsselten Lieferartefakt sehen. Sie verhindert auch, dass Dritte gültig verschlüsselte Updates ohne Ihren privaten Schlüssel erzeugen 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.

Tip

Die Verschlüsselung ist insbesondere wichtig für:

• Apps, die sensible Daten oder Geschäftslogik verarbeiten
• Unternehmen mit Compliance-Anforderungen
• Apps, die in regulierten Branchen eingesetzt werden
• 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: Erstellt und sicher gespeichert in Ihrem Entwicklungsumfeld (wird für die Verschlüsselung verwendet)
• Öffentlicher Schlüssel: Abgeleitet aus Ihrem privaten Schlüssel und gespeichert in der Capacitor-Konfiguration Ihres Apps (wird für die Entschlüsselung verwendet)
• Sitzungschlüssel: Zufällige AES-Schlüssel werden für jede Bundle-Upload-Operation generiert

2. Verschlüsselungsprozess

1. Für jeden Upload eines Pakets wird eine zufällige AES-Sitzungsschlüssel generiert
2. Ihr Paket wird mit dem AES-Sitzungsschlüssel verschlüsselt
3. Der Paket-Prüfsummenwert wird berechnet
4. Beide der AES-Sitzungsschlüssel und der Prüfsummenwert werden gemeinsam mit Ihrem RSA-Privatschlüssel verschlüsselt (wodurch der “Signatur” entsteht)
5. Das verschlüsselte Paket und die verschlüsselte Signatur werden gespeichert

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

3. Entschlüsselungsprozess

1. Ihre App lädt das verschlüsselte Paket und die verschlüsselte Signatur herunter
2. Der Capgo SDK verwendet Ihren RSA-öffentlichen Schlüssel (der im App gespeichert ist), um die Signatur zu entschlüsseln
3. Dies offenbart den AES-Sitzungsschlüssel und die ursprüngliche Prüfsumme
4. AES-Sitzungsschlüssel wird verwendet, um das Paket zu entschlüsseln
5. Eine Prüfsumme des entschlüsselten Pakets wird berechnet und mit der ursprünglichen Prüfsumme für eine Integritätsprüfung verglichen

Dieser Prozess stellt sicher, dass selbst wenn ein Angreifer das verschlüsselte Paket 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 Signaturwert zu erstellen, der von der öffentlichen Schlüssel entschlüsselt werden kann

Hinweis

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

Capgo vs. Andere Plattformen

Funktion	Capgo	__CAPGO_KEEP_0__
__CAPGO_KEEP_0__ vs. Andere OTA-Plattformen Plattformen	Verschlüsselt im Speicher/Übertragung; noch von einem entschlossenen Reverse-Engineer mit der App-Datei untersuchbar	Öffentlich lesbar
Sicherheitsmethode	Wahrer End-to-End-Verschlüsselung	Code-Signatur nur
Privatsphäresebene	Starker Lieferung/Speicher-Schutz; kein Anti-Reverse-Engineering	Die Plattform kann auf Ihr code zugreifen
Schutz	Inhalt + Integrität + Authentizität	Integrität + Authentizität nur

Weshalb das wichtig ist:

• Code Signierung __CAPGO_KEEP_0__ überprüft nur, dass Updates nicht manipuliert wurden und vom richtigen Quellcode stammen
• Capgo Verschlüsselung __CAPGO_KEEP_0__ Verschlüsselung schützt das Bundle während der Speicherung und Übermittlung und macht gefälschte verschlüsselte Updates viel schwieriger, da der Angreifer Ihre private Schlüssel benötigen würde
• Nach der Veröffentlichung des Apps ist eine Umkehrung noch immer möglich 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 (aktuelle Standard)

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

Verschlüsselung V1 (Veraltet)

• Wendet RSA-2048 für die Verschlüsselung von Schlüsseln an
• AES-256-CBC für die Verschlüsselung von Paketen
• Verfügbarkeit nicht mehr in der aktuellen CLI
• Legacy-Anwendungen, die V1 verwenden, müssen auf V2 migrieren

Warnung

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

Einstellung der Verschlüsselung

Schritt 1: Erstellung von Verschlüsselungsschlüsseln

Erstellt zunächst Ihre Verschlüsselungsschlüssel mithilfe der Capgo CLI:

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

Dies erzeugt:

• .capgo_key_v2: Ihr privater Schlüssel (halten Sie diesen sicher aufgehoben!)
• .capgo_key_v2.pub: Ihr öffentlicher Schlüssel (wird von Ihrer App verwendet)

Diese Dateien werden im aktuellen Verzeichnis erstellt, in dem Sie den Befehl ausführen.

Vorsicht

Wichtige Speichervorlagen:

• Privater Schlüssel (.capgo_key_v2): Kommitieren Sie 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 kommitieren, da es eine Sicherungskopie Ihres öffentlichen Schlüssels ist.
• Dateilocation: Schlüssel werden im aktuellen 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 Ihrem Capacitor-Konfiguration für die mobile App zu speichern.

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

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

Sie kontext: HTML-Textfragment aus einem längeren Capgo-UI-String (Elternschlüssel `you_definition`). Seite/Bereich: Capgo-Marketingwebsite. Rolle: Langer Marketing- oder Rechtsparagraph. Gesehen in: Seite Disclaimer.astro, Seite Rückkehr.astro. Nachrichtenschlüssel `you_definition` (Sie Definition). 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)

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

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

Vorsicht

Zu den erforderlichen Schritten:

1. Die key save der 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 verschlüsselte Updates nicht 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. Erstellen Sie ein Zip-Bundle:

   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 Ihrem Speicher (z.B. S3) und registrieren Sie es mit 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:

• Private Schlüssel in sicheren Schlüsselverwaltungsdiensten (AWS KMS, Azure Key Vault usw.) speichern
• Private Schlüssel mit CI/CD-Secret-Management verwenden
• Nie committieren Sie private Schlüssel in die Versionskontrolle

Zweck der Nutzung:

• Privater Schlüssel: Wird von CLI für die Verschlüsselung während der Bundle-Uploads verwendet (sicher aufbewahren)
• Öffentlicher Schlüssel: Wird in der Anwendungs-Konfiguration für die Entschlüsselung auf dem Gerät gespeichert (sicher zum Committen)

Rotieren Sie nach einem privatschlüsselbedingten Kompromiss

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

1. Erstellen Sie ein Ersatzschlüsselpaar:

   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. Übertragen und liefern Sie eine native Version aus: Laufen npx cap sync, dann verteilen Sie eine neue native App-Version, die den Ersatzöffentlichkeitsschlüssel enthält.

4. Zielte auf die neue 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 Zielsetzung für Versionen

5. 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. Ändern Sie Ihr Upload-Secret:

Achtung

Wenn der private Schlüssel kompromittiert ist, sollten Sie ihn sofort einstellen. 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.

Schutzmaßnahmen zur Sicherheit

Schlüsselsicherheit

• Private Schlüssel niemals teilen zwischen Umgebungen oder Teammitgliedern
• Verschiedene Schlüssel für verschiedene Umgebungen (Entwicklung, Staging, Produktion)
• Nach einem Kompromittierung rotieren: ersetzen Sie das Schlüsselpaar, wenn das private Schlüssel verdächtig oder bestätigt ist; eine regelmäßige Kalenderrotation ist nicht erforderlich
• Sicherheitsmaßnahmen für die Speicherung von Schlüsseln Verwenden Sie angemessene Systeme für die Schlüsselverwaltung

Bundle-Sicherheit

• Überprüfen Sie immer die Integrität des Bundles nach der Entschlüsselung
• Überwachen Sie unübliche Downloadmuster oder Fehler
• Verwenden Sie HTTPS für alle Bundle-URLs (erforderlich für mobile Apps)
• Implementieren Sie angemessene Fehlerbehandlung bei Fehlschlägen der Entschlüsselung

Zugriffssteuerung

• Zugriff einschränken Zugriff auf Verschlüsselungsschlüssel nur auf autorisierte Personen beschränken
• Benutzerrollenbasierte Zugriffssteuerung für die Verwaltung von Schlüsseloperationen verwenden
• Überprüfung regelmäßig die Verwendung und den Zugriff auf Schlüssel überprüfen
• Implementierung angemessene Sicherungskopien und Wiederherstellungsverfahren

Fehlersuche bei der Verschlüsselung

Häufige Probleme

Verschlüsselungsfehler:

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

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
• Überprüfen Sie, ob der Schlüssel in Ihrer App-Konfiguration die richtigen Berechtigungen hat

Leistungsausfälle:

• Große Pakete können länger zum Verschlüsseln/Entschlüsseln dauern
• Überlege dir, Delta-Updates (Manifest) zu verwenden, um die Paketgröße zu reduzieren
• Überwache die Leistung des Geräts während der Entschlüsselung

Debug-Befehle

Überprüfe den Verschlüsselungsstatus:

npx @capgo/cli@latest app debug

Teste 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üsselungsdurchführung folgt Branchenstandards:

• AES-256: FIPS 140-2 genehmigte Verschlüsselungsalgorithmus
• RSA-4096: Starke asymmetrische Verschlüsselung 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:

• DSGVO (Datenschutz-Grundverordnung)
• HIPAA (Gesetz über die Portabilität von Gesundheitsversicherungen und die Verantwortlichkeit für Gesundheitsdaten)
• SOC 2 (Service Organization Control 2)
• ISO 27001 (Informationssicherheitsmanagement)

Leistungskriterien

Verschlüsselungsüberhead

• Bundle-Größe: Verschlüsselte Bundle sind leicht größer (~1-2% Überhead)
• Verarbeitungszeit: Die Verschlüsselung/Entschlüsselung fügt nur minimalen Latenz auf
• 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 Geräteleistung auf älteren/Schnellereinheiten

Zukünftige Schritte

• Erhalten Sie Informationen über Benutzerdefinierte Speicherung um die Verschlüsselung mit Ihrer eigenen Infrastruktur zu verwenden
• Erkunden Kanäle Kontext: Capgo-Releasekanäle-Funktion. Seite/Bereich: Capgo-Lösungen-Marketingseite. Rolle: Kurzer UI-Label oder Navigationspunkt. Gesehen in: Seite Lösungen/White-Label.astro. Nachrichtenschlüssel `solutions_white_label_visual_cell2_value` (Solutions White Label Visual Cell2 Value).
• um verschlüsselte Pakete über Umgebungen zu verwalten Einrichten CI/CD-Integration

Kontext: Seite Capgo Builder / native Cloud-Build-Produktseite. Rolle: Kurzer UI-Label oder Navigationspunkt. Nachrichtenschlüssel `native_build_feature_ci_cd` (Native Build Feature Ci Cd).

Fortsetzen von Verschlüsselung Abschnitt mit dem Titel “Fortsetzen von Verschlüsselung” zur Sicherheits- und Compliance-Planung, 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 Unternehmenssicherheit für die Implementierungsdetails in Unternehmenssicherheit.