A method and system for tire pressure sensor authentication based on dynamic encryption

Abstract

This invention relates to the field of sensor authentication technology, and discloses a method and system for authenticating tire pressure sensors based on dynamic encryption. The method involves: the device reading the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain sensor identity data; the device sending the sensor identity data to a central server via a communication module to form an authentication request; comparing the chip ID and real-time rolling code ID in the authentication request against a database and analyzing the number of programming attempts to generate a permission instruction or a disallow instruction for programming; the device performing programming operations on the tire pressure sensor according to the permission instruction and feeding back to the central server to update the cumulative number of programming attempts in the sensor registration record. This invention effectively limits the number of times a single sensor can be used, preventing the unlimited reuse of pirated sensors, and allows for tracing each programming operation through audit logs, thus improving the anti-piracy capability of tire pressure sensors.

Description

Technical Field

[0001] This invention relates to the field of sensor authentication technology, and in particular to a method and system for authenticating tire pressure sensors based on dynamic encryption. Background Technology

[0002] Tire pressure sensors are a crucial component of automotive active safety systems. Due to the increasing maturity of sensor hardware technology, rampant copying and code leaks have led to a surge in counterfeit sensors. Current technology primarily relies on proprietary communication protocols to validate the command format sent by the sensor at the device end. If the command format verification passes, the sensor is identified as their own and programming is permitted. This static protocol-based validation method has significant flaws: once the sensor circuitry is copied or the communication protocol code is leaked, the device cannot effectively identify the counterfeit sensor, allowing attackers to easily bypass the verification mechanism, rendering the protection measures ineffective. Furthermore, existing solutions lack effective control over the number of times sensors can be used, failing to limit the number of times a single sensor can be programmed or trace its usage history. This allows counterfeit sensors to be reused indefinitely, further exacerbating the piracy problem. Summary of the Invention

[0003] The main objective of this invention is to provide a method and system for authenticating tire pressure sensors based on dynamic encryption. This invention effectively limits the number of times a single sensor can be used, prevents pirated sensors from being reused indefinitely, and can also trace each programming operation through audit logs, thereby improving the anti-piracy capability of tire pressure sensors.

[0004] To achieve the above objectives, the present invention provides a tire pressure sensor authentication method based on dynamic encryption, comprising the following steps:

[0005] The device reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain the sensor's identity data;

[0006] The device sends the sensor identity data to the central server via the communication module to form an authentication request.

[0007] The central server performs a database comparison of the chip ID and real-time rolling code ID in the authentication request and analyzes the number of programming attempts to generate a programming permission instruction or a programming permission instruction.

[0008] The device performs programming operations on the tire pressure sensor according to the programming permission instruction and feeds back to the central server to update the cumulative number of programming operations in the sensor registration record.

[0009] Optionally, in a first implementation of the first aspect of the present invention, before reading the chip ID and real-time rolling code ID of the tire pressure sensor to be verified on the device side, the tire pressure sensor authentication method based on dynamic encryption further includes:

[0010] Read the chip ID, first counter value and first timestamp of the tire pressure sensor, and derive the session key from the root key;

[0011] The chip ID, the first counter value, and the first timestamp are concatenated to obtain concatenated data. The session key is then used to perform a hash operation on the concatenated data to obtain intermediate ciphertext.

[0012] The root key is used as the encryption key to encrypt the intermediate ciphertext, generate the original rolling code ID, and the first counter value is incremented and written back to the register.

[0013] The chip ID and the original rolling code ID are reported to the central server, where a sensor registration record is created.

[0014] Optionally, in a second implementation of the first aspect of the present invention, the chip ID and the original rolling code ID are reported to a central server, and a sensor registration record is created in the central server, including:

[0015] The reading and writing device sends an identity reading instruction and a rolling code request instruction to the tire pressure sensor, and receives the returned chip ID and the original rolling code ID;

[0016] The chip ID and the original rolling code ID are uploaded to the central server, and the central server generates a registration request upon receiving them.

[0017] The central server creates a sensor registration record based on the registration request, which includes the chip ID, the original rolling code ID, the maximum number of programming attempts, the initial number of programming attempts, and the first counter value.

[0018] Optionally, in a third implementation of the first aspect of the present invention, the device reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain sensor identity data, including:

[0019] The device sends a wake-up signal and an identity reading command to the tire pressure sensor to be verified via a wireless transceiver module, triggering the tire pressure sensor to enter an active state.

[0020] The tire pressure sensor to be verified responds to the identity reading command, extracts the chip ID and generates a real-time rolling code ID, and then sends it back to the device. The device receives the identity response data.

[0021] The chip ID and the real-time rolling code ID in the identity response data are verified for data integrity. After the verification is successful, they are encapsulated as sensor identity data.

[0022] Optionally, in a fourth implementation of the first aspect of the present invention, the device sends the sensor identity data to the central server via a communication module to form an authentication request, including:

[0023] The device establishes a data connection with the mobile network through a communication module and establishes a TLS encrypted tunnel with the central server to obtain a secure transmission channel.

[0024] The chip ID, real-time rolling code ID, second counter value, device timestamp and device identifier in the sensor identity data are serialized and encapsulated to obtain a verification request message;

[0025] The verification request message is sent to the verification interface of the central server through the secure transmission channel, and the central server generates an authentication request upon receiving it.

[0026] Optionally, in a fifth implementation of the first aspect of the present invention, the central server performs a database comparison of the chip ID and the real-time rolling code ID in the authentication request and analyzes the number of programming attempts to generate a programming permission instruction or a programming disallow instruction, including:

[0027] Extract the chip ID from the authentication request and query the database to obtain the corresponding sensor registration record;

[0028] Based on the original scroll code ID in the sensor registration record and the chip ID, the expected scroll code is recalculated and compared with the real-time scroll code ID. The counter value and the number of programming attempts are then evaluated to obtain the verification result.

[0029] Based on the verification results, if the rolling code comparison, counter determination, and programming count determination all pass, a programming permission instruction is generated; otherwise, a programming disallowment instruction is generated.

[0030] Optionally, in a sixth implementation of the first aspect of the present invention, the step of recalculating the expected scroll code based on the original scroll code ID in the sensor registration record and the chip ID, comparing it with the real-time scroll code ID, and determining the counter value and the number of programming attempts to obtain the verification result includes:

