Cryptographers' Feedback on the EU Digital Identity’s ARF

[alysyans]

The EUDI Wallet Team of the European Commission invited subject-matter experts (i.e. cryptographers) to participate in a Webex meeting on June 5th or 6th, 2024, in which the team presented their current design of the EUDIW (ARF version 1.4.0), and requested feedback. They specifically requested feedback concerning attestations and zero-knowledge proofs. Our feedback is in this document: cryptographers-feedback.pdf

The attached document was co-authored by and thus represents the consensus opinion of the following cryptographers who were present on one of the two calls:

Carsten Baum, Technical University of Denmark
Olivier Blazy, École Polytechnique
Jaap-Henk Hoepman, Karlstad University & Radboud University
Anja Lehmann, Hasso-Plattner-Institute, University of Potsdam
Anna Lysyanskaya, Brown University
René Mayrhofer, Johannes Kepler University Linz
Hart Montgomery
Ngoc Khanh Nguyen, King's College London
abhi shelat, Northeastern University
Daniel Slamanig, Universität der Bundeswehr München
Søren Eller Thomsen, Partisia

Five additional experts (who were unable to participate in the calls, but carefully reviewed the ARF and other relevant materials) also co-authored this document:

Jan Camenisch, Dfinity
Eysa Lee, Brown University
Bart Preneel, KU Leuven
Stefano Tessaro, University of Washington
Carmela Troncoso, EPFL

Executive summary:

The eiDAS 2.0 regulation (electronic identification and trust services) that defines the new EU Digital Identity Wallet (EUDIW) is an important step towards developing interoperable digital identities in Europe for the public and private sectors. The regulation, if realized with the right technology, can make Europe the front runner in private and secure identification mechanisms in the digital space, and act as a template for future digital identity systems in other regions.

Unfortunately, we believe that some of the currently suggested design aspects of the EUDI and its credential mechanism fall short of the privacy requirements that were explicitly defined after extensive debate in the Digital Identity regulation. The main reason for this shortcoming in the current proposal is that it relies on cryptographic methods that were never designed for such requirements.
We do not see a way to fix the proposed solution to meet all the privacy features as required by the regulation; we believe that a larger redesign is in order.

In this document, we propose to use a different cryptographic mechanism instead; namely, anonymous credentials. Anonymous credentials were designed specifically to achieve authentication and identification that are both secure and privacy-preserving. As a result, they fully meet the requirements put forth in the eiDAS 2.0 regulation. Moreover, they are by now a mature technology. This technology was developed more than twenty years ago, and extensive efforts have been expended to analyze, improve, implement, standardize, test, and deploy it. Anonymous credentials are well understood by the scientific community.

Our specific recommendation is to use the BBS family of anonymous credentials. For BBS, thanks to prior work by the W3C, the Decentralized Identity Foundation, IETF/IRTF, ISO, and other standardization bodies, as well as the availability of open-source software libraries, the EC can develop a standard and reference implementation with only a modest effort. We additionally recommend that the EUDI be designed following the principle of crypto-agility, meaning that its underlying technologies can be upgraded quickly in the future if the need arises.

We thank the EC for this opportunity to weigh in. We would be excited to continue to provide feedback on this important endeavor, and see this document as the beginning of a longer dialogue.

cryptographers-feedback.pdf

NOTE: We are still polishing the document for readability and adding pointers to relevant literature; an updated version will likely be posted here in the near future.

[ad-Orange]

Hello,
We totally agree with your analysis of the current situation of the ARF and the direction you're proposing (anonymous credentials with BBS being the favourite). In response to the same request from the commission, we would like to stress the following points (that you also seem to share):

• The way forward is using anonymous credentials, preferably of the BBS type
• There is no "quick fix" to make sure the ARF becomes privacy-preserving. It needs to be rebuilt from the ground up with anonymous credential protocols
• This can be done today

In order to give more credibility to the last point, we just posted a proposal explaining how BBS/BBS+ can be implemented with already deployed SEs in a very efficient way. This can even be made compatible with mDL / SD-JWT.
Given the cumulative skills and knowledge of the authors of your paper, we would be very happy to get your feedback on the proposal we are making and are happy to provide more details if needed.

[rmayr]

I believe this document addresses details of #193, among other issues.

[alysyans]

@ad-Orange: thanks for your comment! Indeed, your post seems extremely relevant. Glad that we are all in agreement!

[ckahlo]

The one main question still is: Why signing at all?!

We successfully showed in BSI TR-03110, TR-03130, etc. how to perform ephemeral authentication without having to sign anything without the need of "zero knowledge proof" or similar algorithms. 15 years ago and every single bit of it is still valid.
(Besides relying party authentication, of course. But the relying party has to be known to the wallet holder anyway.)

The main problem of "verifiable credentials" is 3rd-party-verifiability by unauthorized, illegal / criminal 3rd parties. Also introducing data protection issues when verifiable credentials are accumulated at service providers. Verifiable credentials have their origins in the idea of "signed tokens" as used in OpenID Connect / OAuth2 tokens and SAML2 assertions (this was back in 2001!).

The concept of unprotected CWT (RFC 8392) claims set in COSE (RFC 9052) revives the idea of using encrypted, authenticated point-to-point channels to securely transmit all required claims WITHOUT SIGNATURES:
https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/

One could think about a hash or set of hashes to double-check overall integrity. But the idea of signing personally identifiable information is bad, obsolete and not needed at all. Proven during the past one-and-a-half decades in one of the largest EU member states.

Best,
CK

Edit 1: added missing link to current IETF draft for UCCS.

[kernoelpanic]

I fully support the general recommendation towards more privacy-tailored cryptographic approaches, such as BBS/BBS+ Signatures, which has been put forward in this issue.

In addition, I would like to mention the following two points:

• If the history of other cryptographic schemes and protocols has taught us anything, it is that any protocols/algorithms selected now will be subject to change sooner or later to keep up with evolving attacks (which only tend to get better over time). Keeping this aspect (sometimes referred to as cryptographic agility) in mind could be very helpful. Balancing this agility, while not compromising security or privacy by supporting a plethora of options and backward-compatible approaches, is a challenge that any solution will face. Designers should be aware of this challenge from the start.

• A well-maintained security/threat model, including a prioritized list of security and privacy threats for each use case targeted by the EUDIW, could be very helpful to objectify the discussion and select the appropriate protocols/algorithms. Ideally, this model/list should be derived from the eIDAS legislation and expert consensus and will probably need to be adapted over time as well as new, previously unthought-of security and privacy threats emerge. To provide one example, I would like to mention the potential requirement for repudiation, sometimes also referred to as deniable authentication or designated verifiability. This could be very helpful in some use cases while being mutually exclusive to the goals of other use cases. I am using this example because this property has not been a core design goal of most proposed solution approaches yet, but using the same underlying primitives, it can still be achievable in scenarios that require it, albeit requiring additional effort.

[ckahlo]

@kernoelpanic Thanks a lot. As we're on the jump to post quantum cryptography or currently hybrid mechanisms as well we need versatile "basic" cryptographic primitives. BBS / BBS+ is a DEAD END STREET under the view point of crypto agility and especially forward towards PQC interoperability.
Keep in mind: this process will still take some years until the technology stack is rolled out in production. And quantum supremacy is getting closer as well. In general it will help to stick to generic cryptographic primitives that can be transponed to future more modern mechanisms without throwing over the whole protocol stack.

[kernoelpanic]

