Network Computing is part of the Informa Tech Division of Informa PLC
This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC’s registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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.
Organizations are tacitly agreeing to accept greater risk by moving quickly without equal attention to security. The new normal we heard so much about throughout the pandemic is apparently “insecure by default.”
Zero Trust allows IT professionals to maintain a high level of security despite the extending boundaries of the network perimeter due to the increased use of cloud and remote work.
Implementing a zero-trust network architecture enables enterprises to box in a ransomware attack, limiting the extent to which a fraudster can commandeer data and resources.
Vulnerabilities in the life cycle of open-source software development can start from tiny crumbs but grow into substantial issues.
In today’s increasingly challenging cyber-attack landscape, overlooking any connected device’s security is a risk to your data and your company’s reputation.
Copyright © 2021 Informa PLC. Informa PLC is registered in England and Wales with company number 8860726 whose registered and head office is 5 Howick Place, London, SW1P 1WG.

source

You May Also Like

Threat Hunting: From Passive to Active Information Security

Threat hunting is a proactive process for locating cyber attackers in computing…

Ransomware Attacks: You Can’t Protect What You Can’t See

If your company hasn’t experienced a ransomware attack yet, brace yourself because…

Ukraine Fallout: Connectivity and Cloud Services Access in Flux

Just as a patchwork of international sanctions has tried to isolate Russia…

What the Dahua & Hikvision Controversy Means for Your Network Privacy

While Dahua and Hikvision products have been banned in the U.S. over…