Safe starting method, device and equipment of cabin area controller system and vehicle

Abstract

The invention discloses a safe starting method, device and equipment of a cabin area controller system and a vehicle, and relates to the technical field of vehicles. The safe starting method of the cockpit domain controller system comprises the following steps: checking a system mirror image of a first operating system through a safe starting checking mechanism of the first operating system; after the verification of the system mirror image of the first operating system is passed, verifying a trusted startup component of the first operating system through a first verification public key, a verification public key of a trusted startup component of a second operating system being stored in the trusted startup component of the first operating system; if the trusted boot component of the first operating system passes the verification, verifying a mirror image of a second operating system based on encryption verification information of the second operating system; if the mirror image of the second operating system passes verification, the system mirror image of the second operating system is started through the virtual machine manager, and the starting safety of the cabin domain controller system can be improved by executing the steps.

Description

Technical Field

[0001] The present application relates to the field of vehicle technology, and in particular to a method, device, equipment and vehicle for securely starting a cockpit domain controller system. Background Art

[0002] At present, cars are developing towards networking, automation, sharing and electrification, and the "new four trends" all point to intelligence. An important manifestation of car intelligence is the smart cockpit. The smart cockpit can significantly improve the car's intelligent experience and gradually become one of the important factors affecting consumers' car purchases.

[0003] As an important direction of automotive technology development, smart cockpits provide convenience and comfort, but also face some security issues. With the development of networking in smart cockpits, in-vehicle and out-of-vehicle communications and applications may bring information security issues. Information security issues include potential hacker attacks on vehicle control systems and the risk of leakage of personal privacy information.

[0004] The related art provides some methods for secure startup of the cockpit domain controller system, but its security still needs to be improved. Summary of the invention

[0005] The main purpose of the embodiments of the present application is to provide a method, device, equipment and vehicle for secure startup of a cockpit domain controller system, aiming to improve the security of startup of the cockpit domain controller system.

[0006] To achieve the above-mentioned purpose, an embodiment of the present application proposes a secure boot method for a cockpit domain controller system, comprising the following steps: verifying a system image of the first operating system through a secure boot verification mechanism of the first operating system, wherein the first operating system is a system for realizing a first function of a vehicle, wherein the first function includes a real-time operating system task, a vehicle network communication and / or an advanced driving assistance; after the system image of the first operating system passes the verification, verifying a trusted boot component of the first operating system through a first signature verification public key to obtain first verification result indication information; wherein the trusted boot component of the first operating system stores a second signature verification public key corresponding to a trusted boot component of a second operating system, and the second signature verification public key is used to verify the trusted boot component of the second operating system; the trusted boot component of the second operating system stores encrypted verification information of the second operating system, wherein the second operating system is a system for realizing a second function of a vehicle, wherein the second function includes an infotainment function; if the first verification result indication information indicates that the trusted boot component of the first operating system passes the verification, then verifying the image of the second operating system based on the encrypted verification information of the second operating system to obtain second verification result indication information; if the second verification result indication information indicates that the image of the second operating system passes the verification, then starting the system image of the second operating system through a virtual machine manager.

[0007] In some embodiments, the image of the second operating system includes a boot image and a system image, and the verifying the image of the second operating system based on the encrypted verification information of the second operating system includes: verifying the boot image of the second operating system based on the encrypted verification information of the second operating system to obtain third verification result indication information; if the third verification result indication information indicates that the boot image of the second operating system has passed the verification, then verifying the system image of the second operating system according to the public key of the root hash through the boot image of the second operating system to obtain fourth verification result indication information.

[0008] In some embodiments, the second verification result indication information includes the third verification result indication information and the fourth verification result indication information, and if the second verification result indication information indicates that the image of the second operating system has passed the verification, then starting the system image of the second operating system through the virtual machine manager includes: if the third verification result indication information indicates that the startup image of the second operating system has passed the verification, then starting the startup image of the second operating system through the virtual machine manager; when the startup image of the second operating system is successfully started, if the fourth verification result indication information indicates that the system image of the second operating system has passed the verification, then starting the system image of the second operating system through the virtual machine manager.

[0009] In some embodiments, before verifying the system image of the first operating system through the secure boot verification mechanism of the first operating system, the secure boot method of the cockpit domain controller system also includes: in response to a startup trigger signal of the system-level chip, controlling the main boot loader to verify and start the extended boot loader; if the extended boot loader is successfully started, controlling the extended boot loader to verify and start the execution environment.

[0010] In some embodiments, a secure boot root certificate is stored in the extended boot loader, and the controlling the main boot loader to verify and start the extended boot loader includes: calculating a hash value of the root certificate, comparing the hash value with the hash value of the secure boot root certificate stored in the electronic fuse, and obtaining a first comparison result; if the first comparison result indicates that the calculated hash value of the root certificate is the same as the hash value of the secure boot root certificate stored in the electronic fuse, then verifying the image of the extended boot loader through the secure boot root certificate to obtain fifth verification result indication information; if the fifth verification result indication information indicates that the image of the extended boot loader has passed the verification, then starting the extended boot loader through the main boot loader.

[0011] In some embodiments, the secure boot method of the cockpit domain controller system also includes securely booting a microcontroller, and the steps of securely booting the microcontroller include: loading a key set, the key set including multiple levels of keys, and the key set stored in an encryption security engine module; in response to a secure boot command, verifying the boot management in the microcontroller using the key in the key set to obtain sixth verification result indication information; if the sixth verification result indication information indicates that the boot management verification in the microcontroller has passed, then performing a secure boot verification on the application.

[0012] In some embodiments, the loading key set includes: registering an electronic control unit master key, the electronic control unit master key being a boot key; registering a startup message authentication code key, a startup message authentication code and a user key to a data flash unit in the encryption security engine module through the boot key.

[0013] In some embodiments, the secure startup verification of the application includes: generating a cryptographic message authentication code for a first application through an encryption algorithm and a user key; comparing the cryptographic message authentication code of the first application with the cryptographic message authentication code of a second application read through a read-only memory to obtain a second comparison result; if the second comparison result indicates that the cryptographic message authentication code of the first application is consistent with the cryptographic message authentication code of the second application, then starting the application.

[0014] To achieve the above-mentioned purpose, another aspect of an embodiment of the present application proposes a secure boot device for a cockpit domain controller system, wherein the secure boot device for the cockpit domain controller system includes: a first verification module, used to verify the system image of the first operating system through a secure boot verification mechanism of the first operating system, wherein the first operating system is a system for realizing a first function of the vehicle, wherein the first function includes real-time operating system tasks, vehicle network communications and / or advanced driving assistance; a second verification module, used to verify the trusted boot component of the first operating system through a first verification public key after the system image of the first operating system has been verified, to obtain first verification result indication information; wherein the trusted boot component of the first operating system stores the corresponding trusted boot component of the second operating system a second signature verification public key, the second signature verification public key is used to verify the trusted boot component of the second operating system; the trusted boot component of the second operating system stores encrypted verification information of the second operating system, the second operating system is a system for realizing a second function of the vehicle, and the second function includes an infotainment function; a third verification module is used to verify the image of the second operating system based on the encrypted verification information of the second operating system to obtain second verification result indication information when the first verification result indication information indicates that the trusted boot component of the first operating system has passed the verification; a startup module is used to start the system image of the second operating system through the virtual machine manager when the second verification result indication information indicates that the image of the second operating system has passed the verification.

