Security policy construction method, device and equipment of in-vehicle infotainment system and vehicle

Abstract

The invention discloses a safety strategy construction method, device and equipment of a vehicle-mounted infotainment system and a vehicle, and relates to the technical field of vehicles, and the safety strategy construction method of the vehicle-mounted infotainment system comprises the steps that the types of hardware parts in the vehicle-mounted infotainment system are determined, and the types of the hardware parts comprise debugging interfaces; constructing a corresponding security policy according to the type of the hardware component so as to enable the hardware component to operate safely; wherein the security policy corresponding to the debugging interface comprises the security policy of the debugging interface corresponding to the production stage of the vehicle machine. Therefore, by determining the types of the hardware parts in the vehicle-mounted terminal system and constructing the corresponding safety strategy according to the determined types of the hardware parts, comprehensive safety protection of the vehicle-mounted terminal system can be achieved, and the safety risk of the vehicle-mounted terminal system is further reduced through the safety strategy of the debugging interface corresponding to the production stage of the vehicle-mounted terminal, so that the safety of the vehicle-mounted terminal system is improved. And the defense capability of the vehicle machine system is enhanced.

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 constructing a security strategy for a vehicle-mounted system. Background Art

[0002] With the rapid iteration of software and hardware technologies such as automotive chips, human-computer interaction, and automotive systems, the automotive cockpit has begun to enter the intelligent stage. The cockpit system has gradually shifted from physical buttons to full touch and voice interaction. The smart cockpit can significantly improve the intelligent experience of the car and has gradually become one of the important factors affecting consumers' car purchases.

[0003] As more and more functions are installed in the smart cockpit, the information security of the vehicle is becoming increasingly prominent. The security issues in the vehicle computer system are also the focus of attention. Many information intrusions invade the vehicle computer system through hardware and endanger the security of the software.

[0004] There are still security risks in the security protection of the vehicle computer system in the relevant technology, resulting in insufficient defense capabilities of the vehicle computer system. 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 constructing a security strategy for a vehicle system, aiming to enhance the defense capability of the vehicle system.

[0006] To achieve the above-mentioned purpose, one aspect of an embodiment of the present application proposes a method for constructing a security policy for a vehicle-computer system, comprising the following steps: determining the types of hardware components in the vehicle-computer system, the types of hardware components including debugging interfaces; constructing corresponding security policies according to the types of hardware components to enable the safe operation of the hardware components; wherein the security policy corresponding to the debugging interface includes the security policy of the debugging interface corresponding to the production stage of the vehicle-computer.

[0007] In some embodiments, the corresponding security policy is constructed according to the type of hardware components, including: if the production stage of the vehicle computer is the mass production debugging stage, then executing the corresponding first security operation according to the type of the debugging interface; if the production stage of the vehicle computer is the post-mass production and pre-shipment stage, then executing the corresponding second security operation according to the type of the debugging interface.

[0008] In some embodiments, the first security operation includes verifying a security identifier, and the first security operation corresponding to the type of the debug interface is performed, including: if the debug interface is a joint test action group interface, verifying the security identifier in the microcontroller unit and the security identifier in the compiled software to obtain a verification result; and determining whether the joint test action group interface is securely connected based on the verification result.

[0009] In some embodiments, the first security operation includes limiting debugging functions and / or removing packaging traces, and performing the corresponding first security operation according to the type of the debugging interface includes: if the debugging interface is a universal asynchronous receiver and transmitter interface of a chip-level system, then limiting the debugging function of the universal asynchronous receiver and transmitter interface and / or removing the packaging traces of the universal asynchronous receiver and transmitter interface.

[0010] In some embodiments, the first security operation includes identity authentication, and the corresponding first security operation is performed according to the type of the debugging interface, including: if the debugging interface is a network interface, and the debugging tool debugs the software system in the vehicle system through the network interface, then the client and server connected to the debugging tool are authenticated; and according to the result of the identity authentication, it is determined whether the debugging tool is securely connected through the network interface.

[0011] In some embodiments, the second security operation includes closing the debugging interface and turning off the debugging function, and the corresponding second security operation is performed according to the type of the debugging interface, including: if the debugging interface is a joint test action group interface or a universal asynchronous receiver and transmitter interface, then closing the debugging interface and turning off the debugging function of the debugging interface.

[0012] In some embodiments, the second security operation includes at least one of turning off the debugging function, setting a function switch, removing superuser permissions, enabling secure boot and verification functions, or controlling the debugging tool's permission to obtain log files. The corresponding second security operation is performed according to the type of the debugging interface, including: if the debugging interface is a network interface, and the debugging tool debugs the software system in the vehicle system through the network interface, then performing at least one of the following operations: turning off the debugging function of the debugging tool; setting a function switch corresponding to the debugging tool based on the factory mode of the vehicle system, wherein the factory mode is securely accessed through preset gestures and passwords; removing superuser permissions and enabling secure boot and verification functions; controlling the debugging tool's permission to obtain log files.

[0013] In some embodiments, the types of hardware components include circuit boards and chips, and the corresponding security policies constructed according to the types of hardware components include at least one of the following: if the chip has data processing capabilities and data computing capabilities, erasing key information of the chip, the key information including the brand logo of the chip, the design mark of the chip and the parameter information of the chip; dispensing the chip with data storage function with anti-disassembly glue; hiding the design mark on the circuit board.

