Key increment burning method, device and medium based on version control

Abstract

The application provides a version control-based key incremental burning method, device and medium. The method comprises the following steps: obtaining a first key of a corresponding device end and a first version number corresponding to the first key from a device key database according to a target key identifier; generating a second key and a second version number corresponding to the second key according to the first key and the first version number; the second version number is higher than the first version number; performing incremental difference and encryption processing on the first key and the second key to obtain target encrypted data; determining a target data packet according to the target key identifier, the target encrypted data, the first version number and the second version number, and sending the target data packet to the device end; receiving update completion information returned by the device end, and updating the device key database according to the second key and the second version number. The key difference data instead of the complete key can be transmitted, so that the transmission cost is reduced and the key distribution and updating efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of key burning technology, and in particular to a method, device and medium for incremental key burning based on version control. Background Technology

[0002] In distributed connector device management scenarios, the server needs to perform batch operations such as key distribution, online updates, and key revocation for a large number of connector devices. Traditional key update methods often use full key transmission and overall replacement mechanisms, which suffer from problems such as large data transmission volume, high bandwidth consumption, and low update efficiency. At the same time, they lack key version control, incremental updates, and fault tolerance rollback capabilities, and cannot meet the high-efficiency and secure key iteration requirements of large-scale device clusters.

[0003] Therefore, improving the efficiency of key distribution and update is an urgent issue to be addressed. Summary of the Invention

[0004] This application provides a version-controlled incremental key burning method, device, and medium. The server manages the keys on the device in a versioned manner. When updating the key, only the first key and the second key are incrementally differentially processed and encrypted to obtain the target encrypted data. The target data packet carrying the version identifier is then sent to the device for incremental merging and version update, avoiding the full transmission of the complete key data and improving the efficiency of key distribution and update.

[0005] In a first aspect, embodiments of this application provide a version-controlled incremental key burning method, applied to a server, the method comprising: Based on the target key identifier, the first key of the corresponding device and the first version number corresponding to the first key are obtained from the device key database; the target key identifier is the key identifier corresponding to the key that needs to be incrementally burned; the device key database is a database used by the server to store multiple historical version data of different types of keys for each device. Based on the first key and the first version number, a second key and a second version number corresponding to the second key are generated; the second version number is higher than the first version number. Incremental differential and encryption processing is performed on the first key and the second key to obtain the target encrypted data; The target data packet is determined based on the target key identifier, the target encrypted data, the first version number, and the second version number, and the target data packet is sent to the device. The device receives update completion information returned by the device and updates the device key database according to the second key and the second version number; the update completion information indicates that the device has completed the version update of the first key.

[0006] Secondly, embodiments of this application provide a version-controlled incremental key burning method, applied to a device, the method comprising: Receive the target data packet sent by the server; the target data packet includes the target key identifier, target encrypted data, first version number, second version number, differential offset, differential length, local timestamp, and target signature; Obtain the local key database, root key, and device private key corresponding to the device; Based on the target key identifier and the first version number, the local key database is queried to obtain the reference encryption key; The reference encryption key is decrypted using the stored root key to obtain the first key; The target encrypted data is decrypted using the device's private key to obtain incremental differential data; Based on the differential offset and the differential length, the first key and the incremental differential data are incrementally merged to obtain the second key; The second key is encrypted and stored in the local key database, and an update completion message is returned to the server.

[0007] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the programs include instructions for performing steps in any method of the first aspect of this application.

[0008] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program for electronic data interchange, wherein the computer program causes a computer to perform some or all of the steps described in any method of the first aspect of this application.

[0009] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps described in any method of the first aspect of this application. The computer program product may be a software installation package.

[0010] As can be seen, by managing the keys on the device side in a versioned manner on the server side, when the key is updated, only the first key and the second key are incrementally differentially processed and encrypted to obtain the target encrypted data. The target data packet carrying the version identifier is then sent to the device side for incremental merging and version update, avoiding the transmission of the complete key data and improving the efficiency of key distribution and update. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a system architecture diagram of a key incremental burning system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the interaction process between a server and a device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a version control-based incremental key burning method provided in an embodiment of this application; Figure 5 This is a flowchart illustrating another version-controlled incremental key burning method provided in this application embodiment; Figure 6 This is a schematic diagram of a key encryption storage process provided in an embodiment of this application; Figure 7 This is a functional module block diagram of a version control-based incremental key burning device provided in an embodiment of this application; Figure 8 This is a block diagram of the functional modules of another version-controlled incremental key burning device provided in this application embodiment. Detailed Implementation

[0013] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0014] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0015] It should be understood that the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, "multiple" refers to two or more.

[0016] In the embodiments of this application, "at least one item" or its similar expression refers to any combination of these items, including any combination of a single item or a plurality of items. "One or more" means one or more, while "multiple" means two or more. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0017] In this application, the term "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. This application does not impose any limitations on this.

[0018] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0019] In distributed connector device management scenarios, the server needs to perform batch operations such as key distribution, online updates, and key revocation for a large number of connector devices. Traditional key update methods often use full key transmission and overall replacement mechanisms, which suffer from problems such as large data transmission volume, high bandwidth consumption, and low update efficiency. At the same time, they lack key version control, incremental updates, and fault tolerance rollback capabilities, and cannot meet the high-efficiency and secure key iteration requirements of large-scale device clusters.

[0020] Therefore, improving the efficiency of key distribution and update is an urgent issue to be addressed.

