Quantum secure key update method and device based on dual-mode key distribution

Abstract

The application provides a quantum security key updating method and device based on a dual-mode key distribution, the method comprising: obtaining a dual-mode link between a server and a device, and determining a distribution mode identifier according to a link state of the dual-mode link; randomly generating a new key, an OTP key segment and a target entropy source value respectively according to a quantum random number generator; determining encrypted differential data according to an old key, the new key and the OTP key segment; generating target data packets according to a first version identifier, a second version identifier, the distribution mode identifier, the target entropy source value and the encrypted differential data; sending the OTP key segment and the target data packets to the device through the dual-mode link; and in response to update completion information returned by the device for the new key, taking the new key as a key associated with the device. The security and reliability of key updating are improved through dual-mode link switching and encryption of differential data using the OTP key segment.

Description

Technical Field

[0001] This application relates to the field of key update technology, and in particular to a quantum-safe key update method and apparatus based on dual-mode key distribution. Background Technology

[0002] In distributed device management scenarios, existing key update schemes generally suffer from security vulnerabilities: key exchange uses traditional cryptographic systems, which are susceptible to quantum computing cracking; differential data is encrypted using low-quality pseudo-random session keys, resulting in insufficient entropy source security and weak quantum protection capabilities. Furthermore, key distribution typically only supports single-channel transmission; when the channel fails or is attacked, key updates are directly interrupted, making it difficult to adapt to highly reliable distributed device management scenarios.

[0003] Therefore, improving the security and reliability of the key update process is an urgent issue that needs to be addressed. Summary of the Invention

[0004] This application provides a quantum-safe key update method and apparatus based on dual-mode key distribution. It improves the disaster recovery capability of key distribution by automatically switching between dual-mode links, and uses OTP key fragments to encrypt differential data to achieve security protection, thereby greatly improving the security and reliability of the key update process.

[0005] In a first aspect, embodiments of this application provide a quantum-secure key update method based on dual-mode key distribution, applied to a server, the method comprising: The dual-mode link between the server and the device is obtained, and the distribution mode identifier is determined according to the link status of the dual-mode link; the dual-mode link includes a fiber optic mode link and a tunnel mode link; the distribution mode identifier includes a fiber optic mode identifier or a tunnel mode identifier. Based on the quantum random number generator corresponding to the server, a new key, an OTP key fragment, and a target entropy source value are randomly generated respectively. Based on the old key, the new key, and the OTP key fragment stored on the server and associated with the device, the encrypted differential data is determined; the old key and the new key correspond to the first version identifier and the second version identifier, respectively, and the second version identifier is greater than the first version identifier; A target data packet is generated based on the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data; The OTP key fragment and the target data packet are sent to the device via the dual-mode link; the device recovers the new key based on the OTP key fragment and the target data, generates update completion information based on the new key, and returns it to the server. In response to the update completion information returned by the device for the new key, the new key is used as the key associated with the device.

[0006] Secondly, embodiments of this application provide a quantum-secure key update method based on dual-mode key distribution, applied to a device, the method comprising: Through a dual-mode link between the server and the device, the target data packet and the OTP key fragment sent by the server are received respectively; the target data packet includes a first signature, a first version identifier, a second version identifier, a distribution mode identifier, a target entropy source value, and encrypted differential data; The target data packet and the OTP key fragment are verified to obtain the verification result; When the verification result is successful, a new key is determined based on the target data packet and the OTP key fragment; the new key serves as the key associated with the server. An update completion message is generated based on the new key and sent 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 of the methods of the first and second aspects of embodiments 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 of the methods of the first and second aspects of embodiments 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, the computer program being operable to cause a computer to perform some or all of the steps described in any of the methods of the first and second aspects of the embodiments of this application. The computer program product may be a software installation package.

[0010] It is evident that by automatically switching between dual-mode links to enhance the disaster recovery capability of key distribution, and by using OTP key fragments to encrypt differential data for security protection, the security and reliability of the key update process are significantly improved. 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 update system provided in an embodiment of this application; Figure 2 This is a schematic diagram of a dual-mode link 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 quantum-secure key update method based on dual-mode key distribution provided in an embodiment of this application; Figure 5 This is a schematic diagram of a process for determining encrypted differential data provided in an embodiment of this application; Figure 6 This is a flowchart illustrating another quantum-secure key update method based on dual-mode key distribution provided in this application embodiment; Figure 7 This is a functional block diagram of a quantum-secure key update device based on dual-mode key distribution provided in an embodiment of this application; Figure 8 This is a functional block diagram of another quantum-safe key update device based on dual-mode key distribution 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] The following is an explanation of the relevant terms used in this application: One-Time Pad (OTP): refers to a truly random key fragment of the same length as the differential data, generated by a quantum random number generator. It is used to encrypt the differential data and is destroyed after use, thus ensuring the security of the key update process at the information theory level.

[0020] Target entropy source value: A truly random number independently generated by a quantum random number generator. It does not participate in the encryption of differential data, but serves as a one-time freshness identifier for this key update operation. It is encapsulated in plaintext in the target data packet and sent to the device.