[0015] To achieve the above-mentioned purpose, another aspect of an embodiment of the present application proposes an electronic device, which includes a memory and a processor, the memory stores a computer program, and the processor implements the above-mentioned safe startup method of the cockpit domain controller system when executing the computer program.

[0016] To achieve the above-mentioned purpose, another aspect of an embodiment of the present application proposes a vehicle, wherein a cockpit domain controller system of the vehicle is securely started by a secure startup method for a cockpit domain controller system, a secure startup device for a cockpit domain controller system, or an electronic device as described in any one of the above.

[0017] The embodiments of the present application include at least the following beneficial effects:

[0018] The present application provides a secure boot method, device, equipment and vehicle for a cockpit domain controller system. In an embodiment of the present application, a system image of a first operating system is verified by a secure boot verification mechanism of a first operating system, where the first operating system is a system for implementing a first function of a vehicle, and the first function includes real-time operating system tasks, vehicle network communications and / or advanced driving assistance; after the system image of the first operating system is verified, a trusted boot component of the first operating system is verified by a first signature verification public key to obtain first verification result indication information; wherein a second signature verification public key corresponding to a trusted boot component of a second operating system is stored in the trusted boot component of the first operating system, and the second signature verification public key is used to verify the trusted boot component of the second operating system; encrypted verification information of the second operating system is stored in the trusted boot component of the second operating system, where the second operating system is a system for implementing a second function of the vehicle, and the second function includes an infotainment function; if the first verification result indication information indicates that the trusted boot component of the first operating system has passed the verification, the image of the second operating system is verified based on the encrypted verification information of the second operating system to obtain second verification result indication information; if the second verification result indication information indicates that the image of the second operating system has passed the verification, the system image of the second operating system is started through a virtual machine manager. Verifying the system image of the first operating system through the secure boot verification mechanism of the first operating system can ensure the boot security of the system image of the first operating system. After the system image of the first operating system passes the verification, the trusted boot component of the first operating system is verified through the first verification public key. Given that the trusted boot component of the first operating system stores the verification public key of the trusted boot component of the second operating system, and the trusted boot component of the second operating system stores the encrypted verification information of the second operating system, after the trusted boot component of the first operating system passes the verification, verifying the image of the second operating system based on the encrypted verification information of the second operating system can ensure the secure boot of the second operating system, thereby improving the security of the cockpit domain controller system startup.

[0019] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0021] Figure 1 is a flow chart of a method for securely starting a cockpit domain controller system provided by some embodiments of the present application;

[0022] Figure 2 It is a schematic diagram of verifying a second operating system image by a first operating system provided in some embodiments of the present application;

[0023] Figure 3 is a flow chart of a secure boot method for a microcontroller provided by some embodiments of the present application;

[0024] Figure 4 It is a schematic block diagram of a module of a safety startup device of a cockpit domain controller system provided by some embodiments of the present application;

[0025] Figure 5 It is a schematic diagram of the hardware structure of an electronic device provided in some embodiments of the present application. DETAILED DESCRIPTION

[0026] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the reference to "embodiment" in this article means that the specific features, structures or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present application. The appearance of this phrase in various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of the present application. They are only examples of devices and methods consistent with some aspects of the embodiments of the present application as detailed in the attached claims.

[0027] It is understood that the terms "first", "second", etc. used in this application can be used to describe various concepts in this article, but unless otherwise specified, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another concept. For example, without departing from the scope of the embodiment of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the words "if" and "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determination".

[0028] The terms "at least one", "multiple", "each", "any", etc. used in this application, at least one includes one, two or more, multiple includes two or more, each refers to each of the corresponding multiple, and any refers to any one of the multiple.

[0029] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0030] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0031] In order to make the inventive concept of the present application easy to understand, before describing the embodiments of the present application in detail, the English abbreviations (terms) / related concepts involved in the embodiments of the present application are first described. The English abbreviations (terms) / related concepts involved in the embodiments of the present application are subject to the following explanations.

[0032] SBL: SBL stands for Secondary Boot Loader in English, which means secondary boot loader image in Chinese.

[0033] PBL: PBL stands for Primary Boot Loader in English, which is mainly responsible for enumerating boot modes and loading SBL images. It runs on the integrated read-only memory of the chip-level system and its main function is to perform self-test.

[0034] XBL: XBL stands for Xtensa Boot Loader, which is a boot loader responsible for core application functions such as chip driving and charging.

[0035] AVB: AVB stands for Attestation Verification Boot, which means verification boot module in Chinese. The main function of the AVB module is to verify the various components in the boot process to ensure that they are authentic and have not been tampered with, which is essential to ensure the safe boot of the system. In automotive electronics and other safety-critical systems, the AVB module is the key to ensuring that all parts of the system, from firmware to the operating system, are authentic and have not been tampered with.

[0036] VBMeta: VBMeta is the full spelling of Verified Boot Metadata, which is a secure boot mechanism in the operating system. It is a file that contains system boot security policy and certificate information, and is used to verify the integrity of system images (such as kernel, root file system, etc.).

[0037] VMM: VMM stands for Virtual Machine Manager in English, which means virtual machine manager in Chinese.

[0038] Dm-verity: Dm-verity is a target device type under the device-mapper architecture, which is used to ensure the integrity of the device or device partition. The Dm-verity type target device has two underlying devices, one is the data device, which is used to store the actual data, and the other is the hash device, which is used to store the hash data.

[0039] OTP: OTP is a memory that can only be programmed once. Once the information is programmed into the OTP memory, it cannot be erased or modified. This memory is usually used to store fixed configuration information, keys or other one-time settings to ensure their security and immutability.

[0040] Bootloader: Bootloader is also called boot loader, startup program or boot program, which refers to the program that boots the operating system. The boot program startup method and program vary depending on the type of application model. Simply put, BootLoader is a small program that runs before the operating system kernel runs. Through this small program, we can initialize hardware devices and establish a mapping of memory space, so that the system's hardware and software environment is brought to a suitable state, so as to prepare the correct environment for the final call to the operating system kernel.

[0041] CMAC: CMAC stands for Cipher Block Chaining-Message Authentication Code in Chinese. It is an algorithm used for message authentication. It uses a symmetric key to encrypt the message to generate a fixed-length summary to verify the integrity and source of the message.

[0042] CSEC: CSEC stands for Cryptographic Security Engine, a hardware encryption module that integrates a dedicated processor for encryption and decryption operations that can be used to protect data security.

[0043] MAC: MAC stands for Message Authentication Code, which is a cryptographic hash used to verify the integrity and origin of a message. During the boot process, the CSEC module calculates a MAC value based on the contents of the boot image (such as boot.img, system.img, etc.).

[0044] EMMC: EMMC stands for Embedded MultiMediaCard, which is an embedded storage device widely used in mobile devices, consumer electronics and automotive electronics. EMMC partition software refers to the tool or application used to manage and configure EMMC internal storage partitions.

[0045] SOC: SOC stands for System on Chip in English, which means system-level chip in Chinese.

[0046] MCU: MCU is the full spelling of Microcontroller Unit in English, which is explained as microcontroller unit in Chinese.

