Secure Boot Introduction – Part 1
Hi, I’m Phil Lapczynski, Principal Engineer for Automotive Security at Renesas. I’ve been on the security team at Renesas for 4 years, and before that, I worked in automotive security, OTA solutions, and bootloaders for over a decade. I’m happy to announce a series of blog articles introducing the concepts of secure boot and describing how they are achieved using our Renesas automotive MCUs and SoC devices. This blog article, part one in a three-part series, aims to give readers a basic understanding of what secure boot is and why it is needed. Look forward to more secure boot articles from colleague Satoshi Yamanaka-san and me soon.
1. A growing challenge
The modern automotive vehicle has increased exponentially in complexity since the introduction of microprocessors into vehicle architectures in the late 1960s. Initially introduced for electrically controlling fuel injection, vehicle computers now control every aspect of modern vehicles from heating seats to semi-autonomous driving. Today’s vehicles can be found with more than 100 car computers executing over 100 million lines of code. To put the complexity in perspective, 100 million is approaching the total number of DNA base pairs of small animals like mice, (humans have about 3,300 billion base pairs). Future autonomous vehicles will have over 300 million lines of code.
Figure 1 - http://www.informationisbeautiful.net/visualizations/million-lines-of-code/
With this increasing complexity, cybersecurity is an ongoing concern in car design. As more control of driving is given to computers, the impact of cybersecurity incidents is compounded. To make matters even more challenging, security architects need to balance privacy and security with functional security requirements. Imperative to the safety and security, code running in the vehicle must be authentic and unchanged. This is where secure boot comes in. Secure boot answers the questions “How do I know the software is authentic before executing?”, and “How do I know the software is unaltered before execution?”.
2. Secure boot bootcamp
Secure boot is a foundational first step in modern multi-layered embedded system security. Secure boot is a security mechanism by which software is verified for integrity and authenticity before execution. In other words, secure boot allows detection (and may disallow execution of) inauthentic or modified software when booting an embedded device. Secure boot reduces an attacker’s ability to gain persistence in a device.
On the most basic level, if the intended software is not what is expected, a defined set of sanctions are executed. Sanctions could include disallowing access to cryptographic keys or peripherals, resetting the CPU, or executing a fallback or device recovery program. While at the highest level this concept seems simple enough, there are many steps involved in ensuring secure boot works properly.
3. Building a root-of-trust
To perform secure boot, a “root-of-trust" is required. This essentially establishes the ground truth for all further steps and anchors the trust chain to something immutable. The “root-of-trust", sometimes referred to as a “trust anchor”, is rooted in an immutable part of the device hardware. While there are several methods for realizing this concept, there are generally two key traits in all of them: 1) The reset vector must be able to be securely controlled. 2) The code that the reset vector points to must be secure.
Common solutions for what to execute out of reset include the following:
- A fixed mask ROM that cannot be changed
- One-time programmable (OTP) code flash that has already been programmed and locked
- Executing software on a dedicated security core with protected memory as the boot core
The first block of code must execute the secure boot logic. Its goal is to prepare the system for the next boot stage and to verify it. This critical block of code must be heavily audited, and complexity kept to a minimum. As an immutable part of the system, any vulnerabilities or bugs in this section of code are often only repairable through complete replacement of the hardware.
4. Verify the software image
The next step in building a secure boot implementation is verifying the software image. There are typically two different methods utilized for checking authenticity and integrity in secure boot. The chosen method is based on the design requirements or factors such as boot up time.
4.1 Method 1: Secure boot verification using symmetric algorithms
One method of validating boot code is by using a keyed symmetric cryptographic algorithm called a Message Authentication Code. Benefits of this method are realized if the hardware device has accelerators for the used algorithms. Using a CMAC or HMAC algorithm can result in fast boot up times. The largest challenge with this solution is the storage of cryptographic keys and reference MACs. Private keys used for symmetric algorithms need to be stored securely inside a protected security environment like an HSM. Additionally, since the same key is used for MAC generation and MAC verification, the property of non-repudiation is not offered by default. To work around this shortcoming, keys can be configured to have MAC generation or verify-only properties enforced by the hardware.
4.2 Method 2: Secure boot verification using asymmetric algorithms
In this method, the code is verified using an asymmetric cryptographic algorithm (also known as public-key cryptography). Asymmetric algorithms are based on mathematical problems termed one-way functions. Two popular solutions are RSA and ECDSA. While the underlying mathematics and algorithms are different, both solutions rely on a public and private key pair.
FlippyFlink, CC BY-SA 4.0, via Wikimedia Commons
To validate an image, the image must be signed by a signing authority using the private key. This is done outside of the device. On the device, the secure boot code validates the image using the public key. Since the key is public and the private key cannot be easily derived from knowledge of the public key, privacy of the public key is not a requirement. While privacy of the public key is not needed for the security of the key, the system must still ensure the public key cannot be modified or replaced without authorization.
4.2.1 Signature generation
To generate a signature, a message digest (hash) is calculated from the input data. This is typically created in an enterprise setting outside of the embedded device. The signer encrypts the message digest with their private key. The encrypted digest is called the signature. The type of signature is dependent on the algorithm and padding scheme (such as RSA-PSS). The original image data and signature are programmed into the device.
4.2.2 Signature verification
Signature verification is the process of validating data against the code signature for integrity and authenticity. Verification involves calculating the message digest (hash) of the data and comparing it to the digest received in the decrypted signature.
5. Building a chain of trust
Several methods exist for building a chain of trust when doing secure boot. A chosen strategy is primarily driven by boot time requirements.
The simplest method of executing secure boot is a monolithic approach, where the entire image is verified by the first stage boot. While clean and simple, monolithic boot rarely works in real world situations due to boot time requirements. Often an embedded device needs to be up and performing its primary task within milliseconds of a power on reset. In these cases, a staged approach must be taken.
More advanced solutions allow parts of execution and verification to run in parallel. This is most common on multicore systems.
As image size and complexity increase, cryptographic hardware accelerators become necessary to meet timing requirements.
6. When the happy path isn’t so happy…sanctions
So far, we have only discussed the general flow when verification passes, but what happens if one of the stages fails verification? In this case, sanctions need to be applied. The system designer must decide what to do when a verification stage fails. Depending on the stage and other system requirements, one or more possible sanctions may happen:
- System reset
- Execute next stage with reduced privilege
- For instance, disallowing usage of cryptographic keys or certain peripherals
- Execute an alternate verified application
- Changing execution to a fallback or alternate application
- This case is especially useful in the case of a failed OTA or diagnostic update
- Staying in current boot stage
7. How to update software?
Okay, so we understand that secure boot will ensure that applications are authentic and unchanged, but how do we address the need to update the device with new (authentic) software? Software updates allow new features and allow remediation of bugs and security vulnerabilities. Critical is the ability to secure these updates. Every time new software is released, the new software must be resigned. The signing of released software needs to be part of the build / release process for production software development. Addressing the complexity and security of this process is nontrivial. We won’t get into software update security in this article, but there are projects like TUF and Uptane which focus directly on this topic. We plan to release an in-depth article on software updates in the future.
8. Conclusion
In summary…
- Secure boot is integral for creating a secure system of chain of trust.
- It provides:
- #1 - Authentication (unauthorized images not allowed to run)
- #2 - Integrity (‘tampered’ images shall be detected)
- It typically uses:
- Digital signatures
- Ensures authentication and integrity
- Private key -> used for signing
- Public key -> used to verify
- (Optionally) Image/data encryption
- Used for confidentiality
- Used for anti-cloning/counterfeit
- Digital signatures
- When validation fails, sanctions are applied
- Secure boot needs to coexist with the software update strategy
Remember that Renesas is your trusted partner in building secure embedded systems! Keep an eye out for part two in our secure boot series where Satoshi Yamanaka-san will introduce secure boot concepts on our RH850 MCU devices.
9. Glossary
| Glossary terms | |
|---|---|
| Bootloader | The first code that runs on an MCU or SoC after power up or reset and runs before any other software. Its job is to bring up the next stage of boot and commonly support features such as low level software update, and facilitate secure boot. |
| Root of trust | Source: NIST SP 800-172 Highly reliable hardware, firmware, and software components that perform specific, critical security functions. Because roots of trust are inherently trusted, they must be secure by design. Roots of trust provide a firm foundation from which to build security and trust. |
| RSA | Source: NIST SP 800-15 For the purposes of this specification, RSA is a public-key signature algorithm specified by PKCS #1. As a reversible public-key algorithm, it may also be used for encryption. |
| Secure boot | Process by with a computer uses digital signatures or MACs to validate authenticity and integrity of boot software before executing it. |
| Mask ROM | A type of read only memory where the addresses and data are physically encoded into the integrated circuit. While flash memory has largely replaced mask ROM for most applications, it is still common to employ mask ROM or OTP for initial boot of devices. |
| Secret key (symmetric) cryptographic algorithm | Source: NIST SP 800-175B Rev. 1 A cryptographic algorithm that uses the same secret key for an operation and its complement (e.g., encryption and decryption). The key is kept secret and is called either a secret key or symmetric key. |
| Public key (asymmetric) cryptography (PKC) | Source(s): NIST SP 800-12 Rev. 1 NIST SP 800-56B Rev. 2 Encryption system that uses a public-private key pair for encryption and/or digital signature. A form of cryptography that uses two related keys, a public key and a private key; the two keys have the property that, given the public key, it is computationally infeasible to derive the private key. For key establishment, public-key cryptography allows different parties to communicate securely without having prior access to a secret key that is shared, by using one or more pairs (public key and private key) of cryptographic keys. |
| Message Authentication Code (MAC) | Source: NIST SP 800-108 A family of cryptographic algorithms that is parameterized by a symmetric key. Each of the algorithms can act on input data of arbitrary length to produce an output value of a specified length (called the MAC of the input data). A MAC algorithm can be used to provide data origin authentication and data integrity. |
| CMAC | Source: NIST SP 800-108 Cipher-based Message Authentication Code (as specified in NIST SP 800-38B). |
| HMAC | Source: NIST SP 800-108 Keyed-hash Message Authentication Code (as specified in FIPS 198-1). |
| Hash function | Source: NIST SP 800-108 A function that maps a bit string of arbitrary length to a fixed length bit string. Approved hash functions are designed to satisfy the following properties:
|
| Digital signature | Source: NIST SP 800-12 Rev. 1 The result of a cryptographic transformation of data which, when properly implemented, provides the services of: 1. origin authentication, 2. data integrity, and 3. signer non-repudiation. |
| Non-repudiation | Source: NIST SP 800-18 Rev. 1 Assurance that the sender of information is provided with proof of delivery and the recipient is provided with proof of the sender’s identity, so neither can later deny having processed the information. |
| Padding (cryptography) | Source: https://en.wikipedia.org/wiki/Padding_(cryptography) Padding is any of a number of distinct practices which all include adding data to the beginning, middle, or end of a message prior to performing a cryptographic operation. |
10. Acronyms
| CMAC | Cipher-based MAC |
| ECDSA | Elliptic Curve Digital Signature Algorithm |
| HMAC | Hash-based MAC |
| HSM | Hardware Security Module |
| ICU | Intelligent Cryptographic Unit |
| MAC | Message Authentication Code |
| MCU | Microcontroller Unit |
| OTP | One-time Programmable |
| ROM | Read Only Memory |
| RSA | Rivest, Shamir, Adelman (algorithm) |
| SoC | System on Chip |
| TUF | The Update Framework |