Safety communication method and device for upper computer and ECU, storage medium and program product

Abstract

The invention provides a secure communication method and device for an upper computer and an ECU (Electronic Control Unit), a storage medium and a program product, which are respectively applied to an upper computer end and an ECU end, and the method comprises the following steps: the upper computer obtains an encryption public key of the ECU and a decryption private key of the upper computer, generates a session key for data encryption and decryption, and sends the session key to the ECU; and the session key is subjected to double encryption by sequentially using an encryption public key of the ECU and a decryption private key of the ECU, and a communication ciphertext is generated and sent to the ECU end. And after receiving the communication ciphertext, the ECU end performs dual decryption by using the encryption public key of the upper computer and the decryption private key of the ECU end in sequence, so that the session key is recovered. And after the key negotiation is completed, the two parties encrypt and decrypt communication data through a symmetric encryption mode based on the session key. According to the invention, a hybrid encryption communication mechanism taking the public key infrastructure as the root of trust is constructed, confidentiality and integrity protection of communication data is realized, and the authentication capability of the identity of the communication entity is remarkably enhanced.

Description

Technical Field

[0001] This application relates to the field of intelligent transportation technology, and in particular to a method, device, storage medium, and program product for secure communication between a host computer and an ECU. Background Technology

[0002] In modern vehicle communication systems, PCAN (such as PCAN-USB) serves as a common data exchange interface between the host computer and the Electronic Control Unit (ECU), and is widely used in scenarios such as vehicle fault diagnosis, parameter calibration, and functional verification. This type of communication typically follows the ISO 14229 standard (Unified Diagnostic Service Protocol, UDS) and interacts with the ECU through diagnostic service commands.

[0003] However, in existing technologies, data transmission between the host computer and the ECU is mostly conducted in plaintext. The communication content lacks effective encryption protection mechanisms at the physical or data link layers, making it vulnerable to cybersecurity threats such as unauthorized eavesdropping, data tampering, and replay attacks. Especially when transmitting sensitive parameters or executing critical function commands, plaintext communication seriously threatens the operational security and data trustworthiness of the entire vehicle system.

[0004] Although the ISO 14229 standard defines a secure access service (0x27 service) that authenticates the host computer via a seed-key mechanism, this mechanism only implements one-way authentication; that is, the ECU verifies the identity of the host computer. It does not provide reverse verification of the ECU's identity, nor does it impose encryption protection on subsequent data communication processes. Therefore, existing solutions struggle to meet the core security requirements of vehicular network communication in terms of confidentiality, integrity, and authenticity, especially lacking effective protection against advanced attack methods such as man-in-the-middle attacks (MITM) and replay attacks. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides a method, device, storage medium, and program product for secure communication between a host computer and an ECU, which at least solves the problem that existing technologies lack two-way authentication and data encryption mechanisms in the communication process between the host computer and the ECU, making it difficult to resist man-in-the-middle attacks and replay attacks.

[0006] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0007] Firstly, some embodiments of this application provide a secure communication method between a host computer and an ECU, applied to the host computer, including:

[0008] Obtain the ECU's encryption public key and the host computer's own decryption private key;

[0009] Generate a session key, which is used for encryption and decryption of communication data with the ECU;

[0010] The session key is encrypted using the ECU encryption public key to obtain the first ciphertext;

[0011] The first ciphertext is encrypted using the private key decrypted by the host computer to obtain the second ciphertext;

[0012] The second ciphertext is sent to the ECU via data transmission service;

[0013] After the session key is negotiated, a symmetric encryption algorithm is used to encrypt and decrypt the communication data with the ECU based on the session key.

[0014] Secondly, some embodiments of this application provide a secure communication method between a host computer and an ECU, applied to the ECU end, wherein the ECU end includes a pre-stored host computer encryption public key and an ECU decryption private key, including:

[0015] Receive double-encrypted ciphertext sent by the host computer;

[0016] The communication ciphertext is first decrypted using the host computer's encryption public key to obtain intermediate ciphertext; the intermediate ciphertext is then second decrypted using the ECU's decryption private key to obtain the session key.

[0017] Based on the session key, a symmetric encryption algorithm is used to encrypt and decrypt the communication data between the host computer and the computer.

[0018] Thirdly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0019] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform the host computer and ECU secure communication method as described above.

[0020] Fourthly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, which, when executed by a processor, implement the host computer and ECU secure communication method as described above.

[0021] Fifthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the host computer and ECU secure communication method as described above.

