1. Certificateless Authenticated Two-Party Key Agreement Protocols
Master Thesis
Tarjei K. Mandt

2. Agenda Introduction Certificateless Public Key Cryptography
Key Agreement Protocols
Proposed Protocol
Security and Efficiency Analysis
Certificate management: verification, distribution, revocation, etc. of certificates
Key escrow: The trusted authority knows every user’s private key and may recover session keys
Can CL-PKC be used to devise more efficient and secure schemes?

3. Problems
Certificate management in traditional public key infrastructure (PKI) is inefficient
Key escrow in identity-based public key cryptography (ID-PKC)
Can certificateless public key cryptography
(CL-PKC) be used to design more efficient and
secure key agreement schemes?
Certificate management: verification, distribution, revocation, etc. of certificates
Key escrow: The trusted authority knows every user’s private key and may recover session keys
Can CL-PKC be used to devise more efficient and secure schemes?

4. Contribution
A new efficient certificateless authenticated two-party key agreement protocol
A protocol that can be used to establish keys between users of distinct domains
Security- and adversary model for certificateless authenticated key agreement
Proposed a new certificateless authenticated key agreement protocol that is more efficient than the current scheme proposed in 2003.
Proposed a protocol that can establish session keys between users of different domains (under different trusted authorities)
Analyzed the security properties of the protocol, and suggested a security- and adversary model for certificateless authenticated key agreement.

5. Why Certificateless Public Key Cryptography?
No certificates used (PKI)
Low storage and communication bandwidth
No need to verify certificates (certificate chains)
Higher degree of privacy
Public keys are always valid
No need for revocation (CRLs)
No key escrow (ID-PKC)
Trusted authority cannot recover session keys
Trusted authority cannot forge signatures
No certificates are used to authenticate public keys
CL-PKC storage and communication bandwidth is low because the identifier only contains relevant information; certificate-related redundancies are not present
CL-PKC potentially reduces computational bandwidth, as certificates do not need to be verified before the public keys are used.
CL-PKC offers its users a higher degree of privacy due to its inclusion of only relevant information in the identifier. Certificates can contain a lot of irrelevant information (depending on application) such as date of birth, an address etc.
Public keys are always valid.
In CL-PKC, the key generation center does not know every user’s private key. Thus, the KGC cannot recover session keys nor forge signatures.

6. Certificateless Public Key Cryptography (1)
Public Key Infrastructure
Identity-based Cryptography
CL-PKC enjoys the advantages of both worlds, and can thus be considered a cross between PKI and ID-PKC.

7. Certificateless Public Key Cryptography (2)
Key Generation
Center (KGC)
Alice’s identity
Alice
Partial private key
secret value
Bob
Basically you present yourself to the Key Generation Center saying this is my identity. It could be an address, an ip-address, anything as long as it uniqely identifies you in the system. The KGC then returns a partial private key
Each key is represented by an integer point on an elliptic curve.
master-key
partial private
key +
secret value
Private Key
secret value ×
public generator
Public Key

8. Key Agreement (1) Two or more parties agree on a shared key
Both parties contribute with input
Diffie-Hellman model used today
Authenticated Key Agreement ensures that only the intended parties can compute the session key
Bilinear pairings of elliptic curve groups used extensively today (provides shorter keys)

9. Key Agreement (2) Alice Bob Key Agreement Key Agreement Shared Secret
Alice’s private key
Bob’s public key
Alice’s public key
Bob’s private key
Key
Agreement
Key
Agreement
Shared Secret

10. Diffie-Hellman Key Exchange
Alice
Bob a gb ga b
Alice’s private key
Bob’s public key
Alice’s public key
Bob’s private key
gba
gab
Many key agreement models build on the Diffie-Hellman key exchange.
secret key
secret key
Shared Secret

11. Man-in-the-Middle Attack on Diffie-Hellman
Alice
Eve
Bob ga gc
gcb gb
Key agreement schemes that aren’t properly authenticated may be vulnerable to man-in-the-middle attacks.
In this case, Eve will know both Alice’s and Bob’s session key, and can modify messages at will.
One solution is to sign the exchanged keys but this requires additional computation. gc
gca
Signing exchanged keys is inconvenient (size, computation)
Including identities can achieve proper authentication

