 All right. Thank you. Can everybody this is working? Okay, great Well, thank you very much for real-world crypto. This is one of my favorite events. I think my favorite event actually the year This is it's an honor for me to be back and I want to talk today about a project That's been brewing at Cloudflare for a few years now and and was released last year in 2017 It's a project that uses some interesting cryptography and it was Mostly done by Brendan MacMillian who didn't want to come up here. So I'm doing the presentation so the basic problem is Geographically distributed key management So what does that mean? Well first let's let me explain a little bit what Cloudflare is It's not a vendor pitch or anything just an explanation. Trust me. This helps that thing. I'll set things up So Cloudflare sits in front of websites and web services It blocks attacks it caches content there's something like seven million domains that use Cloudflare and Cloudflare situated all around the world. There's this is an old map, but there's a hundred and twenty nine locations or so and in order to do what Cloudflare needs to do in terms of caching and blocking content it It needs to terminate TLS. So if you are anywhere in the world, you can connect to a website it'll go to the closest Cloudflare node and you do your handshake and then It continues back to the website. So in order to To do that you need a TLS You need a private key and that means the private key has to be everywhere everywhere in the world and Not everyone is comfortable with the keys being everywhere and it's not just Russia I'm not gonna pick on them, but every every needs every need of every customers is different and I Mean just to be clear Cloudflare does not give out private keys to anybody really But that doesn't mean that customers are necessarily really comfortable with the private keys the keys to the kingdom for their websites being Anywhere in the world So there are a lot of other reasons you might want to limit where your keys are are going But you still want the benefit of a global CDN all around the world. So there's privacy regulations physical security general paranoia there are all these sort of things so What what do we really want to do to help these customers? Feel more safe. Well, first we want them to be able to choose where in the world their keys are kept and If we do this we want it to actually be something that we can deploy and something we can manage and something that actually fits into Cloudflare's Ecosystem something that works for now and works for the future. So that means fitting it into This engine we're not we're not gonna rewrite the way that data distribution in the network works at Cloudflare But let's look at the components that we have of the engine of Cloudflare to see what we have at our disposal for limiting access to keys and you can kind of think of this in terms of constraints and components one of the constraints is Legacy client software. We're not gonna change TLS. We're not gonna ship a browser We're not gonna change the way that people use the internet. It has to when you connect to Cloudflare It's regular HTTPS so In order to have keys in a different location and still terminate TLS. There's something called keyless SSL, which This map is not showing up at all, but imagine that somewhere in Europe So you need a private key to actually Continue to make a comp make a TLS connection. So you connect to Whatever the nearest connection is and there's only one part of the TLS handshake that actually needs a private key and you can actually put that somewhere else in this case in another country and During the handshake you do your your round trips in the handshake and then the call out to where the key is to do the Private key operation. So this is this is keyless SSL. It has a pretty severe latency cost Because network is pretty high latency. So Depending on where it is in the world This can add quite a bit of the connect quite a bit of time to your connection This is a single round trip, but you know, it's a viable cost. It's Cryptographically though colossal you saw how much it took for post quantum crypto algorithms earlier today What are the tools we have or what other components of the system? One is a provisioning system This is how cloudflare Configures the system configures all these machines that handle requests. There's a central provisioning system a template of the configuration that basically just takes whatever the name of the system is and Applies it to a template and you know shoots it out to where the where the system is and where this edge machine is There's no there's no real way to do a key registry These the number of machines changes a lot data centers are added every week Different machines are added to different data centers things are taken out. This is kind of a push-based provisioning system This is non interactive and it's really identity-based the only thing that you use in the configuration for templating is the name What else we have well, there's a globally synchronized database and this is how when you change your settings or Upload new keys to cloudflare. This is how it actually gets out to everywhere. There's this this kind of waterfall of Database replication that goes from a central place to regional masters to local masters to whatever this is This is very automated. It's it's anything that you do that. It's very interactive it changes but it is bandwidth limited and You can kind of think of it as a as a broadcast mechanism So stepping back and saying okay, what what do we have at cloudflare? We want to build some sort of way to limit access to keys. We're not rebuilding the engine But we have this kind of identity based Provisioning system this broadcast database of keys and this high latency fallback. How do we solve this? with cryptography Well looking back into the world Symmetric cryptography. This has been around since antiquity one-way functions We can kind of evolve to asymmetric cryptography things from the 70s and whatnot And you know 21st century cryptography pairing base crypto. There's there's a lot of tools in your tools toolkit You can go all the way to fully homomorphic. Yeah, we're not gonna go that far. That's that's a that's a bridge too far so what one of the interesting tools in this set of Options cryptographically is is identity based encryption which has three Main pieces where you have a public key This is a piece of information you can use to encrypt data to a given identity and the identity is just a string There's a master key. This is used to provision private keys to Identities and then the private key itself Great thing about this is it allows encryption to identities Even if they don't have their key yet, they haven't been registered in the system. It's it's a sort of preset and Kind of visually you can think of identity based encryption In this sort of way you have a master key. You have an extract phase You have private keys you send them to the participants. This may be a familiar diagram and For identity based encryption for decryption Or for taking content and and encrypting it you have your public key You encrypt it to a name and then you have this cipher text You can send it to anybody you want but only the person with The private key associated with that name can decrypt it So identity based encryption was proposed by Shamir in the 80s But it really wasn't realized as a fully functional thing until Bonnet and Franklin in 2001 and uses a mathematical Tool called bilinear pairings So I I can go deep into this if we want to and and I think we do it's real-world crypto Let's at least cover what we need to to understand this so Typically it's two groups to additive groups and you have a function that goes from these two groups to Another group typically a multiplicative group and it has this nice property if you can find a pairing That's easy to execute has this property where it's linear in both inputs Which has some interesting properties? particularly it allows you to solve Diffie-Hulman in either of the two pre-image groups from solving it in the in the destination group so for one example of this is is super singular curves if you have Super singular curve you can create this pairing that that sends the group elements of these curves to a finite field so you typically you have elliptic curve group or a subgroup of elliptic curve going to a finite field and this leads led to things like the MOV attack and and if you have an efficient pairing you can do identity-based encryption and the first one of which was By Bonnet and Franklin this is from the they pairing so identity-based encryption as as a tool can be generalized and If you have pairings you have efficient pairings that you can use There's the idea of identity-based broadcast encryption, which is a very simple generalization This is proposed by Delara Blay This is kind of a reformulation of this concept of multi receiver ID base key encapsulation by Nigel smart and other other folks, but generally it lets you encrypt to a set of identities up to a Maximum size and we call that parameter k and if you set k equals 1 that is identity-based encryption So it's kind of a broader generalization of that you can encrypt to a set of people up to k or set of set of identities On the converse of that there's a concept called identity-based revocation and with that you can encrypt data to every identity minus a Certain selected subset up and up to k and this is also very very similar to identity-based encryption or a concept of broadcast encryption where you can revoke particular people from a Cypher text that has been kind of sent out so Two pretty good examples of identity-based broadcast encryption and identity-based revocation Are from these two papers they were Delara Blay and another is another construction from a Bunch of other folks at Trapeze and Lieber to pan a few. Yeah, exactly There's a there's a bunch of folks who who worked on this and made different formulations based on pairings to do IBBE and IVR and things like this, but the interesting part of this construction is that The Cypher text size is actually constant so up into it as long as You have set k in advance and set your parameters. You can encrypt to any number of identities Whether they've registered in the system or not doesn't matter in the same way as identity-based encryption the Cypher text size is going to be constant for both of these constructions and The second one was built in Was demonstrated as part of a build up to a more complex attribute based encryption scheme so these these use pairings and What sort of pairing should we use? Well? Common group common type of pairing that you can use is based on what are called a bread o'nary curves and this is a specifically chosen curve and in pairings there's g1 and g2 and they map to gt in this case you have a specifically chosen elliptic curve over a finite field a prime finite field and this the second group is you can take an Sort of a 12th extension the elliptic curve over the 12th extension field of finite fields one of the cool optimizations is they you can map that down to a curve over fp2 which is a lot smaller more compact you can do some operations a lot quickly and send it over fp12 so using the the optimal eight pairing you can have how it use these these curves and And you have a nice pairing you can construct both of these constructions using this and In particular one of the curves that is commonly used is is called bn 256 and it says here 128 bit security level There's a little star there. I'll I'll talk about that in a second, but generally even if you you don't need you don't really need to know all the details about this but But the first group is essentially 32 bytes 64 bytes 192 bytes you have a function that goes from the first two to the end and recently there's been some advancements in the number field sieve algorithm for solving Diffie-Hulman in Fp12 and as I mentioned earlier if you can solve Diffie-Hulman in the destination group It lets you solve Diffie-Hulman in the source group So this lowered the security somewhat to somewhere in the 90-bit range, but generally Bn 256 is is is rather solid. It's well known And there's a go implementation Cloudflare uses quite a bit of go by Adam Langley Brendan McMillian on our team did some assembly a speed up for this specific implementation to get a 10x speed up but the important thing to know is computing one of these pairings is is Slow cryptographically if you're comparing it to classic crypto algorithms But compared to network times, it's actually pretty comparable thinking of you know a round trip between two places within within Switzerland it's it's rather comparable so Stepping back a second we have this idea of identity-based broadcast encryption identity-based verification We have this nice curve setting that's Been been used for several years We can combine those together and build a sort of practical IBBE and IVR scheme and The key this parameters look like this. They the public key and the private key They scale linearly with the size of the set that you're using but the ciphertext itself is rather Small 192 2 bytes and this is constant So it doesn't matter how many elements you put up to K into who you're the destination is you can You can still use these constant size ciphertext. So How does this apply to key management? It feels like we've gone on a tangent, but we really haven't we've really been describing several constructions that map pretty well with the way that the architecture of cloud flare systems are designed so Um Considering that you have this IBR and IBBE schemes This is how theorized simplified version of geo key manager could work. So every location in the world it or every physical location of 129 locations of cloud flare would be provisioned a private key so the associated with its name and Then a customer could say hey, I want my TLS key only in Zurich in New York or you can say I want it everywhere except the United States for example and then we would encrypt the TLS key to the name of these locations using one of these two schemes and Send it out through our distribution mechanism and then when a connection comes in we would either Use the local identity based key to decrypted and you know finish the TLS handshake And you can cash that and use it for subsequent requests Or you would use keyless SSL to connect to whatever the nearest location that actually has access to this key So this is this kind of makes sense. This is this is something that that'd be nice to use It's maybe not as flexible as we'd like it to be Because the network is growing you have 129 data centers now We want this system to work when there's a thousand data centers and we don't want any sort of manual intervention So one kind of wrinkle that you can put in here that these these kind of semantics that you'd want would be You could somebody can choose to put their keys in multiple locations and also have a kind of default for New locations that are added for different regions and you also might want to blacklist specific locations So if you know you want everything in the United States, but you don't like Kansas City You can do something like that So because the networks is growing you we want something really flexible And this is where key encapsulation comes in this is where Geo key managers the real new parts of it are is that you can combine these three Or I guess you can combine the an IBBE scheme and an IBR scheme with just some simple key splitting So you have a key encryption key say you're somebody uploads a TLS private key you encrypt it encrypted with this key encryption key and you can split this into two and one for the region that you're white listing for and one for the region that you're blacklisting and And you basically have an overlay so you need to have to be both be in the region that you're allowed and not be in the specific location that's blacklisted and To get a white listed location that's out of a region that you're default off for You can just simply take the key the key encryption key and just Identity-based broadcast encryption to these extra white listed locations and and combining these three you actually get the desired semantics that you need Fitting this into the real system that we use you have a provisioning server This is this is the setup phase and you have the master keys for both the IBBR and I be oh, sorry IBBE and IBR scheme and When you provision each of these new machines you extract the private keys and and send them down and when someone uploads their private TLS key you can then wrap it with these various key encapsulation mechanisms and Send that down the pipeline and this will replicate all through the system and none of these intermediate nodes will be able to Decrypt this data Along the way and even the master database will not be able to decrypt this data and visually you can kind of imagine it like this you have half the key in and your white listed regions are the u.s In EU and you don't want these two specific cities. I can see there Yeah, Dallas in London for some reason, but you do want your keys in Sydney and Tokyo, so combine these together and You can't see the background, but so if anyone were to visit any of these gray pops group gray locations that are outside of these regions You would connect to there and you would do keyless SSL to whatever the closest Network node is so we have this this network where pair-wise we have a long-lived connection between every single location and You look at the key see where it's available and go to that place If you're actually in a location that has access to that key you just use the key encapsulation mechanism decrypt it and go there so Because there's pairings involved People typically say you can't deploy pairings. They're too slow. They're not really That useful, but when you compare the time as I mentioned to Network latency it actually isn't that big of a deal if you're worried this much about where your keys are this this hit Is is something that you can Occasionally take so this is beta this beta for this is live. There are over 50 customers that are using this something like a hundred to two hundred requests per second are being used through this new keyless SSL distributed key mechanism and we have cryptographic enforcement and Compatibility so We've deployed this sort of thing but what I described earlier was a slight simplification When you're building a hybrid crypto system You think you have the outer layer and you have the inner layer and in the system that I described the outer layer here is this Brilliant kind of identity-based system and you're wrapping this basic symmetric key inside of it So the thought was you know we're doing a lot of these pairing operations at least one per private key per location and Probably per machine in each location can we do better is there a way to do a better type of encapsulation and One way to do that is to have a three layer hybrid scheme So you have your identity base scheme and then inside of it You wrap a public key base scheme and the inside of that you wrap your symmetric scheme so The details here I Can kind of walk through this but essentially When you have a certain configuration that says you know These are the ten locations that are white listed or these are the ten locations that are black listed you create these sets of key encapsulation mechanisms in what I described before this is you know a Symmetric key that's like a yes or something like this that split three ways in this case what you're encapsulating is a Diffie-Hellman private exponent, so the interesting thing about this is once you've computed for first given configuration the this set of configuration These set of key encapsulations you only have to have the public values. So For each configuration you you generate three Diffie-Hellman shares and three definite Diffie-Hellman public keys a a times p b times p and c times p and then When you actually need to wrap the key itself Rather than wrapping it with the key encryption key. That's just arbitrarily generated you Essentially do a key exchange with your configuration So every time that you have a new key you generate your key encryption key this way so You can wrap it with the private key and you have this kind of Diffie-Hellman type of situation in that You in this case, it's a plus p you're kind of rather than key splitting by taking a symmetric key and X soaring it You're using exponents in the Diffie-Hellman case And for your whitelisted region the one that is not actually Key split you do this key escrow business where rather than doing a key exchange You you you do a key exchange and then you just encrypt the key key encryption key so The nice thing about this is that once it's actually distributed You only have to do a pairing for once for every configuration So if it's very common that people say I want my keys everywhere except for Moscow Then you know that really you only have to do a pairing once for any particular key that uses this even though They're they're wrapped differently so Given this and given this this mechanism right here You have a very configurable way to Distribute keys using this broadcast mechanism and it's been working for us and it's been live in production for a little while and That's it here are some references. Thank you very much We have lots of time for questions Thanks Nick so one of the Features you generally want out of a broadcast encryption scheme is that two people that can't on their own get the secret can't work together to get the secret and It seems to me you lose that when you do your splitting between the share one and share two So in your example for example If you have the man that the second one or the original one the map Yeah, that this one. Yeah, right. So if London so London will get share one, but not share two and Moscow can read share two, but not share one and So London and Moscow working together Could get the key now it may not matter in your system because you don't treat your Your right. I think the presence as adversarial, right if there's a compromise in both London and Moscow I think that's that's kind of worse. Oh, yeah, yeah Okay, yeah, it doesn't really fit into this model because each each location is is not considered adversarial as you said It's it's a an independent location. I Have a question actually speaking of adversarial points of presence So Microsoft has been fighting this case about a search warrant from the US in a data center in Ireland and I guess it's going to the Supreme Court and I was wondering if you had any thoughts about the interaction between this kind of system and and what the United States government is doing Yeah, so so one of the one of the reasons I guess this I don't know how well this has been borne out in court, but One of the reasons that this is built the way it is is so that it's actually cryptographically impossible to Access a key in one of these locations that it's chosen not to talk to be in this is it's cryptographically enforced so For a court of law to say this key is in my country. You can make a pretty strong argument that it actually isn't it's actually something that is Indiciferable that's that's actually in in the country. So despite the fact that you're broadcasting the same information everywhere Because the keys to decrypt that information is are not everywhere It's it's a lot stronger than having say like an access control mechanism like a look like a white list or a black list and say Like can you access this yes or no? I don't know how well that type of argument would hold up in legal scenarios, but At the very least It's it's cryptographically sound Hope that hope that helps Protect the master key and in which country that is held. Yeah, so the master key is There's actually a pretty big difference between the This part right here where someone uploads their keys and it gets put into this database This can is it's sort of we have to lock that down It's ephemeral versus like the master secret which lets you encrypt things for the rest of the world in this case Actually, you don't actually have to have live decryption data, but Then there's this piece where the master keys right now. They're in a location. That's a lot more locked down than the rest of cloudflare's network, so Essentially you have different levels of access to different machines and different administrative domains and this is in the most lockdown administrative domain that we have Are there any questions from the invisible microphone upstairs looks like no, okay? So if there are no more questions, let's thank Nick again