[0014] In some embodiments, there is sensitive information in the vehicle system, and the method also includes the step of constructing a corresponding security policy for the sensitive information, wherein the corresponding security policy for the sensitive information includes: if the vehicle system is equipped with a hardware security module, a security chip or a security service, then controlling the encryption operation of the sensitive information in the vehicle system to run in the hardware security module, the security chip or the security service; and securely storing the sensitive information in a trusted environment provided by the security service.

[0015] In some embodiments, there is firmware code in the vehicle system, and the method also includes the step of building a corresponding security policy for the firmware code, wherein the building of the corresponding security policy for the firmware code includes: obfuscating or specially compiling the firmware code; if the firmware code is the firmware code of a microcontroller unit, the firmware code is stored in a flash memory in the microcontroller unit; if the firmware code is the firmware code of a chip-level system, the firmware code is stored in an external embedded multi-card storage card.

[0016] To achieve the above-mentioned purpose, another aspect of an embodiment of the present application proposes a security policy construction device for a vehicle-computer system, wherein the security policy construction device for the vehicle-computer system includes: a determination module, used to determine the types of hardware components in the vehicle-computer system, wherein the types of hardware components include debugging interfaces; a construction module, used to construct corresponding security policies according to the types of hardware components to enable the safe operation of the hardware components; wherein the security policy corresponding to the debugging interface includes the security policy of the debugging interface corresponding to the production stage of the vehicle-computer.

[0017] 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, wherein the memory stores a computer program, and the processor implements the security policy construction method of the above-mentioned vehicle system when executing the computer program.

[0018] To achieve the above-mentioned purpose, another aspect of an embodiment of the present application proposes a vehicle, wherein the vehicle-mounted system of the vehicle is security designed through any of the above-mentioned vehicle-mounted system security policy construction methods, the above-mentioned vehicle-mounted system security policy construction devices or the above-mentioned electronic devices.

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

[0020] The present application provides a method, device, equipment and vehicle for constructing a security policy for a vehicle system. In an embodiment of the present application, first, the types of hardware components in the vehicle system are determined, and the types of hardware components include debugging interfaces; then, corresponding security policies are constructed according to the types of hardware components to ensure the safe operation of the hardware components; wherein the security policies corresponding to the debugging interfaces include the security policies of the debugging interfaces corresponding to the production stage of the vehicle system. Thus, by determining the types of hardware components in the vehicle system and constructing corresponding security policies according to the determined types of hardware components, comprehensive security protection of the vehicle system can be achieved, and by using the security policies of the debugging interfaces corresponding to the production stage of the vehicle system, the security risks of the vehicle system can be further reduced, thereby enhancing the defense capability of the vehicle system.

[0021] 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

[0022] 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:

[0023] Figure 1 is a flow chart of a method for constructing a security strategy for a vehicle system provided by some embodiments of the present application;

[0024] Figure 2 is a schematic block diagram of the safety design of the vehicle system provided by some embodiments of the present application;

[0025] Figure 3 is a schematic block diagram of modules of a security policy building device for a vehicle system provided by some embodiments of the present application;

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

[0027] 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.

[0028] 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".

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] UART: UART refers to Universal Asynchronous Receiver / Transmitter interface, a universal serial data transmission interface. The main function of the UART interface is to provide a convenient way to connect two devices, which can help users transmit data between different devices.

[0034] JTAG: JTAG interface is a standard interface for testing and debugging integrated circuits, which aims to provide a standardized method of communication and control between multiple chips. JTAG interface usually consists of four lines, namely TCK (clock signal), TMS (state selection), TDI (data input) and TDO (data output), which can be used to control the test mode of the target chip and read its internal state.

[0035] ADB: ADB stands for Android Debug Bridge, which is a versatile command-line tool that allows devices to communicate with each other. ADB commands can be used to perform various device operations, such as installing and debugging applications. ADB provides access to a Unix shell that can be used to run various commands on the device.

[0036] T-Box: T-Box refers to the vehicle-mounted communication terminal, which is mainly responsible for functions such as Internet access.

[0037] HSM: HSM is the abbreviation of Hardware Security Module. HSM is a computer device used to protect and manage keys and sensitive data used by strong authentication systems and provide related cryptographic operations.

[0038] TrustZone: TrustZone is a security technology developed by ARM to prevent the limited resources of a device from being copied, destroyed or tampered with. TrustZone is a hardware-based security technology supported on ARM processors. It distinguishes between the secure world and the non-secure world by adding a CPU security mode, and uses the security identification bit of the chip bus to distinguish access modes.

[0039] TEE: TEE is a security technology that provides an isolated execution environment. It allows security-related code to be run on top of a normal operating system (such as Linux), such as fingerprint matching and private key signature actions during payment. TEE has its own execution space, where the security level of the operating system running is higher than that of a normal operating system, but lower than that of a secure element (such as a smart card). TEE can protect the security, integrity and access rights of its internal resources and data, and each trusted application (TA) is independent of each other and requires authorization.

[0040] MCU: MCU means microcontroller unit.

