A variety of published and unpublished security incidents in the last few years have driven the software industry to focus on the security of the boot process for microprocessors and embedded processors. Solutions to the problem of insecure boot processes vary enormously depending on two major inputs: whether the ‘secure boot’ solution is trying to protect the boot code itself from loss and reverse engineering, and what threat the ‘secure boot’ solution is trying to address.
The first question is whether a ‘secure boot’ solution is actually protecting the boot code of the embedded device or system. The most sophisticated antagonists who have access to your boot device or process will be able to access the code then use it for reverse-engineering purposes. This will allow the hacker to understand the system and its operation, giving them all the information they need to either clone the system, insert malware, or develop countermeasures or other ways to disable the system based on a system vulnerability or flaw. A secure boot solution that doesn’t protect the code itself offers no real security against the most determined attackers.
The next question to ask about a secure boot solution is what kind of threat it addresses (see similar article in Embedded Computing Design). This question is a little bit more complicated. Some solutions aim to prevent the substitution of altered boot code (‘unauthorized replacement’), which may introduce malware or security backdoors into a processor once it is initalized. Other solutions attempt to limit changeable parameters in the device as it loads, so that an antagonist cannot interrupt the boot process and substitute false commands or security backdoors into the device set-up.
Solutions to these kinds of attacks include digitally signed boot files, sometimes called ‘pre-boot authentication’. This is typically done by creating a digital signature within an ‘approved’ boot file, which is required to authorize initial boot. This is an important class of secure boot solution, and is as secure as the hashing algorithm and key used to create the digital signature. Another important solution in the processing market is the development of a ‘trusted boot loader’, which is a set of boot loading instructions and code that has been scrutinized and tested for unwanted behavior and insecure operation.
While it is a great step forward as an industry to see so much attention placed on secure boot capabilities, it is important to note that not all secure boot solutions are created equally — nor are they secure against every type of threat.
Digitally signed boot files provide an important first step in preventing some of the most widespread boot-loading attacks tracked on the internet. While some manufacturers call this capability ‘secure boot’ because of its increased resistance to repetitive attacks, it is still susceptible to attacks in the verification procedure if the verifying module is not integrated into the embedded processor. In addition, this kind of secure boot does absolutely nothing to protect proprietary and sensitive information embedded in the boot file itself.
Improving the trust and security levels of boot loaders is also an important step in industry security and awareness. However, this cannot in itself offer a ‘secure boot’ capability because of all of the other potential avenues of attack on the embedded boot process.
When CPU Tech talks about secure boot in embedded systems, it means a fully encrypted boot file with multiple levels of encryption, implemented by a security engineer within a controlled environment. This involves configuring the device so that it boots only from an encrypted file that can be matched to the secure processor through a unique hardware ID. This process protects the boot code and any proprietary information within, it manages the boot process through a dedicated internal security processor to prevent code tampering, and follows boot loader guidelines for secure operating systems to constrain unknown configuration states.
While there is ample reason to rejoice at the increasing number of security features available in military and secure processors, it is likewise prudent to maintain skepticism about manufacturer claims towards secure boot in embedded processing. Today’s open standards on Trusted Computing address important problems, but do not necessarily offer the highest levels of boot code security.