Support for Hierarchical Deterministic Keys (HDK)

[sander]

Hi OpenID4VCI authors! With a cross-pilot working group we’re specifying Hierarchical Deterministic Keys (HDKs) for the European Digital Identity Wallet. Let’s discuss how we could make HDK work with OpenID4VCI.

An HDK is a key deterministically derived from parent key material, and bound to a wallet secure cryptographic device (WSCD) using key blinding. A wallet instance could derive an HDK either locally, just using a static seed and path, or remotely, additionally using a key handle provided by another component. Remote key derivation is implemented using Asynchronous Remote Key Generation (ARKG). By construction, the wallet instance and optional remote party know that child keys are bound to the same WSCD (if any) as their parent key.

This design should offer several advantages to the ecosystem:

• Issuers can rely on WSCD binding without processing additional personal metadata, such as issuer trust evidence or proof of association.
• Wallet users only need to create a single proof of possession using the WSCD to enable issuers to regularly issue fresh batches of single-use credentials.
• Wallet solutions can efficiently deploy off-the-shelf WSCD solutions that support protecting a single ECDH or EC-SDSA key, and implement the rest in (mobile) wallet instance software.

Locally derived keys are opaque to issuers, so can be considered just an optimisation for wallet solution design. Remotely derived keys have some consequences for OpenID4VCI applications:

1. To request remote key derivation, the client provides an ARKG public seed (pk_kem, pk_bl), where pk_kem is a KEM public key and pk_bl is an asymmetric key blinding public key (the key to derive from).
2. To respond with remotely derived keys, the issuer associates with each credential an AKRG key handle, which is an opaque byte string. This key handle should not be part of the credential itself, to avoid sharing metadata with relying parties.
3. A single ARKG public seed may be used to issue many credentials, potentially in several batches. These credentials have the same configuration and dataset, but distinct cryptographic material derived using ARKG. The credentials do not need to be delivered in a particular order.
4. When ARKG is applied, the credential to be issued does not contain the same public key as the proof of possession, but a key derived from it.
5. When ARKG is applied, the proof of possession may be implicit. For example, the issuer may have authenticated the user with PID, and remotely derive public keys from the presented PID-bound public key.

As of d5ed198, it looks like OpenID4VCI does not yet fully support these features. As @paulbastian suggested in a recent HDK call, we could define a new proof type.

My first suggestion would be:

• Add an hdk proof type with an associated object containing elements:
  • seed: REQUIRED. An ARKG public seed represented as base64url-encoded COSE_Key structure.
• Add an optional Credential Response parameter array key_handles containing base64url-encoded ARKG key handles in the same order as the associated entries in the credential or credentials parameter.
• Specify how the issuer may indicate to the user that for a given hdk.seed, a proof of possession needs to be given of the key associated with the BL public key – and hence with the WSCD, if any. Does invalid_proof meet this use case?

What do you think?

[jogu]

Hi @sander

Thanks for working on this! I'm one of the co-chairs of the DCP WG group (the other chairs being Kristina & Torsten).

We don't seem to obviously have a contribution agreement from you or your company - unless you already completed one in the last few days, can you please complete one via the docusign process on https://openid.net/intellectual-property/openid-foundation-contribution-agreements/ ? This is a necessary step for anyone that wants to contribute to an OpenID Foundation specification, so it may be something you want to mention to other members of your working group that might get involved in adding this to the VCI spec.

In principle your proposal seems to make sense (although I am not qualified to comment on any of the cryptographic details).

I suspect a sensible next step might be to try and arrange for some members of your working group to join a DCP WG call and give the working group members a briefing on your specification. The WG call schedule is on https://openid.net/wg/digital-credentials-protocols/ - we have two different time slots (one is "EU friendly", one APAC-ish friendly), we may need to do this in both time slots (or perhaps do it in one and record it). Probably the earliest we could think about doing this is 11th July, and we should avoid week of 22nd July as IETF is that week.)

[sander]

Thanks @jogu! I’ve just signed the contribution agreement. The 11th July EU Call should work for me, I’ll also check with other working group members.

[jogu]

Great, thanks. Just for clarity we'll also need to confirm we have the right people on our side available that day too.

[paulbastian]

Hi @sander , I already opened an Issue for this discussion a week ago here: #355 which is kind of adjacent

[sander]

Thanks @paulbastian, this is indeed closely related and should be aligned. Note that with HDK:

• the Wallet Provider would not attest the optional device_keys, but just the cnf key to ensure the Wallet Provider does not learn the derived public keys as correlation handles;
• the Wallet Instance extends the cnf key into an ARKG public seed, without involvement of the Wallet Provider, so this will not be part of the WTE/ITE;
• (Q)EAA Providers typically do not need ITE if they have already verified some PID and trust that its PID Provider has authenticated the WSCD (which PID Providers may be legally required to do?), reducing:
  • reliance on Wallet Provider availability;
  • risk of tracking users between Wallet Providers and (Q)EAA Providers.

[sander]

Great, thanks. Just for clarity we'll also need to confirm we have the right people on our side available that day too.

@jogu should we still meet tomorrow? I could also do next week if it works better.

[Sakurann]

Could we do this discussion after IETF, the week of July 29th? @paulbastian is on vacation next two weeks and I think it would be better to have him on the call.

Also, is there any implementation experience on the approach being proposed in this issue?

[c2bo]

This sounds like John should be there as well imho - If I recall correctly we had some initial discussions in this/a similar direction at an IIW with him?

[sander]