[0021] To address the aforementioned issues, this application provides a version-controlled incremental key burning method, device, and medium. First, based on a target key identifier, a first key and its corresponding first version number are obtained from a device key database. The target key identifier is the key identifier corresponding to the key currently requiring incremental burning. The device key database is a server-side database used to store multiple historical version data of different types of keys for each device. Then, based on the first key and the first version number, a second key and its corresponding second version number are generated. The second version number is higher than the first version number. Incremental differential and encryption processing is performed on the first key and the second key to obtain target encrypted data. Next, a target data packet is determined based on the target key identifier, the target encrypted data, the first version number, and the second version number, and the target data packet is sent to the device. An update completion message is received from the device, and the device key database is updated based on the second key and the second version number. The update completion message indicates that the device has completed the version update of the first key.

[0022] As can be seen, by managing the keys on the device side in a versioned manner on the server side, when the key is updated, only the first key and the second key are incrementally differentially processed and encrypted to obtain the target encrypted data. The target data packet carrying the version identifier is then sent to the device side for incremental merging and version update, avoiding the transmission of the complete key data and improving the efficiency of key distribution and update.

[0023] For easier understanding, please refer to Figure 1 , Figure 1 This is a system architecture diagram of a key incremental burning system provided in an embodiment of this application. The key incremental burning system includes a server and multiple devices. The server and each device are connected through network communication. The server can send target data packets to each device to perform key incremental burning operations on the specified target device.

[0024] The server is used to manage the versioning of various keys on each device. When a key update is required, it performs incremental differential calculation based on the first key currently in effect on the device and the newly generated second key, and encapsulates the differential data, version identifier and security verification information into a target data packet and sends it to the device.

[0025] The device receives the target data packet, performs security verification and decryption, incrementally merges the differential data with the locally stored first key to restore the second key, and encrypts and seals the second key for storage, while retaining the first key for abnormal rollback.

[0026] As can be seen, by managing keys in a versioned manner on the server side and transmitting only the differential data between the old and new keys, the device side restores the new key based on the differential data and the local old key, and retains both the old and new versions. This significantly reduces network transmission overhead, while achieving full traceability of key status and rapid version rollback in case of update anomalies, thus improving the efficiency of key distribution and update.

[0027] For easier understanding, please refer to Figure 2 , Figure 2 This is a schematic diagram of the interaction process between a server and a device, provided in an embodiment of this application. In a large-scale distributed connector device management scenario, the server acts as a centralized management node, responsible for the unified versioning management and distribution of various keys from multiple devices. Each device maintains its own local key database and trusted platform module, with key data isolated from each other.

[0028] When performing incremental key programming on different devices, the server performs the following operations for each device: Based on the device's unique identifier and target key identifier, it extracts the currently effective first key and first version number from the device key database, generates a second key and second version number, performs incremental differential calculation on the first and second keys corresponding to the device, and encrypts the differential data using the device's public key to generate target encrypted data that only that device can decrypt. Finally, it sends the target data packet carrying the target encrypted data, version identifier, and security verification information to the target device. Because different devices hold their own independent private keys, even if the target data packet of one device is intercepted by another device during transmission, the interceptor cannot decrypt it to obtain the differential data because it does not hold the corresponding device private key, thus ensuring secure isolation of the incremental key programming operation between devices. After receiving the target data packet, the device sequentially completes signature verification, version validity verification, differential decryption, key XOR merging, and sealed storage of the new key, while retaining the old key for fault rollback. After all processing is successful, it sends update completion information back to the server. After receiving the update completion information, the server synchronously updates the version record of the device key database, completing the closed loop of single key incremental burning.

[0029] It should be noted that when batch key updates are required for multiple devices, the server can generate separate target data packets for each device and distribute them sequentially in parallel or serial mode. Since each target data packet only carries differential data of the key change fragment rather than the complete key, network bandwidth can be significantly saved and the overall key distribution and update efficiency can be improved in scenarios involving synchronous updates of large-scale device clusters.

[0030] The following is combined Figure 3The electronic devices in the embodiments of this application will be described. Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 3 As shown, the electronic device includes one or more processors, a memory, a communication interface, and one or more programs. The processor is connected to the memory and the communication interface via an internal communication bus.

[0031] The one or more programs are stored in the aforementioned memory and configured to be executed by the aforementioned processor, and the one or more programs include instructions for performing any step in the above method embodiments.

[0032] The processor can be a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, cells, and circuits described in conjunction with the disclosure of this application. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. The communication unit can be a communication interface, transceiver, transceiver circuit, etc., and the storage unit can be a memory.

[0033] The memory can be volatile or non-volatile, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0034] It is understood that the electronic device may include more or fewer structural elements than those shown in the block diagram above, such as a power module, physical buttons, a Wi-Fi module, a speaker, a Bluetooth module, sensors, a display module, etc., without limitation. It is understood that the electronic device may incorporate elements such as... Figure 1 The system architecture described above.

[0035] After understanding the software and hardware architecture of this application, the following will be combined with... Figure 4 This application describes a version-controlled incremental key burning method in an embodiment. Figure 4 This is a flowchart illustrating a version-controlled incremental key burning method provided in this application embodiment, applied to the server side, and specifically includes the following steps: Step S11: Based on the target key identifier, obtain the corresponding first key of the device and the first version number corresponding to the first key from the device key database.

