Security and Privacy Self Review

[Wind4Greg]

Security and Privacy Self Review

This review is a Security and Privacy Self-Review for BBS Cryptosuite v2023 Securing Verifiable Credentials with Selective Disclosure using BBS Signatures which is a specific cryptosuite for use with the Verifiable Credential Data Integrity specification.

It should be noted that the following related specifications have recently undergone horizontal review and are now in the W3C Candidate Recommendation phase:

• Verifiable Credential Data Integrity
• Data Integrity EdDSA Cryptosuites v1.0
• Data Integrity ECDSA Cryptosuites v1.0

This is an additional cryptographic message securing mechanism that provides for selective disclosure and unlinkable proofs as explained in BBS Cryptosuite: Introduction.

When reviewing the Security and Privacy considerations, it is important to first be aware of the Security and Privacy Considerations for Verifiable Credentials:

• Verifiable Credential Security Considerations
• Verifiable Credential Privacy Considerations

and then consider the Security and Privacy considerations provided in the Verifiable Credential Data Integrity specification:

• Verifiable Credential Data Integrity Security Considerations
• Verifiable Credential Data Integrity Privacy Considerations

and then finally consider the Security and Privacy considerations of this cryptography suite.

Since the Verifiable Credential Data Integrity largely deals with the creation of digital proofs on JSON data, the responses will be focused on the data exposed via those digital proofs. To understand the additional privacy and security features provided by this specification one needs to keep the verifiable credential model of issuer, holder, and verifier in mind.

As compared to other signature schemes applied to verifiable credentials this scheme is more nuanced, i.e., what is sent from the issuer to holder is not the same as what is sent from the holder to verifier. When this specification applies the BBS signature scheme to verifiable credentials the digital proof sent from the issuer to the holder, called the base proof in this specification, makes use of a BBS signature. This is much different from the digital proof sent from the holder to a verifier, called a derived proof in this specification, and makes use of a BBS proof. A BBS proof is a "zero knowledge proof of knowledge of a signature" (ZKPKS) and has desirable unlinkability properties which are important for some use-cases.

The BBS signature scheme provides for both selective disclosure and unlinkable proofs. When used to provide unlinkable proofs care must be taken. This is detailed in the privacy considerations section of this specification using a layer approach based on an anonymity set model to provided tracking resistance in the cases of verifier-issuer and verifier-verifier collusion.

An example of example base proof attached to a document is shown below (from VC-DI-BBS: Signed base document test vector):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "@vocab": "https://windsurf.grotto-networking.com/selective#"
    }
  ],
  "type": [
    "VerifiableCredential"
  ],
  "credentialSubject": {
    "sailNumber": "Earth101",
    "sails": [
      {
        "size": 5.5,
        "sailName": "Kihei",
        "year": 2023
      },
      {
        "size": 6.1,
        "sailName": "Lahaina",
        "year": 2023
      },
      {
        "size": 7,
        "sailName": "Lahaina",
        "year": 2020
      },
      {
        "size": 7.8,
        "sailName": "Lahaina",
        "year": 2023
      }
    ],
    "boards": [
      {
        "boardName": "CompFoil170",
        "brand": "Wailea",
        "year": 2022
      },
      {
        "boardName": "Kanaha Custom",
        "brand": "Wailea",
        "year": 2019
      }
    ]
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0Cg9hAWFCTx6viP99IVmVLyFjmB7dlmvgrVkNAcxRUiEck7AHiU2CsSeOc8N92MVNTcwQsrtJWq-1ugYhOcaIVkP742-B-F33O3Yz-lORXTEq1GiK9-dhAWCAAESIzRFVmd4iZqrvM3e7_ABEiM0RVZneImaq7zN3u_4R4HS9jcmVkZW50aWFsU3ViamVjdC9zYWlsTnVtYmVyeBovY3JlZGVudGlhbFN1YmplY3Qvc2FpbHMvMXggL2NyZWRlbnRpYWxTdWJqZWN0L2JvYXJkcy8wL3llYXJ4Gi9jcmVkZW50aWFsU3ViamVjdC9zYWlscy8y"
  }
}

