Secret Hanshakes

1
On Privacy-Preserving Secure Interaction
Gene Tsudik Computer Science Department University
of California, Irvine CURRENTLY Fulbright
Senior Lecturer Dipartimento di
Informatica Universita degli Studi di Roma La
Sapienza
2
Why Privacy?

• Basic human right and desire
• Transcends physical and electronic worlds
• Being assaulted from many directions
• Sometimes well-meaning and legitimate
• Privacy can be good for everyone
• Individuals
• Corporations
• Governments
• Obviously, privacy has a sinister side
• Do we stop here?

3
Privacy Areas

• Anonymous communication
• Asynchronous, e.g., Email
• Synchronous, e.g., HTTP
• Traffic analysis resistance
• Location/movement privacy
• E.g., Internet, MANETs, cellular, RFIDs
• Private information retrieval (PIR)
• Hiding source and access patterns
• Anonymous signing (escrowed anonymity)
• Group signatures, ring signatures, etc.
• Etc., etc., etc.

4
Privacy-Preserving Secure Interaction?

• New notion of Affiliation-Hiding
• Informally
• if I dont fully trust you, you dont need to
  know who issued my credentials
• or
• You dont need to see my certificate
• One-sided interaction
• information delivery with a twist
• Two-sided interaction
• all-or-nothing unobservable authentication
• Many-sided interaction
• all-or-nothing unobservable group authentication
• sometimes more subtle than all-or-nothing

5
References

• OSBE-s
• Du, et al., Oblivious Signature-Based
  Envelopes, ACM PODC 2003.
• Nasserian and Tsudik, OSBE Revisited, FC 2006.
• Secret Hanshakes
• Balfanz, et al., Secret Handshakes, IEEE SP
  (Oakland) 2003.
• Xu and Yung, K-Anonymous Secret Handshakes with
  Reusable Credentials, ACM CCS 2004.
• Castelluccia, et al., Secret Handshakes from
  CA-oblivious Encryption, IACR Asiacrypt 2004.
• Ateniese, et al., Secret Handshakes with Dynamic
  and Fuzzy Matching, NDSS 2007.
• Group Secret Handshakes
• Jarecki, et al., Authentication for Paranoids
  Multi-Party Secret Handshakes, ACNS 2006.
• Jarecki, et al., Affiliation-Hiding
  Authenticated Group Key Agreement, CT-RSA 2007.
• Tsudik and Xu, A Framework for Group Secret
  Handshakes, PET 2006.
• Xu and Yung, K-Anonymous Multi-Part Secret
  Handshakes , Financial Cryptography 2007.

6
One-Sided Private Interaction Motivation
Bob
Alice
I have a message P to give to the CIA but I want
to make sure you are a CIA agent. Please show me
your CIA certificate!
I wont/cant show my CIA certificate. Just give
me the message!
??????

• Why doesnt Bob trust Alice with his certificate?
• She might convince others that Bob is with the
  CIA
• Bob is not allowed to reveal his credentials to
  non-CIA agents

7
Public Key Certificate

• Bobs CIA certificate
• Signing PK the CIAs public key.
• M Bob is with CIA, his key is xxx,
• M could be an X.509v3 certificate template
• ? SigPK(M) lt---- signature on M (certificate).
  
• The secret here is ? -- the signature itself

8
Oblivious Signature-Based Envelope (OSBE)
Receiver (Bob?)
Sender (Alice)
Message P

• Receiver can open the envelope IFF s/he has the
  certificate
• Sender cant know whether the receiver has the
  certificate

9
OSBE Definition

• Setup
• PK CAs public key
• M content of the certificate
• ? SigPK(M) signature on M
• S/Alice Sender of message P (P is given to S
  only).
• R1/Bob Intended Receiver who has ? -- Bob
• Bob-who-has-? might not exist
• R2/Eve Receiver without ? -- adversary
• PK and M are given to all three parties

10
OSBE Definition (contd)

• Interaction
• One of R1 and R2 is chosen as R
• S does not know which one.
• S and R run OSBE protocol
• Open
• R outputs P if and only if R R1.
• Recall R1 has the certificate (M, ?), R2 doesnt.

11
Security Requirements

• A secure OSBE scheme must be
• Sound R1 outputs P with overwhelming
  probability.
• Oblivious S does not learn whether it is
  communicating with R1 or R2.
• Semantically secure against the receiver R2
  learns nothing about P.
• Forward-Secure compromise of long-term secret
  (?) should not result in compromise of P (i.e.,
  PFS) or