@ckahlo I would not call BBS/BBS+ a "dead end", it is probably the most thoroughly researched algorithm specifically designed for the use case at hand and the most advanced in terms standardization (compared to other newcomers). Is it perfect? Probably not, as nothing will be.

I am getting your point regarding signatures and 3rd-party-verifiability and the demand for repudiation, which I also support. Although BBS+ as put forward in the RFC does not have this as an explicit goal, I believe the underlying primitives can be used to achieve schemes which can do it, at least with a performance decrease e.g, when used interactively (please correct me if I am wrong). So assuming, repudiation/deniable authentication could also be solved, what remains is the threat of a quantum computer, but abandoning a by-today's-standards well thought through approach that ticks almost all boxes (maybe all with some tweaks) because of this is also not the way to go my opinion. This does not mean, that we should not consider upgradeability right from the start.

Generally, it would be a good idea for the discussion to agree on a prioritized list of boxes which should be ticked by a solution first. Maybe, there is no one-size-fits-all solution ...

[rmayr]

Please note that the main basis for this document is the published legal text of the regulation, i.e. the list of requirements (unlinkability, selective disclosure, pseudonymity, etc.) is taken directly from the regulation. We intentionally did not want to go through the requirements analysis itself, because this is defined in the law at this point.
If somebody wanted to go back to the start, other requirements may be prioritized, but that was not the starting point for this recommendation.

[ad-Orange]

@kernoelpanic As regards to repudiation, there is indeed a technology invented in 1996 to implement plausible deniability for all ZKP based anonymous credentials. We detail its use with our BBS# proposal in page 20 of our paper (it is called DVP and referenced as [JSI96]). Please also note that contrary to popular belief, interactive ZKP do not provide plausible deniability.
@ckahlo We don’t think that authenticated channels present any sort of advantage for repudiation compared to our proposal (and the DVP technology in general).

[LittleDetritus]

@ad-Orange
Two points on this regard how do you ensure that reyling parties can not forward the verified data without the users knowledge?

Following IT-Security best practices:

• Assume breach
• Zero Trust

that the user does not need to rely on trusting the relying party that they do not forward the tokens?

If we also take the eIDAS2 requierments by heart following security by design at state of the art, do you see a way around 2FA for LOA high including an airgapped physical token?

[ad-Orange]

@ckahlo So in essence, you are opposing a possible but as of yet hypothetical threat (“quantum supremacy”) to a legal requirement (respect of GDPR including minimization and unlinkability) due today. Furthermore, it's not even clear how you would end up being GDPR compliant with your so called 'versatile "basic" cryptographic primitives'.
As explained in the original paper of this thread in section 6 and in our own paper, the “dead end street” of BBS/BBS+ ensures unconditional / everlasting privacy today.

Now, let’s talk about authenticated channels:

• For some options (e.g. option D in the “German ARF”) The security of it relies on properly implemented SE
  o As explained by Google here and here, if a SINGLE of these SE (CC certified or not) is compromised (reminder: 448,4 millions inhabitants in Europe, source: EU), the attacker could impersonate anyone
• None of the proposals we have seen supports full unlinkability (as also explained in part 2 of the original paper of this thread "Analysis of the ARF and Its Shortcomings")
• Repudiation / plausible deniability needs to be decided on a per use case basis and not imposed for all use cases indiscriminately
• How do you store all the necessary attributes and data structures in an SE ? If you don't, how do you combine multiple VCs in a single presentation ?
• How do you manage revocations in a privacy preserving way ?
• The implementation is subject to a lot of overhead. Depending on the chosen option, it could involve (potentially a combination thereof):
  o Changes in the ARF
  o Changes in the interfaces of the RP
  o Deployment of widespread extremely highly protected SE (see for point of this paragraph…)

As long as there is no clear advantage identified today for authenticated channels as opposed to other proposals (including the paper we just posted), especially taking into account the constraints that will be there at the launch of eIDAS in a few years, it doesn’t seem like less of a “dead street end” than BBS/BBS+…

[ad-Orange]

@LittleDetritus, I'm not sure you are understanding how DVPs work. Basically, you can steal or forward the ZKP to anyone you want, they will not be able to assess their validity (except its designated target, e.g. the verifier to whom the holder is doing the presentation). Once again, it's a technology that dates back to 1996 and how to use it in the realm of BBS signatures is explained in our paper around page 20.
As regards to air-gapped solutions, you can use a FIDO key if you want and think that makes sense from a usability point of view. It can be discussed whether it really adds anything in terms of security, but that's another discussion. As an inspiration, you can look at this architecture proposed by the GSMA and replace the SIM with a FIDO key or even just add a FIDO key to the intricated factors. You will not lose anything in terms of privacy.

[msporny]

Speaking as an Editor for the W3C work cited in the paper (W3C Verifiable Credentials, W3C Data Integrity, the W3C Data Integrity BBS Cryptosuite), and as someone deploying that technology with national and state governments globally, I agree with the findings of the cryptographic review and the experts that put the paper together.

The current approach taken by SD-JWT is deeply flawed, as it relates to unlinkability and cryptographic agility, and has been flawed from the beginning. This has been expressed multiple times over the years, but the review from the cryptographic experts listed above hopefully places more weight on the previous criticisms of the use of SD-JWT. It is not fit for purpose for the EU's Digital Identity initiatives.

I will also note that the W3C VCWG has known about these limitations for years and has provided a viable alternate path via W3C Verifiable Credentials, W3C Data Integrity, and the W3C Data Integrity BBS Cryptosuite. Additionally, future cryptographic innovations utilizing W3C Data Integrity wouldn't require a format change, by design. The same cannot be said for VC-JWT, SD-JWT, or JWP.

I will also note that a review of the ARF's data model choices and cryptographic primitives have not been requested of any W3C Working Group. I would strongly suggest that the European Commission (or relevant body) officially request a review from the W3C on the ARF, as many of the experts in the W3C would not feel comfortable volunteering an unsolicited review.

[aj-stein-nist]

The current approach taken by SD-JWT is deeply flawed, as it relates to unlinkability and cryptographic agility, and has been flawed from the beginning. This has been expressed multiple times over the years, but the review from the cryptographic experts listed above hopefully places more weight on the previous criticisms of the use of SD-JWT.

I read the paper yesterday to understand your perspective, but beyond unlinkability, the criticism you summarize here about SD-JWT is not further explained. I do not have a strong position on whether it is valid or invalid criticism, but can you link to where those discussions about the criticisms have been happening for SD-JWT, is it within the IETF mailing lists, somewhere else? Thanks.

[ghost]

@ckahlo the German solution is well-known and from security point of view the best solution. The disadvantage: Lack of adoption. Germany achieved 15% usage rate after 14 (!) years since publishment

Your statement " But the idea of signing personally identifiable information is bad, obsolete and not needed at all. Proven during the past one-and-a-half decades in one of the largest EU member states." is a bit wrong looking at the less usage rate in Germany. Looking at Germany its proven that the German approach was best for security because it also mitigates the biggest security risk - the user.

"One could think about a hash or set of hashes to double-check overall integrity." - a hash without PoE is useless.

Majority of EU Member states use signed data in eID: Which fraud identity or data dealers for which signed eiD Data from which eID means based on which eID Scheme do you know? Please provide so that we can analyse commonly. This information is essential to assess the security risk and possible measures

[ckahlo]

At first: I gave a ❤️ emoji to the initial post, because I totally AGREE on BBS+ in case one has to rely on software certificates or weak key stores like Androids StrongBox or Apples SecureEnclave.

