Zoned system for a vehicle

Abstract

A computer-implemented method causes a data processing hardware to perform operations when executed by the data processing hardware. The operations include providing a common encryption key and a unique encryption key at a system on a chip (SoC) of a radar module, providing a unique key pair at the SoC, the unique key pair including a unique public key and a unique private key, and encrypting software with the common encryption key. The operations further include generating a secure boot certificate for the encrypted software, signing the secure boot certificate using the unique private key, and writing the encrypted software to an external flash memory. The operations further include updating the software at the SoC, verifying the software update via a regional public key, and signing the secure boot certificate with a device unique private key via a hardware security module (HSM) of the SoC.

Description

[0001] introduction

[0002] The information provided in this section is for the purpose of presenting the general context of this disclosure. The work of the currently attributed inventors, to the extent described in this section, and aspects of the description that might not otherwise be considered prior art at the time of filing, are neither expressly nor implicitly acknowledged as prior art to this disclosure. Technical Field

[0003] This disclosure generally relates to a method for regionalizing an automotive controller that enables safe starting, and more specifically, to a regionalization system for an automotive electronic control unit (ECU) of a vehicle. Background Technology

[0004] Modern vehicles have witnessed rapid technological advancements in the number of electronic devices and related software incorporated within them. For example, Electronic Control Units (ECUs) serve as embedded systems within vehicles, controlling various electromechanical systems. However, there is a need to support multiple Public Key Infrastructure (PKI) systems in automotive ECUs for vehicles to be sold both domestically and internationally. Specifically, improved cryptographic key protection is required for vehicles sold in foreign regions but manufactured domestically. Summary of the Invention

[0005] In some aspects, the computer-implemented method causes the data processing hardware to perform operations when executed by the data processing hardware. These operations include providing a common encryption key and a unique encryption key at the system-on-chip (SoC) of the radar module, providing a unique key pair at the SoC, the unique key pair including a unique public key and a unique private key, and encrypting software with the common encryption key. The operations also include generating a secure boot certificate for the encrypted software, signing the secure boot certificate using the unique private key, and writing the encrypted software to external flash memory. The operations further include updating the software at the SoC, verifying the software update via a regional public key, and signing the secure boot certificate via the SoC's hardware security module (HSM) using the device's unique private key.

[0006] In some examples, providing a unique key pair may include hashing a unique public key at a fuse on the SoC, storing the hash of the unique public key in the fuse, and encrypting a unique private key with a unique encryption key. Optionally, the external flash memory may include flash bootloader software that includes a default region public key. Operation may also include verifying the region public key and region credentials of the flash bootloader software via a diagnostic routine having the default region public key. The operation may also include verifying a regionization record using the default region public key via the flash bootloader of the SoC and the HSM of the SoC. In some instances, the operation may include storing the default region public key and region credentials in the external flash memory in response to the verified regionization record, performing a diagnostic routine at the SoC including verifying the region public key of the external flash memory, and providing the SoC with a region credential corresponding to the default region public key of the external flash memory. The operation may also include receiving a software update at the flash bootloader of the SoC and verifying the software update via the HSM using the region public key from the external flash memory.

[0007] In other aspects, a regionalization system for a radar module in a vehicle includes data processing hardware and memory hardware communicating with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. These operations include providing a common encryption key and a unique encryption key at a system-on-a-chip (SoC) of the radar module; providing a unique key pair at the SoC, the unique key pair including a unique public key and a unique private key; encrypting software with the common encryption key; and generating a secure boot certificate for the encrypted software. The operations also include signing the secure boot certificate using the unique private key; writing the encrypted software to external flash memory; executing diagnostic routines at the SoC, including verifying the regional root public key of the external flash memory; and providing the regional credentials and the regional root public key to the SoC.

[0008] In some examples, providing a unique key pair may include hashing a unique public key at a fuse on the SoC, storing the hash of the unique public key in the fuse, and encrypting the unique private key using a unique encryption key before storing the unique private key in external flash memory. Optionally, the external flash memory may include flash bootloader software that includes a default regional public key. Operation may also include verifying the regional public key and regional credentials, as well as the default credentials of the flash bootloader software, via a diagnostic routine having the default regional public key. The operation may also include verifying a regionalization record using the default regional public key via the flash bootloader of the SoC and the hardware security module (HSM) of the SoC. In some instances, the operation may include storing the regional public key and the regional credentials in the external flash memory in response to the verified regionalization record, performing a diagnostic routine at the SoC that includes verifying the regional public key of the external flash memory, and providing the SoC with a regional credential corresponding to the regional public key of the external flash memory. The operation may also include receiving software updates at the SoC's flash bootloader and verifying the software updates via the HSM using a regional public key from external flash memory.