[0022] Compared with related technologies, the solution provided in this application constructs a hybrid encrypted communication mechanism with public key infrastructure as the root of trust. By introducing a dual encryption process during the communication initialization phase—the host computer first encrypts the session key using the ECU's public key, and then re-encrypts the result using its own private key—it effectively prevents man-in-the-middle attacks and ensures that only ECUs with legitimate decryption permissions can recover the key. This introduces a two-way implicit authentication mechanism during key exchange. Through the collaborative application of asymmetric and symmetric encryption, not only is the confidentiality and integrity of communication data protected, but the authentication capability of communication entities is also significantly enhanced. Therefore, this solution ensures end-to-end communication security while meeting the comprehensive requirements of terminal identity verification, data tamper-proofing, and lightweight implementation in the intelligent vehicle field, making it suitable for various high-security scenarios such as in-vehicle network security, remote diagnostics, and software upgrades. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other implementation methods can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is one of the flowcharts illustrating the secure communication method between the host computer and the ECU provided in the embodiments of this application;

[0025] Figure 2 This is the second flowchart illustrating the secure communication method between the host computer and the ECU provided in this application embodiment;

[0026] Figure 3 This is a schematic diagram of the communication process of the secure communication method between the host computer and the ECU provided in the embodiments of this application;

[0027] Figure 4 This is a timing diagram of the communication flow of the secure communication method between the host computer and the ECU provided in the embodiments of this application;

[0028] Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] PKI (Public Key Infrastructure) is an information security system based on asymmetric encryption mechanisms, designed to provide core security capabilities such as identity authentication, key management, data encryption, and digital signatures for data transmission in open network environments. PKI establishes secure trust between user entities by constructing a framework consisting of key pairs (public and private keys), digital certificates, Certificate Authorities (CAs), and related trust chains.

[0031] In a PKI system, each communicating entity holds a digital certificate issued by a trusted third party, which binds its identity to its public key. The sender can use the receiver's public key to encrypt sensitive data, and the receiver uses its private key to decrypt it, thus ensuring data confidentiality and tamper-proofness. Simultaneously, communicating entities can also digitally sign messages using their private keys. The receiver verifies the signature and certificate chain to confirm the integrity and authenticity of the information, thereby ensuring non-repudiation.

[0032] First Embodiment

[0033] The first embodiment of this application relates to a secure communication method between a host computer and an ECU, applied to a host computer, also known as a host terminal, which is a central control device or external computing terminal used to control, configure, manage, or interact with the ECU. Examples include test platforms, vehicle diagnostic tools, engineering development tools, or upper-level main control devices running vehicle control system management software. An ECU is an embedded microcontroller deployed inside a vehicle to perform specific control tasks, such as a power control unit, battery management system, body control unit, or advanced driver assistance system. An ECU typically possesses comprehensive hardware and software resources, including a secure storage unit for storing security keys, a cryptographic calculation module supporting encryption and decryption algorithm processing, and a data interface for communication with the host computer.

[0034] This embodiment employs a combination of asymmetric and symmetric encryption mechanisms. Through dual encryption authentication of the session key, secure negotiation and transmission of the session key between the host computer and the ECU are achieved. In subsequent communications, a symmetric encryption algorithm is used to encrypt and decrypt data based on the negotiation result, thereby constructing a secure communication channel with authentication capabilities, resistance to replay attacks, and confidentiality of communication data. (Refer to...) Figure 1 As shown, this embodiment specifically includes the following steps:

[0035] Step S101: Obtain the ECU's encryption public key and the host computer's own decryption private key.

[0036] Specifically, for step S101, obtaining the ECU's encrypted public key can be achieved by the vehicle manufacturer embedding the ECU's device public key into the host computer system during the production phase, for example, by pre-installing it in the trusted root directory of the host computer software in .pem or .der format; or, during the initial connection process, the host computer requests the ECU's public key certificate from the ECU through an authentication channel (such as pairing verification or a secure OTA channel) and verifies the trustworthiness of the public key by verifying the digital signature. The ECU's encrypted public key refers to the asymmetric encryption public key used for key exchange, which can be generated based on algorithms such as RSA, ECC, or the Chinese national cryptographic standard SM2.

[0037] The host computer's decryption private key is typically generated by the host computer itself in a trusted environment and stored in a dedicated security module, such as a TPM (Trusted Platform Module), HSM (Hardware Security Module), or encrypted USB drive, to prevent leakage. During the initialization phase, the host computer loads this private key through its local certificate management module and decrypts it via a PIN code, hardware authentication, or software sandbox. In practical applications, this private key can be an RSA private key or an SM2 private key, used to further encrypt the first ciphertext (encrypted by the ECU public key) to generate a second ciphertext, ensuring the integrity and traceability of the communication key during transmission.

[0038] In the dual encryption mechanism of this application, the ECU's public key is used for the first layer of encryption to protect the session key content from being obtained by a man-in-the-middle; the host computer's private key is used for the second layer of encryption to ensure that the ECU can verify in reverse that the message was indeed sent by the legitimate host computer, thereby achieving identity authentication.

[0039] Step S102: Generate a session key, which is used for encryption and decryption of communication data with the ECU.

[0040] In this embodiment, step S102 specifically includes:

