It looks like you're having connection troubles. Reconnect now.
01/25/2022 22:39:54
30c3-talk-5214 Latest text of pad 30c3-talk-5214 Saved Jan 25, 2022 |
Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!
Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!
======================================================================
OK, now I think we have a picture here. Please. We have are paying Kottmann from the university nightmare here, who is going to talk to us about some very interesting developments with a smartcards and an attribute based authentication. So please give it a very warm welcome to Japan, Kottmann, who is going to reveal to us the gospel of Elmo. Thank you. Yes. So my name is Jarvik Goodman, I'm from the Rubble University, Nijmegen in the Netherlands and also from the Privacy and Identity Labs. And I'm very grateful to the organizers of CCC to allow me to give this presentation about a cool project that we are doing in animation, in the privacy and identity lab. And because of the season, I thought it was would be good to frame it as a like a Christmas kind of story. The Gospel of Irma. Irma is our cool project, and I will tell you later what it means and what it does. Back in the pre-internet age, when you had to identify yourself, you would have, you know, have a passport or an identity card and you would, you know, use that to prove your identity. You would also use that to prove certain attributes certain properties about yourself, like your nationality, your age or your name. And in fact, you would actually have to use that in a physical shop. You actually have to present your ID card, for instance, if you would be slightly younger than me and still look like about maybe 16 17 and then prove that you were actually over 18 in order to buy some alcohol. So, you know, passports were used a lot and then internet came and people thought, OK, we need some information about these people that use the internet. So they basically sort of copied the passport model of doing ID and actually also proving, you know, information about yourself to the internet world using certificates x 5.9. Whatever these things, you know, contain your name, contain all information if you have extension fields. And the good thing of the passport in the in the physical world was that, you know, even
if you would show your passport or your identity card to a shopkeeper, he would usually not have photographic memory. So you show the passport, he verifies your age. And if we get, he forgets about you. In the digital world, the digital merchant never forgets. He just copies the whole certificate. That's a problem. So people thought of like intermediate steps to smoothen the process. Also, partly because they didn't want to store all the information at different merchants. You want sort of like ease the experience for the user. So they thought of something called identity management, where here in this picture you have this user that wants to do some business. That's what they call a relying party in these kind of schemes. And in order to actually access that service, he will to have identify himself. So what would he have to do? The relying party says, Well, you know, I have this contract with this identity provider. So if you have an account there, just sign in at the identity provider and then the identity provider will tell me everything I need to know about you. Again, you know, if the ruling party wanted to, he could ask all kinds of stuff about yourself, not only your age or your nationality, because I ask also your name and other identifying information. This is really not so good. And that is where enormous steps in our heroine of the story, where the gospel, what the gospel is all about. She is trying to prevent this situation from happening. And there is the project that we are. We are developing in the information and it's earmuffs stands for. I reveal my attributes and it's a call that collaboration between the my university and serve that certain that there's a big network provider for academic institutions in the Netherlands. And one of the important features of of our approach is that we use actual base credentials and that allows us to, you know, only show only prove to certain relying parties, certain specific attributes, certain specific pieces o
f information about yourself without revealing everything in one go. Secondly, it is smartcard based and this is what set us apart from a lot of other attribute based credential approaches, because we are the first that actually can implement a full attribute based credential system on the smart card with reasonable performance. And of course, by Did We Do This? A smart card is a more or less secure container for these kind of credentials. And by using specific protocols, we can also make it privacy friendly. Everything is open source, actually, all the sources are on GitHub, I will give you the link later at the end of the talks, or you can look maybe even contribute that we recall and the the the main idea of attribute based credentials in general and also in the project is that we want to make the user in control. We want a user to decide what he shows to a relying party in order to access a service. It's not a relying party to decide. It's the user to decide and sees and has control of the infrastructure that we, we envision is is in principle open. But there is has to be some kind of governance, and I will explain later why that has to be. You have to have something to decide whether certain relying parties can be part of that system, whether certain attribute issues can be part of the system. And I'll show you how it works. The important bit to remember first is that an attribute based credential system allows you to prove an attribute about yourself, your age, your nationality, some kind of preference, blood groups, whatever. Without revealing your full identity, you each and each and every attribute is an individual item that you can individually show and present to somebody else. These attributes are stored in so-called gold credentials. That's why everything is gold at every base credentials, and such a credential is really a secure container for your attributes. This is what is stored on the smartcard mom. In a way, attributes of such a credential is the
key, the key that is only stored in the smart card that never leaves a smart card that is used to prove that you own that credential. There's also a expiration time credential. I only have a, you know, a limited validity, and there are certain attributes. In case of error, we only have four attributes per credential. These credentials are issued by a credential issuer, typically after showing that you have you have the right or you actually have the properties that the credential claims that you have, the credential issuer will issue you that credential. Of course, it's very important that whoever issues the credential has, you know, anything meaningful to say about you and is actually trusted to say something about you. And also that many other people trust that is sure to say something about you, it doesn't really help anybody here in this room. If my father would say that my name is shopping, whom you don't know my father, so why would you trust him? Similarly, it wouldn't really help if my son would go to the liquor store and say, my father says that I'm 25. The liquor store said, Yeah, OK, that's fine. But you know, I want a proper authority to say this like in a passport. You know, you need a proper identity card, a property, proper passport to do that. Same goes here. I already said the provincial contains attributes and these attributes you can selectively disclose. So even though there's always for at least four slots for attributes in a credential, that does not mean that if you want to use the credential, you have to show all the four attributes at the same time. During the show and protocol, you can decide which attributes to reveal and which not to reveal. And what can you use this for? Notice that I'm calling this consistently attribute based credentials when these systems were designed. They were a first called anonymous credentials. So the people from IBM who designed this called this anonymous credential systems. But, you know, whether a conventiona
l is anonymous or not really depends on the information that's in there. If I put my name as an attribute in a credential that's highly identifying, if I put a Social Security number in a attribute in a credential, then this thing is highly identifying, not anonymous at all. That is an important distinction to remember, because what we're doing here is to make a system that gives you full privacy in the infrastructure. But you can totally put identifying information in an attribute and use it that way. So if you if you look at, for instance, anonymous uses of these things want one. Well, simple stuff is like age verification, like the typical and almost boring example of the liquor store where you have to provide proof your age. Slightly more interesting, especially because this is something that started many, many years ago after hour of a chip card hacking stuff and thinking about, OK, how could we improve that system? One of the things that we thought of was actually, OK, maybe we can use attribute based credentials for like a train ticket system. And you can't, for instance, encode the fact that you have a a track pass that you're free travel on a certain track or you have free travel for a month or a year on the Deutsche Bank or anywhere else. Another interesting application about to be best credentials is, for instance, concert tickets. I don't know how the situation is here in Germany, but at least in the Netherlands, there's a huge black market of popular, popular shows. So when a show opens, the ticket sale opens. Many people want to get tickets. But of course, there's also like companies that try to get a lot of tickets, buy them first and then try to sell them later for double the price. Did that you can easily do that because you basically get the paper ticket that you can just sell again and again and again. Now if you would encode a concert ticket essay attributes in a credential, it will be bound to your card. You will not be able to transfer it to an
ybody else. So by just using and with basic attention for this kind of systems, for these kind of applications, you, you, you basically kill the possibility for having a black market. Of course, you have to think about, OK, what do you do if you want to return your ticket or whatever? You have to have some exception processing. But you get the point. There's, of course, also an enormous applications of of credentials. For instance, loyalty cards like if you go to your shop, a subscription to a newspaper. Online, if I want to access my online newspaper, I have an account that can just be anonymous. They don't have to know who actually reached that paper. They just want to know that the person has a subscription and you can even argue. But that should be not totally anonymous, right? And there's full identifying applications like using it for passport like stuff like your address, your Social Security number or a student card, or even something like emergency health information where you know, attributes in gold, your blood type and very vital medical information. So how does it work? So here have you. It's important to realize that in with basic credentials, the issuing of a credential is separate from using it. This is also different from the transitional model of identity management that I showed for all the parties have to be online. You know, if you go to your line party, the identity provider also has to be online. In the case of actual best credentials, this is not the case. You first go to a credential issuer and ask to issue to get issued a credential to your card that you hold as a user. And then later on, you can use it as a relying party, and I already drew the scheme, authorities are in the corner, too, to highlight the fact that the scheme authority has certain rules about who can be a credential issue or who cannot be a credential issuer. In the end, the overall trust, the overall trust that users of the system and uses are in this case, not only ordina
ry users but also relying parties depend on the trust rating of trustworthiness of individual credential issuers. In that sense, the situation is a bit like what you see in the certificates for four four websites. If there's one rotten Apple, the whole trust falls apart. So that's an issue. And so, you know, once you have convinced the credential issuer that you actually are a person that actually has certain attributes, he will issue you that credential. Now, if you want to use that credential disclosing some attributes as a relying party, another protocol runs. And in this case, the relying party has a so-called relying party certificate that encodes the access rights to things that the ruling party can see. This is important because you can you can either let the user decide all by himself whether he should reveal certain attributes. But it's even stronger if you by default restrict the access of the ruling party anyway. If a an online video rental store only needs to verify whether you are a member or whether and whether you are a certain age, because certain age restrictions apply to certain online material, you just give him only the right to verify those attributes. You don't give him the right to access name, address, whatever. So this is encoded in these ruling party certificates, and if a user goes to relying party to access the service now first, they're relying upon the certificate is transferred to the card. Together with a request for certain attributes and a card verifies that the attributes they're relying party ask for are actually permitted by the scheme authority. And then still, the user has a choice to say, OK, I will actually reveal these attributes or not. In any case, you see these like darker boxes in the in the in the credential for the attributes that are not revealed. Important properties for for these kind of systems are the following you. Of course, credentials should not be or should not be forcible because otherwise the whole system w
ill be useless. And you want to make sure that whenever a credential contains certain attributes, then this is something that a credential issuer issued and not a user generated all by himself. Secondly, and this is the privacy preserving property. It should be unthinkable. And unsinkable means that if you actually has two aspects, first of all, it should mean that the if you get a credential issued from an issuer, the issuer should not be able to detect the use of that credential at an at an arbitrary relying party. So this is totally disconnected issuer from the use of the credentials. He has no way of following you looking at the credentials in the technical sense, of course. And again, remember this is in the technical infrastructure if the attributes themself contain a identifying number. Of course, he will be able to track that. Secondly, there's also a unlink ability between several showings of the same credential to different relying parties or even to the same ruling party. I would go to my online newspaper with my credential showing that I have a subscription there than that online newspaper would not be able to tell that I was the same person coming there again and again and again. So he does not know how much time I spent on that site or how many times I go to that site. So these are very, very strong privacy guarantees. Third of all, an important property, but the hard property is revoke ability. You want to be able to revoke certain credentials, for instance, if they are abused, if they expire. This you can do by setting the expiry time of each credential, you know, at the right time. But sometimes things, you know, things change if you encode certain access rights, for instance, and you forget to pay for something or whatever you want to revoke that access, right? If that is encoded in a credential, so you want to be able to revoke credentials, of course. And you know, if you're paying attention, you realize that if you want to do that in an attribute
based credential system that has these unknowability guarantees, you should already start wondering how can you do that? Because you know, I just told you that if you, you know, if I present a credential to a to a relying party and I come back again, he will not be able to tell that this is the same credential. So how do I revoke? This is a challenge. We have some ideas for that, but that's that's a challenging thing to do. Of course, things should be nontransferable and should not be possible for somebody else to use my credentials. In a technical sense, this is guaranteed by using this, this key that is embedded in as one of the attributes in each and every credential because that binds it to the card. Yet, you know, there is not really that much stopping me from using my card somewhere else. We did have we do have certain features to prevent that the more in the in the in the online and offline world, sorry than in the online world. So you see in there my card. These are the cards we produce. We we classify them and lemonade them and issue them at the moment. As for testing purposes? There's mine and you see my picture on the front and you see some, some generic information or back saying that this is a member of is a property of the IMA project. So you find it, please return it and there is a unique number at the bottom. Now I said that this was a privacy friendly tool. So why is this unique number there? This unique number is only on the outside of the card or on the side of the card. You typically do not present in the shop, you only show the front. And this is for if you as a user, want to revoke your card. That's what the number is for. It's not inside the card, it's only on the outside of the card, inside the card. That's a contactless card. So that means that you can use NFC phones or NFC tablets as as readers. Which is a huge advantage, because I mean, many more and more and more devices start getting them more smartphones, more tablets, having that kind
of stuff inside the cars, we implement the filter, we implement it it makes. On a maltose card, we initially started off using a Java card that was in a very slightly similar to two to two program. However, we didn't have the full access to the crypto hardware that we really required to do the complex crypto operations that we have to do in order to implement this IDMC system that originally, I think now 10, 15 years ago, was designed by IBM. And we use a thousand seventy four bit keys, which is a bit low, but otherwise we do not get the performance that we want. So this picture on the outside is needed to ensure that you, uh, that you are bound to your credentials, to your car. So in a in an offline world, in a shop kind of world, uh, you can still use this in the online world. Of course, the picture is meaningless. The Reliant party doesn't see it. So the only thing that we can do then is using pinkos or something to prevent somebody who stole your card to use your card. But it still does not prevent you from, you know, giving your card to your little brother and then allowing him to buy liquor. This is, but I should add, is something that happens in all, uh, online systems anyway. I mean, I can always, you know, give my access credentials to somebody else and he can use it. About performance, because this is really the the most interesting or that was the most challenging thing that we did. And that actually allowed us to do it to to do the whole project in the first place. And that is that we were able to do a full card implementation of it, a mix on, I think in this case and Infineon actually does. These figures are probably from the sixty six I think we now use to seven 77. And you see that issuing still takes depending on the number of attributes that you want to issue a considerable amount of time. But showing some attributes is depending on the number of attributes you want to show. If you have to attribute stored and you want to show one attribute. You'll
see that it's almost a second. And if you want to show two attributes, it's zero point eight nine seconds. But if you have five stored attributes and you want to disclose five of them, it's zero point nine seconds below a second. This is usable. This is not usable for all kinds of applications, so for instance, the application that I mentioned that inspired this research in the first place, namely public transport. That's a no go because then people will have to wait one second before they could actually go through the tunnel. That doesn't work. But for certain online stuff, it works. And later on in the afternoon, I'm around to give demos so you can see how the performance actually feels. And this is really I think we are beholders in a way, a world record in this. We are the fastest implementation of this stuff on smart cars. But before that, we need to have really good access to the critical pressure, and we're actually talking to smart card providers now to actually give us that access even on other platforms, because that would really, you know, help us get this speed even better. I read told you that we use NFC contactless card, and that means that we have all kinds of terminals that we can use to, uh, as terminals in the in the MRI system. So we have like Nexus tablets that run verifiers. We have you can use NFC phones and we even at some points are asked a point of sale manufacturer to implement Irma on one of these phone to sell dominos. So those are usually used for Ben or Max Stripe payments. That one is horribly slow, though, because it runs on Java and stuff, but it works. So I told you about the card, this contains the credentials. Now I'm going to tell you about the application. What, how, how do we make sure that you can actually use that system as a relying party? So first of all, of course, the most important bit is the the the the application that allows you to verify certain attributes. There was already a picture on the on the previous slide on
the on the on the left. This this tablet shows you an error, my verifier. And basically, it has a hardcoded set of attributes that it wants to verify in this case. And then if you present your card, this is an implicit acknowledgment, acknowledgment that you want to show. Reveal your attributes there, and then it verifies whether those attributes are actually present on the card. There's also a card proxy because, like I said, you want to use this also in all my scenarios, but most PCs or devices don't really have a smart card reader. So we implemented something that we call the card proxy that allows a I'm sorry mobile phone to be used as a card reader for the attributes while signing in to a website with a visual browser on your ordinary PC imprints. I'm not going to show you here how it works. The idea is basically that your mobile phone scans a QR code only on the screen of the ordinary PC, and that handles then the authentication with the session that is basically encoded in this QR code. So then the backend can decide, OK, this is OK. Now I can show you the content on the on the normal channel, on the on the browser, and there's something that we call the card management app. There's an application that the user typically uses for himself to see what credentials are on there on the card to delete credentials, to maybe change pin code. And something very important, we think, is the ability to view the log file. The log file maintains all the actions that have been performed with this card. So this means that the user can see which credentials were verified, that with time, which time by which relying party. So this is like a second channel to verify that shouldn't relying parties actually did ask for stuff that they they claimed they were doing? And you can see after the fact that they may be over if they so if that happens. So this is a second way of verifying and keeping relying parties in check. If you if you want to look at the whole system already, basica
lly we see card holders and relying parties as users. Then there's providers that provide all these kind of services that are essential for the functioning of the system. So this is credential issuers, card issuers and a revocation authority. The scheme authority basically decides who gets into the respective roles and gets certificates to do that. So, for instance, a credential issuer needs to have a keeper with which he can sign the credentials, and that needs to be stored in a central repository so that the relying parties can later use those keys to verify that the credential is in fact, authentic. And then there are certain services at the sides that you also need to get the system running. Like I said, so this is this is the basically what we have here. We are currently running a pilot with students. We really want to do this in a more in a larger, slightly less tech savvy audience. So if you have ideas come, please come forward later after the talk. But there are certain limitations still. So one of the things I already mentioned, there's a thousand only four bit RSA key used, which is really too low because of the computational limitations of the card. We cannot do anything with the quality proofs and we cannot do parallel proofs. So typically, normally speaking, engagement basically answer you can basically show one credential, then another. And in the way the proof is constructed, you can be sure that those two proofs actually belong together. This is something that we cannot do in order to remedy the situation, because otherwise you would maybe be able to fool credentials and prove, for instance, that your eye could be able. I could, for instance, prove that I'm over 18 and German if somebody in the room is German without me doing that proof. So this is this is limited by constructing a channel between the card and the relying party and ensuring that only authentic cards talk to the relying parties. We are implementing replication, and I already told you
there's weak binding of the card to the cardholder. So there are some issues. But let's get back to the original theme of the story. So there we have this Irma, there's this heroine of the story that's trying to protect her privacy by implementing attribute based credentials. But the powers that be the powers that you know, we're there already before the internet was existed at some points figured out how the internet works and trying to exert their powers also onto the internet, and therefore they will also exert their powers onto their mom. And you know, there's a general discussion that in the fields of and this depends a bit on the country where you live, whether you should have like identity systems in the first place. So why are we building an identity management identity infrastructure? If there are these risks and what are these risks? Well, one of the most important risks is function creep. Because once you show some attributes to some ruling parties, to some services, if you, uh, if you're used to showing that you're over 18 at a liquor store, if you're used to showing this and this and this, and if at some point you use your image card everywhere and everywhere, it becomes more and more natural to show even more articles everywhere. And what is stopping these service providers? Um, asking for whatever they want, because that's what they're doing now, anyway, right? So and now we're giving them an infrastructure that is giving them authentic attributes. So before you could maybe, you know, lie about your name to evade a real name policy. Maybe you could lie about your address where you live if you want to shop abroad. I mean, there's like services like border links or whatever that allow me to shop in Germany or in the U.K. or the U.S. and they just ship it to me in a way I'm lying right because it's not my address. More fundamentally, maybe, is the fact that the service provider sets age restrictions now. Typically, service providers are American and thei
r restrictions are ridiculous. So, you know, typically parents in Europe will say, OK, you too there to judge their children or you can go on Facebook and in some cases the children just go on Facebook and live other agencies themselves. I mean, they're they're good. But you know, this is no longer possible if you have a system like Irma that would allow Facebook to verify the age of whoever tries to sign in using Irma. You will not be able to lie about your age anymore. And attributes our cookies, really. If a big drop or a big company like DoubleClick would register as a credential issuer and whenever I visit the sites that is affiliated to DoubleClick would issue a credential with an attribute that is identifying and issues that to my card. And then when I visit an arbitrary other site. That is affiliated to DoubleClick that asks for that credential and that attributes to be revealed. I'm tracked all over the place. And again, it's very authentic, I cannot play with this stuff, I cannot even try to taint the database or do anything. It's, you know, that's a problem. And I told you about the scheme authority, which has a very important role to play defending against the things that I just talked about. But the problem is that who is the scheme authority going to be? This is really a hard problem because we we talked, for instance, in the Netherlands, they are thinking about implementing an electronic identity card as well, like the German system. And we talk to them and then at some points we thought, OK, suppose that at some point the Dutch government would decide, which I think would be very, very cool actually to allow Airmar to be on this Dutch identity card. Then the question comes up, who is going to be the scheme authority, is it going to be the government? Is it going to be an independent party? Is it going to be a company whose that's going to be because that that has huge ramifications for the potential of abuse of such a system and especially if, you kn
ow, attribute based credentials are used to prevent the government from tracking you all over the place. There may be nothing. The government being the scheme authority is not a very good idea. The underlying theme of attitude of at least the earmark system is that we want to put the user in control, which I think is a valid point of departure. However, you have to be very, very careful by not making the user responsible for everything because the user can screw things up horribly. And you really have to think about these things. And I must admit that this is hard and we don't we don't really know yet how we can help the user making the right decisions in all cases. So this is this is also a problem. Finally, also what I mentioned is there is this carte management app that allows you to see all the credentials that are on your card. Of course, this card management app is protected by PIN code. But you know, if there's some malware on my my mobile device that I use to verify you and I'll do something with this card management app, it's trivial for that malware to intercept my pin code and then later, you know, access these credentials and do whatever it wants. So this is really a way to pickpocket my, my, my, my, my, my card, my credentials. And there's many, many more, many more. There's no auditability, which actually, I mean, this was this is the purpose of the system, right? But in certain use cases, this is a problem for relying parties that want to use that system. OK? Told you about the cards many months after the implements that API. Of course, a very important issue is also the fact that attribute based credentials, if you and these kind of privacy preserving systems really go against current business models. And the underlying question is perhaps that OK, of course, we should build price enhancing technologies, but maybe we should also try to counter the business models that, you know, go in, go against this. People want to share and and for for, uh, for, u
h, uh, say, more government kind of people. They always have this argument that anonymous, anonymous anonymity is abused by people that don't want to show what they're doing. So for them, this is a disadvantage. I'm not saying that it's for me, isn't that disadvantage, but this is certainly for certain people a disadvantage to these kind of systems. So the question is, I've been telling you about the school program, and I still think it's cool, but I'm also telling you about these problems that we see with a system like this. So how can we reconcile good and evil? Can we reconcile good and evil? Should we reconcile? Well, I think. And we need to we need to think about how to make identity and identity systems more privacy friendly because they are out there, they're in Belgium, they're in Estonia, they're in Germany. The German system is slightly privacy friendly. I should say they allow you to approve certain attributes about yourself, but they are. It's limited and their security features are different. Different talk all by itself, actually. If you want to know more, please discuss Come up, come up. So you know, these things happen. And if these things are built, then I'd rather have a system that has the technology that allows you to to make it more privacy friendly from the start. And not make it totally trackable, like a belching system or a different duchess system. But I think the more fundamental point here, and that's the the message that I also want to send here is that, you know, technology alone doesn't help, is useless, is helpless. It's whatever less. It's one thing you do together with. You know, legal safeguards, together with economic principles, business models, whatever, think about these things as well and in general, think as a society about how you want to use this system, these systems. Because even if we would implement a totally privacy friendly attack with presidential system like Irma and implement this on a national ID card, if people re
ally want to abuse that system for total surveillance, they will be able to do that. But at least in this kind of way, you make it much harder to do it. And if you would have the proper controls in terms of a good scheme authority that has it independence, if you would have proper legal safeguards, if you would have proper incentives to use these systems in the right way, then we actually would have a world that is much more privacy friendly. And that concludes my talk. Thank you for your patience. And are you listening this early hour here in Hamburg? If there are any questions, please, please feel free to use the microphones I'm told I. You know, thanks for the presentation, also touching on some of the more challenging aspects. I've heard similar talks about these attributes. Credentials are focusing specifically on the crypto, which researchers get totally excited about. But as you stated, the real problem solve of the incentives into business models. And so I'm curious like, what's your take on the way the system is out there? Or does the technology exist for many years already and hasn't been really been deployed in in the way other than in research labs and the two companies who had been spearheading this effort, IBM and Microsoft even themself are not using that technology. In fact, they are doing standardization on completely different technologies. And if you look at the marketplace and you mentioned the practices on, for example, mobile phone applications illustrate that there's obviously huge reluctance to just ask for a limited number of. Data elements, but instead, people ask for everything, even your most stupid, the stupidest game does that. Yeah, and nobody enforces that. So like how do we actually get from where we are today to anything that is better, even if it's not like all these fancy crypto around it? Yeah, that's a that's a very good question. Actually, you're asking many different questions in one question, which is a challenge to answer. B
ut thanks anyway. It's good. I think your observation about people not using this kind of technology is actually much is not even limited to attribute based credentials. I think it's limited to its extensive identity management systems in general. I mean, we still use username password systems almost everywhere. And this has to do with the fact that in a in any identity management system and this includes attribute based credential systems, the the there is a two sided market, unique users that are able to use the system and you need relying parties that accept that form of identity assurance, so to speak. And the problem is, of course, if there's no use, there's no ruling party is going to implement that interface. And if there's no ruling party implementing that interface, there's not going to be a user wanting to use those systems. So that's that is in itself a challenge. But you have, I think I disagree with you on that. But there are many identity management systems used today in different in different industries and for consumer based web services like if you think of course this one, you find out all over the place. Yeah, but the challenge has been and you hinted slightly to that is the choice of the technology. So you had these smart cards. Obviously, if you want to use smart cards with your regular web browser, you would be you basically cut 95 percent of your audience away, which is for many of the internet services. Obviously an issue, even if they if they kill three percent of the audience. So how you actually get to this have an incremental deployment stories is sort of the challenge. Yeah, sure. And that's why we why we said, OK, we're going to use a contactless cards. That's what we said. We're going to implement stuff on NFC phones and tablets, which at least allows you to use these things on on tablets. And we even have thought about integration integrating that stuff with PCs. But yes, this is a challenge, but we're taking it on. What else can I sa
y? But more questions? OK. I wonder if you have if you go, for example, to a shop with your card? Yeah. And how you make sure that that the shopkeeper really only requests the attributes that you want to reveal. So say the shopkeeper tells you, Oh, I'm only asking for your age, but how do you keep it on your card? How do you verify that that's what you're selling asking for? Yeah, that's the principal way to prevent that kind of stuff from happening is by giving the shopkeeper, in this case, a certificate that restricts him to only ask for the H. He cannot ask for anything else because the card will just see that he does not have a certificate for it. That's how you basically prevent that, because otherwise you run into issues with, OK, who's a user interface? Am I using where I actually see what he's asking? And is this actually what he's actually asking through the card because the card doesn't have to have a user interface? Thanks. Yeah. Number three, maybe because. OK. So when a shopkeeper says, OK, give me your car, I'll check your age with it, and then you said the shopkeepers some little gifts, the card, a certificate that proves that the shopkeeper is authorized by the scheme authority, right? Yeah, but that's a long process that doesn't involve the same authority and kind of an online way, right? So there's no way to revoke that certificate. So if someone stole the shopkeepers certificate for, let's say, reading of my name or something like that, you could just put it in its own device, walk around with it and steal people's information until the shopkeeper certificates validity date runs out. That's a thing you even have a way to validate what the current status. Yeah, that's a good point. Yes. Actually, we use a standard trick that also is used in the electronic passports where, of course, the smart card cannot maintain its own time. Right. It doesn't know the date, but it does know the last time it saw a trustful reader. And then it records the date of t
he truthful reader as a best approximation of now. So but that's, you know, that's at least increasing. And then at some point the credentials expire. But definitely that is an issue. This is how we tackle it. You can always add revocation to standard credentials sort of certificates because these are just basic certificates. You can add that. So that's always a possibility to revoke eternal. But lots of different cards have lots of different vendors, and there's lots of mechanisms below the level where you operate, there's the anti-collision stuff, the serial numbers, there's no different protocol versions, so there's many ways to identify the users of this card long before any of your beautiful software has has ways of preventing that drew. That, of course, is that that depends on the kind of car you use that depends on the on whether you use a random random identifiers instead of a fixed identifier. So you have to be very, very careful. But even then, even our own research and our group shows that even if you put all that kind of stuff, you could even distinguish different kind of silicon. But just the way that the hardware performs. So in the end, yes, that does. That is a possibility. But you have to do much more work this. How are we on time or? So we still have 10 minutes left. There are question number four, maybe I'm in a physical shop too. Does the shopkeeper use NFC? Can he? I think he shouldn't. OK, explain why he shouldn't. Well, I could take my card, put it in a microwave, steal your hat and show your card with a picture. And I didn't know was that take your card, put it in the microwave and show shall not put my card in the microwave and put your cat behind it so it can read it. Yeah. Oh yeah, sure. Oh, sure. But yeah, yeah, sure. I mean, if you but I mean, if you would, if you would steal my card, you could use that. Maybe you would have to eliminate it over and put your picture on it. And then that would be possible. But that's depending on the kind
of security features that you have on the card that will be easier or not so easy. Well, I like the independence of using NFC, right? I could use my smart phone and just have a high powered sender so I could have your card somewhere in the vicinity and just put my card right on the device and say, Yeah, that's me here. My picture, right? Yeah. These are yeah, of course. I mean, this is this is in general with contactless cards. So you have really kind of attacks, which are an issue. Yes. I have two quick two questions. The first one is you said that you use pins to manage the credentials. How to prevent brute forcing of pin codes. Yeah, OK. You a long pink pinkos. I mean, this is, I mean, in general, I mean, I guess the the underlying principle, the underlying idea is that you keep your your your in my car to yourself, you're not supposed to give it. If you lose it, you should revoke it. And in that way, avoid abuse of that. But, you know, once you lose a card, in this case, this is a problem we have been thinking actually for the card management app to to do something slightly more advanced by not only using a pin code to access all the credentials in the card with friends and binding the card to one specific user device. So you would have to have at least the corresponding device to actually read the full contents of the card. OK. That address your concern somewhat. And how many credentials can you store on one card? Not so many. I think about between 10 or 20. So this is limited. So actually, one of the things we also want to think about is, OK, can you somehow do kind of like caching of credentials in any meaningful way while still being pretty friendly if you store this stuff either on your own PC or on the cloud or somewhere because at some point? Actually, we do believe that, you know, you know, the basic credentials, the basic attributes, you want to prove fit in like five or six credentials. But as soon as you want to do special applications, phone applica
tions, the number of credentials you could collect is going to be huge. So then you have to think about these issues. OK, thanks. Thanks for the questions. I've got a question about whoever the authority is storing all of this data. Have you thought about how you can distribute that data among many authorities so that no one authority has ever knows everything? Because if I'm imagining in if this were to take off in 10 years, 20 years, something like that, you might have all of the information about everybody in the world and you don't want that on in one big, it becomes a honeypot. Sure. No. And that's that's a good question, because actually, that is what airmen try to prevent, because it actually it actually, uh, the idea is that you store your credentials on your card. So not anywhere else credentials. Sorry. So it doesn't have the credentials. No, no, no. The scheme authority only managers who can has access to the infrastructure, let's say it doesn't store it, only the card source. And this is a big difference from, say, Irma and the more traditional identity management systems that I showed in the beginning. Well, thanks for the question, because I think it's clear. Yeah. The person in the back three, yeah. Um, can you do the age verification that I'm older than 18 without revealing my actual age? Yeah. OK. But yes, yes, the answer is yes, but we use a trick here because one of the things that we I told you we can only do equality proves in it makes the crypto library. The full implementation actually allows you to ask an arbitrary question like, OK, where is this person over x years and then based on your date of birth? The system would actually compute to prove that yes or no. In our case, we cannot do that because the card is way too slow for us. So we basically slow store a bit and we have predefined age ranges that we store. And then a lot of question, if I buy something online from a physical shop, would it be possible that my name and address get revea
led to the mail carrier, but not to the actual shop? Not because I mean the the the holes, you know? In a way, whenever you use the email system a a session, a secure channel is set up between the card. Really, the cards is the endpoint and a relying party on the other end. Of course, if the ruling party at the other end is going to do whatever it wants with those things that he gets, I mean, that is something that we cannot stop. Except that at some point a scheme authority is going to say, OK, you're going to you're abusing the system, you're out. Yeah. Thank you. Last question, I guess I have a question regarding purpose limitation in in in the scheme of things in general with the assistance today, you basically the idea was of the data protection regulation that provided stem cells or bio through regulation get incentives to ask for as little as possible. And you mentioned that it's a shortcoming or challenge for your system as well. Mm-Hmm. And that is indeed tricky because think about Angry Angry Birds who ask for your location and obviously don't give you a choice. You can't say, no, I don't want to give him location. The game is still supposed to work. So someone would have to look at the purpose of the application and then decide on what would be legitimate and what not. Apparently, that doesn't happen today, so I wonder how you would imagine this to work in the future. Like who would check regularly, ideally with every software update, whether the new feature is actually reasonable for that application or it's not because obviously application providers themself would argue I need the location for location based advertising, period. They they are in the control. The users are not putting the the user in the control doesn't help because the user has no voice in that game. True. And that is that you're sketching the scenario of, for instance, installing an application on a mobile phone or whatever or anywhere else. And that in that case, there is not really
a a third party that sort of protects the individual user against basically the big power of the application, provided that basically sets the rules of the game. And here in at least in in the email scheme, the scheme authority has to issue a certificate to the ruling party, allowing him to access attribution in the first place. So if he does not get a certificate, he does not get anything. Now, of course, it depends on the on the on the spine of the of the scheme authority, whether this is going to make any difference in the real world, yes or no, but at least the default is that the ruling party gets nothing and this is different from the situation now. But it well, it depends on, of course, the application you have today. But it it doesn't seem that there's a story on who would actually do that. I don't think the identity provider will go off and will talk and look at the app to every application and then say, OK, now this is this is useful practice. Like if I have my identity provided a fast moving German government, they will then look at all the applications and internet, and we'll figure out on whether that's a fair use. I don't think that's particularly realistic and also like they don't even have the manpower to do that. That is that is an issue. And that's why I said and this is the discussion about OK, who is going to be the scheme authority and is this going to be trust? Is it really going to be trustworthy and is it really going to do that kind of checks? And why totally agree with you this and what their business model is because obviously they would have to have lots of people to actually check it out each and every application, whether they do the right thing. Sure. I agree. OK, OK. Thank you. We still have one very short question. I have been assured from the internet, OK, from the internet. Call the voice of the internet. Yeah. One question from the ISC was, do you thought about and display on the cards? So maybe you can check which information the
shopkeeper wants? Yeah, that would be cool. And actually, I mean, I think I've even seen pictures from the 70s of these are having these kind of cards with displays. So this is definitely a possibility, but we haven't experimented with that yet. OK, thanks. Thank you, internet for the question. Let me just point you to the website for more information if you want to see the the. There's also lists the the GitHub link, where the sources are for all the calls and anybody interested in demos. At two o'clock at the noisy square, I will be around to give demos. I still have to find where the noisy squares. I have no idea. Let's see. I will find it. Maybe see you there. Thank you very much.
