Crittografia at-rest predefinita

Questi contenuti sono stati aggiornati per l'ultima volta a maggio 2024 e rappresentano lo status quo al momento della redazione. I criteri e i sistemi di sicurezza di Google potranno variare in futuro, di pari passo con il nostro impegno al costante miglioramento della protezione dei clienti.

In Google, la nostra strategia di sicurezza completa include crittografia at-rest, che contribuisce a proteggere i dati dei clienti dagli autori degli attacchi. Criptiamo tutti i contenuti dei clienti di Google archiviati inattivi, senza che sia richiesta alcuna azione da parte tua, utilizzando uno o più meccanismi di crittografia. Questo documento descrive il nostro approccio alla crittografia at-rest predefinita per l'infrastruttura Google e Google Cloude il modo in cui la utilizziamo per proteggere maggiormente i contenuti dei clienti.

Questo documento è destinato agli architetti della sicurezza e ai team di sicurezza che attualmente utilizzano o stanno prendendo in considerazione Google. Questo documento presuppone una conoscenza di base della crittografia e delle primitive crittografiche. Per ulteriori informazioni sulla crittografia, consulta Introduction to Modern Cryptography.

La crittografia dei dati inattivi è la crittografia utilizzata per proteggere i dati archiviati su un disco (incluse le unità a stato solido o SSD) o su supporti di backup. Tutti i dati archiviati da Google vengono criptati a livello di archiviazione utilizzando l'algoritmo Advanced Encryption Standard (AES), AES-256. Utilizziamo una libreria crittografica comune, Tink, che include il nostro modulo convalidato FIPS 140-2 (denominato BoringCrypto) per implementare la crittografia in modo coerente in Google Cloud.

Possediamo e gestiamo le chiavi usate nella crittografia at-rest predefinita. Se utilizzi Google Cloud, Cloud Key Management Service ti consente di creare le tue chiavi di crittografia che puoi utilizzare per aggiungere la crittografia envelope ai tuoi dati. Utilizzando Cloud KMS, puoi creare, ruotare, monitorare ed eliminare le chiavi. Per saperne di più, consulta Approfondimenti su Cloud Key Management Service.

Chiavi in Google Cloud

La seguente tabella descrive le diverse proprietà delle chiavi in Google Cloud.

Tipo di chiave	Autokey di Cloud KMS	Cloud KMS gestito dal cliente (manuale)	Google-owned and Google-managed encryption key (crittografia predefinita di Google)
Può visualizzare i metadati chiave	Sì	Sì	No
Proprietà delle chiavi1	Cliente	Cliente	Google
Può gestire le chiavi2 e controllare le chiavi3	La creazione e l'assegnazione delle chiavi sono automatizzate. Il controllo manuale del cliente è completamente supportato.	Cliente, solo controllo manuale	Google
Supporta i requisiti normativi per le chiavi gestite dal cliente	Sì	Sì	No
Condivisione della chiave	Unico per un cliente	Unico per un cliente	I dati di più clienti sono in genere protetti da chiavi di crittografia condivise (KEK).
Controllo della rotazione della chiave	Sì	Sì	No
Policy CMEK dell'organizzazione	Sì	Sì	No
Registra l'accesso amministrativo e ai dati alle chiavi di crittografia	Sì	Sì	No
Separazione logica dei dati tramite crittografia	Sì	Sì	No
Prezzi	Varia	Varia	Gratis

¹ Il proprietario della chiave indica chi detiene i diritti sulla chiave. Le chiavi di tua proprietà hanno accesso strettamente limitato o nessun accesso da parte di Google.

² La gestione delle chiavi include le seguenti attività:

• Crea chiavi.
• Scegli il livello di protezione delle chiavi.
• Assegna l'autorità per la gestione delle chiavi.
• Controlla l'accesso alle chiavi.
• Controllare l'utilizzo delle chiavi.
• Imposta e modifica il periodo di rotazione delle chiavi o attiva una rotazione delle chiavi.
• Modifica lo stato della chiave.
• Elimina le versioni della chiave.