[0021] In distributed device management scenarios, existing key update schemes generally suffer from security vulnerabilities: key exchange uses traditional cryptographic systems, which are susceptible to quantum computing attacks; differential data is encrypted using low-quality pseudo-random session keys, resulting in insufficient entropy source security and weak quantum protection capabilities. Furthermore, key distribution typically only supports single-channel transmission; when the channel fails or is attacked, key updates are directly interrupted, making it difficult to adapt to highly reliable distributed device management scenarios. Therefore, improving the security and reliability of the key update process is an urgent issue to address.

[0022] To address the aforementioned issues, this application provides a quantum-secure key update method and apparatus based on dual-mode key distribution. First, a dual-mode link between the server and the device is acquired, and a distribution mode identifier is determined based on the link status of the dual-mode link. The dual-mode link includes a fiber optic mode link and a tunnel mode link; the distribution mode identifier includes either a fiber optic mode identifier or a tunnel mode identifier. Then, a new key, an OTP key fragment, and a target entropy source value are randomly generated using a quantum random number generator corresponding to the server. Encrypted differential data is determined based on the old key associated with the device stored on the server, the new key, and the OTP key fragment; the old key and the new key... The first and second version identifiers are respectively associated with the first version identifier and the second version identifier, with the second version identifier being greater than the first version identifier. Next, a target data packet is generated based on the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data. The OTP key fragment and the target data packet are sent to the device via the dual-mode link. The device recovers the new key based on the OTP key fragment and the target data, generates update completion information based on the new key, and returns it to the server. Finally, in response to the update completion information returned by the device for the new key, the new key is used as the key associated with the device.

[0023] It is evident that by automatically switching between dual-mode links to enhance the disaster recovery capability of key distribution, and by using OTP key fragments to encrypt differential data for security protection, the security and reliability of the key update process are significantly improved.

[0024] For easier understanding, please refer to Figure 1 , Figure 1 This is a system architecture diagram of a key update system provided in an embodiment of this application. The key update system includes a server and a device.

[0025] The server is used to detect the link status of the dual-mode link and determine the distribution mode identifier based on the link status; it calls the quantum random number generator to generate a new key, an OTP key fragment, and a target entropy source value; it calculates the XOR difference between the old key and the new key, and uses the OTP key fragment combined with an encryption algorithm to encrypt the difference to obtain encrypted differential data; it integrates the version identifier, distribution mode identifier, target entropy source value, and encrypted differential data to assemble the target data packet; finally, it sends the target data packet and the OTP key fragment to the device through the dual-mode link.

[0026] The device is used to receive target data packets and OTP key fragments through a dual-mode link, and sequentially perform signature verification, version verification, and freshness verification on the target data packets. After the verification is successful, the device uses the OTP key fragment to decrypt the differential data, performs an XOR operation with the old key to recover the new key, and returns an update completion message to the server.

[0027] It is evident that by using asynchronous distribution of dual-mode links and a quantum random number-enhanced authentication and encryption mechanism, high-security key updates and link distribution guarantees resistant to quantum computing are achieved.

[0028] For easier understanding, please refer to Figure 2 , Figure 2 This is a schematic diagram of a dual-mode link provided in an embodiment of this application. The fiber optic mode link consists of a server-side optical module, fiber optic cable, and a device-side optical module connected sequentially, used for physical layer optical signal transmission of OTP key fragments. The tunnel mode link is established based on the existing network infrastructure between the server and the device, and uses a preset post-quantum cryptography protocol for encryption, used for secure transmission of target data packets and OTP key fragments. During key updates, the server automatically selects either the fiber optic mode link or the tunnel mode link as the transmission channel for OTP key fragments based on the link status, while target data packets are uniformly transmitted through the tunnel mode link.

[0029] The following is combined Figure 3 The 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.

[0030] 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.

[0031] 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.

[0032] 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).

[0033] 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.

[0034] The following is combined Figure 4 This application describes a quantum-safe key update method based on dual-mode key distribution. Figure 4 This is a flowchart illustrating a quantum-secure key update method based on dual-mode key distribution provided in this application embodiment, applied to the server side, and specifically includes the following steps: Step S11: Obtain the dual-mode link between the server and the device, and determine the distribution mode identifier based on the link status of the dual-mode link.

[0035] The dual-mode link includes an optical fiber mode link and a tunnel mode link; the distribution mode identifier includes an optical fiber mode identifier or a tunnel mode identifier.

[0036] The specific steps for determining the distribution mode identifier based on the link status of the dual-mode link include: S111. Obtain the insertion status and optical power value of the optical module corresponding to the optical fiber mode link; S112. If the insertion state is in place and the optical power value is greater than a preset threshold, then the fiber optic mode link is determined to be available, and the distribution mode identifier is determined as the fiber optic mode identifier. S113. If the insertion state is not in place, and / or the optical power value is less than or equal to the preset threshold, then the fiber optic link is determined to be unavailable, and the tunnel mode link is detected to be in a connected state. S114. If the tunnel mode link is in the connected state, the tunnel mode link is determined to be available, and the distribution mode identifier is determined as the tunnel mode identifier.

