144 lines
9.5 KiB
Markdown
144 lines
9.5 KiB
Markdown
# 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.
|