The BCNSW group signature scheme is a dynamic scheme with verifiable opening employing a user PKI (connected with an unforgeable digital signature scheme Σ = (Kg, Sign, Vrfy) specified in Section 3.4). It has a single security parameter κ ∈ N and uses bilinear groups G1 = (g1), G2 = (g2), and GT of prime order Q with |Q| = κ and a bilinear map e : G1 × G2 → GT. Additionally, two hash functions Hash1, Hash2 : {0, 1}∗ → ZQ are used and modeled as random oracles in the proof of security. The BCNSW scheme is based on the ordinary Camenisch- Lysyanskaya signature scheme [57, Scheme A] and especially makes use of the fact that these signatures are re-randomizable, i.e., given a valid signature (a, b, c) ∈ G3
1 on a message m, the signature (ar, br, cr) will also be valid for any r ∈ Z∗
Q.
In the following we specify the core algorithms and protocols of the BCNSW scheme. Our description follows the specification from [31].
Key generation. The key generation algorithm GKg on input 1κ performs the following steps: x
1. Select x ∈RZQ, y ∈RZQ and set X = g2, Y = g2 y .
2. Output (gpk, gmsk, reg) such that:
• group public key gpk = (Q, G1, G2, g1, g2, e, X, Y ) • group manager’s secret key gmsk = (gpk, x, y) • registration list reg is initially empty.
It is assumed that key generation is performed in a trusted way. In particular, this means that the elements x, y are chosen independently at random from ZQ. This assumption is necessary to ensure trust into the group public key gpk.
User key generation. The user key generation algorithm UKg on input 1κ computes and returns the private/public key pair (usk[i], upk[i]) ←R Kg(1κ) for the digital signature scheme Σ where upk[i] is assumed to be certified. As noticed in Section 2.3.2 a user PKI is modeled here through public (read) access to the list of registered public keys upk.
Join protocol. The join protocol Join is executed between the group manager with input
gmsk = (gpk, x, y) and a prospective member i with input gpk = (Q, G1, G2, g1, g2, e, X, Y ) and an own PKI-certified key pair (usk[i], upk[i]). It proceeds as follows:
1. The group manager chooses a random Ki ∈R ZQ, computes ti = Hash2(Ki), and sends ti to the member i.
2. Member i chooses τi ∈R ZQ, computes si = gτ1i, ri = Xτi, ki = e(g
1, ri), as well as σ¯i ←R Sign(usk[i], ki), sends (si, ri, σ¯i) to the group manager together with a proof
τi = Xτi
NIZKPoK τi : si = g1 and ri .
3. The group manager verifies the signature using Vrfy(upk[i], e(g1, ri), σ¯i) and computes, if the signature is valid, zi = sig1
Ki and w
i = riXKi, stores (wi, ri, Ki, σ¯i) in reg[i], chooses
ρi y x ρixy
ρi ∈R ZQ, computes ai = g1 , bi = ai, and ci = aizi , and sends (ai, bi, ci, Ki) to the user together with a proof
x ρixy ρi x ci = aizi and ai = g 1 and X = g2 NIZKPoK x, y, ρi : y . Y = g2 and 1 = bx i/g1 ρixy
4. Member i computes ξi = τi + Ki mod Q and checks whether ti = Hash2(Ki). She also verifies e(ai, Y ) = e(bi, g2) and, if the verification is successful, stores the entry gsk[i] = (gpk, ξi, ai, bi, ci).
The (ai, bi, ci) part of the secret signing key represents an ordinary Camenisch-Lysyanskaya signature on message ξi.
Signature generation. The signing algorithm GSign takes as input the secret signing key gsk[i] = (gpk, ξi, ai, bi, ci) of member i, where gpk = (Q, G1, G2, g1, g2, e, X, Y ), and a message m ∈ {0, 1}∗, and proceeds as follows:
1. Re-randomize the signature by choosing r ∈R ZQ and computing T1 = air, T2 = bir, and T3 = cir.
2. Compute S as a signature of knowledge e(T3,g2)
SoK ξi : e(T1,X) = e(T2, X)ξi m .
3. Output group signature σ = (S, T1, T2, T3).
In the above signature generation algorithm, which leverages the re-randomizability property of ordinary Camenisch-Lysyanskaya signatures, the SoK signature proves that the signer knows ξi for which (T1, T2, T3) is a valid signature; thus, proving that the signer has a valid signing key gsk[i].
Signature verification. The signature verification algorithm GVrfy takes as input the group public key gpk = (Q, G1, G2, g1, g2, e, X, Y ), a message m, and a candidate group signature σ and proceeds as follows:
1. Parse σ as (S, T1, T2, T3).
2. If e(T1, Y ) = e(T2, g2) and S is a valid SoK signature on message m then output 1; otherwise output 0.
Opening procedure. The opening algorithm Open takes as input the group manager’s secret key gmsk = (gpk, x, y), a message m, a group signature σ, and the registration list reg, and proceeds as follows:
1. Parse σ as (S, T1, T2, T3).
2. If GVrfy(gpk, m, σ) = 0 then output (0, ⊥).
3. For all entries reg[i] = (wi, ri, Ki, σ¯i) check whether e(T3, g2) = e(T1, X)e(T2, wi) holds. If the equation holds for no entry reg[i] then output (0, ⊥), otherwise compute for the entry reg[i], for which the equation holds, ki = e(g1, ri) and J as the NIZKPoK proof
NIZKPoK wi, Ki :
e(T3,g2)
e(T1,X) = e(T2, wi) and ki =
e(g1,wi)
e(g1,X)Ki .
4. Output (i, τ) where τ = (ki, ¯σi, J).
The NIZKPoK proof J ensures that the group manager does not output some uninvolved member i for which e(T3, g2) = e(T1, X)e(T2, wi) does not hold. By putting out ki, the verifi cation of the signature σ¯i on ki becomes possible (with e(g1, ri) = ki).
Note that the opening operation is linear in the number of users in the system, which is reasonable if the group manager has sufficient resources and the operation is not performed too often.
Judgement procedure. The judgement algorithm Judgetakes as input the group public key
gpk = (Q, G1, G2, g1, g2, e, X, Y ), a message m, a group signature σ, an identity i, and proof τ, and proceeds as follows:
1. If GVrfy(gpk, m, σ) = 0 then output 0. 2. Retrieve upk[i].
3. Parse τ as (ki, σ¯i, J).
4. If J is a valid NIZKPoK and Vrfy(upk[i], ki, σ¯i) = 1 then output 1, otherwise output 0. The judgement procedure ensures the validity of the group signature. Through the additional verification of the NIZKPoK proof J it obtains confidence that user i has been chosen correctly from reg in the opening step. The actual identification of the signer i is performed using the signer’s PKI-certified public key upk[i] and the signature σ¯i. It is implicitly assumed that identity i points to the candidate public key upk[i] used in this final verification step.