Providing interoperability for ECDH-HMAC signatures on key binding JWT

[Razumain]

This proposal is produced jointly with Peter Altmann, who discussed the topic with Christian Bormann for additional clarity. At Daniel's suggestion, we are opening this issue for broader discussion.

We propose amending the current text in SD-JWT, Section 4.3.2 by appending the following:

After the current paragraph:

If the Verifier requires Key Binding, the Verifier MUST ensure that
the key with which it validates the signature on the Key Binding JWT
is the key specified in the SD-JWT as the Holder's public key. For
example, if the SD-JWT contains a cnf value with a jwk member, the
Verifier would parse the provided JWK and use it to verify the Key
Binding JWT.

Add:

If the alg Header Parameter is HMAC-based (i.e., HS256, HS384, or HS512), the shared secret key MUST be derived as:

HMAC-key = HKDF(IKM, keylen, info, salt)

Where:

• HKDF is the HMAC-based Extract-and-Expand Key Derivation Function as detailed in RFC 5869,
• IKM is the output of the Diffie-Hellman key exchange between the public key in the cnf and the verifier private key,
• keylen is the output size of the selected HMAC algorithm (256, 384, or 512 bits),
• info is the ASCII string "SD_JWT_KB_" || alg (e.g., "SD_JWT_KB_HS256"),
• salt is the nonce value.

---

Motivation

Note that this discussion is limited to algorithms for the key binding JWT. ECDSA will still be used to sign the issuer signed JWT.

When planning for EU Digital Identity Wallet implementation, we identified several strong requirements:

• The Wallet's private key MUST be managed by a server-based HSM.
• The HSM MUST expose functionality via the PKCS#11 API.
• Each attestation must have a distinct public key.

Distinct cnf key material is used to enable verifier-unlinkable presentations. We want to derive single-show keys from a HSM-protected root key, but cannot find a way to do so while satisfy the above requirements using ECDSA for the key binding JWT.

However, it is possible to meet these requirements using the MAC algorithms listed in RFC 7518 section 3.1.

The proposed HMAC signing approach is fully supported in mDoc, where the derivation of the HMAC key is specified in Section 9.1.3.5 of [ISO/IEC 18013-5]. The proposal here mirrors that design as RFC 7518 does not specify how the MAC key should be derived.

We understand the SD-JWT specification is in its final stages. However, this is a non-breaking and narrowly scoped change that promotes interoperability in HMAC-based deployments. We therefore think it is worth the effort of an update before publication. Furthermore, this addition is critical for anyone aiming to support SD-JWT with single-show binding keys, where HSM resources are accessed using PKCS#11. Without it, we may only be able to guarantee verifier-unlinkability for mDoc (ISO/IEC 18013).

[Denisthemalice]

The proposed approach is trying to sneak a recommendation that applies to cryptographic algorithm interoperability without explicitly stating it.

The motivation states:

Note that this discussion is limited to algorithms for the key binding JWT.
ECDSA will still be used to sign the issuer signed JWT.

Currently, SD-JWT does not specify which cryptographic algorithms should be used and thus the second sentence is inappropriate.

ECDSA may be a choice but they are better choices, in particular when one-time-use digital credentials are being used.

• If SD-JWT remains agnostic to cryptographic algorithm interoperability, the proposal should not be accepted.

• If SD-JWT does not remain agnostic to cryptographic algorithm interoperability, other possibilities should also be mentioned. At this late stage, I wonder whether it would be appropriate to do it. This topic would be better addressed in a separate document.

The motivation states:

When planning for EU Digital Identity Wallet implementation, we identified several strong requirements:
· The Wallet's private key MUST be managed by a server-based HSM.
· The HSM MUST expose functionality via the PKCS#11 API.
· Each attestation must have a distinct public key.

If the wallet is supported by a smartphone, I don't understand why the Wallet's private key MUST be managed by a server-based HSM and why it MUST expose functionality via the PKCS#11 API.

