Data transmission method, device and system, and vehicle

Abstract

The present application relates to the technical field of communications, and discloses a data transmission method, device and system, and a vehicle, capable of reducing the processing load of a processor, particularly reducing the load of the processor related to MAC-related calculations, while ensuring the integrity and legitimacy of service data transmission. In the present application, for the same data, a sender of a packet can reuse different parts of a MAC value to protect the integrity of the same service data, and correspondingly, a receiver of the packet can reuse different parts of the MAC value to verify the integrity of the packet; on this basis, the number of calculations of MAC can be reduced while ensuring the integrity and legitimacy of service data transmission, thereby reducing the processing load of a processor, particularly reducing additional overhead introduced by the processor for secure communications, such as MAC-related calculation overhead and resource overhead, and improving the timeliness of packet processing at the sender and receiver.

Description

Data transmission method, device, system and vehicle

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 29, 2023, with application number 202311627069.2 and application name “Data transmission application method, device, system and vehicle”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a data transmission method, device, system and vehicle. Background Art

[0003] Currently, to protect the integrity or legitimacy of data transmission, the sender often encapsulates business data with a calculated message authentication code (MAC) and sends it to the receiver. After receiving the message from the sender, the receiver will calculate the MAC and verify the integrity of the message by comparing the calculated MAC with the received message.

[0004] MAC calculation typically requires invoking underlying encryption and decryption services. It is calculated using encryption and decryption algorithms based on business data, freshness values, and locally stored keys. This imposes significant processor overhead on both the sender and receiver. For example, the transmission of a 64-byte message with a 10ms period typically requires approximately 1% processor load, of which MAC calculation accounts for approximately 70%. Given the high frequency of communication data in current communication scenarios, the high frequency of MAC calculations on both the sender and receiver sides imposes significant processor overhead. Summary of the Invention

[0005] The present application provides a data transmission method, device, system and vehicle, which can reduce the processing load of the processor while ensuring the integrity and legality of business data transmission, especially reducing the load of the processor regarding MAC-related calculations.

[0006] To achieve the above objectives, this application adopts the following technical solutions:

[0007] In a first aspect, a data transmission method is provided. The method can be applied to a communication device, such as a first device. The method may include:

[0008] First, a first device receives a first request for transmitting first information. Taking an in-vehicle communication scenario as an example, the first request may be initiated by an in-vehicle application in a software component (SWC), where the first request is used to request that information indicating application data of the in-vehicle application be transmitted to another device. For example, the application data may include, but is not limited to, autonomous driving data, vehicle driving data, road image data, and other data, such as vehicle speed control data and vehicle speed status data, without specific limitation.

[0009] Then, the first device generates a first MAC based on the first information, the first freshness value, and the key; and the first device splits the first MAC into M parts, where M is a positive integer greater than 1. The first freshness value is used to ensure that the bus data is different each time to effectively prevent replay attacks; the key is a key used in the encryption and decryption algorithm agreed upon in advance by the first device and the second device, and is not specifically limited.

[0010] Afterwards, the first device sends a first message for indicating the first information, wherein the first message includes first data, a first freshness value, and one of the M parts, and the first data is at least part of the data used to carry the first information. The first data is protected data in the data indicated by the first information, such as the first data can be all the data indicated by the first information, or it can be a part of the data indicated by the first information that is pre-set or identified. For example, the first data can be relatively important data in the data indicated by the first information, such as data that has a greater impact on vehicle safety, stability, comfort, etc. The embodiment of the present application does not make specific limitations on this, and it can depend on the specific usage scenario and business data category.

[0011] After this, after the first device receives the second request for requesting the transmission of the second information, the first device can send a second message for indicating the second information, wherein the second message includes second data, a first fresh value and another part of the M parts, and the second data is at least part of the data used to carry the second information, and the second data is the same as the first data.

[0012] With the solution provided in the first aspect above, the message sender can reduce the number of MAC calculations for the same data by reusing different parts of the MAC value, while ensuring the integrity and legal transmission of the business data. This reduces the processor's processing load, particularly reducing the additional processor overhead introduced by secure communications, such as MAC-related calculation overhead and resource overhead, and improves the timeliness of message processing at the sender and receiver. For example, based on the solution provided in this application, taking the example of 10 10ms security paths occupying approximately 10% of the total processor load resources, experiments have shown that, under ideal circumstances, the solution provided in this embodiment of the application can save 5.6% of the total processor load. Assuming that each MAC part is 24 bits long and the MAC is calculated once for 5 frames of repeated messages, under ideal circumstances, the HSM resources can be saved by approximately 80%.

[0013] As a possible implementation, the method further includes: the first device maintaining a counter, wherein the maximum value of the counter is M; when the first message is sent, the count value of the counter is an initial value; when the second message is sent, the count value is incremented by 1. Based on this, the transmitting end can maintain a timer to reuse different parts of the subsequent MAC value for the same data based on the count value of the counter, thereby ensuring efficient and reliable reuse of the subsequent MAC value.

[0014] As an example, the initial value of the count value is 1.

[0015] As a possible implementation, the method further includes: after the first device sends M messages, it receives a third request for requesting the transmission of third information, wherein the M messages sent by the first device respectively include different parts of the M parts, and each of the M messages includes a first fresh value, and the M messages include a first message and a second message; the first device generates a second MAC based on the third information, the second fresh value and the key, wherein the second fresh value is different from the first fresh value; the first device sends a third message for indicating the third information, wherein the third message includes third data, a second fresh value and a second MAC part, and the third data is at least part of the data used to carry the third information, wherein the third data is the same as the first data. Based on this, the sending end can recalculate the MAC value after the various parts of the MAC value are reused and perform integrity protection on subsequent identical business data based on the newly calculated MAC value, thereby ensuring the integrity and legal transmission of the business data.

[0016] As a possible implementation, when the first device sends the third message, the count value of the counter is the initial value. Based on this, the sending end can reset the counter to ensure that different parts of the subsequent MAC value are reused based on the reset counter, thereby ensuring efficient and reliable reuse of the subsequent MAC value.

[0017] As a possible implementation, the method further includes: the first device receives a fourth request for requesting the transmission of fourth information; the first device generates a third MAC based on the fourth information, the third freshness value, and the key; the first device sends a fourth message for indicating the fourth information, wherein the fourth message includes fourth data, the third freshness value, and part of the third MAC, the fourth data is at least part of the data used to carry the fourth information, and the fourth data is different from the first data. Based on this, the sender can recalculate the MAC value when transmitting new business data (i.e., the same protected data has not been transmitted before) and perform integrity protection on subsequent identical business data based on the newly calculated MAC value, thereby ensuring the integrity and legal transmission of the business data.

[0018] As a possible implementation, when the first device sends the fourth message, the count value of the counter is the initial value. Based on this, the sending end can reset the counter to ensure that different parts of the subsequent MAC value are reused based on the reset counter, thereby ensuring efficient and reliable reuse of the subsequent MAC value.

[0019] As a possible implementation, the M parts can be of the same or different lengths. That is, the transmitter can split the MAC address in ways that include, but are not limited to, uniform and uneven splitting. For example, the transmitter can evenly split the first MAC address into M parts, each with an equal number of bits. Another example is that the transmitter can unevenly split the first MAC address into M parts, with at least two of the M parts having unequal bit numbers. Based on this, a more flexible MAC value reuse strategy can be provided to further improve the integrity and legal transmission of service data.

[0020] As a possible implementation, the lengths of the M parts include any one or more of the following lengths: 24 bits, 28 bits, or 32 bits. This can provide more flexible MAC splitting to support more flexible MAC value reuse strategies, thereby further improving the integrity and legality of service data transmission.

[0021] As a possible implementation, the first device generates a first MAC based on the first information, the first fresh value, and the key, including: the first device generates the first MAC based on the first data, the first fresh value, and the key. Based on this, a more flexible MAC value reuse policy triggering mechanism can be provided. For example, the first device can reuse the unused portion of the previously calculated MAC value when the service data is exactly the same as the previous service data, or can reuse the unused portion of the previously calculated MAC value when the service data is partially identical to the previous service data (such as the same protected data), so as to provide a more flexible and variable MAC value reuse triggering mechanism suitable for the needs of various application scenarios.

[0022] In a second aspect, a data transmission method is provided. The method can be applied to a communication device, such as a second device, and the method includes:

[0023] First, the second device receives a first message from the first device, wherein the first message includes the first data, the first freshness value, and the i-th part of M parts of the first MAC, where M is a positive integer greater than 1. As an example, the first data can be all the business data carried or indicated by the first message, or it can be a pre-set or identified part of the business data carried or indicated by the first message. For example, the protected data can be relatively important data in the business data carried or indicated by the first message, such as data that has a greater impact on vehicle safety, stability, comfort, etc. This application does not make specific limitations on this, and it can depend on the specific usage scenario and business data category.

[0024] The second device then generates a second MAC based on the first data, the first freshness value, and the key; and splits the second MAC into M parts. As an example, the second device can generate the second MAC based on the first data, the first freshness value, and the key based on an integrity protection algorithm. For example, the integrity protection algorithm may include, but is not limited to, an AES algorithm, such as AES128, and the calculation process may include, but is not limited to, key round addition, byte substitution, row shifting, column obfuscation, etc.

[0025] Afterwards, the second device determines that the first message verification is successful based on the jth part of the M parts of the second MAC being consistent with the ith part of the M parts of the first MAC, where i,j∈[1,M].

[0026] After that, when receiving the second message from the first device including the first fresh value and the i+1th part of the M parts of the first MAC, the second device determines that the second message verification is successful based on the j+1th part of the M parts of the second MAC is consistent with the i+1th part of the M parts of the first MAC.

[0027] The solution provided in the second aspect above is based on the premise that the sender encapsulates the same freshness value in the message for the same business data. Accordingly, the receiver can verify the integrity of the message by reusing different parts of the MAC value. While ensuring the integrity and legal transmission of the business data, the number of MAC calculations is reduced, thereby reducing the processing load of the processor, especially reducing the additional overhead introduced by the processor for secure communication, such as MAC-related calculation overhead and resource overhead, and improving the timeliness of message processing at the sender and receiver. For example, based on the solution provided in this application, taking the example of 10 10ms security paths occupying approximately 10% of the total processor load resources, through experiments, it is found that based on the solution provided in the embodiment of this application, the total processor load can be saved by 5.6% under ideal conditions. Assuming that each MAC part is 24 bits long and the MAC is calculated once for 5 frames of repeated messages, the HSM resources can be saved under ideal conditions by approximately 80%.

