Vehicle-mounted system communication method and device, equipment and storage medium

Abstract

The invention discloses a vehicle-mounted system communication method and device, equipment and a storage medium, and relates to the technical field of intelligent automobiles. The method comprises the following steps: a first operating system responds to a communication link request sent by a second operating system, generates a first authentication code key and a first random number in a trusted execution environment, and sends the first authentication code key and the first random number to the second operating system; in response to target information sent by the second operating system, extracting a first random number and a first authentication code from the target information, and obtaining a second authentication code key from the trusted execution environment; generating a second authentication code according to the second authentication code key and the first random number; comparing the first authentication code with the second authentication code to obtain a consistency comparison result; and agreeing or refusing to communicate with the second operating system according to a consistency comparison result. According to the invention, the communication security between the first operating system and the second operating system can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent vehicles, in particular to a vehicle-mounted system communication method and device, equipment and storage medium. BACKGROUND

[0002] A vehicle-mounted system includes multiple operating systems, such as Android / Linux as an information entertainment domain operating system, and QNX as a safety critical domain operating system. Different domain operating systems can achieve cross-domain communication through a high-speed distributed bus, but there is a problem of low communication security. For example, there are security risks such as easy eavesdropping of communication content and weak key management. SUMMARY

[0003] The present application aims to at least solve one of the technical problems existing in the prior art. To this end, the present application proposes a vehicle-mounted system communication method and device, equipment and storage medium, which can improve communication security.

[0004] To achieve the above-mentioned purpose, a first aspect of an embodiment of the present application proposes a vehicle-mounted system communication method applied to a first operating system, wherein the first operating system is provided with a trusted execution environment, and the method comprises: In response to a communication link request sent by a second operating system, generating a first authentication code key and a first random number in the trusted execution environment, and sending the first authentication code key and the first random number to the second operating system; In response to target information sent by the second operating system, extracting the first random number and the first authentication code from the target information, and obtaining a second authentication code key from the trusted execution environment; wherein the target information is generated by the second operating system according to the first authentication code key and the first random number; Generating a second authentication code according to the second authentication code key and the first random number; Comparing the first authentication code and the second authentication code to obtain a consistency comparison result; In response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, agreeing to communicate with the second operating system, or in response to the consistency comparison result indicating that the first authentication code and the second authentication code are not the same, refusing to communicate with the second operating system.

[0005] Optionally, the first operating system and the second operating system are both deployed in a target electronic control unit, and the target electronic control unit is further provided with a vehicle safety module, and the first operating system is configured to allow the vehicle safety module to access the trusted execution environment; The method comprises the following steps: In response to the first session context parameter sent by the vehicle security module, the first session context parameter is transmitted to the trusted execution environment; wherein the first session context parameter is obtained by the vehicle security module parsing the communication link request sent by the second operating system; The first authentication code key is generated in the trusted execution environment according to the first session context parameter, and the first random number is generated; The first authentication code key and the first random number are transmitted to the vehicle security module; wherein the vehicle security module is used to transmit the first authentication code key and the first random number to the second operating system.

[0006] Optionally, the first operating system is also provided with an encrypted storage area; the first authentication code key is generated in the trusted execution environment according to the first session context parameter, comprising: The encrypted storage area is accessed in the trusted execution environment to obtain a preset master key; The first authentication code key is generated in the trusted execution environment according to the preset master key and the first session context parameter; wherein the preset master key is set to be prohibited to be transmitted out of the trusted execution environment.

[0007] Optionally, the first operating system and the second operating system are deployed in a target electronic control unit, the target electronic control unit is also deployed with a vehicle security module, the first operating system is used to allow the vehicle security module to access the trusted execution environment, the first operating system is deployed with a first communication agent module, and the method is applied to the first communication agent module; the second authentication code key is obtained from the trusted execution environment, comprising: The access request is sent to the vehicle security module through the first communication agent module; wherein the vehicle security module is used to parse the access request to obtain a second session context parameter, and transmit the second session context parameter to the trusted execution environment; The second authentication code key is generated in the trusted execution environment according to the preset master key and the second session context parameter; wherein the preset master key is set to be prohibited to be transmitted out of the trusted execution environment.

[0008] Optionally, the first operating system is deployed with a first communication agent module, the second operating system is deployed with a second communication agent module, and the method is applied to the first communication agent module; and the step of, in response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, agreeing to communicate with the second operating system, comprises: in response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, agreeing to communicate with the second communication agent module; the step of, in response to the consistency comparison result indicating that the first authentication code and the second authentication code are not the same, refusing to communicate with the second operating system, comprises: in response to the consistency comparison result indicating that the first authentication code and the second authentication code are not the same, refusing to communicate with the second communication agent module.

[0009] Optionally, after agreeing to communicate with the second communication agent module, the method further comprises: generating a second random number in the trusted execution environment, and performing parameter assembly according to the first random number and the second random number to obtain a target session context parameter; performing key generation according to a preset master key and the target session context parameter in the trusted execution environment to obtain a communication agent key; wherein the preset master key is set to be prohibited from being transmitted out of the trusted execution environment; encrypting plaintext service data according to the communication agent key to obtain ciphertext service data; sending the ciphertext service data and the second random number to the second communication agent module; wherein the second communication agent module is configured to decrypt the ciphertext service data according to the second random number.

