Tire pressure sensor identity verification method and system based on dynamic encryption

Abstract

The invention relates to the technical field of sensor identity verification, and discloses a tire pressure sensor identity verification method and system based on dynamic encryption. The method comprises the following steps: reading a chip ID and a real-time rolling code ID of a tire pressure sensor to be verified by an equipment end to obtain sensor identity data; the device end sends the sensor identity data to the central server through the communication module to form an identity verification request; performing database comparison on the chip ID and the real-time rolling code ID in the identity verification request, analyzing the programming times, and generating a programming permission instruction or a programming dispermission instruction; and the equipment end performs programming operation on the tire pressure sensor according to the programming permission instruction, and feeds back to the central server so as to update the accumulated programming times in the sensor registration record. According to the method, the use frequency of a single sensor is effectively limited, the pirate sensor is prevented from being repeatedly used infinitely, each programming operation can be traced through the auditing log, and the pirate prevention capability of the tire pressure sensor is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of sensor identity authentication, and in particular to a tire pressure sensor identity authentication method and system based on dynamic encryption. BACKGROUND

[0002] The tire pressure sensor is an important component of the active safety system of an automobile. As the hardware technical solution of the sensor is increasingly mature, the phenomenon of plate copying and code leakage occurs frequently, resulting in a large number of pirated sensors. In the prior art, tire pressure sensor manufacturers mainly develop exclusive communication protocols to check the command format sent by the sensor at the device end, and when the command format check is passed, it is determined as a self sensor and programming operation is allowed. This protection method based on static protocol format check has obvious defects: once the sensor circuit is copied by plate copying or the communication protocol code is leaked, the device end cannot effectively identify the pirated sensor, and the attacker can easily bypass the verification mechanism, resulting in a virtual protection measure. In addition, the existing scheme lacks effective control of the number of times the sensor is used, and cannot limit the number of programming times of a single sensor, nor can it trace the use history of the sensor, which makes the pirated sensor can be reused infinitely, further aggravating the severity of the pirated problem. SUMMARY

[0003] The main purpose of the present application is to provide a tire pressure sensor identity authentication method and system based on dynamic encryption, which effectively limits the number of times a single sensor is used, prevents pirated sensors from being reused infinitely, and also traces each programming operation through audit logs, improving the anti-piracy capability of the tire pressure sensor.

[0004] To achieve the above purpose, the present application provides a tire pressure sensor identity authentication method based on dynamic encryption, comprising the following steps: The device end reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain sensor identity data; The device end sends the sensor identity data to the central server through the communication module to form an identity authentication request; The central server compares the chip ID and real-time rolling code ID in the identity authentication request with the database and analyzes the number of programming times to generate an allowed programming instruction or a not allowed programming instruction; The device end performs programming operation on the tire pressure sensor according to the allowed programming instruction and feeds back to the central server to update the cumulative programming times in the sensor registration record.

[0005] Optionally, in the first implementation manner of the first aspect of the present application, before the device end reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified, the tire pressure sensor identity authentication method based on dynamic encryption further comprises: reading a chip ID, a first counter value and a first timestamp of the tire pressure sensor, and deriving a session key from a root key; concatenating the chip ID, the first counter value and the first timestamp to obtain concatenated data, and performing a hash operation on the concatenated data using the session key to obtain intermediate ciphertext; encrypting the intermediate ciphertext using the root key as an encryption key to generate an original rolling code ID, and incrementing the first counter value and writing it back to a register; reporting the chip ID and the original rolling code ID to a central server, and creating a sensor registration record in the central server.

[0006] Optionally, in a second implementation manner of the first aspect of the present application, reporting the chip ID and the original rolling code ID to a central server to create a sensor registration record in the central server comprises: the reading and writing device sends an identity reading instruction and a rolling code request instruction to the tire pressure sensor, and receives the chip ID and the original rolling code ID returned; uploading the chip ID and the original rolling code ID to the central server, and the central server forming a registration request after receiving; the central server creating a sensor registration record containing the chip ID, the original rolling code ID, an upper limit of programming times, an initial programming time and a first counter value based on the registration request.

[0007] Optionally, in a third implementation manner of the first aspect of the present application, the device end reads a chip ID and a real-time rolling code ID of a tire pressure sensor to be verified to obtain sensor identity data, comprising: the device end sends a wake-up signal and an identity reading instruction to the tire pressure sensor to be verified through a wireless transceiver module to trigger the tire pressure sensor to be verified to enter an active state; the tire pressure sensor to be verified extracts the chip ID and generates a real-time rolling code ID after receiving the identity reading instruction, and returns them to the device end, and the device end receives identity response data; performing data integrity verification on the chip ID and the real-time rolling code ID in the identity response data, and encapsulating the sensor identity data after the verification is passed.

[0008] Optionally, in a fourth implementation manner of the first aspect of the present application, the device end sends the sensor identity data to a central server through a communication module to form an identity verification request, comprising: The device end establishes a data connection with a mobile network through a communication module and establishes a TLS encryption tunnel with the central server to obtain a secure transmission channel; The chip ID, real-time rolling code ID, second counter value, device timestamp and device identification in the sensor identity data are serialized and packaged to obtain a verification request message; The verification request message is sent to a verification interface of the central server through the secure transmission channel, and the central server forms an identity verification request after receiving the verification request message.

[0009] Optionally, in the fifth implementation manner of the first aspect of the present application, the central server performs database comparison on the chip ID and real-time rolling code ID in the identity verification request and analyzes the programming times to generate an allowed programming instruction or a disallowed programming instruction, including: The chip ID is extracted from the identity verification request and is queried in a database to obtain a corresponding sensor registration record; The expected rolling code is recalculated based on the original rolling code ID in the sensor registration record and the chip ID, and is compared with the real-time rolling code ID, and the counter value and the programming times are determined to obtain a verification result; According to the verification result, if the rolling code comparison, the counter determination and the programming times determination all pass, an allowed programming instruction is generated, otherwise a disallowed programming instruction is generated.

