Communication method and apparatus

Abstract

To solve the problem in the prior art that packets are susceptible to eavesdropping when an ECU transmits them, an in-vehicle network-based communication method and apparatus are provided. In this application, a first ECU performs an operation using a first key and a first fresh value to generate a key stream, performs an exclusive-OR operation using the key stream and a first plaintext packet to be transmitted to generate a first ciphertext packet, and transmits the first ciphertext packet to a second ECU. The first fresh value is a value generated by a counter in the first ECU when the first ECU transmits the packet, and the counter is configured to record the number of packets transmitted by the first ECU. The first ECU transmits the first ciphertext packet to the second ECU. This can help prevent the first packet transmitted by the first ECU from being eavesdropped and improve the confidentiality of the packet transmitted by the first ECU.

Description

Technical Field

[0002] This application relates to the field of communication technologies, and in particular, to a communication method and apparatus based on an in-vehicle network.

Background Art

[0003] With the development of science and technology, various services in the automotive industry are becoming increasingly mature. A large number of electronic control units (ECUs) are configured in a vehicle system, and an ECU is a microcomputer controller specific to a vehicle. The network connecting these ECUs is called a controller area network (CAN). The CAN bus protocol is a serial communication bus based on a message broadcast mode. The protocol was initially used to implement reliable communication between ECUs in a vehicle, and then has been widely used in other fields such as industrial automation, ships, and medical due to features such as simplicity, practicality, and reliability.

[0004] Currently, in communication processing based on the CAN bus protocol, a malicious attacker may eavesdrop on, modify, or perform a replay attack on a CAN packet (frame) transmitted in the communication processing. To prevent an attacker from performing a modification or replay attack on a CAN packet, there are several authentication mechanisms for CAN packets. For example, the secure onboard communication (SecOC) mechanism in AUTomotive open system architecture (AUTOSAR) provides a method for secure communication based on the CAN bus protocol to prevent an attacker from performing a modification or replay attack on a CAN packet. However, the SecOC mechanism in AUTOSAR cannot prevent an attacker from eavesdropping on a CAN packet.

Summary of the Invention

[0005] This application provides an in-vehicle network-based communication method and apparatus for improving the confidentiality of packets transmitted by an ECU.

[0006] According to a first aspect, this application provides an in-vehicle network-based communication method and apparatus. The method can be executed by an ECU in a vehicle. The method includes a step in which a first ECU executes an operation using a first key and a first freshness value to generate a key stream, and a step of performing an exclusive OR operation using the key stream and a first plaintext packet to be transmitted to generate a first ciphertext packet. The first ECU transmits the first ciphertext packet to a second ECU. The first freshness value is a value generated by a counter in the first ECU when the first ECU transmits a packet, and the counter is configured to record the number of packets transmitted by the first ECU.

[0007] Based on this solution, the first ECU obtains a first ciphertext packet by encrypting a first plaintext packet, and transmits the first ciphertext packet to the second ECU. This can help prevent packets transmitted by the first ECU from being eavesdropped on and improve the confidentiality of packets transmitted by the first ECU. Even if the ciphertext packet is stolen by an attacker, the attacker cannot obtain the plaintext packet corresponding to the ciphertext packet.

[0008] In a possible implementation, the first ECU can combine encryption protection and integrity protection. Hereinafter, three examples of possible implementations are provided.

[0009] Implementation 1: The first ECU first performs encryption protection and then integrity protection.

[0010] The first ECU executes an operation using the first key and the first freshness value to generate a key stream, and executes an exclusive OR operation using the key stream and the first plaintext packet to be transmitted to generate a first ciphertext packet. Further, the first ECU can execute an operation using the second key, the first ciphertext packet, and the first freshness value to generate a message authentication code (MAC). The message authentication code is used by the second ECU to perform an integrity check on the first plaintext packet. In a possible implementation, the first ECU arranges the first ciphertext packet, the message authentication code, and the first freshness value in order to obtain a second ciphertext packet, and the first ECU transmits the second ciphertext packet to the second ECU.

[0011] Implementation 2: The first ECU performs integrity protection and encryption protection simultaneously.

[0012] The first ECU executes an operation using the first key and the first freshness value to generate a key stream, and executes an exclusive OR operation using the key stream and the first plaintext packet to generate a first ciphertext packet. In addition, the first ECU performs an operation of generating a message authentication code by using the second key, the first plaintext packet, and the first freshness value, where the message authentication code is used by the second ECU to perform an integrity check on the first plaintext packet, and arranges the first ciphertext packet, the message authentication code, and the first freshness value in order to obtain a second ciphertext packet. In a possible implementation, the first ECU transmits the second ciphertext packet to the second ECU.

[0013] Implementation 3: The first ECU first performs integrity protection and then performs encryption protection.

[0014] The first ECU executes an operation using the second key and the first plaintext packet to generate a message authentication code, where the message authentication code is used by the second ECU to perform an integrity check on the first plaintext packet. Further, the first ECU obtains a second plaintext packet by arranging the first plaintext packet and the message authentication code in sequence. Next, the first ECU executes an exclusive OR operation using the key stream and the second plaintext packet to generate a first ciphertext packet. In a possible implementation, the first ECU transmits the first ciphertext packet and the first freshness value to the second ECU.

[0015] In the present application, the first key may be generated by the first ECU by executing an operation using a key derivation algorithm and using a shared key and a first pre-set parameter, where the shared key is a key shared by the first ECU and the second ECU. Alternatively, the first key may be pre-set by the first ECU. The second key may be generated by the first ECU by executing an operation using a key derivation algorithm and using a shared key and a second pre-set parameter, or may be pre-set by the first ECU.

[0016] In the present application, the first ECU may further transmit indication information to the second ECU. The indication information is used to indicate that the first ECU performs integrity protection on the first plaintext packet, or is used to indicate that the first ECU performs integrity protection and encryption protection on the first plaintext packet.

[0017] According to a second aspect, the present application provides a communication method based on an in-vehicle network, which can be executed by an ECU in a vehicle. The method includes: a second ECU obtains a first ciphertext packet and a first freshness value, executes an operation using a first key and the first freshness value to generate a key stream, and executes an exclusive OR operation using the key stream and the first ciphertext packet to obtain a first plaintext packet. The first ciphertext packet comes from a first ECU, the first freshness value is a value generated by a counter in the first ECU when the first ECU transmits a packet, the counter is configured to record the quantity of packets transmitted by the first ECU, and the shared key is a key shared by the first ECU and the second ECU.

[0018] Based on this solution, the second ECU receives the first ciphertext packet transmitted by the first ECU. This can help prevent the packets received by the second ECU from being eavesdropped and improve the confidentiality of the packets received by the second ECU. Even if the ciphertext packet is stolen by an attacker, the attacker cannot obtain the plaintext packet corresponding to the ciphertext packet.

[0019] The order in which the second ECU performs integrity check and decryption can be divided into the following two cases.

[0020] Case 1: The second ECU first performs an integrity check and then performs decryption, or performs the integrity check and decryption simultaneously.

