WEBVTT

00:00.000 --> 00:13.640
All right, for the next talk, Johan and Valentin

00:13.640 --> 00:16.600
will tell us everything there is now from the point

00:16.600 --> 00:18.160
boost security features on embedded

00:18.160 --> 00:20.160
little system. Let's welcome them.

00:20.160 --> 00:27.160
So, hello everyone. We are very happy today to be with you

00:27.160 --> 00:30.960
to explain some Linux boot-secular features.

00:30.960 --> 00:35.160
We are trying to develop on our image systems.

00:35.160 --> 00:39.160
So, I'm Valentin Jeffoa and I am with today with Johan Gutier

00:39.160 --> 00:43.160
and we are both Linux and Bailey engineers in IoT Base Ledge.

00:43.160 --> 00:47.160
So, it's a small company that is in France.

00:47.160 --> 00:53.160
I will quickly explain what we are making in Alcompanie

00:53.160 --> 00:58.160
and then we will speak about some secure boot features and Johan will explain

00:58.160 --> 01:03.160
what we have developed in respect to the environment.

01:03.160 --> 01:09.160
So, firstly, we are based in Brittany and we are known for contribution

01:09.160 --> 01:11.160
on our automotive Linux.

01:11.160 --> 01:15.160
So, it's a project we contribute.

01:15.160 --> 01:21.160
And today we are developing our web-based, which is two things.

01:21.160 --> 01:27.160
So, it's an embedded system based on the centre-s of all those nodes.

01:27.160 --> 01:33.160
We have a lot of security features and in another part,

01:33.160 --> 01:39.160
there is a web-based factory which allows us to build applications and images.

01:39.160 --> 01:45.160
So, the context today is cyber-secretary, so it's a very big world.

01:45.160 --> 01:51.160
So, cyber-secretary in our use case, we have to think about embedded devices.

01:51.160 --> 01:57.160
So, for example, for home automation, for automotive, for mobile devices,

01:57.160 --> 02:02.160
you can have vulnerabilities, issues about security.

02:02.160 --> 02:05.160
So, a lot of entry points.

02:05.160 --> 02:10.160
And for someone with malicious thoughts, for example,

02:10.160 --> 02:14.160
he wants to gain access on the system.

02:14.160 --> 02:17.160
So, it could be very dangerous.

02:17.160 --> 02:26.160
So, that's why we are trying to fix to build a real world of trust on our systems.

02:26.160 --> 02:29.160
So, you can have the web-neverchage tool.

02:29.160 --> 02:33.160
So, today we are mainly focused about the booting security.

02:33.160 --> 02:41.160
No, it's about CV or other things that you can find on our other presentation at was them.

02:41.160 --> 02:48.160
Today, the European Union is working very hard to give some worlds,

02:48.160 --> 02:50.160
tenders and laws about security.

02:51.160 --> 02:56.160
Maybe you know a cyber-resigned act, which is effective today.

02:56.160 --> 03:02.160
And it's penalties for manufacturers who are not respecting some standards.

03:02.160 --> 03:10.160
That's why embedded providers and suppliers must be compliant with this world.

03:10.160 --> 03:16.160
And in a specific use case for automotive, for example, there are a lot of standards to that.

03:16.160 --> 03:21.160
That's why booting security is very important.

03:21.160 --> 03:28.160
So, today, I'm not speaking about all our security features in our operating system,

03:28.160 --> 03:35.160
but mainly about sexual boot and essential integrity, verification and our system.

03:35.160 --> 03:39.160
So, it's very important to increase all your data.

03:39.160 --> 03:42.160
Let's see the sensible, for example.

03:42.160 --> 03:55.160
And you and we will explain later what's we deploy on our systems in restricted environments with constraints.

03:55.160 --> 04:00.160
So, a generalised statement for our image for images.

04:00.160 --> 04:06.160
So, we support a lot of B-speed today, both arm and internal architectures.

04:07.160 --> 04:14.160
And the manufacturers, the survivors, have different implementation of cyber boot features.

04:14.160 --> 04:19.160
That's why it's difficult to generalise big solution for everything.

