How Decentralized Identities can Improve the Security in Enterprise Networks

Yeah. So thank you very much for the introduction. I'm going to talk about how decentralized identities can improve the security in enterprise networks today. And first of all, I want to start by giving you a short introduction about our research approach because we are doing a lot of research on self-sovereign identity, and decentralized identities at th h nurnberg. First we start with the question, how can decentralized identities benefit organizations on the one hand and users on the other hand, then we want to achieve better security and better usability.

So this question is closely re related to the first question. And then we always ask ourselves, how can we minimize the need for changes in existing applications or protocols?

Okay, so this is how we start in our research. First of all, let's talk about security and enterprise networks today. And it's kind of interesting that most protocols that we use today in enterprise networks are really, really old. So I think most organizations use Windows environments, windows networks, and there we have cabs as a protocol for authentication and authorization. Yeah. So if you have a Windows environment, you use kras. Do you have any idea how old cabs is? It's from the late, late seventies, huh? So it's nearly 40 years old. And this is the protocol that we still use today.

So there have been some, some slight changes, but the protocol is basically still the same today. And that's the one interesting part. The second interesting part is well identification. Authentication is still based on user alignment passwords today, which is obviously a pretty bad, pretty bad thing. So we asked the questions, couldn't be used, decentralized identities to improve network security to improve enterprise security. And we think we have found two really nice usage scenarios, which I want to present to you today. First one is keros.

Yeah, used for Windows authentication. And the second one is the EAP protocol, the extensible authentication protocol, which is used for authentication in enterprise networks. So if you have a wifi at your organization or even connected land environment, you hopefully use EAP for security reasons. And they're also, we think that DIDs centralized identities, we can use them in EAP to improve security, to improve user experience. Yeah.

Well, and the best part is these protocols, they support extensibility. Yeah. So you can extend this protocols, and this is where we started our research, Some high level advantages and some high level goals for both integrations. So integration of DITs into s and into EAP.

We, this is our main goal. We want to get rid of passwords. Passwords are a bad thing of authentication. We want to get rid of them. We don't want to have a central storage of user passwords of user keys anymore, which is the case today in Windows environments.

Yeah, you have cameras, you have an authentication server somewhere, and there you have user passwords. They are stored at some point, some central database. And of course for an attacker, if he manages to access the, the central database, that's, that's bad for security. And we want to make, we want to have data minimization, which is supported with SSI via selective disclosure. And there we will see in the second part, in the second use case there, you will see.

Okay, this really is cool to have selective disclosure data minimization in in EAP. So let's start with the first part with the integration of DITs in Kros Kros, I don't want to get into the all the technical details.

So I, I put a lot of slides in this slide deck here, but it's for you afterwards. So if you're really interested in, in technical things, then please have a look into the slides or in our papers that we already published. I just want to give you a, an overview of the concept. keros is based on, on tickets. So the first step when you log into your machine to your client in the morning, then you authenticate, that's the first part, yeah. Authenticate towards the authentication server. So you log in with your username password, then you get a, so-called ticket granting ticket.

And this ticket granting ticket, this allows single sign on because later on, if you want to use different resources, so for example, you want to access the file system, you want to print pages, for example, then you go to the ticket granting server, present your TGT and say, here, I already authenticated, I'm already authenticated. So now please check if I'm authorized to use this service.

And if so, please issue me a ticket. And with this ticket you can go to the resources. This is basically how boroughs works. So we have single sign on, which is a really good thing. But of course, from a security point of view, it's the advant, the disadvantage that it's based on passwords. So the overall security in cabs is based on passwords. So for example, the encryption keys with which the messages are exchanged, they are derived from user passwords. So if you have a, a weak user password, you get weak encryption keys and you have a problem.

It's, it's very, very simplified now, but I hope you get the idea of the problem. So we started at looking at the, at kros protocol and said, well, now we want to integrate SSI functionality how to do it. It might sound pretty, pretty straightforward, but of course it's not.