[0010] To achieve the above object, a second aspect of the embodiment of the present application provides a vehicle-mounted system communication method, applied to a second operating system, and the method comprises: sending a communication link request to a first operating system; wherein the first operating system is provided with a trusted execution environment, and the first operating system is configured to, in response to the communication link request, generate a first authentication code key and a first random number in the trusted execution environment, and send the first authentication code key and the first random number to the second operating system; generating a first authentication code according to the first authentication code key and the first random number, and generating target information according to the first random number and the first authentication code; sending the target information to the first operating system; wherein the first operating system is configured to: extract the first random number and the first authentication code from the target information, and acquire a second authentication code key from the trusted execution environment, generate a second authentication code according to the second authentication code key and the first random number, and compare the first authentication code and the second authentication code to obtain a consistency comparison result; in response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, agree to communicate with the second operating system, or in response to the consistency comparison result indicating that the first authentication code and the second authentication code are not the same, refuse to communicate with the second operating system.

[0011] To achieve the above object, a third aspect of the embodiments of the present application provides a vehicle-mounted system communication device, the device comprising: a first operating system configured to implement the method of the first aspect; and a second operating system configured to implement the method of the second aspect.

[0012] To achieve the above object, a fourth aspect of the embodiments of the present application provides a vehicle-mounted system communication device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method of the first aspect or the method of the second aspect when executing the computer program.

[0013] To achieve the above object, a fifth aspect of the embodiments of the present application provides a computer readable storage medium, which stores a computer program, wherein the computer program is executable by a processor to implement the method of the first aspect or the method of the second aspect.

[0014] The vehicle-mounted system communication method and device, equipment, and storage medium provided by the present application have the following advantages. When the second operating system requests to communicate with the first operating system, the first authentication code key, the first random number, and the second authentication code key are all generated in the trusted execution environment, and are all generated by the first operating system in response to the request or information sent by the second operating system, thus having high security and being related to the second operating system. If no replay attack is encountered during data transmission, the consistency comparison result indicates that the first authentication code and the second authentication code are the same at this time, so the first operating system will agree to communicate with the second operating system. However, if a replay attack is encountered during data transmission, the first authentication code key or the first random number received by the second operating system, or the first authentication code or the first random number received by the first operating system may have been tampered with, so the consistency comparison result indicates that the first authentication code and the second authentication code are not the same at this time, so the first operating system will refuse to communicate with the second operating system. In this way, the present application can provide a replay attack-resistant two-way identity authentication process, and can also reduce the risk of key leakage, thus improving the security of communication.

[0015] Additional aspects and advantages of the present application will be made apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is a flowchart of a vehicle system communication method applied to a first operating system provided by an embodiment of the present application; Figure 2 is Figure 1 is a flowchart of step 101 in Figure 3 is Figure 2 is a flowchart of step 202 in Figure 4 is a flowchart of obtaining a second authentication code key provided by an embodiment of the present application; Figure 5 is a flowchart of a vehicle system communication method provided by another embodiment of the present application; Figure 6 is a flowchart of a vehicle system communication method applied to a second operating system provided by an embodiment of the present application; Figure 7 is an example flowchart of a vehicle system communication method provided by an embodiment of the present application. DETAILED DESCRIPTION

[0017] In order to make the objects, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and should not be used to limit the present application.

[0018] It should be noted that although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification and claims and the above drawings are used to distinguish similar objects, and do not necessarily describe a specific order or sequence.

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

[0020] Before the embodiments of the present application are further described in detail, the terms and phrases involved in the embodiments of the present application are explained, and the terms and phrases involved in the embodiments of the present application are applicable to the following explanations.

[0021] In-Vehicle System or Automotive System: Refers to various electronic control units, sensors, communication devices and software integrated in vehicles to achieve various functions of vehicles, including driving assistance, entertainment, information security, diagnosis, etc. In-Vehicle System includes multiple operating systems.

[0022] Operating System: Also known as In-Vehicle Operating System, operating systems play different roles in vehicles, each responsible for different functions and levels. For example, Android / Linux as Infotainment Domain Operating System, and QNX as Secure Critical Domain Operating System. Cross-domain communication is achieved through high-speed distributed bus between the two domains.

[0023] Infotainment Operating System: Also known as Infotainment OS, it is an operating system designed specifically for vehicle multimedia and interactive systems. It provides user interface, navigation, multimedia, network connection and other functions, emphasizing user experience and multitasking capabilities.

[0024] Secure Critical Domain Operating System: Also known as Critical Domain OS or Secure Critical OS, it is an operating system designed specifically for critical safety and real-time control tasks in vehicles, aiming to ensure the reliability, security and real-time performance of vehicle safety-related functions.

[0025] Fast Distributed Bus (FDBus): Provides inter-process communication and remote procedure call functions. It is suitable for multiple operating systems, including Android, Linux and QNX, aiming to provide high-performance, low-latency and low-resource overhead message passing mechanisms.

[0026] Trusted Execution Environment (TEE): A hardware-based secure computing solution. Through software and hardware methods, a secure area is built in the CPU to ensure the confidentiality and integrity of the programs and data loaded inside. TEE divides the system's hardware and software resources into two execution environments: trusted and untrusted (normal). These two environments are isolated, and the untrusted part cannot access the storage and memory of the trusted part.