04:19.160 --> 04:25.160
So, that's why we have to think about each step of the boot flow.

04:25.160 --> 04:33.160
For example, we have NXP, Renaissance, T-Site Instruments, the survivors.

04:33.160 --> 04:38.160
We are currently at zero B-speed for our operating system of some boards.

04:38.160 --> 04:45.160
And today, we will see only one NXP for people and others.

04:45.160 --> 04:51.160
And NXP, why because it's well documented, you can file all documentation at the web.

04:51.160 --> 04:58.160
And, for example, for me, it helped me a lot to understand a lot of sexual boot features.

04:58.160 --> 05:05.160
So, the idea is to guarantee each boot flow step.

05:05.160 --> 05:12.160
For example, with a signed process or by a verification of each switch.

05:12.160 --> 05:16.160
Here is an example of two things.

05:16.160 --> 05:21.160
So, firstly, it's important to understand a classical Linux boot flow.

05:21.160 --> 05:24.160
So, there are a lot of things.

05:24.160 --> 05:28.160
And as a previous talk, speak about it.

05:28.160 --> 05:33.160
You can have different steps in the chain.

05:33.160 --> 05:39.160
So, here is the first example of a typical boot chain on NXP platform.

05:39.160 --> 05:47.160
So, from the separate starting, you have a lot of vulnerabilities, which load a lot of things.

05:47.160 --> 05:53.160
And for us, the interesting parts is on your boot boot loader.

05:53.160 --> 05:58.160
And the little boot boot loader will load the canal in the memory.

05:58.160 --> 06:05.160
And after, you can have a system G services, in our case, and our base OS application.

06:05.160 --> 06:11.160
So, we have to guarantee all these flow in-integrity.

06:11.160 --> 06:15.160
So, you can have here an example on NXP platform.

06:15.160 --> 06:17.160
It's a couple of implementations.

06:17.160 --> 06:24.160
So, with a couple of private key and public key, you can use to sign a bold loader.

06:24.160 --> 06:32.160
You can start the public key on one-time programmable fuse, if you know.

06:32.160 --> 06:40.160
And you see the values in G and G3 to start the primary public key on the hardware.

06:40.160 --> 06:45.160
And this guarantee us the vote of trust of our system.

06:45.160 --> 06:53.160
And after when the system load, you can have your boots verification, the snitor.

06:53.160 --> 06:58.160
And an interesting feature, it's a very five-boats.

06:58.160 --> 07:02.160
You can check the Linux kernel and the device tree integrity.

07:02.160 --> 07:08.160
To guarantee that a malicious user hasn't changed anything.

07:09.160 --> 07:22.160
And you can have a kind of features like FSVWT, but for us today, we will speak about the MCreate and the MVWT.

07:22.160 --> 07:29.160
So, just a setup, the MVWT is a runtime in a verification of some integrated blocks.

07:29.160 --> 07:32.160
And the MCreate is for encryption.

07:32.160 --> 07:39.160
And I let you and explain to you how it applies to features and what's problem.

07:39.160 --> 07:42.160
You add on a restricted platform.

07:53.160 --> 07:55.160
A little time.

08:03.160 --> 08:06.160
Thank you.

08:06.160 --> 08:11.160
So, Valentine explained the theory about a secure boot.

08:11.160 --> 08:24.160
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.

08:25.160 --> 08:37.160
So, on top of a security, about secure boot, there is the full description and the integrated check.

08:37.160 --> 08:40.160
So, I'm going to talk about that.

08:40.160 --> 08:44.160
Every here is the hardware we had to work on.

08:44.160 --> 08:51.160
So, one call, CPU, 32 bytes, one gigabyte, and one gigabyte of RAM.

08:52.160 --> 08:58.160
And most of the time, none of the memory for the disk.

08:58.160 --> 09:01.160
The other one is a bit better.

09:01.160 --> 09:17.160
But still, we were restricted also because the segmenter only supports old kernels, 3.18 and 4.14.

09:17.160 --> 09:23.160
So, many security features are not available with those kernels.

