 For the afternoon, thanks for attending. In this session, we are going to take a look into network about disk encryption and highlight some of the usability improvements that we made to make the task of keys rotation simpler. So let's get started. So this is a brief agenda. I'm going to give you a brief overview of the projects taking cleverness. And then we are going to the key rotation procedure. We are going to see a short demo on this. So eventually, people start encrypting disks for getting more secured. But basically, it has a trade-off that it requires you to type the password manually upon boot so that you can unlock the data and the boot procedure continues. Like in here, we see a typical boot screen. Like we have an unencrypted disk. Requesting us to type the password. So we can simply type it. And it's OK. Or we can use what we call network bound disk encryption and VDE for short, the acronym. Basically, it's going to allow us to unlock a disk without need to manually type the password. And now we are going to see how exactly this works. So we have a server-side counterpart, like a demo. It is a summit to run in a controlled environment, for instance, a data center or a corporate network. And we have a specific protocol that's going to dictate how the data is going to be transferred between the client and the server. Essentially, it's some software JSON over ATP. And we use this key exchange, Macallan-Railia, which are two hand headers. I believe the second person is here. I saw him yesterday, I guess. So it's based on Diffie-Hellman and IES. This secret does not leave the client. So that's useful for what we want to do here. On the client side, we have Clevis. This is going to be a response for the automatic decryption. The configuration for it is also using JSON. And we support for now three different plugins that we call PINs. Like we have a PIN called TENG. In this case, you can bind the disk to a specific TENG servers or a set of servers. We have a TPM2 PIN that can use the first platform module that may be available. And we have a third PIN called SSS, which is Chamber Secret Sharing. So for the TENG PIN, this one allows us to bind a disk to a TENG server. And that's where the name network bound comes from. So we are going to have some sort of secret tied to a specific server. Like the SSH protocol, it's also trust on first use. So we are going to see the key of the server and we decide or not if we should accept it or not. It also supports offline enrollment, which means that we can previously download the advertisement from the server, like the keys it provides. And so we can do the encryption itself offline without need to access it. And here we can see an example of how we can use it. Like, basically, we have a command clavis lux bind, minus they will specify the device that we're interested in binding. Then we use the specific PIN that we want to use, in this case, TENG. And here is the JSON configuration. We have a URL and basically the server itself. Like, let's try to see it in this VM. This VM basically has both clavis and TENG. Install it locally. Let me see if it's working. TENG is going to list on the part number 80, so I can check if we have a OK. It gives me the advertisement, which is this payload. And I have VDI3 device, which is encrypted. I'm going to use this to bind to the server just to see if it works. So I use a command like that one. Clavis lux bind, minus they, by the way, is the font size OK or? OK, thank you. And then I specify the plugin, TENG, and the configuration. Basically, the URL. In this case, it's local, so localhost. So here, I see the key from the server, and I can't trace it or not. Let me trace it. And at this point, I'm prompted to type the execution looks password for this device. What we are doing here is basically creating. Probably made a mistake here. Let's try it again. It's going to create a new password, and add to another look slot in this device. So we should have now two, like one that already existed when the device was created, and one that was added just now. However, we added it encrypted. And we are going to need this TENG server to do the decryption for us, at which point you can actually do the decryption of the device, the unlocking of the device. So just to verify that we actually have the two keys slots. Yes, so we have keys slot 0 and 1. We keep checking. You'll see that we actually have a token tied to keys slot 1. That was Clevis just did. So this is the Clevis PIN. The SSS PIN, it implements this, our Charmise secret sharing. Basically, it allows us to divide a secret in parts, different parts. And we can also determine the number of parts, the minimum number of parts we need to recover the secret. This also allows us, in this case, to mix PINs together. And basically, you can create sophisticated unlocking policies. Here's a simple example of how we can code use this. Like they use the same Clevis, looks, bind, the device, the PIN SSS. We define the threshold as 1, which basically means that we need only one of these to succeed. You see, I'm now using two tank servers. So one of these could be down. We could still unlock the disk. So it can be used for high availability. Like this is the primary use case in this example. We also have a TPM2 PIN. Basically, it's going to use a trusted platform module that implements the V2 specification 2.0. As of now, we support the state key PCR policies. So basically, you can see the data based on the value of the PCRs. And here is also an example. Similar everything, the plug-in disk case TPM2. And here, we are tied to the specific PCR ID. And now, we go to the key rotation mechanism. We are mostly interested in Tang, because Tang is the network part. So network bound disk encryption. Let's focus on Tang. Tang uses two keys on the server, like we have on signing key and one encryption key. And there is also, like in security, like in passwords, we are supposed to rotate them periodically. So eventually, we should go to the server and do the key rotation, which essentially is let's generate new keys, new pair of keys, which we can do by using one script that is provided with Tang. And we also should tell the system that the current keys should not be advertised anymore. So OK, now we have new keys. The other ones, let's not advertise them. So in practice, let's see how it works. In this directory, vrdb-tang, we have the actual keys Tang is using. So here are the two keys. And I'm going to create a new pair of keys to rotate this. I can use that binary Tangd keygen and specify a new directory. So at this point, I have four. So I'm going to now move the other ones. Basically, I'm going to rename them and prefix with a dot. And from that point on, Tang will not advertise them anymore. They still exist if you have clients using them like that device that I've bounded. They still work because they still are there. So let me rename these two. So at this point, I have two keys and two keys that are now rotated. From the server side, that's it. It's very simple. However, now comes the issue in the clients. Like I mentioned, since the keys still exist, I can still unlock the device using them, which I can test, for instance, Clevis Lux Unlock. I pass the device. And I can specify a name for the device on set opens. So when we do this, it's going to contact Tang, do the key exchange, and unlock the device. You can see the device is now open. So everything worked as expected. So from the client side, everything is working as expected. The client doesn't know that the key was actually rotated because it still exists. Let's go back to the presentation. On the client side, as I said, it's hard to verify that the keys were rotated because basically everything worked the same. So how can we actually check if the keys were rotated or not? It's possible to do. Basically, you have to manually load the metadata from the Lux slot, the crypt, go through every single device, every single hook, and actually compare what are the keys that are marketed in there. You can also go to the Tang server and see what keys it's advertising. So it's possible to do, not impossible, but not trivial, and very highly error-prone. And actually, it's hard to even know what kind of configurations we are using. Assistant administrator managers, hundreds of devices, probably they have hundreds of Tang servers or TPM configurations. So we go to here, OK, I have here what kind of configuration I'm using here. Obviously, it should be documented, but there should be an easier way for us to get this kind of information. So now we have some usability issues that we are trying now to resolve or improve the situation. Because on the client side, we need to do some things like rotate the keys, but we don't even know if they were rotated. Actually, we don't even know what kind of configuration we are using. And now we have a few new subcomments, like this Clavis Lux list that's going to display basically the configuration that's being used in my particular device. The user is simple, like it would basically I pass the device, and here's how it works. Clavis Lux list minus the devvvvvvvv3. So now I see that in key slot number one, I'm using Tang as the plugin, and here's the configuration that is being used. And the configuration I see here, it's actually ready to be used in Clavis itself. I can Clavis Lux bind minus the, and use this configuration as it's in here. So now we have a simple way to at least know what Tang servers are bound to, or in case of TPM, or PCR IDs we are using. So it's now simple to do that. And we also are providing two new subcomments to help you with the key rotation. We share the Clavis Lux report. It uses a similar however we need to specify this slot. So it's going to tell us whether the keys that we are using this device were rotated or not. So I can use it. Clavis Lux report, specify the device, and this lot. And now it's telling me, oh, this particular key that we have in our metadata is not being advertised by the server. So it was probably rotated. The same one with the second key. Onset shows this to us. It actually asks whether we want to regenerate the binding, like to update the keys. Like, you want to actually rotate them? Yes? So it's going to use the existing configuration. And at this point, I can again provide the, an existing Lux password. And it's going to basically do a rebind. Like, okay, let's rebind now using the current keys that we have. Case were successfully rotated. So if I, for instance, run the command again, not put because, okay, the keys we are using are now correct. So this is basically to help with the key rotation on the client side. The server side was never a problem. It's a very simple operation, but on the client, it was complicated. So the third common that we are adding is the Clebs Lux Regen. This one is going to do the rebinding. And then in our example that we did right now, it was actually used from the report. It offered to run it, and we accepted it and run it. So this, now we are going to show a demo, which is basically what I just showed it. In this case, this demo, as I say, there's a single VM. It has both Clebs and Tang. Since I'm not demonstrating an actual unlock, like I'm not rebooting the VM, so this is perfect for our experiments. And the key rotation, both the server and client side. So here you have some useful links, like the projects are open source, so everyone is welcome and encouraged to contribute. So get involved. Here's Tang and Clebs. And here are two useful talks and slides from both Nataniel McCallum from a couple of years ago, Securing Automate Decryption. Basically, in here it introduced Tang and Clebs and all the mathematical details of that. And there is a second talk. This one is more recent, I believe, from last week. Clebs and Tang, Securing Our Secrets at Rest. So here is the actual talk, the video. It was a very interesting talk. And basically, that was it. So please go ahead. Key rotation. Otherwise it wasn't still. Yes, no. We can make the question into the mic. Okay, so the question was if we can basically automate this. Yes, we can. Let me check it. Let me look at the report. So basically, you can specify both are quiet modes so it doesn't really prompt anything. And there is also minus there, like you are already answering the question if it should regenerate. So you can script this and even pass. Let's see. Yeah, you can automate this, basically. I mean, it was told of that as a possibility and we can do it. I don't remember all the details but it's possible to do it. Yes. So firstly, how are you protecting the key material in transit? Because you're using HTTP here, not HTTPS. So when that information is coming from the server, how are you ensuring that the key can't be accepted? Can you repeat the question? Yes, he's asking if how we can protect the key. Okay, and actually that's an area that I'm not an expert. So basically, this key exchange does that for you. Like it protects that for you. That first talk that I mentioned is gonna answer your question. Yes. I mean, TLS is not even necessary. Yeah. The private key is never actually exchanged. The secret never... It's just token locally, that's the story. The token uses the public key from the tank server. Yeah. And secondarily, the implication for what you were showing, and again, it might not actually be how it works, is that you don't have a unique key per device. I mean, while you were showing all the VM implied, maybe I'm wrong here and that's not how it actually works. What do you mean by not having a unique key per device? Usually, every server is gonna have unique keys. I mean, that's the recommended way for deploying. Okay, so every device or every server? Every client generates unique keys. Sorry, it's okay. That exchange is happening on the board. No, every time you bind a device on the client's side, a new key is gonna be generated with the same entropy of the master key. So we are gonna encrypt that key using the exchange and we're gonna store that encrypted. So when we do the exchange to retrieve the key for the encryption, then we unlock it. But every fast phrase added is unique. And also from the server side, every key of par key is also unique. My grade to hell, eight. Since you probably have, the question was, how can we migrate a tank server running on hell seven to hell eight? Basically not much change in terms of seven is off configuration. So I suppose if you have clients using the keys that you have, you are gonna migrate those. Like you're gonna do an installation on hell eight and get the keys that you have available in the VORDB tank. Those are the keys. So just copy the keys, start the tank server. It should advertise this. Your clients, you talk to them and it will work. Yes. Yes, ideally we're gonna use like a configuration like this SSS example. Like with at least two or three or four servers for high availability. But in terms of configuration, just copy your keys to the new server and you are okay. Sorry, could you repeat the question? No, you mean two separate. If you understood the question, he's asking if in case of high availability we have two separate databases. Actually, there are two different machines. If you are following the recommendations, each of them have unique part of keys. They are not the same. So when you are gonna do the binding, it's actually gonna ask you to trust the keys from all the server listed. So you are gonna trust twice in this case. Like the keys from the first server and the keys from the second server. Remember the servers? Like in DNS, would you still be able to resolve all the servers behind the DNS and so on? What matters in these cases is the threshold one. Like if you can arrange one of them, you can decrypt the data. Like in terms of load ballancy, it's not, if you understood correctly, it's gonna resolve maybe a different server every time, is that? Or several. Or several? Yeah, in this case, you have to make sure at least the keys are the same. If you have to first bind two of them, like this, like a list of them, and then when you are resolving, you are basically one of them, randomly. If those keys are the ones that it was binding to, bound to, it's gonna work. So it's possible to do it, but you probably would have to list individually, like the 10 of them. You have 10, you list 10. When you are resolving, you probably resolve. Right, but look, decouple the configuration in the clients from the number of time-serves to half to just the major they grow, maybe they don't need to be committed to making sure that your secret status and the same server is the same all the time. Yeah. What? I mean to see who's first binding that from the client. Yes, that's one possibility. Like copy the keys. It's not really recommended, but you can eventually, like if you are adding or reducing the number, you can rebind it. Like probably it's simple, but that can be automated. For the customer before, he's deployed very similar technology and their server side key storage was kept around somewhere. So if you do consider deploying this, make sure you have offline backups of that server side done at least every few hours. Yeah, that meant they threw 2,000 laptops in the bin. Yeah. Because it was quicker and cheaper for them to do that and just tell their staff to go and buy any laptop. Anyone else who's trying to fix it or what? In this, do you usually want to leave like the password of your slot servers or backup for something similar? Yeah. And then you just, who cares about the tank servers? You add anyone. The fact that key servers are kept around somewhere probably shows you the confidence of that organization. You're probably storing the actual secrets, too. Yes. It's impossible to confine the chance you could share them with VPN and the client. Exactly, yes. I see both of them. Basically, we could continue the JSON configuration, put a comma here, put the name of the order. You could even use SSS recursively. Like in a first step, you want to validate the TPM. In a second step, you want to validate a set of tank servers. So it's possible. And I'm afraid we're out of time now. So thank you, everyone. Thank you.