[0010] Optionally, in the sixth implementation manner of the first aspect of the present application, the expected rolling code is recalculated based on the original rolling code ID in the sensor registration record and the chip ID, and is compared with the real-time rolling code ID, and the counter value and the programming times are determined to obtain a verification result, including: The original rolling code ID in the sensor registration record is extracted as a key seed, and dynamic encryption is performed in combination with the chip ID, the second counter value and the device timestamp in the identity verification request to generate an expected rolling code; The expected rolling code is compared with the real-time rolling code ID in the identity verification request byte by byte to obtain a rolling code comparison result, it is determined whether the second counter value is greater than the first counter value in the sensor registration record and the difference is within a set range to obtain a counter determination result, and it is determined whether the cumulative programming times in the sensor registration record are less than the upper limit of the programming times to obtain a programming times determination result; When the rolling code comparison result is consistent, the counter determination result is passed and the programming times determination result is not over the limit, it is determined that the verification is passed, otherwise it is determined that the verification fails, and a verification result is obtained.

[0011] Optionally, in the seventh implementation form of the first aspect of the present application, the device side performs programming operation on the tire pressure sensor according to the allowed programming instruction, and feeds back to the central server to update the cumulative programming times in the sensor registration record, including: extracting an authorization token from the allowed programming instruction, encapsulating the authorization token in a programming preparation instruction and sending to the tire pressure sensor, and after receiving, the tire pressure sensor unlocks the parameter configuration area and returns ready confirmation information; based on the ready confirmation information, the device side transmits programming data to the tire pressure sensor in blocks, receives and verifies the check value returned by the tire pressure sensor after transmitting each block, and after transmitting all data blocks, the tire pressure sensor solidifies the parameters and returns programming success response information; According to the programming success response information, the device side encapsulates the chip ID, the third counter value and the programming timestamp as a programming completion notification and sends it to the central server, and the central server updates the cumulative programming times in the sensor registration record and updates the third counter value to the first counter value.

[0012] Optionally, in the eighth implementation form of the first aspect of the present application, the device side transmits programming data to the tire pressure sensor in blocks based on the ready confirmation information, receives and verifies the check value returned by the tire pressure sensor after transmitting each block, and after transmitting all data blocks, the tire pressure sensor solidifies the parameters and returns programming success response information, including: based on the ready confirmation information, the device side divides the programming data into multiple data blocks and transmits them to the tire pressure sensor in sequence; The tire pressure sensor calculates the CRC32 check value after receiving each data block and returns it, and the device side verifies the CRC32 check value, retransmits the data block if the verification fails, and continues to transmit the next data block if the verification is successful; When all data blocks are verified, the device side sends a programming end instruction to the tire pressure sensor, and the tire pressure sensor writes the programming data into the non-volatile storage area and increments the second counter value to obtain the third counter value, and returns the programming success response information after completion.

[0013] The present application also provides a tire pressure sensor identity authentication system based on dynamic encryption, including: a reading module for the device side to read the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain sensor identity data; an identity authentication module for the device side to send the sensor identity data to the central server through the communication module to form an identity authentication request; A comparison module is configured to compare the chip ID and the real-time rolling code ID in the identity authentication request in the database of the central server and analyze the programming times to generate an allowed programming instruction or a disallowed programming instruction; A programming operation module is configured to program the tire pressure sensor according to the allowed programming instruction on the device side and feed back to the central server to update the cumulative programming times in the sensor registration record.

[0014] In summary, the application solves the problem that the static protocol format verification in the prior art is easy to be cracked. Even if an attacker successfully copies the sensor hardware or obtains the communication protocol code, the attacker cannot forge valid identity authentication data due to the dynamic generation characteristics of the rolling code, thereby completely blocking the manufacturing path of the pirated sensor. The application establishes a central server centralized verification system, moves the decision-making power of identity authentication from the device side to the cloud side, and realizes the cryptography level verification of the sensor identity through a multi-dimensional protection mechanism composed of database comparison, counter continuity determination and programming times limit determination. The programming authorization is rejected if any verification dimension fails. By recording the upper limit of the programming times, the current programming times and the current counter value of each sensor on the server side, the fine management of the whole life cycle of the sensor is realized. Not only the use times of a single sensor are effectively limited to prevent the pirated sensor from being repeatedly used, but also each programming operation can be traced back through the audit log, thereby improving the anti-piracy capability of the tire pressure sensor. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 is a dynamic encryption-based tire pressure sensor identity authentication method step schematic diagram in an embodiment of the application; Figure 2 is a dynamic encryption-based tire pressure sensor identity authentication system structure block diagram in an embodiment of the application.

[0016] The implementation of the object, functional characteristics and advantages of the application will be further described with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0017] In order to make the object, technical scheme and advantages of the application more clear, the application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the application and not to limit the application.

[0018] Referring to Figure 1 The embodiment provides a dynamic encryption-based tire pressure sensor identity authentication method, which comprises the following steps: S1, a device side reads the chip ID and the real-time rolling code ID of a tire pressure sensor to be verified to obtain sensor identity data; Specifically, the device end sends a set of wake-up signals to the tire pressure sensor to be verified through its integrated low-frequency wireless transceiver module (such as a 433 MHz or 315 MHz ASK modulation module). The wake-up signal is a 200 ms carrier pulse, which wakes up the sensor in low-power sleep state and makes the sensor enter an active standby state. After the sensor receives the wake-up signal and completes the initialization of the radio frequency receiving circuit, the device end then sends an identity reading instruction sequence, which includes multiple standard format command frames, including a first instruction for requesting chip ID extraction and a second instruction for triggering the generation of a rolling code. When the sensor responds to the instruction, it reads the 128-bit unique chip ID written at the factory from its secure storage area. The dynamic encryption module inside the sensor starts the rolling code generation process, generates a 128-bit real-time rolling code ID based on the current rolling counter value, real-time timestamp, chip ID, and session key derived from the root key, through HMAC-SHA256 hash calculation and AES-128-CTR encryption, and assembles the chip ID and rolling code ID into identity response data in a preset format and returns it to the device end. After the device end receives the identity response data, it performs data integrity verification operations, including parsing and comparing the CRC check field in the data frame structure to verify whether the data has been tampered with or lost during wireless transmission. If the CRC check passes, the chip ID and rolling code ID extracted from the identity response data are packaged into structured sensor identity data.

