Secure Boot on the i.MX6 – Part 1
With the proliferation of IoT – spanning just about everything from smart cities to hardware devices to wireless jewellery – the need to prioritise information security in secure embedded systems has never been greater.
The secure boot process is one of the foundation stones of software development best practice. It’s a complex, necessary part of your application program’s anti-malware fortress.
In this 3-part series, we’re taking an in-depth look at the secure boot protocol, and will also tell you our top tips for executing secure boot on one of the most popular processors in electronics – the i.MX6.
What is Secure Boot?
Secure boot is a process where your OS [Operating System] boot images and code are required to be authenticated against the hardware (a.k.a. boot device) before they are allowed to be used in the boot process. The hardware is set up beforehand in such a way that it only authenticates code generated by you or an authority above you in a chain of trust, such as with SSL.
You would use secure boot if you were anticipating that your system would become a target of people pushing malware. It would only boot into an operating system configured as you want it to be.
Secure Boot is necessary to establish the OS software you’re running is indeed the OS software that you want to run.
If you did not have secure boot enabled in your processor, someone could take your hardware and put another OS or other software program they want on it. This could be for a number of malicious purposes such as to make it fail, for data harvesting, reverse engineering your product to copy your design either in hardware or software.
Generally, secure boot is applicable in this sense for any single-use device, something that’s not intended to be a general-purpose computing unit would benefit [from secure boot] from a manufacturer’s point of view.
If you were building, say, an e-reader which is a popular use of the i.MX6 – for reasons including that some versions, such as the DualLite, have an integrated E-Ink display controller – you don’t tend to want general computing on an e-reader. It’s there to read e-books and related activities [example: making notes on e-books].
Booting into an environment where you have a locked-down Linux with everything fixed in place, i.e. your OS, your bootloader, their settings, etc. having all of that, would be where you want such a product.
Other situations, such as an Android phone, would be slightly different. You could still use secure boot, and you might still want to. Although, there are a lot of people who run Android who want to change the OS on their phones, using custom ROMs [ex. CyanogenMod].
Using Secure Boot would prevent that use case, unless you signed those images yourself for the sake of user choice.
But you can still use secure boot if you just wanted to keep the phone, or any other device with Android, locked-down. You might be running Android on, again, an e-book reader.
A good time to use secure boot is really any case where you don’t want another party to load an operating system or a different bootloader on to your device.
For more integrated systems, for example, IP cameras; if you have an IP camera running Linux, you very much don’t want that to gain any malicious boot code or operating system software. It could very easily lead to a situation where the feed from the camera is publicly uploaded onto the internet, or otherwise altered so that the feed does not contain the footage wanted by the owner.
Secure Boot: The Process on the i.MX6
On the i.MX6, once you have created your boot images, you would then generate a set of secure keys against an SSL certificate, generated for this purpose. This is signed against either another self-signed certificate or one from a certificate authority.
Then, these keys are used in the generation of a secure set of commands which are compiled and appended to the boot image using vendor (Freescale, now NXP) -supplied tools. Then the processor will take your first stage bootloader; authenticate the certificate data generated by the Secure Boot compilation tools, using your certificates.
If the key data in your boot image that’s written to your boot media matches the key data stored in the secure storage in the processor; the secure commands will be executed, which will then check a cryptographic hash of your images to make sure they match what the secure commands say they should be. If they do match, the processor will load and execute your boot image.
Once this process has passed through the CPU’s bootloader, you can still call into the secure boot library from your bootloader code. This allows you to load your operating system image and authenticate it in the same way that the CPU bootloader authenticates your software bootloader.
So at that point, you are in your OS, in a verified secure environment. You know that it’s legitimate because every stage has passed the test of being authenticated against the key hashes that are in the processor.
One-time Programmable
In terms of what makes this secure, you have your root keys which are generated from your SSL certificate. This is then hashed and that hash is burned into the CPU. This process is one-time programmable. Once that key has been burned into processor, it cannot be changed. That’s one of the reasons it’s secure.
Your boot images are then also signed against this key and the data generated from this signing process is combined with your image.
So, the processor checks your image key with its key, and if those match, it then checks the image against the key that was just matched with the processor. If that then matches, the image is executed. There will be code in that boot image that was just executed which performs these same steps to load the next image.
So, you go from the CPU bootloader to a normal bootloader to the operating system. Of course, this is i.MX6 specific. There are Secure Boots on other operating systems and platforms entirely, X86 being the most obvious one with UEFI (Unified Extensible Firmware Interface) secure boot. However, that’s outside the scope of the i.MX6.
In Part two of Secure Boot on the i.MX6, we’ll go into depth on leveraging the hardware and examine the pitfalls of the secure boot process.
And don’t forget – if you need support with Secure Boot on the i.MX6 or require any other embedded software help, get it touch! Our software experts are here to assist.
How can ByteSnap help you today?
From start-ups to blue chips, ByteSnap’s embedded systems developers are enabling companies to stay a step ahead by providing them with bespoke solutions. Maintain your competitive edge – contact us today and find out how we can optimise your product development!