[0027] Rich Execution Environment (REE): Refers to the main operating system or software platform in a vehicle, responsible for running ordinary applications, user interfaces, background services, and other non-safety-critical tasks.

[0028] Replay Attack: A network attack method in which an attacker intercepts data from a legitimate communication and then resends the data at a future time point to deceive the system or gain unauthorized access.

[0029] Currently, with the development of intelligent automotive electronic and electrical architecture, Android / Linux is commonly used as the infotainment domain operating system in vehicle systems, while QNX is used as the safety-critical domain operating system. When cross-domain communication is implemented between the two domains through the FDBUS (FastDBus) bus, the following security risks exist: 1. Communication content is easily intercepted: traditional FDBUS does not provide encryption protection for transmitted data; 2. Lack of identity authentication: there is no effective communication party identity authentication mechanism; 3. Risk of replay attack: existing mechanisms cannot resist message replay attacks; 4. Weak key management: static key storage can lead to key leakage. The present application aims to at least solve one of the technical problems existing in the prior art. To this end, the present application proposes a vehicle system communication method and device, equipment, and storage medium, which can improve communication security.

[0030] The vehicle system communication method, vehicle system communication device, vehicle system communication equipment, and computer readable storage medium provided by the embodiments of the present application are specifically explained through the following embodiments. First, the vehicle system communication method in the embodiments of the present application is described.

[0031] Please refer to Figure 1 , Figure 1 An optional flowchart of a vehicle system communication method is disclosed. Figure 1 The method in the embodiment is applied to a first operating system, and the first operating system is provided with a trusted execution environment. The method can include, but is not limited to, steps 101 to 105.

[0032] Step 101: In response to a communication link request sent by a second operating system, a first authentication code key and a first random number are generated in a trusted execution environment, and the first authentication code key and the first random number are sent to the second operating system; Step 102: In response to target information sent by the second operating system, a first random number and a first authentication code are extracted from the target information, and a second authentication code key is obtained from the trusted execution environment; wherein the target information is generated by the second operating system according to the first authentication code key and the first random number; Step 103: A second authentication code is generated according to the second authentication code key and the first random number; Step 104, comparing the first authentication code and the second authentication code to obtain a consistency comparison result. Step 105, in response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, agreeing to communicate with the second operating system, or in response to the consistency comparison result indicating that the first authentication code and the second authentication code are not the same, refusing to communicate with the second operating system.

[0033] The steps 101 to 105 shown in the embodiments of the present application, when the second operating system requests to communicate with the first operating system, the first operating system first generates a first authentication code key and a first random number in the trusted execution environment, so that the second operating system generates a first authentication code according to the first authentication code key and the first random number, and then generates target information; the first operating system secondly acquires a second authentication code key in the trusted execution environment in response to the target information sent by the second operating system, and then generates a second authentication code according to the first random number and the second authentication code key; finally, the first operating system agrees or refuses to communicate with the second operating system according to the consistency comparison result. In this way, since the first authentication code key, the first random number and the second authentication code key are all generated in the trusted execution environment, and are all generated by the first operating system in response to the request or information sent by the second operating system, the security is high and is related to the second operating system. If there is no replay attack in the data transmission process, the consistency comparison result is used to indicate that the first authentication code and the second authentication code are the same at this time, so the first operating system will agree to communicate with the second operating system. But if there is a replay attack in the data transmission process, the first authentication code key or the first random number received by the second operating system, or the first authentication code or the first random number received by the first operating system may have been tampered with, so the consistency comparison result is used to indicate that the first authentication code and the second authentication code are not the same at this time, so the first operating system will refuse to communicate with the second operating system. In this way, the present application can provide a replay attack resistant two-way identity authentication process, and can also reduce the risk of key leakage, and improve the communication security.

[0034] The above data transmission process includes: a process in which the second operating system sends a communication link request to the first operating system, or a process in which the second operating system sends the first authentication code key and the first random number to the first operating system, or a process in which the second operating system sends target information to the first operating system.

[0035] In one example, the first operating system is an infotainment domain operating system, and the second operating system is a safety-critical domain operating system. In another example, the first operating system is a safety-critical domain operating system, and the second operating system is an infotainment domain operating system.

[0036] Before describing steps 101 to 105 in detail, the construction process of the trusted execution environment is described first.

[0037] In the hardware security layer, the TrustZone is enabled in the processor on the first operating system side, which divides the secure world and the normal world. Specifically, the TrustZone is a hardware-level security extension that provides a mechanism to create two isolated spaces on the same processor core: the secure world: mainly used to store sensitive code and data, such as key management, encryption algorithms, secure boot, etc. The TEE is implemented in the secure world; the normal world: mainly used to run normal applications, the REE is implemented in the normal world. For example, the first operating system sets an access control policy: only processes with PID = car_security_daemon are allowed to call the key interface. The key interface is responsible for providing access, updating, destroying, etc. Core operations of the key, to ensure the safe use of the key in the TEE. The key managed by the key interface can include the first authentication code key and the second authentication code key. In an example, the key interface is the car security AES-128-CMAC interface.

