WEBVTT 00:00.000 --> 00:18.000 Out of the room, if you are going, so are you ready? 00:18.000 --> 00:22.000 Yes, I think I'm ready, no, okay, perfect. 00:22.000 --> 00:29.000 So our next presentation is from Stefan, and he will speak about the 80-day interviews. 00:29.000 --> 00:33.000 Yes, so thank you all for being here. 00:33.000 --> 00:40.000 I was already introduced, so without further introduction, I would just go to the first light. 00:40.000 --> 00:48.000 I brought the initial scenario with me, so this is Alice and Bob, and probably you all know them by heart. 00:48.000 --> 00:55.000 And Alice is sending Bob a public key, just to establish a secure communication or a trusting communication. 00:55.000 --> 00:58.000 So the question to you is, what's wrong? 00:58.000 --> 01:04.000 Can you tell me what's wrong with Alice sending her public key over to Bob? 01:04.000 --> 01:06.000 Is that secure? 01:06.000 --> 01:12.000 No, of course not, yes. 01:12.000 --> 01:17.000 There is no name attached to the public key, there is no signature. 01:17.000 --> 01:19.000 There are lots of things missing. 01:19.000 --> 01:23.000 Do you see additional properties that could go wrong? 01:23.000 --> 01:29.000 So what's wrong with the model of Alice and Bob in general? 01:29.000 --> 01:37.000 Like who sees one topic, one additional topic, hands up, or maybe two? 01:37.000 --> 01:41.000 Okay, so I brought four with you. 01:41.000 --> 01:47.000 So the first one are basically privacy risks, and probably most of you are not aware of it, 01:47.000 --> 01:52.000 but before you do a establish a TLS connection, maybe to your banking system, 01:52.000 --> 01:55.000 they're also DNS queries running and so on. 01:55.000 --> 02:01.000 And all these queries and the communication patterns that are established across the internet, 02:01.000 --> 02:05.000 they do paint a picture of you in the internet. 02:06.000 --> 02:12.000 The second thing that is wrong with the model of Alice and Bob is that it doesn't deal with group communication. 02:12.000 --> 02:22.000 We do a lot of stuff to basically re-implement the group communication on top of a couple of TLS connections. 02:22.000 --> 02:25.000 So that is simply missing. 02:25.000 --> 02:31.000 We do have marvellous, so if you have your, like for example, your email address, 02:31.000 --> 02:34.000 published somewhere in the internet with your PGP key. 02:34.000 --> 02:37.000 Of course, somebody can send you a malware. 02:37.000 --> 02:41.000 VPN doesn't protect you from receiving malware through the VPN. 02:41.000 --> 02:44.000 It's not the right protection layer. 02:44.000 --> 02:47.000 And we have, of course, denial of service attacks. 02:47.000 --> 02:52.000 If I have your email address and I can send you lots of encrypted emails, 02:52.000 --> 02:55.000 and you will drown in emails. 02:55.000 --> 02:58.000 You don't know what's in, you all have to believe them. 02:58.000 --> 03:00.000 That's also not good. 03:00.000 --> 03:06.000 I will go through the forest that I see here, and I will tell you what we are doing in the new 03:06.000 --> 03:11.000 European service security mesh to prevent basically these four things. 03:11.000 --> 03:19.000 So recap what is the digital identity and what is the digital identity in the service security mesh. 03:19.000 --> 03:23.000 Basically, it's a data structure that is similar to a job token. 03:23.000 --> 03:26.000 So it is coming from the job token. 03:26.000 --> 03:30.000 We use nowadays more binary serialization. 03:30.000 --> 03:35.000 So we use the CBOR web token format CWP. 03:35.000 --> 03:38.000 And otherwise the fields are basically the same. 03:38.000 --> 03:41.000 We have expiration dates and so on. 03:41.000 --> 03:44.000 One special note has to be done. 03:44.000 --> 03:47.000 We have so-called re-infield. 03:47.000 --> 03:52.000 That means a user can say he would like to belong to a re-in. 03:52.000 --> 04:00.000 And the issue of audience ID, they are not strings, but they are fixed size 32 bytes, fears. 04:00.000 --> 04:05.000 And I will explain you in a second why this is the case. 04:05.000 --> 04:08.000 I will hop over this slide. 04:08.000 --> 04:15.000 Here's the reason why we use the issue and the audience are fixed size. 04:15.000 --> 04:18.000 So they are 256 bit hash values. 04:19.000 --> 04:21.000 So you can take any text. 04:21.000 --> 04:27.000 And there's one to one mapping if you use a cryptographic hash function to the hash value of it. 04:27.000 --> 04:28.000 So here there are two examples. 04:28.000 --> 04:35.000 The hash value of some stupid text is one ID that you can put in as the re-in for example. 04:35.000 --> 04:38.000 The second one is this is Alice. 04:38.000 --> 04:39.000 And the hash value of it. 04:39.000 --> 04:43.000 That is unique across the whole system. 04:44.000 --> 04:50.000 You can also create such 256 bit hash value from the signature of this token. 04:50.000 --> 04:55.000 So basically you take the hash value of the signature that also gives you an NP ID. 04:55.000 --> 04:59.000 And that is also something that you can put into the re-infield. 04:59.000 --> 05:02.000 And last but not least, we have an NP subject. 05:02.000 --> 05:09.000 And that is also a kind of an NP ID with a notable difference that you can combine several NP IDs. 05:09.000 --> 05:12.000 You basically just mix all them together. 05:12.000 --> 05:14.000 So here I have depicted as an example. 05:14.000 --> 05:16.000 You use the ID one. 05:16.000 --> 05:19.000 The hash value of some stupid text plus the ID two. 05:19.000 --> 05:21.000 So this is Alice. 05:21.000 --> 05:27.000 That gives you again a unique subject that is unique in our system. 05:27.000 --> 05:33.000 Or you could use it in conjunction with the fingerprint of the signature. 05:33.000 --> 05:37.000 So that is also then unique. 05:38.000 --> 05:42.000 Of course, you need to verify the signature that is involved. 05:42.000 --> 05:45.000 So we have a public key in our digital identities. 05:45.000 --> 05:48.000 And that allows you to verify. 05:48.000 --> 05:52.000 If you have set the issue of here, then there is one difference. 05:52.000 --> 05:55.000 All tokens in our system are self-signed. 05:55.000 --> 06:02.000 And if there is an issue of here, then we are pushing the additional signature of the issue to the attribute set. 06:02.000 --> 06:06.000 So there are two signatures that you have to verify that. 06:07.000 --> 06:09.000 And each fingerprint. 06:09.000 --> 06:14.000 So each digital identity in our system has a unique fingerprint. 06:14.000 --> 06:21.000 And there is only one person who can generate this kind of fingerprint on the word. 06:21.000 --> 06:22.000 Okay. 06:22.000 --> 06:25.000 So back to the photo picks. 06:25.000 --> 06:27.000 How do we deal with privacy? 06:27.000 --> 06:30.000 Of course, the first two points. 06:30.000 --> 06:33.000 They are more of a hassle to use. 06:33.000 --> 06:35.000 Your privacy is impacted. 06:35.000 --> 06:38.000 Of course, identity theft is possible. 06:38.000 --> 06:43.000 You could receive fishing emails, which are tailored to your specific profile. 06:43.000 --> 06:48.000 But especially you would have to look for the metadata of communication. 06:48.000 --> 06:52.000 So your IP address is something that belongs to you. 06:52.000 --> 06:55.000 So it's like a personal data that belongs to you. 06:55.000 --> 06:58.000 But you can't hide it, even with a TLS connection. 06:58.000 --> 07:02.000 That is the baseline of the internet, how it has been built today. 07:03.000 --> 07:08.000 So what can we do to basically remove this kind of privacy risk? 07:08.000 --> 07:13.000 We will just use random digital identities. 07:13.000 --> 07:18.000 So we just, with our digital identity, we just create a second one. 07:18.000 --> 07:23.000 And we use this one to first establish a TLS connection to a different system. 07:23.000 --> 07:24.000 Right? 07:24.000 --> 07:29.000 That basically doesn't tell anybody who is really connecting. 07:29.000 --> 07:36.000 And then in the second step, we allow the connectivity and the transport of the digital identity of LSM pop. 07:36.000 --> 07:41.000 And the point is, LSM can use more than one random digital identity. 07:41.000 --> 07:46.000 So she can use three, four, how many she would like to. 07:46.000 --> 07:48.000 And Bob can do the same. 07:48.000 --> 07:51.000 And that means there will be multiple authentication paths. 07:51.000 --> 07:54.000 So it's not like a multi-factor authentication. 07:54.000 --> 08:02.000 But there are multiple ways how you can contact LSM because of the different identities. 08:02.000 --> 08:08.000 If we do this, then each actor is also at least authenticated once, 08:08.000 --> 08:17.000 because with the random digital identities, you have several ways how to do it. 08:18.000 --> 08:25.000 We can basically say we can introduce now Marvin and Eliza and they do the same. 08:25.000 --> 08:35.000 So even the middle of here is a bit lost because she doesn't know any more which of the connections between all the different random digital identities. 08:35.000 --> 08:36.000 She should attack. 08:36.000 --> 08:44.000 And she actually doesn't know which of these connections is really carrying data. 08:45.000 --> 08:51.000 So in our cybersecurity mesh, we let these random digital identities establish connectivity. 08:51.000 --> 08:57.000 So we take away from you the control to establish this kind of connectivity. 08:57.000 --> 09:01.000 We solely base it on latency and on hash distance. 09:01.000 --> 09:06.000 And we let the random digital identities connect by themselves. 09:06.000 --> 09:12.000 And by this, we unfortunately, we add something that we already had. 09:12.000 --> 09:17.000 That is no, we take away also feature and that is confidentiality. 09:17.000 --> 09:23.000 Because if you don't know if your next top is one of you or that of Eliza, 09:23.000 --> 09:26.000 then you don't trust Eliza, it's a problem. 09:26.000 --> 09:33.000 So we have to do something to add back confidentiality into the system of random digital identities. 09:33.000 --> 09:37.000 We can change these random digital identities frequently. 09:37.000 --> 09:42.000 So you can basically stop one instance, you can take a new one and so on. 09:42.000 --> 09:51.000 Just to basically opposite if I make it difficult for her to attack the system. 09:51.000 --> 09:56.000 And under what I introduced you the second topic, good communication. 09:56.000 --> 09:59.000 So that was the second problem that we had. 09:59.000 --> 10:04.000 So privacy, we can say with random digital identities, that's possible. 10:04.000 --> 10:08.000 We could protect ourselves at least better than before. 10:08.000 --> 10:12.000 So now we have also introduced Eliza and Marvin. 10:12.000 --> 10:16.000 And the question is, how can you basically integrate them, 10:16.000 --> 10:20.000 let they get also can communicate with Eliza and pop. 10:20.000 --> 10:27.000 And group communication has several other challenges like key distribution. 10:27.000 --> 10:31.000 Also membership, revocation or membership addition. 10:32.000 --> 10:39.000 And our solution is we will use an additional identity which we call the intent token. 10:39.000 --> 10:46.000 So you know that our random digital identities, they have fingerprints, they are all the same. 10:46.000 --> 10:53.000 We can our subject is also a hash value, that's also 256 bits. 10:53.000 --> 10:57.000 So we can use the random digital identities as a routing layer. 10:58.000 --> 11:01.000 And we can basically publish intent token. 11:01.000 --> 11:12.000 And because they all use the same subject, they will find themselves in across all the random digital identities. 11:12.000 --> 11:18.000 Again, a bit of knowledge shaping what is an intent token. 11:18.000 --> 11:23.000 I think the official term is disposable yet official identity. 11:23.000 --> 11:29.000 So consider yourself you're driving a motorway and there are lots of different total collect stations. 11:29.000 --> 11:38.000 And at each station you have to pay a fee that you can pass and you can go on on the motorway on the way to your vacation. 11:38.000 --> 11:47.000 For each of the different total collect stations, you would like to use a random disposable identity so that your path cannot be tracked. 11:47.000 --> 11:51.000 So that is something that is official because you can pay with it. 11:51.000 --> 11:55.000 But it's disposable and it's goes away once you have used it. 11:55.000 --> 11:57.000 So when intent token is exactly that. 11:57.000 --> 12:02.000 So we basically derive it from the digital identity automatically. 12:02.000 --> 12:07.000 We do it for a dedicated data channel and we can limit the access. 12:07.000 --> 12:10.000 We can limit the access in terms of time. 12:10.000 --> 12:14.000 So you can have intent token for just half an hour. 12:14.000 --> 12:21.000 You can have it once. You can repeatedly refresh the intent token if you would like to, but still they will always be different. 12:21.000 --> 12:23.000 They always have a different fingerprint. 12:23.000 --> 12:29.000 The only thing that they have in common is the subject. 12:29.000 --> 12:38.000 And we could add of course you can add additional attributes to the token just to do additional access control. 12:38.000 --> 12:42.000 There's one thing more that you can do with these intent token. 12:42.000 --> 12:45.000 We can define different classifications. 12:45.000 --> 12:50.000 So you're used to TLS and there's a TLS connection to a system. 12:50.000 --> 12:56.000 But in the security mesh, you can now have different classification of transport layers. 12:56.000 --> 13:05.000 So we have defined a virtual, token exchange, a virtual data channel, a public, a protected and a private one. 13:05.000 --> 13:10.000 So the virtual one will just exchange the token and nothing more will happen. 13:10.000 --> 13:13.000 There's no callback, nothing can happen more. 13:13.000 --> 13:19.000 The public one is intended to be used like interfaces or APIs. 13:19.000 --> 13:23.000 The protected one basically is the same as MTLS connection. 13:23.000 --> 13:25.000 So you know who you're going to talk to. 13:25.000 --> 13:28.000 So you can directly put it to the audience field. 13:28.000 --> 13:31.000 You know this will be the fingerprint of the other person. 13:31.000 --> 13:34.000 You know this will be your protected data channel. 13:34.000 --> 13:46.000 And the private one basically means you combine the subject with different so you X or together several kind of IDs and identities to create a private data channel. 13:46.000 --> 13:53.000 So the difference is in the classic internet, you have IP addresses and it's very system-centric. 13:53.000 --> 13:58.000 And in European with the public data channels everything is interface-centric. 13:58.000 --> 14:02.000 And you basically with a private data channel you put back in the system. 14:02.000 --> 14:09.000 So first you have an interface by combining it with the fingerprint of a specific service. 14:09.000 --> 14:12.000 Then you may have a system access. 14:12.000 --> 14:20.000 So that's like a turnaround of the architecture and what you can do with the service security mesh. 14:21.000 --> 14:25.000 We have used this approach in the Fluiders project. 14:25.000 --> 14:28.000 Maybe some of you have heard of it. 14:28.000 --> 14:30.000 It's Fluiders.eu. 14:30.000 --> 14:33.000 It's part of the European cloud initiative. 14:33.000 --> 14:36.000 And we use exactly this kind of different. 14:36.000 --> 14:43.000 So we use virtual data channels to discover all the clusters that are available. 14:43.000 --> 14:49.000 And then we use private ones to exchange details about the clusters. 14:49.000 --> 14:52.000 So the private data channels are end to end encrypted. 14:52.000 --> 14:55.000 And the virtual ones are just the public information. 14:55.000 --> 14:58.000 I have a cluster. I would like to communicate with you. 14:58.000 --> 15:01.000 But nothing else is going to happen on. 15:05.000 --> 15:08.000 Okay. So back to group communication. 15:08.000 --> 15:10.000 Now we have a mean. 15:10.000 --> 15:12.000 We have a common denominator. 15:12.000 --> 15:14.000 We can exchange all this message into token. 15:14.000 --> 15:19.000 And that allows us to basically define different kind of sessions. 15:19.000 --> 15:24.000 So Eliza gets all the token from Bob, Marvin and Alice. 15:24.000 --> 15:27.000 And she can set up different sessions. 15:27.000 --> 15:31.000 So she could authorize maybe just Bob and Marvin and centre message. 15:31.000 --> 15:36.000 It likewise Eliza could deny that Bob can centre message. 15:36.000 --> 15:42.000 So it's always placed on authorizations of each person for sending and receiving. 15:43.000 --> 15:49.000 So basically we have now put back in confidentiality with the internet encryption, 15:49.000 --> 15:51.000 which is based on this intent token. 15:51.000 --> 15:56.000 This is supposedly yet official identities. 15:56.000 --> 15:59.000 So group communication. 15:59.000 --> 16:00.000 So privacy. 16:00.000 --> 16:05.000 So I see the sign 10 minutes left. 16:05.000 --> 16:10.000 So I hope I won't take that long for marvellous. 16:10.000 --> 16:13.000 But the good news is it's solved. 16:13.000 --> 16:16.000 We have the message intent token. 16:16.000 --> 16:19.000 And with this message intent token, 16:19.000 --> 16:23.000 we can basically restrict the access for specific data types. 16:23.000 --> 16:26.000 We can say we have an intent token for pictures. 16:26.000 --> 16:29.000 We can have an intent token for JPEX. 16:29.000 --> 16:33.000 And you can pack in all the validations of the security modules behind it 16:33.000 --> 16:35.000 that you would like to have. 16:35.000 --> 16:39.000 At least, of course, if you accept everything, we can't change it. 16:39.000 --> 16:44.000 But at least you have the grip to say, no, I don't want to receive everything. 16:44.000 --> 16:46.000 All right. 16:46.000 --> 16:52.000 So it's getting very hard for an attacker just to send you something without your knowledge. 16:52.000 --> 16:58.000 So at least the attacker will become visible because if you would like to send you malware, 16:58.000 --> 17:03.000 then he has to first get your authorization via the intent token. 17:03.000 --> 17:08.000 So malware, let's say, solved. 17:08.000 --> 17:12.000 The denial of service, what do we do with this one? 17:12.000 --> 17:15.000 It's also solved. 17:15.000 --> 17:18.000 Because if you don't have an authorization of the other peer, 17:18.000 --> 17:22.000 you can send as many messages as you would like to. 17:22.000 --> 17:24.000 We just throw them away. 17:24.000 --> 17:29.000 You won't know if the other person has authorized your token. 17:29.000 --> 17:30.000 It's useless. 17:30.000 --> 17:33.000 And that basically means in this cybersecurity mesh, 17:33.000 --> 17:36.000 we don't have spam anymore. 17:36.000 --> 17:39.000 So if you don't give the authorization to a sender, 17:39.000 --> 17:43.000 the messages will never appear. 17:43.000 --> 17:48.000 Again, an attacker would become visible if he would like to send you a message. 17:48.000 --> 17:52.000 Because he has to subscribe to the same data channel. 17:52.000 --> 17:54.000 He has to issue the intent token. 17:54.000 --> 17:59.000 And that means you know who is sending you messages. 17:59.000 --> 18:03.000 Okay. So how much time is left? 18:03.000 --> 18:10.000 8 minutes, including questions or including questions. 18:10.000 --> 18:14.000 Okay. 18:14.000 --> 18:19.000 I have a couple of examples how you could use the cybersecurity mesh 18:19.000 --> 18:22.000 or how you could use the digital identities. 18:22.000 --> 18:25.000 I will skip over the first two, 18:25.000 --> 18:28.000 because then we have a bit more time for questions. 18:28.000 --> 18:31.000 And I will directly draw to the third one, 18:31.000 --> 18:35.000 because we started off with the topic of federated identity. 18:35.000 --> 18:40.000 So how could you use the cybersecurity mesh 18:40.000 --> 18:44.000 if you would like to host an identity provider? 18:44.000 --> 18:45.000 So what's? 18:45.000 --> 18:47.000 How would you do it? 18:47.000 --> 18:49.000 First of all, you would issue yourself 18:49.000 --> 18:54.000 a digital certificate and you would use SSCA certificate authority. 18:54.000 --> 18:57.000 That's like a classic PKI setting. 18:57.000 --> 18:59.000 So but you keep it private. 18:59.000 --> 19:00.000 This is CA. 19:00.000 --> 19:01.000 So that is yours. 19:01.000 --> 19:03.000 It never leaves the system. 19:03.000 --> 19:04.000 It stays. 19:04.000 --> 19:07.000 But you can use the fingerprint of this digital identity 19:07.000 --> 19:13.000 to put it into the issue of field of additional identities. 19:13.000 --> 19:17.000 And within your identity provider, 19:17.000 --> 19:20.000 you can then set up additional reels. 19:21.000 --> 19:24.000 And for each real, you have the issue. 19:24.000 --> 19:27.000 For each real, you have a fingerprint. 19:27.000 --> 19:30.000 So you don't have, that's unique. 19:30.000 --> 19:33.000 That's a name, the hash value of a name. 19:33.000 --> 19:36.000 So now we don't need this strange abbreviations. 19:36.000 --> 19:41.000 You have it anymore, but we can just directly put the hash value in it. 19:41.000 --> 19:44.000 And then you offer basically a data channel for others 19:44.000 --> 19:46.000 to register to your real. 19:46.000 --> 19:48.000 So for your clients. 19:48.000 --> 19:53.000 But also means that your clients, you don't need to set up any credentials anymore for your clients. 19:53.000 --> 19:56.000 Because they have additional identity. 19:56.000 --> 20:02.000 They claim to be in this here, you can just say, yes, this client belongs to my real or not. 20:02.000 --> 20:04.000 And we are done. 20:04.000 --> 20:11.000 Similarly, you can also say, the other users can register within your identity provider. 20:11.000 --> 20:16.000 So you set up a different data channel to register your users. 20:16.000 --> 20:21.000 And again, we don't need to store any passwords of the users anymore 20:21.000 --> 20:24.000 because they have additional identity. 20:24.000 --> 20:30.000 So our identity provider basically is a solution to manage root membership. 20:30.000 --> 20:35.000 And the identity provider doesn't need to store any passwords anymore. 20:35.000 --> 20:40.000 And that also reduces your risk of operating this identity provider 20:40.000 --> 20:45.000 because you don't have to do all the measures for the user database and for the password database. 20:45.000 --> 20:54.000 So in conclusion, so the cybersecurity mesh, as it is also shown here on the right side, 20:54.000 --> 20:59.000 it is in itself a federated identity setup. 20:59.000 --> 21:04.000 We have all the different kinds of digital identities which are talking to each other 21:04.000 --> 21:11.000 and we use these different kinds of sub identities, the intent token to establish data channels. 21:11.000 --> 21:19.000 Basically, it's a bit like each participant is hosting its own micro-pecker E for its own purposes. 21:19.000 --> 21:23.000 And then you will let these pick eyes talk to each other. 21:23.000 --> 21:28.000 And our main topic for the next years probably will also be an efficient group management. 21:28.000 --> 21:33.000 How we can do this, of course, with these data channels, 21:33.000 --> 21:39.000 and basically the main point here is efficiency how we can do it. 21:40.000 --> 21:42.000 Our project has received funding. 21:42.000 --> 21:44.000 I would like to mention this. 21:44.000 --> 21:48.000 So we are part of the NGI zero and the next generation internet. 21:48.000 --> 21:53.000 We have received two funding from NGI assure in NGI zero. 21:53.000 --> 21:58.000 We have also received the funding from the fluidors project. 21:58.000 --> 22:04.000 And probably we are going to start an open collective campaign this year. 22:04.000 --> 22:07.000 But we have to set up all the details. 22:07.000 --> 22:12.000 So maybe if you're interested, get back to me. 22:12.000 --> 22:14.000 These are repositories. 22:14.000 --> 22:20.000 So if you like what we are doing, that gives us a star or maybe a fork it. 22:20.000 --> 22:22.000 And that was my talk. 22:22.000 --> 22:23.000 Thank you for your attention. 22:23.000 --> 22:29.000 And if you have any questions. 22:29.000 --> 22:39.000 So thank you very much. 22:59.000 --> 23:27.000 Thank you. 23:27.000 --> 23:37.000 Check, check, check.