Capacitor-aggiornatore ora supporta la crittografia end-to-end code . La firma Code assicura che gli aggiornamenti eseguiti dai dispositivi degli utenti finali non sono stati alterati e fornisce un livello di protezione aggiuntivo rispetto alla sicurezza standard del Capacitor-aggiornatore.
La sicurezza predefinita dell'Capacitor-aggiornatore
Di default, il modello di sicurezza dell'Capgo è simile a quello dei fornitori di hosting web. Capgo memorizza gli aggiornamenti crittografati in massa e li serve tramite HTTPS utilizzando cifre moderne. Allo stesso modo, pubblicare un aggiornamento da un computer del developer utilizza sempre HTTPS.
La sicurezza predefinita dell'Capgo ottiene un A+ nel test SSL Labs' HTTPS (https://www.ssllabs.com, novembre 2022)
Come i migliori hosting web, Capgo utilizza HTTPS per proteggere la privacy e l'integrità delle connessioni di rete tra il server e i dispositivi degli utenti finali. Si tratta di un livello eccellente di sicurezza che funziona bene sia per il web che per le app Ionic che utilizzano Capgo.
La catena di fornitura dell'infrastruttura cloud
Un'altra cosa Capgo e la maggior parte dei provider di hosting web hanno in comune è che funzionano su infrastrutture cloud di livello inferiore, spesso da AWS, GCP o un altro popolare provider di cloud. L'hardware e il software gestiti da questi provider di cloud e Capgo o altri provider di hosting web fanno parte della catena di fornitura del cloud.
La catena di fornitura del cloud e il suo modello di sicurezza funzionano per un numero enorme di siti web e app. Ogni sviluppatore web che utilizza un provider di cloud mette fiducia in quel provider e si aspetta che i file che carica siano i file che vengono eseguiti o serviti senza essere stati alterati. E i provider di cloud lavorano duramente per mantenere la loro infrastruttura sicura.
Ma ovviamente, le vulnerabilità di hardware e software vengono scoperte. I provider di cloud patchano le vulnerabilità in orari prestabiliti, prevenendo proattivamente il software malintenzionato (ad esempio Google’s SLSA), e costruiscono strati di difesa in profondità, e in pratica, l'infrastruttura cloud ha dimostrato di soddisfare le maggiori esigenze di sicurezza dei siti web e delle app. Tuttavia, alcune app Ionic includono infrastrutture cloud compromesse nei loro modelli di minaccia. Per queste Capacitor app JS con le più elevate esigenze di sicurezza al di sopra del web, abbiamo costruito la firma end-to-end code in Capgo e nel protocollo di aggiornamento standard Capacitor. La firma end-to-end Capgo con __CAPGO_KEEP_1__.
End-to-end code signing with Capgo
Capgo’s end-to-end code signing uses public-key cryptography to ensure end users’ devices run only unmodified, original updates from the Capacitor app developer.
“Da capo a fine” significa che questa sicurezza copre il flusso dal momento in cui lo sviluppatore pubblica un aggiornamento fino al momento in cui il dispositivo dell'utente finale riceve e esegue l'aggiornamento. “Code firma” utilizza la crittografia e una chiave privata segreta per “firmare” code, e in seguito utilizza una chiave pubblica affidabile per verificare la firma.
Ecco uno schema semplice* per spiegare come funziona:
- Complesso nella pratica, la crittografia è difficile
Definizione:
- AES: Standard di crittografia avanzata, un algoritmo di crittografia simmetrica, una chiave per l'encryption e la decrittografia.
- RSA: Rivest-Shamir-Adleman, un algoritmo di crittografia asimmetrica, due chiavi vengono utilizzate: una chiave pubblica e una chiave privata.
- Cifrario: I dati crittografati.
- Chiave di sessione: Una chiave AES utilizzata per crittografare e decrittografare i dati.
- Checksum: Un hash calcolato per un file
- Firma: Un checksum che è stato crittografato con una chiave privata RSA. Può essere verificato con una chiave pubblica RSA
Utilizziamo l'algoritmo AES per crittografare l'aggiornamento. Una chiave AES casuale viene generata per ogni upload, quindi la chiave AES e il checksum (in seguito “firma”) vengono crittografati con la chiave privata RSA dello sviluppatore. La chiave pubblica RSA dello sviluppatore viene utilizzata nell'app per decrittografare la chiave AES e la firma (convertono nuovamente in un checksum). In seguito, la chiave AES decrittografata viene utilizzata per decrittografare l'aggiornamento; un checksum del file decrittografato viene calcolato e viene confrontato con la firma decrittografata.
Utilizziamo due diversi algoritmi di crittografia perché RSA non può essere utilizzato per crittografare grandi quantità di dati. AES viene utilizzato per crittografare l'aggiornamento e RSA viene utilizzato per crittografare la chiave AES e il checksum.
Con questo, nemmeno Capgo può leggere il contenuto del tuo pacchetto. Questo è un modello di sicurezza robusto che viene utilizzato da molti clienti aziendali.
Crittografia dell'aggiornamento V2 2024-08-27:
- Abbiamo cambiato il tipo di chiave che viene memorizzata nell'app. Ciò è stato fatto per prevenire l'inferenza della chiave pubblica (utilizzata precedentemente per la crittografia) dalla chiave privata (utilizzata precedentemente per la decrittografia). Ora, l'app memorizza la chiave pubblica (utilizzata ora per la decrittografia).
- Abbiamo cambiato il checksum dall'algoritmo CRC32 all'algoritmo SHA256. Abbiamo anche iniziato a firmare il pacchetto.
- Quando è configurata la crittografia V2, un aggiornamento deve avere una firma valida. Ciò viene rigorosamente imposto dal plugin.
Ora imponevamo una firma valida. Questi 3 cambiamenti sono stati fatti dopo un'analisi di sicurezza da parte di un membro della community. Sono qui per prevenire attacchi crittografici durante l'aggiornamento. Se hai utilizzato la crittografia V1, migra a V2 per beneficiare delle nuove funzionalità di sicurezza. Segui le.
istruzioni di migrazione. Con la crittografia end-to-end code, Capgo diventa un'infrastruttura cloud 'senza fiducia'. Se uno dei provider di Capgo o anche Capgo stesso modificasse un aggiornamento firmato con code, i dispositivi degli utenti rifiuterebbero quell'aggiornamento e eseguirebbero il precedente aggiornamento affidabile che è già presente sul dispositivo.
Sebbene il HTTPS a livello web sia sufficiente per molte app, alcune grandi aziende trovano l'ulteriore livello di sicurezza da code firma a fine a fine attraente. Alcune di queste aziende creano app di finanza che emettono transazioni di valore elevato e permanente. Altre aziende hanno CISO che includono infrastrutture cloud compromesse nei loro modelli di minaccia. Abbiamo implementato la firma a fine a fine code in Capgo per questi casi d'uso e siamo interessati a sentire più da aziende con bisogni di sicurezza più elevati.
Avvio rapido per i clienti aziendali
Per le grandi aziende o i progetti che si curano profondamente della sicurezza, vogliamo rendere la code firma facile da configurare e mantenere. A tale scopo, forniamo ora le seguenti funzionalità:
- Configurazione rapida del certificato e della configurazione
- Sostegno per la code firma dei server di sviluppo con entrambi Capgo e build di sviluppo
- Firma code in produzione su ogni aggiornamento
La Capgo code firma è disponibile per tutti i clienti. Per iniziare, segui le istruzioni di configurazione Crediti.
Un grande ringraziamento a
Ionic Questo articolo è basato susetup istruzioni Questo articolo Riscritto con Chat-GPT-3 e adattato.
Continua da E2E Encryption per Capacitor Aggiornatore tramite Code Firma
Se stai utilizzando E2E Encryption per Capacitor Aggiornatore tramite Code Firma per pianificare la sicurezza e la conformità, connettilo con Crittografia per i dettagli di implementazione in Crittografia, 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, e Capgo Centro di fiducia per il flusso di lavoro del prodotto in Capgo Centro di fiducia.