[0031] Extract the original scroll code ID from the sensor registration record as a key seed, and perform dynamic encryption by combining the chip ID, the second counter value in the authentication request, and the device timestamp to generate the desired scroll code;

[0032] The expected scroll code is compared byte by byte with the real-time scroll code ID in the authentication request to obtain the scroll code comparison result. The second counter value is determined to be greater than the first counter value in the sensor registration record and the difference is within a set range to obtain the counter determination result. The cumulative programming count in the sensor registration record is determined to be less than the upper limit of programming count to obtain the programming count determination result.

[0033] The verification is considered successful when the rolling code comparison result is consistent, the counter determination result is successful, and the programming count determination result is within the limit; otherwise, the verification is considered unsuccessful, and the verification result is obtained.

[0034] Optionally, in a seventh implementation of the first aspect of the present invention, the device performs a programming operation on the tire pressure sensor according to the programming permission instruction and feeds back to the central server to update the cumulative programming count in the sensor registration record, including:

[0035] The authorization token is extracted from the programming permission instruction, and the authorization token is encapsulated in the programming preparation instruction and sent to the tire pressure sensor. After receiving the instruction, the tire pressure sensor unlocks the parameter configuration area and replies with a readiness confirmation message.

[0036] Based on the readiness confirmation information, programming data is transmitted to the tire pressure sensor in blocks. Each time a data block is transmitted, the verification value returned by the tire pressure sensor is received and verified. After all data blocks are transmitted, the tire pressure sensor solidifies the parameters and returns a programming success response message.

[0037] Based on the successful programming response information, the chip ID, the third counter value, and the programming timestamp are encapsulated into a programming completion notification and sent to the central server. The central server updates the cumulative programming count in the sensor registration record and updates the third counter value to the first counter value.

[0038] Optionally, in the eighth implementation of the first aspect of the present invention, the step of transmitting programming data to the tire pressure sensor in blocks based on the readiness confirmation information, receiving and verifying the verification value returned by the tire pressure sensor after each data block is transmitted, and fixing the parameters of the tire pressure sensor and returning a programming success response information after all data blocks have been transmitted, includes:

[0039] Based on the readiness confirmation information, the programming data is divided into multiple data blocks and transmitted sequentially to the tire pressure sensor;

[0040] After receiving each data block, the tire pressure sensor calculates the CRC32 check value and sends it back. The device verifies the CRC32 check value. If the verification fails, the data block is retransmitted. If the verification passes, the next data block is transmitted.

[0041] Once all data blocks have passed verification, a programming end command is sent to the tire pressure sensor. The tire pressure sensor writes the programming data into a non-volatile memory area and increments the second counter value to obtain the third counter value. After completion, it returns a programming success response message.

[0042] The present invention also provides a tire pressure sensor authentication system based on dynamic encryption, comprising:

[0043] The reading module is used by the device to read the chip ID and real-time rolling code ID of the tire pressure sensor to be verified, and obtain the sensor identity data.

[0044] An authentication module is used by the device to send the sensor identity data to the central server through the communication module to form an authentication request.

[0045] The comparison module is used by the central server to perform database comparison of the chip ID and real-time rolling code ID in the authentication request and analyze the number of programming attempts to generate a programming instruction that allows or disallows programming.

[0046] The programming operation module is used by the device to program the tire pressure sensor according to the programming permission instruction and to report back to the central server to update the cumulative number of programming times in the sensor registration record.

[0047] In summary, this invention solves the problem of static protocol format verification being easily cracked in existing technologies. Even if an attacker successfully copies the sensor hardware or obtains the communication protocol code, the dynamic generation characteristics of the rolling code prevent them from forging valid authentication data, completely blocking the manufacturing path of pirated sensors. This invention establishes a centralized server verification system, moving the decision-making power for identity authentication from the device to the cloud. Through a multi-dimensional protection mechanism consisting of database comparison, counter continuity judgment, and programming limit judgment, cryptographic-level verification of sensor identity is achieved. Failure in any verification dimension results in rejection of programming authorization. By recording the maximum number of programming attempts, the current number of programming attempts, and the current counter value for each sensor on the server side, refined management of the entire sensor lifecycle is achieved. This not only effectively limits the number of times a single sensor can be used, preventing pirated sensors from being reused indefinitely, but also allows for tracing each programming operation through audit logs, thereby improving the anti-piracy capability of tire pressure sensors. Attached Figure Description

[0048] Figure 1 This is a schematic diagram of the steps of a tire pressure sensor authentication method based on dynamic encryption in one embodiment of the present invention;

[0049] Figure 2 This is a block diagram of a tire pressure sensor authentication system based on dynamic encryption in one embodiment of the present invention.

[0050] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this invention clearer, the invention 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 merely illustrative and not intended to limit the invention.

[0052] Reference Figure 1 This embodiment provides a tire pressure sensor authentication method based on dynamic encryption, including the following steps:

[0053] S1, the device reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain the sensor identity data;

[0054] Specifically, the device sends a wake-up signal to the tire pressure sensor to be verified via its integrated low-frequency wireless transceiver module (such as a 433MHz or 315MHz ASK modulation module). The wake-up signal is a carrier pulse lasting 200 milliseconds, waking up the sensor from its low-power sleep state and putting it into an active standby state. After the sensor receives the wake-up signal and completes the initialization of its RF receiving circuit, the device then sends an identity reading instruction sequence. This sequence contains multiple standard format command frames, including a first instruction for requesting chip ID extraction and a second instruction for triggering rolling code generation. When the sensor responds to the instructions, it reads the 128-bit unique chip ID, which was permanently written at the factory, from its secure storage area. The sensor's internal dynamic encryption module initiates the rolling code generation process. Based on the current rolling counter value, real-time timestamp, chip ID, and session key derived from the root key, it generates a 128-bit real-time rolling code ID through HMAC-SHA256 hash calculation and AES-128-CTR encryption. The chip ID and rolling code ID are then assembled into identity response data in a preset format and sent back to the device. After receiving the identity response data, the device performs a data integrity verification operation, 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 encapsulated into structured sensor identity data.

[0055] S2, the device sends the sensor identity data to the central server through the communication module to form an authentication request;