[0019] S2, the device end sends the sensor identity data to the central server through the communication module to form an identity verification request; Specifically, the device is built-in with a wireless communication module supporting LTE Cat-1 or Cat-4 standards. After the communication module is turned on, it performs a network attachment process with the operator's base station, and automatically obtains an IP address and routing parameters based on the configured access point name (APN), completing data connection with the mobile network. The device side establishes an encrypted transmission channel based on the TLS 1.3 protocol with the central server's verification interface through a preset server address. The TLS tunnel uses a two-way handshake authentication method to ensure the confidentiality, integrity, and anti-middleman attack capabilities of the data in the communication process. After the tunnel is established, the device side structurally encapsulates the sensor identity data, including chip ID (128 bits), real-time rolling code ID (128 bits), second counter value (i.e., the current rolling counter value of the sensor), device timestamp (device-generated UTC time), and device identifier (such as device serial number or unique ID). The above fields are uniformly encoded into Protocol Buffers format, with efficient binary transmission capabilities and cross-platform compatibility. After encapsulation, the device side sends the verification request message to the server's dedicated verification port (such as TCP 8443) through the established TLS tunnel, and starts a local timeout timer to wait for the server's response. When the central server receives the verification request message, it extracts the message body from the TLS channel and deserializes it to recover the verification request containing the complete identity data.

[0020] S3, the central server compares the chip ID and real-time rolling code ID in the identity verification request with the database and analyzes the programming times to generate an allowed programming instruction or a disallowed programming instruction; Specifically, after the central server receives the verification request message transmitted by the device end through the TLS encrypted channel, the message body is deserialized, and the chip ID, real-time rolling code ID, rolling counter value, device timestamp, and other key identity fields are extracted. The chip ID is used as the primary key field to perform a search operation in the pre-established sensor information database to query whether there is a sensor registration record corresponding to the chip ID. If the chip ID cannot be hit in the database or its status field is identified as invalid, expired, or blocked, the server immediately terminates the verification process and directly generates a response instruction that does not allow programming. If the query hits a legal record, the server extracts the initial rolling code ID in the registration record as a key seed, combines the currently received chip ID, counter value, and device timestamp, and performs the same dynamic rolling code calculation process as the sensor end, i.e., hashes these data through HMAC-SHA256, and then generates the expected rolling code through AES-128-CTR secondary encryption. The server compares the expected rolling code calculated with the real-time rolling code ID uploaded by the device end byte by byte, and if the result is completely consistent, it passes the cryptographic consistency verification. The counter value is continuously checked, and the current value must be greater than the last record value in the database and not exceed the preset jump range (such as not exceeding 100), to prevent counter offset caused by offline wakeup and replay attacks; it is judged whether the cumulative programming times are less than the set maximum threshold (such as 50 times), and those exceeding the threshold will be considered as illegal reuse. When the rolling code comparison, counter validity, and programming times limit all pass, the server determines that the verification is successful, and generates an instruction structure that allows programming, which includes the authorization token, remaining programming times, and token valid time fields; if any verification condition is not met, an instruction that does not allow programming is generated with a rejection code to identify the failure reason.

[0021] S4, the device end performs programming operation on the tire pressure sensor according to the programming allowed instruction, and feeds back to the central server to update the cumulative programming times in the sensor registration record.

[0022] Specifically, the device end extracts a 128-bit authorization token from the allowed programming instruction, the authorization token is generated by the central server through the HMAC-SHA256 algorithm, and is embedded with the chip ID, the rolling counter value and the server random number, has the properties of single validity and time limit restriction. The authorization token is encapsulated into a programming preparation instruction of a specific format, the programming preparation instruction is composed of a synchronization header, an instruction code, a parameter length field and a token body, and is sent to the tire pressure sensor to be programmed through a low-frequency wireless channel. After receiving the programming preparation instruction, the sensor executes the token verification process, and after verification, it automatically unlocks the parameter configuration area and the firmware update area, and returns a ready confirmation response code to the device end to indicate that it has entered the programming state. After receiving the confirmation information, the device end starts the data transmission process, splits the programming content according to the preset data block size (such as 128 bytes) and sends it block by block, and waits for the sensor to return the CRC32 check value of the data block after each transmission. The device end judges whether the data block is successfully written according to the returned check value, if the verification fails, it triggers the retransmission logic, and if it still fails after at most three attempts, it aborts the entire programming process. After all the data blocks are verified and successfully written, the device end sends a programming end instruction to notify the sensor to perform the parameter solidification operation. After completing the EEPROM write and updating the counter, the sensor returns a programming success response information, indicating that all configurations have been safely written. The device end encapsulates the chip ID, the updated third counter value and the current programming timestamp into a programming completion notification message, which also contains the device identifier, and reports it to the central server through the established TLS encrypted channel. After receiving the notification, the server updates the registration record of the sensor in the sensor information database, including: increasing the cumulative programming times field by one, updating the last programming time field to the current time, covering the current counter value field with the third counter value used this time, and writing this operation information to the audit log.

[0023] In one example, before reading the chip ID and the real-time rolling code ID of the tire pressure sensor to be verified at the device end, the dynamic encryption-based tire pressure sensor identity verification method further comprises: reading the chip ID, the first counter value and the first timestamp of the tire pressure sensor, and deriving a session key from the root key; splicing the chip ID, the first counter value and the first timestamp to obtain spliced data, and performing a hash operation on the spliced data using the session key to obtain intermediate ciphertext; encrypting the intermediate ciphertext using the root key as the encryption key to generate the original rolling code ID, and incrementing the first counter value and writing it back to the register; reporting the chip ID and the original rolling code ID to the central server, and creating a sensor registration record in the central server.

[0024] In this example, the chip ID is extracted by the hardware scanning logic during the sensor chip initialization phase, which is a 128-bit unique identifier burned by the chip manufacturer at the factory through one-time programmable fuses or non-erasable areas, ensuring uniqueness and unchangeability. The sensor control logic reads the current first counter value from the power-down hold register, which represents the number of activations since initialization, initially set to 0x00000001 and automatically incremented after each roll code generation. The sensor obtains the current timestamp, i.e., the first timestamp, from the internal crystal oscillator timing unit, which records the number of seconds accumulated since the standard time origin, represented as a 32-bit unsigned integer. The root key derivation logic is invoked to combine the 256-bit root key pre-stored in the secure area with the chip ID, and calculate a 256-bit session key through XOR operation or HMAC derivation function, serving as the dedicated encryption context for this roll code generation operation. The chip ID, first counter value, and first timestamp are concatenated in sequence to form a continuous bit stream, which is used to form the dynamic identity factor. The sensor inputs the session key as the key and performs a single hash operation on the concatenated data using the HMAC-SHA256 hash algorithm to obtain a 256-bit intermediate ciphertext, enhancing the uniqueness and sensitivity of the input factor. The root key is used as the encryption key to invoke the AES-128-CTR encryption module to perform symmetric encryption on the intermediate ciphertext, and the output ciphertext is the 128-bit original roll code ID generated this time. After completing the encryption process, the first counter value is incremented by 1 and written back to the register. The sensor packages the generated chip ID and original roll code ID into a registration reporting data structure and uploads the data to the central server through the read-write device. The uploaded data is in JSON format, containing chip ID, roll code ID, timestamp, production line number, and operator information. After receiving the data, the central server creates a corresponding sensor registration record in its MySQL or equivalent database, including chip ID, initial roll code, current counter value, registration time, cumulative programming times, maximum programming times limit, status flag, and other content, and establishes a unique index for the chip ID field.