• Original certificate signer should be unable to
  obtain P
• Imposter-Oblivious after multiple interactions
  involving M, S learns nothing about R1 or R2

12
IBE-based OSBE
Identity Based Encryption (IBE)
System Parameters
Alice
Message P
Public encryption key derived from Bob is a
CIA member
Cipher Text
13
IBE-OSBE (Du, et al. 2003)
Sender (Alice)
Receiver (Bob)
(0) my name is Bob
(1) Public key PK F(Bob is a CIA
member) F() public function
(2) EPK(M)
(3) Decrypt EPK(M) with private key
14
Summary

• IBE-OSBE is one-round no real interaction
• IBE-OSBE doesnt offer perfect forward secrecy
• If Receiver is later compromised, message P is
  leaked
• Not compatible with existing PKI-s
• Receiver (Bob) might not have the decryption key
  when message P is sent
• Is this good or bad?
• IBE-OSBE can be trivially resolved with Cocks or
  Boneh/Franklin IBE schemes
• Cocks IBE extremely inefficient, but standard
  assumptions
• Boneh/Franklin IBE more efficient (yet still
  expensive), but assumptions are relatively new
  and untested
• What about other OSBE schemes?

15
RSA OSBE Scheme (Du, et al.)

• RSA Signatures
• (e, n) public key PK
• e public exponent
• n modulus
• d private key.
• h hash(M) hash value of M.
• ? SigPK(M) hd (mod n) signature.
• (hd)e (he)d h (mod n)

16
RSA-OSBE Scheme Setup

• Setup
• Everybody knows h, M, (e, n)
• Sender S knows P
• Only R1 knows ? (h d mod n)

17
Using Key Agreement
Sender
Receiver
P
Sender knows the key Receiver knows the key
only if he has hd mod n
18
Diffie-Hellman Key Agreement
Bob
Alice
h x mod n
x
y
h y mod n
(h x) y mod n
(h y) x mod n
h x y mod n
19
Transforming Diffie-Hellman
S
R1
? h d h x mod n
x
y
? h e y mod n
? e y (h dx) e y
Kr (hey) x
h e d y h e x y h y h e x y
Ks (? e y)/h y h e x y
CLAIM Ks Kr if and only if Receiver knows h
d mod n
20
Properties

• RSA-OSBE is sound (KsKr)

• RSA-OSBE is oblivious
• R1 ? hdx
• R2 ? hx
• hdx x random and hx x random are
  statistically indistinguishable

• RSA-OSBE is semantically secure against the
  receiver,
• i.e, R2 cannot learn KsKr

21
Summary

• RSA-OSBE takes 2 rounds
• But, it needs to be 2-rounds only once
• PFS (forward security) is offered if x is
  generated anew each time
• RSA-OSBE can be used in an existing PKI
• RSA-OSBE is imposter-oblivious
• What does S know after having two interactions?
• What about other OSBE schemes?

22
El Gamal Signature FamilyTsudik and Nasserian,
FC 2006.

• Nyberg/Rueppel
• Schnorr
• El Gamal (and variants)
• DSA
• All signatures look like
• (e,s)
• where
• e one-time public key
• s actual signature
• Variations are in the details of computing e and s

23
Schnorr-OSBE

• Setup
• Everyone knows
• h() hash function, M Bob, FBI Agent
• system-wide parameters (p,q,g)
• CAs public key yga mod p
• CAs secret key a
• Sender S knows P (message intended for Bob)
• Receiver R1 (Bob) knows s (e,s)
• where
• e h(M,gk)
• s (ae k) mod q ah(M,gk)k mod q
• Schnorr Verification h(M, gsy-e) ? e

24
Schnorr-OSBE
S
R1
X gsy-e mod p gK mod p
(y,h)
s(e,s)
1) generate z 2) Ks yh(M,X)Xz g(aek)z
Z gz mod p
KrZsgz(aek)
Encrypt P under key derived from Ks
CLAIM Ks Kr if and only if R1 knows saek
mod q
25
EG-OSBE

• Setup
• Everyone knows
• hhash(M), M Bob, FBI Agent
• system-wide parameters (p,g)
• CAs public key yga mod p
• CAs secret key a
• Sender S knows P (message for Bob)
• Receiver R1 knows s (e,s) where
• e gk mod p
• s k-1(h - ae) mod (p-1)
• El Gamal Verification esye ? gh
• Note esye g h-aeagk g h

