Secure Boot on the i.MX6 – Part 2
With embedded systems safety such a hot topic right now, we’re looking at the secure boot on the i.MX6 – one of electronics’ most popular processors.
Part one was really an introduction to the secure boot process, examining it in detail.
Here, in the second instalment of our 3-part series, we cover managing the hardware, the pitfalls of the secure boot process, and authentication.
Secure Boot on the i.MX6 – Leveraging the Hardware
It’s a suite of hardware – you have secure storage, you have one-time storage, you have hardware-accelerated cryptography.
Algorithms can be hardware-accelerated which combine to make a speedy and secure boot process.
Part of it is the one-time fuses – these are specifically fuses. Once they’re blown, they cannot be unblown. And there are fuses which you can blow which prevent other fuses from being blown. Therefore, once you’ve burned your key, you can then say that “This key is now burned, don’t allow any other fuses to be burned for the key.” Your key hash is then permanent.
Multiple keys can be combined into one key hash as well, so you can revoke a key if it has been compromised.
In addition, the i.MX6 has a hardware cryptographic algorithm accelerator. There exists algorithms such as AES hashing, Triple DES hashing, SHA1, SHA256 and so on. These types of algorithms can be accelerated by the processor. So, the boot process can remain speedy because cryptographic security is often slow in the general sense.
Another function of this is the CPU internal boot loader, a static piece of code which has also been security tested. So, using secure boot, you can establish a chain of security up to the operating system level.
The Pitfalls
The most obvious pitfall is you are responsible for your system’s safety and private keys. If your keys leak out into the world, then someone can sign that code against the key that’s in the processor anyway. You need to keep your process secure in addition to the hardware.
The whole process must be done properly. A processor configured to only boot securely will not boot unless it has an image that is signed properly. So, if you improperly burn your hash into the processor, it may result in a processor that can no longer run code as the burnt-in hash does not match the generated hash the code is signed against. In other words, this might result in a processor that is no longer usable.
Once you’ve told the processor to be secure, there is no way of loading unsecured code to it. It will only allow you to safely load from storage, such as SD or NAND flash, or other modes of loading software into the processor (USB image loading).
Therefore, the process must be kept secured, the steps for preparing your hardware and the processor must be kept secure. You must also ensure that your bootloader are prepared for this as well.
As previously mentioned, your bootloader must call into the secure library on the processor in order to authenticate the next stage in the boot chain. If you have not properly coded your bootloader for the proper use of the secure library, then you may not fully ensure that your operating is secure.
Now, having completed the secure boot process for the i.MX6, what you gain is a much smaller surface for attackers, be it malware or IP theft.
What you end up with, with regards to security, is you only have to make sure that the OS and supporting software is free of bugs and attack vectors.
An attacker cannot load their own boot code or OS. So they must work within the confines of the system as posted. That’s the point of Secure Boot.
Don’t Be Lulled Into a False Sense of Security
To be clear, secure boot doesn’t lock the entire system down, only the OS software that’s on there. So you’re guaranteed a bootloader with an OS environment, but you still have your chosen bootloader and OS.
Although you know what Linux you are booting into, the Secure Boot process doesn’t stop someone running any valid Linux program if you are booting into Linux. For instance, someone might write some Linux malware. If they could load it, Secure Boot does not necessitate your file system is covered by this.
Authentication
It is possible to authenticate parts of the file system. The Secure Boot process on the iMX6 works on chunks of memory. So, if you were to load your file system into a fixed point in memory, along with the correct set of secure commands, you could authenticate it there and be sure that you’re running a verified file system.
However, it is likely that it would be a very slow process. You might still want to do it if you wanted to ensure full security.
In general, the file system will be left unauthenticated. So someone could in theory still load malware onto the device and execute it. But they would have to work within the operating system as it is as opposed to loading a less secure operating system or a bootloader which loads malware into the operating system.
In the third and final part of Secure Boot on the iMX6, we’ll have some top tips to help get you through the process as smoothly as possible.
This series is designed to signpost you through this demanding process; if you need support for any of your embedded software development requirements, get it touch with our experienced software team.
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!
