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?