Google Meet passa alla crittografia post-quantum contro il rischio HNDL

🛡️ Executive Summary

• Google estende la crittografia post-quantum alle chiamate Meet, oltre alla protezione già disponibile nelle riunioni con client-side encryption.
• Il rollout parte dai client web su laptop e dall’hardware delle sale riunioni; il supporto mobile arriverà successivamente e non richiede interventi degli utenti.
• La priorità è contrastare Harvest Now, Decrypt Later: intercettare oggi comunicazioni cifrate per tentare di decifrarle in futuro con computer quantistici più potenti.

Google Meet porta la protezione post-quantum dalle configurazioni specialistiche al traffico ordinario delle videoconferenze. Dal 12 ottobre Google ha iniziato ad applicare la nuova protezione alle chiamate Meet sui client web utilizzati da laptop e sull’hardware delle sale riunioni, con il supporto mobile previsto successivamente. Non serve modificare impostazioni né intervenire sulla console amministrativa: la migrazione viene gestita direttamente dall’infrastruttura Google. Il problema che Mountain View vuole anticipare non è un computer quantistico capace oggi di rompere le chiamate Meet, perché una macchina crittograficamente rilevante di questo tipo non esiste ancora. Il rischio è temporale: un avversario può conservare oggi traffico cifrato di valore e tentare di decifrarlo tra anni, quando capacità quantistiche sufficienti potrebbero rendere vulnerabili alcune primitive a chiave pubblica utilizzate attualmente.

Google Meet estende il quantum-safe oltre le riunioni CSE

Nell’annuncio ufficiale di Google Workspace Google conferma che la protezione viene estesa alle chiamate Meet in generale. In precedenza la tecnologia quantum-safe era già utilizzata nelle riunioni configurate con client-side encryption, CSE, modalità enterprise nella quale i media vengono cifrati sul dispositivo del partecipante e Google non possiede le chiavi necessarie a decifrarli. Il rollout di ottobre cambia scala perché la preparazione al rischio quantistico smette di essere una funzione riservata alle organizzazioni che costruiscono una specifica infrastruttura di gestione delle chiavi. La protezione viene inserita direttamente nel servizio e raggiunge anche account personali e utenti Workspace senza una procedura di attivazione. È un salto coerente con la trasformazione di Google Meet in infrastruttura sempre più interoperabile con Microsoft Teams e con l’hardware delle sale riunioni: aumentando il numero di organizzazioni e dispositivi che attraversano la piattaforma, aumenta anche il valore della protezione delle comunicazioni nel lungo periodo.

Leggi anche: Google Cloud protegge l’importazione delle chiavi con crittografia quantum-safe

Harvest Now, Decrypt Later rende sensibili anche le chiamate di oggi

Il punto centrale è Harvest Now, Decrypt Later, il modello di minaccia nel quale l’attaccante non deve essere in grado di violare immediatamente la crittografia. Può intercettare, copiare e archiviare materiale cifrato confidando che in futuro una nuova capacità computazionale permetta di recuperare le informazioni protette. Per una conversazione quotidiana il valore del dato potrebbe essere già scaduto quando ciò diventasse tecnicamente possibile; per informazioni industriali, governative, sanitarie, finanziarie o di ricerca il periodo di riservatezza può invece essere molto più lungo. Lo stesso problema aveva già portato Google Cloud a proteggere anche il trasferimento delle chiavi BYOK verso Cloud KMS, segnale che la migrazione non riguarda più soltanto certificati o protocolli teorici ma i punti reali nei quali informazioni sensibili attraversano infrastrutture operative.

Google non dice quale algoritmo usa e questo limite va mantenuto

La comunicazione di Google non identifica pubblicamente, nell’annuncio di Meet, quale KEM o costruzione ibrida venga utilizzata per le chiamate ordinarie. La distinzione è importante perché il resto dell’ecosistema Google sta già implementando algoritmi standardizzati e schemi ibridi in Android, Cloud KMS e altre componenti, ma questo non autorizza ad attribuire automaticamente la stessa configurazione a Meet. ML-KEM, per esempio, è ormai una primitiva centrale della transizione post-quantum e compare già in implementazioni Google, OpenSSL e negli standard NIST, ma l’annuncio del 12 ottobre parla genericamente di PQC. La scelta editoriale corretta è quindi separare ciò che Google dichiara da ciò che sarebbe tecnicamente plausibile. Meet è ora protetto contro il rischio quantistico secondo l’architettura Google; i dettagli crittografici del nuovo percorso non sono stati ancora esposti nella comunicazione pubblica.

Web e sale partono subito ma il mobile resta nella seconda fase

La distribuzione inizia sui client web utilizzati da laptop e sull’hardware Google Meet per le sale, con rollout graduale fino a quindici giorni per i domini Rapid Release e Scheduled Release. I dispositivi mobili arriveranno successivamente. Per amministratori e utenti non esiste un toggle da attivare, scelta che rende la migrazione molto diversa dalla client-side encryption tradizionale: CSE richiede identità esterna, gestione delle chiavi e configurazioni dedicate, mentre questa protezione diventa parte del livello crittografico gestito da Google. La distinzione resta però fondamentale. Post-quantum non significa automaticamente end-to-end encryption e non rende Google incapace di elaborare i dati di una normale riunione cloud. Google continua infatti a distinguere cloud encryption, end-to-end encryption e client-side encryption come modelli differenti. PQC interviene sulla resistenza futura di determinate primitive, non modifica da sola chi possiede le chiavi o quali servizi possono accedere ai contenuti durante il normale funzionamento.

La scadenza Google del 2029 rende Meet un test di migrazione su scala reale

Google ha fissato nel marzo 2026 un obiettivo molto aggressivo: completare una parte sostanziale della propria migrazione post-quantum entro il 2029. Portare Meet dentro questo percorso mostra quanto il problema sia passato dalla ricerca alla gestione operativa di servizi utilizzati da milioni di persone. La difficoltà maggiore della transizione non consiste infatti nel pubblicare un nuovo algoritmo, ma nel sostituire primitive crittografiche dentro browser, sistemi operativi, librerie, infrastrutture cloud, dispositivi e protocolli senza interrompere compatibilità e prestazioni. In Europa la stessa urgenza sta entrando nella supervisione finanziaria: EBA, EIOPA ed ESMA hanno già inserito il rischio quantistico tra le vulnerabilità da presidiare, spostando la questione dal laboratorio alla governance del rischio ICT.

Continua con:

UE porta il rischio quantistico nella vigilanza su blockchain e finanza

Pentagono investe 350 milioni nel quantum: la sfida alla Cina cambia scala

La migrazione quantistica diventa invisibile ed è proprio questo il salto

La vera novità di Google Meet non è che una nuova funzione di sicurezza compare nelle impostazioni. È esattamente il contrario: l’utente non deve fare nulla. La migrazione crittografica comincia a diventare una proprietà dell’infrastruttura, come TLS o la cifratura dei dati a riposo, invece di un’opzione riservata ai team di sicurezza più maturi. È probabilmente il modello necessario per affrontare il rischio quantistico su scala: inventari delle primitive, crypto-agility, deployment ibridi e sostituzione progressiva degli algoritmi devono avvenire prima che esista una macchina capace di sfruttare realmente le debolezze della crittografia classica. Google non sta annunciando che il quantum abbia rotto Internet e non fornisce una data per una macchina in grado di farlo. Sta facendo qualcosa di più concreto: modifica oggi una delle proprie piattaforme di comunicazione perché le conversazioni intercettate nel 2026 non diventino improvvisamente leggibili nel futuro.