³ Il controllo delle chiavi significa impostare controlli sul tipo di chiavi e su come vengono utilizzate, rilevare le variazioni e pianificare un'azione correttiva, se necessario. Puoi controllare le chiavi, ma delegare la gestione a una terza parte.

In che modo la crittografia at-rest contribuisce a proteggere i dati

La crittografia dei dati inattivi è un tassello di una strategia di sicurezza più ampia. La crittografia offre i seguenti vantaggi:

• Contribuisce a garantire che, se i dati finiscono nelle mani di un utente malintenzionato, quest'ultimo non possa leggerli senza avere accesso anche alle chiavi di crittografia. Anche se gli autori degli attacchi ottengono i dispositivi di archiviazione contenenti i dati dei clienti, non potranno comprenderli o decriptarli.
• Aiuta a ridurre la superficie di attacco escludendo i livelli più bassi dello stack hardware e software.
• Funge da "collo di bottiglia" perché le chiavi di crittografia gestite centralmente creano un'unica posizione in cui si impone l'obbligo di accesso ai dati e da cui è possibile controllare tutti gli accessi.
• Contribuisce a ridurre la superficie di attacco perché, anziché dover proteggere tutti i dati, le aziende possono concentrare le proprie strategie di protezione sulle chiavi di crittografia.
• Fornisce un importante meccanismo di privacy per i nostri clienti. Quando i dati vengono criptati a riposo, l'accesso di sistemi e ingegneri ai dati è limitato.

Che cosa sono i dati dei clienti?

Come definito nei Google Cloud Termini di servizio, i dati dei clienti sono i dati che i clienti o gli utenti finali forniscono a Google tramite i servizi nell'ambito del loro account.

I contenuti dei clienti sono i dati che generi tu stesso o che ci fornisci, ad esempio i dati archiviati in bucket Cloud Storage, volumi Persistent Disk e snapshot di dischi utilizzati da Compute Engine. Questo documento si concentra sulla crittografia at-rest predefinita per questo tipo di dati dei clienti.

I metadati dei clienti sono dati sui contenuti dei clienti e includono numeri di progetto generati automaticamente, timestamp, indirizzi IP, le dimensioni in byte di un oggetto in Cloud Storage o il tipo di macchina in Compute Engine. I metadati dei clienti sono protetti in modo ragionevole per garantire prestazioni costanti e continuità delle operazioni. Questo documento non si concentra sulle protezioni per i metadati.

I contenuti e i metadati dei clienti costituiscono i dati dei clienti.

Crittografia predefinita dei dati at-rest

Google utilizza uno o più meccanismi di crittografia per criptare tutti i contenuti archiviati inattivi dei clienti, senza che sia richiesta alcuna azione da parte tua. Le sezioni seguenti descrivono i meccanismi che utilizziamo per criptare i contenuti dei clienti.

Livelli di crittografia

Google utilizza diversi livelli di crittografia per proteggere i dati. L'utilizzo di più livelli di crittografia aggiunge una protezione dei dati ridondante e ci consente di scegliere l'approccio ottimale in base ai requisiti dell'applicazione.

Il seguente diagramma mostra i diversi livelli di crittografia generalmente utilizzati per proteggere i dati degli utenti nei data center di produzione di Google. La crittografia dei file system distribuiti o a livello di archiviazione di file e database, così come la crittografia dei dispositivi di archiviazione, è applicata a tutti i dati utente e a tutti i dati nei data center di produzione di Google.

Crittografia a livello di infrastruttura

Tutti i sistemi di archiviazione di Google utilizzano un'architettura di crittografia simile, anche se i dettagli di implementazione variano da sistema a sistema. I dati sono suddivisi in blocchi logici per l'archiviazione e le dimensioni di ogni singolo blocco possono arrivare a diversi gigabyte. Ogni blocco viene criptato a livello di archiviazione con una chiave di crittografia dei dati (DEK) individuale: due blocchi non avranno la stessa DEK, anche se appartengono allo stesso cliente o sono archiviati sulla stessa macchina.