09:23.160 --> 09:26.160
Or you have to backport a lot of stuff.

09:26.160 --> 09:38.160
We also had that requirement that key features had to be up at least at 30 seconds after boot.

09:39.160 --> 09:47.160
It's already very complex to have this kind of feature running without security.

09:47.160 --> 09:56.160
It's even harder when you want to integrate all this boot security.

09:57.160 --> 10:15.160
First, about full description, the key is stored into security memory, HSM or KB, TPM.

10:15.160 --> 10:27.160
And then you, because our client, of course, doesn't want to have the same key for all it's bought.

10:27.160 --> 10:30.160
We had to encrypt the board at boot time.

10:30.160 --> 10:33.160
So, we had to do that at first boot.

10:33.160 --> 10:37.160
So, to do that, we had to implement an image from FS.

10:37.160 --> 10:42.160
That there is the full description at first boot, so that takes a lot of time.

10:42.160 --> 10:48.160
And then store the key and burn the key into security memory.

10:48.160 --> 10:56.160
And also, as the memory is, it seems like it works.

10:56.160 --> 10:58.160
It's a NAND.

10:58.160 --> 11:01.160
It has nowhere leveling hardware leveling.

11:01.160 --> 11:09.160
So, we had to use the UBFS and squashFS to do the software ware leveling.

11:10.160 --> 11:15.160
So, this has an impact as we're using the input to encrypt the disk.

11:15.160 --> 11:20.160
It's not supported on such old kernels.

11:20.160 --> 11:29.160
So, we had to use another file system on top of UBFS to use the input that way.

11:29.160 --> 11:35.160
So, this has a pretty big impact about 20 to 40% IO throughput.

11:35.160 --> 11:38.160
And also, it takes more space.

11:38.160 --> 11:47.160
As you have another file system, it's taking about 15 megabytes added on top of that.

11:47.160 --> 11:53.160
Of course, you have to use all the hardware solution that you can use.

11:53.160 --> 12:02.160
And again, whenever you want to update, you have to re-encrypt the new partition.

12:03.160 --> 12:06.160
On top of that, you have to add the integrated check.

12:06.160 --> 12:12.160
And on this platform, the NAND is not usable at all.

12:12.160 --> 12:17.160
As it's too much for IO's NCPU.

12:17.160 --> 12:28.160
So, we had to do the integrated check again at good time from the initramFS.

12:28.160 --> 12:39.160
So, at good time, we calculate the hash of the old file system and store it into the RAMFS.

12:39.160 --> 12:45.160
And as it is trusted by the previous bootchain, it's safe there.

12:45.160 --> 12:50.160
You can change it as you wish.

12:50.160 --> 12:59.160
But of course, at boot, you lose 10 seconds just for very faring your system.

12:59.160 --> 13:04.160
And also, whenever you want to update, you have to update a boot image.

13:04.160 --> 13:11.160
But to avoid that, we implemented a way.

13:11.160 --> 13:16.160
And we are storing the integrated hash at the end of every partition.

13:16.160 --> 13:21.160
Then, whenever you want to, and of course, this is signed at built-in.

13:21.160 --> 13:27.160
And whenever you want to verify the integrated, you can check the signing of the hash at the end.

13:27.160 --> 13:32.160
And verify all the partition as you would usually do.

13:32.160 --> 13:41.160
And of course, for that, you have to parallelize as much as you can as you want to optimize the IO's.

13:41.160 --> 13:47.160
And that.

13:47.160 --> 13:54.160
So, as you could see, security has a big cost in terms of performance.

13:54.160 --> 14:00.160
It's pretty difficult to implement mostly on old SOC.

14:00.160 --> 14:10.160
And you're very constrained by what your SOC vendor give you.

14:10.160 --> 14:21.160
And there is, of course, a lot of progress to do on that on our side.

14:21.160 --> 14:26.160
So here is some reference and a link for finding this.

14:26.160 --> 14:33.160
And if you have any question, we'd be glad to answer them.

14:34.160 --> 14:43.160
Thank you.

