Introduction
Are you aware of the following:
-
What is the significance of automotive information security?
-
What is the main purpose of Secure Boot?
-
What are the conventional implementation solutions for Secure Boot?
In this article, we will explore and answer these questions together. For better understanding, here is the outline of the article:
▍Main Content
Before we explain Secure Boot, let’s first understand why automotive information security is necessary.
Why is Automotive Information Security Necessary?
With the continuous development of intelligent driving and smart cockpits, in-vehicle ECUs are becoming increasingly centralized and networked. ECUs can not only communicate directly via Ethernet but also communicate with the outside world through V2X technology, leading to tighter connections between vehicles and external entities, thus opening numerous channels for external communication with vehicles.
For instance, the commonly used OTA technology for vehicles poses a significant risk; if the software running in an ECU is suddenly tampered with or controlled by hackers during driving, it could greatly affect driving safety. As the technology for fully autonomous vehicles evolves from L3 to L4 and even L5, the role of human drivers will diminish, making the security of vehicle information crucial.
The essence of vehicle information security lies in ensuring that each intelligent control ECU performs relevant security confirmations and verifications during the startup phase to control risks in a timely manner. If checks are performed during runtime, it may lead to greater safety issues.
Therefore, in the field of automotive information security, implementing appropriate security checks at the startup phase of each intelligent ECU node, known as Secure Boot technology, is essential. This can effectively thwart various tampering attempts by hackers at an early stage, ensuring the safety of programs running in each ECU.
▍Overview of Secure Boot
Application Background
Code running on chips generally faces two major categories of information security attack risks:
-
Code being maliciously altered or attacked;
-
Code IP being illegally read or obtained;
For the first type of risk, we need to adopt some security mechanisms to ensure that the chip runs the user-specified program and prevent malicious tampering of the code; for the second type of risk, to prevent code theft, the original code must be encrypted for storage and decrypted during the chip startup process.
Since the aforementioned code encryption or startup code verification requires more CPU resources, relying solely on traditional CPUs may not efficiently complete these tasks. It is necessary to introduce dedicated hardware related to security encryption, such as HSM or HSE.
HSM or SHE modules essentially serve as hardware encryption and decryption engines, offloading these time-consuming tasks to specialized hardware modules, which can meet Secure Boot requirements while also improving program startup efficiency.
Generally, chips that support Secure Boot will have an OTP (one-time programmable) area, which works similarly to a fuse. After leaving the factory, all bits in this area are set to 1. If a bit is burned to 0, it is permanently cut off and cannot be changed back to 1, typically used to store user key information.
Some chips may implement OTP through certain control registers that control specific memory areas, ensuring that these control registers cannot be rewritten, thus indirectly achieving the characteristics of an OTP area.
Implementation Goals
Chips with security features like HSM, once integrated with Secure Boot functionality, will utilize user key information stored in the OTP area to perform multi-level security verification on the software to be loaded, thereby establishing a reliable security trust chain. Through this security boot trust chain, we can achieve the five key characteristics of software information security:
-
Authenticity: The software version has not been tampered with;
-
Integrity: The software version contains all content released by the developer without any changes;
-
Timeliness: The software version is valid within its effective period;
-
Non-repudiation: After the software is released, the publisher cannot deny ownership of the version;
-
Confidentiality: The software version is not disclosed to unauthorized individuals or entities and cannot be illegally stolen or read;
▍Summary of Cryptographic Methods Related to Secure Boot
Before discussing the implementation strategies of Secure Boot, it is necessary to understand the basic cryptographic methods related to Secure Boot to thoroughly grasp why these methods are employed for enhanced security.
Plaintext Code Encryption and Symmetric Encryption Algorithms
To protect software version IP and prevent malicious tampering of the code, it is essential to encrypt the software version, specifically the plaintext code.
AES, as a common symmetric encryption algorithm, has advantages such as wide application range, relative ease of concealment, and high throughput, making it suitable for code encryption.
A symmetric encryption algorithm uses the same key for both encryption and decryption. As shown in Figure 1, the code provider can encrypt the plaintext code using the AES algorithm to produce ciphertext, which is then burned into the corresponding storage chip. The secure chip HSM or HSE loads the encrypted code into memory during startup and uses the pre-burned key in the OTP area for code decryption. The entire decryption process utilizes the same key and the inverse algorithm of the same algorithm, thus restoring the ciphertext back to plaintext.
The significant advantage of AES symmetric encryption technology is its fast encryption and decryption speed, making it particularly suitable for large data volume encryption storage.
Information Digest and Hash Functions
A hash function, also known as a hash algorithm, is a method that creates a fixed-length digital fingerprint from a data set of arbitrary length. This digital fingerprint is referred to as an information digest, which will be uniformly referred to as such for ease of understanding.
The hash function employs hash transformations, which have the following two typical characteristics:
-
Irreversibility of the encryption process: This means that no one can deduce the plaintext from the information digest.
-
One-to-one correspondence: The input plaintext corresponds one-to-one with the information digest, and there will never be different plaintexts that produce the same information digest after hashing.
In Secure Boot, the SHA hash function is generally used to perform hash transformations to generate the final information digest, such as the commonly used SHA256, which generates a 4-byte (Hash Value) information digest for code integrity verification, as shown in Figure 2.
Trust Chain and Asymmetric Encryption Algorithms
Throughout the Secure Boot process, in addition to preventing accidental access to code IP, the most critical issue is to address a trust problem. The trust problem refers to ensuring that the software version loaded by the CPU is the version released by software publisher A, not an illegal version from someone else.
To resolve this trust issue, asymmetric encryption algorithms are required. An asymmetric encryption algorithm involves two keys: one public key and one private key. They form a pair; if the public key is used for encryption, only the corresponding private key can decrypt it, and vice versa.
Generally, the longer the key length, the more secure the algorithm. Asymmetric encryption algorithms, such as RSA, are typically used to address the aforementioned trust issues. RSA is a public, mathematically-based encryption algorithm that does not rely on any institution or individual and is difficult to crack, enabling digital signatures and authentication.
As shown in Figure 3-1, during the Secure Boot process, software publisher A can use the RSA private key to encrypt the information digest of the code, generating a digital signature. The chip can then use the corresponding public key to decrypt the digital signature, verifying the version’s authenticity. Once verified, it also ensures non-repudiation, as only software publisher A possesses the private key, as illustrated in Figure 3-2:
Public Key Information Exchange and Digital Certificates
In addition to addressing the trust issue of the software version itself, it is also necessary to ensure the security and confidentiality of the key information during transmission. This requires establishing a complete trust mechanism for key transmission.
A digital certificate is an authoritative document issued by a certificate authority (CA) that certifies a user’s public key, commonly referred to as a “root certificate.” A certificate generally contains the following aspects:
-
Information about the electronic signature authority;
-
Public key user information;
-
Public key;
-
Validity period and digital signature, etc.;
Generally, the format and verification method of the digital certificate must comply with the X.509 international standard.
▍Secure Boot Implementation Strategies
At this point, the cryptographic methods related to automotive information security Secure Boot have been introduced. You should now have a clearer understanding of why these cryptographic methods are used in Secure Boot. Next, we will focus on how Secure Boot utilizes the aforementioned cryptographic methods to achieve the following two aspects:
-
Secure Image Generation Process: This process mainly describes how cryptographic methods can generate legitimate software versions that can be correctly identified by the chip, preventing illegal software from being inadvertently started;
-
Secure Image Boot Process: This process mainly describes how to implement a multi-layer security verification mechanism for the software version using cryptographic methods;
The files that need to be verified during the entire secure boot version mainly include the following two parts:
-
X.509 format digital certificate or root certificate;
-
User software version;
Secure Image Generation Process
As shown in Figure 4, the entire secure image file generation includes the following basic steps:
S1: The user uses the AES encryption algorithm to convert the plaintext code into ciphertext, and the user also needs to pre-burn the AES key in the chip’s OTP area;
S2: The user must use the SHA256 hash function to perform a hash operation on the ciphertext code, ultimately obtaining the information digest of the software version ciphertext;
S3: The user must generate a digital certificate or root certificate file that complies with the X.509 international standard, which must include the information digest of the software version ciphertext and RSA public key information;
S4: The user must use the SHA256 hash function to perform a hash operation on the digital certificate, obtaining the information digest of the digital certificate, while the user uses the RSA private key to encrypt this information digest, ultimately obtaining the user’s digital signature.
Secure Image Boot Process
As shown in Figure 5, it provides a detailed illustration of the multi-level security verification mechanism in the secure boot process, ensuring the final software’s security, legality, and integrity.
S1: After the chip is reset and started, the hardware encryption module, such as HSM or HSE, first hashes the X.509 standard digital certificate public key information burned in Flash and compares it with the public key hash value pre-burned in the chip’s OTP area. If the results match, the legitimacy of the public key can be confirmed. This is the first and crucial link in the entire information security trust chain;
S2: After confirming the public key’s legitimacy, the hardware encryption module, such as HSM or HSE, uses the digital signature of the digital certificate for user legitimacy authentication. The specific operation steps involve decrypting the digital signature with the confirmed public key to obtain the certificate’s hash value, while re-hashing the certificate stored in the Flash chip and comparing the two hash values for consistency. If they match, authentication is successful, and legitimacy is ensured;
S3: The hardware encryption module, such as HSM or HSE, then recalculates the hash value of the software version stored in the Flash chip, i.e., the information digest, and compares it with the information digest of the digital certificate to confirm consistency. If they match, it indicates that the code has not been maliciously tampered with, ensuring the integrity and security of the user software version;
S4: Finally, the hardware encryption module, such as HSM or HSE, uses the AES key stored in the OTP area to decrypt the code, obtaining the plaintext code, which can then be loaded into the CPU for normal operation.
Note: If any of the above processes fail, subsequent verification will not proceed, and the boot will remain in the current state.
Due to the additional multi-layer security verification mechanisms in Secure Boot compared to traditional Boot, it undoubtedly increases the code startup time, which may delay the transmission of the first frame message. Therefore, it is necessary to balance and optimize. In specific project implementations, there may be slight variations from the above processes, with common differences including:
-
For example, if the public key information of the digital certificate has been successfully extracted on the host computer, there is no need for software to perform this, reducing startup time;
-
Some projects may consider omitting AES encryption and decryption measures for software code due to startup time concerns; this depends on the specific project requirements;
-
The Secure Boot processes used by different vendors may vary from the above processes, depending on each project. This article only provides general Secure Boot implementation strategies.
