Skip to content

Approfondimenti Network Security

Lab

True / False

Crittografia in pratica - Qualche dettaglio

L'uso "pratico" della crittografia si basa su molti dettagli non presentati nel corso. In questa sezione sono discussi alcuni di questi molto brevemente ed in maniera molto semplificata. Possono essere utili se qualcuno vuole "provare ad usare" qualche strumento software.

Rappresentazione e memorizzazione delle chiavi

Una chiave crittografica, in pratica, viene memorizzata in un file.

Esistono molti formati diversi per rappresentare una chiave crittografica. Alcuni di questi formati sono testuali, altri sono binari.

Quando si usa uno strumento crittografico, occorre verificare in quale formato esso si aspetta di ricevere la chiave. Tipicamente uno strumento accetta molti formati che possono essere specificati con un flag di input opportuno. Se la chiave che si ha a disposizione è rappresentata in un formato diverso da quelli attesi dallo strumento, allora la chiave deve essere convertita di formato con un software appropriato.

Alcuni formati molto comuni sono:

  • PEM Formato testuale (file con questo formato hanno tipicamente estensione .pem, .crt, .key). Usato spesso per la crittografia a chiave pubblica e per i certificati. Tipicamente inizia con una linea BEGIN e termina con una linea END. La chiave è rappresentata in formato Base64-encoded.
  • DER Formato binario (file con questo formato hanno tipicamente estensione .der, .cer). Usato spesso per certificati e per chiavi private.

Ci sono molti altri formati, ad esempio PKCS#8, PKCS#12, quelli usati dai software SSH, dai software GPG ed altri.

Protezione chiavi con password

I file che memorizzano chiavi private di solito sono associati ad una password. Per usare una chiave privata contenuta in file è necessario dimostrare la conoscenza della password corrispondente. Il solo diritto di accesso in lettura al file, quindi, non è sufficiente per usare la chiave contenuta nel file.

Ad esempio, un software che deve usare una chiave privata deve ricevere in input:

  1. il nome del file contenente la chiave privata; e,
  2. la password per quel file.

I dettagli realizzativi di questo meccanismo di protezione non fanno parte di questo corso. Non sono banali: come fa il software di verifica a conoscere la password corretta?

Tentativo di risposta: la memorizza nello stesso file. Ciò non avrebbe senso: chi ha diritto di accesso in lettura al file potrebbe leggerne il contenuto e quindi ottenere la password; pertanto la protezione del file con password sarebbe inutile.

Chi è interessato trova alcune note in questa pagina.

Mode of operation

In breve: se viene chiesto di specificare un "mode of operation" in una operazione crittografica, scegliere CCM oppure GCM. Il motivo è riassunto in forma intuitiva qui di seguito.

Esistono molti algoritmi di crittografia a chiave privata. Quelli più comunemente usati sono detti block ciphers perché operano su blocchi di byte, cioè prendono in input una sequenza di byte di lunghezza fissa e forniscono in output una sequenza di byte della stessa lunghezza.

Gli algoritmi block ciphers possono essere configurati per funzionare in vari modes of operation che differiscono nelle modalità con le quali i blocchi di ciphertext sono ottenuti dai blocchi di plaintext. Ad esempio:

  • nel mode of operation EBC ogni blocco di plaintext è crittato in modo indipendente da tutti gli altri blocchi;
  • nel mode of operation CBC ogni blocco di plaintext viene crittato dopo averne calcolato lo XOR con il precedente blocco di ciphertext (quindi ogni blocco di ciphertext dipende da tutti i blocchi di ciphertext precedenti).

Le proprietà di sicurezza dei block ciphers nei confronti di un network attacker dipendono dal mode of operation usato:

  • Forniscono secrecy, authentication, integrity: CCM, CWC, EAX, GCM, IAPM, OCB.
  • Forniscono solo secrecy (quindi sono raramente usati in pratica): ECB, CBC, CFB, OFB, CTR.

Per comprendere cosa significano esattamente authentication e integrity, indichiamo con PT, KT e BT il plaintext, la chiave, il ciphertext sul lato trasmittente e con PR, KR, BR quelli sul lato ricevente.

Immaginiamo che l'operazione di decryption abbia avuto successo, cioè il ricevente ha BR, lo decritta con KR ed ottiene PR senza nessuna indicazione di errore.

Authentication e integrity significano che è matematicamente certo che KR=KT e che BR=BT. In altre parole, la chiave usata dal ricevente è identica alla chiave usata dal trasmittente (la chiave è autentica) ed il ciphertext ricevuto è identico al ciphertext trasmesso (il ciphertext è integro). Un network attacker quindi non può generare un ciphertext che sarà accettato dal ricevente (perché non conosce la chiave KR che il ricevente userà in decryption) e non può modificare il ciphertext trasmesso senza che il ricevente rilevi la modifica in decryption.

Nei mode of operation che forniscono solo secrecy, invece, non è matematicamente certo che KR=KT e che BR=BT. Anche se la decryption con KR ha avuto successo, è cioè possibile che BR sia stato generato con una chiave diversa da KT (non è garantito che la chiave sia autentica) o che BR sia diverso da BT (non è garantito che il ciphertext sia integro).

Ulteriore complicazione.

Se provate ad usare un mode of operation che garantisce solo secrecy ed a modificare il ciphertext, vedrete che la decryption fallisce quasi sempre, nonostante il mode of operation non garantisca integrity.

Ciò non è in contraddizione con quanto sopra descritto: "molte modifiche" al ciphertext sono rilevate in fase di decryption; è però sempre possibile trovare modifiche al ciphertext che non sono rilevate in fase di decryption. Trovarle può essere più o meno facile. E' molto facile usando il mode of operation ECB (quello sopra descritto, in cui ogni blocco di plaintext è crittato in modo indipendente da tutti gli altri blocchi). Se fate qualche prova con ECB vedrete infatti che non è difficile applicare modifiche al ciphertext che non provocano errore in decryption.