[0021] The second ECU is to receive a second encrypted packet from the first ECU, where the second encrypted packet is obtained by arranging the first encrypted packet, the message authentication code, and the first freshness value in sequence, and obtain the first encrypted packet, the message authentication code, and the first freshness value from the second encrypted packet. When it is determined that the first freshness value is greater than the second freshness value, an operation using the second key, the first encrypted packet, and the first freshness value is executed to generate a new message authentication code. If it is determined that the new message authentication code matches the obtained message authentication code, the integrity check is successful. The second freshness value is the freshness value locally stored when the second ECU receives the second encrypted packet. Next, the second ECU executes an operation using the first key and the first freshness value to generate a key stream, and executes an exclusive OR operation using the key stream and the first encrypted packet to obtain the first plaintext packet.

[0022] Case 2: The second ECU first performs decryption and then executes an integrity check.

[0023] Case 2 can be divided into the following two cases.

[0024] Case 2.1: The second ECU receives the first encrypted packet and the first freshness value from the first ECU. The second ECU executes an exclusive OR operation using the key stream and the first encrypted packet to obtain the second plaintext packet, where the second plaintext packet is obtained by arranging the first plaintext packet and the message authentication code in sequence.

[0025] Furthermore, optionally, the second ECU executes an operation using the second key, the first plaintext packet, and the first freshness value to generate a new message authentication code. If it is determined that the new message authentication code matches the obtained message authentication code, it is determined that the first plaintext packet is complete.

[0026] Case 2.2: The second ECU is to receive a second encrypted packet from the first ECU, where the second encrypted packet is obtained by arranging in order the first encrypted packet, the message authentication code, and the first freshness value, and obtain the first encrypted packet, the message authentication code, and the first freshness value from the second encrypted packet. When it is determined that the first freshness value is greater than the second freshness value, the second ECU executes an operation using the second key, the first plaintext packet, and the first freshness value to generate a new message authentication code. If it is determined that the new message authentication code matches the obtained message authentication code, the integrity check is successful. The second freshness value can be a freshness value locally stored when the second ECU receives the second encrypted packet.

[0027] In a possible implementation, the first key may be generated by the second ECU by executing an operation using a key derivation algorithm and using a shared key and a first pre-set parameter, where the shared key is a key shared by the first ECU and the second ECU. Alternatively, the first key may be pre-set by the second ECU. The second key may be generated by the second ECU by executing an operation using a key derivation algorithm and using a shared key and a second pre-set parameter, or may be pre-set by the second ECU.

[0028] In a possible implementation, the second ECU may further receive indication information from the first ECU, where the indication information is used to indicate that the first ECU performs integrity protection for the first plaintext packet, or is used to indicate that the first ECU performs integrity protection and encryption protection for the first plaintext packet. After the second ECU receives the indication information used by the first ECU to indicate that the first ECU performs integrity protection for the first plaintext packet, the second ECU performs an integrity check on the first plaintext packet after decryption.

[0029] According to a third aspect, the present application provides a communication device. The communication device has a function of implementing the first ECU in the first aspect or the second ECU in the second aspect. The function may be implemented by using hardware, or may be implemented by using hardware that executes corresponding software. The hardware or software includes one or more units or modules corresponding to the above functions.

[0030] In a possible implementation, the communication device may be an ECU, or a module such as a chip, chip system, or circuit that can be used within the ECU. For the beneficial effects, refer to the description in the first aspect or the second aspect. The details will not be described again here. The communication device may include a transceiver and a processor. The processor may be configured to support the communication device when executing the corresponding functions of the above ECU. The transceiver is configured to support the communication device when communicating with another ECU or the like. The transceiver may be an independent receiver, an independent transmitter, a transceiver integrating receiving / transmitting functions, or an interface circuit. Optionally, the communication device may further include a memory, which may be coupled to the processor and stores program instructions and data used for the communication device.

[0031] According to a fourth aspect, the present application provides a communication device configured to perform a method according to the first aspect or any one of its possible implementations, or configured to perform a method according to the second aspect or any one of its possible implementations. The communication device comprises corresponding functional modules respectively configured to perform steps in the above methods. The functions may be implemented by utilizing hardware or by utilizing hardware executing corresponding software. The hardware or software comprises one or more modules corresponding to the above functions.

[0032] In a possible implementation, the communication device may be an ECU, and the communication device may include a processing module and a transceiver module. These modules are ECU For details, please refer to the detailed description in the method example. The details will not be described again here.

[0033] According to a fifth aspect, the present application provides a communication system. The communication system includes a first ECU and a second ECU. The first ECU may be configured to execute the method of the first aspect or any one of the possible implementations of the first aspect, and the second ECU may be configured to execute the method of the second aspect or any one of the possible implementations of the second aspect.

[0034] According to a sixth aspect, the present application provides a computer-readable storage medium. The computer-readable storage medium stores a computer program or instructions. When the computer program or instructions are executed by a communication device, the communication device is enabled to perform the method of the first aspect or any one of the possible implementations of the first aspect, or the communication device is enabled to perform the method of the second aspect or any one of the possible implementations of the second aspect.

[0035] According to a seventh aspect, the present application provides a computer program product. The computer program product includes a computer program or instructions. When the computer program or instructions are executed by a communication device, the method according to any one of the first aspect or possible implementations of the first aspect is implemented, or the method according to any one of the second aspect or possible implementations of the second aspect is implemented.

Brief Description of the Drawings

[0036]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Modes for Carrying Out the Invention

[0037] Hereinafter, embodiments of the present application will be described in detail with reference to the accompanying drawings.

[0038] FIG. 1 is a schematic diagram of the architecture of a communication system to which the present application is applicable. For example, the communication system is an electronic and electrical (E / E) system. The communication system may include a gateway, a domain controller, electronic control units (ECUs), and at least one CAN bus. The communication system may be divided into a plurality of different domains based on functions. Each domain may include at least one domain controller, and each domain controller is configured to manage a plurality of ECUs connected to one or more CAN buses within the domain. As shown in FIG. 1, domain controller 1 is configured to manage a plurality of ECUs connected to the vehicle control system CAN bus within the domain, domain controller 2 is configured to manage a plurality of ECUs connected to the entertainment system CAN bus within the domain, domain controller 3 is configured to manage a plurality of ECUs connected to the diagnostic system CAN bus within the domain, and domain controller 4 is configured to manage a plurality of ECUs connected to the intelligent driving system CAN bus within the domain. A domain controller can also be an ECU. Each domain controller in the communication system belongs to the gateway. As shown in FIG. 1, domain controllers 1, 2, 3, and 4 belong to the gateway. For example, the gateway is configured to separate an ECU outside the communication system from the communication system and can perform protocol conversion between ECUs within the communication system. The gateway may also be an ECU. FIG. 1 is only a schematic diagram. The communication system may further include another device, for example, a relay device not shown in FIG. 1. The number of gateways, domain controllers, and ECUs connected to various CAN buses included in the communication system is not limited in the present application.

[0039] A communication system may include a vehicle having a communication function, an in-vehicle device, a wireless terminal in autonomous driving, and an in-vehicle network chip, etc. In this application, the scenarios to which the communication system is applicable are not limited.

[0040] It should be noted that the system architecture and application scenarios described in this application are intended to more clearly explain the technical solutions in this application and are not intended to limit the technical solutions provided in this application. As the system architecture evolves and new scenarios emerge, those skilled in the art can know that the technical solutions provided in this application are also applicable to similar technical problems.

[0041] In the following, in order to facilitate the understanding of those skilled in the art, some terms in this application will be explained and described.

[0042] 1. Replay Attack

