A Look Inside Modern Design Principles for Secure Boot in CPU Hardware

Secure boot capabilities have been around for almost two decades in commodity parts. These capabilities are meant to provide users or owners with confidence that a device has booted up securely and with approved firmware authorized by the original manufacturer. When not successful, it can lead to booting unauthorized software that violates the security and integrity of the entire system (like what was seen with the flaw in GRUB2 Linux bootloader last year).

The primary assurances of a secure boot sequence center around cryptographic operations meant to protect the integrity of the boot code, the provenance of the boot code, and potentially its confidentiality. The concept of secure boot often includes a significant number of intricacies that can be difficult for product teams to both understand and account for in their designs. To shed some light on this process (and the technologies involved), let’s look at some of the most significant design principles that teams should consider (in no particular order) and what the industry considers the current best practices.

Global keys should be avoided whenever possible, instead relying upon unique-per-device keys.

The term global key (GKEY) refers to a key value that’s common across all devices of a specific set, such as a product family. Global keys are typically used as an initial Key-Encryption-Key to protect the next key in the key hierarchy through a process known as key wrapping. Although there is convenience afforded with the use of a GKEY, these keys typically represent a significant risk for a break-once, run-everywhere (BORE) attack. Such keys become a prime target for attackers of all levels as it’s recognized that identification of this value can have significant potential impact on perhaps an entire family of devices. At a minimum, vendors should look to use a key split to store GKEYs across multiple storage mediums.

Anchor keys should be stored across multiple locations and/or technologies.

Anchor keys are extremely high value as they represent the starting point for any chain-of-trust or key hierarchy. They also represent one of the greatest challenges because they cannot be encrypted while as rest since they are the very first key used. Although they’re not required to be a GKEY, embedding the keys into logic has been the traditional approach to provide the best obfuscation of the key. However, supply chain risks and advances in imaging and reverse engineering attacks have made it substantially more difficult to ensure confidentiality of these keys. To minimize these threats, keys should be split on the system or not stored at all and instead regenerated during power-on using a physically unclonable function (PUF) or a hash-based key derivation function.

List the storage options from the most restrictive to the least and use the most restrictive that satisfies the requirements of the product.

Due to the function provided by cryptographic keys as part of the secure boot process, it is critical that they are stored appropriately. The option selected for storage can have numerous implications, such as confidentiality, ease of access, ability to update or revoke, and uniqueness. If the key being stored is encrypted or otherwise cryptographically protected from confidentiality concerns, any storage medium is acceptable provided it meets all other security requirements. The use of an approved PUF is currently the best option, but an HMAC-based Key Derivation Function that utilizes material from multiple storage sources (like key splits) is considered the next best solution.

Symmetric keys and asymmetric private keys need to be confidentiality and integrity protected, while asymmetric public keys usually only need to be integrity protected.

When accessing the keys that will be used as part of a secure boot solution, it is imperative to identify the characteristic of the key to determine storage requirements. First, teams need to determine the confidentiality requirement for every key, as the integrity requirement should be assumed. Second, any symmetric key at the anchor of the chain-of-trust needs to have very special protections Keys used as part of a secure boot process, especially those with confidentiality requirements, should only be indirectly accessible. This is most frequently done by tying the keys directly to a cryptographic engine or storing them in a memory element directly accessible only by a cryptographic engine.

Order of operation matters in cryptography, so when doing encryption and signing, they should be performed in that order.

A significant amount of debate has occurred over the years relating to the order of operation for encryption and signing. The result has been a split between the sign-then-encrypt and encrypt-then-sign options. However, sign-then-encrypt allows cryptanalyst to create known cipher-text attacks against the symmetric encryption algorithm as the image is not validated prior to decryption operations. To mitigate this, all implementors should leverage encrypt-then-sign for all firmware images used as part of a secure boot implementation.

Design crypto-based solutions using defense-in-depth approaches rather than relying on single mitigations.

When creating defense-in-depth solutions using cryptography, this usually means both encrypting and signing your firmware and software. For years, too many solutions have relied upon signed images only to ensure trusted images are executed. That said, signing all possible firmware is still considered an industry best practice and should always be performed. However, the consequence of only signing is that many systems are broken because a vulnerability has been discovered in the authentication routine that allows attackers to bypass it. Without encryption as a secondary deterrent, attackers may have free reign on the platforms.

Minimize exposure and accessibility to cryptographic keys to the smallest time windows possible.

Best security practices for accessing cryptographic keys use only indirectly accessible keys where the key is retained only in hardware and accessed only by firmware/software using an index or handle that represents the desired key. Such implementations rely on cryptographic accelerators in hardware to perform the operations, with the key value being fed into the accelerator from some form of memory. Whenever possible and wherever feasible, this approach is considered the best from a security perspective.

Signing keys need to have a revocation method that is robust and does not rely upon a potentially compromised key.

The revocation of signing keys is a mechanism put in place to allow for the de-authorization of a previously authorized key for the signing of firmware or software images. Unfortunately, revocation is not an automatic or instantaneous process. The recommended practice is to assign one specific key as the revocation key and not allow this key to be used for any standard signing operations. Further, revocation operations should require the use of multiple keys to prevent a single compromised key from revoking all other non-compromised keys.

Separate keys are needed to support the generation of debug images versus production images.

Most products generate a combination of both production and debug images. The debug images often contain enhanced permissions or accessibility features that provide developers greater introspection capability to support their debug efforts. These debug images then become much more powerful, and thus much more attractive, for potential attackers in comparison to the standard production images. As such, best practices suggest that the images should not be protected using the same cryptographic keys as their compromise has drastically different potential impacts.

Secure Boot support is enabled by default and requires OEM or user intervention to de-activate.

Secure boot features are typically customizable and capable of being turned on or off by the OEM. The question then arises of which mode should be the default. The general guidelines effectively breakdown based upon two fundamental questions: 1) it is a general-purpose product or custom product for a specific customer, and 2) what portion of the firmware is provided by the manufacturer and when does it execute? There is no concrete answer to which approach should be used, but the decision is typically made by the OEM that utilizes the processing element.

To learn more about the secure boot process and industry initiatives, check out resources on OpenTitan, Microsoft, and the Open Mobile Terminal Platform.   

Matt Areno is Principal Engineer, Security Architecture and Engineering at Intel.