So we, we came across a number of issues, which we solved with our protocol. And one thing I want to stress out here is that, as I said, we don't want to to adapt the protocol too much here. So we want to have just small things that we extend. And the main extension is here at the key distribution center, the authentication server. So here we need some agent, some SSI agent, and that's the agent that supports the SSI functionality. So this is the only adaption that we really make to the capitals protocol.

So if you think about your Windows environment, you have the server and therefore you would need to have one component which deals with authentication with your decentralized identities. So as I said, we have the protocol, which I'm not gonna going to go to the details, but I edit it for you for later on to, because you will need some time to to get into it. But the nice thing really is I want to stress out again, the exchanges, the of messages in K bureaus, they don't change at all. Yeah.

So you have standard Ks, but with the support for authentic case authentication with your decentralized identity. So how will it work?

Well, you have some wallet where you have your credentials in it, whatever wallet it is. We used wallet, I think it's not anymore the market, any experts here, I don't know. But it was two years ago when we did the implementation of our concept. And then how would it work?

Well, you sit in front of your client machine, you want to log in and you say, okay, I want to log in with my decentralized identity. You start the standard cameras message exchange, and then you will get presented QR code on your Windows client, which you scan with your wallet, and then you get a notification which asks you about some credential. Yeah.

So I say, I want to authenticate on this machine. I am, I am an employee at this company.

So yes, please use this credential and send a proof of this credential to the SSI agent. And the SSI agent checks the presentation proof and tells the authentication.

But yes, he authenticated, he's really an employee here. You can let him into the network. This is how it basically works. There's some implementation details here. Coming to the, to the evaluation of, of this integration. We can say that the things that we extended, they are fully compliant with with RFC 61 13. So there is the possibility for KRAS to integrate certain extensions, which we did, but we fully comply with the RFC. So we don't come up with some new thing that can't be used in practice.

But we really think that we can, if we implement it on a large scale, this can be actually used. And of course, as I said, we have enhanced security, so we get rid of passwords. We don't need any other security mechanisms on top. Yeah. So I really hope that nobody is beating me up today because a lot of companies here that sell functionality to secure Windows environments by putting some things on top. I think if integrated into K, we don't need this anymore. So please be kind.

And we have enhanced usability because we say, well, users will have this decentralized identities anyway, so you will have your badge in your wallet, so why not use it for authentication? This is our, our idea. Okay. Part two is about integration of decentralized identities in EAP. What is E-A-P-E-A-P is an so-called extensible authentication protocol, which is used for authentication in professional networks. Yeah. So if you have your wifi at home, you won't use EAP, but for your wifi at the enterprise, you have the 802 1 X framework.

And there you use EAP and some other methods for authentication. So we are talking about professional environments here, and as the name suggests, this protocol also allows the extension via authentication methods. And this is where we started.

We said, okay, we have EAP, it's extensible, so why not extend it with did functionality with SSI functionality? And I want to present you a, a really cool usage scenario, in my opinion, even if it doesn't quite fit to your enterprise, maybe in the first site. But still you will see the, the advantages, I hope. So. You might know aro if you've studied in the last 10 years or so, then yeah, I see a lot of people you, you know arom. So AROM is a, is a network which can be used in 106 countries. You have participating universities.

So it doesn't matter where in the world in which university you are a student or an employee, for example, you can go to any place in the world and request access to the wifi, to the A room wifi. Huh? And how does it work?

Well, that's the part where EAP comes into, into play. So the client, the mobile phone, the laptop uses EAP to authenticate towards the local authentication server. So say I'm in Berlin now I go to TTU Berlin, I want to connect with the aome. So I am exchanging EAP messages with the local authentication server. And then in the background you have a lot of radios messages being exchanged. So there is a complex architecture, a hierarchical architecture of radio servers. So somehow the T Berlin, they don't know me. Yeah. I'm not a student there. I'm not an employee there.

So they need to check if I'm allowed to enter their network. What are they doing?

