In this section, we provide a sketch of the security proof of the LEPID followed by a detailed security proof.
A Sketched Security Proof for LEPID
A variant of the sequence of games of [CDL16] is presented, showing that no environmentE can dis- tinguish the real world protocolΠ with an adversary A, from the ideal world FlEPIDwith a simulatorS. Starting with the real world protocol game, we change the protocol game by game in a computationally indistinguishable way, finally ending with the ideal world protocol.
Game 1. This is the real world protocol.
Game 2. An entity C is introduced, that receives all inputs from the honest parties and simulatesΠ for them. This is equivalent to Game 1.
Game 3. C is split intoF and S. F behaves as an ideal functionality, receiving all inputs and forwarding them to S, who simulates the real world protocol for honest parties. S sends the outputs to F, who forwards them toE. This game is similar to Game 2, but with a different structure.
Game 4. F now behaves differently in the setup interface. It stores the algorithms for the issuer I, and checks that the structure of sid is correct for an honestI, aborting if not. In case I is corrupt, S extracts the secret key forI and proceeds in the setup interface on behalf of I. Clearly E will notice no change. Game 5. F now performs the verification and key revocation checks instead of forwarding them to S. There are no protocol messages and the outputs are exactly as the real world protocol. However, the verification algorithm thatF uses does not contain any key or signature revocation checks. F can perform this check separately, so the outcomes are equal.
Game 6. F stores in its records the members that have joined. If I is honest, F stores the secret key tsk, extracted fromS, for corrupt platforms. S always has enough information to simulate the real world protocol except when the issuer is the only honest party. In this case,S does not know who initiated the join, and so cannot make a join query withF on the signer’s behalf. Thus, to deal with this case, F can safely choose any corrupt signer and put it into Members. The identities of signers are only used for creating signatures for honest signers, so corrupted signers do not matter. In the case that the signer is already registered in Members,F would abort the protocol, but I will have already tested this case before continuing with the query JOINPROCEED. HenceF will not abort. Thus in all cases, F and S can interact to simulate the real world protocol.
Game 7. (Anonymity). In this game,F creates anonymous signatures for honest platforms by running the algorithms defined in the setup interface. Let us start by defining Game 7.k.k0. In this gameF handles the first k0signing inputs ofMifor i < k using algorithms, and subsequent inputs are forwarded toS who
creates signatures as before. We note that Game 7.0.0=Game 6. For increasing k0, Game 7.k.k0will be at some stage equal to Game 7.k+ 1.0, this is because there can only be a polynomial number of signing queries to be processed. Therefore, for large enough k and k0,F handles all the signing queries of all signers, and Game 7 is indistinguishable from Game 7.k.k0. To prove that Game 7.k.k0+ 1 is indistin- guishable from Game 7.k.k0, suppose that there exists an environment that can distinguish a signature of an honest party using tsk= xxx1from a signature using a different tskj= xxx1j, then the environment can solve
The first j ≤ k0 signing queries on behalf of Mk are handled by F using the algorithms, and
subsequent inputs are then forwarded to S as before. Now suppose that F outputs the tu- ples (nymj, pppj,oooij,kkkij,dddij, sssxj1, sss
j e, sssqji, sss j l0i, sss j l00i , sss j l000i ,c j
v,SRL) for j ≤ k0, with nymj = pppjxxx1+ eeej, for an
error term eeej ← Ds, and the remaining proofs are honestly generated. The j = k0+ 1-th
query for Mk is as follows: (nymS, pppS,oooSi ,kkksi,dddSi, sssSx1, sss
S e, sssSqi, sss S l0 i , sssS l00 i , sssS l000 i ,cS v,µS,SRL). S is chal-
lenged to decide if (nymS, pppS,oooSi,kkkis,dddSi, sssSx1, sssSe, sssSqi, sssSl0 i , sssS l00 i , sssS l000 i ,cS
v,µS,SRL) is chosen from a Ring-
LWE distribution for some secret xxx1 or uniformly at random. S proceeds in simulating the
signer without knowing the secret xxx1. S can answer all the H queries, as S is controlling
FCRS. S sets: tttSki=oooSi sssSx1 + sss S l00i − X cSvkkkS i; tttSdi=nym ∗ isssSqi + sss S l000i − X cSvdddS i; tttSoi=ppp ∗ isssSqi + sss S l0i − X cSvoooS i; tttSnym=pppSsssSx 1+ sss S e− Xc S
vnymS; and, finally, cS
v :=H(tttSnym|tttSoi|ttt
S ki|ttt
S di|µ
S).For i > k0+ 1, S outputs the tuples
(nymj, pppj,oooij,kkkij,dddij, sssxj1, sssej, sssqji, sssj l0i, sss j l00i , sss j l000i ,c j v,µj,SRL), with nymj= pppjxxx j 1+ eee
j mod q, for some freshly
generated secret xxx1j and error term eeej←Ds. For each case,Mk can provide a simulated proof as fol-
lows.S sets tttkj i=ooo j isss j x1+ sss j l00i − X cvjkkkj i; ttt j di=nym ∗ isss j qi+ sss j l000i − X cvjdddj i; ttt j oi=ppp ∗ isss j qi+ sss j l0i− X cvjoooj i; ttt j nym=pppjsss j x1+ sss j e−
Xcvjnymj; and, finally, cj
v:=H(ttt j nym|ttt j oi|ttt j ki|ttt j di|µ j).
Thus, any distinguisher between Game 7.k.k0 and Game 7.k.k0+ 1 can solve the Decision Ring-LWE Problem.
Game 8. F now no longer informs S about the message and ppp that are being signed. If the signer M is honest, thenS can learn nothing about the message µ and ppp. Instead, S knows only the leakage l(µ, ppp). To simulate the real world,S chooses a pair (µ0, ppp0) such that l(µ0, ppp0)=l(µ, ppp). An environment E observes no difference, and thus Game 8=Game 7.
Game 9. If I is honest, then F now only allows members that joined to sign. An honest signer will always check whether it has joined before signing in the real world protocol, so there is no difference for honest signers. Therefore Game 9=Game 8.
Game 10. When storing a new tsk= xxx1,F checks CheckTskCorrupt(tsk)=1 or CheckTskHonest(tsk)=1.
We want to show that these checks will always pass. In fact, valid signatures always satisfy nym= pppxxx1+eee
where kxxx1k∞≤β and keeek∞≤β. By the unique Shortest Vector Problem, there exists only one tuple (xxx1,eee)
such that kxxx1k∞≤β and keeek∞≤β for small enough β. Thus, CheckTskCorrupt(tsk) will always give
the correct output. Also, due to the large min-entropy of discrete Gaussians the probability of sampling xxx01= xxx1, and thus of having a signature already using the same tsk= xxx1, is negligible, which implies
that CheckTskHonest(tsk) will give the correct output with overwhelming probability. Hence Game 10=Game 9.
Game 11. (Completeness). In this game,F checks that honestly generated signatures are always valid. This is true as sig algorithm always produces signatures passing through verification checks. Those signatures satisfy identify(tsk, σ, µ, ppp)= 1, which is checked via
nym. F also makes sure, using its internal records Members and DomainKeys that honest users are not sharing the same secret key tsk. If there exists a key tsk0= xxx01in Members and DomainKeys such that
knym − pppxxx01k∞≤β, then this breaks search Ring-LWE.
Game 12. Check-IX is added to ensure that there are no multiple tsk tracing back to the same signature. Since there exists only one pair (xxx1,eeeI), kxxx1k∞≤β, keeeIk∞≤β, satisfying nymI= H(bsnI)xxx1+ eeeI, two different signers cannot share the same xxx1, thus any valid signature traces back to a single tsk.
Game 13. (Unforgeability). To prevent accepting signatures that were issued by the use of join creden- tials not issued by an honest issuer,F further adds Check-X. This is due to the unforgeability of Boyen signatures [Boy10].
Game 14. (Unforgeability). Check-XI is added toF, preventing the forging of signatures with honest tsk and credentials. If a valid signature is given on a message that the signer has never signed, the proof could not have been simulated. xxx1would be extracted and Ring-LWE would be broken. So Game 14=Game
13.
Game 15. Check-XII is added toF, ensuring that honest signers’ keys are not being revoked. If an honest signer is simulated by means of the Ring-LWE problem instance and a proper key KRL is found, it must be the secret key of the target instance. This is equivalent to solving the search Ring-LWE problem.
Game 16. F now performs signature-based revocation when verifying signatures. F checks that there is no (σ∗,nym∗, ppp∗) ∈ SRL such that for some matching tski and (σ∗,µ∗, ppp∗) ∈ SRL, we have
identify(σ∗,µ∗, ppp∗,tski)= 1. By the soundness of the proof presented in Section 6.4.2, this check will
always pass with overwhelming probability.
Detailed Security Proof of the LEPID Scheme
• SETUP
On input (SETUP, sid) fromI, output (FORWARD, (SETUP, sid,I) to S. • JOIN
1. On input (JOIN, sid, jsid) from the platform Mi, output (FORWARD, (JOIN,
sid, jsid,Mi)) toS.
2. On input (JOINPROCEED,sid, jsid) from I, output (FORWARD,
(JOINPROCEED,sid, jsid),I) to S. • SIGN
1. On input (SIGN,sid, ssid, ppp) fromMi, output (FORWARD, (SIGN,sid, ssid,Mi, ppp)) to S.
2. On input (SIGNPROCEED,sid, ssid) fromMi, output (FORWARD, (SIGNPROCEED,
sid, ssid), Mi) toS.
• VERIFY
On input (VERIFY, sid, µ, ppp,σ,KRL,SRL) from V, output (FORWARD, (VERIFY, sid,µ, ppp,σ,KRL,SRL), V) to S.
• REVOKE: On the input tsk∗ from a party R, output (FORWARD, (REVOKE, sid,µ,tsk∗,KRL,SRL), R) to S.
On the input (σ∗,µ∗, ppp∗) from a party R, (FORWARD, (REVOKE, sid, µ∗, ppp∗,σ∗,KRL,SRL), R) toS.
• OUTPUT
On input (OUTPUT, P, µ) fromS, output µ to P. Figure 6.1:Game 3 forF
• KeyGen
Upon receiving input (FORWARD, (SETUP, sid,I)from F, give “I” (SETUP, sid) . • JOIN
1. Upon receiving (FORWARD, (JOIN, sid, jsid,Mi) fromF, give input (JOIN, sid, jsid)
to “Mi”
2. Upon receiving input (FORWARD, (JOINPROCEED,sid, jsid),I) from F, give “I” input (JOINPROCEED,sid, jsid).
• SIGN
1. Upon receiving input (FORWARD, (SIGN, sid, ssid,Mi, ppp) from F, give “Mi” input
(SIGN, sid, ssid, ppp).
2. Upon receiving input (FORWARD, (SIGNPROCEED,sid, ssid),Mi) fromF, give “Mi”
input (SIGNPROCEED,sid, ssid). • VERIFY
Upon receiving input (FORWARD, (VERIFY, sid, µ, ppp,σ,KRL,SRL), V) from F, give “V” input (VERIFY, sid, µ, ppp,σ,KRL,SRL).
• REVOKE
Upon receiving (FORWARD, (REVOKE, sid, µ, tsk∗,KRL,SRL), R) from F, give “R” an input (REVOKE, sid, µ, tsk∗,KRL,SRL).
Upon receiving (FORWARD, (REVOKE, sid, µ∗, ppp∗,σ∗,KRL,SRL), R) from F, give “R” an
input (REVOKE, sid, µ∗, ppp∗,σ∗,KRL,SRL). • OUTPUT
When any simulated party “P” outputs a message µ,S sends (OUTPUT, P,µ)to F. Figure 6.2:Game 3 forS
• SETUP
1. On input (SETUP, sid) fromI, verify that sid = (I,sid0) and output (SETUP, sid) toS. 2. On input (ALGORITHMS, sid, sign, ver, revoke, identify, Kgen) fromS, check that ver,
revoke, and identify are deterministic. Store ( sid, sign, ver, revoke, identify, Kgen) and output (SETUPDONE, sid) toI.
• JOIN
1. On input (JOIN, sid, jsid) from the platform Mi, output (FORWARD, (JOIN,
sid, jsid,Mi)) toS.
2. On input (JOINPROCEED,sid, jsid) from I, output (FORWARD, (JOINPROCEED,sid, jsid),I) to S.
• SIGN
1. On input (SIGN, sid, ssid, ppp) fromMi, output (FORWARD, (SIGN, sid, ssid,Mi, ppp)) to
S.
2. On input (SIGNPROCEED,sid, ssid) from Mi, output (FORWARD,
(SIGNPROCEED,sid, ssid),Mi) toS. • VERIFY
On input (VERIFY, sid, µ, ppp,σ,KRL,SRL) from V, output (FORWARD, (VERIFY, sid,µ, ppp,σ,KRL,SRL), V) to S.
• REVOKE
On the input tsk∗from a party R, output (FORWARD, (REVOKE, sid, µ, tsk∗,KRL), R) to S. On the input (σ∗,µ∗, ppp∗,KRL,SRL) from a party R, (FORWARD, (REVOKE,
sid,µ∗, ppp∗,σ∗,KRL,SRL), R) to S. • OUTPUT
On input (OUTPUT, P, µ) fromS, output µ to P.
Figure 6.3:Game 4 forF
• KeyGen: HonestI: On input (SETUP, sid) from F – Check sid= (I,sid0), output ⊥ toI if the check fails. – Give “I” input (SETUP, sid).
– Upon receiving output (SETUPDONE, sid) from “I”, S takes its private key ˆTI. – Define Sign(tsk, µ, ppp,KRL,SRL) as follows:
Define SamplePre( ˆTI,uuut,uuu,id) that outputs a signature ˆXh= [ ˆXh1| ˆXh2] as satisfying
ˆ
AhXˆh= uuuh mod q,
with k ˆXh1k∞≤β/2 and k ˆXh2k∞≤β, and id is a fresh tag will be the L-EPID credential.
∗ nym= ppptsk + eee mod q, for an error term eee ← Dssuch that keeek∞< β.
∗ ∀(σ∗i, ppp∗i,nym∗i) ∈ SRL · qqqi,lll0i,lll00i ,lll000i ←Ds · oooi= ppp∗iqqqi+ lll 0 i · kkki= oooixxx1+ lll00i · dddi= nym∗iqqqi+ lll 000 i · rrrx1,rrre,rrrqi,rrrli0,rrrl00i ,rrrl000i ←Ds · tttnym= ppprrrx1+ rrre · tttoi= ppp ∗ irrrqi+ rrrl0i. · tttki = oooirrrx1+ rrrl00i . · tttdi= nym ∗ irrrqi+ rrrl000i . · cv= H(tttnym|tttoi|tttki|tttdi|µ) ∈ {0,1,2,...,2n − 1}. · sssx1= rrrx1+ x cvxxx 1 · ssse= rrre+ xcveee · sssqi= rrrqi+ x cvqqq i · sssl0 i= rrrl 0 i+ x cvlll0 i · sssl00 i = rrrl 00 i + x cvlll00 i · sssl000 i = rrrl 000 i + x cvlll000 i ∗ rej(sssx1, x cvxxx
1,ξ), rej(ssse, xcveee,ξ), rej(sssqi, x
cvqqq i,ξ), rej(sssl0 i, x cvlll0 i,ξ), rej(sssl00 i, x cvlll00 i ,ξ) or rej(sssl000 i , x cvlll000 i ,ξ). ∗ σ = ( π, nym, oooi, kkki, dddi, sssx 1, ssse, sssqi, sssl0i, sssl00i , sssl000i , cv, KRL, SRL)
– Define ver(σ, µ, ppp,KRL,SRL) as follows: ∗ ∀ tsk∗∈ KRL, if kppptsk∗− nymk∞≤β outputs 0. 1. ∀ σ∗i = (πnym∗ i,nym ∗ i, ppp ∗ i) ∈ SRL, 2. compute: 3. ttt0ki=oooisssx1+ sssl00i − x cvkkk i 4. ttt0di=nym ∗ isssqi+ sssl000i − x cvddd i 5. ttt0oi=ppp ∗ isssqi+ sssl0i− x cvooo i 6. ttt0 nym=pppsssx1+ ssse− x cvnym 7. cv ? = H(ttt0 nym|ttt0oi|ttt 0 ki|ttt 0 di|µ). 8. check ksssxxx1k∞, ksssek∞,ksssqik∞,ksssli0k∞,ksssl00i k∞,ksssl000i k∞≤β + √ nβ.
9. check 2kdddi− kkkik< Γ, where Γ is a function of β. If 2kdddi− kkkik< Γ the verifier outputs
∗ If all checks pass, output (VERIFIED, sid, 1), (VERIFIED, sid, 0) otherwise. – Define revoke( tsk∗,σ∗,µ∗, ppp∗), add tsk∗to KRL or σ∗to SRL after verifying σ∗.
– Define Identify(σ, µ, ppp,tsk) as follows: It parses σ as (nym, ppp) and checks that tsk ∈ Ds,
ver(σ, µ, ppp)=1 and knym − ppptskk∞≤β. If so output 1, otherwise output 0.
– Define Kgen, take tsk ∈Dsand output tsk.
– S sends (KEYS, sid, Sign, Verify, Revoke, Identify, Kgen) to F.
Corrupt I: S notices this setup as it notices I registering a public key with FCAwith sid=
(I,sid0).
– If the registered key is in the form ( ˆAI,πI) and πIis valid, thenS extracts ˆTIfrom πI. – S defines the algorithms Sign, Verify, Revoke, and Identify as before, but now depending
on the extracted key.S sends (SETUP, sid) to F on behalf of I. On input (KEYGEN, sid) fromF, S sends (KEYS, sid, Sign, Verify, Revoke, Identify, Kgen) to F.
– On input (SETUPDONE, sid) fromF. S continues simulating “I”. • JOIN, SIGN, VERIFY, REVOKE: Unchanged.
Figure 6.4:Game 4 forS
• SETUP
1. On input (SETUP, sid) fromI, verify that sid = (I,sid0) and output (SETUP, sid) toS.
2. On input (ALGORITHMS, sid, sign, ver, revoke, identify, Kgen) fromS, check that ver, revoke, and identify are deterministic. Store ( sid, sign, ver, revoke, identify, Kgen) and output (SETUPDONE, sid) toI.
• JOIN
1. On input (JOIN, sid, jsid) from the platform Mi, output (FORWARD, (JOIN,
sid, jsid,Mi)) toS.
2. On input (JOINPROCEED,sid, jsid) from I, output (FORWARD, (JOINPROCEED,sid, jsid),I) to S.
• SIGN
1. On input (SIGN, sid, ssid, ppp) fromMi, output (FORWARD, (SIGN, sid, ssid,Mi, ppp)) to
S.
2. On input (SIGNPROCEED,sid, ssid) from Mi, output (FORWARD,
(SIGNPROCEED,sid, ssid),Mi) toS. • VERIFY
On input (VERIFY, sid, µ, ppp,σ,KRL,SRL) from V – Set f = 0 if
∗ There is a tsk∗∈ KRL such that Identify(σ, µ, ppp,tsk∗)= 1
– Add (σ, µ, ppp,KRL, f ) to VerResults, output (VERIFIED, sid, f ) to V. • REVOKE
On input (REVOKE, tsk∗,σ∗,µ∗, ppp∗), the revocation manager adds tsk∗to KRL or σ∗to SRL after verifying σ∗.
• OUTPUT
On input (OUTPUT, P, µ) fromS, output µ to P.
Figure 6.5:Game 5 forF
• KeyGen, JOIN, SIGN : Unchanged. • VERIFY, REVOKE: Nothing to simulate.
Figure 6.6:Game 5 forS
• SETUP
1. On input (SETUP, sid) fromI, verify that sid = (I,sid0) and output (SETUP, sid) toS.
2. On input (ALGORITHMS, sid, sign, ver, revoke, identify, Kgen) fromS, check that ver, revoke, and identify are deterministic. Store ( sid, sign, ver, revoke, identify, Kgen) and output (SETUPDONE, sid) toI.
• JOIN
1. JOINREQUEST: On input (JOIN, sid, jsid) fromMi
– Create a join session h jsid,Mi, request i.
– Output (JOINSTART, sid, jsid,Mi) toS.
2. JOIN REQUEST DELIVERY: Proceed upon receiving delivery notification fromS. – Update the session record to h jsid,Mi, deliveredi.
– IfI or Miis honest and hMi,∗i is already in Members, output ⊥.
– Output (JOINPROCEED,sid, jsid,Mi) toI.
3. JOIN PROCEED: Upon receiving (JOINPROCEED,sid, jsid,Mi) fromI
– Update the session record to h jsid, sid,Mi, completei.
– Output (JOINCOMPLETE, sid, jsid) toS.
4. KEY GENERATION: On input (JOINCOMPLETE,sid, jsid, tsk) fromS. – Update the session record to h jsid,Mi, completei
– IfMiis honest, set tsk= ⊥.
– Insert hMi,tski into Members, and output (JOINED, sid, jsid) to Mi.
• SIGN
1. On input (SIGN, sid, ssid, ppp) fromMi, output (FORWARD, (SIGN, sid, ssid,Mi, ppp)) to
2. On input (SIGNPROCEED,sid, ssid) from Mi, output (FORWARD,
(SIGNPROCEED,sid, ssid),Mi) toS.
• VERIFY
On input (VERIFY, sid, µ, ppp,σ,KRL,SRL) from V – Set f = 0 if
∗ There is a tsk∗∈ KRL such that Identify(σ, µ, ppp,tsk∗)= 1 – If f , 0, set f =Verify(σ, µ, ppp, KRL, SRL).
– Add (σ, µ, ppp,KRL, f ) to VerResults, output (VERIFIED, sid, f ) to V.
• REVOKE
On input (REVOKE, tsk∗,σ∗,µ∗, ppp∗), the revocation manager adds tsk∗to KRL or σ∗to SRL after verifying σ∗.
• OUTPUT
On input (OUTPUT, P, µ) fromS, output µ to P.
Figure 6.7:Game 6 forF
• KeyGen: Unchanged. JOIN: HonestMi,I
– WhenS receives (JOINSTART, sid, jsid,Mi) fromF
– It simulates the real world protocol by giving “Mi” input (JOIN, sid, jsid) and waits for
output (JOINPROCEED, sid, jsid,Mi) from “I”.
– AsMiis honest,S already knows tsk as it is simulating Mi.
– S sends (JOINSTART, sid, jsid) to F.
– Upon receiving input (JOINCOMPLETE, sid, jsid) fromF, S gives “I” input (JOINPRO- CEED, sid, jsid) and waits for output (JOINED, sid, jsid) from “Mi”.
– Upon receiving input (JOINCOMPLETE, sid, jsid) fromF, S sends (JOINCOMPLETE, sid, jsid,⊥) to F.
HonestI, Corrupt Mi:
– S notices this join as “I” receives (SENT, sid0,(uuut,πuuut)) fromF
∗ auth.
– S doesn’t know the identity of the signer that started this join, so S chooses any corrupt M∗and proceeds as if this signer initiated this join, although this may not be the correct
signer. This makes no difference as when creating signatures we only look for corrupt signers as they are not considered in generating signatures.
– S then extracts tsk from the proof πuuut.
– S makes a join query with M∗by sending (JOIN, sid, jsid,M∗) toF.
– Upon receiving input (JOINSTART, sid, jsid,M∗) from F, S continues simulating “I” until it outputs (JOINPROCEED, sid, jsid,M∗).
– S sends (JOINSTART, sid, jsid) to F.
sid, jsid,tsk) to F.
– Upon receiving (JOINED, sid, jsid) fromF as Miis corrupt,S gives “I” input (JOIN-
PROCEED, sid, jsid). HonestMi, CorruptI:
– On input (JOINSTART, sid, jsid,Mi) fromF, S gives “Mi” input (JOIN, sid, jsid) and
waits for output (JOINED, sid, jsid,Mi) from “Mi”.
– S sends (JOINSTART, sid, jsid) to F.
– Upon receiving input (JOINPROCEED, sid, jsid) from F, S sends (JOINPROCEED, sid, jsid) to F on behalf of I.
– Upon receiving input (JOINCOMPLETE, sid, jsid) fromF, S sends (JOINCOMPLETE, sid, jsid,⊥) to F.
• SIGN, VERIFY, LINK: Unchanged.
Figure 6.8:Game 6 forS
• SETUP, JOIN: Unchanged. • SIGN
– SIGN REQUEST: On input (SIGN, sid, ssid, µ, ppp) fromMi,
∗ Create a sign session hssid,Mi,µ, ppp, requesti.
∗ Output (SIGNSTART, sid, ssid,Mi) toS.
– SIGN REQUEST DELIVERY: On input (SIGNSTART, sid, ssid) fromS, update the ses- sion to hssid,Mi,µ, ppp, deliveredi.
– Output (SIGNPROCEED, sid, ssid, µ, ppp) toMi.
– SIGN PROCEED: On input (SIGNPROCEED, sid, ssid) fromMi
∗ Update the records hssid,Mi,µ, ppp, deliveredi.
∗ Output (SIGNCOMPLETE, sid, ssid) toS.
– SIGNATURE GENERATION: On the input (SIGNCOMPLETE, sid, ssid, σ) fromS, if Miis honest then:
∗ Ignore the adversary’s signature σ. ∗ Generate the signature σ ← S ign(tsk, µ, ppp).
∗ For all (σ∗,µ∗, ppp∗) ∈ SRL, find all (tsk∗,M∗) from Members and DomainKeys such that identify(σ∗,µ∗, ppp∗,∗,tsk∗)= 1
· Check that no two distinct keys tsk∗trace back to σ∗. · Check that no pair (tsk∗,Mi) was found.
∗ IfMiis honest, then store hσ, µ,Mi, pppi in Signed and output (SIGNATURE, sid, ssid,σ)
toMi.
• VERIFY
On input (VERIFY, sid, µ, ppp,σ,KRL,SRL) from V – Set f = 0 if
∗ There is a tsk∗∈ KRL such that Identify(σ, µ, ppp,tsk∗)= 1
– If f , 0, set f =Verify(σ, µ, ppp).
– Add (σ, µ, ppp,KRL, f ) to VerResults, output (VERIFIED, sid, f ) to V. • REVOKE
On input (REVOKE, tsk∗,σ∗,µ∗, ppp∗), the revocation manager adds tsk∗to KRL or σ∗to SRL after verifying σ∗.
• OUTPUT
On input (OUTPUT, P, µ) fromS, output µ to P.
Figure 6.9:Game 7 forF
• KeyGen, JOIN: Unchanged. • SIGN :HonestMi
Upon receiving (SIGNSTART, sid, ssid,Mi, ppp,µ) from F.
– S starts the simulation by giving “Mi” input (SIGN, sid, ssid,, µ, ppp).
– When “Mi” outputs (SIGNPROCEED, sid, ssid, µ, ppp),S sends (SIGNSTART, sid, ssid)
toF.
– Upon receiving (SIGNCOMPLETE, sid, ssid) from F, output (SIGNPROCEED, sid, ssid) to “Mi”.
– When “Mi” outputs (SIGNATURE, sid, ssid, σ), send (SIGNCOMPLETE, sid, ssid, ⊥)
toF. CorruptMi
Upon receiving (SIGNSTART, sid, ssid,Mi, ppp,µ) from F, send (SIGNSTART, sid, ssid) to
F.
– Upon receiving (SIGNPROCEED, sid, ssid, µ, ppp) fromF on behalf of Mi, asMiis cor-
rupt,S sends (SIGN, sid, ssid,Mi,µ, ppp) to F on behalf of Mi.
– Upon receiving (SIGNCOMPLETE, sid, ssid) from F, S sends (SIGNCOMPLETE, sid, ssid,σ) to F.
• VERIFY, LINK: Nothing to simulate.
Figure 6.10:Game 7 forS
• SETUP, JOIN: Unchanged. • SIGN
– SIGN REQUEST: On input (SIGN, sid, ssid, µ, ppp) fromMi, ∗ Create a sign session hssid,Mi,µ, ppp, requesti.
∗ Output (SIGNSTART, sid, ssid,Mi, l(µ.bsn))toS.
– SIGN REQUEST DELIVERY: On input (SIGNSTART, sid, ssid) fromS, update the ses- sion to hssid,Mi,µ, ppp, deliveredi.
– Output (SIGNPROCEED, sid, ssid, µ, ppp) toMi.
– SIGN PROCEED: On input (SIGNPROCEED, sid, ssid) fromMi ∗ Update the records hssid,Mi,µ, ppp, deliveredi.
∗ Output (SIGNCOMPLETE, sid, ssid) toS.
– SIGNATURE GENERATION: On the input (SIGNCOMPLETE, sid, ssid, σ) fromS, if Miis honest then:
∗ Ignore the adversary’s signature σ.
∗ Generate the signature σ ← S ign(tsk, µ, ppp).
∗ For all (σ∗,µ∗, ppp∗) ∈ SRL, find all (tsk∗,M∗) from Members and DomainKeys such that identify(σ∗,µ∗, ppp∗,∗,tsk∗)= 1
· Check that no two distinct keys tsk∗trace back to σ∗.
· Check that no pair (tsk∗,Mi) was found.
∗ IfMiis honest, then store hσ, µ,Mi, pppi in Signed and output (SIGNATURE, sid, ssid,σ)
toMi. • VERIFY
On input (VERIFY, sid, µ, ppp,σ,KRL,SRL) from V – Set f = 0 if
∗ There is a tsk∗∈ KRL such that Identify(σ, µ, ppp,tsk∗)= 1 – If f , 0, set f =Verify(σ, µ, ppp, KRL, SRL).
– Add (σ, µ, ppp,KRL, f ) to VerResults, output (VERIFIED, sid, f ) to V.
• REVOKE
On input (REVOKE, tsk∗,σ∗,µ∗, ppp∗), the revocation manager adds tsk∗to KRL or σ∗to SRL after verifying σ∗.
• OUTPUT
On input (OUTPUT, P, µ) fromS, output µ to P.
Figure 6.11:Game 8 forF
• KeyGen, JOIN: Unchanged. • SIGN
HonestMi:
Upon receiving (SIGNSTART, sid, ssid,Mi,l) from F.
– S takes a dummy pair (µ0,bsn0) such that l(µ0,bsn0)= l.
– S starts the simulation by giving “Mi” input (SIGN, sid, ssid, µ0, ppp0).
– When “Mi” outputs (SIGNPROCEED, sid, ssid, µ0, ppp0),S sends (SIGNSTART, sid, ssid)
toF.
sid, ssid) to “Mi”.
– When “Mi” outputs (SIGNATURE, sid, ssid, σ), send (SIGNCOMPLETE, sid, ssid, ⊥)
toF. CorruptMi
Upon receiving (SIGNSTART, sid, ssid,Mi,l) from F.
– Send (SIGNSTART, sid, ssid) toF.
– Upon receiving (SIGNPROCEED, sid, ssid, µ, ppp) fromF on behalf of Mi, asMiis cor-
rupt,S sends (SIGNPROCEED, sid, ssid,µ, ppp) to F on behalf of Mi.
– Upon receiving (SIGNCOMPLETE, sid, ssid) from F, send (SIGNCOMPLETE, sid, ssid,σ) to F.
• VERIFY, LINK: Nothing to simulate.
Figure 6.12:Game 8 forS
• SETUP, JOIN: Unchanged. • SIGN
– SIGN REQUEST: On input (SIGN, sid, ssid, µ, ppp) fromMi, – Abort ifI is honest and no entry hMi,∗i exists ML.
∗ Create a sign session hssid,Mi,µ, ppp, requesti. ∗ Output (SIGNSTART, sid, ssid,Mi, l(µ.bsn)) toS.
– SIGN REQUEST DELIVERY: On input (SIGNSTART, sid, ssid) fromS, update the ses- sion to hssid,Mi,µ, ppp, deliveredi.
– Output (SIGNPROCEED, sid, ssid, µ, ppp) toMi.
– SIGN PROCEED: On input (SIGNPROCEED, sid, ssid) fromMi ∗ Update the records hssid,Mi,µ, ppp, deliveredi.
∗ Output (SIGNCOMPLETE, sid, ssid) toS.
– SIGNATURE GENERATION: On the input (SIGNCOMPLETE, sid, ssid, σ) fromS, if Miis honest then:
∗ Ignore the adversary’s signature σ.
∗ Generate the signature σ ← S ign(tsk, µ, ppp).
∗ For all (σ∗,µ∗, ppp∗) ∈ SRL, find all (tsk∗,M∗) from Members and DomainKeys such that identify(σ∗,µ∗, ppp∗,∗,tsk∗)= 1
· Check that no two distinct keys tsk∗trace back to σ∗.
· Check that no pair (tsk∗,Mi) was found.
∗ IfMiis honest, then store hσ, µ,Mi, pppi in Signed and output (SIGNATURE, sid, ssid,σ)
toMi. • VERIFY
On input (VERIFY, sid, µ, ppp,σ,KRL,SRL) from V – Set f = 0 if
∗ There is a tsk∗∈ KRL such that Identify(σ, µ, ppp,tsk∗)= 1
– If f , 0, set f =Verify(σ, µ, ppp, KRL, SRL).
– Add (σ, µ, ppp,KRL, f ) to VerResults, output (VERIFIED, sid, f ) to V. • REVOKE
On input (REVOKE, tsk∗,σ∗,µ∗, ppp∗), the revocation manager adds tsk∗to KRL or σ∗to SRL after verifying σ∗.
• OUTPUT
On input (OUTPUT, P, µ) fromS, output µ to P.
Figure 6.13:Game 9 forF
• SETUP: Unchanged. • JOIN: Unchanged. • SIGN: Unchanged. • VERIFY: Unchanged. • LINK: Unchanged.
Figure 6.14:Games 9-16 forS
• SETUP: Unchanged. • JOIN
1. JOINREQUEST: On input (JOIN, sid, jsid) fromMi – Create a join session h jsid,Mi, request i.
– Output (JOINSTART, sid, jsid,Mi) toS.
2. JJOIN REQUEST DELIVERY: Proceed upon receiving delivery notification fromS.
– Update the session record to h jsid,Mi, deliveredi.
– IfI or Miis honest and hMi,∗i is already in Members, output ⊥. – Output (JOINPROCEED,sid, jsid,Mi) toI.
3. JOIN PROCEED: Upon receiving (JOINPROCEED,sid, jsid,Mi) fromI – Update the session record to h jsid, sid,Mi, completei.
– Output (JOINCOMPLETE, sid, jsid) toS.
4. KEY GENERATION: On input (JOINCOMPLETE,sid, jsid, tsk) fromS.
– Update the session record to h jsid,Mi, completei – IfMiis honest, set tsk= ⊥.
– Else, verify that the provided tsk is eligible by performing the following checks: ∗ IfMiis honest, then CheckTskHonest(tsk)=1.
∗ IfMiis corrupt, then CheckTskCorrupt(tsk)=1.
• SIGN
– SIGN REQUEST: On input (SIGN, sid, ssid, µ, ppp) fromMi, – Abort ifI is honest and no entry hMi,∗i exists ML.
∗ Create a sign session hssid,Mi,µ, ppp, requesti. ∗ Output (SIGNSTART, sid, ssid,Mi, l(µ.bsn)) toS.
– SIGN REQUEST DELIVERY: On input (SIGNSTART, sid, ssid) fromS, update the ses- sion to hssid,Mi,µ, ppp, deliveredi.
– Output (SIGNPROCEED, sid, ssid, µ, ppp) toMi.
– SIGN PROCEED: On input (SIGNPROCEED, sid, ssid) fromMi ∗ Update the records hssid,Mi,µ, ppp, deliveredi.
∗ Output (SIGNCOMPLETE, sid, ssid) toS.
– SIGNATURE GENERATION: On the input (SIGNCOMPLETE, sid, ssid, σ) fromS, if