Thank you.
So yeah, so I'm Temek and I'm going to be talking to you about FTPMs and how they can
be implemented.
So that's me.
I'm currently wrapping up my bachelors in automation and robotics and working full-time
at FRIEMDepth as an embedded systems developer.
Junior embedded systems developer, please keep that in mind.
So if I say something, I'll do my best.
And what is FRIEMDepth?
We are a company based in Gdańsk, Poland and our expertise is in firmware and embedded
systems development.
And we're kind of cool.
You may know us from our main product, Dasara, which is a core boot distribution.
So that's the agenda.
I'm going to first give some information about TPMs, then about ARM trust zone and then about
how it translates to practice and implementing it on embedded systems.
So I guess most of you know what that TPM is, but I'm still going to give a brief overview.
So usually it's a separate piece of hardware, a chip that runs cryptographic operations
like encryption or generating random numbers.
So the system becomes more secure.
Not everything is visible to the user space and thus the surface of attack is lessened.
So there are a few kinds of TPMs.
Oh, yeah, so those are the more about what's cool about TPMs.
Yeah, they can also verify the integrity of the system, of the boot process and detect
any alteration to it.
And yeah, the secure random number generation is also a really important part.
So yeah, there's a few way you can implement TPMs into your system.
So the most basic, the most known way and the one that was shown earlier is the discrete
TPM and it's a separate physical chip that's completely separate from the CPU.
It's on the motherboard, but it communicates with it.
The difference will be more visible when I show you integrated TPM.
It has the cheaper and more space saving option and that is the TPM that is integrated into
another chip.
The danger of that is that now it's that chip, if that chip is somehow corrupted, it's
attacked, it has an connection, it has access to the integrated TPM.
So it's less secure.
The next one is the least secure, but it's still something that is used software TPM and
it's usually an emulation just made for tests and prototyping.
So the main topic of this talk is the last one, the firmware TPM and it's a software
TPM that runs in a trusted execution environment and is separated from the normal S, from the
user space via the trusted execution environment.
The plus of it is it's cheap and it can be implemented on devices that are already provisioned.
So via an update or something, but via an update.
On embedded devices, the trusted execution environment is made possible via ARM trust
zone and ARM trust zone creates a hardware separation.
It creates two distinct words, they're called.
So we have a normal word where we have the normal user space in documentation, it's called
re-choice and there we run our applications like kernel and user space apps and we have
a secure word that has trusted applications and those can be like stuff you don't want
the user space to have access to or only have certain access to.
Such I think can be an FTPM and it can run operations like encryption, decryption, creation
of keys and then it's a random number generation that I'm particularly fond of because it's
kind of funny.
So yeah, and also secure word provides makes it so only trusted OS can access certain parts
of the hardware of for example memory.
So there are parts that are reserved for operations of trusted OS and there are those allowed to
be accessed by which OS.
And this exactly is made possible via secure monitor.
So we have ARM trust zone specifies exception levels and as you can see a secure monitor
allows certain like for example, it tells hypervisor when what memory addresses it can
use and what are specified for secure partition manager that is part of the D.
And so the threat model here is of course if we have an app that's been like a virus
or something, it doesn't get to the bottom.
So we can look at it this way that okay when we have our hypervisor is corrupted, the trusted
applications and trusted OS is still like valid.
But if the secure monitor is somehow corrupted, then we have a problem.
And I'll get to that part later.
Yeah, and all of that was for Cortex-I ARM series.
That's important distinction because on ARM Cortex-M the trust zone works completely different.
It works through interrupts.
It's kind of a funny topic because you could theoretically implement some sort of I wouldn't
say FTPM because Cortex-M doesn't really allow you for example for running operating systems.
There were some, there are some products that do that.
They're on the border of black magic and they're awesome.
But yeah, so FTPM on Cortex-M is a weird concept a little.
Okay, so yeah, there are some problems with FTPMs because you could as I said update a
device via the internet over the air to allow it to add to it FTPMs.
But as the slide says, the best protected systems have dedicated security from the beginning.
And ARM trust zone and TR and like magical thing you can just throw on a device to make
it more secure.
It will make it more secure but not as much secure as it would be if you would think about
those things from the beginning.
Because ARM trust zone doesn't add in itself a lot of the important parts that make an
embedded device secure.
For example, there's no secure storage on like in the ARM trust zone specifically.
You can use an MMC to achieve that.
But if you don't have that on the device that you're updating, you have to find some work
rounds.
The same happens with secure counter or secure clock that can prevent rollback attacks.
And if you don't have those, you're not really protected from them.
The secure source of entropy is a really fun one because there's been a work around
for this.
Actually, there's been work around this specified by the UNICEK presentation.
It's linked at the end of the slides.
The secure source of entropy is a fun one because they've managed to achieve secure
source of entropy via only right ones, only fuses that have some random seed on it.
And they're written once when the device is manufactured.
They can be written again.
And they act as a seed for random number generation.
So fun.
Yeah.
And FTPM also has its own problems because the secrets are written to the memory.
It's not safe on its own, for example, from cold boot attacks.
So when the device is suddenly shut down, you can see the state of the memory that was
at the end of the device last runtime.
The same happens with bus sniffing.
So we can just physically peek at the electrons that travel on the bus.
And also, yeah, you can just plug a JTEC to some processors.
And also, there's a one small caveat.
Normal and secure world can't run in parallel.
So always one runs at once, and they take over.
So if you have an embedded device that requires real-time operation, you're in trouble.
There are workarounds, of course.
But I would like to hear them because it's a problem.
So imagine you were a junior developer and you were taught, OK, so do an FTM in practice.
You're me, basically.
So yeah, that's how I approach the problem.
And that's how it can be approached.
So let's say you have some embedded device.
And yeah, we have there are a few implementations of T that you could use.
Most of them are proprietary.
Opti is not.
Opti is open source.
It's awesome.
It has a documentation.
So yeah, once we have that, we need to build FTPM as a trusted application for RT.
In this case, for Opti.
And at the last step, we add some user space support so we can actually call the TPM.
So let's focus on the second part because it's fun.
No, sorry.
Let's focus on the last part first because I didn't arrange the slides as I thought I did.
So yeah, there's a kernel module in the Linux upstream currently that supports access
to him for FTPM.
So it allows the system to mount FTPM as a TPM.
I'm not going to show you the code.
It's called.
I don't understand half of it by school.
But as you can see, it's made by Microsoft.
And Microsoft provides a description like the paper, the white paper that was written
on FTPMs.
That's also cool.
And they provide a reference implementation.
Great.
And it's for ARM.
Great.
So the half of the work is done, right?
Oh yeah.
That's as I said.
I didn't arrange it as like, yeah.
So that's how the kernel driver works visually.
So yeah, it mounts it.
So it's seen by the user space as a TPM device.
OK, so that's a problem with the Microsoft implementation.
Like it's not maintained at all.
It's provided as it is.
It's cool that it is.
It could us to them.
But it doesn't work currently as it is.
And so that's what I've been fighting with for the last few weeks.
And OK, so this requires tweaking.
The amazing guys at Linaro shouted to them.
We're kind enough to create a fork of OptiMunifestudes
for we used for building.
And it allows to build FTPM.
I have a few minutes left.
So I think I won't be able to show you a demo of it,
because it's there on this laptop.
And I also didn't have time in the last few days
to create a pull request.
So I hope by the time this video is up,
it will already be on GitHub.
And I hope also it will be merged.
But yeah, if you want to build an FTPM on Camu,
that's the best currently repository
available to fork it.
And yeah, Yocto also provides a bitmake recipe
for building OptiWeef FTPM as a trusted application.
But it currently works only for ARM.
I mean, it only works as a test for ARM.
To add support for your own board,
you have to append some recipes and do some magic
to make it work.
I haven't tested it through Rugu.
I haven't tested it as much as we would like to.
So yeah.
And all of this was made work on our current operating
system for embedded devices.
Like to focus on security and make it as adaptable as possible
to solutions for your embedded device.
So yeah.
This is those other resources I use.
So they're all awesome.
I highly recommend this book.
It's not as boring as it may sound.
It's really well written.
So yeah, that's all.
And if we have time for questions, then we can do questions.
Just a request.
Can you go back to the very information
you took page?
OK, yeah, sure.
I'll go back to.
OK, I was shown a card to repeat the question.
So yeah, I was told to go back as late.
So that was a question.
How many?
It's also online.
Make sure that they're also online.
Oh, yeah.
And slides are also online.
So if anyone wants to do something, they're available.
So yeah.
If we have a few minutes.
Oh, yeah, sure.
Just a few years.
Can you use the opti-recipes?
Opti-recipes.
Opti-recipes.
There are the example ones.
Yeah.
So the question was, did I use opti-recipes to build it?
I didn't see any related to FTPM in the examples.
And the examples are also cool, but they're kind of complicated.
So it took a lot of reading and trying
to make sense of those make files.
So I used only I tried, but the thing that worked
was the patching of the Linaro fork, because it also has it.
Like it was last updated, I think, a few years ago.
So it uses a lot of outdated.
Like there's Python 2 syntax in it somewhere.
And so yeah, that's the one I'll be providing.
Apple request, hopefully soon too.
So yeah.
Are there any more questions?
There's also time, Tim, if you want to do a demo,
I'm sure people will.
OK, sure.
So maybe in three minutes, and then we still have five minutes.
Yeah, yeah.
Awesome.
So yeah, this is the Camel image made from this forked Linaro.
So as you can see, we have a normal and secure word.
Currently, it's not started.
So I can start it.
There's some outputs.
Yeah, the secure word doesn't really
provide any way of communicating with it.
We have any sort of, like besides user space.
Oh, sorry.
So yeah.
And this particular example there's an I'll show you,
but I have only one hand for right now.
So it's kind of hard.
That's all.
Yeah, so the Linaro guys provided some aliases to load
the utilities that are on the host system.
They are not built in.
They default in this example, and they load up the not the
exactly kernel module that's currently in the upstream.
It's a slightly different one.
So that's also why I didn't like want to call it a live demo,
because it's more of a live Frankenstein that is currently
working.
Maybe at next post them, I'll have something better
to show you.
So yeah, and if I run this alias that uses all of those
commands, we can run some tests with the IBM implementation
of DPM utilities.
So I think it will output some random generated code.
Oh, I also have to hear a cheat sheet,
because I couldn't remember the exact syntax for creating,
for encryption, the encryption, because DPM tools also
works.
As I said, the FTPM is mounted as a TPM.
So every user's space utility that can use TPM works.
So yeah, I don't know.
Load.
So yeah, so that's the demo, I guess.
So I think we're done.
So thank you.
It's been a pleasure.
See you all somewhere.