Principi di progettazione dei protocolli sicuri

La progettazione di protocolli sicuri presuppone un avversario che controlla completamente la rete. Il modello di Dolev-Yao (1983) specifica che l'avversario può intercettare, leggere, ritardare, riprodurre, eliminare e modificare qualsiasi messaggio in transito. L'avversario può generare messaggi indistinguibili da quelli delle parti oneste. Può comporre nuovi messaggi a partire dai componenti già noti. Non può violare le primitive crittografiche (decifrare senza la chiave o falsificare le firme). È fondamentale che l'avversario sia limitato computazionalmente, cioè operi in tempo polinomiale, ma controlli tutti i canali di comunicazione. La sicurezza del protocollo consiste nel raggiungere gli obiettivi di autenticazione e segretezza anche contro un avversario così potente, facendo affidamento esclusivamente sulla difficoltà computazionale delle primitive sottostanti.

Abadi e Needham (1994) hanno riassunto le lezioni pratiche sulla progettazione dei protocolli in una serie di principi. (1) Ogni messaggio deve dichiarare il proprio significato: l'interpretazione di un messaggio deve essere autonoma e non dipendere dal contesto. (2) Le condizioni che un'entità deve soddisfare per intraprendere un'azione devono essere dichiarate esplicitamente nel protocollo. (3) Se l'identità di un'entità è importante, deve essere indicata esplicitamente nel messaggio. (4) È necessario chiarire perché viene usata la cifratura: la cifratura garantisce la riservatezza, mentre la firma garantisce l'autenticazione; non si deve usare la cifratura come sostituto della firma. (5) Un messaggio deve essere cifrato al livello del protocollo in cui è necessaria la sua segretezza. Questi principi hanno impedito molti difetti di tipo NS.

Gli attacchi di replay sono tra le vulnerabilità più comuni dei protocolli. I meccanismi di freschezza garantiscono che un messaggio ricevuto sia stato generato di recente e non riprodotto da una sessione precedente. Esistono due approcci: (1) Nonce (Number used ONCE, numero usato una sola volta): un meccanismo challenge-response in cui il ricevente invia un valore casuale e si aspetta di riceverlo ripetuto nella risposta. La risposta deve contenere il nonce cifrato o firmato, impedendo a una vecchia registrazione di soddisfare la sfida. (2) Timestamp: entrambe le parti includono l'ora corrente; un messaggio con un timestamp obsoleto viene rifiutato. I timestamp richiedono orologi sincronizzati (Kerberos tollera uno scarto di 5 minuti). I nonce sono preferibili quando la sincronizzazione degli orologi non è disponibile; i timestamp semplificano la verifica senza stato.

L'uso della stessa chiave crittografica per più scopi crea interazioni pericolose. Se una chiave K viene usata sia per la cifratura sia per l'autenticazione, un avversario potrebbe fornire ciphertext appositamente costruiti al meccanismo di autenticazione per estrarre informazioni. TLS 1.3 evita rigorosamente questo problema tramite HKDF-Expand-Label, usando etichette distinte per ogni chiave derivata: "c hs traffic" (handshake del client), "s hs traffic" (handshake del server), "c ap traffic" (traffico applicativo del client). Anche se la chiave dell'handshake viene compromessa, le chiavi applicative derivate da un ramo HKDF diverso rimangono sicure. La progettazione dei protocolli deve verificare ogni chiave per individuare i rischi di riutilizzo multiplo e derivare chiavi separate per scopi separati.

Le credenziali di autenticazione devono essere associate alla sessione specifica in cui vengono utilizzate. Senza questa associazione, una credenziale ottenuta in una sessione può essere riutilizzata in un'altra. Tecniche: (1) includere gli identificatori di sessione nei dati firmati/protetti con MAC. (2) includere il transcript DH nella firma (approccio STS). (3) usare la chiave di sessione derivata con HKDF per calcolare un MAC sull'identità (approccio SIGMA). Messaggio Finished di TLS 1.3: MAC(server_finished_key, transcript_hash) — il MAC copre l'intero transcript, quindi il riutilizzo di un Finished proveniente da una sessione diversa non va a buon fine. È questa associazione a impedire gli attacchi tra sessioni riscontrati nelle prime versioni di Kerberos e nelle varianti NS.

I protocolli dovrebbero divulgare solo le informazioni minime necessarie al loro funzionamento. Le identità dovrebbero essere rivelate solo a chi ne ha bisogno. Non si dovrebbero includere numeri di serie dei certificati o identificatori che consentano di associare le sessioni alle identità, salvo quando necessario. TLS 1.3 cifra il certificato del server, a differenza di TLS 1.2, in cui è trasmesso in chiaro, riducendo le informazioni a disposizione di un intercettatore passivo. ESNI (Encrypted SNI, ora ECH — Encrypted Client Hello) cifra l'indicazione del nome del server per nascondere a quale server il client si sta connettendo. La divulgazione minima delle informazioni è anche un principio della progettazione dei token: i claim JWT dovrebbero contenere solo ciò che è necessario per l'autorizzazione, non i record completi dell'identità.

