A method and system for preventing replay attacks on a remote keyless entry system
By employing a four-fold protection mechanism—random number challenge-response, timestamp verification, hardware feature verification, and replay cache detection—combined with a symmetric encryption algorithm, the problem of traditional remote keys being vulnerable to replay attacks has been solved, achieving high-strength protection and low-power compatibility, thus improving the security of automotive electronics.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- C&C TRUCKS
- Filing Date
- 2026-03-16
- Publication Date
- 2026-06-19
AI Technical Summary
Traditional remote key communication methods are vulnerable to replay attacks. Existing protection solutions are susceptible to clock drift and lack hardware-level uniqueness verification. Attackers can launch attacks by cloning remote keys.
It employs a four-fold protection mechanism of random number challenge-response, timestamp verification, hardware feature verification, and replay buffer detection, combined with a symmetric encryption algorithm, to achieve high-strength protection for remote control commands while reducing the computational overhead of embedded software.
It achieves high-strength anti-replay attack capabilities, improving anti-attack capabilities by more than 3 times. It is compatible with existing automotive BCM/PEPS controllers, reducing the modification costs for car manufacturers, ensuring real-time communication and low power consumption, and improving the vehicle's anti-theft level.
Smart Images
Figure CN122247675A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of automotive electronic anti-theft technology. Specifically, this invention relates to a method and system for preventing replay attacks on remote control keys. Background Technology
[0002] Traditional remote control keys mostly use fixed code or linear rolling code communication methods. These methods have obvious security vulnerabilities: attackers can intercept the device through radio frequency signals, capture the communication messages between the remote control key and the vehicle controller, and then illegally unlock the car door or start the vehicle by simply replaying the intercepted legitimate messages to the vehicle controller, seriously threatening the safety of the vehicle and the property inside.
[0003] To address the aforementioned issues, existing technologies have proposed several improvements, such as employing a single timestamp verification mechanism or a rolling code synchronization mechanism. However, these are susceptible to clock drift. If the clock deviation between the remote key and the vehicle controller exceeds a threshold, legitimate commands may be mistakenly deemed invalid. Furthermore, if the initial synchronization code of the rolling code synchronization mechanism is intercepted, attackers can analyze the generation pattern of the rolling code to forge legitimate messages and launch attacks.
[0004] Furthermore, most existing solutions do not incorporate hardware-level uniqueness verification. Attackers can bypass software-level verification mechanisms by cloning the software information of the remote control key to generate a cloned key with the same function. Summary of the Invention
[0005] This invention aims to overcome the shortcomings of the prior art and proposes a method and system for preventing replay attacks on remote control keys, so as to achieve the following objectives: to realize high-strength protection of remote control commands, while reducing the computational overhead of embedded software and ensuring real-time communication.
[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: a method for preventing replay attacks on remote control keys, the method comprising the following steps:
[0007] Step S1: The vehicle controller generates a first random number Rand_1 and starts a timestamp timer; the user wakes up the remote key, and then the remote key sends a session request frame to the vehicle controller;
[0008] Step S2: The vehicle controller performs frame verification on the session request frame. If the verification passes, it reads the current timestamp T_1 and generates a challenge frame; otherwise, it discards the session request frame and triggers an abnormal alarm.
[0009] Step S3: After the remote key receives the challenge frame and completes the frame verification, it generates a response frame and encrypts it based on the second random number Rand_2;
[0010] Step S4: After receiving the response frame and completing the frame verification, the vehicle controller performs multiple verifications, including timestamp verification, hardware feature verification, decryption verification, and replay buffer verification. If any verification fails, the message is immediately discarded and an abnormal alarm is triggered.
[0011] Step S5: After all verifications pass, the vehicle controller drives the actuator to move according to the function instruction Cmd' decrypted from the response frame, and sends a successful instruction execution feedback frame to the remote key; at the same time, the vehicle controller generates a new third random number Rand_3 to replace the locally stored first random number Rand_1, completes the current session update, and waits for the next session request.
[0012] Step S6: After receiving the success feedback frame, the remote key clears the Rand_1, Rand_2 and T_1 data of this session and immediately enters low-power sleep mode; if the success feedback frame is not received, it will automatically go into sleep mode after timeout and will not resend the message.
[0013] Preferably, the frame verification includes frame header and frame tail verification. The frame header and frame tail verification includes: if the frame header of the current frame is consistent with the preset fixed value of the frame header and the CRC8 verification of the frame tail passes, then the frame header and frame tail verification is determined to be successful; otherwise, the session request frame is discarded and an abnormal alarm is triggered.
[0014] Preferably, the session request frame includes a frame header, a key unique identifier ID_key, and a frame trailer.
[0015] Preferably, in step S2, the frame verification of the session request frame by the vehicle controller further includes:
[0016] The vehicle controller queries its own stored list of valid ID_keys. If the ID_key in the session request frame is not in the list, the session request frame is discarded and an abnormal alarm is triggered; otherwise, the current timestamp T_1 is read and a challenge frame is generated. Preferably, the challenge frame includes a frame header, a first random number Rand_1, a timestamp T_1, and a frame trailer.
[0017] Preferably, the response frame includes a frame header, a second random number Rand_2, an encrypted message Msg_encrypt, a hardware signature code F_hard, and a frame tail.
[0018] Preferably, the encrypted message Msg_encrypt is obtained by encrypting the second random number Rand_2. The encryption process includes: after generating the second random number Rand_2, using the pre-stored shared key K_shared as the key, the first random number Rand_1, the second random number Rand_2, the timestamp T_1 and the current function instruction Cmd are grouped and encrypted, and the encrypted message Msg_encrypt is obtained after encryption.
[0019] Preferably, in step S4, the multiple verifications include timestamp verification, hardware feature verification, decryption verification, and replay buffer verification performed sequentially, as follows:
[0020] Step S41, Timestamp Verification: Read the current timestamp T_2 and calculate the time difference ΔT = |T_2-T_1|; if the time difference ΔT is greater than the preset time threshold T_max, it is determined to be an overdue message, regarded as a replay attack risk message, the message is immediately discarded, and an abnormal alarm is triggered; otherwise, continue to the next step.
[0021] Step S42, Hardware Feature Verification: Extract the hardware feature code F_hard from the response frame and compare it bit by bit with the hardware feature code F_hard corresponding to the pre-stored current key ID_key; if the comparison does not match, it is determined to be an attack message initiated by a cloned key, the message is immediately discarded, and an abnormal alarm is triggered; otherwise, continue to the next step.
[0022] Step S43, Decryption Verification: Decrypt the encrypted message Msg_encrypt using the shared key K_shared to obtain the decrypted first random number Rand_1', second random number Rand_2', timestamp T_1', and function command Cmd'; verify whether Rand_1' is consistent with the locally stored Rand_1 and whether T_1' is consistent with T_1 in the challenge frame; if they are consistent, the message is deemed valid and the next step is continued; if they are inconsistent, the message is deemed to have been tampered with, the message is immediately discarded, and an abnormal alarm is triggered.
[0023] Step S44, Replay Cache Verification: The vehicle controller is configured with a replay detection cache, which stores the second random number Rand_2 of the most recent sessions with the same ID_key; the second random number Rand_2 in the current response frame is compared with the data in the cache. If a match is found, it is determined to be a replay attack packet, the packet is immediately discarded, and an abnormal alarm is triggered; if no match is found, the second random number Rand_2 in the current response frame is written into the cache, overwriting the oldest historical data.
[0024] Preferably, the operations performed after the abnormal alarm is triggered include:
[0025] Record the attack time, ID_key, and message characteristics;
[0026] Limit the frequency of session requests for this ID_key to no more than the first frequency within a preset time period;
[0027] If the number of attacks detected within a preset time exceeds the preset number, the ID_key will be temporarily disabled, and the user will need to verify the key via the vehicle's physical key to unlock it.
[0028] This invention provides a remote key anti-replay attack system, using the aforementioned remote key anti-replay attack method, the system comprising:
[0029] The remote control key includes a first core processing module, a wake-up module, a communication module, a random number generation module, an encryption module, and a storage module; the first core processing module is connected to the wake-up module, the communication module, the random number generation module, the encryption module, and the storage module respectively.
[0030] The vehicle-mounted controller includes a second core processing module, a session management module, an authentication module, a decryption and verification module, an instruction execution module, an anomaly alarm module, and a secure storage module; the second core processing module is connected to the session management module, the authentication module, the decryption and verification module, the instruction execution module, the anomaly alarm module, and the secure storage module, respectively.
[0031] The first core processing module communicates with the second core processing module through the communication module.
[0032] The technical effects of this invention are as follows:
[0033] 1. High protection strength: It adopts a four-fold protection mechanism of random number challenge-response, timestamp verification, hardware feature verification and replay cache detection. It prevents replay attacks from four dimensions: message content, time window, hardware uniqueness and historical messages. Attackers cannot launch effective attacks by intercepting or cloning messages. Compared with the existing single protection solution, the anti-attack capability is improved by more than 3 times.
[0034] 2. Strong engineering compatibility: The software module can be directly integrated into the embedded architecture of existing automotive BCM / PEPS controllers without adding new hardware. Only the secure storage area and AES-128 encryption / decryption algorithm function library need to be expanded. It is compatible with mainstream automotive MCUs such as Infineon TC3xx and Renesas RH850, reducing the technical transformation costs for car manufacturers.
[0035] 3. Balancing real-time performance and low power consumption: Employing a lightweight AES-128 hardware encryption algorithm, the encryption / decryption operation time is less than 1ms, meeting the real-time communication requirements between the remote key and the vehicle controller with no significant operation delay; the remote key enters a low-power sleep mode when not in use, extending battery life by 20% compared to traditional solutions;
[0036] 4. Intelligent anomaly handling: The anomaly alarm module can record attack events and dynamically limit the frequency of session requests to prevent illegal messages from occupying communication bandwidth. At the same time, it further enhances the vehicle's anti-theft level through a temporary disabling mechanism, meeting the high reliability requirements of automotive electronic security. Attached Figure Description
[0037] Figure 1 A flowchart of a method for preventing replay attacks on remote control keys provided in an embodiment of the present invention;
[0038] Figure 2 A flowchart of the multiple verification method provided in the embodiments of the present invention. Detailed Implementation
[0039] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. This is to help those skilled in the art to have a more complete, accurate, and in-depth understanding of the inventive concept and technical solutions of the present invention, and to facilitate its implementation. It should be noted that the terms "first," "second," etc., used in this application are only for the convenience of describing the technical solutions and to distinguish components; the corresponding component configurations may be the same or different, and are not intended to limit the scope of this application. To make the technical solutions of the present invention clearer, the present invention will be explained and illustrated through the following embodiments.
[0040] Currently, the automotive electronics field has placed higher demands on the security of remote control keys. They not only require strong anti-replay attack capabilities but also need to meet the engineering application requirements of low computational overhead, high real-time performance, and strong compatibility with existing hardware in embedded systems. To address this, this invention provides a method for preventing replay attacks on remote control keys. Through a four-layer protection mechanism—random number challenge-response, timestamp verification, hardware feature verification, and replay buffer detection—combined with a symmetric encryption algorithm, it achieves high-strength protection for remote control commands while reducing the computational overhead of embedded software and ensuring real-time communication.
[0041] The embodiments of the present invention are implemented as follows:
[0042] A method for preventing replay attacks on remote control keys, such as Figure 1 As shown, the method includes the following steps:
[0043] Step S1: The vehicle controller generates a first random number Rand_1 and starts a timestamp timer; the user wakes up the remote key, and then the remote key sends a session request frame to the vehicle controller;
[0044] Step S2: The vehicle controller performs frame verification on the session request frame. If the verification passes, it reads the current timestamp T_1 and generates a challenge frame; otherwise, it discards the session request frame and triggers an abnormal alarm.
[0045] Step S3: After the remote key receives the challenge frame and completes the frame verification, it generates a response frame and encrypts it based on the second random number Rand_2;
[0046] Step S4: After receiving the response frame and completing the frame verification, the vehicle controller performs multiple verifications, including timestamp verification, hardware feature verification, decryption verification, and replay buffer verification. If any verification fails, the message is immediately discarded and an abnormal alarm is triggered.
[0047] Step S5: After all verifications pass, the vehicle controller drives the actuator to move according to the function instruction Cmd' decrypted from the response frame, and sends a successful instruction execution feedback frame to the remote key; at the same time, the vehicle controller generates a new third random number Rand_3 to replace the locally stored first random number Rand_1, completes the current session update, and waits for the next session request.
[0048] Step S6: After receiving the success feedback frame, the remote key clears the Rand_1, Rand_2 and T_1 data of this session and immediately enters low-power sleep mode; if the success feedback frame is not received, it will automatically go into sleep mode after timeout and will not resend the message.
[0049] Specifically, refer to step S1. Step S1 aims to initialize the session, which is the starting point of the entire anti-replay communication process. Its core purpose is to prepare the vehicle controller and remote key for the initial state, laying a secure foundation for subsequent challenge-response interactions, while eliminating invalid communication requests and reducing system resource consumption. After the vehicle controller is powered on, it completes a self-test to check for hardware faults, communication anomalies, and other issues. It then automatically generates a first random number Rand_1 (32-bit) and stores it in a secure RAM area to prevent it from being stolen through physical or software attacks such as memory scanning or bus snooping, thus ensuring the confidentiality of the first random number. At the same time, the vehicle controller starts a high-precision timestamp timer to add a precise timestamp to each session, providing an objective and tamper-proof reference for subsequent message verification. The counter is initially 0 and increments by 1 every 1ms. The 1ms precision ensures that each message can obtain a unique timestamp, and even continuous communication within a very short period of time can be accurately distinguished by the timestamp, without putting excessive computational pressure on the vehicle controller. When a user presses a function key (unlock / lock / open trunk) on the remote key, the remote key is woken up from low-power sleep mode. Subsequently, the remote key sends a session request frame to the vehicle controller.
[0050] In this embodiment, the designed session request frame includes a frame header, a key unique identifier ID_key, and a frame trailer. The ID_key is the unique identifier of the remote key, equivalent to the key's identity credential. Its core function is to allow the vehicle controller to quickly identify the legitimacy of the requester and exclude requests from unauthorized keys. The generated session request frame is sent by the remote key to the vehicle controller, aiming to establish a session between the remote key and the vehicle controller, laying a fresh, reliable, and efficient foundation for all subsequent secure interactions. The frame format definition of the session request frame in this embodiment is shown in Table 1 (unit: bytes):
[0051] Frame header ID_key End-of-frame check 2 8 1
[0052] Table 1
[0053] It should be noted that in this embodiment, the session request frame, challenge frame, and response frame all adopt the same frame header and frame trailer design. The frame header is designed with a fixed value (e.g., 0xAA55) and pre-stored in the remote key or vehicle controller for subsequent verification. A fixed frame header simplifies the message parsing logic of the vehicle controller or remote key; the controller only needs to check if the beginning of the received data is the preset fixed value to quickly determine its integrity, improving message parsing efficiency. Simultaneously, a fixed frame header can filter out most invalid data (such as noise signals generated by environmental interference), reducing system resource consumption. The frame trailer uses a CRC8 checksum to ensure frame data integrity. The CRC8 checksum at the frame trailer is a technique used to detect errors during data transmission or storage. Its core principle is as follows: the sender performs a specific polynomial division operation on the original data (information bits) to be sent, and appends the remainder (i.e., the CRC checksum) to the end of the original data frame. After receiving the data, the receiver performs the same polynomial division operation on the complete data frame (containing information bits and the checksum). If the remainder is zero, it is assumed that the data was transmitted with a very high probability that there were no errors; if the remainder is not zero, it is concluded that there are errors in the data.
[0054] Based on the above design, in this embodiment, the frame verification process initiated by the remote key or vehicle controller after receiving a message includes frame header and frame trailer verification. The frame header and frame trailer verification includes: if the frame header of the current frame is consistent with the preset fixed value of the frame header and the CRC8 check of the frame trailer passes, then the frame header and frame trailer verification is deemed successful; otherwise, the session request frame is discarded and an abnormal alarm is triggered. In this embodiment, the frame header and frame trailer verification process is placed as the first execution step in each frame verification process, thereby first confirming that the frame data has not been tampered with.
[0055] Referring to step S2, after receiving the session request frame sent by the remote key, the vehicle controller first performs frame verification on the session request frame. If the verification passes, it reads the current timestamp T_1 and generates a challenge frame; otherwise, it discards the session request frame and triggers an abnormal alarm.
[0056] In the frame verification process of the session request frame by the vehicle controller, after the initial frame header and frame trailer verification is completed, the ID_key in the session request frame is also verified. The specific verification method is as follows:
[0057] The vehicle controller queries its stored list of valid ID_keys. If the ID_key in the session request frame is not in the list, the session request frame is discarded and an anomaly alarm is triggered. This prevents any system information (such as whether a message was received, the reason for verification failure, etc.) from being leaked to unauthorized keys, and prevents attackers from observing the controller's response behavior to obtain the system's working logic (such as verification order, timeout time, etc.) and thus formulate targeted attack strategies. If the ID_key in the session request frame is in the list, it means the key is valid, and the current timestamp T_1 is read and a challenge frame is generated. The ID_key is a declaration of the remote key's identity. After receiving this frame, the vehicle controller verifies it by querying the list of valid keys. This is a very low-cost filtering operation. If the ID_key is invalid, the vehicle controller will immediately terminate the session without performing any time-consuming cryptographic operations, effectively resisting massive identity probing or blind attacks, acting as the first line of defense.
[0058] In this embodiment, the designed challenge frame includes a frame header, a first random number Rand_1, a timestamp T_1, and a frame trailer. The corresponding frame format definitions are shown in Table 2 (unit: bytes):
[0059] Frame header Rand_1 T_1 End-of-frame check 2 4 4 1
[0060] Table 2
[0061] The first random number, Rand_1, serves as the core of the challenge, triggering the remote key to generate the corresponding response information. The timestamp, T_1, acts as a time identifier for subsequent timestamp verification. The timestamp T_1 is the time identifier for this challenge-response session, its core function being to link with the time information in subsequent response frames to achieve timestamp verification and defend against delayed replay attacks. Reading the current timestamp T_1 and writing it into the challenge frame ensures that each challenge frame contains unique time information. Even with consecutive requests from the same key, the timestamp T_1 will differ every 1ms increment, ensuring that each challenge frame is unique and cannot be reused. Simultaneously, the timestamp T_1 and the first random number, Rand_1, together constitute the challenge information. This dual random / unique identifier further enhances the non-replicability of the challenge frame: Rand_1 is a truly random number and unpredictable; T_1 is a unique timestamp and cannot be repeated. The combination of these two ensures that each challenge frame is unique, preventing attackers from forging identical challenge frames for subsequent attacks even if they intercept them.
[0062] Referring to step S3, after the remote key receives the challenge frame and completes frame verification, it generates a response frame and encrypts it based on the second random number Rand_2. In this embodiment, the designed response frame includes a frame header, the second random number Rand_2, the encrypted message Msg_encrypt, the hardware signature code F_hard, and a frame trailer. The corresponding frame format definitions are shown in Table 3 (unit: bytes):
[0063] Frame header Rand_2 Msg_encrypt F_hard End-of-frame check 2 4 16 8 1
[0064] Table 3
[0065] Rand_2 (32-bit) is the second random number generated by the remote key. Its function complements that of the first random number Rand_1, together constructing a dynamic challenge-response mechanism. Rand_2 has two core functions: first, it serves as the core identifier of the response frame, used for subsequent replay buffer verification by the vehicle controller; second, it works with the first random number Rand_1, the timestamp T_1, and the function command Cmd to participate in encryption, increasing the complexity of the encrypted message, improving encryption strength, and preventing attackers from obtaining sensitive information by cracking the encrypted message.
[0066] Specifically, in this embodiment, the encrypted message Msg_encrypt is obtained by encrypting the second random number Rand_2. The encryption process includes: after generating the second random number Rand_2, using the pre-stored shared key K_shared as the key, the first random number Rand_1, the second random number Rand_2, the timestamp T_1, and the current function instruction Cmd (8 bits, such as 0x01 for unlocking and 0x02 for locking) are encrypted in blocks. The length of the encrypted block is 128 bits, and the padding method is PKCS7. After encryption, the encrypted message Msg_encrypt is obtained. The encryption algorithm uses the AES-128 algorithm. AES-128 is a symmetric encryption algorithm with a key length of 128 bits, which is extremely difficult to crack. At the same time, it has high encryption and decryption efficiency and can complete the encryption operation in a very short time (millisecond level). The core information of this session consists of four items: the first random number Rand_1, the second random number Rand_2, the timestamp T_1, and the current function command Cmd. Encryption ensures that this information cannot be intercepted or tampered with by attackers. Rand_1 and T_1 come from the challenge frame and are used for subsequent decryption verification by the vehicle controller; Rand_2 is the random number generated by the key and is used for replay cache verification; and Cmd is the user's function command, used by the vehicle controller to perform the corresponding operation. If this information is not encrypted, an attacker could intercept it and directly forge a response frame to achieve a replay attack.
[0067] The hardware signature code F_hard is the hardware signature code of the remote key. Its core function is to bind the hardware identity of the key, preventing attackers from cloning the key (such as copying ID_key and K_shared to forge a remote key). F_hard is a unique identifier for the key hardware, generated by hash calculation from the inherent information of the key's MCU chip and other hardware (such as chip serial number, hardware version number, etc.). It cannot be modified or copied, and it corresponds one-to-one with ID_key, pre-stored in the vehicle controller. Writing F_hard into the response frame allows the vehicle controller to verify the hardware legitimacy of the key by comparing F_hard, thus blocking key cloning attacks.
[0068] After sending a response frame, the remote key enters a waiting-for-feedback state. The core purpose is to receive successful instruction execution feedback from the vehicle controller, confirming the completion of the session and avoiding duplicate message transmissions. This embodiment also includes a timeout period; after the feedback timeout, the remote key automatically goes into sleep mode. In this embodiment, the timeout period is set to 500ms. Under normal circumstances, the time for the vehicle controller to receive the response frame, complete verification, and send a feedback frame does not exceed 200ms. Setting a 500ms timeout provides sufficient buffer time to avoid misjudgments due to communication delays (such as duplicate message transmissions due to failure to receive feedback frames in time). Simultaneously, the 500ms timeout also prevents the key from remaining in a waiting state for extended periods; that is, automatic sleep after the timeout reduces the key's power consumption.
[0069] Referring to step S4 of this embodiment, after the vehicle controller receives the response frame and completes frame verification, it also performs multiple verifications, including timestamp verification, hardware feature verification, decryption verification, and replay buffer verification. If any verification fails, the message is immediately discarded, and an abnormal alarm is triggered. Multiple verifications are a key step in preventing replay attacks. Their core purpose is to perform comprehensive verification of the response frames sent by the remote key, eliminating various attack messages such as tampering, replay, and cloning, and ensuring that only legitimate response frames can trigger subsequent command execution.
[0070] Specifically, such as Figure 2 As shown, the multi-factor verification in this embodiment includes timestamp verification, hardware feature verification, decryption verification, and replay cache verification, which are performed sequentially. The specific process is as follows:
[0071] Step S41, Timestamp Verification: Read the current timestamp T_2 and calculate the time difference ΔT = |T_2-T_1|, which represents the total time from the challenge frame to the response frame. If the time difference ΔT is greater than the preset time threshold T_max, it is determined to be an overdue message, considered a replay attack risk message, immediately discarded, and an abnormal alarm is triggered; otherwise, continue to the next step. In this embodiment, the time threshold T_max is set to 200ms (which can be adjusted according to the vehicle-mounted radio frequency communication distance; generally, 200ms can cover 99% of legitimate communication scenarios). It should be noted that if the threshold is set too small (e.g., 100ms), some legitimate communications may be misjudged as attack messages due to slight delays, affecting user experience; if the threshold is set too large (e.g., 500ms), it will give attackers ample time to intercept the challenge and response frames, delay the transmission of the response frame to achieve a replay attack, and reduce the protection effect.
[0072] The core method of an attacker's delayed replay attack is to intercept legitimate challenge and response frames, delay sending the response frame for a period of time, and deceive the vehicle controller into performing an operation. The core logic of the timestamp verification is that the time window for each session is unique. Response frames exceeding 200ms are highly likely to be replay messages delayed by the attacker, and are therefore directly identified as attack messages, discarded, and trigger an anomaly alarm. Step S42, Hardware Feature Verification: Extract the hardware feature code F_hard from the response frame and compare it bit by bit with the hardware feature code F_hard corresponding to the pre-stored current key ID_key. If the comparison does not match, it is determined to be an attack message initiated by a cloned key, the message is immediately discarded, and an anomaly alarm is triggered; otherwise, continue to the next step.
[0073] When an attacker clones a key, they can typically only copy the ID_key and K_shared, but not the key's hardware characteristics (F_hard is generated from the key's inherent hardware information, is bound to the hardware, and cannot be modified or copied). Therefore, by comparing F_hard, legitimate keys and cloned keys can be accurately distinguished. If the F_hard of a cloned key does not match the F_hard pre-stored in the HSM, it will be identified as an attack message, thus blocking the attack using cloned keys.
[0074] Step S43, Decryption Verification: Decrypt the encrypted message Msg_encrypt using the shared key K_shared to obtain the decrypted first random number Rand_1', second random number Rand_2', timestamp T_1', and function command Cmd'; verify whether Rand_1' is consistent with the locally stored Rand_1 and whether T_1' is consistent with T_1 in the challenge frame; if they are consistent, the message is deemed valid and the next step is continued; if they are inconsistent, the message is deemed to have been tampered with, the message is immediately discarded, and an abnormal alarm is triggered.
[0075] Corresponding to the encryption logic of the remote key, the vehicle controller uses the same K_shared key as the remote key to decrypt the encrypted message Msg_encrypt. Only when the keys match can the correct original data be decrypted, ensuring the uniqueness and security of the decryption. The first random number Rand_1' and the timestamp T_1' obtained after decryption are the core of the verification. The first random number Rand_1 is a random number generated by the vehicle controller and stored only in local secure RAM, which attackers cannot obtain; the timestamp T_1 is the timestamp in the challenge frame and is also unique.
[0076] The response frame is a reply to the challenge frame. Rand_1 and T_1 are the core information of this challenge frame. Only when a legitimate key receives and processes the challenge frame can an encrypted message containing the correct Rand_1 and T_1 be generated. After decryption, Rand_1' and T_1' consistent with the local data can be obtained. If an attacker forges the response frame, they cannot obtain the Rand_1, and the decrypted Rand_1' will inevitably be inconsistent with the local Rand_1, thus being identified as a tampered message. Furthermore, if an attacker intercepts the response frame and tampers with the encrypted message Msg_encrypt (e.g., modifying Cmd to change the unlock command to a start command), the decrypted Rand_1' and T_1' will be inconsistent with the locally stored data, thus being identified as a tampered message. Therefore, decryption verification effectively defends against attackers' tampering attacks on encrypted messages, ensuring the legitimacy and integrity of functional commands.
[0077] The reason for not verifying Rand_2' is that Rand_2 is the second random number generated by the remote key. The vehicle controller does not store the original value of Rand_2 locally, so the correctness of Rand_2' cannot be directly verified. The verification of Rand_2 will be completed in the subsequent replay cache verification. There is no need to verify it again here, which can reduce the system's computational pressure and improve the verification efficiency.
[0078] Step S44, Replay Cache Verification: The vehicle controller is configured with a replay detection cache (size N, N=10 by default in engineering), which stores the second random number Rand_2 of the most recent sessions with the same ID_key; the second random number Rand_2 in the current response frame is compared with the data in the cache. If a match is found, it is determined to be a replay attack packet, the packet is immediately discarded, and an abnormal alarm is triggered; if no match is found, the second random number Rand_2 in the current response frame is written into the cache, overwriting the oldest historical data.
[0079] The second random number Rand_2 for the most recent sessions of the same ID_key is stored separately in a replay detection cache. This is because Rand_2 for different ID_keys may be duplicated, and storing them separately can avoid interference between different keys and ensure the accuracy of the verification.
[0080] The second random number Rand_2 is a unique random number generated by the key in each session. The Rand_2 of each session is not repeated. Therefore, if the Rand_2 in the current response frame matches the historical Rand_2 in the buffer, it means that the response frame is a replayed historical message, and it is immediately judged as a replay attack.
[0081] The quadruple verification employs a progressive and complementary design, performing simple and fast checks first (timestamp verification and hardware feature verification), followed by complex and time-consuming checks (decryption verification and replay cache verification). This reduces system resource consumption and improves verification efficiency. For example, if timestamp verification fails, the packet can be discarded directly without subsequent decryption and cache comparison, saving computational resources; if hardware feature verification fails, it indicates a cloned key, eliminating the need for further verification and quickly blocking attacks.
[0082] Meanwhile, the four-fold verification targets different attack scenarios: timestamp verification resists delayed replay, hardware feature verification resists cloned keys, decryption verification resists tampering, and replay cache verification resists instant replay, forming a comprehensive protection barrier to ensure that any type of attack packet can be accurately identified and blocked, maximizing the security of the system.
[0083] In this embodiment, the operations performed after an abnormal alarm is triggered in all scenarios include:
[0084] Record the attack time, ID_key, and message characteristics;
[0085] Limit the frequency of session requests for this ID_key within a preset time period to no more than the first frequency (for example, limit the frequency of session requests for this ID_key to no more than once per minute within 5 minutes; the specific implementation can be flexibly set according to the actual situation).
[0086] If the number of attacks detected within a preset time exceeds the preset limit (for example, more than 3 attacks within 5 minutes; the specific implementation can be flexibly set according to the actual situation), the ID_key will be temporarily disabled, and the user will need to verify the key through the physical key inside the vehicle to unlock it.
[0087] For example, a replay attack multi-check and exception handling instance is as follows:
[0088] Assuming an attacker intercepts a legitimate remote key's response frame using an RF intercept device and replays the frame to the vehicle controller within 150ms (less than T_max), the specific processing flow is as follows:
[0089] 1. The vehicle controller receives the replayed response frame, completes frame verification, and then performs timestamp verification. If Delta T = 150ms < 200ms, the timestamp verification passes.
[0090] 2. Perform hardware feature verification. F_hard matches the pre-stored value, and the verification passes.
[0091] 3. Perform decryption verification. The decrypted data is consistent with the original data, and the verification is successful.
[0092] 4. Perform replay buffer verification, extract Rand_2 from the response frame, compare it with the Rand_2 values of the most recent 10 sessions stored in the buffer, and find that the Rand_2 already exists in the buffer.
[0093] 5. The vehicle controller determines that the message is a replay attack message, discards it immediately, and triggers the abnormal alarm module: records the attack time, ID_key and message characteristics; limits the session request frequency of this ID_key to no more than 1 time / minute within 5 minutes; if the number of attacks exceeds 3 times within 5 minutes, temporarily disables the ID_key, and the user needs to verify it through the physical key in the vehicle to unlock it.
[0094] Referring to step S5, after all verifications pass, the vehicle controller drives the actuator to perform actions (such as controlling the door lock motor to unlock) according to the function instruction Cmd' decrypted from the response frame, and sends a successful instruction execution feedback frame to the remote key; at the same time, the vehicle controller generates a new third random number Rand_3 to replace the locally stored first random number Rand_1, completes the current session update, and waits for the next session request;
[0095] Finally, referring to step S6, after the remote key receives the success feedback frame, it clears the first random number Rand_1, the second random number Rand_2, and the timestamp T_1 of this session, and immediately enters a low-power sleep mode to reduce power consumption; if the remote key does not receive the success feedback frame, it will automatically go into sleep mode after timeout and will not resend the message.
[0096] Based on the above-described method for preventing replay attacks on remote keys, this embodiment constructs a corresponding system for preventing replay attacks on remote keys, the system comprising:
[0097] The remote control key includes a first core processing module, a wake-up module, a communication module, a random number generation module, an encryption module, and a storage module; the first core processing module is connected to the wake-up module, the communication module, the random number generation module, the encryption module, and the storage module respectively.
[0098] The vehicle-mounted controller includes a second core processing module, a session management module, an authentication module, a decryption and verification module, an instruction execution module, an anomaly alarm module, and a secure storage module; the second core processing module is connected to the session management module, the authentication module, the decryption and verification module, the instruction execution module, the anomaly alarm module, and the secure storage module, respectively.
[0099] The first core processing module communicates with the second core processing module through the communication module.
[0100] Specifically, the first and second core processing modules are used for data processing on the remote key and vehicle controller sides, respectively. The first core processing module uses a low-power ARM Cortex-M0+ core MCU. The wake-up module is used to detect user operations and wake up the first core processing module. The communication module uses 433MHz radio frequency communication, supports bidirectional data transmission, and is used for 433MHz radio frequency bidirectional communication with the second core processing module of the vehicle controller. The random number generation module uses a True Random Number Generator (TRNG) to generate a second random number Rand_2 based on the TRNG. The encryption module uses an AES-128 hardware encryption module to generate an encrypted message Msg_encrypt based on the AES-128 algorithm. The storage module is configured with a one-time programmable (OTP) storage area to store the key's unique identifier ID_key, the shared key K_shared, and the hardware feature code F_hard (using a combination of the MCU chip's unique serial number and the radio frequency module's impedance characteristic value, with a length of 64 bits).
[0101] The second core processing module uses an automotive-grade 32-bit MCU. The session management module generates the first random number Rand_1, maintains the timestamp counter, and manages the replay detection buffer. The authentication module verifies the legitimacy of the key's unique identifier ID_key and hardware signature F_hard. The decryption verification module performs timestamp verification, hardware signature verification, decryption operations, random number consistency verification, and replay buffer verification. The instruction execution module executes valid function instructions and provides feedback on the execution results. The anomaly alarm module records attack events, limits session request frequency, and temporarily disables invalid ID_keys. The secure storage module uses a secure storage unit (HSM) to store a list of valid ID_keys, their corresponding hardware signature F_hard, and the shared key K_shared.
[0102] Based on the above-described remote key anti-replay attack system, the method execution flow of this embodiment of the invention is as follows:
[0103] Step S1: The vehicle controller calls the session management module to generate the first random number Rand_1 and starts the timestamp timer; after the user operates the remote key, the wake-up module is triggered to wake up the entire remote key. Subsequently, the remote key sends a session request frame to the vehicle controller through the communication module.
[0104] Step S2: The vehicle controller calls the authentication module to perform frame verification on the session request frame. If the verification passes, the current timestamp T_1 is read and a challenge frame is generated. The challenge frame is sent to the remote key through the communication module. Otherwise, the session request frame is discarded and the abnormal alarm module is triggered.
[0105] Step S3: After receiving the challenge frame through the communication module and completing the frame verification, the remote key calls the random number generation module to generate a second random number Rand_2 based on a True Random Number Generator (TRNG). Then, using the AES-128 hardware encryption module, the second random number Rand_2 generates an encrypted message Msg_encrypt. Finally, the remote key encapsulates Rand_2, Msg_encrypt, and F_hard into a response frame.
[0106] Step S4: After receiving the response frame and completing the frame verification, the vehicle controller calls the decryption verification module to perform multiple verifications. The multiple verifications include timestamp verification, hardware feature verification, decryption verification, and replay buffer verification. If any verification fails, the message is immediately discarded and the abnormal alarm module is triggered.
[0107] Step S5: After all verifications pass, the vehicle controller calls the instruction execution module to drive the corresponding actuator according to the function instruction Cmd' decrypted from the response frame, and sends a successful instruction execution feedback frame to the remote key; at the same time, the vehicle controller calls the session management module to generate a new third random number Rand_3 to replace the first random number Rand_1 stored in the local security storage module, completes the session update, and waits for the next session request.
[0108] Step S6: After receiving the success feedback frame, the remote key clears the Rand_1, Rand_2 and T_1 data of this session and immediately enters low-power sleep mode; if the success feedback frame is not received, it will automatically go into sleep mode after timeout and will not resend the message.
[0109] In summary, the method of this invention avoids the defects of fixed codes or rolling codes through bidirectional random number interaction, limits the effective time window of messages through timestamp verification, prevents key software from being cloned through hardware signature verification, and intercepts duplicate message attacks through replay detection buffers. Correspondingly, this invention also provides a remote key anti-replay attack system, including multiple modules configured on the remote key end and the vehicle controller end. Each module has independent functions and standardized interfaces, and can be directly integrated into the embedded software architecture of existing automotive BCM or PEPS controllers without significant changes to the hardware design, and is compatible with mainstream automotive MCUs.
[0110] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution; or the direct application of the inventive concept and technical solution to other situations without modification, are all within the protection scope of the present invention.
Claims
1. A method for preventing replay attacks on remote control keys, characterized in that: The method includes the following steps: Step S1: The vehicle controller generates a first random number Rand_1 and starts a timestamp timer; the user wakes up the remote key, and then the remote key sends a session request frame to the vehicle controller; Step S2: The vehicle controller performs frame verification on the session request frame. If the verification passes, it reads the current timestamp T_1 and generates a challenge frame; otherwise, it discards the session request frame and triggers an abnormal alarm. Step S3: After the remote key receives the challenge frame and completes the frame verification, it generates a response frame and encrypts it based on the second random number Rand_2; Step S4: After receiving the response frame and completing the frame verification, the vehicle controller performs multiple verifications, including timestamp verification, hardware feature verification, decryption verification, and replay buffer verification. If any verification fails, the message is immediately discarded and an abnormal alarm is triggered. Step S5: After all verifications pass, the vehicle controller drives the actuator to move according to the function instruction Cmd' decrypted from the response frame, and sends a successful instruction execution feedback frame to the remote key; at the same time, the vehicle controller generates a new third random number Rand_3 to replace the locally stored first random number Rand_1, completes the current session update, and waits for the next session request. Step S6: After receiving the success feedback frame, the remote key clears the Rand_1, Rand_2 and T_1 data of this session and immediately enters low-power sleep mode; if the success feedback frame is not received, it will automatically go into sleep mode after timeout and will not resend the message.
2. The method for preventing replay attacks on a remote control key according to claim 1, characterized in that: The frame verification includes the verification of the frame header and the frame tail. The verification of the frame header and the frame tail includes: if the frame header of the current frame is consistent with the preset fixed value of the frame header and the CRC8 verification of the frame tail passes, then the verification of the frame header and the frame tail is determined to be successful; otherwise, the session request frame is discarded and an abnormal alarm is triggered.
3. The method for preventing replay attacks on a remote control key according to claim 1, characterized in that: The session request frame includes a frame header, a key unique identifier ID_key, and a frame trailer.
4. A method for preventing replay attacks on a remote control key according to claim 3, characterized in that: In step S2, the frame verification of the session request frame by the vehicle controller further includes: the vehicle controller queries its own stored list of valid ID_keys; if the ID_key in the session request frame is not in the list, the session request frame is discarded and an abnormal alarm is triggered; otherwise, the current timestamp T_1 is read and a challenge frame is generated.
5. A method for preventing replay attacks on a remote control key according to claim 1, characterized in that: The challenge frame includes a frame header, a first random number Rand_1, a timestamp T_1, and a frame tail.
6. A method for preventing replay attacks on a remote control key according to claim 1, characterized in that: The response frame includes a frame header, a second random number Rand_2, an encrypted message Msg_encrypt, a hardware signature code F_hard, and a frame trailer.
7. A method for preventing replay attacks on a remote control key according to claim 6, characterized in that: The encrypted message Msg_encrypt is obtained by encrypting the second random number Rand_2. The encryption process includes: after generating the second random number Rand_2, using the pre-stored shared key K_shared as the key, the first random number Rand_1, the second random number Rand_2, the timestamp T_1 and the current function instruction Cmd are encrypted in groups. After encryption, the encrypted message Msg_encrypt is obtained.
8. A method for preventing replay attacks on a remote control key according to claim 6, characterized in that: In step S4, the multiple verifications include timestamp verification, hardware feature verification, decryption verification, and replay buffer verification, which are performed sequentially. The specific process is as follows: Step S41, Timestamp Verification: Read the current timestamp T_2 and calculate the time difference ΔT = |T_2-T_1|; if the time difference ΔT is greater than the preset time threshold T_max, it is determined to be an overdue message, regarded as a replay attack risk message, the message is immediately discarded, and an abnormal alarm is triggered; otherwise, continue to the next step. Step S42, Hardware Feature Verification: Extract the hardware feature code F_hard from the response frame and compare it bit by bit with the hardware feature code F_hard corresponding to the pre-stored current key ID_key; if the comparison does not match, it is determined to be an attack message initiated by a cloned key, the message is immediately discarded, and an abnormal alarm is triggered; otherwise, continue to the next step. Step S43, Decryption Verification: Decrypt the encrypted message Msg_encrypt using the shared key K_shared to obtain the decrypted first random number Rand_1', second random number Rand_2', timestamp T_1', and function command Cmd'; verify whether Rand_1' is consistent with the locally stored Rand_1 and whether T_1' is consistent with T_1 in the challenge frame; if they are consistent, the message is deemed valid and the next step is continued; if they are inconsistent, the message is deemed to have been tampered with, the message is immediately discarded, and an abnormal alarm is triggered. Step S44, Replay Cache Verification: The vehicle controller is configured with a replay detection cache, which stores the second random number Rand_2 of the most recent sessions with the same ID_key; the second random number Rand_2 in the current response frame is compared with the data in the cache. If a match is found, it is determined to be a replay attack packet, the packet is immediately discarded, and an abnormal alarm is triggered; if no match is found, the second random number Rand_2 in the current response frame is written into the cache, overwriting the oldest historical data.
9. A method for preventing replay attacks on a remote control key according to any one of claims 2-8, characterized in that: The operations performed after the abnormal alarm is triggered include: Record the attack time, ID_key, and message characteristics; limit the session request frequency of this ID_key to no more than the first frequency within a preset time. If the number of attacks detected within a preset time exceeds the preset number, the ID_key will be temporarily disabled, and the user will need to verify the key via the vehicle's physical key to unlock it.
10. A remote key anti-replay attack system, using a remote key anti-replay attack method according to any one of claims 1-9, characterized in that: The system includes: The remote control key includes a first core processing module, a wake-up module, a communication module, a random number generation module, an encryption module, and a storage module; the first core processing module is connected to the wake-up module, the communication module, the random number generation module, the encryption module, and the storage module respectively. The vehicle-mounted controller includes a second core processing module, a session management module, an authentication module, a decryption and verification module, an instruction execution module, an anomaly alarm module, and a secure storage module; the second core processing module is connected to the session management module, the authentication module, the decryption and verification module, the instruction execution module, the anomaly alarm module, and the secure storage module, respectively. The first core processing module communicates with the second core processing module through the communication module.