W HAT IS DAA? 1 S ECURITY M ODEL OF DAA 2 A B LUEPRINT FOR DAA 3 - - PowerPoint PPT Presentation

DIRECT ANONYMOUS ATTESTATION

Essam Ghadafi

ghadafi@cs.bris.ac.uk Department of Computer Science, University of Bristol

Brown Univeristy – 14th March - 2013

DIRECT ANONYMOUS ATTESTATION

OUTLINE

1

WHAT IS DAA?

2

SECURITY MODEL OF DAA

3

A BLUEPRINT FOR DAA

4

ROM INSTANTIATIONS

5

STANDARD-MODEL CONSTRUCTIONS

6

EFFICIENCY COMPARISON

7

SUMMARY

8

OPEN PROBLEMS

DIRECT ANONYMOUS ATTESTATION

OUTLINE

1

WHAT IS DAA?

2

SECURITY MODEL OF DAA

3

A BLUEPRINT FOR DAA

4

ROM INSTANTIATIONS

5

STANDARD-MODEL CONSTRUCTIONS

6

EFFICIENCY COMPARISON

7

SUMMARY

8

OPEN PROBLEMS

DIRECT ANONYMOUS ATTESTATION

OUTLINE

1

WHAT IS DAA?

2

SECURITY MODEL OF DAA

3

A BLUEPRINT FOR DAA

4

ROM INSTANTIATIONS

5

STANDARD-MODEL CONSTRUCTIONS

6

EFFICIENCY COMPARISON

7

SUMMARY

8

OPEN PROBLEMS

DIRECT ANONYMOUS ATTESTATION

OUTLINE

1

WHAT IS DAA?

2

SECURITY MODEL OF DAA

3

A BLUEPRINT FOR DAA

4

ROM INSTANTIATIONS

5

STANDARD-MODEL CONSTRUCTIONS

6

EFFICIENCY COMPARISON

7

SUMMARY

8

OPEN PROBLEMS

DIRECT ANONYMOUS ATTESTATION

OUTLINE

1

WHAT IS DAA?

2

SECURITY MODEL OF DAA

3

A BLUEPRINT FOR DAA

4

ROM INSTANTIATIONS

5

STANDARD-MODEL CONSTRUCTIONS

6

EFFICIENCY COMPARISON

7

SUMMARY

8

OPEN PROBLEMS

DIRECT ANONYMOUS ATTESTATION

OUTLINE

1

WHAT IS DAA?

2

SECURITY MODEL OF DAA

3

A BLUEPRINT FOR DAA

4

ROM INSTANTIATIONS

5

STANDARD-MODEL CONSTRUCTIONS

6

EFFICIENCY COMPARISON

7

SUMMARY

8

OPEN PROBLEMS

DIRECT ANONYMOUS ATTESTATION

OUTLINE

1

WHAT IS DAA?

2

SECURITY MODEL OF DAA

3

A BLUEPRINT FOR DAA

4

ROM INSTANTIATIONS

5

STANDARD-MODEL CONSTRUCTIONS

6

EFFICIENCY COMPARISON

7

SUMMARY

8

OPEN PROBLEMS

DIRECT ANONYMOUS ATTESTATION

OUTLINE

1

WHAT IS DAA?

2

SECURITY MODEL OF DAA

3

A BLUEPRINT FOR DAA

4

ROM INSTANTIATIONS

5

STANDARD-MODEL CONSTRUCTIONS

6

EFFICIENCY COMPARISON

7

SUMMARY

8

OPEN PROBLEMS

DIRECT ANONYMOUS ATTESTATION

WHAT IS DAA? A protocol standardized by TCG (Trusted Computing Group) that allows a user possessing a TPM (Trusted Platform Module) to attest to this fact to a verifier, i.e. the TPM anonymously authenticates itself to the verifier. ◮ Direct: Without a third party. ◮ Anonymous: The identity of the user is not revealed. ◮ Attestation: A proof, i.e. convinces the verifier. TPM delegates the non-critical operations to its more powerful host.

DIRECT ANONYMOUS ATTESTATION 1 / 46

DAA

User 2

Verifier

User 1 User 4 User 3

Group

User x

Manager

Join DAA Signature

DIRECT ANONYMOUS ATTESTATION 2 / 46

THE TPM

Random Number Generator Cryptographic Processor RSA Key Generator SHA-1 Hash Generator Enc-Dec-Sign Engine Endorsement Key (EK) Persistent Memory Storage Root Key (SRK) Versatile Memory Platform Configuration Registers (PCR) Attestation Identity Key (AIK) Storage Keys Secured Input - Output

DIRECT ANONYMOUS ATTESTATION 3 / 46