[0041] Step S1021: In each round of passage initialization phase, perturbation data is obtained from multiple independent entropy sources and subjected to debiasing and entropy enhancement to generate random seed data with high entropy characteristics;

[0042] Step S1022: Concatenate the random seed data with the current communication session number and device identifier parameters to form a session seed vector;

[0043] Step S1023: Based on the session seed vector, apply a hash function to perform entropy compression and structured processing to obtain the derived input;

[0044] Step S1024: Execute the key derivation process in the trusted computing environment to generate a fixed-length session key that is only used in the current communication cycle based on the derivation input.

[0045] Specifically, the host computer collects perturbation data from multiple independent entropy sources. These sources may include operating system kernel-level random number generators, CPU hardware random number engines, TPM modules, or random inputs driven by physical environmental perturbations (such as user input behavior). To improve entropy quality, the collected data undergoes debiasing processing (such as Von Neumann debiasing) and entropy enhancement algorithms (such as enhancement algorithms based on binary sampling or compression coding) to generate original random seed data with high entropy characteristics.

[0046] The aforementioned random seed is combined with the current communication context information, including the current session number (e.g., a communication session ID identified by global increment or timestamp) and device identification parameters (e.g., ECU hardware serial number, MAC address, VIN code, etc.). These parameters are concatenated into a vector input according to structured rules to form the session seed vector, which serves as the unique input basis in subsequent key derivation logic.

[0047] The session seed vector is input into a preset secure hash function (such as SHA-256 or SM3), and entropy compression and structure normalization are performed on it to obtain a derived input with a stable structure and a set entropy value, ensuring that the input format meets the security and consistency requirements of the subsequent key derivation function.

