Hi, I am Alice. I worked at Capfruit actually in Switzerland, a company from Switzerland.
And today I'm going to talk about Trusted Boot with the GenotOS framework, aka using TPM with
Genot. A word about Capfruit. So once upon a time, some team of engineers that work
in R&D could create a real product based on microcan and inkable-b-based security.
In 2018, this five-engine year for the Capfruit I-D. One of the most important milestones
in 2020, Capfruit released its first NDP, a Trusted Execution Environment for the banking
industry and I-John Capfruit. Since then, Capfruit has committed with different partners and
created network to work on product for the IoT sectors, most of using under the device
based on ARM or X86. These devices are mostly used to interconnect other devices to the
internet or even with the ambition to quickly replace different set of machines to be on
a one-board on the needs of your machine that does the machine control and also connect
to the internet. This set, this set, this is a set of requirements
that we have for our product key infrastructure. We want other devices to be shipped from
the factory with their touch provisioning. What we are meaning here is that we don't want
a new man or an specific intervention to open on the device. It's provisioning in the factory
and it's protocol, customer and it should connect to the cloud and fetch its configuration
for there. For this, we need to provide access to the cloud. Another thing that we want
to do for that is to use the Trusted Cognitive-based to record the bootchain environment
in PCRs. And for that, we're going to use a router straff. It's going to be a TPM, a Trusted
Platform module. We're also going to use the TPM to sign shortly certificate so that
this legacy up can easily access the cloud. And all of this is running on a macro-canon-based
operating system. So the design goal we are for the TPM stack is compatibility and separation
of concerns between a huge monotip block. We have different components and some of the
components are part of the TCB. We need them to be able to easily trust them, such minimal
Trusted Confidence. We also want for application to benefit from existing libraries. Also,
we want integration with a measured boot and non-retail PCRs. We don't this because we
want to be able to take the system and we want to be sure which system is actually running
so shorter than secure boot. We want to be sure this is this image that is running and
eventually we also want updating to do rollback prevention. Finally, we will see PIM to authenticate
and integrate our OPKI and we also want compatibility with the legacy up application.
So the foundation of all of this is measured boot and platform configuration registers a
amount of existing image that is extended in TCI and 9. So let's look at a practical example.
The FH Trésor Trusted Anchor. What is Trésor? Trésor is the consist of block
uncryptor created by Gnode. It's actually an ecosystem and most notably we have its Trusted Anchor.
So in Gnode, VF is not like any operating system. We have a global FH system. We have a
FH system server and provide the session interface in all the micro-danners stuff and the actual
implementation of the FH system they usually come as plug-ings. Trude object. For example, if you have
an actual FH, you can have the implementation of an actual FH system from a block device.
When it's then fashion that Linux likes to do character device, we can also create a FH system
a plug-ing that will be the driver for the TPM and expose it as a file. That's the architecture
we decide to take. So everything that we are seeing here from the TPM up to the Trésor Trusted
Anchor is actually 5 system plug-ings at the exception of two other devices. So how does that look like?
We have the hardware on there. We have what we call the TPMOS. It's going to be a subsistender
content to drive for the hardware. In the middle, we have the TPM max. It's going to multiplex
the TPM and some resources, more detail about this coming and finally we have the Trésor Trusted Anchor.
The Trésor Trusted Anchor is basically abstracting for the rest of the subsistender,
the secret key that is used by the CBE. The three, so it has different set of file that abstract
low operation you can do. But the three main operation we are interested in from the TPM is creating the
secret key, still in it, and unsealing it. And what we are going to do is perhaps this plug-ing
using a TPM. We can also have at the same time also component. We have the TPM to run them here.
It's basically just the lip C-base example from the lip TSS. We can have a TPM to it. TPCR
reports that basically report the state of the PCR in the NXML blob. And report the specific
session in the genome operating system framework. It's more to use for debugging.
So the support hardware, let's have a look at the TPM observed system. TPM comes in different
versions. We may have this great TPM, we have femo TPMs, and we also have TPMs on USB-T because
why not. On this great TPM usually they are connected to the main slot using a spi-bus or an
isqueci-bus. So the first plug-ing is going to abstract the platform and a pin control session
into a file system session. So it hands just a fine. That's going to be dev-spi. But it does
the red-white interface is just an extra abstraction to the bus. If we want to use it for the
TPM, we will need the TPM-T. This is going to be to translate the ability to write a full
command and under all the bus operation. For X86, we have the TPM CRB, so TPM can be accessible from the
command response buffer interface. In that case, we can directly write the all command to the bus.
So in that case, we all directly have the TPM row file. And finally, for USB-C, we are taking
advantage of a cool feature of the genome that is actually too. So on a higher level, we bought
the TPM 2TSS library, so client application can use the TPM. This library comes from the Linux
world and expects a dev TPM zero device. The TPM max provides this device. It multiplixes the command
if different components wants to access the TPM. But most importantly, it loads an unload
object-manage method resources. As I said, the TPM is a discrete device. It has a hue, a persistent
object, but most of the time, when you want to do an operation, you will need to load in advance
first, so that you need, and then you can buffer an operation. And then you need to unload
this resource. Otherwise, you are not going to be able to perform many operations. This component
does that for you. So the application that has 200 at this level, this resource management.
On Linux, we have the TPM 2, AB, Air and D, which comes also for the Linux world, but it's way
to complex for a use case. And also, we want to keep the TPM as much as possible. So step
120 road, the TPM max, a simple AirFest plugin keeping the TCC small.
Now, the Troso Trost Anker. So it's a file plugin. What must it do is generate the CBE
secret key. And it's in the CBE key on a persistent file system. What the system is brought
down, and later on it turns it on, and you want to unlock your CPE again. For that, we use the
TPM 2, TSS library that reads the TPM 0 file from the TPM max. It uses a policy session for PCR
and password authorization. This is where whole the magic happened. Remember, at the beginning,
you were using visual boots, and at that thing, our boot chain, we have measured all the boot
components of the operating system. So when we reach the state of the full of the running operating
system, all the PCR has be extended, we think that matters to us to be measured. We will use
those value to authorize certain operation on the TPM on top. Let's have a look at which function
actually the Trost Anker will use from the TPM 2, TSS library. Here, there is actually an important
detail. When the Trost Anker is constructed for the first time and access the TPM, we will need to
provision it. In this specific case, for the sake of simplicity, if it's not provision, what we're
going to do is create a policy PCR, and for that we're going to select a set of PCR and a value
and they're going to result in a digest in the policy. Then we are going to ask the TPM to create
an empty space, and this space is one of this persistent object in the TPM. And we are going to write
this policy digest that we just created in there. And we select the policy, the PCR we want,
using this policy PCR. And this time, we result with a digest, we're going to do policy
authorized, and what happened in the TPM is that the digest that is in the policy is compared
again to one in the end of the run. Those two methods match. In the result operation, whether
the policy is authorized, it's not. Then we will extend this policy with the password. This is
basically the password, the user provide. The result digest is basically wrapped into the private
part of the key we are using to seal the secret key. On the TPM, when you generate a key, the
private part that you get and store on your system is always encrypted, so you can't access
the actual private key, only the TPM can. And then we are basically done, we have our RAP secret
key. Later on we want to unseal, so we load our secret key, we will recreate our policy again,
we autorize it and again at the end of the run, we set the policy password, and if everything
is authorized, then we can actually unseal from the private key and get the secret key.
First of all, I haven't talked about the different key, but there exists a different
key on which you can create different keys and a primary key that you have derived
all the keys. And those different key are different property. We have been using the owner
year, and the owner used the TPM owner, we want to set the owner password. In that case, we
don't have any input GUI to provide it, so we assume it's not set, which on a positive
environment we shouldn't do that. Later on, we also don't have input GUI to set to provide
the password, the old value for the end space. So it means that when we provision the TPM in
the first place, we have created the random, and we set this is the password to access the end space.
We wrote it, and as soon as we are done, we get rid of the password. This is a problem,
because this means that now we have brittle PCRs. We are protected from an attacker, it's very
good. No one can change the LVRM, and no one can pretend, putting another system. Now,
we rest in a trusted state. You can't do that. The problem is, if you're using an operating
system such as code, and you're updating to the next version, you pull the C for PCR,
are not matching again. So you can't unlock the CB anymore. So for that, we need a mechanism
to update the PCR values to actually update the policy digest into NVR, and when the PCR
values change, because of the system update. Finally, and most importantly, the biggest problem
we have is the TPM. Two TSS depends in the ellipse C. So a problem that might not be obvious
in the first place is that everything is running in file systems. Those are file system plugings.
Displayable, you may need such things as an allocator. There is to it to proceed. As I provide
a minimal ellipse, that is not filling on the VFS, only to perform operational such as
allocation, or eventually just armor, damage with patches on top of the libraries.
The lesson's run. TPM are hard. Most notably, we had a case where we sealed a key, and then we
unsealed it, and the unsealed value is not matching the value we sealed, because something I haven't
mentioned earlier, but we were using a parameter encryption. This means any sensitive data
provided to the TPM is not visible to a potential observer on the bus. And if it's not done properly,
eventually you might take a quick garbage and just get garbage in the return. But there is a good
advantage is providing vitamins instead of bank healers when using the TPM. Finally, again, using TPM
to TSS, and then getting open as a challenge when using the VFS when they depend on the
ellipse. And also, what's really neat with the file system plugging architecture is that it's a very
good way for my perspective to organize the complexity of all these things together and to expose
them to third party application or subsystem without having a huge monolid block.
Thank you for your attention.
Thank you Alice for this great talk on a very important subject, and we have lots of time for
questions, because this is the last last one. So, good question. I have a question. What you've
described so far seems to be mostly focused on aesthetic wood of trust. Have you also looked
at the dynamic wood of trust, who did NPCOS 17 and 18?
Now, I think I've got answer this question because my knowledge are limited to this.
However, what we are planning to fix this to have non-britled BCR is to use sign policy and to
rather provide the policy about the wood image and to let the TPM recognize this policy saying
all this was decided by trusted authorities, such as example our company or any provider of the
wood image, and then said, okay, now we can load this policy that contains the RPCR value.
But there is certainly also mechanism that I'm not aware of.
It's just that recent versions of Novok provide this TXT image of launch, where you don't have
to rely on a wood loader and is long chain of trust anymore, and that Alexander at some point
gets to the point where this becomes generally usable for G-node, I think you'll benefit from
the TPM.
Any other questions?
So when you have mentioned the USB here, I did not apply to G-node this question.
I'm here, but it's SPI, but it's certainly just a bug interface as well.
The motivation I think that it was on in the first place, so Stefan Tony, when they came to me
and said, oh, look, I have done that and we finally can use.
He said, must this reason right now, unfortunately, doesn't have to use this on a Linux platform,
this TPM to go, you need a version of TPM 2TSA that is recent enough that it contains the proper
TCTI that's not willing from TPM 0, but using your USB.
So, unfortunately, it's very difficult to rebuild yourself to TPM 2TSA, it's not difficult to
but update it on your system because you break a lot of dependencies.
So, where we say is, oh, maybe it's actually just easier to create this for G-node and using it
from G-node because what we want to do is G-node development.
So, that was the first motivation, but I think we will certainly come with support on top of
base-ish typically.