[0056] Specifically, the device has a built-in wireless communication module supporting LTE Cat-1 or Cat-4 standards. After powering on, the communication module performs a network attachment process with the operator's base station and automatically obtains the IP address and routing parameters based on the configured Access Point Name (APN) to complete the data connection with the mobile network. The device establishes an encrypted transmission channel based on the TLS 1.3 protocol with the central server's authentication interface through a preset server address. The TLS tunnel uses a two-way handshake authentication method to ensure the confidentiality, integrity, and resistance to man-in-the-middle attacks of the data during communication. After the tunnel is established, the device encapsulates the sensor identity data in a structured manner, including the chip ID (128 bits), real-time rolling code ID (128 bits), second counter value (i.e., the current value of the sensor's rolling counter), device timestamp (UTC time generated locally by the device), and device identifier (such as device serial number or unique ID). All of these fields are uniformly encoded in Protocol Buffers format, which has efficient binary transmission capabilities and cross-platform compatibility. After encapsulation, the device sends the verification request message through the established TLS tunnel to the dedicated verification port (such as TCP 8443) that the server is listening on, and starts a timeout timer locally 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 complete identity data.

[0057] S3, the central server compares the chip ID and real-time rolling code ID in the authentication request with the database and analyzes the number of programming attempts to generate a programming permission instruction or a programming permission instruction.

[0058] Specifically, after receiving the verification request message transmitted from the device via a TLS encrypted channel, the central server deserializes the message body, extracts key identity fields such as chip ID, real-time rolling code ID, rolling counter value, and device timestamp, and performs a search operation in a pre-established sensor information database using the chip ID as the primary key to check if a sensor registration record corresponding to the chip ID exists. If the chip ID cannot be found in the database or its status field indicates invalid, expired, or blocked, the server immediately terminates the verification process and directly generates a response instruction that disallows programming. If a valid record is found, the server extracts the initial rolling code ID from the registration record as a key seed, combines it with the currently received chip ID, counter value, and device timestamp, and performs the same dynamic rolling code calculation process as the sensor, i.e., hashing these data using HMAC-SHA256 and then performing secondary encryption using AES-128-CTR to generate the desired rolling code. The server compares the calculated desired rolling code byte-by-byte with the real-time rolling code ID uploaded by the device. If the results are completely consistent, the cryptographic consistency verification is passed. The counter value is continuously verified, requiring the current value to be greater than the previous record value in the database but not exceeding a preset jump range (e.g., not exceeding 100) to prevent count offsets and replay attacks caused by offline wake-up. The cumulative programming attempts are checked against a set maximum threshold (e.g., 50 times); exceeding this threshold is considered unauthorized reuse. When the rolling code comparison, counter validity, and programming attempt limit all pass, the server considers the verification successful and generates a programming-allowed instruction structure containing fields such as an authorization token, remaining programming attempts, and token validity period. If any verification condition is not met, a programming-disallowed instruction is generated with a rejection code to indicate the reason for failure.

[0059] S4, the device performs programming operations on the tire pressure sensor according to the allowed programming instructions, and sends feedback to the central server to update the cumulative number of programming times in the sensor registration record.

[0060] Specifically, the device extracts a 128-bit authorization token from the programming permission command. This token, generated by the central server using the HMAC-SHA256 algorithm, embeds the chip ID, rolling counter value, and a server random number, and has the attributes of single-use validity and time limit. The authorization token is encapsulated into a specific programming preparation command, consisting of a synchronization header, command code, parameter length field, and the token itself, and transmitted to the tire pressure sensor to be programmed via a low-frequency wireless channel. Upon receiving the programming preparation command, the sensor executes a token verification process. Upon successful verification, it automatically unlocks its parameter configuration area and firmware update area and returns a ready confirmation response code to the device, indicating that it has entered programming mode. After receiving the confirmation information, the device initiates the data transmission process, dividing the programming content into blocks according to a preset data block size (e.g., 128 bytes) and sending them one block at a time. For each data block transmitted, the device waits for the sensor to return the CRC32 checksum of the data block. The device determines whether the data block has been successfully written based on the returned checksum. If verification fails, a retransmission logic is triggered, with a maximum of three attempts before the entire programming process is terminated. After all data blocks have passed verification and been successfully written, the device sends a programming completion command to notify the sensor to perform parameter solidification. The sensor, after completing the EEPROM write and updating the counter, returns a programming success response, indicating that all configurations have been securely written. The device encapsulates the chip ID, the updated third counter value, and the current programming timestamp into a programming completion notification message, which also includes the device identifier. This message is then reported to the central server via the established TLS encrypted channel. Upon receiving the notification, the server updates the sensor's registration record in the sensor information database, including: incrementing the cumulative programming count field, updating the last programming time field to the current time, overwriting the current counter value field with the third counter value used this time, and writing this operation information to the audit log.

[0061] In one example, before reading the chip ID and real-time rolling code ID of the tire pressure sensor to be verified on the device side, the tire pressure sensor authentication method based on dynamic encryption also includes:

[0062] Read the chip ID, first counter value and first timestamp of the tire pressure sensor, and derive the session key from the root key;

[0063] The chip ID, the first counter value, and the first timestamp are concatenated to obtain the concatenated data. The session key is then used to perform a hash operation on the concatenated data to obtain the intermediate ciphertext.

[0064] The root key is used as the encryption key to encrypt the intermediate ciphertext, generate the original rolling code ID, and increment the first counter value and write it back to the register.

[0065] The chip ID and original rolling code ID are reported to the central server, where a sensor registration record is created.

[0066] In this example, during the sensor chip initialization phase, the chip ID is extracted via hardware scanning logic. The chip ID is a unique 128-bit identifier, programmed by the chip manufacturer at the factory using a one-time programmable fuse or a non-rewritable area, ensuring its uniqueness and immutability. The sensor control logic reads the current first counter value from the power-down holding register. This first counter value represents the number of activations since initialization, initially set to 0x00000001, and automatically increments after each rolling code generation. The sensor obtains the current timestamp, i.e., the first timestamp, through its internal crystal oscillator timing unit, recording the accumulated seconds since the standard time start, represented as a 32-bit unsigned integer. The root key derivation logic is invoked, combining the 256-bit root key pre-stored in the secure area with the chip ID. A 256-bit session key is calculated using an XOR operation or an HMAC derivative function, serving as the dedicated encryption context for this rolling code generation operation. The chip ID, first counter value, and first timestamp are sequentially concatenated to construct a continuous bit stream, used to form the dynamic identity factor. The sensor uses the session key as input and performs a hash operation on the concatenated data using the HMAC-SHA256 hash algorithm to obtain 256-bit intermediate ciphertext, enhancing the uniqueness and sensitivity response to input factors. Using the root key as the encryption key, the AES-128-CTR encryption module performs symmetric encryption on the intermediate ciphertext, and the output ciphertext is the generated 128-bit original rolling code ID. After encryption, the first counter value is incremented by 1 and written back to the register. The sensor packages the generated chip ID and the original rolling code ID into a registration and reporting data structure and reports the data to the central server via a read / write device. The uploaded data is in JSON format and includes the chip ID, rolling code ID, timestamp, production line number, and operator information. Upon receiving the data, the central server creates a corresponding sensor registration record in its MySQL or equivalent database. The record fields include chip ID, initial rolling code, current counter value, registration time, cumulative programming count, maximum programming count limit, status flag, etc., and a unique index is created for the chip ID field.

[0067] In one example, the chip ID and the original rolling code ID are reported to the central server, and a sensor registration record is created on the central server, including:

[0068] The reading and writing device sends an identity reading command and a rolling code request command to the tire pressure sensor, and receives the returned chip ID and original rolling code ID;

[0069] The chip ID and the original rolling code ID are uploaded to the central server, which then generates a registration request upon receiving them.

[0070] The central server creates a sensor registration record based on the registration request, which includes the chip ID, original rolling code ID, maximum number of programming attempts, initial number of programming attempts, and the first counter value.

[0071] In this example, during the sensor's factory quality inspection, a wireless connection is established between the reader / writer and the sensor to be registered via a 13.56MHz near-field communication protocol (such as the ISO15693 standard). The reader / writer sends an identity reading command, such as 0xA5, to the tire pressure sensor. This triggers the sensor's internal logic to read the chip ID in the secure storage area via a specific frame structure. The sensor encapsulates the read 128-bit chip ID into a 16-byte data frame, and completes the response data using a preset frame header, frame trailer, data length field, and CRC checksum, which is then sent back to the reader / writer. The reader / writer sends a rolling code request command, 0xB6, activating the sensor's pre-installed dynamic encryption algorithm module. This module executes a rolling code generation process based on HMAC-SHA256 and AES-128-CTR double-layer encryption, generating the original rolling code ID, which is also returned as a 16-byte data frame. After receiving the chip ID and original rolling code ID, the reader / writer uses these two data points as core identity fields. Combined with other auxiliary information such as production line number, operator ID, and production timestamp, these are packaged into a JSON data packet and uploaded to the central server via Ethernet or local area network. The central server listens for registration request interfaces. Upon receiving the JSON-structured registration request data, it performs a uniqueness check on the chip ID field to prevent duplicate registrations. Once confirmed to be unique, it immediately creates a new sensor registration record in the database. The sensor registration record structure includes fields such as chip ID, original rolling code ID, preset maximum programming attempts (e.g., 50 times), initial programming attempts (0), and current first counter value (initially 1). A unique index is created on the chip ID field. The database records the registration timestamp and sets the sensor status to "active," indicating that the sensor has been successfully registered and has a legitimate identity.

[0072] In one example, the device reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain sensor identification data, including:

[0073] The device sends a wake-up signal and an identity reading command to the tire pressure sensor to be verified via a wireless transceiver module, triggering the tire pressure sensor to enter an active state.

[0074] The tire pressure sensor to be verified responds to the identity reading command, extracts the chip ID and generates a real-time rolling code ID, and then sends it back to the device. The device receives the identity response data.

[0075] The chip ID and real-time rolling code ID in the identity response data are verified for data integrity. After the verification is successful, they are packaged into sensor identity data.

[0076] In this example, after the device is powered on and the communication module is initialized, it sends a continuous wake-up signal to the target tire pressure sensor via its built-in wireless transceiver module (such as a 433MHz or 315MHz ASK modulation module). The wake-up signal uses a carrier pulse with a fixed frequency modulation and a duration of approximately 200 milliseconds to activate the sensor, which is in a 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 is triggered to enter an active state, activating the radio frequency transceiver circuit and switching to command listening mode. The device sends an identity reading command to the sensor. The identity reading command consists of a set of formatted command frames, including fields such as synchronization header, command code, parameter length, and checksum. The command code specifies the type of reading operation, such as reading the chip ID or triggering rolling code generation. When the tire pressure sensor receives the identity reading command, its internal control logic retrieves its preset 128-bit chip ID from the secure storage area. The chip ID is written by the manufacturer at the time of chip manufacturing and cannot be changed, ensuring its uniqueness. The sensor activates its dynamic encryption module. By reading the current counter value and timestamp, and combining them with the session key derived from the chip ID and root key, it executes a dynamic encryption algorithm based on a two-layer structure of HMAC-SHA256 and AES-128-CTR to generate a unique real-time rolling code ID for the current moment. The chip ID and rolling code ID are encapsulated into data frames and transmitted back to the device in a specific format. The data frame structure includes a frame header, data length, data body, CRC16 check field, and frame trailer, used to maintain structure and verifiability in the wireless channel. Upon receiving the identity response data, the device decodes the CRC check field in the data frame and recalculates the CRC value in conjunction with the data body for comparison. This ensures that the data has not been tampered with or has not experienced bit flips during wireless transmission. If the verification fails, the response is discarded and the reading process is re-initiated. After passing the integrity verification, the device 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 a preset format (such as Protocol Buffers).

[0077] In one example, the device sends sensor identity data to the central server via a communication module, forming an authentication request, including:

[0078] The device 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.

[0079] The chip ID, real-time rolling code ID, second counter value, device timestamp and device identifier in the sensor identity data are serialized and encapsulated to obtain the verification request message;

[0080] The authentication request message is sent to the authentication interface of the central server through a secure transmission channel. After receiving the message, the central server generates an authentication request.

[0081] In this example, the device is configured with a data communication module that supports cellular networks, such as a Cat-1 or Cat-4 LTE module, and initializes the network connection process after system startup. Upon power-on, the device accesses the IoT-dedicated cellular network through a preset APN configuration, completing attachment, authentication, and IP address allocation with the operator's core network, and obtaining 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 (TLS) 1.3 protocol. This process includes key exchange, certificate verification, and session key negotiation, generating a symmetric encryption key for all communication data during the connection period, thereby establishing an end-to-end encrypted communication tunnel between the device and the server. The device serializes and encapsulates the sensor identity data, specifically including the chip ID (i.e., the sensor's unique hardware identifier), the real-time rolling code ID (generated in real-time by a dynamic encryption mechanism), a second counter value (representing the sensor's current state counter), a device timestamp (recording the local time at which the identity data was generated), and a 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, forming efficient binary format messages with field identifiers. The device sends the encapsulated verification request message to the designated verification interface of the central server via a TLS encrypted channel. The designated verification interface listens on a dedicated port (such as TCP 8443) and enables the server-side TLS certificate verification mechanism. Upon receiving the verification request message, the server immediately decodes and extracts the content of each field in the message body, reconstructing an authentication request structure containing information such as the sensor chip ID, rolling code ID, and counter value.

[0082] In one example, the central server performs a database comparison of the chip ID and real-time rolling code ID in the authentication request and analyzes the number of programming attempts to generate instructions that allow or disallow programming, including:

[0083] Extract the chip ID from the authentication request and query the database to obtain the corresponding sensor registration record;

[0084] The expected scroll code is recalculated based on the original scroll code ID and chip ID in the sensor registration record. The result is compared with the real-time scroll code ID, and the counter value and programming count are judged to obtain the verification result.

[0085] Based on the verification results, if the rolling code comparison, counter judgment, and programming count judgment all pass, a programming permission instruction is generated; otherwise, a programming disallowment instruction is generated.

[0086] In this example, after receiving the verification request message uploaded by the device, the server parses the message body through deserialization to extract key fields including chip ID, real-time scroll code ID, current counter value, and device timestamp. The chip ID serves as the sensor's unique primary key in the database and is used to initiate the query operation. The server retrieves the complete registration record of the chip from the sensor registration database using an SQL statement: "SELECT * FROM sensor_info WHERE chip_id = 'specified ID' AND sensor_status = 'active'". If the query fails, it indicates the chip has never been registered or is in a blocked or expired state; the server directly returns a verification failure command and ends the processing flow. If the query succeeds, it indicates the chip has been successfully registered and is active, and the multi-dimensional authentication stage begins. The server extracts the original scroll code ID saved during initial registration from the registration record as the encryption key seed and, combined with the chip ID, counter value, and device timestamp from this request, recreates the scroll code generation algorithm process on the sensor side. The server executes the same encryption logic as the sensor locally. First, it derives the session key from the original rolling code ID. Then, it concatenates the chip ID, counter value, and timestamp, calculates the intermediate ciphertext using the HMAC-SHA256 algorithm, and performs a second encryption using AES-128-CTR to generate the desired rolling code. The desired rolling code is compared byte-by-byte with the real-time rolling code ID attached to the verification request. If they match completely, cryptographic authentication is successful; otherwise, it is considered a counterfeit device or illegal data tampering. Based on a successful rolling code comparison, the continuity of the counter value is verified. This requires that the current counter value in the verification request must be greater than the previous value in the database record, and the difference must not exceed a set jump tolerance (e.g., 100) to prevent replay attacks caused by counter rollback or jumps. Finally, it checks whether the programming count has reached its limit by determining if the value of the `program_count` field in the database is less than `program_limit` (e.g., 50 times). If all three conditions are met, the server will recognize the verification as legitimate, generate a programming permission instruction along with an authorization token and information on the remaining programming attempts; if any condition fails, a programming disallowment instruction will be generated and the specific reason for failure will be marked, such as "invalid counter", "inconsistent rolling code", or "programming attempts exhausted".

[0087] Before recalculating the expected rolling code based on the original rolling code ID and chip ID in the sensor registration record and comparing it with the real-time rolling code ID, and before determining the counter value and programming count, the following operations are also included: extracting the historical counter value and historical verification timestamp from the sensor registration record at the time of the most recent successful verification; calculating the difference between the second counter value and the historical counter value to obtain the counter increment; calculating the difference between the device timestamp and the historical verification timestamp to obtain the time interval; dividing the counter increment by the time interval to obtain the counter growth rate; determining whether the counter growth rate is within the preset reasonable rate range; if the counter growth rate is too high, it is marked as a high-frequency anomaly; if the counter growth rate is too low, it is marked as a low-frequency anomaly; reading the historical verification record table from the sensor registration record, calculating the average time interval of the most recent N verification requests as the normal usage time interval benchmark; calculating the deviation ratio between the current time interval and the normal usage time interval benchmark; when the deviation ratio is less than the first deviation threshold, it is determined to be in normal usage mode; when the deviation ratio is greater than the first deviation threshold but less than the second deviation threshold... When the deviation ratio exceeds the second deviation threshold, it is determined to be an intermittent abnormal mode. When the deviation ratio exceeds the second deviation threshold, it is determined to be a long-term shutdown and restart mode. For normal use mode, the preset counter deviation allowable range and time window threshold are kept unchanged, and the difference between the second counter value and the first counter value is judged according to the standard judgment rule. For intermittent abnormal mode, the counter deviation allowable range is increased by 50%, and an additional rolling code secondary verification requirement is added in subsequent verification. For long-term shutdown and restart mode, the counter deviation allowable range is increased to three times the preset value, and the device is required to provide additional device identity authentication information as auxiliary verification. The timestamp sequence of the most recent M programming operations is extracted from the sensor registration record, the time interval sequence between two adjacent programming operations is calculated, and the programming frequency feature value is obtained by statistical analysis of the time interval sequence. The current time interval is compared with the programming frequency feature value. If the current time interval is significantly less than the minimum value of the programming frequency feature value, it is marked as abnormal high-frequency programming. If the cumulative number of abnormal high-frequency programming reaches the preset number, the safety level of the tire pressure sensor is downgraded.

[0088] In one example, the expected scroll code is recalculated based on the original scroll code ID and chip ID in the sensor registration record, compared with the real-time scroll code ID, and the counter value and programming count are used to determine the verification result, including:

[0089] Extract the original rolling code ID from the sensor registration record as the key seed, combine it with the chip ID, the second counter value in the authentication request, and the device timestamp to perform dynamic encryption and generate the desired rolling code;

[0090] The expected scroll code is compared byte by byte with the real-time scroll code ID in the authentication request to obtain the scroll code comparison result. The second counter value is determined to be greater than the first counter value in the sensor registration record and the difference is within the set range to obtain the counter determination result. The cumulative programming count in the sensor registration record is determined to be less than the upper limit of programming count to obtain the programming count determination result.

[0091] The verification is considered successful if the rolling code comparison result is consistent, the counter judgment result is successful, and the programming count judgment result is within the limit; otherwise, the verification is considered unsuccessful, and the verification result is obtained.

[0092] In this example, after receiving the authentication request message uploaded by the device, the central server extracts fields such as chip ID, real-time rolling code ID, second counter value, and device timestamp through deserialization. Using the chip ID as the primary key, it queries the sensor information database to obtain the corresponding sensor registration record. From the registration record, the server extracts the original rolling code ID as the key seed in the key derivation process. It performs an HMAC-SHA256 hash operation on the key seed and chip ID to generate the current session key. The chip ID, second counter value, and device timestamp are concatenated sequentially into a unified data string. Using the session key as the input key, it performs another HMAC-SHA256 hash operation to generate 256-bit intermediate ciphertext. Using the root key stored in the registration record or its last 128 bits as the AES-128-CTR encryption key, it performs symmetric encryption on the intermediate ciphertext to generate the desired 128-bit rolling code. The server compares the expected scrolling code with the real-time scrolling code ID uploaded in the authentication request byte by byte. If the two are completely identical within the entire 16 bytes (128 bits), the scrolling code match is considered successful; otherwise, it is considered inconsistent and regarded as identity forgery or an illegal request. Simultaneously, the server checks the validity of a counter, verifying whether the second counter value is greater than the first counter value in the registration record and the difference does not exceed a preset tolerance range (e.g., no greater than 100) to allow offline activation but prevent rollback and abnormal jumps. If this condition is met, the counter is considered valid. The server compares the cumulative programming count field in the registration record with its corresponding maximum programming count field. If the current programming count is less than the preset maximum (e.g., 50 times), the programming count judgment is considered successful. The scrolling code comparison result, the counter validity judgment result, and the programming count limit judgment result are combined logically. When all three are satisfied, the verification request is deemed legitimate and enters the programming authorization process; if any one is not satisfied, the verification is considered failed and authorization is rejected.

[0093] The process involves extracting the original rolling code ID from the sensor registration record as a key seed, combining it with the chip ID, the second counter value from the authentication request, and the device timestamp to perform dynamic encryption and generate the desired rolling code. This includes: extracting the original rolling code ID from the sensor registration record as an initial key seed, performing an XOR operation with the chip ID to obtain a session key seed, and then performing a key derivation function operation with the session key seed and the second counter value to generate the current session key; concatenating the chip ID, the second counter value, the device timestamp, and the current server timestamp of the central server, performing an HMAC-SHA256 hash operation on the concatenated data using the current session key to obtain a first hash value, and taking the high 128 bits of the first hash value as the first intermediate ciphertext; encrypting the first intermediate ciphertext using the last 128 bits of the original rolling code ID as an AES key using AES-128-CTR, using the second counter value as the initial counter value to generate the desired rolling code; calculating the time difference between the device timestamp and the server timestamp, determining whether the absolute value of the time difference is less than a preset time window threshold, and if it exceeds the preset time window threshold, determining it as a time anomaly and marking the desired rolling code as invalid.

[0094] When the verification result indicates a failure, the central server performs the following operations: It reads the safety status field and the consecutive failure count field from the sensor registration record, and classifies the failure cause into three types based on the failure type in the verification result: rolling code mismatch failure, counter abnormal failure, or programming count exceeding limit failure. For rolling code mismatch failure, it increments the consecutive failure count field by 1, checks if the consecutive failure count is less than a first failure threshold. If it is less than the first failure threshold, it sets the safety status field to a warning state and generates a restricted programming instruction containing the remaining retries. If it reaches the first failure threshold, it sets the safety status field to a temporary lock state and generates a restricted programming instruction containing the lock time. Long programming instructions are not allowed; for counter failures, it is determined whether the difference between the second counter value and the first counter value is within the recoverable range. If it is within the recoverable range, a counter synchronization request instruction is generated and the safety status field is marked as synchronizing. The counter synchronization request instruction carries the first counter value as a reference value and waits for the device to perform a synchronization reset operation on the tire pressure sensor counter before re-initiating verification; for programming failures due to exceeding the limit, the safety status field is set to the number of attempts exhausted state, the time of exceeding the limit and the last requested device identifier are recorded in the sensor registration record, a programming instruction not allowed containing the reason code for exceeding the limit is generated, and the event of exceeding the limit is written to the exception audit log table.

[0095] In one example, the device programs the tire pressure sensor according to the programmed instructions and sends feedback to the central server to update the cumulative programming count in the sensor registration record, including:

[0096] Extract the authorization token from the programming permission instruction, encapsulate the authorization token in the programming preparation instruction and send it to the tire pressure sensor. After receiving the instruction, the tire pressure sensor unlocks the parameter configuration area and replies with a readiness confirmation message.

[0097] Based on the readiness confirmation information, the programming data is transmitted to the tire pressure sensor in blocks. After each data block is transmitted, the verification value returned by the tire pressure sensor is received and verified. After all data blocks are transmitted, the tire pressure sensor solidifies the parameters and returns a programming success response message.

[0098] Based on the successful programming response information, the chip ID, the third counter value, and the programming timestamp are encapsulated into a programming completion notification and sent to the central server. The central server updates the cumulative programming count in the sensor registration record and updates the third counter value to the first counter value.

[0099] In this example, after the device receives a successful verification response message from the central server, it parses out the 128-bit authorization token contained within. This authorization token is generated by the server using the HMAC-SHA256 algorithm based on the chip ID, rolling counter value, and a server-generated random number. It is characterized by single-use and short-term validity. The authorization token is embedded in the programming preparation instruction, which includes a synchronization header, function code (e.g., 0xD1), parameter length field, authorization token data body, and checksum field. This instruction is then sent to the tire pressure sensor to be programmed via a low-frequency wireless communication module (e.g., 433MHz ASK). Upon receiving the programming preparation instruction containing the authorization token, the tire pressure sensor executes its local verification logic to verify the token's validity and integrity. If verification is successful, it automatically releases the write protection of its parameter configuration register and firmware update area, enters programming-ready mode, and returns a ready confirmation response to the device using a fixed response code (e.g., 0xAC) to indicate successful reception and readiness to begin programming. After receiving the readiness confirmation, the device initiates the programming data transmission process, dividing the preset programming data into blocks, for example, 128 bytes per block, and sending them to the sensor one block at a time. After each block is sent, the sensor performs a CRC32 check or equivalent verification on the data block and sends the calculated check value back to the device for comparison and confirmation. If the comparison passes, the next block of data is transmitted; if the comparison fails, retransmission logic is triggered, up to three times. If the retransmission still fails, the programming operation is aborted and an exception handling process is initiated. Once all data blocks have been successfully transmitted and verified, the device sends a programming end command, instructing the sensor to persistently write all received parameters to its non-volatile memory (such as EEPROM), update the programming completion flag in its internal status register, and increment the current counter value for synchronization with the next round of verification logic. After writing is complete, the sensor returns a programming success response message (such as 0xEE) to the device, indicating that the parameter update has officially taken effect. Upon receiving the response message, the device encapsulates the chip ID, the currently used third counter value, and the programming timestamp obtained locally by the device into a programming completion notification and sends it to the central server via a TLS encrypted channel. After receiving the programming completion notification, the server parses its structure and performs a status update operation on the corresponding record in the sensor registration database, including: incrementing the cumulative programming count 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.

[0100] Before transmitting programming data to the tire pressure sensor in blocks based on readiness confirmation information, the following operations are included: extracting a 128-bit token master key from the authorization token; performing HMAC-SHA256 operation on the token master key and chip ID to obtain the programming session root key; generating an independent block encryption key for each data block using a key derivation function based on the programming session root key and data block sequence number; dividing the programming data into multiple plaintext data blocks of fixed block size and assigning an incrementing block sequence number to each plaintext data block; using the block encryption key corresponding to the block sequence number to encrypt each plaintext data block using AES-128-CBC to obtain encrypted data blocks; and calculating... The SHA256 hash value of each encrypted data block is used as the block hash value. The block hash value of the first encrypted data block is used as the initial chain hash value. Starting from the second encrypted data block, the block hash value of the previous encrypted data block is concatenated with the plaintext data of the current encrypted data block, and then the hash value is calculated to form a chain hash value sequence. This generates a programming data packet containing all encrypted data blocks, block numbers, block hash values, and chain hash values. The programming session root key and integrity verification parameters are encapsulated in the extended field of the programming preparation instruction and sent to the tire pressure sensor along with the authorization token. After receiving the authorization token, the tire pressure sensor extracts the programming session root key and derives the encryption keys for each block.

[0101] In one example, programming data is transmitted to the tire pressure sensor in blocks based on readiness confirmation information. Each data block is transmitted, and a checksum returned by the tire pressure sensor is received and verified. After all data blocks have been transmitted, the tire pressure sensor's parameters are fixed, and a programming success response message is returned, including:

[0102] Based on the readiness confirmation information, the programming data is divided into multiple data blocks and transmitted sequentially to the tire pressure sensor;

[0103] After receiving each data block, the tire pressure sensor calculates the CRC32 check value and sends it back. The device verifies the CRC32 check value. If the verification fails, the data block is retransmitted. If the verification passes, the next data block is transmitted.

[0104] Once all data blocks have passed verification, a programming end command 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 the third counter value. After completion, it returns a programming success response message.

[0105] In this example, based on the readiness confirmation information, the programming data to be sent is logically divided into blocks of a predetermined size, such as a fixed-length data structure of 128 bytes per block, forming an ordered set of data blocks. Starting with the first data block, the device sends data block by block to the tire pressure sensor in programming mode. Each data block is transmitted to the sensor receiving module via a wireless communication link. After receiving each data block, the tire pressure sensor calls its internal verification logic module to perform a CRC32 cyclic redundancy check operation on the received data, obtaining the corresponding 32-bit checksum, and encapsulates the checksum into a response data frame to send back to the device. Upon receiving the CRC32 checksum returned by the sensor, the device compares the CRC32 checksum with the CRC32 result calculated locally for the same data block before transmission. If they match, it indicates that the data block has not been corrupted or bit-errored during wireless transmission, and the device proceeds to the next data transmission block. If the CRC checksum results are inconsistent, it indicates that an error occurred during transmission, and the device retransmits the current data block and waits for the sensor's verification response again. For each data block, the device allows a maximum of 3 retransmissions. If three consecutive retransmissions fail, the programming operation is aborted, triggering an error handling mechanism and prompting the user to check communication stability or sensor status. Once all data blocks have passed verification and been successfully transmitted, the device sends a programming end command, informing the tire pressure sensor that the current programming data transmission is complete and requesting it to perform parameter writing. Upon receiving the programming end command, the tire pressure sensor writes all verified data blocks from the temporary RAM buffer to a non-volatile storage medium, such as EEPROM or Flash memory, to ensure the programming data is retained even in the event of a power outage. Simultaneously, after writing, it increments the internal second counter value used for authentication by 1 to obtain the third counter value. After the data writing and counter update operations are complete, the tire pressure sensor sends a programming success response message back to the device, indicating that the programming has been solidified and the status has been updated.

[0106] Reference Figure 2 This embodiment provides a tire pressure sensor authentication system based on dynamic encryption, including:

[0107] Reading module 1 is used by the device to read the chip ID and real-time rolling code ID of the tire pressure sensor to be verified, and obtain the sensor identity data;

[0108] Authentication module 2 is used by the device to send sensor identity data to the central server through the communication module to form an authentication request;

[0109] Comparison module 3 is used by the central server to perform database comparison between the chip ID and real-time rolling code ID in the authentication request and analyze the number of programming attempts to generate instructions that allow or disallow programming.

[0110] Programming module 4 is used by the device to program the tire pressure sensor according to the allowed programming instructions and to report back to the central server to update the cumulative number of programming times in the sensor registration record.

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

[0112] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, system, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, system, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, system, article, or method that includes that element.

[0113] The above description is only a preferred embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A tire pressure sensor authentication method based on dynamic encryption, characterized in that, include: The chip ID, first counter value, and first timestamp of the tire pressure sensor are read, and a session key is derived from the root key. The chip ID, first counter value, and first timestamp are concatenated to obtain concatenated data. The session key is used to perform a hash operation on the concatenated data to obtain intermediate ciphertext. The root key is used as the encryption key to encrypt the intermediate ciphertext, generating an original rolling code ID. The first counter value is incremented and written back to the register. The chip ID and the original rolling code ID are reported to the central server, and a sensor registration record is created in the central server. The device reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain the sensor's identity data; The device sends the sensor identity data to the central server via the communication module to form an authentication request. The central server performs a database comparison of the chip ID and real-time rolling code ID in the authentication request and analyzes the number of programming attempts to generate a programming permission instruction or a programming permission instruction. The device performs programming operations on the tire pressure sensor according to the programming permission instruction and feeds back to the central server to update the cumulative number of programming operations in the sensor registration record.

2. The tire pressure sensor authentication method based on dynamic encryption according to claim 1, characterized in that, The chip ID and the original rolling code ID are reported to the central server, and a sensor registration record is created in the central server, including: The reading and writing device sends an identity reading instruction and a rolling code request instruction to the tire pressure sensor, and receives the returned chip ID and the original rolling code ID; The chip ID and the original rolling code ID are uploaded to the central server, and the central server generates a registration request upon receiving them. The central server creates a sensor registration record based on the registration request, which includes the chip ID, the original rolling code ID, the maximum number of programming attempts, the initial number of programming attempts, and the first counter value.

3. The tire pressure sensor authentication method based on dynamic encryption according to claim 1, characterized in that, The device reads the chip ID and real-time rolling code ID of the tire pressure sensor to be verified to obtain sensor identification data, including: The device sends a wake-up signal and an identity reading command to the tire pressure sensor to be verified via a wireless transceiver module, triggering the tire pressure sensor to enter an active state. The tire pressure sensor to be verified responds to the identity reading command, extracts the chip ID and generates a real-time rolling code ID, and then sends it back to the device. The device receives the identity response data. The chip ID and the real-time rolling code ID in the identity response data are verified for data integrity. After the verification is successful, they are encapsulated as sensor identity data.

4. The tire pressure sensor authentication method based on dynamic encryption according to claim 1, characterized in that, The device sends the sensor identity data to the central server via a communication module, forming an authentication request, including: The device establishes a data connection with the mobile network through a 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 identifier 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 generates an authentication request upon receiving it.

5. The tire pressure sensor authentication method based on dynamic encryption according to claim 1, characterized in that, The central server performs a database comparison of the chip ID and real-time rolling code ID in the authentication request and analyzes the number of programming attempts to generate instructions that allow or disallow programming, including: Extract the chip ID from the authentication request and query the database to obtain the corresponding sensor registration record; Based on the original scroll code ID in the sensor registration record and the chip ID, the expected scroll code is recalculated and compared with the real-time scroll code ID. The counter value and the number of programming attempts are then evaluated to obtain the verification result. Based on the verification results, if the rolling code comparison, counter determination, and programming count determination all pass, a programming permission instruction is generated; otherwise, a programming disallowment instruction is generated.

6. The tire pressure sensor authentication method based on dynamic encryption according to claim 5, characterized in that, The process of recalculating the expected scroll code based on the original scroll code ID in the sensor registration record and the chip ID, comparing it with the real-time scroll code ID, and determining the counter value and programming count to obtain the verification result includes: Extract the original scroll code ID from the sensor registration record as a key seed, and perform dynamic encryption by combining the chip ID, the second counter value in the authentication request, and the device timestamp to generate the desired scroll code; The expected scroll code is compared byte by byte with the real-time scroll code ID in the authentication request to obtain the scroll code comparison result. The second counter value is determined to be greater than the first counter value in the sensor registration record and the difference is within a set range to obtain the counter determination result. The cumulative programming count in the sensor registration record is determined to be less than the upper limit of programming count to obtain the programming count determination result. The verification is considered successful when the rolling code comparison result is consistent, the counter determination result is successful, and the programming count determination result is within the limit; otherwise, the verification is considered unsuccessful, and the verification result is obtained.

7. The tire pressure sensor authentication method based on dynamic encryption according to claim 1, characterized in that, The device performs programming operations on the tire pressure sensor according to the programmed instructions and feeds back to the central server to update the cumulative number of programming attempts in the sensor registration record, including: The authorization token is extracted from the programming permission instruction, and the authorization token is encapsulated in the programming preparation instruction and sent to the tire pressure sensor. After receiving the instruction, the tire pressure sensor unlocks the parameter configuration area and replies with a readiness confirmation message. Based on the readiness confirmation information, programming data is transmitted to the tire pressure sensor in blocks. Each time a data block is transmitted, the verification value returned by the tire pressure sensor is received and verified. After all data blocks are transmitted, the tire pressure sensor solidifies the parameters and returns a programming success response message. Based on the successful programming response information, the chip ID, the third counter value, and the programming timestamp are encapsulated into a programming completion notification and sent to the central server. The central server updates the cumulative programming count in the sensor registration record and updates the third counter value to the first counter value.

8. The tire pressure sensor authentication method based on dynamic encryption according to claim 7, characterized in that, The programming data is transmitted to the tire pressure sensor in blocks based on the readiness confirmation information. For each data block transmitted, a verification value returned by the tire pressure sensor is received and verified. After all data blocks have been transmitted, the tire pressure sensor's parameters are fixed and a programming success response message is returned, including: Based on the readiness confirmation information, the programming data is divided into multiple data blocks and transmitted sequentially to the tire pressure sensor; After receiving each data block, the tire pressure sensor calculates the CRC32 check value and sends it back. The device verifies the CRC32 check value. If the verification fails, the data block is retransmitted. If the verification passes, the next data block is transmitted. Once all data blocks have passed verification, a programming end command is sent to the tire pressure sensor. The tire pressure sensor writes the programming data into a non-volatile memory area and increments the second counter value to obtain the third counter value. After completion, it returns a programming success response message.

9. A tire pressure sensor authentication system based on dynamic encryption, characterized in that, The steps for implementing the tire pressure sensor authentication method based on dynamic encryption as described in any one of claims 1 to 8 include: The reading module is used by the device to read the chip ID and real-time rolling code ID of the tire pressure sensor to be verified, and obtain the sensor identity data. An authentication module is used by the device to send the sensor identity data to the central server through the communication module to form an authentication request. The comparison module is used by the central server to perform database comparison of the chip ID and real-time rolling code ID in the authentication request and analyze the number of programming attempts to generate a programming instruction that allows or disallows programming. The programming operation module is used by the device to program the tire pressure sensor according to the programming permission instruction and to report back to the central server to update the cumulative number of programming times in the sensor registration record.

Images