[0048] In a trusted computing environment (such as a Trusted Platform Module (TPM) or a Hardware Security Module (HSM), a key derivation algorithm is invoked to perform a key generation operation on the derived inputs, ultimately outputting a session key of fixed length that meets the specifications of a symmetric encryption algorithm (such as AES-128 or SM4-128). This key is for temporary use and is only valid within the current communication cycle. After generation, it is not stored in plaintext outside the host computer to ensure data security throughout the key's lifecycle.

[0049] Through the above steps, the host computer can generate a unique, high-entropy, and securely isolated session key in each session, establishing an encrypted foundation for data communication with the ECU and preventing security risks such as key replay, prediction, or leakage.

[0050] Generating a session key in each communication cycle also includes:

[0051] Set the validity period of the session key. The validity period is constrained based on the session duration of the current communication cycle, the number of data packets threshold, or a timestamp window.

[0052] During communication, the system periodically checks whether the current time or data transmission status meets the expiration conditions of the session key. If the conditions are met, the system actively terminates the use of the current session key.

[0053] Immediately after the key's lifecycle ends, perform a memory erase operation on the session key to ensure that the key is completely removed from random access memory and prevent unauthorized access to residual data.

[0054] A new session key is then generated during the next round of communication initialization to ensure that the key is not reusable.

[0055] Specifically, in this embodiment, to ensure the security and timeliness of key usage, a dynamic session key lifecycle management mechanism is implemented within each communication cycle. First, after generating the current session key, the key's validity period is set based on preset parameter configurations. Specifically, the key expiration time T is obtained by adding the timestamp T_start when the current key was generated to the expected duration ΔT of the communication cycle. expire =T start +ΔT; Simultaneously, an internal packet counter Pkt_count is maintained, with its maximum threshold Pkt_thresh set, and the initial time window Win_start and allowed time offset window Win_offset corresponding to key generation are recorded. These parameters serve as the underlying input conditions for determining the key's validity status.

[0056] During communication, a timed detection task or event-driven hook logic is embedded to judge the following three types of failure conditions: (1) obtain the current system time T_now and compare whether T_now≥T_expire is true; (2) monitor whether Pkt_count exceeds Pkt_thresh; (3) judge whether T_now-Win_start≥Win_offset is satisfied. Once any of the above judgment conditions is true, the key invalidation event is triggered.

[0057] After the key is invalidated, the system schedules a secure cleanup routine, which calls trusted hardware or system API to perform a memory overwrite operation. This means erasing the key content at the address Addr_key, where the current key resides, by writing it multiple times with all zeros or pseudo-random numbers, ensuring that the key content at that address is unrecoverable.

[0058] Step S103: Encrypt the session key using the ECU encryption public key to obtain the first ciphertext.

[0059] Specifically, in step S103, after successfully generating the session key used for the current communication session, the host computer first calls the local encryption module to load the pre-stored encryption public key of the target ECU. This encryption public key can be generated using various asymmetric encryption algorithms, such as RSA public key, ECC public key, or SM2 public key conforming to the national cryptographic standard. This public key has been legally authenticated and distributed by the ECU device manufacturer or vehicle management system in the form of a digital certificate.

[0060] The host computer takes the session key as plaintext input and calls the encryption algorithm to perform public-key encryption. The specific process includes: encoding the session key in a format (such as encapsulating it in a PKCS#1 or ASN.1 structure) and performing an encryption operation based on the loaded ECU public key. This encryption process is typically completed in a trusted execution environment to prevent unauthorized reading of intermediate data.

[0061] The first ciphertext generated is the session key ciphertext encrypted using the ECU's public key. It can only be decrypted and obtained by the ECU holding the corresponding private key, thus achieving confidentiality protection during key transmission and preventing the session key from being eavesdropped on or intercepted in the communication link.

[0062] Step S104: Use the host computer's decryption private key to encrypt the first ciphertext to obtain the second ciphertext.

[0063] Specifically, in step S104, after generating the first ciphertext, the host computer further calls the local encryption module, taking the first ciphertext as input and loading the decryption private key held by the host computer to perform an encryption operation. This decryption private key and the host computer's encryption public key form an asymmetric key pair, which has been bound to a digital certificate issued by a certification authority and pre-deployed in a trusted operating environment. In a specific implementation, the same asymmetric encryption algorithm as in step S103 (such as RSA, ECC, or SM2) can be used to encrypt the first ciphertext using the host computer's private key, thereby forming the second ciphertext. This operation can be understood as a signature encryption of the first ciphertext. Since only a legitimate host computer holds the private key corresponding to its public key, the ECU can use the host computer's public key for reverse verification to confirm that the key indeed originates from a legitimate host computer entity, preventing man-in-the-middle attacks by forging the host computer.

[0064] Through the above-mentioned double-layer encryption process, the confidentiality of the session key during transmission is guaranteed, and two-way identity authentication between the communicating parties is achieved, thereby constructing a secure and reliable key negotiation mechanism.

[0065] Step S105: Send the second ciphertext to the ECU via the data transmission service.

[0066] Before sending the second ciphertext, the process also includes: encapsulating the second ciphertext into a data packet that conforms to the protocol requirements, specifically including:

[0067] The second ciphertext is appended with structured communication header information, which includes an identification field for identifying the encryption key type, a timestamp field for preventing replay attacks, a session number field for session management, and a verification field for verifying data integrity.

[0068] Based on the preset frame format specification, the communication header information and the second ciphertext are combined to generate a complete key exchange data frame;

[0069] The key exchange data frames are encoded and formatted to adapt to the vehicle bus transmission protocol and then sent to the ECU via the communication interface.

[0070] Specifically, after the second ciphertext is generated, it is first encapsulated using protocol messages. This process includes the following key steps. First, a structured communication header is appended to the second ciphertext to support the receiver's identification and verification. This communication header may include the following fields:

[0071] Key type identifier field: used to indicate the key type contained in the current message (e.g., whether it is an initialization key, renewal key or encryption method identifier), so that the ECU can execute the corresponding parsing logic;

[0072] Timestamp field: Records the time information when the second ciphertext was generated, used to prevent replay attacks and improve the timeliness and uniqueness of the key exchange process;

[0073] Session ID field: Identifies the communication session number to which the current key negotiation belongs, supporting multi-session parallel communication and session state management;

[0074] Integrity verification field: Mechanisms such as CRC checksum and MAC message authentication code can be used to verify the entire data frame content to ensure that the data has not been tampered with during transmission.

[0075] Next, the aforementioned communication header information and the second ciphertext content are combined bit-by-bit to generate a complete key exchange data frame. This data frame conforms to a preset frame format specification to ensure that it can be correctly decoded and parsed by the ECU. After the frame structure is constructed, encoding and format conversion processes are performed, such as applying specific bit-filling rules, frame synchronization identifiers, and encoding compression, to ensure that the data frame meets the link layer requirements of the selected vehicle bus protocol. Finally, the encoded data frame is sent to the target ECU through the physical communication interface, completing the distribution of the key negotiation data.

[0076] The above encapsulation and transmission process ensures the integrity and secure transmission of key data in the network, and also enhances the system's ability to resist unauthorized access, tampering, and replay attacks.

[0077] Step S106: After completing the negotiation of the session key, based on the session key, the communication data between the ECU is encrypted and decrypted using a symmetric encryption algorithm.

[0078] Specifically, regarding step S106, once the ECU successfully obtains the session key generated and transmitted by the host computer through the decryption process, both communicating parties possess a consistent symmetric key. Thereafter, all communication data between the host computer and the ECU is no longer transmitted directly in plaintext, but is uniformly encrypted using this session key. The symmetric encryption algorithm used may include, but is not limited to, AES, SM4, or other suitable symmetric encryption algorithms.

[0079] The encryption and decryption process is as follows:

[0080] Before sending data, the host computer uses the negotiated session key to encrypt the original business data in blocks;

[0081] After receiving the ciphertext, the ECU performs a symmetric decryption operation using the same session key to restore the original business data content;

[0082] During data transmission, a message verification code (such as a MAC) or a checksum can be attached to further enhance data integrity.

[0083] If the session key becomes invalid or expires during communication, the key update mechanism will be automatically triggered and a new key will be renegotiated to prevent security risks caused by long-term reuse.

[0084] Second Embodiment

[0085] The second embodiment of this application relates to a secure communication method between a host computer and an ECU, applied to the ECU side, for decrypting the encryption key sent by the host computer and implementing data encryption and decryption operations in subsequent communication processes. To ensure the confidentiality, integrity, and trustworthiness of the communication data, the ECU side needs to pre-store the encryption public key corresponding to the host computer and its own decryption private key. (Refer to...) Figure 2 As shown, this embodiment specifically includes the following steps:

[0086] Step S201: Receive a key exchange message sent by the host computer, wherein the key exchange message is encapsulated with communication ciphertext that has undergone double encryption.

[0087] Specifically, in step S201, the ECU receives a key exchange message sent by the host computer via a connection to the vehicle bus or diagnostic communication interface. This message encapsulates double-encrypted ciphertext, typically following a predetermined frame format, and includes header information fields such as encryption type, timestamp, and session number. Upon receiving the data, the ECU buffers the key exchange message in its receive buffer and performs frame header parsing and integrity verification to validate the message's legitimacy. This includes:

[0088] Perform message structure parsing processing on the received key exchange message to extract the frame header field, payload field, encryption identifier field and verification field;

[0089] Determine whether the frame header field matches the preset protocol start identifier to confirm the validity of the data frame;

[0090] Verify that the data length recorded in the payload field is consistent with the actual received data length;

[0091] Check whether the encryption identifier field indicates that the communication ciphertext uses a double encryption structure and conforms to the definition specifications of the key encryption level;

[0092] The verification code is calculated for the main body of the communication ciphertext based on the preset verification algorithm, and the value recorded in the verification field is compared to determine whether there is any tampering or transmission error.

[0093] If all the above verifications pass, the encrypted communication text will be input into the decryption module for decryption.

[0094] If any verification fails, the current encrypted communication is discarded, the abnormal event is recorded in the local security log, and an error response flag code is returned to the host computer, triggering the security handling process.

[0095] Specifically, a structured parsing operation is performed on the received key exchange message. Following a preset frame format protocol, key fields are extracted sequentially, including: the frame header field, the payload field (i.e., the ciphertext), the encryption identifier field, and the checksum field. This parsing process is typically implemented using a protocol parsing module to ensure the correct identification of the boundaries and semantics of each field.

[0096] The frame header field is identified to determine whether it matches the start identifier defined by the protocol, in order to confirm whether the current data frame is a legitimate start message and prevent the accidental reception of non-protocol data or malicious data packets.

[0097] The data length information recorded in the payload field is read and compared with the actual received valid data length to verify data integrity. If a data length discrepancy exists, it indicates that the message may have been truncated or contaminated during transmission and will be treated as an illegal message.

[0098] Check the content of the encryption identifier field to determine whether the current key exchange message uses a double encryption structure, and further confirm whether the encryption structure conforms to the system's preset key encryption level definition specification, such as the hierarchical structure of "the inner layer is encrypted by the ECU key and the outer layer is encrypted by the host computer key". If the structure does not conform, an exception flag will be triggered.

[0099] After passing the above structural verification, the system performs checksum calculation on the communication ciphertext (i.e., the payload field) based on a preset verification algorithm (such as CRC, hash check, or message authentication code MAC algorithm), and compares the calculation result with the original value in the message verification field to further verify whether the message has been tampered with or bit errors have occurred during transmission.

[0100] If all parsing and verification operations succeed, the extracted ciphertext is input into the security decryption module, initiating the subsequent dual decryption process. Conversely, if any verification step fails, the currently received message is immediately discarded, and the relevant error event is recorded in the local security log, including the message number, exception type, and timestamp. Simultaneously, an error response flag code is generated and returned to the host computer via the communication interface, indicating a communication anomaly and triggering the system's security handling mechanism to ensure the integrity and reliability of the communication link.

[0101] Step 202: Use the host computer's encryption public key to perform the first decryption of the communication ciphertext to obtain the intermediate ciphertext.

[0102] Specifically, in step S202, the ciphertext extracted from the payload field is input into a pre-defined decryption module. This module embeds an encryption engine that supports asymmetric decryption algorithms (such as RSA or ECC). Before performing the decryption operation, the system identifies the current encryption structure based on the encryption identifier field in the message and confirms that the ciphertext was encrypted using the host computer's decryption private key. Therefore, the system uses its locally stored host computer encryption public key as the decryption key to perform the first-level decryption operation.

[0103] The specific processing flow is as follows: The system uses an asymmetric encryption / decryption algorithm, taking the ciphertext as the input data stream and the host computer's encryption public key as the decryption factor to perform decryption calculations. The decryption process can be based on modular exponentiation or elliptic curve transformation of the encryption algorithm to restore the ciphertext to intermediate plaintext data, i.e., intermediate ciphertext. This intermediate ciphertext is still encrypted data; its content is the ciphertext of the session key initially generated by the host computer encrypted with the ECU's encryption public key. Therefore, this first decryption operation only completes the outer layer decryption task of the ciphertext and does not expose the final session key, ensuring that the entire exchange process remains securely encrypted until the key undergoes dual authentication.

[0104] This decryption layer uses the host computer's public key to restore the ciphertext, which in turn is encrypted using the host computer's private key. Only a legitimate host computer possessing the private key can generate ciphertext that can be correctly decrypted by the public key. If decryption fails, it indicates that the key was not encrypted by a trusted host computer, or that the data has been tampered with. Therefore, the first layer of decryption is to authenticate the host computer's identity and ensure that the received key exchange data is indeed generated by a trusted host computer, preventing man-in-the-middle attacks or forged key injection attempts.

[0105] Step 203: Use the ECU decryption private key to perform a second decryption of the intermediate ciphertext and obtain the session key.

[0106] Specifically, in step S203, after completing the first-level decryption operation and successfully extracting the intermediate ciphertext encrypted by the host computer using the ECU public key, the ECU further uses its own ECU decryption private key to perform a second-level decryption process on the intermediate ciphertext in order to restore the session key that is actually used for subsequent data encryption and decryption.

[0107] This second-layer decryption process typically relies on asymmetric encryption algorithms such as RSA or ECC, using the private key stored securely in the ECU to decrypt the intermediate ciphertext. Since the intermediate ciphertext is encrypted using the host computer's public key during generation, only the corresponding ECU decryption private key can restore it. Therefore, even if an attacker intercepts the intermediate ciphertext, they cannot reverse-engineer the session key within it.

[0108] Once the ECU successfully obtains the session key, it can be used for symmetric encryption and decryption of communication data between the ECU and the host computer, ensuring a high level of security in terms of confidentiality, integrity, and anti-counterfeiting for the entire communication session.

[0109] Furthermore, when a failure occurs during the decryption process of the ciphertext, the method also includes:

[0110] Write the event of current key decryption failure to the local security event queue and mark the current communication session as abnormal;

[0111] Determine whether the failure is due to an invalid session key, an abnormal encrypted payload structure, or an inconsistent session number, and classify and record the error type accordingly;

[0112] Immediately mark the current session key as invalid and terminate subsequent data communication processes based on the session key;

[0113] Return a session failure notification frame to the host computer, which includes an error type identifier and a key renegotiation instruction;

[0114] After receiving the session key renegotiation request from the host computer, the key negotiation process is re-initialized to complete the generation and update of the new session key;

[0115] If decryption fails multiple times consecutively or the number of key negotiation failures exceeds a preset threshold, a security lockout mechanism is triggered to restrict key renegotiation operations within a short period of time, in order to prevent brute-force replay or attack behavior.

[0116] To enhance the system's resilience and attack prevention capabilities in the event of communication anomalies, a complete error response and key renegotiation mechanism will be triggered when the ECU fails to decrypt the encrypted communication data. Specifically, the ECU will first write the event information of the current key decryption failure to its local security event queue and mark the current communication session as abnormal to prevent erroneous keys from continuing to participate in communication.

[0117] Subsequently, the reasons for decryption failure will be classified and analyzed, including but not limited to: invalid session key (such as key not being negotiated successfully or being tampered with), abnormal encrypted payload structure (such as ciphertext field format not matching), inconsistent session number (such as possible replay attack), etc., and corresponding error type identifiers will be generated accordingly for subsequent log analysis and host computer response.

[0118] Once decryption failure is confirmed, the system will immediately mark the current session key as "invalid" and terminate all encryption and decryption processes that rely on that key to prevent further spread of leaked data or erroneous operations. Simultaneously, the ECU sends a session failure notification frame to the host computer via the communication interface. This frame carries an error type identifier and a key renegotiation instruction, prompting the host computer to re-initiate the key exchange process.

[0119] If the host computer responds promptly and sends a new key negotiation request, the ECU will re-enter the key initialization phase, generate and update a new session key according to the established process, and restore the secure communication channel. To defend against potential replay attacks or brute-force attempts, if the system detects multiple consecutive decryption failures or a key negotiation failure count exceeding a set threshold, a security lockout mechanism will be triggered. This will suspend new key negotiation requests for a limited time and record the behavior as a potential attack event, further enhancing the overall ECU communication system's anti-attack capability and fault tolerance stability.

[0120] Step 204: Based on the session key, use a symmetric encryption algorithm to encrypt and decrypt the communication data between the host computer and the computer.

[0121] In step S204, after successfully obtaining the session key, the ECU enters the secure communication phase. Based on this session key, it establishes an encrypted communication channel with the host computer and performs encryption and decryption processing on the subsequently sent and received data. Specifically, the ECU uses the session key as the core input parameter of a symmetric encryption algorithm, applying symmetric encryption algorithms such as AES or SM4 to encrypt the data sent to the host computer and decrypt the encrypted data received from the host computer, thereby ensuring the confidentiality and tamper resistance of the communication content during transmission.

[0122] In actual operation, the data processing module on the ECU inputs the original data payload into the encryption engine before each data transmission. It then performs symmetric encryption with the currently valid session key to generate a ciphertext frame. Simultaneously, when receiving data, after parsing the ciphertext portion, it calls the same encryption algorithm and the session key to perform reverse decryption to restore the original plaintext data.

[0123] To improve communication efficiency and key security, the system can also proactively refresh the session key based on the current communication session status, when a certain time interval or the number of data packets reaches a threshold, to ensure that the key does not become less secure due to long-term reuse.

[0124] Third Embodiment

[0125] The third embodiment of this application relates to a secure communication method between a host computer and an ECU. This method combines a negotiation mechanism between the host computer and the ECU to achieve dynamic generation, secure transmission, and symmetric encrypted communication of the session key, thereby strengthening the anti-replay and anti-eavesdropping capabilities of the communication link. Figure 3 As shown, the host computer is used to generate and encrypt the session key, and the ECU is used to decrypt and obtain the session key, thereby establishing a secure communication connection.

[0126] The process includes:

[0127] Step 1: The host computer randomly generates a session key K;

[0128] Step 2: The host computer uses the ECU's public key to encrypt K, obtaining ciphertext C;

[0129] Step 3: The host computer then uses its own decryption private key to encrypt K, obtaining ciphertext D;

[0130] Step 4: The host computer sends the encrypted D to the ECU.

[0131] Step 5: The ECU uses the host computer's public key to perform the first decryption of ciphertext D, obtaining ciphertext C;

[0132] Step 6: The ECU then uses its own decryption private key to perform a second decryption of the ciphertext C, thereby restoring the session key K;

[0133] Step 7: After the ECU obtains the session key K, it will use it for symmetric encryption and decryption operations of subsequent communication data.

[0134] Figure 4 This is a timing diagram illustrating the communication flow of the secure communication method between the host computer and the ECU in this embodiment of the invention. It shows the complete timing process of negotiating a session key between the host computer and the ECU and performing encrypted communication based on that key, specifically including two stages:

[0135] Negotiating Session Key Phase:

[0136] The host computer initiates an extended session request service to the ECU (service identifier code is 0x10), and the ECU returns an extended session confirmation;

[0137] The host computer initiates a download request service (service identifier code is 0x34), and the ECU returns a download service response;

[0138] The host computer randomly generates a session key K in a secure environment and generates ciphertext D based on a dual encryption mechanism;

[0139] The host computer transmits the encrypted D to the ECU via a data transmission request service (service identifier code 0x36);

[0140] After receiving the ciphertext D, the ECU obtains the session key K through decryption.

[0141] Data encryption transmission stage:

[0142] Based on the negotiated session key K, all subsequent service requests during communication are exchanged under symmetric encryption protection, ensuring the confidentiality and integrity of the data.

[0143] As can be seen from the above embodiments, this application constructs a hybrid encrypted communication mechanism with public key infrastructure as the root of trust. By introducing a dual encryption process during the communication initialization phase—that is, the host computer first encrypts the session key using the ECU's encryption public key, and then encrypts the encryption result again using its own decryption private key—it effectively prevents man-in-the-middle attacks and ensures that only ECUs with legitimate decryption permissions can recover the key. This introduces a two-way binding implicit authentication mechanism during key exchange. Through the synergistic application of asymmetric and symmetric encryption, not only is the confidentiality and integrity of communication data protected, but the authentication capability of communication entities is also significantly enhanced. Therefore, this scheme, while ensuring the security of the entire communication link, meets the comprehensive requirements of terminal identity verification, data anti-tampering, and lightweight implementation in the field of intelligent vehicles, and is suitable for various high-security scenarios such as in-vehicle network security, remote diagnostics, and software upgrades.

[0144] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0145] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0146] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform a host computer and ECU secure communication method as provided in any one or more of the above embodiments. Figure 5 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0147] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 5 Taking the example of a connection between China and Israel via a bus.