[0028] As a possible implementation, the method further includes: the second device maintaining a counter, wherein the maximum value of the counter is M, the count value of the counter is an initial value before verifying the first message, the count value is incremented by 1 when the first message verification is successful, and the count value is further incremented by 1 when the second message verification is successful. Based on this, the receiving end can maintain a timer to reuse different parts of the MAC value during subsequent integrity verification for the same data based on the count value of the counter, thereby ensuring efficient and reliable reuse of the subsequent MAC value.

[0029] As a possible implementation, the method further includes: when the second message is successfully verified, the second device uses the first data as the data obtained by parsing the second message. Based on this, it can be guaranteed that the service data transmitted by the receiving end to the upper layer based on the second message is always correct. For example, if the protected data in the second message is tampered with, based on this method, because the correct service data parsed from the previous message is transmitted to the upper layer, it can be guaranteed that the service data transmitted to the upper layer is still correct.

[0030] As a possible implementation, the method further includes: the second device verifying the first message using the j+1th part of the M parts of the second MAC based on an inconsistency between the jth part of the M parts of the second MAC and the ith part of the M parts of the first MAC; and the second device determining that verification of the first message is successful based on an inconsistency between the j+1th part of the M parts of the second MAC and the ith part of the M parts of the first MAC. This ensures that subsequent message verification is not affected even in the event of frame loss.

[0031] As a possible implementation, the method further includes: the second device, based on the inconsistency between the j+1th part of the M parts of the second MAC and the ith part of the M parts of the first MAC, uses the j+2th part of the M parts of the second MAC to verify the first message, and so on; based on the inconsistency between the j+1th part, ..., Mth part of the M parts of the second MAC and the ith part of the M parts of the first MAC, indicating a risk of a replay attack. Based on this, the receiving end can be helped to successfully identify the risk of a replay attack during the process of executing the policy of reusing MAC values, so as to promptly respond to possible security threats.

[0032] As a possible implementation, the method further includes: the second device receiving a third message from the first device, wherein the third message includes third data, a second freshness value, and the kth part of the M parts of the third MAC; the second device generating a fourth MAC based on the third data, the second freshness value, and the key; the second device splitting the fourth MAC into M parts; the second device determining that the third message verification is successful based on the tth part of the M parts of the fourth MAC being consistent with the kth part of the M parts of the third MAC, where k, t∈[1,M]. Based on this, under the premise that the sending end encapsulates different freshness values ​​in messages for different business data, the receiving end can, correspondingly, recalculate the MAC value and perform subsequent integrity verification of the same business data based on the newly calculated MAC value when receiving a message carrying a freshness value different from that carried in the previous message, thereby ensuring the integrity and legal transmission of the business data.

[0033] As a possible implementation, the second device initializes the counter value before verifying the third message. Based on this, the receiving end can reset the counter to ensure that different parts of the subsequent MAC value are reused based on the reset counter, thereby ensuring efficient and reliable reuse of the subsequent MAC value.

[0034] As a possible implementation, the method further includes: the second device verifying the third message using the t+1th part of the M parts of the fourth MAC based on the inconsistency between the tth part of the M parts of the fourth MAC and the kth part of the M parts of the third MAC, and so on; and the second device indicating a bus attack risk based on the inconsistency between the t+1th, ..., and Mth parts of the M parts of the fourth MAC and the kth part of the M parts of the third MAC. Based on this, the receiving end can be helped to successfully identify the risk of a bus attack during the process of executing the policy of reusing MAC values, so as to promptly respond to possible security threats.

[0035] As a possible implementation, the M parts can be of the same or different lengths. That is, the receiving end can split the MAC in ways that include, but are not limited to, even and uneven splitting. For example, the receiving end can evenly split the first MAC into M parts, each with an equal number of bits. Another example is that the receiving end can unevenly split the first MAC into M parts, with at least two of the M parts having unequal bit numbers. Based on this, a more flexible MAC value reuse strategy can be provided to further improve the integrity and legal transmission of service data.

[0036] As a possible implementation, the lengths of the M parts include any one or more of the following lengths: 24 bits, 28 bits, or 32 bits. This can provide more flexible MAC splitting to support more flexible MAC value reuse strategies, thereby further improving the integrity and legality of service data transmission.

[0037] In a third aspect, a communication device is provided, comprising: a memory for storing computer program instructions and data; and a processor for executing the computer program instructions to support the communication device in implementing the method described in any possible implementation of the first aspect or the second aspect.

[0038] In a fourth aspect, a communication system is provided, which includes multiple communication devices, such as a first device and a second device, wherein the first device is used to implement the method described in any possible implementation of the first aspect, and the second device is used to implement the method described in any possible implementation of the second aspect.

[0039] In a fifth aspect, a vehicle or other means of transport is provided, which may include the communication device as described in the third aspect to implement the method described in any possible implementation of the first aspect or the second aspect.

[0040] In a sixth aspect, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the method in any possible implementation of the first aspect or the second aspect is implemented.

[0041] In a seventh aspect, a computer program product comprising instructions is provided, which, when executed on a computer, enables the computer to implement the method in any possible implementation of the first aspect or the second aspect.

[0042] In an eighth aspect, a chip system is provided, comprising a processing circuit and a storage medium storing computer program instructions; when the computer program instructions are executed by the processor, the method of any possible implementation of the first or second aspect is implemented. The chip system may be composed of a chip alone, or may include a chip and other discrete components. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] FIG1 is a schematic diagram of a conventional data transmission process;

[0044] FIG2 is a schematic diagram of a data integrity protection process provided by an embodiment of the present application;

[0045] FIG3 is a schematic diagram of a system architecture of a communication device provided in an embodiment of the present application;

[0046] FIG4 is a schematic diagram of a MAC value multiplexing strategy of a transmitting end provided in an embodiment of the present application;

[0047] FIG5 is a schematic diagram of a method for performing data transmission by multiplexing MAC values ​​according to an embodiment of the present application;

[0048] FIG6 is a second schematic diagram of a method for performing data transmission by multiplexing MAC values ​​provided in an embodiment of the present application;

[0049] FIG7 is a third schematic diagram of a method for performing data transmission by multiplexing MAC values ​​provided in an embodiment of the present application;

[0050] FIG8 is a fourth schematic diagram of a method for performing data transmission by multiplexing MAC values ​​provided in an embodiment of the present application;

[0051] FIG9 is a schematic diagram of a message processing strategy of a receiving end provided in an embodiment of the present application;

[0052] FIG10 is a schematic diagram of a method for performing data parsing by multiplexing MAC values ​​according to an embodiment of the present application;

[0053] FIG11 is a second schematic diagram of a method for performing data parsing by reusing MAC values ​​provided in an embodiment of the present application;

[0054] FIG12 is a third schematic diagram of a method for performing data parsing by reusing MAC values ​​according to an embodiment of the present application;

[0055] FIG13 is a fourth schematic diagram of a method for performing data parsing by reusing MAC values ​​according to an embodiment of the present application;

[0056] FIG14 is a flow chart of a data transmission method provided in an embodiment of the present application;

[0057] FIG15 is a flow chart of a data analysis method provided in an embodiment of the present application;

[0058] FIG16 is a structural block diagram of a transmitting end / receiving end provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships can exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0060] Hereinafter, the terms "first," "second," and so on are used solely to distinguish different descriptive objects and have no limiting effect on the position, order, priority, quantity, or content of the described objects. For example, if the described object is a "field," the ordinal number preceding the "field" in "first field" and "second field" does not define the position or order of the "fields." "First" and "second" do not define whether the modified "fields" are in the same message, nor do they restrict the order of the "first field" and "second field." For another example, if the described object is a "level," the ordinal number preceding the "level" in "first level" and "second level" does not define the priority of the "levels." For another example, the number of described objects is not limited by the ordinal number and can be one or more. For example, in the case of "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the described object is a "device," the "first device" and "second device" can be the same type of device or different types of devices. For another example, if the described object is "information," the "first information" and "second information" can be information of the same content or different contents. In short, the use of prefixes such as ordinal numbers to distinguish the described objects in the embodiments of the present application does not constitute a restriction on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and no unnecessary restrictions should be constituted due to the use of such prefixes.

[0061] Furthermore, in the embodiments of the present application, "connection" may be a direct connection or an indirect connection; in addition, it may refer to an electrical connection or a communication connection; for example, the connection between two electrical components A and B may refer to a direct connection between A and B, or may refer to an indirect connection between A and B through other electrical components or connection media, or may refer to an indirect connection between A and B through other communication devices or communication media, as long as communication between A and B can be achieved.

[0062] At present, in order to verify the integrity of the message during the communication process, the sender of the message can calculate the message authentication code based on the business data, the fresh value and the locally stored key (referred to as "key-A"). code, MAC) (hereinafter the MAC calculated by the sender is denoted as "MAC-A*", such as MAC-A1, MAC-A2, etc.), and then the fresh value, MAC-A* (such as the entire or partial sequence of MAC-A*) and the service data are encapsulated in a message and sent to the receiving end. When the receiving end of the message receives the message, it can calculate the MAC (hereinafter the MAC calculated by the sender is denoted as "MAC-B*, such as MAC-B1, MAC-B2, etc.") based on the service data, fresh value and the locally stored key (denoted as "key-B") therein, and then verify the integrity of the message by comparing the entire or partial sequence of MAC-B* with the MAC-A* sequence encapsulated in the received message. For example, when the MAC-B* sequence is consistent with the MAC-A* sequence encapsulated in the message, it is determined that the service data has not been tampered with; when the MAC-B* sequence is inconsistent with the MAC-A* sequence encapsulated in the message, it is determined that the message has been tampered with. In the above process, since Key-A and Key-B are negotiated in advance between the sender and the receiver and are usually known only to the sender and the receiver, if the MAC-B* sequence is inconsistent with the MAC-A* sequence encapsulated in the message, it is highly likely that the message has been tampered with.