PKCS#11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40 https://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/cs01/pkcs11-curr-v2.40-cs01.html published in 2014 contains a set of cryptographic mechanisms which limits the kind of cryptographic algorithms that can be used. Newer algorithms have been defined since then and are not included.

The sentence

"Each attestation must have a distinct public key"

is left unexplained. The word "attestation" is not present in SD-JWT.

The motivation states:

We want to derive single-show keys from a HSM-protected root key, but cannot find a way to do so while satisfy the above requirements using ECDSA for the key binding JWT.
(...)

Furthermore, this addition is critical for anyone aiming to support SD-JWT with single-show binding keys, where HSM resources are accessed using PKCS#11.

There are other ways to derive single-show binding keys.

[danielfett]

I think it's fine to use an HMAC algorithm for "signing" the KB-JWT. Right now we use the term "signing", even though it's not technically correct, to mean both asymmetric and symmetric methods. As far as I know, we don't have normative language preventing the use of HMAC-based algorithms, but if there are concrete proposals to improve the wording, we can look into it.

I would not go as far as defining how the shared key is formed as proposed above.

[c2bo]

Defining something like key derivation should not happen in this specification IMHO. That should be part of a specification in JOSE (and would become usable via the IANA registry).

[Razumain]

I try to respond to some comments/questions here:

@Denisthemalice
Sorry about the ECDSA confusion. That is what We plan to use. The specification is clear that the SD JWT signature must be a signature and not HMAC. The point was to say that this only applies to key bindin JWT.

The requirement to use a HSM originates from EU requirements (EIDAS2). We either need to use a real HSM in the phone (not generally available), an external HSM connected to the phone, or an HSM on a server. HSM on a server is by far the most user-friendly option.

With regard to the wordings attestation and distinct key. This is part of our motivation and not proposed text. The eIDAS use of SD JWT (or mDOC) Is to express various attestations. The requirement on unlinkability forces us to use a unique key-binding key for each SD JWT derived from the HSM key pair for the wallet. This can be done using standard Diffie-Hellman for HMAC keys, but can't be done for ECDSA signing. This is why we need HMAC signatures to be specified to the level necessary for interoperability with all verifiers.

To all comments above: Why is this needed, and why not in JOSE.

If this is done, it MUST be in SD JWT. The reason is simple. The key binding key is defined in SD JWT, and that is the key that is used to form a HMAC key for SD JWT Key Binding JWT. JOSE can't specify the use of a key that is not defined in JOSE.

We absolutely need the specify how the HMAC shared secret is derived from the Holder's public key binding key to achieve interoperability. This is NOT needed e.g. for ECDSA, as the public key is all you need. You simply use that public key to verify the signature.

When using ECDH-HMAC as signing algorithm, it is necessary to specify how the HMAC key is derived from the public key in the SD-JWT in order to allow a recipient to validate the Key Binding JWT signature. Without this, the verifier would be clueless on how to verify the ECDH-HMAC signature.

I personally think that it is very reasonable to specify how you use the public key binding key to also verify a Key Binding JWT signed with HMAC.

Finally:

We share this problem with many others. I just don't think many have realized this yet. If this is not fixed, my guess is that we will have to abandon use of SD JWT all together and only use mDoc instead. This may lead to a large user base of this specification will be forced to not use it as well, unless this is specified elsewhere.

Our thought was that since this is defined in mDoc, that it would be appropriate to do in SD JWT as well. But we are aware that this is a last minute request, and that this will cause many to hesitate.

[paulbastian]

I've seen this need a long time ago which is why I started this: https://github.com/paulbastian/draft-bastian-jose-dvs

The correct way to do this is to create a new JOSE algorithm that defined all of this, doing this only in SD-JWT is not a clean standardization path and should be avoided. If you think that we need this then please respond on the JOSE mailing list.

I'm also unsure how this changes the unlinkability issues, as the EC public key still needs to be encoded in the issuer-signed SD-JWT

[AltmannPeter]

Part of our motivation is pragmatic: PKCS#11 is widely supported and backed by extensive implementation experience. While alternatives exist, they are significantly harder to justify when PKCS#11 is available. This is why we aim to ensure that key binding is compatible with PKCS#11-based deployments.

Beyond implementation concerns, there is also an issue of specification integrity. As it stands, SD-JWT does not avoid scenarios where compliant issuance results in unverifiable tokens.

@paulbastian rightly highlights a problem. Even if we restrict alg to the MAC algorithms in RFC 7518, Section 3.1, multiple degrees of freedom remain in how a shared HMAC key is derived. Both the key agreement mechanism and the KDF process are variable and must be standardized to ensure interoperability. Whether this is done through a new JOSE algorithm, an ETSI profile, by simply referring to RFC 9180, or elsewhere is an open question, but it must done. Otherwise SD-JWT continues to permit unverifiable issuance.

It is possible to explicitly forbid MAC-based approaches, but doing so would effectively exclude server-based architectures that rely on PKCS#11, which is arguably a highly attractive model for many implementers.

[Denisthemalice]

@Stefan,

I did not realized that you were the author of the first exchange.
It is good to talk with you again as it has been a very long time since we last exchanged (20 years ?).

You wrote:

The requirement to use a HSM originates from EU requirements (EIDAS2). We either need to use a real HSM in the phone (not generally available), an external HSM connected to the phone, or an HSM on a server. HSM on a server is by far the most user-friendly option.

An "HSM" in a smart phone is available in most (if not all ?) smart phones in the form of a TEE (Trusted Execution Environment). A TEE can host one or more TAs (Trusted Applications). However, at the moment, smart phone manufacturers do no allow to download TAs in their TEE, unless the TA has been developed by themselves.

The major advantage is that the cryptographic keys are (well) protected and managed by the TEE and that they can only be used by a TA hosted in the TEE.

A TEE and a TA in a smart phone "is by far the most user-friendly option" because it can work in a proximity mode.

:-)

You wrote:

The requirement on unlinkability forces us to use a unique key-binding key for each SD JWT derived from the HSM key pair for the wallet.

I would rephrase this sentence into:

The requirement on unlinkability forces to use a unique key-binding key for each SD JWT generated randomly by the TEE of the wallet.

You wrote:

This can be done using standard Diffie-Hellman for HMAC keys, but can't be done for ECDSA signing. This is why we need HMAC signatures to be specified to the level necessary for interoperability with all verifiers.

HMAC and ECDSA signing are not the only two choices.

You conclude:

If this is not fixed, my guess is that we will have to abandon use of SD JWT all together and only use mDoc instead. This may lead to a large user base of this specification will be forced to not use it as well, unless this is specified elsewhere.

As there are other choices, this does not need "to be fixed" in the way you propose.
The good news is that we do not "have to abandon the use of SD JWT all together".

:-)

Thanks both to NIST and IETF, others cryptographic algorithms can readily be used as they have already been registered by IANA many years ago; hence there is no need for JOSE to specify them, nor to register them.

Name 	                        Reference 
WOTSP-SHA2_256	        [RFC8391, Section 5.2]
WOTSP-SHA2_512	        [RFC8391, Section 5.2]
WOTSP-SHAKE_256	        [RFC8391, Section 5.2]
WOTSP-SHAKE_512	        [RFC8391, Section 5.2]
WOTSP-SHA2_192	        [SP 800-208, Section 5]
WOTSP-SHAKE256_256	[SP 800-208, Section 5]
WOTSP-SHAKE256_192	[SP 800-208, Section 5]

See: https://www.iana.org/assignments/xmss-extended-hash-based-signatures/xmss-extended-hash-based-signatures.xhtml

In the context of one-time use SD-JWTs, the major advantage of using these algorithms is that they are Post-Quantum resistant and far more performant than any other PQ-resistant ZKP solution being explored at the moment.

When using a TA, the use of the keys is controlled by the TA. When using a RichOS application, other RichOS applications voluntarily installed by the owner of the smart phone can use the keys as they are not well protected.

As an example, if Bob (25) accepts to collaborate with Alice (12), Alice can demonstrate to a Verifier hat she is over 18 while it will be unknown that the trick has been performed with the collaboration of Bob, thanks to the verifier-verifier unlinkability property.

Unfortunately, because collaborative attacks between users are not considered, this threat is not identified in section 9 (Security Considerations) from SD-JWT.

Payments are implemented in payment wallets running in a TEE. Selective disclosure of claims contained in digital credentials shall be implemented in digital identity wallets running in a TEE.

In practice, it is impossible to implement a secure wallet, unless the Holder application is hosted in a TEE.

@paul,

I am not on the JOSE mailing list and as I am already registered to too many lists, I would like to avoid to subscribe to an additional mailing list.

@peter,

You wrote:

It is possible to explicitly forbid MAC-based approaches, but doing so would effectively exclude server-based architectures that rely on PKCS#11, which is arguably a highly attractive model for many implementers.

Server-based architectures that rely on PKCS#11:

• cannot support the proximity mode (e.g., NFC),
• cannot support cryptographic algorithms that are Post-Quantum resistant,
• cannot be secure against user collaborative attacks when the verifier-verifier unlinkability property is supported
  ... unless you demonstrate the contrary.

[Razumain]

I didn't plan to provide the full math why ECDH-HMAC works with PKCS#11 HSM while ECDSA does not in the case where the wallet key binding key is derived from a static HSM key.

But as there seems to be some questions about this I will outline how and why this works just for reference. Consider this extra material for those wanting to understand the underlying rationale.

Deriving HMAC IKM with PKCS#11 HSM

keying material:

• w, W - The wallet private key w and public key W (HSM protected via PKCS#11)
• b - A blind scalar for a particular SD JWT
• v, V - The verifier key v and its public key V
• t, T - A unique key binding key pair based on the wallet key pair w, W and b.

The following actors are involved in the process when issuing, presenting and verifying an SD JWT

Issuer - Issuing the SD JWT with a key binding key T
Wallet - Doing presentations and creates key binding JWT
Verifier - Verifies the key binding JWT

The process to issue a SD JWT

1. The wallet communicates W and proves possession of w to the issuer
2. The issuer and the wallet agrees on a blind b (through exchange or deterministic derivation)
3. The issuer derives T = b * W

The key binding signature is generated by the wallet using

The wallet derives the HMAC IKM by the following two steps

1. use HSM to calculate DH(w, V)
2. derives IKM from b * DH(w, V)

The verifier Derives the HMAC IKM from DH(v, T)

[Razumain]

@paulbastian Thank you for your draft and your work. I actually looked at this as it was pointed out that this had been discussed before.

Let me start by acknowledging your points.

I see your point in defining a separate alg for designated signatures where you can deterministically validate the signature based on a given public key and parameters known or explicitly communicated to the verifier.

I can even see the point and value of having a defined identifier for a defined key agreement process.

However, even if we would follow your draft, in SD JWT, it seems to me that we would still have to define how to use it in SD JWT.

So seeking a first step of a common ground here. Could we both agree that SD JWT in some way would benefit from defining how you can create a SD JWT with key binding key, where the Key Binding JWT can be signed using ECDH-HMAC, AND where the verifier can deterministically verify the signature solely based on information found in the SD JWT presentation?

If we can agree on that, we could move on to what the best solution would look like.

[Razumain]

@Denisthemalice Then I assume your last name is Pinkas? :)

Denis, I think we should avoid the TEE discussion. Let's just say that all collaborating member states in EU agree on that a majority of mobile phones in use today lack the key protection required to meet the eIDAS regulation requirements.

Besides, enabling use of ECDH-HMAC with deterministic validation has value regardless.

[bc-pi]

Copying my mailing list reply here for posterity and/or to add noise to the issue commentary.

Speaking as one of the editors but not one that was not involved in these aforementioned initial contacts, I think there might have been some miscommunication or misunderstanding here.