[0047] eFUSE: Also known as "electronic fuse" or "embedded fuse", it refers to a hardware security feature that is usually used to store critical security information, such as certificate hashes, keys, device identity information, etc. Once written, this information is usually unchangeable, thus providing hardware-level security.

[0048] Image: Software image. Usually, Image refers to a piece of software code or data stored in a non-volatile memory (such as flash memory), which is loaded into the memory for execution when the SOC starts.

[0049] At present, automobiles are developing towards networking, automation, sharing and electrification, and the "new four trends" all point to intelligence. Intelligence brought about earth-shaking changes in the mobile phone industry 15 years ago, and is now repeating itself in the automotive industry, making automobiles the most dynamic market in the world. An important manifestation of automobile intelligence is the smart cockpit. The smart cockpit can significantly improve the automobile intelligence experience and gradually become one of the important factors affecting consumers' car purchases.

[0050] As consumers pay more and more attention to smart cockpits, information security issues in cars are becoming increasingly prominent. Key management is an important part of automotive information security requirements, which involves all aspects of automotive information security, including vehicle telematics services, in-vehicle network communications, engine control units, on-board diagnostic systems, etc. In order to ensure the security and reliability of smart vehicle terminals, smart vehicle terminals need to have certain protection measures in hardware and software to prevent the leakage of personal information and sensitive data, and prevent vehicles and vehicle services from being abused or attacked, and ensure that the cockpit domain controller system can start smoothly every time it is powered on, and is not abused or attacked.

[0051] The related art provides some methods for secure startup of the cockpit domain controller system, but its security still needs to be improved.

[0052] In view of this, the present application proposes a secure startup method, device, equipment and vehicle for a cockpit domain controller system, wherein the scheme verifies the system image of the first operating system through a secure startup verification mechanism of the first operating system, wherein the first operating system is a system for realizing a first function of the vehicle, and the first function includes real-time operating system tasks, vehicle network communications and / or advanced driving assistance; after the system image of the first operating system passes the verification, the trusted startup component of the first operating system is verified through a first signature verification public key to obtain first verification result indication information; wherein the trusted startup component of the first operating system stores a second signature verification public key corresponding to a trusted startup component of a second operating system, and the second signature verification public key is used to verify the trusted startup component of the second operating system; the trusted startup component of the second operating system stores encrypted verification information of the second operating system, and the second operating system is a system for realizing a second function of the vehicle, and the second function includes an infotainment function; if the first verification result indication information indicates that the trusted startup component of the first operating system passes the verification, the image of the second operating system is verified based on the encrypted verification information of the second operating system to obtain second verification result indication information; if the second verification result indication information indicates that the image of the second operating system passes the verification, the system image of the second operating system is started through a virtual machine manager. Verifying the system image of the first operating system through the secure boot verification mechanism of the first operating system can ensure the boot security of the system image of the first operating system. After the system image of the first operating system passes the verification, the trusted boot component of the first operating system is verified through the first verification public key. Given that the trusted boot component of the first operating system stores the verification public key of the trusted boot component of the second operating system, and the trusted boot component of the second operating system stores the encrypted verification information of the second operating system, after the trusted boot component of the first operating system passes the verification, verifying the image of the second operating system based on the encrypted verification information of the second operating system can ensure the secure boot of the second operating system, thereby improving the security of the cockpit domain controller system startup.

[0053] The method provided in the embodiment of the present application can be applied to the electronic device provided in the embodiment of the present application, wherein the electronic device can be the processor, memory, storage device, security module (such as TPM-Trusted Platform Module) and other related vehicle hardware of the cockpit domain controller.

[0054] The method provided in the embodiment of the present application can also be applied to the vehicle provided in the embodiment of the present application. The vehicle can be a modern car that adopts advanced driver assistance (ADAS) and intelligent interconnection system.

[0055] The method provided in the embodiment of the present application can also be applied to a software platform, which includes an operating system, firmware, a boot loader (such as SBL), a security software stack, etc. of a cockpit domain controller.

[0056] The above is an introduction to the implementation environment of the embodiments provided in this application.

[0057] In order to more clearly understand the embodiments provided in the present application, before introducing the implementation methods of the above steps, the startup process of the cockpit domain controller system (vehicle system) is first introduced.

[0058] The following is the startup process of the vehicle system provided in the embodiment of the present application:

[0059] 1. After the MCU detects the power-on signal, it outputs an enable signal, turns on the power supply on the system side, and supplies power to the SOC;

[0060] 2. After SOC detects that the power supply is on, SOC starts to start;

[0061] 3. Load and run the Bootloader, initialize the hardware devices, and establish a memory space mapping map. Loading the Bootloader is mainly divided into three stages:

[0062] Phase 1:

[0063] 1) First, initialize the hardware code:

[0064] a. Shield all interrupts: The execution process of BootLoader does not need to respond to any interrupts;

[0065] b. Set the CPU speed and clock frequency;

[0066] c. Random Access Memory (RAM) initialization: Correctly set the function registers of the system memory controller.

[0067] d. Disable the CPU internal instruction / data cache.

[0068] 2) After the hardware is initialized, a readable and writable RAM space is reserved for loading phase 2, and the RAM space address is tested.

[0069] 3) Set up the stack pointer and jump to stage 2 of the Bootloader by modifying the PC register to point to the appropriate address.

[0070] Phase 2:

[0071] 1) In order to output I / O information to the end user, it is also necessary to initialize hardware devices such as timers;

[0072] 2) Check the memory map in the vehicle system and load the kernel hardware and root file system;

[0073] 3) Set the kernel startup parameters and call it.

[0074] Phase 3:

[0075] 1) SOC solidifies the boot program and loads the boot program of Bootloader from EMMC;

[0076] 2) After the boot program is successfully started, the Bootloader initializes the double data rate memory (DDR) and loads the program into the DDR;

[0077] 3) After DDR is loaded successfully, start the virtualization manager (Hypervisor);

[0078] 4. Start the Linux Kernel and mount system files;

[0079] 5. Load the relevant processes of virtual machine interaction, and tell the virtual machine interaction process to notify the Android system that the resource loading is complete;

[0080] 6. After the SOC is successfully started, start the Android system kernel, load the file system and application programs, and read and write system logs;

[0081] 7. Load the screen driver for the central control and instrument panel, light up the screen, and play the welcome animation.

[0082] The above is the normal process of starting up the car computer. In order to prevent the operation of unauthorized or maliciously modified software and affect the security of the car computer system, the car computer needs to verify the integrity and legality of the executed code when the system starts. To prevent illegal updates to the EMMC partition software, the car computer system prohibits writing to the EMMC bootloader partition from the driver layer.

[0083] It should be understood that the secure boot of SOC mainly verifies all images during the SOC boot process. Only images that pass the verification can be executed, thereby ensuring that the images being run are legal and have not been tampered with. After the image is compiled, it can be signed with a private key, and the signature result and certificate chain are added to the image file. During the system startup process, the public key is used for verification.

[0084] The following will describe in detail the implementation steps of a secure startup method for a cockpit domain controller system provided by an embodiment of the present application in conjunction with the accompanying drawings.

[0085] Please refer to Figure 1 , Figure 1A flowchart of a secure startup method for a cockpit domain controller system provided for some embodiments of the present application. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0086] The method of the embodiment of the present application comprises the following steps:

[0087] Step 101: Verify a system image of a first operating system through a secure boot verification mechanism of the first operating system, where the first operating system is a system for implementing a first function of a vehicle, where the first function includes a real-time operating system task, vehicle network communication, and / or advanced driver assistance;

[0088] Step 102: after the system image of the first operating system passes the verification, the trusted boot component of the first operating system is verified by using the first signature verification public key to obtain first verification result indication information, the first verification result indication information is used to indicate whether the trusted boot component of the first operating system passes the verification; wherein the trusted boot component of the first operating system stores a second signature verification public key corresponding to the trusted boot component of the second operating system, the second signature verification public key is used to verify the trusted boot component of the second operating system; the trusted boot component of the second operating system stores encrypted verification information of the second operating system, the second operating system is a system for realizing a second function of the vehicle, and the second function includes an infotainment function;

[0089] Step 103: If the first verification result indication information indicates that the trusted boot component of the first operating system has passed the verification, the image of the second operating system is verified based on the encrypted verification information of the second operating system to obtain second verification result indication information, where the second verification result indication information is used to indicate whether the image of the second operating system has passed the verification;

[0090] Step 104: If the second verification result indication information indicates that the image of the second operating system has passed the verification, the system image of the second operating system is started through the virtual machine manager.

[0091] In steps 101 to 104 shown in the embodiment of the present application, the system image of the first operating system is verified by the secure boot verification mechanism of the first operating system, which can ensure the boot security of the system image of the first operating system. After the system image of the first operating system passes the verification, the trusted boot component of the first operating system is verified by the first verification public key. Given that the trusted boot component of the first operating system stores the verification public key of the trusted boot component of the second operating system, and the trusted boot component of the second operating system stores the encrypted verification information of the second operating system, when the trusted boot component of the first operating system passes the verification, the image of the second operating system is verified based on the encrypted verification information of the second operating system, thereby ensuring the secure boot of the second operating system, thereby improving the security of the cockpit domain controller system startup.

[0092] The specific implementation methods of the above steps are introduced below.

[0093] In step 101, a system image of a first operating system is verified through a secure boot verification mechanism of the first operating system. The first operating system is a system for implementing a first function of a vehicle. The first function includes real-time operating system tasks, vehicle network communications, and / or advanced driver assistance.

[0094] In the embodiment of the present application, the first operating system may be a QNX system, which is a real-time operating system (RTOS) owned by BlackBerry, and is widely used in the automotive industry for its high reliability, real-time performance and security features. It should be understood that the first operating system is a system that can be used to implement the first function of the vehicle, and the first function includes real-time operating system tasks, vehicle network communications and / or advanced driver assistance. It is understandable that any system that can be used to implement the first function of the vehicle can be the first operating system, wherein the first operating system can also be a VxWorks system, which is a real-time operating system that can support real-time operating system tasks, vehicle network communications and / or advanced driver assistance.

[0095] The first operating system's secure boot verification mechanism usually involves some key steps and components to ensure the integrity and security of the operating system during the boot process. These steps include: boot loader, digital signature and encryption, establishing a trust chain, secure boot, etc.

[0096] For example, the QNX system image may be verified by starting the verification process securely through the QNX system.

[0097] The embodiment provided in the present application verifies the system image of the first operating system through the secure boot verification mechanism of the first operating system, which can ensure the reliability and security of the first operating system and help prevent system failures of the first operating system caused by software damage or malicious attacks.

[0098] In step 102, after the system image of the first operating system passes the verification, the trusted boot component of the first operating system is verified by the first verification public key to obtain first verification result indication information, the first verification result indication information is used to indicate whether the trusted boot component of the first operating system has passed the verification, the trusted boot component of the first operating system stores the second verification public key of the trusted boot component of the second operating system, the second verification public key is used to verify the trusted boot component of the second operating system, the trusted boot component of the second operating system stores encrypted verification information of the second operating system, the second operating system is a system for realizing a second function of the vehicle, and the second function includes an infotainment function.

[0099] It is understandable that the verification mechanism of the second operating system is usually different from the verification mechanism of the first operating system. Therefore, the second operating system cannot be verified by the verification mechanism of the first operating system.

[0100] For example, the verification mechanism of Android Image is different from that of QNX Image; and the key used when signing Android Image is also different from the secure boot key of QNX, so the secure boot root certificate of QNX cannot be used directly to verify Android Image.

[0101] In view of this, the embodiment of the present application adopts two sets of VBMeta, one is the host VBMeta (Host VBMeta), that is, the VBMeta of the first operating system, and the other is the client VBMeta (Guest VBMeta), that is, the VBMeta of the second operating system. The public key of the Guest VBMeta is stored in the Host VBMeta, which can be used to verify the Guest VBMeta. The Host VBMeta is protected by a signature, and its key is stored in the QVB module in the QNX System.

[0102] Exemplarily, the host VBMeta may be VBMeta in a QNX system, and the guest VBMeta may be VBMeta in an Android system.

[0103] After the system image of the first operating system passes the verification, the trusted boot component of the first operating system can be verified by the first signature verification public key. Among them, the first signature verification public key is a public key used to verify the signature of the trusted boot component of the first operating system, and the first signature verification public key can be a verification certificate public key (attest certificate public key, i.e. Host AVBKEY). The trusted boot component of the first operating system can be the host verification boot metadata (Host VBMeta).

[0104] Exemplarily, the Host AVB KEY may be used to verify the Host VBMeta to obtain a verification result, where the verification result is used to indicate whether the Host VBMeta passes the verification.

[0105] Among them, the trusted boot component of the first operating system is protected by a signature, and its signature verification public key (Host AVB KEY) is built into the QVB (QNX Verified Boot) module in the QNX system. The QVB module is a module in the QNX operating system, which provides a secure boot function similar to Android's Android Verified Boot (AVB). QVB is designed to ensure that the device's boot process is secure and prevent unauthorized software or firmware from running on the device.

[0106] In the embodiment provided in the present application, the certificate chain can be a three-certificate chain structure, including a rootca certificate (root certificate), an attestca certificate and an attest certificate.

[0107] The rootca certificate is a self-signed certificate issued by a trusted certificate authority (CA). It is the starting point of the certificate trust chain; the attestca certificate usually refers to a certificate held by a certificate authority that is specifically used to provide device or service certification. This certificate is issued by the root CA or another intermediate CA to prove the identity and authority of the verification certificate authority (attestca); the attest certificate is a certificate issued by attestca, which is usually used to prove the specific attributes of a device, service or entity, such as proving that the device has not been tampered with or is running genuine software; it is used to prove the specific status of a device, service or entity, such as that the secure boot has been completed or the device configuration meets specific standards.

[0108] Exemplarily, the Host VBMeta stores the signature verification public key (LA_AVB_KEY) of the client authentication boot metadata (Guest VBMeta), which is used to verify the Guest VBMeta. It should be understood that after the Host VBMeta is verified, the Guest VBMeta can be verified by LA_AVB_KEY. After the Guest VBMeta is verified, the boot image of the second operating system can be further verified by GuestVBMeta.

[0109] The Guest VBMeta stores the hash value of the boot image and the hash value of the public key used to verify the signature of the boot image. The signature verification public key can be stored at the end of the boot image.