[0036] The target key identifier is the key identifier corresponding to the key that needs to be incrementally programmed. The device key database is a database used by the server to store multiple historical versions of keys of different types for each device. Specifically, when performing incremental key programming, the server first retrieves the first key currently used by the device and its corresponding first version number from the device key database based on the target key identifier. The target key identifier is the key identifier corresponding to the key that needs to be incrementally programmed, used to distinguish different types of keys, such as key encryption key (KEK), data encryption key (DEK), or session key. The device key database is a database pre-built by the server to store multiple historical versions of keys of different types for each device. This device key database uses the device's unique identifier and key type (divided by key identifier) ​​as index dimensions, configuring independent and incremental version numbers for each type of key for each device, encrypting and storing all historical version keys, and recording the current effective version and reclaimable status of each key in real time.

[0037] The specific steps of obtaining the first key of the first device and the first version number corresponding to the first key from the device key database based on the target key identifier include: S111. Obtain the unique device identifier of the device. S112. Based on the device unique identifier and the target key identifier, query the device key database to obtain multiple reference keys and multiple reference version numbers; S113. Obtain the latest version number from the plurality of reference version numbers to obtain the first version number; S114. Determine the first key corresponding to the first version number among the plurality of reference keys.

[0038] In a specific embodiment, firstly, the server obtains the unique device identifier corresponding to the target device for this incremental programming task. The unique device identifier can be the serial number programmed at the device's factory, the media access control address, or a device number uniformly assigned to each device by the server, used to uniquely distinguish different devices in the device key database. Then, the server uses the unique device identifier and the target key identifier as query conditions to search the device key database. Since the device key database stores multiple historical versions of the same type of key for the same device, the query results typically include all historical versions of the key for that device under that key type, i.e., multiple reference keys, and multiple reference version numbers corresponding one-to-one with each reference key. For example, taking the KEK key of device DEV_001 as an example, the query results may include historical key data for multiple versions such as KEK_v1 and KEK_v2.

[0039] Next, the server sorts and compares the multiple reference version numbers obtained from the query. Since the version numbers are assigned using an incremental allocation strategy, a larger version number indicates a newer version. The server selects the version number with the largest value as the first version number, which corresponds to the key version currently in effect on the device. Then, it extracts the reference key corresponding to this first version number from the multiple reference keys, and uses it as the first key. This first key is the key currently in effect on the device and will serve as the basis for subsequent incremental differential calculations.

[0040] It should be noted that if the server uses encrypted storage when writing the first key into the device key database, it needs to be decrypted before reading. If the server is deployed in a physically isolated secure data center, and the device key database has strict access control and network security protection, and the first key is stored in plaintext, the retrieved first key can be directly used for subsequent differential calculations without additional decryption steps.

[0041] As can be seen, by using a dual-index query mechanism of device unique identifier and target key identifier, all historical version data of the target device under the target key type can be accurately extracted from the device key database, and the current effective key can be automatically located using the latest version number as the first version number, thus ensuring the accuracy of incremental differential calculation and the reliability of version tracing.

[0042] Step S12: Generate a second key and a second version number corresponding to the second key based on the first key and the first version number.

[0043] Specifically, the second version number is higher than the first version number. The server can call a preset random number generation algorithm to generate a random byte sequence of the same length as the first key as the second key. This random number generation algorithm can be a key generation method based on a true random number generator or a cryptographically secure pseudo-random number generator, ensuring that the generated second key has sufficient entropy and unpredictability. The server can also use the first key as input and call a preset key derivation function to generate the second key. This key derivation function can be a hash-based message authentication code or a key derivation algorithm, which derives new key data from the first key by introducing parameters such as salt or iteration count. The server increments the first version number to obtain the second version number. Because the version number uses a monotonically increasing allocation strategy, the value of the second version number is strictly greater than the first version number, thus ensuring the continuity and order of the version numbers. For example, if the first version number is 2, the second version number can increment to 3.

[0044] Step S13: Perform incremental differential encryption on the first key and the second key to obtain the target encrypted data.

[0045] The specific steps for performing incremental differential and encryption processing on the first key and the second key to obtain the target encrypted data include: S131. Convert the first key and the second key into a first byte array and a second byte array, respectively; S132. Determine the key update interval based on the preset differential offset and differential length; S133. Within the key update interval, perform a byte-by-byte XOR operation on the first byte array and the second byte array to obtain incremental differential data. S134. Obtain the device public key corresponding to the device, and encrypt the incremental differential data according to the device public key to obtain the target encrypted data.

[0046] In a specific embodiment, since the keys are typically stored in a specific data format on the server, to facilitate byte-by-byte differential operations, the server first converts the format of the first and second keys, representing them as equal-length first and second byte arrays, respectively. Taking a 256-bit key as an example, the converted byte array is 32 bytes long. If the lengths of the first and second keys are inconsistent, the server can first use padding or truncation operations to make them equal in length before performing the conversion.

[0047] Then, the server defines the key update interval on the first and second byte arrays according to the preset differential offset and differential length. The differential offset indicates the starting byte position of the key update interval, and the differential length indicates the number of consecutive bytes from that starting position that require differential operations. For example, when the differential offset is 16 and the differential length is 32, the key update interval covers bytes 16 to 47. The preset differential offset and differential length can be flexibly configured according to the actual range of key changes. When only a partial segment of the key changes, differential operations on the entire key are unnecessary; only the changed interval needs to be processed, further reducing computation and transmission load. In scenarios involving a full key change, the differential offset can be set to 0, and the differential length can be set to the total key length.

[0048] Next, the server iterates through each byte position within the key update interval, performing an XOR operation between the corresponding byte value in the first byte array and the corresponding byte value in the second byte array to obtain the difference byte at that position. After the iteration is complete, all difference bytes form the incremental differential data. Within the key update interval, each byte of the second key is equal to the result of an XOR operation between the corresponding byte of the first key and the corresponding byte of the differential data. Therefore, after receiving the incremental differential data, the device only needs to perform an XOR operation with the corresponding interval of the locally stored first key to reconstruct the data for that interval of the second key. For bytes outside the key update interval, the second key remains consistent with the first key and requires no further processing.