[0025] In one example, the chip ID and original roll code ID are reported to the central server, and a sensor registration record is created in the central server, including: The read-write device sends an identity reading instruction and a roll code request instruction to the tire pressure sensor, and receives the returned chip ID and original roll code ID; Upload the chip ID and original roll code ID to the central server, and the central server forms a registration request after receiving it; The central server creates a sensor registration record containing chip ID, original roll code ID, programming times limit, initial programming times, and first counter value based on the registration request.

[0026] In this example, in the sensor factory quality inspection stage, a wireless connection between the read-write device and the sensor to be registered is established through the 13.56 MHz near field communication protocol (such as the ISO 15693 standard). The read-write device sends an identity reading instruction, such as 0xA5, to the tire pressure sensor, triggering the sensor internal logic to call the chip ID reading function in the secure storage area through a specific frame structure. The sensor encapsulates the read 128-bit chip ID into a 16-byte data frame, and returns it to the read-write device through the preset frame header, frame tail, data length field and CRC check to form a complete response data. The read-write device sends a rolling code request instruction 0xB6 to activate the pre-installed dynamic encryption algorithm module in the sensor, execute the rolling code generation process based on the double-layer encryption of HMAC-SHA256 and AES-128-CTR, generate the original rolling code ID and return it in a 16-byte data frame. After receiving the chip ID and the original rolling code ID, the read-write device encapsulates the two data as the core identity field, and combines other auxiliary information such as production line number, operator ID and production timestamp, and uniformly encapsulates it into a JSON format data packet, and uploads the data to the central server through Ethernet or local area network connection. The central server listens to the registration request interface, and after receiving the registration request data in JSON structure, it performs a uniqueness search on the chip ID field to prevent duplicate registration, and immediately creates a new sensor registration record in the database after confirming that there is no duplicate record. The sensor registration record structure includes chip ID, original rolling code ID, pre-set upper limit of programming times (such as 50 times), initialized programming times value (0), current first counter value (initially 1) and other fields, and a unique index is created for the chip ID field. The database records the registration timestamp, and sets the sensor state to "active", indicating that the sensor has been successfully warehoused and has a legal identity.

[0027] In one example, the device end reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified, obtaining the sensor identity data, including: The device end sends a wake-up signal and an identity reading instruction to the tire pressure sensor to be verified through the wireless transceiver module, triggering the tire pressure sensor to be verified to enter an active state; The tire pressure sensor to be verified responds to the identity reading instruction, extracts the chip ID and generates the real-time rolling code ID, and returns them to the device end, and the device end receives the identity response data; The chip ID and real-time rolling code ID in the identity response data are subjected to data integrity check, and after the check is passed, they are encapsulated into sensor identity data.

[0028] In this example, the device end sends a continuous wake-up signal to the target tire pressure sensor through the built-in wireless transceiver module (such as a 433MHz or 315MHz ASK modulation module) after turning on the power and initializing the communication module. The wake-up signal uses a fixed frequency modulation and a carrier pulse with a duration of about 200 milliseconds to activate the sensor in low-power sleep state and wake up its internal radio frequency receiving system. When the sensor receives the wake-up signal, its internal control logic triggers to enter an active state, turns on the radio frequency transceiver circuit and switches to command listening mode. The device end sends an identity reading instruction to the sensor, which is composed of a group of formatted command frames containing synchronization header, instruction code, parameter length, checksum, etc. The instruction code is used to specify the type of reading operation, such as reading chip ID or triggering rolling code generation, etc. When the tire pressure sensor receives the identity reading instruction, the internal control logic extracts its pre-set 128-bit chip ID from the secure storage area. The chip ID is written by the manufacturer at the time of factory shipment and cannot be changed, and it is unique. The sensor starts the dynamic encryption module, reads the current counter value and timestamp, combines the chip ID and the session key derived from the root key, and executes the dynamic encryption algorithm based on the HMAC-SHA256 and AES-128-CTR double-layer structure to generate a unique real-time rolling code ID at the current time. The chip ID and rolling code ID are encapsulated into data frames and returned to the device end in a specific format, where the data frame structure includes frame header, data length, data body, CRC16 checksum field and frame tail, etc. for maintaining structure and verifiability in the wireless channel. After receiving the identity response data, the device end performs decoding operation on the CRC check field in the data frame and recalculates the CRC value for comparison to ensure that the data has not been tampered with or bit-flipped during wireless transmission. If the verification fails, the response is discarded and the reading process is re-initiated. After passing the integrity check, the device end encapsulates the chip ID and real-time rolling code ID extracted from the identity response data into a structured sensor identity data object according to the pre-set format (such as Protocol Buffers).

[0029] In one example, the device end sends the sensor identity data to the central server through the communication module to form an identity verification request, including: The device end establishes a data connection with the mobile network through the communication module and establishes a TLS encrypted tunnel with the central server to obtain a secure transmission channel; The chip ID, real-time rolling code ID, second counter value, device timestamp and device identification in the sensor identity data are serialized and encapsulated to obtain a verification request message; The verification request message is sent to the verification interface of the central server through the secure transmission channel, and the central server forms an identity verification request after receiving it.

[0030] In this example, the device-side configuration supports a data communication module of a cellular network, such as a Cat-1 or Cat-4 LTE module, and initializes a network connection process after system startup. The device accesses a cellular network dedicated to the Internet of Things through a preset APN configuration at startup, completes attachment, authentication, and IP address allocation with the operator's core network, and obtains the IP address corresponding to the public domain name of the central server through DNS resolution. After successfully establishing the underlying network connection, the device initiates a handshake negotiation process with the server based on the Transport Layer Security protocol TLS 1.3, which includes key exchange, certificate verification, and session key negotiation steps, to generate a symmetric encryption key for all communication data within the connection period, thereby building an end-to-end encrypted communication tunnel between the device and the server. The device serializes and encapsulates sensor identity data, including chip ID (i.e., sensor unique hardware identifier), real-time rolling code ID (generated by a dynamic encryption mechanism in real time), second counter value (representing the current state counter of the sensor), device timestamp (recording the local time when the identity data is generated), and device identifier (used to identify the specific terminal device initiating the request). These data fields are structured and encapsulated according to the Protocol Buffers protocol to form an efficient binary format message with field identifiers. The device sends the encapsulated verification request message to the specified verification interface of the central server through the TLS encryption channel, and the specified verification interface listens on a dedicated port (such as TCP 8443) and enables server TLS certificate verification mechanism. After receiving the verification request message, the server immediately decodes and extracts the field contents in the message body to restore the identity verification request structure containing the sensor chip ID, rolling code ID, and counter value.