[0037] In a specific embodiment, firstly, the server reads the insertion status register corresponding to the optical module on the optical fiber communication port through the optical module management interface to obtain the insertion status of the optical module; at the same time, it reads the optical power value through the optical power monitoring circuit, which reflects the actual strength of the optical signal sent by the peer end (i.e., the device end) of the optical fiber mode link to the local end (i.e., the server end).

[0038] The server then checks the obtained insertion status and optical power value. If the insertion status is "in place" and the optical power value is greater than a preset threshold (e.g., -20dBm), it indicates that the optical module has been correctly installed in the fiber optic communication port, and the signal attenuation of the fiber optic link is within an acceptable range. This ensures reliable optical signal transmission between the server and the device, thus determining the fiber optic link as usable and assigning the distribution mode identifier to the fiber optic link. Because the fiber optic link has physical layer isolation characteristics, the signal is difficult to eavesdrop on remotely, and it supports direct optical signal modulation transmission of OTP key fragments, providing high transmission security. Therefore, it is preferred when the fiber optic link is available. If the insertion status is "out of place," it indicates that the optical module has not been inserted or has been removed from the fiber optic communication port, or the optical power value is less than or equal to the preset threshold, indicating that the fiber optic link attenuation is too high or the physical connection is broken. In this case, the fiber optic link is determined to be unusable.

[0039] At this point, the server probes the connectivity of the tunnel mode link. Specifically, the server sends a link probe message to the tunnel service port on the device and starts a preset response waiting timer to detect the connectivity of the tunnel mode link. If the server receives a response message from the device within the preset time, it indicates that the tunnel mode link is connected, the tunnel mode link is deemed available, and the distribution mode identifier is determined to be the tunnel mode identifier. The tunnel mode link is an encrypted transmission channel established based on a post-quantum cryptography protocol. Although it is less physically isolated than the fiber optic mode, its security can resist quantum computing attacks, and it can be deployed based on existing network infrastructure, offering high deployment flexibility. Therefore, it is suitable as a backup distribution channel when the fiber optic mode is unavailable.

[0040] It is evident that by automatically detecting the status and switching priorities of the dual-mode links, the fiber optic mode is used first for key distribution when the fiber optic link is normal in order to obtain physical layer security features; when the fiber optic link fails, it automatically switches to tunnel mode to ensure the continuity and reliability of the key update process.

[0041] Step S12: Based on the quantum random number generator corresponding to the server, a new key, an OTP key fragment, and a target entropy source value are randomly generated respectively.

[0042] Specifically, quantum random number generators generate truly random bit sequences based on quantum physical processes (such as photon phase fluctuations or quantum vacuum noise). Their entropy source originates from the inherent randomness of quantum mechanics, fundamentally different from pseudo-random number generators based on deterministic algorithms. Therefore, the random sequences generated by quantum random number generators possess unpredictability and non-reproducibility, meeting the security requirements of key updates. Specifically, the quantum random number generator randomly generates a new key, an OTP key fragment, and a target entropy source value. The new key is a 256-bit truly random sequence, used to replace the old key currently used by the device as the symmetric key for the next communication. The OTP key fragment is also a 256-bit truly random sequence, used to encrypt and protect subsequently generated differential data. The target entropy source value is a 128-bit truly random sequence, serving as a freshness identifier for this key update operation. It is transmitted in plaintext with the target data packet, allowing the device to verify the authenticity of the OTP key fragment's source and the freshness of the current session before performing key recovery.

[0043] Step S13: Determine encrypted differential data based on the old key, the new key, and the OTP key fragment stored on the server and associated with the device.

[0044] The old key and the new key correspond to the first version identifier and the second version identifier, respectively, and the second version identifier is greater than the first version identifier.

[0045] For easier understanding, please refer to Figure 5 , Figure 5 This is a flowchart illustrating a process for determining encrypted differential data according to an embodiment of this application. The specific steps for determining encrypted differential data based on the old key, the new key, and the OTP key fragment stored on the server and associated with the device include: S131. Perform a bitwise XOR operation on the old key and the new key to obtain the first difference data; S132. Using the OTP key fragment as the encryption key, the first differential data is encrypted to obtain the encrypted differential data.

[0046] In a specific embodiment, the server performs a bitwise XOR operation on the old key and the new key to obtain the first difference data. For example, A XOR B = C, where A represents the old key, B is the new key, and C represents the first difference data. The XOR operation is inversely related; after receiving the first difference data, the device only needs to perform another XOR operation with the locally stored old key to accurately recover the new key, without requiring the server to directly transmit the new key itself.

[0047] The server uses an OTP key fragment as the encryption key to encrypt the first differential data, obtaining encrypted differential data. Specifically, the encryption process of the first differential data can employ a preset authentication encryption algorithm (such as AES-256-GCM) for authentication encryption. This authentication encryption algorithm generates an authentication tag for integrity verification while generating the ciphertext.