[0038] In step 101, the first operating system generates a first authentication code key and a first random number in the trusted execution environment in response to a communication link request sent by the second operating system, and sends the first authentication code key and the first random number to the second operating system. The communication link request is a message or signal initiated by the requesting end to the requested end, aiming to request the establishment of a communication link or connection. The communication link request informs the requested end that the requesting end hopes to establish a session with it so that both parties can exchange information. The identifier of the requested end is usually carried in the communication link request. In this embodiment, the requesting end is the second operating system, and the requested end is the first operating system. In an example, the first operating system is QNX, and the identifier carried by the communication link request can be "com.vehicle.fdbus.qnxsvc".

[0039] The trusted execution environment has been described above and will not be described here. The first authentication code key is a key used to generate or verify a message authentication code (MAC). The first authentication code key is an important cryptographic material to ensure the integrity and authentication of messages in communication. The first random number is a value generated according to a certain probability distribution, which cannot be predicted or repeated by any deterministic method.

[0040] In an example, the first authentication code key can be generated by CMAC_Key = AES-128-CMAC(Master_Key, Context_Info). Master_Key refers to a master key stored in an encrypted storage area of the TEE, and the encryption algorithm can use AES-256-XTS. Context_Info refers to a session context parameter that can be extracted from a communication link request.

[0041] It should be noted that the first operating system and the second operating system are usually run in different electronic control units or in different isolated areas of the same electronic control unit to achieve functional isolation and security assurance. The electronic control unit (ECU) refers to an embedded electronic controller in a vehicle for managing and controlling various electronic systems and functions of the vehicle.

[0042] In an embodiment, the first operating system and the second operating system are both deployed on a target electronic control unit. The target electronic control unit also deploys a vehicle security module.

[0043] The target electronic control unit is one of a plurality of electronic control units in the vehicle, and the first operating system, the second operating system, and the vehicle security module are deployed simultaneously.

[0044] The vehicle security module (Car Security) is a security control center mainly responsible for verifying and protecting communication content. The vehicle security module can receive messages from other systems (such as the Android operating system), call a trusted application (TA) to generate or verify an authentication code, and decide whether to allow the message to pass or trigger a security response according to the verification result, and can also execute some security policies, such as rejecting illegal messages, alarming, or disconnecting.

[0045] The first operating system is used to allow the vehicle security module to access the trusted execution environment. In an example, the vehicle security module provides a vehicle security service interface (Car_Security_Service interface), and the second operating system can call the vehicle security service interface to obtain the first authentication code key and the first random number from the trusted execution environment.

[0046] In an example, the Car_Security_Service interface is implemented as follows: byte[] generateCMAC(byte[] keyHandle, byte[] data) { / / Call the IPSec SP800-38B interface of Trusty TEE return TrustyCrypto.cmac(keyHandle, data, CMAC_128BIT)}.

[0047] The function of the above-mentioned generateCMAC function is to generate the value of CAMC, the input is the key and data, and then the return is the CMAC value.

[0048] In an embodiment, with reference to Figure 2 , step 101 can include: Step 201, in response to the first session context parameter sent by the vehicle security module, transmitting the first session context parameter to the trusted execution environment; wherein the first session context parameter is obtained by the vehicle security module analyzing the communication link request sent by the second operating system; Step 202, generating a first authentication code key and a first random number according to the first session context parameter in the trusted execution environment; Step 203, transmitting the first authentication code key and the first random number to the vehicle security module; wherein the vehicle security module is used to transmit the first authentication code key and the first random number to the second operating system.

[0049] In step 201, the first session context parameter is carried in the communication link request, and the first session context parameter can be parsed from the communication link request by using a conventional parsing method. The session context parameter usually refers to the key state information or configuration parameter used for saving and transmitting in the session process in the automotive security or system design. In the embodiment, the first session context parameter specifically refers to the parameter carried by the second operating system for requesting a session with the first operating system. The first session context parameter includes a first session identifier, first session state information, a first timestamp, etc. The session state information can be authenticated, or unauthenticated, or timeout, and the first session state information is specifically unauthenticated.

[0050] In step 202, the first operating system can generate a key for the first session context parameter by using a preset key generation algorithm to obtain the first authentication code key. The first operating system can also randomly select a number within a predetermined value range as the first random number.

[0051] In step 203, after the first operating system generates the first authentication code key and the first random number in the trusted execution environment, it can transmit them to the vehicle security module, so that the vehicle security module is used to transmit the first authentication code key and the first random number to the second operating system. In this way, although the second operating system cannot directly access the trusted execution environment, it can indirectly obtain the first authentication code key and the first random number from the trusted execution environment by accessing the vehicle security module.

[0052] The embodiment of steps 201 to 203 has the benefit that the security isolation of the first operating system and the second operating system is further implemented by the vehicle security module, which is conducive to improving the security of communication between different operating systems.

[0053] In an embodiment, with reference to Figure 3 , step 202 can include: Step 301, accessing the encrypted storage area in the trusted execution environment to obtain a preset master key; Step 302, generating a first authentication code key in the trusted execution environment according to the preset master key and the first session context parameter.

[0054] In step 301, the first operating system is also provided with an encrypted storage area. The encrypted storage area refers to a storage area specially designed in the trusted execution environment to protect sensitive data and keys. This storage area is protected by multiple protection mechanisms of hardware and software to ensure that the stored content cannot be tampered with by unauthorized access or malicious software. The encryption algorithm used by the encrypted storage area can be AES-256-XTS. In this embodiment, the preset master key Master_Key is mainly stored in the encrypted storage area.