[0031] In one example, the central server performs database comparison on the chip ID and real-time rolling code ID in the identity verification request and analyzes the programming times to generate an allowed programming instruction or a disallowed programming instruction, including: Extract the chip ID from the identity verification request and perform database query to obtain the corresponding sensor registration record; Based on the original rolling code ID and chip ID in the sensor registration record, recalculate the expected rolling code and real-time rolling code ID comparison, and determine the counter value and programming times to obtain the verification result; According to the verification result, if the rolling code comparison, counter determination, and programming times determination all pass, an allowed programming instruction is generated, otherwise a disallowed programming instruction is generated.

[0032] In this example, after receiving the verification request message uploaded by the device side, the server parses the message body through deserialization operation, extracts the key fields including chip ID, real-time rolling code ID, current counter value, device timestamp, etc., wherein the chip ID is used as the unique identity primary key of the sensor in the database to initiate the query operation. The server retrieves the sensor_info table in the sensor registration database through SQL statement, and uses the "SELECT * FROM sensor_info WHERE chip_id ='specified ID' AND sensor_status = 'active'" instruction to obtain the complete registration record of the chip. If the query is not hit, it means that the chip has never been registered or is in the state of being banned or expired, and the server directly returns the instruction of verification failure and ends the processing flow; if the query is successful, it means that the chip has been successfully registered and is in the active state, then enters the multi-dimensional identity verification stage. The server extracts the original rolling code ID saved at the time of initial registration as the encryption key seed from the registration record, and combines the chip ID, counter value and device timestamp in this request to reproduce the rolling code generation algorithm flow on the sensor side. The server locally executes the same encryption logic as the sensor side, first derives the session key using the original rolling code ID, then concatenates the chip ID, counter value and timestamp, and calculates the intermediate ciphertext through HMAC-SHA256 algorithm, and generates the expected rolling code through AES-128-CTR twice encryption. Compare the expected rolling code with the real-time rolling code ID attached in the verification request byte by byte, if they are completely consistent, then pass the cryptographic authentication judgment, otherwise it is considered as a fake device or illegal tampering data. On the basis of rolling code comparison, check the continuity of the counter value, that is, the current counter value in the verification request must be greater than the last value in the database record, and the difference value must not exceed the set jump tolerance (such as 100), in order to prevent replay attacks caused by counter rollback or jump. Check whether the programming times have reached the upper limit, judge whether the value of program_count field in the database is less than program_limit (for example, 50 times). If all three judgment conditions are met, the server determines that the verification is legal, generates the programming instruction and attaches the authorization token and the remaining programming times information; if any condition fails, generate the instruction that does not allow programming and mark the specific failure reason, such as "invalid counter" "rolling code inconsistency" or "programming times have been exhausted" etc.

[0033] The re-computation of the expected rolling code ID and the real-time rolling code ID based on the original rolling code ID and the chip ID in the sensor registration record, and the determination of the counter value and the programming frequency before the determination of the counter value and the programming frequency, further include the following operations: extracting the historical counter value and the historical verification timestamp at the last successful verification from the sensor registration record, calculating the difference between the second counter value and the historical counter value to obtain a counter increment, calculating the difference between the device timestamp and the historical verification timestamp to obtain a time interval, dividing the counter increment by the time interval to obtain a counter growth rate, determining whether the counter growth rate is within a preset reasonable rate range, and if the counter growth rate is too high, marking it as a high-frequency anomaly, and if the counter growth rate is too low, marking it as a low-frequency anomaly; reading the historical verification record table from the sensor registration record, and calculating the average time interval of the last N verification requests as a normal use time interval reference, calculating the deviation ratio of the current time interval and the normal use time interval reference, and determining the normal use mode when the deviation ratio is less than a first deviation threshold, determining the occasional anomaly mode when the deviation ratio is greater than the first deviation threshold and less than a second deviation threshold, and determining the long-term idle restart mode when the deviation ratio is greater than the second deviation threshold; for the normal use mode, maintaining the preset counter deviation allowed range and the time window threshold unchanged, and using the standard determination rule for the difference between the second counter value and the first counter value; for the occasional anomaly mode, expanding the counter deviation allowed range by fifty percent, and adding an additional rolling code secondary verification requirement in subsequent verification; for the long-term idle restart mode, expanding the counter deviation allowed range to three times the preset value, and requiring the device to provide additional device identity authentication information as auxiliary verification; extracting the timestamp sequence of the last M programming operations from the sensor registration record, calculating the time interval sequence between adjacent two programming operations, performing statistical analysis on the time interval sequence to obtain a programming frequency characteristic value, comparing the current time interval with the programming frequency characteristic value, and marking it as an abnormal high-frequency programming if the current time interval is significantly smaller than the minimum value of the programming frequency characteristic value, and downgrading the safety level of the tire pressure sensor if the abnormal high-frequency programming accumulates to a preset number of times.

[0034] In one example, the re-computation of the expected rolling code ID and the real-time rolling code ID based on the original rolling code ID and the chip ID in the sensor registration record, and the determination of the counter value and the programming frequency, obtain a verification result, including: Extracting the original rolling code ID in the sensor registration record as a key seed, combining the chip ID and the second counter value and the device timestamp in the identity verification request to perform dynamic encryption to generate an expected rolling code; The expected rolling code is compared with the real-time rolling code ID in the authentication request byte by byte to obtain a rolling code comparison result, and it is determined whether the second counter value is greater than the first counter value in the sensor registration record and the difference is within a set range to obtain a counter determination result, and it is determined whether the cumulative programming times in the sensor registration record are less than the upper limit of the programming times to obtain a programming times determination result; When the rolling code comparison result is consistent, the counter determination result is passed, and the programming times determination result is not exceeded, it is determined that the verification is passed, otherwise it is determined that the verification fails, and a verification result is obtained.

