ANALISI DEL PROTOCOLLO SRP (SECURE REMOTE PASSWORD)

ANALISI DEL PROTOCOLLO SRP
(SECURE REMOTE PASSWORD)
Technical Paper - rev.0.6 - Maggio 2007
Andrea Manganaro, Mingyur Koblensky, Michele Loreti
Dipartimento di Sistemi e Informatica, Universita’ di Firenze
Viale Morgagni 65 - 50134 Firenze, Italy
amanga@ngi.it, mingyur@gmail.com, loreti@dsi.unifi.it
Keywords:
Abstract:
Password-based authentication, SRP-3, SRP-6, SRP-6a
SRP (Secure Remote Password) è un protocollo di autenticazione pensato per lo scambio sicuro ed autenticato
di chiavi di sessione, progettato per resistere ad attacchi passivi ed attivi. L’autenticazione delle parti avviene
tramite la prova del possesso di un segreto condiviso, la password di un utente accreditato presso un Server di
Autenticazione. Lo scopo di SRP è infatti quello di poter utilizzare password facilmente memorizzabili dalle
persone (quindi anche relativamente corte e semplici) senza che questo condizioni la sicurezza del protocollo.
In questa Technical Paper vengono presentate le caratteristiche fondamentali di SRP, partendo dalle basi
matematiche ed illustrando la definizione delle principali versioni storiche.
1 Introduzione
SRP (Secure Remote Password) è un protocollo
password-based stato ideato da Thomas Wu nel 1997,
mentre era studente alla Stanford University [20]:
SRP è stato pensato per lo scambio sicuro ed autenticato
di chiavi di sessione e progettato per resistere ad
attacchi passivi ed attivi. L’autenticazione delle parti
avviene tramite la prova del possesso di un segreto
condiviso, la password di un utente accreditato presso
un Server di Autenticazione. La peculiaritá principale
di SRP è che consente di utilizzare password
facilmente memorizzabili dalle persone (quindi anche
relativamente corte e semplici) senza che questo
condizioni la sicurezza del protocollo.
La definizione di SRP fa parte processo di standardizzazione
IEEE P1363.2 [12], che si occupa di
raccogliere le specifiche per la realizzazione di tecniche
di autenticazione, derivazione e scambio sicuro
delle chiavi, utilizzando cifrari a chiave pubblica.
In questo documento vengono presentati i fondamenti
teorici ed i dettagli di funzionamento del
protocollo.
2 Fondamenti teorici
SRP si basa sull’utilizzo della funzione di esponenziazione
discreta, che è supposta essere di tipo
one-way, ovvero che il calcolo della sua inversa (il
logaritmo discreto) non sia computazionalmente praticabile.
Il meccanismo è analogo a quello del protocollo
noto come Diffie-Hellman Key Exchange [5], di
cui SRP è una estensione.
In questo paragrafo vengono riassunte le basi matematiche
della esponenzazione discreta, insieme alla
sua applicazione al protocollo di Diffie-Hellman: per
una trattazione approfondita si rimanda a [14].
2.1 Radici primitive e logaritmo
discreto
Ricordando che per P si intende l’insieme dei numeri
primi, consideriamo quanto segue.
Definizione 1 (Funzione di Eulero) Sia N + = N −
{0}, si definisce come funzione di Eulero
φ : N + → N +
la funzione che individua la cardinalità ∀n ∈ N +
φ(n) = #{b ∈ N | 1 ≤ b ≤ n , (b,n) = 1}

