Click the blue text aboveTalk Think Lab

Get more automotive cybersecurity information

01

Why Secure Boot is Necessary

Secure boot, also known as secure boot, is a technology that achieves trusted firmware loading by progressively verifying the boot image. The following is the basic boot process of an embedded system:

The process starts with the boot ROM, progressively booting through SPL and U-Boot to start the Linux operating system. Assuming that SPL, U-Boot, and the Linux image are all stored in flash, each bootloader needs to load the next boot image from flash during startup, as illustrated in the following flowchart:

If the above process does not execute secure boot, once the images in flash are replaced by a malicious attacker, the final system will run the tampered firmware. If the Linux and rootfs are replaced, the entire system will be under the control of the attacker after booting, rendering all security mechanisms built on the operating system ineffective.

In summary, for platforms that need to provide secure services, the basic requirement is that the system itself is trustworthy. Therefore, it is essential to ensure that all code from the first instruction executed at system startup to the completion of the operating system loading has undergone integrity and authenticity verification. Secure boot is designed to achieve this goal.

02

Implementation of Secure Boot

2.1 Trust Chain of Secure Boot

Since the operating system may require multiple levels of boot images, if any one of these images does not execute the secure boot process, all subsequent images are effectively untrustworthy. A typical example is as follows:

In the above example, the boot ROM verifies the SPL image. If SPL does not verify the U-Boot image, once the U-Boot image is replaced, the attacker can control all subsequent boot processes. For instance, the replaced U-Boot can load an illegal Linux image from another location, potentially implanting backdoors, etc.

Therefore, secure boot needs to establish a trust chain for secure boot, where each level of the image is verified for legitimacy by its preceding image. As long as the first-level image is legitimate, the legitimacy of the second-level image is guaranteed by the first-level image, and the legitimacy of the third-level image is guaranteed by the second-level image. This connects the entire boot process’s trust chain like a chain, ultimately ensuring that the entire system is trustworthy.

2.2 Trust Root of Secure Boot

Since the legitimacy of the images in the trust chain is verified by their preceding images, how is the legitimacy of the first-level image guaranteed? This leads us to the issue of the trust root. Since it cannot be endorsed by a preceding image, the problem that software cannot solve naturally requires hardware intervention.

We know that ROM is a type of read-only memory that can only be programmed once, and its content cannot be changed afterward. Therefore, if a ROM chip is integrated within the SoC and the first-level boot image is flashed onto this ROM during chip production, it ensures that it is trustworthy, which is a common practice in modern SoCs.

Since the SoC may support different boot methods, such as XIP booting directly from external NOR flash, after integrating the boot ROM image into ROM, it is also necessary to ensure that the chip must always start executing from the boot ROM; otherwise, an attacker could bypass the entire secure boot process through XIP. Generally, XIP boot mode is used during the debugging phase for problem localization, so it must be disabled before the product debugging is completed and secure boot is initiated. This can usually be achieved by setting a specific bit in OTP or EFUSE.

2.3 Image Verification

The trust chain of secure boot is achieved through progressive image verification, and a legitimate image should possess the following characteristics:

(1) The image is officially released, meaning it needs to verify the identity of the image publisher.

(2) The image has not been tampered with by anyone else, meaning the content of the image is intact.

The verification of these characteristics can be accomplished through specific cryptographic algorithms. For instance, data integrity can be verified using message digest algorithms, while the identity of the image publisher can be verified using asymmetric signature verification algorithms.

2.3.1 Introduction to Message Digest Algorithms

A message digest algorithm is a process that converts the content of a message into another fixed-length message using a one-way hash function, and the generated message is called a hash value, which has the following characteristics:

(1) Any length of input message will output a fixed-length hash value.

(2) The hash function must possess one-way properties, meaning the original message cannot be derived from the hash value.

(3) Different input messages will produce different output messages, indicating strong collision resistance.

(4) The computation speed of the hash value must be fast.

These characteristics make it suitable for verifying message integrity. Next, we will perform a simple deduction:

