Analysis of Key Agreement Protocols

1. Analysis of Key Agreement Protocols Brita Vesterås Supervisor: Chik How Tan

2. Motivation & purpose • Motivation: New protocols are designed rapidly, and they have not been thoroughly analysed. • Purpose: Analyse a few protocols and try to find their weaknesses.

3. Why do protocols contain security flaws? • New attacks arise. • Hard/impossible to consider all possible attack scenarios.

4. Work of this thesis • Summarise different attack methods on key agreement protocols • Describe design methods of key agreement protocols • Analyse five key agreement protocols

5. Attack methods on key agreement protocols • Eavesdropping - an adversary captures information that is sent in the protocol • Modification - the information sent in the protocol is altered by an adversary • Replay - a transmission is recorded, and then later retransmitted • Reflection - sending the same message back to the sender in a new protocol run

6. Attack methods on key agreement protocols (cont.) • denial of service attacks - the attacker overwhelms the server so that legitimate users will not get a connection with the server • typing attack - replacing a message field of one type with a message field of another type • cryptanalysis - the study of methods for obtaining the meaning of encrypted information • certificatemanipulation - modification of the certificate • protocolinteraction - using a new protocol to interact with a known protocol

7. Design methods • ”One-way functions” – functions that are hard to solve without additional information • hash functions • discrete logarithm • elliptic curve discrete logarithm problem • factorisation

8. Design methods (cont.) • Schemes used as basis for the protocols: • Diffie-Hellman • Elliptic Curve Cryptography • MQV protocol

9. Analysis of protocols • Wanted security features • Known key security • Forward secrecy • Key compromise impersonation • Unknown key-share • Key Control

10. Known key security • A protocol run should result in a unique secret session key. If this key is compromised, it should have no impact on other session keys.

11. Forward secrecy • Even if long-term private keys are compromised, it should not have any effect on the secrecy of previously established session keys.

12. Key compromise impersonation • If entity A's long-term private key are compromised, an adversary is able to impersonate A. But this should not enable him to impersonate other entities to A.

13. Unknown key-share • If entity A wants to create a secret key with B, it should not be possible that A is tricked into sharing a key with entity C.

14. Key Control • Neither of the entities should be able to force the session key to a value of his choice.

15. Analysis of protocols

16. Outline of analysis presentation • Popescu’s protocol – forward secrecy  OK • Popescu’s protocol – key compromise impersonation  not met • Harn-Hsin-Mehta’s protocol – forward secrecy  not met • Harn-Hsin-Mehta’s protocol – key compromise impersonation - OK

17. Popescu’s protocol 1/2

18. Popescu’s protocol 2/2

19. Popescu meets the forward secrecy goal • The session key is created by KA = -kA * VBor KB = -kB * VA ( K = kA * kB * P). (kA and kB random secret values). • The long term private keys a and b does not affect the session key. • Forward secrecy: Even if long-term private keys are compromised, it should not have any effect on the secrecy of previously established session keys.

20. Problem: does not meet the key compromise impersonation goal • The authentication of the parties is based on the knowledge of Ks = -b * YA = -a * YB (a, b private, YA, YB public). • If an attacker gets hold of the private value a, he can use this information to impersonate A to B. • But he can also impersonate B to A. • Key Compromise Impersonation: If entity A's long-term private key are compromised, an adversary is able to impersonate A. But this should not enable him to impersonate other entities to A.

21. Harn-Hsin-Mehta’s protocol 1/2

22. Harn-Hsin-Mehta’s protocol 2/2

23. Problem: no forward secrecy • Session key from A to B: kAB = (rA)dB mod nB • The value nBis publicly known, and rAis transmitted. The secrecy is only based on dB. • If an attacker gets hold of this value, he can compute the session key for messages sent from A to B. • Forward secrecy: Even if long-term private keys are compromised, it should not have any effect on the secrecy of previously established session keys.

24. Problem: no forward secrecy (cont.) • If the attacker has eavesdropped on previous protocol runs, he may compute all previous session keys as long as the known private key dB has been used to create the session key. • Forward secrecy: Even if long-term private keys are compromised, it should not have any effect on the secrecy of previously established session keys.

25. Harn-Hsin-Mehta meets the key compromise impersonation goal • We assume an attacker knowing A’s private key dA tries to impersonate B to A. • The attacker can compute k’BA = (RA)kBmod nA (RA and nA are public values, and he may choose kBfreely) • But he cannot compute kAB = (rA)dBmod nB

26. Harn-Hsin-Mehta meets the key compromise impersonation goal • The attacker does not know the correct value of kAB, and can not compute a signature that A will accept. • Key Compromise Impersonation: If entity A's long-term private key are compromised, an adversary is able to impersonate A. But this should not enable him to impersonate other entities to A.

27. Conclusion • 3 of 5 protocols failed to meet all the requirements. • All the problems encountered is caused by disclosure of long-term secret keys. • The result of the analysis is no proof of how secure a protocol is. • But it shows the need for better routines for analysing/securing new protocols.

28. Questions?