In absence of stronger protection mechanisms of the private key, signed ID data is the only option we have. I am very well aware of that and was looking for a clear answer, because we're talking about secure elements as if this was the very same thing as well.

So, without a secure element of any kind: BBS+ is probably the best way to go. Authenticated channels would lead to forgeable identities if the authentication key is leaked. A clear no-brainer I assume.

@ad-Orange 1st comment: my question "why signing at all" wasn't with repudiation in mind, it's an option. Reduced to repudiation I might agree.

@ad-Orange 2nd comment: Thanks for https://github.com/user-attachments/files/15905230/BBS_Sharp_Short_TR.pdf,
I already knew https://www.engr.mun.ca/~howard/SAC_SLIDES/slides_Barki.pdf and "Improved Algebraic MACs and Practical Keyed-Verification Anonymous Credentials" from the past. Good work.

• But the Y2Q threat (https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later) isn't just my personal opinion. NIST explained their motivation here: https://csrc.nist.gov/Projects/post-quantum-cryptography - and the corresonding EU member state bodies and independent researchers I've been in touch with support this. I had been explicitely pointed to this by digital rights groups. It is something to keep in mind when designing new systems. Another 15 years and it is almost 2040.

• I said "dead end street" for crypto agility towards PQC mechanisms - I wasn't even discussing about long-term privacy of BBS+, but before someone claims "everlasting privacy" a peer-reviewed proof should exist. Both papers are new, so a credible peer-review does not exist yet. If your claims are correct, I'll be absolutely happy anyway. :)

Authenticated channels:

1. I am not in charge of the SPRIN-D architecture - and NEVER said I'm happy with this architecture. Don't mix that up, just because people are from the same country.
   But I know the numbers and from the existing system I can tell you the chip authentication key is either limited to 2 million documents or 3 months of issuance time. As the document signer is linked to the chip auth key and has a limited lifetime a breach of 1 key affects only this 1 batch and only if it is not expired yet. Expired batches are "allowed" (and somewhat expected) to breach. The national ID cards have a lifetime of 10 years, discussed lifetimes for the secure element version were between 6 months and 2 years. If a batch breaches within the validity period it enters the defect list, effectively blocking those documents. But if that happens the secure element users (and the OEM and the SE supplier) may have lots of other problems as well ;-) Think of payment and device encryption.
   For an EU-DI variant, a corresponding value for the key lifetime/number of wallets would have to be defined in any case. Probably further splitting the document signers by issuing institutions/countries, implementations, etc. any way.
   Even NXP P5 errata exists - a breach is not known yet. 15 years. How long lives your phone? Galaxy S24 lifetime is sought to be at 7 years at max (speaking of updates).
   And have a look into ISO 23220-4 §7.1.6 where they suggest publishig the document signer key after expiration. (Personally I don't like that, even it may be mathematically valid)
   I would only talk about CC EAL5+ evaluated "secure elements", no toys please.

2. Unlinkability is given in the 1-in-2-million-documents / 1-in-3-months-issued-documents frame. So, these numbers have to be chosen wisely. Don't blame me if SPRIN-D didn't.

3. As said before repudiation wasn't my idea when asking "why signing at all?". I won't discuss this here.

4. As per current proposals only keys and the minimum dataset and hashes of external attributes / attribute stores is stored in the secure element itself. Larger sets of attributes (or even PDFs) are stored in the wallet application / mobile device storage with an option for synchronization with a remote storage. But this affects a BBS+ implementation on secure elements as well. Concepts can be combined for shure.

5. Please see BSI TR-03110 restricted identification. There exist two distinct RIDs, one for revocation, one for pseudonymous access - that's the current implementation. For a wallet a revocation RID key-pair is generated during initialization and the public key returned to the issuer who adds the public key to a revocation database. The public key is then associated with a hash of some minimal PII (name, birthdate, metadata such as issuance date of the "document") and a randomly chosen revocation password and stored in the DB. But I'm totally happy if someone comes up with new ideas / better approaches. As said, this is ~15 years old.

6. I am speaking of this as an alternative approach. As said above I totally agree (and like) BBS+ for non-secure-element solutions. In another discussion I said "there have to be two types of wallets, one with signed data and BBS+ and another one with a different approach using secure channels / ECIES".

BUT: I would be interested in having a closer look into the backgrounds of your paper. Because from
https://www.gsma.com/gsmaeurope/resources/architecture-considerations-for-eidas-2-0/ page 10 in the section "Privacy" it is said BBS+ is not supported by SEs in the market in an efficient way. And with my knowledge until today I can confirm this. Regarding your paper you're talking about ECSchnorr and ECDSA as if it was the same. But the "real" ECSchnorr is only available as an option with the BSI CSP (https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03181/BSI-TR-03181.pdf?__blob=publicationFile&v=5). The standard JavaCard APIs (https://docs.oracle.com/en/java/javacard/3.1/jc_api_srvc/api_classic/javacard/security/Signature.html) only know classical ECDSA - not the "real Schnorr".

I would be happy if we could confirm your findings from your paper and would encourage our BSI to have a closer look at it. If it works out, we could push it together. Hint: I've some dozen top-notch secure elements here - but older ones as well. :-)
You'll find my contact coordinates on my profile or somewhere on the net.

@KeepTrust: what a bold comment from an account created just 15 hours ago!
If you cite statistics, please cite with sources. Statistics differ. As you may know the German eID system isn't "centralized" at all - bigger service providers have their own eID servers and mostly smaller ones use eID-services such as those from Governikus and Bundesdruckerei.
So, there are no consolidated transaction logs or counts on them. The best options are surveys and what I could find using Google is 3 years old. I've got different more up-to-date numbers, but I'm probably not authorized to publish them without talking to BSI/BMI before.

That being said: Germany has a high population density with a good offline infrastructure compared to more rural areas within the EU. Additionally there is the "silver generation" with a fear of technology.
BUT: Corona was a game-changer, the adoption increased during the shutdowns and more service providers entered the show.
AND: Germany was never forcing anybody "you have to use the eID" as other countries did, this started only slowly in the past time and well, the adoption rate increased.

Let's have a look how the adoption in the EU will be before judging too early.

Technically the usage rate is not linked to the underlying protocols. We started to issue the first
"QES" signature cards in 1999 - other EU countries would claim this as "oooh, look we started with
eID that early" - basically, all signature based ID schemes claimed as "eID" would be the same.
But we chose to split "signature" and eID. And some people mix that up.

And we're also aware about some EU members not applying any reasonable security measures as well! Thanks for the fish.

Just a hint: use Google with "estonian identity disaster", look up how Petr Švenda became able to impersonate basically everybody in Estonia. And continue, there are more examples. But that's your homework, not mine.

From my side this is end of discussion.

Good bye & good night,
CK

[veikkoeeva]

ECSchnorr. Please note that as no pairings are involved, the BBS# proposal is also compatible with standard curves. Here are a bit more details: o In 2.1.6, we show how to calculate the issuer signature [...]

A quick (rookie) question, if allowed, would this work with TPM 2.0?

[ckahlo]

@veikkoeeva Yes. E.g. ECSchnorr as signing scheme in the toolchains. The TCG specs also specify it.
https://github.com/tpm2-software/tpm2-tools/blob/master/man/common/alg.md

[henkbirkholz]

The TPM2 Tools and TSS implementation is based on the TCG Algorithm Registry (and that checks out, too).

[henkbirkholz]

And I just saw that @ad-Orange also confirmed that in #211 (comment) already.

[veikkoeeva]

I saw the mention on various secure elements and HSMs, but didn't see TPMs and maybe there's something more one might need to know. Probably it's found out when someone -- maybe me -- tries to do it with a TPM. In my case I like try to do it through .NET (I'm already working some preliminary designs with byte buffers in/out TPM, simple operations still).