14:43.160 --> 14:47.160
Okay, I just want to ask you, why do you keep the pride of key?

14:47.160 --> 14:49.160
Into the question.

14:49.160 --> 14:52.160
Where do we keep the private key?

14:52.160 --> 14:57.160
Into.

14:57.160 --> 15:07.160
To keep the private key.

15:07.160 --> 15:19.160
To keep the private key for fully-concruption.

15:19.160 --> 15:29.160
Yeah, sure.

15:29.160 --> 15:31.160
Yeah.

15:31.160 --> 15:37.160
Yes, this is on the builder somewhere else, but not exactly on the builder, but it's like it.

15:37.160 --> 15:42.160
The private key is not stolen the board, it's only on the builder.

15:42.160 --> 15:48.160
And then you can verify using the public key.

15:49.160 --> 15:58.160
Our client is private key secretly, but not really using the two world developers and so on, because that's.

15:58.160 --> 16:00.160
That's done by our clients.

16:00.160 --> 16:06.160
They have their own server for keeping the priority and delivering the public key for signing.

16:06.160 --> 16:08.160
Okay.

16:08.160 --> 16:14.160
And historically, on the server, or you use the other security model on top.

16:14.160 --> 16:17.160
Yeah, that was our client thought.

16:17.160 --> 16:20.160
Oh, we excuse me.

16:20.160 --> 16:26.160
Do you store the public key in an HSM on this build server on the build machines?

16:26.160 --> 16:27.160
Yeah.

16:27.160 --> 16:29.160
So where were we keep the private key?

16:29.160 --> 16:33.160
We as IoT does not keep the private key.

16:33.160 --> 16:37.160
That's our client that takes care of how they keep the private key.

16:37.160 --> 16:44.160
Of course, yes, it's very probably done on server HSM and things like that.

16:45.160 --> 16:46.160
Yeah.

16:46.160 --> 16:48.160
I just want to add to the loop.

16:48.160 --> 16:50.160
Think about a couple.

16:50.160 --> 16:52.160
And people are good.

16:52.160 --> 16:55.160
Yes, that was actually.

16:55.160 --> 16:57.160
No, no, yes.

16:57.160 --> 16:58.160
Sorry.

16:58.160 --> 17:01.160
Did we look into the core boot then?

17:01.160 --> 17:03.160
Libre boot.

17:03.160 --> 17:06.160
I actually know.

17:06.160 --> 17:12.160
And very probably they were not available for those old partners that we have to use.

17:13.160 --> 17:14.160
Okay.

17:18.160 --> 17:22.160
So if you didn't have to use this background,

17:22.160 --> 17:24.160
what would you do differently today?

17:24.160 --> 17:26.160
It was a modern system.

17:26.160 --> 17:28.160
I would use.

17:28.160 --> 17:29.160
Oh, yeah.

17:29.160 --> 17:33.160
What do we do if we could use some more recent scan L?

17:33.160 --> 17:34.160
Yeah.

17:34.160 --> 17:35.160
So start 12.

17:35.160 --> 17:36.160
Yeah.

17:38.160 --> 17:41.160
We probably would use a file disk encryption.

17:42.160 --> 17:49.160
But we proposed that actually to our client as we could do with this old comments.

17:49.160 --> 17:52.160
But this has the program.

17:52.160 --> 17:57.160
I think that's again, you have to check at runtime.

17:57.160 --> 18:01.160
And that's pretty big load for those CPUs.

18:01.160 --> 18:04.160
And you have to list the files.

18:04.160 --> 18:08.160
That's that are important to to check.

18:08.160 --> 18:11.160
And so you don't have to check the entire file system.

18:11.160 --> 18:14.160
But that would be the best alternative.

18:14.160 --> 18:20.160
We'd propose them that they wanted the full integrity and full disk encryption for some reason.

18:20.160 --> 18:23.160
Other questions?

18:23.160 --> 18:24.160
Why?

18:24.160 --> 18:26.160
I have a comment on the question.

18:26.160 --> 18:29.160
So I spotted a terrible time when we stake our modules live.

