 I guess many of you are using PGP 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, ask for a key. 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 PGP keys? Our next speaker will introduce you to ClaimChains, a system aiming to solve this problem. Please give a warm round of applause to doctoral researcher, Marius Kutakias. Hello, good hackers. So Hades has given a great description of what we would be talking about. It's called ClaimChains. It's a modern key distribution mechanism, protocol, and implementation that we've done in collaboration with Bogdan Kulinich and Carmela Troncozo from EPFL, and George Zanezes from University College London. I'm Marius Kutias again from University College London. So in a few words, ClaimChain 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. So it is a hype, of course. Blockchains have been used in many applications. But they actually 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 number proof. It's very difficult to modify them without overwriting the history. And we can also be sure of the authenticity of the data because of all these cryptographic signing and hashing going on. And by definition, blockchains are decentralized. So they can provide good availability. You can go to any Bitcoin full node, for example, and verify your transactions. They are sensitive resistant. If you want 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, then the more ballots you get in the lottery, more tickets you get. Oop. So the first generation of blockchain-based public infrastructures are based on such proof of work blockchains, for example, namecoin and blockstack. They have replaced the kind of use the Bitcoin token, the cryptocurrency tokens, for identities. Therefore, you can buy identities, you can sell them to others, et cetera. And they belong to you. So this is a more powerful abstraction for identities compared to PGP keys, as we use them today. And they also provide you with a global namespace. If you have this identity in namecoin, 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, Alice in that system, how can we know out of all the people who claim to be Alice that this person is actually Alice? There is no kind of trust mechanism. All transactions are public, and this has some privacy implications. For example, you might be able 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 for all the transaction fees. And of course, it's very resource expensive with the proof of work. There is a 10-minute latency for every block to be a specific number of transactions that can be included, and so on. Then came the next generation of public infrastructures and blockchains with key base and the conics that can be deployed by email providers, for example, IZMB and Gmail. So what they did, they replaced the transactions block with a Merkle prefix tree. I'm going to describe in a bit what this is. And what they achieve is accountability for the providers with regards to the keys they publish about their users. So imagine, for example, that Gmail is using conics. You could go and retrieve the public key material for a Gmail user from the conic server, 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 Alice at Gmail belongs to the Gmail 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 evocation. They just make it detectable at a later state, which might be already too late. And to an extent, they are centralizing the public key infrastructure, which opens them to attacks, for example, because they are a single point of failure. If the Gmail conic server is down, then you won't be able to get the PGP key material for the Gmail users, and also puts the providers in this privileged position to perform surveillance with regard to who is trying to communicate revealing the social graph that the users would like to hide, et cetera. So the Merkle binary prefix tree that I mentioned before is a Merkle binary tree, as you see. But the difference is that in order to sort the leaf nodes when we are inserting them, we are using a very randomly random function. Instead of a hash, we use this very randomly random function. It is a function that produces a unique output given a private key. So imagine that I have a private key that is compatible with this very fine 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, when applied to Merkle trees, assures us that everybody who will search for a specific label will end up to the same leaf node in the Merkle tree. Therefore, achieving non-equivocation. I cannot, if two people come to Conics' Gmail provider and ask for Alice's Gmail, because of these properties, they will both get the same leaf node. Now, claim chains. How are we using the Merkle binary prefix trees? And what are we doing different compared to key-basin Conics, for example? What we do different is we push for decentralization by having the users host the claim chain by themselves. So we have a claim chain for each user, or for each of their devices, or for each of their identities that they don't want to connect. For example, you have Alice who has her own chain, Bob has his own chain. And Guy Fox, who could be anyone in the internet, even Alice, has a different chain. There is no consensus. There is no global consensus. Blocks are repeated as needed. You just generate the structure, sign it with a 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 this can be interpreted as a compromise, because somebody has got my signing key and published something different, or it could be that I've tried to evocate to one of the readers. And finally, we've also added a fine-grained access control mechanism based on capabilities that allows the claim chain owners to select who can read a specific claim. And through the non-equivocation of the Merkel prefix trees, we assure that all readers get the same content. Yet we need a way to propagate this information, because how do we know of updates of our friends? How do we find out how does the key distribution works? We have introduced this mechanism of cross-hassing, where we include a vouch, a stamp, of the latest state of the claim chains of our friends. So you see here, for example, that Alice includes an attestment for Bob's latest block and Guy Fogg's 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, in groups of users. This is how gossiping works in the real world and between real humans anyway. We don't just append cryptographic signs on keys of other users, but we also vouch for the latest state of their view of the world. And we can use this cross-hassing mechanism for introducing friends, for social validation on a web of trust, while at the same time preserving the privacy of the social graph of the claim chain owners. Another view of the claim chain properties, so claim chains are high integrity authenticated data stores, high integrity because of the block chains and the Merkel prefix tree authenticated because of all the signing going on, that can support generic claims. So we've decided to use this for a public infrastructure. You can use the claim chain structure for building access control delegation or command and control for your botnets or whatever you might come up with. At the same time, we assure privacy of the claims that are published, even though everything goes public. It would not reveal any information about the content of the claims or about the readers of the claims. And we do that via capability mechanism that we're going to describe in a bit. Privacy sometimes can mean a key vocation. I could present, I could encrypt different things to different readers. We, again, prevent that. All the readers get the same view. The crosshousing mechanism enables the propagation and vouching of the latest state of linked claim chains. I've mentioned that the evocation attempts and compromises produce non-reputable cryptographic evidence, the claim chain forks, and non-reputable cryptographic evidence. It means that we can take them. They are self-sustained evidence that we can share with the world that we've observed two blocks originating from a specific block in time. Therefore, something is wrong with that claim chain. Now, with regard to deployment, and we've done lots of work in evaluating how a claim chain can scale and how effective it is with regards to key propagation, et cetera, and what are the bandwidth requirements, how long does it take to compute the structs, et cetera. You can find all this information at claimchains.github.io page, where we have our paper. Claim chains is very flexible in terms of deployment. It can work in the federated scenario, like in Conics, or it can work with high availability online data stores when we just go on and upload all of our blocks. Or it can even work in gossiping ad hoc scenario when we just append. Do you want to? How do you say this word? When you just include the proofs in the emails that you want, when you attach the evidence that you want in the emails you send with your friends, and we can do that in a very efficient way by including only the claims that we want to include for that reader, plus some evidence that these claims are actually part of the claim chain and the proof of inclusion in the mercenary, et cetera. Now the internals of claim chain, we still have some time for that. The block structure has some claim chain protocol information, like the version, of course, a timestamp, the block sequence index, some nones that we use for achieving an leakability between the claims and the capabilities across different blocks. Claim chain metadata, all the connected identities may they be other claim chains, or a Twitter handle, or an email that the user wants to connect into this claim chain, and some public keys that are needed for the operation of claim chain. We need the public key for signing new blocks, the public key for the verifiable random function that we use for the Merkle prefix tree, and the difficult element key that we use for the capabilities technique. But then, the core element of the block is the block map, where we store all the claims and the capabilities in the form of a Merkle prefix tree. Of course, pointers to previous blocks, that's how we connect the blocks into the block chain. Now if we consider all of the fields on the left as the payload of the block, we sign it and we attach the signature. This is a self-sustained piece of information that we can attach to an email, or we can store in an online data store that we do not trust. And still be sure that no one can tamper that information. If we want to add a claim, for example, we are analysis Merkle prefix tree, and we want to add a crosshash for Bob. First, we need to define the label that we will be using for Bob from now on. It's going to be Bob at riseup.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 Alice's private key. And then we're going to put inside Bob at riseup.net plus the nonce, so that we can achieve only capabilities I've mentioned before. Then we can calculate the index of the leaf node. How are we going to store that leaf 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 encryption key. Again, by taking the claim key k from step one and appending encryption and then hashing it all together. So we encrypt the claim content with the symmetric encryption key that we got in step number three. And we also include the VRF proof that other people can go and get to be sure that the claim key that we've computed in step number one is actually the correct and the only one. So that's how we get the leaf node that corresponds to the cross has for Bob's claim chain. We store that in the tree. Next scenario. We want to add the capability for Guy Fox to read Bob's cross has into Alice's claim chain. First step, we use the Diffie-Hellman to establish a third secret s between Alice and Guy Fox. So we use that third secret into a has, again, along with nonce and with lookup to generate the capability lookup key. That will be the index of the lookup key of the capability claim that we're going to store it in the tree. Nonce is here in order to achieve an leakability and to hide the patterns of how capabilities are added and revoked. We're going to derive a symmetric encryption key as we did before. And we're going to encrypt the claim key from the blue leaf node that we've added before with that symmetric encryption key from step three so that Guy Fox can decrypt it in the future. So we generate that leaf node and we store it in the tree. Now, if Guy Fox wants to retrieve that wants to find out the latest update for Bob in Alice's tree, he's going to do the reverse process. He's going to establish a Diffie-Hellman third secret s between Alice and Guy Fox and get the capability lookup key and the symmetric key in the same way that Alice computed it. And he's going to go to Alice's claim tree, metal prefix tree, and retrieve the corresponding leaf node. He's going to decrypt it with the symmetric key k from step number three. And he will be able to get the claim key for Bob's claim. So far, if you remember, the claim key for Bob's claim includes the VRF, the hash of a VRF. So he's going to retrieve Bob's claim from Alice's metal prefix tree and decrypt it using, yeah, again, he can compute the VRF key because of step number four. And are we done? Not really. He needs to use the VRF proof that is embedded into the decrypted claim in order to verify that actually the VRF proof that he gets is the only one that Alice could have produced with her VRF private key. I know it's, yeah, we went through that very fast. But again, all this information is 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, et cetera. Yeah, one thing I should have mentioned is that in step number four, if Guy Fox tries to retrieve a capability block and cannot find it, it means that Alice has not given to Guy Fox the capability to read the claim about Bob. Or at that point, Guy Fox cannot know whether a capability for Bob exists at all. Now, we've submitted this talk for the CCC 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 why we decided 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, projects that care about resilience need to be open to collaborations with communities that are already working on these problems. And we've done that, for example, with another organization in Germany. And we're in close collaboration with Autocrypt with that. And we've used techniques from that they are actually, again, very, very well used. OK, sorry. So in academia, there isn't this techniques going on now in applied research that is pushing for formally verifying the properties and the code that you are producing. And for claim change specific, we have formally defined all the security and privacy properties using cryptographic games. So we know, for example, that we provide non-equivocation under what terms and that we can provide unlicability across blocks again because of this and this and this cryptographic game that we can combine together. And we also have a formally verifying implementation of our cryptographic components in F-star. So you can go on and find the microprefix tree and the VRF 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 Endron data set. This is a leaked email directory from a company called Aeron. So it's usually used in the academia for when we need to simulate real-world communication patterns. And we've used this for calculating the efficiency of the cross-hassing protocol in propagating the latest state of other people's key material. When it comes to interoperability and plans for gradual deployment, as we've mentioned, claim chains 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 starting to implement it 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 GNU-PG agent. Again, something that is very important. I don't think we've done great work here, but usability of email encryption. How do you perform key management in a way that users can understand and not do mistakes? What happens when you need to revoke a key or there's a key compromise? How do you communicate with the user and how we can act upon that? Yeah, there is a great debate that is going on on that. And unfortunately, we cannot say that we've solved this at all. We focused on coming up with the structures and the properties and simulating how claim chains can scale and work effectively. Hopefully, though, we've been able to do all of the above because we are a multidisciplinary team in X-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 they can actually use the knowledge of all parties for that. And I think 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 chain structure and use it for other types of applications. So this is how we can extend claim chains. Now, so we have a bit of time for questions. Thank you very much for your time. OK, we have four microphones here in the hall. Please line up next to them. Thank you again very much, Mariusz. 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 GPG, but also to ask your friends to give you read access to parts of their social graph. Isn't that even harder to use and scale than GPG? Your understanding is correct. We still need to do these crazy dance thing and ceremonies and key signing parties. If you want to be sure about that the other person, that you have the right claim chain for the other person, but we believe that through this mechanism of introductions, it might actually, let's see how it works. So this is part of the simulations. And as you can see on the left, we simulate the completely centralized 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 we say that we can have a good status of emails going out encrypted with the right keys. Microphone number one, please. I'm interested in the expressiveness of your capability-based access model. Do you support things like groups? Do you support revocation of credentials? Do you support sort of delegating, right access, things like that? You can do all that. This is a very, yeah. What we do, for example, we say that you can use Sekpal semantics, and then you can do whatever you like. Press hold revocations, and all that. You can build this on top of our struct, but we haven't done it now. Microphone number two, please. Use SHA-256 for both lookup and encryption key generation. How difficult would it be to change it, provided it's broken one day? Ha. Given that we have a claim chain protocol version somewhere at the top of the block structure, that's how you would probably change it. But no, it won't be easy. Thank you. Microphone number three, please. Hi, thank you. Great talk. I want to ask about the crypto bit and key derivation process. Why are you using SHA hash function to derive keys, not some key derivation function, like HKDF or PBKDF? I think it's for simplicity reasons. But yeah, I don't have an answer on that. Probably what you're suggesting is better. And would you like to discuss about it later on? Of course. Thank you very much. We have time for one more quick question from the internet before we have to close. Yes. How is privacy of the social graph, the cross hashing, ensured again? I'm not sure I fully understand that. The privacy of the social graph, how do we protect that? The privacy of the social graph, the cross hashing, how is this ensured? OK. So if you take a look at the when we add a claim, the actual content of the claim that we put in our Merkle prefix trees is encrypted. And it does not leak any information about the label or the content of that claim. And because of the capability mechanism of allowing only a specific number of readers to read a specific cross has, I think that's how we achieve the privacy of the social graph. Thank you to everyone. Sadly, we ran out of time. But Marios will be here for a little while longer, so you can catch up with him over a chunk or a beer. And well, thank you again, Marios.