e che gode delle seguenti proprietà:
1. φ(1) = 1
2. se p ∈ P =⇒ φ(p) = (p − 1)
3. se p ∈ P =⇒ φ(p n ) = (p n − p n−1 ) = p n (1 − 1 p )
4. se (m,n) = 1 =⇒ φ(mn) = φ(m)φ(n)
Teorema 2.1 (di Eulero - s.d.) Dati a ∈ Z e n ≥ 1
tali che siano relativamente primi tra loro, cioè
si ha che
□
(a,n) = 1
a φ(n) ≡ n 1 (1)
Definizione 2 (Radice primitiva) Siano α , n ∈ N
tali che (α,n) = 1, si definisce come ordine di α
modulo n la seguente quantità
ord n (α) = min{i > 0 | α i ≡ n 1}
Dal teorema di Eulero avremo necessariamente
che
ord n (α) ≤ φ(n)
Allora si dirà che α è radice primitiva di n se vale
che
ord n (α) = φ(n) (2)
In generale si ha che vale il seguente risultato
Teorema 2.2 (Forma delle radici primitive - s.d.)
Un numero n ha radici primitive se e solo se è nella
forma
dove
□
2 , 4 , p α , 2p α
p ∈ P , p > 2 , α > 1
Consideriamo adesso un certo α radice primitiva di n.
Per quanto appena visto vale che
(α,n) = 1
ma dalla teoria dei numeri sappiamo che in questo
caso esiste un unico
α −1 mod n
Dati quindi i seguenti valori
α 1 , α 2 , ... , α φ(n)
valgono le seguenti considerazioni:
• i valori elencati sono tutti diversi tra loro (modulo
n)
• i valori elencati sono tutti relativamente primi con
n, poichè già vale che (α,n) = 1. Di conseguenza
questo varrà anche modulo n e che quindi
{α 1 mod n , α 2 mod n , ... , α φ(n) mod n} = Z ∗ p
Basandoci sulle precedenti considerazioni si
introduce la seguente
Definizione 3 Sia p ∈ P e α radice primitiva di p, si
definiscono le seguenti funzioni
dove
exp α,p : Z ∗ p → Z ∗ p , ind α,p : Z ∗ p → Z ∗ p
exp α,p (i) = (α i mod p) (3)
è detta esponenziazione discreta. Mentre
ind α,p (a) = min{i > 0 | α i mod p = a} (4)
è detto logaritmo discreto.
Concludendo abbiamo che la funzione di esponenziazione
è biettiva e risulta che
ind α,p = exp −1
α,p
2.1.1 One-wayness della esponenziazione
discreta
La funzione di esponenziazione discreta è supposta
essere di tipo one-way e quindi il calcolo di ind α,p (n)
con p molto grande non è computazionalmente praticabile.
Infatti, uno dei modi per ottenere il logaritmo
discreto è quello di provare tutte le potenze di α finchè
non si trova l’esponente giusto, ma con numeri grandi
questo richiede molte risorse di calcolo. Esistono anche
strategie più sofisticate ed efficienti, come il Pollard’s
rho method [13] che comunque si vanificano
con adeguate grandezze di p.
Esempio
Supponiamo sia dato
ind 2,19 (9) = h
e che si voglia ottenere h procedendo per tentativi.
Dalla definizione avremo che
h = min{i > 0 | 2 i mod 19 = 9}
2

Quindi, provando esaustivamente le potenze di α si
ottiene
...
...
2 5 ≡ 19 13
2 6 ≡ 19 7
2 7 ≡ 19 14
2 8 ≡ 19 9
concludendo, in questo caso, che h = 8.
2.2 Diffie-Hellman Key Exchange
Il Diffie-Hellman Key Exchange è un protocollo che
si basa sulla funzione di esponenziazione discreta e
sulle proprietà della sua inversa, il logaritmo discreto
(paragrafo 2.1). Il suo scopo è, essenzialmente, quello
di far derivare in modo sicuro chiavi simmetriche a
due parti in comunicazione.
2.2.1 Funzionamento
In un modello client-Server, il funzionamento è il
seguente
Client
(g,n)
←→
Server
1.
2. a < n
3. A = g a mod n
A
−→
4. b < n
5.
←− B = g b mod n
6. K S = B a mod n K S = A b mod n
Tabella 1: Funzionamento del Diffie-Hellman Key
Exchange
1. Le parti devono concordare su due valori pubblici:
n ∈ P molto grande
g radice primitiva di n e tale che g < n
2. Il client genera un numero casuale
a < n tenendolo segreto
3. Il client inoltre calcola
A = g a mod n inviandolo al Server
4. Il Server genera un numero casuale
b < n tenendolo segreto
5. Il Server infine calcola
B = g b mod n inviandolo al client
B
6. Le parti calcolano la medesima chiave di sessione
K S
client −→ K S = B a mod n
Server −→ K S = A b mod n
Il fatto che client e Server derivino la stessa K S si
dimostra osservando i seguenti passaggi
K S = B a mod n =
= (g b mod n) a mod n = (g b ) a mod n =
= (g a ) b mod n = (g a mod n) b mod n =
= A b mod n = K S
dove effettivamente il primo e l’ultimo corrispondono
ai calcoli svolti, rispettivamente da client e Server, per
ottenere la chiave di sessione.
2.2.2 Sicurezza
L’unica strategia che ha un attacante per ricavare K S
dalle informazioni pubbliche (g, n, A, B) è cercare di
ricavare uno dei due valori privati, cioè calcolando
a = ind g,n (A) oppure b = ind g,n (B)
ma come si è visto nel paragrafo 2.1 questo è un
problema non praticabile con n opportunatamente
grande.
2.2.3 Vulnerabilità
Le principali vulnerabilità note del protocollo di
Diffie-Hellman riguardano gli attacchi Man-in-the-
Middle e di Clogging.
Man-in-the-Middle Attack Come evidenziato in
[18] questo protocollo è suscettibile ad attacchi di
tipo Man-in-the-Middle, a causa della mancanza di
un meccanismo di autenticazione che permetta di
stabilire l’autenticità delle chiavi.
L’attacco funziona con una terza parte che si interpone
nella comunicazione tra client e Server e
procede come segue (ricordando che n e g sono noti):
1. genera un numero casuale i < n e calcola Ω AB =
g i mod n
2. invia Ω AB a client e Server
A questo punto l’attaccante è in grado di derivare
due chiavi di sessione distinte
K S1 = A i mod n
K S2 = B i mod n
che gli permettono di avviare due canali cifrati indipendenti
con client e Server che però rimarranno
convinti di comunicare l’uno con l’altro.
3