[0063] It should be noted that the solution for message integrity verification during data transmission in this application can be applied to any scenario involving data transmission, including but not limited to terminal communication scenarios, vehicle-mounted communication scenarios, etc., and the embodiments of this application do not make specific limitations.

[0064] Taking the in-vehicle communication scenario as an example, the automotive open system architecture (AUTOSAR) organization introduced the secure onboard communication (SecOC) module in the AUTOSAR classic platform (CP) related specifications. The SecOC module is used to protect the integrity of end-to-end message transmission in the vehicle, such as the integrity protection of message transmission between electronic control units (ECUs).

[0065] For example, please refer to Figure 1, which shows a schematic diagram of a conventional data transmission process using the SecOC module to perform message integrity protection as an example. As shown in Figure 1, the process of the SecOC module performing message integrity protection mainly includes S1-S8:

[0066] S1: The software component (SWC) writes the business data into the communication module (Com).

[0067] For example, SWC can call the signal interface to write business data into the buffer inside the Com module.

[0068] S2: The Com module processes the service data to obtain signal protocol data unit (sPdu) data, and then transmits it to the protocol data unit router (PduR) module.

[0069] For example, the Com module can process the service data based on the periodic processing function to obtain the sPdu data.

[0070] S3: The PduR module forwards the sPdu data to the SecOC module.

[0071] S4: The SecOC module obtains the freshness value (FV) from the freshness value management (FVM) module.

[0072] Among them, in the embodiment of the present application, the freshness value can ensure that the bus data is different each time, based on which replay attacks can be effectively prevented, wherein a replay attack refers to an attacker sending a message that has been successfully received by the receiving end before, in order to achieve the purpose of deceiving the sending and receiving ends.

[0073] As an example, a fresh value may be generated based on a timestamp check mode and a frame counter check mode, etc. The embodiments of the present application do not specifically limit this, and reference may be made to conventional technologies.

[0074] S5: The SecOC module transmits the sPdu data and FV to the hardware security module (HSM).

[0075] S6: Based on the integrity protection algorithm, the HSM calculates MAC-A* according to the sPdu, FV and the saved key and transmits it to the SecOC module.

[0076] S7: The SecOC module encapsulates the sPDU, FV and MAC-A* (such as the entire or partial sequence of MAC-A*) into a secure PDU message and transmits it to the PduR module.

[0077] S8: The PduR module sends the safety PDU message to the communication bus through the controller area network interface (CanIf) module or the socket adapter (SoAd) module.

[0078] Afterwards, the safety PDU message can be transmitted to the receiving end via the communication bus.

[0079] As shown in Figure 1, MAC value calculation typically requires invoking underlying encryption and decryption services (such as the FVM module and HSM shown in Figure 1). As shown in Table 1 below, MAC value calculation imposes significant processor load and computational overhead on both the transmitter and receiver. Taking the Advanced Encryption Standard (AES) 128 algorithm as an example, each additional security message with a 10ms period and 64 bytes (such as the maximum length of a CAN with flexible data rate (CANFD) protocol message) increases processor load by approximately 1%. Of this 1% of processor load, SecOC's invocation of underlying encryption and decryption services to calculate MAC values ​​accounts for approximately 70% (approximately 100µs).

[0080] Table 1

[0081] In today's communication scenarios, with frequent data transmission, the high frequency of MAC value calculations on both the sender and receiver sides creates a significant processor load. For example, in the case of in-vehicle communications, while the SecOC module can provide message integrity protection, it fails to account for the high timeliness requirements and fast cycle times (mostly 10-20ms) of in-vehicle messages, as well as the high message repetition rate. For example, when the vehicle is stationary, messages from ECUs like steering and chassis control have a near 100% repetition rate. Furthermore, when the vehicle is in motion, messages from ECUs like steering and speed are unlikely to change constantly, and messages from ECUs like car seats remain virtually constant. Using conventional integrity protection mechanisms like the one shown in Figure 1, even if the service data remains unchanged, the SecOC modules on both the sender and receiver sides would need to repeatedly call the underlying encryption and decryption services to calculate MAC values, wasting significant processor resources. This is unacceptable in the already resource-constrained in-vehicle embedded system.

[0082] In order to reduce the processing load of the processor (such as the central processing unit (CPU)) while ensuring the integrity and legality of business data transmission, especially to reduce the additional overhead introduced by the processor for secure communication, such as the overhead of MAC-related calculations, an embodiment of the present application provides a data transmission method. In this solution, for the same business data, the sender can reuse the same MAC value when performing data encapsulation (such as the encapsulation of a secure PDU message). In other words, the sender only needs to perform a MAC calculation once, and then it can perform integrity protection for multiple subsequent identical business data based on this. For example, when there is a need to transmit data 1, after calculating the MAC value based on data 1, a fresh value and a key, if there is a subsequent need to transmit the same data as data 1, there is no need to calculate the MAC value again, but the previously calculated MAC value can be reused to directly perform data encapsulation. Based on this, not only can the integrity and legality of business data transmission be guaranteed normally, but the overhead of calculating the MAC value corresponding to the repeated messages can also be greatly reduced, thereby reducing the processing load of the processor.

[0083] As a possible implementation, when reusing the same MAC value for the same service data, the sender may use different parts of the same MAC value. For example, when performing integrity protection on the same data, the first and second parts of the MAC value (e.g., MAC-A1) may be used separately. MAC-A1 may be calculated based on data 1, a fresh value, and a key in response to a request to transmit data 1. It may also be calculated based on data 3, a fresh value, and a key in response to a request to transmit data 3 before there is a need to transmit data 1, where data 3 is the same as data 1.

[0084] Please refer to Figure 2, which shows a schematic diagram of a data integrity protection process provided by an embodiment of the present application. As shown in Figure 2, when there is a need to transmit data 1, the sender can calculate MAC-A1 based on the integrity protection algorithm according to data 1, a fresh value (such as FV-1) and a key (such as Key-A), and split MAC-A1 into M parts (M is a positive integer greater than 1, where Figure 2 takes M as a positive integer greater than 2 as an example). As shown in Figure 2, when integrity protection is performed on data 1, the sender can encapsulate data 1, FV-1 and the first part of MAC-A1 (such as MAC-A1-1) into message 1. Later, when there is a need to transmit data 2 that is identical to data 1, the sender does not need to calculate the MAC value again, but can reuse MAC-A1 to encapsulate data 1, FV-1, and the second part of MAC-A1 (for example, denoted as MAC-A1-2) into message 2. Similarly, when there is a need to transmit data M that is identical to data 1, the sender can directly multiplex MAC-A1 to encapsulate data 1, FV-1, and the Mth part of MAC-A1 (for example, denoted as MAC-A1-M) into message M.

[0085] In this embodiment of the present application, the transmitting end may split the MAC-A1 in a manner including, but not limited to, uniform splitting and uneven splitting. For example, the transmitting end may evenly split the MAC-A1 into M parts, with each part having an equal number of bits. Alternatively, the transmitting end may unevenly split the MAC-A1 into M parts, with at least two of the M parts having unequal numbers of bits. This allows for a more flexible MAC value reuse strategy to further improve the integrity and legal transmission of service data.

[0086] In some embodiments, the transmitting end may also maintain a counter, where the counter is used to indicate which part of the MAC-A1 is used when multiplexing the MAC-A1. The initial value of the counter is, for example, 1, and the maximum value is M. For example, if the MAC-A1 is evenly split into M parts, M = [length of the MAC-A1 / length of each part of the MAC-A1]. Taking the AES128 algorithm as an example, the calculated length of the MAC-A1 may be 128 bits. If the MAC-A1 is evenly split with a cutoff MAC length of 24 bits, the maximum value of the counter is 128 bits / 24 bits, rounded to the integer of 5. Based on this, when the sending end sends message 1 including data 1, the count value of the counter can be the initial value (such as the initial value is 0), when the sending end sends message 2 including data 2 that is the same as data 1, the count value of the counter is increased by 1 (such as changed to 1), when the sending end sends message 3 including data 3 that is the same as data 1, the count value of the counter is increased by 1 again (such as changed to 2), and so on. When the sending end sends message 4 including data 4 different from data 1, the count value of the counter is reset to the initial value.

[0087] Similarly, the receiving end may split MAC-B* in ways that include, but are not limited to, uniform and uneven splitting. Furthermore, the receiving end may also maintain a counter. The receiving end's method and process for calculating MAC-B*, the method and process for splitting MAC-B*, and the specific strategy for maintaining the counter may be consistent with those of the transmitting end. For details, refer to the aforementioned method and process for calculating MAC-A*, the method and process for splitting MAC-A*, and the specific strategy for maintaining the counter for the transmitting end, and will not be repeated here.

[0088] Of course, the embodiment of the present application does not limit the length of MAC-A* and MAC-B*, such as the length of MAC-A* and MAC-B* can also be 256 bits, etc.; the embodiment of the present application does not limit the length of each part of the MAC value, such as the length of any part of MAC-A* and MAC-B* can also be 28 bits or 32 bits, etc.; in addition, the embodiment of the present application does not limit the specific strategy of the sender and the receiver to maintain the counter.

[0089] It should be noted that the present application is an embodiment that does not limit the specific algorithm used by the sender and the receiver to calculate the MAC value based on the business data, fresh value and key. For example, the algorithm may include but is not limited to the AES algorithm, such as the AES128 algorithm, etc. For example, the calculation process is not limited to key round addition, byte replacement, row shift, column confusion, etc., and specific reference can be made to conventional technology.

[0090] As a possible example, please refer to Figure 3. Figure 3 uses an in-vehicle communication scenario as an example to illustrate a system architecture diagram of a communication device provided by an embodiment of the present application. The communication device can be a data transmitter or a data receiver. As shown in Figure 3, the communication device can include, from top to bottom, a SWC, a Runtime Environment (RTE), a communication stack, and a communication bus.

[0091] Among them, SWC may include a series of in-vehicle applications or functions (hereinafter collectively referred to as "in-vehicle applications"). For example, the in-vehicle applications may include but are not limited to navigation, automatic driving, automatic parking and other applications, which are not limited in the embodiments of this application.