[0055] In an example, taking QNX as the first operating system, the preset master key Master_Key (256 bits) can be burned in the Trust Zone of QNX, and the access permission is set to be called only within the trusted execution environment. The preset master key is set to be prohibited from being transmitted out of the trusted execution environment.

[0056] In step 302, the first authentication code key can be generated by the following method: CMAC_Key=AES-128-CMAC(Master_Key, Context_Info), and Context_Info refers to the first session context parameter at this time. The first authentication code key can also be generated by other methods, which are not limited in the present application, as long as the method of generating the first authentication code key is the same as the method of generating the second authentication code key.

[0057] The embodiment of steps 301 to 302 has the benefit that the first authentication code key is generated according to the preset master key, and the preset master key is not easy to be leaked, which reduces the risk of tampering with the first authentication code key, is conducive to improving the security of two-way authentication of the first operating system and the second operating system, and further improves the communication security.

[0058] In step 102, the first operating system extracts the first random number and the first authentication code from the target information in response to the target information sent by the second operating system, and acquires the second authentication code key from the trusted execution environment. The target information is generated by the second operating system according to the first authentication code key and the first random number. Specifically, the second operating system generates the first authentication code according to the first authentication code key and the first random number, and generates the target information according to the first random number and the first authentication code.

[0059] In an example, the second operating system generates the first authentication code by using an AES-128-CMAC algorithm: m_mac_A = AES-128-CMAC(CMAC_key, Nonce_A), where CMAC_key is the first authentication code key and Nonce_A is the first random number. The second operating system encapsulates the first random number and the first authentication code to obtain the target information.

[0060] In combination with the above, the first operating system and the second operating system can realize cross-domain communication through a high-speed distributed bus (FDBUS). The FDBUS is used as a communication bridge between the first operating system and the second operating system. In an embodiment, the first operating system is deployed with a first communication agent module, and the second operating system is deployed with a second communication agent module. Taking QNX as the first operating system, the first communication agent module can be a QNX-side FDBUS. The vehicle system communication method can be executed by the first communication agent module of the first operating system, i.e., can be executed by the QNX-side FDBUS. Taking Android as the second operating system, the second communication agent module can be an Android-side FDBUS. The vehicle system communication method can be executed by the second communication agent module of the second operating system, i.e., can be executed by the Android-side FDBUS.

[0061] In an embodiment, the vehicle system communication method is applied to the first communication agent module, and the first communication agent module is configured to perform the following steps: Figure 4 The process of acquiring the second authentication code key from the trusted execution environment can include: Step 401: sending an access request to a vehicle security module; the vehicle security module is configured to parse the access request to obtain a second session context parameter, and transmit the second session context parameter to the trusted execution environment; Step 402: generating the second authentication code key according to a preset master key and the second session context parameter in the trusted execution environment.

[0062] In step 401, the first communication agent module can generate an access request containing the second session context parameter in response to the target information, and then send the access request to the vehicle security module. After receiving the access request, the vehicle security module parses the second session context parameter therefrom, and transmits the second session context parameter to the trusted execution environment.

[0063] In step 402, the access permission of the preset master key is limited to internal calling of the TEE, and the preset master key is set to be prohibited from being transmitted out of the trusted execution environment. Taking the first communication agent module as the QNX-side FDBUS as an example, the QNX-side FDBUS calls the car security AES-128-CMAC interface to obtain the CMAC_key. Specifically, CMAC_Key = AES-128-CMAC(Master_Key, Context_Info), wherein the Master_Key refers to the preset master key, and the Context_Info refers to the second session context parameter.

[0064] The embodiment of steps 401 to 402 has the benefit that the second authentication code key is generated according to the preset master key, and the preset master key is not easy to be leaked, thereby reducing the risk of tampering of the second authentication code key, and being conducive to improving the security of the bidirectional authentication of the first operating system and the second operating system, and further improving the communication security.

[0065] In step 103, the first operating system generates a second authentication code according to the second authentication code key and the first random number. Alternatively, the first communication agent module generates a second authentication code according to the second authentication code key and the first random number.

[0066] In an example, the second authentication code generation process can be as follows: m_mac_Q = AES-CMAC(CMAC_Key, Nonce_A), wherein m_mac_Q refers to the second authentication code, AES-CMAC() refers to an authentication code generation algorithm, CMAC_Key refers to the second authentication code key, and Nonce_A refers to the first random number.

[0067] In another example, the second authentication code generation process can be as follows: m_mac_Q = AES-CMAC(CMAC_Key, Nonce_A || Session_ID), wherein Session_ID refers to a session identifier, which can be extracted from the second session context parameter.

[0068] In step 104, the first operating system or the first communication agent module compares the first authentication code and the second authentication code to obtain a consistency comparison result. The consistency comparison result indicates whether the first authentication code and the second authentication code are the same or different. For example, the consistency comparison result can be determined by "m_mac_A == m_mac_Q?", where m_mac_A refers to the first authentication code and m_mac_Q refers to the second authentication code.

[0069] In step 105, the first operating system agrees to communicate with the second operating system in response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, or the first operating system refuses to communicate with the second operating system in response to the consistency comparison result indicating that the first authentication code and the second authentication code are different.