Client Attaccante Server
K S1 = (Ω AB ) a
A
−→
Ω
←−
AB
Ω AB = g i
K S1 = A i
K S2 = B i
Ω AB
−→
B
←−
K S2 = (Ω AB ) b
Tabella 2: Man-in-the-middle attack nel Diffie-Hellman Key Exchange: le operazioni si intendono modulo n.
Clogging Attacks Un altro problema dello schema
Diffie-Hellman è la vulnerabilità ai cosiddetti Clogging
Attacks, ovvero i casi in cui un attaccante sommerga
una delle parti con richieste contenenti i valori
A ′ o B ′ ottenuti da esponenziazione discreta. In questo
modo il ricevente è costretto a rispondere, calcolando
la chiave di sessione per ogni richiesta, sprecando
risorse di calcolo.
Replay Attacks Così come è definito, lo schema
Diffie-Hellman non offre protezione da attacchi di tipo
Replay, ovvero in cui un attaccante utilizzi i dati
di una precedente comunicazione tra client e Server
per tentare successivamente di impersonare una delle
parti.
2.3 Sicurezza dei parametri
L’utilizzo della funzione di esponenziazione discreta
in sistemi basati sullo schema Diffie-Hellman pone
degli interrogativi sulla corretta scelta dei parametri,
in particolare di g ed n. Si parla in questo caso di sicurezza,
poichè, senza un controllo sulle caratteristiche
dei valori, si rende praticabile ad un attaccante la possibilità
di ottenere la chiave simmetrica [9, Chapter
12].
2.3.1 Requisiti matematici
Il primo aspetto legato alla sicurezza di un protocollo
basato sullo schema DH è che le parti in comunicazione
possano verificare l’aderenza ai requisiti
matematici di n e g, ovvero:
• la primalità di n;
• che n verifichi le proprietá di safe prime 1 ;
• che g sia effettivamente una radice primitiva per
n.
1 Cioé che n sia un numero primo sufficientemente
grande e nella forma 2q + 1, con q anch’esso primo.
Questi tipi di test sono peró computazionalmente
molto onerosi, di conseguenza, nell’utilizzo pratico,
si pone come requisito l’appartenenza ad un insieme
predefinito di valori che già verificano le proprietà
richieste. Si veda ad esempio [13].
2.3.2 Dimensione di n
Il secondo aspetto è quanto grande debba essere n e,
di conseguenza, il numero di bit con cui lo si andrà
a rappresentare. Si è visto, infatti, che l’esponenziazione
discreta fonda la sua one-wayness sull’impraticabilità
di effettuare i tentativi necessari per calcolare
il logaritmo discreto (si veda l’esempio al paragrafo
2.1): questo è fortemente dipendente dalla grandezza
di n che, ai fini pratici, si lega al numero di bit che lo
rappresentano.
Le usuali stime di sicurezza sulla lunghezza delle
chiavi crittografiche simmetriche (tipicamente di 128
o 256 bit) non si possono applicare a questo contesto,
in quanto le operazioni di esponenziazione sono
molto più lente per un calcolatore rispetto a quelle di
encryption. Infatti, obbligare un attaccante a 2 128 tentativi
per attaccare lo schema Diffie-Hellman richiede
circa 6800 bit per n [9].
Una autorevole pubblicazione in cui si affronta
questo problema è [15], dalla cui lettura ci si può convincere
che una dimensione di 2048 bit dovrebbe essere
il minimo assoluto e che l’utilizzo di 4096 bit
offra un adeguato livello di sicurezza.
3 Schema generale di SRP
SRP si ispira ad un schema pubblicato in [3] e
formalmente noto come EKE (Encrypted Key Exchange).
Da questo schema sono stati derivati poi
principalmente il protocollo DH-EKE (Diffie Hellman
EKE), e lo schema AKE (Asymmetric Key
Exchange), che è una generalizzazione di SRP.
In SRP viene adottata una forma del Diffie-
Hellman Key Exchange a cui si aggiunge un mecca-
4

