An encryption transmission method and system based on AES128-CBC algorithm

Abstract

The application discloses an encryption transmission method and system based on an AES128-CBC algorithm, and relates to the technical field of vehicle electronic vehicle-mounted network security. The method comprises the following steps: preconfiguring a fixed key and a fixed initial vector with a length not less than 16 bytes; establishing a double-dimension hierarchical mapping relationship that one CAN identifier corresponds to one group of keys, different security levels under the same CAN identifier correspond to exclusive initial vectors, and different ECUs are configured with independent key groups; completing hierarchical encryption transmission of a diagnosis message based on the AES128-CBC algorithm; and binding hierarchical security access authentication and diagnosis operation permission compulsorily, wherein read-only operation does not need security access authentication, part of read-write functions are opened after low security level authentication, and high-risk read-write operation can be executed only after high-level authentication. The application can effectively solve the problems of chaotic encryption levels, missing permission control and easy illegal use of high-risk operation in the traditional scheme, and meet the security compliance requirements of vehicle diagnosis, firmware flashing, parameter calibration and other scenes.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic vehicle network security technology, and in particular to an encrypted transmission method and system based on the AES128-CBC algorithm. Background Technology

[0002] With the rapid iteration of electronic control technologies in intelligent connected vehicles and new energy vehicles, the scale and frequency of CAN bus data interaction between in-vehicle communication terminals, electronic control units (ECUs), and on-board diagnostic tools have significantly increased. As the core communication carrier for automotive electronics, the CAN bus carries the transmission of core and sensitive data such as vehicle power control, vehicle status monitoring, fault diagnosis, electronic control parameter calibration, and firmware upgrades. Currently, in-vehicle CAN communication generally uses plaintext transmission or simple encryption schemes, leading to a growing risk of attacks such as bus eavesdropping, data interception, message tampering, malicious message injection, and unauthorized diagnostic access. If core electronic control data is tampered with, leaked, or forged, it will directly result in loss of vehicle power control, abnormal vehicle functions, and failure of the diagnostic system, seriously threatening the overall vehicle driving safety and the operational stability of the electronic control system.

[0003] In existing technologies, Advanced Encryption Standard 128-bit Cipher Block Chaining (AES128-CBC) is widely used for encryption protection in scenarios such as automotive UDS diagnostics, ECU flashing, and parameter calibration due to its high encryption strength, moderate computational overhead, and compatibility with embedded automotive chips. Under the ISO14229 UDS unified diagnostic protocol system, high-risk operations such as in-depth automotive diagnostics, firmware flashing, and parameter writing must be performed only after secure access authentication has been obtained. However, existing automotive CAN encryption solutions have the following core defects in mass production deployment:

[0004] 1. Lack of UDS security hierarchical encryption mechanism: Traditional automotive encryption solutions use a unified key and unified IV (Initialization Vector) to encrypt all CAN diagnostic messages, which is not adapted to the multi-security level architecture of automakers' UDS diagnostics. The security levels of different permission diagnostic operations, such as vehicle basic status reading, fault code reading, ECU parameter writing, and whole vehicle firmware flashing, vary greatly. The unified encryption method leads to the rampant abuse of high-risk flashing operation permissions, which can be easily exploited by malicious devices to illegally flash and tamper with underlying electronic control parameters.

[0005] 2. The key and initialization vector are not bound together. The initialization vector of the dedicated key is not configured with 16 bytes or more as per the manufacturer's specifications. Most solutions have insufficient key length and no standard for initialization vector randomization, which does not comply with the vehicle manufacturer's supplier-specific key configuration specifications. At the same time, a one-to-one mapping relationship between the CAN identifier (CANID), security level and key initialization vector is not implemented, making it impossible to configure dedicated encryption parameters for different ECUs, different diagnostic services, and different security dimensions, resulting in extremely poor mass production security and adaptability.

[0006] 3. Decoupling of UDS secure access and function execution: Traditional encryption schemes only encrypt message transmission and do not bind security authentication results to diagnostic permissions. Industry standard UDS diagnostic procedures require that devices that have not passed the corresponding level of security access are prohibited from performing high-risk operations such as ECU writing, firmware flashing, and parameter calibration. Existing solutions lack permission interception mechanisms, and once encryption is passed, all diagnostic functions can be executed directly, posing a significant vehicle-wide security risk.

[0007] 4. Lack of manufacturer-specific key management system; general encryption schemes are not adapted to the differentiated key configuration specifications of OEMs and Tier 1 suppliers; lack of hierarchical key storage, permission matching, and illegal access interception mechanisms; cannot meet the hierarchical security control requirements of vehicle mass production, after-sales diagnostics, and firmware upgrades; and does not comply with the vehicle UDS diagnostic security compliance standards.

[0008] In summary, existing AES128-CBC-based automotive encryption solutions are not deeply integrated with the diagnostic protocol security system. They lack a hierarchical encryption mechanism with CAN identifiers and security levels, hierarchical configuration of dedicated key initial vectors, and mandatory control logic for security access permissions. High-risk diagnostic operations lack access control, which fails to meet the high security and compliance requirements of automakers for mass production of automotive diagnostics. Summary of the Invention

