Date post: | 18-Dec-2015 |
Category: |
Documents |
View: | 216 times |
Download: | 0 times |
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