[0041] SOC: SOC refers to a chip-level system, which is mainly used to process audio signals, video signals, image signals and other signals of the vehicle system.

[0042] With the rapid iteration of software and hardware technologies such as automotive chips, human-computer interaction, and automotive systems, the automotive cockpit has begun to enter the intelligent stage. The cockpit system has gradually shifted from physical buttons to full touch and voice interaction. The smart cockpit can significantly improve the intelligent experience of the car and has gradually become one of the important factors affecting consumers' car purchases.

[0043] As more and more functions are installed in the smart cockpit, the information security of the vehicle is becoming increasingly prominent. The security issues in the vehicle computer system are also the focus of attention. Many information intrusions invade the vehicle computer system through hardware and endanger the security of the software.

[0044] There are still security risks in the security protection of the vehicle computer system in the relevant technology, resulting in insufficient defense capabilities of the vehicle computer system.

[0045] In view of this, the present application proposes a method, device, equipment and vehicle for constructing a security policy for a vehicle-mounted system. The solution determines the types of hardware components in the vehicle-mounted system, and the types of hardware components include debugging interfaces. Then, a corresponding security policy is constructed according to the types of hardware components to ensure the safe operation of the hardware components. Among them, the security policy corresponding to the debugging interface includes the security policy of the debugging interface corresponding to the production stage of the vehicle-mounted system. Therefore, by determining the types of hardware components in the vehicle-mounted system and constructing the corresponding security policy according to the determined types of hardware components, comprehensive security protection of the vehicle-mounted system can be achieved. Through the security policy of the debugging interface corresponding to the production stage of the vehicle-mounted system, the security risk of the vehicle-mounted system can be further reduced, thereby enhancing the defense capability of the vehicle-mounted system.

[0046] 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 a terminal or a server.

[0047] The terminal may be a tablet computer, a laptop computer, a vehicle-mounted computer, a desktop computer, etc., but is not limited thereto.

[0048] The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content distribution networks, as well as big data and artificial intelligence platforms.

[0049] The following will describe in detail the implementation steps of a method for constructing a security strategy for a vehicle system provided by an embodiment of the present application in conjunction with the accompanying drawings.

[0050] Please refer to Figure 1 , Figure 1 A flowchart of a method for constructing a security policy for a vehicle-mounted 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 may be executed in an order different from that shown here.

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

[0052] Step 101: Determine the types of hardware components in the vehicle system, where the types of hardware components include a debugging interface;

[0053] Step 102: construct corresponding security policies according to the types of hardware components to ensure safe operation of the hardware components;

[0054] Among them, the security policy corresponding to the debugging interface includes the security policy of the debugging interface corresponding to the production stage of the vehicle computer.

[0055] Steps 101 to 102 shown in the embodiment of the present application can achieve comprehensive security protection for the vehicle system by determining the types of hardware components in the vehicle system and constructing corresponding security policies based on the determined types of hardware components. The security policy of the debugging interface corresponding to the production stage of the vehicle system can further reduce the security risk of the vehicle system, thereby enhancing the defense capability of the vehicle system.

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

[0057] In step 101, the types of hardware components in the vehicle system are determined, wherein the types of hardware components include a debugging interface.

[0058] The vehicle system, also known as the in-vehicle infotainment system, has the following hardware components: microcontroller unit (MCU), which is the core of the vehicle system and is responsible for processing data and running the operating system; memory (RAM), which provides data storage during runtime and affects the response speed of the system; storage, including flash memory, is used to store operating systems and applications; hard disk drives (HDD) or solid-state drives (SSD), provide larger data storage space; connection interfaces, including USB ports, are used to connect external devices such as USB drives, smartphones, etc.; AUX inputs are used to connect external audio devices; Bluetooth modules are used to wirelessly connect external devices such as mobile phones and headphones; GPS modules are used for navigation and location services; communication modules, including 4G / 5G modems, are used for Internet connection; Wi-Fi modules are used to provide wireless network connection; debugging interfaces, such as JTAG, serial ports, etc., are used for hardware debugging and software development; circuit boards, including main circuit boards and possible other functional circuit boards, on which many of the above hardware components are integrated. These hardware components together form the physical foundation of the vehicle system. They work in coordination with software to provide users with functions such as navigation, entertainment, communication and vehicle information.

[0059] Among them, the hardware components that need to be protected may include debugging interfaces, circuit boards, chips, etc. Among them, the debugging interfaces may include UART interfaces, JTAG interfaces, and network interfaces, etc.

[0060] The embodiments provided in the present application provide a basis for constructing corresponding security policies for the types of hardware components by determining the types of hardware components in the vehicle system.

[0061] In step 102, a corresponding security policy is constructed according to the type of hardware component to ensure the safe operation of the hardware component.

[0062] According to the type of the hardware component determined in step 101, a corresponding security policy can be constructed according to the determined type of the hardware component and its potential security risk to ensure the safe operation of the corresponding hardware component.

[0063] In some embodiments, the security policy corresponding to the debugging interface includes the security policy of the debugging interface corresponding to the production stage of the vehicle computer. Optionally, constructing a corresponding security policy for the debugging interface includes: if the production stage of the vehicle computer is the mass production debugging stage, then the corresponding first security operation can be executed according to the type of the debugging interface; if the production stage of the vehicle computer is the post-mass production and pre-shipment stage, then the corresponding second security operation can be executed according to the type of the debugging interface.

