UniTO/anno2/YearI/FirstSem/CS/lesson4-30102017.md

Lo scope di una chiave (segreto)

Spesso l'utilizzo di una chiave va ristretto ad un ambito specifico (firmare un programma, stabilire una connessione ssl, accedere a dei servizi, etc).

Esempio: chiave DES

Una chiave DES e' formata da 56 + 8 bit (64), di cui i 56 sono divisi in 8 gruppi da 7 e ad ogni gruppo viene aggiunto l'ottavo bit. Di questi 8 bit, sono 3 sono utilizzati, mentre i restanti 5 sono reserved (per uso futuro).

I 3 bit hanno il seguente valore:

• Il primo e' detto Session Master.
• Il secondo e' una encryption flag (1 se la chiave si puo' usare come encryption key).
• Il terzo e' una decryption flag.

Questo e' un utilizzo piuttosto triviale (anni 80), ma allora era sufficiente.

Esempio: certificati simmetrici

3 componenti principali:

• Master key
• Session key
• Control vector: un vettore che e' hashato con un algoritmo digest alla stessa lunghezza della master key.

La somma del digest del control vector e della master key e' considerata una chiave singola, mentre la session key e' considerata dati. Questo viene inserito in un algoritmo di cifratura ottenendo una encrypted session key.

Per decifrare la session key, e' sufficiente utilizzare la precedente chiave (master+vector) con un decryption algorithm per ottenere la chiave decrittata.

E' importante notare come il segreto in questo approccio sia il control vector: se questo e' sbagliato, non e' possibile cifrare o decifrare la chiave, anche se la master key e' corretta.

Challenge-Response

I protocolli di tipo Challenge-Response sono basati su di una sfida che, una volta lanciata, ottiene una risposta. Questa potrebbe essere sempre diversa, rendendo i protocolli molto resistenti ad attacchi replay.

Contesto: Chiave pubblica

Nel caso della chiave pubblica, non c'e' piu' la necessita' di dialogo singolo con i peer che si ha con la chiave simmetrica. Una chiave pubblica e' condivisa tra tutti i peer che vogliono parlare con un singolo (che si occupa di distribuire la chiave). Questo semplifica l'autenticazione, ma presenta vari svantaggi:

1. Ogni soggetto che vuole permettere l'autenticazione a vari peer dovra' distribuire la propria chiave pubblica a tutti i peer. Questo limita i soggetti che ricevono la chiave: molti non possono riceverla direttamente (fisicamente). Se la chiave viene distribuita con un mezzo (es: email) che e' sensibile al man in the middle, e' possibile che un attacker utilizzi una sostituzione di chiavi per falsificare i messaggi tra il soggetto e il peer.

• Soluzione: public key directory. La chiave non e' distribuita ma memorizzata in una directory, che e' solitamente una TTP (trusted third party). Ogni soggetto memorizza la propria chiave, che quindi e' facilmente ritrovabile dai peer interessati. Vantaggi: la chiave e' memorizzata solo una volta (e non N volte per N soggetti). Questo approccio e' piu' sicuro ma comunque vulnerabile al MITM.

Soluzione 2: public key authority (Needham / Schroeder a chiave pubblica o asimmetrico).

La chiave e' gestita da un'authority, con i seguenti passaggi:

• Il peer A informa l'authority di voler parlare con B, mandando una R(B) richiesta, e un timestamp t1.
• L'authority risponde con la chiave pubblica di B, la richiesta e il timestamp ripetuti, tutto cifrato con la chiave pubblica dell'authority (condivisa a priori). L'authority deve quindi conoscere le chiavi pubbliche di A,B,etc, e le ottiene fisicamente per evitare il MITM.
• Se anche B effettua la stessa richiesta all'authority, entrambi i peer ottengono le chiavi dei rispettivi compagni.
• Una volta che entrambi i peer hanno una public key, la comunicazione viene effettuata con:

1. A->B: Ekb(IDa, N1) dove Ekb e il messaggio cifrato con la pubkey di B, IDa e' l'identificativo di A, e un Nonce N1
2. B->A: Eka(N1, N2) dove B risponde con un Nonce successivo al nonce N1
3. A->B: Ekb(K2) A risponde ripetendo il Nonce ricevuto.

Le precedenti comunicazioni possono avvenire su una rete insicura come internet, perche' sono cifrati da chiavi pubbliche.Questo protocollo e' sicuro ma scomodo (in quanto la richiesta alla TTP va fatta ogniqualvolta che i peer entrano in contatto), e quindi si utilizza un diverso tipo di TTP: la certification authority.

Certification authority

La Certification authority e' una TTP che non fornisce una chiave pubblica ma un certificato di chiave pubblica.

Steps:

1. A manda alla CA il proprio ID e la propria chiave pubblica, al di fuori della rete, su un canale sicuro.
2. CA verifica l'identita di A e spesso anche la conoscenza della chiave privata corrispondente alla pubblica fornita (tramite challenge-response). Questo e' un processo one-time (teoricamente). Risponde tramite la rete con un certificato unico ad A. Questo puo' essere mandato tramite la rete in quanto esso e' chiuso, non modificabile, non segreto. Il certificato contiene l'IDa, la chiave pubblica di A, un timestamp, e altre informazioni importanti riguardanti A. Il certificato e' reso non modificabile tramite la firma della CA.