[0148] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0149] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0150] In this embodiment, a computer-readable medium stores a computer program / instructions, which, when executed by a processor, implement a secure communication method between a host computer and an ECU provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not be assembled into that device. The computer-readable medium carries one or more computer-readable instructions.

[0151] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0152] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0153] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0154] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0155] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0156] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0157] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0158] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0159] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first" and "second" are used only to distinguish descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0160] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for secure communication between a host computer and an ECU, characterized in that, Applications on the host computer side include: Obtain the ECU's encryption public key and the host computer's own decryption private key; Generate a session key, which is used for encryption and decryption of communication data with the ECU; The session key is encrypted using the ECU encryption public key to obtain the first ciphertext; The first ciphertext is encrypted using the private key decrypted by the host computer to obtain the second ciphertext; The second ciphertext is sent to the ECU via data transmission service; After the session key is negotiated, a symmetric encryption algorithm is used to encrypt and decrypt the communication data with the ECU based on the session key.

2. The secure communication method between the host computer and the ECU according to claim 1, characterized in that, The step of generating the session key includes: In each round of passage initialization phase, perturbation data q is obtained from multiple independent entropy sources for debiasing and entropy enhancement to generate random seed data with high entropy characteristics; The random seed data is concatenated with the current communication session number and device identifier parameters to form a session seed vector; Based on the aforementioned session seed vector, a hash function is applied for entropy compression and structuring to obtain derived input; A key derivation process is performed in a trusted computing environment to generate a fixed-length session key that is used only in the current communication cycle, based on the derived input.