[0092] In this embodiment of the present application, an in-vehicle application in the SWC can initiate a data storage request, where the data storage request is used to request that application data of the in-vehicle application be sent to another device. For example, application data may include, but is not limited to, autonomous driving data, vehicle driving data, road image data, etc., and is not specifically limited in this embodiment of the present application.

[0093] RTE can be used to pass data transmission requests initiated by the in-vehicle application in the SWC to the communication stack so that the communication stack can perform subsequent data integrity protection and data sending processes.

[0094] As an example, as shown in FIG3 , the communication stack may include a Com module, a PduR module, a SecOC module, an FVM module, an HSM module, and a CanIf module / SoAd module.

[0095] The Com module shown in Figure 3 processes the service data to be transmitted, generates sPdu data, and transmits it to the PduR module. The PduR module forwards the sPdu data to the SecOC module. The SecOC module protects the integrity of the sPdu data, for example, by encapsulating the sPdu data, a portion of the freshness value, and the MAC value into a secure PDU message and sending it to the PduR module. After receiving the secure PDU message from the SecOC module, the PduR module can send the secure PDU message to the communication bus via the CanIf module / SoAd module, allowing the secure PDU message to be sent to the receiving end via the communication bus.

[0096] In some embodiments, when performing integrity protection on the sPdu data, if the SecOC module does not store a MAC value corresponding to the previous identical data, the SecOC module may instruct the FVM module to generate a fresh value (e.g., FV-1). The FVM module is configured to generate the fresh value (e.g., FV-1) and provide the generated fresh value to the SecOC module. After obtaining the fresh value, the SecOC module may send the sPdu data and the fresh value to the HSM module and instruct the HSM module to calculate the MAC value. Correspondingly, the HSM module may, in response to the instruction of the SecOC module, calculate the MAC value based on the fresh value (e.g., FV-1) from the SecOC module, the sPdu data, and a stored key (e.g., Key-A), and then send the calculated MAC-A1 to the SecOC module. After obtaining the MAC-A1, the SecOC module may split the MAC-A1 into M parts, encapsulate the sPdu data, FV-1, and a portion of the MAC-A1 (e.g., the first part) into a secure PDU message, and transmit the message to the PduR module.

[0097] In other embodiments, when performing integrity protection on the sPdu data, if the SecOC module already stores a MAC value (such as MAC-A1) corresponding to the previous identical data, the SecOC module may directly reuse the unused portion of MAC-A1 to encapsulate the sPdu data and obtain a secure PDU message.

[0098] Among them, the previous identical data described in the embodiment of the present application refers to the business data that was most recently used to call the encryption and decryption service for MAC value calculation before the current business data. The business data may be the previous frame data of the current message, or the previous frame data or earlier data, without specific limitation.

[0099] Taking the vehicle communication scenario as an example, as an example, the data transmission method provided in the embodiment of the present application can be applied to a domain controller, such as a domain controller on a vehicle. For example, the data transmission request described in the present application can be initiated by the domain controller.

[0100] The vehicle described in the embodiments of the present application is a broad concept and can be any vehicle, such as a land vehicle, a water vehicle, an air vehicle, an industrial device, an agricultural device, or an entertainment device. For example, the vehicle described in the embodiments of the present application can be a vehicle (such as a car, a bus, a subway, a high-speed train, a motorcycle, a flying car, a train, etc.), an industrial vehicle (such as a forklift, a trailer, a tractor, etc.), an engineering vehicle (such as an excavator, a bulldozer, a crane, etc.), an agricultural device (such as a mower, a harvester, etc.), an amusement ride, a toy vehicle, a boat, an air cushion vehicle, a submarine, an airplane, a helicopter, etc. The embodiments of the present application do not limit the specific type, form, or function of the vehicle.

[0101] In some examples, domain controllers can be divided into several domains (also called "functional domains") based on the functions of various parts of the vehicle, such as the intelligent driving domain, cockpit domain, chassis domain, power domain, and body domain. Based on this, the on-board domain controllers may include, but are not limited to, any one or more of the following: intelligent driving domain controller, cockpit domain controller, chassis domain controller, power domain controller, thermal management controller, and body domain controller. The data transmission request described in this application can be initiated by any of the above domain controllers.

[0102] The intelligent driving domain primarily provides autonomous driving perception and decision-making services, such as image reception, image processing and judgment, data processing and calculation, navigation and route planning, and rapid real-time situation judgment and decision-making. The intelligent driving domain requires processing algorithms at the three levels of perception, decision-making, and control, placing the highest demands on the domain controller's hardware and software. The cockpit domain primarily controls the various electronic information systems within the vehicle's intelligent cockpit, including the central control system, in-vehicle infotainment system, head-up display, seating system, instrumentation system, rearview mirror system, driver behavior monitoring system, and navigation system. The chassis domain primarily controls the vehicle's driving behavior and posture. Its functions include, but are not limited to, brake system management, transmission system management, driving system management, steering system management, vehicle speed sensor management, body posture sensor management, air suspension system management, and airbag system management. The powertrain domain primarily controls the vehicle's powertrain, optimizing its performance and ensuring safety, including engine management, transmission management, battery management, power distribution management, emissions management, speed limit management, and fuel and power conservation management. The body domain is mainly used to control various body functions, including but not limited to the control of headlights, taillights, interior lights, door locks, windows, sunroof, wipers, electric trunk, smart keys, air conditioning, antennas, gateway communications, etc.

[0103] The following will describe in detail a data transmission method implemented by multiplexing MAC values ​​provided in an embodiment of the present application with reference to the accompanying drawings.

[0104] For example, please refer to Figure 4, which shows a schematic diagram of a MAC value reuse strategy of a transmitter provided in an embodiment of the present application. As shown in Figure 4, upon receiving a data transmission request, the transmitter can first determine whether the service data is the same as the previous data.

[0105] As shown in FIG4 , if the service data is the same as the previous data, the sender further determines whether the current value of the counter is the maximum value of the counter. If the current value of the counter is not the maximum value of the counter, the sender does not need to calculate the MAC value and can directly reuse the MAC-A* calculated based on the previous identical data, such as MAC-A1, and use the same fresh value (such as FV-1) as the fresh value corresponding to the previous identical data. For example, the service data, a portion of MAC-A1 indicated by the current count value, and the fresh value corresponding to the previous identical data are encapsulated into a data message, and then the counter value is updated, such as by adding 1 to the count value. If the current value of the counter is the maximum value of the counter, the sender can increment the fresh value, such as to FV-2, and then calculate a new MAC value, such as MAC-A2, based on the service data, FV-2, and the key, and set the counter value to the initial value (such as 1). Based on this, the sender can encapsulate the service data, a portion of MAC-A2 indicated by the initial count value, and FV-2 into a data message.

[0106] As shown in Figure 4, if the service data is different from the previous data, the sender can update the fresh value, such as increasing the fresh value to FV-3, and then calculate a new MAC value, such as MAC-A3, based on the service data, FV-3 and the key, and set the value of the counter to the initial value (such as 1). Based on this, the sender can encapsulate the service data, the part of MAC-A3 indicated by the count value as the initial value, and FV-3 into a data message.

[0107] Taking the example of splitting MAC-A1 into 4 parts, i.e., M=4, please refer to FIG5 , which shows a schematic diagram of a method for data transmission by reusing MAC values ​​provided by an embodiment of the present application. As shown in FIG5 , when receiving a data transmission request 1 requesting the transmission of data 1, the sending end can obtain FV-1 through the FVM module, then call the encryption and decryption service to calculate the MAC value, such as MAC-A1, set the count value of the counter to the initial value (such as 1), and finally attach the part corresponding to the count value 1 in MAC-A1, such as MAC-A1-1, to data 1 to form message 1, which is sent to the receiving end via the communication bus. Afterwards, when receiving a data transmission request 2 requesting the transmission of data 2, the sending end determines that the protected data of data 2 and data 2 are the same by comparing data 2 with data 2. In this case, the sending end can add 1 to the count value of the counter, such as setting it to 2, use the same FV-1 as message 1, and reuse MAC-A1-2 corresponding to the count value 2 in MAC-A1 to attach it to data 2 to form message 2, which is sent to the receiving end via the communication bus. By analogy, when receiving data transmission request 3 for data 3 whose protected data is the same as data 1 and data transmission request 4 for data 4 whose protected data is the same as data 3, the sending end does not need to calculate the MAC value, but can directly multiplex MAC-A1-3 corresponding to the count value 3 and MAC-A1-4 corresponding to the count value 4 in MAC-A1 to send messages 3 and 4 to the receiving end respectively.

[0108] The protected data can be all business data or a pre-set or identified portion of the business data. For example, the protected data can be relatively important business data, such as data that has a significant impact on vehicle safety, stability, comfort, etc. This embodiment of the application does not specifically limit this and can be determined based on the specific usage scenario and business data category.

[0109] As shown in FIG5 , after the transmission of message 4 is completed, the count value of the counter reaches a maximum value of 4. If the sending end receives a data transmission request 5 requesting the transmission of data 5, the sending end needs to recalculate the MAC value, such as re-obtaining FV-2 through the FVM module, and then calling the encryption and decryption service to calculate a new MAC value, such as MAC-A2, and set the count value of the counter to the initial value (such as 1). Finally, a part corresponding to the count value 1 in MAC-A2, such as MAC-A2-1, is attached to data 5 to form message 5, which is sent to the receiving end through the communication bus.

[0110] Among them, the length of MAC-A* (such as MAC-A1 or MAC-A2) shown in Figure 5 can be 128 bits, and the length of the M parts can be 32 bits. Of course, this application does not specifically limit the length of MAC-A* and the length of each part.

[0111] It should be noted that the protected data of data 5 and data 4 shown in Figure 5 may be different or the same, and this embodiment of the application does not make any specific limitations.

[0112] In addition, FIG5 only takes the transmitting end multiplexing all parts of MAC-A1 as an example. In some embodiments, the transmitting end may not multiplex all parts of MAC-A1.