nismo di autenticazione. Lo schema generale del protocollo
comprende gli elementi mostrati nella tabella
3: si sfruttano le caratteristiche della funzione di esponenziazione
discreta e della sua inversa, il logaritmo
discreto.
Elementi fondamentali per il protocollo SRP sono
che permette la mutua autenticazione delle parti e che
tutti i messaggi scambiati sono “in chiaro”.
n un numero primo molto grande
g una radice primitiva di n
s una stringa casuale
P la password dell’utente
x una chiave privata, derivata da P e da s
u un valore casuale
a,b chiavi private temporanee
A,B le chiavi pubbliche temporanee
H( ) una funzione one-way di hash
K la chiave di sessione
Tabella 3: Notazione matematica per SRP
3.1 Operazioni modulo n
I calcoli vengono operati all’interno di un campo finito
GF(n) con n primo molto grande e tutte le operazioni
si intendono modulo n: tale valore e g sono fissati
e si suppone siano noti alle parti, mentre a partire
da SRP-6 (paragrafo 6) spetta al Server comunicarli
esplicitamente.
Per i valori di n e g le implementazioni di SRP usano
come riferimento un insieme perdefinito di valori,
definiti in [19].
3.2 Funzioni di hash
SRP richiede una funzione di hash H ritenuta sicura e
che produca un output di almeno 16 byte: la famiglia
di funzioni SHA [8] in genere è considerata adeguata
e viene usata in tutte le implementazioni conosciute
di SRP. Riguardo la sicurezza delle funzioni di hash,
vale la pena citare [11], un autorevole punto di vista
di P. Hoffman e B. Schneier, dove vengono illustrate
le effettive problematiche di sicurezza degli attuali
algoritmi disponibili.
3.3 Inizializzazione dei valori
Alla creazione dell’account del Client, il Server conserva
temporaneamente nel proprio database la userID
I e la password P dell’utente, generando un valore
casuale s (detto salt) relativo a tale account e
procedendo con i seguenti calcoli
x = H(s,I,P)
v = g x detto verifier
Conseguentemente il Server conserva i seguenti
dati relativi al client
(I,s,v)
cancellando dal proprio database la password del
client: questo fatto è cruciale, poichè facilita la gestione
delle politiche di sicurezza del server e semplifica
il protocollo.
4 SRP-1
La prima versione di SRP è stata definita in [20]
e viene indicata in questo documento come SRP-1.
Per realizzare l’accesso alla rete e l’autenticazione il
client ed il Server procedono con uno scambio di messaggi
non cifrati nel seguente modo (illustrato nella
tabella 4):
Client
(g,n)
←→
1.
−→
2. x = H(s,I,P)
s
←−
3. A = g a A
−→
I
B,u
Server
ricerca (I,s,v)
4.
←− B = v + g b
5. S = (B − g x ) a+ux S = (Av u ) b
6. K = H(S) K = H(S)
7. M 1 = H(A,B,K)
M
−→
1
verifica M1
M
8. verifica M 2
2 ←−
Tabella 4: Funzionamento di SRP-1
1. Il client invia il proprio userdID I;
M2 = H(A,M 1 ,K)
2. Il Server cerca la tripla (I,s,v) corrispondente ed
invia s;
3. Il client genera 1 < a < n casuale, calcola A e la
invia al Server;
4. Il Server genera 1 < b < n ed u casuali, calcola B
e li invia al Client;
5. Entrambe le parti calcolano il valore esponenziale
comune S, utilizzando i parametri a disposizione.
5

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

4.2.1 Secondo esempio di attacco
Si supponga che l’attaccante abbia rubato il verifier v
relativo all’utente I, possegga u e si finga tale utente
presso il Server:
1. l’attaccante invia lo userID I dell’utente che vuole
impersonare;
2. il server procede come già visto, inviando s;
3. l’attaccante calcola
A = g a v −u
invece di usare la formula prestabilita ed invia tale
risultato al Server;
4. il server calcola ed invia B = v + g b regolarmente
all’attaccante;
5. l’attaccante calcola S nel seguente modo
S = (B − v) a
inviando la prova M 1 al Server;
6. il Server procede e l’attaccante guadagna l’accesso
impersonando l’utente I, derivando la chiave di
sessione K.
Questo attacco funziona perchè il Server calcola come
già visto il valore S = (Av u ) b , ma a causa del calcolo
al passo 3 succede che
S = (Av u ) b = (g a v −u v u ) b = g ab
quindi è evidente che l’attaccante il passo 5 ottiene
proprio lo stesso S
S = (B − v) a = ((v + g b ) − v) a = (g a ) b = g ab = S
e si dimostra che è necessario non rivelare u sino al
ricevimento di A da parte del Server.
4.3 Resistenza agli attacchi passivi
I parametri scambiati in chiaro tra le parti non possono
essere usati da un attaccante per ottenenere le
informazioni private; qui di seguito lo dimostriamo
spiegando il comportamento di SRP con gli attacchi
di questo tipo.
4.3.1 Attacco alla chiave di sessione
Come già affermato nel paragrafo 4 il problema di
ottenere S o K solo dalle informazioni scambiate in
chiaro si basa alla supposta one-wayness della esponenziazione
discreta. Si dovrebbe infatti poter calcolare
il logaritmo discreto sui valori A e B, ma questo è
considerato computazionalmente non praticabile.
In alternativa, si potrebbe tentare un attacco con
forza bruta su M 1 o M 2 per ottenere direttamente K,
poichè
M 1 = H(A,B,K)
M 2 = H(A,M 1 ,K)
ed i parametri A,B,M 1 ,M 2 sono tutti pubblici.
Questo tipo di attacco con SRP-1 è limitato dall’output
della funzione hash in uso: in SHA-1 si hanno
128 bit, quindi si richiederà in media uno sforzo
nell’ordine di 2 127 per ottenere tutti i candidati per
K. 3
4.3.2 Attacco di Denning-Sacco
Si tratta di una situazione illustrata per la prima volta
in [4]; siamo nel caso in cui un attaccante sia riuscito
in qualche modo a derivare la chiave di sessione K
in uso tra client ed Authentication Server e la voglia
usare per impersonare il client.
Si può dimostrare che SRP-1 è resistente a questo
tipo di attacco, infatti anche se l’attaccante possiede
K non è in grado di derivare informazioni sulla password
utilizzando M 1 e M 2 . Entrambi i valori sono
calcolati solo sulla base di parametri inviati in chiaro
e su K stessa. Per come sono stati definiti i parametri
x, S e K, si ha che trovare una certa password P ′ che
verifichi la chiave K posseduta, si riduce ad un attacco
con forza bruta.
4.3.3 Attacchi basati su dizionario
Un attacco basato su un dizionario di termini probabili
per la password non è praticabile: P influenza solo
i valori di x e v, che sono noti solo alle parti legittime.
L’attaccante, per ciscuno dei valori x ′
ottenuti
dal proprio dizionario, dovrebbe procedere esaustivamente
per trovare i valori a o b che verifichino
rispettivamente M 1 o M 2 . Infatti
M 1 = H(A,B,H((B − g x ) a+ux ))
M 2 = H(A,M 1 ,H(A((g x ) u ) b ))
ma a e b sono valori casuali.
4.4 Resistenza agli attacchi attivi
La vulnerabilità evidenziata per lo schema di Diffie-
Hellman agli attacchi Man-in-the-Middle, non è più
applicabile a SRP. La modifica dei valori A e B causa
3 Si parla di candidati, poichè M 1 e M 2 sono il risultato di
una funzione one-way: una ricerca esaustiva potrebbe portare
dei falsi positivi a causa di una collisione nella funzione
di hash.
7

