Holder's Secret Key Management Device for VC Binding

USB Key which stores SecretKey for binding
Connection with a browser

1. Introduction:

In the ecosystem of Verifiable Credentials (VC) standardized by W3C, the integrity of the claims contained within a VC can be verified by third parties through the issuer’s signature. To ensure that a VC has indeed been issued to a specific entity, there is a mechanism called binding. This binding associates the VC with the Holder’s secret key, so that only the entity possessing this secret key can legitimately present the VC.

In this project, we implemented the binding functionality of VCs on physical hardware devices, more specifically in the form of a USB key, where the secret key is stored. This device executes cryptographic operations using the key as the binding functionality.

We built the device using the firmware of the open-source FIDO2-compliant authenticator, OpenSK. We extended this firmware to add the blind signature functionality of BBS signatures and a zero-knowledge proof for the knowledge of the secret key.

And these functions can be called from websites or native app!

2. Ecosystem of Verifiable Credentials:

The W3C[1] has established a standardized ecosystem for Verifiable Credentials that consists of three primary roles:

Issuer: The entity that creates and signs Verifiable Credentials using their private key. Issuers can be educational institutions, government agencies, or any authorized organization that issues credentials.
Holder: The entity that receives and stores Verifiable Credentials. Holders can selectively choose which attributes to disclose and present it as Verifiable Presentations (VP).
Verifier: The entity that receives and validates VPs. Verifiers use the Issuer's public key to verify the authenticity of the presented credentials.

Furthermore, by combining selective disclosure and unlinkability, a Holder can control which attributes they present to the Verifiers without linking them to previously presented VPs, which enhances privacy and allows users to have stronger control over their identities.

The typical process flow in this VC ecosystem proceeds as follows:

The Issuer creates a Verifiable Credential by signing it with their private key and issues it to the Holder
The Holder stores the credential and can create Verifiable Presentations by selecting specific attributes to share
The Verifier receives the Verifiable Presentation and verifies the signature using the Issuer's public key

CleanShot 2024-11-04 at 23 33 09@2x

Figure1: Overview of the VC ecosystem

3. Presentation Spoofing in VC and Linkability

Since the original VC ecosystem does not support binding between the issued VC and the Holder, there is a risk that the VC could be presented by someone other than the intended holder[2].

To verify the Holder's identity, an ID or public key can be included in the VC. When presenting the VP, the Holder reveals their public key–which is included in the VC–and proves ownership using their private key[3].

However, if the Holder reuses the same public key across multiple Verifiers, it enables these Verifiers to identify the Holder.

CleanShot 2024-11-04 at 23 33 24@2x

Figure 2: Spoofing in VC

4. Our implementation Strategy

To address presentation spoofing in VC, The Holder can utilize Blind Signatures. The Holder maintains their secret key, generates a commitment of the secret key and sends it to the Issuer. The Issuer then returns a Blind Signature of the commitment of the secret key. Subsequently, the Holder can present the Verifiable Presentation, including a Zero-Knowledge Proof (ZKP) that proves the possession of a valid secret key.

CleanShot 2024-11-04 at 23 33 35@2x

Figure 3: Approach Using Blind Signatures

However, a challenge arises as the Holder must manage their secret key in binding methods. This scenario presents two main challenges in secret key management:

The burden of secret key management
The risk of secret key leakage

To address these challenges, we implemented a USB key device to help VC Holders manage their secret keys securely, which performs binding operations within the device to mitigate secret key leakage. This device performs binding operations internally to prevent secret key leakage. Additionally, by storing the secret key and VC in separate locations, the system can prevent unintended VP presentations even if the wallet provider becomes compromised.

For our implementation, we extended the open-source FIDO authenticator firmware (OpenSK)[4]. Our USB key stores the VC Holder's secret key and generates commitments during VC issuance. It also supports zero-knowledge proofs of secret key ownership when presenting VPs.

CleanShot 2024-11-04 at 23 34 47@2x

Figure 4: USB key storing the VC Holder's secret key

We utilized CTAP which is standarized by FIDO2 Alliances for communication between USB Key and a browser, so these new functions can be called from any browser. So it helps a wallet to manage a secret key. We show this demo on the video.