FEATURES OF DAA ◮ The user remains anonymous, i.e. verifiers do not know which TPM produced the signature. ◮ Rogue (i.e. compromised) TPMs can be traced. ◮ The user can opt to have some of his transactions (targeted at the same verifier, i.e. on the same basename bsn) to be linkable. However, anonymity is still preserved.

DIRECT ANONYMOUS ATTESTATION 4 / 46

A BIT OF HISTORY The first DAA protocol (RSA-based) was proposed by Brickell, Camenisch and Chen [BCC04] in 2004 and was standardized by TCG as TPM 1.2. Other (Pairing-based) constructions followed: ◮ Brickell, Chen and Li [BCL08] 2008. ◮ Chen [C09] 2009. ◮ Chen, Morrissey and Smart [CMS09] 2009. ◮ Chen, Page and Smart [CPS10] 2010. ◮ Bernhard, Fuchsbauer, Ghadafi, Smart and Warinschi [BFG+11] 2011.

DIRECT ANONYMOUS ATTESTATION 5 / 46

PRE-DAA

To simplify the security model and the constructions, we proceed in two steps:

1 Consider a pre-DAA scheme: a fully functional DAA but the

user is regarded as one entity (i.e. not split into a powerful untrusted Host and a computationally-constrained trusted TPM).

2 Convert the pre-DAA into a DAA by delegating non-critical

• perations to the Host without compromising the security.

DIRECT ANONYMOUS ATTESTATION 6 / 46

HOW TO TRACE? Unlike in group signatures, users do not have public keys bound to their identities!

Q: So how to trace users?

DIRECT ANONYMOUS ATTESTATION 7 / 46

HOW TO TRACE? Unlike in group signatures, users do not have public keys bound to their identities!

Q: So how to trace users? A: We use the join transcript as a public key for the user “Uniquely

Identifying Transcripts”. ◮ ⇒ Each completed transcript T traces to at most one secret key sk.

DIRECT ANONYMOUS ATTESTATION 7 / 46

SYNTAX OF A PRE-DAA SCHEME ◮ Setup(1λ): Creates common public parameters param. ◮ GKg(param): Creates a key pair (gmpk, gmsk) for the issuer. ◮ UKg(param): Creates a secret key sk for a user. ◮ Join(gmpk, sk), Issue(gmsk): If completed successfully, the user obtains a group signing key gsk. ◮ GSig(sk, gsk, bsn, m): Creates a signature σ on message m and basename bsn. bsn could be empty, i.e. bsn =⊥. ◮ Verify(gmpk, σ, m, bsn): Verifies a signature. ◮ Link(gmpk, m0, σ0, m1, σ1, bsn): Checks if σ0 on (m0 and bsn) and σ1 on (m1 and bsn) where bsn =⊥ are by the same user.

DIRECT ANONYMOUS ATTESTATION 8 / 46

SYNTAX OF A PRE-DAA SCHEME ◮ *IdentifyT(gmpk, T , sk): Checks if transcript T matchs the secret key sk. ◮ *IdentifyS(gmpk, σ, m, bsn, sk): Checks if σ was produced by the owner of sk.

DIRECT ANONYMOUS ATTESTATION 9 / 46

SECURITY OF PRE-DAA The security requirements are: ◮ Correctness. ◮ Anonymity. ◮ Traceability. ◮ Non-frameability.

DIRECT ANONYMOUS ATTESTATION 10 / 46

SECURITY OF PRE-DAA ◮ Correctness: If all parties are honest, we have that:

Signatures are accepted by the Verify algorithm. Signatures can be traced. Signatures that are linkable link.

DIRECT ANONYMOUS ATTESTATION 11 / 46

SECURITY OF PRE-DAA ◮ Anonymity: Signatures do not reveal who signed them and unlinkable signatures do not link even if the Issuer is corrupt.

DIRECT ANONYMOUS ATTESTATION 12 / 46

SECURITY OF PRE-DAA ◮ Anonymity: Signatures do not reveal who signed them and unlinkable signatures do not link even if the Issuer is corrupt.

σ←GSig(gskb,skb,m,bsn) gmpk,gmsk

AddU AddU USK USK GSK GSK Sign Sign CrptU CrptU SndToU SndToU

... i0, i1, bsn, m b←{0,1} ... b* i0, i1, bsn, m

Adversary wins if: b = b∗, both i0 and i1 are honest and he never asked for a signature on bsn by i0 or i1.

DIRECT ANONYMOUS ATTESTATION 12 / 46

SECURITY OF PRE-DAA ◮ Traceability-1: The adversary cannot output an untraceable signature.

DIRECT ANONYMOUS ATTESTATION 13 / 46

SECURITY OF PRE-DAA ◮ Traceability-1: The adversary cannot output an untraceable signature.

gmpk

SndToI SndToI CrptU CrptU