[0009] In another aspect, a regionalization system for a vehicle includes data processing hardware and memory hardware communicating with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. These operations include providing a common encryption key and a unique encryption key at a system-on-a-chip (SoC) of a radar module, providing a unique key pair at the SoC, the unique key pair including a unique public key and a unique private key, encrypting software with the common encryption key, and generating a secure boot certificate for the encrypted software. The operations also include signing the secure boot certificate using the unique private key, writing the encrypted software to external flash memory, and executing diagnostic routines at the SoC, including verifying a default regional public key from the external flash memory. The operations further include verifying a regionalization record using the default regional public key and regional credentials from the external flash memory via the SoC's flash bootloader and the SoC's hardware security module (HSM), providing the regional credentials and the default regional public key to the SoC, and storing the provided regional credentials in response to the verified regionalization record.

[0010] In some examples, providing a unique key pair may include hashing a unique public key at a fuse on the SoC, storing the hash of the unique public key in the fuse, and encrypting a unique private key with a unique encryption key. Optionally, the external flash memory may include flash bootloader software that includes a default regional public key. Operation may also include verifying the regional public key and regional credentials of the flash bootloader software via a diagnostic routine having the regional public key. The operation may also include storing the provided regional credentials in response to the verified regional record. In some cases, operation may include receiving a software update at the flash bootloader on the SoC and verifying the software update via the HSM using the default regional public key from the external flash memory. Attached Figure Description

[0011] The accompanying drawings described herein are for illustrative purposes only for the selected configurations and are not intended to limit the scope of this disclosure.

[0012] Figure 1 This is a schematic diagram of a vehicle equipped with a radar module according to this disclosure;

[0013] Figure 2 This is an exemplary block diagram of a regionalized system for a radar module according to the present disclosure;

[0014] Figure 3 This is another exemplary block diagram of a regionalized system according to the present disclosure, the regionalized system including a system-on-a-chip (SoC) and external flash memory;

[0015] Figure 4 This is another exemplary block diagram of a regionalized system according to the present disclosure, which configures the SoC and external flash memory;

[0016] Figures 5 to 9 An exemplary startup process for a regionalized system according to this disclosure is shown;

[0017] Figure 10 and Figure 11 An exemplary software update for a regionalized system according to this disclosure is shown; and

[0018] Figure 12 An exemplary method for performing a regionalized system according to this disclosure is shown.

[0019] Throughout the accompanying drawings, corresponding reference numerals indicate the corresponding parts. Detailed Implementation

[0020] The example configuration will now be described more fully with reference to the accompanying drawings. The example configuration is provided so that this disclosure will be thorough and will fully communicate the scope of this disclosure to those skilled in the art. Specific details, such as examples of specific components, devices, and methods, are set forth to provide a thorough understanding of the configuration of this disclosure. It will be apparent to those skilled in the art that the specific details are not required, the example configuration can be implemented in many different forms, and the specific details and example configuration should not be construed as limiting the scope of this disclosure.

[0021] The terminology used herein is for the purpose of describing a particular exemplary configuration only and is not intended to be restrictive. As used herein, the singular articles “a,” “an,” and “the” may be intended to include plural forms as well, unless the context clearly indicates otherwise. The terms “comprises,” “comprising,” “including,” and “having” are inclusive and therefore specify the presence of features, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof. Unless specifically identified as an order of execution, the method steps, processes, and operations described herein should not be construed as requiring them to be performed in the specific order discussed or shown. Additional or alternative steps may be employed.