[0110] In the embodiment of the present application, the second operating system may be an Android operating system, which is used to implement the second function of the vehicle, and the second function includes an infotainment function. It is understandable that any system that can be used to implement the second function of the vehicle can be the second operating system, wherein the second operating system may also be an Android Automotive system, which is a version of the Android operating system developed by Google and designed specifically for automobiles. It provides a rich application ecosystem and high customizability; the second operating system may also be a Windows Automotive system, which is an operating system designed specifically for automobile infotainment systems provided by Microsoft; the second operating system may also be an AliOS system developed by Alibaba Group.

[0111] The embodiment provided by the present application verifies the trusted boot component of the first operating system through the first verification public key after the system image of the first operating system has passed the verification, wherein the trusted boot component of the first operating system stores the second verification public key of the trusted boot component of the second operating system, which is used to verify the trusted boot component of the second operating system, and the trusted boot component of the second operating system stores encrypted verification information of the second operating system, thereby ensuring the security of the trusted boot component of the first operating system. Given that the second verification public key of the trusted boot component of the second operating system is stored in the trusted boot component of the first operating system, support is provided for verifying the second operating system through the first operating system.

[0112] In step 103, if the first verification result indication information indicates that the trusted boot component of the first operating system has passed the verification, the image of the second operating system is verified based on the encrypted verification information of the second operating system to obtain second verification result indication information, and the second verification result indication information is used to indicate whether the image of the second operating system has passed the verification.

[0113] In some embodiments, the image of the second operating system includes a boot image and a system image. The boot image of the second operating system is verified based on the encrypted verification information of the second operating system, and if the boot image of the second operating system passes the verification, the system image of the second operating system is verified by the boot image of the second operating system according to the public key of the root hash.

[0114] The encrypted verification information of the second operating system may include a hash value of a boot image and a hash value of a public key used to verify the signature of the boot image. The boot image of the second operating system may be verified by the hash value.

[0115] Exemplarily, the Android bootimage may be verified based on the encrypted verification information stored in the Guest VBMeta.

[0116] After the boot image of the second operating system passes the verification, the system image of the second operating system can be verified through the bootimage of the second operating system according to the public key of the root hash.

[0117] Exemplarily, after the Android boot image passes the verification, the Android system Image can be verified by using the public key of the root Hash of the Android boot image and the signature verification public key of the boot image.

[0118] Among them, Android's system image uses the DM-Verity mechanism and is verified based on a hash tree. The top-level node of the hash tree is called the root hash, and the root hash signature is saved in the AVB Footer at the end of the system image. The public key corresponding to the signature of the root hash will be compiled into the boot image, which is responsible for verification to ensure the integrity of the system image. If the verification succeeds, the boot image will continue to load and execute the system image; if the verification fails, the boot image will refuse to load the system image, thereby preventing malware or tampered system images from being loaded onto the device.

[0119] By verifying the systemimage of the second operating system according to the public key of the root hash through the boot image of the second operating system, the boot image can ensure that the system image has not been tampered with after distribution, thereby improving the security of the system.

[0120] In step 104, if the second verification result indication information indicates that the image of the second operating system has passed the verification, the system image of the second operating system is started through the virtual machine manager.

[0121] In some embodiments, the second verification result indication information includes third verification result indication information and fourth verification result indication information. If the third verification result indication information indicates that the startup image of the second operating system has passed the verification, the startup image of the second operating system is started through the virtual machine manager; if the startup image of the second operating system is successfully started, if the fourth verification result indication information indicates that the system image of the second operating system has passed the verification, the system image of the second operating system is started through the virtual machine manager.

[0122] Exemplarily, if the Android boot image passes the verification, the VMM is notified to start the Android boot image; if the Android boot image is successfully started and the Android system image passes the verification, the VMM is notified to start the Android system image, thereby implementing the verification and startup process of the Android system.

[0123] The embodiment provided in the present application can ensure the integrity and security of the second operating system image by verifying the image of the second operating system based on the encrypted verification information of the second operating system, thereby improving the security of starting the second operating system.

[0124] See also Figure 2 , Figure 2 This is a schematic diagram of verifying the first operating system against the second operating system image provided by some embodiments of the present application. In the figure, the first operating system is the QNX system, and the second operating system is the Android_LA system (Android system).

[0125] The QNX system includes the system image module and Host VBMeta.img. The system image module includes the QVB module and the virtual machine manager. The QVB module stores the Host AVB KEY used to verify the Host VBMeta, that is, HostVBMeta is protected by a signature, and its key is stored in the QVB module in the QNX system. The Host VBMeta.img stores the LA_AVB_KEY used to verify the Guest VBMeta.

[0126] In Android, LA or _la usually refers to loading and initialization, which usually refers to loading and initializing different components or data. For example, System_la.img: This is a boot image, which contains the loading and initialization code for starting System.img. System_la.img is responsible for loading System.img during the boot process.

[0127] The Android_LA system includes VBMeta_la.img, which includes VBM_LA protected by signature. The corresponding signature verification public key of VBM_LA is LA_AVB_KEY, which is stored in Host VBMeta.img. The Android_LA system also includes boot_la.img and system_la.img, which are used to load and initialize boot image and systemImage respectively.

[0128] Figure 2 In the process, the QNX system security boot verification process can be used to verify the QNX system image. After the verification passes, the Host VBMeta.img is verified and authorized through QVB. After the Host VBMeta.img passes the verification, VBMeta_la.img, boot_la.img and system_la.img are verified and authorized through QVB. After all of them pass the verification, the VMM is notified to load and start boot_la.img and system_la.img. Figure 2 In the figure, AUTH indicates the process of authenticating and authorizing the boot image, and LOAD indicates the process of loading and starting.

[0129] In some embodiments of the present application, before verifying the system image of the first operating system through the secure boot verification mechanism of the first operating system, it also includes: in response to a startup trigger signal of the system-level chip, controlling the main boot loader to verify and start the extended boot loader; when the extended boot loader is successfully started, controlling the extended boot loader to verify and start the execution environment.

[0130] In some embodiments, a secure boot root certificate is stored in the extended boot loader, and a hash value of the root certificate can be calculated, and the hash value can be compared with the hash value of the secure boot root certificate stored in the electronic fuse to obtain a first comparison result; if the first comparison result indicates that the calculated hash value of the root certificate is the same as the hash value of the secure boot root certificate stored in the electronic fuse, the image of the extended boot loader is verified through the secure boot root certificate to obtain fifth verification result indication information, and the fifth verification result indication information is used to indicate whether the image of the extended boot loader has passed the verification; if the fifth verification result indication information indicates that the image of the extended boot loader has passed the verification, the extended boot loader is started through the main boot loader.

[0131] For example, after the SOC is powered on, the PBL is started first. Since the PBL is solidified inside the chip and its security is guaranteed by the chip hardware, attackers cannot modify its content. Therefore, the PBL is credible and does not need to be verified. It is the root of trust (ROT) for secure boot. The root certificate hash is stored in eFUSE, and the certificate chain exists in XBL.

[0132] Before PBL starts XBL, it needs to verify XBL. First, read the root certificate of secure boot from XBL, calculate its hash value, and read the hash value of the root certificate of secure boot from eFUSE. Compare the two hash values. If the two are the same, the root certificate of secure boot in XBL is considered legal. Use this certificate to verify the certificate chain and verify the Image. If the hash values ​​are different or the Image verification fails, it is considered that XBL has been tampered with and the startup fails. If the verification succeeds, PBL starts XBL and gives the execution right to XBL.

