Gmail introduce la cifratura su Android e iOS: perché non è vera end-to-end

La cifratura introdotta in Gmail, adesso portata anche sui dispositivi Android e iOS, crea spesso confusione perché Google utilizza il termine E2EE (end-to-end encryption) mentre la tecnologia alla base è un’altra: la client-side encryption (CSE). Senza chiarire cosa significhi davvero CSE e quale ruolo svolga, è difficile capire se si tratti di una protezione equivalente a quella offerta da strumenti come OpenPGP o se ci si trovi dinanzi a un modello differente.

Che cos’è la client-side encryption

La client-side encryption, abbreviata CSE, è un modello in cui la cifratura dei dati avviene direttamente sul dispositivo dell’utente: browser, smartphone o client email. Il dato viene trasformato in forma cifrata prima ancora di essere inviato al server.

Nel caso di Gmail, questo significa che il contenuto dell’email e gli allegati sono cifrati in locale; i server Google ricevono e memorizzano solo dati cifrati. Google non possiede le chiavi per leggerli, quindi non può accedere al contenuto in chiaro.

Questo è il primo pilastro della soluzione: spostare la cifratura dal server al client elimina una delle principali superfici di rischio tipiche dei servizi cloud.

Il ruolo della CSE in Gmail

La CSE è il meccanismo che rende possibile parlare di protezione avanzata in Gmail. Senza CSE, la cifratura resterebbe limitata al trasporto dei dati tramite protocollo TLS.

Quando l’utente attiva la modalità protetta, il client Gmail esegue tre operazioni fondamentali: prima cifra il contenuto del messaggio con una chiave simmetrica temporanea; poi protegge quella chiave utilizzando la chiave pubblica del destinatario; infine invia tutto ai server Google.

Da quel momento, Google conserva solo dati cifrati. Nessuna operazione lato server consente di recuperarli in chiaro.

Rispetto a una crittografia end-to-end classica, come quella usata da OpenPGP o da strumenti di messaggistica come Signal, le differenze sono eventi quando ci si concentra sulla gestione delle chiavi.

In Gmail, le chiavi non restano esclusivamente sotto il controllo diretto degli utenti. Entrano in gioco servizi esterni di gestione chiamati Key Access Control List Service (KACLS): sono sistemi che conservano le chiavi e decidono chi può utilizzarle.

Quando un destinatario apre un messaggio, il client Gmail deve richiedere la chiave al servizio esterno. Solo dopo una verifica di identità e delle policy, la chiave viene rilasciata e il contenuto può essere decifrato in locale.

Perché CSE non è sinonimo di E2EE

La CSE descrive dove avviene la cifratura: sul dispositivo. Non dice nulla su chi controlla le chiavi nel tempo. Una E2EE rigorosa richiede che solo mittente e destinatario possano accedere alle chiavi, senza intermediari. CSE, invece, può essere implementata anche con un sistema centralizzato di gestione delle chiavi.

Gmail sfrutta proprio questa possibilità: combina cifratura lato client con controllo centralizzato delle chiavi. Il risultato è una protezione forte, ma non completamente autonoma.

Questa architettura risponde a esigenze precise: le imprese devono poter revocare accessi, applicare policy e rispettare normative. Con una gestione centralizzata delle chiavi, è possibile bloccare l’accesso a un utente, registrare le operazioni e integrare la cifratura con sistemi di identità aziendali.

Una soluzione come OpenPGP non offre queste possibilità in modo nativo: la perdita di controllo sulle chiavi equivale alla perdita di accesso ai dati, senza possibilità di intervento. La CSE consente quindi un equilibrio tra sicurezza e governabilità: i dati restano cifrati, ma l’accesso può essere gestito.

Chi gestisce la CSE in Gmail

La cifratura lato client in Gmail non è gestita direttamente da Google né dagli utenti finali: il controllo, come evidenziato in precedenza, è nelle mani dell’organizzazione che utilizza Google Workspace. Ed è per questo che la soluzione crittografica della società di Mountain View, adesso integrata anche in Android e iOS, è compatibile soltanto con la suite Google Workspace.