il fallimento dell’autenticazione delle parti e non dà
informazioni all’attacante per ottenere P.
SRP-1 è immune anche dagli attacchi di Replay e,
al momento, non sono note vulnerabilità rilevanti; tuttavia
SRP-1 sembra comunque suscettibile ad attacchi
di Clogging, così come avveniva per il protocollo di
Diffie-Hellman.
4.5 Ottimizzazione del Protocollo
La necessità di implementare in modo efficiente SRP
in sistemi reali porta a dover considerare il numero
di round necessari per completare l’autenticazione e
la derivazione della chiave K; nella formulazione fin
qui fatta si può osservare che servono 6 messaggi,
equivalenti a 3 round (vedi tabella 5).
Client Server Parametro Inviato
=⇒ I
⇐= s
=⇒ A
⇐= B,u
=⇒ M 1
⇐= M 2
modo si preservano i requisiti del protocollo, illustrati
nel paragrafo 4.2: l’utilità di questa modifica trova ragione
in SRP-6, la successiva versione del protocollo
che viene descritta nel prossimo paragrafo.
Sebbene nello RFC 2945 non lo si indichi esplicitamente,
è ancora possibile ridurre il numero di
round necessari al protocollo, riordinando la sequenza
originale come mostrato nella tabella 8.
Client
(g,n)
←→
1.
−→
2. x = H(s,I,P)
s
←−
3. A = g a A
−→
I
Server
ricerca (I,s,v)
B = v + g b
4. u=H(A,B) ←− u=H(A,B)
5. S = (B − g x ) a+ux S = (Av u ) b
6. K = H(S) K = H(S)
7. M 1 = H(A,B,K)
M
−→
1
verifica M1
M
8. verifica M 2
2 ←−
B
M2 = H(A,M 1 ,K)
Tabella 7: Funzionamento di SRP-3. Cambiano il calcolo e
l’utilizzo del parametro u.
Tabella 5: I round di SRP-1
Si può dimostrare che è possibile ridurre il numero di
messaggi, pur mantenendo le caratteristiche originali
di SRP-1: la tabella 6 mostra la sequenza ottimizzata
che sfrutta l’invio simultaneo di più parametri senza
alterare i calcoli necessari.
Client Server Parametro Inviato
5 SRP-3
=⇒ I,A
⇐= s,B,u
=⇒ M 1
⇐= M 2
Tabella 6: SRP-1 ottimizzato
Nel settembre 2000 lo IETF ha pubblicato lo RFC
2945 [21] che definisce le specifiche del protocollo
SRP-3. Le differenze rispetto a SRP-1 sono minimali
e si riassumono nella modifica del calcolo di u, che
avviene tramite hashing dei parametri A e B: in tal
Client Server Parametro Inviato
=⇒ I,A
⇐= s,B
=⇒ M 1
⇐= M 2
Tabella 8: SRP-3 ottimizzato. u non viene più inviato.
6 SRP-6 e SRP-6a
Le precedenti versioni del protocollo SRP sono
state migliorate sulla base di alcune considerazioni legate
alla sicurezza ed all’ottimizzazione. La nuova
versione, denominata SRP-6, è stata proposta in [22]
e successivamente inclusa nel processo di standardizzazione
IEEE P1363.2. La descrizione che segue include
anche la recente versione SRP-6a, introdotta nel
luglio 2005 e solo parzialmente documentata in [19].
6.1 Attacco Two-for-One
Nella sue precedenti formulazioni, SRP permette ad
un attaccante di effettuare due tentativi in uno per
8