I’ll join the Thu Aug 1 meeting at 17:00 CEST as discussed, hopefully together with some more HDK working group members such as @ve7jtb. For the briefing, I could present an extract of the HDK slide deck, highlighting the points in this issue’s opening post.

The main objectives would be to:

• align on idiomatic application and/or extension of OpenID4VCI to convey:
  • a single ARKG public seed from the holder to the issuer;
  • optional proof of possession of the asymmetric key blinding public key in the ARKG public seed;
  • one or more ARKG key handles from the issuer to the holder;
• raise awareness that HDK remote derivation may address some problems in Issuer Trust Evidence / key attestations for OpenID4VCI #355.

[sander]

To further detail some Q&A from today’s call:

• Are the ARKG authors involved? Yes, they contribute to the informal working group. We collaborate on impact to the ARKG draft and share interest in application to OpenID4VCI.
• Where to standardise HDK? While the current community specification can already be reviewed and applied, we likely want to contribute to CFRG for cryptographer review, the IPR process, and the open publishing channels.
• Has the cryptography been reviewed? It is currently based on elliptic curve cryptography and SHA-2 hashing. The general approach has been validated in cryptocurrency systems, and reviewed for digital identity applicability in ETSI TR 119476 v1.2.1. The detailed solution components that require security review:
  • Local derivation is an application of BIP32 primitives, to review at e.g. CRFG
  • Remote derivation is an application of ARKG, Internet-Draft for CFRG
    • See Informative References for security proofs of additive blinding
    • Multiplicative blinding is work in progress: Multiplicative blinding with ARKG sander/hierarchical-deterministic-keys#7
  • Central blinded proof-of-possession is an application of KBSS, Internet-Draft for CFRG
  • Distributed blinded proof-of-possession is an application of threshold signatures and/or multiple-ECDH, threats are well-known, application to review at e.g. CFRG
• Does HDK address Issuer-Verifier collusion? (@David-Chadwick) No, HDK just aims to solve collusion based on proof-of-possession keys. A credential scheme applying HDK could address Issuer-Verifier collusion however. For example, HDK proof-of-possession keys could be combined with BBS+ issuer signatures as in BBS#. In this case, the issuer signature and the signed attributes will not be a correlation handle between issuers and verifiers. Note that for the EU Digital Identity context, BBS+ issuer signatures would require issuer HSM support as detailed in: Cryptographers' Feedback on the EU Digital Identity’s ARF eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework#211 (comment)

[paulbastian]

Here are some sketches of how these mechanism could be applied to OpenID4VCI:

Given that we only use local derivation, the flow would be:

• a key attestation/ITE would only include one key
• a Wallet could provide the key attestation and add N locally derived keys and a proof of association that these new keys are derived from the attested key
• an Issuer checks key attestation/ITE and issues N credentials bound to N keys

Benefits:

• issuance of key attestations from the Wallet Provider does not require user authentication
• reissuance of credentials (a new batch) with a refresh token would not require user authentication
• unlinkability between Wallet Provider and RP

This could work well with a new proof type and is easy to integrate today:

{
  "credential_identifier": "CivilEngineeringDegree-2023",
  "proofs": {
    "hdkeys": {
       "ite" : "..." //ite attestation with only 1 key + optional proof
       "keys" : [
         {
           "key": "eyJ0eXAiOiJvcGVuaWQ0dmNpL...Lb9zioZoipdP-jvh1WlA",
           "poa": "..."
         },
         {
           "key": "eyJraWQiOiJkaWQ6ZXhhbXBsZ...KPxgihac0aW9EkL1nOzM",
           "poa": "..."
         }
      }
    ]
  }
}

[paulbastian]

Given that we only use remote derivation, the flow would be:

• a key attestation/ITE would only include one key
• a Wallet could provide the key attestation and a public key seed to the issuer
• an Issuer checks key attestation/ITE, derives new public key and issues N credentials bound to N keys + N key handles
• Wallet receives credentials and gets the associated private keys from the key handles

Benefits:

• issuance of key attestations from the Wallet Provider does not require user authentication
• reissuance of credentials (a new batch) with a refresh token would not require user authentication
• resissuance of credentials can be precalculated without a Credential Request, which is nice for load balancing
• unlinkability between Wallet Provider and RP

This has some challenges for integration in OpenID4VCI, as we also have to change the Credential Response.
Credential Request:

{
  "credential_identifier": "CivilEngineeringDegree-2023",
  "proofs": {
    "hdkeys": {
       "ite" : "..." //ite attestationwith only 1 key + optional proof
       "pk_seed" : "..."
      }
    ]
  }
}

Credential Response proposal 1:

{
  "credentials": [
    "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L",
    "YXNkZnNhZGZkamZqZGFza23....29tZTIzMjMyMzIzMjMy"
  ],
  "credentials_metadata" :  [
    "...", //keyhandle for credential 1
    "..." //keyhandle for credential 2
  ],
  "c_nonce": "fGFF7UkhLa",
  "c_nonce_expires_in": 86400
}

Credential Response proposal 2:

{
  "credentials": [
    { 
      "credential" : "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L",
      "metadata" : "..." //keyhandle
    },
    { 
      "credential" : "LUpixVCWJk0eOt4CXQe1NXK....WZwmhmn9OQp6YxX0a2L",
      "metadata" : "..." //keyhandle
    }
  ],
  "c_nonce": "fGFF7UkhLa",
  "c_nonce_expires_in": 86400
}

A third option to be analysed is also to derive new credentials from the public key of an existing, verified credential.