[00:30.000 --> 00:36.000] Okay, so we'll start now. [00:36.000 --> 00:42.000] The topic of this presentation is overview of secure boot state in the arm-based socks [00:42.000 --> 00:47.000] and this is the second edition of this presentation. [00:47.000 --> 00:50.000] No mic here. [00:50.000 --> 00:55.000] It's only for the video. [00:55.000 --> 00:59.000] Okay, so the first edition was taken place like two years ago. [00:59.000 --> 01:07.000] So now we want to present some update from the research that we have done two years ago. [01:07.000 --> 01:09.000] Maybe you can speak up a little bit. [01:09.000 --> 01:11.000] Okay. [01:11.000 --> 01:15.000] Okay. [01:15.000 --> 01:21.000] Sorry for some... [01:21.000 --> 01:29.000] A little technical issue. [01:29.000 --> 01:37.000] Okay. [01:37.000 --> 01:45.000] Sorry for that. [01:45.000 --> 01:49.000] Okay. [01:49.000 --> 01:53.000] Okay, so it is an agenda for this presentation. [01:53.000 --> 02:01.000] So first, I will tell you who I am and where I work. [02:01.000 --> 02:07.000] So say a couple of words about our company. [02:07.000 --> 02:15.000] Next, I will just present shortly what do I mean by secure boot in the case of arm socks [02:15.000 --> 02:19.000] and present how the typical implementation and workflow works. [02:19.000 --> 02:27.000] Later, we will show the results from the first edition, so from the 2028. [02:27.000 --> 02:35.000] Then we will discuss the two cases that we check for this edition, [02:35.000 --> 02:39.000] so the Mediatek and the Rockchip cases. [02:39.000 --> 02:41.000] Next, we will summarize the whole presentation. [02:41.000 --> 02:47.000] So try to look what was different between those two editions of the presentation [02:47.000 --> 02:52.000] and with some Q&A session. [02:52.000 --> 02:55.000] So this is me. [02:55.000 --> 03:01.000] I'm Tomasz Gieski and I'm an Embedded Systems Team Leader at 3MDep. [03:01.000 --> 03:04.000] I work there over three years now. [03:04.000 --> 03:10.000] Mostly, I work on the Embedded Systems built with the Yoctop project. [03:10.000 --> 03:17.000] So I try to integrate the update system and the OS creation for the Embedded Devices. [03:17.000 --> 03:27.000] But because I work with the Embedded Devices, I try to touch different areas of the whole life of the devices. [03:27.000 --> 03:32.000] So one of the things I work with is also the system security. [03:32.000 --> 03:38.000] And this is the topic of this presentation. [03:38.000 --> 03:43.000] So here are a couple of words about our company. [03:43.000 --> 03:49.000] We are from Poland and based in Gdańsk. [03:49.000 --> 03:55.000] We are the core boot license service providers since 2016. [03:55.000 --> 03:59.000] Also, UFI adopters since 2018. [03:59.000 --> 04:05.000] Yoctop recipients, so this is the area which I work with. [04:05.000 --> 04:18.000] From the 2019, also like the consultants for the FWPD project and IBM Open Power Foundation members. [04:18.000 --> 04:26.000] Okay, so now let's explain first what do you mean by the secure boot in the context of this presentation. [04:26.000 --> 04:34.000] So here we are focused on the ARM context, which is like the feature of the boot room. [04:34.000 --> 04:38.000] One of the features that boot room has. [04:38.000 --> 04:49.000] Maybe we should call it more like the verified boot because the case here is that when we start the firmware, [04:49.000 --> 04:54.000] the next steps of the loaded images are like verified. [04:54.000 --> 05:02.000] The signatures is verified by the previous part of the firmware. [05:02.000 --> 05:08.000] So that's why we should call it the verified boot maybe. [05:08.000 --> 05:19.000] So we need to like use some private key to sign the binary that we put into our machine. [05:19.000 --> 05:26.000] Then we also need to take the public key from that private key and put it also there. [05:26.000 --> 05:34.000] So when we start it, we will be able to verify the signature and decide if it should be loaded or not. [05:34.000 --> 05:44.000] In ARM context, we assume that the boot room is our root of trust. [05:44.000 --> 05:49.000] We need to take that assumption because most of them are closed source. [05:49.000 --> 05:57.000] Probably it would be better if they would be open sourced, but it is what it is. [05:57.000 --> 06:02.000] And yeah, basically like the meaning of the secure boot can be different for any given architecture. [06:02.000 --> 06:11.000] So if you would be talking about the x86, that would be a different scenario. [06:11.000 --> 06:15.000] Okay, so this is the typical implementation. [06:15.000 --> 06:20.000] We have the public key that needs to be written inside our sock. [06:20.000 --> 06:28.000] Different vendors will have some different way to achieve that. [06:28.000 --> 06:32.000] So we can, for example, fuse them using electrical fuse. [06:32.000 --> 06:40.000] So one time write them in our sock and later use it every time that we start our firmware. [06:40.000 --> 06:44.000] There is also a possibility for the OTP registers. [06:44.000 --> 06:47.000] So those are the one time programmable. [06:47.000 --> 06:53.000] So as the name says also can be used only one time. [06:53.000 --> 07:04.000] And one of those two possibilities allow us to make from our boot room a root of trust, [07:04.000 --> 07:09.000] which we later use to expand it to the chain of trust. [07:09.000 --> 07:14.000] Next components can use like different keys. [07:14.000 --> 07:25.000] So in case of secure boot, we talk about the step between the boot room and the boot loader. [07:25.000 --> 07:32.000] And here we have some one key that was used to sign the binary and that public key that was used to verify it. [07:32.000 --> 07:38.000] But the later steps of starting our machine can use different keys. [07:39.000 --> 07:44.000] And yeah, so that would be it. [07:44.000 --> 07:49.000] So typically we have like let's say our host machine. [07:49.000 --> 07:52.000] That should be some secure location and our target device. [07:52.000 --> 07:56.000] So on our host machine we generate some private keys. [07:56.000 --> 08:01.000] We build binary and use specific tool to sign them. [08:01.000 --> 08:06.000] And later we need to take the public key part of that keys. [08:06.000 --> 08:13.000] Also design a binary and put it in the target device and then try to verify it. [08:13.000 --> 08:18.000] So if the verification will be successful, then we will just boot another step. [08:18.000 --> 08:28.000] If not, then specific things can happen depends on the vendor that we are using. [08:28.000 --> 08:35.000] Also let's say maybe a couple of words about what it is to sign the binary. [08:35.000 --> 08:44.000] Basically what is common between all the vendors probably is that the sign in binary means that we take the original binary [08:44.000 --> 08:48.000] and add some header on top of it. [08:48.000 --> 09:00.000] This header contains the signature of the digital signature and also some specific format at the start [09:00.000 --> 09:07.000] which can be different across some vendors or can be also different inside within one vendor [09:07.000 --> 09:11.000] but when we are using different signing tools. [09:11.000 --> 09:20.000] So if we try to like sign our binary we can always try to dump the first couple of bytes of our signed image [09:20.000 --> 09:26.000] and check if everything goes as expected. [09:27.000 --> 09:31.000] This is a quick recap from the last edition. [09:31.000 --> 09:35.000] So we look at the 11 cases. [09:35.000 --> 09:47.000] Five of them like the NXP, IMX and Liarscape, STSTM, Xilinix and NVIDIA looks like we're like fully open sourced let's say [09:47.000 --> 09:54.000] and there was none NDA problems with them so everyone could try to take the documentation [09:55.000 --> 10:02.000] needed using and signing tools and try to implement the secure boot on them. [10:02.000 --> 10:11.000] We have a couple of cases where there are information that there is some like secure boot to enable on that given machine [10:11.000 --> 10:13.000] but it is under the NDA. [10:13.000 --> 10:22.000] So we're talking here about the Marvel Armada, Texas Instruments, Sitara, Qualcomm and Microchips [10:22.000 --> 10:29.000] and also we talk about two stocks from the Chinese vendors like Rockchip and Allwinner [10:29.000 --> 10:36.000] where like documentation was, some documentation was there, another was missing. [10:36.000 --> 10:46.000] Also there were some information about tools but we were not able to find them or maybe use them correctly. [10:46.000 --> 10:54.000] Okay, so now I will go through three or five, three or four vendors that were listed from the last edition [10:54.000 --> 10:59.000] and talk about the differences that was between those two years. [10:59.000 --> 11:02.000] So now let's start from the NXP. [11:02.000 --> 11:13.000] In these cases like I think this is the easiest way to start with the secure boot on the ARM stocks [11:13.000 --> 11:16.000] because the full documentation is there. [11:16.000 --> 11:27.000] All documentation is probably like, all documentation is publicly available so everyone can use it. [11:28.000 --> 11:44.000] We have the HAP 4.4 so the high assurance boot mechanism on the platforms that are the NXP IMX50, 53, 67 and 8M. [11:44.000 --> 11:46.000] The application note is here. [11:46.000 --> 11:56.000] The only difference between here and there is that those applications are under the free registration to the site. [11:56.000 --> 12:06.000] The same is for the IMX8 and IMX8X which uses the HAP mechanism, so advanced high assurance boot. [12:06.000 --> 12:16.000] The same for CoreQ and as you see here the signing tool are available after the free registration. [12:16.000 --> 12:26.000] For Marvel Armada we can look at the manuals that are available on their sites. [12:26.000 --> 12:34.000] We saw that for the 38 and 39 X families we have some information that NDA is needed. [12:34.000 --> 12:43.000] For other families like I believe 8K there is only information that there is a secure boot available but nothing else there. [12:44.000 --> 12:55.000] 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 [12:55.000 --> 12:58.000] but now it is not there. [12:58.000 --> 13:02.000] It is only on the older releases. [13:02.000 --> 13:12.000] So this is another difficult step that needs to be taken to find those informations. [13:12.000 --> 13:24.000] But if you will just use this from the 2018 branch we will see the information how to implement the secure boot but still this is only the theoretical knowledge [13:24.000 --> 13:33.000] and there is no step-by-step solution how to achieve that so probably there is a room for mistakes. [13:34.000 --> 13:40.000] In Zidia Tegria another quick update. [13:40.000 --> 13:47.000] Last time we saw that there are some documentation and tools available. [13:47.000 --> 14:01.000] 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:01.000 --> 14:06.000] and they also provide the flashing tools, the script called flash sh. [14:06.000 --> 14:11.000] But in the other place they just say that the secure boot will be available in the future. [14:11.000 --> 14:20.000] Nobody exactly knows when the future will be but yeah that would be it. [14:20.000 --> 14:27.000] Also about fusing there is additional script for that but documentation of it is also some kind of updated. [14:28.000 --> 14:39.000] There is also one thread in the forum of Zidia where someone tried to use it to fuse keys on its platform and it caused the platform to break [14:39.000 --> 14:50.000] 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. [14:50.000 --> 14:53.000] Also update on Alwinner. [14:54.000 --> 15:07.000] Still we think that there is no official documentation about the Alwinner socks which would tell us about the secure boot and also no official documentation about the secure boot itself. [15:07.000 --> 15:15.000] But we found some interesting case on the forum where someone was able to use the Nano Pioneer with Alwinner H3. [15:16.000 --> 15:25.000] And he there provides like all the useful links like the 10 or 15 of them or also the whole list of the verification process. [15:27.000 --> 15:41.000] 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:42.000 --> 15:49.000] The one vulnerability there is that in any case when we. [15:51.000 --> 15:52.000] Oh sorry. [15:52.000 --> 16:01.000] One vulnerability is here that if we try to start our firmware which is signed and the verification fails. [16:01.000 --> 16:07.000] The platform always goes to the cell mode which is some kind like the Debug mode. [16:07.000 --> 16:13.000] And the Debug mode can be accessed via the USB port. [16:13.000 --> 16:26.000] So if the verification fails someone could always like plug in the USB start some me come and then read everything from the fuses or maybe even wipe them. [16:26.000 --> 16:34.000] So the solution there for that was just to destroy the USB lines data lines on that given port. [16:34.000 --> 16:43.000] So even if the platform goes into the cell mode no one will be able to just read anything from it. [16:43.000 --> 16:50.000] Okay so now the Mediatek case documentation is provided on the GitLab pages. [16:51.000 --> 17:05.000] 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 the signing to achieve the implementing the secure boot. [17:06.000 --> 17:20.000] But basically as in other ARM socks the boot room there is like the root of trust and later we just achieve it using other mechanism to have the whole chain of trust. [17:20.000 --> 17:29.000] So after secure boot we have the TFA trusted board boot and then you can use the U-boot feed wave side boot to load our kernel image. [17:29.000 --> 17:37.000] So if we have all those steps then we have like whole boot process verified. [17:38.000 --> 18:05.000] 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 then the boot room may just skip the process of verification of the image [18:05.000 --> 18:28.000] and still load the firmware so it looks like even if we like have the public key in the fuses and also the firmware signed, a public key in the fuses and we provide the unsigned image and like use this vulnerability we will be still able to boot our platform. [18:29.000 --> 18:54.000] 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 public key so this is the public key that we put in the fuses and calculates also the share of the signature of the BL2 so this is like the next step loaded. [18:54.000 --> 19:20.000] After that we compare those two values and if everything is okay we go next and then we load the signature from the BL2 and also calculate the share of it, make the comparison and if everything is once again is okay we boot the next steps. [19:24.000 --> 19:33.000] And here is the process of enabling the secure boot, it is not clear from the documentation on which socks the secure boot can be enabled. [19:33.000 --> 20:02.000] The documentation mentioned the MT-83-65 and MT-83-695 ones, different socks may have different fuses indexes so 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:03.000 --> 20:23.000] In the process of enabling the secure boot we need to create the 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 [20:23.000 --> 20:52.000] proprietary tools to flush the image inside our platform which is also described like here so we have the fuse writer tool, this is another tool provided with the NDA only which can be used to like check the secure boot state on our platform and check if the download agent authentication bits are set. [20:53.000 --> 21:12.000] If they are not set we just need to set them and then like provide the public key which will be fused on the key hash zero field and after that we will just sign our firmware and use this public key to verify it. [21:13.000 --> 21:18.000] Okay so now let's go to the Rockchip case. [21:19.000 --> 21:27.000] The public key here can be stored in a fuses in the OTP and it depends on which sock we are using. [21:28.000 --> 21:44.000] If the verification of loaded binary will be successful then we will just extend our rule of trust so the boot ROM as in the other ARM core socks to the chain of trust. [21:45.000 --> 22:00.000] And later in case of Rockchip you can use the verified boot mechanism, 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:01.000 --> 22:15.000] So basically to establish it we need to like once again generate some private and public keypire, burn the public key into the fuses or OTP registers, depends on which sock we are using. [22:16.000 --> 22:26.000] Then sign our firmware called id below the image in case of Rockchip which is like the U-boot TPL plus SPL merge into one file. [22:28.000 --> 22:39.000] 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:40.000 --> 23:00.000] Documentation for Rockchip and for our winner is like how to find and if we find any probably it will be outdated or really short or just not such useful at first. [23:01.000 --> 23:20.000] 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 will just need to skip the description of it. [23:21.000 --> 23:26.000] And now we can talk about signing code in Rockchip. [23:26.000 --> 23:35.000] So code can be signed using one of the two tools, the Erka sign tool which can be started on Linux or secure boot tool which can be started on Windows. [23:36.000 --> 23:39.000] Linux tools can be found on the Erka bin repository. [23:40.000 --> 23:52.000] Windows tools was a couple days ago, some time ago was on the repository called Kools tools but now we are not able to find it. [23:53.000 --> 24:04.000] For some reasons the Rockchip based repositories are maintained in such way that some things may be missing after some time. [24:06.000 --> 24:14.000] But if you use the Erka sign tool we can just generate the signing keys and those keys can be used later with the Linux or Windows tools. [24:15.000 --> 24:32.000] And if you use it and also the Erka repository provides the any files which are the files that can be used to create the mini-loader used later to fuse our keys in the firmware. [24:35.000 --> 24:42.000] And basically any given firmware that you want to sign and use in our socks can be also signed with those two tools. [24:45.000 --> 24:54.000] There is another tool just to burn the effuses and we have for that the effuse tool which is only for the Windows machines. [24:57.000 --> 25:09.000] It turns out that when we burn the effuses on the Rockchip socks we also need to provide the voltage for the one of the pins of the sock. [25:09.000 --> 25:30.000] So it is not visible here but there should be like VCC, E effuse pin which needs to be powered up when we want to fuse the keys in our sock. [25:31.000 --> 25:43.000] 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 just to enable that. [25:45.000 --> 25:49.000] Also this information comes from another documentation that is hard to find. [25:50.000 --> 25:53.000] This is a summarized of enable the secure boot. [25:54.000 --> 26:00.000] So we need to create loader using the boot manager script that is in the Erka bin repository. [26:01.000 --> 26:03.000] Next we create the keys with Erka sign tool. [26:04.000 --> 26:17.000] Next we need to sign the loader with secure boot tool because from what we know now only signed with that tool binaries can be later used on our socks. [26:17.000 --> 26:30.000] We try to sign with the Erka sign tool 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. [26:32.000 --> 26:46.000] Then we need to use the effuse tool to fuse our public key in socks and use another tool called the Erka develop tool which is in the Erka bin repository just to load the signer tool. [26:47.000 --> 26:53.000] So we need to put loader into our platform and secure boot enabled. [26:54.000 --> 27:04.000] Here is a link for the blog post which describes all of that containing all of that what we done with the Rockchip platforms. [27:05.000 --> 27:10.000] So this is the summarized of where we are after the second edition. [27:11.000 --> 27:22.000] The changes are here about the NXP platforms where it looks like we now need to register to get the socks reference documentation. [27:23.000 --> 27:32.000] The NVIDIA Tegra looks like the documentation is not really uncertain and may be outdated. [27:32.000 --> 27:38.000] The Rockchip one we know now that it can be achieved but still the documentation is not the best quality. [27:38.000 --> 27:47.000] The same with the Allwinner and for the MediaTek we see that NDA is needed to achieve the secure boot. [27:48.000 --> 27:55.000] So this is the summary of the presentation. Looks like our knowledge is expanded over the last two years. [27:55.000 --> 28:01.000] We for example know now how to enable the secure boot on the Rockchip. [28:01.000 --> 28:11.000] Still the general principles is common for all the vendors so we want to authenticate image before we load it. [28:12.000 --> 28:21.000] We have some private key to sign the firmware. We need to fuse the public key inside the sock and the boot room is still fit as the root of trust. [28:21.000 --> 28:38.000] 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. [28:39.000 --> 28:46.000] Here is the way of how you can contact us and thank you for that presentation. [28:53.000 --> 28:58.000] I think we are a little after time or maybe one question if there is any. [28:59.000 --> 29:01.000] Yes. [29:04.000 --> 29:17.000] The question is about in NXP secure boot you have a possibility to use ROM in your boot loader to check the fiber block. [29:17.000 --> 29:22.000] So you can use the secure boot of NXP for more components like fit and newborn and so on. [29:22.000 --> 29:33.000] 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. [29:33.000 --> 29:44.000] Okay so the question was that the NXP provides the possibility to use the boot ROM to verify other parts of the firmware loaded in the whole process. [29:45.000 --> 29:48.000] And the question is if other vendors also provide such things. [29:48.000 --> 29:57.000] From what we know now this is only like the NXP case and yeah basically that's the answer. [29:57.000 --> 29:59.000] And yeah maybe this one. [29:59.000 --> 30:08.000] How is given that you analyze so many vendors how is the support among the vendors for different types of key with different trust boundaries. [30:08.000 --> 30:14.000] Like for example like the delegation key for like some select like the production in Asia. [30:14.000 --> 30:20.000] Then you would remote that key using row back levels and use cases like this. [30:20.000 --> 30:35.000] Okay so the question was I believe if we try to somehow if there are any process to in order to change the key used to sign the firmware yes. [30:35.000 --> 30:39.000] To have multiple keys like you would hand out one key. [30:39.000 --> 30:46.000] Okay to have like multiple keys to one person and to another team to another company maybe even and then later revoke it. [30:47.000 --> 30:59.000] I believe that this will be depends on if we have some mechanism in our socks to provide more than one public key yeah. [30:59.000 --> 31:11.000] But as we said those are one time only 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:16.000 --> 31:23.000] Okay thank you.