[0043] A replay attack, also known as a playback attack or a repeat attack, is a type of attack in which an attacker sends a packet received by a target host in order to impersonate a system, and is mainly used to undermine the validity of authentication in an identity authentication process.

[0044] The basic principle of a replay attack is to resend the eavesdropped data to the receiver without any modification. For example, the system simply encrypts the authentication information before sending it. In this case, the attacker cannot eavesdrop on the password, but the attacker can intercept the encrypted password and replay the encrypted password to launch an attack in such a way.

[0045] 2. Key Stream

[0046] To enable a short key (also called the actual key or the seed key) to be used to encrypt longer plaintext or decrypt longer ciphertext, a long key stream is generated by using a short random key, and the long key stream is used to encrypt the plaintext or decrypt the ciphertext.

[0047] 3. Protocol Data Unit (PDU)

[0048] In a hierarchical network structure, for example, in the Open Systems Interconnection (OSI) model, a PDU is established at each layer of the sending system. The PDU includes information from the upper layer and additional information from the entity at the current layer. This PDU is delivered to the next lower layer.

[0049] 4. Exclusive OR (xor)

[0050] The mathematical symbol for exclusive OR is

[0051]

Number

[0052] That is. When a and b are different, the result of the exclusive OR is 1, or when a and b are the same, the result of the exclusive OR is 0.

[0053] 5. Least Significant Bit (LSB)

[0054] The LSB refers to bit 0 in a binary number (i.e., the least significant bit) and has a weight of 2 0 In big-endian order, the LSB refers to the rightmost bit.

[0055] 6. Most Significant Bit (MSB)

[0056] The MSB refers to bit n - 1 in an n - bit binary number and has the highest weight of 2 (n-1) and corresponds to the LSB. In big - endian order, the MSB refers to the left - most bit.

[0057] Referring to FIGS. 2 to 7, the in - vehicle network - based communication method provided in the present application will be described in detail below. In the present application, "at least one" means one or more, and "a plurality of" means two or more. "At least one of the following items (pieces)", or a similar expression, indicates any combination of these items including a single item (piece), or any combination of a plurality of items (pieces). For example, at least one of a, b, or c may indicate a, b, c, "a and b", "a and c", "b and c", or "a, b, and c", where a, b, and c may be singular or plural. The term "and / or" describes the association relationship between related objects and indicates that three relationships may exist. For example, A and / or B may represent the following three cases: namely, only A exists, both A and B exist, and only B exists. A and B may be in singular or plural forms. In the text description of the present application, the symbol " / " generally represents the "or" relationship between related objects. In the formulas of the present application, the symbol " / " indicates the "division" relationship between related objects.

[0058] The various numbers in the embodiments of this application are only used for distinction to facilitate the description and are not to be understood as being used to limit the scope of the embodiments of this application. It should be understood that the sequence numbers of the above processes do not mean the execution order, and the execution order of the processes should be determined based on the functions and internal logic of the processes. Terms such as "first" and "second" are used to distinguish similar objects and do not need to be used to describe a specific order or sequence. In addition, the terms "include" and "have" and any variations thereof cover non-exclusive inclusion, for example, they are intended to include a series of steps or modules. A method, system, product, or device is not necessarily limited to the steps or modules literally listed, and may include other steps or modules not literally listed or specific to such a process, method, product, or device.

[0059] This application provides a communication method based on an in-vehicle network. The method is applicable to the communication system shown in FIG. 1. The first ECU and the second ECU may be any two ECUs in FIG. 1. Each of the ECUs shown in FIG. 1 stores a shared key (secret key K). In other words, the first ECU and the second ECU may be two ECUs arranged in the same vehicle, and each of the first ECU and the second ECU stores a shared key. Further, optionally, the method is applicable to the Secure On-Board Communication (SecOC) mechanism in the Automotive Open System Architecture (AUTOSAR). This provides confidentiality protection for the packets transmitted through SecOC and is compatible with the existing SecOC mechanism.

[0060] FIG. 2 is a schematic flowchart of a communication method based on an in-vehicle network according to this application. The method includes the following steps.

[0061] Step 201: The first ECU executes an operation using a key derivation algorithm with a shared key and a first pre-set parameter to generate a first key. The shared key is a key shared by the first ECU and the second ECU.

[0062] Step 201 is an optional step. For example, the first key may alternatively be pre-set by the first ECU.

[0063] It can also be understood that the input to the key derivation algorithm includes the shared key and the first pre-set parameter, and the output is the first key. The key derivation algorithm may be a key derivation function (KDF). The first key is a key used by the first ECU to encrypt the first plaintext packet, and the first pre-set parameter is used to indicate that the first key needs to be generated.

[0064] Furthermore, optionally, the input to the key derivation algorithm may further include one or more of an identifier of the first plaintext packet, a first freshness value (counter, CNT), a CAN identifier, and an ECU identifier. The identifier of the first plaintext packet may uniquely identify one first plaintext packet, and the first freshness value is a value generated by a counter in the first ECU when the first ECU transmits a packet. In a possible case, the first ECU locally holds the counter, and the counter is configured to record the number of packets transmitted by the first ECU. For example, when the first ECU transmits a first plaintext packet, the first freshness value generated by the counter is incremented by 1. The CAN identifier is an identifier of the CAN bus connected to the first ECU. Referring to FIG. 1, when the first ECU is an ECU connected to the vehicle control system CAN bus, the CAN identifier is the identifier of the vehicle control system CAN bus, or when the first ECU is an ECU connected to the diagnostic system CAN bus, the CAN identifier is the identifier of the diagnostic system CAN bus. The ECU identifier may uniquely identify one ECU, i.e., the identifier of the first ECU.

[0065] Step 202: The first ECU performs an operation using the first key and the first freshness value to generate a key stream.

[0066] Here, the operation for generating the key stream may be based on an encryption algorithm or may be based on a KDF. Also, the first ECU may perform an operation for outputting a key stream using the first key and the first freshness value input to the KDF, or it may be understood that the first ECU may perform an operation using the first key and the first freshness value input to the encryption algorithm to output a key stream. Refer to FIG. 3.

[0067] Furthermore, the input for generating the key stream may further include the length of the key stream, the identifier of the CAN packet, and / or the identifier of the first plaintext packet to be transmitted. It should be understood that the length of the key stream may be a default length set by the first ECU.

[0068] Step 203: The first ECU performs an exclusive OR operation using the key stream and the first plaintext packet to generate a first ciphertext packet.

[0069] That is, the first ciphertext packet is

[0070]

Equation

[0071] obtained by (see Figure 3), where the first plaintext packet transmitted by the first ECU may be PDU data.

[0072] Step 204: The first ECU transmits the first ciphertext packet to the second ECU.

[0073] Step 205: The second ECU obtains the first ciphertext packet and the first freshness value.

[0074] In a possible implementation, the second ECU may receive the first ciphertext packet and the first freshness value from the first ECU. That is, the first ECU may transmit the first ciphertext packet and the first freshness value to the second ECU.

[0075] In another possible implementation, the second ECU may obtain the first ciphertext packet from the first ECU and obtain the first freshness value from another device (e.g., the domain controller or gateway in the communication system shown in Figure 1).

[0076] In yet another possible implementation, the second ECU may decrypt the first ciphertext packet from the first ECU to obtain the first freshness value.

[0077] Step 206: The second ECU executes an operation using the shared key and the first pre-set parameter by means of a key derivation algorithm to generate a first key.

