Wallet Security Mechanisms for the Decentralized Ecosystem

Yeah. Hey, so as he just mentioned, is the German National Apprentice office where the issue of analog high security documents like the EID card, passport driving license, all kinds of things, but mostly now also looking into to the electronic versions of those, and therefore, naturally, of course, interested in world security because we want to enable to issue high security credentials.

So yeah, what's the motivation for world security? What do we want to protect?

Of course, I don't have to explain IDAs. I think it's, it's the main topic nowadays. We want to secure the assets that we have in the wallet, especially our high security credentials, pit, MDL, et cetera. They also mostly are regulated use cases, the high security credentials, and therefore we have, yeah, the requirements from law to achieve a certain security level with those. And so we have to see what's the wallet's job in ensuring these high security features. It is about ensuring that the legitimate authenticated user is actually using these credentials.

Because if we look from a verifier perspective, there's other security features like data authenticity and data integrity. We make sure that the data is actually correct. It's not manipulated, it's coming from an authentic issuer. This is all covered usually by digital signatures. So this is not the wallet's job. Then again, the verifier might be interested, is the credential cell valid? Is it revoked or not? This is also not job, not the job of the wallet, but it's about the user. Authenticity is the credential presented by a legitimate person. So this is what the wallet has to enable us.

And if we look what kind of credentials we have for user binding, I usually differentiate between identity credentials and attestation credentials. Identity credentials are the credentials that themself are an identity proof of my person. So the classic is the EID card or the passport. If I present this, this means I am Paul. If I have an attestation credential, for example, my diploma that only says Paul has a master's degree, if I show my diploma, nobody believes me that I'm Paul just because I own my diploma.

So that's, yeah, a basic differentiation that we have between those. And so the user authenticity then can be established through different means.

Again, looking from the very fast perspective, identity credentials was a credential presented by the legitimate person or for attestation credentials. It's more like our multiple credentials actually associated to the same person. And if we look into user binding, we see mainly four categories of this. On the left hand side we see two things that we know from the analog world. This is biometric binding and claim based binding and biometric binding. We would embed a biometric reference of the person into the credential.

This is the analog EID card, or my passport has a picture of me or claim based binding. Again, the example from the diploma, the diploma embeds claims like first name, last name, birthdate, that enable verifiers to associate is this diploma presented by or associated to the person that I'm interested in. And then usually I need to present a diploma together with A PID or another identity credential. On the other hand, we have the cryptographic bindings, and this is where it gets interesting. And this is also an early exit.

If you don't want to worry about all the hassle that's coming with wall security in the upcoming slides, you can take the first exit here and say, well, maybe I'm just only doing biometric binding or claim based binding. Then you can ignore the remaining parts of of the slides and, and take an easy exit, which is probably a legitimate path for issuers in the beginning of the ecosystem because lots of what I will present in the coming slides is, is not there yet and includes a lot of complexity.

And if you wanna look more about the different user bindings and how they compare, I encourage you to, to check out the QR link. It's from a presentation that I did two months ago at Transit digital Identity where I compare these. So what's interesting for world security is the cryptographic binding and this is what we will look into now for cryptographic binding, of course the most interesting question is how are my cryptographic keys stored? And there the A RF defines A-W-S-C-D, which is abbreviation for wallet security cryptographic device.

This is a temper proof resilient key store that also does the user authentication. So the user binding is kind of indirectly allowing access to this key. So if I authenticate to my WSCD, this enables the wallet then to use those keys and then using those keys I can present a credential and therefore achieve the user bin. And the WSCD is a central piece for most wallets as the choice of the WSCD has has major impacts on, on your wallet architecture, there's four different categories. We have a local WSCD or native WSCD that are in the device.

We have external ones like the EID card or we have remote WSCD, like an HSM. If we look in the WSCD landscape like we have today, we see that there's lots of different things, especially due to the fragmentation of the smartphone market. They all have different key attestations, they all have different level of assurances. They different, yeah, they differ a lot. And this is what, it makes it really hard for this ecosystem because this is probably too much of a burden for the issuers to, to deal with this varied landscape.

And therefore the idea of the WSCD is to abstract all of these kinds so that we get the information about the WSCD. Then later in something that we will see on the next slide, the WTE, but short again, what can A-W-S-C-D do? It has some kind of user authentication. It creates a user context where lots of my keys are embedded. I have A-W-S-C-D attestation. These are the key attestations that may differ from the actual hardware chip that we're using.

We can create crease, we can create proofs with these keys and, and maybe also show that these are associated, as I've said, we have a lot of different of those. So what is beneficial then that we have an abstraction of these different WSDs into a common unified format. And this is what wallet attestations or nowadays also wallet trust evidence is called are about, it's a key bound signed object. So it's kind of working as a credential as at a station itself. And it contains a public key for the wallet instance. It contains information about the WSCD.

