Deciphering BBS+ Signatures

The BBS+ signature scheme is a pedersen commitment-based DSS that establishes the signer’s identity and reduces the risk of forgery.
Nov 15, 2021

In the physical world, you sign a document and become responsible for its contents, including the duties and liabilities entailed in it. While it’s possible to forge or duplicate these physical signatures, it’s not easy.

But what about the digital world?

The option to copy and paste signatures makes it a breeze to forge them. Hence, it became necessary to have Digital Signature Schemes (DSS) to establish the signer’s identity and to reduce the risk of forgery.

Broadly speaking, digital signature schemes have two components,

  • A private signing algorithm to securely identify the signer

  • A public verification algorithm to verify the authenticity of the signer.

Many digital signature schemes have these two components, and today, we’ll talk about one such signature schema — BBS+ Signatures.

This digital signature was created by Dan Boneh, Xavier Boyen, and Hovav Shacham using the strong Diffie-Hellman encryption technique, and hence the name BBS (after their respective surnames). The original signature was modified later to include proof of knowledge, and hence the name BBS+

What is the BBS+ Signature Scheme?

The BBS+ signature scheme is a DSS that can have two distinct parties, namely, the signer and the signature holder. Here the signature holder is the owner of a signature while the signer is the entity authenticating that the signature belongs to the holder.

Essentially, what happens is that the signature holder enters into a Pedersen commitment with the signer.

Before moving further, let’s digress a bit here to understand the Pedersen commitment as this is the building block of BBS+ electronic signatures.

Understanding the Pedersen Commitment

A Pedersen commitment is a scheme that allows a sender to commit to a secret value that can be revealed in the future. Until then, the sender transmits a commitment to preserve the secret.

Until the sender chooses, the secret remains private and can be revealed only when the sender displays a necessary parameter that’s agreed as a part of the commitment process. This commitment allows senders to commit to a ton of data in one-go and at the same time, it’s not possible for a hacker to access all of that data until the sender decides to reveal it. Let’s understand this with a simple example.

Let’s say, Bob creates a secret and sends a commitment of the secret to Alice. Here, the commitment can be a cryptographic value like a hash function or discrete logarithms, and this is stored by Alice. Remember, she doesn’t know Bob’s secret and can’t find out with the commitment value either.

In the future, Bob decides to reveal the secret, and Alice checks this secret against the commitment to verify that Bob hasn’t changed the secret.

Besides Bob and Alice, no one else knows about its existence.

Now, let’s extrapolate this Pedersen commitment to BBS+ signatures.

BBS+ Signatures and Pedersen Commitment

As mentioned above, BBS group signatures create the possibility for the signer and the signature holder to be two different entities, like Alice and Bob. The commitment is the connecting aspect, and the contents are blinded until the holder decides to reveal it.

Also, these signatures give complete control to the holder to decide when and what must be revealed, and follow the principles of Zero-Knowledge Proofs (ZKPs) where the holder can prove the required identity to another entity without having to reveal the identifiable data of the transaction.

BBS+Signatures in Verifiable Credentials

All these features make it a good DSS for implementing verifiable credentials. Also, a key advantage of BBS+ Signatures is that it allows a part of a verifiable credential to be shared with others.

For example, let’s say the issuer is a startup company that issues VCs containing the date of birth and address of the holder. Next, the holder wants to share the address with a verifier for a delivery process, so the holder can share a part of the VC (only the address) without sharing the date of birth. This is possible only when the verifiable credential is fragmented into multiple individual fields, each secured by a signature.

Here is an example of a VC implementation with BBS+ signature. { "@context": [ "", "", "" ], "@type": "Person", "firstName": "Jane", "lastName": "Does", "jobTitle": "Professor", "telephone": "(425) 123-4567", "email": "", "proof": { "type": "BbsBlsSignature2020", "created": "2020-04-25", "verificationMethod": "did:example:489398593#test", "proofPurpose": "assertionMethod", "proofValue": "F9uMuJzNBqj4j+HPTvWjUN/MNoe6KRH0818WkvDn2Sf7kg1P17YpNyzSB+CH57AWDFunU13tL8oTBDpBhODckelTxHIaEfG0rNmqmjK6DOs0/ObksTZh7W3OTbqfD2h4C/wqqMQHSWdXXnojwyFDEg==", "requiredRevealStatements": [4,5] } }

Each field in the VC, like the firstName, lastName, jobTitle, etc, is a separate signature and the holder has the option to pick one or more of these fields and include them in a verifiable presentation.

This example can be extended to any of the real-world VC use-cases and PoCs from Affinidi’s Hackathon.

In fact, this ability to share just the required information follows the principle of ZKP and is a secure way for the holder to safely share what’s required to the concerned verifier. At the same time, note that BBS+ signatures are not identical to ZKPs as there’s an option to fragment and reveal just some parts of the VC.

In this sense, BBS+ signatures are selective disclosures controlled completely by the holder where every field in the VC has a signature. Hence, the VC itself becomes a compilation of individual signatures, one for each field.

Affinidi’s Implementation of BBS+ Signatures

At Affinidi, we have implemented the BBS group signature schema on our tech stack to give holders the flexibility to build a presentation with only the required fields from a credential. These fragments are cryptographically verifiable as they are signed by the BBS+ signature.

With this, Affinidi supports both BBS+ and other states/keys that are identity-capable, so developers can decide which one to use. This opens a lot of opportunities for developers to use the signature keys that are most conducive for their business through our tech-stack.

Reach out to us on Discord to build VC-based applications using our tech stack.

Follow us on LinkedIn, Facebook, or Twitter. You can also join our mailing list to stay on top of interesting developments in this space.

The information materials contained in this article are for general information and educational purposes only. It is not intended to constitute legal or other professional advice.

Get an email whenever Affinidi Publishes!