Crittografia

Capgo fornisce una robusta crittografia end-to-end per i pacchetti dell'applicazione, garantendo che il suo JavaScript code e gli asset 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 dall'accesso non autorizzato. Quando la crittografia è abilitata, 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 dall'accesso casuale in storage o in transito e assicura che solo qualcuno con la sua chiave privata possa produrre un aggiornamento crittografato valido. Non fa not rendono impossibile agli asset web distribuiti essere sottoposti a reverse engineering: la chiave pubblica utilizzata dal client per decrittare gli aggiornamenti è distribuita nell'app, quindi un determinato attaccante può ancora estrarla e ispezionare i contenuti del pacchetto con sufficiente sforzo.

Quando Hai Bisogno di Crittografia

Se carichi un pacchetto senza crittografia, trattalo come un asset pubblico. I canali privati limitano quali dispositivi ricevono un aggiornamento, ma non rendono il pacchetto 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. Non garantisce che i JavaScript, HTML o CSS distribuiti possano mai essere ispezionati.

Modello di Minaccia

Capgo crittografia protegge contro la divulgazione del pacchetto Capgo, fornitori di archiviazione, CDN o chiunque veda solo l'artefatto di consegna crittografato. Inoltre, impedisce ai terzi di generare aggiornamenti crittografati validi senza la tua chiave privata. Poiché la chiave pubblica è incorporata nell'app distribuita, il client può decrittare gli aggiornamenti, quindi qualcuno che ha il binario dell'app e sufficiente motivazione può ancora recuperare i materiali di chiave necessari per ispezionare il pacchetto.

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 archiviata in modo sicuro nel tuo ambiente di sviluppo (utilizzata per la crittografia)
• Chiave Pubblica: Derivata dalla tua chiave privata e archiviata nel tuo file di configurazione Capacitor dell'app (utilizzata per la decrittografia)
• Session Keys: Chiavi AES casuali generate per ogni caricamento di bundle

2. Processo di crittografia

1. Viene generata una chiave AES casuale per ogni caricamento di bundle
2. Il vostro bundle viene crittografato utilizzando la chiave AES
3. Si calcola il checksum del bundle
4. Entrambe la chiave AES e il checksum vengono crittografate insieme utilizzando la vostra chiave privata RSA (creando la “firma”)
5. L' bundle crittografato e la firma crittografata vengono archiviati

