Certificateless Public Key Cryptography

Certificateless Authenticated TwoParty Key Agreement Protocols
Master Thesis
Tarjei K. Mandt
09.06.2006
Agenda
•
•
•
•
•
Introduction
Certificateless Public Key Cryptography
Key Agreement Protocols
Proposed Protocol
Security and Efficiency Analysis
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?
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
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
Certificateless Public Key
Cryptography (1)
Certificateless Public
Key Cryptography
Public Key
Infrastructure
Identity-based
Cryptography
Certificateless Public Key
Cryptography (2)
Alice’s identity
Alice
Partial private key
secret value
Private Key
Public Key
partial private
key
+
secret value
secret value
×
public generator
Key Generation
Center (KGC)
Bob
master-key
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)
Key Agreement (2)
Alice
Alice’s private key
Bob
Bob’s public key
Alice’s public key
Key
Agreement
Bob’s private key
Key
Agreement
Shared Secret
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
secret key
secret key
Shared Secret
Man-in-the-Middle Attack
on Diffie-Hellman
Alice
Eve
Bob
ga
gc
gb
gca
gcb
gc
• Signing exchanged keys is inconvenient (size, computation)
• Including identities can achieve proper authentication
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
Proposed protocol
Key Generation Center
Master-key: s
KGC public key: sP
Proposed protocol
Key Generation Center
Master-key: s
KGC public key: sP
Partial private key
DA = sQA
Private key
SA = <DA,xA>
Public key
PA = xAP
Alice
Proposed protocol
Key Generation Center
Master-key: s
KGC public key: sP
Partial private key
DA = sQA
Private key
SA = <DA,xA>
Public key
PA = xAP
Alice
Partial private key
DB = sQB
Bob
Private key
SB = <DB,xB>
Public key
PB = xBP
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
Public key
PA = xAP
a
TA = aP
TB, PB
b
TB = bP
Private key
SB = <DB,xB>
Public key
PB = xBP
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
Public key
PA = xAP
a
TA = aP
TB, PB
b
TB = bP
KA = ê(QB, PB + sP)a · ê(xAQA + DA,TB)
Private key
SB = <DB,xB>
Public key
PB = xBP
KB = ê(QA, PA + sP)b · ê(xBQB + DB,TA)
K = ê(QB, P)a(s+xB) · ê(QA,P)b(s+xA)
Proposed protocol with
multiple KGCs
KGC 1
standardized
elliptic curve parameters
Master-key: s1
KGC public key: s1P
KGC 2
Master-key: s2
KGC public key: s2P
Partial private key
DA = s1QA
Partial private key
DB = s2QB
Private key
SA = <DA,xA>
Alice
TA, PA
Bob
Public key
PA = xAP
a
TA = aP
TB, PB
b
TB = bP
KA = ê(QB, PB + s2P)a · ê(xAQA + DA,TB)
Private key
SB = <DB,xB>
Public key
PB = xBP
KB = ê(QA, PA + s1P)b · ê(xBQB + DB,TA)
K = ê(QB, P)a(s2+xB) · ê(QA,P)b(s1+xA)
(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
FKA = H(K, abP, xAxBP)
FKB = H(K, baP, xBxAP)
long-term
public key
session key
short-term
private key
short-term
public key
(long-term)
secret value
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
Security Attributes
 Known-key security
• 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
Example: Forward
Secrecy
Alice
establishes n
session keys
Bob
Example: Forward
Secrecy
Alice
Alice’s private key
establishes n
session keys
Eve
Bob
Bob’s private key
Example: Forward
Secrecy
Alice
Alice’s private key
establishes n
session keys
Eve
Bob
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
Protocol’s Efficiency
Protocol
Type
No precomputation
Precomputation
Smart
ID
2p + 1m + 1e
1p
Chen-Kudla # ’1
ID
2p + 2m + 1e
1p + 1m
Chen-Kudla # ’2
ID
1p + 4m
1p + 1m
Al-Riyami-Paterson
CL
4p + 2m + 1e
4p + 1m
Our protocol
CL
2p + 3m + 1e
2p + 2m
Our protocol
(public keys known)
CL
2p + 3m + 1e
1p + 1m
p = pairing, m = point multiplication, e = pairing exponentiation
Precomputation: known values are computed before the key agreement
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)
Questions?