3. The secure communication method between the host computer and the ECU according to claim 1, characterized in that, Generating a session key in each communication cycle also includes: Set the validity period of the session key, which is constrained based on the session duration of the current communication cycle, a data packet quantity threshold, or a timestamp window; During communication, the system periodically checks whether the current time or data transmission status meets the expiration conditions of the session key. If the conditions are met, the system actively terminates the use of the current session key. Immediately after the key's lifecycle ends, perform a memory erase operation on the session key to ensure that the key is completely removed from the random access memory and prevent unauthorized access to residual data. A new session key is then generated during the next round of communication initialization to ensure that the key is not reusable.

4. The secure communication method between the host computer and the ECU according to claim 1, characterized in that, Before sending the second ciphertext, the method further includes: encapsulating the second ciphertext into a data packet that conforms to the protocol requirements, specifically including: The second ciphertext is appended with structured communication header information, which includes an identification field for identifying the encryption key type, a timestamp field for preventing replay attacks, a session number field for session management, and a verification field for verifying data integrity. Based on the preset frame format specification, the communication header information is combined with the second ciphertext to generate a complete key exchange data frame; The key exchange data frame is encoded and format converted to adapt to the vehicle bus transmission protocol, and then sent to the ECU via the communication interface.

5. A method for secure communication between a host computer and an ECU, characterized in that, Applied to the ECU (Electronic Control Unit), the ECU includes a pre-stored host computer encryption public key and an ECU decryption private key, including: Receive a key exchange message sent by a host computer, wherein the key exchange message is encapsulated with communication ciphertext that has undergone double encryption. The communication ciphertext is first decrypted using the host computer's encryption public key to obtain intermediate ciphertext. The intermediate ciphertext is decrypted a second time using the ECU decryption private key to obtain the session key; Based on the session key, a symmetric encryption algorithm is used to encrypt and decrypt the communication data between the host computer and the computer.