[0064] It should be understood that the debugging interface includes multiple interfaces, and illustratively, it can be a JTAG port or a UART interface.

[0065] For different debugging interfaces, since they face different security risks, corresponding security policies can be built to protect them. For example, a security policy can be built for the JTAG port; or a security policy can be built for the UART interface.

[0066] The security strategy built for the debugging interface can also correspond to the production stage of the vehicle computer.

[0067] Optionally, if the vehicle is in the mass production debugging stage, then the corresponding first security operation can be performed for different debugging interfaces. It should be understood that the first security operation is a corresponding security operation designed for the security risks that may exist in different debugging interfaces during the mass production debugging stage of the vehicle. Among them, the first security operation can be an encryption operation, an identity authentication operation, a restricted debugging operation, etc.

[0068] Exemplarily, during the mass production and debugging of vehicle computers, the protection of the debugging interface (the first security operation) may include access control, including identity authentication and permission classification. Identity authentication can ensure that only authenticated users or devices can access the debugging interface; permission classification can set different access rights for different debugging personnel or teams to limit access to sensitive functions. The protection of the debugging interface may also include physical security, such as protecting the debugging port with a physical lock or other mechanism to prevent unauthorized physical connection; or hiding or blocking the debugging port during design to make it difficult to be discovered. The protection of the debugging interface may also include communication encryption, including using encryption protocols such as SSL / TLS to encrypt the communication data of the debugging interface, or ensuring that the debugging data is encrypted when stored to prevent data leakage.

[0069] Optionally, if it is the stage before the vehicle is shipped after mass production, then the corresponding second safety operation can be performed for different debugging interfaces. It should be understood that the second safety operation is a corresponding safety operation designed for the security risks that may exist in different debugging interfaces at this stage after the mass production and debugging stage of the vehicle and before the factory stage. Among them, the second safety operation can be closing or disabling the debugging interface, removing superuser permissions, enabling secure boot and verification functions, and controlling the debugging tool to obtain log files, etc.

[0070] Exemplarily, after the mass production debugging of the vehicle computer is completed, the security protection operation (second security operation) of the debugging interface before leaving the factory can include closing or disabling the debugging interface, including ensuring that all debugging interfaces (such as JTAG, serial port, debugging network port, etc.) are restricted or closed at the hardware or software level; for hardware debugging interfaces, it can also be achieved by removing jumpers, welding off switches, or physically disconnecting them on the circuit board. The second security operation can also include clearing or overwriting all startup options and configuration files for debugging, clearing the storage space for air conditioning trials, ensuring that there is no residual debugging information, restoring system settings to the factory default state, ensuring that there is no special configuration during debugging, encrypting the system to ensure data security, and locking the basic input / output system (BIOS) / unified extensible firmware interface (UEFI) and other underlying system settings to prevent unauthorized modifications.

[0071] In some embodiments, during the mass production debugging of the vehicle computer, if the debugging interface is a joint test action group interface, then the security identifier in the microcontroller unit and the security identifier in the compiled software can be verified to obtain a verification result; based on the verification result, it is determined whether the joint test action group interface is securely connected; wherein, the first security operation includes verifying the security identifier.

[0072] Exemplarily, during the mass production debugging of the vehicle computer, the JTAG interface can be set to be only provided to the vehicle computer MCU, and the model of the vehicle computer MCU can be RH850. During the mass production stage of the vehicle computer, the security identifier (secure ID) can be packaged into an .img format and burned into the MCU. When debugging in the mass production stage, the JTAG debugging interface of the MCU is connected to the JTAG debugging tool (i.e., JTAG tool) on the PC side to verify whether the secure ID of the MCU matches the secure ID of the JTAG debugging tool. If they match, then the connection between the MCU and the JTAG debugging tool is established; if they do not match, the connection between the PC and the MCU cannot be established through the JTAG tool.

[0073] In some embodiments, during the mass production debugging of the vehicle computer, if the debugging interface is a universal asynchronous receiver-transmitter interface of a chip-level system, then the debugging function of the universal asynchronous receiver-transmitter interface can be limited and / or the packaging traces of the universal asynchronous receiver-transmitter interface can be removed; wherein, the first safety operation includes limiting the debugging function and / or removing the packaging traces.

[0074] Exemplarily, the UART interface of the vehicle computer SOC is set to be used only for the output function of the log file (log). During the mass production and debugging process of the vehicle computer, no obvious interface package is left on the shell at the hardware level corresponding to the UART interface, and the UART serial port printing driver is removed at the software level, that is, the debugging function is restricted or prohibited.

[0075] Optionally, the vehicle MCU is also equipped with a UART communication interface. UART is mainly used to output log information (sensitive information is not included in the log information) and receive debugging commands sent by special debugging tools. In the mass production stage, when the UART communication interface receives the debugging command sent by the special debugging tool, it checks the password corresponding to the debugging command. Only when the check is successful can the data of the vehicle system be read. During the interface retention period, the UART shell has no obvious packaging at the hardware level.

