Vehicle Bootloader Authentication System

Abstract

A bootloader authentication system having a multimedia device, a memory device, and a processor to be installed in a vehicle. The memory device stores data indicating a public key associated with the vehicle and a signed hash bootloader image indicating a signature of a private key. The processor communicates with the memory device and is programmed to: generate a signature verification block based on a combination of a random number and the signed hash bootloader image; compare the signature verification block with the public key to verify the signature of the private key; authenticate the bootloader in response to verifying the signature of the private key; and activate the multimedia device in response to bootloader authentication.

Description

Technical Field

[0001] One or more embodiments relate to authenticating a vehicle embedded system bootloader. Background Art

[0002] Automotive embedded systems include controllers or control modules for controlling corresponding vehicle systems such as audio systems, powertrain systems, and navigation systems. Each controller includes a bootloader, and after the vehicle is started, the bootloader executes a boot process to load software into the main memory of the controller before the software can be executed. The bootloader can perform a secure boot process to authenticate the boot software in a secure manner within an expected time range to confirm that the boot software has not been compromised or "hacked". The secure boot process can include a large amount of calculations for verifying the authenticity of the boot software, which results in an increase in boot time delay and limits access to the vehicle system. For example, after starting the vehicle, the driver may notice a delay in the response from the audio system or the rearview camera due to the inefficient secure boot process performed by the corresponding system. Summary of the Invention

[0003] In one embodiment, a bootloader authentication system is provided with a multimedia device, a memory device, and a processor to be installed in a vehicle. The memory device stores data indicating a public key associated with the vehicle and a signed hash bootloader image indicating a signature of a private key. The processor communicates with the memory device and is programmed to: generate a signature verification block based on a combination of a random number and the signed hash bootloader image; compare the signature verification block with the public key to verify the signature of the private key; authenticate the bootloader in response to verifying the signature of the private key; and activate the multimedia device in response to bootloader authentication.

[0004] In another embodiment, a bootloader authentication system is provided with a multimedia device to be installed in a vehicle and a controller for controlling the multimedia device. The controller is configured to: generate a signature verification block based on a combination of a random number and a signed hash bootloader image indicating a signature of a private key; compare the signature verification block with a public key associated with the vehicle to verify the signature of the private key; authenticate the bootloader in response to verifying the signature of the private key; and activate the multimedia device in response to bootloader authentication.

[0005] In yet another embodiment, a method for authenticating an automotive embedded system bootloader is provided. An input indicating vehicle startup is received. In response to the input indicating vehicle startup, a random number is generated. Data is retrieved from a memory, the data indicating a public key associated with the vehicle and a signed hash bootloader image indicating a signature of a private key associated with a multimedia device adapted to be installed within the vehicle. Based on a combination of the random number and the signed hash bootloader image, a signature verification block is generated. The signature verification block is compared with the public key to verify the signature of the private key. In response to verifying the signature of the private key, the bootloader is authenticated. In response to bootloader authentication, the multimedia device is activated. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 A diagram of a vehicle including a digital cockpit according to one or more embodiments.

[0007] Figure 2 A flowchart of a method for authenticating Figure 1 the bootloader of a digital cockpit.

[0008] Figure 3 A diagram of the signature generation portion of the Figure 2 method.

[0009] Figure 4 A diagram of the signature verification portion of the Figure 2 method. DETAILED DESCRIPTION

[0010] As needed, detailed embodiments of the present disclosure are disclosed herein; however, it should be understood that the disclosed embodiments are merely examples of the present disclosure that may be implemented in various and alternative forms. The drawings are not necessarily to scale; some features may be enlarged or minimized to show details of particular components. Accordingly, the specific structural and functional details disclosed herein should not be construed as limiting, but rather as a representative basis.

[0011] Reference Figure 1, which shows a digital cockpit according to one or more embodiments and generally designated by reference numeral 100. The digital cockpit is a modular system that includes the functionality of one or more vehicle systems such as an audio system, an infotainment system, a dashboard, and an advanced driver assistance system (ADAS). The digital cockpit 100 is depicted within a vehicle 102. The digital cockpit 100 includes at least one multimedia device 104, such as a speaker, a camera, a sensor, or a display. The digital cockpit 100 also includes a controller 106. The controller 106 includes a microprocessor 108 and a memory 110 that stores and executes software for controlling the digital cockpit 100. The controller 106 utilizes an asymmetric encryption-based secure boot method that uses a public key to authenticate boot software data signed with a corresponding private key while minimizing any delay in activating the functionality of the multimedia device 104. Although the asymmetric encryption-based secure boot method is described with reference to the digital cockpit 100, the method can be implemented in any vehicle controller that performs a boot process.