12. Computational Problems
Discrete Logarith problem (DLP) Given <g,q>, find an element a, such that ga = q
EC Discrete Logarithm problem Given <P,Q>, find an element a, such that aP = Q
EC Computational Diffie-Hellman (CDH) problem Given <P,aP,bP>, compute abP
Bilinear Diffie-Hellman (BDH) problem Given <P,aP,bP,cP>, compute ê(P,P)abc
DLP > CDHP > BDHP example: ê(abP,cP) = ê(P,cP)ab = ê(P,P)abc
There are a number of problems that need to be solved for a key agreement protocol to be broken.
Finally, we see that if one manages to solve the discrete logarithm problem, then computational diffie-hellman problem becomes easy.
And similarily, if the CDH problem is easy, then the BDHP is easy to solve.

13. Proposed protocol Key Generation Center
Master-key: s
KGC public key: sP
In the proposed protocol, Alice and Bob each hold a short-term and long-term key pair. The long-term key pair is the public and private keys which are used in every protocol run. The short-term key pair is session-specific and changes from one protocol run to another.
In a protocol run, the participants exchange long-term and short-term public keys. They can then compute the shared session key.

14. Proposed protocol Alice Key Generation Center Partial private key
Master-key: s
KGC public key: sP
Partial private key
DA = sQA
Private key
SA = <DA,xA>
Alice
In the proposed protocol, Alice and Bob each hold a short-term and long-term key pair. The long-term key pair is the public and private keys which are used in every protocol run. The short-term key pair is session-specific and changes from one protocol run to another.
In a protocol run, the participants exchange long-term and short-term public keys. They can then compute the shared session key.
Public key
PA = xAP

15. Proposed protocol Alice Bob Key Generation Center Partial private key
Master-key: s
KGC public key: sP
Partial private key
DA = sQA
Partial private key
DB = sQB
Private key
SA = <DA,xA>
Alice
Bob
Private key
SB = <DB,xB>
In the proposed protocol, Alice and Bob each hold a short-term and long-term key pair. The long-term key pair is the public and private keys which are used in every protocol run. The short-term key pair is session-specific and changes from one protocol run to another.
In a protocol run, the participants exchange long-term and short-term public keys. They can then compute the shared session key.
Public key
PA = xAP
Public key
PB = xBP

16. Proposed protocol Alice Bob Key Generation Center TA, PA TB, PB
Master-key: s
KGC public key: sP
Partial private key
DA = sQA
Partial private key
DB = sQB
Private key
SA = <DA,xA>
Alice
TA, PA
Bob
Private key
SB = <DB,xB> a
TA = aP b
TB = bP
In the proposed protocol, Alice and Bob each hold a short-term and long-term key pair. The long-term key pair is the public and private keys which are used in every protocol run. The short-term key pair is session-specific and changes from one protocol run to another.
In a protocol run, the participants exchange long-term and short-term public keys. They can then compute the shared session key.
Public key
PA = xAP
TB, PB
Public key
PB = xBP

17. K = ê(QB, P)a(s+xB) · ê(QA,P)b(s+xA)
Proposed protocol
Key Generation Center
Master-key: s
KGC public key: sP
Partial private key
DA = sQA
Partial private key
DB = sQB
Private key
SA = <DA,xA>
Alice
TA, PA
Bob
Private key
SB = <DB,xB> a
TA = aP b
TB = bP
In the proposed protocol, Alice and Bob each hold a short-term and long-term key pair. The long-term key pair is the public and private keys which are used in every protocol run. The short-term key pair is session-specific and changes from one protocol run to another.
In a protocol run, the participants exchange long-term and short-term public keys. They can then compute the shared session key.
Public key
PA = xAP
TB, PB
Public key
PB = xBP
KA = ê(QB, PB + sP)a · ê(xAQA + DA,TB)
KB = ê(QA, PA + sP)b · ê(xBQB + DB,TA)
K = ê(QB, P)a(s+xB) · ê(QA,P)b(s+xA)

