Certificateless Authenticated Two-Party Key Agreement

ProtocolsMaster Thesis

Tarjei K. Mandt09.06.2006

• Introduction• Certificateless Public Key Cryptography• Key Agreement Protocols• Proposed Protocol• Security and Efficiency Analysis

Agenda

• Certificate management in traditional public key infrastructure (PKI) is inefficient

• Key escrow in identity-based public key cryptography (ID-PKC)

Problems

Can certificateless public key cryptography(CL-PKC) be used to design more efficient and

secure key agreement schemes?

• 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

Contribution

• 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

Why Certificateless Public Key

Cryptography?

Certificateless Public Key Cryptography (1)

Public KeyInfrastructure

Identity-basedCryptography

Certificateless PublicKey Cryptography

Alice

Bob

Key GenerationCenter (KGC)

Certificateless Public Key Cryptography (2)

Alice’s identity

Partial private key

partial privatekey+

secret value

secret value×

public generator

Private Key Public Key master-key

secret value

• 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 (1)

Alice

Alice’s private key

KeyAgreement

Bob’s public key

Shared Secret

Alice’s public key

KeyAgreement

Bob’s private key

Bob

Key Agreement (2)

Alice

Alice’s private key Bob’s public key

Shared Secret

Alice’s public key Bob’s private key

Bob

Diffie-Hellman Key Exchange

a gb ga b

gba

secret key

gab

secret key

Alice Bob

Man-in-the-Middle Attack

on Diffie-Hellman

gb

ga

Eve

gc

gcagc

gcb

• Signing exchanged keys is inconvenient (size, computation)• Including identities can achieve proper authentication

• Discrete Logarith problem (DLP)Given <g,q>, find an element a, such that ga = q

• EC Discrete Logarithm problemGiven <P,Q>, find an element a, such that aP = Q

• EC Computational Diffie-Hellman (CDH) problemGiven <P,aP,bP>, compute abP

• Bilinear Diffie-Hellman (BDH) problemGiven <P,aP,bP,cP>, compute ê(P,P)abc

• DLP > CDHP > BDHPexample: ê(abP,cP) = ê(P,cP)ab = ê(P,P)abc

Computational Problems

Key Generation CenterMaster-key: s

KGC public key: sP

Proposed protocol

Alice

Key Generation CenterMaster-key: s

KGC public key: sP

Partial private keyDA = sQA

Private keySA = <DA,xA>

Public keyPA = xAP

Proposed protocol

Alice Bob

Key Generation CenterMaster-key: s

KGC public key: sP

Partial private keyDB = sQB

Partial private keyDA = sQA

Private keySA = <DA,xA>

Public keyPA = xAP

Private keySB = <DB,xB>

Public keyPB = xBP

Proposed protocol

Alice Bob

Key Generation CenterMaster-key: s

KGC public key: sP

TA, PA

TB, PB

Partial private keyDB = sQB

Partial private keyDA = sQA

Private keySA = <DA,xA>

Public keyPA = xAP

Private keySB = <DB,xB>

Public keyPB = xBP

aTA = aP

bTB = bP

Proposed protocol

Alice Bob

Key Generation CenterMaster-key: s

KGC public key: sP

TA, PA

TB, PB

Partial private keyDB = sQB

Partial private keyDA = sQA

Private keySA = <DA,xA>

Public keyPA = xAP

Private keySB = <DB,xB>

Public keyPB = xBP

aTA = aP

bTB = bP

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)

Proposed protocol

Alice Bob

KGC 1Master-key: s1

KGC public key: s1P

TA, PA

TB, PB

Partial private keyDB = s2QB

Partial private keyDA = s1QA

Private keySA = <DA,xA>

Public keyPA = xAP

Private keySB = <DB,xB>

Public keyPB = xBP

aTA = aP

bTB = bP

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)

Proposed protocol with multiple KGCs

KGC 2Master-key: s2

KGC public key: s2P

standardizedelliptic curve parameters

• 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

(Final) Session Key

FKA = H(K, abP, xAxBP)

FKB = H(K, baP, xBxAP)

session key

short-termprivate key

short-termpublic key

(long-term)secret value

long-termpublic key

• 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

Protocol’s Security

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

Security Attributes

Example: Forward Secrecy

Alice Bobestablishes nsession keys

Example: Forward Secrecy

Eve

Alice Bob

Alice’s private key

Bob’s private key

establishes nsession keys

Example: Forward Secrecy

Eve

Alice Bob

• 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

establishes nsession keys

Alice’s private key

Bob’s private key

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 exponentiationPrecomputation: known values are computed before the key

agreement

Protocol’s Efficiency

• 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)

Conclusions

Questions?