18:29.160 --> 18:31.160
Can you go back please?

18:31.160 --> 18:34.160
Where you had the boot flow with the.

18:35.160 --> 18:36.160
Good job.

18:36.160 --> 18:38.160
Yes.

18:38.160 --> 18:39.160
That's for.

18:39.160 --> 18:41.160
It's a part of the screen.

18:41.160 --> 18:42.160
Yeah.

18:42.160 --> 18:43.160
It's lower case.

18:43.160 --> 18:45.160
It's not the paper spell.

18:45.160 --> 18:46.160
Yes.

18:46.160 --> 18:48.160
It's a mistake.

18:48.160 --> 18:51.160
Another question is, you mentioned.

18:51.160 --> 18:56.160
You have kernel 2018 and 14.

18:56.160 --> 18:57.160
Right.

18:57.160 --> 18:58.160
Yeah. That one.

18:58.160 --> 19:01.160
Do you use later system D on this user space?

19:01.160 --> 19:03.160
They do have system here.

19:03.160 --> 19:06.160
Oh, I don't think so.

19:06.160 --> 19:11.160
Because if you do upgrade system D next version,

19:11.160 --> 19:14.160
it will not boot on either of this.

19:14.160 --> 19:15.160
Yeah.

19:15.160 --> 19:18.160
On this one, there's no system D at all.

19:18.160 --> 19:19.160
Just a minute.

19:19.160 --> 19:21.160
Even this end of life.

19:21.160 --> 19:23.160
It does handle the.

19:23.160 --> 19:24.160
It does handle the.

19:24.160 --> 19:25.160
The end of system D.

19:25.160 --> 19:26.160
You are healing.

19:26.160 --> 19:27.160
Yeah.

19:27.160 --> 19:28.160
Yeah.

19:28.160 --> 19:29.160
We should.

19:29.160 --> 19:32.160
We should not even use this old car now.

19:32.160 --> 19:34.160
You know, they have to produce.

19:34.160 --> 19:35.160
Yeah.

19:35.160 --> 19:36.160
Yeah.

19:36.160 --> 19:38.160
Yeah.

19:38.160 --> 19:39.160
Okay.

19:39.160 --> 19:42.160
So I'm wondering what the final goal is.

19:42.160 --> 19:43.160
It's just an experiment.

19:43.160 --> 19:44.160
What could be done?

19:44.160 --> 19:47.160
Because I mean, give you all these ancient versions,

19:47.160 --> 19:49.160
which are out of life.

19:49.160 --> 19:50.160
And of life.

19:50.160 --> 19:52.160
You cannot really make a product out of it.

19:52.160 --> 19:54.160
So what's the.

19:54.160 --> 19:56.160
So the question is,

19:56.160 --> 19:59.160
Why using those old car names?

19:59.160 --> 20:01.160
Yes.

20:01.160 --> 20:03.160
You have to use them, but in the end,

20:03.160 --> 20:05.160
if you want to make a product out of it,

20:05.160 --> 20:07.160
you can't do that chip.

20:07.160 --> 20:08.160
So.

20:08.160 --> 20:09.160
That's.

20:09.160 --> 20:10.160
I'm sorry.

20:10.160 --> 20:12.160
I don't know how to repeat the question.

20:12.160 --> 20:13.160
Well.

20:13.160 --> 20:14.160
So.

20:14.160 --> 20:15.160
Why?

20:15.160 --> 20:16.160
Why?

20:16.160 --> 20:20.160
So segmentos only support this old car name.

20:20.160 --> 20:22.160
So we had to do with it.

20:22.160 --> 20:26.160
And it's is really into today's products.

20:27.160 --> 20:31.160
Which SOC vendor is that?

20:31.160 --> 20:32.160
No, I don't know.

20:32.160 --> 20:34.160
You say sorry.

20:34.160 --> 20:36.160
Not comment.

20:36.160 --> 20:42.160
Because many of those old SOCs are much better supported in the mainline.

20:42.160 --> 20:43.160
Yes.

20:43.160 --> 20:44.160
This.

20:44.160 --> 20:46.160
I think.