[0049] Then, the server obtains the corresponding device public key from the device. This device public key can be the public key portion of the asymmetric key pair registered by the device with the server during the initialization phase. The server uses this device public key to perform asymmetric encryption on the incremental differential data to obtain the target encrypted data. Since the device private key corresponding to the device public key is only stored locally on the device, even if the target encrypted data is intercepted by a third party during transmission, the third party cannot decrypt it to obtain the incremental differential data because they do not possess the device private key, thus ensuring the confidentiality of the key differential data during transmission. It should be noted that if a shared session key has been pre-established between the server and the device, the server can also use this session key to perform symmetric encryption on the incremental differential data to improve encryption efficiency.

[0050] As can be seen, by converting the old and new keys into byte arrays and defining the key update interval based on the differential offset and differential length, and extracting the differential data by performing an XOR operation on only the bytes within the key update interval, the precise capture of local key change segments is achieved, avoiding the full processing of the entire key segment. At the same time, the differential data is encrypted using the device's public key, ensuring that the differential data can only be decrypted by the target device holding the corresponding device private key. This reduces the amount of computation and transmission while ensuring the confidentiality of the differential data transmission.

[0051] Step S14: Determine the target data packet based on the target key identifier, the target encrypted data, the first version number, and the second version number, and send the target data packet to the device.

[0052] The specific steps of determining the target data packet based on the target key identifier, the target encrypted data, the first version number, and the second version number include: S141. Obtain the local timestamp corresponding to the server. S142. Generate a target signature based on the target key identifier, the target encrypted data, the first version number, the second version number, the differential offset, the differential length, and the local timestamp; S143. Combine and encapsulate the target key identifier, the target encrypted data, the first version number, the second version number, the differential offset, the differential length, the local timestamp, and the target signature to obtain the target data packet.

[0053] In a specific embodiment, the server first reads its built-in system clock to obtain the local timestamp of the current moment. This local timestamp is used to identify the initiation time of this incremental update operation, providing a time reference for the device to prevent replay attacks. The local timestamp can use a Unix timestamp format or other standardized time representation format, and its precision can be configured to be in the second or millisecond range according to actual security requirements.

[0054] Then, the server uses the target key identifier, target encrypted data, first version number, second version number, differential offset, differential length, and local timestamp as fields to be signed, and combines them into a data string to be signed according to a preset concatenation order. The server then uses its corresponding private key to execute a digital signature algorithm on the data string to be signed, generating the target signature. The digital signature algorithm can be an elliptic curve signature algorithm or other asymmetric signature algorithms. Upon receiving the target data packet, the device can verify the target signature using a pre-stored server public key to confirm that the target data packet was indeed sent by a legitimate server and has not been tampered with during transmission.

[0055] Next, the server combines and encapsulates the target key identifier, target encrypted data, first version number, second version number, differential offset, differential length, local timestamp, and target signature according to a preset data packet format to form a standardized target data packet. After encapsulation, the server sends the target data packet to the target device through the network communication module. The communication channel can be encrypted using a transport layer security protocol to further enhance the confidentiality of data transmission.

[0056] As can be seen, by generating a target signature from the timestamp and the field to be signed and sending it along with the target data packet, the device can perform signature validity and timeliness verification on the target data packet, effectively resisting forged data packet attacks and replay attacks, and ensuring the integrity and security of incremental update data on the transmission link.

[0057] Step S15: Receive update completion information returned by the device, and update the device key database according to the second key and the second version number.

[0058] The update completion information indicates that the device has completed the version update of the first key, that is, the device has successfully decrypted the target encrypted data and merged it with the first key to restore the second key, and encrypted and stored the second key in the local key database, while retaining the first key for abnormal rollback.

[0059] Specifically, after receiving the update completion information from the device, the server confirms that the incremental burning operation has been successfully executed. Then, the server performs a synchronization update operation on the device key database. This includes: updating the current effective version of the target device under the target key identifier from the first version number to the second version number to reflect the latest version status of the corresponding key on the device. The server writes the second key and the second version number as new historical version data for the device under the target key identifier into the device key database. The second key can be stored encrypted in the device key database to ensure that the key data always exists in ciphertext form when written to disk; alternatively, the second key can be stored in plaintext form in the device key database. No specific limitation is made here. After the device key database is updated, the historical version data of the device under the target key identifier includes both the first key corresponding to the first version number and the second key corresponding to the second version number.

[0060] In one possible embodiment, the server marks the first key corresponding to the first version number as recyclable in the device key database. Simultaneously, the server starts a scheduled task with a set delay for cleanup. When the scheduled task reaches the specified time, the server automatically cleans up the first key in the recyclable state, releasing storage space in the device key database. This delay time is designed to account for the time window requirements of abnormal rollbacks, ensuring that the first key remains available for rollback operations within a reasonable timeframe when a version rollback might be triggered on the device.

[0061] In one possible embodiment, if the server does not receive update completion information from the device within a preset confirmation timeout period, the server-side fault tolerance process is triggered. The server proactively initiates a status query request to the device. Based on the device status returned by the device, the server determines to perform one of the following operations: If the current effective version number returned by the device is the second version number, it indicates that the device has completed the update but the confirmation information has been lost. The server directly synchronizes and updates the device key database without resending the target data packet; if the current effective version number returned by the device is still the first version number, it indicates that the device has not successfully performed the update. The server resends the target data packet or sends a version rollback command to the device; if the device returns a key verification failure or a key tampering abnormal status, the server sends a version rollback command to the device, specifies the target rollback version identifier, records the abnormal log, and triggers an operation and maintenance alarm.

