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/944 Thanks!
I guess many of you are using P-gp
here. If you do raise your hand.
Good hackers.
So if you want an introduction
to someone new that
you know someone else has a key to.
You usually have to do the little dance
as quirky. Do you have a key to that in
that person?
Because that's well, let's admit it.
Pulling keys off key servers is boring,
but that's the way you usually do it.
What if I told you there is a better
way?
What if your friends and friends
of friends can attest that a certain key
actually belongs to someone in
a more nicer way than
just attaching signatures to putative
keys?
Our next speaker will introduce you to
claim chains a system aiming to solve
this problem.
Please give a warm round of applause to
doctoral researcher Mario the
chaos.
Take it away.
Hello. Hi, yes.
So he's given a great
description of what we would be talking
about, it's called claim since it's
a modern key distribution mechanism
protocol in implementation
that we've done in collaboration with
both Alkalinity and Carmela Troncoso from
EPFL and Jordan Aziz from
University College London.
I might ask you this again from
University College London.
So in a few words, Clinton is
a decentralized public key infrastructure
that supports privacy friendly
social verification.
And if you've read the description
of our talk, you know that we will be
mentioning a lot the word blockchain.
And
yeah, so
it is a hype. Of course, blockchains have
been used in many applications,
but they actually they provide some very
good properties
that might be useful for public
infrastructures.
For example, they provide high integrity
for the data that we store
past data become tamper proof.
It's very difficult to modify them
without changing overwriting the
history.
And we can also be sure of the
authenticity of the data because of all
these cryptographic signing and harsin
going on.
And by definition,
blockchains are decentralized
so they can provide good availability.
You can get you can go to any bitcoin
full node, for example, and verify
your transactions.
There are censorship resistant if you
want to break down to bring bitcoin
down, you have to go and bring every
full node down,
and they've solved the problem of global
consensus through this
lottery mechanism of proof of work.
The more resources you distribute, you
contribute to the systems
than the, the more
balance you get in the lottery,
more tickets you get.
So the first generation of
blockchain based public infrastructures
are based on SATs proof of
work
blockchains, for example, named Coin
and Blockstack.
They have replaced
the kind of use
the Bitcoin toolkit, the cryptocurrency
tokens for identities.
Therefore, you can buy identities, you
can sell, you can sell them to others,
etc. and they belong to you.
So this is a
more powerful abstraction for identities
compared to PDP keys as we
use them today, and they also provide you
with a global namespace.
If you have this identity in name coin,
it is you.
Everybody will
recognize you as the owner of that
identity.
On the other side, they provide no
mechanism for social validation.
If somebody claims to be, for example,
uh, at least in that system,
how can we know out of all the people who
claim to be allies that this person is
actually there is no level of trust
mechanism.
All transactions are public and this has
some privacy implications.
For example, you might be able to through
the transactions to infer
that some identities are linked
to each other.
There are some inherent fees that
users have to pay
for buying coins and foreign transaction
fees. And of course, it's very resource
expensive with a proof of work.
There is a 10 minute latency
for every block to be a specific
number of transactions that can be
included.
Yeah, and so on.
Then came the next generation of public
infrastructures and blockchains
with key bays and the clinics
that can that can be deployed
by email providers, for example, hasn't
email.
So what they did, they have replaced
the transactions block with
a medical traffic stream.
This could been a bit what this is
and whether he achieves accountability
for the providers with regards to
the keys they publish about their users.
So imagine, for example, that email is
using Connex.
You could go and retrieve
the public key material for
its email user from the iconic
set of it. And you also get some proof
that this is the same key that
everybody's getting at that specific
time.
So you also have easy discovery because,
you know, for example, that Alison's
email belongs to the email provider and
you go directly there and it's very
efficient because it's only Google that
maintains and constructs the structures,
and they can provide you with very
efficient proof in a few
kilobytes that actually this is the right
data that you get on the other side.
They do not prevent the give.
They just make it detectable at a later
state, which might be already too late.
And to an extent,
they are centralizing
the public infrastructure, which
opens them to a
tax, for example, because they are a
single point of failure.
If the email connectivity is down,
then you won't be able to
get the PDP key material
for their email users
and also puts
the providers in this privileged
position to perform surveillance with
regard to who is getting
who is going to communicate,
revealing the social graph of the users
would like to hide, etc..
So the metal binary prefix three that I
mentioned before is this
is a medical binary tree,
as you see.
But the difference is that in
order to sort the live notes
when we are inserting them, we are using
a verified random function instead of a.
We use this very fundamental random
function.
It is a function that produces a unique
output, given a private
key.
So imagine that they have a private key
four that is compatible with this
verifiable random function.
I can produce an output that looks random
to everybody. You cannot guess it.
But if I give you the public key, you can
verify that this is the unique output.
And this as
a result will apply to Merkle
trees.
He assures us that everybody
who will search
for the
specific label will end up
to the same leaf node
in the Merkle tree.
Therefore, therefore achieving canonical
vacation. I cannot.
If if two people come
to call the email provided that it ask
for Alison's email
because of these properties,
they both get the same live node.
Now claim, since how are we using
the metal binary prefix trees and what
are we doing different compared to here
based on a context, for example?
But we do different things.
We push for decentralization
by having the
users host
the claimed chain by themselves.
So we have a claim chain for its user
or for each of their devices or for
each of their identities that they want
don't want to connect.
For example, you have Alice.
Here's what I'm saying Bob his own saying
and Guy Fawkes would be anyone
in it, even Alice.
Here's a different scene.
There is no consensus, and it's not
global. Consensus blocks are updated as
needed. You just generate the structure.
Sign it with the signing key.
And that's it.
Everybody can verify that there is
a sequence.
This sequence is valid.
Imagine now that at
some point there is a fork in a chain
because two valid blocks originate
from a given
block. Then then this can
be interpreted as a compromise
because somebody has got my
signing key and publish something
different. Or it could be that I've tried
to equivocate to one of the readers.
And finally, we've also added
a fine grained access control mechanism
based on capabilities
that allows the claim, saying owners
to select who can read the specific claim
and for and that
through the non evocation of the medical
prefix trees, we are sure that all
readers get the same content.
Yet we need a way to propagate
this information, because, yeah, how
do we know of updates of our
friends? How do we find out that
the big how does a key distribution
works?
We've we've introduced this mechanism
of cross crossing where we
include a voucher, a stamp
of the later state of
the blow, reclaim claim chains of our
friends. So you see here, for example,
that Alice includes an assessment
for Bob's latest block and Guy Fawkes
latest block.
And Bob
also includes a statement, but
at a previous point that he
was aware of.
It might be stale a bit, but that's
how consensus and
propagation works in these systems.
So we have propagation of key updates
in cliques of users and groups
of users. This is how gossiping
works in the real world and between the
real humans anyway.
We don't vouch for we don't
just append cryptographic signs
on keys of other users,
but we also
vouch for the later state of their
view of the world.
And we can use this cross-cutting
mechanism for introducing friends
for social validation, a web of trust,
while at the same time preserving the
social privacy of the social graph of the
claim. Team owners
and overview of the claim saying
properties so claim things
are high integrity
authenticated data stores high integrity
because of the blockchains
and the medical prefix three
authenticated because of all the signing
going on that can support
generic claims.
So we've decided to use this for the
public infrastructure.
You can use the claims in structure for
building access control,
delegation or command and control
for your botnet or whatever you might
come up with.
At the same time, we ask for privacy
of the claims that are published, even
though this even though everything goes
public. If we do not reveal any
information about the content
of all
of the claims or who is
up or about the readers of the claims,
and we do that via capability mechanism
that we I'm going to describe in a bit.
Privacy sometimes can mean case
equivocation I could present.
I could then keep two different things to
different readers.
We put we again prevent that
all readers get the same view.
The cross-cutting mechanism enables the
propagation and voting of the later
state of linked claims, since
I've mentioned that they give location
attempts and compromises produce
nonrenewable cryptographic evidence, the
claims in forks and nonrenewable
cryptographic evidence, it means that we
can take them.
They are self-sustained
evidence that we can share with a world
that we've observed two blocks
originating from a
specific block in time, and therefore
something is wrong with that, Clinton.
Now, with regard to deployment and we
spent a lot of we've done lots
of work in evaluating how
Clemson can scale and how effective it is
with regards to key propagation, etc.
and how what are the bandwidth
requirements?
What how long does it take to
compute the structure, etc.?
You can find all this information.
The claim saints GitHub, the database
where we have our paper, a
claim status is very flexible in terms of
deployment. It can work in the federated
scenario like in so it can
work with high availability,
online data stores when we just go
on and upload or for all of our blogs,
or it can even work in a gossiping,
ad hoc scenario when we just append.
Do you want to?
How do you say this word?
So anyway, when you just include
the proofs in the email is that you want
it when you attach that
to the evidence you want in
the emails you send with your friends
with.
And we can do it that we can do that in a
very efficient way by including all
the claims that we want to include for
that reader, plus
some evidence that these claims
are actually part of
the claim chain and all
the proof of inclusion
in the METTL3, etc..
Now the internals of claim changed.
We still have some time for that.
A The blog structure has
some claim chain protocol information
like the version, of course a time
stub, the block sequence index.
Some nodes that we use for achieving and
likability between
the claims and the capabilities across
different blocks claim
metadata or the connected identities
may be the claim saying.
Saw a Twitter handle or an email
that the user wants to connect into the
Scream team.
And some public
keys that they are needed for the
operation of Clinton.
We need the public key for signing
can you blocks the public key for
the verifiable function that we use for
the military prefix three and the
difficult monkey that we use for
the capabilities technique?
Then the the main
the core element of the
block is the block mapping, where
we store all the claims and the
capabilities in the form of a metal
prefix. Of course, pointers to previous
blocks, that's how we achieve how we
connect the blocks into the
blockchain.
Now, if we can see that all of the.
A feeling on the left as the
payload of the block, we
sign it and we attach
the signature, and this is a self-sustained
piece of information that we can attach
to different to any mail or we can
stored in an
online store that we do not trust
and still and still be sure that no one
can tamper that information.
If we want to add a claim,
for example, we are analysis a
medical prefix three and we want to
add a claim
for Bob.
First, we need to to define
the label that we will be using for
Bob.
From now on, it's going to be bob rise of
the net. And let's imagine that the claim
is the latest head.
So first, we're going to compute the
claim key with a verifiable random
function using aliases, private key.
And then we we're going to put inside
bob a tricep dot net
plus the nonce so
that we get active unlike abilities I've
mentioned before.
Then we can calculate the index
of the live node,
how we're going to store that lymph node
in the tree simply
by taking the claim key
and hashing it with the string lookup.
And we're going to generate a symmetric
activation key again by taking
the the the claim kick
from step one and appending
appending conclusion and then hashing it
all together.
So we
increase the claim content with the
symmetric encryption key that we got in
step number three, and
we also include the VLF
proof that other people can go
and get to be sure that the
claim key that we verify that we've
computed in step number one is actually
the correct and the only one.
So that's how we get
the lymph node
that corresponds to the cross
for Bob's claim for Bob's Clinton
story. We started out in the three nick
scenario.
We want to add the capability for Guy
Fawkes to read a Bob's
Cross Plus into Alice
in Alice's Clinton
first step. We use a difficult one
to establish a third
secret s between Alice
and Guy Fawkes.
So we used that third
secret into a
house again, along with nuns
and with a look up to generate
the the capability look up key.
That will be the index of the
look up key of the capability.
Claim that we're going to study it
in the three nuns is here
in order to achieve applicability.
And to hide the patterns of how
capabilities are added and revoked,
we're going to derive asymmetric
encryption key as we did before,
and we are going to encrypt
the claim key
from the blue cliff
note that we've added before.
Without without the symmetric encryption
key from step three, so that
the guy folks can decrypt is in the
future.
So we generated
a live node and we started in the dream.
Now if Guy Fawkes wants to
retrieve a.
That that it wants to
find out the latest update for
Bob in the story.
He's going to do the reverse process.
He's going to establish a difficult,
massive search secret as between
Alison Guy Fawkes and
get the capability lock up key in the
symmetric key in the same way that
Alice computed it.
And he's going to go to
Alex's claim through
a mental mental study and retrieve
the corresponding leaf note.
He's going to decrypt it with
the symmetric key from step
number three.
And he will be able to get
the claim key for Bob's claim.
So far,
uh, if you if you
remember, the claim for
Bob's claim includes
the v rf, the heart of a v r
f.
So he's going to retrieve
a.
Bob's claim from Alice's
medical prefix three and decrypted
a.
Using yeah, again, he can compute
the VLF key because
of step number four.
And are we
done? Not really.
He needs to use the v
r f proof that is embedded into
the decrypted claim
in order to verify that actually the
verify prove that he gets is the
only one that could have produced a
very private key.
I know it, yeah.
We went through that very fast.
But again,
all this information see in the paper.
And you can take a look at it, or please
come find me after we're done, I have
more slides that explain how proof of
inclusion work, how proof of absence
work, etc..
Yeah, well, I think I should have
mentioned these that in step number four,
if Guy Fawkes
tries to retrieve a capability block
and cannot find it, it means that
Alice has not given to Guy Fawkes
the capability to read
a.
And the claim about Bob
or week end at that point,
Guy Fawkes cannot know whether a
capability for for four bob exists
at all.
Now we've submitted to
this talk for the city's resilience
track, and we understand
that this is academic work to an extent,
but we do care about resilience and we
would like to share some of.
Yes.
What what way we decide
to do that.
First of all, we started with
a field research to understand user
needs.
This was done by some
researchers in Paris.
Later on, we we
pick projects that care about resilience,
need to be open to collaborations
with communities that they are already
working on these problems.
And we've done that, for example, with
some with another organization
in Germany and
we in close collaboration, we felt
equipped with that a.
And we've used.
Techniques from that, they are actually,
again, very, very,
very well used.
Um.
OK, so, so in
academia, that is in these techniques
going on now
in applied research
that he's pushing for
formally verifying the properties
and the code that you're producing and
for claim S. Specific,
we have we have formally defined
all of the security and privacy
properties using cryptographic games.
So we know, for example, that we provide
non-native location under what terms
and that we can provide and likability
across blocks again because of this
and this and these cryptography game
that we can combine together.
And we also have a formal,
very formal, formally verifying
implementation of our cryptographic
components in F Star.
So you can go in and find the American
prefix three and the V r f function
in our GitHub repositories.
When it comes to resilience, we need to
know of how our systems
can scale and
therefore we've used simulations
with real world data from the
dataset.
This is a leaked
email directly
from a company called Aaron.
So it's usually used in the academia
for.
When we need to simulate real world
communication patterns
and we've used these for calculating the
efficiency of prop of
the Cross Classic Protocol in propagating
the latest state, um
of other people's key material.
When it comes to interoperability and
plans for gradual deployment,
as we've mentioned, claim change
is very flexible on how you're going to
deploy it.
We've chosen to be and we know,
for example, we haven't done much yet,
but we know that when it comes to
actually giving started to implement
to give this to users,
we need to be compatible with all
existing email encryption applications.
So, for example, we want to be compatible
with the agent
again, something that is very important.
I don't think we've done great work here,
but a
usability of
email encryption.
How do you how do you
perform key management
in a way that the users can understand,
not mistakes?
What happens when we knew
you need to revoke a key or
there's a key compromise?
How do you communicate with a user
and how um
and how
we can act upon that?
And yeah, this is
this is a great debate that is going on
on that. And unfortunately, we
we don't we cannot say that we've solved
this at all.
We focused on,
uh, coming up with the structures
and the properties and the,
uh, simulating
how climate change can scale and work
effectively.
Hopefully, though, we've we've been able
to do all of the above because we are a
multi-disciplinary team in next leap.
We've got sociologists, we've got
philosophers, cryptographers
and it's great to
have European projects that are
focused on privacy and secure
communications.
And um, they
can actually
use their knowledge of
all parties for that.
And I think we also
this is also pushing for open innovation.
All of our material
reports and source code is open
to the public and
everybody can go and take the
claim same structure and use it for other
for other types of applications.
So this is how we yeah, we we can
extend a claim things
now. So we have a bit of time for
questions.
Thank you, sir. Thank you very much for
your time.
OK. We have four microphones here
in the hall, police line up next to them.
Thank you again very much, Mario.
We do have a question from the internet
signal angel, please.
Yes.
As far as I understand,
to use this system, you both
have to do the signing dance just
as with GPP, but also
to ask your friends to give your read
access to parts of their social
graph.
Isn't that even harder to
use in scale than GPG?
Your understanding is correct.
We still need to do
these crazy dancing
and ceremonies and keep signing parties.
If you, um,
if you want to be sure about that, the
other person that you
have the right claim to for the other
person.
Uh, but
we believe that through this mechanism
of, uh, introductions.
It might be it might actually
know. Let's see how it works.
So this is part of the simulations
and the as you can see on that on the
left, we simulate
the complete decentralized scenario
where we just attach
introductions in emails
and we see that it kind of works
without having to.
If you trust the person who is
introducing you to the other
participants in the conversation, then
you can then we say that we can
have.
Egg, a good start to
email. Emails going out
encrypted with the right keys.
Microphone number one, please.
I'm interested in the expressiveness
of your capability based
access model did support
things like groups.
Do you support revocation of credentials?
Do you support delegating
race access, things like that?
You can do all that.
This is a very. Yeah.
Um, you can.
What we do, for example, we say that you
can use a
simple semantics and then you can do
whatever you like, like threshold
replications and or you can build based
on top of our struct.
But we haven't done it.
Not.
Microphone number two, please
use SHA256 for both
lock up and encryption key generation.
How difficult would it be to change it,
provided it's broken one day?
Huh.
Given that we have
a Clinton protocol version somewhere
at the top of the block structure,
that's how that's how you would probably
change it, but it's no it won't be.
Thank you. Microphone number three,
please.
Hi, thank you. Great talk.
I want to ask about a crypto beat
and a
key derivation process.
Why are we using FHA
hash function to derive keys?
Not some key derivation
function like it's codes for
predictive
um.
I think it's for simplicity reasons,
but.
Yeah.
I don't have an answer of that's probably
what you were suggesting is better.
And would you like to discuss about it
later on? Chris, thank you very much.
We have time for one more quick question
from the internet before we have tacos.
Yes. How is privacy
of the social graph, the cross
hashing insured again?
I'm not sure I fully understand that.
The primacy of the social graph.
How do we protect that?
The privacy of the social graph,
the cross hashing, how is this insured?
OK, so if you take a look at when we add
the claim.
The actual content
of the claim that we put in our
medical traffic studies is encrypted.
And it does not like any information
about the label or the content
of that claim.
So
and because of the capability mechanism
of allowing
only a specific number of readers.
To read the specific crosshairs,
I think that's how we achieve
the purpose of the social graph.
Thank you to everyone.
Sadly, we ran out of time, but Mario
will be here for a little while longer so
you can catch up with him over a drink
or a beer.
Well, thank you again, Mario.
The.