[0035] In this example, after receiving the authentication request message uploaded by the device end, the central server extracts the chip ID, real-time rolling code ID, second counter value and device timestamp fields through deserialization, and queries the corresponding sensor registration record in the sensor information database with the chip ID as the primary key. In the registration record, the server extracts the original rolling code ID as the key seed in the key derivation process, performs HMAC-SHA256 hash derivation operation on the key seed and the chip ID to generate the current session key, concatenates the chip ID, the second counter value and the device timestamp in order to form a unified data string, and uses the session key as the input key to perform hash operation again through the HMAC-SHA256 algorithm to generate 256-bit intermediate ciphertext. The root key or the last 128 bits saved in the registration record are used as the encryption key of the AES-128-CTR mode to perform symmetric encryption operation on the intermediate ciphertext to generate the current expected 128-bit rolling code. The expected rolling code is compared with the real-time rolling code ID uploaded in the authentication request byte by byte, and if they are completely consistent within the full 16 bytes (128 bits), it is considered that the rolling code comparison is passed; otherwise, it is determined that it is inconsistent, which is considered as identity forgery or illegal request. At the same time, the server determines the validity of the counter, checks whether the second counter value is greater than the first counter value in the registration record and the difference is not more than the preset tolerance range (for example, not more than 100) to allow offline activation but prevent rollback and abnormal jump, and if the condition is met, the counter is determined to be valid. The server compares the cumulative programming times field in the registration record with the corresponding programming times upper limit field, and the current programming times is less than the preset upper limit (such as 50 times) to determine that the programming times determination is passed. The rolling code comparison result, the counter validity determination result and the programming times limit determination result are combined for logical judgment, and when all of them are satisfied, it is determined that the current verification request is a legal verification and enters the programming authorization process; any item that does not meet the requirements is considered as verification failure and authorization is refused.

[0036] The original rolling code ID in the sensor registration record is extracted as a key seed, dynamic encryption is performed in combination with the chip ID and the second counter value and the device timestamp in the identity verification request, and the expected rolling code is generated, including: the original rolling code ID in the sensor registration record is extracted as an initial key seed, and the chip ID is subjected to an exclusive OR operation to obtain a session key seed; the session key seed is subjected to a key derivation function operation with the second counter value to generate a current session key; the chip ID, the second counter value, the device timestamp, and the current server timestamp of the central server are spliced, the current session key is used to perform HMAC-SHA256 hash operation on the spliced data to obtain a first hash value, and the high 128 bits of the first hash value are taken as a first intermediate ciphertext; the first intermediate ciphertext is subjected to AES-128-CTR encryption using the last 128 bits of the original rolling code ID as an AES key, with the second counter value as the initial value of the counter, to generate the expected rolling code; the time difference value between the device timestamp and the server timestamp is calculated, and it is determined whether the absolute value of the time difference value is less than a preset time window threshold value; if the preset time window threshold value is exceeded, it is determined that the time is abnormal and the expected rolling code is marked as an invalid state.

[0037] When the verification result determines that the verification fails, the central server further performs the following operations: reading the security state field and the consecutive failure number field from the sensor registration record, and classifying the failure reason according to the failure type in the verification result into three failure types of rolling code mismatch failure, counter abnormal failure, or programming number exceeding failure; for the rolling code mismatch failure, the consecutive failure number field is incremented by 1, it is determined whether the consecutive failure number is less than a first failure threshold value, if the consecutive failure number is less than the first failure threshold value, the security state field is set to a warning state and a restricted programming instruction containing the remaining retry number is generated, and if the first failure threshold value is reached, the security state field is set to a temporary lock state and a programming disallowed instruction containing the lock duration is generated; for the counter abnormal failure, it is determined whether the difference between the second counter value and the first counter value is within a recoverable range, if the difference is within the recoverable range, a counter synchronization request instruction is generated and the security state field is marked as a synchronization state, the counter synchronization request instruction carries the first counter value as a reference value, and the device end reinitiates the verification after performing a synchronization reset operation on the counter of the tire pressure sensor; for the programming number exceeding failure, the security state field is set to a number exhausted state, the exceeding time and the last requested device identifier are recorded in the sensor registration record, a programming disallowed instruction containing an exceeding reason code is generated, and the exceeding event is written into an exception audit log table.

[0038] In one example, the device end performs a programming operation on the tire pressure sensor according to the allowed programming instruction, and feeds back to the central server to update the cumulative programming number in the sensor registration record, including: The authorization token is extracted from the programming instruction, encapsulated in the programming preparation instruction and sent to the tire pressure sensor, and after receiving, the tire pressure sensor unlocks the parameter configuration area and returns the ready confirmation information; Based on the ready confirmation information, the programming data is transmitted to the tire pressure sensor in blocks, and after each block is transmitted, the check value returned by the tire pressure sensor is received and verified. After all the data blocks are transmitted, the tire pressure sensor solidifies the parameters and returns the programming success response information; According to the programming success response information, the chip ID, the third counter value and the programming timestamp are encapsulated as a programming completion notification and sent to the central server, and the central server updates the cumulative programming times in the sensor registration record and updates the third counter value to the first counter value.

[0039] In this example, when the device end receives the verification success response message returned from the central server, the 128-bit authorization token contained therein is parsed. The authorization token is generated by the server based on the chip ID, rolling counter value, and random number generated by the server through the HMAC-SHA256 algorithm, and has characteristics such as single use and short time validity. The authorization token is embedded in the programming preparation instruction, which includes a synchronization header, a function code (such as 0xD1), a parameter length field, an authorization token data body, and a checksum field, and is sent to the tire pressure sensor to be programmed through a low-frequency wireless communication module (such as 433MHz ASK). After receiving the programming preparation instruction containing the authorization token, the tire pressure sensor performs local token verification logic to verify the validity and integrity of the authorization token. After passing the verification, it automatically removes the write protection state of its parameter configuration register and firmware update area, enters the programming ready mode, and returns a ready confirmation response to the device end, using a fixed response code (such as 0xAC) to indicate successful reception and preparation for programming operation. After receiving the ready confirmation, the device end starts the programming data transmission process, divides the preset programming data into blocks, for example, 128 bytes per block, and sends each block to the sensor. After sending each block, the sensor performs CRC32 or equivalent verification on the data block and returns the calculated verification value to the device end for comparison and confirmation. If the comparison passes, the next data transmission is entered. If the comparison fails, retransmission logic is triggered, with a maximum of three retransmissions. If it still fails, the programming operation is aborted and an exception handling process is entered. When all data blocks are successfully transmitted and verified, the device end sends a programming end instruction to notify the sensor to persistently write all received parameters to its non-volatile memory (such as EEPROM) and update the programming completion flag bit of the internal state register, while incrementing the current counter value for synchronization with the next round of verification logic. After completing the write, the sensor returns a programming success response message (such as 0xEE) to the device end, indicating that the parameter update has taken effect. After receiving the response message, the device end encapsulates the chip ID, the third counter value currently in use, and the programming timestamp obtained locally into a programming completion notification and sends it to the central server through a TLS encrypted channel. After receiving the programming completion notification, the server parses its structure and performs a state update operation on the corresponding record in the sensor registration database, including incrementing the cumulative programming times field, updating the current first counter value field to the third counter value used this time, updating the last programming time field, and writing this operation record to the audit log.

