Reducing Correlation in Verifiable Credentials without ZKP

From IIW

Reducing Correlation In Verifiable Credentials Without ZKP

Session: 12C

Convener: Rory Martin (Workday)

Notes-taker(s): Nikhil Wadwa, Gabe Cohen

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Rory giving overview:

These are topics we are considering but not actively developing

VCs are claims with provenance - Emerging WC standard

Workday credentials platform is a Verifiable Data Registry

The proof is signed by a key defined on issuers DID document

The credentials themselves are not the blockchain - only the public key infrastructure and the revocations are on the blockchain

There could be collusion between verifiers to aggregate data and gather extra information about the holder

Generating new identity for every credential - if the private key is lost, one may not be able to access / control the identity anymore - but it reduces correlation

BIP32 protocol: Can be used to create an “extended public key”, and one can create the corresponding Private key by using the master private key - and the index of the corresponding public key

  • Then only the master private key needs to be backed up

Key exposure risk can be reduced by using Hardened keys

Good security practice: Protect the master key by using a hardened child key

We need to create a stronger identity and reduce the risk of fraud

If multiple people hold a private key, they could utilize the benefits of that private key - however there is an increased risk of fraud for the verifier


rouven Question: what happens if the master key is lost or compromised:

Rory: We backup the master key / private key - encrypted - as a service for the wallet

rouven: Hypothesis is that we are moving towards hardware based keys

Rory: We use secure enclave to encrypt the keys

venu reddy question: are we holding keys on the holder side?

Rory: yes

Venu: How to aggregate credentials

Rory: the VC could be issued to a public key and not a DID

malwhere: a linked secret is a random number correlated to multiple DIDs. Also how does that solve correlation

Rory: The correlation we are solving is that the same credential doesn't get shared across verifiers If we shared the same correlation to different verifiers they could collude - we reduce correlation but not completely solve it - the only correlateable attribute is the id.

Brent : BIP32 adds a lot of complexity. Why are we adding so much complexity, rather than support a signature that uses ZKPs?

Rory: WD does not use ZKPs because its hard to explain how they work and they won't be accepted in all transaction environments, e.g. government environments

Kendra: ZKPs arent approved for a lot of customers

Brent: BBS+ provides blinded signatures to hide attributes

Margo: Thanks for philosophical point about reducing bad correlation

Malwhare: ZKPs are not 100% anonymous but they give the choice of what to reveal

Rory: We are trying to be flexible and reduce correlation. We aren't trying to solve all levels of correlation - e.g. IP addresses based - we are trying to reduce correlation

David: Do you seek informed consent from users that they will be exposed to correlation? Data aggregates reduce the cost of selling data if you submit new data. if you disclose anything that is PII, they will toss the data into the global data market. There is a reasonable expectation of privacy for non-technical users. “Informed Consent”

Rory: From WD perspective all of our credentials are going to have PII that is correlatable - when we talk about informed consent - could we implement this via contractual obligations - we could also inform customers about how data is being used. WD will not be selling / aggregating that data. ZKPs do solve this from a tech standpoint - but we could also solve this from a business standpoint

Keith: We do full disclosure to the user about how they use the data and we can have terms and conditions as Rory said

Oliver: ZKPs arent fully understood

Problem being solved: correlation across verifiers

  • If all creds issued to a single identifier, verifiers can collude and aggregate data
    • Risk of selling data to a 3rd party
    • Creds not stored on blockchain, only PKI + revocation list
  • The act of sharing a cred is privacy eroding (conveys info about the holder)
  • Correlatable fields on creds:
    • Credential ID
    • Credential subject (DID)
    • Claims with PII (like a name)

Solution? Multiple identities (pseudonyms)

  • Generate a new identity per cred
    • Pros:
      • reduce correlation x-verifiers that received different creds
    • Cons:
      • Increase # of private keys that need to be backed up
        1. of identities grows with # of creds