Si crittografa il checksum 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ò decrittolarla, ciò garantisce che sia la chiave AES e il checksum attesi 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. La Capgo SDK utilizza la tua chiave pubblica RSA (archiviata nell'app) per decrittografare la firma
3. Questo rivela la chiave di sessione AES e il checksum originale
4. La chiave di sessione AES viene utilizzata per decrittografare il bundle
5. Si calcola un checksum del bundle decrittografato e si confronta con il checksum originale per la verifica dell'integrità

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

Consiglio

RSA non può crittografare grandi quantità di dati in modo efficiente, quindi AES viene utilizzato per la crittografia effettiva del bundle mentre RSA protegge la chiave AES e fornisce la verifica dell'integrità attraverso la firma del checksum

Capgo vs Altre Piattaforme

Caratteristica	Capgo	Altre piattaforme OTA
Contenuto in bundle	Criptato in archiviazione/trasito; tuttavia, un determinato ingegnere di reverse engineering può ancora esaminarlo con il binario dell'applicazione	Leggibile dal pubblico
Metodo di sicurezza	Criptazione end-to-end vera e propria	Code firma solo
Livello di privacy	Protezione forte di consegna/archiviazione; non antiriciclaggio	La piattaforma può accedere al tuo code
Protezione	Integrità + autenticità + autenticazione	Integrità + autenticità solo

Perché Questo Importa:

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

Metodi di Crittografia

Capgo utilizza Crittografia V2 come metodo di crittografia standard:

Crittografia V2 (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 la crittografia delle chiavi
• AES-256-CBC per la crittografia dei pacchetti
• Non più disponibile nella versione corrente CLI
• Le app legacy che utilizzano V1 devono migrare a V2

Pericolo

La versione 1 dell'encryption non è più supportata nel corrente Capgo CLI. Se stai utilizzando l'encryption V1, devi migrare alla versione 2. Vedi il guida di migrazione per istruzioni dettagliate.

Configurazione dell'Encryption

Passo 1: Genera le chiavi di encryption

In primo luogo, genera le tue chiavi di encryption 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 dall'applicazione)

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

Attenzione

Note importanti di archiviazione:

• Chiave Privata (.capgo_key_v2): Mai commettere questo alla versione di controllo. Questo file dovrebbe essere tenuto sicuro e utilizzato solo per la crittografia durante gli upload del pacchetto.
• 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 esegui il key create command.
• Chiave Pubblica in Config: Devi eseguire key save per memorizzare la chiave pubblica nel tuo 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 aver configurato.

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 piattaforma Capacitor (Obbligatorio)

Dopo aver salvato la chiave pubblica, devi sincronizzare la piattaforma __CAPGO_KEEP_0__ per copiare la configurazione aggiornata al layer nativo: sync the Capacitor platform to copy the updated config to the native layer:

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

Passaggi Obbligatori

I:

1. I passaggi obbligatori key save Il comando memorizza la chiave pubblica nel tuo Capacitor config
2. npx cap sync copia questo config al layer nativo dove l'app mobile può accedervi
3. Senza entrambi i passaggi, la tua app non sarà in grado di decrittografare gli aggiornamenti crittografati

Crittografia dei Bundles

Metodo 1: Crittografia durante l'upload

La soluzione più semplice è crittografare 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 crittografia manuale

Per un controllo maggiore, puoi criptare manualmente i bundle:

1. Crea un bundle zip:

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

2. Cripta il bundle:

   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:

   # 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. Basata su file (sviluppo locale):

   # 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 (obbligatoria):

# 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 in servizi di gestione delle chiavi sicure (AWS KMS, Azure Key Vault, ecc.)
• Utilizza la gestione dei segreti per CI/CD per le chiavi private
• Non commettere mai le chiavi private nel controllo delle versioni

Utilizzo delle Chiavi:

• Chiave Privata: Utilizzata da CLI per la crittografia durante l'upload del pacchetto (tieni sicuro)
• Chiave Pubblica: Archiviata nella configurazione dell'applicazione per la decrittografia sul dispositivo (sicuro da commettere)

Rotazione delle Chiavi

Rotazione regolare delle 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 pacchetti crittografati con la nuova chiave

Pratiche di Sicurezza

Key Security

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

Bundle Security

• Verifica sempre l'integrità del bundle dopo la decrittazione
• Monitora gli schemi di download insoliti o le fallite
• Usa HTTPS per tutte le URL dei bundle (richiesto per gli app mobili)
• Implementa il trattamento degli errori appropriato per le fallite di decrittazione

Controllo degli accessi

• Limita l'accesso ai chiavi di crittografia solo ai personale autorizzato
• Usa l'accesso basato su ruoli per le operazioni di gestione delle chiavi
• Audit verifica regolarmente l'utilizzo e l'accesso alle chiavi
• Implementa procedure di backup e ripristino corrette

Risoluzione dei problemi di crittografia

Problemi comuni

Fallimenti di decrittazione:

• 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 relativi alla chiave:

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

Problemi di prestazioni:

• Le grandi raccolte possono richiedere più tempo per la crittografia/decriptazione
• Considera l'utilizzo delle aggiornamenti Delta (manifesto) per ridurre le dimensioni delle raccolte
• Monitora le prestazioni del dispositivo durante la decriptazione

Comandi di debug

Verifica lo stato di crittografia:

npx @capgo/cli@latest app debug

Testa il flusso di crittografia/decrittografia:

# 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

Norme e Standard di conformità

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

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

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

• 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

Sovrappeso di crittografia

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

Suggerimenti di ottimizzazione

• Utilizza aggiornamenti Delta (manifesto) per minimizzare il trasferimento di dati crittografati
• Optimizza il tuo bundle di dimensioni convertendo le immagini in formato WebP
• Minimizza i file JavaScript e CSS prima di procedere alla confezione
• Elimina le dipendenze non utilizzate e code
• Monitorare le prestazioni del dispositivo su dispositivi più vecchi/lenti

Passaggi successivi

• Impara su Storage personalizzato per utilizzare la crittografia con la tua infrastruttura
• Esplora Canali per gestire i bundle crittografati all'interno di ambienti diversi
• Imposta 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 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 la dettagliata implementazione in Sicurezza dell'organizzazione.