indovinare i parametri segreti ad ogni connessione;
infatti, poichè vale
B = v + g b = g x + g b
un attaccante che si finga Authentication Server può
trattare B come
g y + g z
inserendo in y ed z i valori corrispondenti a due
presunte password P ′ e P ′′ , calcolando
y = H(s,I,P ′ ) e z = H(s,I,P ′′ )
Considerando che il client sottrae g x a tale quantità (si
veda la tabella 4) se y o z corrispondono alla password
cercata il valore di S che verrà calcolato dal client e
dall’attaccante sarà lo stesso, portando inevitabilente
a concludere con successo l’autenticazione.
Questa caratteristica non pone reali problemi alla
sicurezza del protocollo, poichè si tratta di una situazione
facilmente rilevabile e che richiede un numero
non praticabile di connessioni per realizzare una
quantità di tentativi significativa; tuttavia, a partire da
SRP-6, è stata proposta una modifica che elimina la
simmetria nel calcolo e, di conseguenza, la possibilità
di realizzare questo attacco.
La nuova formula utilizzata con SRP-6 è
dove:
B = kv + g b
• k = 3 nella descrizione data nel documento [22];
• k = H(n,g) nella più recente versione SRP-6a,
inclusa in [19].
ne consegue che il client, quando riceve B, dovrà
calcolare S in un nuovo modo, ovvero
S = (B − kg x ) a+ux
6.2 Ordinamento dei messaggi
SRP-1 e SRP-3 richiedono che per entrambe le parti
siano in qualche modo fissati a priori n e g; questo
però, è difficile da realizzare in pratica e renderebbe
comunque poco flessibile il protocollo; è quindi
più naturale permettere al Server di inviare al client
i parametri necessari all’avvio del protocollo, dopo il
primo messaggio.
Tuttavia questo approccio (mostrato in tabella 9)
vanifica le ottimizzazioni di SRP-1 e SRP-3, poichè
n e g sono necessari per il calcolo di A e pertento
quest’ultimo non può essere inviato fino al loro
ricevimento.
Client Server Parametro Inviato
=⇒ I
⇐= n,g,s
=⇒ A
⇐= B
=⇒ M 1
⇐= M 2
Tabella 9: SRP-3 con parametri
La soluzione è quella di inviare B come parte del
primo messaggio del Server. Come è già stato fatto
notare (paragrafo 4.2), è necessario non rivelare u sino
al ricevimento del valore A e questa situazione è
stata già risolta con la modifica presentata in SRP-3:
u non viene più inviato in chiaro ma è derivato implicitamente
dalle parti. Si ricorda infatti che per far
questo client e Server calcolano
u = H(A,B)
basandosi quindi solo sui valori A e B rispettivamente
ricevuti. In questo modo l’attacco mostrato al paragrafo
4.2 diventa difficile da realizzare, anche se il
valore B del Server viene inviato prima di ricevere A;
infatti un attaccante dovrebbe trovare un valore u per
cui valga
u = H(g a v −u ,B)
ma anche scegliendo a ed u in modo arbitrario, se si
utilizza una funzione di hash come SHA-1, diventa
impraticabile poter ottenere il giusto valore di u e, di
conseguenza, quello di a.
Conseguentemente diventa possibile ottenere una
sequenza ottimizzata secondo le modifiche proposte e
che non incrementi i messaggi necessari (tabella 10).
Client Server Parametro Inviato
=⇒ I
⇐= n,g,s,B
=⇒ A,M 1
⇐= M 2
Tabella 10: SRP-6 ottimizzato
6.3 Funzionamento di SRP-6
Secondo le modifiche presentate nei paragrafi precedenti,
il protocollo SRP-6 si riassume quindi nei passi
illustrati nella tabella 11 (schema completo senza
9

iordinamento dei messaggi). Come si può notare la
derivazione della chiave K è stata spostata come ultima
azione del protocollo e la verifica dei valori M 1
e M 2 coinvolge direttamente S e non più K: questa
scelta non compromette in alcun modo la sicurezza
del protocollo, anzi, mortifica ulteriormente eventuali
attacchi con forza bruta su M 1 M 2 per l’ottenimento
di S. Infatti, il valore di S, a differenza di K, ha un numero
di bit variabile, limitato superiormente solo dai
bit con cui è rappresentato n (tipicamente di almeno
1024 bit): questo rende praticamente impossibile un
attacco con forza bruta.
Inoltre, la differenza per la derivazione di K, risparmia
risorse di calcolo nel caso in cui l’autenticazione
del client fallisca e sembra che questo meccanismo
sia più adatto per l’integrazione di SRP con
protocolli come TLS.
Client
1.
−→
2. x = H(s,I,P)
n,g,s
←−
3. A = g a A
−→
I
Server
ricerca (I,s,v)
B = kv + g b
4. u = H(A,B) ←− u = H(A,B)
5. S = (B − kg x ) a+ux S = (Av u ) b
6. M 1 = H(A,B,S)
B
M 1 −→
verifica M1
7. verifica M 2
M
←−
2
M2 = H(A,M 1 ,S)
8. K = H(S) K = H(S)
Tabella 11: Il protocollo SRP-6.
Teorema 6.1 (Simmetria della chiave in SRP-6)
Se la password P è simmetrica, allora anche la
chiave di sessione K è simmetrica.
Dimostrazione:
Si procede analogamente al teorema 4.1.
S = (B − kg x ) a+ux =
= ((kv + g b ) − kg x ) a+ux = ((kv + g b ) − kv) 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
□
6.4 Resistenza agli attacchi
Poichè SRP-6 è completamente basato sulla struttura
delle precedenti versioni, continuano a valere le considerazioni
già fatte nei paragrafi 4.3 e 4.4 per quanto
riguarda la resistenza agli attacchi passivi ed attivi.
La sicurezza della chiave di sessione è stata ulteriormente
rafforzata, poichè un attacco con forza bruta
sui valori M 1 o M 2 per ottenere K adesso dipende
dalla dimensione di S, solitamente molto più grande.
7 Sicurezza
L’analisi della sicurezza di un qualunque protocollo
non é semplice se si vogliono utilizzare dei metodi
formali. Ad esempio, il Dolev-Yao model [6] si puó
applicare con certi requisiti, tuttavia si é dimostrato
[17] che non e’ adeguato quando si trattano primitive
come l’esponenziazione discreta. Inoltre la sicurezza
di un protocollo puó diventare indecidibile con
modelli piú generali [10], poiché l’insieme di stati da
considerare puó essere troppo grande o infinito.
In questi ultimi anni ’e stato mostrato un certo interesse
per provare formalmente la sicurezza dei protocolli
password-based utilizzando un ideal-cipher
model [1], per il quale sono state date prove della
sua applicabilitá [2] anche per SRP. Sfortunatamente
é stato dimostrato [23] che la dimostrazione formale
della sicurezza di un protocollo secondo lo idealcipher
model non significa che valga anche per l’
istanziazione del protocollo stesso. Di conseguenza
si puó affermare che ancora non si é stati in grado
di provare formalmente la sicurezza di un protocollo
password-based.
Nonostate questa limitazione formale, il protocollo
SRP viene considerato inerentemente sicuro, poiché
la sua struttura matematica puó essere ridotta al
ben noto schema di Diffie-Hellman [5]. Quindi é possibile
dimostrare la sicurezza di SRP considerando
la resistenza agli attacchi passivi ed attivi conosciuti,
proprio come illustrato nei paragrafi precedenti.
8 Implementazioni
La Stanford University supporta attivamente un
progetto Open Source 4 che raccoglie un ampia documentazione
ed i sorgenti di varie implementazioni per
SRP.
Il protocollo viene gia’ usato in diverse applicazioni
di rete, tra cui SSH, Telnet e TLS; da evidenziare
il progetto GnuTLS 5 che offre un insieme di applicazioni
e librerie dove SRP è stato integrato con
TLS.
4 The Stanford SRP Authentication Project, http://
srp.stanford.edu/
5 Transport Layer Security Library for the GNU system,
www.gnutls.org
10