CertA = SigCA{ IDa, K+a, ts, ... } = I, Ekca(H(I)) dove I e' l'informazione, abbinata a una cifratura con la chiave di CA dell'hash delle informazioni stesse (detta firma).

Un'informazione firmata e' quindi Info+Firma.

3. Una volta che B ha ottenuto il proprio certificato (one time process), A e B possono comunicare semplicemente scambiandosi i certificati. Il MITM non e' piu' effettivo perche' cambiare qualunque parte del certificato ne invalida la firma, che e' prodotta con la chiave della CA.

Questo sistema e' sicuro e pratico (dato che ottenere il certificato e' un one-time process).

CA: creazione di una sessione

Una volta che i peer A, B hanno un proprio certificato, possono iniziare e mantenere una sessione.

Soluzione 1

1. A manda a B il proprio ID
2. B risponde ad A con una chiave di sessione cifrata con la chiave pubblica di A. (per renderlo meno vulnerabile, B puo' rispondere con Eks(M), MACks(M) dove MAC e' un'autenticazione (firma) della chiave di sessione.

I messaggi successivi sono cifrati e autenticati con la session key. Questo approccio ha il difetto che un attacker puo' mandare sequenze random di bit per ottenere una risposta. (chiave fasulla).

Un altro rischio e' che il MITM faccia da ponte tra A e B, falsificando i messaggi. Questo presuppone che C (MITM) sia in grado di ottenere una sessione da B.

Soluzione 2

1. A manda a B il proprio ID e un Nonce N1, cifrati con la chiave pubblica di B.
2. B risponde con un nonce N2 successivo a N1 e con N1 stesso, cifrando con la chiave pubblica di A.
3. A risponde a B ripetendo N2 cifrato con la chiave pubblica di B.
4. Uno dei due peer, non importa quale, genera la chiave di sessione Ks e la invia cifrata con la pubkey dell'altro peer, mandando anche un'autenticazione (una firma Sig(Ks) con la propria chiave privata).

SSL/TLS e' un'evoluzione di questo protocollo. (leggi cap 13.1/13.2 del libro)

Kerberos

Kerberos e' un'evoluzione di Needham / Schroeder a chiave simmetrica. E' un progetto MIT di inizio anni '90, diventando uno dei sistemi di autenticazione di Microsoft. Lo scopo originale di Kerberos era fornire un'autenticazione affidabile in rete locale, dove quindi lo sniffing e' un problema frequente.

L'idea e' quella di utilizzare un servizio di autenticazione centralizzato.

Schema di funzionamento

Consideriamo un servizio V (online) e un client C. La maniera piu' triviale di gestire l'autenticazione sarebbe una password che mandata a V permetta l'accesso, ma cio' e' scomodo e non scalabile.

Per questo motivo si introduce un authentication server AS, che gestisca l'accesso ai servizi. Procedura:

1. C manda ad AS IDc, IDv, Pc dove Pc e' la password del client
2. AS risponde a C con un ticket, cioe' un messaggio cifrato con una chiave condivisa tra AS e V (ma non C: come un biglietto di accesso a V, C non ha bisogno di coonscere il contenuto del ticket).
3. C manda a V IDc, ticket, che V verifica, garantendo a C l'accesso al servizio.

• Il ticket contiene:

ticket = Ek[AS,V] (IDc, MACc, IDv) dove MAC e' il mac address di C (nota: allora il MAC address non era falsificabile)

Pros

• Centralizzazione delle password di accesso ad AS
• ticket chiuso, quindi pratico perche' facilmente mandabile in rete

Cons (vulnerabilita')

• replay del ticket e' possibile (per riutilizzare un ticket, un attacker puo' falsificare il suo MAC address e mandare l'IDc, facilmente ottenibile tramite sniffing di (1)).
• rischio di intercettazione delle password e' alto.

Soluzione alle vulnerabilita': Kerberos v2

Oltre all'AS, viene introdotto il Ticket granting service, una quarta entita' che si occupa dell'emissione del ticket.

Procedura:

1. C manda ad A IDc, IDtgs richiedendo di utilizzare il TGS.
2. AS risponde con Ek[C,AS](ticketTGS) mandando un ticket cifrato con una chiave condivisa tra C e AS. Questo evita di mandare la password in rete, ma permette a C di ottenere un ticket per TGS. IL ticketTGS e':

ticketTGS = Ek[AS, TGS] (IDc, MACc, IDtgs, ts1, lifetime1) dove MACc e' il mac address del client, e il ts1 e' un timestamp

Il client ottiene il ticketTGS ma non puo' leggerlo.

3. C manda al TGS il ticketTGS, il quale lo decifra.
4. TGS manda a C il ticketV, che e' simile al ticketTGS come struttura:

ticketV = Ek[TGS, V] (IDc,IDv, ts2, lifetime2)

Questa versione di Kerberos introduce dei lifetime per evitare il replay di ticket (che pero' e' comunque possibile durante il periodo di validita' del ticket, che non puo' essere troppo breve per non introdurre scadenze prima dell'utilizzo.