So today we will talk about trust for the platform module project.
So, hello, I am Matej.
I am currently an engineering manager at 3MDep.
I'm an open source contributor for several years.
I'm interested in various stuff, build systems.
I enjoy build reliability especially.
I like embedded systems in general.
I worked to several layers with embedded Linux projects.
Now, I'm also working with some stuff with Carboot.
Also, security aspects is what I'm interested in.
You can have some contact information on the slide if you want to reach me.
Some of you already heard that we are 3MDep,
a parent-based company over severance in the market.
We work mostly in open source firmware and embedded Linux areas.
We are a part of various organizations,
various open source initiatives like Carboot
licensed service providers or reactor participants.
So, to the agenda.
So, let's start with explaining what the TWPM project is,
why we decided to start one.
We'll talk about some stuff about TPM modules.
Then, we'll explain how we started such project,
what challenges do we expect,
what roadmap we have and what's the current state of the project. So,
Trust World Reversed Trusted.
So, you probably know that Trusted platform modules.
So, we came up with a name Trust World 3 platform module.
So, to indicate that the goal would be to make it a bit more
trust-worthy than it is today by providing the open source
firmware for that one.
And the goal also would be to be compliant with
the TCGPC client specification,
which might be in fact quite difficult or maybe even impossible.
We will see, we will discuss also that later.
But, yeah, that's the goal.
The project is funded by Nernet, by NGI Azure Fund.
So, why we came up with the idea,
the traditional TPMs are dedicated microcontrollers and they,
not typically, they always have proprietary firmware,
which can be easily audited or at least not by regular users,
maybe by some governance, maybe.
If there are bugs, they might not be fixed,
depending on what the vendor is planning for,
site-line TPM module, TPM chip.
There are also capabilities which might be limited in some cases
and if there is no firmware update from vendor,
they might not be modified by a user.
There are also several different interfaces, LPC,
which is present mostly on older motherboards,
but it's still commonly used.
There is also SPI,
which is typically present on newer PCs.
And there is also iSquare-C,
which is present mostly on mobile devices or also on TALAS.
So, another problem is that if you,
at some point, wanted to buy a TPM module,
you probably know that there are a bunch of
different types of connectors,
you need to get a one which is compatible with your mainboard.
Even if they look the same,
they are really not and if you plug in
incompatible one, you may even break
your module or even your mainboard.
For example, we can see LPC connectors for MSI and ASUS.
They look the same, the MTP is in the same place,
but the ground and power is swapped.
So, some smoke may happen if you look ASUS to MSI or all the way around.
Similar stuff for SPI.
Also, connectors look the same at the first glance,
but they are very, very different for different motherboards.
Even for the same vendor,
you can have different type of connectors and there are many, many more.
So, at first, we wanted also to address the hardware problem,
but it looks too complex.
We want to focus on just the firmware for start.
The virality of connectors is huge,
bigger than anticipated.
So, at other states of the project,
we focus purely on the firmware and connect it even by
some jumper wires to the motherboard,
just to have some proof of concept in the firmware,
then we can worry about some other stuff.
So, how can we start the project?
We need some code to process our TPM2 commands.
There are a few command processors out there.
At least, we know of two of them,
the Microsoft Implementation,
which provides simulator code for various OSs.
There are also some interesting samples in that repository.
There is FTPM trusted application for us,
ARM trust zone and there are also some samples for STM32,
Nucleo, which is what we will be interested the most.
Then, we also have a simulator from IBM.
Maybe there is some more.
I think these two are the most popular ones.
So, we took a look at the Nucleo sample,
which was mentioned just before from the Microsoft TPM reference stack.
So, it was created like four years ago,
contributed and it's not like either maintained or tested.
So, there is no single person who knows if it ever worked, basically.
It looks like it was developed in
Atolic True Studio, which is not an existing software.
Currently, it was replaced by some other STM32 integrated development environment.
We also asked about the status in general of the sample codes.
So, the answer is that these are
those contributed at some point in time or when it may not work currently.
So, we took a closer look at that piece of code.
We have converted the product into the newer programs.
We were able to build at least to a certain point to at least run it.
On the Nucleo board,
we noticed there is some Vicom application.
It was presumably used for testing the solution on.
The application is only for Windows.
We haven't even tried to bother with that.
In fact, as we know,
as what pain it might be to build some all-to-visual studio stuff.
But we look at the code.
We saw that the STM32 code can
accept TPM commands via USB CDC.
It can process it.
It can return some response or some simple command response was there.
But what was important is some custom protocol was involved here.
So, there was no interoperability with existing tools,
such as TPM tools stack or with existing TPM interfaces
because it was very custom one,
and the interoperability is a major goal of this project as well.
Also, the resources on the MCU was quite low.
So, at this point, we had a lot of idea of what we have to face with.
So, we want to also show how different the flow
is for the TPM2 simulator versus the TPM2 actual hardware.
The block on the top is,
we can say what Microsoft or IBM reference implementation provides.
It just provides TPM2 commands processing.
For the simulator, that's fine.
It uses like sockets and communicates with
the TPM2 software stack in the OS directly.
But in case of the hardware,
you need to plug in the actual module to the motherboard.
So, we need all of the plumbing.
So, there are also dedicated specifications on that in the TCG.
So, those are the orange blocks that
needs to be implemented in the firmware.
So, we need all of the plumbing to pass the commands from
the microcontrollers through the motherboard connectors to the OS drivers,
and then at last to the TPM2 software stack in the operating system.
What are the challenges, current and expected?
One of the first was the global chip shortage,
which happened in the meantime.
So, even if you wanted to use the STM32L4,
it was no longer available to source.
The other microcontroller was also quite difficult to get.
The project in the samples was developed using
the hardware abstraction layer from STM.
If you want to switch to another hardware,
you would need to rewrite that thing at least to some point,
to another hardware abstraction layer,
and then the chips becomes unavailable and that will go on forever.
Also, we do not have the requirements
clarified that were at that point.
So, we believe that what must be done is to have
some OS handling the TPM stack.
So, we are looking into ZFROs to have
some better hardware coverage and
just implement the TPM stack in the ZFROs.
So, we can switch between boards more easily.
Another challenges are different types of timing problems.
In the TCG specification,
it requires some timings of different levels on the hardware level.
For example, some registers must respond in some milliseconds and so on.
It might be difficult to achieve such responsiveness
on just a microcontroller.
Maybe we will need to fall back to FPGA in some cases.
Definitely, we need to fall back to FPGA for LPC interface,
which is non-existent on general-purpose microcontrollers.
So, we are developing a hardware block in FPGA for that.
There are also some environment improvements which can be made.
As I said before, a full compliance might be quite difficult or
might be even impossible to achieve.
For example, in case of the strict initialization time and
power requirements because the power requirements are quite low.
I don't remember the exact value right now,
but typical microcontroller plus FPGA and also the boot time might be challenging here.
It's a lot of moving parts.
We are still looking into that.
So, the roadmap.
The first step on the project plan was public site-duty documentation.
So, that one is already live.
Although, there is not much content there yet.
We are just starting, we can say.
But once there is already there,
we have already some structure and the roadmap is also public.
Then the hardware, as I mentioned before,
we started with the nuclear as it was supported by the Microsoft samples.
We're still exploring that,
but that's probably not enough of a hardware to accomplish the goals of this project.
Another one we are exploring right now is one which is based on the EOS S3 SoC.
It combines Cortex-M4 and FPGA in a single chip.
That might be interesting to have a Cortex-M4 for TPM to stack,
and to have some FPGA for fast response and LPC communication.
The third point which we are working on right now is LPC implementation.
FPGA, so that requires to target the many mainboards which are currently in the market,
which have only the LPC interface.
Then we need to implement also all of the plumbing I showed before on the slides.
So, TPM registers as defined in the specification.
Also, there is some specialized FIFO protocol to pass the commands between the TPM and the host.
So, that's a screenshot of some testing at the LPC module.
We are using very like Icarus, I believe, for creating the data and GTK wave for drawing that out, currently.
Then some testing is also necessary.
We are already preparing some test cases.
We can start preparing them based on the regular TPM modules,
and we want to expect that our module will meet the same criteria.
Of course, we'll add some specific test cases later on as well.
SPI protocol is also tricky, even though it should be simpler in theory,
because the typical MCUs have SPI,
but typically, they are tested, let's say, in master mode, not in the slave mode.
That's the most common case, and also the frequency is limited.
The frequency of SPI on motherboards can be 40 MHz or more,
but typical SPI, for example, the STM32 is advertised up to 24 MHz,
but in reality, we have not been able to achieve that event so far,
so that also might be difficult,
and maybe also FPGA can help you to achieve the timing requirements we need.
The eight point is exactly exploring the usage of simpler hardware platforms,
so maybe we were hoping that maybe we can achieve at least SPI connection
on a board without FPGA.
That would be simpler and would give more users ability to test that out,
at least on even Raspberry Pi or with the motherboard,
so they can push that forward and have some TPM module on some regular development boards, even.
I already mentioned some TPM stack improvements,
sorry, the flash drive for TPM stack improvements.
For example, the more test suites,
there are some problems we already seen with what was there,
there is no redundancy at least,
maybe also encryption because the SPI could be read out from the board,
but we may leave the encryption for later,
but at least we would like to have the redundancy
because otherwise it would be quite easy to prick the TPM board,
which is not what we want.
We also need some unique identification and some source of entropy,
that would be required to have some unique ID for each device,
and we need some entropy for cryptographic operations.
This is left for later,
we will see what kind of hardware we will end up in the end.
We might use some hardware specific features,
and if not, maybe we can use FPGA finally.
Manufacturing, as you might know,
each TPM must contain unique key,
endorsement key, and also certificate related to that.
So, we might provide a way for a user to generate
the endorsement key for their TPM,
so just to provide some scripts and procedures,
how they can provision the TPM device.
Then also we imagine that it would be nice to have some nice build system,
so we can configure what kind of interface I want to target.
I have a motherboard with SPI,
so I just flip the SPI switch,
rebuild the project,
I check the hash algorithm I'm interested in,
I choose what kind of hardware entropy I'm interested in,
and the goal here is to make the transition between the boards more easy.
I can plug out my TPM,
flash another firmware,
and use it on my new motherboard,
which now supports SPI and previously it used like LPC.
What's currently in progress?
Yes, the LPC module I showed a screenshot from.
The next TPM registers will be implemented.
We want to pursue as much as we can in the FPGA also in the simulation,
and before we stick to two certain hardware,
and we also determine how big of the FPGA would be required here.
We also in the parallel exploring the path of not using FPGA and using
SPI for on the STM or another microcontroller.
Maybe even if we could reduce the frequency to lower,
use it with the Raspberry Pi as a proof of
concept that would already be quite an achievement I believe.
Maybe even if it wouldn't work with the regular mainboards,
maybe after some time it could be improved,
but it could be a nice step forward.
Dogs, we are working on the dogs,
they will be progressively filled with
the results of our current work.
Yes, if you are interested in the progress and maybe want to contribute,
maybe want to discuss about the project and created stuff,
you can join our communication channels.
On the other hand, if you want to join the team or work daily
on open-source similar projects,
you might approach me directly or use
contact information from the next slide.
So that would be it and we might have some questions. Yes.
You mentioned the timing of the problems.
Have you looked into how the system behaves if you delay,
maybe they or will things not work if you are too late answering some things?
I'm not sure if I followed exactly, you're asking about some timing issues we had.
There are some timings defined by the TCG specification.
So for example, they say the given command,
TPM to command must respond with the given time.
So that's one.
If you don't respond in that time,
what happens and did you look into that?
We are not at the stage even currently.
We are at the lower layer,
so we are trying to get the plan being done so we can even send one command.
But on the lower level, yes,
there are also problems with timing too.
At least on the SPI part, for example,
we had a problem that the STM32,
we've been using doesn't give us the enough flexibility
that we needed to follow the spec in some cases.
There is like SPI IP block,
which can just send and receive some data over the SPI.
But if you would want to specify
some more on the start of the transmission,
pull that line down or up,
that might be more tricky to do as well.
So maybe the FPGA would also help here. Yes.
I have a couple of questions about FPGA.
Have you selected an FPGA?
So the question was if we selected FPGA, no.
As I said, we are just exploring the hardware on the right.
So the ESS3 SoC,
so that one has Cortex-M4 and FPGA integrated into one SoC,
and that's the one we are analyzing right now.
Maybe it would be fit for the project.
If you wanted to use FPGA only,
because what is also important here is that we require,
we need CPU to process the TPM stack commands.
So either we can use hard CPU like that with FPGA combined,
or we need to use full-blown FPGA, soft core, and so on,
and that's another complexity.
We might be also not that much experienced with that,
because we need to run the TPM stack on the CPU.
When do you select an FPGA you need to use when you control flash,
or because of so that it can't be tampered with it's using?
Yes. So the question is if we want to,
if we need to use internal flash so that flash is not tampered with,
yes, that would be preferable of course,
but at this point we are flexible enough to just have anything working,
prove that it's even feasible with some limitations,
even if the flash is separate, it can be read out.
We might not care right now.
We focus on the most important parts to even prove that it's feasible or not,
and maybe other stuff can be handled later once we prove that we can do it or not.
The problem is that you're trying to receive data over SPI essentially,
your device tries to be an SPI slave,
but the SPI is not flexible enough, and you want to run it, is that right?
So yes, it's right that we want to be a SPI slave because the main board is master, yeah?
So are you aware of chip line-up from Cypress, the P-talk?
It's like a Cortex-M plus a little bit of not really FPGA but programmable clue,
which can configure just some degree.
Probably.
Okay, so there is a suggestion from the audience on the some Cypress series, B-talk, yeah?
So yeah, so I don't think we have considered that so far, so thank you for that.
From the hardware with hard CPU plus FPGA, we found so far the EOS S3 which we're looking into,
it has some Zephyr support, which is a plus, of course.
There are, I think, also one board from Go-in, like Tank Nano, it was the name, I think.
Yeah, so thanks, we'll check that out after the Cypress B-talk.
Yeah?
Did you consider trying to get an emulator-based development environment working,
mainly using something like QMU, so that you are sort of decoupling your hardware debug
from your software debug, and I know that QMU, you can implement a virtual LPC and SPI devices,
and it also has a Cortex-M emulator in QMU as well, so perhaps that might be a possibility.
Okay, so the question is if we consider some emulator development environments.
So as I showed, we're right now exploring some, at least for the FPGA part, we start with simulation,
and we develop LPC slave and host, and we can test that out in a simulation
for simulating the whole Cortex-M, we have not done so far,
maybe that's also something to consider.
Any more questions? We can have one more, I believe.
Okay, sec, oh, okay.
Isn't it a big risk to, let's say, move away from the hardware part first,
because a big part of using a TPM is actually being a trusted device,
so if it's somewhere and you come back, then you will know it's what you want,
and by now putting a lot of focus on the software, and just kind of ignoring the hardware part,
what would happen if this software would work really nicely?
Let's say SCM32 is in the field, I'm probably testing that.
Wouldn't that weaken everything a lot more than just trusting these CC evaluated TPMs?
So the question is, I believe, if we have a, let's say, software firmware running on the SCM32,
and how we can make sure that the software was not tampered with, for example, yeah?
Yeah, tampered or maybe extracted or whatever.
Okay, so we know there are existing mechanisms, for example,
for different values have already microcontrollers, different types of secure boots and so on,
so we can verify if it's our firmware, if it's signed.
The user can sign its own firmware and otherwise the firmware wouldn't boot, for example.
I believe once we have the functionality, there are already existing mechanisms
that can prove that the firmware was not tampered with.
That's my understanding, yeah.
Okay, so we are out of time, thank you.
Thank you.