Ulteriore, finale complicazione. Le modifiche al ciphertext in ECB che non provocano errore in decryption forniscono un plaintext difficile da prevedere a priori: talvolta un plaintext composto da un solo carattere o qualcosa di analogo. Un network attacker tipicamente vorrebbe modificare il ciphertext in modo che il plaintext sia esattamente una sequenza di byte scelta dall'attacker stesso. Trovare la modifica al ciphertext che oltre a non provocare errore in decryption fornisce un "chosen plaintext" è ancora più complicato (ma nei mode of operation che forniscono solo secrecy la possibilità di riuscirci non può essere esclusa matematicamente).

Crittografia nella storia

Come è facile immaginare, esistono moltissimi aneddoti e riferimenti sull'uso della crittografia nella storia. Ne riporto qui solo alcuni secondo me molto interessanti:

  • Codici e Segreti di Simon Singh Testo divulgativo bellissimo e molto appassionante. Consigliatissimo per chi è interessato a questi argomenti.
  • Enigma Romanzo di spionaggio che si svolge a Bletchley Park durante la seconda guerra mondiale, nel gruppo di persone impegnate a tentare di decrittare le trasmissioni di Enigma. Da questo romanzo è stato tratto un film, ma il romanzo è infinitamente migliore. _Da non confondere con il film The Imitation Game

Duemila morti a causa di una trasmissione di prova con Enigma

(mio blog post del 2013)

Quando parlo di crittografia a Reti di Calcolatori I descrivo in modo intuitivo ed informale un requisito di base di ogni algoritmo: la conoscenza del testo cifrato non deve fornire nessuna informazione sul corrispondente testo in chiaro o sulla chiave utilizzata.

La macchina cifrante Enigma non aveva questa proprietà. Anche per questo motivo gli Alleati hanno vinto la seconda guerra mondiale. Ed anche per questo motivo, i padri ed i nonni di alcuni di noi sono andati incontro ad una tragedia terribile, la battaglia navale di Capo Matapan.

Immaginate di essere a bordo di una nave militare in tempo di guerra, in mezzo alle acque gelide del Mar Mediterraneo. Su di una nave impossibilitata a muoversi. Di notte e al buio. Immaginate poi di attendere per ore i soccorsi, senza sapere se arriveranno prima i soccorsi o il nemico. Immaginate poi di sentire arrivare un convoglio navale e di vedere la vostra nave che lancia un razzo di segnalazione pensando che siano i soccorsi. Immaginate poi di rendervi conto che si tratta del nemico. Poi arrivano le cannonate. Cannonate che pochi minuti dopo arrivano anche verso il convoglio di soccorso. Totale di morti stimato circa duemilatrecentotrenta.

Cosa c'entra Capo Matapan con il requisito di cui sopra ? Enigma non aveva quella proprietà. Gli Inglesi intercettevano continuamente il traffico radio Enigma ed erano quindi in grado di estrarre informazioni sulla chiave utilizzata. Ciò non assicurava automaticamente la possibilità di decrittare il traffico: l'estrazione di informazioni era manuale, osservando le trascrizioni senza senso del traffico cifrato; il traffico era tantissimo; la chiave cambiava ogni giorno. Quando andava bene (per loro) riuscivano a ridurre molto il numero delle chiavi possibili in base alla mera analisi manuale e poi le provavano tutte, usando a tale scopo il primo calcolatore mai realizzato ("Colossus").

Una crittoanalista inglese, analizzando il traffico intercettato del giorno, si accorse che quasi certamente era la cifratura del testo "LLLLLLLLLLLLLLL": una trasmissione di prova da parte di operatori italiani che stavano provando Enigma. Ciò le permise di restringere grandemente l'insieme di chiavi del giorno---proprio perché il traffico cifrato Enigma forniva informazioni sul testo in chiaro e sulla chiave. Il che permise agli Inglesi di decrittare i messaggi crittati in quella chiave. Il che portò alla terribile tragedia di Capo Matapan.

HTTPS

Attacco MITM su HTTP ad un candidato presidenziale in Egitto

Gli esempi reali di attacchi MITM sono tantissimi. Nel corso viene mostrato che HTTP non offre nessuna difesa nei confronti di questi attacchi.

Un esempio recente e molto rilevante è stato reso pubblico da Google Threat Analysis Group in collaborazione con The Citizen Lab (Settembre 2023). E' stato installato un malware per sorvegliare le attività di un candidato alle elezioni presidenziali in Egitto (mai dimenticare cosa è accaduto in Egitto a Giulio Regeni). L'installazione del malware avviene con un meccanismo non discusso in questo corso, cioè lo sfruttamento di vulnerabilità nei browser (tema analizzato nel corso di Cybersecurity nella Laurea Magistrale). Ci basti sapere che il procedimento di attacco si basa su quanto segue:

  1. il browser segue un link HTTP;
  2. l'attaccante MITM effettua una redirect verso un sito web controllato dall'attaccante ed in grado di infettare il browser;

"When Eltantawy (il candidato presidenziale) visited certain websites not using HTTPS, a device installed at the border of Vodafone Egypt’s network automatically redirected him to a malicious website to infect his phone with Cytrox’s Predator spyware."

Il punto 2 è tecnicamente possibile perché il link è HTTP, quindi la comunicazione tra browser e web server non ha nessuna garanzia di autenticazione ed integrità (oltre che di riservatezza). Se il link fosse stato HTTPS allora questo meccanismo di attacco non avrebbe funzionato.

Tutti i dettagli su: