Re: Demonstration of Support for NIST-Compliant Selective Disclosure for Data Integrity Cryptosuites in VCWG

On Mon, Aug 28, 2023 at 7:59 AM Oliver Terbu <oliver.terbu@spruceid.com> wrote:
> Manu, I appreciate your response. It has clarified all the questions I had. So, just to confirm my understanding, the HMAC serves solely as a CSPRNG, and there's no requirement to independently verify the actual HMAC.

Correct, it's never sent over to the verifier.

> Additionally, I completely agree that introducing extra ephemeral keypairs would indeed be complex in this context.

Glad to hear.

> Here's an interesting aspect to consider. In certain legal jurisdictions, reaching the highest assurance level requires the protection of the key used for signing statements within an HSM as well. For instance, to achieve eIDAS high, as outlined in the document https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/eIDAS+Levels+of+Assurance, protecting the esk in hardware is mandatory. This aspect adds an extra layer to the discussion about the ephemeral public key in the ecdsa-sd scenario. Despite the fact that the public key is signed by an HSM, it lacks the protection of an HSM.

Yes, this was considered when designing ecdsa-sd. There are at least
three answers to the suggestion above (depending on what one
believes):

1. The intermediate stages of the creation of a VC need not be
protected by an HSM. For example, IIUC, eIDAS does not mandate that
the salting, hashing, or building of the selective disclosure data
structure are performed within an HSM... but if you do those bits
wrong, you can digitally sign compromised data. In other words, it
trusts the issuer to secure the environment  that creates the hash to
sign using standard industry practices (such as running in an
appropriate cloud data center with appropriate controls). What is
required is that the key that secures the entire payload is in an HSM,
which can be done with ecdsa-sd.

2. If, for some reason, eIDAS mandates that /any key/ used in the
securing of a VC MUST live in an HSM (instead of just the issuers key)
-- and again, please share the text in eIDAS that mandates that, it is
possible to just sign that information with an HSM-bound ephemeral key
as well. Sure, it's more computationally expensive to perform that
operation, but it can be done w/ ecdsa-sd -- and we have HSMs capable
of this feat at negligible price points today.

3. Given that there is nothing limiting ecdsa-sd to only have a single
cryptosuite (unlike SD-JWT), a cryptosuite version could be created
that uses the salted-hash scheme (but the loss there would be to the
efficient signature sizes used in ecdsa-sd). So, if this is really a
concern, which I'm suggesting that it's not given that the rest of the
signing process isn't required to happen in an HSM, we can easily
crank out a new cryptosuite (such as ecdsa-sd-eidas) that does align
more closely w/ eIDAS (without impacting the base data format like JWT
-> SD-JWT -> JWP does).

So, if this really is a concern (and at present, I don't see any text
in eIDAS that says that it is), then we should look into it and
address it. Could you please point to the specific text that states
that ephemeral keys need to be protected by an HSM? I'm basing my
position on, at a minimum, the fact that TLS connections for "high"
use cases use ephemeral keys that are not secured by an HSM.

> Agreeing with your point about unlinkable signatures being optimal for privacy, I'd like to add that it's crucial to consider the absence of robust hardware support for BBS+ credentials. As long as this deficiency exists, those credentials remain susceptible to cloning, which, in my opinion, undermines achieving high security levels.

There isn't "robust hardware support" for post-quantum schemes at
present either, so I wouldn't use that as an argument for something to
not be useful for a subset of the population. I also wouldn't presume
that there isn't hardware support for BBS+ either. :)

Solutions don't need to always meet the highest level of security --
heck, if you look at the way almost all of us operate today, society
uses SSH keys (not in HSMs) that are sitting on our systems
(unencrypted in memory!) to access and manage critical infrastructure.

> Merging BBS+ with ECDSA would compromise its unlinkability property, which defeats its intended purpose.

Hrm, I don't think anyone was suggesting that BBS+ be merged w/ ECDSA?

> A potential solution might involve the use of linked secrets or signature IDs. However, it's worth noting that these alternatives might also lack hardware-based anti-cloning protection. For credentials to have a high assurance level, effective measures against impersonation must be in place to uphold security, as neglecting this aspect also jeopardizes privacy.

Why do you think that BBS is only for high assurance use cases?
They're largely for low to medium assurance use cases where
unlinkability is desired... at least, that's where I see them most
useful. Hardware-backed BBS would be able to possibly support
high-assurance use cases, but those use cases typically require
information that correlates the individual anyway. You can't just
cross a border by stating that you're a citizen of a particular
country... they want to know exactly WHO you are.

Hope the above helps -- interested in your responses to the statements
and questions above.

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
https://www.digitalbazaar.com/

Received on Monday, 28 August 2023 19:59:13 UTC