[0062] For easier understanding, please refer to Figure 5 , Figure 5 This is a flowchart illustrating another version-controlled incremental key burning method provided in this application embodiment, applied to the device side, specifically including the following steps: Step S21: Receive the target data packet sent by the server.

[0063] The target data packet includes a target key identifier, target encrypted data, a first version number, a second version number, a differential offset, a differential length, a local timestamp, and a target signature.

[0064] After receiving the target data packet sent by the server, the method further includes the following steps: S211. Determine whether the target data packet meets the preset verification conditions and obtain the verification result; the preset verification conditions are that the legality verification of the target signature is successful, the timeliness verification of the local timestamp is successful, and the second version number is higher than the first version number. S212. If the verification result is successful, then the target data packet is determined to be successfully verified, and the step of querying the local key database corresponding to the device based on the target key identifier and the first version number to obtain the reference encryption key is executed. S213. If the verification result is a verification failure, the target data packet is discarded.

[0065] In a specific embodiment, the device obtains a pre-stored server public key and uses it to verify the target signature in the target data packet. Specifically, the device combines the target key identifier, target encrypted data, first version number, second version number, differential offset, differential length, and local timestamp from the target data packet into a data string to be verified, following the same preset concatenation order as when the server signed it. The device then uses the server public key to execute a digital signature verification algorithm on this data string and the target signature. If the verification passes, it indicates that the target data packet was indeed sent by a legitimate server and has not been tampered with during transmission; the legitimacy of the target signature is successfully verified. If the verification fails, it indicates that the target data packet may have been forged or tampered with; the legitimacy of the target signature fails to be verified.

[0066] The device extracts the local timestamp from the target data packet and reads its own current system time. The device calculates the time difference between the current system time and the local timestamp and compares this difference with a preset validity period window. If the time difference is within the preset validity period window, the target data packet is considered valid, and the local timestamp's validity verification is successful. If the time difference exceeds the validity period window, the target data packet may be a replay attack packet or an expired packet, and the local timestamp's validity verification fails. This validity period window can be configured according to actual security requirements, for example, set to 60 seconds or 300 seconds.

[0067] The device extracts the first version number and the second version number from the target data packet and compares their values. If the value of the second version number is strictly greater than the value of the first version number, the version number increment verification is successful, indicating that this update is a legitimate version upgrade operation; if the value of the second version number is less than or equal to the value of the first version number, the verification fails, indicating that there may be an illegal key downgrade attack or a server configuration error, and the device rejects the update request.

[0068] The device comprehensively judges the results of the three verifications: if all three verifications are successful, the verification result is successful; if any one verification fails, the verification result is unsuccessful. Specifically, when the verification result is successful, the device confirms that the target data packet has passed security verification and is a legitimate, complete, and valid incremental update data packet. At this point, the device continues to query its local key database based on the target key identifier and the first version number to obtain the reference encryption key. When the verification result is unsuccessful, the device directly discards the target data packet, does not perform any key update operation, and returns a verification failure error message to the server. The error message may include the specific reason for the verification failure, such as signature verification failure, timestamp expiration, or invalid version number, to allow the server to troubleshoot and handle errors accordingly. The data in the device's local key database remains unchanged, and the currently effective key version is unaffected.

[0069] As can be seen, by performing triple verification on the target data packet—signature validity, timestamp validity, and version number increment—the subsequent key processing flow is only entered when all verifications pass. If any verification fails, the data packet is discarded. This effectively resists attacks such as forged data packets, replay attacks, and illegal key downgrade attacks, ensuring the security of incremental burning operations.

[0070] Step S22: Obtain the local key database, storage root key, and device private key corresponding to the device.

[0071] Specifically, the local key database is a database used by the device to store historical version data of various keys of the device. It records the version number of each historical version and the corresponding sealed key ciphertext for each type of key, using the key identifier as the index dimension, and marks the currently effective version in real time. The storage root key is an asymmetric key that is uniquely bound to the trusted platform module when the trusted platform module is initialized for the first time. Its private key part is permanently stored inside the trusted platform module chip and is used for subsequent desealing operations of the first key and encryption and sealing operations of the second key. The device private key is the private key that is paired with the device public key used for encryption by the server. It is stored in the secure storage area of ​​the device or inside the trusted platform module and is used to decrypt the target encrypted data.

[0072] Step S23: Query the local key database according to the target key identifier and the first version number to obtain the reference encryption key.

[0073] Specifically, the device searches its local key database using the target key identifier and the first version number as query criteria. Since each historical version of each key type in the local key database is distinguished by a version number, the device can locate the corresponding key type storage area based on the target key identifier. Then, it precisely matches the first version number within that area, extracting the sealed ciphertext corresponding to the first version number, which serves as the reference encryption key. This reference encryption key is the ciphertext form of the old version key currently in effect on the device. It must be desealed and restored to plaintext before it can be used for incremental merging operations.

[0074] Step S24: Decrypt the reference encryption key according to the stored root key to obtain the first key.

