Saltare al contenuto

L'encryption

Capgo fornisce una robusta crittografia end-to-end per i pacchetti dell'applicazione, garantendo che il tuo JavaScript code e le tue risorse siano protetti durante la trasmissione e lo storage. Questo sistema di crittografia è progettato per darti il controllo completo sulla sicurezza dell'applicazione mentre mantieni la comodità delle aggiornamenti in tempo reale.

Capgo utilizza metodi crittografici di standard industriale per proteggere i pacchetti da accessi non autorizzati. Quando abilitata la crittografia, i pacchetti sono crittografati prima di lasciare l'ambiente di sviluppo e rimangono crittografati fino a quando non vengono decrittografati dall'applicazione sul dispositivo dell'utente.

Cosa la Crittografia Protegge Effettivamente: A differenza dei sistemi OTA che firmano solo gli aggiornamenti, Capgo crittografa il pacchetto caricato prima dello storage e della consegna. Ciò protegge i contenuti del pacchetto da accessi casuali in storage o in transito e assicura che solo qualcuno con la tua chiave privata possa produrre un aggiornamento crittografato valido. Ciò non rende impossibile per gli attacchi determinati: la chiave pubblica utilizzata dal client per decrittografare gli aggiornamenti è distribuita nell'app, quindi un attaccante determinato può ancora estrarla e esaminare i contenuti del pacchetto con sufficiente sforzo.

Capgo utilizza un approccio di crittografia ibrida che combina la crittografia RSA e AES per una sicurezza e prestazioni ottimali:

Flusso di crittografia di Capgo

  • Chiave privata: Generata e memorizzata in modo sicuro nel tuo ambiente di sviluppo (utilizzata per la crittografia)
  • Chiave pubblica: Derivata dalla tua chiave privata e memorizzata nella configurazione del tuo app Capacitor (utilizzata per la decrittografia)
  • Chiavi di sessione: Chiavi AES casuali generate per ogni caricamento di bundle
  1. Viene generato un chiave di sessione AES casuale per ogni caricamento di bundle
  2. La vostra bundle viene crittografata utilizzando la chiave di sessione AES
  3. Viene calcolato il checksum del bundle
  4. Entrambe la chiave di sessione AES e il checksum vengono crittografati insieme utilizzando la vostra chiave privata RSA (creando la “firma”)
  5. Viene memorizzato il bundle crittografato e la firma crittografata