[0133] After XBL passes the verification, it can continue to verify other partitions of the system through the QVB module using its built-in attest certificate public key (Host AVBKEY). That is, XBL continues to load and verify QTEE and QHEE. If the verification passes, the execution right is handed over to QTEE, and all images in the process are started. Among them, the next-level image is verified by the image that has passed the verification of the previous level, and only the image that has passed the verification can get the execution right.

[0134] The embodiment of the present application controls the main boot loader to verify and start the extended boot loader; when the extended boot loader is successfully started, the extended boot loader is controlled to verify and start the execution environment, providing multiple layers of security and reliability, which can reduce the risk of system startup failure and thereby improve the security and reliability of the system.

[0135] In some embodiments of the present application, a secure boot of a microcontroller (MCU) is also included. The secure boot of the microcontroller includes: loading a key set, the key set includes multiple levels of keys, and the key set is stored in a cryptographic security engine module (CSEC module); in response to a secure boot command, the boot management (BM) in the microcontroller is verified using a key in the key set to obtain sixth verification result indication information, and the sixth verification result indication information is used to indicate whether the boot management in the microcontroller has passed the verification; if the sixth verification result indication information indicates that the boot management in the microcontroller has passed the verification, a secure boot verification is performed on the application.

[0136] The code area of ​​MCU usually includes boot manager (BM), flash boot loader (FBL) and application program (APP).

[0137] The BM is used for boot management. If the BM secure boot check passes, the APP secure boot check will continue. The flash boot loader is only used when the application is upgraded. When the upgrade command is received, it triggers the upgrade process and then resets the boot manager. After that, it jumps back to the flash boot loader, completes the secure boot check of the flash boot loader, and then continues the upgrade process. After the APP upgrade is completed, the MCU is reset, the BM is started, and then the APP secure boot check is performed.

[0138] The secure boot of MCU is achieved by running a boot program (boot) at address zero, which is stored in OTP. Secure boot is achieved through CSEC in MCU, that is, when the program specifies the Flash address range that needs to be verified, CSEC can calculate the MAC value of the address range by itself and compare it with the given MAC value. If they are consistent, it returns a successful secure boot and starts the application; if they are inconsistent, it returns a failed secure boot and resets the execution verification.

[0139] In some embodiments, loading the key set includes: registering an electronic control unit master key, the electronic control unit master key being a boot key; registering a boot message authentication code key, a boot message authentication code, and a user key to a data flash unit in a cryptographic security engine module (CSEC) through the boot key.

[0140] For example, before executing the secure boot command, it is necessary to register the boot key (ECU MASTER KEY), and then register the BOOT MAC KEY (boot message authentication code key), BOOT MAC (boot message authentication code) and USER_KEY1 (user key) into CSEC (encryption security engine module) through the boot key.

[0141] Among them, the MCU uses the electronic control unit master key (ECU MASTER KEY) as the boot key to generate the Load Key. MASTER_ECU_KEY is a master key stored in the electronic control unit (ECU) for a long time, which is used to generate and verify other security-related keys. During the startup process, MASTER_ECU_KEY is used to generate the Load Key. The Load Key is the key used to encrypt the startup image (such as boot.img, system.img, etc.). During the startup process, the MCU uses the Load Key to encrypt the startup image to ensure that only authorized code can run on the MCU.

[0142] BOOT_MAC_KEY is the key used to generate BOOT MAC. BOOT MAC is a message authentication code used to verify the integrity of the boot image. During the boot process, the MCU generates BOOT MAC using BOOT_MAC_KEY and compares it with the BOOT MAC in the boot image to ensure that the boot image has not been tampered with.

[0143] USER_KEY1: is the key used to generate APP CMAC. Since the MCU does not support HASH operation, APP CMAC uses AES128 to calculate the entire APP. During the APP upgrade process, USER_KEY1 is used to generate APP CMAC to ensure the integrity of the APP.

[0144] BOOT_MAC: is a message authentication code calculated when the boot image is created and stored in secure storage (such as TPM or encrypted storage area). At startup, the MCU calculates the hash value of the boot image and then generates a BOOT MAC using BOOT_MAC_KEY. The system compares the calculated BOOT MAC with the BOOT MAC stored in the boot image to see if they are consistent. If they are consistent, the system believes that the boot image has not been tampered with and the boot is successful; if they are inconsistent, the system believes that the boot image may have been tampered with and the boot fails.

[0145] By using these keys and mechanisms, the vehicle system can ensure that data transmission and storage during the startup and upgrade process are encrypted, prevent malware attacks, and ensure the integrity and reliability of the system. This mechanism helps to improve the security of the vehicle system and prevent unauthorized software tampering and potential security threats.

[0146] In some embodiments, a secure startup check is performed on an application, including: generating a cryptographic message authentication code (CMAC) of a first application through an encryption algorithm and a user key; comparing the cryptographic message authentication code of the first application with a cryptographic message authentication code of a second application read through a read-only memory to obtain a second comparison result; if the second comparison result indicates that the cryptographic message authentication code of the first application is consistent with the cryptographic message authentication code of the second application, starting the application.

[0147] The application uses a password-based message authentication code (CMAC) for verification. The CMAC value will be stored in the upgrade file and stored in the read-only memory (ROM) after the upgrade. At startup, if the calculated CMAC value is consistent with the CMAC value stored in the ROM, the startup is successful, otherwise the startup fails.

[0148] Exemplarily, the USER_KEY1 used for APP verification is a 16-byte key used to generate the CMAC of the application. Since the MCU usually does not have a built-in hash function (HASH) processing capability, the APP CMAC (CMAC) uses the AES128 encryption algorithm (using the 128-bit AES encryption algorithm) to calculate the entire APP. The calculated APPCMAC length is 16 bytes, which can cover the data in the last 16 bytes of the APP segment to ensure the integrity of the application. Among them, APP CMAC is a message authentication code (Cipher-Based Message Authentication Code) calculated by the application. It is a message authentication code based on the AES encryption algorithm and is used to verify the integrity and authenticity of the data.

[0149] See also Figure 3 , Figure 3 is a flowchart of a secure startup method for a microcontroller provided in some embodiments of the present application, Figure 3 In the process, before executing the secure boot command, MASTER_ECU_KEY, BOOT_MAC_KEY, BOOT_MAC and USER_KEY are loaded in sequence. After the secret key is loaded, the MCU is restarted and secure boot verification is performed, wherein the secure boot verification includes the secure boot of the BM, and it is determined whether the secure boot verification is successful. If successful, the APP CMAC value in the ROM is read to determine whether the APP CMAC value generated by the encryption algorithm and the user key is consistent with the APP CMAC value read from the ROM. If they are consistent, the application is successfully started. If they are inconsistent, it returns to the secure boot verification stage. It should be understood that if multiple verifications fail, the startup fails.

[0150] After the SOC chip safety boot verification fails, the SOC cannot start, and the MCU chip records the diagnostic trouble code (DTC code). After the MCU safety boot verification fails, the MCU can be restarted once every period of time (for example, 90 seconds) and the safety boot verification can be re-performed. After multiple restart failures (for example, 5 times), the control signal conditioner (CSC) will enter the SOC abnormal state and record the DTC code through other domain controllers.

