Unraveling eIDAS 2.0: A Practical Guide to the EU Identity Framework [Intermediate]

So, I'm of course the last speaker, so I'm going to start with a bit of brain training and I'm going to ask you how many seconds are there in two weeks? So, to help you out a bit, so it's one million two hundred and thousand.

So, Unraveling eIDAS 2.0, a bit of a practical guide. So, there are a lot of misconceptions and there are a lot of… So, I'm just going to frame it a bit and I'm going to even go back.

So, we started with doing IT and doing interfacing. So, what we do is we have two systems, they interconnect together and we started with wired.

So, we're doing networking, stuff like that and then at some point we did mobile. So, we have wireless connections and now I want to challenge you to think as the wallet as a data transport. It's just transporting data, but now to the user and maybe even offline. What does that mean?

So, we started with interfacing, so we have a connection and we're trusting the connection, so we know the data came through that pipe and we know where it came from and that's where we have customer authentication, we have PKI, we have TLS, all the certificates and we're using that to secure the connections. But the problem is that once we have a lot of connections it scales in a square, so that means that it gets spaghetti really quickly.

So, how do we solve that? We do federation. We just add a central node and we interface to the central node. It works really well. But there's a problem. Once you enter the federation network, you have access to all the data. You can and then the central node sees all the data, so there's a privacy and a scope issue and also there's a problem where a relying party needs to be compliant to the rules of the federation.

So, that means that there is a barrier to entry for relying parties and if we actually need users in there, so every federation solution needs to use authentication stuff, so it gets messy really quickly for users as well. And so, this is basically why complex large projects in IT across organizations fail, as we all know and if we have all witnessed.

So, that's also a problem. What we see in EIDIS too, we have the EIDIS nodes and we have all the different interoperability. But now we have a wallet. What does the wallet do? It is the federation node to the user where we are interfacing and exchanging the data to the user. But what that means is that I as a user get my wallet, have my wallet, go to an issuer and the issuer is servicing my wallet.

So, that means that the issuer is not interfacing with the relying parties. They don't even know who the relying parties are, so they just can focus on servicing the wallet. And now a relying party doesn't have to interact with issuers, they don't need a contract with issuers, they only need to understand how to get the data out of the wallet and understand which data comes from which issuer. And now the EU has done something really, really, really wonderful. There is a special issuer called the PIT issuer.

So, the EU is solving the identity verification problem for everybody. The EU, every member state is sovereign, so they need to figure out which wallet they want to service with their database of citizens and they'll issue a digital identity into your wallet. So now every verifier only needs to be able to read out the PIT and they have a strong digital identity of every user for free at scale.

So, if we go back to our history, that doesn't mean that we're going to replace everything. No, I mean we're still going to do direct connections, we're still going to do federations, but we're going to use the wallet to cut through federations across digital chains, doing complex digital transformations without the complexity of the federation.

So, that means that we have decoupling, so the scope of the decoupling between the issuers and the verifiers and the scope of the data exchange is one. I, as a wallet holder, go to an issuer, proclaim my identity, get my data, the scope of the data is me. And then I go back and distribute to a verifier.

Again, the scope of the data is me. So, from a liability point of view, the issuer knows it's me and he gives me my data. And from a verifier point of view, I deliver my data.

So, from a GDPR point of view, consent is arranged, etc., etc. But we get new capabilities. We have a wallet. In our wallet, I can see with whom I shared my data.

So, I have a transparency lock. So, when I accidentally drop my phone into the sea, I would really want my transparency lock back.

So, I need some kind of recovery. I have transparency with my transparency lock. I have consent because I consent to every sharing and for every acquisition of my data to an issuer. But what I also get is what we call data provenance.

I, as a relying party, am not getting the data through a direct connection. I'm getting it through a wallet to the user.

So, I need to protect the data itself because I'm getting it indirectly. So, that means that I need to develop a notion of provenance. Where should this data be coming from? Not from the user because the user can make up data himself. It needs to be for a trusted party further down the line. On the other hand, this is if I am sitting on a mountain of data and I want to share that through a wallet. Maybe I want to control who gets access to the data. We call that audience management.