[0009] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes an encrypted transmission method and system based on the AES128-CBC algorithm.

[0010] In a first aspect, embodiments of the present invention provide an encrypted transmission method based on the AES128-CBC algorithm, comprising:

[0011] S100. Based on the vehicle manufacturer's safety specifications, pre-configure multiple sets of encryption parameters. Each set of encryption parameters includes a fixed AES encryption key and a fixed initialization vector with a length of not less than 16 bytes. Establish a hierarchical encryption parameter mapping table based on the encryption parameters and solidify the hierarchical encryption parameter mapping table into the dedicated storage area of ​​the legitimate diagnostic equipment and the vehicle ECU.

[0012] When the S200 diagnostic device initiates a UDS diagnostic request, it identifies the CAN identifier of the current diagnostic message and the security level corresponding to the UDS service, retrieves the fixed AES encryption key and fixed initialization vector matched in the mapping table, uses the AES128-CBC algorithm to encrypt the UDS diagnostic plaintext message into blocks, encapsulates it into an encrypted diagnostic CAN frame, and sends it to the vehicle CAN bus.

[0013] S300. The vehicle ECU receives encrypted diagnostic CAN frames, parses the CAN identifier and security level information carried in the message, retrieves the corresponding key and initial vector stored locally, and decrypts the UDS plaintext message through the AES128-CBC algorithm.

[0014] S400.ECU triggers the corresponding level of security access authentication based on the security level of the UDS service; read-only UDS diagnostic operations can be executed without security access authentication; if the low security level authentication is successful, some read-write diagnostic operation permissions are granted; if the high security level authentication is successful, all high-risk read-write diagnostic operation permissions are unlocked.

[0015] Furthermore, in S100, a hierarchical encryption parameter mapping table is established based on the encryption parameters. The specific establishment rules include: one CAN identifier uniquely corresponds to a set of AES encryption keys; different UDS security levels under the same CAN identifier are matched with different fixed initialization vectors; different vehicle ECUs correspond to independent CAN identifiers and exclusive key sets; the UDS security levels are at least divided into low security levels and high security levels, with low security levels corresponding to read-only and low-risk read-write diagnostic services, and high security levels corresponding to high-risk read-write diagnostic services.

[0016] Furthermore, the read-only diagnostic services include fault code reading, vehicle status query, and version information reading; the read-write diagnostic services include ECU parameter writing, vehicle firmware flashing, electronic control parameter calibration modification, and actuator active control; the key groups of different ECUs are independent of each other, and leakage of encrypted parameters of a single ECU does not affect the communication security of other ECUs.

[0017] Furthermore, in S200, before encrypting the diagnostic message, ISO-TP packet assembly and segmentation processing is performed according to the ISO15765 protocol. The specific methods include: diagnostic messages with a data length of no more than 8 bytes are transmitted in a single frame, and diagnostic messages with a data length of more than 8 bytes are transmitted in multiple frames. Fragmentation transmission and flow control are completed through the first frame, consecutive frames and flow control frames. AES128-CBC encryption operation is performed on the complete UDS data block after packet assembly, and after decryption, it is restored to a standard UDS message according to the protocol rules.

[0018] Furthermore, in S400, high-security access authentication follows the service specifications of the ISO14229 diagnostic protocol, with the specific process as follows:

[0019] The diagnostic device sends a session control command to switch to an extended diagnostic session or a programmed diagnostic session;

[0020] The diagnostic device sends a seed request command to the ECU, and the ECU generates a time-sensitive random seed, which is returned to the diagnostic device via ISO-TP multi-frame method;

[0021] The diagnostic equipment performs an encryption operation on the seed based on the matched exclusive key and initialization vector, generates a verification key, and sends it to the ECU;

[0022] The system verifies the consistency of the local key. If the verification passes, high-security authentication is completed, and the corresponding diagnostic permissions are unlocked within the session validity period. If the verification fails, a negative response is returned. If the failure exceeds a preset number of times, a cooling-off lockout mechanism is triggered.

[0023] Furthermore, read-only UDS diagnostic operations can be executed without secure access authentication; if low-security-level authentication passes, some read-write diagnostic operation permissions are granted; if high-security-level authentication passes, all high-risk read-write diagnostic operation permissions are unlocked.

[0024] Read-only UDS diagnostic operations (fault code reading, status query, version information reading, etc.) can be executed directly without security access authentication; if low-security-level authentication is successful, some read-write diagnostic operation permissions are granted, while high-risk operation requests such as ECU parameter writing, firmware flashing, and calibration modification are strictly blocked, and a negative response is returned if the conditions are not met.

[0025] If the high-security-level security access authentication is successfully completed, the corresponding high-risk diagnostic operation permissions will be unlocked, allowing the execution of ECU parameter writing, vehicle firmware flashing, and electronic control calibration modification functions. The security access authentication status is bound to the session lifecycle. After the session times out or returns to the default session, the unlocked high permissions will automatically become invalid.