[0151] The above is an introduction to an embodiment of the secure startup method for the cockpit domain controller system provided in this application.

[0152] The implementation of the secure startup device for the cockpit domain controller system provided by the embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0153] Regarding the secure startup method of the cockpit domain controller system provided in the above embodiment, the present application embodiment also provides a secure startup device of the cockpit domain controller system, which is used to implement the above method, such as Figure 4 As shown, Figure 4 This is a schematic block diagram of a module of a safety startup device 400 of a cockpit domain controller system according to an embodiment of the present application. The safety startup device 400 of a cockpit domain controller system includes:

[0154] A first verification module 401 is used to verify the system image of the first operating system through a secure boot verification mechanism of the first operating system, where the first operating system is a system for implementing a first function of the vehicle, the first function including a real-time operating system task, vehicle network communication and / or advanced driving assistance;

[0155] The second verification module 402 is used to verify the trusted boot component of the first operating system by using the first signature verification public key after the system image of the first operating system passes the verification, and obtain first verification result indication information, the first verification result indication information is used to indicate whether the trusted boot component of the first operating system passes the verification, the trusted boot component of the first operating system stores the second signature verification public key of the trusted boot component of the second operating system, and the second signature verification public key is used to verify the trusted boot component of the second operating system; the trusted boot component of the second operating system stores the encrypted verification information of the second operating system, and the second operating system is a system for realizing the second function of the vehicle, and the second function includes an infotainment function;

[0156] A third verification module 403 is used to verify the image of the second operating system based on the encrypted verification information of the second operating system when the first verification result indication information indicates that the trusted boot component of the first operating system has passed the verification, and obtain second verification result indication information, where the second verification result indication information is used to indicate whether the image of the second operating system has passed the verification;

[0157] The starting module 404 is configured to start the system image of the second operating system through the virtual machine manager when the second verification result indication information indicates that the image of the second operating system has passed the verification.

[0158] It can be understood that the contents of the above method embodiments are all applicable to the present device embodiments, the functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0159] like Figure 5 As shown, the embodiment of the present application further provides an electronic device 500, the electronic device 500 includes a memory 501, one or more processors 502 ( Figure 5 Only one is shown) and a computer program stored in the memory 501 and executable on the processor 502. Wherein: the memory 501 is used to store software programs and units, and the processor 502 executes various functional applications and data processing by running the software programs and units stored in the memory 501 to obtain the resources corresponding to the above-mentioned preset events. Optionally, the processor 502 implements the above-mentioned safe startup method of the cockpit domain controller system by running the above-mentioned computer program stored in the memory 501.

[0160] The memory 501, as a non-transitory computer-readable medium, can be used to store non-transitory software programs and non-transitory computer executable programs. In addition, the memory 501 may include a high-speed random access memory, and may also include a non-transitory memory, such as at least one disk storage device, a flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include a memory remotely disposed relative to the processor, and these remote memories may be connected to the processor via a network.

[0161] It can be understood that the contents of the above method embodiments are all applicable to the electronic device embodiment, the functions specifically implemented by the electronic device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0162] The embodiment of the present application also provides a vehicle, which includes the above-mentioned safety startup device of the cockpit domain controller system or the above-mentioned electric drive assembly of the electronic device. Among them, the cockpit domain controller system of the vehicle is safely started by the safety startup method of the cockpit domain controller system, the safety startup device of the cockpit domain controller system or the electric drive assembly of the above-mentioned electronic device. Specifically, the vehicle can be a private car, such as a sedan, SUV, MPV or pickup truck. The vehicle can also be an operating vehicle, such as a van, bus, small truck or large trailer. The vehicle can be a gasoline vehicle or a new energy vehicle. When the vehicle is a new energy vehicle, it can be a hybrid vehicle or a pure electric vehicle.

[0163] It can be understood that the contents of the above method embodiments are all applicable to the present vehicle embodiment, the functions specifically implemented by the present vehicle embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0164] An embodiment of the present application also provides a computer program product, which includes a computer program. When the computer program is executed by one or more processors, it can implement the steps of the secure startup method of the cockpit domain controller system as described above.

[0165] It can be understood that the contents of the above method embodiments are all applicable to this computer program product, the functions specifically implemented by this computer program product embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0166] The embodiments of the present application provide a secure boot method, device, electronic device, vehicle, and computer program product for a cockpit domain controller system. By verifying the system image of the first operating system through the secure boot verification mechanism of the first operating system, the boot security of the system image of the first operating system can be ensured. After the system image of the first operating system passes the verification, the trusted boot component of the first operating system is verified through the first verification public key. Since the verification public key of the trusted boot component of the second operating system is stored in the trusted boot component of the first operating system, and the encrypted verification information of the second operating system is stored in the trusted boot component of the second operating system, after the trusted boot component of the first operating system passes the verification, the second operating system can be started based on the first verification public key. The encrypted verification information is used to verify the image of the second operating system, so as to ensure the safe startup of the second operating system, thereby improving the security of the cockpit domain controller system startup; further, the extended boot loader is verified and started by controlling the main boot loader; when the extended boot loader is successfully started, the extended boot loader is controlled to verify and start the execution environment, providing multiple layers of security and reliability, which can reduce the risk of system startup failure and thus improve the security and reliability of the system; by using multi-level keys and security verification mechanisms, the vehicle system can ensure that data transmission and storage during the startup and upgrade process are encrypted, prevent malware attacks, and ensure the integrity and reliability of the system. This mechanism helps to improve the security of the vehicle system and prevent unauthorized software tampering and potential security threats.

[0167] The embodiments described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0168] Although specific embodiments are described herein, those of ordinary skill in the art will recognize that many other modifications or alternative embodiments are also within the scope of the present disclosure. For example, any of the functions and / or processing capabilities described in conjunction with a particular device or component may be performed by any other device or component. In addition, although various exemplary implementations and architectures have been described according to embodiments of the present disclosure, those of ordinary skill in the art will recognize that many other modifications to the exemplary implementations and architectures herein are also within the scope of the present disclosure.

[0169] Some aspects of the present disclosure are described above with reference to the block diagram and flow chart of the system, method, system and / or computer program product according to the exemplary embodiments.It should be understood that the combination of one or more blocks in the block diagram and the flow chart and the blocks in the block diagram and the flow chart can be realized by executing computer executable program instructions respectively.Equally, according to some embodiments, some blocks in the block diagram and the flow chart may not need to be executed in the order shown, or may not need to be executed in full.In addition, additional components and / or operations beyond those components and / or operations shown in the blocks in the block diagram and the flow chart may be present in certain embodiments.

[0170] Therefore, the blocks in the block diagrams and flow charts support the combination of devices for performing the specified functions, the combination of elements or steps for performing the specified functions, and the program instruction devices for performing the specified functions. It should also be understood that each block in the block diagrams and flow charts and the combination of blocks in the block diagrams and flow charts can be implemented by a special-purpose hardware computer system or a combination of special-purpose hardware and computer instructions that performs a specific function, element or step.

[0171] The program modules, applications, etc. described herein may include one or more software components, including, for example, software objects, methods, data structures, etc. Each such software component may include computer-executable instructions that, in response to execution, cause at least a portion of the functionality described herein (e.g., one or more operations of the illustrative methods described herein) to be performed.

