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

See comments below.

On Mon, Aug 28, 2023 at 9:59 PM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> > 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...


Performing actions like salting, hashing, or constructing the selective
disclosure data structure doesn't necessarily need to be done within an
HSM. I agree with that. However, I would disagree when it comes to the
cryptographic signature operation itself, as it could potentially introduce
vulnerabilities that could lead to credential forgery.


> 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.
>

I would partially disagree with that statement. This approach increases the
vulnerability of the effective issuance key to potential forgery risks.


>
> 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.
>

Yes, agreed. It can certainly be done with ecdsa-sa.


>
> 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.
>

Text from eIDAS 1.0 regulation (2015):
https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015R1502&from=EN

Text on guidance on levels of assurance (eIDAS 1.0):
https://ec.europa.eu/cefdigital/wiki/download/attachments/40044784/Guidance+on+Levels+of+Assurance.docx

Specifically under the following point:
> Sensitive cryptographic material, if used for issuing electronic
identification means and authentication, is protected from tampering.

EC recommends the following (not that this applies to both LoAs:
substantial or higher):
> It is common practice that these security controls are implemented as
part of a hardware security module (HSM). Such products fulfilling this
purpose should provide transparency in the security mechanisms implemented
and meet the highest quality and security standards. Security certification
can give accompanying evidence and is good practice to assess the quality
of HSMs, like certification under Criteria Recognition Arrangement (CCRA)
and/or the Senior Officials Group Information Systems Security Mutual
Recognition Agreement (SOGIS-MRA), or FIPS-140. Products should be sourced
from a trusted vendor and commissioned in a way that ensures the chain of
custody of the units, from the manufacturing of the unit to the point where
the HSM is taken into production.


>
> > 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. :)
>

I believe that BBS is highly valuable in numerous scenarios where there is
no need for hardware-backed cloning protection.


>
> 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.
>

I agree, although it's worth noting that our use case document includes
scenarios that even necessitate air-gapped issuer keys, such as those for
passports. Broadly speaking, the document encompasses a wide range of
high-assurance credentials like passports, healthcare, and finance. It
might be beneficial for us to incorporate more specific use cases that
would gain advantages from low-assurance credentials.


>
> > 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?
>

No, nobody has suggested that, and I wouldn't suggest it either. What I was
explaining is that if we were to combine these two approaches, we would
compromise unlinkability. We probably agree on that.


>
> > 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?
>

In fact, my argument was in favor of using BBS for low assurance use cases,
(arguably not even medium but definitely) not high. This is because
implementing hardware-backed cloning protection is currently a challenging
task with no straightforward solution.


> 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.
>

I believe that maintaining unlinkability is crucial in most scenarios. I
think we can find common ground on that point. However, I wanted to clarify
why I feel that BBS might not be suitable for achieving high assurance.
This is due to the current limitations in state-of-the-art technology and
the lack of support for required cryptographic functions like curves and
derivation functions in widely used mobile devices and HSMs.