6. The secure communication method between the host computer and the ECU according to claim 5, characterized in that, After receiving the key exchange message, the process also includes: Perform message structure parsing processing on the received key exchange message to extract the frame header field, payload field, encryption identifier field and verification field; Determine whether the frame header field matches the preset protocol start identifier to confirm the legality of the data frame; Verify whether the data length recorded in the payload field is consistent with the actual received data length; Check whether the encryption identifier field indicates that the communication ciphertext adopts a double encryption structure, and whether q conforms to the definition specification of key encryption level; Based on a preset verification algorithm, a checksum is calculated for the main body of the ciphertext. The value recorded in the verification field is compared with q to determine whether there is any tampering or transmission error. If all the above verifications pass, the encrypted communication text is input to the decryption module for decryption. If any verification fails, the current encrypted communication is discarded, the abnormal event is recorded in the local security log, and an error response flag code is returned to the host computer, triggering the security handling process.

7. The secure communication method between the host computer and the ECU according to claim 5, characterized in that, When a failure event occurs during the decryption process of the ciphertext, the method further includes: Write the event of current key decryption failure to the local security event queue, and mark the current communication session as abnormal; Determine whether the failure is due to an invalid session key, an abnormal encrypted payload structure, or an inconsistent session number, and q classifies and records the error type accordingly. Immediately mark the current session key as invalid, and terminate subsequent data communication processes based on the session key. Return a session failure notification frame to the host computer, which includes an error type identifier and a key renegotiation instruction; After receiving the session key renegotiation request from the host computer, the key negotiation process is re-initialized to complete the generation and update of the new session key; If decryption fails multiple times consecutively or the number of key negotiation failures exceeds a preset threshold, a security lockout mechanism is triggered to restrict key renegotiation operations within a short period of time, in order to prevent brute-force replay or attack behavior.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions, which, when executed, cause the processors to perform the host computer and ECU secure communication method as described in any one of claims 1-7.

9. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the secure communication method between the host computer and the ECU as described in any one of claims 1-7.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the secure communication method between the host computer and the ECU as described in any one of claims 1-7.

Images