[0040] The method further comprises the following operations before the programming data is transmitted to the tire pressure sensor in blocks based on the readiness confirmation information: extracting a 128-bit token master key from the authorization token, performing HMAC-SHA256 operation on the token master key and the chip ID to obtain a programming session root key, generating an independent block encryption key for each data block based on the programming session root key and a data block serial number using a key derivation function; dividing the programming data into a plurality of plaintext data blocks in a fixed block size and assigning an increasing block serial number to each plaintext data block, performing AES-128-CBC encryption on each plaintext data block using the block encryption key corresponding to the block serial number to obtain an encrypted data block, and calculating the SHA256 hash value of each encrypted data block as a block hash value; taking the block hash value of the first encrypted data block as an initial chained hash value, and starting from the second encrypted data block, splicing the block hash value of the previous encrypted data block with the plaintext data of the current encrypted data block and then calculating the hash value to form a chained hash value sequence, and generating a programming data packet containing all encrypted data blocks, block serial numbers, block hash values and chained hash values; encapsulating the programming session root key and the integrity verification parameter in the extension field of the programming preparation instruction and sending them to the tire pressure sensor together with the authorization token, and extracting the programming session root key and deriving each block encryption key after the tire pressure sensor receives them.

[0041] In one example, the programming data is transmitted to the tire pressure sensor in blocks based on the readiness confirmation information, a check value returned by the tire pressure sensor is received and verified after each data block is transmitted, and the tire pressure sensor solidifies the parameters and returns a programming success response information after all data blocks are transmitted. The programming data is divided into a plurality of data blocks based on the readiness confirmation information, and is transmitted to the tire pressure sensor in sequence. The tire pressure sensor calculates a CRC32 check value after receiving each data block and returns it, and the device end verifies the CRC32 check value, retransmits the data block if the verification fails, and continues to transmit the next data block if the verification is passed. When all data blocks are verified, a programming end instruction is sent to the tire pressure sensor, the tire pressure sensor writes the programming data into the non-volatile storage area and increments the second counter value to obtain a third counter value, and returns a programming success response information after completion.

[0042] In this example, based on the ready confirmation information, the programming data to be sent is logically divided into a predetermined block size, for example, a fixed-length data structure of 128 bytes per block, forming a set of ordered data block collection. The device starts from the first data block and sends data to the tire pressure sensor in programming mode block by block. Each data block is transmitted to the sensor receiver module through the wireless communication link. After receiving each data block, the tire pressure sensor calls the internal verification logic module to perform CRC32 cyclic redundancy check operation on the received data, obtains the corresponding 32-bit check code, and encapsulates the check code as a response data frame to return to the device. After receiving the CRC32 check value returned by the sensor, the device compares the CRC32 check value with the CRC32 result calculated locally before sending the same data block. If they are consistent, it means that the data block has not been damaged or bit error during wireless transmission, and the device enters the next data transmission process. If the CRC check result is inconsistent, it means that the data block has an error during transmission, and the device will resend the current data block and wait for the sensor's verification response again. For each data block, the device allows a maximum of 3 retransmissions. If it still fails to pass the verification for 3 consecutive times, the programming operation is aborted, and an error handling mechanism is triggered to prompt the user to check the communication stability or sensor status. When all data blocks pass the verification and are successfully transmitted, the device sends a programming end instruction, which informs the tire pressure sensor that the current programming data transmission is complete and requests it to perform parameter write operation. After receiving the programming end instruction, the tire pressure sensor writes all verified data blocks from the temporary RAM buffer to the non-volatile storage medium, such as EEPROM or Flash memory, to ensure that the programming data remains in the event of power failure, and increments the second counter value used for identity verification by 1 to obtain the third counter value after writing is completed. After the data write and counter update operations are completed, the tire pressure sensor returns a programming success response information to the device, indicating that the current programming has been solidified and the status has been updated.

[0043] Referring to Figure 2 The embodiment provides a tire pressure sensor identity verification system based on dynamic encryption, comprising: A reading module 1 is used for the device to read the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain sensor identity data; An identity verification module 2 is used for the device to send the sensor identity data to the central server through the communication module to form an identity verification request; A comparison module 3 is used for the central server to compare the chip ID and real-time rolling code ID in the identity verification request in the database and analyze the programming times to generate an allowed programming instruction or an unallowed programming instruction; The programming operation module 4 is configured to perform programming operation on the tire pressure sensor according to the allowed programming instruction at the device end, and feedback to the central server to update the cumulative programming times in the sensor registration record.

[0044] In the embodiment, the specific implementation of each unit in the system embodiment is described above in the method embodiment, which will not be repeated here.

[0045] It should be noted that in this paper, the term "includes", "contains" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, system, article or method including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or includes elements inherent to such process, system, article or method. Without more limitations, the element defined by the statement "includes a" does not exclude the existence of other identical elements in the process, system, article or method including the element.

[0046] The above is only the preferred embodiment of the present application, and does not limit the patent scope of the present application, and any equivalent structure or equivalent process transformation using the content of the present application specification and drawings, or direct or indirect application in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A dynamic encryption-based tire pressure sensor authentication method, characterized by, The method comprises the following steps: The device end reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain sensor identity data; The device end sends the sensor identity data to the central server through the communication module to form an identity verification request; The central server compares the chip ID and real-time rolling code ID in the identity verification request with the database and analyzes the programming times to generate an allowed programming instruction or a disallowed programming instruction; The device end performs programming operation on the tire pressure sensor according to the allowed programming instruction and feeds back to the central server to update the cumulative programming times in the sensor registration record.

