I Messaggi WhatsApp Sono Veramente Privati? Ecco Cosa Abbiamo Scoperto
Giuseppe Longobardi : 21 Gennaio 2025 07:56
WhatsApp dichiara di adottare un meccanismo di crittografia end-to-end (E2E) basato sul Protocollo Signal (noto precedentemente come “TextSecure Protocol”). L’assunto di fondo di un sistema E2E è che soltanto i dispositivi dei due interlocutori gestiscano le chiavi di crittografia necessarie alla cifratura e decifratura dei messaggi, escludendo chiunque altro (inclusi i server dell’azienda fornitrice).
Tuttavia, i test sperimentali condotti suggeriscono che Meta potrebbe conservare le chiavi utilizzate per crittografare e decrittare i messaggi degli utenti. Questa ipotesi si basa su un’osservazione specifica: la capacità di ricevere messaggi da nuovi contatti su WhatsApp Web o sull’app desktop anche quando lo smartphone è spento.
Questo comportamento indica che le chiavi crittografiche non sono archiviate esclusivamente sugli smartphone, un requisito fondamentale per garantire la crittografia ‘End-to-End’. Infatti, se le chiavi fossero presenti solo sui dispositivi mobili, sarebbe tecnicamente e logicamente impossibile comunicare con nuovi contatti senza il telefono connesso.
Sei un Esperto di Formazione?
Entra anche tu nel Partner program!
Accedi alla sezione riservata ai Creator sulla nostra Academy e scopri i vantaggi riservati ai membri del Partner program.
Per ulteriori informazioni, scrivici ad [email protected] oppure su Whatsapp al 379 163 8765
Supporta RHC attraverso:
Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.
Di conseguenza, il fatto che questa comunicazione avvenga anche a telefono spento dimostra che le chiavi crittografiche potrebbero essere conservate in altri sistemi, non limitandosi ai nostri dispositivi personali.
Queste assunzioni generano forti dubbi sulla reale efficacia del canale E2E e sulla conformità alla stessa Privacy Policy di WhatsApp.
1. Meccanismi di scambio delle chiavi simmetriche (Diffie-Hellman)
1.1 Diffie-Hellman “classico”
Per lo scambio di chiavi simmetriche abbiamo tendenzialmente tre tecniche:
- Offline Distribution
- Public Key Tunneling
- Diffie-Hellman
Usiamo l’offline distribution quando possiamo comunicare verbalmente con un altro soggetto, fornendogli la credenziale senza l’uso di supporti elettronici. Questo chiaramente non è applicabile per comunicazioni da remoto, quindi la quasi totalità.
Per questo motivo è necessario usare una delle altre due opzioni, per la public key tunneling serve un certificato X.509 che contenga la chiave pubblica (come nel caso di HTTPS) o un meccanismo di exchange della chiave pubblica compatibile per entrambi i dispositivi.
Siccome i nostri dispositivi non posseggono un certificato, l’unica tecnica applicabile è la terza, che permette di sfruttare un algoritmo matematico in grado di scambiare chiavi crittografiche senza la necessità di acquistare un certificato firmato da una CA (Certificate Authority) riconosciuta.
Il protocollo Diffie-Hellman (DH) consente a due entità (in questo esempio Alice e Bob) di stabilire una chiave simmetrica condivisa su un canale insicuro:
- Si sceglie un numero primo p di grandi dimensioni e una radice primitiva g modulo p.
- Alice genera un valore privato a e calcola la chiave pubblica A=gamod p
- Bob genera un valore privato b e calcola la chiave pubblica B=gbmod p
- Alice e Bob si scambiano le chiavi pubbliche A e B rispettivamente.
- Alice calcola K = Ba mod p, Bob calcola K = Ab mod p. Entrambi ottengono la medesima chiave condivisa K=gab mod p.
In un contesto di crittografia moderna, questa chiave simmetrica K è poi utilizzata (ad esempio) da un algoritmo AES-256 in modalità GCM o CTR per cifrare il traffico.
1.2 Codice Python esplicativo
#!/usr/bin/env python3
import random
def diffie_hellman_demo():
# Scelta di un numero primo p e di una radice primitiva g (esempio didattico)
p = 23
g = 5
print(f"Valore di p (primo): {p}")
print(f"Valore di g (radice primitiva modulo p): {g}\n")
# Alice genera il proprio valore privato a
# (in uno scenario reale si utilizzano valori molto più grandi e sicuri)
a = random.randint(2, p-2)
print(f"Alice sceglie il valore privato a: {a}")
# Alice calcola la propria chiave pubblica A = g^a mod p
A = pow(g, a, p)
print(f"Alice calcola la chiave pubblica A = g^a mod p: {A}\n")
# Bob genera il proprio valore privato b
b = random.randint(2, p-2)
print(f"Bob sceglie il valore privato b: {b}")
# Bob calcola la propria chiave pubblica B = g^b mod p
B = pow(g, b, p)
print(f"Bob calcola la chiave pubblica B = g^b mod p: {B}\n")
# Alice e Bob si scambiano le chiavi pubbliche A e B (canale insicuro)
# Alice calcola la chiave condivisa K_A = B^a mod p
K_A = pow(B, a, p)
print(f"Alice calcola la chiave condivisa K_A = B^a mod p: {K_A}")
# Bob calcola la chiave condivisa K_B = A^b mod p
K_B = pow(A, b, p)
print(f"Bob calcola la chiave condivisa K_B = A^b mod p: {K_B}\n")
# Verifica che le due chiavi coincidano
if K_A == K_B:
print(f"Chiave condivisa K calcolata correttamente: {K_A}")
else:
print("ERRORE: le chiavi non corrispondono!")
if __name__ == "__main__":
diffie_hellman_demo()
RUNTIME OUTPUT :
Valore di p (primo): 23
Valore di p (primo): 23
Valore di g (radice primitiva modulo p): 5
Valore di g (radice primitiva modulo p): 5
Alice sceglie il valore privato a: 19
Alice calcola la chiave pubblica A = g^a mod p: 7
Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21
Alice sceglie il valore privato a: 19
Alice calcola la chiave pubblica A = g^a mod p: 7
Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21
Alice calcola la chiave pubblica A = g^a mod p: 7
Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21
Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21
Bob sceglie il valore privato b: 13
Bob calcola la chiave pubblica B = g^b mod p: 21
Bob calcola la chiave pubblica B = g^b mod p: 21
Alice calcola la chiave condivisa K_A = B^a mod p: 20
Alice calcola la chiave condivisa K_A = B^a mod p: 20
Bob calcola la chiave condivisa K_B = A^b mod p: 20
Chiave condivisa K calcolata correttamente: 20
1.3 Varianti e Double Ratchet
WhatsApp si basa su un’implementazione evoluta del Protocollo Signal, che sfrutta:
- X3DH (Extended Triple Diffie-Hellman) per la fase di handshake iniziale, in cui si combinano chiavi “a lungo termine” (Identity Key), chiavi “semi-persistenti” (Signed PreKeys) e chiavi effimere (One-Time PreKeys).
- Double Ratchet per la fase di aggiornamento continuo delle chiavi a ogni messaggio o gruppo di messaggi, garantendo forward secrecy e post-compromise security.
Nel modello teorico, l’utente (sul proprio dispositivo) dovrebbe detenere tutte le chiavi private necessarie, mentre il server memorizza soltanto le chiavi pubbliche (prekey) per favorire la consegna dei messaggi offline. L’esperimento mostrato più avanti, però, insinua che WhatsApp gestisca in modo meno trasparente parte delle chiavi di sessione, specie in ambienti multi-dispositivo (app, web, desktop).
2. Architettura di WhatsApp dal punto di vista crittografico
2.1 Struttura multi-dispositivo
In passato, WhatsApp Web agiva come semplice “mirror” dello smartphone primario, richiedendo la connessione attiva del telefono. Con le versioni più recenti, è ora possibile utilizzare WhatsApp Web (O l’app per Desktop) anche se il telefono risulta offline, a patto che sia stato registrato il dispositivo prima dello spegnimento dello smartphone.
Questo cambio di paradigma potrebbe permettere a Meta di memorizzare le chiavi crittografiche degli utenti, rompendo di fatto il vincolo di confidenzialità delle chat propugnato nella Privacy Policy.
2.2 Sincronizzazione chiavi e potenziale “key escrow”
Per rendere operativo questo meccanismo, WhatsApp (Meta) deve memorizzare o sincronizzare parte del materiale crittografico su server propri. Questo processo potrebbe includere alcune PSK (chiavi crittografiche simmetriche) utilizzate per stabilire una chat con un contatto con cui non si sono mai scambiati messaggi prima di spegnere il telefono e messaggiare su whatsapp web.
Se tali chiavi sono accessibili ai server, allora la promessa di una crittografia end-to-end “pura” viene quantomeno scalfita, poiché l’intermediario (Meta) può intervenire o ricostruire una parte delle chiavi.
Le chiavi di cui stiamo parlando sono diverse per ogni contatto e vengono negoziate e scambiate nel primo messaggio ricevuto o inviato da e ad un contatto nuovo.
2.3 Implicazioni di sicurezza
Un server che disponga delle chiavi può, di fatto, decriptare i messaggi o fornirne il contenuto a terze parti. Nel contesto legale, si tratta di una forma non dichiarata di “escrow”. In termini tecnici, questa gestione potrebbe essere giustificata come “necessaria per il multi-device”, ma non rispetterebbe l’idea di E2E in senso stretto.
Meta quindi potrebbe essere in grado di decriptare le nostre conversazioni, le nostre telefonate e persino le nostre foto e video. Questo costituisce un rischio enorme per la privacy degli utenti della piattaforma.
3. Proof of Concept (PoC)
3.1 Scenario
Si vuole mostrare come, per un nuovo contatto (un utente che non ha mai inviato prima messaggi), sia possibile ricevere il primo messaggio direttamente su WhatsApp Web, mentre lo smartphone rimane spento.
3.2 Passi sperimentali
- Autenticazione su WhatsApp Web: prima di spegnere lo smartphone, si effettua il login a WhatsApp Web (QR code).
- Spegnimento del telefono.
- Invio del messaggio: un contatto “mai visto prima” invia il primo messaggio verso l’account WhatsApp in questione.
- Osservazione: su WhatsApp Web, il messaggio appare correttamente, nonostante l’assenza di qualsivoglia scambio di chiavi dal telefono spento.
- Cattura di rete: con Wireshark si analizza il flusso tra il PC e i server WhatsApp, evidenziando che si instaura una sessione cifrata (TLS) ma non risulta alcuna negoziazione implicita con il dispositivo mobile per la generazione di nuove chiavi.
3.3 Conclusioni del test
È evidente che i server di WhatsApp consentano la creazione di una sessione (o il recupero di chiavi preesistenti) anche per i contatti non precedentemente in chat, senza alcuna “nuova” partecipazione del telefono primario. In un sistema E2E puro, invece, la negoziazione iniziale dovrebbe avvenire direttamente tra i due dispositivi coinvolti (mittente e destinatario).
4. Discrepanze rispetto alla Privacy Policy
La Privacy Policy di WhatsApp dichiara testualmente:
“I messaggi e le chiamate rimangono tra te e chi li riceve. Nemmeno WhatsApp può leggerli o ascoltarli, perché sono protetti dalla crittografia end-to-end.”
Tuttavia, il PoC dimostra:
- Possibile conservazione delle chiavi: Le prove indicano che Meta gestisca o memorizzi chiavi (o prekey) in un modo che consenta l’attivazione di nuove sessioni con contatti “mai visti” anche a telefono offline.
- “Key escrow” non dichiarato: Se i server possono ricostruire le chiavi necessarie a decrittare i messaggi, la confidenzialità end-to-end “piena” non è più rispettata.
- Gestione multi-dispositivo poco trasparente: La documentazione fornita da WhatsApp non spiega in dettaglio come e dove vengano mantenute le chiavi.
Conclusioni
L’esperimento illustrato dimostra una caratteristica preoccupante nella gestione delle chiavi crittografiche di WhatsApp. Nel momento in cui si riceve un messaggio da un contatto “mai visto” su WhatsApp Web con il telefono spento, si evidenzia che Meta conserva o è in grado di rigenerare la chiave necessaria all’avvio della sessione cifrata, senza richiedere la partecipazione del dispositivo mobile.
Sebbene WhatsApp affermi di utilizzare il Signal Protocol (rinomato per la robusta E2E) — e in effetti ne adotti gran parte delle tecniche (X3DH e Double Ratchet) — la gestione del multi-dispositivo non è documentata in modo trasparente. Gli utenti non sanno esattamente dove vengano conservate le chiavi, né con quale logica vengano sincronizzate o replicate.
Implicazioni:
- Si configura un potenziale “key escrow” non dichiarato, per cui Meta può (forse su richiesta legale, o per finalità di debug e controllo) accedere al contenuto dei messaggi.
- Questo contrasta con l’idea di un E2E “assoluto”, in cui solo gli endpoint (i dispositivi dei due interlocutori) possiedono i segreti per decrittare i messaggi.
- Vi è una discrepanza evidente con la Privacy Policy di WhatsApp, che suggerisce un’impossibilità da parte di WhatsApp di accedere ai contenuti delle conversazioni.
Giuseppe LongobardiCyberSecurity Manager e ICT Trainer, specializzato in Networking e CyberSecurity. Inventore della web app "OnionCert", registrata alla SIAE con N. Registrazione D000016744, ideatore del "Metodo Longobardi" per il Subnetting ed autore di svariati corsi di formazione in ambito Networking e CyberSecurity. Da sempre seguo progetti di ricerca e sviluppo in ambito Industry 4.0 , Smart City e Blockchain. Credo nello sviluppo continuo di nuove competenze, tecnologie e soluzioni open source. La mia filosofa di vita: "Se i tuoi progetti hanno come obiettivo 1 anno pianta del riso, 20 anni pianta un albero, un secolo insegna a degli uomini"Visita il sito web dell'autore