[0075] Specifically, the device can input a reference encryption key into the trusted platform module, which then uses the stored root key to decrypt the reference encryption key. During decryption, the device first verifies whether its current platform state (i.e., the platform configuration register state) is consistent with the state at the time of sealing. If the platform state has not changed, the stored root key is used to decrypt the reference encryption key, restoring the first key plaintext. The decrypted first key plaintext only exists briefly within the trusted platform module or in the device's memory for subsequent incremental merging operations and is not written to non-volatile memory. If the platform state has changed, such as firmware tampering or replacement of critical system components, the trusted platform module will refuse the decryption operation to prevent key leakage in an untrusted environment.

[0076] Step S25: Decrypt the target encrypted data according to the device private key to obtain incremental differential data.

[0077] Specifically, the device uses its private key to perform an asymmetric decryption algorithm on the target encrypted data in the target data packet, obtaining incremental differential data. Since the target encrypted data was generated by the server using the device's corresponding public key, according to the principle of asymmetric encryption, only the device holding the paired device private key can successfully decrypt it. The decrypted incremental differential data is a binary byte sequence, the length of which is consistent with the number of bytes indicated by the differential length field in the target data packet, corresponding to the difference between the first key and the second key within the key update interval. After decryption, the incremental differential data is temporarily stored in the device's memory for subsequent XOR merging with the first key to restore the second key. After merging, the incremental differential data is cleared from memory to reduce the risk of key data residue.

[0078] Step S26: Based on the differential offset and the differential length, incrementally merge the first key and the incremental differential data to obtain the second key.

[0079] The step of incrementally merging the first key and the incremental differential data based on the differential offset and the differential length to obtain the second key includes the following steps: S261. Convert the first key into a first byte array; S262. Determine the key update interval based on the differential offset and the differential length; S263. Within the key update interval, perform a byte-by-byte XOR operation on the first byte array and the incremental differential data to obtain the target update data. S264. Update the first byte array according to the target update data to obtain the second byte array; S265. Determine the second key based on the second byte array.

[0080] In a specific embodiment, firstly, the device converts the first key into a first byte array for easy byte-by-byte operation. Taking a 256-bit key as an example, the converted first byte array is 32 bytes long. The byte order of the byte conversion is consistent with the byte order used by the server when generating the differential data, ensuring that the byte positions correspond one-to-one during subsequent XOR operations. Then, the device extracts the differential offset and differential length from the target data packet and defines a key update interval on the first byte array. The differential offset indicates the starting byte position of the key update interval, and the differential length indicates the number of consecutive bytes that need to be merged starting from that starting position. For byte positions outside the key update interval, since the server does not perform differential operations on them, the second key byte values ​​at these positions are the same as the byte values ​​at the corresponding positions of the first key, requiring no processing.

[0081] Next, the device iterates through each byte position within the key update interval, performing a byte-by-byte XOR operation between the byte value at that position in the first byte array and the corresponding byte value in the incremental differential data to obtain the target update byte at that position. After the iteration is complete, all target update bytes form the target update data. Since the server generates the differential data by performing "old key byte XOR new key byte" to obtain the differential bytes, the device can restore the new key bytes by performing "old key byte XOR differential byte". Then, the device uses the target update data to replace the original bytes within the key update interval in the first byte array to obtain the second byte array. In the second byte array, the bytes within the key update interval come from the target update data, while the bytes outside the key update interval remain the same as in the first byte array, thus completely restoring the byte sequence of the second key. The device converts the second byte array back to the key format according to the same byte order as the first key to obtain the second key. This second key is the complete restoration result of the new version key pre-generated by the server. Compared with the first key, only the bytes within the key update interval differ, while the rest remain the same.

[0082] As can be seen, by using the first key as a base copy and performing byte-by-byte XOR operations only on the key update interval determined by the differential offset and differential length, the second key is restored in a local update manner, avoiding the decryption and replacement of the entire key segment. This significantly reduces the computational overhead on the device side while ensuring the correctness of the restoration and improving the execution efficiency of the key update.

[0083] Step S27: Encrypt and store the second key in the local key database, and return update completion information to the server.

[0084] For easier understanding, please refer to Figure 6 , Figure 6 This is a schematic diagram of a key encryption storage process provided in an embodiment of this application, wherein the specific steps of encrypting and storing the second key in the local key database include: S271. Encrypt the second key according to the storage root key to obtain the target encryption key; S272. The target key identifier, the target encryption key, and the second version number are associated and stored in the local key database.

[0085] In a specific embodiment, firstly, the device inputs the second key into the trusted platform module and invokes the stored root key to perform an encryption and sealing operation on the second key. During the sealing process, the plaintext of the second key is bound to the current platform state of the device, and encrypted using the stored root key to generate the target encryption key. The target encryption key is the ciphertext form of the second key, and its decryption is bound to the current trusted platform module and the platform state of the device. If the device firmware or critical system components are tampered with after sealing, causing a change in the platform state, the trusted platform module will refuse to decrypt the target encryption key, thereby preventing the key from being leaked in an untrusted environment. The plaintext of the second key only exists briefly within the trusted platform module and is cleared from memory after sealing is completed; the target encryption key is always stored on disk.

[0086] Next, the device associates the target key identifier, the target encryption key, and the second version number in the target data packet, and writes this information into the local key database. Simultaneously, the device updates the current effective version of this key type in the local key database from the first version number to the second version number. For the reference encryption key corresponding to the original first version number, the device does not delete it but retains it in the local key database, marking it as a historical version key, maintaining the correspondence between the first version number and the reference encryption key, and serving as a backup key data source for subsequent anomaly rollbacks.

