Blind BBS Signatures

Blind BBS Signatures MATTR

vasilis.kalos@mattr.global

Grotto Networking

gregb@grotto-networking.com

Internet CFRG This document defines an extension to the BBS Signature scheme that supports blind digital signatures, i.e., signatures over messages not known to the Signer.

Introduction Blind signatures are cryptographic protocols that allow for a signer to create a signature over content without actually knowing the content. They form a useful cryptographic primitive particularly in situations that are privacy sensitive. The concept has existed for quite some time and is well explained in Chaum's 1985 popular article "Security without identification: transaction systems to make big brother obsolete" . In , "RSA Blind Signatures", the RSA signature scheme was extended to provide for blind signing. In this document the BBS digital signature scheme, as defined in , is extended to provide blind BBS signatures. Like BBS signatures blind BBS signatures work with a three party model of Signer, Prover, and Verifier. The blind BBS protocol defined here has the following useful properties:

Provides a signature over an ordered set of messages from the Prover that are kept secret from the Signer via a statistically hiding cryptographic commitment.
The Signer will produce a signature for the Prover, only if the later can prove knowledge of the set of messages they choose. This will be done through a zero-knowledge proof-of-knowledge of the ordered set of secret Prover messages. The Signer will not issue a signature without this proof of knowledge.
The Blind BBS signature produced is of the same size as current BBS signatures based on the same elliptic curve.
In addition to the Prover provided secret messages, the Signer can optionally sign over an additional ordered set of messages of their choosing. This is sometimes know as a "partially blind" signature.
Using the Blind BBS signature created by the Signer the Prover can disclose any subset of both the secret Prover messages or the Signer's messages and prove that these were in the signed sets.
Without knowledge of the ordered set of secret messages no selective disclosure proof can be generated even solely for a subset of the Signer messages. (within the security assumptions of the BBS signature scheme).

While the core BBS protocol allows a prover to either disclose or withhold a message from a verifier, this specification allows for committed disclosure of a message . In this case, the prover provides a commitment (computationally binding and perfectly hiding) to the message along with proof that the commitment corresponds to a particular message in the signature. This enables a prover to demonstrate properties of credential attributes without revealing the underlying attribute values. The idea behind this committed-disclosure extension for BBS is that it also accommodates further zero-knowledge proof (ZKP) extensions for predicate proofs -- e.g. range proofs or different pseudonyms -- in a modular, plug-and-play style. Such extensions are out of scope of this specification.

Blind BBS Protocol Overview The presented protocol, compared to the scheme defined in , introduces an additional communication step between the Prover and the Signer. An overview of the protocol is given below.

The Prover will start by constructing a "hiding" commitment to the ordered set of messages they want to get a signature on (i.e., a commitment which reveals no information about the committed values), together with a proof of correctness of that commitment.
The Prover will send the (commitment, proof) pair to the Signer, who, upon receiving the pair, will attempt to verify the commitment's proof of correctness.
If successful, they will use it in generating a blind BBS signature over the messages committed by the Prover, including the Signer's own messages if any.
The Signer will send the blind signature along with its additional ordered messages (if any) to the Prover
The Prover can choose to selectively disclose or commit to any subset of either its own messages, kept secret from the Signer and messages provided by the Signer in the signature. They also furnish a ZKP that the these disclosed messages were included in the signature.
The Verifier verifies the proof received from the Prover based on the Signer's public key.

Note: Cryptographic commitments are used for two distinct purposes in this specification. One, as a mechanism for the prover to get a blind signature from an signer, i.e., the prover is getting a signature over some data it is not revealing to the signer. And, two, as mechanism to furnish less information from the prover to the verifier by providing a commitment along with a ZKP about that commitment. For example, instead of providing a date of birth, the prover provides a commitment to that date of birth along with ZKP that indicates that the provers age lies in a particular range. Below is a basic diagram describing the main entities involved in the scheme.

Basic diagram capturing the main entities involved in using the scheme. | | | | | | | | | | +----------+ +-----------+ | | | (5)* Send proof + disclosed msgs | | \ / +-----------+ | | | | | | | Verifier | | | | | | | +-----------+ | / \ | | | | +----- (6) ProofVerify ]]> Note The protocols implied by the items annotated by an asterisk are out of scope for this specification This document, in addition to defining the operation for creating and verifying a commitment, also details a core signature generation operation, different from the one presented in , meant to handle the computation of the blind signature. The document will also define a new BBS Interface, which is needed to handle the different inputs, i.e., messages committed by the Prover or chosen by the Signer etc.. The signature verification and proof generation and verification core cryptographic operations however, will work as described in .