[0070] In an embodiment, when the vehicle system communication method is applied to the first communication agent module, the first communication agent module agrees to communicate with the second communication agent module in response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, or the first communication agent module refuses to communicate with the second communication agent module in response to the consistency comparison result indicating that the first authentication code and the second authentication code are different. In this way, by performing mutual authentication on the respective communication agent modules of different operating systems, the communication security is improved, the adverse effects of identity authentication on the operation of the operating system are reduced, and the stability and reliability of the vehicle system are improved.

[0071] It can be understood that if the first communication agent module agrees to communicate with the second communication agent module, it means that the first operating system agrees to communicate with the second operating system. If the first communication agent module refuses to communicate with the second communication agent module, it means that the first operating system refuses to communicate with the second operating system.

[0072] In an example, the FDBUS bus extension of the communication protocol stack integrated by the vehicle system is as follows: {"interface": "com.vehicle.fdbus.secure", "methods": { "SecureConnect": { "in": ["nonce_A", "m_mac_A"], "out": ["nonce_Q", "m_mac_Q"]}, "EncryptedTransfer": { "in": ["encrypted_data", "iv", "aad"], "out": ["status"] } }。

[0073] In an example, after the first communication agent module agrees to communicate with the second communication agent module, the first communication agent module generates a second random number in the trusted execution environment, and authentication is completed; then the two parties exchange authentication success flags, and an encrypted communication channel is established.

[0074] In an embodiment, after the first communication agent module agrees to communicate with the second communication agent module, with reference to Figure 5 , the vehicle-mounted system communication method executed by the first communication agent module can further include: Step 501, generating a second random number in the trusted execution environment, and assembling parameters according to the first random number and the second random number to obtain a target session context parameter; Step 502, generating a communication agent key according to a preset master key and the target session context parameter in the trusted execution environment; Step 503, encrypting plaintext service data according to the communication agent key to obtain ciphertext service data; Step 504, sending the ciphertext service data and the second random number to the second communication agent module; wherein the second communication agent module is configured to decrypt the ciphertext service data according to the second random number.

[0075] In step 501, the target session context parameter refers to a parameter assembled based on the authenticated session context parameter. In an example, the target session context parameter can be represented as: Context_Info = Nonce_A ||Nonce_Q. In another example, the target session context parameter can also be represented as: Context_Info = Session_ID || Timestamp || Nonce_A || Nonce_Q. Timestamp refers to a time stamp.

[0076] In step 502, the preset master key is set to be prohibited from being transmitted out of the trusted execution environment. The communication agent key refers to a key used for encrypting data when the first communication agent module and the second communication agent module perform data transmission. The communication agent key can be represented as: FDBUS_Key = KDF(Master_Key, Context_Info, 128).

[0077] The generation logic of the communication agent key can be as follows: def derive_key(Master_key, context): # Using NIST SP 800-108 COUNTER mode kdf = CMAC_KDF(Master_key, 128) return kdf.generate( label="FDBUS_SESSION_KEY", context=context, length=16).

[0078] In step 503, the plaintext service data can be encrypted by using the AES-CBC mode, and the ciphertext service data can be represented as: Ciphertext = AES-128-CBC (FDBUS_Key, IV, Plaintext). Wherein, IV is an increasing counter for each frame, and Plaintext refers to the plaintext service data.

[0079] In step 504, the first communication agent module sends the ciphertext service data and the second random number to the second communication agent module. The second communication agent module is used to decrypt the ciphertext service data according to the second random number. The decryption process is the inverse process of the encryption process, which will not be described here.

[0080] The embodiment of the above steps 501 to 504 has the benefit that the key is generated according to multiple factors (the first random number, the second random number, and the preset master key, etc.), has the ability to prevent replay attacks, and each session independently derives the key, and single key disclosure does not affect the security of historical communication.

[0081] The above vehicle system communication method is executed by the first operating system or the first communication agent module. The following describes a vehicle system communication method executed by the second operating system or the second communication agent module.

[0082] In an embodiment, referring to Figure 6 , the vehicle system communication method applied to the second operating system can include: Step 601, sending a communication link request to the first operating system; wherein the first operating system is provided with a trusted execution environment, and the first operating system is used to generate a first authentication code key and a first random number in the trusted execution environment in response to the communication link request, and send the first authentication code key and the first random number to the second operating system; Step 602, generating a first authentication code according to the first authentication code key and the first random number, and generating target information according to the first random number and the first authentication code; Step 603, sending target information to the first operating system; wherein the first operating system is configured to: extract the first random number and the first authentication code from the target information, and obtain the second authentication code key from the trusted execution environment, generate the second authentication code according to the second authentication code key and the first random number, and compare the first authentication code and the second authentication code to obtain a consistency comparison result; in response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, agreeing to communicate with the second operating system, or in response to the consistency comparison result indicating that the first authentication code and the second authentication code are not the same, refusing to communicate with the second operating system.

[0083] It should be noted that the vehicle system communication method applied to the second operating system can be implemented by referring to the above-mentioned vehicle system communication method applied to the first operating system, and will not be described here.

[0084] In an example, referring to Figure 7 , the vehicle system communication method can include the following steps: (1) The Android side FDBUS requests to link the QNX side FDBUS, and calls the car security AES-128-CMAC interface to obtain the first authentication code key CMAC_key_A and generate the first random number Nonce_A; specifically, the car security AES-128-CMAC interface can be called to obtain the first authentication code key CMAC_key_A and generate the first random number Nonce_A from the TA of the QNX side, and the TA runs in the TEE. The TA stands for Trusted Application, which means an application running in the TEE environment. The Android side FDBUS can also call the car security AES-128-CMAC interface through the CA, and the CA stands for Client Application, which means an application running in the REE environment.

[0085] (2) The Android side FDBUS calculates the first authentication code for the first random number: m_mac_A = AES-128-CMAC(CMAC_key_A, Nonce_A).

[0086] (3) The Android side FDBUS sends the target information, including the first random number Nonce_A and the first authentication code m_mac_A.

[0087] (4) The QNX side FDBUS calls the car security AES-128-CMAC interface to obtain CMAC_key_Q.

[0088] (5) The QNX side FDBUS calculates the second authentication code for the sent information: m_mac_Q = AES-128-CMAC(CMAC_key_Q, Nonce_A).

[0089] (6) The QNX side FDBUS compares whether the two authentication codes are consistent. If they are consistent, communication is agreed; if they are inconsistent, communication is rejected. The comparison process can be represented as: m_mac_A==m_mac_Q?

[0090] It should be noted that, Figure 7 The Nonce shown includes Nonce_A and Nonce_Q, m_mac includes m_mac_A and m_mac_Q, and CMAC_key is CMAC_key_A. HU stands for Hardware Unit, which refers to a hardware unit, mainly including QNX-side FDBUS and Android-side FDBUS. Native Service refers to a native service, typically a service provided directly by the underlying system or hardware within the operating system or platform, implemented with native code. HAL stands for Hardware Abstraction Layer, a software architecture design used to hide the specific implementation details of the hardware, providing a unified interface for upper-layer software.

[0091] The benefits of this example are at least that it achieves physical protection of the key through TEE, defends against software-level key extraction attacks, and has low computational overhead and low resource consumption for CMAC authentication.

[0092] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they are not described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0093] This application also discloses a vehicle-mounted system communication device, which includes: The first operating system, used to implement, etc. Figures 1 to 5 The vehicle-mounted system communication method shown; The second operating system is used to implement, for example Figure 6 The vehicle-mounted system communication method is shown.