[OBIvision]

Based on the touted use cases, this is supposed to be the future of identification in the EU. It is incredibly important to get this right.

It is pretty clear that ARF is heading for BIG TIME failure - doing the exact opposite (i.e. total surveillance) of what is needed (empowerment of citizens).

[jtalir]

We are already living in this "total surveillance" for 6 years since eIDAS 1.0 federated centralized identity system launched in 2018. There was no citizen uprising because of this I'd know about. Now we have possibility how to divert from this to better SSI approach. And as probably Voltaire said: "Perfect is the enemy of good".

[OBIvision]

We are already living in this "total surveillance" for 6 years since eIDAS 1.0 federated centralized identity system launched in 2018.

Correct. The problem has been steadily growing over the last decades and the failure of eIDAS 1.0 on security was obvious.

There was no citizen uprising because of this I'd know about.

Well. You got the unlinkability requirement in eIDAS 2.0, DMA and the raising requirements to enforce GDPR. That is how a democracy say - "Get you act together or go to jail".

Now we have possibility how to divert from this to better SSI approach. And as probably Voltaire said: "Perfect is the enemy of good".

SSI is the nightmare, we have in BigTech and e.g. in Denmark - everything collapse when unrestricted power takes control. This is exactly what need to be eliminated with eIDAS 2.0 and the reason the unlinkability requirement is so important.

[stefan2904]

Personally, I think in eIDAS 1, there was no "uprising" or complaint or lawsuit because there were mostly government SPs, and people don't care too much if one government entity knows about you logging in at another entity. This drastically changes with eIDAS 2, hence the bigger focus on unobservability (and unlinkability, pseudonyms, etc).

[OBIvision]

Personally, I think in eIDAS 1, there was no "uprising" or complaint or lawsuit because there were mostly government SPs, and people don't care too much if one government entity knows about you logging it at another entity. This drastically changes with eIDAS 2, hence the bigger focus on unobservability (and unlinkability, pseudonyms, etc).

First - it doesn't really matter what you think people care about. Human rights are mainly about protecting citizens from governments.

Second - the public sector have become immensely more important with BigData AI as we now se governments doing the same as BigTech, only worse.

Unlinkability is priority in public sector, but the publi8c sector also cover issues where it require more to design good security, e.g. taxation, healthcare, research, anti-crime, border controls, schools, social etc.

[paolo-de-rosa]

Dear @alysyans,
Thank you for sharing your feedback. Your proposal is indeed an interesting approach with strong potential for privacy preservation. However, as you correctly point out, there are crucial aspects of the eIDAS regulation, particularly at Assurance Level High, that need to be analysed and thoroughly addressed before this solution can be fully considered for the EUDI Wallet.

Identity means at Level of Assurance High
The eIDAS regulation requires that the EUDI Wallet is an electronic identification means at Level of Assurance (LoA) High, and as such must comply with the corresponding requirements in Commission Implementing Regulation (EU) 2015/1502. Apart from stringent identity proofing and verification procedures this necessitates a robust binding between the digital identity and the holder. This is typically achieved with cryptography involving keys stored on secure hardware such as secure elements or (remote) HSMs. Anonymous credentials as described, while excellent for privacy, may present challenges in establishing this strong binding and making it verifiable by a Relying Party. Another requirement in Commission Implementing Regulation (EU) 2015/1502 for electronic identification means at LoA High is that such identification means must be tamper-proof and duplication-proof. Again, complying with such requirements requires the use of secure hardware. These measures ensure that the electronic identification means are not compromised or duplicated, thus maintaining the integrity of the identity verification process. Achieving this level of security with anonymous credentials may require additional developments or modifications to the existing protocols.

Revocation of Attestations
Revocation mechanisms are essential for managing the lifecycle of digital identities and maintaining trust in the system. The eIDAS regulation requires that attestations can be revoked under certain circumstances. While revocation can be implemented with anonymous credentials, it might introduce complexities, and it does not seem to be entirely solved in the proposed approach.

Hardware Support and Cryptographic Functions
The Regulation does not put any requirements on the device on which the EUDI Wallet is installed. From the recitals in the Regulation, the Wallet is intended to be used on (mobile) devices that are already in possession of users. Current devices, and in particular the secure hardware available to these devices, may not comprehensively support the cryptographic functions (such as Pairing-Friendly Curves) required for anonymous credentials. Implementing these functions in hardware could therefore prove challenging, potentially necessitating modifications to existing designs or the development of new hardware modules. This could subsequently impact the cost and complexity of EUDI Wallet implementations, as well as jeopardizing the timelines for introduction of Wallets by Member States, as required in the Regulation.

Conclusion
We appreciate your insightful analysis and recognize the potential of your proposal to enhance privacy within the EUDI Wallet. While your approach is promising, we must ensure full alignment with the stringent security requirements of the eIDAS regulation, especially those specified in the Commission Implementing Regulation (EU) 2015/1502 for Assurance Level High, as well as adhere to the timelines for the introduction of Wallets by Member States. We believe that by fostering collaboration between cryptographers , policymakers, and industry stakeholders, we can bridge the gap between privacy preservation and security, ultimately achieving a robust and privacy-preserving EUDI Wallet implementation.
For this reason, we welcome further discussions to explore potential solutions and refinements to the current architecture. In particular, we aim to collaborate with you on introducing a Zero-Knowledge Proof (ZKP) solution in the EUDI Wallet that supports holder binding and revocation, that can be implemented in the secure elements/HSM available in the market. To delve deeper into this topic, we propose scheduling a follow-up meeting in July.

[OBIvision]

Dear @paolo-de-rosa

You write

Identity means at Level of Assurance High The eIDAS regulation requires that the EUDI Wallet is an electronic identification means at Level of Assurance (LoA) High, and as such must comply with the corresponding requirements in Commission Implementing Regulation (EU) 2015/1502. Apart from stringent identity proofing and verification procedures this necessitates a robust binding between the digital identity and the holder. This is typically achieved with cryptography involving keys stored on secure hardware such as secure elements or (remote) HSMs. Anonymous credentials as described, while excellent for privacy, may present challenges in establishing this strong binding and making it verifiable by a Relying Party. Another requirement in Commission Implementing Regulation (EU) 2015/1502 for electronic identification means at LoA High is that such identification means must be tamper-proof and duplication-proof.

Agree - and of course this raise questions as to the use of smartphones without dedicated hardware for Level of Assurance (LoA) HIGH in general.

However if you combine BBS# with Trustworthy PKI you get compliance on all the critical aspects at the same time - including strong protection against transfer of device/key control. Point is that Trustworthy PKI and anonymous atomic credentials can operate WITHIN the standards as it essentially just eliminate the CA man-in-the-middle aspect of pseudonym PKI certificates.
https://www.edps.europa.eu/system/files/2022-07/03_-_stephan_engberg_-_edps_trustworthy_pki_engberg_20220622_en_0.pdf

The only thing that is somewhat unclear is the explicit definition of Pseudonym PID - you cannot require e.g. name and maintain unlinkability at the same time so you need proof from the underlying math and/or hardware certification.

In this context, the Cryptographers Feedback advocating shortlived keys (graceful degradation in wider terms) over revocation is a critical aspect to observe.