Se un blocco di dati viene aggiornato, viene criptato con una nuova chiave, non viene riutilizzata la chiave esistente. Questo partizionamento dei dati, con l'utilizzo di una chiave diversa per ogni partizione, limita il rischio di una potenziale compromissione della chiave di crittografia dei dati a un solo blocco di dati.

Google cripta i dati prima che vengano scritti in un sistema di archiviazione di database o su un disco hardware. La crittografia è integrata in tutti i nostri sistemi di archiviazione, non viene aggiunta in un secondo momento.

Ogni blocco di dati logici ha un identificatore univoco. Gli elenchi di controllo di accesso (ACL) contribuiscono a garantire che ogni blocco possa essere decriptato solo dai servizi Google che operano con ruoli autorizzati, a cui viene concesso l'accesso solo in quel momento. Questa limitazione dell'accesso contribuisce a impedire l'accesso ai dati senza autorizzazione, rafforzando la sicurezza e la privacy dei dati.

Ogni blocco viene distribuito nei nostri sistemi di archiviazione e viene replicato in formato criptato a fini di backup e ripristino di emergenza. Un malintenzionato che vuole accedere ai dati dei clienti deve conoscere ed essere in grado di accedere a due elementi: tutti i blocchi di archiviazione corrispondenti ai dati che vuole e tutte le chiavi di crittografia corrispondenti ai blocchi.

Il seguente diagramma mostra come i dati vengono caricati nella nostra infrastruttura e poi suddivisi in blocchi criptati per l'archiviazione.

Utilizziamo l'algoritmo AES per criptare i dati inattivi. Tutti i dati a livello di archiviazione vengono criptati dalle DEK, che utilizzano l'algoritmo AES-256 per impostazione predefinita, ad eccezione di un numero ridotto di dischi permanenti creati prima del 2015 che utilizzano l'algoritmo AES-128. L'algoritmo AES è di uso comune perché sia AES-256 sia AES-128 sono consigliati dal National Institute of Standards and Technology (NIST) per l'archiviazione a lungo termine e l'algoritmo AES è spesso incluso nei requisiti di conformità dei clienti.

Un blocco di dati logico potrebbe contenere i dati di più clienti. Se vuoi ottenere la separazione logica dei dati tramite la crittografia, devi abilitare Cloud Key Management Service.

Crittografia a livello di dispositivo di archiviazione

Oltre alla crittografia a livello di sistema di archiviazione, i dati vengono criptati anche a livello di dispositivo di archiviazione con AES-256 per dischi rigidi (HDD) e unità a stato solido (SSD), utilizzando una chiave separata a livello di dispositivo (diversa dalla chiave utilizzata per criptare i dati a livello di archiviazione). Un numero ridotto di HDD legacy utilizza l'algoritmo AES-128. Le SSD utilizzate da Google implementano l'algoritmo AES-256 esclusivamente per i dati degli utenti.

Crittografia dei backup

Il nostro sistema di backup garantisce che i dati rimangano criptati durante il processo di backup. Questo approccio evita esposizioni non necessarie dei dati del testo non crittografato.

Inoltre, il sistema di backup cripta ulteriormente la maggior parte dei file di backup in modo indipendente, ognuno con una propria DEK. La DEK deriva da una chiave archiviata in Keystore e da un seme generato in modo casuale al momento del backup e diverso per ogni file. Durante i backup, per tutti i metadati viene utilizzata un'altra DEK, archiviata anch'essa in Keystore.

Conformità FIPS per dati inattivi

Google utilizza nel suo ambiente di produzione un modulo di crittografia convalidato FIPS 140-2 (certificato 4407).

Gestione delle chiavi

A causa dell'elevato volume di chiavi utilizzate da Google e della necessità di mantenere una bassa latenza e un'alta disponibilità, le DEK vengono archiviate vicino ai dati che devono criptare. Le DEK sono criptate (sottoposte a wrapping) con una chiave di crittografia della chiave (KEK), utilizzando una tecnica nota come crittografia envelope. Queste chiavi KEK non sono specifiche per i clienti. Esistono invece una o più chiavi KEK per ogni servizio.

