LEZIONE 14 · DAL CONCETTO ALLA SCELTA

Quattro scenari, quattro confini di fiducia

Scegliere un algoritmo viene dopo aver capito chi può vedere i dati, chi deve poterli modificare e quali evidenze servono. Le tecniche studiate si combinano, ma non diventano intercambiabili.

Chi?

Utenti, dispositivi, operatori dei servizi e possibili avversari.

Che cosa?

Una decisione motivata su dati, chiavi, identità e prove.

Quando?

Prima dello sviluppo e ogni volta che cambiano minacce, protocolli o durata della protezione.

Dove?

Nei confini tra browser, server, dispositivi personali e servizi esterni.

Perché?

La frase «è cifrato» è incompleta senza dire contro chi, dove e con quali chiavi.

1. Pagare su un sito

Scenario didattico realistico. Alice inserisce dati nel browser. HTTPS autentica il dominio e protegge il collegamento verso il punto che termina TLS. Il server riceve normalmente il contenuto in chiaro per elaborarlo. L’autenticazione di Alice e la sua autorizzazione a disporre il pagamento sono controlli ulteriori.

Domanda decisiva: il certificato copre il dominio che intendeva raggiungere? Un avversario che controlla il sito o il codice della pagina può leggere ciò che Alice digita anche se la connessione è cifrata. Strumenti: TLS, gestione sicura della sessione, controlli applicativi e conferma dell’operazione.

2. Messaggistica con cifratura end-to-end

Cifratura end-to-end, o da estremo a estremo, significa che il contenuto è protetto tra i dispositivi dei partecipanti e non viene normalmente decifrato dal servizio intermedio. È una proprietà dell’architettura e del protocollo, non il nome di un singolo cifrario. Le applicazioni possono combinarla con accordi di chiave e rinnovi frequenti dei segreti.

Domanda decisiva: come si autenticano i dispositivi e che cosa accade ai backup? Un backup con chiavi accessibili al fornitore può avere un confine di fiducia diverso dalla chat. Un dispositivo compromesso può mostrare i messaggi già decifrati. Anche con contenuto protetto possono restare metadati su orari, volumi e contatti. Non si può attribuire a ogni prodotto la stessa garanzia senza leggerne il protocollo.

3. Un backup di cartelle cliniche

Il dato è sensibile e deve restare recuperabile. Uno schema autenticato protegge contenuto e alterazioni; la chiave va custodita e ripristinata con controlli adeguati. Si può usare envelope encryption: una chiave per i dati viene protetta da una seconda chiave di custodia. I due livelli hanno ruoli diversi e agevolano la gestione, ma non eliminano l’esigenza di autorizzare gli accessi.

Domanda decisiva: chi potrà decifrare fra cinque anni, e chi potrà distruggere tutte le copie? Un ransomware è un software ostile che può rendere indisponibili dati o sistemi e richiedere un riscatto. Cifrare il backup non impedisce di cancellarlo. Servono copie isolate, permessi separati e prove di ripristino: la disponibilità non nasce dall’algoritmo.

4. Un aggiornamento software firmato

Il dispositivo deve installare solo pacchetti autorizzati, non tenerli necessariamente segreti. La firma copre dati e metadati previsti dal sistema; il verificatore usa una chiave già fidata e controlla destinazione, versione e scadenze. La distribuzione può usare anche HTTPS, ma la firma resta verificabile dopo il download.

Domanda decisiva: che cosa succede se rubano la chiave del produttore? Servono procedure per revoca, rinnovo, distribuzione di nuove chiavi e recupero. Un file malevolo firmato con una chiave compromessa può superare una verifica matematica corretta.

Una frontiera reale: la transizione post-quantistica

Un computer quantistico sufficientemente potente e corretto negli errori potrebbe attaccare i problemi matematici su cui si basano RSA ed ECC. Questo non implica che ogni chiave sia oggi già recuperabile o che tutti gli algoritmi vadano trattati allo stesso modo. Il rischio harvest now, decrypt later consiste nel raccogliere oggi traffico da decifrare in futuro, importante per segreti di lunga durata.

Nel 2024 il NIST ha pubblicato i primi standard di questa serie: ML-KEM per incapsulamento di chiavi, ML-DSA e SLH-DSA per firme. Un KEM, Key Encapsulation Mechanism, permette a un soggetto di incapsulare un segreto per il possessore di una chiave privata; non è un cifrario da applicare direttamente a un grande file. Annuncio NIST degli standard FIPS 203, 204 e 205.

La crypto-agility è la capacità progettata di cambiare algoritmi, parametri e chiavi senza ricostruire ogni componente. Richiede un inventario degli usi, formati versionati e migrazioni verificate. Non significa permettere liberamente algoritmi deboli in una negoziazione.

La griglia da riutilizzare in un progetto

Gli scenari sono applicazioni didattiche di architetture realmente usate, non cronache di incidenti specifici. Fonti, standard e correzioni. Continua con il laboratorio e gli esercizi di progettazione.