La negoziazione della versione è una superficie d'attacco comune: un avversario rimuove o modifica il ClientHello per costringere entrambe le parti a usare una versione del protocollo più vecchia e più debole. Difese: (1) negoziazione autenticata della versione — includere la versione negoziata nel transcript firmato (il Finished di TLS copre il ClientHello, inclusa la versione). (2) Sentinelle anti-downgrade — TLS 1.3 imposta byte magici in ServerHello.Random quando effettua il downgrade a TLS 1.2, consentendo al client di rilevarlo. (3) Prevenzione dell'intolleranza alle versioni — i server devono rifiutare i ClientHello malformati senza ricorrere silenziosamente al fallback. (4) SCSV — TLS_FALLBACK_SCSV segnala al server che il client sta riprovando con una versione inferiore, consentendo al server di rifiutare i fallback illegittimi.

I messaggi del protocollo dovrebbero essere vincolati fin dal primo scambio. La non malleabilità significa che un avversario non può modificare un ciphertext o una firma e farli validare in un contesto diverso. AEAD garantisce la non malleabilità del ciphertext: qualsiasi modifica invalida il tag di autenticazione. A livello di protocollo, l'hashing del transcript assicura che lo scambio Finished alla fine dell'handshake vincoli ogni messaggio inviato. Questo impedisce gli attacchi cut-and-paste: combinare messaggi provenienti da due sessioni diverse non può produrre un valore Finished valido per nessuna delle due sessioni. Gli schemi di commitment (commitment basati su hash) estendono questo principio ai flussi di protocollo che richiedono un pre-impegno prima della rivelazione.

I protocolli complessi spesso falliscono ai confini della macchina a stati. Se una transizione di stato è ambigua — cosa succede se il messaggio 3 arriva prima del messaggio 2? cosa succede se arriva un tipo di messaggio imprevisto? — le implementazioni possono divergere, creando incoerenze che un avversario può sfruttare. Le specifiche del protocollo devono definire: la macchina a stati completa, con tutti gli stati e le transizioni valide; il comportamento in caso di input imprevisti, ad esempio rifiutare con un errore specifico o ignorare silenziosamente; i timeout e i limiti di ritrasmissione; la pulizia della sessione. Storicamente, SSL/TLS ha sofferto di divergenze nelle macchine a stati delle implementazioni — CVE-2014-0160 (Heartbleed) è stato essenzialmente un errore della macchina a stati, in cui una richiesta heartbeat veniva elaborata in uno stato nel quale la memoria non era adeguatamente limitata.

I protocolli crittografici vengono raramente utilizzati da soli. Un protocollo AKE stabilisce una chiave di sessione, che viene poi utilizzata da un protocollo a livello applicativo. Se il protocollo AKE e quello applicativo vengono progettati indipendentemente, senza tenere conto della componibilità, le loro interazioni possono compromettere la sicurezza. Il framework Universal Composability (UC) (Canetti, 2001) fornisce un modello rigoroso per la composizione dei protocolli: un protocollo è sicuro in senso UC se rimane sicuro quando viene composto arbitrariamente con altri protocolli sicuri in senso UC. TLS 1.3, Signal e Noise mirano a garantire la sicurezza componibile. In pratica: utilizzare il channel binding (esportare l'hash del transcript) per collegare la sessione AKE all'autenticazione applicativa successiva, impedendo l'inoltro delle credenziali tra sessioni stabilite dallo stesso protocollo AKE.

I progettisti di protocolli commettono ripetutamente gli stessi tipi di errori. (1) Crittografia fatta in casa: implementare cifrari a blocchi, MAC o derivazione delle chiavi personalizzati senza una revisione da parte di esperti. (2) Fiducia implicita: presumere l'origine di un messaggio in base al contesto di rete anziché a una dimostrazione crittografica. (3) Sicurezza opzionale: rendere configurabili la cifratura o l'autenticazione, portando inevitabilmente a un downgrade. (4) Token di lunga durata senza revoca: emettere JWT o chiavi di sessione con periodi di validità lunghi e senza un meccanismo di revoca. (5) Ignorare il canale degli errori: non autenticare i messaggi di errore consente a un avversario di iniettare errori per influenzare il comportamento del protocollo. (6) Usare la cifratura per l'autenticazione: cifrare i dati non autentica la loro origine senza un MAC o una firma.

La progettazione sicura dei protocolli applica principi consolidati: il modello dell'avversario Dolev-Yao, cioè un avversario che controlla la rete; i principi di Abadi-Needham, ovvero identità esplicita e messaggi autocontenuti; la freschezza mediante nonce o timestamp; la separazione delle chiavi mediante HKDF con etichette distinte; l'associazione delle credenziali di autenticazione alla sessione; la divulgazione minima delle informazioni; la prevenzione dei downgrade mediante l'autenticazione del transcript; la non malleabilità tramite AEAD e hashing del transcript; macchine a stati chiare con gestione degli errori definita; e la componibilità mediante dimostrazioni di sicurezza nel modello UC. Le violazioni di questi principi sono all'origine di quasi tutte le vulnerabilità crittografiche note a livello di protocollo.