[0026] Furthermore, it also includes a data integrity calibration step, the specific methods of which include:

[0027] Before and after data encryption, the diagnostic data bytes are aligned, matched and calibrated according to the ISO14229 diagnostic protocol specification to ensure that the byte length and data points of the diagnostic data are completely consistent before and after encryption and decryption, and to prevent byte misalignment and data loss.

[0028] Furthermore, it also includes security logging and anomaly interception steps, the specific methods of which include:

[0029] The entire process of UDS security authentication, encrypted transmission, and diagnostic operation logs is recorded; abnormal operations such as key initialization vector mismatch, decryption failure, unauthorized permission attempts, and unauthorized flashing / writing are proactively intercepted, the diagnostic process is terminated, and vehicle safety alarms are reported.

[0030] Secondly, this invention also discloses an encrypted transmission system based on the AES128-CBC algorithm, comprising: a hierarchical encryption parameter configuration and secure storage module, a diagnostic request hierarchical encryption and message encapsulation module, an encrypted diagnostic message parsing and decryption restoration module, and a hierarchical security authentication and diagnostic access control module; wherein:

[0031] The hierarchical encryption parameter configuration and secure storage module is used to pre-configure multiple sets of encryption parameters according to the vehicle manufacturer's safety specifications. Each set of encryption parameters includes a fixed AES encryption key and a fixed initialization vector with a length of not less than 16 bytes. A hierarchical encryption parameter mapping table is established based on the encryption parameters, and the hierarchical encryption parameter mapping table is fixed to the dedicated storage area of ​​legitimate diagnostic equipment and vehicle ECU.

[0032] The diagnostic request hierarchical encryption and message encapsulation module is used to identify the CAN identifier of the current diagnostic message and the security level corresponding to the UDS service when the diagnostic device initiates a UDS diagnostic request. It retrieves the fixed AES encryption key and fixed initialization vector matched in the mapping table, uses the AES128-CBC algorithm to encrypt the UDS diagnostic plaintext message into blocks, encapsulates it into an encrypted diagnostic CAN frame and sends it to the vehicle CAN bus.

[0033] The encrypted diagnostic message parsing and decryption module is used by the vehicle ECU to receive encrypted diagnostic CAN frames, parse the CAN identifier and security level information carried in the message, retrieve the corresponding key and initial vector stored locally, and decrypt the UDS plaintext message through the AES128-CBC algorithm.

[0034] The tiered security authentication and diagnostic permission control module is used by the ECU to trigger corresponding level of security access authentication based on the security level of the UDS service; read-only UDS diagnostic operations can be executed without security access authentication; if the low security level authentication is successful, some read-write diagnostic operation permissions are granted; if the high security level authentication is successful, all high-risk read-write diagnostic operation permissions are unlocked.

[0035] Thirdly, the present invention also discloses an in-vehicle electronic device, comprising:

[0036] One or more processors;

[0037] Memory, used to store one or more programs and hierarchical encryption parameter mapping tables;

[0038] One or more I / O interfaces are provided for information interaction between the processor and the vehicle CAN bus and external diagnostic interfaces; when the program is executed by the processor, the method described in any one of claims 1 to 8 is implemented; wherein the vehicle electronic device is a vehicle ECU or a legitimate diagnostic device.

[0039] This invention discloses an encrypted transmission method and system based on the AES128-CBC algorithm. The method includes pre-configuring a fixed key and a fixed initialization vector with a length of no less than 16 bytes; establishing a two-dimensional hierarchical mapping relationship where a CAN identifier corresponds to a set of keys, different security levels under the same CAN identifier correspond to exclusive initialization vectors, and different ECUs are configured with independent key groups; and performing hierarchical encrypted transmission of diagnostic messages based on the AES128-CBC algorithm, forcibly binding hierarchical security access authentication with diagnostic operation permissions. A lower security level is not equivalent to read-only. Correct statement: Read-only operations do not require security access authentication; after passing authentication at a lower security level, partial read / write functionality is enabled; high-risk read / write operations require higher-level authentication before execution. This invention effectively solves the problems of chaotic encryption layers, lack of access control, and susceptibility to unauthorized use of high-risk operations in traditional solutions, meeting the security and compliance requirements of scenarios such as vehicle diagnostics, firmware flashing, and parameter calibration.

[0040] Compared with the prior art, the present invention has the following beneficial effects:

[0041] 1. Strong compliance with automakers and high compatibility with mass production. This invention uses a fixed key and initialization vector of 16 bytes or more, follows the standardized configuration rules of single CAN identifier single key, hierarchical initialization vector with the same ID, and multiple keys for multiple ECUs, abandons random parameters and unified encryption mode, and is fully compatible with the security specifications of automakers in all scenarios of mass production, after-sales diagnosis and firmware upgrade, solving the problems of chaotic encryption layers and low security in traditional solutions.

[0042] 2. Strict access control and high vehicle security. This invention deeply integrates tiered security access authentication with high-risk diagnostic operations. Parameter writing and firmware flashing operations are strictly prohibited without passing the corresponding level of authentication, thus blocking the risk of unauthorized devices tampering with electronic control data and maliciously flashing firmware from the ground up, constructing a closed-loop vehicle UDS diagnostic security protection system.