[0012] According to one or more embodiments, the microprocessor 108 is a system-on-chip (SoC). An SoC is a small integrated circuit or "chip" that integrates all or most of the components of a computer, such as a central processing unit (CPU), memory, input / output ports, and auxiliary storage. The memory 110 includes random access memory (RAM, or main memory), read-only memory (ROM), and flash memory. The flash memory portion of the memory 110 may include an embedded multimedia controller (eMMC), which refers to a package consisting of both flash memory and a flash memory controller integrated on the same silicon die.

[0013] The controller 106 communicates with a plurality of other vehicle controllers or control modules via a vehicle network 112. For example, the vehicle 102 may include: a powertrain control module (PCM) 114, a body control module (BCM) 116, an electronic brake module (EBM) 118, and an image processing module (IPM) 120. The PCM 114 may receive a signal indicating the vehicle state (such as: "off", "accessory", "running", or "starting") and provide this signal to other controllers via the vehicle network. The IPM 120 monitors and controls imaging devices, such as a front-view camera configured for an autonomous driving system and / or a rear-view camera 122 for a rear-view camera system. In one or more embodiments, the digital cockpit 100 includes the IPM 120. The vehicle network 112 may include one or more channels for communication, such as a serial network protocol based on a controller area network (CAN), a local interconnect network (LIN) protocol, or a media-oriented system transport (MOST) protocol, and an Ethernet network defined by the Institute of Electrical and Electronics Engineers (IEEE) 802 series of standards.

[0014] Vehicle 102 also includes a control module that communicates with the internal control module via vehicle network 112 and communicates with external devices. For example, vehicle 102 includes an Auxiliary Protocol Interface Module (APIM) 124 that monitors and controls some external inputs to the vehicle network. For example, APIM 124 may include a Bluetooth communication interface for communicating with Bluetooth-enabled devices (e.g., mobile phones, tablets) and a USB interface for communicating with USB-enabled devices coupled to a Universal Serial Bus (USB) interface within the vehicle. APIM 124 may also include an SD card interface for exchanging data with an SD card inserted into the vehicle's Secure Digital (SD) interface. Vehicle 102 may also include a Telematics Control Unit (TCU) 126 that monitors and controls communication with a cellular voice and / or data network. TCU 126 may access media (e.g., movies and / or music) from a provider via a cloud-based network 128. In one or more embodiments, digital cockpit 100 includes APIM 124 and / or TCU 126.

[0015] Vehicle 102 includes a diagnostic port 130 that also facilitates external access to the vehicle control modules via vehicle network 112. Diagnostic port 130 may include a connector for receiving a mating connector of a scan device 132. A user may use scan device 132 to initiate communication with one or more of the vehicle controllers via vehicle network 112. If the user is authorized to access the control modules, the user may request information from the control modules, such as Diagnostic Trouble Codes (DTCs). The user may also provide information to the control modules, such as a new executable program or a new calibration value for an existing program, either of which may affect the operation of the controller and vehicle performance.

[0016] Such external communication with the vehicle control modules may allow access for malicious purposes. For example, a "hacker" with knowledge of the vehicle communication protocol may gain access to vehicle network 112 and affect vehicle performance. Additionally, once vehicle network 112 is accessed, information about the vehicle owner may be obtained. For example, an electronic module related to cellular communication may store a name and phone number. Additionally, a navigation module may store addresses, including the home address of the vehicle owner. In some cases, the electronic modules may be reprogrammed in an undesired manner. As a result, a "hacker" may compromise vehicle performance in an unexpected way without the vehicle owner's knowledge.

[0017] Each vehicle controller includes a microprocessor and a memory, and the microprocessor and the memory execute programs for controlling corresponding vehicle systems. For example, each controller includes an operating system (OS) and a bootloader. At startup, the bootloader locates the OS kernel, loads it into the memory, and performs the boot process. During the boot process, the authenticity of each stage of the software is verified and a trust chain is established. An unauthenticated / malicious bootloader may inject vulnerabilities into the system and create a backdoor. In addition, the bootloader may be used for unauthorized execution of on-board applications. Therefore, once the bootloader is infected, hackers can gain full control of the operation of the vehicle. The infected bootloader may exist throughout the life cycle of the embedded device because the bootloader is typically not affected during any firmware update.