... σ, m, bsn, sk'1, ..., sk'n

Adversary wins if all the following holds: σ verifies on m and bsn. ∀T ∈ T∃ i ∈ {1, n} s.t. T traces to ski. T is the set of all Join transcripts. σ does not trace to any ski.

DIRECT ANONYMOUS ATTESTATION 13 / 46

SECURITY OF PRE-DAA ◮ Traceability-2: The adversary cannot output two signatures which should link but they do not.

DIRECT ANONYMOUS ATTESTATION 14 / 46

SECURITY OF PRE-DAA ◮ Traceability-2: The adversary cannot output two signatures which should link but they do not. gmpk, gmsk ... σ0, m0, σ1, m1, bsn, sk' Adversary wins if all the following holds: σ0 verifies on m0 and bsn, and σ1 verifies on m1 and bsn. Both σ0 and σ1 trace to sk′. σ0 and σ1 do not link.

DIRECT ANONYMOUS ATTESTATION 14 / 46

SECURITY OF PRE-DAA ◮ Non-Frameability-1: The adversary cannot output a signature that traces to an honest user who did not produce it.

DIRECT ANONYMOUS ATTESTATION 15 / 46

SECURITY OF PRE-DAA ◮ Non-Frameability-1: The adversary cannot output a signature that traces to an honest user who did not produce it.

gmpk,gmsk

AddU AddU USK USK GSK GSK Sign Sign CrptU CrptU SndToU SndToU

... σ, m, i, bsn

Adversary wins if all the following holds: σ verifies on m and bsn. User i is honest and has not signed (m, bsn). σ traces to ski.

DIRECT ANONYMOUS ATTESTATION 15 / 46

SECURITY OF PRE-DAA ◮ Non-Frameability-2: The adversary cannot output signatures that link but they should not.

DIRECT ANONYMOUS ATTESTATION 16 / 46

SECURITY OF PRE-DAA ◮ Non-Frameability-2: The adversary cannot output signatures that link but they should not.

gmpk,gmsk

AddU AddU USK USK GSK GSK Sign Sign CrptU CrptU SndToU SndToU

... σ0, m0, bsn0 ,σ1, m1, bsn1, sk

Adversary wins if all the following holds: σ0 verifies on m0 and bsn0, and σ1 verifies on m1 and bsn1. σ0 and σ1 link on either bsn0 or bsn1. bsn0 = bsn1, bsn0 =⊥, bsn1 =⊥, or only one signature traces to sk.

DIRECT ANONYMOUS ATTESTATION 16 / 46

GENERIC CONSTRUCTION OF PRE-DAA All previous DAA constructions require the following tools: ◮ Randomizable Weakly Blind Signatures (RwBS)

Used by the Issuer to issue certificates as credentials when users join the group.

◮ Linkable Indistinguishable Tags (LIT)

Needed to provide the linkability of signatures when the same basename is signed by the same user.

◮ Signatures of Knowledge (SoK)

Used by users to prove they have a credential and that the signature on the basename verifies w.r.t. thier certified secret key.

DIRECT ANONYMOUS ATTESTATION 17 / 46

BLIND SIGNATURES

USER SIGNER

sk pk

DIRECT ANONYMOUS ATTESTATION 18 / 46

BLIND SIGNATURES

USER SIGNER

sk pk

Sig

...

DIRECT ANONYMOUS ATTESTATION 18 / 46

BLIND SIGNATURES

USER SIGNER

sk pk

Sig Sig

...

Security Requirements: ◮ Blindness: An adversary (i.e. a signer) who chooses two messages does not learn the order in which the messages were signed. ◮ Unforgeability: An adversary (i.e. a user) cannot forge new signatures.

DIRECT ANONYMOUS ATTESTATION 18 / 46

BLIND SIGNATURES

USER SIGNER

sk pk

Sig Sig

...

Security Requirements: ◮ Blindness: An adversary (i.e. a signer) who chooses two messages does not learn the order in which the messages were signed. ◮ Unforgeability: An adversary (i.e. a user) cannot forge new signatures.

DIRECT ANONYMOUS ATTESTATION 18 / 46

RANDOMIZABLE WEAKLY BLIND SIGNATURES (RWBS) Similar to blind signatures but: ◮ Randomizability: Given a signature σ, anyone can produce a new signature σ′ on the same message. ◮ Weak Blindness: Same as blindness but the adversary never sees the messages ⇒ The adversary cannot tell if he was given a signature on a different message or a re-randomization of a signature on the same message.

DIRECT ANONYMOUS ATTESTATION 19 / 46

LINKABLE INDISTINGUISHABLE TAGS (LIT)

Alice Bob

sk sk

m τ←LITTag(sk,m) m, τ Accept if LITTag(sk,m)=τ