[0048] It is evident that by converting key updates into secure transmission of differential data through XOR operations, and by authenticating and encrypting the differential data with OTP key fragments generated by quantum random numbers, the confidentiality of the new key is securely guaranteed.

[0049] Step S14: Generate a target data packet based on the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data.

[0050] The specific steps for generating the target data packet based on the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data include: S141. Encapsulate the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data to generate a data packet to be signed; S142. The data packet to be signed is signed using a preset signature generation algorithm to generate a first signature; S143. Combine the data packet to be signed and the first signature to generate the target data packet.

[0051] In a specific embodiment, firstly, the server encapsulates the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data according to a preset data structure to generate a data packet to be signed. The first version identifier indicates the old key version number currently held by the device, and the second version identifier indicates the new key version number for this update. These two identifiers form an incremental version relationship, facilitating version validity verification and subsequent rollback operations on the device. The distribution mode identifier indicates the selected key distribution link type, which the device uses to determine the link for receiving OTP key fragments. The target entropy source value serves as a freshness identifier for this key update operation, allowing the device to verify the authenticity of the OTP key fragment source and the freshness of the session before performing key recovery. The encrypted differential data represents the differences between the old and new keys.

[0052] Then, the server invokes a preset signature generation algorithm (such as ML-DSA-65) and uses its locally stored server private key to digitally sign the data packet to be signed, generating a first signature. The signature operation calculates all fields of the data packet to be signed, ensuring that any tampering with any field will cause subsequent signature verification to fail, thus achieving comprehensive protection of the target data packet's integrity. Next, the server combines the data packet to be signed with the first signature to generate the final target data packet. The target data packet contains a payload (the fields in the data packet to be signed) and a signature (the first signature). Upon receiving the target data packet, the device can extract the payload, recalculate the digest, and compare it with the signature to verify the integrity and authenticity of the target data packet's origin.

[0053] As can be seen, by encapsulating the version identifier, distribution mode, entropy source value, and encrypted differential data and attaching a digital signature, verifiable data integrity protection is provided to the device.

[0054] Step S15: Send the OTP key fragment and the target data packet to the device via the dual-mode link.

[0055] Specifically, the device recovers the new key based on the OTP key fragment and the target data, generates update completion information based on the new key, and returns it to the server.

[0056] Specifically, the step of sending the OTP key fragment and the target data packet to the device via the dual-mode link includes: S151. The target data packet is sent to the device through the tunnel mode link, and the sending time of the target data packet is recorded; S152. If the distribution mode identifier is the fiber optic mode identifier, then after a preset first time period, the OTP key fragment is sent to the device via the fiber optic mode link; the start time of the preset first time period includes the sending time. S153. If the distribution mode identifier is the tunnel mode identifier, then after a preset second time period, the OTP key fragment is sent to the device through the tunnel mode link; the start time of the preset second time period includes the sending time.

[0057] In a specific embodiment, the server first sends the target data packet to the device via a tunnel mode link and records the transmission time of the target data packet. Regardless of whether the distribution mode identifier is a fiber optic mode identifier or a tunnel mode identifier, the target data packet is transmitted via the tunnel mode link. This tunnel mode link establishes an encrypted channel based on a post-quantum cryptography protocol, providing confidentiality and integrity protection for the target data packet.

[0058] If the distribution mode identifier is a fiber optic mode identifier, the OTP key fragment will be sent to the device via the fiber optic mode link after a preset first time period. The start time of the preset first time period includes the sending time of the target data packet. This preset first time period is a relatively short duration, such as a fixed or random value within the range of 1 to 10 milliseconds. Because the fiber optic mode link has physical layer isolation characteristics and the signal is transmitted directionally along the fiber, it is difficult to be eavesdropped on remotely without contact. Therefore, the time offset between the OTP key fragment and the target data packet can be set to be short, ensuring both security and update efficiency.

[0059] If the distribution mode identifier is a tunnel mode identifier, the OTP key fragment will be sent to the device via the tunnel mode link after a preset second time period. The start time of the preset second time period includes the sending time of the target data packet, and the preset second time period is a longer duration than the first time period, such as a fixed or random value within the range of 50 milliseconds to 500 milliseconds. Since the tunnel mode link is built based on the network layer or transport layer, the OTP key fragment and the target data packet share the same logical channel. Setting a longer time offset reduces the risk of both being intercepted simultaneously on the same link.

[0060] In this design, the target data packet and the OTP key fragment are separated in both time and space. The target data packet is transmitted via a tunnel mode link, while the OTP key fragment selects either a fiber optic mode link or a tunnel mode link based on the distribution mode identifier, and their transmission times are independent and offset from each other. Even if an attacker successfully intercepts the target data packet, they cannot decrypt the encrypted differential data within it because they do not possess the OTP key fragment. Furthermore, the delayed transmission of the OTP key fragment makes it difficult for an attacker to simultaneously intercept the ciphertext and the key within the same time window, further enhancing the anti-eavesdropping capability of the key distribution process.