Well, they use the spec backend infrastructure with radio service to forward my request. And my request is just my email address. I tell to TE Berlin, I'm Ronald Berg. And Telin then says, well, we don't know him, but we have to forward this request to TH Berg. And then I am, I'm establishing a secure channel from my mobile phone to my home institution. And within the secure channels, it's a TLS protected channel. I authenticate typically why I use an password and MS. CHOP file two, which is also a very, very old protocol by the way.

And then my home institution tells the t Berlin, okay, this guy really works with us. You can let him into your network. So why am I presenting this to you? Do you see where decentralized identities make sense here? What can we get rid of?

Well, this yellow box here, we don't need this anymore. We don't need this radios hierarchical architecture, this all this service and so on. Because the really cool thing is now I can use my credentials that I have in my wallet. So let's say in five or 10 years, every student with with will have his University credential in his wallet. Then he goes to some place and says, please let me into your network here. I'm a student, my name is blah, blah, blah. I'm a student at this university. Please let me in.

And the student and the application server just checks the credentials and says, well that's true, please. Here you go. And now comes the even better part. I've talked about selective disclosure before. So we can even go further. We don't even need to tell who we are. So this is really nice. From a privacy protection point of view, we just send the proof to the network, to the authentication server there and say, we are a student, a, an employee at some participating institution. We don't tell them who we are or where are are we are from just that. We are allowed to enter the network.

They check it and let us in. So this is this use case of integrating DETS into EAP.

Again, we have all the protocol details, which I bear you here. From a security point of view, again, we can get rid of passwords. So we don't want to have the central database at the universities or at your enterprise anymore, where we have all those user passwords, which are used during MS CHOP file.

Two, we get rid of this, we have public key crypto instead. No identity information is leaked to eavesdropper. So nobody knows that I'm here because otherwise, as I said, I tell them my email address. So people who are eavesdropping, they know, oh, this guy is here. This we also get rid of, Okay, this is what I already said. We have privacy protection, which is very good. And so I already come to the conclusion what we get, well, we are the first to propose such an integration of S into RAs and EAP.

We came up with the protocol specifications, we came up with a prototype for RAs for the CABRA scenario. And the next step, we want to show that the EAP scenario also works.

Yeah, for the example or for the enterprise example. And then of course it would be really, really nice to see these things in practice.

So for us, from a university perspective, we can do all the research, we can write research papers, we can come up with the concepts, but we really need to have partners from the industry that also see the potential and say, well, let's do it together and get these things out in practice in five or 10 years or so. So this is why I'm here today and present you this, this use case. And I will be really glad if you also see the potential. And well talk to me later on if it, if there is some room for collaboration. Thank you very much.

Well, what can I say? At least now in the hindsight, so to say that seems like a simple and ingenious idea. So if anyone has technical questions, of course you should. You should probably talk, talk to you later. But we have time for, I think like a more general question. How would you approach the, how do you, how would you approach the revocation use case of credentials? For example, in the enterprise, the the, with the EAP scenario? Yeah. You wouldn't want an employee that you fired today be able to connect to the network tomorrow.

Yeah, very good question. So for kras, I think it's easy.

Yeah, because that's the built in thing in kras. So you have the ttts, which you get issued after authentication, and then you have the resource tickets, which you can go to the resources with. And what you do there is you have, There's no easy possibility for revocation in boroughs. Yeah. But you have, you need to go to the authorization server, to the ticket grounding server every time you want to use a resource. So this happens in the background. Yeah. So if I go there and the TGS says, well, you got fired five minutes ago.

Yeah, you still have a TGT, you are authenticated, but you got fired, you won't get this resource ticket. You are not allowed to access the file system anymore. So I think there, it's easy for the other case, I think it's not that easy. So I haven't thought about it. But once you have a credential, it's you want to get rid of the yellow box. You don't want to ask somebody, is he really still a student there? So you have this credential, which is valid for one semester, and you will have access for one semester. Okay. Awesome.

Well, thanks a lot.