26
EG-OSBE
S
R1
e gk
(y,h)
s(e,s)
1. generate z 2. Ks yez z-hz gz(ae-h)
Z ez mod p
KrZ-se-zs
Encrypt P under key derived from Ks
CLAIM Ks Kr if and only if R1 knows
sk-1(h-ae) mod p
27
Security?

• Obliviousness is easy
• Semantic security against R is hard
• Entails showing that it is infeasible for R2 to
  exponentiate with s
• NR ?
• DSA ?
• El Gamal ?
• Schnorr ? use Pointcheval/Stern (forking lemma)
  result

28
Comparison

• RSA-OSBE can be forward-secure
• ElGamal-family OSBE-s need an extra gb in the
  first message for forward security
• RSA-OSBE is impostor-oblivious
• None others are is there a fix?
• Costs are similar ca. 2 mod-exps for both
  parties
• Very little overhead over normal (non-oblivious)
  PK-based envelopes ? this is surprising!

29
Cost?
OSBE Schemes
Costs factors NR Schnorr
EG/DSA RSA protocol rounds 2 2 2 2
protocol msgs 2 2 2 2 mod exps for
S 3 3 3 3 mod exps for R 1 3
1 2
Observation suppose S wants to send a message P
to R w/out OSBE. With DH-based PFS, same number
of exponentiations would be needed ? OSBEs offer
more functionality at same cost!
30
Measured costs
RSA optimized RSA-OSBE
31
One-Sided Secret Handshake?

• What if we add a confirmation round to OSBE?

Sender
Receiver
P
F(P)

• Alice knows Bob is an FBI agent
• But, Alice cannot prove it

32
Secret Handshakes example setting

• Alice and Bob are FBI agents
• FBI agents are not allowed to divulge affiliation
  except to other FBI agents
• Alice will authenticate to Bob only if hes an
  FBI agent
• Bob will authenticate to Alice only if she is an
  FBI agent
• Other parties (whether CIA agents or not) must
  not be able to detect Alices or Bobs
  affiliation
• How can Alice Bob authenticate each other?
• OSBEs are one-sided

33
Group Secret Handshakes ?Jarecki, et al.,
CT-RSA 2007

• How about using a long-term group-wide secret
  key?
• Problems (1) traceability, (2) revocation
• Each player must have a PKI-style certificate
  (ID,cert)

First Goal Authenticated Group Key Agreement
Second Goal Affiliation Hiding
FBI agent
FBI agent
?
K
K
Adversary
FBI agent
FBI agent
K
Adversary cannot determine players affiliations
K

• All FBI members compute same key (assuming
  Adversary is passive)
• The adversary cannot compute this key (even if
  Adversary is active)

34
Standard Authenticated Key AgreementNo
Affiliation Privacy!
Bobs ID (B) certified by CA
Alices ID (A) certified by CA
sA SIGCAA
sB SIGCAB
ID exchange (A,B)
As Key-Agreement msg SIGCA A

Bs Key-Agreement msg SIGCA B

Even passive adversary can determine players
affilations
35
Adding Affiliation Privacy to Authenticated Key
Agreement
Bobs ID (B) certified by CA
Alices ID (A) certified by CA
sA SIGCAA
sB SIGCAB
ID exchange (A,B)
?
sB
sA
Alices credential Alices policy
Bobs credential Bobs policy
?
CAB
CAA
Secure Computation of Ver(CAA,B,sB)
Ver(CAB,A,sA)
Q1 Is Bob a member of Alices organization CAA ?
True or False
( a random Key if True)
Q2 Is Alice a member of Bobs organization CAB ?
Secure Computation Protocol gt Players Inputs
are Hidden gt Affiliation Privacy
36
Affiliation-Hiding in AGKA a closer look
ID A
ID B
Player 1
Player 2
?
Player 3
ID C
ID D
Player 4

• Adversary cannot assign players to groups
• Adversary who is a member of some group can
  tell if other users are members of same group
  only by active attack

