In questa argomentazione vedremo come è possibile garantire l'autenticità di un messaggio.
Ci sono essenzialmente due modi:
- l'autenticazione simmetrica
- la firma elettronica
L'idea di base è autenticare un messaggio sfruttando un codice di autenticazione. Nell'autenticazione simmetrica questo avviene attraverso l'uso di cifrari simmetrici come DES
o AES. Mentre nella firma elettronica avviene attraverso cifrari asimmetrici come RSA. Vediamo prima come potrebbero essere sfruttati i cifrari che conosciamo per l'autenticazione.
Autenticazione mediante chiave simmetrica...
Consideriamo il caso in cui due utenti condividono una chiave simmetrica che consenta loro di cifrare/decifrare i messaggi scambiati.
Immaginiamo un messaggio
Inoltre,
Tuttavia dobbiamo approfondire un attimo la questione:
Una soluzione potrebbe essere quella di considerare autentico, solo un certo numero di pattern di bit. Se il numero di pattern accettati dal sistema è abbastanza alto, la probabilità di ottenere un messaggio non sensato sarebbe molto bassa.
Un'altra soluzione è quella di forzare il messaggio in chiaro ad avere una certa struttura facilmente riconoscibile, ma che non possa essere replicata senza ricorrere alla funzione di cifratura. Per esempio, si potrebbe aggiungere un error-detecting code, anche noto come frame check sequence (FCS), o ancora checksum, ad ogni messaggio prima che avvenga la cifratura. Ecco un esempio:
- il checksum viene aggiunto al messaggio
- l'intero blocco
Quando
Ricordiamo che la funzione
Autenticazione mediante chiave pubblica...
L'uso della chiave pubblica fornisce confidenzialità, ma non autenticazione.
Infatti, la sorgente
Per fornire autenticazione, il mittente
Assumendo che esiste una struttura tale da poter autenticare correttamente il messaggio, allora la cifratura asimmetrica è in grado di fornire autenticazione. Oltre a questo, però, questo schema fornisce anche un'altra cosa, nota come firma digitale: solo
Notiamo anche che questo schema non fornisce confidenzialità, poiché il messaggio cifrato con
Per ottenere sia confidenzialità, che autenticazione e firma digitale,
Message Authentication Code (
Un'alternativa tecnica di autenticazione coinvolge l'uso di una chiave segreta per generare un piccolo blocco di dati di dimensione fissa, tale blocco è noto come
Il messaggio, con l'aggiunta del
- Il destinatario è sicuro che il messaggio ricevuto non è stato alterato, poiché se il messaggio viene alterato nel corso della trasmissione verso
- Il destinatario è sicuro che il messaggio arriva dal mittente
La funzione utilizzata per la generazione del
Il
- attraverso DES e CBC
- attraverso una funzione di hash.
Questa tecnica è stata largamente utilizzata per diversi anni per autenticare, in ambito governativo, i dati scambiati. L'algoritmo utilizza CBC con le operazioni di DES. I dati (da autenticare: qualsiasi tipo) sono raggruppati in blocchi di 64 bit contigui:
- Il messaggio viene cifrato con DES-CBC
- Si utilizza l'ultimo blocco cifrato o parte di esso come
L'immagine del libro indica il
Il
Il codice serve per autenticare, se il ricevente ricevesse un messaggio modificato, il
Inoltre, non è possibile generare messaggi falsi, senza conoscere la chiave usata per generare il
Data una funzione di hash resistente alle collisioni, si genera il MAC applicando la funzione al messaggio e alla chiave segreta.
Esempio...
Il messaggio viene suddiviso in blocchi:
l'ultimo blocco potrebbe venire riempito con degli zeri (padding) per raggiungere la dimensione di
Definiamo
Definiamo
Definiamo anche delle costanti chiamate
Le costanti vengono ripetute per
Sicurezza...
HMAC on opportune scelte per la funzione H è ritenuto sicuro contro attacchi di tipo chosen message.
La generazione di collisioni è possibile, tuttavia risulta non possibile autenticare il messaggio utilizzando la chiave, che in teoria è segreta solo a chi comunica.
HMAC è efficiente quanto la funzione di hash che viene utilizzata (due volte, dove la seconda viene applicato ad un input più corto, vedi immagine sotto).
Nell'immagine sotto 
Firma elettronica...
L'autenticazione dei messaggi protegge le due parti comunicanti da manomissioni per mani di terzi. Tuttavia, essa non protegge le due parti da loro stessi.
Per esempio, supponiamo che John invia un messaggio autenticato a Mary, usando uno degli schemi sopra discussi, di cui mostriamo una panoramica di seguito, combinato con un MAC (DESC-CBC o HMAC):
Consideriamo la seguente disputa, che potrebbe nascere:
- Mary potrebbe creare un messaggio diverso e affermare che provenga da John. Mary dovrebbe semplicemente creare un messaggio e aggiungergli un codice di autenticazione usando la chiave che sia John che Mary condividono.
- John potrebbe negare l'invio di tale messaggio. Perché è possibile per Mary (ma anche per John stesso) creare messaggi con le caratteristiche sopra evidenziate. Effettivamente non ci sarebbe modo di provare che John non ha inviato tale messaggio.
In una situazione in cui non vi è piena fiducia tra chi invia i messaggi e chi li riceve è necessario avere qualcosa in più di una semplice autenticazione, ovvero la firma elettronica, le cui caratteristiche sono elencate di seguito:
- deve verificare l'autore e la data e l'orario della firma
- deve autenticare i contenuti al momento della firma
- deve essere verificabile da parti terze per risolvere eventuali dispute.
La firma elettronica è ottenibile in due modi:
- RSA con MD5/SHA-1
- DSA con SHA-1 (che non vedremo)
RSA con MD5/SHA-1...
Il messaggio
Con questo procedimento si ottengono:
- un procedimento di firma pari a quello reale, ma in forma virtuale
- il concetto di NO-repudation: il mittente non può ammettere di non aver inviato un dato messaggio.
La chiave pubblica del mittente è nota a tutti, in tal caso si dice che la firma è opponibile a terzi: chiunque può svolgere l'operazione di verifica (e questo rispecchia anche la realtà nel mondo reale).
Problemi della firma digitale...
L'attacco del compleanno è possibile...
Il mittente cifra il messaggio
- prende
- prende un
- trova una collisione e convince il mittente a firmare il messaggio falsificato (non sempre possibile poiché entra in gioco il fattore umano)
Per il paradosso del compleanno, ovvero nel caso in cui
L'attacco è possibile, poiché la firma è pubblica; con l'utilizzo di un
Attacco man-in-the-middle...
Un utente terzo (
Firma digitale e firma elettronica sono utilizzati in modo intercambiabile.
Esistono diversi tipi di firma, che forniscono livelli di sicurezza differenti.
Ricapitolando, la firma digitale è ottenebile:
- firmando un dato con la chiave privata (vulnerabile a MITM descritto sopra);
- firmando un dato con la chiave privata per poi cifrarlo con la chiave pubblica del destinatario (sicuro, ma non protegge i partecipanti alla comunicazione da sé stessi)
- generando un HMAC a partire da un dato con una funzione hash (attraverso una chiave simmetrica condivisa tra i partecipanti della comunicazione), firmando con la chiave privata tale HMAC e inviando i dati a destinazione.
Distribuzione di chiavi pubbliche...
Sono state proposte diverse tecniche per la distribuzione delle chiavi pubbliche.
Idealmente tutte le proposte possono essere raggruppate nei seguenti schemi:
- Annuncio pubblico;
- Directory disponibile pubblicamente
- Autorità di chiavi pubbliche
- Certificati di chiavi pubbliche
Annuncio di chiavi pubbliche...
A prima vista, può sembrare ovvio, in una cifratura a chiave asimmetrica rendere pubblica la chiave pubblica.
Come abbiamo visto questo risulta essere un problema per l'attacco man in the middle che abbiamo visto sopra.
Directory disponibile pubblicamente...
Un maggior grado di sicurezza può essere raggiunto mantenendo una directory dinamica delle chiavi pubbliche che sia pubblicamente disponibile. La distribuzione e il mantenimento di tale directory dovrebbe essere compito di un'organizzazione fidata.
Un tale schema includerebbe i seguenti elementi:
- L'autorità mantiene una directory con una entry per ciascun partecipante del tipo: nome, chiave pubblica.
- Ogni partecipante registra una chiave pubblica con l'autorità responsabile della directory. La registrazione dovrebbe avvenire di persona o con qualche forma di comunicazione sicura e autenticata.
- Un partecipante può sostituire la chiave esistente con una nuova quando vuole, sia per voglia che perché, per esempio, la sua chiave privata (collegata a tale chiave pubblica) è stata compromessa.
- I partecipanti potrebbe anche accedere alla directory elettronicamente. A questo scopo l'ente potrebbe cifrare i dati con la sua chiave privata e renderli disponibili agli utenti che possiedono la sua chiave pubblica.
Questo schema è più sicuro degli annunci pubblici individuali, ma ha ancora delle vulnerabilità. Se l'attaccante riesce a calcolare/ottenere la chiave privata dell'autorità, allora l'attaccante potrebbe distribuire chiavi pubbliche contraffatte, impersonando qualsiasi partecipante e intercettare i messaggi inviati a qualsiasi partecipante.
Autorità delle chiavi pubbliche...
Una maggiore sicurezza per la distribuzione delle chiavi pubbliche può essere ottenuta fornendo un controllo più stringente sulla distribuzione delle chiavi pubbliche dalla directory.
Uno scenario tipico è illustrato di seguito:
Un'autorità centrale mantiene una directory che contiene le chiavi pubbliche degli utenti.
Inoltre, come prima, si suppone che ogni partecipante conosce una chiave pubblica dell'autorità.
Seguono i passi:
- A invia un messaggio con timestamp all'autorità delle chiavi pubbliche contenente una richiesta della chiave pubblica attuale di B.
- L'autorità risponde con un messaggio che è cifrato usando la chiave privata dell'autorità (
- la chiave pubblica di B;
- la richiesta originale fatta da A all'autorità, per confrontare la risposta con la richiesta e verificare che non sia stata manomessa;
- il timestamp originale dato in modo che A possa determinare che questo non è un vecchio messaggio dell'autorità contente una chiave diversa dalla chiave pubblica di B.
- A memorizza la chiave di B e la usa per mandargli messaggi
- B richiede la chiave di A per rispondergli
- L'autorità risponde come nel punto 2
A questo punto entrambi gli utenti hanno le chiavi e possono comunicare.
Si noti che i passi per ricevere la chiave non devono essere effettuati sempre, i comunicanti possono salvare la chiave, tuttavia dovranno comunicare con l'autorità per verificare l'autenticità e la validità della chiave.
Certificati di chiave pubblica...
Lo scenario descritto prima è interessante, ma ha alcuni svantaggi.
Come prima per la directory pubblica dell'autorità è vulnerabile a manomissione.
Un altro approccio consiste nei certificati che possono essere usati da partecipanti per scambiare chiavi senza contattare l'autorità delle chiavi pubblica, ma come se fossero ottenute da essa. In sostanza un certificato consiste di:
- una chiave pubblica
- un ID del proprietario
- e l'intero blocco firmato da una terza parte fidata.
Tipicamente, la terza parte è un'autorità di certificazione (Certificate Authority, CA), come un'agenzia governativa.
Un utente può presentare la sua chiave pubblica alla CA e ottenerne un certificato.
Dal certificato si vede che vi è la firma della CA che può essere usata per verificare la validità della chiave.
Un utente può comunicare il suo certificato ad altri utenti che possono effettuare verifiche simili da esso.
Vogliamo ottenere che:
- qualsiasi partecipante deve poter leggere un certificato per determinare il nome e la chiave pubblica del proprietario del certificato;
- qualsiasi partecipante deve poter verificare che il certificato provenga dalla CA e non sia contraffatto;
- solo la CA deve poter aggiornare i certificati.
Il timestamp contrasta il seguente scenario:
la chiave privata di A viene rubata. A genera una nuova coppia di chiavi e se le fa certificare. Nel frattempo l'attaccante si spaccia per A, potendo leggere i messaggi che sono destinati ad A.
A ha cambiato chiave, ma il suo vecchio certificato è ancora in circolo. Entra in gioco il timestamp: ad un certo punto esso non verrà aggiornato e il certificato scadrà ed esso non sarà più valido.
I certificati più recenti, consentono anche di aggiungere i certificati (se il proprietario lo richiede) in una lista di certificati revocati, consentendo agli utenti di verificare che il certificato per quell'utente non sia stato revocato, superando il limite precedentemente descritto.
Di seguito uno scenario che riassume il funzionamento delle PKI:
Consideriamo che Alice abbia bisogno di usare la chiave pubblica di Bob per inviargli un messaggio. Alice deve prima ottenere in modo affidabile e sicuro una copia della chiave pubblica della CA. Questo può essere fatto in diversi modi, dipende dalla politica della CA in questione.
Fatto ciò Alice verifica che la chiave di Bob sia ancora valida e che non sia stata revocata, se è ancora valido, Alice ottiene una copia del certificato di Bob (che contiene la chiave pubblica di Bob). Ora Alice può usare la chiave pubblica di Bob per inviargli un messaggio. Bob può anche utilizzare la sua chiave privata per firmare digitalmente dei documenti, in questo caso Bob può includere, insieme al documento firmato, il suo certificato, o presumere che Alice abbia modo di ottenerlo (come abbiamo descritto poco prima, per esempio).
Per verificare la firma di Bob, Alice utilizza prima la chiave pubblica della CA per garantire che il certificato sia valido, poi utilizza la chiave pubblica di Bob (ottenuta dal certificato) per verificare la firma di Bob, confermando l'autenticità del documento.