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 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?