Crittografia

Capgo garantisce una crittografia a prova di fine per i pacchetti del tuo'applicazione, assicurandoti 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 del tuo'applicazione, mantenendo comunque la comodità delle aggiornamenti in tempo reale.

Panoramica

Capgo’s encryption system uses industry-standard cryptographic methods to protect your bundles from unauthorized access. When encryption is enabled, your bundles are encrypted before leaving your development environment and remain encrypted until they’re decrypted by your app on the user’s device.

A differenza dei sistemi di aggiornamento in tempo reale che firmano solo gli aggiornamenti, __CAPGO_KEEP_0__ 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. Non rende i beni web spediti impossibili da reverse ingegnerizzare: 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 sforzo.: Unlike OTA systems that only sign updates, Capgo encrypts the uploaded bundle before storage and delivery. This protects the bundle contents from casual access in storage or transit and ensures only someone with your private key can produce a valid encrypted update. It does Quando Hai Bisogno della Crittografia __CAPGO_KEEP_0__

Panoramica

Se caricate un bundle senza crittografia, trattatelo come un asset pubblico. I canali privati limitano i dispositivi che 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. Non garantisce che il JavaScript, l'HTML o il CSS consegnato 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 decrittografare gli aggiornamenti, qualcuno che ha il binario dell'app e abbastanza motivazione può ancora recuperare i materiali di chiave necessari 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 del tuo 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 di sessione AES casuale viene generata per ogni caricamento di bundle
2. Il tuo bundle viene crittografato utilizzando la chiave di sessione AES
3. Vengono calcolati il checksum del bundle
4. Entrambe la chiave di sessione AES e il checksum vengono crittografate insieme utilizzando la tua chiave privata RSA (creando la “firma”)
5. L'invio crittografato del bundle e la firma crittografata vengono archiviati

Vengono crittografati il checksum e la chiave AES per prevenire eventuali modifiche. Poiché solo la tua chiave privata RSA può creare questa firma e solo la chiave pubblica corrispondente può decrittificarla, ciò garantisce che sia la chiave di sessione AES che il checksum atteso 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. L'Capgo SDK utilizza la tua chiave pubblica RSA (archiviata 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 decrittografare il pacchetto
5. Si calcola un checksum del pacchetto decrittografato e si confronta 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ò decrittografare.

Suggerimento

RSA non può crittografare grandi quantità di dati in modo efficiente, quindi si utilizza AES per la crittografia effettiva del pacchetto 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 del Pacchetto	Crittografato in archiviazione/trasito; ancora esaminabile da un determinato ingegnere di reverse engineering con il binario dell'applicazione	Leggibile dal pubblico
Metodo di Sicurezza	Crittografia a fine-utente vera e propria	Code firma solo
Livello di Privacy	Protezione forte di consegna/archiviazione; non antiricompilazione	La piattaforma può accedere al tuo code
Protezione	Contenuto + 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
• La reverse engineering è 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 attuale)

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

Crittografia V1 (Deprecated)

• 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

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 ulteriori istruzioni.

Impostazione della crittografia

Passo 1: Genera chiavi di crittografia

In primo luogo, 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

Ciò 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): Non commettere mai questo file in controllo di versione. 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 in controllo di versione poiché è un backup della tua chiave pubblica.
• Posizione del file: Le chiavi vengono create nella directory corrente dove si esegue il comando. key create Chiave pubblica nella configurazione
• __CAPGO_KEEP_0__: Deve essere eseguito 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 la configurazione.

Passo 2: Salva la 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 sincronizzare il Capacitor piattaforma per copiare la configurazione aggiornata al layer nativo:

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

Attenzione

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 potrà decrittografare gli aggiornamenti crittografati

Crittografia dei Pacchetti

Metodo 1: Crittografia durante l'upload

Il modo 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 avere più controllo, puoi crittografare manualmente i pacchetti:

1. Crea un pacchetto 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. Incarica il tuo archivio (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

Stocca le 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 privataUtilizzato da CLI per la crittografia durante l'upload del pacchetto (mantenere sicuro)
• Chiave pubblicaUtilizzato per la configurazione dell'app per la decrittografia sul dispositivo (sicuro da committere)

Rimuovi dopo un compromesso della chiave privata

Rimuovere il pair di chiavi quando la chiave privata è sospettata o confermata compromessa. Una rotazione calendario regolare non è richiesta. Questo è una migrazione della chiave nativa, non un cambiamento solo OTA.

1. Genera un nuovo pair di chiavi:

   npx @capgo/cli@latest key create

2. Salva la chiave pubblica di sostituzione nel tuo Capacitor config:

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

3. Sincronizza e distribuisci una versione nativa di rilascio: Esegui npx cap sync, poi distribuisci una nuova versione di app nativa contenente la chiave pubblica di sostituzione.

4. Mirare alla nuova versione nativa: I dispositivi che ancora eseguono il binario nativo vecchio non possono decrittografare gli aggiornamenti crittografati con la chiave pubblica di sostituzione. Utilizza Targeting della versione per limitare i pacchetti di sostituzione alla nuova versione nativa mentre il resto della flotta si aggiorna attraverso la store o MDM.

5. Sostituisci il tuo segreto di caricamento: Non appena quella versione nativa è live, sostituisci la chiave privata nel CI e carica solo pacchetti mirati alle versioni native che contengono la chiave pubblica di sostituzione.

Attenzione

In caso di compromissione della chiave privata, smettete di utilizzarla immediatamente. Le installazioni esistenti con la vecchia chiave pubblica necessitano di un aggiornamento del magazzino nativo o MDM prima di poter ricevere pacchetti crittografati con la chiave di sostituzione.

Pratiche di Sicurezza

Sicurezza delle Chiavi

• Non condividere mai le chiavi private tra ambienti o membri del team
• Usare chiavi diverse per ambienti diversi (dev, staging, production)
• Rinnovare dopo un compromissioneRipristina 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

Capacità di Sicurezza del Pacchetto

• Verifica sempre l'integrità del pacchetto dopo la decrittografia
• Monitora per i pattern di download insoliti o fallimenti
• Utilizza HTTPS per tutte le URL dei pacchetti (richiesto per le app mobili)
• Esegui gestione degli errori corretta per le fallite di decrittazione

Controllo degli Accessi

• Limitare l'accesso agli archivi delle chiavi 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

Risolvere i problemi di crittografia

Issue comuni

Fallimenti di decrittografia:

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

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

Problemi di prestazioni:

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

Comandi di debug

Verifica lo stato di crittografia:

npx @capgo/cli@latest app debug

Testa il flusso di crittografia/decriptazione:

# 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

Capgo implementa la crittografia secondo gli standard dell'industria:

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

Ciò rende Capgo adatto per 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 di servizio 2 (SOC 2)
• Gestione della sicurezza delle informazioni (ISO 27001)

Considerazioni di prestazione

Carico di crittografia

• Dimensione del pacchetto: I pacchetti crittografati sono leggermente più grandi (~1-2% di sovraccarico)
• Tempo di elaborazione: La crittografia e la decrittografia aggiungono una latenza minima
• Uso della memoria: Aumento temporaneo durante le operazioni di cifratura/decifratura

Suggerimenti di ottimizzazione

• Utilizza gli aggiornamenti Delta (manifesto) per ridurre il trasferimento di dati cifrati
• Optimizza il tuo bundle di dimensioni riducendo 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

Passaggi successivi

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

Continua da Crittografia

Crittografia If you are using 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 in Capgo Centro di Trust, e Sicurezza dell'Organizzazione per i dettagli di implementazione in Sicurezza dell'Organizzazione.