Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

An Analysis of Secure Remote Password (SRP)


Published on

We study the internal structure of the SRP key exchange protocol and experiment with it. SRP establishes a shared encryption key between communicating parties using passwords that were shared out-of-band. We perform basic cryptanalysis of SRP using open-source implementations. We present a demo of how SRP was compromised due to an implementation bug, allowing the attacker to login without the password. The author of the Go-SRP library promptly fixed the issue on the very same day we reported the vulnerability.

Published in: Software
  • Login to see the comments

An Analysis of Secure Remote Password (SRP)

  1. 1. An Analysis of Secure Remote Password Dr. Dharma Ganesan, Ph.D.,
  2. 2. 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
  3. 3. 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 ( ○ 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. 4. 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)
  5. 5. 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. 6. 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. 7. 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
  8. 8. 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. 9. 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) x = Hash(salt,passwd) 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. 10. 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) x = Hash(salt,passwd) S = (B - gx )(a + ux) = (B - gx )a K = Hash(S)
  11. 11. 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. 12. 12 ● There are several implementations of SRP ○ See, ote_Password_protocol
  13. 13. 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 ○ ● 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
  14. 14. 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
  15. 15. 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)
  16. 16. 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
  17. 17. 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!
  18. 18. 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
  19. 19. 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) ○
  20. 20. References 1. 2. 3. 4. 5. 6cfc9a11c3d 20