[0043] 3. Excellent real-time performance and strong compatibility. The lightweight encryption algorithm is compatible with various low-computing-power automotive embedded ECU chips, without requiring modifications to the vehicle hardware or the original CAN and UDS architectures. It is compatible with all mainstream vehicle electronic control systems, resulting in extremely low mass production costs.

[0044] 4. Convenient operation and maintenance auditing with strong traceability. The system records security authentication, encrypted transmission, permission operation, and anomaly interception logs throughout the entire process. With dedicated optimizations such as message correspondence, byte calibration, and multi-frame packet assembly, it not only ensures stable diagnostic communication but also enables rapid tracing of security anomalies, meeting the vehicle information security compliance auditing needs of automakers. Attached Figure Description

[0045] Figure 1 A flowchart illustrating an encrypted transmission method based on the AES128-CBC algorithm provided in an embodiment of the present invention;

[0046] Figure 2 This is a schematic diagram of the high-security-level function execution flow provided in an embodiment of the present invention;

[0047] Figure 3 A structural block diagram of an encrypted transmission system based on the AES128-CBC algorithm provided in an embodiment of the present invention;

[0048] Figure 4 This is a structural block diagram of an in-vehicle electronic device provided in an embodiment of the present invention. Detailed Implementation

[0049] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0050] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0051] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0052] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0053] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0054] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0055] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides an encrypted transmission method and system based on the AES128-CBC algorithm.

[0056] This embodiment discloses an encrypted transmission method based on the AES128-CBC algorithm, such as... Figure 1 ,include:

[0057] S100. Based on the vehicle manufacturer's safety specifications, pre-configure multiple sets of encryption parameters. Each set of encryption parameters includes a fixed AES encryption key and a fixed initialization vector with a length of not less than 16 bytes. Establish a hierarchical encryption parameter mapping table based on the encryption parameters and solidify the hierarchical encryption parameter mapping table into the dedicated storage area of ​​the legitimate diagnostic equipment and the vehicle ECU.

[0058] In S100 of this embodiment, a hierarchical encryption parameter mapping table is established according to the encryption parameters. The specific establishment rules include: one CAN identifier uniquely corresponds to a set of AES encryption keys; different UDS security levels under the same CAN identifier are matched with different fixed initialization vectors; different vehicle ECUs correspond to independent CAN identifiers and exclusive key sets; the UDS security levels are at least divided into low security levels and high security levels, with low security levels corresponding to read-only and low-risk read-write diagnostic services, and high security levels corresponding to high-risk read-write diagnostic services.

[0059] The read-only diagnostic services include fault code reading, vehicle status query, and version information reading; the read-write diagnostic services include ECU parameter writing, vehicle firmware flashing, electronic control parameter calibration modification, and actuator active control; the key groups of different ECUs are independent of each other, and leakage of encrypted parameters of a single ECU does not affect the communication security of other ECUs.

[0060] When the S200 diagnostic device initiates a UDS diagnostic request, it identifies the CAN identifier of the current diagnostic message and the security level corresponding to the UDS service, retrieves the fixed AES encryption key and fixed initialization vector matched in the mapping table, uses the AES128-CBC algorithm to encrypt the UDS diagnostic plaintext message into blocks, encapsulates it into an encrypted diagnostic CAN frame, and sends it to the vehicle CAN bus.

[0061] In S200 of this embodiment, before encrypting the diagnostic message, ISO-TP packet assembly and segmentation processing is performed according to the ISO15765 protocol. The specific method includes: diagnostic messages with a data length of no more than 8 bytes are transmitted in a single frame, and diagnostic messages with a data length of more than 8 bytes are transmitted in multiple frames. Fragmentation transmission and flow control are completed through the first frame, consecutive frames and flow control frames. The AES128-CBC encryption operation is performed on the complete UDS data block after packet assembly, and after decryption, it is restored to a standard UDS message according to the protocol rules.

[0062] S300. The vehicle ECU receives encrypted diagnostic CAN frames, parses the CAN identifier and security level information carried in the message, retrieves the corresponding key and initial vector stored locally, and decrypts the UDS plaintext message through the AES128-CBC algorithm.

[0063] S400.ECU triggers the corresponding level of security access authentication based on the security level of the UDS service; read-only UDS diagnostic operations can be executed without security access authentication; if the low security level authentication is successful, some read-write diagnostic operation permissions are granted; if the high security level authentication is successful, all high-risk read-write diagnostic operation permissions are unlocked.

[0064] In S400 of this embodiment, the high-security-level secure access authentication follows the service specifications of the ISO14229 diagnostic protocol, and the specific process is as follows:

[0065] The diagnostic device sends a session control command to switch to an extended diagnostic session or a programmed diagnostic session;

[0066] The diagnostic device sends a seed request command to the ECU, and the ECU generates a time-sensitive random seed, which is returned to the diagnostic device via ISO-TP multi-frame method;

