Analysis of Key Agreement Protocols

Brita VesteråsSupervisor: 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 KA = -kA * VB or 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.

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.

Harn-Hsin-Mehta’s protocol 1/2

Harn-Hsin-Mehta’s protocol 2/2

Problem: no forward secrecy

• Session key from A to B: kAB = (rA)dB mod nB

• The value nB is publicly known, and rA is 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.

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.

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)kB mod nA

(RA and nA are public values, and he may choose kB freely)

• But he cannot compute kAB = (rA)dB mod nB

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.

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?