[0022] When an element or layer is referred to as being “on,” “joined to,” “connected to,” “attached to,” or “linked to” another element or layer, it may be directly on, joined to, connected to, attached to, or linked to the other element or layer, or there may be intermediate elements or layers present. Conversely, when an element is referred to as being “directly on,” “directly joined to,” “directly connected to,” “directly attached to,” or “directly linked to” another element or layer, there may be no intermediate elements or layers present. Other terms used to describe relationships between elements should be interpreted in a similar manner (e.g., “between” vs. “directly between,” “adjacent” vs. “directly adjacent,” etc.). As used herein, the term “and / or” includes any and all combinations of one or more of the associated listed items.

[0023] The terms “first,” “second,” “third,” etc., may be used herein to describe various elements, components, regions, layers, and / or sections. These elements, components, regions, layers, and / or sections should not be limited by these terms. These terms may be used only to distinguish one element, component, region, layer, or section from another. Unless the context clearly indicates otherwise, terms such as “first,” “second,” and other numerical terms do not imply order or sequence. Therefore, without departing from the teachings of the example configuration, the first element, component, region, layer, or section discussed below may be referred to as the second element, component, region, layer, or section.

[0024] In this application, including the following definitions, the term "module" may be replaced by the term "circuit". The term "module" may refer to, be a part of, or include: application-specific integrated circuits (ASICs); digital, analog, or mixed-signal analog / digital discrete circuits; digital, analog, or mixed-signal analog / digital integrated circuits; combinational logic circuits; field-programmable gate arrays (FPGAs); processors (shared, dedicated, or grouped) that execute code; memory (shared, dedicated, or grouped) that stores code executed by the processor; other suitable hardware components that provide the described functionality; or combinations of some or all of the foregoing, such as in a system-on-a-chip.

[0025] The term "code" as used above can include software, firmware, and / or microcode, and can refer to programs, routines, functions, classes, and / or objects. The term "shared processor" covers a single processor that executes some or all of the code from multiple modules. The term "group processor" covers a processor that, in combination with additional processors, executes some or all of the code from one or more modules. The term "shared memory" covers a single memory that stores some or all of the code from multiple modules. The term "group memory" covers memory that, in combination with additional memory, stores some or all of the code from one or more modules. The term "memory" can be a subset of the term "computer-readable medium." The term "computer-readable medium" does not cover transient electrical and electromagnetic signals propagating through a medium, and therefore can be considered tangible and non-transitory memory. Non-limiting examples of non-transitory memory include tangible computer-readable media, which include non-volatile memory, magnetic memory, and optical memory.

[0026] The apparatus and methods described in this application can be implemented, in part or in whole, by one or more computer programs executed by one or more processors. The computer program includes processor-executable instructions stored on at least one non-transitory tangible computer-readable medium. The computer program may also include and / or depend on stored data.

[0027] A software application (i.e., a software resource) can refer to computer software that enables a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and game applications.

[0028] Non-transitory memory can be a physical device used to temporarily or permanently store programs (e.g., instruction sequences) or data (e.g., program state information) for use by a computing device. Non-transitory memory can be volatile and / or non-volatile addressable semiconductor memory. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electrically erasable programmable read-only memory (EEPROM) (e.g., commonly used in firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase-change memory (PCM), and magnetic disks or magnetic tapes.

[0029] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages ​​and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0030] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuits, integrated circuits, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementations in one or more computer programs executable and / or interpretable on a programmable system, which includes at least one programmable processor, which may be dedicated or general-purpose, coupled to receive data and instructions from a storage system, at least one input device, and at least one output device, and to transmit data and instructions to the storage system, at least one input device, and at least one output device.

[0031] The processes and logic described in this specification can be executed by one or more programmable processors (also known as data processing hardware) that execute one or more computer programs to perform functions by manipulating input data and generating output. The processes and logic can also be executed by special-purpose logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). Processors suitable for executing computer programs include, for example, both general-purpose microprocessors and special-purpose microprocessors, as well as any one or more processors of any kind of digital computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or operatively coupled to receive data from or transfer data to one or more mass storage devices, or both. However, a computer does not need to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0032] To provide interaction with a user, one or more aspects of this disclosure can be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touchscreen, and optionally a keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, voice, or tactile input. Furthermore, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a web page to a web browser on the user's client device in response to a request received from a web browser.