(1) If a message is tampered with, due to the strong collision resistance of the hash function, the computed hash value will differ from the hash value of the original content, making it easy to determine whether the message has been tampered with.

(2) Due to the one-way property of the hash value, it cannot be used to deduce the original message. Therefore, even if there theoretically exist different original messages with the same hash value, an attacker cannot deduce the original message from the hash value. This means that from a cryptographic perspective, the hash value and the original message are one-to-one correspondences.

(3) Since the output hash value has a fixed length and occupies a small amount of space (e.g., SHA-256 occupies 256 bits, while SHA-512 occupies 512 bits), attaching a hash value to other messages is completely acceptable in terms of storage space.

With the message digest algorithm, we can verify the integrity of the image, making it easy to identify tampered images.

In cryptography, there are various message digest algorithms, such as MD5, SHA-1, SHA-256, SHA-512, SHA-3, etc. With the advancement of computer technology, some algorithms previously considered to have strong collision resistance (such as MD5, SHA-1) are now deemed insecure. Therefore, secure boot generally uses SHA-256, SHA-512, and other algorithms as integrity algorithms.

2.3.2 Introduction to Asymmetric Algorithms

Asymmetric cryptographic algorithms are contrasted with symmetric cryptographic algorithms, where the same key is used for both encryption and decryption. In asymmetric algorithms, different keys are used for encryption and decryption, with the private key kept by the key owner and not disclosed, while the public key can be distributed to others. Data encrypted with the public key can only be decrypted with the private key, and data signed with the private key can only be verified with the public key.

In the secure boot process, the hash value of the image is signed with the private key and attached to the image file. Thus, during system startup, the image can be verified by checking the signature with the public key, as follows:

(1) Since only the key owner can access the private key, others cannot forge the signature.

(2) During public key verification, only data signed with the corresponding private key can be verified, while any forged data will fail verification. This ensures that only images signed by the private key owner can pass verification, thus confirming the identity of the image publisher.

2.3.3 Image Signing and Verification Process

From the above analysis, the basic process of image signing is as follows:

(1) Use the hash algorithm to generate the hash value of the image hash(image)

(2) Using the image publisher’s private key, perform the signing process on the image’s hash value using the asymmetric algorithm, generating the signature value sig(hash)

Finally, the image’s hash value, signature value, and the image itself are published. During chip startup, the following process can be used to verify the legitimacy of the image:

(1) Use the public key and signature value from the asymmetric algorithm to verify the image’s hash value. If the verification passes, further integrity checks can be performed. Otherwise, the startup fails.

(2) If the verification passes, recalculate the image’s hash value hash(image)’ and compare it with the original hash value hash(image). If they are equal, it indicates that the image integrity verification has passed. Otherwise, the startup fails.

2.4 Public Key Protection

Since the verification operation relies on the public key, if the public key on the device is replaced by an attacker, the attacker can forge the image signature using the corresponding private key. Therefore, it is essential to ensure that the public key on the device cannot be replaced. Generally, SoC chips contain several OTP or EFUSE spaces that can only be programmed once and cannot be modified afterward.

Thus, if the public key is stored in OTP or EFUSE, it can be effectively protected from modification. Since the OTP space is generally small, while the length of public keys like RSA is relatively long (e.g., RSA 2048 has a length of 2048 bits), to save OTP resources, only the hash value of the public key (e.g., the hash value of SHA-256 is 256 bits) is typically stored in OTP, while the public key itself is attached to the image.

Before using the public key, it is necessary to verify the integrity of the public key attached to the image using the hash value stored in OTP to ensure its legitimacy.

Source: Zhihu @lgjjeff

https://zhuanlan.zhihu.com/p/536007837

Talk Think AutoSec 10th Anniversary Conference

Discussion Group

The Talk Think 10th Anniversary Conference will deeply explore automotive cybersecurity technology, data security compliance challenges, and new challenges in intelligent connected vehicle security. Through practical case analysis, immersive technical demonstrations, and roundtable discussions, it aims to provide the industry with more systematic security solutions and more precise resource matching platforms.