Il Dipartimento di Sistemi e Informatica dell’Universitá
di Firenze sta sviluppando [7,16] l’integrazione
di SRP-6 come metodo di autenticazione EAP per
sistemi di rete wireles.
9 Conclusioni
SRP costituisce un ottimo esempio di come può
essere costruito un protocollo di autenticazione e derivazione
delle chiavi di sessione, basato solo sulle password
degli utenti e che non faccia uso di certificati
digitali. Presenta infatti caratteristiche interessanti:
• si basa su uno schema ben studiato (Diffie-
Hellman), ereditandone i vantaggi e risolvendo la
maggior parte delle vulnerabilità;
• ha una definizione elegante e semplice: questo
è utile per analizzarne la sicurezza e conveniente
per l’implementazione;
• realizza la mutua autenticazione delle parti;
• deriva chiavi di sessione simmetriche;
• le credenziali possono facilmente essere generalizzate;
• le specifiche sono aperte e documentate.
Sembra quindi che SRP, in particolare la versione
SRP-6, sia un candidato ideale per essere integrato come
protocollo di autenticazione in molte applicazioni
dove si voglia adottare uno schema password-based
sicuro.
Riferimenti bibliografici
[1] M. Bellare, D. Pointcheval, and P. Rogaway, “Authenticated
key exchange secure against dictionary attacks,”
Lecture Notes in Computer Science, vol. 1807,
p. 139, 2000.
[2] M. Bellare and P. Rogaway, “The AuthA protocol
for password-based authenticated key exchange,” Tech.
Rep., 2000, contribution to the IEEE P1363 study
group for Future PKC Standards.
[3] S. M. Bellovin and M. Merrit, “Encrypted key exchange:
Password-based protocols secure against
dictionary attacks,” AT&T Bell Laboratories, 1992.
[4] D. Denning and G. M. Sacco, “Timestamps in key
distribution systems,” Tech. Rep., 1981, communications
of the ACM.
[5] W. Diffie and M. E. Hellman, “New directions in cryptography,”
IEEE Transactions on Information Theory,
vol. IT-22, no. 6, pp. 644–654, 1976.
[6] D. Dolev and A. C. Yao, “On the security of public
key protocols,” Stanford, CA, USA, Tech. Rep., 1981.
[7] K. D. M. Dorje, “Implementazione del protocollo
di autenticazione EAP-SRP-256,” Dip. di Sistemi ed
Informatica, December 2006, Master Thesis.
[8] Announcing the SECURE HASH STANDARD, Federal
Information Processing Standards Publication FIPS
180-2, August 2002.
[9] N. Ferguson and B. Schneier, Practical Cryptography.
Wiley Publishing Inc., 2003, ISBN 0-471-22894-X.
[10] N. Heintze and J. D. Tygar, “A model for secure protocols
and their compositions,” Software Engineering,
vol. 22, no. 1, pp. 16–30, 1996.
[11] P. Hoffman and B. Schneier, “Attacks on cryptographic
hashes in internet protocols,” RFC 4270, IETF,
2005.
[12] Draft Standard Specifications for Password-based Public
Key Cryptographic Techniques, IEEE Working
Draft Proposed Standard P1363.2, Rev. D26, 2006.
[13] T. Kivinen and M. Kojo, “More modular exponential
MODP) diffie-hellman groups for internet key
exchange (IKE),” RFC 3526, IETF, 2003.
[14] N. Koblitz, A Course in Number Theory and Cryptography,
2nd ed., ser. Graduate Texts in Mathematics.
Springer, 1994, no. 114.
[15] A. K. Lenstra and E. R. Verheul, “Selecting cryptographic
key sizes,” Journal of Cryptology: the journal
of the International Association for Cryptologic
Research, vol. 14, no. 4, pp. 255–293, 2001.
[16] A. Manganaro, “Studio di un metodo di autenticazione
per le reti wireless basato sul protocollo SRP-
6.” Dip. di Sistemi ed Informatica, December 2005,
Master Thesis.
[17] J. Millen and V. Shmatikov, “Symbolic protocol analysis
with products and diffie-hellman exponentiation,”
2003.
[18] W. Stallings, Cryptography and network security.
Prentice Hall, 2006.
[19] D. Taylor, T. Wu, N. Mavrogiannopoulos, and T. Perrin.
(2006, June) Using SRP for TLS authentication.
IETF Internet draft (Work in Progress). [Online].
Available: draft-ietf-tls-srp-12.txt
[20] T. Wu, “The secure remote password protocol,” in
Proceedings of the 1998 Internet Society Network and
Distributed System Security Symposium, San Diego,
CA, November 1997, pp. 97–111.
[21] ——, “The SRP authentication and key exchange
system,” RFC 2945, IETF, 2000.
[22] ——, “SRP-6: Improvements and refinements to the
secure remore password protocol,” Submission to the
IEEE P1363 Working Group, October 2002.
[23] Z. Zhao, Z. Dong, and Y. Wang, “Security analysis of
a password-based authentication protocol proposed to
IEEE 1363,” Theor. Comput. Sci., vol. 352, no. 1, pp.
280–287, 2006.
11