[0033] refer to Figure 1-4The regionalization system 10 is configured as part of the radar module 100 for vehicle 102. The radar module 100 is manufactured and configured separately from vehicle 102 and is installed for use with various operations of vehicle 102. Therefore, the regionalization system 10 of radar module 100 is configured to communicate with other vehicle modules 104 during operation of vehicle 102. The radar module 100 is configured to detect objects near or around vehicle 102 during operation and provide radar data 106 to the other vehicle modules 104. Each radar module 100 is configured to communicate with one of the domestic data center 200 and the foreign server 300. For example, the regionalization system 10 is configured with a flexible security key architecture 12, which is configured to allow communication between one of the domestic data center 200 or the foreign server 300, as described in more detail below. For simplicity, a single foreign server 300 is described. However, it is contemplated that multiple servers 300 may be used as part of the regionalization system 10.

[0034] The radar module 100 also includes a system-on-a-chip (SoC) 14 configured with data processing hardware 16 and memory hardware 18. The data processing hardware 16 is configured to perform a flexible security key architecture 12 and operations associated with the regionalization system 10. The memory hardware 18 is configured as temporary memory, such that data stored on the memory hardware 18 can be erased when the regionalization system 10 is reset. The memory hardware 18 communicates with the data processing hardware 16 and stores instructions that, when executed by the data processing hardware 16, cause the data processing hardware 16 to perform the operations described herein.

[0035] Radar module 100 also includes external flash memory 20 communicatively coupled to SoC 14. External flash memory 20 includes a default regional public key 22 stored in flash bootloader (FBL) software 26. A regional credential 24 is provided to external flash memory 20, as described in more detail below. FBL software 26 contains the default regional public key 22, which SoC 14 uses to verify the regional credential 24. The regional public key 22 and regional credential 24 inform radar module 100 which of the domestic data center 200 and the foreign server 300 it is configured to communicate with. Radar module 100 is thus configured to receive communication only from either the domestic data center 200 or the foreign server 300, verified by the regional key 22 and regional credential 24.

[0036] See further Figure 1-4The SoC 14 also includes an application kernel 28 (described in more detail below) and is provided with a public encryption key 30, a unique encryption key 32, and a device-unique key pair 34. The public encryption key 30 may be generated within the SoC 14 and / or provided to the SoC 14 from external flash memory 20. The public encryption key 30 is used to encrypt software 36. For example, software 36 may include, but is not limited to, application software 36a, secure bootloader software 36b, and hardware security module (HSM) software 36c. In some examples, software 36 may also include FBL software 26. The regionalization system 10 may also periodically receive software updates 38 verified using the regional public key 22, as described in more detail below.

[0037] A common encryption key 30 and a unique encryption key 32 may be set in fuse 40 of SoC 14. A unique key pair 34 is provided by external flash memory 20 and includes a device-unique private key 34a and a device-unique public key 34b. The hash of the unique public key 34b is stored in fuse 40 of SoC 14. As a result, a public key hash 42 is stored in fuse 40. The unique private key 34a is encrypted with the unique encryption key 32 and stored in external flash memory 20. External flash memory 20 also includes a secure boot certificate 72 generated for software 36, as described below. The secure boot certificate 72 is signed by the unique private key 34a and written to external flash memory 20 for storage.

[0038] SoC 14 also includes a secure bootloader 46 configured to execute diagnostic routines 48 of SoC 14. Diagnostic routines 48 are configured to ensure that a common encryption key 30, a unique encryption key 32, and a unique key pair 34 are correctly provided to SoC 14. For example, diagnostic routines 48 may include using the regional public key 22 of external flash memory 20 to verify a regional credential 24 of the flash bootloader (FBL) software 26. SoC 14 also receives the regional credential 24 from external flash memory 20, which corresponds to the regional public key 22 of external flash memory 20. The regional credential 24 is used by SoC 14 during operation of radar module 100 to support securely configuring radar module 100 for use with either domestic data center 200 or foreign server 300.

[0039] Still referencing Figure 1-4The SoC 14 also includes Flash Bootloader (FBL) software 26 and Hardware Security Module (HSM) 52 loaded into the application kernel 28. The FBL software 26 and HSM 52 are configured to verify a regional record 54 using a default regional public key 56 and a default credential 58 from the FBL software 26. The regional record 54 includes a region-specific root public key 54a, which is compared with the default regional public key 56 to verify the authenticity of software updates provided via diagnostic routine 48.