[ad-Orange]

@paolo-de-rosa

To delve deeper into this topic, we propose scheduling a follow-up meeting in July.

July is very near by now, can we schedule this meeting ASAP ?

[OBIvision]

Dear @paolo-de-rosa.

Whereas assurance levels are indeed critical, two fundamental problems arise here.

a) We need QUALIFIED ANONYMOUS SIGNATURES at all levels of assurance meaning that Relying Parties can implicitly verify that the signature in question is bound to one entity and all credentials are related to the same entity. From there new credentials can be added to customize the identity to context.

Here the ARF are far behind e.g. U-Prove and IDEMIX (IDEMIX, all use-time blinding models with multishow unlinkability, then have a massive problem as it depends on revocation forever making smartphones based solution unsustainable as smartphones are lost constantly and probably cannot be sufficiently secured for LoA High).

b) The present ARF structure DO NOT CONTAIN ANY COMPLIANT SOLUTION able to establish an unlinkable qualified signature which is absolutely minimum for basic society processes to work.

Part of the problem here is that the main Use Cases are not taking citizen rights and security into consideration, they are all surveillance-based and should be enabled trustworthy secure.

A particular instructive use case is age verification in connection with access to porn sites - you need qualified anonymity, payment verification, age-verifying proofs and perhaps accountability at the same time while maintaining unlinkability.

Another instructive Use Case is Schengen requirements in connection with anti-terror airport security. You need strong, but still unlinkable verification with LoA High. Related to e.g. temporary residence, you also need special models to kick in in case of failure to leave the country again which is easy in a surveillance-approach, but require careful design in a unlinkable Schengen setup where you e.g. cannot collect biometrics.

If these issues are not addressed urgently, the ARF will fail to provide.

[rmayr]

In terms of certification for LoA High, do we already have specific targets or are these also under discussion as indicated by the parallel ATAG?