[0061] It is evident that by asynchronously sending the target data packet and the OTP key fragment, transmission isolation is constructed in both time and space dimensions, increasing the difficulty for attackers to simultaneously intercept the ciphertext and the key, thereby enhancing the security of key distribution.

[0062] Step S16: In response to the update completion information returned by the device for the new key, the new key is used as the key associated with the device.

[0063] Specifically, after successfully recovering the new key, the device generates an update completion message and sends it to the server. This update completion message includes at least a second version identifier, a confirmation status field, and the device's own identifier, indicating that the device has successfully received, verified, and recovered the new key corresponding to the second version identifier. The device can sign the update completion message using its private key, and the server verifies the validity of the signature using the corresponding public key to ensure the integrity and authenticity of the update completion message.

[0064] The server extracts the second version identifier from the update completion information and compares it with the locally recorded unconfirmed version to confirm that the version confirmed by the device matches the version issued this time. After successful verification, the server updates the key status associated with the device in its local key management library: marking the new key as the currently valid key and updating the corresponding key version record to the second version identifier. Simultaneously, the server retains the old key and its corresponding first version identifier to support key rollback operations when needed. If no update completion information is received from the device within a preset waiting time, the server can mark this update as timed out and retain the old key as the currently valid key, thereby avoiding key status inconsistencies due to link interruption or device malfunction.

[0065] As can be seen, the closed-loop confirmation mechanism of device-side signature confirmation and server-side timeout rollback ensures that the key status of both parties is consistent, avoiding key asynchrony due to link interruption or device abnormality.

[0066] For easier understanding, please refer to Figure 6 , Figure 6 This is a flowchart illustrating another quantum-secure key update method based on dual-mode key distribution provided in this application embodiment, applied to the device side, specifically including the following steps: Step S21: Receive the target data packet and OTP key fragment sent by the server through the dual-mode link between the server and the device.

[0067] The target data packet includes a first signature, a first version identifier, a second version identifier, a distribution mode identifier, a target entropy source value, and encrypted differential data.

[0068] Specifically, the device can receive the target data packet sent by the server through a tunnel mode link, and then receive the OTP key fragment from the corresponding link according to the distribution mode identifier carried in the target data packet. Specifically, if the distribution mode identifier is a fiber optic mode identifier, the device receives the OTP key fragment through a fiber optic mode link after receiving the target data packet; if the distribution mode identifier is a tunnel mode identifier, the device receives the OTP key fragment through a tunnel mode link after receiving the target data packet.

[0069] Step S22: Verify the target data packet and the OTP key fragment to obtain the verification result.

[0070] The specific steps for verifying the target data packet and the OTP key fragment to obtain the verification result include: S221. Verify the first signature using a preset signature verification algorithm; S222. If the first signature verification fails, the verification result is determined to be a verification failure. S223. If the first signature verification is successful, then the first version identifier and the second version identifier are verified. S224. If the first version identifier is greater than or equal to the second version identifier, then the verification result is determined to be a verification failure. S225. If the first version identifier is less than the second version identifier, then a verification request is sent to the server with the target entropy source value as the challenge value. S226. Receive the response value generated by the server based on the local OTP key fragment and the challenge value; S227. Compare the response value with the verification value generated by the device using the OTP key fragment and the challenge value; S228. If the response value and the verification value are inconsistent, the verification result is determined to be a verification failure. S229. If the response value and the verification value are consistent, the verification result is determined to be successful.

[0071] In a specific embodiment, after receiving the target data packet and the OTP key fragment, the device needs to perform multi-layer security verification on them in sequence to confirm the integrity, authenticity of the source, legality of the version of the target data packet, and freshness of the source of the OTP key fragment. Only after all verifications are passed can the OTP key fragment be used to recover the new key.

[0072] The process involves the device extracting a first signature from the target data packet and invoking a preset signature verification algorithm (such as ML-DSA-65). The device uses the server's public key (corresponding to its private key) to verify the first signature, confirming that the target data packet has not been tampered with during transmission and was indeed generated by a server holding a legitimate private key. If the first signature verification fails, it indicates that the target data packet may have been tampered with or not signed by a legitimate server. The device determines the verification result as a failure, terminates the subsequent verification process, discards the received target data packet and OTP key fragment, and does not perform a key recovery operation. If the first signature verification passes, the device extracts a first version identifier and a second version identifier from the target data packet and performs a version validity check to prevent attackers from replaying older version update packages and inducing the device to revert to an outdated key version.

[0073] In this system, the first version identifier represents the old key version currently held by the device, and the second version identifier represents the old key version updated this time. If the first version identifier is greater than or equal to the second version identifier, it indicates that the target data packet may be a replay packet or have incorrect version information. The device determines the verification result as a failure and discards the target data packet. Subsequent verification continues only if the first version identifier is less than the second version identifier.

