Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/79 Thanks!
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 of
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 conventional 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
anybody 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 ordinary 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 will 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, basically 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 their 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 know, 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, uh,
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
really 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.
But 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 say?
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 the 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 applications, 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 revealed 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.