[0172] Software components can be encoded with any of various programming languages. An exemplary programming language can be a low-level programming language, such as an assembly language associated with a specific hardware architecture and / or an operating system platform. The software component comprising assembly language instructions may need to be converted to executable machine code by an assembler before being executed by hardware architecture and / or platform. Another exemplary programming language can be a higher-level programming language, which can be transplanted across multiple architectures. The software component comprising a higher-level programming language may need to be converted to an intermediate representation by an interpreter or a compiler before execution. Other examples of programming languages ​​include but are not limited to macro languages, shells or command languages, job control languages, scripting languages, database queries or search languages ​​or report writing languages. In one or more exemplary embodiments, the software component comprising the instruction of one of the above-mentioned programming language examples can be directly executed by an operating system or other software components, without first being converted into another form.

[0173] Software components may be stored as files or other data storage structures. Software components of similar type or related functions may be stored together, such as in a specific directory, folder, or library. Software components may be static (e.g., preset or fixed) or dynamic (e.g., created or modified at execution time).

[0174] The embodiments of the present application are described in detail above in conjunction with the accompanying drawings, but the present application is not limited to the above embodiments, and various changes can be made within the knowledge scope of ordinary technicians in the relevant technical field without departing from the purpose of the present application.

Claims

1. A method for securely starting a cockpit domain controller system, characterized in that: The following steps are involved: Verifying a system image of the first operating system through a secure boot verification mechanism of the first operating system, the first operating system being a system for implementing a first function of the vehicle, the first function including a real-time operating system task, vehicle network communication, and / or advanced driver assistance; After the system image of the first operating system passes the verification, the trusted boot component of the first operating system is verified by using the first signature verification public key to obtain first verification result indication information; wherein the trusted boot component of the first operating system stores a second signature verification public key corresponding to the trusted boot component of the second operating system, and the second signature verification public key is used to verify the trusted boot component of the second operating system; the trusted boot component of the second operating system stores encrypted verification information of the second operating system, and the second operating system is a system for realizing a second function of the vehicle, and the second function includes an infotainment function; If the first verification result indication information indicates that the trusted boot component of the first operating system has passed the verification, verifying the image of the second operating system based on the encrypted verification information of the second operating system to obtain second verification result indication information; If the second verification result indication information indicates that the image of the second operating system has passed the verification, the system image of the second operating system is started through the virtual machine manager.

2. The secure startup method of the cockpit domain controller system according to claim 1, characterized in that: The image of the second operating system includes a boot image and a system image, and the verifying the image of the second operating system based on the encrypted verification information of the second operating system includes: Verifying the startup image of the second operating system based on the encrypted verification information of the second operating system to obtain third verification result indication information; If the third verification result indication information indicates that the startup image of the second operating system has passed the verification, the system image of the second operating system is verified by the startup image of the second operating system according to the public key of the root hash to obtain fourth verification result indication information.

3. The secure startup method of the cockpit domain controller system according to claim 2, characterized in that: The second verification result indication information includes the third verification result indication information and the fourth verification result indication information, and if the second verification result indication information indicates that the image of the second operating system passes the verification, starting the system image of the second operating system through the virtual machine manager includes: If the third verification result indication information indicates that the startup image of the second operating system has passed the verification, starting the startup image of the second operating system through the virtual machine manager; In the case where the startup image of the second operating system is successfully started, if the fourth verification result indication information indicates that the system image of the second operating system has passed the verification, the system image of the second operating system is started through the virtual machine manager.

4. The secure startup method of the cockpit domain controller system according to claim 1, characterized in that: Before verifying the system image of the first operating system by the secure boot verification mechanism of the first operating system, the secure boot method of the cockpit domain controller system further includes: In response to a start trigger signal of the system-level chip, controlling the main boot loader to verify and start the extended boot loader; When the extended boot loader is successfully started, the extended boot loader is controlled to check and start the execution environment.

5. The secure startup method of the cockpit domain controller system according to claim 4, characterized in that: The extended boot loader stores a root certificate for secure booting, and the controlling main boot loader verifies and starts the extended boot loader, including: Calculating a hash value of the root certificate, and comparing the hash value with a hash value of the secure boot root certificate stored in the electronic fuse to obtain a first comparison result; If the first comparison result indicates that the calculated hash value of the root certificate is the same as the hash value of the secure boot root certificate stored in the electronic fuse, verifying the image of the extended boot loader by using the secure boot root certificate to obtain fifth verification result indication information; If the fifth verification result indication information indicates that the image of the extended boot loader has passed the verification, the extended boot loader is started through the main boot loader.

6. The secure startup method of the cockpit domain controller system according to claim 1, characterized in that: The method further comprises the step of securely starting the microcontroller, wherein the securely starting microcontroller comprises: Loading a key set, the key set including multiple levels of keys, the key set stored in an encryption security engine module; In response to a secure boot command, verifying the boot management in the microcontroller by using the key in the key set to obtain sixth verification result indication information; If the sixth verification result indication information indicates that the startup management verification in the microcontroller has passed, a secure startup verification is performed on the application.

7. The secure startup method of the cockpit domain controller system according to claim 6, characterized in that: The loading key set includes: Registering an electronic control unit master key, where the electronic control unit master key is a boot key; The boot message authentication code key, the boot message authentication code and the user key are registered to the data flash memory unit in the encryption security engine module through the boot key.

8. The secure startup method of the cockpit domain controller system according to claim 6, characterized in that: The secure startup verification of the application includes: generating a cryptographic message authentication code of the first application using an encryption algorithm and a user key; Comparing the cryptographic message authentication code of the first application with the cryptographic message authentication code of the second application read through the read-only memory to obtain a second comparison result; If the second comparison result indicates that the cryptographic message authentication code of the first application is consistent with the cryptographic message authentication code of the second application, the application is started.

9. A safe startup device for a cockpit domain controller system, characterized in that: The device comprises: A first verification module, configured to verify a system image of a first operating system through a secure boot verification mechanism of the first operating system, wherein the first operating system is a system for implementing a first function of a vehicle, wherein the first function includes a real-time operating system task, vehicle network communication, and / or advanced driver assistance; a second verification module, configured to verify the trusted boot component of the first operating system by using the first signature verification public key after the system image of the first operating system passes the verification, and obtain first verification result indication information; wherein the trusted boot component of the first operating system stores the second signature verification public key corresponding to the trusted boot component of the second operating system, and the second signature verification public key is used to verify the trusted boot component of the second operating system; the trusted boot component of the second operating system stores the encrypted verification information of the second operating system, and the second operating system is a system for realizing a second function of the vehicle, and the second function includes an infotainment function; a third verification module, configured to verify the image of the second operating system based on the encrypted verification information of the second operating system to obtain second verification result indication information when the first verification result indication information indicates that the trusted boot component of the first operating system has passed the verification; A startup module is used to start the system image of the second operating system through the virtual machine manager when the second verification result indication information indicates that the image of the second operating system has passed the verification.

10. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the secure startup method of the cockpit domain controller system as described in any one of claims 1 to 8 when executing the computer program.

11. A vehicle, characterized in that: The vehicle's cockpit domain controller system is securely started by the secure startup method for the cockpit domain controller system as described in any one of claims 1 to 8, by the secure startup device for the cockpit domain controller system as described in claim 9, or by the electronic device as described in claim 10.

Images