[0074] After the version legitimacy verification is successful, the device sends a verification request (i.e., a key source verification request) to the server using the target entropy source value carried in the target data packet as the challenge value. Specifically, the device sends the challenge value to the server via a tunnel mode link, requesting the server to prove that it holds the OTP key fragment corresponding to the challenge value. Both the challenge value (i.e., the target entropy source value) and the OTP key fragment are independently generated by the same quantum random number generator and have no derivation relationship. Upon receiving the verification request, the server uses its locally held OTP key fragment corresponding to this update to perform a preset cryptographic operation on the challenge value, generating a response value, and returns the response value to the device. This cryptographic operation can use hash message authentication codes (such as HMAC-SHA256) or XOR operations to ensure that the response value is related to both the OTP key fragment and the challenge value. Simultaneously or subsequently, the device uses its received OTP key fragment to perform the same cryptographic operation on the same challenge value (i.e., the target entropy source value) to generate a verification value. Then, the device compares the received response value with the verification value.

[0075] If the response value and the checksum do not match, it indicates that the server cannot prove that it holds the correct OTP key fragment. Possible reasons include the OTP key fragment being tampered with during transmission, an attacker attempting to replay an old OTP key fragment, or the server's identity being untrusted. The device determines the verification result as verification failure, discards the received target data packet and OTP key fragment, and does not perform key recovery. If the response value and the checksum match, it indicates that the server holds the correct OTP key fragment, and that this OTP key fragment was indeed generated in this update operation. The freshness verification of the OTP key fragment passes, and the device determines the verification result as successful, proceeding to the subsequent key recovery steps.

[0076] As can be seen, through a three-layer progressive verification of signature verification, version increment verification, and entropy source challenge response, the integrity of the target data packet, the legitimacy of the version, and the freshness of the OTP key fragment are fully ensured, preventing replay and forgery attacks.

[0077] Step S23: When the verification result is successful, a new key is determined based on the target data packet and the OTP key fragment.

[0078] The new key is used as a key associated with the server.

[0079] The specific steps for determining the new key based on the target data packet and the OTP key fragment include: S231. Decrypt the encrypted differential data using the OTP key fragment to obtain the first differential data; S232. Load the old key corresponding to the first version identifier from the secure storage area on the device. S233. Perform a bitwise XOR operation between the old key and the first differential data to generate the new key.

[0080] In a specific embodiment, the device uses the OTP key fragment as the decryption key to decrypt the encrypted differential data carried in the target data packet, obtaining the first differential data. This decryption operation corresponds to the server-side encryption operation, employing a preset authentication and decryption algorithm (such as AES-256-GCM) for authentication and decryption. It should be noted that during the decryption process, the authentication tag carried in the encrypted differential data can be verified first. If the authentication tag verification passes, it indicates that the encrypted differential data has not been tampered with during transmission, and the decrypted first differential data is complete and reliable. If the authentication tag verification fails, the device terminates the key recovery process and discards the received target data packet and OTP key fragment.

[0081] Then, based on the first version identifier in the target data packet, the device loads the old key corresponding to that version identifier from its secure storage area. This secure storage area can be hardware-isolated and protected by a trusted platform module or security element integrated into the device, ensuring that the old key is not accessed or exported without authorization during storage and use. This old key is the currently valid key being used by the device. The device then performs a bitwise XOR operation between the old key and the first differential data to generate a new key.

[0082] After the new key is generated, the device associates it with the second-version identifier and stores it in a secure storage area, while retaining the old key and its corresponding first-version identifier. Retaining the old key supports rollback operations: if communication anomalies occur after the new key is put into use, the device can switch back to the old key to restore normal communication with the service. Simultaneously, the device destroys the OTP key fragment used this time, ensuring that the OTP key fragment is not reused and adhering to the one-time use principle.

[0083] As can be seen, by decrypting differential data using OTP key fragments and XORing it with the local old key to recover the new key, secure incremental updates of the key can be achieved without transmitting the plaintext of the new key.

[0084] Step S24: Generate update completion information based on the new key and send it to the server.

[0085] Specifically, after successfully restoring the new key, the device generates update completion information based on the new key and sends it to the server to notify the server that the key update operation has been successfully completed. This update completion information includes at least a second version identifier, a confirmation status field, and the device's identifier. This identifier helps the server accurately locate the corresponding key association in multi-device management scenarios. The device can use its locally stored private key to digitally sign the update completion information, generating a second signature. The device can then combine this second signature with the update completion information to obtain a signed update completion message, ensuring its anti-forgery capability in a quantum computing environment. The device sends the signed update completion message to the server via a tunnel-mode link.

[0086] As can be seen, by signing and encrypting the update completion information carrying the version identifier and device identifier on the device side, a verifiable and tamper-proof update confirmation is provided to the server, ensuring accurate synchronization of key status in multi-device scenarios.

[0087] 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.

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