[0076] In some embodiments, during the mass production debugging of the vehicle computer, if the debugging interface is a network interface, and the debugging tool debugs the software system in the vehicle computer system through the network interface, identity authentication is set for the client and server connected to the debugging tool; and based on the result of the identity authentication, it is determined whether the debugging tool is securely connected through the network interface.

[0077] The network interface of the vehicle system may include a Wi-Fi interface and an Ethernet interface, which is not limited in this application.

[0078] The debugging tool involved in the vehicle system may be an ADB debugging tool, wherein the ADB debugging tool can debug the software system in the vehicle system through a network interface.

[0079] During the debugging of the vehicle system through the network interface, it is necessary to set the identity authentication information for both ends of the debugging tool connection, and authenticate the identities of the client and the server during the debugging connection. If the identity authentication is successful, the debugging tool can debug the software of the vehicle system through the network interface. If the authentication is unsuccessful, a valid connection cannot be established.

[0080] Exemplarily, if ADB is used for debugging, the debugging permission control policy needs to be used to protect the debugging function. The ADB debugging service enables the PC to establish a connection with the vehicle system through the hotspot of the T-Box. After a secure connection is established, the PC can access the vehicle to read data, install APK (APK is a file format used by the Android operating system, which contains all components of Android applications), change configurations, and other operations. To ensure that the service is not used maliciously by attackers, identity authentication is added to the client and server connected to the ADB debugging bridge, such as high-intensity password protection, certificate-based identity authentication, etc. If the identity authentication is passed, ADB can establish a connection through the hotspot provided by the T-Box. If the identity authentication is not passed, ADB cannot be used to debug the vehicle system. It should be understood that the hotspot provided by the T-Box is a trusted network hotspot.

[0081] The embodiments provided in the present application can enhance the defense capability of the system and effectively reduce the risk of network attacks and data leakage by executing corresponding first security operations for different debugging interfaces during the mass production and debugging stage of the vehicle computer.

[0082] In some implementations, before the vehicle machine leaves the factory, if the debugging interface is a joint test action group interface or a universal asynchronous receiver / transmitter interface, the debugging interface is closed and the debugging function of the debugging interface is disabled.

[0083] For example, before the car machine leaves the factory, the UART interface and JTAG interface with debugging function should be closed. Ensure that there is no debugging port on the car machine housing, the test points of the debugging interface on the PCB board of the car machine should be deployed in a dispersed manner, and the debugging function of the UART interface and JTAG interface should be turned off at the software level, which can be achieved by removing the debugging interface driver.

[0084] In some embodiments, before the vehicle computer leaves the factory, if the debugging interface is a network interface, and the debugging tool debugs the software system in the vehicle computer system through the network interface, at least one of the following operations is performed: turning off the debugging function of the debugging tool; setting the function switch of the corresponding debugging tool based on the factory mode of the vehicle computer system, wherein the factory mode is securely accessed through specific gestures and passwords; removing superuser permissions and enabling secure boot and verification functions; and controlling the debugging tool's permissions to obtain log files.

[0085] For example, before the car is shipped out of the factory, the ADB debugging function is turned off, that is, the Android debugging bridge function of the car system is ensured to be turned off. Considering the subsequent maintenance and inspection of the car, the factory mode can be set for the car system. The factory mode is a special mode, which is mainly used to provide more system information and debugging tools when the car system needs maintenance or diagnosis, to help technicians detect hardware and software problems, or perform system recovery. When the car system has serious problems, such as software crashes, virus infections, or chaotic system settings, the system is restored to the factory state through the factory mode, that is, all user data and settings are deleted to return the system to its initial state.

[0086] Based on the factory mode of the vehicle system, the debugging switch for the ADB debugging function can be set. By default, the debugging switch is off. In factory mode, when the Android debugging bridge on the PC is used to debug the vehicle system, verify whether the bridge permission is available (whether it is a specific person). If so, enable the Android debugging bridge function and build a connection between the vehicle system and the Android debugging bridge through the T-Box hotspot to read the data of the vehicle system, install APK for the vehicle system, and change the configuration parameters of the vehicle system. It should be understood that specific gestures and passwords will be set for protection of the factory mode. The entry method of the factory mode is only provided to specific debuggers, developers, etc., and other users are restricted from entering.

[0087] Before the car is shipped out of the factory, the root permission (superuser permission) of the ADB debugging function will be removed, and the secure boot and verification functions will be enabled. At this time, if the ADB debugging connection is established, it will only have limited permission to obtain logs, and cannot install APKs or modify configuration files.

[0088] The embodiment provided in the present application performs the corresponding second security operation for different debugging interfaces before the vehicle computer leaves the factory, takes into account the security risks that the vehicle computer may face after leaving the factory, improves the security measures, further enhances the defense capability of the system, and reduces the risk of the vehicle computer system being subject to security incidents.

[0089] In some embodiments, the types of hardware components include circuit boards and chips, and corresponding security policies are constructed according to the types of hardware components, including at least one of the following: if the chip has data processing capabilities and data computing capabilities, erasing key information of the chip, the key information includes the brand logo of the chip, the design mark of the chip, and the parameter information of the chip; dispensing anti-disassembly glue on the chip with data storage function; hiding the design mark on the circuit board.

