secret handshakes from ca-oblivious encryption asiacrypt 2004, jeju-do, korea claude castelluccia,...

Secret HandshakesSecret HandshakesfromfromCA-Oblivious EncryptionCA-Oblivious Encryption

Asiacrypt 2004, Jeju-do, Korea

Claude Castelluccia, Stanisław Jarecki, Gene Tsudik

UC Irvine

Public Key AuthenticationNo Affiliation Privacy

certA = SIGUCI{ “Alice, etc”, A}

Alice: PK A, certified by UCI

Bob

proof of possession of Sec.Key SKA A

Alice’s affiliation (UCI) is revealed by her certificate

• Can Alice authenticate herself in a way that reveals her affiliation only if the verifier passes some criteria she sets?• Seems like a Chicken and Egg Problem: The party that authenticates itself first has to reveal its affiliation…

A1: Only IACR members learn Alice’s affiliationA2: Only IACR members learn that IACR Alice’s

policyB: (and vice versa for Bob)

, certified by IACR

“Secret Handshake”:Authentication with Secrecy Properties

Alice, certified by UCI

Secret Handshake Protocol

Bob

PolicyA= {IACR}

certA = SIGUCI{A}

certB = SIGIACR{B}

PolicyB = {UCI}

Parties Exchange Pseudonyms A,B

Secret Handshake AuthenticationOur Results

• Previous Results:- Privacy for Symmetric-Key Authentication [e.g.

Abadi]- Secret Handshakes (for Public-Key Authentication)

introduced in [Balfanz, et al.’03], solved under “Bilinear Diffie-Hellman” assumption on El. Curves with Bilinear Maps

• Our Results:- Solution based on standard groups, assuming

hardness of Computational Diffie-Hellman- Efficiency improvements- Blinded certificate issuance => Less trust in CA- Extension to general PKI where A and B have

different CA’s- Connection with “CA-Oblivious” Encryption

Alice’s PK A, Alice’s CA UCI, certA

Alice, certified by UCI

Standard Authentication usingPublic Key Infrastructure

proof of possession of Sec.Key SKA A

On input UCI and A,Bob verifies the

proof

certA = SIGUCI{A}

Bob

Sec.Key SKA

Alice’s PK A, Alice’s CA UCI, certA

Pseudonym A, Alice’s CA UCI, certA

proof of possession of UCI’s signature on A

Alice, certified by UCI

PKI-based Authentication(changing the terms )

On input UCI and A,Bob verifies the

proof

certA = SIGUCI{A}

Certificate certA, i.e. CA’s signature on Alice’s public key A,

can serve as the only authentication secret no need for the secret key SKA

no need for A to be a public key (any ID string will do)

?

Sec.Key SKA

Bob

Affiliation Privacy in Authentication: Problem for Both Parties

Alice, certified by UCIAlice’s Pseudonym A

Bob’s Pseudonym B

certA = SIGUCI{A}

certB = SIGIACR{B}

PolicyB = {UCI}PolicyA= {IACR}

Bob, certified by IACR

proof of possession of UCI’s sign. on A

proof of possession of IACR’s sign. on B

Security of the Authentication Scheme:For Alice: Semantic security of Enc => only Bob can return n For Bob: Proof of signature possession includes Bob’s nonce

Our Solution: Secret Handshakes fromSignature-Based Encryption (pt.1)

EncPK(IACR,B){A, proof of poss. of SIGUCI{A} + n}

n

Alice, certified by UCI

encryption key derived for (IACR,B)

signature =decryption key

certA = SIGUCI{A} PolicyB = {UCI}

certB = SIGIACR{B}

Bob, certified by IACR

Bob’s Pseudonym B

PolicyA= {IACR}

What’s needed for “Secret Handshake” Secrecy:

1. CA-obliviousness: Pseudonym B must hide Bob’s CA Ciphertext must hide CA Alice used in

encryption

Our Solution: Secret Handshakes fromSignature-Based Encryption (pt.2)

EncPK(IACR,B){A, proof of poss. of SIGUCI{A} + n}

n

Alice, certified by UCI

encryption key derived for (IACR,B)

signature =decryption key

certA = SIGUCI{A} PolicyB = {UCI}

certB = SIGIACR{B}

Bob, certified by IACR

Bob’s Pseudonym B

PolicyA= {IACR}

2. Semantic security of Encryption under Chosen Message Attack

Chosen-Message Attackon a Signature Scheme:

Unsigned message M*+

Forged signature on M*

Mn

Signer(PK)

SigPK(Mn)M1 SigPK(M1)

Chosen-Message Attackon Signature-Based Encryption:

Bn SigPK(Bn)B1 SigPK(B1)

Certification Authority

(PK = IACR)

Unsigned Pseudonym B*m1, m2

EncPK(IACR,B*){mb} b

Signature Security: inability to output on B*Encryption Security: inability to use B* to

decrypt

Previous Results onSignature-Based Encryption

• Signature-Based Encryption of [Li,Du,Boneh, PODC’03]- RSA, Factoring (Rabin Sigs.), or Billinear Maps (BLS

Sigs.)- No secrecy properties

• Here:- Computational Diffie-Hellman (Schnorr Signatures)- Affiliation secrecy for both sender and receiver

Terminology Caveat:[LDB]’s “obliviousness”: sender doesn’t know if receiver

decryptsOur “CA-obliviousness”: affiliation privacy for both

parties

Schnorr Signature (CA is the signer):SKCA: x , PKCA: y = g x mod p

Sign(“B”) = (s,r) , s.t. g s = r * y H(r,“B”) mod p

CA-oblivious Signature-Based Encryption secure under Comp. Diffie-Hellman [CDH]

Schnorr-based Encryption (Bob is a decryptor):Pseudonym: (r ,“B”), for a random

string “B”Decryption Key: SKB = s

Encryption Key: PKB = r * y H(r,“B”) [= g s]ElGamal ciphertext: (c1,c2) = (g k , H( PKB k ) M)

CA-obliviousness: r and c1 are random values in Zp

*

Semantic Security under CMA attack: Recall [PS’96]: Schnorr sign. forger => x (DL attack) Ciphertext distinguisher => computing zx on rnd. z

(CDH att.)

Contributions:• “Secret Handshake” Authentication under

Computational Diffie Hellman (no bilinear maps)

• Efficiency improvements, reduced trust in CA

Open Problems:• How to handle certificate chains?• Linkability (our pseudonyms are constant &

public)• O(n2) computation blow-up when Bob has n

certificates and Alice has n CA’s in its policy

Conclusions and Open Problems