37
Related Work on Affiliation-Hiding Key Agreement
38
Efficient Affiliation-Hiding Authenticated Key
Exchange Example RSA certificates
Diffie-Hellman
Bobs ID (B) certified by (n,e)
Alices ID (A) certified by (n,e)
sA SIGn,eA (sA)e H(A)
sB SIGn,eB (sB)e H(B)
ID exchange (A,B)
Consider a Diffie-Hellman Key Agreement
39
Efficient Affiliation-Hiding Authenticated Key
Exchange Example RSA certificates
Diffie-Hellman
Bobs ID (B) certified by (n,e)
Alices ID (A) certified by (n,e)
sA SIGn,eA (sA)e H(A)
sB SIGn,eB (sB)e H(B)
ID exchange (A,B)
Consider a Diffie-Hellman Key Agreement (modified)
Alices view - sends ?A - computes key K if
she knows tA DL( ?A )
Idea Contribute tA in ?A implicitly
authenticated under (n,e)
40
Efficient Affiliation-Hiding Authenticated Key
Exchange Example RSA certificates
Diffie-Hellman
Bobs ID (B) certified by (n,e)
Alices ID (A) certified by (n,e)
sA SIGn,eA (sA)e H(A)
sB SIGn,eB (sB)e H(B)
ID exchange (A,B)
Consider a Diffie-Hellman Key Agreement
Alices view - sends ?A - computes key K if
she knows tA DL( ?A )
Idea Contribute tA in ?A implicitly
authenticated under (n,e)
41
Efficient Affiliation-Hiding via Implicitly
Authenticated Key Agreement
Bobs ID (B) certified by (n,e)
Alices ID (A) certified by (n,e)
sA SIGn,eA (sA)e H(A)
sB SIGn,eB (sB)e H(B)
ID exchange (A,B)
Under RSA assumption If Alice does not embed a
valid signature (on A) into ?A then Alice cannot
compute key KB
Consider a Diffie-Hellman Key Agreement
Alices view - sends ?A - computes key K if
she knows tA DL( ?A )
Idea Contribute tA in ?A implicitly
authenticated under (n,e)
42
Efficient Affiliation-Hiding via Implicitly
Authenticated Key Agreement
Bobs ID (B) certified by (n,e)
Alices ID (A) certified by (n,e)
sA SIGn,eA (sA)e H(A)
sB SIGn,eB (sB)e H(B)
ID exchange (A,B)
To ensure Affiliation-Hiding players send
Under RSA assumption If Alice does not embed a
valid signature (on A) into ?A then Alice cannot
compute key KB
where g satisfies Zn ltggt x lt-1gt b is a
random bit, and v is random in 0,,2k/n
43
Affiliation-Hiding in Authenticated Group Key
Agreement Same Idea!
Bobs ID (B) certified by (n,e)
Alices ID (A) certified by (n,e)
sA SIGn,eA (sA)e H(A)
sB SIGn,eB (sB)e H(B)
ID exchange (A,B)
Standard DH Key Agreement Pi sends gti and
then uses ti to compute the key Affiliation-Hiding
AKA Pi sends (si gti) and Pj recovers gti
via implicit-authentication Group KA protocols
Pi sends gti and then uses ti in some further
interactions Affiliation-Hiding AGKA Pi sends
(si gti) and then uses ti as in the AGKA
protocol, while Pjs recover gti via
implicit-authentication
44
Adding Affiliation-Hiding Authentication to BD
GKA
Burmester-Desmedt GKA
AH-AGKA version of BD

• Pi ?G

Deliver implicitly
authenticated ( affiliation-hiding)
Step 1
Pi ?G
Compute session id, s
Step 2
Key Computation
45
Summary

• Authenticated Group Key Agreement can be
  Affiliation-Hiding at No Extra Cost
• 2 communication rounds (the second one
  broadcasts)
• 3-4 exponentiations per player
• Affiliation-hiding via implicit authentication
• Secure under various assumptions (in ROM)
• Diffie-Hellman
• RSA
• Extensions
• Perfect Forward Secrecy (one extra round)

46
Open Questions

• Weaker assumptions?
• Affiliation-Hiding (Group) Authentication without
  ROM?
• Privacy after Revocation
• How to provide Forward Privacy in case of
  member revocation?
• Currently, affiliation of revoked identities is
  made public...
• How to get rid of identities entirely
• Unlinkable Secret Handshakes?

47
Group Secret Handshakes another takeXu, et al.
(PET06)

• How to achieve group secret handshakes
• with unlinkability
• and
• Avoid one-time pseudonyms/certificates

48
Soundness and Security properties

• Correctness if all m parties are in G, handshake
  succeeds else, failure.
• Impersonation-resistance only a member can
  complete a handshake
• Detection-resistance a non-member cant identify
  a successful handshake
• Unlinkability multiple handshakes by same member
  can only be linked by the CA
• Eavesdropper-indistinguishability curious
  insiders cant determine handshake outcome
• Traceability any valid handshake transcript is
  traceable
• No-misattribution no coalition of members and CA
  can frame an honest member