The intent in the context of this draft has long been (for at least a year and 10 revisions) to not prohibit the use of HMAC (or anything other than "none") JWS signing algorithms. But not to attempt to define the pieces like the KDF and key exchange that would be needed to make HMAC work kinda like an asymmetric signature. My stance has been that the proper layer for that is in the presentation request/response protocol (such as OpenID4VP). Or maybe not the proper layer exactly but the most pragmatic layer given the totality of circumstances. As mentioned in a comment on that #574 issue, Paul believes it would be more appropriate at the JWS algorithm layer. That's certainly a reasonable perspective but would almost certainly still need some pieces spelled out at the presentation protocol layer. Having said that, I don't think much or even any allowance or guidance exits in the presentation request/response protocol layer that I'm familiar with, OpenID4VP, to facilitate anything like this. To the extent that it's as important as implied here, I'd suggest some of the energy behind this be directed there (while being aware that that document is in the latter stages of the OIDF process).

As Danial mentioned also in a comment on that issue #574 we use the term "signing" in SD-JWT to mean HMAC as well as typical asymmetric signatures. Even though it's not technically correct, it follows the terminology of JWS/JWT that encompass MACs as JSON Web Signatures. As far as I know, there is no normative language preventing or prohibiting the use of HMAC-based algorithms. However, if there are concrete suggestions to improve specific language in the draft, we can certainly consider incorporating clarifications or improvements.

Lastly please note that IESG Balloting has already begun on this draft. So the bar for changes at this point, without incurring significant process intervention anyway, is quite high.

[paulbastian]

@paulbastian Thank you for your draft and your work. I actually looked at this as it was pointed out that this had been discussed before.

Let me start by acknowledging your points.

I see your point in defining a separate alg for designated signatures where you can deterministically validate the signature based on a given public key and parameters known or explicitly communicated to the verifier.

I can even see the point and value of having a defined identifier for a defined key agreement process.

However, even if we would follow your draft, in SD JWT, it seems to me that we would still have to define how to use it in SD JWT.

So seeking a first step of a common ground here. Could we both agree that SD JWT in some way would benefit from defining how you can create a SD JWT with key binding key, where the Key Binding JWT can be signed using ECDH-HMAC, AND where the verifier can deterministically verify the signature solely based on information found in the SD JWT presentation?

If we can agree on that, we could move on to what the best solution would look like.

We drafted and implemented the ECDH + HMAC options in the German wallet project using my draft and had no issues with it. So also to @bc-pi I believe that the important pieces in OpenID4VP do exist, especially the option to transfer the verified public key in it's client metadata object. @Razumain the whole point of my draft was to specify all the header parameters and process so that everything is clear from the alg value, this is also in line with Fully-specified algorithms, which is just about to get published by JOSE. Therefore can you explain what's missing in SD-JWT in your opinion when we would use designated Verifier signatures?

[Razumain]

@paulbastian As I read your draft, the info parameter is still not specified, and not included in any header parameter. That would still need to be agreed upon.

I think the draft is great work, and fantastic if it was to be accepted and implemented in all JOSE tools. But before that it seems problematic to change the alg parameter. I don't think I can use any existing JOSE library to process this signature for a long time.

Perhaps a route that would allow me to use existing JOSE tools would be to keep "HS256" and similar as alg (It is still an HS256 signature), but add a header parameter that specifies how you derive the HMAC key. Peter Altman will contact you and try to setup a discussion on this.

For SD JWT I do however the chance of getting text referring to your draft is a no-go as it would hold up this document for considerable time.

[paulbastian]

SD-JWT would not need a reference to my draft, as all Jose algorithms apply to JWS, and that's what SD-JWT is using.

Even if you were to use HS256, you would need to do additional ECDH and KDF stuff that usually should be done by a library, so the best and fastest way would be to implement the correct algorithm right away in my opinion.

[danielfett]

For SD JWT I do however the chance of getting text referring to your draft is a no-go as it would hold up this document for considerable time.

That would exactly be the concern, as such an addition would need quite a bit of time.