Cifratura

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

Panoramica

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

Cosa protegge la crittografia: 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 chiave privata possa produrre un aggiornamento crittografato valido. Non rende gli asset web spediti impossibili da reverse engineering: la chiave pubblica utilizzata dal client per decrittografare gli aggiornamenti è distribuita nell'applicazione, quindi un attaccante determinato può ancora estrarla e ispezionare i contenuti del pacchetto con sufficiente impegno. Quando hai bisogno della crittografia Quando hai bisogno della crittografia

Quando hai bisogno della crittografia

If si carica un bundle senza crittografia, trattalo come un asset pubblico. I canali privati limitano quali dispositivi ricevono un aggiornamento, ma non rendono il bundle caricato confidenziale. La crittografia è utile quando si desidera una protezione migliore in archiviazione e trasporto e quando si desidera che solo i detentori della chiave privata possano pubblicare aggiornamenti crittografati validi. Ciò non garantisce che il JavaScript, l'HTML o il CSS spedito possa mai essere ispezionato.

Modello di minaccia

Capgo crittografia protegge contro la divulgazione del bundle da Capgo, fornitori di archiviazione, CDN o chiunque veda solo l'artefatto di consegna crittografato. Inoltre, impedisce a terzi di generare aggiornamenti crittografati validi senza la tua chiave privata. Poiché la chiave pubblica è incorporata nell'applicazione distribuita, in modo che il client possa decrittare gli aggiornamenti, qualcuno che ha il binario dell'app e abbastanza motivazione può ancora recuperare il materiale di chiave necessario per ispezionare il bundle.

Suggerimento

La crittografia è particolarmente importante per:

• Applicazioni che gestiscono dati sensibili o logica di business
• Applicazioni aziendali con requisiti di conformità
• Applicazioni distribuite in settori regolamentati
• Organizzazioni con politiche di sicurezza rigorose

Come funziona la crittografia

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

1. Generazione della Chiave

• 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 dell'app Capacitor (utilizzata per la decrittografia)
• Chiavi di Sessione: Chiavi AES casuali generate per ogni caricamento di bundle

2. Processo di Crittografia

1. Una chiave AES casuale viene generata per ogni caricamento di bundle
2. Il tuo bundle viene crittografato utilizzando la chiave AES di sessione
3. Si calcola il checksum del bundle
4. Entrambe la chiave AES di sessione e il checksum vengono crittografate insieme utilizzando la tua chiave privata RSA (creando la “firma”)
5. Il bundle crittografato e la firma crittografata vengono memorizzati

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

3. Processo di decrittografia

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

Questo processo assicura che anche se un attaccante intercetta il pacchetto crittato, 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.

Consiglio

L'RSA non può crittare grandi quantità di dati in modo efficiente, quindi l'AES viene utilizzato per la crittografia effettiva del pacchetto mentre l'RSA si occupa della chiave AES e della verifica dell'integrità attraverso la firma del checksum.

Capgo vs Altre Piattaforme

Caratteristica	Capgo	Altre piattaforme OTA
Contenuto del pacchetto	Criptato in archiviazione/trasito; ancora esaminabile da un determinato ingegnere di reverse engineering con il binario dell'applicazione	Pubblicamente leggibile
Metodo di Sicurezza	Verifica crittografica end-to-end	Code firma solo
Livello di Privacy	Protezione forte di consegna/archiviazione; non antiricorsione	La piattaforma può accedere al tuo code
Protezione	Contenuto + integrità + autenticità	Integrità + autenticità solo

Perché Questo Importa:

• Code firma verifica solo che gli aggiornamenti non siano stati alterati e provengano dalla fonte giusta
• Capgo crittografia proteggono il bundle durante la sua memorizzazione e consegna 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

Metodi di crittografia

Capgo utilizza la crittografia V2 come metodo di crittografia standard:

Crittografia V2 (Metodo standard corrente)

• Utilizza RSA-4096 per una maggiore sicurezza
• AES-256-GCM per crittografia autenticata
• Fornisce verifica dell'integrità
• Miglior prestazioni e sicurezza

Crittografia V1 (Deprecato)

• Utilizza RSA-2048 per crittografia delle chiavi
• AES-256-CBC per crittografia dei pacchetti
• Non più disponibile nella versione corrente CLI
• App legacy che utilizzano V1 devono migrare a V2

Pericolo

La crittografia V1 non è più supportata nella versione corrente Capgo CLI. Se stai utilizzando la crittografia V1, devi migrare a V2. Vedi il Guida di migrazione Per istruzioni dettagliate.

Configurazione della crittografia

Passo 1: Genera le chiavi di crittografia

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

# 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 dove si esegue il comando.

Attenzione

Nota importante sullo storage:

• Chiave privata (.capgo_key_v2): Mai commettere questo alla versione di controllo. Questo file dovrebbe essere mantenuto sicuro e utilizzato solo per la crittografia durante gli upload dei pacchetti.
• Chiave pubblica (.capgo_key_v2.pub): Questo è sicuro da commettere alla versione di controllo poiché è un backup della tua chiave pubblica.
• Posizione del file: Le chiavi vengono create nella directory corrente dove si esegue il key create comando.
• Chiave pubblica nella configurazione: Deve eseguire key save per memorizzare la chiave pubblica nel suo Capacitor config affinché l'app mobile possa utilizzarla.

Per l'uso di produzione, memorizza la chiave privata in modo sicuro (variabili di ambiente, servizi di gestione delle chiavi) e rimuovila dal tuo progetto locale dopo la configurazione.

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

Tu devi salvare la tua chiave pubblica nel Capacitor 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"