Queste KEK sono archiviate a livello centrale in Keystore, un repository creato appositamente per l'archiviazione delle chiavi. La presenza di un numero inferiore di KEK rispetto alle DEK e l'utilizzo di un keystore centrale rendono gestibili l'archiviazione e la crittografia dei dati su scala Google, oltre a consentire di monitorare e controllare l'accesso ai dati da una posizione centrale.

In Google Cloud, ogni cliente può avere risorse condivise e non condivise. Un esempio di risorsa condivisa è un'immagine di base condivisa in Compute Engine. Per le risorse condivise, più clienti fanno riferimento a una singola copia, criptata con una singola DEK. Le risorse non condivise vengono suddivise in blocchi di dati e criptate con chiavi distinte da quelle utilizzate per altri clienti. Queste chiavi sono distinte anche da quelle che proteggono altre porzioni degli stessi dati appartenenti allo stesso cliente. Esistono eccezioni (ad esempio Datastore, App Engine o Pub/Sub) in cui i dati di più clienti potrebbero essere criptati con la stessa DEK.

Generazione delle DEK

Il sistema di archiviazione genera le DEK utilizzando la libreria crittografica comune di Google. In generale, le DEK vengono quindi inviate a Keystore per essere sottoposte a wrapping con la KEK del sistema di archiviazione e le DEK con wrapping vengono restituite al sistema di archiviazione per essere conservate insieme ai blocchi di dati. Quando un sistema di archiviazione ha bisogno di recuperare i dati criptati, recupera la DEK con wrapping e la invia a Keystore. Keystore verifica che il servizio sia autorizzato a utilizzare la KEK e, in caso positivo, ne annulla il wrapping e restituisce al servizio la DEK in testo non crittografato. In seguito il servizio utilizza la DEK per decriptare il blocco di dati, trasformarlo in testo non crittografato e verificarne l'integrità.

Tutti i sistemi di archiviazione Google Cloud rispettano questo modello di gestione delle chiavi, ma la maggior parte dei sistemi implementa anche livelli aggiuntivi di KEK lato archiviazione per creare una gerarchia di chiavi. In questo modo, i sistemi possono fornire una bassa latenza utilizzando la KEK di livello più alto (memorizzata in Keystore) come radice di attendibilità.

Generazione di KEK

La maggior parte delle KEK per la crittografia dei blocchi di dati viene generata all'interno di Keystore, mentre le altre vengono generate all'interno dei servizi di archiviazione. Per coerenza, tutte le KEK vengono generate tramite la libreria crittografica comune di Google, utilizzando un generatore di numeri casuali (RNG) creato da Google. L'RNG si basa sulla pubblicazione NIST 800-90Ar1 CTR-DRBG e genera una KEK AES-256. In passato, l'algoritmo era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati.

Per i processori Intel e AMD, l'RNG ha origine dall'istruzione RDRAND e dall'RNG del kernel Linux. A sua volta, l'RNG del kernel Linux deriva da più origini entropiche indipendenti, tra cui RDRAND ed eventi entropici provenienti dall'ambiente del data center (ad esempio, misurazioni granulari del numero di operazioni di ricerca su disco e dei tempi di arrivo tra pacchetti). Per i processori Arm, l'RNG ha origine dall'RNG del kernel Linux.

Le DEK vengono sottoposte a wrapping con le KEK utilizzando gli algoritmi AES-256 o AES-128, a seconda del Google Cloud servizio. Al momento stiamo lavorando per eseguire l'upgrade di tutte le KEK per i serviziGoogle Cloud all'algoritmo AES-256.

Gestione delle KEK

Keystore è stato creato esclusivamente per la gestione delle KEK. Per progettazione, le KEK utilizzate dai sistemi di archiviazione non sono esportabili da Keystore; tutte le operazioni di crittografia e decrittografia con queste chiavi devono essere eseguite all'interno di Keystore. Ciò contribuisce a evitare fughe di dati e usi impropri e consente a Keystore di creare un audit trail quando le chiavi vengono utilizzate.