[0018] Each vehicle controller periodically authenticates its boot software to confirm that the software has not been compromised or "hacked". For example, each controller can perform a secure boot process ("secure boot") to authenticate its boot software in response to receiving an ignition status signal of "run" or "start". During the secure boot process, the controller authenticates its OS boot image software against the hardware before being allowed to proceed with the actual boot process. The controller is pre-set in such a way that it only authenticates code generated using trusted security credentials.

[0019] The controller can limit or delay the functionality of the corresponding vehicle system while performing the secure boot process. For example, after starting vehicle 102, a user can immediately shift the transmission into reverse and view a display (not shown) in vehicle 102 and expect to see an image generated by the rearview backup camera system 122. However, the corresponding vehicle system (e.g., the image processing module (IPM) 120) may delay the generation of the image until the system has completed its secure boot process. Additionally, a current user can start vehicle 102, and an existing audio system (not shown) can immediately start playing audio selected during a previous driving cycle, e.g., a radio station at the volume setting when vehicle 102 was turned off. The current user may be different from the previous user who selected the radio station and volume setting, and the current user can immediately press the audio system power button to turn off the audio. However, the existing audio system controller may delay turning off the audio until the controller has completed its secure boot process, and such a delay may be inconvenient for the current user.

[0020] Reference Figure 2, shows a method for authenticating boot software according to one or more embodiments and referred to by reference numeral 200. Method 200 includes a signature generation step and a signature verification step, both of which relate to the fabrication and implementation of software code contained within the controller 106 of the digital cockpit 100. Figure 3 FIG. 300 showing the signature generation step of method 200, and Figure 4 FIG. 400 showing the signature verification step of method 200. Although method 200 is described using a flowchart showing multiple sequential steps, one or more steps may be omitted and / or performed in a different manner or simultaneously in one or more other embodiments. Additionally, although method 200 is described with reference to the digital cockpit 100, method 200 may be implemented in any vehicle controller that performs a boot process.