[0078] Here, the shared key is shared by the second ECU and the first ECU, and the first pre-set parameter and the key derivation algorithm may be pre-agreed by the first ECU and the second ECU. In addition, for Step 206, refer to the description in Step 201. Details will not be described again here.

[0079] Step 206 is optional, and the first key may be pre-set by the second ECU.

[0080] Step 207: The second ECU executes an operation using the first key and the first freshness value to generate a key stream.

[0081] For Step 207, refer to the description in Step 202, that is, the first ECU in Step 202 is replaced by the second ECU. Details will not be described again here.

[0082] Step 208: The second ECU executes an exclusive OR operation using the key stream and the first ciphertext packet to obtain the first plaintext packet.

[0083] In other words, to obtain the first ciphertext packet, an exclusive OR operation is performed on the key stream and the first plaintext packet. Conversely, to obtain the first plaintext packet, an exclusive OR operation is performed on the key stream and the first ciphertext packet.

[0084] As can be understood from steps 201 to 208 above, the first ECU can obtain a first encrypted packet by encrypting a first plaintext packet and transmit the first encrypted packet to the second ECU. This can help prevent the packets transmitted by the first ECU from being eavesdropped and improve the confidentiality of the packets transmitted by the first ECU. Even if the first encrypted packet is stolen by an attacker, the attacker cannot obtain the first plaintext packet corresponding to the first encrypted packet.

[0085] In this application, in order to prevent an attacker from tampering with the first plaintext packet and performing a replay attack, the first ECU can further perform integrity protection on the first plaintext packet. In other words, the first ECU can perform integrity protection and encryption protection on the first plaintext packet to be transmitted. In this way, not only can the first plaintext packet be prevented from being eavesdropped, but also the first plaintext packet can be prevented from being subjected to a replay attack and being tampered with. Hereinafter, three possible implementation examples of combining integrity protection and encryption protection are provided. Hereinafter, the operations for generating the key stream are based on an encryption algorithm, and the description is provided by using an example in which the second ECU obtains the first freshness value from the first ECU.

[0086] Implementation 1: The first ECU first performs encryption protection and then integrity protection.

[0087] FIG. 4 is a schematic flowchart of a method for first performing encryption protection and then integrity protection according to this application. The first ECU can execute an operation using a shared key and a first pre-set parameter by using a key derivation algorithm to generate a first key, execute an operation using the first key and the first freshness value to generate a key stream, and execute an exclusive OR operation using the key stream and the first plaintext packet to obtain the first encrypted packet.

[0088] Furthermore, the first ECU executes an operation using the shared key and the second pre-set parameter by utilizing a key derivation algorithm to generate a second key, and executes an operation using the second key, the first encrypted packet, and the first freshness value to generate a message authentication code.

[0089] In a possible implementation, the first ECU can arrange the first encrypted packet, the message authentication code, and the first freshness value in order. For example, the message authentication code is placed behind the first freshness value, and the first freshness value is placed behind the first encrypted packet. For another example, the first freshness value is placed behind the message authentication code, and the first encrypted packet is placed behind the first freshness value. The first ECU acquires the second encrypted packet and transmits the second encrypted packet to the second ECU.

[0090] In Implementation 1, the second ECU can first execute a integrity check and then execute decryption, or execute the integrity check and decryption simultaneously.

[0091] In a possible implementation, after receiving the second ciphertext packet from the first ECU, the second ECU may separately obtain the first ciphertext packet, the message authentication code, and the first freshness value. If the second ECU determines that the first freshness value is greater than the second freshness value, it indicates that the first plaintext packet is not under a replay attack. The second freshness value is the freshness value locally stored when the second ECU receives the second ciphertext packet. Further, the second ECU uses a key derivation algorithm to execute an operation using the shared key and the second pre-set parameter to generate a second key, and executes an operation using the second key, the first ciphertext packet, and the first freshness value to generate a new message authentication code. If the second ECU determines that the new message authentication code matches the obtained message authentication code, the integrity check is successful, that is, the first plaintext packet has not been tampered with or a replay attack has not been executed, or if the second ECU determines that the new message authentication code does not match the message authentication code obtained from the second ciphertext packet, the integrity check fails. If the integrity check is successful, it indicates that both the first plaintext packet and the first freshness value received by the second ECU are complete and not tampered with.

[0092] If it is determined that the integrity check is successful, the second ECU decrypts the first ciphertext packet. The specific process may be as follows. The second ECU uses a key derivation algorithm to execute an operation using the shared key and the first pre-set parameter to generate a first key, executes an operation using the first key and the first freshness value to generate a key stream, and executes an exclusive OR operation using the key stream and the first ciphertext packet to obtain the first plaintext packet. The first plaintext packet is a valid message transmitted from the first ECU to the second ECU.

[0093] If the second ECU determines that the integrity check has failed, the second ECU does not need to execute the process of decrypting the first ciphertext packet. Thus, when the second ECU first executes the integrity check, if the integrity check fails, the decryption process does not need to be executed.

[0094] Implementation 2: The first ECU simultaneously executes encryption protection and integrity protection.

[0095] FIG. 5 is a schematic flowchart of a method for simultaneously executing integrity protection and encryption protection according to the present application. The first ECU utilizes a key derivation algorithm to execute an operation using a shared key and a second pre-set parameter to generate a second key, and executes an operation using the second key, the first plaintext packet, and the first freshness value to generate a message authentication code.

[0096] In addition, the first ECU utilizes a key derivation algorithm to execute an operation using the shared key and the first pre-set parameter to generate a first key, executes an operation using the first key and the first freshness value to generate a key stream, executes an exclusive OR operation using the key stream and the first plaintext packet to obtain a first ciphertext packet, and can arrange the first ciphertext packet, the message authentication code, and the first freshness value in sequence. For example, the message authentication code is arranged behind the first freshness value, and the first freshness value is arranged behind the first ciphertext packet. For another example, the first freshness value is arranged behind the message authentication code, and the first ciphertext packet is arranged behind the first freshness value. The first ECU can obtain a second ciphertext packet and transmit the second ciphertext packet to the second ECU.

[0097] In Implementation 2, since the message authentication code is generated based on the first plaintext packet, the second ECU first needs to execute decryption to obtain the first plaintext packet and then execute an integrity check.

[0098] In a possible implementation, the second ECU receives a second ciphertext packet from the first ECU, where the second ciphertext packet is obtained by arranging the first ciphertext packet, the message authentication code, and the first freshness value in sequence. The second ECU may separately obtain the first ciphertext packet, the message authentication code, and the first freshness value from the second ciphertext packet. The second ECU utilizes a key derivation algorithm to execute an operation using the shared key and the first pre-set parameter to generate a first key, executes an operation using the first key and the first freshness value to generate a key stream, and executes an exclusive OR operation using the key stream and the first ciphertext packet to obtain a first plaintext packet. If it is determined that the first freshness value is greater than the second freshness value, the second ECU is to utilize a key derivation algorithm to execute an operation using the shared key and the second pre-set parameter to generate a second key, where the second freshness value is the freshness value locally stored when the second ECU receives the second ciphertext packet, perform an operation using the second key, the first plaintext packet, and the first freshness value to generate a new message authentication code. If the second ECU determines that the new message authentication code matches the obtained message authentication code, the integrity check is successful, or if the second ECU determines that the new message authentication code does not match the obtained message authentication code, the integrity check fails.