Keystore può ruotare automaticamente le KEK a intervalli di tempo regolari, utilizzando la libreria crittografica comune di Google per generare nuove chiavi. Anche se spesso facciamo riferimento a una singola chiave, in realtà intendiamo dire che i dati sono protetti tramite un set di chiavi: una chiave è attiva per la crittografia e un set di chiavi storiche è attivo per la decrittografia. Il numero di chiavi storiche è determinato dalla pianificazione di rotazione della chiave. Le KEK vengono sottoposte a backup a scopo di ripristino di emergenza e possono essere recuperate in modo illimitato.

L'utilizzo delle KEK è gestito tramite gli ACL in Keystore per ogni chiave, con un criterio diverso per ogni chiave. Solo gli utenti e i servizi Google autorizzati possono accedere a una chiave. L'utilizzo di ogni chiave viene monitorato a livello della singola operazione che richiede la chiave, quindi ogni volta che un utente utilizza una chiave viene autenticato e registrato in un log. Tutti gli accessi ai dati da parte degli utenti sono controllabili nell'ambito delle norme sulla privacy e dei criteri di sicurezza globali di Google.

Procedura per accedere ai blocchi di dati criptati

Quando un servizio Google accede a un blocco di dati criptato, si verifica quanto segue:

1. Il servizio effettua una chiamata al sistema di archiviazione dei dati di cui ha bisogno.
2. Il sistema di archiviazione identifica i blocchi in cui sono archiviati i dati (gli ID blocco) e la posizione in cui sono archiviati.
3. Per ogni blocco, il sistema di archiviazione estrae la DEK con wrapping archiviata con il blocco (in alcuni casi, questa operazione viene eseguita dal servizio) e la invia a Keystore per farne annullare il wrapping.
4. Il sistema di archiviazione verifica che il job identificato sia autorizzato ad accedere al blocco di dati in base a un identificatore job e tramite l'ID blocco. Keystore verifica che il sistema di archiviazione sia autorizzato a utilizzare la KEK associata al servizio e ad annullare il wrapping di quella specifica DEK.
5. Keystore esegue una delle seguenti operazioni:
   • Restituisce la DEK decriptata al sistema di archiviazione, che decripta il blocco di dati e lo passa al servizio.
   • In alcuni rari casi, passa la DEK decriptata al servizio. Il sistema di archiviazione passa il blocco di dati criptato al servizio, che lo decripta e lo utilizza.

Questo processo è diverso in alcuni dispositivi di archiviazione dedicati, in cui il dispositivo gestisce e protegge la DEK a livello di dispositivo.

Il seguente diagramma mostra questa procedura. Per decriptare un blocco di dati, il servizio di archiviazione chiama Keystore per recuperare la DEK decriptata del blocco di dati.

Gerarchia delle chiavi di crittografia e radice di attendibilità

L'archivio chiavi è protetto da una chiave radice, chiamata chiave master dell'archivio chiavi, che esegue il wrapping di tutte le KEK nell'archivio chiavi. Questa chiave master del keystore è AES-256 ed è archiviata a sua volta in un altro Key Management Service chiamato Root Keystore. In passato, la chiave master del keystore era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati. Per ulteriore sicurezza, il keystore radice non viene eseguito su macchine di produzione generali, bensì solo su macchine dedicate in ogni data center di Google.

A sua volta, il keystore radice ha una propria chiave radice, chiamata chiave master del keystore radice, che utilizza anch'essa l'algoritmo AES-256 ed è archiviata in un'infrastruttura peer-to-peer, chiamata distributore di chiavi master del keystore radice, che replica queste chiavi a livello globale. In passato, la chiave master del keystore radice era AES-128 e alcune di queste chiavi rimangono attive per decriptare i dati. Il distributore di chiavi master del keystore radice conserva le chiavi solo sulla RAM delle stesse macchine dedicate del keystore radice e utilizza il logging per verificare l'utilizzo corretto.