[0113] For example, as shown in Figure 6, after completing the transmission of message 1, if the sender receives a data transmission request 2 requesting the transmission of data 2 whose protected data is different from data 1, the sender needs to recalculate the MAC value, such as re-obtaining FV-2 through the FVM module, and then calling the encryption and decryption service to calculate the MAC value, such as MAC-A2, and set the count value of the counter to the initial value (such as 1). Finally, the part corresponding to the count value 1 in MAC-A2, such as MAC-A2-1, is attached to data 2 to form message 2, which is sent to the receiving end through the communication bus.

[0114] For another example, as shown in FIG7 , after completing the transmission of message 2, if the sender receives a data transmission request 3 requesting the transmission of data 3 whose protected data is different from data 2, the sender needs to recalculate the MAC value, such as re-obtaining FV-2 through the FVM module, and then calling the encryption and decryption service to calculate a new MAC value, such as MAC-A2, and set the count value of the counter to the initial value (such as 1). Finally, the part corresponding to the count value 1 in MAC-A2, such as MAC-A2-1, is attached to data 3 to form message 3, which is sent to the receiving end through the communication bus.

[0115] For another example, as shown in FIG8 , after completing the transmission of message 3, if the sending end receives a data transmission request 4 requesting the transmission of data 4 whose protected data is different from data 3, the sending end needs to recalculate the MAC value, such as re-obtaining FV-2 through the FVM module, and then calling the encryption and decryption service to calculate a new MAC value, such as MAC-A2, and set the count value of the counter to the initial value (such as 1). Finally, the part corresponding to the count value 1 in MAC-A2, such as MAC-A2-1, is attached to data 4 to form message 4, which is sent to the receiving end through the communication bus.

[0116] After the data message is transmitted to the receiving end, for example, please refer to Figure 9, which shows a schematic diagram of a message processing strategy of the receiving end provided in an embodiment of the present application. As shown in Figure 9, when receiving the data message, the receiving end can first determine whether the freshness value (FV) in the data message is the same as the freshness value (FV) in the previous message received.

[0117] As shown in Figure 9, if the FV in the data message is the same as the FV in the previous message, the receiving end further determines whether the MAC value sequence corresponding to the current count value is the same as the MAC value sequence in the data message; if the MAC value sequence corresponding to the current count value is the same as the MAC value sequence in the data message, the receiving end can pass the business data parsed from the previous message to the upper layer and update the count value of the counter, such as adding 1 to the count value of the counter.

[0118] If the FV in the data message is the same as the FV in the previous message, and the portion of the MAC value corresponding to the current count value is different from the MAC in the data message, the receiver can further determine whether the current value of the counter is the maximum value of the counter. If the current value of the counter is not the maximum value of the counter, the receiver considers that there may be message loss. In this case, the receiver can update the count value of the counter, such as adding 1 to the count value of the counter, and determine whether the portion of the MAC value corresponding to the updated count value is the same as the MAC in the data message, and perform steps similar to the above process based on the judgment result; if the current value of the counter is the maximum value of the counter, the receiver can determine that there is a risk of replay attack.

[0119] If the FV in the data message is different from the FV in the previous message, the receiving end can recalculate the MAC value and then determine whether the part corresponding to the count value 1 in the recalculated MAC value is the same as the MAC in the data message. If the part corresponding to the count value 1 in the recalculated MAC value is the same as the MAC in the data message, the receiving end can pass the business data parsed from the business message to the upper layer and update the count value of the counter, such as adding 1 to the count value of the counter.

[0120] If the FV in the data message is different from the FV in the previous message, and the portion of the MAC value recalculated by the receiver corresponding to the count value 1 is different from the MAC in the data message, the receiver can further determine whether the current value of the counter is the maximum value of the counter. If the current value of the counter is not the maximum value of the counter, the receiver considers that there may be message loss, such as the loss of the first frame message corresponding to the recalculated MAC value. In this case, the receiver can update the count value of the counter, such as adding 1 to the count value of the counter, and determine whether the portion corresponding to the updated count value is the same as the MAC in the data message, and perform steps similar to the above process based on the judgment result; if the current value of the counter is the maximum value of the counter, the receiver can consider that there is a risk of bus attack.

[0121] Since both the sender and the receiver adopt the strategy of multiplexing MAC values, and the sender and the receiver use the same counter strategy to indicate the specific part of the MAC value, the receiver can successfully verify the integrity of the data message through the strategy of multiplexing MAC values.

[0122] Taking the example of splitting MAC-B1 into 4 parts, i.e., M=4, please refer to FIG10, which shows a schematic diagram of a method for data parsing by multiplexing MAC values ​​provided by an embodiment of the present application. As shown in FIG10, when receiving the first frame message 1 including data 1, FV-1, and MAC-A1-1, the receiving end calls the encryption and decryption service to calculate the MAC value, such as MAC-B1, sets the count value of the counter to the initial value (such as 1), and then determines whether the part corresponding to the count value 1 in MAC-B1 (such as MAC-B1-1) is the same as the MAC-A1-1 in the message 1. If they are the same, the message 1 is verified successfully and the count value is increased by 1 (such as 2). Afterwards, when receiving intermediate message 2, which includes data 2, FV-1, and MAC-A1-2, the receiver does not need to calculate the MAC value. Instead, it can directly reuse the portion of MAC-B1 corresponding to count value 2 (e.g., MAC-B1-2) and verify message 2 by comparing MAC-B1-2 with MAC-A1-2 in message 2. Similarly, when receiving intermediate message 3, which includes data 3, FV-1, and MAC-A1-3, the receiver can directly reuse MAC-B1-3 corresponding to count value 3 in MAC-B1 and verify message 3 by comparing MAC-B1-3 with MAC-A1-3 in message 3. Furthermore, when receiving intermediate message 4, which includes data 4, FV-1, and MAC-A1-4, the receiver can directly reuse MAC-B1-4 corresponding to count value 4 in MAC-B1 and verify message 4 by comparing MAC-B1-4 with MAC-A1-4 in message 4.

[0123] As shown in Figure 10, after the verification of message 4 is completed, the count value of the counter reaches the maximum value of 4. If the receiving end receives message 5 including data 5, FV-2 and MAC-A2-1, the receiving end needs to recalculate the MAC value, such as re-obtaining FV-2 through the FVM module, and then calling the encryption and decryption service to calculate the MAC value, such as MAC-B2, and set the count value of the counter to the initial value (such as 1). Finally, it is determined whether the part corresponding to the count value 1 in MAC-B2 (such as MAC-B2-1) is the same as the MAC-A2-1 in message 5. If they are the same, the verification of message 5 is successful, and the count value is increased by 1 (such as set to 2).

[0124] Among them, the length of MAC-B* (such as MAC-B1 or MAC-B2) shown in Figure 10 can be 128 bits, and the length of the M parts can be 32 bits. Of course, this application does not make specific restrictions on the length of MAC-B* and the length of each part.

[0125] It should be noted that the protected data of data 5 and data 4 shown in FIG10 may be different or the same, and this embodiment of the application does not make any specific limitation.

[0126] In addition, Figure 10 only uses the example of a successful message verification when the sender and receiver reuse all parts of MAC-B1. In some embodiments, message verification may fail when using only parts of MAC-B1. In this case, if the FV in the data message is the same as the FV in the previous message, the receiver can increment the count by 1 and use the part of MAC-B1 corresponding to the updated count value to verify the data message. Based on this, frame loss will not affect subsequent message verification.

[0127] For example, as shown in FIG11, assuming that the first frame message 1 is lost during transmission from the sending end to the receiving end, when receiving message 2 including data 2 whose protected data is the same as data 1, the receiving end can call the encryption and decryption service to calculate a MAC value, such as MAC-B1, and set the count value of the counter to the initial value (such as 1). Since data 2 and the fresh value in message 2 are the same as those in the first frame message, the MAC value calculated based on message 2 is consistent with the MAC value calculated based on message 1. However, due to the loss of the first frame message 1, the receiving end cannot pass the verification when using the part corresponding to the count value 1 in MAC-B1 (such as MAC-B1-1) to verify message 2. In this case, as shown in FIG11, the receiving end can add 1 to the count value of the counter and use the part corresponding to the count value 2 in MAC-B1 (such as MAC-B1-2) to verify message 2, and the verification is successful.

[0128] For another example, as shown in Figure 12, suppose that intermediate message 2 is lost during transmission from the sender to the receiver. When message 3 is received, which includes data 3 whose protected data is the same as data 1, the receiver uses the portion of MAC-B1 corresponding to count value 2 (e.g., MAC-B1-2) to verify message 3, but the verification fails. In this case, as shown in Figure 12, the receiver can increase the count value of the counter by 1 and use the portion of MAC-B1 corresponding to count value 3 (e.g., MAC-B1-3) to verify message 3, which is successful.

[0129] Similarly, similar to the loss of intermediate message 2, if intermediate message 3 is lost during transmission from the sender to the receiver, when message 4 is received, which includes data 4 whose protected data is the same as data 2, the receiver uses the portion of MAC-B1 corresponding to count value 3 (such as MAC-B1-3) to verify message 4, but the verification fails. In this case, the receiver can increase the count value of the counter by 1 and use the portion of MAC-B1 corresponding to count value 4 (such as MAC-B1-4) to verify message 4, which is successful.

[0130] For another example, as shown in FIG13 , assuming that the last frame message 4 is lost during transmission from the sending end to the receiving end, when receiving message 5 whose fresh value is different from the fresh value in the previous message 3 and includes data 5, the receiving end can call the encryption and decryption service to calculate the MAC value, such as MAC-B2, set the count value of the counter to the initial value (such as 1), and then verify message 5 by comparing the part corresponding to the count value 1 in MAC-B2 (such as MAC-B2-1) with MAC-A2-1 in message 5, and the verification is successful.

[0131] It can be understood that the method for transmitting data by reusing MAC values ​​provided in an embodiment of the present application can reduce the number of MAC value calculations by reusing MAC values, thereby reducing the processing load of the processor, especially reducing the additional overhead introduced by the processor for secure communication, such as MAC value-related calculation overhead and resource overhead, and improving the timeliness of message processing at the sending and receiving ends.