[0087] After storage is complete, the device returns an update completion message to the server. This message indicates that the device has successfully updated the first key, meaning it has successfully decrypted the target encrypted data and merged it with the first key to restore the second key, which is then encrypted and stored in the local key database. The current effective version has been updated to the second version number. Upon receiving this update completion message, the server synchronously updates the version status in the device's key database, completing the closed loop of this incremental flashing process.

[0088] As can be seen, by calling the storage root key to encrypt and seal the new key and then storing it in association with the version number, the new key is stored on disk in ciphertext form and bound to the device hardware identity. At the same time, the new and old version keys coexist in the local key database, which not only ensures the static storage security of the key, but also provides a backup key data source for quickly rolling back to the old version in case of update anomalies.

[0089] The above primarily describes the solutions of the embodiments of this application from the perspective of the method execution process. It is understood that, in order to achieve the above functions, the electronic device includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments provided herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0090] This application embodiment can divide the electronic device into functional modules according to the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0091] When dividing each function into modules according to its corresponding function. Figure 7 This is a functional module block diagram of a version-controlled incremental key burning device provided in this application embodiment, applied to a server. The version-controlled incremental key burning device 700 includes: The first acquisition module 710 is used to acquire the first key of the corresponding device and the first version number corresponding to the first key from the device key database according to the target key identifier; the target key identifier is the key identifier corresponding to the key that needs to be incrementally burned; the device key database is a database used by the server to store multiple historical version data of different types of keys of each device. The generation module 720 is used to generate a second key and a second version number corresponding to the second key based on the first key and the first version number; the second version number is higher than the first version number. Processing module 730 is used to perform incremental differential and encryption processing on the first key and the second key to obtain target encrypted data; The determination module 740 is used to determine the target data packet based on the target key identifier, the target encrypted data, the first version number and the second version number, and send the target data packet to the device. The update module 750 is used to receive update completion information returned by the device and update the device key database according to the second key and the second version number; the update completion information indicates that the device has completed the version update of the first key.

[0092] Optionally, in the step of obtaining the first key of the corresponding first device and the first version number corresponding to the first key from the device key database according to the target key identifier, the first acquisition module 710 is specifically used for: Obtain the unique device identifier of the device; Based on the device's unique identifier and the target key identifier, the device key database is queried to obtain multiple reference keys and multiple reference version numbers; Obtain the latest version number from the plurality of reference version numbers to obtain the first version number; Determine the first key corresponding to the first version number among the plurality of reference keys.

[0093] Optionally, in the process of performing incremental differential and encryption processing on the first key and the second key to obtain the target encrypted data, the processing module 730 is specifically used for: Convert the first key and the second key into a first byte array and a second byte array, respectively; The key update interval is determined based on the preset differential offset and differential length; Within the key update interval, a byte-by-byte XOR operation is performed on the first byte array and the second byte array to obtain incremental differential data; Obtain the device public key corresponding to the device, and encrypt the incremental differential data according to the device public key to obtain the target encrypted data.

[0094] Optionally, in determining the target data packet based on the target key identifier, the target encrypted data, the first version number, and the second version number, the determining module 740 is specifically configured to: Obtain the local timestamp corresponding to the server; A target signature is generated based on the target key identifier, the target encrypted data, the first version number, the second version number, the differential offset, the differential length, and the local timestamp; The target key identifier, the target encrypted data, the first version number, the second version number, the differential offset, the differential length, the local timestamp, and the target signature are combined and encapsulated to obtain the target data packet.

[0095] It should be noted that the specific implementation of each operation can be described in the corresponding description of the method embodiments shown above. The version control-based key incremental burning device 700 can be used to execute the above method embodiments of this application, and will not be described again.

[0096] When dividing each function into modules according to its corresponding function. Figure 8 This is a functional module block diagram of another version-controlled incremental key programming device provided in this application embodiment, applied to the device side. The version-controlled incremental key programming device 700 includes: The receiving module 810 is used to receive the target data packet sent by the server; the target data packet includes the target key identifier, target encrypted data, first version number, second version number, differential offset, differential length, local timestamp and target signature; The second acquisition module 820 is used to acquire the local key database, storage root key and device private key corresponding to the device; The query module 830 is used to query the local key database based on the target key identifier and the first version number to obtain a reference encryption key; The first decryption module 840 is used to decrypt the reference encryption key according to the stored root key to obtain the first key; The second decryption module 850 is used to decrypt the target encrypted data according to the device private key to obtain incremental differential data; The merging module 860 is used to incrementally merge the first key and the incremental differential data according to the differential offset and the differential length to obtain the second key; The storage module 870 is used to encrypt and store the second key in the local key database and return update completion information to the server.

[0097] Optionally, after receiving the target data packet sent by the server, the version-controlled incremental key burning device 700 is specifically used for: Determine whether the target data packet meets the preset verification conditions and obtain the verification result; the preset verification conditions are that the legality of the target signature is successfully verified, the timeliness of the local timestamp is successfully verified, and the second version number is higher than the first version number; If the verification result is successful, then the target data packet is determined to be successfully verified, and the step of querying the local key database corresponding to the device based on the target key identifier and the first version number to obtain the reference encryption key is executed. If the verification result is a verification failure, the target data packet is discarded.

[0098] Optionally, in the step of incrementally merging the first key and the incremental differential data according to the differential offset and the differential length to obtain the second key, the merging module 860 is specifically used for: Convert the first key into a first byte array; The key update interval is determined based on the differential offset and the differential length; Within the key update interval, a byte-by-byte XOR operation is performed on the first byte array and the incremental differential data to obtain the target update data; The first byte array is updated according to the target update data to obtain the second byte array; The second key is determined based on the second byte array.