Example Blind BBS Applications By allowing the Prover to acquire a valid signature over messages not known to the Signer, blind signatures address some limitations of their plain digital signature counterparts. In the BBS Signature scheme, knowledge of a valid signature and set of signed messages allows generation of BBS proofs. As a result, a signature compromise (for example by a Signer database leakage, a phishing attack etc.,) can lead to impersonation of the Prover by malicious actors (especially in cases involving "long-lived" signatures, as in digital credentials applications etc.,). Using Blind BBS Signatures on the other hand, the Prover can commit to a secret message (for example, a private key) before issuance, guaranteeing that no one will be able to generate a valid BBS proof without knowledge of that secret message. Furthermore, applications like Privacy Pass () may require a signature to be "scoped" to a specific audience or session (as to require "fresh" signatures for different sessions etc.,). However, simply sending an audience or session identifier to the Signer (to be included in the signature), will compromise the privacy guarantees that these applications try to enforce. Using blind signing, the Prover will be able to require signatures bound to those values, without having to reveal them to the Signer.

Example Committed Disclosure Applications Privacy is enhanced via the committed disclosure mechanism along with an external ZKP proof of some predicate. In this case rather than selectively disclosing a signed message to the verifier the prover provides a (computationally binding and perfectly hiding) commitment along with a ZKP concerning some aspect (the predicate) of the committed value. For an example, consider a prover who must demonstrate that they are over 18 years old. Rather than revealing the credential attribute containing their date of birth, the prover generates a proof consisting of:

A BBS presentation proof according to step 5 of , in which the corresponding attribute remains hidden,
The commitment C as part of the above proof,
A proof of knowledge of the opening of C, together with a proof that the committed value is equal to the hidden message contained in the BBS signature,
An additional range proof P showing that the committed birth date in C corresponds to an age greater than or equal to 18.

The generation of predicate proofs (item 4) is outside the scope of this specification. However, this specification defines:

How Pedersen commitments are generated for attributes subject to predicates (item 2),
How equality proofs between committed values and credential attributes are constructed (item 3).

For this reason, the BlindProofGen procedure outputs, in addition to the proof proof sent to the verifier, the tuple add_zkp_info, containing the committed messages and the opening information required to reconstruct Pedersen commitments. This information is never sent to the verifier. Instead, it is retained by the prover and later used to generate predicate proofs. Committed disclosure allows for the modular addition of proving possession of a device key, range proofs, and pseudonyms as discussed in . These would all be implemented as an additional predicate ZKP along with the committed disclosure ZKP specified here.

Terminology Terminology defined by applies to this draft. Additionally, the following terminology is used throughout this document:

blind_signature: The blind digital signature output.
commitment: A point of G1, representing a Pedersen commitment () constructed over a vector of messages, as described e.g., in .
committed_messages: A list of messages committed by the Prover to a commitment.
commitment_proof: A zero knowledge proof of correctness of a commitment, consisting of a scalar value, a possibly empty set of scalars (of length equal to the number of committed_messages, see above) and another scalar, in that order.
secret_prover_blind: A random scalar used to blind (i.e., randomize) the commitment constructed by the prover.
signer_blind: A random scalar used by the signer to optionally re-blind the received commitment.
NONE: An empty function input indicator, used to specify that one of the OPTIONAL inputs of a procedure is not provided by the calling operation.

Notation Notation defined by applies to this draft. Additionally, the following notation and primitives are used:

list.append(elements): Append either a single element or a list of elements to the end of a list, maintaining the same order of the list's elements as well as the appended elements. For example, given list = [a, b, c] and elements = [d, a], the result of list.append(elements) will be [a, b, c, d, a].

Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

BBS Signature Scheme Operations This document makes use of various operations defined by the BBS Signature Scheme document . For clarity, whenever an operation will be used defined in , it will be prefixed by "BBS." (e.g., "BBS.CoreVerify" etc.). More specifically, the operations used are the following:

BBS.octets_to_point_E1: Refers to the octets_to_point_E1 operation defined in .
BBS.CoreVerify: Refers to the CoreVerify operation defined in .
BBS.ProofInit: Refers to the ProofInit operation defined in .
BBS.ProofFinalize: Refers to the ProofFinalize operation defined in .
BBS.ProofVerifyInit: Refers to the ProofVerifyInit operation defined in .
BBS.create_generators: Refers to the create_generators operation defined in .
BBS.calculate_random_scalars: Refers to the calculate_random_scalars operation defined in .
BBS.hash_to_scalar: Refers to the hash_to_scalar operation defined in .
BBS.calculate_domain: Refers to the calculate_domain operation defined in .
BBS.serialize: Refers to the serialize operation defined in .
BBS.signature_to_octets: Refers to the signature_to_octets operation defined in .
BBS.octets_to_signature: Refers to the octets_to_signature operation defined in .
BBS.octets_to_proof: Refers to the octets_to_proof operation defined in .
BBS.octets_to_pubkey: Refers to the octets_to_pubkey operation defined in .

