Okay, so today I'm not going to talk about image based or anything, but I'm going to
talk about the containers.
So what do you mean by containers?
So again, maybe for the remote audience, when you got a boot chain, you put up your computer,
you have UEFI, it goes to bootloader, it goes to the kernel, it goes to initramfs.
And then because we're talking about a lot today, security things, you want to crypt
your disk partition and so enter a passphrase to unlock it.
Then if you want to make sure that what you've loaded is what you expect, you can store measurements,
so signatures, hashes of every step inside the TPM.
A TPM is a passive component.
It is just there to store information, perform some cryptographic computation on it if you
ask it, but it doesn't block anything in the boot chain, right?
It is just there to store and execute comments that you pass to it.
And so later on, after the boot is done, you can go back, for instance, in init in your
kernel to read back what you had in the TPM and check that what you have is what you expect.
The problem is, is there is an issue?
If it's not what you expect, you end up here, you enter your passphrase, but your system
was already compromised into the passphrase that you've just entered, maybe got excreted
and now your disk is compromised as well.
That's typically the case when you have offline attacks on a laptop, you may have forgotten
or left unattended in a FOSDEM conference room.
So what we can do and what people in large organizations typically do is use remote attestation.
So you have an app started, for instance, in the initrmfs, which will talk to the TPM,
get the measurements, and then ask a remote attestation server somewhere trusted to check
that the measurements are what's expected.
And that's where what you got in the previous talk, that you want to have images that are
reproducible, that are signed, comes very key, because a remote attestation server would
typically be your organization server, it knows about the signatures, so you can check
that the image is the one that it signed, that it is the one that is blessed by your
security team.
And then everything is fine, typically the remote attestation server would hand back
a secret to your dedicated attestation client, and the client could use that secret to decrypt
your disk.
And in that case, you don't even need to enter a passphrase anymore.
I mean, you could also add a passphrase if you want to be more sure, but if you had some
kind of control on the attestation server, then you may not even need the passphrase.
The issue is that everybody in this room, maybe some of you work at big companies, but
not everybody obviously, and so how do you set up this server?
You need to rent something in the cloud, it's super inconvenient.
As a matter of fact, all of you, I think, have a server in their pocket, it's called
a mobile phone, and so you just need to run the remote attestation server, that's a security
part because I work for a government agency, and so you have the server run on your phone,
and then you can communicate with your laptop over Bluetooth.
And that's what we implemented, a user-friendly, lightweight TPM remote attestation running
over Bluetooth with a server, well, client, it depends, we will change names, but one
of them running on your phone and the other on your laptop.
It's an idea that was proselytized by Matthew Garrett a couple of years ago at Linux kind
of Australia, but it was just a rough prototype and basically you're trying to make it production
grade, at least hacker grade.
So we have the server running on the laptop, you can know I'm switching names between clients
and server because we can't decide.
So on your laptop, you have the server, it's written in Go, it talks to Bluetooth stack,
and then we have clients for Android and iOS written, well, for the TPM part in Go, and
then for the UI in Kotlin or Swift.
So the way it works is when you start the server on the laptop, it shows a QR code with
some key so that we can encrypt the communication between the laptop and the phone and pair
them in a secure way, you scan the QR code on your phone, it gives you the key, and then
on first use, you have a trust on first use step where you need to kind of trust the measurements
the very first time.
We do not support right now downloading trusted measurements from an external server the way
you would do if you're in a larger organization.
Remember this is for individual users, but we could extend it to support that use case
if needed.
And then every time you want to test and that things haven't changed, then you just run
the server here again on the laptop, you don't need to scan a QR code anymore, you just start
the attestation on the client, it pairs over Bluetooth systematically using the key that
is remembered, it exchanged graphically the results of the measurements.
Thanks to the TPM remote attestation protocol, it can check that it is the same physical
machine or at least the same physical TPM if you left your laptop and attend in the first
dem room unless like the attacker put it open, swap TPM stuff like that, it doesn't have
it.
So it can really make sure it is the same hardware it is talking to or at least the same
TPM, and then it checks that the measurements of the blockchain haven't changed since last
time.
And it can send back a secret optionally to the laptop if you want to use it for disconfusion.
Of course, it doesn't send a secret back if things have failed.
So we have a demo and because we know how demo works, it's a recorded video.
I mean I can also try the demo for real afterwards.
So this is running in a virtual machine created with May Cozy that was mentioned in previous
talks.
So here I'll first show the enrolment.
So the virtual machine is booting for the first time.
So on the left you have the virtual machine, on the right you have the phone.
In that case, the iOS client because it is much more beautiful because my intern spent
a lot more time working on it.
But I don't have Xcode, so the client I reviewed is the Android one and so the one you get
on GitHub has fewer features, I'm sorry, but eventually it will merge everything back.
So here's the first time we boot.
We need to enter a passphrase because we haven't enrolled yet.
And then, sorry, it's the bottom of the screen, but we run the old server to perform the initial
trust and first use enrolment that we are fully booted to a Linux system.
So here you have to trust your system.
It's the first time you boot if it's already compromised your host.
It's going to display the QR code that we are going to scan with the phone.
And then it starts at station showing the steps on both sides, get the measurements,
and now we have the device registered on the right.
So we can change its name, we know when we created it, when we last run an attestation.
And as you'll see, you can edit the security policy.
So the way it works when you boot is you choose what kind of measurements you want to check.
Again, this is only in the iOS application, but coming soon on Android.
Then the next step is to run system decrypt enrol so that because when we enroll the phone,
we send back a secret to the laptop which was stored in the TPM in a special register,
register 9, PCR 9.
And so here we run system decrypt enrol so that we add another factor, another slot
to unlock the disk based not on the passphrase, but on the contents on TPM register 9.
So here basically, yeah, that's what we did.
And now we regenerate the Initram FS using Dracot, Dracot modules.
We would like to get rid of them because they're very buggy, but maybe see preview stock one
day we can, so that we can enable ultra blue and start up.
And here we start again, but now start up stops at some point, starting the ultra blue
server.
And we go on the phone and just press this button, the play button.
Starting an attestation, fetching the measurements, it works.
So we send back the secret and we don't need to enter a passphrase anymore because we send
back the secret so it unlocked the disk based on the secret.
Now what happens if something has changed in the boot?
So again, we start an attestation, yada, yada.
And here we do not send back the secret.
We say, oh, something is different this time.
It's in PCR8, right?
It has changed.
And PCR8, we provide some info to the user, is expected to contain the hash of the kernel
command line.
Then you can even look at the diff, and if you look at the diff you can see that you
have a new command line option, super-heavillopt, that has been added, right?
So this data, you can actually trust it, but you can trust that this data, it's digest,
is the same as the one stored in the TPM.
And then you can choose what you want to do.
You can say, OK, this is a legitimate update, for instance, I updated my firmware, it's
an expected change, so I saved the new one.
You can say, OK, trust, but only once, as you would do in a browser.
Or you can say, oh, no, it's definitely an attack.
I want to reject it, maybe call some security team.
We haven't implemented that yet, but do not send back the secrets in any case.
That's what we do here.
We reject it.
And so it falls back to asking you a passphrase to end up your disk.
And that's about it for today.
So you can, it's Versatile, you can embed it in any TramFS.
You can use it as a second factor.
We provide in the release sample, make a script to build the VM that I just demonstrated.
We also just today published a release just for you, first time attendee, so that you
do not need to rebuild everything.
You can just test.
Then if you're interested about the protocol, you have five minutes of questions.
But trust us, we ask the security team, I mean, the cryptography team in our lab to
review it.
It's fairly standard.
It's fairly standard for a multi-station protocol.
And so, yeah, we want to integrate more.
That's why we are here today to talk to you.
So go on ncfr slash ultra blue, add slash release if you want some binaries for Android
and x86 Linux.
And yeah, I'm here for questions.
I'll start with a question.
How practical would it be to run this on your laptop?
Well, I'm not like I just basically mentored Loic, but I co-mentored Loic with Nicolas
Bouchiner, who should be in this room somewhere, I think, yes, here.
And Nicolas mentioned just yesterday that he's now quite ready to use it on his laptop.
So I guess ask him.
I don't even have secure boot enabled on this laptop.
So I guess the French NSA doesn't allow you to use that.
So it's like, I mean, this is the public, so it's endorsed by our agency.
It's been endorsed in the sense that it's OK to release the code publicly.
We have reviewed it as carefully as we can.
We do not consider it production grade right now.
Have you thought about using it to assess the IMA log at runtime as well, so for files
that are accessed against some network-accessible database, not only for boot, but also for
checks at runtime?
So I think for checks at runtime, there are two things here.
Checks at runtime of your file system, I think you want to use more like the VM variety and
other mechanisms that we have.
But the TPM doesn't only have uses at boot time.
So the fact that you run remote attestation, this could be done later.
The advantage to make it early is that you can detect if you're compromised in the before
inputting your password, basically.
Yes, I see some questions here in the back.
Let's say that nobody swaps your TPM, yes, put that case aside.
Could you get the same level of attestation just with signatures with the TPM?
Let's say you don't think that somebody was going to swap your TPM.
So could you just check some of the parts of the boot chain and just sign the hashes
and just add boot, verify the signature with TPM?
The problem is how do you trust what you see on the screen of your laptop?
The idea that the phone remains in your pocket, so the phone is trusted or it's more trusted
to have two devices than one, because it's harder to compromise two devices.
So if something in your boot loader is compromised, it could show you on your computer that, okay,
the TPM measures check out, et cetera.
And this is even more true for something that's called dynamic root trust measurement, root
of trust measurements.
So not only trusting your BIOS to make the measurements, but like some special instructions
in CPUs where you restart the root of trust later in the boot process.
But for this to work, the check has to be external.
You said it's not production ready.
Do you see it being production ready anytime soon?
Is that the goal?
It's not a stated goal of the agency.
I'd be very happy for it to be used more widely.
But I think for this to happen, we need people outside of the agency interested.
Yeah, looks great.
I have a question regarding the app on the mobile phone.
So how does the app know that it's speaking to a trusted server or the server that it
can trust?
So does it exchange keys with the server on first use or how does it work?
So there is a trust on first use.
So there are two levels of security.
First, the Bluetooth communication is encrypted and the key for that communication is embedded
in the QR code that you scan first.
And then the identity of the TPM.
The TPM has a secret key inside and uses it to...
And so the public key is stored in the app on the mobile phone.
And so the app can check that it talks to the expected TPM.
So basically, the encryption key is used to attest that it's the same operating system
or E-NITRA MFS, and the TPM key is used to check that it's the same TPM.
Yeah, but that's still, as far as I understand, does not prevent a malicious server to send
the app the wrong values or to just imagine the values and send them echoed.
So there is something that we haven't implemented right now because we wanted it to be easy
to test with virtual machines and software TPMs.
But one thing is that the TPM certificates, like basically you have a list, the TPM keys
are signed by vendor, and so you have a list of the keys of the vendor that are used to
sign the certificates.
So when you get the quote from the TPM, you can check that it's a hardware TPM by some
well-known manufacturers and not some eliminated TPM.
So you can be sure that you're actually talking to a physical TPM device, and so the server
cannot mess with that.
But you're right, we haven't implemented this right now, otherwise the demo on purpose,
so to say, because otherwise the demo wouldn't work.
That's an option I want to add.
Very good question.
This is using Bluetooth, Bluetooth specification is very complicated.
How much does it rely on Bluetooth working fine or as expected?
So it's using Bluetooth low energy.
It's relying on the Go Bluetooth library to work fine.
So we don't use any of the Bluetooth stack encryption for the encryption part.
We roll out our stuff, and we layered the code so that it's mostly agnostic to the underlying
transport.
So if you want it to run over infrared, it should be relatively easy to port.
I just don't know how to code that.
And we are extremely conservative in that we just abort as soon as we receive packets
out of orders or unexpected packets.
OK, last question from online.
Someone asked if any distribution expressed any interest in making it in the Ultra Blue?
Yes, in fact, but not officially, some Twitter messages.
We presented this at Open Source PMWare conference last September as well.
And after that, there was some interest online and people saying that Fedora, they may be
interested, but it was not official Fedora position.
Some Fedora contributors.
I can say that this is interesting to that.
Thank you.
Thanks, for the speaker.
We have one request.