Security Requirements: ◮ Indistinguishability: An adversary cannot distinguish between a tag on a message of his choice and a tag produced under a random key. ◮ Linkability: Two tags are identical iff both produced using the same key and are on the same message.

DIRECT ANONYMOUS ATTESTATION 20 / 46

LINKABLE INDISTINGUISHABLE TAGS (LIT)

Alice Bob

sk sk

m τ←LITTag(sk,m) m, τ Accept if LITTag(sk,m)=τ

Security Requirements: ◮ Indistinguishability: An adversary cannot distinguish between a tag on a message of his choice and a tag produced under a random key. ◮ Linkability: Two tags are identical iff both produced using the same key and are on the same message.

DIRECT ANONYMOUS ATTESTATION 20 / 46

SIGNATURES OF KNOWLEDGE (SOK) Signer Verifier

I know w s.t. (w,x)∈RL

m

σ←SoKSign(RL,w,x,m)

m, σ

Accept iff SoKVerify(σ,RL,x,m)=1

Security Requirements [CL06]: ◮ Simulatability: There is a simulator who can produce signatures without knowing a witness. Those are indistinguishable from real signatures. ◮ Extractability: There is an extractor who can extract a valid witness w for the statement x from a signature σ output by the adversary (who can ask for simulated signatures).

DIRECT ANONYMOUS ATTESTATION 21 / 46

SIGNATURES OF KNOWLEDGE (SOK) Signer Verifier

I know w s.t. (w,x)∈RL

m

σ←SoKSign(RL,w,x,m)

m, σ

Accept iff SoKVerify(σ,RL,x,m)=1

Security Requirements [CL06]: ◮ Simulatability: There is a simulator who can produce signatures without knowing a witness. Those are indistinguishable from real signatures. ◮ Extractability: There is an extractor who can extract a valid witness w for the statement x from a signature σ output by the adversary (who can ask for simulated signatures).

DIRECT ANONYMOUS ATTESTATION 21 / 46

(PRIME-ORDER) BILINEAR GROUPS G1, G2, GT are finite cyclic groups of prime order q, where G1 =< P1 > and G2 =< P2 >. Pairing (e : G1 × G2 − → GT) : The function e must have the following properties: ◮ Bilinearity: ∀Q1 ∈ G1 , Q2 ∈ G2 x, y ∈ Z, we have e([x]Q1, [y]Q2) = e(Q1, Q2)xy. ◮ Non-Degeneracy: The value e(P1, P2) = 1 generates GT. ◮ The function e is efficiently computable. Type-3 [GPS08]: G1 = G2 and no efficiently computable isomorphism between G1 and G2.

DIRECT ANONYMOUS ATTESTATION 22 / 46

RWBS IN THE ROM Based on the CL signature scheme [CL04]: ◮ KeyGen: Choose x, y ← Zq, set sk := (x, y) and pk := (X := [x]P2, Y := [y]P2). ◮ Sign: To sign m ∈ Zq, compute σ := (A := [a]P1, B := [y]A, C := [x]A + [mxy]A). ◮ Verify: Check that e(B, P2) = e(A, Y) e(C, P2) = e(A, X)e(B, X)m

DIRECT ANONYMOUS ATTESTATION 23 / 46

RWBS IN THE ROM The idea ◮ To get a signature on m, user sends [m]P1. ◮ The signer needs to provide a NIZK proof that the signature is valid (so that we can simulate signatures). Security: ◮ Weak-Blindness: ⇒ DDH assumption + NIZK soundness. ◮ Unforgeability ⇒ B-LRSW assumption. ◮ Simulatability ⇒ Zero-knowledge of the NIZK proof. DEFINITION (B-LRSW ASSUMPTION) Given ([x]P2, [y]P2) for x, y ← Zq and an oracle that on input M := [m]P1 ∈ G1 outputs: ◮ A LRSW tuple ([a]P1, [ay]P1, [ax]P1 + [axy]M) for a ← Zq. , it is hard to compute a new LRSW tuple for a new m′ ∈ Zq that was never queried to the oracle.

DIRECT ANONYMOUS ATTESTATION 24 / 46

RWBS IN THE ROM The idea ◮ To get a signature on m, user sends [m]P1. ◮ The signer needs to provide a NIZK proof that the signature is valid (so that we can simulate signatures). Security: ◮ Weak-Blindness: ⇒ DDH assumption + NIZK soundness. ◮ Unforgeability ⇒ B-LRSW assumption. ◮ Simulatability ⇒ Zero-knowledge of the NIZK proof. DEFINITION (B-LRSW ASSUMPTION) Given ([x]P2, [y]P2) for x, y ← Zq and an oracle that on input M := [m]P1 ∈ G1 outputs: ◮ A LRSW tuple ([a]P1, [ay]P1, [ax]P1 + [axy]M) for a ← Zq. , it is hard to compute a new LRSW tuple for a new m′ ∈ Zq that was never queried to the oracle.