Scheme Definition

Commitment Operations

Commitment Computation This operation is used by the Prover to create a commitment to a set of messages (committed_messages), that they intend to include in the blind signature. Note that this operation returns both the serialized combination of the commitment and its proof of correctness (commitment_with_proof), as well as the random scalar used to blind the commitment (secret_prover_blind).

Commitment Validation and Deserialization The following is a helper operation used by the BlindSign procedure () to validate an optional commitment. If a commitment is not supplied, or if it is the Identity_G1, the following operation will return the Identity_G1 as the "default" commitment point, which will be ignored by all computations during BlindSign.

Blind BBS Signatures Interface The following section defines a BBS Interface for blind BBS signatures. The identifier of the Interface is defined as ciphersuite_id || BLIND_H2G_HM2S_, where ciphersuite_id is the unique identifier of the BBS ciphersuite used, as defined in . Each BBS Interface MUST define operations to map the input messages to scalar values and to create the generator set, required by the core operations. The input messages to the defined Interface will be mapped to scalars using the messages_to_scalars operation defined in . The generators will be created using the create_generators operation defined in . Other than the BlindSign operation defined in , which uses the FinalizeBlindSign procedure, defined in , all other interface operations defined in this section use the core operations defined in .

Blind Signature Generation This operation returns a BBS blind signature from a secret key (SK), over a header, a set of messages and optionally a commitment value (see ). If supplied, the commitment value must be accompanied by its proof of correctness (commitment_with_proof, as outputted by the Commit operation defined in ). The BlindSign operation makes use of the FinalizeBlindSign procedure defined in and the B_calculate procedure defined in . The B_calculate is defined to return an array of elements, to establish extendability of the scheme by allowing the B_calculate operation to return more elements than just the point to be signed.

Blind Signature Verification This operation validates a blind BBS signature (signature), given the Signer's public key (PK), a header (header), a set of messages (messages), including first the messages chosen by the Issuer and then the ones chosen (and committed to) by the Prover and if used, the secret_prover_blind as returned by the Commit operation (). This operation makes use of the CoreVerify operation as defined in .

Proof Generation This operation creates a BBS proof, which is a zero-knowledge, proof-of-knowledge, of a BBS signature, while optionally disclosing any subset of the signed messages (either chosen by the Issuer or committed by the Prover). In addition, this operation can generate commitments to un-revealed messages and include with the BBS proof that these commitments correspond to specific un-revealed messages. These commitments can be used in subsequent ZKPs outside the scope of this specification . When this operation furnishes disclosed commitment values it will also return an additional bundle of information for use in external ZKPs . This add_zkp_info includes the committed message scalars and the random scalars, from these the disclosed commitments may be recomputed. The add_zkp_info should never be exposed, i.e., it is NOT to be sent to the verifier. The add_zkp_info structure has the following form: The operation will accept two sets of messages: issuer_messages from the issuer and the blind signed messages blind_messages from the prover. Furthermore, the operation also expects the secret_prover_blind (as returned from the Commit operation defined in ) value. If the BBS signature is generated using a commitment value, then the secret_prover_blind returned by the Commit operation used to generate the commitment should be provided to the ProofGen operation (otherwise the resulting proof will be invalid). This operation makes use of the CoreProofGen operation as defined in . The operation will also accept two arrays that indicate the intended handling of each message, issuer_message_disclosures and blind_message_disclosures respectively. Each entry corresponds to an issuer or blind message and can take one of the three values DISCLOSE, HIDE and COMMIT. A DISCLOSE value indicates that messages[i] will be revealed to the Verifier. Correspondingly, a HIDE value indicates that messages[i] will not be disclosed to the Verifier. Finally, a COMMIT value indicates that only a commitment to messages[i] will be disclosed to the Verifier, where messages[i] is either issuer_messages or blind_messages. An example of the issuer_message_disclosures input array is the following,