It contains information how long this is valid. And by using those, we abstract the differences of the WSCD formats into a common data container. And where this is gets interesting if we want to issue a credential as an issuer, because we can now also use this concept of wallet trust evidence and say if we want to give this information to an issuer, we could call it an issuer trust evidence, which is similar to the wallet trust evidence. But we give the new keys that the PIT or the E should be bound to inside this attestation, which is signed by the world provider.

And so gives the pit provider the assurance that the world provider checked all these WSCD specific mechanisms. Moreover, it contains revocation information about the WSCD so that if there is a compromise of the WSCD, maybe there's a, a buck a security flaw, then the issuer could be aware later on and revoke his credentials. And the advantage is that the pit provider only needs to understand this common format. And underneath there could be a secure enclave, a cloud HSMA secure element, but for him it looks all the same. So it's more easily digestible to the, to the issuers and providers.

And what's very important for us is also that these issuer trust evidences should be issuer specific. So I'm not reusing the same one. I will fetch a new issuer trust evidence from my wallet provider for every issuer so that issuers cannot correlate. And we achieve un linkability as the last piece of the puzzle. We have the wallet instance attestation. And while the wallet trust evidence and issuer trust evidence is about the WSCD and the key store. The wallet instance station is about the wallet instance. So the IDA makes the requirement that users shall be enabled to revoke their wallet.

You can imagine them calling their wallet provider or they have a website where they can enter a passphrase or they maybe can even log in with some other credentials and they can say, well, I lost my phone. I want to revoke this. And so the world provider needs to be able to revoke or suspend the whole wallet instance. And this is where the wallet instance at station comes into place.

Again, it's a, it's a signed key bound object issued by the wallet provider. And this is what we can give then to the relying party. And it only attests that basically the wallet is a legitimate EUDI wallet and it is not revoked by the user. So it contains very few information, but it enables the relying party, yeah, to be sure that this wallet instance is legitimate.

And again, similar to the issuer trust evidences, we want to have relying party specific wallet instance adaptations so that relying parties cannot correlate and we achieve linkability. And I think for scalability reasons, the main idea here is to use very short-lived wallet instance attestations. So we get around using revocation for those. I've been working on this topic mostly for two years already. So I'm glad that most of these ideas are kind of picked up in the A RF.

I've started with Tobias one year ago to also bring this into standardization as the trend to OpenID for VCI has picked up for, yeah, I would say one and a half years. We then looked into bringing this into ITF and the OAuth security where open ID is based upon.

And the, we created a draft called attestation based client authentication. I linked it in the QR code. It was adopted by the OR security working group also. It is becoming an A real ITF standard and it standardizes the interaction between the wallet and the issuer in within OpenID for VCI. And we are, yeah, embedding the concepts of of the WTE and the WIA and how to bring them actually into the issuance protocols of E iida. It covers the interaction between the wallet and the issuer without making any constraints how the wallet instance and the wallet provider are talking to another.

So this is a deliberate yeah choice such that they could use any technology that may come up in the future. So we don't want to make use of these WS CD specific key adaptions and mandate anything. So we only say how the common format of these WTE and ites look like and how they're communicated to the issuer. The standard is then picked up in two important profiles, the open ID, high assurance interrupt profile, and the ISO 23, 22 oh dash three standard for issuance.

So yeah, we, we also already see that these are being picked up, but there are still a number of, yeah, specific questions about the lifetimes of the WTE or the contents. So while I think the general idea is getting quite clear, there's a few questions that remain.

This is, yeah, an example of how such an attestation could look like in a, this is in form of adjacent web token. It contains the issuer and the subject, which is then the wallet solution. It contains validity dates, it contains information. Which level of assurance is achievable with this. And of course, it contains a key that is coming from the WSCD itself. And optionally it could also say which WSCD and which user authentication mechanisms are behind this. And this is signed by the world provider and therefore issuers could trust this.

Yeah, that's a short walk into the, into the minefield of W-S-C-D-W-T-E and WIA. And if you have any questions, if, Thank you Paul very much. Thank you very much.

We, we could take one quick question if there is one. Have to be quick.

Oh, right at the back. You have to run. He's my helper. Hi Paul. So thanks for the great talk. So my question would be about the adoption of the field, let's call it like that, especially remote attest station part. And all that stuff involves in using platform attestation mechanism and so on. And right now, this mechanisms I think are not specifically tailored for your use cases. So my question would be to keep it short, how are you engaging with the platform providers, namely Android and iOS, to actually make their, the station services working with that?

Yeah, so the, the platform specific at station mechanism that you mentioned are only intended for like the app issuer. And, but this fits quite nicely into this context because you can use this platform specific adaptation towards the wallet provider who's the intended audience for this. And then the wallet provider can sign this WTE and then make this addressable to all issuers. So this actually, it's, it's quite a, it's quite a nice fit because we can kind of transfer and convert these platform specific adaptations for the whole ecosystem. Okay. Thank you Paul.