DIRECT ANONYMOUS ATTESTATION 24 / 46

LIT IN THE ROM We use the BLS signature scheme [BLS04]: ◮ LITKeyGen(1λ): Choose sk ← Zq. ◮ LITTag(sk, m): To produce a tag on m ∈ {0, 1}∗, compute τ := [sk]H(m). Security: ◮ Indistinguishability ⇒ DDH assumption. ◮ Linkability ⇒ Collision-resistance of H + DL assumption.

DIRECT ANONYMOUS ATTESTATION 25 / 46

LIT IN THE ROM We use the BLS signature scheme [BLS04]: ◮ LITKeyGen(1λ): Choose sk ← Zq. ◮ LITTag(sk, m): To produce a tag on m ∈ {0, 1}∗, compute τ := [sk]H(m). Security: ◮ Indistinguishability ⇒ DDH assumption. ◮ Linkability ⇒ Collision-resistance of H + DL assumption.

DIRECT ANONYMOUS ATTESTATION 25 / 46

INSTANTIATIONS IN THE STANDARD MODEL - THE MOTIVATION All previous constructions require random oracles! Using Random Oracles The Pros: Makes constructions/security proofs much simpler ... The Cons: Cannot be securely realized in practice [CGH98] ...

DIRECT ANONYMOUS ATTESTATION 26 / 46

THE CHALLENGES The challenges in the Standard Model: ◮ LITs are much harder to construct in the standard model especially for large domain space.

⇒ more subtle than VRFs because they need to be deterministic.

◮ Signatures of Knowledge are harder to construct in the standard model.

⇒ Require simulation and extraction at the same time (current PoK techniques do not provide both simultaneously).

DIRECT ANONYMOUS ATTESTATION 27 / 46

LIT IN THE STANDARD MODEL We use the weakly secure signature scheme by Boneh and Boyen [BB04] (used by Dodis and Yampolskiy [DY05] to construct a VRF ): ◮ KeyGen: Select sk ← Zq and compute pk := [sk]P2. ◮ Sign: To sign m ∈ Zq where m = −sk, compute σ := [

1 sk+m]P1.

◮ Verify: Return 1 if e(σ, pk + [m]P2) = e(P1, P2). The Idea: Without knowing the public key pk, σ is indistinguishable from another signature by a random key. The Limitation: Either: ◮ Weak-Ind: Adversary has to declare all his queries and challenge in advance ... ◮ Polynomial Domain Space: ⇒ so that we can guess the challenge ...

DIRECT ANONYMOUS ATTESTATION 28 / 46

LIT IN THE STANDARD MODEL We use the weakly secure signature scheme by Boneh and Boyen [BB04] (used by Dodis and Yampolskiy [DY05] to construct a VRF ): ◮ KeyGen: Select sk ← Zq and compute pk := [sk]P2. ◮ Sign: To sign m ∈ Zq where m = −sk, compute σ := [

1 sk+m]P1.

◮ Verify: Return 1 if e(σ, pk + [m]P2) = e(P1, P2). The Idea: Without knowing the public key pk, σ is indistinguishable from another signature by a random key. The Limitation: Either: ◮ Weak-Ind: Adversary has to declare all his queries and challenge in advance ... ◮ Polynomial Domain Space: ⇒ so that we can guess the challenge ...

DIRECT ANONYMOUS ATTESTATION 28 / 46

LIT IN THE STANDARD MODEL Security: Our LIT is secure under the q-DDHI assumption [BB04]: DEFINITION (q-DDHI ASSUMPTION) Given (Pi, [x]Pi, [x2]Pi, . . . , [xq]Pi) for x ← Zq, it is hard to distinguish [ 1

x]Pi from a random element of group Gi.

We can overcome the limitation by using an interactive variant of the q-DDHI assumption [Khl10] ...

DIRECT ANONYMOUS ATTESTATION 29 / 46

SOK IN THE STANDARD MODEL Our SoK is based on Groth-Sahai proofs [GS08]: G1 × G2

f

→ GT ι1 ↓↑ ρ1 ι2 ↓↑ ρ2 ιT ↓↑ ρT H1 × H2

F

− → HT The proofs work by first committing to (encrypting) the witness and then producing a proof for the statement. The system can be instantiated in either: ◮ The simulation setting ⇒ perfectly hiding proofs. ◮ The extraction setting ⇒ perfectly sound proofs. The issues:

1 Can only extract one-way function (i.e. [w]Pi) of an exponent

witness w.

2 Cannot simulate and extract at the same time.

DIRECT ANONYMOUS ATTESTATION 30 / 46