[0089] When dividing each function into modules according to its corresponding function. Figure 7 This is a functional block diagram of a quantum-safe key update device based on dual-mode key distribution provided in this application embodiment, applied to a server. The quantum-safe key update device 700 based on dual-mode key distribution includes: The acquisition module 710 is used to acquire the dual-mode link between the server and the device, and determine the distribution mode identifier according to the link status of the dual-mode link; the dual-mode link includes a fiber optic mode link and a tunnel mode link; the distribution mode identifier includes a fiber optic mode identifier or a tunnel mode identifier. The first generation module 720 is used to randomly generate a new key, an OTP key fragment, and a target entropy source value according to the quantum random number generator corresponding to the server. The first determining module 730 is used to determine encrypted differential data based on the old key, the new key, and the OTP key fragment stored on the server and associated with the device; the old key and the new key correspond to a first version identifier and a second version identifier, respectively, and the second version identifier is greater than the first version identifier; The second generation module 740 is used to generate a target data packet based on the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data; The sending module 750 is used to send the OTP key fragment and the target data packet to the device through the dual-mode link; the device recovers the new key based on the OTP key fragment and the target data, generates update completion information based on the new key, and returns it to the server; The response module 760 is configured to, in response to the update completion information returned by the device for the new key, use the new key as the key associated with the device.

[0090] Optionally, in determining the distribution mode identifier based on the link status of the dual-mode link, the acquisition module 710 is specifically used for: Obtain the insertion status and optical power value of the optical module corresponding to the optical fiber mode link; If the insertion state is in place and the optical power value is greater than a preset threshold, then the fiber optic mode link is determined to be available, and the distribution mode identifier is determined as the fiber optic mode identifier. If the insertion state is not in place, and / or the optical power value is less than or equal to the preset threshold, then the fiber optic link is determined to be unavailable, and the tunnel mode link is detected to be in a connected state. If the tunnel mode link is in the connected state, the tunnel mode link is determined to be available, and the distribution mode identifier is determined as the tunnel mode identifier.

[0091] Optionally, in determining the encrypted differential data based on the old key, the new key, and the OTP key fragment stored on the server and associated with the device, the first determining module 730 is specifically used for: Perform a bitwise XOR operation on the old key and the new key to obtain the first difference data; The first differential data is encrypted using the OTP key fragment as the encryption key to obtain the encrypted differential data.

[0092] Optionally, in generating the target data packet based on the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data, the second generation module 740 is specifically used for: The first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data are encapsulated to generate a data packet to be signed; The data packet to be signed is signed using a preset signature generation algorithm to generate a first signature; The data packet to be signed and the first signature are combined to generate the target data packet.

[0093] Optionally, in the process of sending the OTP key fragment and the target data packet to the device via the dual-mode link, the sending module 750 is specifically configured to: The target data packet is sent to the device via the tunnel mode link, and the sending time of the target data packet is recorded. If the distribution mode identifier is the fiber optic mode identifier, then after a preset first time period, the OTP key fragment is sent to the device via the fiber optic mode link; the start time of the preset first time period includes the sending time. If the distribution mode identifier is the tunnel mode identifier, then after a preset second time period, the OTP key fragment is sent to the device via the tunnel mode link; the start time of the preset second time period includes the sending time.

[0094] 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 quantum secure key update device 700 based on dual-mode key distribution can be used to execute the method embodiments of this application, and will not be described again here.

[0095] When dividing each function into modules according to its corresponding function. Figure 8 This is a functional block diagram of another quantum-safe key update device based on dual-mode key distribution provided in this application embodiment, applied to the device side. The quantum-safe key update device 700 based on dual-mode key distribution includes: The receiving module 810 is used to receive a target data packet and an OTP key fragment sent by the server through a dual-mode link between the server and the device; the target data packet includes a first signature, a first version identifier, a second version identifier, a distribution mode identifier, a target entropy source value, and encrypted differential data; The verification module 820 is used to verify the target data packet and the OTP key fragment to obtain the verification result; The second determining module 830 is used to determine a new key based on the target data packet and the OTP key fragment when the verification result is successful; the new key is used as a key associated with the server. The third generation module 840 is used to generate update completion information based on the new key and send it to the server.

[0096] Optionally, in verifying the target data packet and the OTP key fragment to obtain a verification result, the verification module 820 is specifically used for: The first signature is verified using a preset signature verification algorithm; If the first signature verification fails, the verification result is determined to be a verification failure; If the first signature verification is successful, then the first version identifier and the second version identifier are verified; If the first version identifier is greater than or equal to the second version identifier, the verification result is determined to be a verification failure. If the first version identifier is less than the second version identifier, then a verification request is sent to the server with the target entropy source value as the challenge value; Receive the response value generated by the server based on the local OTP key fragment and the challenge value; The response value is compared with the verification value generated by the device using the OTP key fragment and the challenge value; If the response value and the verification value are inconsistent, the verification result is determined to be a verification failure. If the response value and the verification value are consistent, the verification result is determined to be successful.

[0097] Optionally, in determining the new key based on the target data packet and the OTP key fragment, the second determining module 830 is specifically configured to: The encrypted differential data is decrypted using the OTP key fragment to obtain the first differential data; Load the old key corresponding to the first version identifier from the secure storage area on the device. The old key is XORed with the first differential data to generate the new key.

