Hello everyone. Nice to have you here. My name is Christian Bormann. I work for the German UDI Wallet Project. Here with me is Anja Lehmann, who is a professor at the HPI for cryptography. And we want to talk about what can we do to enable anonymous credentials or zero-knowledge proofs for digital identity wallets. Digital identity wallets, just like most of you will be familiar with UDI or EIRAS, but like a brief introduction, all member states in the European Union are mandated to provide a UDI wallet to their citizens by end of 2026. That is what is currently happening.
Everyone is building a wallet. And we will have a first iteration of wallets rather soon. We are trying to figure out how can we improve and how can we make things better. The EIRAS legislation demands that we have a high bar of user data protection, non-discriminatory access, interoperability, high security. There are a lot of requirements and these requirements create some tension right now.
So if you look at the legal text, the technical framework of the European Digital Identity Wallet shall not allow providers of electronic attestations of attributes, that is what credentials are called in the EIRAS terms, or any other party to obtain data that allows transaction or user behavior to be tracked, linked or correlated. So really strong privacy requirements. Second one is enable privacy-preserving techniques which ensure unlinkability where the attestation of attributes does not require identification of the user.
So again, really, really strong requirements on privacy. Then we have strong requirements on user control. Users shall have full control of the use of and of the data in the European Digital Identity Wallets. The provider of the European Digital Identity Wallet shall neither collect information about the use of UDI wallet, then more. So really strong privacy guarantees, really user-centric system design requirements. And then we have super strong security requirements. And that has kind of created a tension which is really hard to properly fulfill.
So in terms of security, we have requirements on level of assurance, high at least for the PID. We need to use accepted schemes. So there is this ENISA, a transition to ENISA, the ACM, the agreed-upon cryptographic mechanisms. We require hardware certifications, and we require secure cryptographic device binding. So a lot of really, really strong security requirements paired with strong user-centric, like user control requirements and privacy requirements. So the outcome of that was a system where we have digital credentials built upon currently used and certified cryptographic schemes.
So right now everything is being built on top of ECDSA, like the usual digital signature scheme. And we have a bit of a problem there, because signatures by their design are linkable. So if I get a credential from an issuer, and I present it everywhere, that is linkable. We also wanted to have more control of the data being shown, right? So we invented tricks like using salted hashes to hide certain attributes to allow for selective disclosure. But we are kind of building on a system that was already a bit limiting for us.
For good reasons, because those were the requirements mandated by the law. So we found ways around those as well, right? So for example, for the linkability problem of signatures, we use batch issuance. Batch issuance means if I get one credential, I don't get it once, I get it ten times. And then I use every single one only once, and I throw away the credential and key afterwards.
And what basically happened is we are fulfilling the requirements of the law, but we are shifting a lot of the complexity of the overall system into the overarching infrastructure by batch issuance, by these kind of mechanisms. And especially batch issuance is kind of needed for every statement with a signature that might be linkable. And really important to understand, this is the credentials, so the PID or EIAs, QIAs, etc. But it's also the hidden parts of the system.
Like, for example, there are wallet attestations that are being used towards an issuer to signal, this is a certified, properly functioning wallet. So there is more to it than only the credentials. We need to batch issue single-use credentials for a lot of different things right now. And that creates a lot of tension and cost at the end of the day. So we have complexity and burden in the overall system and infrastructure. Issuers need to manage and issue tons of credentials.
Like, I'm not issuing one PID, I'm probably issuing batches of 10 every few weeks or whatever. And actually the wallets need to generate and manage a lot of keys. That is actually also not that simple. If you think about a wallet with 10 credentials, and every credential has 10 batches, you have 100 keys to manage. That is a lot of complexity. And there's also a bit of a privacy issue here because a malicious issuer would still be able to link. So I'm using separate signatures towards the different relying parties, but there's still the side of the issuer that knows those signatures.
So there's still some amount of linkability in this system. But what I would really, really like to push is, this is not only about privacy. Moving towards anonymous credentials for identity systems is a lot about efficiency. And that is exactly where we ask ourselves the questions, can we get to even stronger privacy guarantees and make the overall system simpler and more manageable? And that is where Anja takes over.
Thanks, Christian. If any one of you talked to a cryptographer in the last two years, then I guess you already know the answer to the question, which is, yes, we can do better. And more concretely, the answer is anonymous credentials. So anonymous credentials essentially work just like classical certificates. The user has a list of signed attributes from a trusted authority. But the main difference is that in the presentation, the user is never going over to send the signature, the credential over in plain, but instead she only makes what's called a zero-knowledge proof and that she has one.
And the amazing thing about zero-knowledge proofs is that you can only make valid statements, convincing statements, if the statement is true, so you really have a credential on these attributes. But at the same time, you don't reveal anything beyond the fact that it's true. So you don't reveal a single bit of information how the signature looks like from the issuer. And you can make as many zero-knowledge proofs as you want from the same main credential.
That means you get multi-show unlinkability for free from the same single credential, and you also get stronger privacy in this untraceability sense where also the issuer can no longer track the user. So we pointed to these anonymous credentials when we invited to give feedback with a couple of other cryptographers to the UADF and also said, this is nothing new. Practical solutions for building these systems exist for 25 years now. So the obvious question is, why haven't they been used yet? And there are two main problems or obstacles we have occurred.
The first one is that all protocols to be used in the UIDI context have to be standardized, simply for interoperability, but also as a sign of maturity. And the primary focus so far was the PIT, which is a regulated use case, and as Kristin said, requires even that all cryptography must be agreed on by the national security bodies within Europe. And there's a particular catalog of schemes, and before post-quantum schemes were added, this only contained signature schemes from the 80s and 90s, which are not compatible with these anonymous credential framework that we would like to build.
Another constraint that was considered to be a challenge was this device binding, because without that, a credential on the smartphone is just a bit string that you can easily copy and transfer across phones, which is nothing that we want to perceive as a good thing if it's an identity credential. We really want to make sure that the credential can only be used by the actual holder.
And the way that is done is by binding the credential to some cryptographic keys that live in a particular secure piece of hardware in your phones, and ensure that the user has access to that secure hardware within a presentation. And that relies on what's called secure element that has also to be on a very high level of assurance. And in these secure elements, at the moment, there's only a single signature scheme, again, from the 90s, ECDSA, which is particularly unfriendly for zero-knowledge proofs.
Which means if we want to get this zero-knowledge proof technology and anonymous credentials into the real world, we basically have to solve both problems. We have to standardize everything, and we have to make sure it's compatible with the hardware when needed. So if we look a bit closer, what it means, what do we have to standardize, and why do we have to get hardware support, we have to look at or we see three main components. The first component is the signature of the issuer. So the issuer has to still sign all the attributes of the user along with the device public key.
And that signature scheme should be as zero-knowledge friendly as possible, because that has the biggest impact on the complexity of the system that we can build afterwards. Also, if you want to have lower-high credentials, then obviously hardware support is going to be beneficial for that as well. Then there's another signature scheme hidden in that protocol flow, and that is the signature of the user.
As I said, the credential contains the user attributes as well as a device public key, and the user on her device has a secure element where the secret key lives in the DSK. And when she makes a presentation, she basically just makes a signature under the DSK over a fresh session that she receives from the relying party. And that signature scheme should also be somewhat ZKP-friendly. It actually has much more relaxed requirements, but here hardware support is absolutely essential to get that non-transferability.
What is a good impact of that mental picture, though, is to understand that the zero-knowledge proof, where all the magic happens, that basically just runs on public values. It runs on the credential that the user has, on the public key, on the signature that the secure element is spitting out on the device public key. So the entire zero-knowledge proof just runs in the wallet and the app. Nothing of that zero-knowledge proof complexity has to be run in hardware. But of course, we still have to standardize that for interoperability.
Okay, so these are the three things we have to instantiate, and now if we look at the current landscape of cryptography and what kind of our options are, as I said, we have to pick the signature scheme for the issuer, we have to pick the signature scheme for the device, then the zero-knowledge proof that we can build on top of that and see what is the impact on efficiency and other pieces of the system. And as I said, this is nothing new.
Cryptographers have invented a scheme that exactly fits the purpose, and that would rely on what's called a BBS signature for the issuer, that is, just using particular design patterns that makes zero-knowledge proofs trivial afterwards. For the device signature, we could use something as simple as a BLS or Schnorr signature, which are also very nice, simple signatures, and the proof on top of that is really trivial. It runs in a matter of a few milliseconds and a few hundred bytes.
So that is what we would like to use as a cryptographer, but I also come to the realization that unfortunately this is not possible in the next one or two years, because on the device the signature is not supported and apparently getting a software update on secure elements is impossible. So what we have to do if we want to get it out in the short to mid-term, we have to be using ECDSA for the device signature scheme, and that's the only thing that's there, and we have to live with that.
And we can be even more pessimistic and also assume that issuers, for some reason, cannot do anything else than ECDSA signatures. Then it's amazing that cryptography has made so much progress that we can now even build anonymous credentials on these very zero-knowledge proof unfriendly schemes with something that's called circuit or general purpose zero-knowledge proofs.
They even run within practical parameters now, but it really shifts all the complexity into this proof system, so that requires a highly optimized circuit and a very complex proof system, and that is an inherent challenge for security, for standardization, but also for extensibility, because currently, in order to get that, it's a highly optimized circuit for one particular presentation that you can make, and as soon as we want to make more features, we don't really know how to do this with our solution.
But it's going to be the only solution that works if we think that issuers cannot do anything else than ECDSA signatures. If we have more faith in the capabilities of our issuers, we can do something nicer and just say, okay, let's stick with ECDSA on the device. We cannot change that, but let's choose a signature scheme for the issuer that is very zero-knowledge proof friendly.
And the advantage of that is that we then can use this very simple proof system again that's just Schnorr proofs, one of the oldest proof systems that exists, and again runs in quite practical parameters, and it's much easier to extend and standardize. So it has really kind of a modular architecture to it, and we can easily put other features on top of that, or even swap out different components. So for instance, if we think this is not good enough for proximity use cases, we can plug in a different cryptographic protocol to do the device binding proof, which uses a tiny, tiny circuit.
Actually, it's kind of a bit wrong. It also uses Schnorr proofs and bullet proofs, and then we can get the size down to less than two kilobytes, and the solution is then also usable for proximity use cases. All right. And with these kind of problems solved, or the main problems of device binding, these different approaches, the BBS-ECDSA combination as well as the ECDSA circuit combination, are both considered for hopefully a future version of the UIDI wallet, and both protocols are undergoing standardization in Etsy at the moment. All right.
And with that, I'm really optimistic that we can see some real-world deployment of anonymous credentials. And to me, the main goal in the short or midterm is to show the feasibility and benefits of that technology, but also to shape sensible requirements, because what we are seeing today is that we're using the same set of requirements and technology for all use cases. And we have use cases where we're revealing our full identity, where we obviously want very strong security, but privacy is basically obsolete there.
And we have use cases such as HProofs, where privacy is at utmost importance, and at the moment, we require the same high level of security as if you want to open a bank account. And we have to understand that different use cases can come with different requirements in terms of security and privacy, and they have different solutions that fit these different use cases.
I'd also hope that we can use the next years to show all the additional features we can realize only with anonymous credentials, such as pseudonyms, blind issuance, issuer hiding, and so on, and also make sure that we can easily add that. And for that, again, a modular protocol is very important so that we can showcase all these features in the next years. And of course, we have to also build the protocol stack on top of cryptography and make sure everything is supported, for instance, in the data formats as well. In the long run, of course, we have to do everything post-quantum secure.
So the current solutions are post-quantum private, but have classical security or classical soundness. Post-quantum solutions exist, so we could already do something now, but a bit more time to flesh out optimal performance and have more faith in assumptions is a good thing.
And for that, all the work that we are currently doing with the classical discrete logarithm-based schemes is immensely helpful to figure out which properties are actually needed, what are the most stringent requirements we have to deal with, and also to see design patterns that we can then easily mirror in the lattice-based constructions as well. For instance, we're already seeing that some hardware APIs for MLDSA are not optimal, so that even the ECDSA tricks we could do now would not work with MLDSA.
But these are just minor changes, but we just have to make sure now that we are getting it right now. Otherwise, we will be stuck with suboptimal hardware APIs in the future.
Okay, but for both, I'm really optimistic that we have solutions that we can, as I said, push in the short midterm, as well have a plan for the long-term post-quantum solution. And the main message of this talk should really be that anonymous credentials, as Kristen said, can help to improve these deployment challenges, get rid of all the issues, and also improve privacy and security. The core challenges that hindered the deployment in the past have been solved, particularly device binding is solved. We have different options.
We're still working on different optimizations for other use cases, and standardization is also an ongoing effort. Of course, it will take some time, but at least for the simpler, circuit-free solutions, I'm pretty optimistic that we have something feasible by the end of the year. We do have different options on the table that are all kind of going for the same vision of anonymous credentials, and they have complementary trade-offs in terms of modularity, legacy, and complexity.
And if you want to think of what the landscape is, you could basically think of the following analogy that I tried to make. For me, the EIDA's regulation basically just says, let's fly to the moon, with all these very strong privacy requirements of unlinkability and so on. And I think they wanted to fly to the moon because they knew that scientists already invented a rocket. But then the EIDA says, but please go to the moon with a car for legacy reasons. And now we have spent quite some time to make sure we built even bigger rockets so that we can shoot a car, so ECDSA, to the moon.
It works, but if the goal was just to go to the moon, we can also just use a much simpler rocket that does the job. So I think that just kind of also matters to take a step back and figure out what we actually want. All right. And with that, if you're kind of curious about more details, there are a couple of papers that you can read up, and if there's time, I think we also have to take questions. Thank you. Thank you very much. This was really very interesting. Felt a bit like studying computer science, just with understanding a bit more a few years later. We have some questions.
I think two minutes left. The first one was, how much privacy are we realistically sacrificing once anonymous credentials become dependent on hardware backed trust and device binding? So that is a nice thing. With anonymous credentials and this proof over ECDSA, we are still fully unlinkable.
So yes, we are relying on an ECDSA signature and an ECDSA public key, but we make a zero knowledge proof that we know a signature under a public key without revealing the signature or the device public key. So the device binding is not harming any of the unlinkability requirements. That kind of was exactly the challenge that we had to overcome. And then another one. That is a long one. Can you also present data with ZKP or just proof a very specific claim means? Can ZKP replace classic presentation of the PID, for example, in order to solve the linkability issue, if I understood correctly?
I'm not sure if I understand the question correctly. So it can present any kind of data in theory. If we have very large inputs, we will probably need to hash so we can't do any proof over those attributes anymore. But in principle, you can prove any kind of data as well. Exactly. So just a certificate that you present in an unlinkable way, wherever this is helpful.
So I mean, there's a lot of use cases where unlinkability is not needed as soon as I reveal all my identity, but then also zero knowledge proofs actually add security to it as well. So something that I couldn't cover, but zero knowledge proofs not only improve privacy, but also security for these use cases of the PID, for instance.
Okay, perfect. So the person who asked the question, pretty sure you can reach out and ask maybe more specific if needed. Thank you very much. Great presentation.
