Device Secure Boot
An IoTSF Secure Design Best Practice Guide Article
Security is based upon a framework of trust, where everything in the system ultimately agrees that some root point in the system can be trusted, providing a secure foundation upon which the rest of the system can be securely built. The greater the risks, or alternatively the greater the value of potential losses, so more assurance is needed that the root of trust is indeed trustworthy.
As an example, a major building contractor tasked to build a 25-storey tower block will want to ensure the foundations are indeed fit for purpose. So they engage a team who will use the correct building materials and construction techniques, and thereafter they know anything built on top won’t fail due to an underlying weakness.
The same approach holds true when securing IoT devices. To have a device run securely the boot process must be assured in the first place, and without that assurance up front anything else that operates on the device cannot be fully trusted.
For example, someone hacking into a device may find a way to replace an existing executable file with one containing malware. On a device without secure boot, the system might reboot at some point and run the malicious code, and the device is compromised. Thereafter, any function the device performs cannot be relied upon to be legitimate and trustworthy. However with a secure boot process in place, the checks at boot time should identify an unexpected file and initiate remedial actions.
How does a secure boot work?
Specific detail of how to design a secure boot solution is beyond the scope of this article, there are plenty of resources online to find out more, so the following just gives a flavour of how a secure boot process might work.
To boot securely a device must go through a series of steps to ensure the installation is as expected in order for the device to run correctly and securely. These steps could be along the lines of:
- Verify the initial bootloader executable is genuine and not been tampered with
- Run bootloader executable, which then…
- Checks the required sub-systems exist and function correctly. If OK then…
- Initiate basic logging
- Check for the existence of a new firmware update. If present, verify it is genuine, update the system to use the new firmware and the restart the system
- Verify all external services such as power supply, DNS, NTP etc. are operating correctly
- Verify the application code and run it if OK
The first stage, verifying that the bootloader is genuine and not been tampered with, is crucial. Only when this has been done can the rest of the boot process be assured. Verifying a bootloader executable file is usually done using public/private keys, more about which can be found in the IoTSF article on Encryption and online.
In essence, the manufacturer stores their private key very securely and never reveals it to anyone. When a device is manufactured, the public key associated with the private key is placed in secure storage on the device. The bootloader code is developed using a secure development process and then a cryptographic hash of it is digitally signed with the manufacturer’s private key. Whenever bootloader firmware is to be installed on the device, the hash signature is checked against the embedded public key on the device to confirm that it is a genuine hash value from that manufacturer. The firmware code is then hashed again and compared with the signed hash. If this matches (which indicates the firmware code hasn’t been altered), only then will the new firmware get installed.
Thereafter, whenever the device boots, the installed bootloader is again verified before being allowed to run. Cryptographic functions for these purposes and storage of keys can be provided by dedicated chips or modules such a Secure Access Modules (SAM) or Trusted Platform Modules (TPM).
The bootloader code knows which sub-systems to expect on the device so checks they exist and are functional. It can also check that there are no unexpected subsystems present.
If all is well then basic logging may begin, recording various start-up parameters and any issues found.
At some point the boot process may well need to check if there is an update to install, so will go away and verify new software as described before and possibly install and reboot, so the process starts again.
There may be other checks to ensure vital services are in place, possibly with security checks to ensure these services are indeed what they’re expected to be.
If everything has been checked successfully up to this point, then now may be the time to run the device’s functional applications. Again the signed application code can be verified against the embedded public key to ensure it is genuine. If that checks out OK then the applications can be started.
So every start-up stage is run only after the previous stage has been verified for authenticity and started successfully, with the whole process initiated by trusted bootloader code.
Caveats and Gotchas
One way to secure a boot process is to build the boot code and burn it into a write-once chipset on the manufacturing line. This will assure the code cannot be tampered with after the device is built, but it means any future changes cannot be made. Aside from any software bugs found in the future, if new security vulnerabilities are discovered over time then these cannot be patched and the device steadily becomes an increasing risk in the network.
Alternatively, as described earlier, keys (or other data) for verifying each boot stage can be locked into the chipset. But again should that key data ever be compromised then all devices with that key suddenly become ‘at risk’, unless there is also a way to securely update the key.
One other option could be to use external services to provide the verification, but this offers limited possibilities as it requires access to (hopefully) trusted external services at an early boot stage – this is rarely a genuinely secure and feasible solution…and what should happen if these services are not accessible?
Issues for Consumer Connected Products
Consumer products are often built to very tight cost margins and unfortunately security commonly loses out when trying to design into a budget. The important thing to do here is not just discard security features without regard for the possible consequences. Consider what the impact of a compromised device may have on the consumer or the network and look at possible alternative mitigations that may alleviate some of the risks via an alternative mechanism.
Insecure devices that are left in the network are a risk to others, especially if there are thousands or millions of them scattered far and wide. They could leak data or be hijacked and used for malicious purposes, denial of service attacks being a common example of this. Having a manufacture’s or retailer’s name become synonymous with insecure products is not a good place to be and can badly hit brand value.
Meeting tight price margins on a product is indeed a real issue, but arguably a greater issue is the impact on all sales for a brand name that’s fallen out of favour in the market.
So what questions do I need to ask to check if a secure boot process has been implemented?
Q1: Does the device have a secure boot process based on a trusted bootloader, which runs security checks at every stage of the boot sequence before executing the next stage?
Q2: Is the bootloader permanently installed such that it cannot ever be overwritten?
A2: Yes it cannot be overwritten (which may initially be ok but may become a risk over time)
Q3: If the bootloader firmware is replaceable, can it be replaced with any code or is it only possible to replace it with verifiable code using a secure replacement process?
A3: It can only be replaced by verifiable code using a secure process.
Q4: Does the device use dedicated security chips/modules offering cryptographic function and storage for critical data?
A4: Yes dedicated security chips/modules provide these functions.