[0090] Exemplarily, for the chips and circuit boards in the vehicle system, it is necessary to use glue with chip anti-disassembly function to dispense glue on the storage chip. It is necessary to erase or smear key information of the chips with data processing and computing capabilities on the vehicle circuit board in the mass production version, hide the design logo on the printed circuit board (PCB board), the design logo, logo, parameters and other key information of the chip, increase the cost and threshold of hardware-level attacks, and increase the time for attackers to collect information. It is forbidden to leak the test port during mass production to prevent attackers from stealing internal chip information and using test points to infiltrate the onboard system. Reduce the exposure of input / output pins to prevent the firmware information from being read after the storage chip is removed. This improves the security of chips and circuit boards in the vehicle system.

[0091] In some implementations, the vehicle system also contains sensitive information, and the method provided in the embodiment of the present application includes the step of constructing a corresponding security policy for the sensitive information. Constructing a corresponding security policy for sensitive information includes: if the vehicle system has a hardware security module, a security chip, or a security service, then controlling the encryption operation of the sensitive information in the vehicle system to run in the hardware security module, the security chip, or the security service; and securely storing the sensitive information in a trusted environment provided by the security service.

[0092] Exemplarily, sensitive data information that needs to be securely stored in the vehicle system includes the following: system configuration files, Wi-Fi service set identifier and password, vehicle identification number (VIN), in-vehicle network secure transmission authentication key, certificate, key; key information used in networked applications; user personal information: such as address book, ID card information, operation habit log, etc.

[0093] Exemplarily, the sensitive data information that needs to be securely stored in the infotainment system in the vehicle includes the following: key information used for secure startup, key information used for local upgrades, Wi-Fi passwords, key information used for vehicle application verification, key information used for payment functions, key information used in networked applications, and user personal information: such as face, voiceprint, password, etc.

[0094] Sensitive data information on the infotainment system and sensitive information in the vehicle system need to be securely stored, and the keys used for sensitive data or secure storage should be placed in the secure and controlled storage area inside the chip. If there is an HSM module or a security chip, sensitive data is stored in the HSM or security chip. If there is no HSM and security chip, secure storage should be implemented based on the secure root of trust provided by TrustZone or TEE.

[0095] When the car computer is connected to the mobile phone via Bluetooth, the car computer will create a cache to save the address book. When the mobile phone and the car computer are disconnected by Bluetooth, the car computer will continue to save the address book to save the synchronization time after the next Bluetooth connection. For the address book, the car computer system will clear the address book cache at regular intervals. Set the file permissions of the address book so that the application cannot access the cached address book to ensure the security of the address book.

[0096] In some implementations, the vehicle system has firmware code, and the method provided in the embodiment of the present application includes the step of constructing a corresponding security policy for the firmware code. Constructing a corresponding security policy for the firmware code includes: obfuscating or specially compiling the firmware code; if the firmware code is the firmware code of a microcontroller unit, storing the firmware code in a flash memory in the microcontroller unit; if the firmware code is the firmware code of a chip-level system, storing the firmware code in an external embedded multi-card storage card.

[0097] For example, the firmware of the vehicle computer is protected to ensure the security of the firmware information and avoid malicious information extraction. The chip (such as a memory chip) can adopt the firmware anti-reading protection measures provided by the chip manufacturer to prevent the firmware from being extracted by attackers.

[0098] By obfuscating the firmware or performing special compilation processing, the difficulty of analyzing sensitive logic can be increased, ensuring that the firmware code cannot be easily reverse analyzed.

[0099] The firmware code of the car computer RH850 is stored in the internal flash memory of the MCU. In the mass production stage, the JTAG interface has a password protection to prevent attackers from accessing the memory of the RH850 through JTAG to perform firmware security protection.

[0100] The firmware code of the car computer SOC is stored in an external embedded multi-card storage card (eMMC). The eMMC can use a ball grid array package (BGA package). The chip pins are not exposed and the eMMC cannot be directly accessed. This can play a certain protective role and improve the security of the firmware code.

[0101] The above is an introduction to an embodiment of the method for constructing a security strategy for a vehicle system provided in this application.

[0102] The application scenario of the embodiments provided in this application may be: an automobile manufacturer is developing a new type of automobile whose vehicle system is equipped with the latest hardware and software technologies. The hardware of the vehicle system includes multiple sensitive components, such as MCU, SOC, and network interface for vehicle communication. In order to ensure the security of these hardware components and prevent unauthorized tampering or hardware implantation, the vehicle system needs to be securely designed.

[0103] Among them, the security design of the vehicle MCU hardware debugging interface is as follows: the JTAG interface is only provided for MCU RH850. Due to the debugging requirements of the vehicle system after mass production, the JTAG debugging can be retained and password-protected. The secure ID can be packaged into the image and burned into the MCU during production. When connecting the JTAG tool, it is necessary to verify whether the secure ID in the MCU matches the secure ID set by the PC compiler software. If they match, the connection between the PC and the MCU is established through the JTAG tool; otherwise, the connection between the PC and the MCU cannot be established through the JTAG tool.

[0104] Set the UART communication interface of the SOC in the car computer to only output log information, and disable the serial port printing driver.