[0132] Taking the example of 10 10ms security paths occupying approximately 10% of the total processor load resources, experiments have shown that based on the solution provided in the embodiment of the present application, the total processor load that can be saved under ideal circumstances is 10%*70%*80%=5.6%, where 70% is the end-to-end time ratio of MAC value calculation in the total message processing time, and 80% is the time ratio weight corresponding to the length of each part of the MAC value being 24 bits and the MAC value being calculated once for 5 frames of repeated messages; and, taking the example of each part of the MAC value being 24 bits and the MAC value being calculated once for 5 frames of repeated messages, based on the solution provided in the embodiment of the present application, the HSM resources that can be saved under ideal circumstances are approximately 80%. Moreover, compared with the resource overhead brought about by calculating the MAC value, the time consumed by the sending end in comparing whether the data is the same in the embodiment of the present application is usually very small. For example, taking 64 bytes of business data as an example, the time consumed for data comparison is about 0.95us, which is much lower than the time consumed for calling the encryption and decryption service to calculate the MAC value (such as about 100us); and, compared with the resource overhead brought about by calculating the MAC value, the receiving end in the embodiment of the present application only needs to compare the fresh value and the MAC. These overheads are also usually very small and can therefore be ignored.

[0133] Moreover, the method for transmitting data by reusing MAC values ​​provided in the embodiment of the present application can also ensure the integrity and legality of business data transmission.

[0134] On the one hand, in the solution provided in the embodiments of the present application, since only the sender and the receiver know the MAC value calculated based on the previous message, even if an attacker intercepts a data message from the communication bus, he cannot infer the MAC value sequence in the next frame message based on the MAC value sequence in the data message.

[0135] On the other hand, even if an attacker tampers with the data message, the solution provided by the embodiment of the present application will not affect the subsequent message verification.

[0136] For example, suppose an attacker tampers with the MAC value sequence in a data message. Since the fresh values ​​in messages containing the same data are consistent, if the receiver fails to verify the message based on the part corresponding to the current count value in the MAC value, the receiver will add 1 to the count value and then verify the message based on the other part corresponding to the updated count value. And so on. If each subsequent part fails to verify, the receiver will discard the data message, and it will not affect the subsequent message verification at the receiver.

[0137] For another example, suppose an attacker tampers with the fresh value in a data message. Since the fresh value in the data message is inconsistent with the fresh value in the previous message, the receiver will recalculate the MAC value and verify the data message one by one based on each part of the recalculated MAC value until the verification is successful. Since the calculation of the MAC value is related to the fresh value, the recalculated MAC value is usually unrelated to the MAC sequence in the data message. Therefore, when verifying the data message based on each part of the recalculated MAC value, the verification will fail. In this case, the receiver will discard the data message, and it will not affect the subsequent message verification at the receiver.

[0138] For another example, suppose an attacker tampers with the business data in a data message. If the data message is the first frame message, the receiver will calculate the MAC value based on the tampered business data. Therefore, when the receiver verifies the data message based on each part of the calculated MAC value, the verification will fail. In this case, the receiver will also discard the data message. If the data message is an intermediate message, the receiver will use the part of the MAC value calculated based on the previous message that corresponds to the current count value to verify the data message and the verification will usually succeed. In this case, the receiver will transmit the business data parsed from the previous message to the upper layer. Therefore, even if the business data in the business message is tampered with, the business data transmitted to the upper layer is still correct.

[0139] In addition, based on the method of transmitting data by reusing MAC values ​​provided in the embodiment of the present application, since the processing logic of the sender and receiver for the same message is consistent and does not change, it can also effectively identify risks such as replay attacks or bus attacks.

[0140] As an example, please refer to Figure 14, which shows a flow chart of a data transmission method provided by an embodiment of the present application, taking the transmitting end as the second device as an example. As shown in Figure 14, a data transmission method provided by an embodiment of the present application can be implemented based on S1401-S1406:

[0141] S1401: A first device receives a first request, where the first request is used to request transmission of first information.

[0142] The first request is a data transmission request, and the first information is used to indicate the business data to be transmitted.

[0143] Taking the in-vehicle communication scenario as an example, as an example, the first request may be initiated by an in-vehicle application in the SWC. The first request is used to request that information indicating application data of the in-vehicle application be sent to another device. For example, the application data may include, but is not limited to, autonomous driving data, vehicle driving data, road image data, etc., and is not specifically limited in this embodiment of the application.

[0144] As an example, the first request may be a request initiated by a vehicle speed control module (such as a vehicle speed control ECU) calculated by a control algorithm, and the first information may include but is not limited to one or more of vehicle speed control information and vehicle speed status information.

[0145] S1402: The first device generates a first MAC according to the first information, the first freshness value, and the key.

[0146] The first fresh value can ensure that the bus data is different each time, so as to effectively prevent replay attacks.

[0147] As an example, the first freshness value (e.g., FV-1) can be generated by the FVM module of the first device, such as based on a timestamp check mode or a frame counter check mode. In some embodiments, the freshness value generated by the FVM module can be monotonically increasing throughout the declaration cycle of the entire device. The key is the key used by the encryption and decryption algorithm agreed upon in advance by the first device and the second device. The embodiment of the present application does not specifically limit the method and specific process for generating the freshness value and the key negotiation process, and reference can be made to conventional technologies.

[0148] As an example, the first device may generate a first MAC (e.g., MAC-A1) based on the first information, the first freshness value, and the key based on an integrity protection algorithm. For example, the integrity protection algorithm may include, but is not limited to, an AES algorithm, such as an AES128 algorithm, etc. For example, the calculation process includes, but is not limited to, key round addition, byte substitution, row shifting, column obfuscation, etc., and for details, reference may be made to conventional technologies.

[0149] As an example, the first device can generate a first MAC based on the integrity protection algorithm according to the protected data indicated by the first information, the first freshness value and the key. The protected data indicated by the first information can be all the data indicated by the first information, or it can be a portion of the data indicated by the first information that is pre-set or identified (such as the first data). For example, the protected data can be relatively important data in the data indicated by the first information, such as data that has a greater impact on vehicle safety, stability, comfort, etc. The embodiment of the present application does not make specific limitations on this, and it can depend on the specific usage scenario and business data category.

[0150] S1403: The first device splits the first MAC into M parts.

[0151] Wherein, M is a positive integer greater than 1.

[0152] As an example, the first device may split the first MAC address in a manner including, but not limited to, uniform splitting and uneven splitting. For example, the first device may evenly split the first MAC address into M parts, each with an equal number of bits; or, as another example, the first device may unevenly split the first MAC address into M parts, with at least two of the M parts having unequal numbers of bits.

[0153] As an example, the length of the first MAC may include but is not limited to 128 bits, 256 bits, etc., and the length of any part of the M parts may include but is not limited to: 24 bits, 28 bits, 32 bits, etc., without specific limitation.

[0154] In some embodiments, a counter may also be maintained in the first device, where the counter is used to indicate which part of the first MAC is used when the first MAC is reused. For example, the initial value of the counter is 1, and the maximum value is M.

[0155] It should be noted that the embodiments of the present application do not limit the correspondence between the count value and the M parts of the first MAC. For example, assuming that the bits of the first MAC are split from left to right into the first part, the second part, ..., the Mth part, and the count values ​​of the counter include 1, 2, ..., M. In some embodiments, the count value 1 can correspond to the first part of the first MAC, the count value 2 can correspond to the second part of the first MAC, ..., and the count value M can correspond to the Mth part of the first MAC; in other embodiments, the count value 1 can correspond to the Mth part of the first MAC, the count value 2 can correspond to the M-1th part of the first MAC, ..., and the count value M can correspond to the first part of the first MAC; in other embodiments, the count value 1 can correspond to the other parts of the first MAC except the first part and the Mth part, the count value 2 can correspond to the other parts of the first MAC except the second part and the M-1th part, ..., and the count value M can correspond to the other parts of the first MAC except the Mth part and the first part. In other words, the embodiments of the present application do not limit the specific order in which the first device reuses the various parts when reusing the first MAC, which can depend on specific settings and policies.

[0156] S1404: The first device sends a first message indicating first information to the second device, where the first message includes first data, a first freshness value, and one of the M parts, where the first data is at least part of the data used to carry the first information.

[0157] The first data is protected data within the data indicated by the first information. The first data is at least a portion of the data used to carry the first information. For example, the first data may be all of the data indicated by the first information, or may be a pre-set or identified portion of the data indicated by the first information. For example, the first data may be relatively important data within the data indicated by the first information, such as data that has a significant impact on vehicle safety, stability, or comfort. This is not specifically limited in the embodiments of the present application and may depend on the specific usage scenario and business data category.

[0158] Taking the example that the first information includes vehicle speed control information and vehicle speed status information, as an example, the first data may be the vehicle speed control information in the first information.

[0159] When the first message is sent, the count value of the counter maintained by the first device is an initial value, such as 1.

[0160] S1405: The first device receives a second request, where the second request is used to request transmission of second information.

[0161] The second request is a data transmission request, and the second information is used to indicate the business data to be transmitted.

[0162] Taking the in-vehicle communication scenario as an example, as an example, the second request and the first request are initiated by the same in-vehicle application in the SWC, and the data category indicated by the information requested to be transmitted to the other device in the second request is the same as the data category indicated by the information requested to be transmitted in the first request. For example, the information requested to be transmitted in the first request and the second request both include vehicle speed control information and vehicle speed status information.

[0163] S1406: The first device sends a second message indicating second information to the second device, where the second message includes second data, a first fresh value, and another part of the M parts. The second data is at least part of the data used to carry the second information, and the second data is the same as the first data.

[0164] The second data is protected data within the data indicated by the second information, and the second data is at least a portion of the data used to carry the second information. For example, the second data may be all of the data indicated by the second information, or may be a pre-set or identified portion of the data indicated by the second information. For example, the second data may be relatively important data within the data indicated by the second information, such as data that has a significant impact on vehicle safety, stability, or comfort.

[0165] Taking the example that the data indicated by the first information and the second information both include vehicle speed control information and vehicle speed status information, the second data being the same as the first data may mean that the vehicle speed control information indicated by the first information is the same as the vehicle speed control information indicated by the second information and / or the vehicle speed status information indicated by the first information is the same as the vehicle speed status information indicated by the second information.

[0166] When the second message is sent, the count value of the counter maintained by the first device is increased by 1 based on the initial value, such as updated to 2.