[0021] Figure 2 and Figure 3 show the signature generation phase of method 200. At step 202, the signature generation phase begins during the fabrication of the controller 106. At step 204, the bootloader image is divided into several blocks. As Figure 3 shown by the bootloader image 302 in n-1 ), the bootloader image may be divided into equal blocks (bl0, bl1, bl2…bl

[0022] At step 206, the hash of each block (BL) is calculated. The hashes (h0, h1, h2,…h n-1 ) 304 are as Figure 3 shown. According to one or more embodiments, an encryption algorithm may be used to calculate the hash of each block.

[0023] At step 208, each hash value is signed with a private key. Referring to Figure 3 , the private key 306 may be provided by the manufacturer of the vehicle 102 according to the public key infrastructure (PKI). PKI refers to a set of roles, policies, hardware, software, and processes for creating, managing, distributing, using, storing, and revoking digital certificates and managing public key encryption. At step 210, the public key is written to the one-time programmable (OTP) portion of the memory 110. OTP memory is a type of non-volatile memory (NVM) that only allows data to be written to the memory once. Once the memory has been programmed, it retains its value when power is removed (i.e., is non-volatile). Additional pairs of private and public keys may be created in steps 208 and 210 to provide backup keys in case either key is compromised. For example, in one embodiment, each hash value may be signed with four different private keys, and four paired public keys may be written to the OTP memory to provide three sets of backup keys. Referring to Figure 3, the given private key 306 is paired with the corresponding public key without disclosing the private key. At block 308, each hash value is used to sign the private key 306 to form a signature block 310.

[0024] At step 212, the signed value is added to the bootloader image block. Refer to Figure 3 , each block of the bootloader image 302 can be appended to the corresponding signed value of the signature block 310 at block 312 to form a signed hash bootloader image 314.

[0025] At step 214, the image containing the signed block (i.e., the signed hash bootloader image 314) is stored in the memory 110. In one or more embodiments, the image containing the signed block is flashed into the embedded multimedia controller (eMMC) portion of the memory 110.

[0026] For the signature generation phase of method 200, i.e., steps 202 to 214, the pseudocode can be represented as follows:

[0027] 1. Bootloader image BL = {bl0, bl1, bl2,... bl n-1}

[0028] 2. Hash h = H(bl)

[0029] h0 = H(bl0)

[0030] h1 = H(bl1)

[0031] h2 = H(bl2)

[0032] h n-1 = H(bl n-1 )

[0033] 3. Digital signature μ = signature algorithm(h, K priv )

[0034] 4. Output bl′ = assemble([μ0, bl0], [μ1, bl1],... [μ n-1 , bl n-1 )

[0035] Figure 2 and Figure 4Illustrates the signature verification phase of method 200 in response to vehicle startup. At step 216, the controller 106 determines a random number using a true random number generator (TRNG). A TRNG is a device (i.e., hardware) that generates random numbers from physical processes (e.g., statistically random "noise" signals). At step 218, the controller 106 extracts the signed data from the memory 110, i.e., the signed hash bootloader image 314. At step 220, the controller 106 determines a signature verification block based on the random number and the signed hash bootloader image 314. Refer to Figure 4 , at system boot, the controller 106 executes a secure boot process (BOOTROM), determines the TRNG 402, and at 404 combines the TRNG 402 with the signed hash bootloader image 314 to determine a single signature verification block 406.

[0036] At step 222, the controller 106 retrieves the paired public key from the memory 110. As indicated in step 210, the paired public key can be electrically fused (e-fused) into the one-time programmable (OTP) section of the memory 110 during the manufacture of the controller 106. At step 224, the controller 106 compares the single signature verification block with the public key to verify the signature. If the signature is verified, the controller 106 proceeds to step 226 and authenticates the boot software and allows the corresponding system (e.g., the digital cockpit 100) to operate. Refer to Figure 4 , at block 410, the controller 106 compares the signature verification block 406 with the public key 408 to verify the signature. If the signature is verified, the controller 106 authenticates the boot software 412.

[0037] If the signature is not verified, the controller 106 proceeds to step 228 and issues an alert or a fault, and / or restricts the functionality of the corresponding system. After steps 226 and 228, the controller 106 proceeds to step 230 and ends the boot process.

[0038] The pseudocode for steps 214 to 230 can be represented as follows:

[0039] / / Infinite loop

[0040] 1. Load the bootloader image bl′ = ([μ0, bl0], [μ1, bl1],... [μ n-1 , bl n-1

[0041] 2. Random x = rand() % n

[0042] 3. Signed block b = bl′[x]

[0043] 4. Authentication result = signature verification(b, K​pub )

[0044] Thus, the digital cockpit 100 utilizes a secure boot method 200 based on asymmetric encryption, which uses a public key to authenticate boot software data signed with a corresponding private key while minimizing any latency in the functionality of the digital cockpit 100. The authentication method 200 quickly guarantees the authenticity of the boot software. During boot, the secure boot software authenticates the boot software using a signature verification process performed on only a portion of the boot software data (i.e., a single signature verification block) rather than the complete data, thereby improving the efficiency of the secure boot process. For example, the total number of blocks is defined by the vendor of the microprocessor 108 and can be 16, 32, 64, 128, 256, 512, 1024, 2048, etc. In one embodiment, the total number of blocks is 64 and the image size is from 1 MB to 10 MB. Analyzing all 64 blocks using an existing secure boot process may take time (t), but by analyzing a single signature verification block 406 instead of all 64, the digital cockpit 100 can perform the signature verification portion of method 200 in half the time (i.e., t / 2). The signature verification block is randomly determined using a true random number generator, which provides a high level of security during the boot process. By ensuring better security with less hardware computing power, the digital cockpit 100 can reduce its startup latency time while using less complex hardware components within the controller 106 to reduce costs.

[0045] Although the exemplary embodiments are described above, these embodiments are not intended to describe all possible forms of the present disclosure. On the contrary, the words used in the specification are descriptive rather than restrictive words, and it should be understood that various changes can be made without departing from the spirit and scope of the present disclosure. Additionally, the features of various embodiments can be combined to form additional embodiments.

Claims

1. A bootloader authentication system, the bootloader authentication system comprising: A multimedia device to be installed in a vehicle; A memory device storing data, the data indicating a public key associated with the vehicle and a signed hash bootloader image indicating a signature of a private key, wherein the signed hash bootloader image includes a plurality of bootloader image blocks and a plurality of encrypted hash values; A processor communicating with the memory device, the processor being programmed to: Determine a random number using a random number generator; Determine a signature verification block using a plurality of bootloader image blocks of the random number; Compare the signature verification block with the public key to verify the signature of the private key; Authenticate the bootloader in response to verifying the signature of the private key; And Activate the multimedia device in response to bootloader authentication.

2. The bootloader authentication system according to claim 1, wherein the signature verification block includes a single signature verification block.

3. The bootloader authentication system according to claim 1, wherein each bootloader image block is appended to a corresponding encrypted hash value.

4. The bootloader authentication system according to claim 3, wherein the plurality of encrypted hash values are based on the plurality of bootloader image blocks and a signed value associated with the signature of the private key.

5. The bootloader authentication system according to claim 1, wherein the multimedia device includes at least one of a speaker, a camera, a sensor, and a display.

6. The bootloader authentication system according to claim 1, wherein the public key is paired with the private key.

7. The bootloader authentication system according to claim 1, wherein the memory device includes a non-volatile memory and a flash memory, and wherein the non-volatile memory stores the data indicating the public key, and wherein the flash memory stores the data indicating the signed hash bootloader image, the signed hash bootloader image indicating the signature of the private key.

8. The bootloader authentication system according to claim 1, wherein the processor is further programmed to generate the signature verification block in response to vehicle startup.

9. A bootloader authentication system, the bootloader authentication system comprising: A multimedia device to be installed in a vehicle; A controller for controlling the multimedia device, the controller being configured to: Determine a random number using a random number generator; Generate a signature verification block based on a combination of the random number and a signed hash bootloader image indicating a signature of a private key, wherein the signed hash bootloader image includes a plurality of bootloader image blocks and a plurality of encrypted hash values, and the signature verification block is one of the plurality of bootloader image blocks; Compare the signature verification block with a public key associated with the vehicle to verify the signature of the private key; Authenticate the bootloader in response to verifying the signature of the private key; And Activate the multimedia device in response to bootloader authentication.

10. The bootloader authentication system according to claim 9, wherein the signature verification block comprises a single signature verification block, and wherein the controller is further configured to: generate the single signature verification block based on a combination of the random number and a single signed hash bootloader image block.

11. The bootloader authentication system according to claim 9, wherein each bootloader image block is appended with a corresponding encrypted hash value.

12. The bootloader authentication system according to claim 11, wherein the plurality of encrypted hash values are based on the plurality of bootloader image blocks and a signed value associated with the signature of the private key.

13. The bootloader authentication system according to claim 9, wherein the public key is paired with the private key.

14. The bootloader authentication system according to claim 9, wherein the multimedia device comprises at least one of a speaker, a camera, a sensor, and a display.

15. The bootloader authentication system according to claim 9, wherein the controller comprises a processor and a memory device, and wherein the memory device comprises: non-volatile memory for storing data indicative of the public key; and flash memory for storing data indicative of the signed hash bootloader image, the signed hash bootloader image indicative of the signature of the private key.

16. A method for authenticating an automotive embedded system bootloader, the method comprising: receiving an input indicative of a vehicle startup; generating a random number in response to the input; retrieving data from a memory, the data indicative of a public key associated with the vehicle and a signed hash bootloader image indicative of a signature of a private key associated with a multimedia device adapted to be installed in the vehicle, wherein the signed hash bootloader image comprises a plurality of bootloader image blocks and a plurality of encrypted hash values; generating a signature verification block based on a combination of the random number and the signed hash bootloader image; comparing the signature verification block with the public key to verify the signature of the private key; authenticating the bootloader in response to verifying the signature of the private key; and activating the multimedia device in response to bootloader authentication.

17. The method according to claim 16, wherein the signature verification block comprises a single signature verification block, and the method further comprises: Generate the single signature verification block based on a combination of the random number and a single signed hash bootloader image block.

18. The method according to claim 16, further comprising appending each bootloader image block with a corresponding encrypted hash value.

19. The method according to claim 16, further comprising: Generate the random number by a physical process based on a statistically random noise signal.

20. The method according to claim 16, further comprising pairing the public key with the private key.

Images