[0067] The diagnostic equipment performs an encryption operation on the seed based on the matched exclusive key and initialization vector, generates a verification key, and sends it to the ECU;

[0068] The system verifies the consistency of the local key. If the verification passes, high-security authentication is completed, and the corresponding diagnostic permissions are unlocked within the session validity period. If the verification fails, a negative response is returned. If the failure exceeds a preset number of times, a cooling-off lockout mechanism is triggered.

[0069] In this embodiment, read-only UDS diagnostic operations can be executed without secure access authentication; if low-security-level authentication passes, some read-write diagnostic operation permissions are granted; if high-security-level authentication passes, all high-risk read-write diagnostic operation permissions are unlocked, specifically including:

[0070] Read-only UDS diagnostic operations (fault code reading, status query, version information reading, etc.) can be executed directly without security access authentication; if low-security-level authentication is successful, some read-write diagnostic operation permissions are granted, while high-risk operation requests such as ECU parameter writing, firmware flashing, and calibration modification are strictly blocked, and a negative response is returned if the conditions are not met.

[0071] If the high-security-level security access authentication is successfully completed, the corresponding high-risk diagnostic operation permissions will be unlocked, allowing the execution of ECU parameter writing, vehicle firmware flashing, and electronic control calibration modification functions. The security access authentication status is bound to the session lifecycle. After the session times out or returns to the default session, the unlocked high permissions will automatically become invalid.

[0072] In this embodiment, the CAN message interaction timing during the high-security level authentication process is described in detail, in conjunction with the ISO-TP protocol specification, such as... Figure 2 As shown.

[0073] This embodiment uses an extended diagnostic session mode, following the ISO14229-1 protocol specification. The complete process is as follows:

[0074] 1. Switch extended diagnostic session

[0075] The diagnostic instrument sent a single-frame request: 02 10 03

[0076] The first byte 02 indicates that the effective data length is 2 bytes; 0x10 is the diagnostic session control service ID, and 0x03 is the sub-function, the goal of which is to switch to an extended session.

[0077] ECU returns a positive response frame: 06 50 03 xx xx xx xx;

[0078] 0x50 is the SID of the positive response from the session control service (request SID + 0x40); 06 indicates a payload of 6 bytes; the last 4 bytes are the P2 and P2* session timeout parameters issued by the ECU, defining the maximum allowed waiting time for subsequent messages. After a successful session switch, the timer starts, and if there is no interaction after the timeout, it will automatically revert to the default session.

[0079] 2. Request secure access to the seed

[0080] The diagnostic instrument sends a single frame requesting to retrieve a seed: 02 27 07;

[0081] 0x27 is the security access service ID, and sub-function 0x07 represents the seed for the corresponding security level of the request.

[0082] Because the seed data length is 18 bytes, exceeding the maximum capacity of a single frame, the ECU returns the data using the ISO-TP multi-frame method:

[0083] First frame: 10 12 67 07 xx xx xx xx, where 10 is the first frame identifier, 12 (decimal 18) represents the total length of the seed data; 0x67 is the positive response code for secure access, 0x07 matches the request sub-function, and the following bytes are the seed pre-data.

[0084] The diagnostic tool returns a flow control frame: 30 00 05, where 30 is the flow control frame identifier, 00 indicates that continuous transmission is allowed, and 05 is the continuous frame interval parameter, notifying the ECU that the remaining data can continue to be transmitted.

[0085] The ECU sends consecutive frames 21..., 22..., carrying the remaining seed bytes. The diagnostic tool concatenates these frames sequentially to obtain a complete 18-byte random seed. The seed has a time limit and key calculation must be completed within the session's validity period.

[0086] 3. Submit the verification key

[0087] The diagnostic instrument uses a matching proprietary key and IV to generate an 18-byte verification key through a pre-defined algorithm on the seed, and sends it in multiple frames:

[0088] First frame: 10 12 27 08 xx xx xx xx, where 0x08 is the key submission sub-function, and the following is the key pre-processing data.

[0089] The ECU returned flow control frame 30 00 05, allowing transmission to continue.

[0090] The diagnostic tool sends consecutive frames 21..., 22..., which the ECU then splices together to obtain the complete key.

[0091] 4. Certification Result Feedback

[0092] The ECU calculates the key locally using the same algorithm and encryption parameters, and compares it with the received key:

[0093] Authentication successful: Returns a single frame 02 67 08, where 0x67 is a positive response code and 0x08 matches the submit key sub-function; high-security level permissions are now unlocked, and high-privilege operations such as writing DID and routine control can be performed during the session validity period.

[0094] Authentication failed: Returns a single frame 03 7F 27 35, where 0x7F is the negative response identifier, 0x27 corresponds to the secure access service, and NRC code 0x35 indicates that the key is invalid; after more than 3 consecutive failures, returns NRC code 0x36 (attempts exceeded) and initiates a cooldown lock.

[0095] To better understand this embodiment, the following example uses the UDS diagnostic interaction of a certain vehicle's power domain ECU. The complete execution logic from parameter configuration to permission control will be explained below.