18. Proposed protocol with multiple KGCs
Master-key: s1
KGC public key: s1P
KGC 2
Master-key: s2
KGC public key: s2P
standardized
elliptic curve parameters
Partial private key
DA = s1QA
Partial private key
DB = s2QB
Private key
SA = <DA,xA>
Alice
TA, PA
Bob
Private key
SB = <DB,xB> a
TA = aP b
TB = bP
This protocol can be used to agree keys between users of different networks, or under different key generation centers.
It assumes that there are some standardized elliptic curve paramteres between the KGCs.
The only real difference is that Alice must use the public key of Bob’s KGC in computing the session key and vice-versa.
Public key
PA = xAP
TB, PB
Public key
PB = xBP
KA = ê(QB, PB + s2P)a · ê(xAQA + DA,TB)
KB = ê(QA, PA + s1P)b · ê(xBQB + DB,TA)
K = ê(QB, P)a(s2+xB) · ê(QA,P)b(s1+xA)

19. (Final) Session Key Need to use a Key Derivation Function (KDF)
To ensure forward secrecy
To prevent the key reveal attack
To ensure compromise of short-term private values does not break the protocol
A secure hash function H is an ideal KDF
A key derivation function is used to destroy the algebraic properties of a key.
A KDF ensures forward secrecy which prevents compromised private keys from compromising the session key.
A KDF also prevents the key reveal attack in which an attacker obtains a session key that can reveal information about another session key.
If both short-term values of a session are compromised, then an attacker can obtain the shared secret unless a proper KDF is used.
Even though short-term private values are not exchanged, these could be precomputed and stored insecurely.
The use of a hash function prevents the key reveal attack, abP/baP ensures forward secrecy, and the last element ensures compromise of short-term values does not reveal the session key.
FKA = H(K, abP, xAxBP)
FKB = H(K, baP, xBxAP)
long-term
public key
session key
short-term
public key
short-term
private key
(long-term)
secret value

20. Protocol’s Security Security reduces to the BDH/CDH problem
A KGC who replaces public keys (long-term and short-term) can attack the protocol
Can be addressed by incorporating public keys into the identity elements: QA = H1(IDA,PA)
Thus, we define two adversaries:
Type I: replaces public keys, does not know master-key
Type II: knows master-key, does not replace public keys
An outside attacker (only has access to public values) has to solve the bilinear diffie-hellman problem (cdh when KDF is used) in order to break the protocol.
A KGC who replaces public keys can break the protocol by generating the corresponding private key.

21. Security Attributes Known-key security Forward secrecy
Each run should produce a different session key
Forward secrecy
Leaked private keys should not reveal a session key
KGC forward secrecy
Key-compromise impersonation
An adversary should not be able to impersonate other entities to A using A’s private key
Unknown key share
A should not share a key with C, when believing she is sharing a key with B
Known session-specific temporary information security
Leaked short-term keys should not reveal a session key
In the face of both these adversaries, the protocol obtains the follwing security attributes.
Known-key security: Each session produces a different key due to the ephemeral values
Forward secrecy: If an adversary compromises the long-term private keys, past keys cannot be computed due to the inclusion of short-term values in the session key.
Key-compromise impersonation:

22. Example: Forward Secrecy
Alice
Bob
establishes n
session keys

23. Example: Forward Secrecy
Alice
Bob
establishes n
session keys
Eve
Alice’s private key
Bob’s private key

24. Example: Forward Secrecy
Alice
Bob
establishes n
session keys
Eve
Alice’s private key
Bob’s private key
Eve can compute K, but not H(K,abP,xAxBP)
Specifically, Eve must know a or b of a given session to compute a · bP = b · aP = abP

25. Protocol’s Efficiency
Type
No precomputation
Precomputation
Smart ID
2p + 1m + 1e 1p
Chen-Kudla # ’1
2p + 2m + 1e
1p + 1m
Chen-Kudla # ’2
1p + 4m
Al-Riyami-Paterson CL
4p + 2m + 1e
4p + 1m
Our protocol
2p + 3m + 1e
2p + 2m
Our protocol (public keys known)
The use of precomputation is desirable as it allows users to compute values before a protocol run, and thus saves on-line computational costs (more efficient).
If our protocol is used in a network where the public keys are known, or many keys are agreed, it is competitive with id-based protocols.
None of the above protocols have all the security attributes as shown on the previous slide.
p = pairing, m = point multiplication, e = pairing exponentiation
Precomputation: known values are computed before the key agreement

26. Conclusions More efficient than previous protocol
Only 2 pairings
Public keys only comprise one group element
Possible to adapt to a multi-TA setting
For instance, ideal in VoIP networks
Efficiency competitive with ID-PKC when many keys are agreed (public keys are known)

27. Questions?