Maybe you want to encrypt it and you want to assure that there is a legal binding and downstream what happens to the data. And the example I always give is if you have a drone that makes a video of something and you want to make a decision on that video, the data provenance is I really want to know that it's the video feed from that drone and not some AI generated video. But on the other hand, maybe I don't want to give everybody access to the data.

So, as a drone, I want to encrypt it and make sure that only authorized parties get access to the video. That part is also relevant for monetization of data because basically you can use that as a monetization platform where as a issuer you can encrypt the data, give it as a verifiable credential to the user, and then the user can deliver the data to a verifier. But the verifier needs to have a contractor relationship and a billing relationship in place to get the data decrypted.

So, EU reference architecture. We're going to focus on this one. And then we're going to do a couple things.

First, certificates. Everybody knows certificates. Everybody loves certificates.

So, we're going to get in there a bit. Then we're going to figure out what a wallet issuer does, what a PID provider does, and what a QAA or PPAA does.

So, basically QAA and PPAA are the same, right? It's just a different name from a governance point of view. And then at the end a signature.

So, let's go quickly. So, we have our framework and we need three things. We need onboarding. That's done for the PID issuer. We need a secure element because we need to figure out that it's a wallet we want to support.

So, we need to check the wallet. And we have issuers, right, that are servicing wallets.

So, let's look at it from a PKI point of view. PKI, we have registration authorities and certification authorities. I have a wallet.

So, now what do I do? I start registrating. I'm ascertaining the identity of a user, right? And then I'm verifying if the user device is correct. Is it a smart card? Is it secure? Etc.

And then, very importantly, from a compliance point of view, I need to create records. I need to have a record that I actually ascertained and checked and verified the identity. And then once the registration authority is done, I go to the CA. Now the CA makes a certificate, keeps a record of making the certificate, keeps a status responder so that you can check the revocation status, and I deliver the certificate in some way. The classic PKI, right?

Now, what does a wallet issuer do? A wallet issuer has a wallet, figures out if the quality of the wallet is correct, if the platform is secure, checks if the key is created in a secure element, hardware-backed storage, a key at the station, creates a record of that verification, asks the wallet unit at the station authority to issue a wallet unit at the station, creates a record of the issuance, has a status service in place, delivers the wallet unit at the station to the wallet issuer. Now I have a PIT authority. What does a PIT authority do?

A PIT authority has a wallet, they check the identity of the user, maybe physical, maybe remotely with NFC and biometrics, checks the wallet unit at the station, creates a record of that event, of that event, creates the PIT, creates a record of issuing the PIT, having a status of the issued PIT for revocation purposes, delivering the PIT to the wallet. Now, what does a qualified electronic attestation issuer do?

We have a wallet, we check the PIT, we check the wallet unit at the station, create a record that we checked it, check with the attributes if there is something in my database so that I want to issue a qualified attestation attribute, make a record of that, have a status of the issuing, and deliver it to a wallet. So now I want to sign a document, I have a wallet, I need to collect and authenticate the identity of the user, I need to collect the document, send it over, get authorization from the user, sign it, and deliver it to the user again.

So what do you see is that all these issuers need to become a QTSP. I need to have records and be compliant. Officially, the wallet attestation is not part of a QTSP, but it could be that it's relevant. So now the secure element part.

Basically, we have a secure element on passports, and that's why we can trust it. But if we look at the NISA, they made a nice overview of what a wallet is, and that's why Andreas also shows how complex it is. Every box here has its own complexity. The UI is complex, the interoperability is complex, the secure element is complex. So if we go into the secure element, what does that mean? Why do we need a secure element? Why can't I just use storage on a mobile phone or in software?