[0096] First, in accordance with the safety specifications of automotive suppliers, dedicated encrypted parameters are configured for the powertrain domain ECU, and these parameters are permanently stored in the diagnostic tool and locally on the ECU. For example:

[0097] Power domain ECU diagnostic CAN ID: 0x7E0 (request) / 0x7E8 (response), corresponding to the dedicated 16-byte key Key_A;

[0098] Low security level (corresponding to fault reading and status query): Matches fixed initialization vector IV_1, with a length of 16 bytes;

[0099] High security level (corresponding to write DID, firmware flashing): matches fixed initialization vector IV_2, length 16 bytes.

[0100] Meanwhile, each ECU in the body domain, chassis domain, and other ECUs is equipped with an independent CAN ID and a dedicated key group, and the encryption parameters of each ECU are isolated from each other.

[0101] Then, the operator initiates a fault code reading request through the diagnostic tool. This is a low-security read-only operation, specifically including:

[0102] The diagnostic tool identifies the current CANID as 0x7E0, the service type as read fault codes, corresponding to a low security level, and retrieves Key_A and IV_1;

[0103] The data processing module performs packet processing on the diagnostic messages. Since the message length is 6 bytes, it uses single-frame transmission.

[0104] The dynamic encryption / decryption module calls the AES128-CBC algorithm, using Key_A as the key and IV_1 as the initial vector, to encrypt the plaintext message and generate the ciphertext message.

[0105] Encapsulated as a standard CAN frame and sent to the CAN bus;

[0106] The power domain ECU receives the message, parses the CAN ID and security level, matches the local Key_A and IV_1, performs AES128-CBC decryption, restores the plaintext message and completes byte alignment verification.

[0107] The ECU recognizes the operation as a low-security-level read-only operation, and without performing high-security access authentication, it directly processes the request and returns an encrypted response message.

[0108] The diagnostic tool decrypts the response message and displays the fault code information.

[0109] Next, the operator initiates a request to write the DID parameter, which is a high-security read / write operation:

[0110] The diagnostic tool identifies the current operation as corresponding to a high security level and triggers a secure access authentication process.

[0111] The diagnostic tool sends a session control command to switch to the extended diagnostic session;

[0112] The seed request, key calculation and submission are completed in accordance with the 27 service specifications. The entire authentication process uses Key_A and IV_2 for encrypted transmission.

[0113] After the ECU verification key is passed, high-security level permissions are unlocked, and the current session permission status is recorded;

[0114] The diagnostic instrument sends a write DID request message, which is transmitted after being encrypted using Key_A and IV_2.

[0115] The ECU decrypts the message, verifies that the current session has unlocked high-security privileges, performs the parameter writing operation, and returns an encrypted response.

[0116] If a write DID request is initiated without completing high-security level authentication, the ECU will directly return a negative response with a negative code (NRC) of 0x33 (secure access not performed), thus blocking the operation.

[0117] Finally, anomaly interception and logging are performed. Throughout the interaction, the key management and logging modules record all operations in real time. If anomalies such as key mismatch leading to decryption failure or unauthorized attempts at high-risk operations occur, the current interaction is immediately terminated and the abnormal event is recorded, while a security alarm is triggered on the diagnostic instrument side.

[0118] This embodiment discloses an encrypted transmission method and system based on the AES128-CBC algorithm. The method includes pre-configuring a fixed key and a fixed initialization vector with a length of not less than 16 bytes, establishing a two-dimensional hierarchical mapping relationship where a CAN identifier corresponds to a set of keys, different security levels under the same CAN identifier correspond to exclusive initialization vectors, and different ECUs are configured with independent key groups. Based on the AES128-CBC algorithm, hierarchical encrypted transmission of diagnostic messages is completed, forcibly binding hierarchical security access authentication with diagnostic operation permissions. Read-only operations do not require security access authentication, low-security-level authentication grants partial read / write functionality, and high-risk read / write operations require high-level authentication before execution. This invention effectively solves the problems of chaotic encryption levels, lack of access control, and susceptibility to unauthorized use of high-risk operations in traditional solutions, meeting the security and compliance requirements of scenarios such as vehicle diagnostics, firmware flashing, and parameter calibration.

[0119] Based on the same inventive concept, embodiments of the present invention also provide an encrypted transmission system based on the AES128-CBC algorithm, such as... Figure 3 It includes: a hierarchical encryption parameter configuration and secure storage module, a diagnostic request hierarchical encryption and message encapsulation module, an encrypted diagnostic message parsing and decryption restoration module, and a hierarchical security authentication and diagnostic access control module; among which:

[0120] The hierarchical encryption parameter configuration and secure storage module is used to pre-configure multiple sets of encryption parameters according to the vehicle manufacturer's safety specifications. Each set of encryption parameters includes a fixed AES encryption key and a fixed initialization vector with a length of not less than 16 bytes. A hierarchical encryption parameter mapping table is established based on the encryption parameters, and the hierarchical encryption parameter mapping table is fixed to the dedicated storage area of ​​legitimate diagnostic equipment and vehicle ECU.