Proof Verification The ProofVerify operation validates a BBS proof, given the Signer's public key (PK), a header and presentation header values, an array of disclosed messages (the ones provided by the Signer and the ones committed by the prover) and a map message_disclosures describing how each signed message index is presented to the Verifier. In addition, the BlindProofVerify operation defined in this section accepts the integer issuer_known_messages_no, representing the total number of signed messages known by the Signer. This operation makes use of the CoreProofVerify operation as defined in . total_msgs_no, return INVALID 7. if length(message_disclosures) != total_msgs_no, return INVALID 8. if the keys of message_disclosures are not exactly the integers 0..total_msgs_no - 1, return INVALID 9. if any value in message_disclosures is not one of DISCLOSE, HIDE, or COMMIT, return INVALID 10. let disclosed_indexes be the integers i in 0..total_msgs_no - 1 so that message_disclosures[i] = DISCLOSE, in ascending order. 11. let commitment_indexes be the integers i in 0..total_msgs_no - 1 so that message_disclosures[i] = COMMIT, in ascending order. 12. if length(disclosed_indexes) != length(disclosed_messages), return INVALID 13. let proof_index(i) be i if i < issuer_known_messages_no, and i + 1 otherwise. 14. proof_disclosed_indexes = (proof_index(i) for i in disclosed_indexes) 15. proof_commitment_indexes = (proof_index(i) for i in commitment_indexes) Procedure: 1. generators = BBS.create_generators( issuer_known_messages_no + 1, api_id) 2. blind_generators = BBS.create_generators( total_msgs_no - issuer_known_messages_no + 1, "BLIND_" || api_id) 3. message_scalars = messages_to_scalars(disclosed_messages, api_id) 4. result = CoreProofVerify( PK, proof, generators.append(blind_generators), header, ph, message_scalars, proof_disclosed_indexes, proof_commitment_indexes, api_id) 5. return result ]]>

Core Operations

Core Commitment Computation

Core Commitment Verification This operation is used by the Signer to verify the correctness of a commitment_proof for a supplied commitment, over a list of points of G1 called the blind_generators, used to compute that commitment.

Finalize Blind Sign This operation computes a blind BBS signature from a secret key (SK) and the point to be signed (B). The operation also accepts the identifier of the BBS Interface that calls this core operation.

Core Proof Generation The Proof Generation with extension, combines the BBS Proof Generation operations (i.e., BBS.ProofInit and BBS.ProofFinalize) with a proof of correctness of commitments over some of the signed messages. The commitments proof of correctness will similarly constitute of a initialization and finalization phase. The two proof protocols will use a common challenge, returned by the ProofChallengeCalculate operation described in . The result of the commitments proof of correctness initialization process will be an object of the following form Following, we describe the Proof Generation Procedure.

Core Proof Verification

Utilities

Messages to Scalars The messages_to_scalars operation is used to map a list of messages to their respective scalar values, which are required by the Blind BBS Signatures Interface in . To accommodate additional ZKPs via the committed disclosure mechanism some messages may be treated as "raw" scalar values and others may be "hashed". Each raw message value has a corresponding flag to indicate how it should be processed by this operation. 2^64 - 1 Procedure: 1. L = length(messages) 2. for i in (1, ..., L): 3. if (messages[i].flag == "RAW") 4. msg_scalar_i = OS2IP(messages[i].value) 5. if (messages[i].flag == "HASH") 6. msg_scalar_i = BBS.hash_to_scalar(messages[i].value, map_dst) 7. return (msg_scalar_1, ..., msg_scalar_L) ]]> The MAP_TO_SCALAR_ID of the above operation is defines as, to indicate that it can pass through "Raw" values as scalars, as well as "Hash" messages to scalars.

Calculate B value

Blind Challenge Calculation

Proof Challenge Calculation 2^64 - 1 2. length(ph) > 2^64 - 1 Procedure: 1. c_arr = (R, i1, msg_i1, i2, msg_i2, ..., iR, msg_iR, Abar, Bbar, D, T1, T2, domain) 2. c_octs = BBS.serialize(c_arr) 3. commitment_arr = (N, ci_1, C_1, C~_1, ..., ci_N, C_N, C~_N) 4. c_octs = c_octs || BBS.serialize(commitment_arr) 5. c_octs = c_octs || I2OSP(length(ph), 8) || ph 6. return BBS.hash_to_scalar(c_octs, hash_to_scalar_dst) ]]>

Serialize

Commitment with Proof to Octets

Octets to Commitment with Proof = r, return INVALID 14. index += octet_scalar_length 15. j += 1 16. if index != length(commitment_octs), return INVALID 17. if j < 2, return INVALID 18. msg_commitments = () 19. if j >= 3, set msg_commitments = (s_1, ..., s_(j-2)) 20. return (C, (s_0, msg_commitments, s_(j-1))) ]]>