[0167] By analogy, when there is a need to transmit information indicating the same business data, the first device can adopt a method similar to S1406 to encapsulate the message by reusing the unused parts of the M parts of the first MAC until all M parts of the first MAC are used.

[0168] In some embodiments, after all M parts of the first MAC are used, such as after sending M messages including information indicating the same business data, when receiving a third request for requesting the transmission of a third information, the first device recalculates the MAC value, such as generating a second MAC (such as MAC-A2) based on the third information, a second fresh value (different from the first fresh value) and a key, and then sends a third message for indicating the third information, wherein the third message includes third data, a second fresh value (such as FV-2) and part of the second MAC, and the third data is at least part of the data used to carry the third information. When the first device sends the third message, the count value of the counter maintained by the first device is reset to the initial value (such as 1). That is, when all parts of the same MAC are used up, the first device needs to recalculate the MAC value, and then use a similar MAC value multiplexing mechanism for subsequent data transmission based on the recalculated MAC value.

[0169] In some embodiments, the third data is the same as the first data, that is, when the various parts of the same MAC are used up, even if a request to transmit data that is the same as the previous data is received, the first device needs to recalculate the MAC value and then use a similar MAC value multiplexing mechanism for subsequent data transmission based on the recalculated MAC value.

[0170] In some embodiments, when parts of the same MAC value have not been used up, assuming that the first device receives a data transmission request to transmit data different from the protected data in the previous data, the first device also needs to recalculate the MAC value, and then use a similar MAC value multiplexing mechanism for subsequent data transmission based on the recalculated MAC value.

[0171] For example, assuming that the first device receives a fourth request for requesting the transmission of fourth information, the first device can generate a third MAC based on the fourth information, a third fresh value (different from the first fresh value and the second fresh value) and a key, and then send a fourth message for indicating the fourth information, wherein the fourth message includes fourth data, a third fresh value and part of the third MAC, wherein the fourth data is at least part of the data used to carry the fourth information, and the fourth data is different from the first data. Taking the example that the data indicated by the fourth data and the first information both include vehicle speed control information and vehicle speed status information, the fourth data being the same as the first data can mean that the vehicle speed control information indicated by the fourth information is the same as the vehicle speed control information indicated by the first information and / or the vehicle speed status information indicated by the fourth information is the same as the vehicle speed status information indicated by the first information. When the first device sends the fourth message, the count value of the counter maintained by the first device is reset to the initial value (such as 1).

[0172] Correspondingly, as an example, please refer to Figure 15, which shows a flow chart of a data parsing method provided by an embodiment of the present application, taking the transmitting end as the first device and the receiving end as the second device as an example. As shown in Figure 15, a data parsing method provided by an embodiment of the present application can be implemented based on S1501-S1506:

[0173] S1501: A second device receives a first message from a first device, where the first message includes first data, a first freshness value, and an i-th part of M parts of a first MAC.

[0174] The first data in the first message is the protected data carried in the first message, and the first data may be all of the business data carried or indicated by the first message, or may be a pre-set or identified portion of the business data carried or indicated by the first message. For example, the protected data may be relatively important data in the business data carried or indicated by the first message, such as data that has a significant impact on vehicle safety, stability, comfort, etc. This embodiment of the present application does not specifically limit this, and may depend on the specific usage scenario and business data category.

[0175] In this embodiment of the present application, the first freshness value in the first message is carried by the first device in the first message to prevent replay attacks; the i-th part of the first MAC address in the first message is carried by the first device in the first message to protect the integrity of the message. Regarding the method and specific process of the first device generating the first message, please refer to the relevant description of Figure 14 above and will not be repeated here.

[0176] S1502: The second device generates a second MAC according to the first data, the first freshness value, and the key.

[0177] As an example, the second device may generate a second MAC (e.g., MAC-B1) based on the first data, the first freshness value, and the key based on an integrity protection algorithm. For example, the integrity protection algorithm may include, but is not limited to, an AES algorithm, such as an AES128 algorithm, etc. For example, the calculation process includes, but is not limited to, key round addition, byte substitution, row shifting, column obfuscation, etc., and for details, reference may be made to conventional technologies.

[0178] S1503: The second device splits the second MAC into M parts.

[0179] Wherein, M is a positive integer greater than 1.

[0180] As an example, the second device may split the second MAC in a manner including, but not limited to, uniform splitting and uneven splitting. For example, the second device may evenly split the second MAC into M parts, each with an equal number of bits; or, as another example, the second device may unevenly split the second MAC into M parts, with at least two of the M parts having unequal numbers of bits.

[0181] As an example, the length of the second MAC may include but is not limited to 128 bits, 256 bits, etc., and the length of any part of the M parts may include but is not limited to: 24 bits, 28 bits, 32 bits, etc., without specific limitation.

[0182] In some embodiments, a counter may also be maintained in the second device, where the counter is used to indicate which part of the second MAC is used when the second MAC is reused. For example, the initial value of the counter is 1, and the maximum value is M.

[0183] It should be noted that the embodiments of the present application do not limit the correspondence between the count value and the various parts of the second MAC. For example, assuming that the bits of the second MAC are split from left to right into the first part, the second part, ..., the Mth part, and the count values ​​of the counter include 1, 2, ..., M. In some embodiments, the count value 1 can correspond to the first part of the second MAC, the count value 2 can correspond to the second part of the second MAC, ..., and the count value M can correspond to the Mth part of the second MAC; in other embodiments, the count value 1 can correspond to the Mth part of the second MAC, the count value 2 can correspond to the M-1th part of the second MAC, ..., and the count value M can correspond to the first part of the second MAC; in other embodiments, the count value 1 can correspond to the other parts of the second MAC except the first and M parts, the count value 2 can correspond to the other parts of the second MAC except the second and M-1 parts, ..., and the count value M can correspond to the other parts of the second MAC except the Mth and first parts. In other words, the embodiments of the present application do not limit the specific order in which the second device reuses the various parts of the second MAC, which can be determined based on specific settings and policies.

[0184] In an embodiment of the present application, the strategy for splitting the second MAC and the strategy for maintaining the counter of the second device are consistent with those of the first device. Taking uniform splitting as an example, the lengths of the M parts of the second MAC and the M parts of the first MAC are the same, the initial value / maximum value of the counter maintained by the second device (such as recorded as "second counter") and the counter maintained by the first device (such as recorded as "first counter") are the same, and the MAC sequence indicated by the same count value of the second counter is the same.

[0185] S1504: The second device determines that the first message verification is successful based on that the j-th part of the M parts of the second MAC is consistent with the i-th part of the M parts of the first MAC, i, j∈[1,M].

[0186] Here, the relationship between i and j is i≥j, for example, i=1, j=1; i=2, j=2; i=3, j=2; i=4, j=2, and so on.

[0187] For example, the second device may verify the first message by comparing the jth part of the M parts of the second MAC with the ith part of the M parts of the first MAC to see whether they are consistent. For example, if they are consistent, it is determined that the first message verification is successful; if they are inconsistent, it is determined that the first message verification has failed.

[0188] In some embodiments, before verifying the first message, the count value of the counter maintained by the second device is an initial value, and the count value is increased by 1 when the first message is successfully verified.

[0189] In some embodiments, if the jth part of the M parts of the second MAC is inconsistent with the ith part of the M parts of the first MAC, the second device may increase the count value of the counter maintained by it by 1, such as setting it to j+1, and then use the j+1th part of the M parts of the second MAC indicated by the count value j+1 to verify the first message. If the j+1th part of the M parts of the second MAC is consistent with the ith part of the M parts of the first MAC, then it is determined that the first message is successfully verified.

[0190] When the first message is successfully verified, the second device may perform subsequent analysis on the first message to obtain first data therefrom, and transmit the first data to an upper layer, such as SWC.

[0191] In some embodiments, if the second device fails to verify the first message using the j+1th part of the M parts of the second MAC indicated by the count value j+1, the second device may increase the count value of the counter it maintains by 1, such as setting it to j+2, and then use the j+2th part of the M parts of the second MAC indicated by the count value j+2 to verify the first message, and so on, until the first message is verified or the count value of the counter maintained by the second device reaches the maximum value. As an example, if the verification of the first message based on the j+1th part, ..., Mth part of the M parts of the second MAC fails, the second device may deem that the first message is a message sent by the attacker and has been successfully received by the second device before. In this case, the second device may indicate that there is a risk of replay attack.

[0192] S1505: The second device receives a second message from the first device, where the second message includes a first freshness value and the (i+1)th part of the M parts of the first MAC.

[0193] The first freshness value in the second message is carried by the first device in the second message to prevent replay attacks; the i+1th part of the first MAC address in the second message is carried by the first device in the second message to protect the message's integrity. For details on the method and specific process by which the first device generates the second message, please refer to the description of Figure 14 above and will not be repeated here.

[0194] S1506: The second device determines that the second message verification is successful based on that the j+1th part of the M parts of the second MAC is consistent with the i+1th part of the M parts of the first MAC.

[0195] It can be understood that because the freshness value carried in the second message is the same as the freshness value carried in the previous first message, the second device can determine that the protected data in the first message is the same as the protected data in the first message. In this case, the second device does not need to calculate the MAC value again, but can directly reuse the unused portion of the previously calculated first MAC, such as the j+1th portion of the first MAC indicated by the count value j+1, to verify the second message.

[0196] In some embodiments, when the second message verification succeeds, the count value is increased by 1, such as set to j+2.

[0197] In some embodiments, when the second message is successfully verified, the second device can transmit the first data as the data obtained by parsing the second message to the upper layer, such as SWC. Based on this, it can be guaranteed that the business data transmitted by the second device to the upper layer based on the second message is always correct. For example, if the protected data in the second message is tampered with, based on this method, because the correct business data parsed from the previous message is transmitted to the upper layer, it can be guaranteed that the business data transmitted to the upper layer is still correct.

[0198] In some embodiments, the second device may recalculate the MAC value based on the received message when receiving a message carrying a freshness value different from that carried in a previous message. For example, when receiving a third message from the first device including third data, a second freshness value, and the kth part of the M parts of the third MAC, the second device may generate a fourth MAC based on the third data, the second freshness value, and the key, split the fourth MAC into M parts, and then perform third message verification based on the tth part of the M parts of the fourth MAC, such as determining that the third message verification is successful when the tth part of the M parts of the fourth MAC is consistent with the kth part of the M parts of the third MAC, where k, t∈[1,M], such as k≥t. As an example, k=1 and t=1.