An example of example derived proof attached to a selectively document is shown below (from VC-DI-BBS: Signed derived document test vector):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    {
      "@vocab": "https://windsurf.grotto-networking.com/selective#"
    }
  ],
  "type": [
    "VerifiableCredential"
  ],
  "credentialSubject": {
    "sailNumber": "Earth101",
    "sails": [
      {
        "size": 6.1,
        "sailName": "Lahaina",
        "year": 2023
      },
      {
        "size": 7,
        "sailName": "Lahaina",
        "year": 2020
      }
    ],
    "boards": [
      {
        "year": 2022,
        "boardName": "CompFoil170",
        "brand": "Wailea"
      },
      {
        "boardName": "Kanaha Custom",
        "brand": "Wailea",
        "year": 2019
      }
    ]
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "bbs-2023",
    "created": "2023-08-15T23:36:38Z",
    "verificationMethod": "did:key:zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ#zUC7DerdEmfZ8f4pFajXgGwJoMkV1ofMTmEG5UoNvnWiPiLuGKNeqgRpLH2TV4Xe5mJ2cXV76gRN7LFQwapF1VFu6x2yrr5ci1mXqC1WNUrnHnLgvfZfMH7h6xP6qsf9EKRQrPQ",
    "proofPurpose": "assertionMethod",
    "proofValue": "u2V0DhNhAWQHAspxxmrqBA8cTxfrLqbaQkwrUWIFmRa3BpTslEBC8OxKNclgCOfZv9OlznihCV5TogbVzf7OrzgKyZV1Ps7q-vVFWhc51Z-q1vQE2DoExFQV2NXUJ2zCSlFadgi1W4cWBQgqK8pt8eYTVD9XHmgbWSiWG2ook6Tw3QtCfLA4k1_5IkZJ8f_5AjVY6ZPWGc3hnofAg90L8bqodN-2kJsnHVWbei-VIIvaXSfxGLIbKqvT59z7hsIcm83hDLjgjIqPMDofVsj_DY2S8XJTPuKMFvm-RK9cVLnpI1NQVccZT1Y5f6oqCOOBa6pEOW2LJ0VuNUnwNWfYZ-6tqh5mxzh2hPGUWwj7vwDskdnKHjDSUmUPgL0s5kROSdsiaAMTuZLvOVwIBrDUC-0dp5rhpkZMgrZ8xId_u7NspFM_H1KOGthU_VLGLQUh0Lse2bIHP8LHeiNLSmfNfL_gX-0Iv4Lv2W1zX3rk5oQzFJPCO_0bzG1Yxr70FUdmBbjL7Lku3IUznYTYFfBKY4qFhtewygPBTATCrlgBCbH5SHRuJOFCug89PIRmHyT86QcFrDLrCnl3PiOtliSUY9kPVwqzUiIBF1KYAAgEEAgcDBgQFBQCNAAECBQYHCAkKCw0OD4YDBAgLDA0"
  }
}

Note that the proofValue contains header information to differentiate between a base proof and derived proof. See serialize base proof value and serialize derived proof value.

2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

The information exposed to Web sites or other parties includes all the information in the proof structure attached to JSON data. The type, cryptosuite, and proofPurpose values just identify the type of cryptographic suite and purpose used and do not create privacy or security concerns (other than conveying that the entity that created the signature is capable of creating such a signature). The created date conveys when a particular signature was done and thus could indicate when a particular individual took an action to create or receive the digitally signed information. The verificationMethod could be used to uniquely identify the entity creating the digital proof across websites unless it is created in a pairwise manner.

The proofValue for a base proof, which is sent from an issuer to a holder, contains a deterministic digital signature (a BBS signature) and is essentially unique. This value is not disclosed by the holder. The proofValue for a derived proof, which is set from a holder to a verifier contains a BBS proof, a zero knowledge proof of knowledge of a signature (ZKPKS), and is statistically independent of the original signature, and multiple essentially independent values can be generated by the holder to prevent this value being used for tracking purposes across verifiers (unlinkability).

What information does your spec expose to the first party that the first party cannot currently easily determine.

If an individual consents to the release of data to the first party, or a first-party shares the data with a 3rd party without the individual's consent, the created date and verificationMethod could be seen as information that a first party could not easily determine until it was transmitted to them.