[0040] FBL software 26 coordinates with HSM 52 to verify the regionalization record 54 using the default regional public key 56 and default credential 58 provided during the manufacturing of the regionalization system 10 of radar module 100. If the regionalization record 54 is verified, SoC 14 stores the provided regional root public key 54a as regional public key 22 in external flash memory 20. SoC 14 protects the regionalization record 54 from potential tampering by generating a Message Authentication Code (MAC) 60 with a device-specific key 62. MAC 60 is stored on external flash memory 20 along with regional public key 22.

[0041] See now Figure 5-9SoC 14 includes a Memory Protection Unit (MPU) 64 configured as part of Application Core 28. MPU 64 can only be configured by HSM 52 of SoC 14. The Master Bootloader (PBL) 66 of Application Core 28 is configured to load an encrypted Secondary Bootloader (SBL) 68 from external flash memory 20 into the temporary random access memory 70 of SoC 14. PBL 66 loads secure boot certificates 72, 72a with the encrypted Secondary Bootloader 68. One or more secure boot certificates 72 may exist, each containing one or more message digests 74. For example, PBL 66 requests HSM code 52a of HSM 52 to verify the Secondary Bootloader (SBL) secure boot certificate 72a of the encrypted Secondary Bootloader 68. In doing so, HSM code 52a verifies that the hash of the unique public key 34b matches the public key hash 42 (i.e., a valid signature), and then uses the unique public key 34b to verify the signature of the secure boot certificate 72. HSM code 52a also verifies the SBL message digest 74a of the encrypted secondary bootloader 68 within the signed secure boot certificate 72. HSM 52a also configures MPU 64 to prevent modification of temporary random access memory 70 before calculating message digest 74. If everything is successfully verified, PBL 66 requests HSM code 52a to decrypt the encrypted secondary bootloader 68 using public encryption key 30. Once the encrypted secondary bootloader 68 is decrypted, PBL 66 requests HSM code 52a to load the secondary bootloader 68 into application random access memory (RAM) 36a, and PBL 66 jumps to the secondary bootloader 68.

[0042] The secondary bootloader (SBL) code 68a is run by the application kernel 28 and loads the encrypted HSM software 36c from external flash memory 20 into temporary random access memory 70. The secondary bootloader 68 is configured to request HSM ROM code 52a to verify the HSM secure boot certificate 72b of the encrypted HSM software 36c. In doing so, HSM ROM code 52a verifies that the hash of the unique public key 34b matches the public key hash 42 (i.e., a valid signature), and then uses the unique public key 34b to verify the signature of the secure boot certificate 72b. HSM ROM code 52a also verifies the HSM message digest 74b of the encrypted HSM software 36c within the signed secure boot certificate 72b. HSM 52 also configures MPU 64 to prevent modification of the temporary random access memory 70 before calculating the message digest 74b. If everything is successfully verified, then the secondary bootloader 68 is also configured to request HSM ROM code 52a to decrypt the encrypted HSM software 36c using the common encryption key 30. HSM ROM code 52a can then load the decrypted HSM software 36c into HSM 52. HSM ROM code 52a is configured to jump to HSM software 36c. HSM ROM code 52a provides a verified unique public key 34b, which HSM 52 uses to verify the secure boot certificate 72. A secondary bootloader 68 provides HSM data 52b from external flash memory 20 to HSM software 36c.

[0043] Further reference Figure 5-9HSM software 36c is configured to configure MPU 64 to restrict write access to HSM 52. For example, HSM 52 is allowed to write to executable memory region 80 of application kernel 28. As a result, application kernel 28 cannot modify executable memory region 80, which will load all application kernel software (e.g., auxiliary bootloader 68 and FBL software 26). Application kernel 28 can only execute from executable memory region 80. SBL code 68a is now configured to run in application kernel 28 and is configured to load encrypted FBL software 26 from external flash memory 20 into temporary random access memory 70. Auxiliary bootloader 68 requests HSM software 36c to verify the FBL secure boot certificate 72c of encrypted FBL software 26. As described similarly above, HSM software 36c verifies that the hash of unique public key 34b matches public key hash 42 (i.e., a valid signature), and then uses unique public key 34b to verify the signature of secure boot certificate 72c. Furthermore, the HSM software 36c verifies the encrypted FBL message digest 74c of the FBL software 26 within the signed Secure Boot Certificate 72c. The HSM 52 also configures the MPU 64 to prevent modification of the temporary random access memory 70 before calculating the message digest 74c. The two verifications of the HSM software 36c are configured to prevent modification of the temporary random access memory 70 until verification and decryption are complete. This limits modification of the temporary random access memory 70 and prevents issues related to check time and usage time.