[0199] In some embodiments, before verifying the third message, the count value of the counter maintained by the second device is an initial value, and when the third message is successfully verified, the count value is increased by 1, such as set to t+2.

[0200] In some embodiments, when the third message is successfully verified, the second device may perform subsequent parsing on the third message to obtain third data therefrom, and transmit the third data to an upper layer, such as SWC.

[0201] In some embodiments, if the second device fails to verify the third message using the tth part of the M parts of the fourth MAC indicated by the count value t, the second device may increase the count value of the counter it maintains by 1, such as setting it to t+1, and then use the t+1th part of the M parts of the second MAC indicated by the count value t+1 to verify the third message, and so on, until the third message is verified or the count value of the counter maintained by the second device reaches the maximum value. As an example, if verification of the third message based on the tth part, ..., Mth part of the M parts of the second MAC fails, the second device may believe that the third message has been tampered with or forged by an attacker. In this case, the second device may indicate that there is a risk of bus attack.

[0202] Based on the same inventive concept, an embodiment of the present application further provides a communication device, which can be a transmitting end or a receiving end. As shown in Figure 16, the communication device may include a processor, a memory, and a network interface. Among them, the processor, the memory, and the network interface are connected via a double data rate (DDR) bus or other types of communication buses. The network interface is used to communicate with other devices. For example, a service message sent by a network device or other communication device can be received through the network interface, and a service message can also be sent to a network device or other communication device through the network interface.

[0203] The processor may be a central processing unit (CPU) or other specific integrated circuit. The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. In practical applications, a communication device may also include multiple processors, each of which may include one or more processor cores.

[0204] Memory is typically used to store executable program code for computer programs. Executable program code includes instructions. The processor executes the instructions stored in the memory to execute various functional applications and data processing functions of the communication device. The memory may include a program storage area and a data storage area. The program storage area may store the operating system and at least one application required for a function, while the data storage area may store data generated during the use of the communication device.

[0205] In addition, the memory may include a high-speed random access memory and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0206] It is understood that the structure shown in FIG16 of the present application does not constitute a specific limitation on the communication device. In other embodiments of the present application, the communication device may include more or fewer components than shown, or combine or separate certain components, or arrange the components differently, and the components may be implemented in hardware, software, or a combination of software and hardware.

[0207] It should be understood that the various schemes of the embodiments of the present application can be reasonably combined and used, and the explanations or descriptions of the various terms appearing in the embodiments can be referenced or explained with each other in the various embodiments, without limitation to this.

[0208] It should also be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0209] It is understandable that, in order to implement the functions of any of the above-mentioned embodiments, a communication device (such as a transmitting end or a receiving end) includes a hardware structure and / or software module corresponding to the execution of each function. It should be easily appreciated by those skilled in the art that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0210] The embodiment of the present application can divide the communication device (such as the transmitting end or the receiving end) into functional modules. For example, each functional module can be divided into different functional modules according to each function, or two or more functions can be integrated into one processing module. For example, as shown in FIG16,

[0211] The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. It should also be understood that the various modules in a communication device (such as a transmitting end or a receiving end) can be implemented in the form of software and / or hardware, and there is no specific limitation on this. In other words, a device (such as a terminal device or a proxy server) is presented in the form of a functional module. The "module" here may refer to an application-specific integrated circuit ASIC, a circuit, a processor and memory that executes one or more software or firmware programs, an integrated logic circuit, and / or other devices that can provide the above-mentioned functions.

[0212] In an optional manner, when data transmission is implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is implemented in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or data center that includes one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a digital video disk (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)).

[0213] The steps of the method or algorithm described in conjunction with the embodiments of the present application can be implemented in hardware or by executing software instructions by a processor. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, registers, hard disk, mobile hard disk, compact disc read-only memory (CD-ROM) or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). In addition, the ASIC can be located in a communication device (such as a transmitting end or a receiving end). Of course, the processor and the storage medium can also exist as discrete components.

[0214] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

Claims

1. A data transmission method, characterized in that: Applied to a first device, the method includes: receiving a first request, wherein the first request is used to request transmission of first information; Generate a first message authentication code MAC according to the first information, the first freshness value and the key; Splitting the first MAC into M parts, where M is a positive integer greater than 1; Sending a first message for indicating the first information, wherein the first message includes first data, the first freshness value, and one of the M parts, wherein the first data is at least part of the data used to carry the first information; receiving a second request, wherein the second request is used to request transmission of second information; A second message is sent to indicate the second information, wherein the second message includes second data, the first fresh value and another part of the M parts, the second data is at least part of the data used to carry the second information, and the second data is the same as the first data.

2. The method according to claim 1, characterized in that The method further comprises: A maintenance counter is provided, wherein the maximum value of the counter is M, the count value of the counter is an initial value when the first message is sent, and the count value is increased by 1 when the second message is sent.

3. The method according to claim 2, characterized in that The method further comprises: After sending the M messages, receiving a third request, the third request being used to request transmission of third information, the M messages respectively including different parts of the M parts, and each of the M messages including the first freshness value, and the M messages including the first message and the second message; generating a second MAC according to the third information, a second freshness value and a key, wherein the second freshness value is different from the first freshness value; A third message is sent to indicate the third information, wherein the third message includes third data, the second freshness value and part of the second MAC, the third data is at least part of the data used to carry the third information, and the third data is the same as the first data.

4. The method according to claim 3, characterized in that When sending the third message, the count value of the counter is the initial value.

5. The method according to any one of claims 2 to 4, characterized in that: The method further comprises: receiving a fourth request, where the fourth request is used to request transmission of fourth information; Generate a third MAC according to the fourth information, the third fresh value and the key; A fourth message is sent to indicate the fourth information, wherein the fourth message includes fourth data, the third freshness value, and part of the third MAC, the fourth data is at least part of the data used to carry the fourth information, and the fourth data is different from the first data.

6. The method according to claim 5, characterized in that When sending the fourth message, the count value of the counter is the initial value.

7. The method according to any one of claims 1 to 6, characterized in that The lengths of the M parts are the same or different.

8. The method according to any one of claims 1 to 7, characterized in that The lengths of the M parts include any one or more of the following lengths: 24 bits, 28 bits or 32 bits.

9. The method according to any one of claims 1 to 8, characterized in that The generating a first MAC according to the first information, the first fresh value and the key includes: The first MAC is generated according to the first data, the first freshness value, and the key.

10. A data transmission method, characterized in that: Applied to the second device, the method includes: Receive a first message from a first device, wherein the first message includes first data, a first freshness value, and an i-th part of M parts of a first MAC, where M is a positive integer greater than 1; Generate a second MAC according to the first data, the first fresh value and the key; Splitting the second MAC into M parts; Determining that the first message is successfully authenticated based on that the j-th part of the M parts of the second MAC is consistent with the i-th part of the M parts of the first MAC, where i,j∈[1,M]; receiving a second message from the first device, wherein the second message includes a first freshness value and an i+1th part of the M parts of the first MAC; Based on the j+1th part among the M parts of the second MAC being consistent with the i+1th part among the M parts of the first MAC, it is determined that the second message verification is successful.

11. The method according to claim 10, characterized in that The method further comprises: A maintenance counter, wherein the maximum value of the counter is M, the count value of the counter is an initial value before verifying the first message, the count value is increased by 1 when the first message verification is successful, and the count value is increased by 1 again when the second message verification is successful.

12. The method according to claim 11, characterized in that The method further comprises: When the second message is successfully verified, the first data is used as data obtained by parsing the second message.

13. The method according to any one of claims 10 to 12, characterized in that: The method further comprises: Based on the inconsistency between the jth part of the M parts of the second MAC and the ith part of the M parts of the first MAC, using the j+1th part of the M parts of the second MAC to verify the first message; Based on the j+1th part among the M parts of the second MAC being consistent with the ith part among the M parts of the first MAC, it is determined that the first message verification is successful.

14. The method according to claim 13, characterized in that The method further comprises: Based on the inconsistency between the j+1th part of the M parts of the second MAC and the ith part of the M parts of the first MAC, use the j+2th part of the M parts of the second MAC to verify the first message, and so on; Because the j+1th, ..., Mth parts of the M parts of the second MAC are inconsistent with the ith part of the M parts of the first MAC, there is a risk of replay attack.

15. The method according to claim 11, characterized in that The method further comprises: receiving a third message from the first device, wherein the third message includes third data, a second fresh value, and a kth part of the M parts of a third MAC; Generate a fourth MAC according to the third data, the second fresh value and the key; Splitting the fourth MAC into M parts; Based on the t-th part among the M parts of the fourth MAC being consistent with the k-th part among the M parts of the third MAC, it is determined that the third message verification is successful, where k, t∈[1,M].

16. The method according to claim 15, characterized in that Before verifying the third message, the count value of the counter is the initial value.

17. The method according to claim 15 or 16, characterized in that The method further comprises: Based on the inconsistency between the tth part of the M parts of the fourth MAC and the kth part of the M parts of the third MAC, using the t+1th part of the M parts of the fourth MAC to verify the third message, and so on; Based on the fact that the t+1th part, ..., the Mth part of the M parts of the fourth MAC are all inconsistent with the kth part of the M parts of the third MAC, a bus attack risk is indicated.

18. The method according to any one of claims 10 to 17, characterized in that: The lengths of the M parts are the same or different.

19. The method according to any one of claims 10 to 18, characterized in that The lengths of the M parts include any one or more of the following lengths: 24 bits, 28 bits or 32 bits.

20. A communication device, characterized in that: The device comprises: Memory for storing computer program instructions and data; A processor, configured to execute the computer program instructions to support the data storage device to implement the method as described in any one of claims 1-9 or 10-19.

21. A vehicle, characterized in that: The vehicle comprises the communication device according to claim 20.

22. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by the processing circuit, the method according to any one of claims 1-9 or 10-19 is implemented.

23. A computer program product comprising instructions, characterized in that When the computer program product is run on a computer, the computer is caused to execute the method according to any one of claims 1 to 9 or 10 to 19.

Images