What information does your spec expose to third parties that third parties cannot currently easily determine.

If an individual consents to the release of data to the third party, or a first-party shares the data with a 3rd party without the individual's consent, the created date and verificationMethod could be seen as information that the third party could not easily determine until it was transmitted to them.

What potentially identifying information does your spec expose to the first party that the first party can already access (i.e., what identifying information does your spec duplicate or mirror).

None.

What potentially identifying information does your spec expose to third parties that third parties can already access.

If a third party is colluding with another third party, the created date and verificationMethod could be already known to a third party.

2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes. In addition, via its selective disclosure mechanism and unlinkability property this specification allows users(holders of verifiable credentials) more autonomy in minimizing data released and fingerprint area.

2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

The verificationMethod could be used to uniquely identify the entity creating the digital proof across websites unless it is created in a pairwise manner. In particular it can be resolved to the public keys of the issuer signing the credential.

The proofValue, used between holder and verifier contains a ZKPKS which if regenerated across origins (which is expected when unlinkability is desired) can be used to minimize tracking based on cryptographic artifacts. Overall advice on reducing tracking via various artifacts associated with a VC using BBS signatures is given in the privacy considerations section of the document which also references the privacy considerations of BBS signature scheme.

The expression of these features are mandatory; without them, the digital signature would not be verifiable.

2.4 How do the features in your specification deal with sensitive information?

The response to this question is the same as the response to 2.3.

2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?

In general, no, the technology is more general than specific use in web browsers, local storage, and in the same-origin / cross-origin security model for the Web. That said, if a proof is shared with an origin, the same tracking concerns raised in 2.3 apply.

2.6 Do the features in your specification expose information about the underlying platform to origins?

In general, no. If specific types of new cryptography are used, such as unlinkable signatures, then the capabilities of the underlying platform could be exposed to the origins. However, given that this capability (the ability to generate unlinkable signatures) is generalized, and any platform is capable of generating those classes of digital signatures, then it does not seem as if the exposure of that information to an origin is of deep concern.

2.7 Does this specification allow an origin to send data to the underlying platform?

These specifications allow origins to send digitally signed messages to an underlying platform, which would then process the digital signature or ZKPKS to ensure that it has not been tampered with. When processing these messages, the concerns in question 2.4 apply. That is, the origin's public key and digital signature or ZKPKS are exposed to the underlying platform which then uses that information to verify the Data Integrity proof.

2.8 Do features in this specification enable access to device sensors?

No.

2.9 Do features in this specification enable new script execution/loading mechanisms?

No.

2.10 Do features in this specification allow an origin to access other devices?

No.

2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No

2.12 What temporary identifiers do the features in this specification create or expose to the web?

The value of a digital signature (expressed in proofValue), or the identifier for a digital proof (expressed in id and previousProof), could be viewed as a temporary identifiers.

The proofValue field is the result of a cryptographic operation, and ranges in size from 64 bytes to many kilobytes and is unique enough to be used as a tracking identifier (if unlinkable digital signatures are not utilized).

The id and previousProof values are expected to be randomly generated, are expected to be at least 128-bits in size, and are therefore unique enough to be used as tracking identifiers if they are not re-generated for every digital proof (which is expected), or if a single digital signature is transmitted more than once (which is expected).

2.13 How does this specification distinguish between behavior in first-party and third-party contexts?

Not applicable.

2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

The features do not work any differently in Private Browsing or Incognito modees.

2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

Yes.

2.16 Do features in your specification enable origins to downgrade default security protections?

No.

2.17 How does your feature handle non-"fully active" documents?

No.

2.18 What should this questionnaire have asked?

The questionnaire focuses on the browser security model as well as interactive user agents for the Web. While it asks important questions related to that context, it is difficult to map data model security specifications to the questions. In particular we deal with the issuer, holder, verifier model and the privacy section of the specification is concerned with both verifier-verifier collusion/tracking which is very similar to the attacks posed by browser fingerprinting but we also deal with verifier-issuer collusion/tracking which is not brought up in the document and is more similar to the tracking inherent in federated identity systems.