[0099] Optionally, in the process of encrypting and storing the second key in the local key database, the storage module 870 is specifically used for: The second key is encrypted using the stored root key to obtain the target encryption key; The target key identifier, the target encryption key, and the second version number are associated and stored in the local key database.

[0100] It should be noted that the specific implementation of each operation can be described in the corresponding description of the method embodiments shown above. The version control-based key incremental burning device 700 can be used to execute the above method embodiments of this application, and will not be described again.

[0101] This application also provides a computer-readable storage medium storing a computer program for electronic data interchange, which causes a computer to perform some or all of the steps of any of the methods described in the above method embodiments, wherein the computer includes an electronic device.

[0102] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0103] It should be noted that, for the sake of simplicity, the above embodiments are all described as a series of actions. Those skilled in the art should understand that this application is not limited to the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0104] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0105] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0106] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, electrically erasable programmable read-only memory (EEPROM), registers, hard disk, portable hard disk, read-only optical disk (CD-ROM), or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0107] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0108] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on the processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented through a software program that runs on the processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0109] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above descriptions are merely specific embodiments of the embodiments of this application and are not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A version-controlled incremental key burning method, applied to a server, characterized in that, The method includes: Based on the target key identifier, the first key of the corresponding device and the first version number corresponding to the first key are obtained from the device key database; the target key identifier is the key identifier corresponding to the key that needs to be incrementally burned; the device key database is a database used by the server to store multiple historical version data of different types of keys for each device. Based on the first key and the first version number, a second key and a second version number corresponding to the second key are generated; the second version number is higher than the first version number. Incremental differential and encryption processing is performed on the first key and the second key to obtain the target encrypted data; The target data packet is determined based on the target key identifier, the target encrypted data, the first version number, and the second version number, and the target data packet is sent to the device. The device receives update completion information returned by the device and updates the device key database according to the second key and the second version number; the update completion information indicates that the device has completed the version update of the first key.

2. The method as described in claim 1, characterized in that, The step of obtaining the first key of the first device and the first version number corresponding to the first key from the device key database according to the target key identifier includes: Obtain the unique device identifier of the device; Based on the device's unique identifier and the target key identifier, the device key database is queried to obtain multiple reference keys and multiple reference version numbers; Obtain the latest version number from the plurality of reference version numbers to obtain the first version number; Determine the first key corresponding to the first version number among the plurality of reference keys.

3. The method as described in claim 1 or 2, characterized in that, The incremental differential encryption process performed on the first key and the second key to obtain the target encrypted data includes: Convert the first key and the second key into a first byte array and a second byte array, respectively; The key update interval is determined based on the preset differential offset and differential length; Within the key update interval, a byte-by-byte XOR operation is performed on the first byte array and the second byte array to obtain incremental differential data; Obtain the device public key corresponding to the device, and encrypt the incremental differential data according to the device public key to obtain the target encrypted data.

4. The method as described in claim 3, characterized in that, The step of determining the target data packet based on the target key identifier, the target encrypted data, the first version number, and the second version number includes: Obtain the local timestamp corresponding to the server; A target signature is generated based on the target key identifier, the target encrypted data, the first version number, the second version number, the differential offset, the differential length, and the local timestamp; The target key identifier, the target encrypted data, the first version number, the second version number, the differential offset, the differential length, the local timestamp, and the target signature are combined and encapsulated to obtain the target data packet.

5. A version-controlled incremental key burning method, applied to the device side, characterized in that, The method includes: Receive the target data packet sent by the server; the target data packet includes the target key identifier, target encrypted data, first version number, second version number, differential offset, differential length, local timestamp, and target signature; Obtain the local key database, root key, and device private key corresponding to the device; Based on the target key identifier and the first version number, the local key database is queried to obtain the reference encryption key; The reference encryption key is decrypted using the stored root key to obtain the first key; The target encrypted data is decrypted using the device's private key to obtain incremental differential data; Based on the differential offset and the differential length, the first key and the incremental differential data are incrementally merged to obtain the second key; The second key is encrypted and stored in the local key database, and an update completion message is returned to the server.

6. The method as described in claim 5, characterized in that, After receiving the target data packet sent by the receiving server, the method further includes: Determine whether the target data packet meets the preset verification conditions and obtain the verification result; the preset verification conditions are that the legality of the target signature is successfully verified, the timeliness of the local timestamp is successfully verified, and the second version number is higher than the first version number; If the verification result is successful, then the target data packet is determined to be successfully verified, and the step of querying the local key database corresponding to the device based on the target key identifier and the first version number to obtain the reference encryption key is executed. If the verification result is a verification failure, the target data packet is discarded.

7. The method as described in claim 5 or 6, characterized in that, The step of incrementally merging the first key and the incremental differential data according to the differential offset and the differential length to obtain the second key includes: Convert the first key into a first byte array; The key update interval is determined based on the differential offset and the differential length; Within the key update interval, a byte-by-byte XOR operation is performed on the first byte array and the incremental differential data to obtain the target update data; The first byte array is updated according to the target update data to obtain the second byte array; The second key is determined based on the second byte array.

8. The method as described in claim 7, characterized in that, The step of encrypting and storing the second key in the local key database includes: The second key is encrypted using the stored root key to obtain the target encryption key; The target key identifier, the target encryption key, and the second version number are associated and stored in the local key database.

9. An electronic device, characterized in that, include: Processor, memory, communication interface, and one or more programs; The one or more programs are stored in the memory and configured to be executed by the processor, the programs including instructions for performing the steps of the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-8.

Images