Proof to Octets

Octets to Proof The octets_to_proof procedure, on input an octet string will return a BBS proof with commitments proof comprised from the following elements

A BBS Proof
A tuple with two arrays. One array of points in G1, corresponding to the message commitments and one array with scalars, corresponding to the proof of correctness of the previous commitments.

= r, return INVALID 25. commitments_proof = ((C_1, ..., C_N), (s_1, ..., s_N)) 26. if length(proof_octets) not equal to eidx + 1, return INVALID 37. return (bbs_proof, commitments_proof) ]]>

Privacy Considerations The privacy considerations discussed in apply to this draft as well.

Total Number and Index of Committed Messages When a Prover submits a commitment to the Signer, the Prover's committed messages are "perfectly" (statistically) hidden from the Signer. However, the proof of the committed messages, which is also sent from the Prover to the Signer, contains the number of committed messages. In the proof sent from the Prover to the Verifier the number of committed messages can be inferred. In addition, indexes of disclosed and committed messages are revealed to the Verifier. In the threats to unlinkability and mitigations for this information with respect to Signer messages is discussed. These threats and mitigations apply to the Prover total number of committed messages and the disclosed and committed indexes as well.

Application Considerations

Input Validity Checks Applications using CoreProofGen (as defined in ) only as a subroutine of BlindProofGen (as defined in ), or CoreProofVerify (as defined in ) only as a subroutine of BlindProofVerify (as defined in ), can skip the checks of the commitment_indexes and disclosed_indexes inputs performed in the corresponding core operation, since the inputs provided by the calling operation will always have the correct form. However, if applications intend to use either core operation in different contexts, those checks must be applied.

Security Considerations Security considerations detailed in apply to this draft as well.

Prover Blind Factor The random scalar value secret_prover_blind calculated and returned by the Commit operation is responsible for "hiding" the committed messages (otherwise, in many practical applications, the Signer may be able to retrieve them). Furthermore, it guarantees that the entity generating the BBS proof (see BlindProofGen defined in ) has knowledge of that factor. As a result, the secret_prover_blind MUST remain private by the Prover and it MUST be generated using a cryptographically secure pseudo-random number generator. See on recommendations and requirements for implementing the BBS.calculate_random_scalars operation (which is used to calculate the secret_prover_blind value).

Key Binding One natural use case for the blind signatures extension of the BBS scheme is key binding. In the context of BBS Signatures, key binding guarantees that only entities in control of a specific private key can compute BBS proofs. This can be achieved by committing to the private key prior to issuance, resulting in a BBS signature that includes that key as one of the signed messages. Creating a BBS proof from that signature will then require knowledge of that key (similar to any signed message). The Prover MUST NOT disclose that key as part of a proof generation procedure. Note also that the secret_prover_blind value returned by the Commit operation defined in (see ), has a similar property, i.e., it's knowledge is required to generate a proof from a blind signature. Many applications however, requiring key binding, mandate that the same private key is used among multiple signatures, whereas the secret_prover_blind is uniquely generated for each blind signature issuance request. In those cases, a commitment to a private key must be used, as described above.

Ciphersuites This document uses the BBS_BLS12381G1_XOF:SHAKE-256_SSWU_RO_ and BBS_BLS12381G1_XMD:SHA-256_SSWU_RO_ defined in and correspondingly.

Test Vectors

BLS12-381-SHA-256

Generators

Blind Generators

Commitment Mocked random scalar parameters

valid no committed messages commitment with proof

valid multiple committed messages commitment with proof

Signature Test Vectors

valid no prover committed messages, no signer messages signature

valid multi prover committed messages, no signer messages signature

valid no prover committed messages, multiple signer messages signature

valid multiple signer and prover committed messages signature

valid no commitment signature

Proof Test Vectors Mocked random scalar parameters

valid all prover committed messages and signer messages revealed proof

valid half prover committed messages and all signer messages revealed proof

valid half prover committed messages and half signer messages revealed proof

valid no prover committed messages and half signer messages revealed proof

valid half prover committed messages and no signer messages revealed proof

valid no prover committed messages and no signer messages revealed proof

valid no prover commitment and half signer messages revealed proof

valid partial prover reveal messages and partial signer reveal with commitments revealed proof

valid partial prover reveal and commit messages and partial signer reveal proof

valid partial prover reveal and commit messages and partial signer reveal and commit proof

BLS12-381-SHAKE-256