[0099] Implementation 3: The first ECU first performs integrity protection and then encryption protection.

[0100] Figure 6 is a schematic flowchart of a method for first performing integrity protection and then performing encryption protection according to the present application. The first ECU executes an operation using a key derivation algorithm to generate a second key by performing an operation using a shared key and a second pre-set parameter, executes an operation using the second key, the first plaintext packet, and the first freshness value to generate a message authentication code, and arranges the first plaintext packet and the message authentication code in order. For example, the message authentication code is placed after the first plaintext packet. In another example, the first plaintext packet is placed after the message authentication code. The first ECU obtains a second plaintext packet. Further, the first ECU executes an operation using the first key and the first freshness value to generate a key stream, executes an exclusive OR operation using the key stream and the second plaintext packet to generate a first ciphertext packet, and transmits the first ciphertext packet and the first freshness value to the second ECU.

[0101] In implementation 3, since the message authentication code generated by the first ECU is based on the first plaintext packet, the second ECU needs to first execute decryption to obtain the first plaintext packet and then perform an integrity check.

[0102] In a possible implementation, the second ECU receives the first ciphertext packet and the first freshness value from the first ECU, executes an operation using a key derivation algorithm to generate a first key by performing an operation using a shared key and a first pre-set parameter, executes an operation using the first key and the first freshness value to generate a key stream, and executes an exclusive OR operation using the key stream and the first ciphertext packet to obtain a second plaintext packet. The second plaintext packet is obtained by arranging the first plaintext packet, the first freshness value, and the message authentication code in order. In other words, the second ECU obtains the first plaintext packet, the first freshness value, and the message authentication code from the second plaintext packet.

[0103] To ensure that the first plaintext packet obtained through decryption is not under a replay attack and has not been tampered with, the second ECU uses a key derivation algorithm to perform an operation using the shared key and the second pre-set parameter to generate a second key, and then performs an operation using the second key, the first plaintext packet, and the first freshness value to generate a new message authentication code. If the second ECU determines that the new message authentication code matches the obtained message authentication code, the integrity check is successful. Or, if the second ECU determines that the new message authentication code does not match the obtained message authentication code, the integrity check fails, and the first plaintext packet may be immediately discarded.

[0104] In the above three implementations, in a possible implementation, after determining that the check is successful, the second ECU may update the obtained first freshness value to the second freshness value stored locally.

[0105] In the above three implementations, to further improve the security of the packets transmitted by the first ECU, it should be noted that the first key used for encryption and the second key used for integrity protection are different. For example, different pre-set parameters (e.g., algorithm type parameters (algorithm type identifiers)) are input for the implementation. For example, the pre-set parameter for generating the first key is the first pre-set parameter, the pre-set parameter for generating the second key is the second pre-set parameter, and the first pre-set parameter and the second pre-set parameter are different. For example, the first pre-set parameter may be "0x01" and the second pre-set parameter may be "0x02". For another example, the first pre-set parameter may be "encryption" and the second pre-set parameter may be "integrity". In addition, the first pre-set parameter and the key generation algorithm may be agreed upon by the first ECU and the second ECU.

[0106] In this application, the input for generating the first ciphertext packet may further include one or more of the identifier of the first plaintext packet, the identifier of the CAN packet, and the length of the key stream. Additionally, the input for generating the message authentication code may also include the identifier of the first plaintext packet. If the input used by the first ECU to generate the message authentication code includes the identifier of the first plaintext packet, the input used by the second ECU to generate a new message authentication code may also include the identifier of the first plaintext packet. The second ECU may obtain the identifier of the first plaintext packet from the packet header of the second ciphertext packet. In a possible implementation, the message authentication code may be a 128-bit character string.

[0107] In this application, in order to reduce the load transmitted by the first ECU, in a possible implementation, the length occupied by the freshness value transmitted by the first ECU to the second ECU may be shortened. For example, the freshness value may be truncated. In other words, the first freshness value may be a truncated freshness value.

[0108] In a possible implementation, the truncated freshness value may be configured to start from the LSB of the complete freshness value or may be configured to start from the MSB of the complete freshness value. To further reduce the load transmitted by the first ECU, the message authentication code may also be truncated. In a possible implementation, the truncated message authentication code may be configured to start from the MSB or may be configured to start from the LSB. In FIG. 7, for example, the truncated message authentication code is configured to start from the MSB and the truncated freshness value is configured to start from the LSB. The truncated freshness value, the truncated message authentication code, and the first ciphertext packet are arranged in order to obtain a second ciphertext, and the second ciphertext packet is transmitted to the second ECU. After receiving the second ciphertext packet, the second ECU obtains the first ciphertext packet, the truncated freshness value, and the truncated message authentication code from the second ciphertext packet. If the second ECU determines that the received truncated freshness value is within the freshness value locally stored in the second ECU and is greater than the freshness value corresponding to the truncated freshness value, it indicates that the received first plaintext packet is not under a replay attack. Further, optionally, the second ECU concatenates a freshness value that is within the locally stored freshness value and other than the freshness value corresponding to the truncated freshness value to the received truncated freshness value to obtain a complete freshness value. If the second ECU determines that the received truncated freshness value is within the freshness value locally stored in the second ECU and is less than the freshness value corresponding to the truncated freshness value, the second ECU adds 1 to a freshness value that is within the locally stored freshness value and other than the freshness value corresponding to the truncated freshness value, and then concatenates the freshness value with 1 added to the received truncated freshness value to obtain a complete freshness value.For example, if the truncated fresh value is 5 bits configured to start from the LSB and the locally stored fresh value in the second ECU is 15 bits, the fresh value corresponding to the truncated fresh value is 5 bits starting from the LSB in the 15-bit fresh value locally stored, and the fresh values other than the fresh value corresponding to the truncated fresh value are 10 bits starting from the MSB in the 15-bit fresh value locally stored.

[0109] It should be noted that the first fresh value in the input of the new message authentication code and key stream generated by the second ECU is the complete fresh value.

[0110] In this application, when the first ECU sends the first encrypted packet and the first fresh value to the second ECU, indication information may be included. The indication information may be used to indicate that the first ECU performs integrity protection on the first plaintext packet, or the indication information may be used by the first ECU to perform integrity protection and encryption protection on the first plaintext packet. After receiving the indication information, the second ECU may check whether integrity protection is performed on the encrypted packet based on the indication information. Furthermore, the indication information may be used to indicate that the first ECU performs encryption protection on the first plaintext packet, or the indication information may be used to indicate that the first ECU does not perform any protection on the first plaintext packet, or the indication information may be used to indicate that the first ECU performs encryption protection on the first plaintext packet and does not perform integrity protection, or the indication information may be used to indicate that the first ECU performs integrity protection on the first plaintext packet and does not perform encryption protection, etc.