Quando viene avviata una nuova istanza del distributore di chiavi master del keystore radice, questa viene configurata con un elenco di nomi host di istanze del distributore già in esecuzione. Le istanze del distributore possono quindi ottenere la chiave master del keystore radice dalle altre istanze in esecuzione. Diversamente dai meccanismi di ripristino di emergenza descritti in Disponibilità e replica globali, la chiave master del keystore radice esiste solo su RAM su un numero limitato di macchine appositamente protette.

Per gestire lo scenario in cui tutte le istanze del distributore di chiavi master del keystore radice in una regione vengono riavviate simultaneamente, il backup della chiave master del keystore radice viene effettuato anche su dispositivi hardware protetti conservati in casseforti fisiche in aree a protezione elevata in più sedi distribuite geograficamente. Questo backup sarebbe necessario solo se tutte le istanze del distributore in una regione si spegnessero contemporaneamente. Solo pochi dipendenti di Google possono accedere a queste casseforti.

Il seguente diagramma mostra la gerarchia delle chiavi di crittografia. La gerarchia delle chiavi di crittografia protegge un blocco di dati con una DEK, criptata con una KEK nel keystore, che a sua volta è protetta dal keystore radice e dal distributore di chiavi master del keystore radice.

Riepilogo della gestione delle chiavi

Il seguente elenco riepiloga la gestione delle chiavi in Google:

• I dati vengono divisi in blocchi e criptati con DEK.
• Le DEK vengono criptate con KEK.
• Le KEK sono archiviate in Keystore.
• Keystore viene eseguito su più macchine nei data center a livello globale.
• Le chiavi dell'archivio chiavi sono criptate con la chiave master dell'archivio chiavi, archiviata nell'archivio chiavi radice.
• Root Keystore ha dimensioni ridotte rispetto a Keystore e viene eseguito solo su macchine dedicate in ciascun data center.
• Le chiavi dell'archivio chiavi radice sono sottoposte a wrapping con la chiave master dell'archivio chiavi radice, archiviata nel distributore di chiavi master dell'archivio chiavi radice.
• Il distributore di chiavi master del keystore radice è un'infrastruttura peer-to-peer che viene eseguita simultaneamente nella RAM di macchine dedicate a livello globale. Ogni macchina riceve il materiale relativo alle chiavi da altre istanze in esecuzione nella regione.
• Nel caso in cui tutte le istanze del distributore in una regione si spengano, una chiave master è archiviata in hardware protetti diversi in casseforti fisiche in alcune sedi di Google.

Replica e disponibilità a livello globale

A ogni livello, l'alta disponibilità, la bassa latenza e l'accesso globale alle chiavi sono fattori essenziali. Queste caratteristiche sono necessarie per poter utilizzare i servizi di gestione delle chiavi in Google.

Per questo motivo, Keystore è a scalabilità elevata e viene replicato migliaia di volte nei nostri data center di tutto il mondo. Viene eseguito su macchine normali nel nostro parco produzione e le istanze di Keystore vengono eseguite a livello globale per supportare le operazioni di Google. Di conseguenza, la latenza di ogni singola operazione relativa alle chiavi è estremamente ridotta.

Root Keystore viene eseguito su varie macchine dedicate alle operazioni di sicurezza in ciascun data center. Il distributore di chiavi master del keystore radice viene eseguito sulle stesse macchine, one-to-one con il keystore radice. Il distributore di chiavi master del Root Keystore fornisce un meccanismo di distribuzione tramite un protocollo gossip. A intervalli di tempo fissi, ogni istanza del distributore seleziona un'altra istanza casuale con cui confrontare le chiavi e riconcilia eventuali differenze nelle versioni delle chiavi. Con questo modello, non esiste un nodo centrale da cui dipende l'intera infrastruttura. Questo metodo di distribuzione ci consente di gestire e proteggere il materiale relativo alle chiavi con alta disponibilità.

Libreria crittografica comune di Google

