Overview of Secure Boot state in the ARM-based SoCs 2nd edition
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61690 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 2023536 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Gamma functionVideoconferencingPresentation of a groupInformation securityState of matterBooting
01:29
Graphical user interfaceBootingBootingImplementationPersonal digital assistantFirmwareOpen sourcePhysical systemInformation securitySystem programmingDisintegrationPresentation of a groupContext awarenessFocus (optics)ArmArchitectureElectronic signatureBinary codeSource codeFormal verificationKey (cryptography)Component-based software engineeringKernel (computing)Computer programRootGastropod shellChainSign (mathematics)System on a chipComputing platformEmailInformationExistenceFeasibility studyProduct (business)Image registrationPhysical systemContext awarenessAreaElectronic signatureMechanism designMedical imagingExpected valueMereologyWordCASE <Informatik>FirmwareBootingInformationArithmetic meanArmBinary codeFile formatInformation securityBootingVirtual machineProjective planeInternet service providerInformation technology consultingUniform resource locatorPublic-key cryptographyCore dumpEmailKey (cryptography)Service (economics)Multiplication signLoginImplementationRootComputer architectureSign (mathematics)ResultantDifferent (Kate Ryan album)MultilaterationVideo gameChainFormal verificationProgrammable read-only memoryConnectivity (graph theory)Decision theoryComputer animation
11:35
BootingArchitectureProduct (business)BitImage registrationOpen sourceBootingFirmwareProcess (computing)FamilyTheoryScripting languageInformationWhiteboardVulnerability (computing)Link (knot theory)Formal verificationComputing platformKey (cryptography)Line (geometry)RootWeb pageComputer-generated imagerySinguläres IntegralStructural loadPairwise comparisonElectronic signaturePhysical systemPrice indexHash functionSingle-board computerAuthenticationBlogComputer programConfiguration spaceMechanism designCurve fittingLink (knot theory)Order (biology)Image registrationCellular automatonChainAdditionWhiteboardThread (computing)Hash functionFirmwareForm (programming)Electronic mailing listProcess (computing)Information securityCASE <Informatik>Medical imagingState of matterAuthenticationFormal verificationBuildingPower (physics)Traffic reportingBootingKernel (computing)InformationShared memoryArmAsynchronous Transfer ModeComputing platformCartesian coordinate system1 (number)Computing platformPublic-key cryptographyDifferent (Kate Ryan album)Binary codeVulnerability (computing)Electronic signatureScripting languageKey (cryptography)Internet forumPhysical systemRootStructural loadWebsiteMechanism designBitField (computer science)Line (geometry)Web pageSign (mathematics)Projective planeComputer animation
21:30
BootingBootingComputer programConfiguration spaceMechanism designSinguläres IntegralCurve fittingFirmwareOpen sourceEmailCodeKey (cryptography)Repository (publishing)Scripting languageNetwork topologyWhiteboardDigital electronicsBinary fileStructural loadBlogDDR SDRAMMulti-agent systemFeasibility studyThread (computing)Internet forumThermal expansionPrincipal idealFunction (mathematics)Personal digital assistantElectronic signatureHash functionAuthenticationComputer-generated imageryComputer hardwareModemWindowVirtual machineBootingPersonal identification numberPower (physics)Mechanism designMedical imagingBinary fileSoftware developerBinary codeKey (cryptography)Computer fileKeyboard shortcutComputing platformInformation securityComputing platformHypermediaMathematicsDigital electronicsDigitizingOrder (biology)Fitness functionConnectivity (graph theory)Formal verificationRootLink (knot theory)FirmwareChainDifferent (Kate Ryan album)CASE <Informatik>Product (business)Presentation of a groupLevel (video gaming)Type theorySign (mathematics)Repository (publishing)Public-key cryptographyDiagramSlide ruleBlogBlock (periodic table)Multiplication signMereologyElectronic signatureScripting languageProcess (computing)InformationRule of inferenceCore dumpCodeStructural loadDescriptive statisticsArmHash functionKernel (computing)Computer animationLecture/Conference
31:24
Program flowchart
Transcript: English(auto-generated)
00:32
Okay. Okay, so we'll start now. The topic of this presentation is overview of secure boot state in the ARM-based socks,
00:42
and this is the second edition of this presentation. No mic here. It's only for the video. Okay. So the first edition was taken place like two years ago. So now we want to present some update from
01:02
the research that we have that two years ago. Can you speak up a little bit? We can't hear you. Okay. Sorry for some.
01:20
A little technical issue. Sorry for that. Okay.
01:50
So it is an agenda for this presentation. So first, I will tell you who I am and where I work.
02:02
So say it's a couple of words about our company. Next, I will just present shortly what do you mean by secure boot in the case of ARM socks, and present how the typical implementation and workflow works. Later, we will show the results from the first edition,
02:23
so from the 2028. Then we will discuss the two cases that we check for this edition, so the Mediatek and the Rockchip cases. Next, we will summarize the whole presentation,
02:41
so try to look what's the difference between those two editions of the presentation, and end with some Q&A session. So this is me. I'm Tomas Zieski, and I'm an Embedded Systems Team Leader at 3MDep.
03:01
I worked there over a few years now. Mostly, I work on the Embedded Systems built with the Yocto project. So I try to integrate the update system and the OS creation for the embedded devices. But because I work with the embedded devices, I try to touch different areas of
03:23
the whole life of the devices. So one of the things I work with is also the system security, and this is the topic of this presentation. So here a couple of words about our company.
03:43
We are from Poland and based in Gdansk. We are the core book license service providers since 2016. Also, UFI adopters since 2018, the Yocto participants.
04:00
So this is the area which I work with from the 2019. Also, the consultants for the FWUPD project, and IBM Open Power Foundation members. Okay. So now, let's explain first what do you mean by
04:21
the secure boot in the context of this presentation. So here we are focused on the ARM context, which is like the feature of the boot room, one of the features that boot room has. Maybe we should call it more like the verified boot,
04:42
because the case here is that when we start the firmware, the next steps of the loaded images are verified, the signatures is verified by the previous part of the firmware.
05:03
So that's why we should call it the verify boot maybe. So we need to use some private key to sign the binary that we put into our machine.
05:20
Then we also need to take the public key from that private key and put it also there. So when we start it, we'll be able to verify the signature and decide if it should be loaded or not. In ARM context, we assume that the boot room is our root of trust.
05:45
We need to take that assumption because most of them are closed source. Probably, it will be better if they will be open-sourced, but it is what it is. Basically, the meaning of the secure boot can be different for any given architecture.
06:02
So if you will be talking about the x86, that would be a little different scenario. So this is the typical implementation. We have the public key that needs to be written inside our sock. Different vendors will have
06:21
some different way to achieve that. So we can, for example, fuse them using electrical fuse. So one time, write them in our sock and later use it every time that we start our firmware.
06:41
There's also a possibility for the OTP registers. So those are the one-time programmable. So as the name says, OTP can be used only one time. One of those two possibilities allow us to make from our boot room our root of trust,
07:04
which we later use to expand it to the chain of trust. Next components can use different keys. So in case of secure boot, we talk about the step between the boot room and the boot loader.
07:26
Here, we have some one key that was used to assign the binary and that public key that was used to verify it. But the later steps of starting our machine can use different keys. So that would be it.
07:45
Typically, we have, let's say, our host machine that should be from secure location and our target device. So on our host machine, we generate some private keys. We build binary and use specific tool to sign them.
08:02
Later, we need to take the public key part of that keys, also the sign in binary, and put it in the target device and then try to verify it. So if the verification will be successful, then we will just boot another step. If not, then specific things can
08:21
happen depends on the vendor that we are using. Also, let's say maybe a couple of words about what it is to sign the binary. Basically, what is common between all the vendors probably is that the sign in binary means that we
08:42
take the original binary and add some header on top of it. This header contain the digital signature and also some specific format at the start which can be different across some vendors,
09:03
or it can be also different inside within one vendor, but when we are using different signing tools. So if we try to sign our binary, we can always try to dump the first couple of bytes of our signed image and check if everything goes as expected.
09:27
This is a quick recap from the last edition. So we look at the 11 cases, five of them like the NXP, IMX, and LiarScape, STSTM,
09:41
Xilinix, and Nvidia looks like fully open-sourced, let's say, and there was none NDA problems with them. So everyone could try to take the documentation that needed fusing and signing tools and try to implement the secure boot on them.
10:02
We have couple of cases where there are information that there is some secure boot to enable on that given machine, but it is under the NDA. So we're talking here about the Marvel Armada, Texas Instruments, Sitara, Qualcomm, and Microchips.
10:22
Also, we talk about two thoughts from the Chinese vendors, like Rockchip and Allwinner, where some documentation was there, another was missing, and also there were some information about tools, but we were not able to find them or maybe use them correctly.
10:46
Okay. So now, I will go through three or four vendors that were listed from the last edition and talk about the differences. That was between those two years. So now, let's start from the NXP.
11:02
In these cases, I think this is the easiest way to start with the secure boot on the ARM socks, because the full documentation is there. All documentation is publicly available,
11:26
so everyone can use it. We have the HAP44, so the High Assurance Boot mechanism on the platforms that are the NXP IMX50,
11:41
53, 6, 7, and 8M. The application note is here, and the only difference between here and there is that those applications are under the free registration to the site. The same is for the IMX8 and IMX8X, which uses the A-HAP mechanism,
12:03
so Advanced High Assurance Boot. The same for Coric Q, and as you see here, the signing tool are available after the free registration. For Marvel Armada, we
12:20
can look at the manuals that are available on the sites. We saw that for the 3D8 and 3D9X families, we have some information that NDA is needed. For other families, like I believe 8K, there's only information that there is a secure boot available,
12:41
but nothing else there. At the last edition, we present that in the U-Boot repositories, we can find some information about how to implement the secure boot on the Marvel Armada. But now, it is not there. It is only on all the releases.
13:02
So this is another difficult step that need to be taken to find those informations. But yeah, if you will just use this from the 2018 branch, we'll see the information how to implement the secure boot,
13:20
but yeah, still this is only the theoretical knowledge, and there's no step-by-step solution how to achieve that. So probably, there's room for mistakes. In video, another quick update.
13:40
Last time, we saw that there are some documentations and tools available. We checked that within last year, and it looks like the documentation is some kind of uncertain, because in one point, it tells that the secure boot is available,
14:02
and they also provides the flashing tools, the script called FlashSH. But in the other place, they just say that the secure boot will be available in the future, nobody exactly know when the future will be. But yeah, that would be it.
14:21
Also about fusing, there's additional script for that, but documentation of it is also some kind of updated. There's also one thread in the form of NVIDIA where someone tried to use it to fuse keys on its platform, and it caused the platform to break,
14:40
because it looks like not every board can be fused, and before we execute that, we just need to check the serial numbers, because some of them are supported some not. Also update on Allwinner. So still, we think that there is no official documentation about the Allwinner socks,
15:01
which would tell us about the secure boot, and also no official documentation about the secure boot itself. But we found some interesting case on the forum where someone was able to use the NanoPioneer with Allwinner H3, and he there provides all the useful links. It's like the 10 or 15 of them,
15:22
or also the whole list of the verification process, with the link to the Sanxi tools repository, which contains some tools which need to be used in order to sign the binaries and also fuse the sock.
15:44
The one vulnerability there is that in any case, when we- oh, sorry. Yeah, one vulnerability is here that if we try to start our firmware, which is signed and the verification fails,
16:02
the platform always goes to the cell mode, which is some kind like the debug mode, and the debug mode can be accessed via the USB port. So if the verification fails, someone could always plug in the USB,
16:21
start from MECOM, and then read everything from the fuses or maybe even wipe them. So the solution there for that was just to destroy the USB data lines on that given port. So even if the platform goes into the cell mode, no one will be able to just read anything from it.
16:43
Okay, so now the Mediatek case. Documentation is provided on the GitLab pages. It is based on the Yocto project like project. So the steps there needs to be done inside the Yocto project build system to achieve
17:02
the implementing the secure boot. But basically, as in other ARM socks, the boot from there is like the root of trust, and later we just achieve it using other mechanism to have the whole chain of trust.
17:21
So after secure boot, we have the TFA trusted board boot, and then we can use the U-Boot feed verified boot to load our kernel image. So if we have all those steps, then we have like whole boot process verified.
17:41
Yeah, and it also was shown in a couple of reports that the Mediatek boot room has some vulnerability, which if we like power it in some special scenario,
18:00
then the boot room may just skip the process of verification the image and still load the firmware. So it looks like even if we like have the public key in the fuses and also the public key in the fuses, and we provide the unsigned image
18:20
and like use this vulnerability, we will be still able to boot our platform. This is a short recap how the secure boot looks on the Mediatek. So we have the BL1 step, which is like the boot room, which load the hashed based on the root of trust
18:43
public key, so this is the public key that we put in the fuses, and calculates also the share of the signatures of the BL2, so this is like the next step loaded. After that, we compare those two values, and if everything is okay, we go next,
19:01
and the same, yeah, and then we load the signature from the BL2, and also calculate the share of it, make the compression, and if everything is once again it's okay, we boot the next steps.
19:23
Okay, and here's the process of enabling the secure boot. It is not clear from the documentation on which socks the secure boot can be enabled. The documentation mentioned the MT8365 and MT683695 ones.
19:43
Different socks may have different FUS indexes, so this, it is really like, we need to check those before we try to fuse our fuses in those socks, but unfortunately, those information is provided with NDA.
20:04
In the process of enabling the secure boot, we need to create two keys, private keys, and provide them to our build system, which sign the BL2 load firmware, and also the, something called the download agent, which is later used by additional proprietary tools
20:26
to flush the image inside our platform, which is also described like here, so we have the FUS writer tool, this is another tool provided with the NDA only,
20:41
which can be used to check the secure boot state on our platform and check if the download agent authentication bits are set. If they are not set, we just need to set them and then provide the public key, which will be fused on the key hash zero field.
21:07
And after that, we will just sign our firmware and use this public key to verify it. Okay, so now let's go to the rock chip case. The public key here can be stored in a fuses in the OTP,
21:24
and it depends on which sock we are using. If the verification of loaded binary will be successful, then we'll just extend our rule of trust, so the bootgram, as in the other ARM core socks,
21:43
to the chain of trust. And later, in case of rock chip, we can use the verified boot mechanism, a fit verified boot mechanism from the SPL to the U-boot and from the U-boot to kernel to provide the whole chain of trust.
22:02
So basically to establish it, we need to like, once again, generate some private and public key pair, burn the public key into the fuses or OTP registers, depends on which sock we are using. Then sign our firmware called edb-loader-image
22:20
in case of rock chip, which is like the U-boot TPL plus SPL merged into one file. Then configure verified boot in SPL and U-boot, which means that we will use the fit images to verify it from the SPL to U-boot and from the U-boot to kernel, and just flush our signed images.
22:41
Documentation for rock chip and as well for our winner, it's like hard to find, and if we find any, probably it will be outdated or really short or just not such useful at first.
23:01
So here we have a diagram of signing the whole of enabling the secure boot, but basically it is something I just described on the previous slide. And sorry for that, but because of time, we'll go just need to skip description of it.
23:22
And now we can talk about signing code in rock chip. So code can be signed using one of the two tools, the ERCA signed tool, which can be started on Linux or secure boot tool, which can be started on Windows. Linux tools can be found on the ERCA bin repository.
23:40
Windows tools was a couple days ago, a couple days, some time ago, was on the repository called Kools tools, but now we are not able to find it. For some reasons, the rock chip-based repositories are maintained in such way
24:01
that some things may be missing after some time. But if you use the ERCA sign tool, we can just generate the signing keys and those keys can be used later with the Linux or Windows tools. And if you use it, and also the ERCA repository provides the any files, which are the files
24:24
that can be used to create the mini loader, used later to fuse our keys in the firmware. And basically any given firmware that we want to sign and use in our socks
24:40
can be also signed with those two tools. There is another tool just to bind the effuses, and we have for that the effuse tool, which is only for the Windows machines. It turns out that when we bring the effuses
25:00
on the rock chip socks, we also need to provide the voltage for one of the pins of the sock, so it is not visible here, but there should be like a FAOCC, FAOCC, FAOE effuse pin,
25:22
which needs to be powered up when we want to fuse the keys in our sock. So for that, we need to find some pin that is there and provide the power by ourselves, or maybe our platform has some special circuit
25:43
just to enable that. Also this information comes from another documentation that are hard to find. This is some summarize of enabling the secure boot. So we need to create loader using the boot merger script that is in the ERCA bin repository.
26:01
Next we create the keys with ERCA sign tool. Next we need to sign the loader with secure boot tool because from what we know now, only sign it with that tool, binaries can be later used on our socks. We try to sign with the ERCA sign tool
26:20
and it doesn't work. And now it looks like this can be hard to achieve because there is no way to download the secure boot tool from what we know now. Then we need to use the effuse tool to fuse our public key in socks and use another tool called the ERCA develop tool,
26:44
which is in the ERCA bin repository just to load the sign that loader into our platform and had secure boot enabled. Here's a link for the blog post which describe all of that, containing all of that,
27:01
what we done with the rock chip platforms. So this is the summarize of where we are after the second edition. The changes are here about the NXP platforms where it looks like we now need to register to get the socks reference documentation.
27:24
The NVIDIA Tegra looks like the documentation is not really, is uncertain and may be outdated. The rock chip one, we know now that it can be achieved but still the documentation is not the best quality. The same with the all winner
27:40
and for the media tag, we see that NDA is needed to achieve the secure boot. So this is the summary of the presentation. Looks like our knowledge is expanded over the last two years. We, for example, know now how to enable the secure boot on the rock chip.
28:02
Still, the general principles is common for all the vendors, so we want to authenticate image before we load it. We have some private key to sign the firmware. We need to fuse the public key inside the sock and the boot home is still fitting as the root of trust.
28:22
All cases use the SHA-2456 as a hash function for digital signatures. And we see that more and more cases the documentation is under the NDA or the quality of it is really not the best. Okay, here's the way of how you can contact us
28:44
and thank you for that presentation. I think we are a little after time. Or maybe one question if there is any.
29:01
Yes, here. The question is about in NXP secure boot, you have a possibility to use ROM in your bootloader to check the fiber block. So you can use the secure boot of NXP for more components
29:21
like fit and new boot and stuff. Do you know of any of those new or the chips you have analyzed other platforms have similar thing, but you can call the ROM and use it as a root for trust of everything. Okay, so the question was that the NXP provides the possibility to use the boot ROM to verify other parts of the firmware loaded
29:43
in the whole process. And the question is if other vendors also provide such things. From what we know, no, this is only like the NXP case. And yeah, basically that's the answer. And yeah, maybe this one. How is, given that you analyzed so many vendors,
30:03
how is the support among the vendors for different types of key with different trust boundaries? Like for example, like the delegation key for like some, like the production in Asia. Then you would remote that key using Robec levels and use cases like this. Okay, so the question was, I believe,
30:24
if we try to somehow, if there are any process to, in order to change the key used to find the firmware. Yes? Or? To have multiple keys, like you would hand out one key. Okay, to have like multiple keys to one person
30:42
and to another team, to another company, maybe even, and then later revoke it. I believe that this will be depends on if we have some mechanism in our socks to provide more than one public key, yeah. But as we said, those are one time only
31:03
flushed in the socks. So if there is only one place, then I think that it will be only one, the private key used later for the verification.
31:21
Okay? Thank you.