Talk Think – Automotive Compliance for Overseas Markets (Europe)

Discussion Group

The Talk Think AutoSec Europe Summit aims to build an international professional platform that integrates global perspectives with Chinese practices, connecting cutting-edge technology with practical applications to help Chinese automotive companies address cybersecurity and data security compliance challenges during their overseas expansion. From discussions on cutting-edge technologies to compliance key points analysis and experience sharing, this platform will provide continuous support. The community has over 200 members and requires an invitation to join. If you wish to join, please add the community assistant on WeChat: taaslabs01.

Talk Think – SDV & AIDV Technology Overseas

Discussion Group

We sincerely invite industry colleagues to join the Talk Think SDV & AIDV overseas technology discussion group, focusing on core topics such as software-defined vehicles, AI-defined vehicles, next-generation EEA, intelligent cockpits, intelligent driving, software architecture, domain controller development, chip technology, software tools, etc. Everyone is welcome to join the group for discussions~~

end

Recommended Premium Events

AutoSec Series Salon

Professional Community

Some experts in the group come from:

New Force Car Companies:

Tesla, Hozon New Energy – Nezha, Li Auto, Zeekr, Xiaomi, Binnli Auto, Jiyue, Leap Motor, Avita, Zhi Ji Auto, Xiaopeng, Lantu Auto, NIO, Geely Auto, Seres……

Foreign Traditional Mainstream Car Companies:

Volkswagen China, Volkswagen Cool Wing, Audi, BMW, Ford, Daimler-Benz, General Motors, Porsche, Volvo, Hyundai, Nissan, Jaguar Land Rover, Scania……

Domestic Traditional Mainstream Car Companies:

Geely Auto, SAIC Passenger Cars, Great Wall Motors, SAIC Volkswagen, Changan Automobile, Beijing Automotive, Dongfeng Motor, GAC, BYD, FAW Group, FAW Liberation, Dongfeng Commercial, SAIC Commercial……

Global Leading Tier 1 Suppliers:

Bosch, Continental Group, United Automotive Electronics, Aptiv, ZF, KOSTAL, Schaeffler, Honeywell, DJI, Hitachi, Harman, Huawei, Baidu, Lenovo, MediaTek, Preh, Joyson, Wuhan Guangting, Xingji Meizu, CRRC Group, Wintech, Weichai Group, Horizon, Unisoc, ByteDance,……

Tier 2 Suppliers (500+):

Upstream, ETAS, BlackDuck, NXP, TUV, Shanghai Software Center, Deloitte, Qihoo 360, Weichan Xinan, Yunchi Future, Xinda Jiexin, Xinchangcheng, Zelu Security, Niuchuang Xinan, Fudan Microelectronics, Tianrongxin, Qihoo 360, China Automotive Center, China Automotive Research Institute, Shanghai Automotive Inspection, Gateron Microelectronics, Zhejiang University……

Personnel Proportion

Company Type Proportion

Articles

Don’t miss out, this could be the largest exclusive community in the automotive cybersecurity industry!

About the lawyer’s statement regarding the alleged imitation of the AutoSec conference brand

This article will help you understand the in-vehicle network communication security architecture of intelligent vehicles

Cybersecurity: TARA methods, tools, and cases

Key analysis of automotive data security compliance

Analysis of automotive chip information security regarding secure boot

Exploration of automotive in-vehicle communication security solutions in domain centralized architecture

System security architecture of vehicle network security architecture

Privacy protection issues in the Internet of Vehicles

Research on cybersecurity technology for intelligent connected vehicles

AUTOSAR information security framework and key technology analysis

What are the information security mechanisms in AUTOSAR?

Underlying mechanisms of information security

Automotive cybersecurity

Use of AUTOSAR hardware security modules (HSM)

First release! Lei Jun from Xiaomi made suggestions on automotive data security issues during the two sessions: Suggestions for building a complete automotive data security management system