[0111] In a possible implementation, the indication information may be information independent of the first ciphertext packet, or may be carried within the packet header of the first ciphertext packet or the second ciphertext packet. For example, the indication information may be identified by using 1 byte. For example, 0 may be used to indicate that no encryption protection is performed on the first plaintext packet, 1 may be used to indicate that encryption protection is performed on the first plaintext packet, or 0 may be used to indicate that no integrity protection is performed on the first plaintext packet, and 1 may be used to indicate that integrity protection is performed on the first plaintext packet. For example, the indication information may be indicated by using 2 bytes. For example, 00 indicates that neither integrity protection nor encryption protection is performed on the first plaintext packet, 01 indicates that no integrity protection is performed on the first plaintext packet but encryption protection is performed on the first plaintext packet, 10 indicates that integrity protection is performed on the first plaintext packet but no encryption protection is performed on the first plaintext packet, and 11 indicates that both integrity protection and encryption protection are performed on the first plaintext packet. It should be understood that the packet header is not encrypted, and after receiving the second ciphertext packet or the first ciphertext packet, the second ECU can immediately determine the indication information from the packet header.

[0112] To implement the functions in the above embodiments, it can be understood that the communication device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should easily recognize that, in combination with the modules and method steps in the examples described in the embodiments disclosed in this application, this application can be implemented by hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by hardware driven by computer software depends on specific application scenarios and design constraints of the technical solutions.

[0113] FIG. 8 and FIG. 9 are respectively schematic diagrams of possible structures of a communication device according to this application. The communication device can be configured to implement the functions of the first ECU or the second ECU in the above method embodiments. Therefore, the beneficial effects of the above method embodiments can also be achieved. In this application, the communication device can be the ECU shown in FIG. 1 or a module (for example, a chip) applicable to the ECU.

[0114] As shown in FIG. 8, the communication device 800 can include a processing module 801 and a transceiver module 802. The communication device 800 is configured to implement the functions of the first ECU or the second ECU in the method embodiments shown in FIGS. 2, 3, 4, 5, or 6.

[0115] When the communication device 800 is configured to implement the functions of the first ECU in the method embodiment shown in FIG. 2, the processing module 801 is configured to execute an operation using the first key and the first freshness value to generate a key stream, and execute an exclusive OR operation using the key stream and the first plaintext packet to be transmitted to generate a first ciphertext packet. Here, the first freshness value is a value generated by a counter in the communication device when the communication device transmits a packet, and the counter is configured to record the number of packets transmitted by the communication device. The transceiver module 802 is configured to transmit the first ciphertext packet to the second ECU.

[0116] When the communication device 800 is configured to implement the functions of the second ECU in the method embodiment shown in FIG. 2, the processing module 801 is to obtain the first ciphertext packet and the first freshness value, where the first ciphertext packet is from the first ECU, and the first freshness value is a value generated by a counter in the first ECU when the first ECU transmits a packet, and the counter is configured to record the number of packets transmitted by the first ECU, and then execute an operation using the first key and the first freshness value to generate a key stream, and execute an exclusive OR operation using the key stream and the first ciphertext packet to obtain the first plaintext packet.

[0117] For a more detailed description of the processing module 801 and the transceiver module 802, please directly refer to the relevant description in the method embodiment shown in FIG. 2. The details will not be described again here.

[0118] It should be understood that the processing module 801 in this embodiment of the present application may be implemented by a processor or a processor-related circuit component, and the transceiver module 802 may be implemented by a transceiver or a transceiver-related circuit component.

[0119] Based on the above content and the same concept, as shown in FIG. 9, the present application further provides a communication device 900. The communication device 900 may include a processor 901 and a transceiver 902. The processor 901 and the transceiver 902 are coupled to each other. It can be understood that the transceiver 902 may be an interface circuit or an input / output interface. Optionally, the communication device 900 may further include a memory 903 configured to store instructions executed by the processor 901, store input data used by the processor 901 to execute the instructions, or store data generated after the processor 901 executes the instructions.

[0120] When the communication device 900 is configured to implement the method shown in FIG. 2, the processor 901 is configured to execute the functions of the processing module 801, and the transceiver 902 is configured to execute the functions of the transceiver module 802.

[0121] The processor in the embodiments of the present application may be a central processing unit (CPU), or another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or another programmable logic device, a transistor logic device, a hardware component, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0122] The method steps in the embodiments of the present application may be implemented in a hardware manner or in a manner of executing software instructions by a processor. The software instructions may include corresponding software modules. The software modules may be stored in a random access memory (RAM), flash memory, read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), register, hard disk, removable hard disk, CD-ROM, or any other form of storage medium well known in the art. For example, the storage medium is coupled to the processor such that the processor can read information from or write information to the storage medium. Of course, the storage medium may be a component of the processor. The processor and the storage medium may be disposed within an ASIC. In addition, the ASIC may be disposed within a network device or a terminal device. Of course, the processor and the storage medium may exist within a network device or a terminal device as individual components.

[0123] All or some of the above embodiments may be implemented by using software, hardware, firmware, or any combination thereof. When software is used to implement the embodiments, all or some of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the procedures or functions in the embodiments of the present application are executed in whole or in part. The computer may be a general-purpose computer, a dedicated computer, a computer network, a network device, a user device, or another programmable device. The computer program or instructions may 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 program or instructions may be transmitted in a wired or wireless manner from a website, a computer, a server, or a data center to another website, a computer, a server, or a data center. The computer-readable storage medium may be any available medium accessible by a computer or a data storage device such as a server or a data center that integrates one or more available media. The available media may be a magnetic medium such as a floppy disk, a hard disk, or a magnetic tape, an optical medium such as a digital video disc (DVD), or a semiconductor medium such as a solid-state drive (SSD).

[0124] In the embodiments of the present application, unless otherwise specified or there is no logical contradiction, the terms and / or descriptions between different embodiments are consistent and may be cross-referenced to each other. To form a new embodiment, the technical features in different embodiments may be combined based on their internal logical relationships.

[0125] Of course, those skilled in the art can make various changes and modifications to this application without departing from the scope of protection of this application. This application is intended to cover these changes and modifications of this application as long as they are included within the scope of the following claims and the scope of equivalent technologies thereof.

Claims

1. 1. A communication method comprising: performing, by a first in-vehicle device, an operation utilizing a key derivation algorithm that utilizes a shared key and a first pre-configured parameter to generate a first key, the shared key being a key shared between the first in-vehicle device and a second in-vehicle device, the first pre-configured parameter and the key derivation algorithm being pre-agreed upon by the first in-vehicle device and the second in-vehicle device, the first pre-configured parameter being an algorithm type identifier indicating that the key derivation algorithm is an algorithm for encryption or indicating that the first key is used to encrypt a first plaintext packet, the first in-vehicle device being an electronic control unit (ECU) and the second in-vehicle device being another ECU; performing, by the first in-vehicle device, an operation utilizing the first key and a first fresh value to generate a keystream, the first fresh value being a value generated by a counter in the first in-vehicle device as the first in-vehicle device transmits packets over an in-vehicle network, the counter being configured to record a quantity of packets transmitted by the first in-vehicle device; performing, by the first in-vehicle device, an exclusive-OR operation utilizing the keystream and the first plaintext packet to generate a first ciphertext packet; transmitting, by the first in-vehicle device, the first ciphertext packet to the second in-vehicle device; A method comprising:

2. The method comprises: performing, by the first in-vehicle device, an operation utilizing a second key, the first ciphertext packet, and the first freshness value to generate a message authentication code, the message authentication code being utilized by the second in-vehicle device to perform an integrity check on the first plaintext packet; ordering, by the first in-vehicle device, the first ciphertext packet, the message authentication code, and the first freshness value to obtain a second ciphertext packet; Further comprising: The step of transmitting the first ciphertext packet to a second in-vehicle device by the first in-vehicle device includes: transmitting, by the first in-vehicle device, the second ciphertext packet to the second in-vehicle device; The method of claim 1.