The context of this question is that a notable set of hardware in current smartphone implementations already carries various certifications, e.g. the Qualcomm Snapdragon 888 SPU with EAL4+AVA_VAN.5 (https://www.tuv-nederland.nl/assets/files/cerfiticaten/2021/12/nscib-cc-0227918-cr.pdf), the Samsung S3K250AF with EAL5+ (https://news.samsung.com/global/samsung-introduces-best-in-class-data-security-chip-solution-for-mobile-devices), or the Google Pixel Titan M2 with BSI-CC-PP-0084-2014 (also EAL4+AVA_VAN.5, https://www.commoncriteriaportal.org/files/epfiles/NSCIB-CC-2300073-01_CERT.pdf). It seems possible that the same hardware can be made capable of creating full BBS(+) signatures with only a firmware update, and to certify that implementation, basically retrofitting existing hardware in the field. Which certification schemes would most likely relate to the LoA High requirements from https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015R1502 ?

Detailed questions about the curves to use and potential (minor) modifications to BBS(+) are certainly open, and we should keep discussing options for reaching both the security and privacy requirements outlined in the regulation.

[ckahlo]

@rmayr "only a firmware update" on a security controller is a quite tough estimation. Well, you could talk to Qualcomm and THALES/Samsung for their Secure Element if they would implement that. The Titan M2 is a quite proprietary device, not a GlobalPlatform Secure Element AFAIRC.

Another (may be even better option) is NXP SN220 (https://www.tuv-nederland.nl/assets/files/cerfiticaten/2022/04/nscib-cc-0428888-1m1-stlite_v1.1.pdf) using NXPs SecureBox to implement BBS+ and the needed curve primitives - probably the fastest way to market.
For Samsung S3K250AF with THALES OS and NXP SN110/SN220 the BSI CSP (https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03181/TR-03181_node.html) has been implemented to deliver crypto primitives not available by standard APIs. This would be the right point to implement your suggestion.
I would recommend talking to BSI SZ1 Dr. Dennis Kügler as a starting point.

Edit 1: consider EAL4+ as the bare minimum for LoA high.

Best,
CK

[ckahlo]

@ad-Orange Anyway, I can confirm it works out.
BTW: Your notation is pretty unusual and does not adhere to the notation mostly used in other places and literature.
While k is instantly recognizable, R, r and s are not. M usually is h. i, j, x aren't used in other places. It probably would help others to express it in a more common way. Such as { r0, s }. And renaming your r to something different, suggestion b (for blind?).
b could also be calculated in a deterministic way depending on the relying party and credential - allowing something similar to restricted identification.

Basically I like your approach. While the scheme has to be analyzed for its BBS properties - the underlying implementation is NIST / SOG-IS compatible. That's a big step forward. PS: I see, it also has some more possible use-cases.

[ad-Orange]

@paolo-de-rosa
You might not have seen this article introducing BBS# we posted about a week ago and that we mentioned already in meetings with you. We think it answers your concerns (and more). I’ll copy the summary for everyone to be able to get an idea of what we’re talking about:

eIDAS 2.0 is a very ambitious regulation aimed at equipping European citizens with a digital wallet that not only needs to achieve a high level of security but also needs to be available as soon as possible for a large number of citizens and respect their privacy (as per GDPR). As of today (June 2024), it does not seem that this goal has been achieved in the European Digital Identity Architecture and Reference Framework (ARF). This document aims to propose the foundations of a digital identity wallet solution that could help move closer to this objective by leveraging the proven anonymous credentials protocol BBS (also known as BBS+) but modifying it to avoid the limitations that have hindered its widespread adoption, especially in certified infrastructures requiring hardware implementation. Thus, the solution we propose does not use bilinear pairings and only requires the implementation in hardware of well-known digital signature schemes such as ECDSA or ECSDSA (also known as ECSchnorr) using classical elliptic curves. Additionally, this solution can be implemented while adhering to the ISO mDL and SD-JWT protocol formats, allowing for its use not only in online contexts but also in face-to-face/proximity contexts. Furthermore, this protocol retains the well-known anonymity properties of BBS+, such as unlinkability and everlasting/unconditional privacy. We also introduce a simple method for plausible deniability for transactions related to services that do not require audits. We provide various improvements in terms of implementation efficiency (a single holder binding proof for verifiable presentations containing multiple (Q)EAA) and security (impossibility for a Wallet Secure Cryptographic Device (WSCD) to generate a proof without the holder's involvement), as well as a highly efficient new method to prove the non-revocation of (Q)EAA used in a transaction. We provide formal security and privacy proofs for our protocol (named BBS#); we believe that BBS# should be deployable quickly on certified infrastructures such as HSMs or SEs and should also simplify the implementation of eIDAS services that rely on the ARF. For example, proofs of non-revocation of all kinds can be done much more simply. Key management can also be greatly simplified, with only a single private key required on users’ WSCD. We believe that this proposal fully addresses the challenges posed by the eIDAS 2 regulation by ensuring GDPR's obligation to be state-of-the-art in personal data protection, while maintaining great deployment flexibility for wide and immediate availability and a certain ability to be certified quickly.

So if we match it to the requirement in your post, and reminding the basics (this is a BBS style protocol with all the privacy that comes with it – we actually added plausible deniability in addition to the “usual” BBS privacy features using a well known technics from 1996):

Identity means at Level of Assurance High

• Holder binding: yes, very efficient single ECDSA or ECSDSA signature.
• Works on SE or HSM: yes, ECDSA today on SE (or Strongbox or TEE). ECSDSA works today on many HSMs and tomorrow on anything building on top of CSP.
• Tamper proof or duplication proof: yes, security proof provided (with a strong hypothesis for ECDSA because it is intrinsically a weaker protocol than ECSDSA).

Revocation of Attestations

• Entirely solved: a privacy preserving method is included
• We don't see any particular complexity. Can you elaborate ?

Hardware Support and Cryptographic Functions

• No use of “pairing friendly curves”: yes, we use any curve that works with ECDSA or ECSDSA

Conclusion

• Do you see any other non-covered functional topic ?

I would like to know if you (or anyone else actually – especially the 6 people that thumbed your post up until now I guess) sees any issue with this, in particular with the underlying security model, or the proofs that are provided.

I would also like to understand why such a scheme would not be taken into the ARF in the very short term as it is the only proposal we know of today that allows both a proper security model and being compliant with GDPR.

[cryptphil]

Could you please elaborate on the point that a privacy-preserving revocation method is included in the proposed BBS# protocol?

As far as I understand, you only explain how revocation could be done in the "half offline mode", where the user needs to get this blinded proof, which is kind of similar to OCSP.
Do you also have a privacy-preserving proposal for the standard variant of BBS# in the verifier-local revocation paradigm, or did I miss it in the paper? Of course, one could alternatively combine your protocol with an accumulator-based solution, but the witness updating problem remains for the user, which unfortunately makes this approach still impractical.

[ad-Orange]

@cryptphil
You have a correct understanding of the situation: we have a solution when the user is online (by using "privacy-preserving non-revocation tokens") and otherwise accumulators have to be used. These tokens could be generated with a "short-lived validity" as suggested in the "Cryptographers' Feedback on the EU Digital Identity's ARF" document.

However we don't agree that the "witness updating problem" "makes this approach still impractical." and for multiple reasons, not the least of which being that in the vast majority of use cases, the users will be online. Especially for ID related transactions. Furthermore, when the user is offline, they probably were online recently, meaning that they could have updated their witness at random times to ensure that the updates to be retrieved at transaction time are minimal.
In anyway, if you have a better solution to propose taking into account all the constraints, we're all ears..

[cryptphil]

I think you misunderstood my comment with the "witness updating problem", it was related to revocation systems based on accumulators. There, users have to update their witness linear with the number of newly (revoked) credentials before being able to present a non-revocation proof. Except for the initial RSA-based accumulator, this would involve pairing operations for the user (although these could be performed outside of the SE).
Regarding the OCSP-alike approach as you have proposed for BBS#, I agree with the practicability.

Unfortunately, I don't know a perfect solution, but I also consider verifier local revocation systems with epochs as quite practical & privacy-friendly, e.g., this one, which could also be combined with BBS+.

[andy-tobin]

It would be helpful in this discussion to describe specifically which elements of the regulation (citing the numbered clauses) the OP believes are not satisfied by the tech proposed in the ARF, and which elements an anoncreds BBS+ solution would address.

I recall that some of the pushback on anoncreds early on was related to the underlying cryptography mechanisms (especially relating to ZKPs) not being on the NIST or SOG-IS approved list of acceptable cryptography mechanisms, therefore not usable by European governments. Is this still the case?

Lastly on revocation, the potential for correlation through embedded revocation information within credentials (eg the position on a status list of a revocation bit being a perfect correlator) is a very tricky issue to handle. It would be useful to understand how the ARF-proposed technologies manage this versus the suggested anoncreds BBS+ approach. I'll get my popcorn ready.

[jaromil]

Hi everyone! at the Dyne.org foundation we agree with criticism of EUDI ARF exposed by the paper in subject, in fact since months.

We started working on an alternative system to SD-JWT we name SD-BLS.

Our threat model includes revocation issuer corruption, since we believe that to be extremely relevant for civil society.

[jaromil]

@cryptphil thanks for taking the time to read the paper, I'm grateful your feedback. The speed measurement of revocation verification in absence of IDs is missing from the benchmarks, and this is a mistake in the current version of the paper, since that holds to the promise in the title mentioning unlinkable revocations. I will do my best to upload the updated version on arxiv ASAP. In my defense here I can only say that SD-BLS went through a lot of grinding in a very small amount time, with hard length constraints imposed by the IEEE conference publication format.

[jaromil]

dear @filip26 we have a C/Lua implementation of BBS+ already, just updating it to v06 of the RFC here dyne/Zenroom#909 and providing feedback to the upstream crew doing this very important work. I'll soon publish some benchmarks on what we can obtain with our approach.

However, we worked on SD-BLS on a side quest to fill in what I believe to be a big gap in EUDI ARF: the missing threat model it should have started in the first place.

SD-BLS for me is a way to establish a dialogue, after we have been totally excluded by the big guys so far, pointing their elbows in our ribs pretty much everywhere. With our paper we just intend to communicate a constructive approach that mentions the need for privacy-preserving revocation and shows how it could be obtained, admitedly at low TRL. We may use it or not in other applications and we hope it provides a benchmark for future ideas.

In conclusion, I believe that what matters is to have a threat model that includes all our concerns, also as civil society, which I mostly represent with my organization. Some good folks are listening at W3C and I'm happy to be a co-chair of the threat model community group https://www.w3.org/community/tmcg/

[jaromil]

@ad-Orange I am happy to take the blame for having introduced the subject of revocation in this thread, to the attention of many talented people, because I believe is a big mistake to overlook it. I am also very interested in your proposed solution, which is undoubtedly closer to final adoption than any other ATM. Thanks for the final pointers and the rust implementation, would be very good to have a math paper about it, we'll do our best to provide a Zenroom based implementation for it too.

[ad-Orange]

@jaromil
I’m not too sure what blame or what you’re talking about in general. Your paper leverages pairings. As explained by @paolo-de-rosa above, it does not comply with the requirements of the commission.

I’m not sure either what you’re referring to with revocation and it being supposedly overlooked: accumulators exist for a long time already and we just pointed to a pairing free accumulator implementation by dock.io. All of that is unlinkable when done properly. If you’re talking about the lack of a proper revocation mechanism in the ARF, yes it’s a serious issue. But there are so many serious issues in the ARF… otherwise I don’t understand what you’re referring to.

Concerning « maths papers », we have already posted a quite crypto heavy paper (and some people are actually complaining to us it’s to mathematically harsh). This paper contains security and privacy proofs. What else would help ?

Your colleague has posted a request for test vectors on the other thread. We’re looking into it.

[jaromil]

I don't understand why you are so aggressive, yes I refer to EUDI ARF and lack of revocation. I have seen that paper and is not really "math heavy".

[Wind4Greg]

Hi folks, if you'd like to get a feel for what a JavaScript only BBS implementation running in a browser feels like give my BBS Demo a try. This was used in talks to the W3C CCG and NIST about a year ago. The performance is feels pretty good, which is a helpful non-quantitative measure. Note that Typscript, Rust, and Java implementations of BBS are available too.

Also remember that the pairings computations are only used in signature and proof verification and not in signature or proof generation. We're currently updating the Blind BBS and BBS Per Verifier Id drafts. If you have feedback let me know, join the BBS DIF discussion group, or use the CFRG mailing list. Cheers Greg

[ckahlo]

@ad-Orange I can fully confirm that.
However, after reformulating parts of the BBS# approach I got a BSI colleague to have a deeper look into BBS#.

[ad-Orange]

Thanks a lot @ckahlo. Is it clear to you that even though BBS# can work with pairing, we're also providing a solution that doesn't need pairing ? (I think it is but from your previous message I wasn't 100% sure).

[ckahlo]

@ad-Orange Crystal clear. That's the reason why we would support it.

[lanterno]

@Wind4Greg Love your demo! if it's open source, please do share. 👍

[Wind4Greg]

Hi @lanterno I just posted the demo code at https://github.com/Wind4Greg/bbs-demo. This uses Vue.js and bootstrap. I've been making a BBS pseudonym demo using Vue.js and Vuetify but its not in shape to publish on the web. The usual caveats apply: (a) SE hardware like TPMs don't generally support BLS12-381, (b) no national agencies are currently supporting/endorsing pairing base crypto. Other than that its well establish 20+ year old technology well on its way to standardization and easily extends to blind signing and pseudonyms of various flavors.

[camgeer]

I've been in and out of this thread this week and now see it's a discussion. Good!

In the context of anonymous credentials, I wanted to be sure people are aware of AnonCredsV2:
https://github.com/hyperledger/anoncreds-v2-rs

Concretely, AnonCreds v2:

Is intended to retain the objects from AnonCreds v1 -- the credential schema, credential definition, presentation request, and presentation.
    Although none of the objects are identical to those in AnonCreds v1, the interactions with the objects are the same. This will enable a path for migrating implementations from AnonCreds v1 to v2.
Substantially increases the information included in the [credential schema](https://github.com/hyperledger/anoncreds-v2-rs#credential-schema) about the claim types such that the encoding and cryptographic handling of the claims can be enhanced to provide more:
    capabilities - additional ZKP presentation options and different, swapable signature schemes
    performance - via support for different signature schemes
    extensibility - additional ZKP presentation options and different, swapable signature schemes
    security - support for more secure signature schemes
Supports [PS Signatures](https://eprint.iacr.org/2015/525.pdf) in the current implementation and can be updated to support [BBS+ Signatures](https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures)
    The [BBS+ Signatures](https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures) support has been tested in this implementation in the past, but is not part of the current codebase.
    [CL Signatures](https://eprint.iacr.org/2001/019.pdf) could be used.
    PS Signatures have a [post-quantum option](https://eprint.iacr.org/2022/509) that will be experimented with in the context of AnonCreds v2.
Supports additional kinds of ZKP presentation capabilities, including:
    Signed integer expressions
    Range proof
    Domain proof (also known as a per verifier credential identifier)
    Set membership
    Verified encryption
    Blinded secret
    Equality proof of claims from different credentials
    Revocation
Supports revocation in a substantially simpler and more scalable way using the [ALLOSAUR](https://eprint.iacr.org/2022/1362) revocation scheme

Forgive me if already posted.

Cheers-Cam

[camgeer]

@andy-tobin @paolo-de-rosa for the revocation discussion the team should take a look at this:

https://hackmd.io/LGlyexsRSBqrm7TIKzzZ_A

Privacy Preserving Scalable Revocation

Introduction (much more than this)

Revocation is one of the most difficult aspects of any credentialing system. PKI (Public Key Infrastructure) uses a "phone-home" system where clients check with the issuer whether the certificate is still valid (not-revoked), thus no privacy. Other proposals based on PIR (Privacy Information Retreival) require clients to download the entire [3, 4] (or a big enough subset) list of valid entries, disclose their unique index or identifier and check this against the list. While this approach allows the presenter to remain anonymous with the issuer, it does not achieve privacy with the verifier.

Some accumulator based approaches require publishing updates when entries are added and removed which requires clients to download large lists to perform local updates and stay in sync or "phone-home" to the revocation manager. Neither approach is scalable and privacy preserving. Downloading large lists penalizes users who do not stay constantly current since they must download all changes since their last update, leaking how long they've been offline, and in some cases is not cryptographically secure (see [1] for these details). Other accumulator based schemes have been proposed [5] that use static lists created at initialization time but again require downloading large amounts of data which can cause issues when checking for current status.

The most common non-privacy approach requires users to "phone-home". The "phone-home" concept is defined as the holder revealing their revocation claim to the issuing party (or intermediary) to determine their revocation status. Either the holder does this directly or the verifier forwards the claim to the issuing party. In this manner, the revocation manager either returns another credential with the current status or gives the status directly. The additional credential can be good for a single presentation, includes date times like expires after or at, or some other method. This is also not privacy preserving as the revocation manager and/or others learn unintended information about the presenter. In many cases the revocation claim being checked is a unique value. This value can be used to track the presenter across uses which is undesirable much like a tracking cookie.

To be both scalable and privacy-preserving, the revocation scheme must meet the following requirements:

The number of issued credentials must not impact the time to check revocation status i.e. must remain constant for the verifier.
Client updates must not depend on the time since their last update.
Updating revocation status must not leak either the precise client requesting the update.

[ad-Orange]

This method still requires pairing friendly curves, right ? Even though it's on the revocation process, it still means you need them in the SE at the end.

[andy-tobin]

Thanks for this, I’ll take a look now.

[andy-tobin]

What’s the latest thinking on the utilisation of a trusted “Revocation Service Provider” (RSP) that provides an intermediary service for revocation status checking?

In this model, the issuer publishes cred revocation status info to the RSP. The RSP provides a relying party with a yes/no answer as to whether a presented credential is revoked. Or the holder contacts the RSP and then provides a ZKP or signed RSP response to the RP confirming their cred isn’t revoked?

Obviously the RSP is the correlation point here, but it’s easier to regulate and monitor a small number of RSPs than it is to try and manage thousands or millions of issuers.

[jaromil]

The issue we have with centralized revocation is RSP corruption. I.e. imagine being an Hungarian journalist criticizing Orban's government, which with the advent of EUDI has access to a "one-click" solution to revoke your ID, driving license and other credentials. If they'd like to ruin your life, they don't even need to find you are anymore. With a yes/no API it would be even difficult to prove a certain credential has been revoked at a certain moment...

[rmayr]

I do not believe that there would be a way to achieve unlinkability/unobservability guarantees under collusion assumptions with RSPs, but would love to see proposals that do so.

…

On June 30, 2024 2:35:44 PM GMT+02:00, Andy Tobin ***@***.***> wrote: What’s the latest thinking on the utilisation of a trusted “Revocation Service Provider” (RSP) that provides an intermediary service for revocation status checking? In this model, the issuer publishes cred revocation status info to the RSP. The RSP provides a relying party with a yes/no answer as to whether a presented credential is revoked. Or the holder contacts the RSP and then provides a ZKP or signed RSP response to the RP confirming their cred isn’t revoked? Obviously the RSP is the correlation point here, but it’s easier to regulate and monitor a small number of RSPs than it is to try and manage thousands or millions of issuers.

-- Written on my mobile phone. Please excuse typos and excessive brevity.

[andy-tobin]

Yes, agreed, however it would be much more feasible to manage/regulate one RSP rather than many issuers/relying parties.

This would be an approach that could be used where no sensible technical solution is possible, and something is needed that is pragmatic and workable at scale.

[sander]

How to standardise BBS
The ETSI TR 119 476 v1.2.1 report on selective disclosure and zero-knowledge proofs lists in § 7.4 “Feasibility of BBS+ applied to eIDAS2” several recommendations to make BBS schemes applicable in the future.

How to implement BBS at the issuers
In addition to these, in the case of QEAA and PuB-EAA, not only the holder WSCD would need to support BBS, but also the issuer QSCD. This is the qualified seal creation device that is required to sign QEAA and PuB-EAA in (EU) 2024/1183 Annex V, point (g); Annex VII, point (g); (EU) 910/2014 Article 3, point (32). Typically it is an HSM configured for local or remote access to nationally admitted functionality.

The Compiled list of QSCDs does not yet seem to contain any QSCD with BBS support. Adding a new QSCD with BBS support requires:

• specification and development of the HSM cryptographic module implementing BBS;
• Common Criteria EAL4+ certification of the BBS implementation against the EN 419221-5 protection profile;
• optionally Common Criteria EAL4+ certification for remote access to BBS functions against the EN 419241-2 protection profile;
• qualification by a Member State’s designated body, that has some policy regarding admissible algorithms, possibly based on SOG-IS.

Getting a single product through this process within two years is a significant challenge, given the need for specialist labs and authorities with full backlogs. We would need an industrial transformation though, in which multiple vendors provide QSCD solutions that issuers can tender early enough on their implementation roadmap. This requires a substantial coordinated effort.

What to do in the meantime
In the meantime, the EU Digital Identity needs transitional solutions. For example, one proposal for batch-issued attestations is Hierarchical Deterministic Keys at #282.

To additionally address the untraceability requirement, we could explore creating an issuer signature not for each individual attestation, but for a large enough batch of short-lived attestations (sander/hierarchical-deterministic-keys#1). All attestations for all subscribers for this issuer would be mixed together. This way, the issuer signature does not provide extra information: relying parties only learn that two attestations were issued during a single time window by a single issuer. This fact they could learn from the issuer ID and timestamp anyway. This approach seems compatible with today’s QSCDs. It also reduces the operational load for issuers.

[ad-Orange]

Once again, I don’t know what you mean by “issuer context”, but to be more precise, if a holder makes a VP including 2 VCs / (Q)EAA coming from 2 different issuers, and if these VCs are SDed in a way that they reveal no identifying attribute (all identifying attributes are hidden by selective disclosure), even if the verifier colludes with the 2 issuers, none of the 3 (nor the 3 combined) will be able to know to which holder any of the VC belongs. I hope this clarifies things a bit.

[OBIvision]

Once again, I don’t know what you mean by “issuer context”, but to be more precise, if a holder makes a VP including 2 VCs / (Q)EAA coming from 2 different issuers, and if these VCs are SDed in a way that they reveal no identifying attribute (all identifying attributes are hidden by selective disclosure), even if the verifier colludes with the 2 issuers, none of the 3 (nor the 3 combined) will be able to know to which holder any of the VC belongs to. I hope this clarifies things a bit.

Sure. But lets not forget to ask how the issuers gets the data unlinkable in the first place and how to combine credentials from two unlinkable issuers ! Otherwise you can only issue credentials originating in surveillance-space.

[ad-Orange]

The issuer gets the data unlinkable by signing them in a way that the holder can then make them unlinkable in VPs. That’s actually the main idea of the modern BBS line of protocols and is not specific to BBS#.
The way to combine credentials coming from different issuers does not involve the issuers and is some crypto done only on the holder side (it kind of involves a combined proof that you control the public keys signed in each of the VCs).
I’m not too sure what your last sentence means but would love to be able to comment it and provide more clarity to you as to how BBS# can help in these matters.

[ad-Orange]

The functions @ad-Orange mentions are out of scope for the issuer QSCD. The QSCD takes (hashed) data as input and creates digital signature values as output. The purpose is to prevent theft of private keys during this process, not to prevent abuse. The theft prevention enables the eIDAS claims of origin and integrity of the data: only the user of the QSCD could have created the seal.

Yes. And the goal of it all is to maintain a sane trust model. If the HSM signing public keys inside QEAA is not also checking the incoming proof of identity (typically the PID) presented by the holder and all other presented proofs (including the non revocation of the WSCD and its certification level, the fact that the public key to be signed corresponds to the same WSCD as the PID, etc…) and it’s all checked in software, then the whole trust model is broken. No need to protect the private key if anyone (at level high) can sign whatever they want with this private key: you’ll be sure that it’s the QSCD signing it but you’re not sure about what they’re signing, including the public key. As long as the public key is right, the trust model holds because you can trace back (if required by the service) who did what, even if it was fraudulent and quickly deactivate everything. If you have free running public keys in the nature, QEAA can be transmitted, used by multiple parties and leveraged to get further illegitimate (Q)EAA without any proper way of tracing back what happened.

Indeed the issuer’s trustworthy system that applies the QSCD needs to securely perform application functions such as:

• holder authentication, for example using person identification data

Within this system, a software application controls a QSCD using some system user credentials registered at the QSCD.

As explained, that’s probably not enough for secure issuance.

But the application does not need to be hosted on the QSCD itself. And the trustworthy system does not need to be qualified by a Member State’s designated body.

I would disagree with that, as per above.

Instead, a conformity assessment body needs to be convinced that the system is trustworthy. For example, they may require a certificate system to be audited against the non-Common Criteria technical specification CEN/TS 419261:2015.

As per above, if I were them I wouldn’t be convinced that it’s « Trustworthy » unless the process is atomic on an HSM.

For the application functions you mentioned, industry-standard specifications should be developed at CEN, IETF and ISO. However, (EU) 2024/1183 does not require such industry-wide standardisation like it requires usage of a QSCD.

Then it’s either a mistake of (EU) 2024/1183 or due to the trust model not being clear enough yet.

[sander]

From a legal compliance perspective, the scope of QSCD is just like I describe. See for additional context: HSMs Largely Protect Keys from Theft Rather Than Abuse.

Indeed issuers of high-security credentials may want additional protection by executing the mentioned security functions within a trusted execution environment. This environment may be the QSCD, running an additional local client application, but also some separate server.

As far as I can see, applying trusted execution environments for credential issuance is not an industry standard requirement anywhere yet. Even in WebPKI most certificate authorities seem to run their main software on regular servers running in secure network zones, just relying on HSMs to protect against key theft. At @cleverbase we do apply a trusted execution environment for issuing some qualified certificates.

Transaction protection within HSMs is common in payments (Payment Card Industry PIN Transaction Security Hardware Security Module) and getting more common in account recovery (Escrow security for iCloud Keychain, Signal Secure Value Recovery, WhatsApp HSM-based Backup Key Vault). So far, credential issuance seems to rely more on public monitoring systems (Certificate Transparency, Key Transparency).

[ad-Orange]

First independent implementation of BBS#

dock.io, a well-recognized actor of the SSI space has made a first independent implementation of BBS#.
Interestingly, it does not suffer from potential timing attacks, does not use pairing anywhere and implements real time but unlinkable revocation through pairing-free accumulators. It is usable with both ECSDSA/ECSchnorr and ECDSA.
A suitable ECDSA API is available for iOS since version 13 and for Android since version 11. For the devices implementing it with an EAL4+ certified SE, this shall therefore be compliant with the requirements expressed by the commission and whose match by
BBS# are detailed here.

[andrea-dintino]

First independent implementation of BBS#

@ad-Orange we have our own multiplatform open source implementation of BBS+, we can do all the signatures in EUDI-ARF so now we're looking at BBS#. We're also looking at the rust implementation from dock.io, but we use C and LUA for our cryptographic virtual machine.
We're a bit a lost with the paper though...Could we get in touch?

[ad-Orange]

Hello,
Thanks for your interest in BBS#. If you don’t mind I think it would be better if these questions are asked publicly so that we don’t have to repeat the answers to other people (who probably will have the same questions as you).
So if you can ask them in this thread, we will happily try and answer on a best effort basis.
I hope this is somehow satisfying for you.