All right.
We are now going to get ready for the last talk of the NixOS Dev Room this year.
We have on stage Julien and Kami, who are going to talk about an attended encrypted
file system boots on NixOS, which everyone who encrypts their hard drives knows about
that program of not being able to reboot remotely.
So give them a round of applause.
Thank you very much.
So I'm Julien Malka and this is Kami Mondeau and we are both old students of Ecole Normale
Superior and we did this during our studies a few months ago.
So we are going to talk about Clevis and Tong on NixOS and I have to say and to thank NLNet
for funding this new feature in NixOS.
So the plan is we are going to motivate why it's interesting to have full disk encryption
and remote servers.
We are going to present Clevis, which is the automated encryption framework, given EAPDES
view of the Tong protocol and then talk about our implementation and show you a demo.
So full disk encryption of remote servers, of course, it looks like a good idea, like
critical data or even non-critical data should be protected by full disk encryption nowadays.
Problem is often more difficult to do it on servers because when you have full disk encryption
you need to basically input your passphrase at boot and this requires physical intervention
so it's a bit painful to reboot servers.
One solution that is often used is spawning a SH server in Itardi.
This way you can instead of having physical intervention you can just SH to your server
and input your key and unlock your root partition and continue booting.
But this still requires synchrony new intervention so if your server reboots for some reason
that it was not planned and you are not awake or doing anything else your server actually
doesn't reboot.
So that's why I think this kind of solution is interesting.
Okay, so before Julian dives in the Macalum-Rallye protocol we are going to present the Clevis
automated encryption framework.
So it's a project developed by the team Latchset which is basically just a big set of batch
scripts wrapping around Jose which is the core encryption system and it's a pluggable
framework for automated decryption.
So there's the notion of PINs which is central is a plugin that implement automated decryption
and to encrypt some data with Clevis, well you just have to do Clevis encrypt and then
you write the PIN you want to use, the config, your plain text message and then you get a
ciphered text in the format GWE.
So the first kind of PIN you can use is TPM 2.0 PIN.
So I don't know exactly how works the encryption using TPM but basically the, well Clevis first
Jose first generates a key and then this key is used to encrypt the message and then this
key is itself encrypted and using the key generated by the TPM and it will be decrypted
the same way when Clevis needs to decrypt the message.
So that's very useful if you require TPM 2.0 and not 1.2 for that to work and then the
most useful kind of PIN is the TANG PIN which was designed by the same team of developers
and so it's a server implementation providing services without the need for an X-Crow.
So basically you do Clevis encrypt TANG and you precise the URL of your TANG server and
this will encrypt your message using the protocol that Julien will describe to you later.
And then there's Shamir secret sharing which is a combination of the, it's a way to break
down a secret into multiple pieces and so there's the notion of threshold here it's
T and its value is 2 and so you basically make a combination in your configuration of
multiple PINs, the previous examples being TPM and TANG and here you see there's three
PINs, one TPM and two TANG servers and the threshold is 2 so you have to have two working
PINs in order to decrypt your secrets.
Obviously at the encryption time you need a whole three PINs to be up.
So Julien was explaining.
Thank you Kami.
I'm going to try to explain a bit how the TANG protocol works which might be, I'll try
to explain it as simple as possible but this is extra extra for you.
So basically the TANG protocol looks like the Diffielman key exchange.
The Diffielman key exchange is something used to get a shared symmetric key between
two actors on an unsecured channel and the idea is not that complicated.
The idea is that you need to imagine that we have a mathematical operation star that
is really, that is easy to compute so if I get two numbers A and B I can compute A star
B but on the other hand super difficult to reverse so if I get C which is A star B it's
very difficult to get A and B.
And the idea is that we have also J which is a public parameter and the idea is that
we have a server and the client that each generates a secret SNC and then they send
their secret star J and then they both on their sides multiply by whatever they receive
from the other side.
So at the end on both sides they get C, JS and SJC which is the same thing so they get
a shared key that they can use to encrypt their messages and talk with each other but somebody
listening here cannot do the separation of these operations so it doesn't get any information.
If the math is a little bit too abstract you can imagine this with paint.
We have J which is the common paint then you have secret paints on each side they do the
mixing of paints and they get each a color and from this color it's very difficult to
find which paints were used to do the mixing then they send both their paints and add their
secret to whatever they receive and they get a shared color which is like an analogy for
the shared key.
This is the if the Diffie-Eleman protocol used on the internet to devise a shared symmetric
key to discuss with somebody and the Tongue protocol is derived from this so there is
two sides of this.
The first side is like the provisioning so it looks like Diffie-Eleman, they both generate
the secret, the server sends J times its secret and the client sends nothing.
The client computes what should be the shared key but doesn't send its secret to the server
and so he divides the key, encodes whatever message he wants to encode with this key and
then throws the key away.
So at this point the client has an encrypted message, ciphertext but doesn't know how to
decrypt it because it throws the key away.
When he wants to decrypt it will do this.
So it will generate a new secret E and send to the server J E plus J C. The server will
take this and multiply by its secret and send it back to the client.
At this point the client does this mathematical operation so whatever received minus J S E
and this gives it another key that it used to decode the message.
And here you have the math of why this works.
So if we go Y minus J S E is X S minus J S E. X was J E plus J C so J E plus J C S
and if you compute this it gives you J E S plus J C S minus J S E which gives J C S
which is K.
So with this manipulation it can find the original key again and decrypt the message.
So what does it give us?
So let's say an attacker gain access to the client.
As I said at this point the client discarded the key only as a ciphertext cannot decrypt
so you gain access to the client cannot do anything.
Take access to the tongue server.
Tongue server doesn't receive any information at no point in this protocol so you have access
of the tongue server you cannot get the secret.
And if you intercept all messages here and here because of what I said like the Diffiel
Man assumption it is very hard to reverse these operations you also get no information.
So basically the only way for an attacker to have the secret would be to get access
of the client and the server at the same time or to be on the local network where you have
your tongue server.
That's the principle of how it works.
Let's talk about the Nixxas implementation now.
Okay thank you Julien for the theory.
Now we're going to dive in the Nixxas implementation.
You'll see that it's really simple.
So if you have your Nixxas laptop with you you can do it live.
If you don't well maybe install Nixxas.
And so first you have to deploy your tongue module.
So it was added by a Jeff Proch.
Who is here by the way?
And you can enable it with simply with services.tongue that's enabled.
Then there's only one parameter really important is the IP address is allow which is critical
because it defines the subnet that you trust because every machine on this subnet will
have access to your tongue server.
And if someone gets your secret.jw using only tongue well it can decipher it.
So you put a network that you trust.
Then you don't forget to open the firewall as I did a lot of time.
So you can change the port.
This is the default port in the Nixxas module but you can put it on port 80 if you want.
So now you have your tongue server.
Then the Clevis module it was packaged inside the init.rd already existed as a Clevis as
an Insignix packages.
So basically it works in init.rd both system dstage1 and scripted init.rd.
So what it does is before decrypting the root partition well it tries to do Clevis decrypt
with the secret.jwe which was put inside your init.rd secret.
And if it succeeds then it pipes the value to decrypt the root partition and if it fails
it falls back and interactive unlocking.
So how now how to use it?
First you have to generate the secret.
So it's really easy you just type in your secret and you pipe it.
Be careful because if you have a you will most certainly not have a return carriage inside
your secret so you have to add a dash n when you pipe to Clevis.
And then you write your Clevis configuration as we showed earlier.
Then when you have your secret you can put it in your etc.
in xy folder or in your flake and then you write this line which is booted in the Clevis
devices.
Then you put here the name of the device inside your file system dot slash root partition
configuration.
So it has to be the same name.
And then well this works only if your root partition is encrypted using one of these
three methods.
The client has also a tpm 2.0 device and what we require.
So first you type in your secret in a secret way so it goes to the secret environment variable.
Then we state the config that we wrote previously in JSON format for Clevis.
So you can see a threshold of 2 for a quick but just.
Then you can pipe your secret to Clevis and creep the secret sharing and with the configuration
that you use.
Snow in post.
So this means that the tongue servers have been reached so that's why you actually have
to choose the sign in keys.
Both tongue servers.
So now you have your secret.
You can try and decrypt it.
Your secret works.
And now you have to modify your configuration.
So first thing because we're using the tpm you have to add the canal module.
So I added both but I think you can probably just add one if you know which one.
Then you add the boot in the configuration.
So it has to map.
So it had to match the file system configuration.
Then you can rebuild.
And while we're rebuild we can turn off one of the tongue sockets.
So the tongue one server.
And yes because we defined in the threshold that just one of two is required.
Then we reboot and we see that it's not a reachable error communicating but it's still
boots very quickly.
Then it's locked out partition right.
So it works but then you turn off the second tongue server just to check that.
And then you can see that there are two errors for both tongue servers.
And so there's an error reading the passphrase.
And now you have to type in your password so if you didn't set up an open SSH server
while you're basically you have to reboot your machine from a.
Okay.
So what's left to do?
Well you can add more pins to match your needs.
So one useful one would be Yubiki.
And then if you have like an exotic encryption solution maybe you can try and use them with
Clevis for instance Veracript or I don't know whatever.
So there's many other solutions to use.
So feel free to contribute and thank you very much for your attention.
We don't have a mic so shout the question and repeat it if you have a question.
Question was in case where the tongue servers are down can you still SSH to input your password
or are you just out of luck?
And the answer is I expected to work correctly with the existing SSH server and it's already
featured so you have to configure it to do that but it's possible.
There is none apart from the fact that Clevis is just fancy wrappers around like the same
calls that the system the crypton world features are doing to the TPM.
I don't know which one was first.
So yes the question was can you put the maybe the configuration.
The question was about the configuration and so the threshold was set to two but we asked
for the TPM to be live to be available and only one of the two tongue servers so it was
very quick but there's actually a combination of pins so there's first the TPM then inside
the SSS configuration there's another SSS pin with the threshold of one so this threshold
applied to the TPM and the SSS with two tongues and the threshold of one so I guess it's okay.
Can you repeat it?
Yes how does encryption key management work with the FS as it supports only one passphrase.
The answer to this it's the same passphrase that you encode in a Clevis secret so what it does
it will first try to decrypt the Clevis secret and if the decryption succeeds then it will use
this key as the encryption for the FS otherwise it will ask you to input it like interactively.
So I guess the answer to this question is currently there is only one key phrase that is either in
your brain or encoded in a Clevis secret.
Yes.
Do you know of any possibility to have an encrypted kernel and init.org so like a bootloader we use the TPM to decrypt the kernel and init.org?
I do not know about this no I don't I mean as you described it it maybe it's possible but I do not know of any implementation of this kind of things.
I guess you need something to decrypt your kernel anyway if you're going to have encrypted kernel what is going to decrypt it?
Yes okay then systemdboot becomes the kernel I don't know.
I think that's pushing it a little bit why would you think you want your kernel to be secret it's like if you're thinking about secrets you want to put in init.org that's something different and we have so currently in XS we have an encrypted init.org secrets but there is also a new features coming into systemdboot and then learn something.
So we have an encrypted system init.org secrets encrypted via the TPM and systemdcrypt what's the name?
Credential systemd credential sorry that's maybe what's more what you want.
Yes.
Yeah I agree so the remark was it's sometimes good not to have like a kernel unencrypted because then an attacker reading your boot partition would know exactly which version of the kernel you're using and maybe target some specific vulnerabilities.
Thank you for the remark.
Okay so the remark was you can use a Kexec to load basically any other kernel that you might have decrypted from the first kernel so that you can still have some kind of encrypted kernel.
Thank you.
Yes.
Should I use the same time server for multiple hosts or set up a different host or set up a different time server for other because any host could decrypt I guess.
Well as long as your tank server is in a secure network that you control the access and you have exclusive access or that you have also set up a TPM on your servers but as long as your network is secure I'd say that the protocol implies that
Tanks servers have not access to anything except their own signing key so you can use as many that's what's cool about the Macalum real real protocol is that you can use as many clients as you want the message doesn't even leave the clients when it's encrypted and the key using for encryption also doesn't leave the client so well they have the key.
Okay so the question was if malicious host reaches your private subnet and gets access to what the client or the.
Well if they get access to the GW secret yes well then they can if they have access to the tank server and the GW then they can decrypt so that's why you have to either well put your tank server on something that you control very much or well encrypt your GW token when you put it on your flake or whatever it should not be clear.
Okay so the question was what happens if your tank server is down is down during the reboot of the server.
Well as you saw well depending on your configuration if you have a lower threshold well it would print an error communicating with the tank server first but then it could depending on your configuration still boot or not if you only have set up one tank server it won't boot and then fall back to interactive unlocking.
And if I may add something you may like configure a system so that it after like it times out trying to unlock your your repartition after some while and reboots and then start again and if it was a transient failure of tank server then you might be saved by that.
We can do one short question.
So there we have some documentation on the next menu. This is sorry this is a merge and available in the next and stable right now it's not in 23.11 and you have you have some documentation in the unstable manual.
Thank you.
So.
Thank you.