3. in the second ciphertext packet, the order is such that the first ciphertext packet precedes the message authentication code, and the message authentication code precedes the first fresh value; The method of claim 2.

4. The method comprises: performing, by the first in-vehicle device, an operation utilizing a second key, the first plaintext packet, and the first freshness value to generate a message authentication code, the message authentication code being utilized by the second in-vehicle device to perform an integrity check on the first plaintext packet; ordering, by the first in-vehicle device, the first ciphertext packet, the message authentication code, and the first freshness value to obtain a second ciphertext packet; Further comprising: The step of transmitting the first ciphertext packet to a second in-vehicle device by the first in-vehicle device includes: transmitting, by the first in-vehicle device, the second ciphertext packet to the second in-vehicle device; The method of claim 1.

5. performing, by the first in-vehicle device, an exclusive-OR operation utilizing the key stream and the first plaintext packet to generate a first ciphertext packet, performing, by the first in-vehicle device, an operation utilizing a second key and the first plaintext packet to generate a message authentication code, the message authentication code being used by the second in-vehicle device to perform an integrity check on the first plaintext packet; ordering, by the first in-vehicle device, the first plaintext packet and the message authentication code to obtain a second plaintext packet; performing, by the first in-vehicle device, an exclusive-OR operation utilizing the keystream and the second plaintext packet to generate the first ciphertext packet; Including, The method of claim 1.

6. The method comprises: and performing, by the first in-vehicle device, a calculation using a key derivation algorithm that utilizes a shared key and second pre-configured parameters to generate the second key, the shared key being a key shared by the first in-vehicle device and the second in-vehicle device. The method according to any one of claims 2 to 5.

7. The method comprises: The method further includes the step of transmitting, by the first in-vehicle device, indication information to the second in-vehicle device, the indication information being: the first in-vehicle device performing integrity protection on the first plaintext packet; or the first in-vehicle device performing integrity protection and encryption protection on the first plaintext packet; is used to indicate one of The method according to any one of claims 1 to 6.

8. 1. A communication method comprising: acquiring, by a second in-vehicle device, a first ciphertext packet and a first freshness value, the second in-vehicle device being an electronic control unit (ECU), the first ciphertext packet coming from the first in-vehicle device being another ECU, the first freshness value being a value generated by a counter in the first in-vehicle device when the first in-vehicle device sends a packet over an in-vehicle network, the counter being configured to record a quantity of packets sent by the first in-vehicle device; performing, by the second in-vehicle device, an operation utilizing a key derivation algorithm to generate a first key utilizing a shared key and a first pre-configured parameter, the shared key being a key shared between the first in-vehicle device and the second in-vehicle device, the first pre-configured parameter and the key derivation algorithm being pre-agreed upon by the first in-vehicle device and the second in-vehicle device, the first pre-configured parameter being an algorithm type identifier indicating that the key derivation algorithm is an algorithm for encryption or indicating that the first key is to be used to encrypt a first plaintext packet; performing, by the second in-vehicle device, an operation utilizing the first key and the first freshness value to generate a keystream; performing, by the second in-vehicle device, an exclusive-OR operation utilizing the keystream and the first ciphertext packet to obtain the first plaintext packet; A method comprising:

9. The step of obtaining the first ciphertext packet and the first freshness value by the second in-vehicle device includes: receiving, by the second in-vehicle device, a second ciphertext packet from the first in-vehicle device, the second ciphertext packet being obtained by ordering the first ciphertext packet, a message authentication code, and the first freshness value; obtaining, by the second in-vehicle device, the first ciphertext packet and the first freshness value from the second ciphertext packet; Including, Prior to the step of performing, by the second in-vehicle device, an operation utilizing a first key and the first fresh value to generate a key stream, the method further comprises: obtaining, by the second in-vehicle device, the message authentication code from the second ciphertext packet; when determining that the first freshness value is greater than the second freshness value, performing, by the second in-vehicle device, an operation utilizing a second key, the first ciphertext packet, and the first freshness value to generate a new message authentication code, the second freshness value being a freshness value stored locally by the second in-vehicle device when it receives the second ciphertext packet; determining, by the second in-vehicle device, that the new message authentication code matches the obtained message authentication code; Further comprising: The method according to claim 8.

10. in the second ciphertext packet, the order is such that the first ciphertext packet precedes the message authentication code, and the message authentication code precedes the first fresh value; 10. The method of claim 9.

11. The step of obtaining the first ciphertext packet and the first freshness value by the second in-vehicle device includes: receiving, by the second in-vehicle device, a second ciphertext packet from the first in-vehicle device, the second ciphertext packet being obtained by ordering the first ciphertext packet, a message authentication code, and the first freshness value; obtaining, by the second in-vehicle device, the first ciphertext packet, the message authentication code, and the first freshness value from the second ciphertext packet; Including, Prior to the step of performing, by the second in-vehicle device, an operation utilizing a first key and the first fresh value to generate a key stream, the method further comprises: when determining that the first freshness value is greater than a second freshness value, performing, by the second in-vehicle device, an operation utilizing a second key, the first plaintext packet, and the first freshness value to generate a new message authentication code, the second freshness value being a freshness value stored locally by the second in-vehicle device when it receives the second ciphertext packet; determining, by the second in-vehicle device, that the new message authentication code matches the obtained message authentication code; Further comprising: The method according to claim 8.

12. The step of obtaining the first ciphertext packet and the first freshness value by the second in-vehicle device includes: receiving, by the second in-vehicle device, the first ciphertext packet and the first freshness value from the first in-vehicle device; performing, by the second in-vehicle device, an exclusive-OR operation utilizing the key stream and the first ciphertext packet to obtain a first plaintext packet, performing, by the second in-vehicle device, an exclusive-OR operation utilizing the keystream and the first ciphertext packet to obtain a second plaintext packet, the second plaintext packet being obtained by sequencing the first plaintext packet and a message authentication code; obtaining, by the second in-vehicle device, the first plaintext packet and the message authentication code from the second plaintext packet; Including, The method comprises: performing, by the second in-vehicle device, an operation utilizing a second key, the first plaintext packet, and the first freshness value to generate a new message authentication code; determining, by the second in-vehicle device, that the first plaintext packet is complete if the new message authentication code matches the obtained message authentication code; Further comprising: The method according to claim 8.

13. The method comprises: and performing, by the second in-vehicle device, a key derivation algorithm to generate the second key using a shared key and second pre-configured parameters, the shared key being a key shared by the first in-vehicle device and the second in-vehicle device. The method according to any one of claims 9 to 12.

14. The method comprises: and receiving, by the second in-vehicle device, indication information from the first in-vehicle device, the indication information being used to indicate that the first in-vehicle device performs integrity protection on the first plaintext packet, or the indication information being used to indicate that the first in-vehicle device performs integrity protection and encryption protection on the first plaintext packet.

13. The method according to claim 11 or 12.

15. An apparatus comprising the first in-vehicle device configured to perform the steps of the method according to any one of claims 1 to 7.

16. An apparatus comprising the second in-vehicle device configured to perform the steps of the method according to any one of claims 8 to 14.

17. A computer readable storage medium containing a program, which, when executed by a processor, performs the method according to any one of claims 1 to 7.

