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