Actually, I always give an example where suppose you have a chip, just a processor, and I have a statement that if the pin is entered and it's correct, the pin check is true. Now what I can do is I can tweak the voltage of the chip. That's called the brownout. So what happens is when I do the pin check if statement, I can drop the voltage, but I won't reset the chip. I'll just make sure that it starts to wiggle a bit. So that means that the result of the calculation is random. Now if my check is if zero, then if one, then I just need one or two tries and I just hack the chip.

If I really programmed it correctly, I can basically have a large number there and I need a lot of tries. Let's say it takes me one second per try and I need a million tries. How long do I need to hack it? Correctly. So if a chip is not protected against this, you can do this. So what is called chips that are protected against this? Those are secure elements. And if we look at mobile phones currently in the market, not one secure element in the mobile phones is correctly certified against the IDES-2. So that means I cannot use anything that is currently in the market on mobile phones.

So if we then look at the RAF, there are four options to do that. I can do an identity card, I can do a mobile phone, Apple, Google, I can do an eSIM or a SIM card, or I can do a remote secure element in the cloud. So if I have an ID card, it's compliant, it's super scalable, it's easy to distribute, it's inclusive, I don't need anything as a citizen. But if I lose the card, I lose the keys. It's not user-friendly because I need to keep the card and I cannot issue it, I need to show up somewhere to get my card.

Now, on the mobile phones, they're not certified currently. So in theory, Apple, Google, the telcos could certify it, but then it will take a couple of years, at least 10 or something, to get a sufficiently high install base to get this done. It's not inclusive because I need new phones that are expensive to play, and if I lose the phone, I still use the keys. But it's super scalable and it's super user-friendly.

So what we at Eureka have done is we have created a remote secure element that you can remotely attach to a wallet with a direct connection that is already on the Article 20 trust list. So it's compliant, it's scalable, it's inclusive, and we get a new capability that we need in this ecosystem, recovery. It's user-friendly, and of course, you can issue it remotely. Here in Germany, they did an open architecture survey and basically this was their conclusion as well. So the only way to get scalable wallets is through remote secure elements. That was my message for today.

We're at time, but if there are any questions for Boris. Feel free to shout. For the last slide you had, what happens if you're offline?

Yeah, so one of the things that also happens out of the SprintD framework is this batch issuance of verifiable credentials. So that means that you can do batch issuance of verified credentials in two ways. You can do a lot of credentials so that you have a linkability to verifiers, but you can also use it to get short-lived local credentials for offline use cases. And that means that the verifiers then can basically have a policy if they want an online high secure qualified credential or an offline available credential.

So you can play around with the CIA part of confidentiality, integrity, availability, based on your remote secure element qualified identity, etc. Other questions? I thought most iPhone and Android since 2013-15 have secure elements, so I was a bit surprised by the last slide.

Yeah, so it's really funny is that there is a secure element, but that secure element is run by the platform. So you're not actually under control of the keys, the platform is under control of the keys. So that means that it's suitable for some use cases, but not for qualified use cases. How do you protect the access to the secure element so that no other than the intended user can use my key material? So I'm going to answer it in a different way. Let's say I had a proper certified secure element on the mobile phone, right? And I have my wallet.

In order to make a secure system, I need a trusted channel between the wallet instance and the secure element because I don't want to trust the platform in between for a man in the middle. So that means that you need to create a direct connection from the wallet into the secure element. And that's what we've built. What happens is, is once you have a direct connection to a secure element from a wallet, that means that you take the secure element, put it in a data center, and get exactly the same security guarantees as if it was local, but now it's remote. Absolutely. That's actually a drawback.

Because what happens is, is when you have secure elements, you want to attack them physically. If they're local, you can basically take it offline and attack the secure element until you've broken it. If it's remotely, you can monitor the direct connection, which is opaque and encrypted, etc., etc. But you can basically detect in real time if somebody's actually attacking the system. So that means that you also get a sense of the quality of your infrastructure and how many attempts there are, which is really, really, really valuable in these kinds of use cases.

Well, thank you very much. This was the Wallet Track.

Thank you, everyone, for having been here.