[0094] In one embodiment, the vehicle system communication device may be deployed on the target electronic control unit.

[0095] The embodiment of the present application further discloses a vehicle-mounted system communication device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the vehicle-mounted system communication method as described above when executing the computer program. The vehicle-mounted system communication device can be an electronic device, which can be a vehicle-mounted terminal, a smart phone, a wearable device, or a portable computer, etc. The vehicle-mounted system communication device can also be a vehicle. The vehicle can be a new energy vehicle, such as a hybrid vehicle or a pure electric vehicle. For example, the vehicle can be a car, an SUV, an MPV, a pickup truck, a van, a bus, etc.

[0096] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the vehicle-mounted system communication method as described above.

[0097] The memory is a non-transitory computer readable storage medium, which can be used to store non-transitory software programs and non-transitory computer executable programs. In addition, the memory can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some embodiments, the memory can optionally include a memory remotely arranged relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0098] The embodiment of the present application further provides a computer program product, which includes a computer program, and the computer program is read and executed by a processor of a vehicle-mounted system communication device, so that the processor implements the vehicle-mounted system communication method as described above when executing the computer program.

[0099] The embodiments described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art can know that, with the evolution of technology and the appearance of new application scenarios, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0100] Those skilled in the art can understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and can include more or fewer steps than those shown in the figures, or combine certain steps, or different steps.

[0101] The apparatus embodiments described above are merely exemplary, and the units described as separate units can or can not be physically separate, i.e., can be located in one place, or can be distributed over multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment.

[0102] Those skilled in the art can understand that all or some of the steps in the method disclosed above, the functional modules / units in the system and the device can be implemented as software, firmware, hardware and appropriate combinations thereof.

[0103] The terms "first", "second", "third", "fourth" and the like in the description of the application and in the claims of the foregoing drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the use of the terms so

[0104] It should be understood that in this application, "at least one" means one or more, and "multiple" means two or more. "And / or" is used to describe the relationship between the associated objects, which means that there can be three relationships, for example, "A and / or B" can mean that there are three cases: only A, only B, and A and B at the same time, where A and B can be singular or plural. The character " / " generally represents that the associated objects before and after are in an "or" relationship. "At least one of the following" or the like means any combination of these items, including any combination of single or multiple items. For example, at least one of a, b or c, can mean a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0105] In several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can be implemented by other manners. For example, the apparatus embodiments described above are merely illustrative, for example, the division of the above units is merely a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some interfaces, apparatuses or units, and can be electrical, mechanical or other forms.

[0106] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they can be located in one place or distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0107] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0108] If the integrated unit is realized in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the part of the prior art that makes a contribution or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method of each embodiment of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program storage media.

[0109] The preferred embodiments of the embodiments of the present application are described above with reference to the accompanying drawings, which are not limited to the scope of the embodiments of the present application. Any modifications, equivalent replacements and improvements made by those skilled in the art without departing from the scope and essence of the embodiments of the present application shall be within the scope of the embodiments of the present application.