20:46.160 --> 20:47.160
I think.

20:47.160 --> 20:50.160
No, that's very old chips.

20:50.160 --> 20:52.160
And it's.

20:52.160 --> 20:54.160
The problem is that it's.

20:55.160 --> 20:56.160
They have.

20:56.160 --> 20:58.160
They are really require.

20:58.160 --> 21:01.160
Certified chips.

21:01.160 --> 21:03.160
And they only.

21:03.160 --> 21:05.160
With the modem.

21:05.160 --> 21:06.160
On it.

21:06.160 --> 21:09.160
So you're very limited in terms of full user.

21:09.160 --> 21:10.160
That.

21:10.160 --> 21:13.160
It gives you a certified product.

21:13.160 --> 21:14.160
And.

21:14.160 --> 21:17.160
So they stick with this kind of.

21:17.160 --> 21:18.160
This case of chip.

21:18.160 --> 21:19.160
That's how.

21:19.160 --> 21:22.160
Very outdated and very odd to maintain.

21:23.160 --> 21:24.160
About the.

21:24.160 --> 21:27.160
In your system, do you have any alternative.

21:27.160 --> 21:31.160
Do we have any alternative to use the.

21:31.160 --> 21:33.160
The.

21:33.160 --> 21:35.160
We did not use the.

21:35.160 --> 21:38.160
I mean on this platform.

21:38.160 --> 21:40.160
Yeah, we.

21:40.160 --> 21:42.160
We tried using the.

21:42.160 --> 21:43.160
The.

21:43.160 --> 21:45.160
Actually they tried before.

21:45.160 --> 21:46.160
We came in the course for.

21:46.160 --> 21:48.160
For doing something in the.

21:48.160 --> 21:49.160
And the.

21:49.160 --> 21:50.160
And.

21:51.160 --> 21:53.160
No, so that's why we had to.

21:53.160 --> 21:56.160
To implement a way of.

21:56.160 --> 21:58.160
Very faring the system.

21:58.160 --> 22:00.160
Uh, before runtime.

22:00.160 --> 22:02.160
As runtime is not working.

22:02.160 --> 22:03.160
It's killing the.

22:03.160 --> 22:05.160
The IOs and and CPU and.

22:05.160 --> 22:07.160
And you can do nothing.

22:07.160 --> 22:08.160
Yeah.

22:08.160 --> 22:09.160
We're.

22:09.160 --> 22:10.160
Thanks.

22:10.160 --> 22:11.160
Thank you.

22:11.160 --> 22:12.160
I'm sure.

22:12.160 --> 22:13.160
I'm sure.

22:13.160 --> 22:14.160
I'm sure.

22:14.160 --> 22:16.160
I'm sure.

22:16.160 --> 22:17.160
I'm sure.

22:17.160 --> 22:18.160
I'm sure.

22:19.160 --> 22:21.160
You would.

22:21.160 --> 22:22.160
You would.

22:22.160 --> 22:23.160
You would.

22:23.160 --> 22:26.160
Oh, it does not support you would.

22:26.160 --> 22:28.160
This chip does not support you would.

22:28.160 --> 22:30.160
It's a UFI and.

22:30.160 --> 22:31.160
We.

22:31.160 --> 22:32.160
Yeah, we.

22:32.160 --> 22:33.160
We have to let you.

22:33.160 --> 22:34.160
Very good.

22:34.160 --> 22:36.160
But not anticipate from but on.

22:36.160 --> 22:39.160
That's that's a specific case for one of our clients.

22:39.160 --> 22:40.160
We're using.

22:40.160 --> 22:41.160
Very.

22:41.160 --> 22:43.160
More recent.

22:43.160 --> 22:46.160
Uh, platforms for our system.

22:46.160 --> 22:47.160
Much more.

22:47.160 --> 22:48.160
Much more.

22:48.160 --> 22:49.160
Much recent.

22:49.160 --> 22:50.160
Yeah.

22:50.160 --> 22:51.160
Anyway.

22:51.160 --> 22:52.160
You.