[0044] If everything is successfully verified, the secondary bootloader 68 can request the HSM software 36c to decrypt the encrypted FBL software 26 using the common encryption key 30. The FBL software 26 can then be loaded onto the application kernel 28. For example, the HSM 52 can use the load address from the FBL secure boot certificate 72c, and the secondary bootloader 68 can jump to the FBL software 26 after it has been successfully verified and decrypted. The FBL code 50a can run in the application kernel 28 to load the encrypted application software 36a from external flash memory 20 into temporary random access memory 70. The FBL software 26 requests the HSM software 36c to verify the secure boot certificate 72d and message digest 74d of the encrypted application software 36a. The HSM 52 can configure the MPU 64 to prevent modification of the temporary random access memory 70 until verification and decryption are complete. The FBL software 26 further requests the HSM 52 to verify and decrypt the encrypted application software 36a using the common encryption key 30. The application software 36a is then loaded into the application kernel 28. FBL software 26 requests HSM 52 to also verify and decrypt digital signal processor software 36d using common encryption key 30, which is then loaded into digital signal processor 82 of SoC 14.

[0045] Still referencing Figure 5-9 The FBL code 50a, executing on the application kernel 28, loads calibration data 84 and tuning calibration 86 from external flash memory 20 into temporary random access memory 70. The FBL software 26 requests the HSM software 36c to verify the calibration security boot certificate 72e, calibration message digest 74e, tuning calibration security boot certificate 72f, and tuning calibration message digest 74f. As described above, the HSM 52 configures the MPU 64 to prevent modification of the temporary random access memory 70 until verification is complete. The FBL software 26 also requests the HSM software 36c to load calibration data 84 and tuning calibration 86 into the application kernel 28.

[0046] Once the HSM software 36c verifies the request, it allows the use of the In-Vehicle Network (IVN) key 88, which allows the device to influence the behavior of other devices in the vehicle. The MPU 64 is configured to allow the application kernel 28 to write to the application kernel random access memory (RAM) 90. The MPU 64 also allows the application kernel 28 to execute application software 36a. The application kernel 28 jumps from the execution of the FBL software 26 to the application software 36a loaded into the application kernel RAM 90. The digital signal processor 82 is activated, and the MPU 64 is configured to prevent further writes to the digital signal processor 82. The procedures described herein apply to all updatable software 26, 36, and calibration data 84, making these procedures applicable to all updates to the elements described herein (i.e., SBL 46, software 26, 36, and calibration data 84).

[0047] Now for reference Figure 10 and Figure 11In some instances, FBL software 26 can erase application software 36a. For example, the Programming Status Indicator (PSI) can be revoked, and application software 36a in external flash memory 20 can be erased. A region signature header 92 includes software update 38, which is provided to FBL software 26. FBL software 26 requests HSM 52 to verify the region signature header 92. HSM 52 is configured to verify the region signature header 92 using the region public key 22. HSM 52 stores the corresponding message digest 92a, application identifier (ID) 92b, module ID 92c, and secure boot certificate 92d from the region signature header 92. Therefore, FBL software 26 of SoC 14 receives software update 38 and verifies software update 38 using the verified region public key 22 from external flash memory 20. FBL software 26 can then program the update in external flash memory 20 and load software update 38 from external flash memory 20 into temporary random access memory 70. Then, FBL software 26 requests HSM 52 to generate message digest 94a on software update 38, which includes application software 36c in temporary random access memory 70 and virtual secure boot certificate 94b, to verify that software update 38 matches the saved message digest 74d from verified area signature header 92.

