Analysis of Key Agreement Protocols Brita Vesterås Supervisor: Chik How Tan
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.
Why do protocols contain security flaws? New attacks arise. Hard/impossible to consider all possible attack scenarios.
Work of this thesis Summarise different attack methods on key agreement protocols Describe design methods of key agreement protocols Analyse five key agreement protocols
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
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 certificate manipulation - modification of the certificate protocol interaction - using a new protocol to interact with a known protocol
Design methods ”One-way functions” – functions that are hard to solve without additional information –hash functions –discrete logarithm –elliptic curve discrete logarithm problem –factorisation
Design methods (cont.) Schemes used as basis for the protocols: –Diffie-Hellman –Elliptic Curve Cryptography –MQV protocol
Analysis of protocols Wanted security features –Known key security –Forward secrecy –Key compromise impersonation –Unknown key-share –Key Control
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.
Forward secrecy Even if long-term private keys are compromised, it should not have any effect on the secrecy of previously established session keys.
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.
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.
Key Control Neither of the entities should be able to force the session key to a value of his choice.
Analysis of protocols
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
Popescu’s protocol 1/2
Popescu’s protocol 2/2
Popescu meets the forward secrecy goal The session key is created by K A = -k A * V B or K B = -k B * V A ( K = k A * k B * P). (k A and k B 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.
Problem: does not meet the key compromise impersonation goal The authentication of the parties is based on the knowledge of K s = -b * Y A = -a * Y B (a, b private, Y A, Y B 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.
Harn-Hsin-Mehta’s protocol 1/2
Harn-Hsin-Mehta’s protocol 2/2
Problem: no forward secrecy Session key from A to B: k AB = (r A ) dB mod n B The value n B is publicly known, and r A is transmitted. The secrecy is only based on d B. 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.
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 d B 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.
Harn-Hsin-Mehta meets the key compromise impersonation goal We assume an attacker knowing A’s private key d A tries to impersonate B to A. The attacker can compute k’ BA = (R A ) kB mod n A (R A and n A are public values, and he may choose k B freely) But he cannot compute k AB = (r A ) dB mod n B
Harn-Hsin-Mehta meets the key compromise impersonation goal The attacker does not know the correct value of k AB, 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.
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.
Questions?