[0105] When the Android debugging bridge on the PC is used to debug the vehicle system, it checks whether the identity authentication is passed. If it is passed, the connection between the vehicle system and the Android debugging bridge is established through the T-Box hotspot, and the data of the vehicle system is read, the APK is installed for the vehicle system, and the configuration parameters of the vehicle system are changed.

[0106] After mass production, the Android debugging bridge function of the car system is in a closed state. When the Android debugging bridge on the PC is used to debug the car system, it is verified whether the bridge permission is possessed (i.e., whether it is in factory mode and whether it is a specific person). If so, the Android debugging bridge function is enabled and a connection is established between the car system and the Android debugging bridge through the T-Box hotspot to read the data of the car system, install APK for the car system, and change the configuration parameters of the car system.

[0107] After mass production, the root permissions are removed and the anti-tampering service is enabled. When the Android Debug Bridge establishes a connection with the vehicle system, the Android Debug Bridge has specific permissions, which are only used to obtain log information.

[0108] The chips in the car system can be treated with anti-dismantling glue, and the circuit boards in the car system can be erased or smeared with key information to increase the cost and threshold of hardware-level attacks.

[0109] The above is an introduction to the application scenarios of the embodiment of the security strategy construction method for the vehicle system provided in this application.

[0110] Please refer to the attached Figure 2 , Figure 2 It is a schematic block diagram of the safety design of the vehicle system provided in some embodiments of the present application. Figure 2 In the security design of the vehicle system, we can start with the circuit board and chip security design, hardware debugging interface security design, ADB debugging security design, storage security design and firmware security design. For the vehicle system, these parts are often the parts with higher security risks. By designing these parts, we can achieve comprehensive security protection for the vehicle system and enhance the defense capability of the system. For the specific security design method, please refer to the introduction in the embodiment of the security policy construction method for the vehicle system provided in this application.

[0111] The implementation of the security policy building device for the vehicle system provided by the embodiment of the present application will be described in detail below with reference to the accompanying drawings.

[0112] Regarding the security policy construction method for the vehicle system provided in the above embodiment, the embodiment of the present application also provides a security policy construction device for the vehicle system, which is used to implement the above method, such as Figure 3 As shown, Figure 3This is a schematic block diagram of the modules of a security policy building device 300 for a vehicle system according to an embodiment of the present application. The security policy building device for the vehicle system includes:

[0113] A determination module 301 is used to determine the types of hardware components in the vehicle system, where the types of hardware components include a debugging interface;

[0114] A construction module 302 is used to construct corresponding security policies according to the types of hardware components to ensure the safe operation of the hardware components;

[0115] Among them, the security policy corresponding to the debugging interface includes the security policy of the debugging interface corresponding to the production stage of the vehicle computer.

[0116] 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.

[0117] like Figure 4 As shown, the embodiment of the present application further provides an electronic device 400, the electronic device 400 includes a memory 401, one or more processors 402 ( Figure 4 Only one is shown) and a computer program stored in the memory 401 and executable on the processor 402. The memory 401 is used to store software programs and units, and the processor 402 executes various functional applications and data processing by running the software programs and units stored in the memory 401 to obtain the resources corresponding to the above-mentioned preset events. Optionally, the processor 402 implements the above-mentioned security policy construction method of the vehicle system by running the above-mentioned computer program stored in the memory 401.

[0118] The memory 401, 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 401 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 401 may optionally include a memory remotely arranged relative to the processor 402, and these remote memories may be connected to the processor 402 via a network.

[0119] 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.

[0120] The embodiment of the present application also provides a vehicle, and the vehicle system of the vehicle constructs a security policy through the above-mentioned vehicle system security policy construction method, device or 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.

[0121] 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.

[0122] 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 security policy construction method for the vehicle system as described above.

[0123] 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.

[0124] The security policy construction method, device, electronic device, vehicle and computer program product of the vehicle system provided in the embodiment of the present application, by determining the types of hardware components in the vehicle system, the types of hardware components include debugging interfaces; then, constructing corresponding security policies according to the types of hardware components to enable the safe operation of the hardware components; wherein the security policies corresponding to the debugging interfaces include the security policies of the debugging interfaces corresponding to the production stage of the vehicle system. Thus, by determining the types of hardware components in the vehicle system and constructing corresponding security policies according to the determined types of hardware components, comprehensive security protection of the vehicle system can be achieved, and by using the security policies of the debugging interfaces corresponding to the production stage of the vehicle system, the security risks of the vehicle system can be further reduced, thereby enhancing the defense capability of the vehicle system.

[0125] The security strategy construction method, device, electronic device, vehicle and computer program product of the vehicle system provided by the embodiments of the present application can achieve comprehensive vehicle system security protection, significantly enhance the system's defense capabilities, and effectively reduce the risk of network attacks and data leakage. At the same time, the strategy ensures the long-term stable operation of the system and maintains the continuity of services. In addition, the imperceptible implementation of the security strategy improves the overall user experience, and preventive maintenance measures help reduce long-term operating costs.

[0126] 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.

[0127] 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 described herein are also within the scope of the present disclosure.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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).

[0133] 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 constructing a security strategy for a vehicle system, characterized in that: The following steps are involved: Determining the types of hardware components in the vehicle system, wherein the types of hardware components include a debugging interface; Constructing corresponding security policies according to the types of the hardware components to ensure the safe operation of the hardware components; Among them, the security policy corresponding to the debugging interface includes the security policy of the debugging interface corresponding to the production stage of the vehicle computer.