L’attivazione della funzionalità passa infatti dalla console amministrativa: l’amministratore deve abilitare esplicitamente la CSE e configurare un’infrastruttura per la gestione delle chiavi. Gmail non crea né conserva le chiavi crittografiche: si limita a usare KACLS, che può essere implementato dall’azienda stessa o da un provider compatibile.

Quando il destinatario utilizza Gmail con CSE abilitata, il flusso resta interno all’applicazione. Il messaggio cifrato arriva nella casella di posta come una normale email, ma il contenuto viene decifrato localmente solo dopo che il client ha ottenuto la chiave dal servizio esterno.

Dal punto di vista dell’utente, non cambia nulla: nessun portale, nessuna procedura aggiuntiva. Tuttavia, dietro le quinte avviene comunque una richiesta al sistema di gestione delle chiavi, che verifica i permessi.

Perché la CSE è legata a Google Workspace

La cifratura lato client di Gmail dipende da una serie di componenti che esistono solo nell’ambiente Google Workspace. Il punto centrale è la gestione delle chiavi, che non avviene automaticamente ma richiede un’infrastruttura dedicata.

Ogni organizzazione deve configurare un servizio esterno per la gestione delle chiavi, definire le policy di accesso e integrare il sistema con un provider di identità. Senza questi elementi, la cifratura non può funzionare.

Un account Gmail gratuito non dispone di questi strumenti: non esiste una console amministrativa, né un sistema per controllare le chiavi o applicare regole di accesso.

Cosa succede sugli account Gmail gratuiti e su Google Workspace con CSE disattivata?

Nella configurazione standard di Gmail, quella utilizzata dagli account gratuiti e da tutti gli ambienti Workspace in cui la CSE non è attiva, il modello di sicurezza cambia in modo significativo e segue logiche molto diverse rispetto alla cifratura lato client.

Quando un’email viene inviata tramite Gmail, il primo livello di protezione è il protocollo TLS: il messaggio viaggia cifrato tra il dispositivo dell’utente e i server Google, e successivamente tra i server Google e quelli del destinatario (tranne alcune eccezioni, ovvero quando l’altra parte non supporta TLS).

L’uso di TLS impedisce a soggetti terzi di intercettare facilmente i dati durante il trasferimento: tuttavia, la protezione vale solo “in transito”. Una volta arrivato ai server, il messaggio torna disponibile in forma leggibile per il provider.

Una volta ricevuto, il messaggio viene memorizzato nei data center Google con cifratura a riposo: la società guidata da Sundar Pichai utilizza sistemi avanzati per proteggere i dati, ma la differenza rispetto alla CSE è netta. Le chiavi crittografiche sono infatti gestite da Google stessa: dal punto di vista tecnico, il contenuto delle email può essere decifrato all’interno dell’infrastruttura del provider.

Conclusioni

La cifratura introdotta in Gmail rappresenta un’evoluzione rispetto al modello tradizionale basato su TLS e cifratura lato server, ma va interpretata con precisione per evitare fraintendimenti. L’uso del termine E2EE da parte di Google è tecnicamente difendibile, ma si basa su una definizione più ampia rispetto a quella adottata nei sistemi completamente decentralizzati.

Nel modello Gmail con CSE, le chiavi non sono sotto il controllo diretto degli utenti, ma sono gestite tramite infrastrutture esterne configurate dalla singola organizzazione.

Ne deriva un sistema ibrido: i dati sono protetti lato client e Google non può accedervi, ma l’accesso resta governato da un’infrastruttura centralizzata. È una scelta progettuale precisa, orientata alle esigenze delle aziende più che a quelle degli utenti individuali.

Al di fuori di questo scenario, Gmail continua a utilizzare un modello basato sulla cifratura in transito e a riposo, con gestione delle chiavi interamente affidata al provider stesso.