Supponiamo due soggetti, diciamo Alice e Bob, debbano tenere una conversazione, scambio di messaggi, e che i due debbano affrontare una serie di problemi, quali:
- non si sono mai incontrati né hanno mai concordato alcunché
- hanno esigenza di confidenzialità in relazione ai contenuti della conversazione.
Sono due requisiti del tutto tipici che due soggetti (persona / persona, persona / macchina o macchina / macchina) debbano trovarsi improvvisamente nella condizione descritta, accade quotidianamente e ne è l’esempio principale la rete internet: quando usiamo il browser per visionare un sito web abbiamo il caso macchina / macchina, che potrebbe essere anche considerato persona / macchina, in quanto c’è spesso una persona dietro al browser. La conversazione, nel caso del web, è lo scambio di dati che avviene secondo le regole del protocollo http(s).
Il secondo requisito viene richiesto frequentemente, in base alla natura dei dati scambiati e ai requisiti personali o di legge. In aggiunta oggi si è andata diffondendo una cultura più estremista, fortemente protettiva della privacy, che per default sceglie la confidenzialità.
Benvenuti a “Privatlandia”, il paese dove la privacy ha la massima priorità (ma non esiste)
Tale cultura non è tuttavia oggi ancora abbastanza consolidata, rimanendo l’utente finale spesso ignaro dei meccanismi lesivi della sua privacy insiti nel normale browsing.
Il modello, che astrae dai dettagli e che viene in genere usato dagli accademici, è mostrato in Figura 1. La freccia orizzontale che collega Alice e Bob va intesa come collegamento logico, che può far uso di Wifi e/o connessioni cablate. L’attaccante, spesso indicato come Trudy (intruder), ha la capacità di intervenire su tale collegamento, in modalità sia attiva che passiva. In particolare, quest’ultima è in genere relativamente semplice e non richiede grandi competenze.
Trudy può ascoltare (sniffare, o eseguire eavesdropping) frammenti o sessioni intere e memorizzare le informazioni catturate. Questo è il significato della freccia verticale ad indicare la capacità di Trudy di agire su una tratta di comunicazione ed intercettare i pacchetti inviati. Nei modelli più complessi può diventare attiva ed agire in generale come Man in The Middle).
Con il termine cifratura (o encryption) indichiamo il processo che prende in input un file, chiamato plaintext, e produce in output altro file, detto ciphertext, con contenuto inintelligibile. La trasformazione usa un algoritmo di cifratura invertibile. Dato cioè il ciphertext, deve essere possibile, sotto certe condizioni che specificheremo tra poco, ricostruire il plaintext. Sarà utile chiarire che osservare il contenuto di un ciphertext è un po’ come osservare il contenuto di un file compresso, che, come si dice, contiene molta entropia.
Dal modello si evince che qualora Alice e Bob scambino messaggi senza cifratura, o in chiaro o plaintext, sarà relativamente semplice per Trudy impadronirsi del loro contenuto. Si noti che anche il ciphertext può essere ulteriormente cifrato, in questo caso diremo che diventa il plaintext corrispondente ad altro ciphertext.
Il modello generale di encryption è descritto nella Figura 2. In particolare, notiamo che Alice produce un plaintext che va in pasto a un algoritmo di cifratura. Da questo fuoriesce del ciphertext, che viene spedito in rete e arriva presso Bob, dove è presente un algoritmo di decifratura (o decryption), capace di trasformare il ciphertext nel plaintext originale.
Da notare come i due algoritmi prendano in input anche delle chiavi (nella Figura 2 sono, “chiave 1” e “chiave 2”) che sono sequenze di bit arbitrarie, di lunghezza prefissata, tenute segrete, che abilitano il corretto funzionamento degli algoritmi.
Ovviamente Alice conoscerà “chiave 1” e Bob “chiave 2.” Qualora accada che “chiave 1” sia uguale a “chiave 2” si parla di cifratura simmetrica, che è anche la più usata ai fini della confidenzialità. In tal caso parleremo semplicemente di “chiave” condivisa fra Alice e Bob. Attenzione, se si decifra con una chiave errata gli algoritmi produrranno lo stesso un risultato, che sarà però errato.
Un requisito che dovrebbe essere soddisfatto dalla chiave è che tutte le sequenze di bit (2n, se sono costituite da n bit) siano possibili ed equiprobabili. Viene usato il condizionale “dovrebbe” perché, qualora non lo fosse, sarebbe più facile per Trudy scoprire la chiave e decifrare il ciphertext (che è quanto effettivamente trasmesso e quindi facile da intercettare). Una tecnica ampiamente usata è quella di ottenere una chiave a partire da una password (usando una password based key derivation function, che è essenzialmente una funzione di hashing di qualità crittografica).
Una password è molto più semplice da ricordare rispetto ad una chiave, essa è anche scrivibile attraverso la tastiera, cosa non vera per una chiave. Il problema è che anche l’avversario può usare la password based key derivation function e, indovinando la password, potrà trovare la chiave. Ci sono due possibili (e frequenti) attacchi: a forza bruta o a dizionario. L’attacco a forza bruta è un attacco esaustivo, dove l’avversario genera tutte le possibili chiavi, per questo si sceglie n abbastanza grande per far sì che il loro numero sia eccessivo rispetto il potere computazionale dell’avversario. Ad esempio, con n = 128 bits avremmo 2128 chiavi differenti. Oggi tale numero è eccessivo, a maggior ragione con chiavi di 256 bits.
Nell’attacco a dizionario si usa la key derivation function (che è nota, secondo quanto previsto dall’approccio open security, opposto all’approccio security by obscurity) dandole in pasto tutte le parole di una lingua, elencate in un file detto dizionario.
Per ogni parola si tentano anche alcune varianti usando maiuscole/minuscole, sostituendo ‘0’ con ‘o’, ‘1’ c ‘i’, eccetera: per esempio, “cibo” diventa “C1b0”). Il numero di casi che vengono esaminati dall’avversario è enormemente ridotto e le sue chance di successo sono molto buone (anche non sapendo la lingua di riferimento). Talvolta, le password vengono concatenate con una manciata di bits casuali generati lato server, che prendono in questo caso il nome di sale (o salt).
Si noti che Trudy durante il suo attacco non avrà necessariamente garanzia del fatto di aver trovato la chiave. Infatti, se il plaintext è una frase di un qualche linguaggio è relativamente facile rilevare il successo, ma nel caso il plaintext sia una lista di numeri (come una lista di coordinate) l’uso di una chiave errata produrrà comunque un risultato interpretabile come lista di numeri: solo che in tal caso la lista sarà errata e l’attaccante non avrà necessariamente a disposizione un meccanismo di verifica di successo/insuccesso, a meno che non si usi una cifratura autenticata, sulla quale tornerò più avanti.
Va precisato che si usa anche la cifratura asimmetrica (dove “chiave 1” è diversa da “chiave 2”, ma le due chiavi sono collegate da una relazione matematica), ma il caso più interessante è quello chiamato “a chiave pubblica,” che è alla base del meccanismo della firma digitale.
Crittografia, ecco i nuovi paradigmi per tutelare i nostri dati
Tipi di cifratura
Vogliamo qui affrontare i due tipi di cifratura simmetrica che oggi tipicamente prendiamo in considerazione. A flusso o a blocco. Essi si pongono inizialmente in contraddizione (ossia l’uno esclude l’altro) ma poi vedremo che possono essere riavvicinati.
A flusso
Nella cifratura a flusso (o stream cipher) si assume che il plaintext venga cifrato interamente, indipendentemente dalla sua lunghezza. Notevoli in tale area sono stati i contributi di Claude Shannon, un ingegnere e matematico americano venuto a mancare a inizio millennio. Egli dimostrò che in un cifrario a flusso la lunghezza della chiave non può essere inferiore a quella del plaintext; per questo, piuttosto che parlare di chiave, si parla di keystream. L’operazione usata è l’ex-or bit a bit fra plaintext e keystream. Un caso particolarmente interessante è costituito da One-time pad, un cifrario (cioè un algoritmo di cifratura) che, nella condizione di keystream casuale, è un perfetto. Viene definito perfetto un cifrario nel quale la visione del chipertext non dà informazioni sul plaintext corrispondente. Ciò significa anche che, nonostante l’opinione diffusa, One-time pad non è propriamente perfetto, perché la visione del ciphertext permette di conoscere la lunghezza del plaintext.
Il fatto che i cifrari a flusso richiedessero chiavi potenzialmente di qualsiasi lunghezza ne ridusse l’uso effettivo. Si tenga presente che una chiave estremamente lunga potrebbe essere il prodotto di un algoritmo che genera bitscasuali, il cui input sia una password condivisa.
A blocco
In questo caso un algoritmo di cifratura a blocco, o block cipher, ha la capacità di cifrare un input di lunghezza predefinita (e tipicamente piccola, come un centinaio di bits) e produrre un output della stessa lunghezza. Un blocco è un frammento di file (plaintext o ciphertext) avente quella lunghezza.
Lo schema di cifratura è sempre quello nella Figura 2, ma in tal caso la questione che sorge in modo naturale è: come cifrare un file di dimensione arbitraria? La risposta a questa domanda è meno ovvia di quanto possa sembrare e sarà oggetto di attenzione nel prossimo paragrafo.
Modi operativi
Si chiamano modi operativi quelle tecniche che standardizzano il modo in cui un file di dimensione arbitraria possa essere cifrato tramite un cifrario a blocchi. Non si considerano per cifrari che nascono a flusso.
L’approccio più naturale è sconsigliato. Supponiamo di indicare con “l” la lunghezza (in bit) del file da cifrare e con “m” la dimensione del blocco. Un tentativo naturale è frammentare il file originale in él/mù blocchi, prolungando l’ultimo blocco, di dimensione verosimilmente inferiore a m, con una serie di zeri (padding) fino a raggiungere la dimensione m. Ciò fatto si può pensare di cifrare separatamente ciascun blocco, di dimensione esattamente eguale ad m. Tale approccio prende il nome di Electronic codebook (Ecb).
L’interesse di Ecb è prettamente didattico, perché il suo uso comporta diversi problemi:
- blocchi di plaintext eguali vengono cifrati in blocchi di ciphertext eguali, quindi, non si celano patterns del plaintext
- la lunghezza del ciphertext è eguale a quella del plaintext (dopo il padding), permettendo all’avversario di conoscere la lunghezza del plaintext
- cifrando più volte lo stesso plaintext si otterrà lo stesso ciphertext, consentendo all’avversario di sapere che il messaggio non è cambiato. Il modello dell’avversario è tale da considerare un successo qualunque informazione, totale o parziale, ottenuta sul plaintext.
Uno dei modi operativi ancora oggi molto usati è il Cipher block chaining (Cbc) in cui la cifratura è sequenziale (non la decifratura). Più precisamente, nel cifrare un certo blocco di plaintext, all’operazione di cifratura si antepone lo ex-or fra il blocco corrente (di plaintext) e il precedente (di ciphertext), è il risultato di tale ex-or che viene cifrato (e combinato allo stesso modo con il blocco successivo), producendo un blocco di ciphertext.
Ciò è ovviamente possibile per tutti i blocchi tranne che per il primo (perché non esiste in quel momento un blocco di ciphertext precedente), per cui si usa una stringa iniziale (denominata Initialization vector o, più brevemente, Iv) generata casualmente ad ogni cifratura.
Si capisce che Cbc previene il primo e l’ultimo dei tre problemi enunciati poco sopra. Infatti il chaining utilizzato distrugge i pattern e l’Iv ogni volta casuale farà generare un ciphertext differente anche a parità di plaintext.
Per prevenire secondo problema è utile preprocessare il plaintext, ad esempio tentandone una compressione (misura efficace anche per Ecb). La Figura 3 mostra l’architettura logica di Cbc per la cifratura, un’architettura leggermente modificata permetterà la decifratura.
C’è una relazione fra Cbc e la filosofia stream cipher ma sarà più semplice e diretta l’analisi tramite un altro modo operativo: Ctr.
Da blocco a flusso
Il modo “counter” (Ctr) rappresenta un’alternativa (ce ne sono molte altre) interessante, soprattutto perché menzionato come standard per l’algoritmo di cifratura AES (il migliore che abbiamo) e perché oggi ispiratore di modi più moderni tesi ad ottenere una authenticated encryption.
Ctr trasforma una cifratura a blocchi in una a flusso, operando attraverso lo schema illustrato nella Figura 4.
Se consideriamo solo la parte inferiore, come mostrato nella Figura 5, abbiamo un semplice schema a flusso, in cui l’intero plaintext, inutilmente suddiviso in blocchi, viene combinato in ex-or con un keystream (proveniente dalla parte alta della Figura 4).
L’immediata conseguenza è che in fase di decifratura occorrerà produrre lo stesso keystream e quindi si dovrà egualmente ricorrere a degli encryptor. Proprietà notevole è che quindi si cifra e si decifra sempre usando degli encryptor.
Molti modi operativi gestiscono gli encryptor a blocco in modo da sfruttare, più o meno con qualche diversa sfumatura, l’approccio dei cifrari a flusso, che sono molto meno utilizzati in via diretta.
Password, come gestirle per evitare problemi: miti da sfatare, regole da seguire
Generazione/scambio chiavi
Ho già parlato in altre occasioni della differenza fra password e chiave e sempre in favore di quest’ultima. È essenziale che se la chiave è composta da k bit allora le 2k possibili chiavi debbono poter essere tutte generate con la stessa probabilità (che è 1/2k). Ciò non vale per le password, che debbono essere scrivibili con la tastiera.
Un approccio molto comune è quello di partire da una password, magari salted, lasciando che sia la macchina a proporre il salt attraverso un Csprng, ossia una categoria di algoritmi tesi a generare in modo pseudo-casuale numeri o bit. Tale password viene usata come input per una opportuna funzione hash crittografica o un Csprng, per produrre in output una chiave ragionevolmente rispettosa dei requisiti di equi-probabilità.
Ciò che è comune a tutta la cifratura simmetrica è il fatto che Alice e Bob devono usare la stessa chiave. Questo genera il problema per cui Alice e Bob debbano concordare (o scambiare, come si usa dire) una chiave. Ma come affrontare il problema dello scambio, che è alla base della condivisione della chiave simmetrica? Alice e Bob possono essere due soggetti che non si sono mai incontrati e che si trovano a migliaia di chilometri di distanza.
Tralasciando l’ovvio (incontro fisico tra le parti, precedente al colloquio cifrato) quali approcci si usano oggi? Due soprattutto. Il primo, basato su un celebre risultato di Diffie e Hellman, vede le parti conversare pubblicamente, convergendo, mediante l’uso di tali informazioni pubbliche, alla stessa chiave segreta. A parte la matematica coinvolta, su cui sorvolerò, l’azione principale condotta dalle parti è la scelta, per ciascuna parte, di un numero segreto (e non confidato a nessuno). Chiamiamolo s. Alice, quindi, invierà a Bob il risultato y di gs mod p ed altrettanto farà Bob, scegliendo un s’ (g e p sono pubblici). Le chiavi calcolate autonomamente da Alice e Bob (usando y‘ per gs‘ mod p) sono:
ys’ mod p = y’s mod p = gss’ mod p
Nella realizzazione del metodo Diffie-Hellman si otterranno diversi benefici evitando di maneggiare numeri enormi (risultato delle potenze), ma anticipando, ed eventualmente ripetendo più volte, l’operazione mod p, che ha come risultato un numero inferiore a p.
Il successo dell’approccio si basa sul fatto che il pubblico, che vede ogni messaggio scambiato, incontra un problema troppo difficile per cui, a partire dai valori di y, si voglia risalire ad s (si tratta di calcolare un logaritmo discreto, assai complesso). Lo scambio di chiavi Diffie-Hellman è oggi usato con numerose varianti, che hanno comunque in comune l’idea di base. Si è anche diffusa l’opinione che il metodo non sia più robusto come una volta.
Un altro approccio, altrettanto popolare, è lo scambio chiavi basato su Rsa. Questo è un cripto sistema asimmetrico basato su chiavi pubbliche. Come è noto, Rsa è alla base della firma digitale (e del non-ripudio) e ha la caratteristica che cifrando con una chiave si possa decifrare con l’altra. Più precisamente, l’approccio consiste in cifrare non con la chiave privata (ottenendo quindi non-ripudio), ma con la chiave pubblica, cosicché solo il legittimo detentore della corrispondente chiave privata possa decifrare.
Normalmente Rsa non viene usato ai fini della confidenzialità, a causa di numerosi problemi: oneroso, lungo, nocivo alle batterie del dispositivo in uso. In più la durata della cifratura (e della corrispondente decifratura) è proporzionale alla lunghezza del documento cifrato. Si tratta inoltre di un cifrario a blocchi, che necessita dunque di un modo operativo. Tutti elementi che contribuiscono a tralasciarlo nei casi in cui occorra la confidenzialità, a vantaggio di altri metodi.
C’è tuttavia un caso in cui gli elementi citati non sono troppo gravosi: l’invio in confidenzialità di una chiave simmetrica. Tale idea è alla base del secondo tipo di scambio chiave, in cui la generazione stessa è demandata ad una delle parti, che poi invierà all’altra parte la chiave stessa in maniera confidenziale tramite Rsa. In questo caso gli elementi a sfavore che abbiamo elencato non sono completamente applicabili. In particolare, la dimensione del plaintext sarà assai piccola, per cui le operazioni di cifratura e decifratura possono avvenire con relativa rapidità. Limitato sarà anche il consumo di batteria. Spesso, sarà necessario l’invio di un solo blocco. Tale idea è anche alla base del celebre protocollo Pgp.
Esistono modi più sofisticati per scambiare una chiave (si consideri Kerberos), ma questi sono usati più raramente e in contesti specifici.
Firma digitale, la guida tecnica completa: tutti gli aspetti matematici le applicazioni
Esempi pratici con Openssl
Come è noto, il software Openssl costituisce ampia libreria di riferimento, pubblica e Open source. A lei e, al celebre software Apache usato per i web servers, si deve la notorietà dell’approccio Open.
Esistono oggi varie fork del software – progetti nuovi che affondano le proprie radici in uno precedente – che tuttavia non ne stravolgono le modalità d’uso. Per tale ragione farò riferimento alla versione originale, il cui ultimo rilascio risale a luglio 2022, ed è la versione 3.0.5.
Supponiamo di iniziare volendo cifrare un file file.txt. La riga di comando di openssl può essere la seguente (non è unica)
>openssl aes-128-cbc -p -in file.txt -out file.txt.enc
In tale riga chiediamo di cifrare il file in input (-in file.txt) utilizzando il metodo Aes con chiave a 128 bit e con modo operativo Cbc(aes-128-cbc). Chiediamo anche di mettere il ciphertext in un file di output (-out file.txt.enc) e di mostrarci i parametri crittografici impiegati (-p). Di seguito sono mostrati i dettagli dell’interazione.
enter AES-128-CBC encryption password:
Verifying – enter AES-128-CBC encryption password:
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
salt=3A533406CAA0000E
key=3451042BF001E948863D0ED83E199EEC
iv =C78AAA86869ADD12870ECC6690E4B57E
Sono necessari alcuni commenti. Innanzitutto, viene richiesta una password usata per derivare una chiave (indicata in esadecimale come key). La derivazione viene fatta attraverso una Kdf che il comando non ha indicato in maniera esplicita: ebbene il warning ottenuto ha avvisato del fatto che è stata usata “per default” una Key derivation function (Kdf) oramai deprecata, consigliandone altre (come ad esempio pkdvf2). La libreria ha generato un sale (salt) indicandolo in esadecimale (non si tratta di informazione confidenziale).
Allo stesso modo ha generato un Iv (necessario per Cbc), anch’esso descritto in esadecimale (si tratta di 128 bit); anche l’Iv non è confidenziale (ma è casuale). La chiave key è presentata in esadecimale e, in questo caso, si tratta di informazione confidenziale. Da notare che chiave e Iv hanno la stessa dimensione, poiché Aes è stato scelto con chiave a 128 bit e la dimensione standard del blocco di Aes è anch’essa 128 bit.
Possiamo chiedere l’uso di una migliore Kdf con:
>openssl aes-128-cbc -p -pbkdf2 -in file.txt -out file.txt.enc
ottenendo
enter AES-128-CBC encryption password:
Verifying – enter AES-128-CBC encryption password:
salt=606CD8C3779496BA
key=87BE49954FF954F4C3533ADFE68A1F13
iv =792F643F30DA4CFA4E96D0E2B00CAE0E
Si vede che il warning è scomparso avendo aggiunto l’opzione -pbkdf2. A ribadire la generazione casuale di sale e Iv proviamo a ripetere lo stesso comando sullo stesso file con la stessa password:
>openssl aes-128-cbc -p -pbkdf2 -in file.txt -out file.txt.enc
enter AES-128-CBC encryption password:
Verifying – enter AES-128-CBC encryption password:
salt=3A348FD5F8059B7F
key=011A3EF307ABBEDAD32F99C8914E69E6
iv =F2A5CF57C25B8335F7B289B59B7AD6CB
I parametri crittografici sono ovviamente mutati.
Esaminiamo ora le prime quattro righe del ciphertext usando hexdump (visualizzatore esadecimale di qualsiasi file)
hexdump -C file.txt.enc | head -n 4
Otteniamo le seguenti righe
00000000 53 61 6c 74 65 64 5f 5f 3a 34 8f d5 f8 05 9b 7f |Salted__:4……|
00000010 2a 00 fc 0c 53 1a 7c db 54 fb 8d 7b 6e f2 f7 50 |*…S.|.T..{n..P|
00000020 6d 0a e8 98 30 84 26 a1 6b 57 0a fb f2 31 12 ec |m…0.&.kW…1..|
00000030 f0 9c f5 7d 26 f2 af 59 76 75 8e c8 4f f8 62 3d |…}&..Yvu..O.b=|
In questa visualizzazione possiamo notare che i primi bytesdel file file.txt.enc (le cifre iniziali di ogni riga indicano l’offset esadecimale rispetto l’inizio del file) contengono i codici Ascii di Salted__, il che è uno standard per Openssl: indica il fatto che alla password è stato aggiunto un sale specificato immediatamente dopo la parola Salted__ e questo sale si può vedere consistere dei simboli esadecimali 3a 34 8f d5 f8 05 9b 7f che coincidono esattamente con l’ultimo sale generato.
A partire dalla seconda riga abbiamo il ciphertext vero e proprio. Il significato di tutto ciò è che a partire dalla password data dall’utente è stato generato un sale casuale che, assieme alla password, è diventato l’input della Kdf. È stato prodotto materiale casuale da tale funzione che include Iv e chiave, operazione che può essere ripetuta dall’altra parte della comunicazione, a partire dalla stessa password.
Sia chiaro che le scelte sul sale e sull’uso della Kdf sono arbitrarie da parte di Openssl, che producendo file cifrati che iniziano con Salted__ determina il fatto che solo openssl, o libreria compatibile, sarà in grado di gestire automaticamente il ciphertext. È anche possibile modificare il comportamento della libreria fornendo già sale, Iv e/o chiave sulla linea di comando, o anche la richiesta di non usare sale. Su tali dettagli non è però interessante approfondire.
Livelli logici di intervento
Un tema assai scarsamente descritto è relativo a come impiegare la cifratura per ottenere la confidenzialità. Possiamo immaginare di sapere tutto sulla cifratura e ancora rimangono questioni irrisolte. La domanda da porre è a quale livello dobbiamo operare la cifratura?
Dimentichiamo dunque i dettagli tecnici ed operativi e parliamo in generale della cifratura. Ci sono essenzialmente tre livelli di intervento.
Cifratura volumi/file system
Con tale dizione facciamo riferimento al fatto che, in maniera del tutto invisibile, i dati che stanno per essere trascritti su disco vengono automaticamente cifrati subito prima della trascrizione. Sicché sul disco saranno scritti dati cifrati. Similmente, effettuando una operazione di lettura da disco, il materiale recuperato verrà automaticamente decifrato, portando dunque nella memoria Ram solo plaintext. La presenza della cifratura è di fatto invisibile all’utente.
In tal caso abbiamo un tipo di cifratura che protegge solo dal furto del disco (l’attaccante troverà ciphertext e in molte circostanze la chiave simmetrica usata non è scritta sul disco). Tale protezione è considerata insufficiente poiché in genere la compromissione dell’host determina anche la compromissione della chiave simmetrica (che non essendo su disco sarà detenuta nella Ram).
Poco importa come sia ottenuto un tale tipo di cifratura poiché l’effetto finale è lo stesso. Ci sono in verità due modi, che possono essere impiegati in disgiunzione o in congiunzione. Nel primo, si decide di impiegare volumi auto cifranti, che sono volumi che in hardware automaticamente gestiscono le operazioni di cifratura/decifratura: qualunque cosa venga scritta sul disco essa subisce automaticamente tale trattamento.
Nel secondo si ricorre a una soluzione software che vede il disco, o qualche sua partizione, subire opportune formattazioni, in grado di supportare cifratura/decifratura automatiche fatte dal sistema operativo. Il fatto che sia possibile impiegare simultaneamente le soluzioni non incrementa la sicurezza, rimanendo in essere il problema fondamentale legato alla compromissione dell’host.
Data base management system (DBMS), cosa sono e come sceglierne uno
Cifratura del database
In questo caso si suppone che le informazioni oggetto di confidenzialità vadano immagazzinata in uno o più databases. Come è noto, un database viene costruito utilizzando un Database management system (Dbms) e, notoriamente, ce ne sono molti di differenti vendor in circolazione. Alcuni di essi hanno iniziato a poter gestire un modulo aggiuntivo, da integrare nel Dbms, che esegue la cifratura/decifratura dei dati presenti nel Dbms stesso.
In questo caso, un operatore potrà utilizzare i dati presenti nell’host ma non potrà accedere ai database cifrati se non fornendo una chiave (o password). Tale possibilità non è permanente.
Ne deriva che i dati cifrati attraverso un Dbms continuano ad essere robusti rispetto al furto del disco, poiché cifrati, ed abbastanza robusti rispetto la compromissione dell’host, in quanto, a meno che essa non avvenga durante il breve periodo in cui la chiave di cifratura/decifratura si trova nella Ram, non produrrà l’automatica compromissione della chiave.
Cifratura utente
Si tratta di una cifratura richiesta esplicitamente dall’utente, che fornirà una password o una chiave. Si tratta di una soluzione ad hoc da applicare su singoli file non più automatica. Il vantaggio è che è l’utente a stabilire singolarmente i casi in cui sia necessaria la confidenzialità ed è lui stesso a gestire la chiave.
Lo svantaggio è che viene a mancare un automatismo, per cui l’utente chiamato a decide in merito alla confidenzialità può commettere errori, magari per difficile interpretazione delle policy aziendali o per pura distrazione.
Si potrà pensare che nel dubbio sia meglio cifrare tutto, ma certe azioni, in casi specifici, come ad esempio l’utilizzo di dati che nascono e rimangono pubblici, possono essere considerate controproducenti. Per esempio, ci si può chiedere quale sarebbe il motivo di cifrare una norma di legge, che per definizione nasce pubblica.
Altro svantaggio è la naturale propensione dell’essere umano a gestire in modo non sicuro la chiave (potrebbe essere rivelata o persa). In ogni caso questa soluzione appare essere la più sicura fra quelle considerate.
Si capisce che la questione è non solo tecnica ma deve vedere i vertici dell’organizzazione decidere policies chiare e illuminate. La questione non può essere demandata al personale IT (che sa cifrare ma non sa stabilire policy correttamente). È perciò richiesta una buona governance della sicurezza, esercitata dalle figure apicali. È opportuno considerare la figura del Ciso (Chief information security officer) che stabilisca le policies e/o espleti le funzioni di raccordo fra il Ceo (Chief executive officer), l’area IT e l’area utenti non informatici.
Cifratura autenticata
Abbiamo già fatto riferimento alla cifratura autenticata (authenticated encryption): ci si riferisce con tale dizione alla volontà di soddisfare simultaneamente due dei requisiti più importanti della sicurezza delle informazioni: confidenzialità e autenticità.
Mentre l’argomento confidenzialità è approssimativamente coperto dal presente articolo, l’autenticità (forma avanzata di integrità) è stata curata in questo articolo. Le trattazioni sono tuttavia autonome, considerando un requisito alla volta. Interessante e frequente è il caso in cui entrambi i requisiti debbano essere soddisfatti.
A tale proposito sono stati creati modi operativi che consentono di cifrare con cifrari a blocchi e allo stesso tempo di curare l’autenticità attraverso il keyed hashing.
Uno degli esempi più notevoli è Gcm: il Galois/Counter Mode. Appartiene all’approccio EtM, che vede effettuare dapprima una cifratura e poi calcolare un codice di autenticazione sul ciphertext. Non tratteremo i dettagli matematici di Gcm, ma vale la pena dire che oggi è molto usato Aes con tale modo operativo.
La cifratura autenticata esiste anche nella variante cosiddetta Aead (Authenticated encryption with associated data), cioè cifratura autenticata con dati associati, in cui si immagina che il messaggio contenga una parte confidenziale e una parte pubblica.
In questo caso si gestisce la cifratura della parte confidenziale e la validazione dell’integrità dell’intero messaggio. Sia l’Unione europea sia il National Insitute of Standards and Technology (agenzia governativa Usa) sono alla ricerca di nuove forme di standardizzazione per l’Aead.
Conclusioni
Ci siamo addentrati un po’, ma non troppo, all’interno di questo affascinante mondo della cifratura e abbiamo compreso come ai fini della confidenzialità ricorriamo alla cifratura simmetrica.
Lasciamo a quella asimmetrica (a chiave pubblica) il compito di trasmettere chiavi simmetriche cifrate. Lo scambio chiavi può avvenire anche con Diffie-Hellman: una variante frequentemente usata, ai fini di abbreviare la grandezza dei valori in gioco, è l’uso delle curve ellittiche, che tuttavia qui non considereremo, non introducendo novità sostanziali nel metodo impiegato.
Le curve ellittiche sono di sovente impiegate nella crittografia a chiave pubblica. Il modello generale in cui abbiamo definito i ruoli di Alice e Bob gode di comode proprietà, tali da renderlo di riferimento anche nei casi in cui la connessione fra i due non sia costituita dalla rete, essendo i due soggetti componenti dello stesso host. Tecniche di cifratura più avanzate, come quella omomorfica, saranno considerate in una futura occasione.
