ANALISI DEL PROTOCOLLO SRP (SECURE REMOTE PASSWORD)

Solo se la password dell’utente utilizzata al passo
2 corrisponde con quella usata dal Server per
generare s,v si otterrà il medesimo valore di S;
6. Entrambe le parti derivano la chiave di sessione
K;
7. Il client calcola M 1 , la prova che ha derivato la
chiave di sessione in modo corretto, e la invia al
Server che effettua lo stesso calcolo e verifica la
corrispondenza;
8. Analogo a sopra dal lato Server, con M 2 .
Tralasciando per ora i dettagli dei calcoli utilizzati,
è facile notare che i passi 3-6 corrispondono ad una
variante del Diffie-Hellman (DH) Key Exchange 2 , per
cui il problema di ottenere K solo dalle informazioni
scambiate in chiaro è facilmente riducibile a quello di
DH e alla supposta one-wayness dell’esponenziazione
discreta. Da questo deriva la resistenza di SRP agli
attacchi passivi.
Teorema 4.1 (Simmetria della chiave in SRP-1)
Se la password P è simmetrica, allora anche la
chiave di sessione K è simmetrica.
Dimostrazione:
La simmetria della password P implica che il Server
produca i parametri (s,x,v) nel modo descritto
nel paragrafo 3.3 e che anche x sia simmetrica.
Poichè K è ottenuta tramite un hash di S è sufficiente
mostrare che client e Server calcolino lo
stesso S. Per questo si osservino i seguenti passaggi
(tutte le operazioni si intendono modulo
n)
S = (B − g x ) a+ux =
= ((v + g b ) − g x ) a+ux = ((v + g b ) − v) a+ux =
= (g b ) a+ux = (g b ) a (g b ) ux = (g a ) b (g b ) ux =
(A) b (g ux ) b =
= (A) b ((g x ) u ) b = (A) b (v u ) b =
= (Av u ) b = S
□
4.1 Il parametro B
Se si fosse seguito lo schema classico del DH Key
Exchange, sarebbe stato possibile calcolare al passo 4
B = g b invece di B = v + g b
Sfortunatamente tale semplificazione esporebbe il
protocollo ad un active dictionary attack, dove un attaccante,
che si finge Authentication Server, convince
il client ad effettuare un tentativo di autenticazione
dopo aver catturato il valore s da una precedente
sessione tra client e Server.
2 Si confronti con la tabella 1.
4.1.1 Primo esempio di attacco
Si utilizzi la tabella 4 come riferimento, supponendo
di calcolare B = g b e di aver catturato s in precedenza:
1. il client invia il proprio userID I all’attaccante;
2. l’attaccante invia al client il valore s catturato in
precedenza;
3. il client invia il proprio esponenziale residuo A;
4. l’attaccante genera i propri b ed u, calcola il
proprio esponenziale residuo (B = g b ) ed invia
B,u;
5. il client calcola la propria chiave di sessione K ed
invia la prova M 1 del suo possesso;
6. l’attaccante simula un network failure o semplicemente
notifica al client che la password non è
corretta.
A questo punto l’attaccante possiede M 1 che è calcolato
dal client utilizzando una chiave di sessione
“pilotata” dai valori B ed u forniti dal falso Server.
Quest’ultimo così è in grado di cercare
x = H(s,I,P) tale che verifichi M 1
tramite tentativi su P basati su un dizionario di termini
e caratteri probabili.
Poichè l’attacco parte da chi non conosce il vero
valore di v è necessario fare in modo che questo condizioni
il valore di B e, di conseguenza quello di M 1 ,
impedendo in questo modo l’attacco descritto. Per
questo motivo si combinano i due valori tramite una
opportuna funzione
f (v,g b )
con particolare attenzione al modo in cui vengono
scelti v e g b (devono rispondere a dei requisti illustrati
in [20]). L’addizione modulare dei termini v + g b
sembra essere la soluzione più semplice; le successive
versioni SRP-3 e SRP-6 differiscono leggermente
in questo aspetto (si veda il paragrafo 6.1).
4.2 Il parametro u
Lo scopo del parametro u è quello di proteggere dalla
compromissione dei dati dell’utente presso il Server,
in particolar modo nel caso del furto del verifier v da
parte di un attaccante.
Il requisito fondamentale è che u non sia noto a
priori e venga inviato solo al passo 3; questo fatto si
spiega immaginando il seguente scenario.
6