Passo 3: Sincronizza la Capacitor Piattaforma (Obbligatorio)

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

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

Avvertenza

Passaggi obbligatori:

1. Il key save comando memorizza la chiave pubblica nella tua configurazione Capacitor
2. npx cap sync copia questa configurazione al layer nativo dove l'app mobile può accedervi
3. Senza entrambi i passaggi, la tua app non riuscirà a decrittografare gli aggiornamenti crittografati

Criptazione dei Pacchetti

Metodo 1: Criptazione Durante l'Upload

La soluzione più semplice consiste nell'effettuare la criptazione durante il processo di 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)

Metodo 2: Flusso di Lavoro di Criptazione Manuale

Per avere il controllo totale, puoi manualmente criptare i pacchetti:

1. Creare un pacchetto zip:

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

2. Crittografa il bundle:

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

3. Carica nel tuo storage (ad esempio, S3) e registra con 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

Gestione delle chiavi

Archiviazione delle chiavi in modo sicuro

Opzioni per la chiave privata:

1. File-based (local development):

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

2. Variabile di ambiente (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"

Configurazione della chiave pubblica (Richiesta):

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

Ambiente di produzione:

• Memorizza 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 la crittografia durante l'upload del pacchetto (tenere al sicuro)
• Chiave pubblica: Memorizzata nella configurazione dell'applicazione per la decrittografia sul dispositivo (sicuro da committere)

Rotazione delle chiavi

Rotare regolarmente le tue chiavi di crittografia per una maggiore sicurezza:

1. Genera nuove chiavi:

   # Navigate to desired directory first, then create keys
   mkdir ./new-keys && cd ./new-keys
   npx @capgo/cli@latest key create

2. Salva la nuova chiave pubblica nel Capacitor config:

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

3. Aggiorna la configurazione dell'applicazione con la nuova chiave pubblica

4. Distribuisci l'applicazione aggiornata prima di caricare i bundle crittografati con la nuova chiave

Pratiche di Sicurezza

Sicurezza della Chiave

• Non condividere mai le chiavi private tra ambienti o membri del team
• Usa chiavi diverse per ambienti diversi (dev, staging, production)
• Rimuovi le chiavi regolarmente (consigliato: ogni 6-12 mesi)
• Mantieni le chiavi al sicuro utilizzando sistemi di gestione delle chiavi appropriati

Capgo Security

• Verifica sempre l'integrità del pacchetto dopo la decrittografia
• Monitora per patterni di download insoliti o fallimenti
• Usa HTTPS per tutte le URL delle bundle (richiesto per le app mobili)
• Implementa gestione degli errori appropriata per i fallimenti di decrittazione

Controllo degli accessi

• Limita l'accesso ai chiavi di crittografia solo a personale autorizzato
• Usa l'accesso basato su ruoli per le operazioni di gestione delle chiavi
• Audit accesso e gestione regolare delle chiavi
• Implementa procedimenti di backup e ripristino adeguati

Risolvere la crittografia

Issue comuni

Fallimenti di decrittografia:

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

Errori legati alle chiavi:

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

Issue 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
• Monitora le prestazioni del dispositivo durante la decrittazione

Comandi di debug

Controlla lo stato di crittografia:

npx @capgo/cli@latest app debug

Testa il flusso di cifratura/decifratura:

# 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à e Standard

Capgo’s implementazione di cifratura segue gli standard dell'industria:

• AES-256: Algoritmo di cifratura asimmetrico FIPS 140-2 approvato
• RSA-4096: Cifratura asimmetrica forte per la protezione delle chiavi
• Modalità GCM: Fornisce sia la riservatezza che l'autenticità
• Secure Random: Generazione di numeri casuali criptograficamente sicuri

This makes Capgo suitable for applications requiring compliance with:

• GDPR (Regolamento generale sulla protezione dei dati)
• HIPAA (Legge sulla portabilità e sulla responsabilità assicurativa per la salute)
• SOC 2 (Controllo di servizio organizzativo 2)
• ISO 27001 (Gestione della sicurezza dell'informazione)

Considerazioni di prestazioni

Onere di crittografia

• Dimensione pacchetto: I pacchetti crittati sono leggermente più grandi (~1-2% di sovraccarico)
• Tempo di elaborazione: L'aggiunta di crittografia/decrittografia comporta una latenza minima
• Utilizzo della memoria: Aumento temporaneo durante le operazioni di crittografia/decrittografia

Consigli di ottimizzazione

• Utilizza gli aggiornamenti Delta (manifesto) per minimizzare il trasferimento di dati crittati
• Ottimizza la dimensione del tuo pacchetto convertendo le immagini in formato WebP
• Minimizza i file JavaScript e CSS prima di creare il pacchetto
• Elimina le dipendenze non utilizzate e code
• Monitorare le prestazioni del dispositivo su dispositivi più vecchi/lenti

Passaggi successivi

• Scopri Storage personalizzato per utilizzare la crittografia con la propria infrastruttura
• Esplora Canali per gestire i bundle crittografati all'interno di ambienti diversi
• Configura Integrazione CI/CD per automatizzare i deployment crittografati

Continua da Criptazione

Se stai utilizzando Criptazione per pianificare la sicurezza e la conformità, connettilo con Conformità per i dettagli di implementazione in Conformità, Capgo Scansionatore di Sicurezza per il flusso di lavoro del prodotto in Capgo Scansionatore di Sicurezza, Capgo Sicurezza per il flusso di lavoro del prodotto in Capgo Sicurezza, Capgo Centro di Trust per il flusso di lavoro del prodotto nel Capgo Centro Trust, e Sicurezza dell'organizzazione per i dettagli di implementazione nella Sicurezza dell'organizzazione.