Certificateless Authenticated Two Party Key Agreement Protocols Master

Certificateless Authenticated Two. Party 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 × 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’s private key 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 Alice’s private key Bob’s public key ga b Alice’s public key Bob’s private key gba gab 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 , find an element a, such that ga = q • EC Discrete Logarithm problem Given , find an element a, such that a. P = Q • EC Computational Diffie-Hellman (CDH) problem Given , compute ab. P • Bilinear Diffie-Hellman (BDH) problem Given , compute ê(P, P)abc • DLP > CDHP > BDHP example: ê(ab. P, c. P) = ê(P, c. P)ab = ê(P, P)abc

Proposed protocol Key Generation Center Master-key: s KGC public key: s. P

Proposed protocol Key Generation Center Master-key: s KGC public key: s. P Partial private key DA = s. QA Private key SA = Public key PA = x A P Alice

Proposed protocol Key Generation Center Master-key: s KGC public key: s. P Partial private key DA = s. QA Private key SA = Public key PA = x A P Alice Partial private key DB = s. QB Bob Private key SB = Public key PB = x B P

Proposed protocol Key Generation Center Master-key: s KGC public key: s. P Partial private key DA = s. QA Partial private key DB = s. QB Private key SA = Alice TA , P A Bob Public key PA = x A P a TA = a. P TB , P B b TB = b. P Private key SB = Public key PB = x B P

Proposed protocol Key Generation Center Master-key: s KGC public key: s. P Partial private key DA = s. QA Partial private key DB = s. QB Private key SA = Alice TA , P A Bob Public key PA = x A P a TA = a. P TB , P B b TB = b. P KA = ê(QB, PB + s. P)a · ê(x. AQA + DA, TB) Private key SB = Public key PB = x B P KB = ê(QA, PA + s. P)b · ê(x. BQB + DB, TA) K = ê(QB, P)a(s+x. B) · ê(QA, P)b(s+x. A)

Proposed protocol with multiple KGCs KGC 1 standardized elliptic curve parameters Master-key: s 1 KGC public key: s 1 P KGC 2 Master-key: s 2 KGC public key: s 2 P Partial private key DA = s 1 Q A Partial private key DB = s 2 Q B Private key SA = Alice TA , P A Bob Public key PA = x A P a TA = a. P TB , P B b TB = b. P KA = ê(QB, PB + s 2 P)a · ê(x. AQA + DA, TB) Private key SB = Public key PB = x B P KB = ê(QA, PA + s 1 P)b · ê(x. BQB + DB, TA) K = ê(QB, P)a(s 2+x. B) · ê(QA, P)b(s 1+x. A)

(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, ab. P, x. Ax. BP) FKB = H(K, ba. P, x. Bx. AP) 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 = H 1(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’s private key establishes n session keys Eve Bob’s private key

Example: Forward Secrecy Alice’s private key establishes n session keys Eve Bob’s private key • Eve can compute K, but not H(K, ab. P, x. Ax. BP) • Specifically, Eve must know a or b of a given session to compute a · b. P = b · a. P = ab. P

Protocol’s Efficiency Protocol Type No precomputation Precomputation Smart ID 2 p + 1 m + 1 e 1 p Chen-Kudla # ’ 1 ID 2 p + 2 m + 1 e 1 p + 1 m Chen-Kudla # ’ 2 ID 1 p + 4 m 1 p + 1 m Al-Riyami-Paterson CL 4 p + 2 m + 1 e 4 p + 1 m Our protocol CL 2 p + 3 m + 1 e 2 p + 2 m Our protocol (public keys known) CL 2 p + 3 m + 1 e 1 p + 1 m 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 Vo. IP networks • Efficiency competitive with ID-PKC when many keys are agreed (public keys are known)

Questions?