[0098] 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 quantum secure key update device 700 based on dual-mode key distribution can be used to execute the method embodiments of this application, and will not be described again here.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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)).

[0106] 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.

[0107] 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 quantum-safe key update method based on dual-mode key distribution, applied to the server side, characterized in that, The method includes: The dual-mode link between the server and the device is obtained, and the distribution mode identifier is determined according to the link status of the dual-mode link; the dual-mode link includes a fiber optic mode link and a tunnel mode link; the distribution mode identifier includes a fiber optic mode identifier or a tunnel mode identifier. Based on the quantum random number generator corresponding to the server, a new key, an OTP key fragment, and a target entropy source value are randomly generated respectively. Based on the old key, the new key, and the OTP key fragment stored on the server and associated with the device, the encrypted differential data is determined; the old key and the new key correspond to the first version identifier and the second version identifier, respectively, and the second version identifier is greater than the first version identifier; A target data packet is generated based on the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data; The OTP key fragment and the target data packet are sent to the device via the dual-mode link; the device recovers the new key based on the OTP key fragment and the target data, generates update completion information based on the new key, and returns it to the server. In response to the update completion information returned by the device for the new key, the new key is used as the key associated with the device.

2. The method as described in claim 1, characterized in that, The step of determining the distribution mode identifier based on the link status of the dual-mode link includes: Obtain the insertion status and optical power value of the optical module corresponding to the optical fiber mode link; If the insertion state is in place and the optical power value is greater than a preset threshold, then the fiber optic mode link is determined to be available, and the distribution mode identifier is determined as the fiber optic mode identifier. If the insertion state is not in place, and / or the optical power value is less than or equal to the preset threshold, then the fiber optic link is determined to be unavailable, and the tunnel mode link is detected to be in a connected state. If the tunnel mode link is in the connected state, the tunnel mode link is determined to be available, and the distribution mode identifier is determined as the tunnel mode identifier.

3. The method as described in claim 1, characterized in that, The step of determining encrypted differential data based on the old key, the new key, and the OTP key fragment stored on the server and associated with the device includes: Perform a bitwise XOR operation on the old key and the new key to obtain the first difference data; The first differential data is encrypted using the OTP key fragment as the encryption key to obtain the encrypted differential data.

4. The method as described in claim 3, characterized in that, The step of generating a target data packet based on the first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data includes: The first version identifier, the second version identifier, the distribution mode identifier, the target entropy source value, and the encrypted differential data are encapsulated to generate a data packet to be signed; The data packet to be signed is signed using a preset signature generation algorithm to generate a first signature; The data packet to be signed and the first signature are combined to generate the target data packet.

5. The method as described in claim 1, characterized in that, The step of sending the OTP key fragment and the target data packet to the device via the dual-mode link includes: The target data packet is sent to the device via the tunnel mode link, and the sending time of the target data packet is recorded. If the distribution mode identifier is the fiber optic mode identifier, then after a preset first time period, the OTP key fragment is sent to the device via the fiber optic mode link; the start time of the preset first time period includes the sending time. If the distribution mode identifier is the tunnel mode identifier, then after a preset second time period, the OTP key fragment is sent to the device via the tunnel mode link; the start time of the preset second time period includes the sending time.

6. A quantum-safe key update method based on dual-mode key distribution, applied to the device side, characterized in that, The method includes: Through a dual-mode link between the server and the device, the target data packet and the OTP key fragment sent by the server are received respectively; the target data packet includes a first signature, a first version identifier, a second version identifier, a distribution mode identifier, a target entropy source value, and encrypted differential data; The target data packet and the OTP key fragment are verified to obtain the verification result; When the verification result is successful, a new key is determined based on the target data packet and the OTP key fragment; the new key serves as the key associated with the server. An update completion message is generated based on the new key and sent to the server.

7. The method as described in claim 6, characterized in that, The verification of the target data packet and the OTP key fragment to obtain the verification result includes: The first signature is verified using a preset signature verification algorithm; If the first signature verification fails, the verification result is determined to be a verification failure; If the first signature verification is successful, then the first version identifier and the second version identifier are verified; If the first version identifier is greater than or equal to the second version identifier, the verification result is determined to be a verification failure. If the first version identifier is less than the second version identifier, then a verification request is sent to the server with the target entropy source value as the challenge value; Receive the response value generated by the server based on the local OTP key fragment and the challenge value; The response value is compared with the verification value generated by the device using the OTP key fragment and the challenge value; If the response value and the verification value are inconsistent, the verification result is determined to be a verification failure. If the response value and the verification value are consistent, the verification result is determined to be successful.

8. The method as described in claim 6, characterized in that, The step of determining a new key based on the target data packet and the OTP key fragment includes: The encrypted differential data is decrypted using the OTP key fragment to obtain the first differential data; Load the old key corresponding to the first version identifier from the secure storage area on the device. The old key is XORed with the first differential data to generate the new key.

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