22:52.160 --> 22:53.160
Back for security.

22:53.160 --> 22:54.160
But it's too old.

22:54.160 --> 22:55.160
No.

22:55.160 --> 22:56.160
Yeah.

22:56.160 --> 22:57.160
Um.

22:57.160 --> 22:58.160
Um.

22:58.160 --> 22:59.160
Um.

22:59.160 --> 23:01.160
Do we back for security features for the.

23:01.160 --> 23:02.160
This all kernels.

23:02.160 --> 23:03.160
Um.

23:03.160 --> 23:04.160
We.

23:04.160 --> 23:05.160
We.

23:05.160 --> 23:06.160
We did not.

23:06.160 --> 23:07.160
Uh.

23:07.160 --> 23:08.160
It's been done.

23:08.160 --> 23:09.160
Uh.

23:09.160 --> 23:10.160
The.

23:10.160 --> 23:11.160
The.

23:11.160 --> 23:12.160
Uh.

23:12.160 --> 23:13.160
Uh.

23:13.160 --> 23:14.160
Uh.

23:14.160 --> 23:15.160
Uh.

23:16.160 --> 23:17.160
There.

23:17.160 --> 23:18.160
There.

23:18.160 --> 23:19.160
Yes.

23:19.160 --> 23:20.160
No.

23:20.160 --> 23:21.160
To more.

23:21.160 --> 23:22.160
No.

23:22.160 --> 23:23.160
Um.

23:23.160 --> 23:24.160
Do.

23:24.160 --> 23:25.160
Do.

23:25.160 --> 23:26.160
Do.

23:26.160 --> 23:27.160
Do we.

23:27.160 --> 23:28.160
We.

23:28.160 --> 23:29.160
We.

23:29.160 --> 23:30.160
You.

23:30.160 --> 23:31.160
Of course.

23:31.160 --> 23:32.160
Do we have any.

23:32.160 --> 23:33.160
For our image.

23:33.160 --> 23:34.160
Yes.

23:34.160 --> 23:35.160
Uh.

23:35.160 --> 23:36.160
That's what I explain.

23:36.160 --> 23:37.160
Uh.

23:37.160 --> 23:38.160
We have to use.

23:38.160 --> 23:39.160
Uh.

23:39.160 --> 23:40.160
Uh.

23:40.160 --> 23:41.160
Uh.

23:41.160 --> 23:42.160
Uh.

23:42.160 --> 23:43.160
Uh.

23:43.160 --> 23:44.160
Uh.

23:44.160 --> 24:00.160
So,

24:00.160 --> 24:01.160
So.

24:01.160 --> 24:03.160
So.

24:03.160 --> 24:09.160
So,

24:09.160 --> 24:10.160
So.

24:10.160 --> 24:13.160
But you're not in the world if you can't remember.

24:13.160 --> 24:15.160
You're not in the world if you can't remember.

24:15.160 --> 24:17.160
You're not in the world if you can't remember.

24:17.160 --> 24:20.160
And I'll check if you can't remember.

24:20.160 --> 24:25.160
Sorry, I did you get anything?

24:25.160 --> 24:26.160
Sorry.

24:26.160 --> 24:36.160
I think maybe your question is, do we use the same key for the channel and in the program FES?

24:36.160 --> 24:38.160
Yes, it's the boot image.

24:38.160 --> 24:42.160
The old boot image is signed and verified by the previous bootloader.

24:42.160 --> 24:48.160
So yes, it's the same key for the old-plop channel and ram FES.

24:48.160 --> 24:52.160
Like you would do with the fit image on your boot or something like that.

24:52.160 --> 24:54.160
You're fine.

24:54.160 --> 24:56.160
Thank you.

24:56.160 --> 24:58.160
One more.

24:58.160 --> 25:00.160
Anybody there?

25:00.160 --> 25:03.160
One, two, twice.

25:03.160 --> 25:05.160
It's like the speaker's time.

25:05.160 --> 25:06.160
Thank you.

25:06.160 --> 25:08.160
Thank you.

25:36.160 --> 25:38.160
Thank you.