18. A computer readable storage medium containing a program, which, when executed by a processor, performs the method according to any one of claims 8 to 14.

19. A first in-vehicle device comprising at least one processor and at least one memory, the first in-vehicle device being an electronic control unit (ECU), the at least one memory being configured to store program instructions, the at least one processor being coupled to the at least one memory and executing the instructions to: performing an operation using a key derivation algorithm that uses a shared key and a first pre-configured parameter to generate a first key, the shared key being a key shared between the first in-vehicle device and a second in-vehicle device, the first pre-configured parameter and the key derivation algorithm being pre-agreed upon by the first in-vehicle device and the second in-vehicle device, the first pre-configured parameter being an algorithm type identifier indicating that the key derivation algorithm is an algorithm for encryption or indicating that the first key is used to encrypt a first plaintext packet, and the second in-vehicle device being another ECU; performing an operation utilizing the first key and a first freshness value to generate a keystream, the first freshness value being a value generated by a counter in the first in-vehicle device as the first in-vehicle device transmits packets over an in-vehicle network, the counter being configured to record a quantity of packets transmitted by the first in-vehicle device; performing an exclusive-OR operation utilizing the keystream and the first plaintext packet to generate a first ciphertext packet; transmitting the first ciphertext packet to a second in-vehicle device; A first in-vehicle device.

20. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, performing an operation utilizing a second key, the first ciphertext packet, and the first freshness value to generate a message authentication code, the message authentication code being utilized by the second in-vehicle device to perform an integrity check on the first plaintext packet; arranging the first ciphertext packet, the message authentication code, and the first fresh value to obtain a second ciphertext packet; transmitting the second ciphertext packet to the second in-vehicle device; 20. A first in-vehicle device as claimed in claim 19.

21. In the second ciphertext packet, the first ciphertext packet precedes the message authentication code, and the message authentication code precedes the first fresh value. The first in-vehicle device of claim 20.

22. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, performing an operation utilizing a second key, the first plaintext packet, and the first freshness value to generate a message authentication code, the message authentication code being utilized by the second in-vehicle device to perform an integrity check on the first plaintext packet; arranging the first ciphertext packet, the message authentication code, and the first fresh value to obtain a second ciphertext packet; transmitting the second ciphertext packet to the second in-vehicle device; 20. A first in-vehicle device as claimed in claim 19.

23. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, performing an operation utilizing a second key and the first plaintext packet to generate a message authentication code, the message authentication code being utilized by the second in-vehicle device to perform an integrity check on the first plaintext packet; aligning the first plaintext packet and the message authentication code to obtain a second plaintext packet; performing an exclusive-OR operation utilizing the keystream and the second plaintext packet to generate the first ciphertext packet; 20. A first in-vehicle device as claimed in claim 19.

24. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, Utilizing a key derivation algorithm, perform an operation utilizing a shared key and second pre-configured parameters to generate the second key, the shared key being a key shared by the first in-vehicle device and the second in-vehicle device. The first in-vehicle device of claim 20.

25. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, Sending indication information to the second in-vehicle device, the indication information comprising the following content: the first in-vehicle device performing integrity protection on the first plaintext packet; or the first in-vehicle device performing integrity protection and encryption protection on the first plaintext packet; is used to indicate any one of the following:

20. A first in-vehicle device as claimed in claim 19.

26. A second in-vehicle device comprising at least one processor and at least one memory, the second in-vehicle device being an electronic control unit (ECU), the at least one memory being configured to store program instructions, the at least one processor being coupled to the at least one memory and executing the instructions to: obtaining a first ciphertext packet and a first freshness value, the first ciphertext packet coming from a first in-vehicle device, the first in-vehicle device being another ECU, the first freshness value being a value generated by a counter in the first in-vehicle device when the first in-vehicle device transmits a packet over an in-vehicle network, the counter being configured to record a quantity of packets transmitted by the first in-vehicle device; performing an operation utilizing a shared key and a first pre-configured parameter utilizing a key derivation algorithm to generate a first key, the shared key being a key shared between the first in-vehicle device and a second in-vehicle device, the first pre-configured parameter and the key derivation algorithm being pre-agreed upon by the first in-vehicle device and the second in-vehicle device, the first pre-configured parameter being an algorithm type identifier indicating that the key derivation algorithm is an algorithm for encryption or indicating that the first key is to be used to encrypt a first plaintext packet; performing an operation utilizing the first key and the first fresh value to generate a keystream; performing an exclusive-OR operation utilizing the keystream and the first ciphertext packet to obtain the first plaintext packet. A second in-vehicle device.

27. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, receiving a second ciphertext packet from the first in-vehicle device, the second ciphertext packet being obtained by arranging the first ciphertext packet, a message authentication code, and the first freshness value; obtaining the first ciphertext packet and the first fresh value from the second ciphertext packet; obtaining the message authentication code from the second ciphertext packet; when determining that the first fresh value is greater than a second fresh value, performing an operation utilizing a second key, the first ciphertext packet, and the first fresh value to generate a new message authentication code, the second fresh value being a fresh value stored locally at the second in-vehicle device when it receives the second ciphertext packet; determining that the new message authentication code matches the obtained message authentication code; 27. A second in-vehicle device as claimed in claim 26.

28. In the second ciphertext packet, the first ciphertext packet precedes the message authentication code, and the message authentication code precedes the first fresh value.

28. A second in-vehicle device as claimed in claim 27.

29. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, receiving a second ciphertext packet from the first in-vehicle device, the second ciphertext packet being obtained by arranging the first ciphertext packet, a message authentication code, and the first freshness value; obtaining the first ciphertext packet, the message authentication code, and the first freshness value from the second ciphertext packet; when determining that the first fresh value is greater than a second fresh value, performing an operation utilizing a second key, the first plaintext packet, and the first fresh value to generate a new message authentication code, the second fresh value being a fresh value stored locally at the second in-vehicle device when it receives the second ciphertext packet; determining that the new message authentication code matches the obtained message authentication code; 27. A second in-vehicle device as claimed in claim 26.

30. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, receiving the first ciphertext packet and the first freshness value from the first in-vehicle device; performing an exclusive-OR operation utilizing the keystream and the first ciphertext packet to obtain a second plaintext packet, the second plaintext packet being obtained by aligning the first plaintext packet with a message authentication code; obtaining the first plaintext packet and the message authentication code from the second plaintext packet; performing an operation utilizing a second key, the first plaintext packet, and the first freshness value to generate a new message authentication code; determining that the first plaintext packet is intact if the new message authentication code matches the obtained message authentication code; 27. A second in-vehicle device as claimed in claim 26.

31. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, Utilizing a key derivation algorithm, perform an operation utilizing a shared key and second pre-configured parameters to generate the second key, the shared key being a key shared by the first in-vehicle device and the second in-vehicle device.

28. A second in-vehicle device as claimed in claim 27.

32. The at least one processor is coupled to the at least one memory and is operable to execute the instructions, receiving indication information from the first in-vehicle device, the indication information being utilized to indicate that the first in-vehicle device performs integrity protection on the first plaintext packet, or the indication information being utilized to indicate that the first in-vehicle device performs integrity protection and encryption protection on the first plaintext packet; 27. A second in-vehicle device as claimed in claim 26.

33. A communication system comprising a first in-vehicle device according to any one of claims 19 to 25 and a second in-vehicle device according to any one of claims 26 to 32.

Images