2. The method for constructing a security strategy for a vehicle system according to claim 1, characterized in that: The constructing a corresponding security policy according to the type of the hardware component includes: If the production stage of the vehicle computer is the mass production debugging stage, performing a corresponding first safety operation according to the type of the debugging interface; If the production stage of the vehicle computer is the stage after mass production and before shipment, the corresponding second safety operation is performed according to the type of the debugging interface.

3. The method for constructing a security strategy for a vehicle system according to claim 2, characterized in that: The first security operation includes verifying a security identifier, and the performing a corresponding first security operation according to the type of the debug interface includes: If the debugging interface is a joint test action group interface, verifying the security identifier in the microcontroller unit and the security identifier in the compiled software to obtain a verification result; Determine whether the joint test action group interface is securely connected based on the verification result.

4. The method for constructing a security strategy for a vehicle system according to claim 2, characterized in that: The first security operation includes limiting the debugging function and / or removing the encapsulation trace, and the performing the corresponding first security operation according to the type of the debugging interface includes: If the debugging interface is a universal asynchronous receiver-transmitter interface of a chip-level system, the debugging function of the universal asynchronous receiver-transmitter interface is limited and / or the encapsulation trace of the universal asynchronous receiver-transmitter interface is removed.

5. The method for constructing a security strategy for a vehicle system according to claim 2, characterized in that: The first security operation includes identity authentication, and the performing the corresponding first security operation according to the type of the debug interface includes: If the debugging interface is a network interface, and the debugging tool debugs the software system in the vehicle system through the network interface, then identity authentication is performed on the client and the server connected to the debugging tool; Determine whether the debugging tool is securely connected through the network interface according to the result of the identity authentication.

6. The method for constructing a security strategy for a vehicle system according to claim 2, characterized in that: The second security operation includes closing the debugging interface and disabling the debugging function, and performing the corresponding second security operation according to the type of the debugging interface includes: If the debugging interface is a Joint Test Action Group interface or a Universal Asynchronous Receiver / Transmitter interface, the debugging interface is closed and the debugging function of the debugging interface is disabled.

7. The method for constructing a security strategy for a vehicle system according to claim 2, characterized in that: The second security operation includes at least one of turning off a debugging function, setting a function switch, removing superuser privileges, enabling secure boot and verification functions, or controlling a debugging tool to obtain privileges for a log file, and performing the corresponding second security operation according to the type of the debugging interface includes: If the debugging interface is a network interface, and the debugging tool debugs the software system in the vehicle computer system through the network interface, at least one of the following operations is performed: Turn off the debugging function of the debugging tool; Based on the factory mode of the vehicle system, setting a function switch corresponding to the debugging tool, wherein the factory mode is securely accessed through a preset gesture and password; Remove superuser privileges and enable secure boot and authentication features; Control the debugging tool's permission to obtain log files.

8. The method for constructing a security strategy for a vehicle system according to claim 1, characterized in that: The types of hardware components include circuit boards and chips, and the step of constructing corresponding security policies according to the types of hardware components includes at least one of the following: If the chip has data processing capability and data computing capability, erasing key information of the chip, the key information including the brand logo of the chip, the design logo of the chip and parameter information of the chip; Performing glue dispensing processing on the chip with data storage function by using anti-disassembly glue; The design logo on the circuit board is hidden.

9. The method for constructing a security strategy for a vehicle system according to claim 1, characterized in that: The vehicle system contains sensitive information, and the method further includes the step of constructing a corresponding security policy for the sensitive information, wherein the step of constructing a corresponding security policy for the sensitive information includes: If the vehicle system is equipped with a hardware security module, a security chip or a security service, controlling the encryption operation of the sensitive information in the vehicle system to be executed in the hardware security module, the security chip or the security service; The sensitive information is securely stored in a trusted environment provided by the security service.

10. The method for constructing a security strategy for a vehicle system according to claim 1, characterized in that: The vehicle system has a firmware code, and the method further includes a step of constructing a corresponding security policy for the firmware code, wherein the step of constructing a corresponding security policy for the firmware code includes: Obfuscating or specially compiling the firmware code; If the firmware code is the firmware code of a microcontroller unit, storing the firmware code in a flash memory in the microcontroller unit; If the firmware code is a firmware code of a chip-level system, the firmware code is stored in an external embedded multi-card memory card.

11. A security strategy building device for a vehicle system, characterized in that: The device comprises: A determination module, used to determine the types of hardware components in the vehicle system, wherein the types of hardware components include a debugging interface; A construction module, used to construct corresponding security policies according to the types of the hardware components to ensure the safe operation of the hardware components; Among them, the security policy corresponding to the debugging interface includes the security policy of the debugging interface corresponding to the production stage of the vehicle computer.

12. 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 method for constructing a security policy for a vehicle system as described in any one of claims 1 to 10 when executing the computer program.

13. A vehicle, characterized in that: The vehicle's on-board system is security designed by the on-board system security policy construction method according to any one of claims 1 to 10, the on-board system security policy construction device according to claim 11, or the electronic device according to claim 12.

Images