SOK IN THE STANDARD MODEL To produce a SoK on a message m w.r.t. a statement x ∈ L, the signer proves the following modified statement:

1 x ∈ L OR 2 He has a signature on x||m that verifies w.r.t. some public key pk.

* The key sk corresponding to pk is only known to the simulator. The SoK construction is secure ◮ Extractability: Instantiate Groth-Sahai proofs in the extraction setting (so that we can extract). ◮ Simulatability: The simulator has sk so he can satisfy the predicate by proving he has a signature on x||m.

DIRECT ANONYMOUS ATTESTATION 31 / 46

SOK IN THE STANDARD MODEL To produce a SoK on a message m w.r.t. a statement x ∈ L, the signer proves the following modified statement:

1 x ∈ L OR 2 He has a signature on x||m that verifies w.r.t. some public key pk.

* The key sk corresponding to pk is only known to the simulator. The SoK construction is secure ◮ Extractability: Instantiate Groth-Sahai proofs in the extraction setting (so that we can extract). ◮ Simulatability: The simulator has sk so he can satisfy the predicate by proving he has a signature on x||m.

DIRECT ANONYMOUS ATTESTATION 31 / 46

INSTANTIATING THE SOK Need a signature scheme that is compatible with Groth-Sahai proofs, i.e. all the variables we need to hide are groups elements ... ⇒We use Waters Signature [W05] (Secure under the CDH+) ◮ Setup: To sign messages of the form m = (m1, . . . , mN) ∈ {0, 1}N, choose (Q, U0, . . . , UN) ← GN+2

1

. ◮ KeyGen: Choose sk ← Zq and compute pk := [sk]P2. ◮ Sign: To sign (m1, . . . , mN) using sk, choose r ← Zq and output (W1 := [pk]Q+[r](U0+

N

• i=1

[mi]Ui), W2 := [−r]P1, W3 := [−r]P2) ◮ Verify: Check that e(W1, P2)e(U0 +

N

• i=1

[mi]Ui, W3) = e(Q, pk) e(W2, P2) = e(P1, W3)

DIRECT ANONYMOUS ATTESTATION 32 / 46

RWBS IN THE STANDARD MODEL (INSTANTIATION I) Based on the NCL signature scheme by Ghadafi [G11]: ◮ KeyGen: Choose x, y ← Zq, set sk := (x, y) and pk := (X := [x]P2, Y := [y]P2). ◮ Sign: To sign (M1, M2) ∈ G1 × G2, return ⊥ if e(M1, P2) = e(P1, M2), otherwise compute σ := (A := [a]P1, B := [y]A, C := [ay]M1, D := [x](A + C)). ◮ Verify: Check that A = 0 and e(B, P2) = e(A, Y) e(C, P2) = e(B, M2) e(D, P2) = e(A + C, X) e(M1, P2) = e(P1, M2)

DIRECT ANONYMOUS ATTESTATION 33 / 46

RWBS IN THE STANDARD MODEL (INSTANTIATION I) Properties of the NCL scheme: ◮ Only M1 is needed in signing ⇒ in the RwBS we hide M2 and produce a PoK for it. ◮ Fully re-randomizable ⇒ more efficient RwBS (need not hide the signature). NCL is secure under the (interactive) DH-LRSW assumption DEFINITION (DH-LRSW ASSUMPTION) Given ([x]P2, [y]P2) for x, y ← Zq and an oracle that on input a pair (M1, M2) ∈ G1 × G2 outputs: ◮ ⊥ if e(M1, P2) = e(P1, M2). ◮ A DH-LRSW tuple ([a]P1, [ay]P1, [ay]M1, [ax]P1 + [axy]M1) for a ← Zq otherwise. , it is hard to compute a DH-LRSW tuple for ([m′]P1, [m′]P2) that was never queried to the oracle.

DIRECT ANONYMOUS ATTESTATION 34 / 46

RWBS IN THE STANDARD MODEL (INSTANTIATION II) Is partially re-randomizable and based on the AHO signature by Abe et al. [AHO10]. ◮ KeyGen:

GR, FU ← G×

2 , a, b ← Z× q .

For i = 1, . . . , k : ci, di ← Z×

q , Gi := [ci]GR, Fi := [di]FU.

cZ, dZ ← Z×

q , GZ := [cZ]GR, FZ := [dZ]FU.

Pick (A0, A1, ˜ A0, ˜ A1) s.t. e(A0, ˜ A0)e(A1, ˜ A1) = e([a]P1, GR). Pick (B0, B1, ˜ B0, ˜ B1) s.t. e(B0, ˜ B0)e(B1, ˜ B1) = e([b]P1, FU). sk := (a, b, cz, dz, (ci, di)k

i=1).