2. The dynamic encryption-based tire pressure sensor authentication method of claim 1, wherein, Before the device end reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified, the tire pressure sensor identity verification method based on dynamic encryption further comprises the following steps: Read the chip ID, first counter value and first timestamp of the tire pressure sensor, and derive a session key from the root key; Splice the chip ID, first counter value and first timestamp to obtain spliced data, and perform hash operation on the spliced data using the session key to obtain intermediate ciphertext; Use the root key as an encryption key to encrypt the intermediate ciphertext to generate an original rolling code ID, and write back the first counter value after incrementing; Report the chip ID and the original rolling code ID to the central server to create a sensor registration record in the central server.

3. The dynamic encryption-based tire pressure sensor authentication method of claim 2, wherein, Reporting the chip ID and the original rolling code ID to the central server to create a sensor registration record in the central server comprises the following steps: The read-write device sends an identity reading instruction and a rolling code request instruction to the tire pressure sensor, and receives the returned chip ID and original rolling code ID; Upload the chip ID and the original rolling code ID to the central server, and the central server forms a registration request after receiving them; The central server creates a sensor registration record containing the chip ID, the original rolling code ID, the upper limit of the programming times, the initial programming times and the first counter value based on the registration request.

4. The dynamic encryption-based tire pressure sensor authentication method of claim 1, wherein, The device end reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain sensor identity data, which comprises the following steps: The device end sends a wake-up signal and an identity reading instruction to the tire pressure sensor to be verified through a wireless transceiver module to trigger the tire pressure sensor to enter an active state; The tire pressure sensor to be verified responds to the identity reading instruction, extracts the chip ID and generates a real-time rolling code ID, and then returns them to the device end, and the device end receives the identity response data; Perform data integrity check on the chip ID and the real-time rolling code ID in the identity response data, and encapsulate the sensor identity data after the check is passed.

5. The dynamic encryption-based tire pressure sensor authentication method of claim 1, wherein, The device end sends the sensor identity data to the central server through the communication module to form an identity verification request, which comprises the following steps: The device end establishes data connection with the mobile network through the communication module and establishes a TLS encryption tunnel with the central server to obtain a secure transmission channel; Serializing and packaging the chip ID, real-time rolling code ID, second counter value, device timestamp and device identification in the sensor identity data to obtain a verification request message; Sending the verification request message to a verification interface of the central server through the secure transmission channel, and forming an identity verification request after the central server receives the verification request message.

6. The dynamic encryption-based tire pressure sensor identity verification method of claim 1, wherein, The central server performs database comparison on the chip ID and real-time rolling code ID in the identity verification request and analyzes the programming times to generate an allowed programming instruction or a disallowed programming instruction, including: Extracting the chip ID from the identity verification request and querying the database to obtain the corresponding sensor registration record; Recomputing the expected rolling code based on the original rolling code ID in the sensor registration record and the chip ID and comparing the real-time rolling code ID, and determining the counter value and the programming times to obtain a verification result; According to the verification result, if the rolling code comparison, counter determination and programming times determination all pass, an allowed programming instruction is generated, otherwise a disallowed programming instruction is generated.

7. The dynamic encryption-based tire pressure sensor identity verification method of claim 6, wherein, The recomputing the expected rolling code based on the original rolling code ID in the sensor registration record and the chip ID and comparing the real-time rolling code ID, and determining the counter value and the programming times to obtain a verification result, includes: Extracting the original rolling code ID in the sensor registration record as a key seed, combining the chip ID and the second counter value and device timestamp in the identity verification request to perform dynamic encryption to generate an expected rolling code; Comparing the expected rolling code with the real-time rolling code ID in the identity verification request byte by byte to obtain a rolling code comparison result, determining whether the second counter value is greater than the first counter value in the sensor registration record and the difference is within a set range to obtain a counter determination result, and determining whether the cumulative programming times in the sensor registration record is less than the upper limit of the programming times to obtain a programming times determination result; When the rolling code comparison result is consistent, the counter determination result is passed and the programming times determination result is not over limit, it is determined that the verification is passed, otherwise it is determined that the verification fails to obtain a verification result.

8. The dynamic encryption-based tire pressure sensor identity verification method of claim 1, wherein, The device end performs programming operation on the tire pressure sensor according to the allowed programming instruction and feeds back to the central server to update the cumulative programming times in the sensor registration record, including: Extracting the authorization token from the allowed programming instruction, packaging the authorization token in a programming preparation instruction and sending it to the tire pressure sensor, and the tire pressure sensor receives it to unlock the parameter configuration area and reply to the ready confirmation information; Based on the ready confirmation information, the programming data is transmitted to the tire pressure sensor in blocks, and the verification value returned by the tire pressure sensor is received and verified after each data block is transmitted, and after all data blocks are transmitted, the tire pressure sensor solidifies the parameters and returns the programming success response information; According to the programming success response information, the chip ID, third counter value and programming timestamp are packaged as a programming completion notification and sent to the central server, and the central server updates the cumulative programming times in the sensor registration record and updates the third counter value to the first counter value.

9. The dynamic encryption-based tire pressure sensor identity verification method of claim 8, wherein, The programming data is transmitted to the tire pressure sensor in blocks based on the readiness confirmation information, a check value returned by the tire pressure sensor is received after each data block is transmitted, and the parameter of the tire pressure sensor is solidified after all data blocks are transmitted, and a programming success response information is returned. The programming data is divided into multiple data blocks based on the readiness confirmation information, and is transmitted to the tire pressure sensor in sequence; The tire pressure sensor calculates a CRC32 check value after receiving each data block and returns it, and the device end verifies the CRC32 check value, retransmits the data block if the verification fails, and continues to transmit the next data block if the verification is successful; When all data blocks are verified, a programming end instruction is sent to the tire pressure sensor, the tire pressure sensor writes the programming data into a non-volatile storage area and increments the second counter value to obtain a third counter value, and returns a programming success response information after completion.

10. A dynamic encryption based tire pressure sensor authentication system, comprising: Steps for implementing the dynamic encryption-based tire pressure sensor identity verification method of any one of claims 1 to 9, comprising: A reading module for reading the chip ID and real-time rolling code ID of the tire pressure sensor to be verified by the device end to obtain sensor identity data; An identity verification module for sending the sensor identity data to the central server through the communication module to form an identity verification request; A comparison module for comparing the chip ID and real-time rolling code ID in the identity verification request with the database and analyzing the programming times to generate an allowed programming instruction or a not allowed programming instruction; A programming operation module for performing programming operation on the tire pressure sensor according to the allowed programming instruction and feeding back to the central server to update the cumulative programming times in the sensor registration record.

Images