diff --git a/draft-irtf-cfrg-bbs-signatures.md b/draft-irtf-cfrg-bbs-signatures.md index 41af543f..88ab328b 100644 --- a/draft-irtf-cfrg-bbs-signatures.md +++ b/draft-irtf-cfrg-bbs-signatures.md @@ -50,7 +50,7 @@ organization = "CryptID" .# Abstract -BBS is a digital signature scheme categorized as a form of short group signature that supports several unique properties. Notably, the scheme supports signing multiple messages whilst producing a single output digital signature. Through this capability, the possessor of a signature is able to generate proofs that selectively disclose subsets of the originally signed set of messages, whilst preserving the verifiable authenticity and integrity of the messages. Furthermore, these proofs are said to be zero-knowledge in nature as they do not reveal the underlying signature; instead, what they reveal is a proof of knowledge of the undisclosed signature. +This document describes the BBS Signature scheme, a secure, multi-message digital signature protocol, supporting proving knowledge of a signature while selectively disclosing any subset of the signed messages. Concretely, the scheme allows for signing multiple messages whilst producing a single, constant size, digital signature. Additionally, the possessor of a BBS signatures is able to create zero-knowledge, proofs-of-knowledge of a signature, while selectively disclosing subsets of the signed messages. Been zero-knowledge, the BBS proofs do not reveal any information about the undisclosed messages or the signature it self, while at the same time, guarantying the authenticity and integrity of the disclosed messages. {mainmatter} @@ -58,17 +58,15 @@ BBS is a digital signature scheme categorized as a form of short group signature A digital signature scheme is a fundamental cryptographic primitive that is used to provide data integrity and verifiable authenticity in various protocols. The core premise of digital signature technology is built upon asymmetric cryptography where-by the possessor of a private key is able to sign a message, where anyone in possession of the corresponding public key matching that of the private key is able to verify the signature. -The name BBS is derived from the authors of the original academic work of Dan Boneh, Xavier Boyen, and Hovav Shacham, where the scheme was first described. - -Beyond the core properties of a digital signature scheme, BBS signatures provide multiple additional unique properties, three key ones are: +Beyond the core properties of a digital signature scheme, the BBS signatures and proofs provide multiple additional unique properties. Three key ones are: **Selective Disclosure** - The scheme allows a signer to sign multiple messages and produce a single -constant size- output signature. A holder/prover then possessing the messages and the signature can generate a proof whereby they can choose which messages to disclose, while revealing no-information about the undisclosed messages. The proof itself guarantees the integrity and authenticity of the disclosed messages (e.g. that they were originally signed by the signer). -**Unlinkable Proofs** - The proofs generated by the scheme are known as zero-knowledge, proofs-of-knowledge of the signature, meaning a verifying party in receipt of a proof is unable to determine which signature was used to generate the proof, removing a common source of correlation. In general, each proof generated is indistinguishable from random even for two proofs generated from the same signature. +**Unlinkable Proofs** - The proofs generated by the scheme are zero-knowledge, proofs-of-knowledge of the signature, meaning a verifying party in receipt of a proof is unable to determine which signature was used to generate the proof, removing a common source of correlation. In general, each BBS proof is indistinguishable from random even if generated from the same signature. -**Proof of Possession** - The proofs generated by the scheme prove to a verifier that the party who generated the proof (holder/prover) was in possession of a signature without revealing it. The scheme also supports binding a presentation header to the generated proof. The presentation header can include arbitrary information such as a cryptographic nonce, an audience/domain identifier and or time based validity information. +**Proof of Possession** - The proofs generated by the scheme prove to a verifier that the party who generated the proof (holder/prover) was in possession of a signature without revealing it. The scheme also supports binding a presentation header to the generated proof. The presentation header can include arbitrary information such as a cryptographic nonce, an audience/domain identifier and or time based validity information (for more details on the presentation header, see (#header-and-presentation-header-usage)). -Refer to the (#use-cases) for an elaboration on situations where these properties are useful +Refer to the (#use-cases) for an elaboration on situations where these properties are useful. Below is a basic diagram describing the main entities involved in the scheme @@ -117,6 +115,10 @@ Figure: Basic diagram capturing the main entities involved in using the scheme **Note** The protocols implied by the items annotated by an asterisk are out of scope for this specification +The name BBS is derived from the authors of the original academic work by Dan Boneh, Xavier Boyen, and Hovav Shacham [@BBS04], where the scheme was first described as part of a group signatures protocol. Soon after, the scheme was described by Camenisch and Lysyanskaya as a stand-alone signatures scheme in [@CL04], for anonymous credentials applications. Later, Au, Susilo an Mu presented the first, provably secure version of BBS Signatures in [@ASM06]. Following, works by Camenisch, Drijvers and Lehmann [@CDL16] and by Barki, Brunet, Desmoulins and Traoré [@BBDT16], proved the security of the scheme in settings where more efficient computations are possible, thereby improving performance. Finally, in 2023, Tessaro and Zhu, presented in [@TZ23] further performance improvements, shrinking the BBS signature. This document is mainly based on that work. + +Note that the BBS Signature scheme is based on pairings and pairing friendly groups. This document will use elliptic curves for that purpose. This means that the BBS signatures scheme is not post-quantum secure. However, the privacy properties of BBS signatures are resilient even against an attacker utilizing quantum computer. See (#post-quantum-security-and-everlasting-privacy) for an elaboration of the security properties of the BBS Signatures scheme against quantum computers. + ## Terminology The following terminology is used throughout this document: @@ -148,11 +150,11 @@ generator signature : The digital signature output. -nonce -: A cryptographic nonce +header +: A payload chosen by the Signer and bound to a BBS signature, as well as the BBS proofs generated using that signature. presentation\_header (ph) -: A payload generated and bound to the context of a specific spk. +: A payload generated and bound to a specific BBS proof. dst : The domain separation tag. @@ -315,6 +317,12 @@ We also use strings in double quotes to represent ASCII-encoded literals. For ex Those rules will be used explicitly on every operation. See also [Serialize](#serialize). +### Header and Presentation Header Usage + +There are two special values defined by the BBS Scheme; the `header` and the `presentation_header`. The `header` value is chosen by the Signer and is bound to both a BBS signature and the BBS proofs generated using that signature. Specifically, the Prover is required to reveal the `header` to the proof Verifier, during every BBS proof presentation. As a result, the Signer SHOULD NOT include to the `header` any identifying information, that may have the potential of compromising the Prover's privacy. Suitable use cases taking advantage of the `header` value, are binding a BBS signature (and subsequent BBS proofs) to a specific application, deployment or domain, or binding the signature to specific sets of metadata etc.. + +Similarly, the Prover can choose a `presentation_header` value to be bound to the BBS proof (in contrast to the `header` value that is chosen by the Signer and is bound to both BBS proof and signature). Verifying a BBS proof will guarantee the authenticity and integrity of the `presentation_header`. This makes it suitable for applications where the Prover may want to "sign" a message in addition to creating their BBS proof, in a way similar to how group signatures may work. Specifically, the Verifier will know that the message included in the `presentation_header` was signed by a member of the group, where group here the Provers having received valid signatures from the specific Signer, but will not know from exactly which member of the group the message was signed. Another application of the `presentation_header` is to guarantee freshness of a BBS proof and to avoid replay attacks. An example of how this could be achieved, is by including a random value supplied by the Verifier to the `presentation_header` value. + ## Key Generation Operations ### Secret Key @@ -377,7 +385,7 @@ Procedure: ## BBS Signatures Interface -This section defines a BBS Signatures Interface (see (#interfaces)), that makes use of the core operations defined in (#core-operations), to perform the functions of signing and verifying the signature, as well as generating and validating the BBS proof. To create the generators (see (#generators)) it uses the `create_generators` operation defined in (#generators-calculation). Each inputted message is an octet string. To map the messages to scalars, it uses the `messages_to_scalars` operation defined in (#messages-to-scalars). +This section defines a BBS Signatures Interface (see (#interfaces)), that makes use of the core operations defined in (#core-operations), to perform the functions of signing and verifying the signature, as well as generating and validating the BBS proof. To create the generators (see (#generators)) it uses the `create_generators` operation defined in (#generators-calculation). Each inputted message is an octet string (see (#messages)). To map the messages to scalars, it uses the `messages_to_scalars` operation defined in (#messages-to-scalars). Generated signatures and proofs may optionally be bound to a header value. A BBS proof may additionally be bound to a presentation header value. See (#header-and-presentation-header-usage) for more details on the header and presentation header usage. ### Signature Generation (Sign) @@ -462,7 +470,7 @@ Procedure: The ProofGen operation creates BBS proof, which is a zero-knowledge, proof-of-knowledge, of a BBS signature, while optionally disclosing any subset of the signed messages. Validating the proof (see ProofVerify defined in (#proof-verification-proofverify)) guarantees authenticity and integrity of the header and disclosed messages, as well as knowledge of a valid BBS signature. -Other than the Signer's public key (PK), the BBS signature, the header and the messages, the operation also accepts a presentation header value, that will be bound the the resulting proof (see(#presentation-header-selection)). To indicate which of the messages should be disclosed, the operation accepts a list of integers in ascending order, representing the indexes of those messages +Other than the Signer's public key (PK), the BBS signature, the header and the messages, the operation also accepts a presentation header value, that will be bound the the resulting proof (see (#header-and-presentation-header-usage)). To indicate which of the messages should be disclosed, the operation accepts a list of integers in ascending order, representing the indexes of those messages ``` proof = ProofGen(PK, signature, header, ph, messages, disclosed_indexes) @@ -686,7 +694,7 @@ Procedure: ### CoreProofGen -This operation computes a zero-knowledge proof-of-knowledge of a signature, while optionally selectively disclosing from the original set of signed messages. The "prover" may also supply a presentation header, see [Presentation header selection](#presentation-header-selection) for more details. Validating the resulting proof (using the `ProofVerify` algorithm defined in (#proof-verification-proofverify)), guarantees the integrity and authenticity of the revealed messages, as well as the possession of a valid signature (for the public key `PK`) by the prover. +This operation computes a zero-knowledge proof-of-knowledge of a signature, while optionally selectively disclosing from the original set of signed messages. The "prover" may also supply a presentation header (see (#header-and-presentation-header-usage) for more details). Validating the resulting proof (using the `ProofVerify` algorithm defined in (#proof-verification-proofverify)), guarantees the integrity and authenticity of the revealed messages, as well as the possession of a valid signature (for the public key `PK`) by the prover. The `ProofGen` operation will accept that signature as an input. It is RECOMMENDED to validate that signature, using the inputted public key `PK`, with the `Verify` operation defined in (#signature-verification-verify). @@ -1624,7 +1632,7 @@ For certain types of message values, set membership proofs (for example, [@VB22] ## Validating Public Keys -It is RECOMENDED for any operation in [Core Operations](#core-operations) involving public keys, that they deserialize the public key first using the [OctetsToPublicKey](#octetstopublickey) operation, even if they only require the octet-string representation of the public key. If the `octets_to_pubkey` procedure (see the [OctetsToPublicKey](#octetstopublickey) section) returns INVALID, the calling operation should also return INVALID and abort. An example of where this recommendation applies is the [Sign](#sign) operation. An example of where an explicit invocation to the `octets_to_pubkey` operation is already defined and therefore required is the [Verify](#signature-verification-verify) operation. +Note that all core operations as defined in (#core-operations) expect the Signer's public key as input. It is RECOMMENDED for all those operations, that they deserialize the public key first using the `octets_to_pubkey` procedure defined in (#octets-to-public-key), even if they only require the octet-string representation of the public key. If the `octets_to_pubkey` procedure returns INVALID, the calling operation should also return INVALID and abort. This recommendation applies is the `CoreSign` ((#coresign)) and `CoreProofGen` ((#coreproofgen)) operations. An explicit invocation to the `octets_to_pubkey` operation is already defined and therefore required in the `CoreVerify` ((#coreverify)) and `CoreProofVerify` ((#coreproofverify)) operations. ## Point Deserialization @@ -1640,21 +1648,7 @@ Some existing implementations skip the subgroup\_check invocation in [Verify](#s ## Side Channel Attacks -Implementations of the signing algorithm SHOULD protect the secret key from side-channel attacks. One method for protecting against certain side-channel attacks is ensuring that the implementation executes exactly the same sequence of instructions and performs exactly the same memory accesses, for any value of the secret key. In other words, implementations on the underlying pairing-friendly elliptic curve SHOULD run in constant time. - -## Randomness Considerations - -The IKM input to KeyGen MUST be infeasible to guess and MUST be kept secret. One possibility is to generate IKM from a trusted source of randomness. Guidelines on constructing such a source are outside the scope of this document. - -Secret keys MAY be generated using other methods; in this case they MUST be infeasible to guess and MUST be indistinguishable from uniformly random modulo r. - -BBS proofs are nondeterministic, meaning care must be taken against attacks arising from using bad randomness, for example, the nonce reuse attack on ECDSA [@HDWH12]. It is RECOMMENDED that the presentation header used in this specification contain a nonce chosen at random from a trusted source of randomness, see the (#presentation-header-selection) for additional considerations. - -When a trusted source of randomness is used, signatures and proofs are much harder to forge or break due to the use of multiple nonces. - -## Presentation Header Selection - -The signature proofs of knowledge generated in this specification are created using a specified presentation header. A verifier-specified cryptographically random value (e.g., a nonce) featuring in the presentation header provides strong protections against replay attacks, and is RECOMMENDED in most use cases. In some settings, proofs can be generated in a non-interactive fashion, in which case verifiers MUST be able to verify the uniqueness of the presentation header values. +There are two places where side channel attacks could be relevant in the BBS Signatures scheme. First, against the Signer, where side channel leakage during signature generation could reveal their secret key. Second, against the Prover, where a side channel attack could be used during proof generation to either directly reveal the udnisclosed messages and signature value, or reveal the random scalars used, leading again to the leakage of the undisclosed messages or the hidden signature. Therefore, implementations MUST apply proper side channel attack protection. One method to achieve this, is by using elliptic curve implementations that execute curve operations in constant time. ## Implementing hash\_to\_curve\_g1 @@ -1664,17 +1658,15 @@ In addition, ciphersuites MUST specify unique domain separation tags for hash\_t ## Choice of Underlying Curve -BBS signatures can be implemented on any pairing-friendly curve. However care MUST be taken when selecting one that is appropriate, this specification defines a ciphersuite for using the BLS12-381 curve in (#ciphersuites) which as a curve achieves around 117 bits of security according to a recent NCC ZCash cryptography review [@ZCASH-REVIEW]. - -## ProofGen Security - -The proof, as returned by ProofGen, is a zero-knowledge proof-of-knowledge [@CDL16]. This guarantees that no information will be revealed about the signature itself or the undisclosed messages, from the output of ProofGen. Note that the security proofs in [@CDL16] work on type 3 pairing setting. This means that G1 should be different from G2 and with no efficient isomorphism between them. +BBS signatures can be implemented on any pairing-friendly curves suitable for type 3 pairing computations. However care must be taken when selecting one that is appropriate, to guarantee the desired security level for the targeted application. This specification defines a ciphersuite for using the BLS12-381 curve in (#ciphersuites) which as a curve achieves around 117 bits of security [@ZCASH-REVIEW]. ## Randomness Requirements -[ProofGen](#proof-generation-proofgen) is by its nature a randomized algorithm, requiring the generation of multiple uniformly distributed, pseudo random scalars. This makes ProofGen vulnerable to bad entropy in certain applications. As an example of such application, consider systems that need to monitor and potentially restrict outbound traffic, in order to minimize data leakage during a breach. In such cases, the attacker could manipulate couple of bits in the output of the `get_random` function to create an undetected chanel out of the system. Although the applicability of such attacks is limited for most of the targeted use cases of the BBS scheme, some applications may want to take measures towards mitigating them. To that end, it is RECOMMENDED to use a deterministic RNG (like a ChaCha20 based deterministic RNG), seeded with a unique, uniformly random, single seed [@!DRBG]. This will limit the amount of bits the attacker can manipulate (note that some randomness is always needed). +The `key_material` input to the `KeyGen` operation defined in (#secret-key) MUST be infeasible to guess and MUST be kept secret. One possibility is to generate the `key_material` from a trusted, cryptographically secure pseudo random function [@!RFC4086]. Secret keys MAY be generated using other methods; in this case they MUST be infeasible to guess and MUST be indistinguishable from uniformly random modulo r. + +The `ProofGen` operation defined in (#proof-generation-proofgen) is by its nature a randomized algorithm, requiring the generation of multiple uniformly distributed, pseudo random scalars. This makes `ProofGen` vulnerable to attacks caused by bad entropy (like the ones described in [@HDWH12]). If randomness is re-used or is in any way predictable or maliciously constructed, an adversary may be able to unveil the undisclosed from the proof messages or the hidden signature value. More subtle attacks are also possible, where the security properties of the BBS proof may not be broken, but a system making use of the BBS scheme may still be compromised. As an example, consider systems that need to monitor and potentially restrict outbound traffic, in order to minimize data leakage during a breach. In such cases, the attacker could manipulate couple of bits in the output of the `get_random` function ((#parameters)) to create an undetected chanel out of the system. Although the applicability of such attacks is limited for most of the targeted use cases of the BBS scheme, some applications may want to take measures towards mitigating them. To that end, it is RECOMMENDED to use a deterministic RNG (like a ChaCha20 based deterministic RNG), seeded with a unique, uniformly random, single seed [@!DRBG]. This will limit the amount of bits the attacker can manipulate (note that some randomness is always needed). -In any case, the randomness used in ProofGen MUST be unique in each call and MUST have a distribution that is indistinguishable from uniform. If the random scalars are re-used, are created from "bad randomness" (for example with a known relationship to each other) or are in any way predictable, an adversary will be able to unveil the undisclosed from the proof messages or the hidden signature value. Naturally, a cryptographically secure pseudorandom number generator or pseudo random function is REQUIRED to implement the `get_random` functionality. See also [@!RFC8937], for recommendations on generating good randomness in cases where the Prover has direct or in-direct access to a secret key. +In any case, the randomness used in ProofGen MUST be unique in each call and MUST have a distribution that is indistinguishable from uniform. If the random scalars are re-used, created from "bad randomness" (for example with a known relationship to each other) or are in any way predictable, the undisclosed messages or the signature value may be compromised. Naturally, a cryptographically secure pseudorandom number generator or pseudo random function is REQUIRED to implement the `get_random` functionality. See [@!RFC4086] for guidance on implementing such functionality. See also [@!RFC8937], for recommendations on generating good randomness in cases where the Prover has direct or in-direct access to a secret key. ## Mapping Messages to Scalars @@ -1682,6 +1674,7 @@ In an application using BBS Signatures, there are 2 places where messages could To allow for re-usability of software, it is RECOMMENDED that application specific processing (like UTF-8 encoding [@RFC3629], Base-64 decoding [@RFC4648] etc.,) should happen before messages are passed to the BBS Interface operations. In those cases, the application should ensure that all protocol participants have a clear and consistent understating for which method should be used to process a message. This can be achieved by associating specific Interfaces (with unique `api_id` values, see (#defining-new-interfaces)) or unique header values (see (#signature-generation-sign)) with different pre-processing methodologies. +<<<<<<< HEAD Note that the BBS Interface defined in this document (see (#bbs-signatures-interface)) only accepts messages that are represented as octet strings. However, in some more advanced applications, like the ones using range proofs ([@BBB17]) to prove that a signed message is within some range (without disclosing that message), the pre-processing of messages may result to some of them being mapped to scalar values, before they are passed to the BBS Interface (for example, an application could use [@ISO8601] to represent dates as integers etc.,) that should directly be signed (e.g., to not be further processed by `hash_to_scalar`). If a BBS Interface accepts both octet strings and scalar values as messages, where depending on the message's type different operations will be used to map it to a scalar (e.g., `hash_to_scalar` for octet strings and the identity operation for scalars), it must still ensure that the properties described in (#define-a-new-map-to-scalar) holds. To that end, the application MUST ensure that it is clear to all participants, which message should be considered an octet string and which a scalar. @@ -1692,6 +1685,12 @@ If the application defines that the first (or last) `n` messages will be scalars In any case, the privacy considerations described in (#privacy-considerations) MUST not be violated, for example, by using unique pre-processing rules or maps between message index and type. To validate the consistency of the message processing rules, the Prover could use mechanisms like the ones described in [@I-D.ietf-privacypass-key-consistency]. +## Post-quantum Security and Everlasting Privacy + +The BBS Signatures scheme has two main security properties; unforgeability of BBS signatures and zero-knowledge of BBS proofs. The first property, referring to the inability of anyone other than the Signer to be able to generate BBS signatures, does not hold true against an adversary using a strong enough quantum computer. Specifically, such a computer could be used to reveal the Signer's secret key from their public key, hence giving them the ability to generate BBS signatures on behalf of that Signer for any message they want. + +On the other hand, the second security property, i.e., the zero-knowledge of the BBS proof, cannot be broken, even by utilizing a quantum computer. We refer to this property as "everlasting privacy". This guarantees that an adversary in possession of a quantum computer, will not be able to reveal neither the messages undisclosed by a BBS proofs, nor the hidden signature value. As a result, the privacy and hiding properties of the BBS proofs that are currently used, will not be compromised by future quantum-attacks. + # Ciphersuites This section defines the format for a BBS ciphersuite. It also gives concrete ciphersuites based on the BLS12-381 pairing-friendly elliptic curve [@!I-D.irtf-cfrg-pairing-friendly-curves]. @@ -3087,6 +3086,46 @@ To sum up; in order to validate the proof, a verifier checks that `e(Abar, PK) = + + + Signature Schemes and Anonymous Credentials from Bilinear Maps + + + + + + + + + + + + + Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials + + Orange Labs + + + Orange Labs + + + Orange Labs + + + Orange Labs + + + + + + + + + U-Prove Cryptographic Specification V1.1 Revision 5 + Microsoft Research + + + Constant-Size Dynamic k-TAA