[0048] HSM software 36c configures MPU 64 to prevent writes to temporary random access memory 70 until HSM software 36c completes the calculations associated with updating message digest 74. HSM 52 is configured to generate the updated message digest 74 and verifies message digest 74 using a saved message digest 74d from the header 92 of the area signature. HSM 52 reads the secure boot certificate 72d associated with application software 36a, places it in the unique public key 34b, and signs the certificate with the unique private key 34a. If message digest 74d is verified, HSM 52 returns the signed secure boot certificate 72d for application software 36a. FBL software 26 programs the secure boot certificate 72d into external flash memory 20 and reads back the secure boot certificate 72d to confirm a successful write. The verification and signing of the secure boot certificate 72d allows SoC 14 to perform a secure boot at each boot, as SoC 14 will use the signed certificate containing message digest 74 to verify that the contents of external flash memory have not been modified.

[0049] refer to Figure 12An exemplary method 1200 for performing regionalization system 10 is illustrated. At 1202, a public encryption key 30 and a unique encryption key 32 are provided to the SoC 14 of radar module 100. At 1204, the SoC 14 is provided with a unique key pair 34. The unique key pair 34 includes a unique public key 34b and a unique private key 34a. At 1206, software 36 is encrypted with the public encryption key 30, and at 1208, a secure boot certificate 72 for the encrypted software 36 is generated. At 1210, the secure boot certificate 72 is signed using the unique private key. At 1212, the encrypted software 36 is written to external flash memory 20. At 1214, the SoC 14 performs a diagnostic routine 48, including verifying the regional public key 22 of external flash memory 20. At 1216, FBL software 26 and HSM 52 verify the regionalization record 54 using the default regional public key 56. At 1218, SoC 14 is provided with a region credential 24 corresponding to the region public key 22 of external flash memory 20, and in response to the verified regionalization record 54, a default region public key 22 is stored at 1220 in external flash memory 20. At 1222, the region public key 22 from external flash memory 20 is verified using a device-specific key 34.

[0050] Many embodiments have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other embodiments are within the scope of the appended claims.

[0051] The foregoing description has been provided for purposes of illustration and description. It is not intended to be exhaustive or limiting of this disclosure. Elements or features of a particular configuration are generally not limited to that particular configuration, but are interchangeable where applicable and can be used in selected configurations, even if not specifically shown or described. They can also be varied in many ways. Such variations should not be considered as departing from this disclosure, and all such modifications are intended to be included within the scope of this disclosure.

Claims

1. A regionalization system for a radar module of a vehicle, the regionalization system comprising: Data processing hardware; and Memory hardware communicating with the data processing hardware, the memory hardware storing instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations, including: A common encryption key and a unique encryption key are provided at the system-on-chip (SoC) of the radar module; A unique key pair is provided at the SoC, which includes a unique public key and a unique private key; Encrypt the software using the aforementioned public encryption key; Generate a secure boot certificate for the encryption software; The secure boot certificate is signed using the unique private key; Write the encryption software to an external flash memory; A diagnostic routine is executed at the SoC, which includes verifying the region root public key of the external flash memory; and Provide the SoC with the region credentials and the region root public key.

2. The regionalization system of claim 1, wherein providing the unique key pair includes hashing the unique public key at a fuse in the SoC, storing the hash of the unique public key in the fuse, and encrypting the unique private key with the unique encryption key before storing the unique private key in the external flash memory.

3. The regionalization system of claim 1, wherein the external flash memory includes flash bootloader software that includes a default regional public key.

4. The regionalization system of claim 3 further includes verifying the regional public key, the regional credentials, and the default credentials of the flash bootloader software via a diagnostic routine having a default regional public key.

5. The regionalization system of claim 4 further includes using the default regional public key to verify the regionalization record via the flash bootloader of the SoC and the hardware security module (HSM) of the SoC.

6. The regionalization system according to claim 5, further comprising: In response to the verified regional record, the regional public key and the regional credential are stored in the external flash memory; A diagnostic routine is executed at the SoC, which includes verifying the region public key of the external flash memory; and Provide the SoC with a region credential corresponding to the region public key of the external flash memory.

7. The regionalization system of claim 5 further includes receiving a software update at the flash bootloader of the SoC and verifying the software update via the HSM using a regional public key from the external flash memory.

8. The regionalization system of claim 1 further includes updating software at the SoC and verifying the software update via a regional public key.

9. The regionalization system of claim 8 further includes signing the secure boot certificate using a device-unique private key via the hardware security module (HSM) of the SoC.

10. A vehicle equipped with the regionalization system according to claim 1.

Images