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:

il nome del file contenente la chiave privata; e,
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).