[0121] The diagnostic request hierarchical encryption and message encapsulation module is used to identify the CAN identifier of the current diagnostic message and the security level corresponding to the UDS service when the diagnostic device initiates a UDS diagnostic request. It retrieves the fixed AES encryption key and fixed initialization vector matched in the mapping table, uses the AES128-CBC algorithm to encrypt the UDS diagnostic plaintext message into blocks, encapsulates it into an encrypted diagnostic CAN frame and sends it to the vehicle CAN bus.

[0122] The encrypted diagnostic message parsing and decryption module is used by the vehicle ECU to receive encrypted diagnostic CAN frames, parse the CAN identifier and security level information carried in the message, retrieve the corresponding key and initial vector stored locally, and decrypt the UDS plaintext message through the AES128-CBC algorithm.

[0123] The tiered security authentication and diagnostic access control module is used by the ECU to trigger corresponding level of security access authentication based on the security level of the UDS service. If the low-security-level authentication is successful, some read-write diagnostic operation permissions are granted; if the high-security-level authentication is successful, all high-risk read-write diagnostic operation permissions are unlocked.

[0124] The specific working methods of the hierarchical encryption parameter configuration and secure storage module, the diagnostic request hierarchical encryption and message encapsulation module, the encrypted diagnostic message parsing and decryption restoration module, and the hierarchical security authentication and diagnostic permission control module have been described in detail in the above-mentioned encrypted transmission method based on the AES128-CBC algorithm, and will not be repeated here in this embodiment.

[0125] Based on the same inventive concept, embodiments of the present invention also provide an in-vehicle electronic device. Figure 4 This is a structural block diagram of an in-vehicle electronic device provided in an embodiment of the present invention. Figure 4 As shown, an embodiment of the present invention provides an in-vehicle electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the methods described in the above embodiments; the one or more I / O interfaces 103 are connected to the processors 101 and configured to enable information interaction between the processors 101 and the in-vehicle CAN bus and external diagnostic interfaces.

[0126] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0127] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0128] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0129] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0130] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0131] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may 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 a remote computer, the remote computer may 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 may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0132] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0133] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0134] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0135] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0136] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive 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-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0137] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for encrypted transmission based on the AES128-CBC algorithm, characterized in that, include: S100. Based on the vehicle manufacturer's safety specifications, pre-configure multiple sets of encryption parameters. Each set of encryption parameters includes a fixed AES encryption key and a fixed initialization vector with a length of not less than 16 bytes. Establish a hierarchical encryption parameter mapping table based on the encryption parameters and solidify the hierarchical encryption parameter mapping table into the dedicated storage area of ​​the legitimate diagnostic equipment and the vehicle ECU. When the S200 diagnostic device initiates a UDS diagnostic request, it identifies the CAN identifier of the current diagnostic message and the security level corresponding to the UDS service, retrieves the fixed AES encryption key and fixed initialization vector matched in the mapping table, uses the AES128-CBC algorithm to encrypt the UDS diagnostic plaintext message into blocks, encapsulates it into an encrypted diagnostic CAN frame, and sends it to the vehicle CAN bus. S300. The vehicle ECU receives encrypted diagnostic CAN frames, parses the CAN identifier and security level information carried in the message, retrieves the corresponding key and initial vector stored locally, and decrypts the UDS plaintext message through the AES128-CBC algorithm. S400.ECU triggers the corresponding level of security access authentication based on the security level of the UDS service; read-only UDS diagnostic operations can be executed without security access authentication. If the low-security-level authentication is successful, some read-write diagnostic operation permissions will be granted; if the high-security-level authentication is successful, all high-risk read-write diagnostic operation permissions will be unlocked.

2. The method according to claim 1, characterized in that, In S100, a hierarchical encryption parameter mapping table is established based on the encryption parameters. The specific establishment rules include: one CAN identifier uniquely corresponds to a set of AES encryption keys; different UDS security levels under the same CAN identifier are matched with different fixed initialization vectors; different vehicle ECUs correspond to independent CAN identifiers and exclusive key sets; the UDS security levels are at least divided into low security levels and high security levels, with low security levels corresponding to read-only and low-risk read-write diagnostic services, and high security levels corresponding to high-risk read-write diagnostic services.

3. The method according to claim 1, characterized in that, The read-only diagnostic services include fault code reading, vehicle status query, and version information reading; the read-write diagnostic services include ECU parameter writing, vehicle firmware flashing, electronic control parameter calibration modification, and actuator active control; the key groups of different ECUs are independent of each other, and leakage of encrypted parameters of a single ECU does not affect the communication security of other ECUs.

4. The method according to claim 1, characterized in that, In S200, before encrypting the diagnostic message, ISO-TP packet assembly and segmentation processing is performed according to the ISO15765 protocol. The specific methods include: diagnostic messages with a data length of no more than 8 bytes are transmitted in a single frame, and diagnostic messages with a data length of more than 8 bytes are transmitted in multiple frames. Fragmentation transmission and flow control are completed through the first frame, consecutive frames and flow control frames. AES128-CBC encryption operation is performed on the complete UDS data block after packet assembly, and after decryption, it is restored to a standard UDS message according to the protocol rules.