pk := (GZ, FZ, GR, FU, (Gi, Fi)k

i=1, A0, A1, ˜

A0, ˜ A1, B0, B1, ˜ B0, ˜ B1).

◮ Sign: To sign M = (Mi)k

i=1 ∈ Gk 1, choose z, r, t, u, w ← Z× q , and

compute

Z := [z]P1, R := [r − czz]P1 k

i:=1[−ci]Mi,

S := [t]GR, T := [(a − r)/t]P1, U := [u − dzz]P1 k

i:=1[−di]Mi,

V := [w]FU, W := [(b − u)/w]P1 σ := (Z, R, S, T, U, V, W).

DIRECT ANONYMOUS ATTESTATION 35 / 46

RWBS IN THE STANDARD MODEL (INSTANTIATION II) ◮ Verify:

Parse σ as (Z, R, S, T, U, V, W), M as (Mi)k

i=1, and pk as

(GZ, FZ, GR, FU, (Gi, Fi)k

i=1, A0, A1, ˜

A0, ˜ A1, B0, B1, ˜ B0, ˜ B1). Check that e(Z, GZ)e(R, GR)e(T, S)

• i

e(Mi, Gi) = e(A0, ˜ A0)e(A1, ˜ A1) e(Z, FZ)e(U, FU)e(W, V)

• i

e(Mi, Fi) = e(B0, ˜ B0)e(B1, ˜ B1)

Properties of the AHO scheme: ◮ The six elements R, S, T, U, V, W are re-randomizable ⇒ in the RwBS we need to hide R, Z, U.

DIRECT ANONYMOUS ATTESTATION 36 / 46

RWBS IN THE STANDARD MODEL (INSTANTIATION II) AHO is secure under the (non-interactive) q-SFP assumption DEFINITION (q-SFP ASSUMPTION) Given GZ, FZ, GR, FU ∈ G2, (A, ˜ A), (B, ˜ B) ∈ G1 × G2 and q random tuples (Z, R, S, T, U, V, W) each satisfying e(A, ˜ A) = e(Z, GZ) e(R, GR) e(T, S) e(B, ˜ B) = e(Z, FZ) e(U, FU) e(W, V) , it is hard to find another such tuple for which Z is neither 0 nor equal to any of the given Z-values.

DIRECT ANONYMOUS ATTESTATION 37 / 46

A MORE EFFICIENT CONSTRUCTION IN THE STANDARD MODEL The intuition: ◮ Use the NCL-based RwBS instead of the AHO-based RwBS. ◮ Replace SoKs with standard PoKs (which are more efficient). ◮ Use the weak Boneh-Boyen signature scheme as a LIT and a standard signature scheme.

DIRECT ANONYMOUS ATTESTATION 38 / 46

A MORE EFFICIENT CONSTRUCTION IN THE STANDARD MODEL ◮ Setup(1λ)

(P, crs1, crs2) ← BSSetup(1λ). Return param := (P, crs1, crs2).

◮ GKg(param)

(gmpk, gmsk) ← BSKeyGen(param). Return (gmpk, gmsk).

◮ UKg(param)

ski ← LITKeyGen(P). Return ski.

◮ Join, Issue

Run (BSRequest, BSIssue) for message (f1(ski), f2(ski)) ∈ MBS. User has input ((f1(ski), f2(ski)), gmpk). Issuer has input gmsk. User’s output is gski = cred.

DIRECT ANONYMOUS ATTESTATION 39 / 46

A MORE EFFICIENT CONSTRUCTION IN THE STANDARD MODEL

◮ GSig(gski, ski, m, bsn)

cred ← BSRandomize(gski). (pkots, skots) ← OTSKeyGen(1λ). σw ← BBSign(ski, 1||pkots). If bsn =⊥

τ ← LITTag(ski, 0||bsn). ϕ := (gmpk, cred, bsn, τ, pkots, σw) . Σ ← GSProve

• crs1, {(f1(ski), f2(ski))} : ϕ ∈ L
• .

Else

τ := ∅; ϕ := (gmpk, cred, pkots, σw). Σ ← GSProve

• crs1, {(f1(ski), f2(ski))}: ϕ ∈ L′

.

σots ← OTSSign(skots, (m, τ, bsn)). σ := (cred, τ, σw, pkots, Σ, σots).

◮ Verify(gmpk, m, bsn, σ)

Parse σ as (cred, τ, σw, pkots, Σ, σots). If OTSVerify(pkots, (m, τ, bsn), σots) = 0, return 0. If bsn =⊥ then

ϕ := (gmpk, cred, bsn, τ, pkots, σw). Return GSVerify

• crs1, ϕ ∈ L, Σ
• .

If τ = ∅ then

ϕ := (gmpk, cred, pkots, σw). Return GSVerify

• crs1, ϕ ∈ L′, Σ
• .

