All right, for the next talk, Johan and Valentin
will tell us everything there is now from the point
boost security features on embedded
little system. Let's welcome them.
So, hello everyone. We are very happy today to be with you
to explain some Linux boot-secular features.
We are trying to develop on our image systems.
So, I'm Valentin Jeffoa and I am with today with Johan Gutier
and we are both Linux and Bailey engineers in IoT Base Ledge.
So, it's a small company that is in France.
I will quickly explain what we are making in Alcompanie
and then we will speak about some secure boot features and Johan will explain
what we have developed in respect to the environment.
So, firstly, we are based in Brittany and we are known for contribution
on our automotive Linux.
So, it's a project we contribute.
And today we are developing our web-based, which is two things.
So, it's an embedded system based on the centre-s of all those nodes.
We have a lot of security features and in another part,
there is a web-based factory which allows us to build applications and images.
So, the context today is cyber-secretary, so it's a very big world.
So, cyber-secretary in our use case, we have to think about embedded devices.
So, for example, for home automation, for automotive, for mobile devices,
you can have vulnerabilities, issues about security.
So, a lot of entry points.
And for someone with malicious thoughts, for example,
he wants to gain access on the system.
So, it could be very dangerous.
So, that's why we are trying to fix to build a real world of trust on our systems.
So, you can have the web-neverchage tool.
So, today we are mainly focused about the booting security.
No, it's about CV or other things that you can find on our other presentation at was them.
Today, the European Union is working very hard to give some worlds,
tenders and laws about security.
Maybe you know a cyber-resigned act, which is effective today.
And it's penalties for manufacturers who are not respecting some standards.
That's why embedded providers and suppliers must be compliant with this world.
And in a specific use case for automotive, for example, there are a lot of standards to that.
That's why booting security is very important.
So, today, I'm not speaking about all our security features in our operating system,
but mainly about sexual boot and essential integrity, verification and our system.
So, it's very important to increase all your data.
Let's see the sensible, for example.
And you and we will explain later what's we deploy on our systems in restricted environments with constraints.
So, a generalised statement for our image for images.
So, we support a lot of B-speed today, both arm and internal architectures.
And the manufacturers, the survivors, have different implementation of cyber boot features.
That's why it's difficult to generalise big solution for everything.
So, that's why we have to think about each step of the boot flow.
For example, we have NXP, Renaissance, T-Site Instruments, the survivors.
We are currently at zero B-speed for our operating system of some boards.
And today, we will see only one NXP for people and others.
And NXP, why because it's well documented, you can file all documentation at the web.
And, for example, for me, it helped me a lot to understand a lot of sexual boot features.
So, the idea is to guarantee each boot flow step.
For example, with a signed process or by a verification of each switch.
Here is an example of two things.
So, firstly, it's important to understand a classical Linux boot flow.
So, there are a lot of things.
And as a previous talk, speak about it.
You can have different steps in the chain.
So, here is the first example of a typical boot chain on NXP platform.
So, from the separate starting, you have a lot of vulnerabilities, which load a lot of things.
And for us, the interesting parts is on your boot boot loader.
And the little boot boot loader will load the canal in the memory.
And after, you can have a system G services, in our case, and our base OS application.
So, we have to guarantee all these flow in-integrity.
So, you can have here an example on NXP platform.
It's a couple of implementations.
So, with a couple of private key and public key, you can use to sign a bold loader.
You can start the public key on one-time programmable fuse, if you know.
And you see the values in G and G3 to start the primary public key on the hardware.
And this guarantee us the vote of trust of our system.
And after when the system load, you can have your boots verification, the snitor.
And an interesting feature, it's a very five-boats.
You can check the Linux kernel and the device tree integrity.
To guarantee that a malicious user hasn't changed anything.
And you can have a kind of features like FSVWT, but for us today, we will speak about the MCreate and the MVWT.
So, just a setup, the MVWT is a runtime in a verification of some integrated blocks.
And the MCreate is for encryption.
And I let you and explain to you how it applies to features and what's problem.
You add on a restricted platform.
A little time.
Thank you.
So, Valentine explained the theory about a secure boot.
And now I'm going to talk about a very specific implementation that we had to do for clients on a very restricted hardware platform.
So, on top of a security, about secure boot, there is the full description and the integrated check.
So, I'm going to talk about that.
Every here is the hardware we had to work on.
So, one call, CPU, 32 bytes, one gigabyte, and one gigabyte of RAM.
And most of the time, none of the memory for the disk.
The other one is a bit better.
But still, we were restricted also because the segmenter only supports old kernels, 3.18 and 4.14.
So, many security features are not available with those kernels.
Or you have to backport a lot of stuff.
We also had that requirement that key features had to be up at least at 30 seconds after boot.
It's already very complex to have this kind of feature running without security.
It's even harder when you want to integrate all this boot security.
First, about full description, the key is stored into security memory, HSM or KB, TPM.
And then you, because our client, of course, doesn't want to have the same key for all it's bought.
We had to encrypt the board at boot time.
So, we had to do that at first boot.
So, to do that, we had to implement an image from FS.
That there is the full description at first boot, so that takes a lot of time.
And then store the key and burn the key into security memory.
And also, as the memory is, it seems like it works.
It's a NAND.
It has nowhere leveling hardware leveling.
So, we had to use the UBFS and squashFS to do the software ware leveling.
So, this has an impact as we're using the input to encrypt the disk.
It's not supported on such old kernels.
So, we had to use another file system on top of UBFS to use the input that way.
So, this has a pretty big impact about 20 to 40% IO throughput.
And also, it takes more space.
As you have another file system, it's taking about 15 megabytes added on top of that.
Of course, you have to use all the hardware solution that you can use.
And again, whenever you want to update, you have to re-encrypt the new partition.
On top of that, you have to add the integrated check.
And on this platform, the NAND is not usable at all.
As it's too much for IO's NCPU.
So, we had to do the integrated check again at good time from the initramFS.
So, at good time, we calculate the hash of the old file system and store it into the RAMFS.
And as it is trusted by the previous bootchain, it's safe there.
You can change it as you wish.
But of course, at boot, you lose 10 seconds just for very faring your system.
And also, whenever you want to update, you have to update a boot image.
But to avoid that, we implemented a way.
And we are storing the integrated hash at the end of every partition.
Then, whenever you want to, and of course, this is signed at built-in.
And whenever you want to verify the integrated, you can check the signing of the hash at the end.
And verify all the partition as you would usually do.
And of course, for that, you have to parallelize as much as you can as you want to optimize the IO's.
And that.
So, as you could see, security has a big cost in terms of performance.
It's pretty difficult to implement mostly on old SOC.
And you're very constrained by what your SOC vendor give you.
And there is, of course, a lot of progress to do on that on our side.
So here is some reference and a link for finding this.
And if you have any question, we'd be glad to answer them.
Thank you.
Okay, I just want to ask you, why do you keep the pride of key?
Into the question.
Where do we keep the private key?
Into.
To keep the private key.
To keep the private key for fully-concruption.
Yeah, sure.
Yeah.
Yes, this is on the builder somewhere else, but not exactly on the builder, but it's like it.
The private key is not stolen the board, it's only on the builder.
And then you can verify using the public key.
Our client is private key secretly, but not really using the two world developers and so on, because that's.
That's done by our clients.
They have their own server for keeping the priority and delivering the public key for signing.
Okay.
And historically, on the server, or you use the other security model on top.
Yeah, that was our client thought.
Oh, we excuse me.
Do you store the public key in an HSM on this build server on the build machines?
Yeah.
So where were we keep the private key?
We as IoT does not keep the private key.
That's our client that takes care of how they keep the private key.
Of course, yes, it's very probably done on server HSM and things like that.
Yeah.
I just want to add to the loop.
Think about a couple.
And people are good.
Yes, that was actually.
No, no, yes.
Sorry.
Did we look into the core boot then?
Libre boot.
I actually know.
And very probably they were not available for those old partners that we have to use.
Okay.
So if you didn't have to use this background,
what would you do differently today?
It was a modern system.
I would use.
Oh, yeah.
What do we do if we could use some more recent scan L?
Yeah.
So start 12.
Yeah.
We probably would use a file disk encryption.
But we proposed that actually to our client as we could do with this old comments.
But this has the program.
I think that's again, you have to check at runtime.
And that's pretty big load for those CPUs.
And you have to list the files.
That's that are important to to check.
And so you don't have to check the entire file system.
But that would be the best alternative.
We'd propose them that they wanted the full integrity and full disk encryption for some reason.
Other questions?
Why?
I have a comment on the question.
So I spotted a terrible time when we stake our modules live.
Can you go back please?
Where you had the boot flow with the.
Good job.
Yes.
That's for.
It's a part of the screen.
Yeah.
It's lower case.
It's not the paper spell.
Yes.
It's a mistake.
Another question is, you mentioned.
You have kernel 2018 and 14.
Right.
Yeah. That one.
Do you use later system D on this user space?
They do have system here.
Oh, I don't think so.
Because if you do upgrade system D next version,
it will not boot on either of this.
Yeah.
On this one, there's no system D at all.
Just a minute.
Even this end of life.
It does handle the.
The end of system D.
You are healing.
Yeah.
We should.
We should not even use this old car now.
You know, they have to produce.
Yeah.
Okay.
So I'm wondering what the final goal is.
It's just an experiment.
What could be done?
Because I mean, give you all these ancient versions,
which are out of life.
And of life.
You cannot really make a product out of it.
So what's the.
So the question is,
Why using those old car names?
Yes.
You have to use them, but in the end,
if you want to make a product out of it,
you can't do that chip.
So.
That's.
I'm sorry.
I don't know how to repeat the question.
Well.
So.
Why?
So segmentos only support this old car name.
So we had to do with it.
And it's is really into today's products.
Which SOC vendor is that?
No, I don't know.
You say sorry.
Not comment.
Because many of those old SOCs are much better supported in the mainline.
Yes.
This.
I think.
No, that's very old chips.
And it's.
The problem is that it's.
They have.
They are really require.
Certified chips.
And they only.
With the modem.
On it.
So you're very limited in terms of full user.
That.
It gives you a certified product.
And.
So they stick with this kind of.
This case of chip.
That's how.
Very outdated and very odd to maintain.
About the.
In your system, do you have any alternative.
Do we have any alternative to use the.
The.
We did not use the.
I mean on this platform.
Yeah, we.
We tried using the.
The.
Actually they tried before.
We came in the course for.
For doing something in the.
And the.
And.
No, so that's why we had to.
To implement a way of.
Very faring the system.
Uh, before runtime.
As runtime is not working.
It's killing the.
The IOs and and CPU and.
And you can do nothing.
Yeah.
We're.
Thanks.
Thank you.
I'm sure.
You would.
Oh, it does not support you would.
This chip does not support you would.
It's a UFI and.
We.
Yeah, we.
We have to let you.
Very good.
But not anticipate from but on.
That's that's a specific case for one of our clients.
We're using.
Very.
More recent.
Uh, platforms for our system.
Much more.
Much recent.
Yeah.
Anyway.
You.
Back for security.
But it's too old.
No.
Yeah.
Um.
Do we back for security features for the.
This all kernels.
Um.
We.
We did not.
Uh.
It's been done.
Uh.
The.
Uh.
There.
Yes.
No.
To more.
No.
Um.
Do.
Do we.
We.
You.
Of course.
Do we have any.
For our image.
Yes.
Uh.
That's what I explain.
Uh.
We have to use.
Uh.
So,
So.
So,
So.
But you're not in the world if you can't remember.
You're not in the world if you can't remember.
And I'll check if you can't remember.
Sorry, I did you get anything?
Sorry.
I think maybe your question is, do we use the same key for the channel and in the program FES?
Yes, it's the boot image.
The old boot image is signed and verified by the previous bootloader.
So yes, it's the same key for the old-plop channel and ram FES.
Like you would do with the fit image on your boot or something like that.
You're fine.
Thank you.
One more.
Anybody there?
One, two, twice.
It's like the speaker's time.
Thank you.