5. The method according to claim 1, characterized in that, In S400, high-security access authentication follows the service specifications of the ISO14229 diagnostic protocol. The specific process is as follows: The diagnostic device sends a session control command to switch to an extended diagnostic session or a programmed diagnostic session; The diagnostic device sends a seed request command to the ECU, and the ECU generates a time-sensitive random seed, which is returned to the diagnostic device via ISO-TP multi-frame method; The diagnostic equipment performs an encryption operation on the seed based on the matched exclusive key and initialization vector, generates a verification key, and sends it to the ECU; The local key is verified to be consistent. If the verification is successful, the high-security level authentication is completed, and the corresponding diagnostic permissions are unlocked within the session validity period. If the verification fails, a negative response will be returned. If the number of consecutive failures exceeds a preset number, a cooling-off locking mechanism will be triggered.

6. The method according to claim 1, characterized in that, Read-only UDS diagnostic operations can be performed without secure access authentication; if low-security-level authentication is successful, some read-write diagnostic operation permissions are granted. If the high-security level authentication is successful, all high-risk read / write diagnostic operation permissions will be unlocked, including: Read-only UDS diagnostic operations can be executed directly without security access authentication; if low-security level authentication is successful, some read-write diagnostic operation permissions are granted, while high-risk operation requests such as ECU parameter writing, firmware flashing, and calibration modification are strictly blocked, and a negative response is returned if the conditions are not met. If the high-security-level security access authentication is successfully completed, the corresponding high-risk diagnostic operation permissions will be unlocked, allowing the execution of ECU parameter writing, vehicle firmware flashing, and electronic control calibration modification functions. The security access authentication status is bound to the session lifecycle. After the session times out or returns to the default session, the unlocked high permissions will automatically become invalid.

7. The method according to claim 1, characterized in that, It also includes a data integrity calibration step, the specific methods of which include: Before and after data encryption, the diagnostic data bytes are aligned, matched and calibrated according to the ISO14229 diagnostic protocol specification to ensure that the byte length and data points of the diagnostic data are completely consistent before and after encryption and decryption, and to prevent byte misalignment and data loss.

8. The method according to claim 1, characterized in that, It also includes security logging and anomaly interception steps, with specific methods including: The entire process of UDS security authentication, encrypted transmission, and diagnostic operation logs is recorded; abnormal operations such as key initialization vector mismatch, decryption failure, unauthorized permission attempts, and unauthorized flashing / writing are proactively intercepted, the diagnostic process is terminated, and vehicle safety alarms are reported.

9. An encrypted transmission system based on the AES128-CBC algorithm, used to implement the method described in any one of claims 1-8, characterized in that, include: The module comprises a hierarchical encryption parameter configuration and secure storage module, a diagnostic request hierarchical encryption and message encapsulation module, an encrypted diagnostic message parsing and decryption restoration module, and a hierarchical security authentication and diagnostic access control module; among which: The hierarchical encryption parameter configuration and secure storage module is used to pre-configure multiple sets of encryption parameters according to the vehicle manufacturer's safety specifications. Each set of encryption parameters includes a fixed AES encryption key and a fixed initialization vector with a length of not less than 16 bytes. A hierarchical encryption parameter mapping table is established based on the encryption parameters, and the hierarchical encryption parameter mapping table is fixed to the dedicated storage area of ​​legitimate diagnostic equipment and vehicle ECU. The diagnostic request hierarchical encryption and message encapsulation module is used to identify the CAN identifier of the current diagnostic message and the security level corresponding to the UDS service when the diagnostic device initiates a UDS diagnostic request. It retrieves the fixed AES encryption key and fixed initialization vector matched in the mapping table, uses the AES128-CBC algorithm to encrypt the UDS diagnostic plaintext message into blocks, encapsulates it into an encrypted diagnostic CAN frame and sends it to the vehicle CAN bus. The encrypted diagnostic message parsing and decryption module is used by the vehicle ECU to receive encrypted diagnostic CAN frames, parse the CAN identifier and security level information carried in the message, retrieve the corresponding key and initial vector stored locally, and decrypt the UDS plaintext message through the AES128-CBC algorithm. The hierarchical security authentication and diagnostic access control module is used by the ECU to trigger corresponding level of security access authentication based on the security level of the UDS service; read-only UDS diagnostic operations can be executed without security access authentication. If the low-security-level authentication is successful, some read-write diagnostic operation permissions will be granted; if the high-security-level authentication is successful, all high-risk read-write diagnostic operation permissions will be unlocked.

10. A vehicle-mounted electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs and hierarchical encryption parameter mapping tables; One or more I / O interfaces are provided for information interaction between the processor and the vehicle CAN bus and external diagnostic interfaces; when the program is executed by the processor, the method described in any one of claims 1 to 8 is implemented; wherein the vehicle electronic device is a vehicle ECU or a legitimate diagnostic device.

Images