• Forward-repudiability a member can only prove
  its own participation in a handshake, not that of
  any other member (even if former reveals all)
• Tagging-resistance any adversary who reads all
  memory of honest member cant track/link that
  member
• Self-Distinction for mgt2, each party convinced
  of uniqueness of all others

49
Self-distinction is unique to groups gt 2Alice
can play two roles in a group handshake
Alices Pseudonym A1
Alices Pseudonym A2
Problem A1 and A2 are UNRELATED (by design)
50
Correctness?
Failure!
51
Correctness take 0
PROTOCOL FAILURE
52
Correctness take 1
53
Correctness take 2
54
Goals

• Avoid
• one-time credentials or pseudonyms
• ability of GA to frame members
• Provide
• group handshakes
• tagging-resistance
• self-distinction

55
Building Block I Centralized Key Distribution
CKD (Broadcast Encryption)

• CKD.Setup GA creates group G
• CKD.Join GA admits new member, updates group
  state info
• CKD.Leave GA revokes existing member, updates
  group state info
• CKD.Update each member updates group info
• CKD.Rekey each member runs (on input of state
  info)

Question Can we simply have m parties exchange
challenges/responses encrypted under a (current)
common key K?
56
Building Block I Centralized Key Distribution
CKD (e.g, LKH, OFT, etc.)

• Correctness YES
• Impersonation-resistance YES
• Detection-resistance YES
• Unlinkability YES (cant be linked even by
  GA)
• Eavesdropper-indistinguishability NO
• Traceability NO
• No-misattribution YES
• Forward-repudiability YES
• Tagging-resistance YES
• Self-Distinction NO

57
Building Block II Group Signatures

• GSS.Setup GA creates group G
• GSS.Join GA admits new member, optionally
  updates group state info
• GSS.Revoke GA revokes existing member, updates
  group state info
• GSS.Update each member updates own state info
• GSS.Sign a member signs on behalf of the group
• GSS.Verify anyone verifies a group signature
• GSS.Open GA opens a valid group signature
  identifies signer

Question Can we simply have m parties exchange
group signatures?
58
Building Block II Group Signatures

• Correctness YES
• Impersonation-resistance YES
• Detection-resistance NO
• Unlinkability YES
• Eavesdropper-indistinguishability NO
• Traceability YES
• No-misattribution YES
• Forward-repudiability YES
• Tagging-resistance YES?
• Self-Distinction NO

Question What if m parties exchange group
signatures encrypted under CKD group-wide key K?
59
Building Blocks I II CKD GSS

• Correctness YES
• Impersonation-resistance YES
• Detection-resistance YES
• Unlinkability YES
• Eavesdropper-indistinguishability NO
• Traceability YES
• No-misattribution YES
• Forward-repudiability YES
• Tagging-resistance YES
• Self-Distinction NO

Need 3rd building block
60
Building Block III Group Key Agreement GKA
(e.g., BD94, STW00, PKT00)

• Authenticated or raw group key agreement?
• Can use CKD group-wide key for authentication

61
Group Handshake Protocol at a Glance

• Phase I all participants run GKA protocol and
  compute one-time key k
• Phase II all participants compute Kf(k,k)
  where k is the broadcast (group-wide) secret key
• Phase III all participants broadcast unique MACs
  to confirm possession of the same K
• Phase IV all participants generate and broadcast
  group signatures (encrypted with K) to assert
  verify membership

62
Building Blocks IIIIII

• Correctness YES
• Impersonation-resistance YES
• Detection-resistance YES
• Unlinkability YES
• Eavesdropper-indistinguishability YES
• Traceability YES
• No-misattribution YES
• Forward-repudiability YES
• Tagging-resistance YES
• Self-Distinction MAYBE

Can prove that if I, II and III are secure, so
is GCD
63
Example 1

• GKA BD94
• GSS ACJT00 CL02
• CKD WGL (KeyGraphs)
• No self-distinction!

64
Example 2

• GKA STW00
• GSS KTY04
• CKD LKH
• Self-distinction!

65
Result a Secret Handshake Framework
Distributed Group Key Agreement Protocol
Group Signature Scheme
Broadcast Encryption Scheme
If each component is secure, so is the resulting
secret handshake scheme but ITS VERY HEAVY
66
To conclude

• Privacy-preserving interaction has some
  compelling use cases
• Protocols are tricky to design
• Naïve approaches dont work
• Security and Privacy properties must be
  considered separately
• If done right, very little (if any) added cost
  due to privacy