It looks like you're having connection troubles. Reconnect now.
01/25/2022 20:26:20
34c3-talk-9094 Latest text of pad 34c3-talk-9094 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!
======================================================================
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. A
nd 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 vo
ucher, 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 the
y 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 actuall
y 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 c
laim 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 com
bine 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? Y
ou 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.