Return 0.

DIRECT ANONYMOUS ATTESTATION 40 / 46

A MORE EFFICIENT CONSTRUCTION IN THE STANDARD MODEL ◮ IdentifyT(gmpk, ski, T )

If T is a valid transcript then check if the user message in Join0 =BSRequest0 is (f1(ski), Ω), for some Ω. If so return 1, otherwise return 0.

◮ IdentifyS(gmpk, ski, m, bsn, σ)

Parse σ as (cred, τ, σw, pkots, Σ, σots). If BSVerify(gmpk, (f1(ski), f2(ski)), cred) = 0 then return 0. If OTSVerify(pkots, (m, τ, bsn), σots) = 0 then return 0. Return 1 iff one of the following hold

bsn = ⊥, τ = ∅ and BBVerify(f2(ski), 1||pkots, σw) = 1. bsn = ⊥, LITVerify(f2(ski), 0||bsn, τ) = 1 and BBVerify(f2(ski), 1||pkots, σw) = 1.

◮ Link(gmpk, σ0, m0, σ1, m1, bsn)

If bsn =⊥ return 0. For b = 0, 1: If Verify(gmpk, mb, bsn, σb) = 0, return ⊥. Parse σb as (credb, τb, σwb, pkotsb, Σb, σotsb). Return 1 if and only if τ0 = τ1.

DIRECT ANONYMOUS ATTESTATION 41 / 46

EFFICIENCY COMPARISON

Scheme Setting Join\Issue Issuer Host TPM [BCC04] RSA E4 + 4E + E2

Γ

E2 + E + EΓ 2E3 + 3EΓ [BCL08] Sym 2EG + 2E2

G

6P 3EG [C09] Asym E2

G1 + EG1

EG2 + 2P 2EG1 [CMP09] Asym 2EG1 + 2E2

G1

4P 3EG1 [CPS10] Asym 2E2

G1 + 3EG1

4P 3EG1 Ours (ROM) Asym E2

G1 + 5EG1

2E2

G1 + 4P

EG1 TABLE: Efficiency comparison

◮ E: (modular) exponentiation. ◮ En: n simultaneous exponentiations. ◮ P: Pairing evaluations.

DIRECT ANONYMOUS ATTESTATION 42 / 46

EFFICIENCY COMPARISON

Scheme Signing Verification Host TPM [BCC04] E4 + 2E3 + E2 + E + EΓ E3 + 3EΓ E6 + 2E4 + E2

Γ + EΓ

[BCL08] 3EG + EGT + 3P E2

GT + 2EGT

E3

GT + E2 GT + 5P

[C09] EG1 + E3

GT

2EG1 + EGT E2

G1 + E2 G2 + E4 GT + P

[CMP09] 3EG1 + P 2EG1 + EGT E3

GT + E2 G1 + 5P

[CPS10] 4EG1 3EG1 2E2

G1 + EG1 + 4P

Ours (ROM) 4EG1 3EG1 2E2

G1 + 4P

TABLE: Efficiency comparison

Scheme Setting Signature Size Ours (ROM) Asym 5|G1| + 2 log(q) Ours (SM) Asym 25|G1| + 11|G2| Groth’s GS [G07]† Asym 24|G1| + +15|G2| Groth’s GS [G07]† Asym-2 25|G1| + 19|G2|

TABLE: Size of the signature

DIRECT ANONYMOUS ATTESTATION 43 / 46

SUMMARY ◮ A rigorous security model that overcomes the shortcomings of previous models. ◮ A generic construction for DAA. ◮ More efficient instantiations in the random oracle model. ◮ The first efficient SoK in the standard model. ◮ The first DAA instantiations in the standard model.

DIRECT ANONYMOUS ATTESTATION 44 / 46

OPEN PROBLEMS ◮ A LIT for large domain space which is based on non-interactive intractability assumptions or finding alternative means to realize indistinguishability and linkability needed for DAA. ◮ More efficient constructions in the standard model.

DIRECT ANONYMOUS ATTESTATION 45 / 46

MORE DETAILS

1 D. Bernhard, G. Fuchsbauer, E. Ghadafi, N.P. Smart and B.

• Warinschi. Anonymous attestation with user-controlled
• linkability. Int. Journal of Information Security, 1615–5262,

1–31, February 2013.

2 D. Bernhard, G. Fuchsbauer and E. Ghadafi. Efficient Signatures

• f Knowledge and DAA in the Standard Model. Cryptology

ePrint Archive, Report 2012/475. August 2012. http://eprint.iacr.org/2012/475.pdf .

DIRECT ANONYMOUS ATTESTATION 45 / 46

THE END

Thank you for your attention! Questions?

DIRECT ANONYMOUS ATTESTATION 46 / 46