An Analysis of Secure Remote Password (SRP)

An Analysis of Secure Remote Password
Dr. Dharma Ganesan, Ph.D.,

Background
● Secure Remote Password (SRP) is a secure client-server protocol
● In SRP, password has to be shared up-front between the client and server
● Using SRP, the client and server arrive at the shared session key K
○ Client and Server can authenticate each other in this process
● Of course, SRP does not send password over the channel
○ Using Diffie-Hellman style, both parties convince each other that they know the password
● SRP is part of TLS 1.2 (but not in TLS 1.3 as far as we know)
● Without digital certificates, SRP creates a secure communication channel
2

Objectives
● Demonstrate how the Secure Remote Password (SRP) protocol works
○ SRP uses nifty ideas of Diffie-Hellman key negotiation
● Demonstrate one implementation attack on SRP
○ Implementation misses a basic check of public key values
● We will break this implementation (https://github.com/opencoff/go-srp/blob/master/srp.go)
○ They fixed it on the same day we reported the issue
● An evil client will successfully authenticate with the server
○ The evil client does not know the password, but will successfully trick the server
3

4
Pick a random number a Pick a random number b
Compute A = ga
Compute B = gb
Secret K = Ba
Secret K = Ab
Send A to Bob Send B to Alice
Both Alice and Bob have
the same secret key Eve sees A and B,
but not a, b, or K
Diffie-Hellman Key Negotiation - Core Idea
(assume that g and prime N are public - in mod N)

SRP vs Diffie-Hellman (DH) Key Negotiation
● DH key negotiation algorithm does not have authentication
○ Alice is not sure whether it is Bob or someone else and vice-versa
● SRP uses DH, but, function(password) is mixed with the server’s public key
● The client will remove the password from the public key
● Afterwards, both the client and server perform basic DH operations
○ They both arrive at the shared key (with authentication support)
● Note that the password is never stored on the server side
● The client never sends the password either
5

6
Client Server x = Hash(salt, passwd)
v = gx
User ID, A = ga
salt, B = kv + gb
u = Hash(A, B)
x = Hash(salt,passwd)
S = (B - gx
)(a + ux)
K = Hash(S)
u = Hash(A, B)
S = (Avu
)b
K = Hash(S)
SRP Protocol: Phase 1 - Key Agreement
(SRP defines the constants g, k, and N (prime); all computation in mod N)

7
Client Server
M2
= H(A, M1
, K)
SRP Protocol: Phase 2 - Mutual Authentication
M1
= H(H(N) xor H(g), H(I), salt, A, B, K)
Is M1
valid?
If yes, send M2Is M2
valid?
If not, abort

Safeguards recommended by SRP
8
The two parties also employ the following safeguards:
1. The client will abort if it receives B == 0 (mod N) or u == 0
2. The server will abort if it detects that A == 0 (mod N)
3. The client must show his proof of K first. If the server detects that the client's
proof is incorrect, it must abort without showing its own proof of K.

9
Why B ≠ 0 mod N?
● B ≠ 0 safeguards against offline dictionary attacks
● Recall that the client performs the following steps
● salt, g, A, B, u, and M1
are public but not x which is derived from the passwd
● The attacker can derive x by comparing against M1
using a dictionary
u = Hash(A, B)
S = (B - gx
)(a + ux)
= (-gx
)a+ux
K = Hash(S)
M1
= H(H(N) xor H(g), H(I), salt, A, B, K)

10
Why u should not be equal to zero?
● u ≠ 0 safeguards against attackers that had stolen gx
from the server
● If an attacker managed to steal gx
, then the attacker can break SRP
● Recall that the client performs the following 4 steps
● If u = 0, then, without knowing the password, the session key is generated
u = Hash(A, B)
S = (B - gx
)(a + ux)
= (B - gx
)a
K = Hash(S)

11
Evil Client Server x = Hash(salt, passwd)
v = gx
User ID, A = N
salt, B = kv + gb
S = 0
K = Hash(0)
u = Hash(A, B)
S = (Avu
)b
= (Nvu
)b
= 0 (mod N)
K = Hash(0)
Why A ≠ 0 mod N?
(SRP defines the constants g, k, and N (prime); all computation in mod N)
Evil Client doesn’t have
the password but sends her
public key A = 0 mod N

12
● There are several
implementations of SRP
○ See,
https://en.wikipedia.org/wiki/Secure_Rem
ote_Password_protocol

Implementations without safeguards
13
● We analyzed a few of these implementations for conformance to SRP
● In this demo, we will exploit one of the Go implementations of SRP
○ https://github.com/opencoff/go-srp/blob/master/srp.go
● It claims “This implementation is accurate as of Aug 2012 edition of the SRP
specification...”
● But, we will show that this claim is not accurate - we will break it
○ The SRP spec introduced the safeguard back in 2000
● This implementation missed the safeguard (A ≠ 0 mod N) of the SRP spec

Checking the value of B
14
func (c *Client) Generate(srv string) (string, error) {
. . .
zero := big.NewInt(0)
z := big.NewInt(0).Mod(B, pf.N)
if zero.Cmp(z) == 0 {
return "", fmt.Errorf("invalid server public key")
}
. . .
}
Fortunately, it does check the value of B
Otherwise, we would have performed offline dictionary attacks using the authentication hash

Vulnerable code (A is the public key of Client)
15
// NewServer constructs a Server instance for computing a shared secret.
func (s *SRP) NewServer(v *Verifier, A *big.Int) (*Server, error) {
...
t0 = big.NewInt(0).Mul(A, big.NewInt(0).Exp(sx.v, u, pf.N))
S := big.NewInt(0).Exp(t0, b, pf.N)
...
}
What if the evil client send A = 0 (mod N)?
Then, the evil client can set the Shared Key!
The Server will compute only the Hash(0)

Demo
16
N =
0xEEAF0AB9ADB38DD69C33F80AFA8FC5E86072618775FF3C0B9EA2314C9C256576D67
4DF7496EA81D3383B4813D692C6E0E0D5D8E250B98BE48E495C1D6089DAD15DC7D7B4
6154D6B6CE8EF4AD69B15D4982559B297BCF1885C529F566660E57EC68EDBC3C05726
CC02FD4CBF4976EAA9AFD5138FE8376435B9FC61D2FC0EB06E3
This implementation uses the above safe prime N
Evil client will just send a malicious public key A such that A = 0 mod N
For example, A = N is one such malicious key

Evil client logged in - without the password
17
~/crypto/srp/srp-example$ ./example
Client Begin; <I, A> --> server:
I: b8fd39a36525c3a6aa40660f6093b2ae5024d23dcd1d9da9421ad53989fb07f8
A:
eeaf0ab9adb38dd69c33f80afa8fc5e86072618775ff3c0b9ea2314c9c256576d674df7496ea81d3383b4813
d692c6e0e0d5d8e250b98be48e495c1d6089dad15dc7d7b46154d6b6ce8ef4ad69b15d4982559b297bcf1
885c529f566660e57ec68edbc3c05726cc02fd4cbf4976eaa9afd5138fe8376435b9fc61d2fc0eb06e3
Client Key: 0e5751c026e543b2e8ab2eb06099daa1d1e5df47778f7787faab45cdf12fe3a8
Server Key: 0e5751c026e543b2e8ab2eb06099daa1d1e5df47778f7787faab45cdf12fe3a8
Since the keys matched, the server thought the client knows the password!

Go-SRP - Fixed the Bug
18
● We reported the issue to Go-SRP
● They fixed the issue on the same day
● That is, they check whether A = 0 mod (N), if true they reject the public key
● We thank Go-SRP for this informal collaboration

Closing Remarks
19
● SRP is a novel protocol for authenticated key negotiation (certificateless)
● A common criticism of SRP is that there is no security proof for it
● SRP is vulnerable to active attacks (subgroup confinement problem)
○ Not discussed in this presentation
● SRP implementations must safeguard against public key values
● Failure to safeguard will allow evil users to take over the server or client
● Future work: Analyze certificateless protocols (e.g., OPAQUE, TLS-PWD, PSK)
○ https://en.wikipedia.org/wiki/Password-authenticated_key_agreement

References
1. http://srp.stanford.edu/design.html
2. https://eprint.iacr.org/2010/149.pdf
3. https://blog.cryptographyengineering.com/should-you-use-srp/
4. https://github.com/opencoff/go-srp/blob/master/srp.go
5. https://github.com/opencoff/go-srp/commit/a2c3544e176ef2e75667efa27c322
6cfc9a11c3d
20

An Analysis of Secure Remote Password (SRP)

More Related Content

What's hot (20)

Similar to An Analysis of Secure Remote Password (SRP) (20)

More from Dharmalingam Ganesan (20)

Recently uploaded (20)

An Analysis of Secure Remote Password (SRP)