BIP32 Hierarchical Deterministic Keys (HD Keys) (http://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)

  • New identities based on master keyset

How does Bitcoin deal with this problem?

  • Accounts are public keys
  • BIP32 is an alg for dynamically generating a tree of keys
  • Hierarchical keys come in two forms: soft and hard
  • Each private key can generate a new child key
  • Each public key can generate a new soft child key
  • A hierarchical wallet can generate a new pub key without holding private keys
  • Only need to back up master key

Vulnerability: not secure for sharing private keys

  • Sharing of a soft private key and any extended pub keys in the hierarchy can lead to exposure of all private keys in the hierarchy
  • Extended pub keys (public keys + chain code) need to be secured better than standard pub keys

Hardened keys act as firewalls by limiting the ability to derive private keys back up the hierarchy Best practices dictates that the first key of a master key needs to be a hardened child key BIP32 + VCs

  • Holder register their master pub key to the blockchain
  • Master will be protected by a hardened child key, which will be used to derive all other child keys
  • Verifiable data registry will generate a unique child pub key and associated DID for each cred issuance, based on the *credential ID (uuid)
  • ISsuer will use that child DID as the “id” field on the credentialSubject block
  • Holder will generate the associated DID Doc on the fly when they need to share the cred w/ a verifier
  • The holder only needs to backup their master private key

Workday’s cred IDs are UUID-4 (128 bits of randomness) Each private key in the hierarchy can have 2B soft child keys In order to have sufficient distribution in child DIDs to ensure that they will not collide, we will need to derive ..


Result: A stronger identity using BIP32 Identity is more than an identifier-- it’s the accumulation of all claims attributed to it; therefore splitting the identity into many independent fragments which has consequences With small identity fragments, risk of sharing the underlying private key is minimized Sharing private keys reduces trust x-system, since claims made about one person can be fraudulently verified against another Sec vuln of BIP32 maintains risk in sharing private keys and therefore increases trust in the validity of a cred

Rouven: how do you handle lost private keys?

Rory: we only have single keys that represent your DID (right now), and we back it up with a password, encrypted as a service with our wallet. can download and recover if you have the pw to unlock your key. similar loss scenario to a master link secret

Rouven: who is storing it? who has access to it? in this case, it’s practical to have a trusted wallet, but not very self sovereign. we have DID because they are a KMS. if I create 100 keys to a 100 DIDs, or creds, then I have to rotate … a single public DID is simpler to manage in terms of rotations, re-issuance, etc. Hypothesis - moving towards keys more in hardware, less moving around. Direction is to use hardware to do encryption

Rory: we do use secure enclave keys to encrypt wallet, but they are not transferable between devices

Venu Reddy: keys are on the holder side? not issuer side? how would you use this information - proof from multiple creds?

Rory: we can ditch DID Docs, and issue creds to pub keys. if you can prove ownership of priv key, you prove ownership over the cred. DID Doc -- key profile over pub key (can be rotated, multiple keys). HD keys -- Verifiable Data Registry holds extended key, and can derive keys for you, but needs a deterministic way to do it. Generates a UUID -> path -> pub key. HD key doesn’t have a DID Doc which makes it easy to back up but hard to rotate

Malwhere: Link secret is not a master key or master secret. Link secret is a random attr you stick in every cred, similar to a DID. Random number, not a DID. How does this solve correlation? The signed data is not changed with BIP32. The data has to change every time you present, including the signature. Otherwise it’s a unique identifier. DID, signature, everything would have to change per-presentation to reduce correlation. BIP32 alone doesn’t reduce correlation.

Rory: Apologies for misrepresentation of linked secret, unaware of workings. Specified correlation we are trying to reduce -- sharing same credential with multiple verifiers. Any data (like the proof) is correlatable, but not a correlation problem we are trying to solve. Trying to solve different creds with different verifiers, they won’t be able to create a master data set.

Malwhere: They still can create a master data set? Any data that is the same can be correlatable.

Rory: Varying levels of correlation. Same cred to two different verifiers, they can recognize they got the same cred from the same holder...but they can’t correlate across credentials. If you had 1000 creds and shared with all different verifiers, no one can come up with a full dataset from collusion. The only truly correlatable ID is the cred subject (ID). Agree it does not solve all correlation.

Brent: Added a lot of complexity...why not use a ZKP signature?

Rory: Above my paygrade. Don’t think they’d be accepted by all txns we use. Govt transactions, not a standard that’s adopted. Hard to explain to customers. We are using Ed25519 signatures. Need to be FIPS complaint Margo: thanks for bringing up the functional side of things. not all correlation is bad

Malwhere: “not the right excuse” re:FIPS. Not 100% anonymous

Rory: Not disputing. We are working within the bounds of Ed key

Keith Kowal: We are sharing names, skills, and directly correlatable attrs in the creds.

Brent: I applaud efforts to reduce correlation. Wish they went further (as some people would prefer).

David Huseby: Do you seek informed consent?

Rory: what can we contractually limit? abide by certain standards on signup

DH: How to square with CCPA? Share with entire possible chain and get consent. Are you building that in?

Rory: Contacts as we can. …. Malwhere: Never said ZKPs don’t leak everything…

Oliver Terbu: ZKP not really well understood by customers in our experience. Even people using Indy not clear on it. Still like and see value in ZKP.

Retrieved from "https://iiw.idcommons.net/index.php?title=Reducing_Correlation_in_Verifiable_Credentials_without_ZKP&oldid=22916"