Licenza e termini di utilizzo
Questo documento è stato realizzato per scopi accademici e di divulgazione scientifica. Le informazioni
contenute sono di dominio pubblico e si vuole favorirne la fruizione senza fini di lucro.
A tutela del lavoro svolto dgli autori e degli scopi sopracitati, questo documento viene distribuito secondo la
licenza Creative Commons Attribuzione-Non Commerciale 2.5. Per leggere una copia della licenza visita il sito
web
http://creativecommons.org/licenses/by-nc-sa/2.5/it/
o spedisci una lettera a
Creative Commons
543 Howard Street
5th Floor
San Francisco, CA 94105-3013
United States
In accordo con tale licenza, si può:
• riprodurre, distribuire, comunicare al pubblico, esporre in pubblico, rappresentare, eseguire e recitare
quest’opera;
• modificare quest’opera.
Alle seguenti condizioni:
Attribuzione.
licenza.
Devi attribuire la paternità dell’opera nei modi indicati dall’autore o da chi ti ha dato l’opera in
Non commerciale.
Non puoi usare quest’opera per fini commerciali.
Ogni volta che usi o distribuisci quest’opera, devi farlo secondo i termini di questa licenza, che va
comunicata con chiarezza.
In ogni caso, puoi concordare col titolare dei diritti d’autore utilizzi di quest’opera non consentiti da questa
licenza.
12