La libreria crittografica comune di Google è Tink, che incorpora il modulo convalidato FIPS 140-2 denominato BoringCrypto. Tink è disponibile per tutti gli sviluppatori di Google. Grazie all'uso coerente di una libreria comune, è sufficiente un team ridotto di crittografi per implementare questo codice rigidamente controllato e revisionato, rendendo superfluo lo sviluppo indipendente di un sistema di crittografia da parte di ogni team di Google. Un team per la sicurezza speciale di Google ha la responsabilità di gestire la libreria crittografica comune per tutti i prodotti.

La libreria di crittografia Tink supporta una vasta gamma di modalità e tipi di chiavi di crittografia che vengono revisionati regolarmente per garantire che siano aggiornati sugli attacchi più recenti.

Al momento, utilizziamo i seguenti algoritmi crittografici per crittografia at-rest per le chiavi DEK e KEK. Gli algoritmi sono soggetti a modifiche in conformità con la nostra politica di continuo miglioramento delle funzionalità e della sicurezza.

Primitiva di crittografia	Protocolli preferiti	Altri protocolli supportati
Crittografia simmetrica	AES-GCM (256 bit)	AES-CBC e AES-CTR (128 e 256 bit) AES-EAX (128 e 256 bit)
Firme simmetriche (quando utilizzate con i protocolli AES-CBC e AES-CTR riportati sopra per l'autenticazione)	HMAC-SHA256	HMAC-SHA512 HMAC-SHA1

Nella libreria sono presenti altri protocolli di crittografia supportati in passato; tuttavia, questa tabella include i principali utilizzi in Google.

Ricerca e innovazione nel campo della crittografia

Per stare al passo con l'evoluzione della crittografia, abbiamo un team di ingegneri della sicurezza di altissimo livello con il compito di seguire, sviluppare e migliorare la tecnologia di crittografia. I nostri ingegneri partecipano ai processi di standardizzazione e alla gestione del software di crittografia di uso comune. Pubblichiamo regolarmente le nostre ricerche nel campo della crittografia in modo che tutti, incluso il pubblico generale, possano beneficiare delle nostre conoscenze.

Ad esempio, nella ricerca sulla crittografia post-quantistica, stiamo lavorando nei seguenti ambiti:

• Standardizzazione: abbiamo progettato insieme lo schema di firma digitale stateless basato su hash standardizzato come FIPS 205. Siamo editor dello standard ISO (International Organization for Standardization) sulle firme basate su hash della crittografia post-quantistica e abbiamo contribuito alle linee guida sulla gestione dello stato per le firme basate su hash presso l'IETF.

• Attivazione: abbiamo implementato la crittografia post-quantistica nel nostro protocollo interno per la sicurezza del livello di trasporto. Abbiamo attivato il supporto della crittografia post-quantistica in Chrome. Abbiamo aggiunto diversi algoritmi di crittografia post-quantistica alla nostra libreria crittografica Tink. Questo codice è sperimentale ed è progettato per aiutare a informare la community su ogni approccio.

• Pubblicazioni: abbiamo pubblicato Transitioning organizations to post-quantum cryptography su Nature. Questo documento fornisce una panoramica delle sfide di migrazione della crittografia post-quantistica. Abbiamo anche pubblicato un documento di ricerca sull'introduzione della crittografia post-quantistica nelle nostre chiavi di sicurezza.

Tieni presente che la crittografia simmetrica (che utilizza AES-128 o versioni successive) rimane resistente agli attacchi quantistici.

Passaggi successivi

• Per informazioni sull'utilizzo delle tue chiavi di crittografia in Google Cloud, consulta Chiavi di crittografia gestite dal cliente (CMEK).

• Per informazioni generali sulla Google Cloud sicurezza, consulta la sezione sulla sicurezza del Google Cloud sito web.

• Per informazioni sulla conformità e sulle certificazioni di conformità, consulta la sezione Conformità del sito web di Google Cloud , che include il report di controllo pubblico SOC3 di Google. Google Cloud

• Per informazioni sulla gestione delle chiavi e della crittografia in Google Workspace, consulta In che modo Google Workspace utilizza la crittografia per proteggere i tuoi dati, che copre gran parte degli stessi contenuti inclusi qui, ma si concentra esclusivamente su Google Workspace.