Crittografia esterna e chiavi condivise — L'approccio della sovranità dell'utenteCrittografia esterna e chiavi condivise — L'approccio della sovranità dell'utente

Se la porta che ti offre la piattaforma ha una copia della chiave per il guardiano, costruisci la tua porta. Ma ricorda: il guardiano può pretendere che vengano abbattute tutte le porte che non può aprire.

---

C'è un approccio che emerge frequentemente quando si discute di Chat Control con persone tecnicamente informate: e se gli utenti crittografassero i loro messaggi con chiavi che gestiscono loro stessi, al di fuori del controllo della piattaforma?

L'idea è semplice e potente. Invece di affidarsi alla crittografia offerta dalla piattaforma (che la legge potrebbe obbligare a indebolire), gli utenti concordano una chiave tramite un canale esterno e crittografano il contenuto prima che la piattaforma lo tocchi.

Lo schema

Canale esterno:  A —————————[k_AB]——————————→ B
                 (accordo di chiave faccia a faccia, Signal, email crittografata, carta)

                 A scrive M
                 A crittografa M con k_AB → C = E_k_AB(M)
                 A invia C tramite la piattaforma
                 B riceve C
                 B decifra C con k_AB → M

                 La piattaforma vede solo C (dati inintelligibili)

In questo schema:

• La piattaforma riceve $C$, che dalla sua prospettiva è rumore indistinguibile da dati casuali
• La piattaforma non può scansionare il contenuto perché matematicamente non ha accesso a $k_{AB}$
• Il CSAR non può obbligare la piattaforma a decifrare ciò che non può decifrare
• A e B mantengono il controllo totale sulla loro comunicazione

Cosa risolve questo approccio

Cosa non risolve

1. Il problema del rilevamento per alta entropia

Un messaggio crittografato con uno schema robusto produce dati statisticamente indistinguibili da rumore casuale. Una piattaforma che conosce il formato atteso dei suoi messaggi (ad esempio, JSON con campi strutturati) può rilevare facilmente che un messaggio non segue quel formato:

Payload normale di WhatsApp:
    {"key": {"remoteJid":"...","fromMe":true},"message":{"conversation":"Ciao"}}
    Entropia: ~4.2 bit/byte

Payload crittografato esternamente:
    <7e9f2b8a1c4d...  (byte apparentemente casuali)
    Entropia: ~7.9 bit/byte → rilevabile

Se la legge obbliga la piattaforma a bloccare messaggi non scansionabili, questo semplice rilevatore di entropia sarebbe sufficiente per identificare e bloccare questi messaggi.

2. Il problema del canale esterno

L'anello più debole dello schema è lo scambio iniziale di chiavi:

Come concordano A e B k_AB senza usare la piattaforma?
    ├→ Faccia a faccia:    Sicuro, ma non scala
    ├→ Signal:             Sicuro, ma richiede che entrambi usino Signal
    ├→ Email crittografata: Fattibile, ma scomodo
    ├→ WhatsApp stesso:    La piattaforma può intercettarlo
    └→ Carta/Codice QR:    Sicuro, ma poco pratico per contatti frequenti

Perché l'approccio funzioni con contatti non tecnici, lo scambio di chiavi dovrebbe avvenire attraverso la piattaforma stessa, il che reintroduce il problema: se la piattaforma può vedere la chiave, la crittografia esterna è irrilevante.

3. Il problema della legge che chiude la scappatoia

Questo è il punto critico che l'analisi tecnica pura tende a trascurare. Una legge come CSAR non si limita a dire "le piattaforme devono scansionare". Può (e prevedibilmente includerebbe) disposizioni come:

Articolo X: I fornitori dovranno assicurare che tutti i messaggi
trasmessi attraverso la loro infrastruttura siano suscettibili di
rilevamento conformemente agli Articoli Y-Z. È vietata la trasmissione
di contenuto che, per il suo formato o caratteristiche tecniche, impedisca
l'applicazione delle misure di rilevamento obbligatorie.

In questo scenario, la piattaforma sarebbe obbligata a:

1. Rilevare messaggi con entropia insolitamente alta
2. Bloccare la loro trasmissione
3. Segnalare l'utente come "sospetto di elusione"

Confronto con altri approcci

Il problema della massa critica

La crittografia esterna con chiavi condivise funziona perfettamente come misura artigianale per un utente tecnico che:

• Sa generare e gestire chiavi
• Ha contatti che sanno farlo anch'essi
• Accetta l'attrito del processo

Ma non funziona come soluzione sistemica per 500 milioni di europei. La ragione non è tecnica ma strutturale: una legge che richiede scansione sulla piattaforma semplicemente proibirà o bloccherà il traffico che non può scansionare, e la stragrande maggioranza degli utenti non avrà né le conoscenze né la motivazione per adottare un sistema di crittografia esterna.

Piramide degli utenti:
    ▲  ~0.1%  Tecnici avanzati (possibile crittografia esterna)
    ├  ~1%    Tecnici medi (possibile con sforzo)
    ├  ~10%   Utenti consapevoli (non fattibile senza strumento)
    ▼  ~90%   Utenti mainstream (usa ciò che l'app offre)

Se la legge blocca la crittografia esterna, il ~99.9% degli utenti
non avrà protezione. E lo 0.1% sarà rilevabile come "utente che
si protegge", esattamente lo stesso paradosso che Obscura documenta
nel contesto del fingerprinting.

Parallelismo con il paradosso della protezione

Questo approccio soffre della stessa asimmetria che la ricerca di Obscura documenta per l'anti-fingerprinting:

Il difensore deve vincere sempre. L'attaccante ha bisogno di vincere solo una volta.

Nel contesto di Chat Control:

• L'utente deve proteggere tutti i suoi messaggi in modo indistinguibile
• La piattaforma deve rilevare una sola anomalia (un messaggio con alta entropia, un pattern di comunicazione inusuale) per identificare l'utente come "sospetto di elusione"
• Una volta identificato, l'utente può essere oggetto di misure aggiuntive (blocco, segnalazione alle autorità, indagine)

L'analogia con il fingerprinting è quasi perfetta. In Obscura, il proxy doveva normalizzare tutti i segnali per non essere rilevato; qui, l'utente deve fare in modo che tutti i suoi messaggi sembrino messaggi normali della piattaforma, il che è incompatibile con la crittografia esterna.

Conclusione

La crittografia esterna con chiavi condivise è tecnicamente solida come misura di privacy individuale. Se A e B concordano una chiave fuori dalla piattaforma e crittografano i loro messaggi, la piattaforma non può leggerli, scansionarli né segnalarli. Punto.

Ma come soluzione politica e sistemica di fronte a una legge come CSAR, ha tre problemi irrisolvibili:

1. La legge chiuderà la scappatoia proibendo o bloccando i messaggi non scansionabili
2. Lo scambio di chiavi reintroduce il problema per la maggior parte degli utenti
3. L'asimmetria difensore-attaccante rende l'utente rilevabile come "elusore" anche se il suo contenuto è sicuro

Non è un approccio sbagliato. È un approccio che funziona per chi può implementarlo, ma che non può essere generalizzato come alternativa allo scanning di massa. È la differenza tra costruire un rifugio nucleare per la tua famiglia e pretendere che tutta l'umanità viva in rifugi nucleari.

---

Documenti correlati:

• Alternative allo scanning di massa
• Crittografia e sorveglianza — Perché lo scanning di massa rompe l'E2EE
• Chat Control — Definizione e contesto