Thank you and it's great to be here and it's one thing I like about this conference is a lot of really good content. In fact I just want to talk about a presentation I saw yesterday by Boris Gorunov yesterday afternoon, Unraveling IDaaS 2.0 Practical Guide to EU Identity Framework. And the reason I thought that was important is he actually did quite a good introduction to this and he said you know one of the things that the Architecture Reference Framework talks about in the EU is that we should use a hardware security module.
And then he made the point that well there's a few problems with that. The first is is that the Apple iPhone and you know the various Android phones are not certified for the EUDI wallet system. Another point that he made is that if you want to get a hardware security module then you better buy an expensive Android phone like a Pixel or a Samsung. If you get one of the low-end ones they just won't have it. So there are these problems and I thought that was kind of a good introduction because we actually came at it from a different point of view.
So you know I'm kind of following the Asia Pacific line that we just had is that I'm not in the EU but the EU, all the work that's happening in the EU around the digital identity wallet etc can be kind of an inspiration outside the EU as well. So let's let's just go and have a look at that. One of the things I guess people say to me is one question I say is what is a HSM? What's a hardware security module? So in the context of this presentation it's a piece of hardware that's specifically built into one of these like iPhone.
You know this is a Samsung phone and the idea is is within that hardware security module you can create private public key pairs. You can export the public key to be used outside the secure element but the private key stays in the secure element and any operations where you need to use the private key happens within that secure element or the secure enclave or strong box, depends what you want to call it, many names. So think of a hardware security module as a safe way to storing the private key and executing them on the private key. So just a quick talk about Anonymous Labs.
So what is Anonymous Labs? What our mission is is to make people more secure, more private and more safe online. So we've kind of built a platform of a whole range of different services from secure communications to VPN to password manager etc etc and then you say well why are you up here talking about DI wallets and and verifiable credentials? It's some years ago we kind of realized there's a really good alignment of that to what our mission is which is trying to make people more secure and private online.
So that's how we got into the space and if you have a look at what we provide in this space is we sort of like full featured so we can issue credentials, verify credentials. We have a wallet SDK that's built in Rust so actually spent two years from the ground up building a wallet that implements all the functions and we built it in Rust so that we could have a native implementation for iOS and Android and that's the that's the SDK that we're going to talk about. If you have a look here and and we don't really need to talk too much about this.
I think I went to seven presentations yesterday on the EU DI wallet so I feel like I'm getting the hang of that one and probably a lot of other people are as well. But one of the things that's really nice about this work is the thing called the architecture reference framework.
In the last version I read which was about two weeks ago was 1.8 and then I got told 1.9 just came out and they do change as you go along so you've got to go back and read them again and it talks about things like verifiable credential formats and exchange protocols and being able to sign and it also has these interesting terms down here user binding and device binding which are kind of interesting and that's I think that that wasn't there right in their early 1.0 version but it means that if you get issued a credential that you can kind of prove that the user was issued that credential or that device was issued that credential and now we're starting to think why this is where HSM has come into it.
So we'll keep going there. So what does it say? So this is what IRF says about secure key management. It says mandate strong cryptographic protection for private keys and cryptographic operations. One thing I've noticed from reading 1.0 all the way through to 1.8 is that that's got stronger over time rather than less strong. In the beginning it kind of was a little bit maybe you could use it maybe you couldn't use it now it seems like it's it's getting pretty mandatory.
So it says HSMs are required to securely generate store and manage private keys using things like digital signatures, authentication, encryption, decryption and the HSM ensures keys are protected against extraction or unauthorized use. So if you go to something like an iPhone they've got a chip that one there's an A7. The actual secure element is inside that so there's not a separate chip within the mobile device that is a secure element but there's a secure element functionality within that A7 chip.
Okay a lot of people who have read the architectural reference framework would love to see love this and they know this diagram and it talks about the wallet instance and they're kind of the interface protocols and down the bottom where I've got that red ring there is where you talk about the HSM right so hardware secure modules and they talk about four remote HSM which is really what Boris was talking about yesterday he was saying well if you're going to have a HSM don't put it on the device put it up in the cloud right and then you have your private public keys up there so that's the first one that they talk about they talk about a local external HSM and it's what they mean by that is something like this and it's pretty hard to see that's like a YubiKey that's called a YubiKey 5c NSC and the reason why it's that because it's got a USB-C port on the bottom and you can also talk to it over NSC and then you've got the local internal HSM things like the secure elements that we're talking about down to in the operating system.
So let's talk about the term that most people are actually familiar with is this idea of holder binding.
I think most people are familiar with that picture at the top it comes from trust over IP and it's you know some people call it the triangle of trust I've heard other people call it the diamond of trust or something but essentially what it means is an issuer issues a credential to a holder which is usually a person holding a mobile device they then will do presentations of credentials to a verifier so they don't actually submit the credential to the verifier but they do what they call presentation proofs and why that's important is those presentation proofs can follow one of a number of different cryptographic protocols.
One of the aims here is that the issuer and verifier never need to talk to each other so I can get a driver's license I can present it at the bar and the bar doesn't have to report back to the DMV or the says you know just go on to the bar.
Below that is the verifiable data registry right there's some sort of trust layer and there's you talk about things like ledgers solutions ledger solutions the one that we focus on is the check network but there's other ledgers there's also non-ledger solutions all the way through to x509 but there has to be some sort of trust at the bottom and then you've got here it said the holder binding is a process that connects the credential to the identity of the holder in a provable and verifiable way it helps prevent impersonation and unauthorized sharing of credentials so the whole point of holder binding here is if that credential is issued from the issuer to the holder that no one else can use it and so then how do you enforce that that's what the holder binding issue is so what we looked at is is kind of around dids right and we said here we want to be able to bind to a decentralized identifier so the verifiable credential is issued to a did controlled by the holder so in in the experiments we did we're saying the holder has a did the issuer will issue a credential to that holder containing that the holders did or the subject did and then when the holder is presenting to the verifier they can see the subject did in the credential but they can also check a signature that the hold is done or the subject's done and again it proves possession the holder must demonstrate that they have control over the private key and it prevents misuse so it means that i can't be issued a credential and give it to somebody else right it looks something like this so the little c up there just means backing this is the check network but essentially if you go through what's happening is we want to generate a public private key pair in a hsm we want to export the public key and then create a decentralized identifier which is the subject did and what we do there is we use something like did key to do that to represent the user then when we go to issue it then i'm not going to go through all those flows but what happens is the issuer makes an offer to the holder to say i want to issue you a credential the the holder replies back with um here's my subject did the issuer puts it into the credential and then issues the credential to the holder then when verifying you know the verifier will say to the holder i want you to give me this presentation proof and that's the point at which both the issuer and the subject signatures can get checked and so what it means is if you've got a hsm in the holder then you know that that private key hasn't left the device and hence you you really have got a binding between um the holder and um the credential and this is to me is interesting well you know when i was listening to boris just say he's talking about well they're not certified the devices don't have them well actually that wasn't what we looked at we were thinking about it more from can you even make this work do the phones and the hsm's in the phones secure element a strong box do they actually support the cryptographic signing algorithms that you need so if you have a look at it here i've actually just put a table together that has like four different credential types so w3c credentials sdjwt got non creds and then the mdl and then within them you have the different signature profiles and that's not that's not exhaustive like if you go to the top one and say i want to do a json ld data integrity proof this is a presentation format there's multiple different cryptographic protocols that you can pick there and you pick it depending what your um your requirements are so for example if i want to do bbs plus right that's because i want to do selective disclosure and there's another version of it so you could actually i could have broken it into two roles which also supports zero knowledge proofs and then if you think about ed25519 people choose that because it's fast and efficient so there's reasons why you would say i want a w3c credential and i'd want a certain cryptographic profile for my signature but then the question comes is can it be supported by the hardware secure elements and then if you look at android it's you look at the top one there you'll see the p256 is supported rsa1 supported ios is very limited just got one tick there and then the yubikey we wanted to test you know having an external device where you can plug it into the phone or use nfc and actually it had the best cryptographic support out of all of them you can see the most green ticks but what it sort of told us pretty early is that the you know although we've designed these credentials with signature you know different different signature profiles things like the ios phone or the android phone they're way back here right they haven't got the support for those cryptographic protocols so it means that i couldn't use a if i wanted to use a w3c credential with bbs plus i just can't use a hsm so that's kind of one of the problems and it's it's kind of a different side to what boris was saying which is you know maybe we need to go to something external from the devices because we don't have good support so what did we do as i said we actually we've built what we call the edge agent sdk which is a wallet sdk so it's built in rust we build it from the ground up and um and it's it's a full wallet implementation so it can support multiple credential types multiple exchange protocols so if you said you know i wanted to use a w3c credential i want to pass it over a certain exchange protocol we can probably do that and we can support you know being issued a credential holding it and then presenting different presentation proofs so that's what we call our edge agent sdk and in fact if you go to the website there you know you can actually see the interface to that the the reason why we built it like that is for in some people think of a wallet as an app right it's an app i need a whole app and it's got to be the wallet but really that's not always true like if you're in a banking situation maybe they want a wallet in their existing banking app so what you want is an sdk so you can add that to the existing application and that was the reason why we went for a rust implementation is so that we weren't pulling things like javascript frameworks in right we wanted to have something was native um so we implemented three alternatives ios secure enclave android strongbox as i said we used a you know i've got a samsung phone to do the strongbox all the ios ones are pretty good and then the shuba key 5c nfc as well i call that experimental because what we really built there was an interface to be able to plug in different hardware security modules to it as i said it's all in rust it's all native rust um and and so now and we've actually released the edge agent now that we've released um it has this full support of these hsm so you can actually select um whether or not um you you when you when you're doing your development whether you want to choose hsm or not choose hsm and obviously you're pretty limited based on the previous one what are the conclusions well we could successfully implement against ios android yuba key with the limitations shown on that table there i've got a full demo and i'm going to show you the slide on that next but we haven't really got time for me to do the demo here i'm going to give you a bit of an overview of it but if you want to come to the anonymy um we've got a booth out there um on the top level i can actually show you uh you know us issuing w3c jason ld credentials sign with ed25519 backed with the check network um and using the yuba key the good thing about using yubikey you can actually see you're using it to create private public key pairs and also for signing operations um one other thing we learned too about android is they'll actually give you an attestation to say to you yeah these private key public key pairs you're using is actually is in the strongbox um and so this is a demonstration which i which we can go through but essentially we're using the anonymy issue on the left there we go through some steps to you know create a private public key pair on a yubikey export the the subject did and put it into a credential and then show presentation to the verifier service so i can show all that up at the booth if you'd like it um as i said and we're backed by the check network there that's kind of the under underneath layer for kind of the trust of the network so i guess i can open up to questions so at least that was the presentation with the most photos taken that i've ever seen so that was quite quite interesting we have three minutes four questions are there questions that we've seen it must be because when they take photos you want to take information with you um kindly ask quick questions and then can you can you have fire back what were the biggest technical challenges that you had to overcome oh i think it's just learning how to use those hardware secure elements it's you know it's not you know they're provided in ios and android but they're obviously not technologies that are used every day the documentation is pretty sparse trying to get examples out there if you try to like look up example code to use them it's pretty sparse as well so i'd say just learning how to use ios android yubikey is probably the best in terms of documentation stuff but the actual ios hsm and the android it's it's pretty sparse in terms of documentation so there's a learning curve to go through for that other questions just a sec also please a quick question thanks for the uh demo um one question if you speak about android hsm and ios hsm are you speaking about trusted execution environment and secure enclave yes exactly yeah exactly yeah okay that was really quick other questions in the room then maybe one from you you've mentioned experimental so how far will you take that experimental regarding the external yubikey what what are you aiming at and what is the um so what we wanted to do is is just try one and as i said we you tried this 5c nfc but there might be other ones and in fact one idea is actually to try try say a cloud hsm and see how that would work so it's more about building an interface for an external hsm access so maybe we can do it with devices or even a cloud-based hsm yeah that's why it's experimental because i think there's more work there to be done right so i'm just also looking for the use case and also who will really do that and right yeah so that that's that's the question that must be good reason for that and if there's a good reason why not do it okay thank you very much paul that was a great presentation thank you