Il checksum viene crittografato insieme alla chiave AES per prevenire la manipolazione. Poiché solo la vostra chiave privata RSA può creare questa firma, e solo la chiave pubblica corrispondente può decrittificarla, ciò garantisce che sia la chiave di sessione AES e il checksum previsto siano autentici e non siano stati modificati da un attaccante.

  1. La vostra app scarica il bundle crittografato e la firma crittografata
  2. La Capgo SDK utilizza la vostra chiave pubblica RSA (memorizzata nell'app) per decrittografare la firma
  3. Questa rivela la chiave di sessione AES e il checksum originale
  4. La chiave di sessione AES viene utilizzata per decrittare il pacchetto
  5. Si calcola e si confronta un checksum del pacchetto decrittato con il checksum originale per la verifica dell'integrità

Questo processo garantisce che anche se un attaccante intercetta il pacchetto crittografato, non può modificare la chiave di sessione AES o fornire un checksum falso, perché dovrebbe avere la tua chiave privata per creare una firma valida che la chiave pubblica può decrittare

CaratteristicaCapgoAltre Piattaforme OTA
Contenuto del PacchettoCriptato in archiviazione/trasito; ancora esaminabile da un ingegnere di reverse engineering determinato con il file binario dell'appPubblicamente leggibile
Metodo di SicurezzaVerifica crittografia end-to-endCode firma solo
Livello di PrivacyProtezione forte di consegna/archiviazione; non antiriciclaggioLa piattaforma può accedere al tuo code
ProtezioneContenuto + integrità + autenticitàIntegrità + autenticità solo

Perché Questo è Importante:

  • Code firma verifica solo che gli aggiornamenti non siano stati alterati e provengano dalla fonte giusta
  • Capgo crittografia proteggono il bundle mentre è archiviato e distribuito e rendono molto più difficile la creazione di aggiornamenti criptati falsificati perché l'attaccante avrebbe bisogno della tua chiave privata
  • L'ingegneria inversa è ancora possibile dopo che l'app è stata rilasciata, perché il client contiene la chiave pubblica necessaria per decrittare e caricare l'aggiornamento

Capgo utilizza la crittografia V2 come metodo di crittografia standard:

  • Utilizza RSA-4096 per una maggiore sicurezza
  • AES-256-GCM per crittografia autenticata
  • Fornisce la verifica dell'integrità
  • Miglior prestazioni e sicurezza
  • Utilizza RSA-2048 per la crittografia delle chiavi
  • AES-256-CBC per la crittografia dei pacchetti
  • Non più disponibile nella versione corrente CLI
  • Gli app legacy che utilizzano V1 devono migrare a V2

Prima di tutto, genera le tue chiavi di crittografia utilizzando il Capgo CLI:

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

Questo crea:

  • .capgo_key_v2: La tua chiave privata (tienila sicura!)
  • .capgo_key_v2.pub: La tua chiave pubblica (utilizzata dal tuo app)

Questi file vengono creati nella directory corrente in cui esegui il comando.

Passo 2: Salva la tua chiave pubblica nel Capacitor Config (Obbligatorio)

Sottosezione intitolata “Passo 2: Salva la tua chiave pubblica nel Capacitor Config (Obbligatorio)”

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

salvare la sua chiave pubblica nel __CAPGO_KEEP_0__ config affinché l'app mobile possa decrittare i pacchetti:
# 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)

Passo 3: Sincronizza la piattaforma Capacitor (Obbligatorio)

Dopo aver salvato la chiave pubblica, tu devi sync il piattaforma Capacitor per copiare la configurazione aggiornata al layer nativo:

Finestra del terminale
# Sync the platform to copy config to native
npx cap sync

La soluzione più semplice è criptare durante il processo di upload:

Fermata del terminale
# Upload with automatic encryption
npx @capgo/cli@latest bundle upload --key-v2
# For external storage, you must encrypt first (see Manual Encryption Workflow below)

Per avere più controllo, puoi criptare manualmente i pacchetti:

  1. Creare un pacchetto zip:

    Fermata del terminale
    npx @capgo/cli@latest bundle zip com.example.app --path ./dist --key-v2
  2. Crittografa il bundle:

    Finestra del terminale
    npx @capgo/cli@latest bundle encrypt ./com.example.app.zip CHECKSUM_FROM_STEP_1
  3. Carica sul tuo storage (ad esempio, S3) e registra con Capgo:

    Finestra del terminale
    # 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

Opzioni per la chiave privata:

  1. File-based (sviluppo locale):

    Fenestra della finestra di comando
    # Key stored as .capgo_key_v2 file in project root
    npx @capgo/cli@latest bundle upload --key-v2
  2. Variabile di ambiente (CI/CD):

    Fenestra della finestra di comando
    # 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"

Configurazione della chiave pubblica (obbligatoria):

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

Ambiente di produzione:

  • Conserva le chiavi private nei servizi di gestione delle chiavi sicure (AWS KMS, Azure Key Vault, ecc.)
  • Utilizza la gestione dei segreti CI/CD per le chiavi private
  • Non commettere mai le chiavi private nel controllo delle versioni

Utilizzo della chiave:

  • Chiave privata: Utilizzata da CLI per l'encryption durante l'upload del pacchetto (mantenere sicuro)
  • Chiave pubblica: Memorizzata nella configurazione dell'applicazione per la decrittazione sul dispositivo (sicuro da commettere)

Rotare il coppia di chiavi quando la chiave privata è sospettata o confermata compromessa. Non è richiesta una rotazione calendario regolare. Si tratta di una migrazione della chiave nativa, non di un cambiamento OTA solo.

  1. Generare una nuova coppia di chiavi:

    Fenestra del terminale
    npx @capgo/cli@latest key create
  2. Salva la chiave pubblica di sostituzione nel tuo Capacitor config:

    Finestra del terminale
    npx @capgo/cli@latest key save --key ./.capgo_key_v2.pub
  3. Sincronizza e distribuisci una versione nativa: Esegui npx cap sync, quindi distribuisci una nuova versione di app nativa contenente la chiave pubblica di sostituzione.

  4. Seleziona la nuova versione nativa: I dispositivi che ancora eseguono la versione binaria nativa vecchia non possono decrittare gli aggiornamenti crittografati con la chiave di sostituzione. Utilizza Targeting della versione context: Pagina/Area: Pagina di marketing delle soluzioni Capgo. Ruolo: Intestazione di sezione o pagina. Visto in: pagina soluzioni/target-versione.astro. Chiave di messaggio `solutions_version_targeting_title` (Titolo del targeting della versione delle soluzioni). | Pagina/Area: Pagina di marketing delle soluzioni Capgo. Ruolo: Etichetta breve UI o elemento di navigazione. Visto in: pagina soluzioni/target-versione.astro. Chiave di messaggio `solutions_version_targeting` (Targeting della versione delle soluzioni).

  5. Per limitare i pacchetti di sostituzione alla nuova versione nativa mentre il resto della flotta si aggiorna attraverso la store o MDM. Passa al tuo segreto di caricamento:

  • Non condividere mai le chiavi private tra ambienti o membri del team
  • Utilizzare chiavi diverse per ambienti diversi (dev, staging, production)
  • Rimuovere dopo un compromessoRipristina la coppia di chiavi quando la chiave privata è sospettata o confermata compromessa; non è richiesta una routine di rotazione del calendario
  • Conserva le chiavi in modo sicuro utilizzando sistemi di gestione delle chiavi appropriati
  • Verifica sempre l'integrità del bundle dopo la decrittografia
  • Monitora per i pattern di download insoliti o le fallite
  • Utilizza HTTPS per tutte le URL del bundle (richiesto per le app mobili)
  • Esegui gestione degli errori corretta per le fallite di decrittazione
  • Limitare l'accesso ai chiavi di crittografia solo ai personale autorizzato
  • Utilizzare il controllo dei ruoli per le operazioni di gestione delle chiavi
  • Audit l'uso e l'accesso delle chiavi regolarmente
  • Implementare procedure di backup e ripristino corrette

Fallimenti di decrittazione:

  • Verifica che la chiave privata corrisponda alla chiave pubblica utilizzata per la crittografia
  • Controlla che il ivSessionKey è corretto
  • Assicurati di utilizzare la crittografia V2 (V1 non è più supportata)

Errori legati alla chiave:

  • Conferma che il formato della chiave privata è corretto (formato PEM)
  • Verifica che la chiave non sia stata corrotta durante lo storage o la trasferimento
  • Controlla che la chiave abbia le autorizzazioni corrette nella configurazione dell'app

Problemi di prestazioni:

  • I pacchetti grandi possono richiedere più tempo per l'encryptazione/decrittazione
  • Considera l'utilizzo delle aggiornamenti Delta (manifesto) per ridurre le dimensioni dei pacchetti
  • Monitorare le prestazioni del dispositivo durante la decrittazione

Controlla lo stato di crittografia:

Fenestra del terminale
npx @capgo/cli@latest app debug

Testa il flusso di crittografia/decrittazione:

Fenestra del terminale
# 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

La implementazione di Capgo di crittografia segue gli standard dell'industria:

  • AES-256: Algoritmo di crittografia approvato da FIPS 140-2
  • RSA-4096: Crittografia asimmetrica forte per la protezione delle chiavi
  • Modalità GCM: Fornisce sia la confidenzialità che l'autenticità
  • Casuale Sicuro: Generazione di numeri casuali criptograficamente sicuri

Ciò rende Capgo adatto per le applicazioni che richiedono la conformità con:

  • Regolamento generale sulla protezione dei dati (GDPR)
  • Legge sulla portabilità e sulla responsabilità assicurativa per la salute (HIPAA)
  • Controllo SOC 2 (Service Organization Control 2)
  • ISO 27001 (Gestione della sicurezza delle informazioni)
  • Dimensione del pacchetto: I pacchetti crittografati sono leggermente più grandi (~1-2% di sovraccarico)
  • Tempo di elaborazione: La crittografia/decriptazione aggiunge una latenza minima
  • Utilizzo della memoria: Aumento temporaneo durante le operazioni di cifratura/decifratura
  • Utilizza gli aggiornamenti Delta (manifesto) per ridurre il trasferimento di dati cifrati
  • Optimizza il tuo bundle di dimensioni convertendo le immagini in formato WebP
  • Minimizza i file JavaScript e CSS prima di compilarli
  • Elimina le dipendenze non utilizzate e code
  • Monitora le prestazioni del dispositivo su dispositivi più vecchi/lenti
  • Scopri Storage personalizzato per utilizzare l'encryption con la tua infrastruttura
  • Esplora Canali context: Canali di rilascio Capgo. Pagina/Area: Pagina di marketing delle soluzioni Capgo. Ruolo: Etichetta UI breve o elemento di navigazione. Visto in: pagina soluzioni/white-label.astro. Chiave di messaggio `solutions_white_label_visual_cell2_value` (Valore cella visiva White Label Solutions).
  • per gestire i pacchetti crittografati all'interno di ambienti diversi Configura Integrazione CI/CD

context: Pagina/Area: Pagina del prodotto Capgo Builder / prodotto di costruzione nativa cloud. Ruolo: Etichetta UI breve o elemento di navigazione. Chiave di messaggio `native_build_feature_ci_cd` (Funzione di costruzione nativa Ci Cd).

per automatizzare i deployment crittografati

Continua da qui dall'Encryption Sottosezione intitolata “Continua da qui dall'Encryption” (Keep going from Encryption). per pianificare la sicurezza e la conformità, connettilo con Conformità per i dettagli di implementazione in Conformità Capgo Scanner di Sicurezza per il flusso di lavoro del prodotto in Capgo Scanner di Sicurezza Capgo Sicurezza per il flusso di lavoro del prodotto in Capgo Sicurezza Capgo Centro di fiducia per il flusso di lavoro del prodotto in Capgo Centro di fiducia, e Sicurezza dell'Organizzazione per i dettagli di implementazione in Sicurezza dell'Organizzazione.