Claims

1. A vehicle-mounted system communication method, characterized in that, Applied to a first operating system, wherein the first operating system is configured with a trusted execution environment, the method includes: In response to a communication link request sent by the second operating system, a first authentication key and a first random number are generated in the trusted execution environment, and the first authentication key and the first random number are sent to the second operating system. In response to the target information sent by the second operating system, the first random number and the first authentication code are extracted from the target information, and the second authentication code key is obtained from the trusted execution environment; wherein, the target information is generated by the second operating system based on the first authentication code key and the first random number; A second authentication code is generated based on the second authentication code key and the first random number; The first authentication code and the second authentication code are compared to obtain a consistency comparison result; If the consistency comparison result indicates that the first authentication code and the second authentication code are the same, communication with the second operating system is agreed upon; or if the consistency comparison result indicates that the first authentication code and the second authentication code are different, communication with the second operating system is refused.

2. The method according to claim 1, characterized in that, Both the first operating system and the second operating system are deployed on the target electronic control unit, which also deploys a vehicle safety module. The first operating system is used to allow the vehicle safety module to access the trusted execution environment. The step of generating a first authentication code key and a first random number in the trusted execution environment in response to a communication link request sent by the second operating system includes: In response to the first session context parameter sent by the vehicle security module, the first session context parameter is transmitted to the trusted execution environment; wherein, the first session context parameter is obtained by the vehicle security module parsing the communication link request sent by the second operating system; Within the trusted execution environment, the first authentication code key is generated based on the first session context parameters, and the first random number is generated; The first authentication key and the first random number are transmitted to the vehicle security module; wherein, the vehicle security module is used to transmit the first authentication key and the first random number to the second operating system.

3. The method according to claim 2, characterized in that, The first operating system also has an encrypted storage area; The step of generating the first authentication code key based on the first session context parameters within the trusted execution environment includes: Access the encrypted storage area within the trusted execution environment to obtain a preset master key; Within the trusted execution environment, a key is generated based on the preset master key and the first session context parameters to obtain the first authentication code key; wherein, the preset master key is set to prevent transmission outside the trusted execution environment.

4. The method according to any one of claims 1 to 3, characterized in that, Both the first operating system and the second operating system are deployed on the target electronic control unit, which also deploys a vehicle safety module. The first operating system is used to allow the vehicle safety module to access the trusted execution environment. The first operating system deploys a first communication proxy module, and the method is applied to the first communication proxy module. The step of obtaining the second authentication key from the trusted execution environment includes: The first communication proxy module sends an access request to the vehicle security module; wherein, the vehicle security module is used to parse the access request, obtain the second session context parameter, and transmit the second session context parameter to the trusted execution environment; Within the trusted execution environment, the second authentication code key is generated based on the preset master key and the second session context parameters; wherein the preset master key is set to prevent it from being transmitted out of the trusted execution environment.

5. The method according to any one of claims 1 to 3, characterized in that, The first operating system has a first communication proxy module deployed, and the second operating system has a second communication proxy module deployed. The method is applied to the first communication proxy module. The response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, and agreeing to communicate with the second operating system, includes: In response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, it is agreed to communicate with the second communication proxy module; The response to the consistency comparison result indicating that the first authentication code and the second authentication code are different, and the refusal to communicate with the second operating system, includes: In response to the consistency comparison result indicating that the first authentication code and the second authentication code are different, communication with the second communication proxy module is refused.

6. The method according to claim 5, characterized in that, After agreeing to communicate with the second communication proxy module, the method further includes: A second random number is generated within the trusted execution environment, and parameters are assembled based on the first random number and the second random number to obtain the target session context parameters; Within the trusted execution environment, a key is generated based on a preset master key and the target session context parameters to obtain a communication proxy key; wherein, the preset master key is set to prevent transmission outside the trusted execution environment; The plaintext service data is encrypted using the communication proxy key to obtain the ciphertext service data; The encrypted service data and the second random number are sent to the second communication proxy module; wherein, the second communication proxy module is used to decrypt the encrypted service data according to the second random number.

7. A vehicle-mounted system communication method, characterized in that, Applied to a second operating system, the method includes: A communication link request is sent to a first operating system; wherein, the first operating system is configured with a trusted execution environment, and the first operating system is used to generate a first authentication code key and a first random number in the trusted execution environment in response to the communication link request, and send the first authentication code key and the first random number to the second operating system; A first authentication code is generated based on the first authentication code key and the first random number, and target information is generated based on the first random number and the first authentication code. The target information is sent to the first operating system; wherein the first operating system is configured to: extract the first random number and the first authentication code from the target information, obtain the second authentication code key from the trusted execution environment, generate the second authentication code based on the second authentication code key and the first random number, compare the first authentication code and the second authentication code to obtain a consistency comparison result; in response to the consistency comparison result indicating that the first authentication code and the second authentication code are the same, agree to communicate with the second operating system, or in response to the consistency comparison result indicating that the first authentication code and the second authentication code are different, refuse to communicate with the second operating system.

8. A vehicle-mounted system communication device, characterized in that, The device includes: A first operating system is configured to implement the method as described in any one of claims 1 to 6; A second operating system is used to implement the method as described in claim 7.

9. A vehicle-mounted system communication device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 7.

Images