Quantum key offline presetting and local activation method and device and related equipment thereof

Abstract

The application provides a quantum key offline presetting and local activation method and device and related equipment thereof, relates to the technical field of quantum security communication, and is used for realizing safe presetting and local safe activation of quantum key materials in a target terminal device. The specific technical scheme is as follows: a Merkle tree is constructed based on original quantum key materials to generate a first root hash value; a random mask is generated, a bitwise exclusive OR operation is performed to generate whitening key materials; a first device root key is generated based on hardware inherent physical features obtained from the target terminal device, and a first packaging key and a first message authentication key are derived; the first packaging key and the first message authentication key are encrypted through an asymmetric public key to generate an authentication tag; the whitening key materials and the first root hash value are respectively encrypted based on the first packaging key to generate an injection container, and the injection container and the random mask are written into the target terminal device. The application is applied to a quantum key safe presetting scene in a network interruption environment.

Description

Technical Field

[0001] This application relates to the field of quantum secure communication technology, and in particular to a method, apparatus and related equipment for offline presetting and local activation of quantum keys. Background Technology

[0002] With the development of quantum communication technology, quantum key distribution has shown great promise in the field of information security. However, due to geographical remoteness or physical limitations, many terminal devices cannot obtain keys in real time via quantum links and need to pre-load quantum key materials into the terminals offline.

[0003] In related technologies, the offline key pre-setting scheme mainly generates key materials through the key management system and then imports them into the terminal device through physical storage media. During the pre-setting process, real-time interactive authentication with the key center is required to ensure legitimacy.

[0004] However, since the establishment of the trust chain depends on the real-time online participation of the network side, when the terminal is in a completely offline environment, the pre-set process cannot be started because it cannot complete the interactive authentication, resulting in the failure of key deployment. At the same time, the key materials stored in the physical medium lack sufficient passive security protection, and attackers can directly extract the valid key after obtaining the medium, resulting in damage to the security of the key system. Summary of the Invention

[0005] This application provides a method, apparatus, and related equipment for offline pre-setting and local activation of quantum keys, which are used to achieve secure pre-setting and local secure activation of quantum key materials in target terminal devices.

[0006] In a first aspect, embodiments of this application provide an offline quantum key pre-setting method, applied to a pre-setting workstation, comprising:

[0007] Generating original quantum key materials based on quantum random number sources;

[0008] A Merkle tree is constructed based on the original quantum key material to generate the first hash value;

[0009] A random mask of the same length as the original quantum key material is generated, and the original quantum key material and the random mask are XORed bit by bit to generate whitened key material.

[0010] Based on the inherent physical characteristics of the hardware obtained from the target terminal device, a first device root key is generated, and a first packaging key and a first message authentication key are derived based on the first device root key.

[0011] The first packaging key and the first message authentication key are encrypted using the asymmetric public key in the asymmetric key pair to generate an authentication tag. The asymmetric key pair is generated on the target terminal device.

[0012] The whitening key material and the first hash value are encrypted based on the first packaging key to generate an injection container containing the encryption result and the authentication tag, and the injection container and the random mask are written into the target terminal device.

[0013] The technical solution provided in this application brings at least the following beneficial effects:

[0014] The quantum key offline pre-setting and local activation method of this application generates original key material through a quantum random number source to ensure the security of the entropy source. Then, it performs bit-by-bit XOR whitening with an equal-length random mask and writes the mask independently to the terminal, so that the whitened key material in storage is only random noise after being removed from the mask. The device root key generated based on the inherent physical characteristics of the terminal hardware has device uniqueness. The packaging key and message authentication key derived from it will not leave the security boundary, so that container decryption is anchored to specific hardware and cannot be decrypted outside the original device. The packaging key and message authentication key are encrypted using the asymmetric public key generated by the target terminal to form an authentication tag. The corresponding private key is only stored inside the terminal, so that the container and terminal identity are cryptographically bound, effectively blocking media copying attacks that clone the container to illegal terminals. The whitened key material and Merkle root hash value are encrypted based on the packaging key to generate an injection container and write it to the terminal. The Merkle root hash value reserves an independent verification benchmark for integrity self-verification under offline conditions. The aforementioned layered encapsulation ensures that the decryption of the injection container requires the simultaneous fulfillment of three conditions: possessing the correct mask, matching PUF hardware characteristics, and the correct asymmetric private key. The absence of any one of these conditions will prevent the recovery of a valid key. This prevents attackers from recovering valid quantum key materials after obtaining a copy of the injection container. Furthermore, the breach of a single terminal device will not compromise the security of other devices or the entire key system.

[0015] One possible implementation is that the injection container includes:

[0016] The encryption key material field is used to store the whitened key material encrypted with the first packaging key;

[0017] The authentication label field is used to store the authentication label;

[0018] The root hash value field is used to store the first root hash value of the Merkle tree after it has been encrypted with the first packaging key.

[0019] Another possible implementation, wherein generating the first device root key based on the inherent physical characteristics of the hardware obtained from the target terminal device, includes:

[0020] An excitation signal is applied to the Physically Unclonable Function (PUF) module of the target terminal device to obtain the original physical response of the PUF module caused by semiconductor manufacturing process deviations.

[0021] The original physical response is subjected to error correction and extraction processing to generate the first device root key.

[0022] Secondly, embodiments of this application provide a quantum key local activation method, applied to a target terminal device, comprising:

[0023] In the offline state, a second device root key is generated based on the inherent physical characteristics of the target terminal device, and a second packaging key and a second message authentication key are derived based on the second device root key;

[0024] Using the second packaging key and the asymmetric private key in the preset asymmetric key pair, the injection container preset in the target terminal device is double-verified and decrypted to obtain the original quantum key material and the first hash value. The injection container includes the encryption result obtained by encrypting the whitened key material and the first hash value with the first packaging key, and the authentication tag generated by encrypting the first packaging key and the first message authentication key with the asymmetric public key.

[0025] Based on the original quantum key material obtained from decryption, the Merkle tree is reconstructed, and the newly generated second hash value is compared with the first hash value obtained from decryption.

[0026] If the comparison passes, an activation key is derived based on the original quantum key material, and a business session key pool is generated using the activation key to complete the local activation of the quantum key. The original quantum key material, the activation key, and the injection container are then securely erased.

[0027] One possible implementation involves using the second packaging key and the asymmetric private key from a pre-set asymmetric key pair to perform double verification and decryption on the injection container pre-installed in the target terminal device to obtain the original quantum key material and the first hash value, including:

[0028] The encryption result in the injection container is decrypted using the second packaging key to obtain the whitened key material and the first hash value;

[0029] The authentication tag in the injection container is decrypted using the asymmetric private key to obtain the first packaging key and the first message authentication key;

[0030] The first packaging key and the first message authentication key obtained by decryption are compared with the second packaging key and the second message authentication key derived from the second device root key;

[0031] If the comparison passes, the original quantum key material is recovered by performing a bit-by-bit XOR operation on the whitened key material using a preset random mask.

[0032] Another possible implementation involves reconstructing the Merkle tree based on the decrypted original quantum key material, and comparing the regenerated second hash value with the decrypted first hash value, including:

[0033] The original quantum key material is divided into multiple pieces, and the hash value of each piece is calculated to obtain the reconstructed leaf nodes;

[0034] The reconstructed leaf nodes are recursively concatenated pairwise and their hash values ​​are calculated until the second root hash value is obtained, which is then compared with the first root hash value.

[0035] Another possible implementation, wherein deriving an activation key based on the original quantum key material and generating a business session key pool using the activation key, includes:

[0036] Using the original quantum key material as the input key material and the activation seed derived from the second device root key as the salt value, the activation key is generated through a key derivation function;

[0037] Based on the activation key and the current count value of the hardware monotonic counter, multiple service session keys are generated sequentially using a pseudo-random function and filled into the service session key pool.

[0038] Another possible implementation, after generating the business session key pool, also includes:

[0039] Each time a service session key is allocated from the service session key pool, the hardware monotonic counter is controlled to perform an atomic increment operation;

[0040] If the count value of the hardware monotonic counter is greater than or equal to the warning threshold and less than the capacity limit of the service session key pool, a key exhaustion warning is triggered to indicate that the target terminal device needs to re-inject the original quantum key material.

[0041] If the count value of the hardware monotonic counter is greater than or equal to the capacity limit, a self-locking protection is triggered to prevent further allocation of service session keys from the service session key pool and to clear the service session key pool.

[0042] Another possible implementation includes, before generating the second device root key based on the inherent physical characteristics of the target terminal device, the following:

[0043] The tamper sensor signal status of the target terminal device is detected. When the signal status indicates that the device casing has been illegally opened, an emergency erase sequence is triggered to destroy the random mask and the asymmetric private key pre-installed in the target terminal device.

[0044] Thirdly, embodiments of this application provide a quantum key offline pre-setting and local activation system, including a pre-setting workstation and a target terminal device;

[0045] The pre-configured workstation is used to execute the offline quantum key pre-configuration method as described in the first aspect;

[0046] The target terminal device is used to execute the quantum key local activation method as described in the second aspect.

[0047] Fourthly, embodiments of this application provide a quantum key offline pre-setting device, comprising:

[0048] The generation module is used to generate raw quantum key materials based on a quantum random number source;

[0049] The generation module is also used to construct a Merkle tree based on the original quantum key material to generate the first hash value;

[0050] The computation module is used to generate a random mask of the same length as the original quantum key material, and to perform a bit-by-bit XOR operation between the original quantum key material and the random mask to generate whitened key material.

[0051] The acquisition module is used to generate a first device root key based on the inherent physical characteristics of the hardware obtained from the target terminal device, and derive a first packaging key and a first message authentication key based on the first device root key;

[0052] An encryption module is used to encrypt the first packaging key and the first message authentication key using the asymmetric public key in the asymmetric key pair to generate an authentication tag, wherein the asymmetric key pair is generated on the target terminal device;

[0053] The writing module is used to encrypt the whitening key material and the first root hash value based on the first packaging key, generate an injection container containing the encryption result and the authentication tag, and write the injection container and the random mask into the target terminal device.

[0054] One possible implementation is that the injection container includes:

[0055] The encryption key material field is used to store the whitened key material encrypted with the first packaging key;

[0056] The authentication label field is used to store the authentication label;

[0057] The root hash value field is used to store the first root hash value of the Merkle tree after it has been encrypted with the first packaging key.

[0058] Another possible implementation, the acquisition module is specifically used for:

[0059] An excitation signal is applied to the Physically Unclonable Function (PUF) module of the target terminal device to obtain the original physical response of the PUF module caused by semiconductor manufacturing process deviations.

[0060] The original physical response is subjected to error correction and extraction processing to generate the first device root key.

[0061] Fifthly, embodiments of this application provide a quantum key local activation device, comprising:

[0062] The generation module is used to generate a second device root key based on the inherent physical characteristics of the target terminal device in the offline state, and derive a second packaging key and a second message authentication key based on the second device root key;

[0063] The verification and decryption module is used to perform dual verification and decryption on the injection container pre-installed in the target terminal device using the second packaging key and the asymmetric private key in the pre-installed asymmetric key pair to obtain the original quantum key material and the first hash value. The injection container includes an encryption result obtained by encrypting the whitened key material and the first hash value using the first packaging key, and an authentication tag generated by encrypting the first packaging key and the first message authentication key using the asymmetric public key.

[0064] The construction module is used to reconstruct the Merkle tree based on the original quantum key material obtained from decryption, and compare the regenerated second root hash value with the decrypted first hash value;

[0065] The generation module is further configured to, upon successful comparison, derive an activation key based on the original quantum key material, generate a business session key pool using the activation key, thereby completing the local activation of the quantum key, and securely erase the original quantum key material, the activation key, and the injection container.

[0066] One possible implementation is that the verification and decryption module is specifically used for:

[0067] The encryption result in the injection container is decrypted using the second packaging key to obtain the whitened key material and the first hash value;

[0068] The authentication tag in the injection container is decrypted using the asymmetric private key to obtain the first packaging key and the first message authentication key;

[0069] The first packaging key and the first message authentication key obtained by decryption are compared with the second packaging key and the second message authentication key derived from the second device root key;

[0070] If the comparison passes, the original quantum key material is recovered by performing a bit-by-bit XOR operation on the whitened key material using a preset random mask.

[0071] Another possible implementation, the building module, is specifically used for:

[0072] The original quantum key material is divided into multiple pieces, and the hash value of each piece is calculated to obtain the reconstructed leaf nodes;

[0073] The reconstructed leaf nodes are recursively concatenated pairwise and their hash values ​​are calculated until the second root hash value is obtained, which is then compared with the first root hash value.

[0074] Another possible implementation is that the generation module is specifically used for:

[0075] Using the original quantum key material as the input key material and the activation seed derived from the second device root key as the salt value, the activation key is generated through a key derivation function;

[0076] Based on the activation key and the current count value of the hardware monotonic counter, multiple service session keys are generated sequentially using a pseudo-random function and filled into the service session key pool.

[0077] Another possible implementation is that the quantum key local activation device further includes an execution module;

[0078] After generating the business session key pool, the execution module is configured to:

[0079] Each time a service session key is allocated from the service session key pool, the hardware monotonic counter is controlled to perform an atomic increment operation;

[0080] If the count value of the hardware monotonic counter is greater than or equal to the warning threshold and less than the capacity limit of the service session key pool, a key exhaustion warning is triggered to indicate that the target terminal device needs to re-inject the original quantum key material.

[0081] If the count value of the hardware monotonic counter is greater than or equal to the capacity limit, a self-locking protection is triggered to prevent further allocation of service session keys from the service session key pool and to clear the service session key pool.

[0082] In another possible implementation, before generating the second device root key based on the inherent physical characteristics of the target terminal device, the execution module is further configured to:

[0083] The tamper sensor signal status of the target terminal device is detected. When the signal status indicates that the device casing has been illegally opened, an emergency erase sequence is triggered to destroy the random mask and the asymmetric private key pre-installed in the target terminal device.

[0084] In a sixth aspect, this application provides an electronic device comprising: a processor and a memory; the memory storing a program or instructions executable on the processor, wherein the program or instructions, when executed by the processor, implement the methods of the first or second aspect described above.

[0085] In a seventh aspect, this application provides a readable storage medium on which a program or instructions are stored, which, when executed by a computer, implement the methods of the first or second aspect described above.

[0086] Eighthly, this application provides a computer program product that is stored in a storage medium and, when executed by a computer, implements the methods of the first or second aspect described above.

[0087] Ninthly, embodiments of this application provide a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the methods described in the first or second aspect.

[0088] The beneficial effects of aspects two through nine mentioned above are described in the corresponding way in aspect one, and will not be repeated here. Attached Figure Description

[0089] Figure 1 This application provides a network architecture for a quantum key offline pre-setting and local activation method.

[0090] Figure 2 This is a flowchart illustrating an offline quantum key pre-setting method provided in an embodiment of this application.

[0091] Figure 3 This is a flowchart illustrating a method for generating a device root key using a physically unclonable feature, as provided in an embodiment of this application.

[0092] Figure 4 This is a flowchart illustrating a quantum key local activation method provided in an embodiment of this application.

[0093] Figure 5 This is a flowchart illustrating a method for performing dual verification and decryption on an injected container using a second packaging key and a preset asymmetric private key, as provided in an embodiment of this application.

[0094] Figure 6 This is a flowchart illustrating a Merkle tree reconstruction and root hash value comparison method provided in an embodiment of this application.

[0095] Figure 7 This is a flowchart illustrating a method for deriving an activation key and generating a service session key pool, as provided in an embodiment of this application.

[0096] Figure 8 This is a flowchart illustrating a key exhaustion warning and self-locking protection method provided in an embodiment of this application.

[0097] Figure 9 This is a flowchart of a quantum key presetting and activation method provided in an embodiment of this application.

[0098] Figure 10 This is a schematic diagram of the structure of an offline quantum key pre-setting device provided in an embodiment of this application.

[0099] Figure 11 This is a schematic diagram of a quantum key local activation device provided in an embodiment of this application.

[0100] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0101] The following section will describe in detail the offline pre-setting and local activation method, apparatus, and related equipment for quantum keys provided in this application, with reference to the accompanying drawings.

[0102] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0103] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0104] The terms "at least one," "at least one of," etc., used in the specification and claims of this application refer to any one, any two, or a combination of two or more of the included items. For example, at least one of a, b, and c can mean: "a," "b," "c," "a and b," "a and c," "b and c," and "a, b, and c," where a, b, and c can be single or multiple. Similarly, "at least two" refers to two or more items, and its meaning is similar to that of "at least one."

[0105] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0106] The embodiments of this application provide a method, apparatus and related equipment for offline pre-setting and local activation of quantum keys, which can be applied to quantum key security pre-setting scenarios in offline environments.

[0107] Existing offline deployment schemes for subkeys have the following technical problems: On the one hand, existing schemes rely on online real-time interactive authentication from the key center to ensure legitimacy during offline pre-deployment. When the terminal is in a completely offline environment, the pre-deployment process cannot start because interactive authentication cannot be completed, resulting in key deployment failure. On the other hand, the key materials stored in the physical medium lack sufficiently strong passive security protection. Attackers can directly extract valid keys after obtaining the physical medium, resulting in compromised key system security. Further analysis by the inventors revealed that the underlying cause of the above problems is that existing technologies have not yet built a complete local trust chain under the constraint of "offline," lacking both the terminal's autonomous authentication capability independent of network interaction and a deep cryptographic encapsulation protection mechanism for the storage medium.

[0108] To address the aforementioned technical problems, this application provides a method, apparatus, and related equipment for offline pre-setting and local activation of quantum keys. This approach separates the pre-setting and activation processes of quantum key materials and anchors a local root of trust based on the inherent physical characteristics of the device hardware. In the pre-setting stage, whitening masking and layered encryption encapsulation techniques are used to convert the original quantum key material into an injection container that can only be decrypted on the target device. In the activation stage, the terminal device autonomously completes the decryption verification, integrity verification, and key derivation of the container based on the local hardware root of trust. Through this method, secure pre-setting and local activation of quantum key materials can be achieved in a completely offline environment, preventing the extraction of valid keys even if the physical storage medium is intercepted.

[0109] The following description, in conjunction with the accompanying drawings, details the offline presetting and local activation method, apparatus, and related equipment for quantum keys provided in this application.

[0110] Figure 1 This illustration shows a network architecture for an offline quantum key pre-setting and local activation method provided in an embodiment of this application. For example... Figure 1 As shown, the network architecture includes a pre-configured workstation 101 and a target terminal device 102. The pre-configured workstation 101 and the target terminal device 102 are interconnected via an offline physical interface.

[0111] In some embodiments, the pre-installed workstation 101 may be a server, a computer, or a processor or processing unit within a server or computer. The server may be a single server or a server cluster comprising multiple servers. The pre-installed workstation 101 is equipped with a certified quantum random number generator (QRNG) for generating raw quantum key materials; the pre-installed workstation 101 also runs a trusted execution environment (TEE) for performing cryptographic operations and processing sensitive data. It should be noted that the specific device form of the pre-installed workstation 101 is not limited in this application embodiment. Figure 1 The example shown is a pre-configured workstation 101 as a single server.

[0112] In some embodiments, the target terminal device 102 may be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, personal computer (PC), ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc., or it may be a dedicated data acquisition terminal, communication base station equipment, or Internet of Things sensor node. This application embodiment does not impose specific limitations. The target terminal device 102 integrates a physically unclonable (PUF) module, a tamper-proof security element (SE), and a trusted execution environment (TEE). Figure 1 The example shown is a dedicated communication terminal, Target Terminal Device 102.

[0113] In some embodiments, a preset workstation 101 is used to perform offline preset operations for the quantum key, and a target terminal device 102 is used to perform local security activation operations for the quantum key. During the quantum key preset stage, the preset workstation 101 establishes an offline connection with the target terminal device 102 via a physical data line; the preset workstation 101 applies an excitation signal to the PUF module of the target terminal device 102, and the target terminal device 102 returns the original physical response generated by the PUF module to the preset workstation 101; the preset workstation 101 generates a first device root key based on this original physical response, and derives a first packaging key and a first message authentication key. Simultaneously, the target terminal device 102 generates an asymmetric key pair within its SE and sends the asymmetric public key to the preset workstation 101 via the physical data line. The preset workstation 101 uses the asymmetric public key to perform asymmetric encryption on the first packaging key and the first message authentication key to generate an authentication tag. The pre-configured workstation 101 further performs symmetric encryption on the whitened key material and the first hash value based on the first packaging key, and packages the encryption result along with the authentication tag into an injection container. Then, the injection container is written to the general non-volatile storage area of ​​the target terminal device 102, while a random mask is written to the SE protected storage area of ​​the target terminal device 102. After writing, the target terminal device 102 returns a verification success signal to the pre-configured workstation 101, and the pre-configured workstation 101 immediately destroys all sensitive data in memory, completing the offline pre-configuration of the quantum key. Subsequently, the target terminal device 102 is deployed to a network-off site. After power-on, it autonomously completes the dual verification decryption of the injection container, Merkle tree integrity verification, activation key derivation, and loading of the business session key pool based on the local hardware root of trust. This local activation process does not require communication with the pre-configured workstation 101 or any other online devices.

[0114] It should be noted that, Figure 1 The network architecture shown is merely an exemplary architecture provided in this application embodiment and does not constitute a limitation on the embodiments of this application. In practical applications, one pre-configured workstation 101 can sequentially pre-configure keys for multiple target terminal devices 102, or multiple pre-configured workstations 101 can perform batch pre-configuration on multiple target terminal devices 102 in parallel. The changes in the above deployment method do not affect the implementation of the embodiments of this application.

[0115] Furthermore, the network architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As network architectures evolve, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0116] See Figure 2 This is a flowchart illustrating an offline quantum key pre-setting method provided in an embodiment of this application. Figure 2 As shown, the quantum key offline pre-setting method provided in this application embodiment can be implemented through the above-mentioned pre-setting workstation, specifically including the following steps 201 to 206.

[0117] Step 201: The pre-set workstation generates the original quantum key material based on the quantum random number source.

[0118] Step 202: The pre-built workstation constructs a Merkle tree based on the original quantum key material to generate the first hash value.

[0119] Step 203: The preset workstation generates a random mask of the same length as the original quantum key material, and performs a bit-by-bit XOR operation between the original quantum key material and the random mask to generate whitened key material.

[0120] Step 204: The pre-configured workstation generates a first device root key based on the inherent physical characteristics of the hardware obtained from the target terminal device, and derives a first packaging key and a first message authentication key based on the first device root key.

[0121] Step 205: The pre-configured workstation encrypts the first packaging key and the first message authentication key using the asymmetric public key in the asymmetric key pair to generate an authentication tag. The asymmetric key pair is generated in the target terminal device.

[0122] Step 206: The pre-set workstation encrypts the whitening key material and the first hash value based on the first packaging key, generates an injection container containing the encryption result and the authentication label, and writes the injection container and the random mask into the target terminal device.

[0123] First, the original quantum key material is generated based on a quantum random number source.

[0124] In this embodiment, the pre-installed workstation is equipped with a certified quantum random number generator (QRNG). This quantum random number generator uses quantum mechanical principles such as the measurement collapse effect of quantum states to generate truly random numbers, thus generating a primitive quantum key material of length L. The quantum random number generator can be a QRNG chip based on photons (such as attenuated laser pulses or single-photon sources) or a QRNG module based on physical effects such as vacuum fluctuations; this application does not limit this. Random numbers generated by a quantum random number source possess entropy source security at the quantum level, ensuring that the key material is unpredictable at its source, providing a solid foundation for the security of subsequent key layers.

[0125] Next, a Merkle tree is constructed based on the original quantum key material to generate the first hash value.

[0126] In this embodiment, the pre-set workstation will use the original quantum key material The key is divided into m data fragments (or key fragments), and a Merkle tree is constructed using each fragment as a leaf node, ultimately yielding a unique first root hash value. The construction process of this Merkle tree is as follows: calculate the hash value of each fragment as a leaf node; then concatenate adjacent leaf nodes pairwise and calculate the hash value again to obtain the parent node of the next level; recursively execute the above pairwise concatenation and hash calculation process layer by layer until the unique root hash value is finally obtained. This root hash value acts as the "data fingerprint" of the original quantum key material, used for subsequent verification of the integrity of the key material by the terminal in a network-off environment. Because hash functions have anti-identical and collision-resistant properties, any modification to the content of the original key material, change of fragment order, or version rollback will cause the reconstructed Merkle tree root hash value to be inconsistent with the original root hash value, thus being detected by the terminal.

[0127] Then, a random mask of the same length as the original quantum key material is generated, and the original quantum key material and the random mask are XORed bit by bit to generate whitened key material.

[0128] In this embodiment, the pre-configured workstation calls a cryptographically secure true random number generator in a trusted execution environment to generate a random mask M of length L (i.e., the same as the original quantum key material). A random bit string of equal length). This random mask M is used to mask the original quantum key material. Perform a bit-by-bit XOR operation to obtain the whitened key material. Key material after whitening treatment Random noise that is statistically uniformly distributed means that even if an attacker obtains... Without knowing the random mask M, it is impossible to recover the original quantum key material. The essence of this whitening operation is to "hide" the original key material under a device-independent random mask, so that even in the extreme case where the encryption layer of the injected container is compromised, the attacker still faces the barrier of needing to obtain the random mask.

[0129] Subsequently, based on the inherent physical characteristics of the hardware obtained from the target terminal device, a first device root key is generated, and a first packaging key and a first message authentication key are derived from the first device root key.

[0130] This step is used to establish a root of trust anchored to the physical characteristics of the terminal device's hardware. A pre-configured workstation applies an excitation signal to the Physically Unclonable Function (PUF) module of the target terminal device via a physical interface (e.g., JTAG, SPI, or a custom debug interface, which is not limited in this embodiment). This obtains the original physical response R of the PUF module, which is generated by random physical deviations inherent in the semiconductor manufacturing process, such as differences in doping concentration, oxide layer thickness fluctuations, and linewidth deviations. Since the PUF's physical response is affected by environmental noise (e.g., temperature fluctuations, voltage drift), directly using the original response may result in bit errors. Therefore, error correction and extraction processing of the original physical response is required. This can be achieved using a fuzzy extractor to perform error correction and stabilization processing on the original physical response, extracting a fixed-length, high-entropy first device root key. .

[0131] After obtaining the first device root key Then, using a key derivation function (KDF, such as HKDF, PBKDF2, or SM3-based KDF, which is not limited in this embodiment) to... The first packaging key is derived from the master key. and the first message authentication key Among them, the first packaging key Used in subsequent steps to symmetrically encrypt the whitened key material and the root hash value, forming the ciphertext payload injected into the container; First message authentication key This is used for subsequent integrity verification of the injected container to ensure that the container content has not been tampered with during storage and transmission.

[0132] The first packaging key and the first message authentication key are encrypted using the asymmetric public key in the asymmetric key pair to generate an authentication tag. This asymmetric key pair is generated on the target terminal device.

[0133] In this embodiment, before or simultaneously with the start of the preset operation, the anti-tampering security unit inside the target terminal device uses its built-in True Random Number Generator (TRNG) to generate a pair of asymmetric keys. , ),in It is an asymmetric private key. This is an asymmetric public key. The pre-configured workstation obtains this asymmetric public key from the target terminal device offline (e.g., via a secure data cable). Then, the workstation uses this asymmetric public key. The first packaging secret derived from the above steps and the first message authentication key Perform asymmetric encryption and generate authentication tags. Due to the nature of asymmetric encryption, only those who possess the corresponding asymmetric private key can use it. Only the target terminal device can decrypt the authentication tag to obtain and This completes the identity authentication process. This mechanism ensures the authentication of the injected container; even if the injected container is copied to other devices, the authentication will not be successful because the corresponding private key is not present in the SE (Security Entity) of those other devices. The correct packaging key and message authentication key cannot be obtained by decrypting the authentication tag, thus making it impossible to complete subsequent decryption and verification.

[0134] Finally, the whitening key material and the first hash value are encrypted based on the first packaging key to generate an injection container containing the encryption result and the authentication label, and the injection container and the random mask are written into the target terminal device.

[0135] In this embodiment, the pre-configured workstation uses the first packaging key. (Symmetric key) respectively for whitened key materials Symmetric encryption is performed with the first hash value Root to obtain the encrypted result. and Enc ( (Root). The above encryption result, together with the authentication tag generated in step 105, is packaged according to a predetermined data structure to generate an injection container. Subsequently, the pre-configured workstation writes the injection container C and the random mask M generated in step 103 into different secure storage areas of the target terminal device via a physical transmission interface (e.g., USB, SDIO, or a custom high-speed interface). Preferably, the injection container can be written to a general storage area of ​​non-volatile memory (such as a normal partition of eMMC), while the random mask M is written to the protected storage area of ​​the tamper-proof secure element (SE) to achieve physical isolation storage of the key material and the mask.

[0136] At this point, the pre-configured workstation has completed the offline injection of quantum key materials into the target terminal device. After writing, a verification command can be sent to the target terminal device, which will read and calculate the checksum of the injected container. Upon confirming the integrity of the written data, it will return a success signal. Upon receiving the success signal, the workstation immediately executes a memory zeroing command to destroy any remaining original key materials in memory. Random mask M, first device root key All sensitive data is collected to eliminate the risk of data leakage in intermediate stages.

[0137] Based on the above method, by introducing a hybrid encryption system that combines whitening mask and layered encryption, the injected container always maintains the ciphertext form in the storage medium. Even if the attacker obtains the physical storage medium, they cannot directly extract the valid key material. At the same time, by binding the decryption capability of the key to the hardware physical characteristics of the terminal device, the injected container can only be decrypted on the original target device, effectively preventing cloned media attacks and device replacement attacks.

[0138] In an optional embodiment, to further clarify the specific data structure of the injection container, this application provides a specific implementation method of the injection container.

[0139] In this embodiment, the injection container C is organized using the following three-field structure:

[0140] The first field is the encryption key material field, used to store the whitened key material encrypted with the first packaging key, i.e. This field is the core payload within the injection container, carrying the key material protected by both whitening concealment and symmetric encryption. During the activation phase, the terminal device first needs to decrypt this field using the first packaging key to obtain the whitened key material, and then use an XOR operation with the random mask M to recover the original quantum key material.

[0141] The second field is the authentication tag field, used to store the authentication tag. This authentication tag is obtained by encrypting the first packaging key and the first message authentication key using an asymmetric public key. Its function is to ensure the ownership authentication of the injection container, meaning that only a specific terminal device holding the corresponding asymmetric private key can decrypt the tag. This field is equivalent to the "digital key" of the injection container, used to bind the injection container to a specific target terminal device, and is the key to achieving one-to-one container-device binding.

[0142] The third field is the root hash value field, which stores the first root hash value of the Merkle tree encrypted with the first packaging key. This field carries the standard reference required for the terminal to perform local integrity self-verification during the activation phase. That is, after decrypting and recovering the original quantum key material, the terminal needs to reconstruct the Merkle tree based on the recovered key material and compare the recalculated root hash value with the first root hash value to verify whether the original quantum key material has been tampered with during storage and transmission.

[0143] The aforementioned three-field structure can be serialized and encoded using TLV (Tag-Length-Value) format or JSON and other structured formats. This application embodiment does not impose specific limitations on this. Through this structured injection container design, a unified container parsing interface is provided between the pre-built workstation and the terminal device, facilitating interoperability between different devices.

[0144] In an optional embodiment, in order to further illustrate the specific process of extracting the device root key from the inherent physical characteristics of the terminal device hardware, this application provides a specific implementation method for generating the device root key through the Physically Unclonable Function (PUF).

[0145] See Figure 3 This is a flowchart illustrating a method for generating a device root key using a physically unclonable feature, as provided in an embodiment of this application. Figure 3 As shown, the method includes steps 301 to 302.

[0146] Step 301: The preset workstation applies an excitation signal to the Physically Unclonable Function (PUF) module of the target terminal device to obtain the original physical response of the PUF module caused by the semiconductor manufacturing process deviation.

[0147] Step 302: The preset workstation performs error correction and extraction processing on the original physical response to generate the first device root key.

[0148] In this embodiment, the pre-installed workstation first applies a specific excitation signal (Challenge) to the Physically Unclonable Function (PUF) module of the target terminal device. The PUF module utilizes the unique and unclonable physical characteristics generated during semiconductor manufacturing due to uncontrollable process deviations (such as differences in transistor threshold voltages, delay deviations in metal interconnects, and the randomness of the initial power-on state of memory cells) to generate a corresponding original physical response to the excitation signal. The incentive signal can be a random challenge value sent by a preset workstation or a fixed challenge value generated by the terminal security unit; this application embodiment does not limit this.

[0149] Because the raw physical response of a PUF may experience minor bit flips during multiple reads due to environmental factors (such as changes in operating temperature, power supply voltage fluctuations, and chip aging), directly using it as a cryptographic key would lead to key inconsistency. Therefore, error correction and extraction processing of the raw physical response are necessary. Specifically, error correction encoding and hash extraction can be performed during the "generation" stage of a fuzzy extractor. The fuzzy extractor first processes the raw physical response... Error correction encoding (e.g., using BCH, Reed-Solomon, or Hamming codes) is performed to generate HelperData; then, the error-corrected response is hashed (e.g., using SHA-256 or SM3 algorithms) to finally obtain a fixed-length, high-entropy first device root key. This HelperData can be stored publicly without revealing the device root key information. It is used in subsequent activation phases to help the terminal device recover the same device root key from the read PUF response.

[0150] Through a PUF-based device root key generation mechanism, each terminal device's device root key originates from the inherent physical variations in its chip manufacturing process. This ensures uniqueness (different chips, even those using the same manufacturing process, will produce different physical responses), non-cloning (even if an attacker possesses the complete manufacturing process, they cannot create a chip with the same PUF response), and tamper-proof properties (any attempt to physically probe the PUF module will alter its physical characteristics, causing the generated root key to change). In this way, the generation of the device root key stems entirely from hardware-level physical randomness, eliminating the need to store it in plaintext on any non-volatile storage medium, fundamentally enhancing the security of the root of trust.

[0151] See Figure 4 This is a flowchart illustrating a quantum key local activation method provided in an embodiment of this application. Figure 4 As shown, the quantum key local activation method provided in this application embodiment can be implemented through the above-mentioned target terminal device, specifically including the following steps 401 to 404.

[0152] Step 401: In the offline state, the target terminal device generates a second device root key based on the inherent physical characteristics of the target terminal device's hardware, and derives a second packaging key and a second message authentication key based on the second device root key.

[0153] Step 402: The target terminal device uses the second packaging key and the asymmetric private key in the pre-set asymmetric key pair to perform double verification and decryption on the injection container pre-set in the target terminal device to obtain the original quantum key material and the first hash value.

[0154] Step 403: The target terminal device reconstructs the Merkle tree based on the original quantum key material obtained from decryption, and compares the regenerated second hash value with the first hash value obtained from decryption.

[0155] Step 404: If the comparison is successful, the target terminal device derives an activation key based on the original quantum key material, generates a business session key pool through the activation key, completes the local activation of the quantum key, and securely erases the original quantum key material, the activation key, and the injection container.

[0156] First, in the offline state, a second device root key is generated based on the inherent physical characteristics of the target terminal device's hardware, and a second packaging key and a second message authentication key are derived based on the second device root key.

[0157] Specifically, when the target terminal device is deployed to the network outage site and powered on, its tamper-proof security unit (SE) first re-powers the Physically Unclonable Function (PUF) module, applies the same excitation signal as in the preset stage, and obtains the current PUF physical response R′. Due to the repeatability of the PUF response, the current response R′ obtained under the same excitation signal should be highly consistent with the original physical response R obtained in the preset stage within the error-correctable range of the error-correcting code. Using the auxiliary data HelperData generated in the preset stage (which can be read from the non-volatile storage area of ​​the security unit), the current response R′ is corrected through the "reconstruction" stage of the fuzz extractor, and the second device root key consistent with the preset stage is reconstructed from it. The second device root key Theoretically, it should be the same as the root key of the first device. They are completely identical, meaning they both originate from the physical response of the same excitation point in the same PUF module and are processed by the same fuzz extractor.

[0158] Then, within a Trusted Execution Environment (TEE) or Security Element (SE), the terminal device uses the same key derivation function KDF as in the pre-configuration phase, with the second device root key. The second wrapper key is derived from the master key. Second message authentication key The entire derivation process described above is executed within a security boundary, and the intermediate values ​​of each derivation key are not exposed to a typical rich execution environment (REE), thereby ensuring the security of the key derivation chain.

[0159] Then, using the second packaging key and the asymmetric private key in the pre-set asymmetric key pair, the injection container pre-set in the target terminal device is double-verified and decrypted to obtain the original quantum key material and the first hash value.

[0160] In this embodiment, the terminal device's TEE reads the preset injection container C from the non-volatile memory and simultaneously reads the preset asymmetric private key from the protected storage area of ​​the SE. And a random mask M. TEE uses a second wrapper key derived from the local PUF response. and asymmetric private key The injected container C undergoes a dual verification and decryption process: firstly, the ciphertext portion is decrypted using a locally derived symmetric key (the second wrapper key); secondly, the authentication tag portion is decrypted using a hardware-stored asymmetric private key. The intermediate results obtained through these two independent decryption paths are cross-checked to verify the ownership and integrity of the injected container.

[0161] After both verifications pass, the terminal device recovers the original quantum key material. And the first root hash value.

[0162] Then, the Merkle tree is reconstructed based on the original quantum key material obtained from decryption, and the regenerated second hash value is compared with the first hash value obtained from decryption.

[0163] In this embodiment, the target terminal device is based on the recovered original quantum key material. The Merkle tree is reconstructed using the exact same fragment size, hash algorithm, and concatenation method as the pre-set stage. Specifically: The system is divided into m segments. For each segment, a hash value is calculated to obtain the reconstructed leaf nodes. Then, the hashes are recursively concatenated pairwise until the second hash value, Root′, is obtained. The second hash value Root′ is compared with the first hash value Root obtained from the decryption of the injection container. If Root′ = Root, it proves that the original quantum key material in the storage medium is completely consistent with the material generated in the pre-setting stage and has not been tampered with or replaced. If they are inconsistent, it is determined that the key material has been tampered with, and the activation process is immediately terminated.

[0164] Finally, if the comparison passes, an activation key is derived from the original quantum key material, and a business session key pool is generated using the activation key to complete the local activation of the quantum key. The original quantum key material, the activation key, and the injection container are then securely erased.

[0165] After the Merkle tree integrity verification is passed, the terminal device recovers the original quantum key material within the TEE. For input key material, and combined with the activation seed derived from the local hardware trust root (e.g. ), generate activation keys using key derivation algorithms such as HKDF. The activation key This is used to further derive a business session key pool for use by upper-layer business modules in scenarios such as communication encryption.

[0166] After the business session key pool is loaded, the terminal device immediately performs a secure erasure operation: first, the original quantum key material is erased via low-level memory overwrite instructions. and activation key The memory address is repeatedly overwritten with cryptographic pseudo-random numbers and then cleared to zero. Next, a secure erase command is sent to the storage controller to erase the physical sector containing the injected container C, eliminating any ciphertext residue on the storage medium. After secure erasure, no traces of the original quantum key material are retained inside the terminal device, achieving "use and destroy" of the key material after activation, thus preventing cold start attacks and offline analysis attacks on the storage medium.

[0167] In this embodiment, the terminal device, in a completely offline state, completes the entire process of key material authentication, decryption, integrity verification, key derivation, and service loading solely relying on the local hardware root of trust (PUF) and a pre-configured injection container. The entire activation process does not depend on any network communication or third-party online services, achieving local autonomous secure activation of the quantum key.

[0168] In an optional embodiment, to further illustrate the detailed process of dual verification and decryption, this application provides a specific implementation of the method.

[0169] See Figure 5 This is a flowchart illustrating a method for performing dual verification and decryption on an injected container using a second packaging key and a preset asymmetric private key, as provided in an embodiment of this application. Figure 5 As shown, the method includes steps 501 to 504.

[0170] Step 501: The target terminal device decrypts the encryption result injected into the container using the second packaging key to obtain the whitened key material and the first hash value.

[0171] Step 502: The target terminal device decrypts the authentication tag in the injected container using the asymmetric private key to obtain the first packaging key and the first message authentication key.

[0172] Step 503: The target terminal device compares the decrypted first packaging key and first message authentication key with the second packaging key and second message authentication key derived from the second device root key.

[0173] Step 504: If the comparison passes, the target terminal device performs a bit-by-bit XOR operation on the whitened key material using a preset random mask to recover the original quantum key material.

[0174] First, the encryption result injected into the container is decrypted using the second packaging key to obtain the whitened key material and the first hash value.

[0175] In this embodiment, the terminal device's TEE uses the second packaging key derived from the local PUF response. For the cryptographic key material field injected into the container Symmetric decryption is performed to obtain the whitened key material. At the same time, for the root hash value field Perform symmetric decryption to obtain the first hash value. It is important to note that the decryption operation here only uses the locally derived symmetric key; decryption of asymmetric keys is not yet involved.

[0176] Then, the authentication tag injected into the container is decrypted using the asymmetric private key to obtain the first packaging key and the first message authentication key.

[0177] Specifically, the terminal device reads a pre-installed asymmetric private key from the protected secure storage area of ​​the SE. The asymmetric private key is used to perform asymmetric decryption of the Tag field in the injected container: This allows the use of an asymmetric public key by a pre-configured workstation. The first package key for encryption and the first message authentication key Since the asymmetric key pair is generated within the target terminal device's SE, It is stored only in the SE of the target terminal device, so only that specific device can correctly decrypt the authentication tag.

[0178] Then, the decrypted first packaging key and first message authentication key are compared with the second packaging key and second message authentication key derived from the second device root key.

[0179] TEE will decrypt the first packaging key. Second Packaging Key Derived Locally Perform a byte-by-byte comparison and use the first message authentication key. Second message authentication key derived locally A byte-by-byte comparison is performed. Since the first packaging key and the first message authentication key both originate from the PUF response in the pre-configuration phase, while the second packaging key and the second message authentication key originate from the PUF response in the activation phase, if the terminal device is the original target device and the PUF response has not undergone uncorrectable changes, the key values ​​derived from both ends should be completely identical. If the comparison matches, it proves from a cryptographic perspective that the hardware identity of the terminal device is consistent with that in the pre-configuration phase, i.e., the injection container does indeed belong to this terminal device; if the comparison does not match, it indicates that the hardware identity of the terminal device does not match that in the pre-configuration phase (possibly due to device replacement, damage to the PUF module, or attempted physical probing, etc.), and the TEE terminates the subsequent activation process and records a security anomaly log.

[0180] Finally, if the comparison passes, the original quantum key material is recovered by performing a bit-by-bit XOR operation on the whitened key material using a preset random mask.

[0181] TEE reads a preset random mask M from the protected storage area of ​​SE, and decrypts the resulting whitened key material. Perform a bitwise XOR operation with the random mask M: Thus, the complete original quantum key material can be recovered. Because the random mask M and the whitened key material are physically stored separately (in the secure storage area of ​​SE and the general non-volatile storage area respectively), attackers need to compromise both storage areas simultaneously to recover the original key material, significantly raising the barrier to key recovery.

[0182] Through the aforementioned dual verification mechanism, the container decryption verification of the symmetric key path and the authentication tag decryption verification of the asymmetric key path mutually verify the results of the two paths, forming a double insurance: even if an attacker cracks the symmetric encryption, they cannot pass the asymmetric authentication verification; conversely, even if they obtain the asymmetric private key, they cannot complete the symmetric decryption without the PUF derived key.

[0183] In an optional embodiment, to further illustrate the detailed process of Merkle tree reconstruction and root hash value comparison, this application provides a specific implementation of the method.

[0184] See Figure 6 This is a flowchart illustrating a Merkle tree reconstruction and root hash value comparison method provided in an embodiment of this application. Figure 6 As shown, the method includes steps 601 to 602.

[0185] Step 601: The target terminal device divides the original quantum key material into multiple pieces and calculates the hash value for each piece to obtain the reconstructed leaf nodes.

[0186] Step 602: The target terminal device recursively concatenates the reconstructed leaf nodes pairwise and calculates the hash value until the second hash value is obtained, so as to compare the second hash value with the first hash value.

[0187] First, the original quantum key material is divided into multiple pieces, and the hash value of each piece is calculated to obtain the reconstructed leaf nodes.

[0188] In this embodiment, the TEE will recover the original quantum key material. The data is divided into m fragments according to the fragmentation granularity agreed upon in the pre-defined stage (the fragmentation granularity can be consistent with the number of fragments m and the fragmentation size S in the pre-defined stage; this application embodiment does not limit this). For each fragment... (in ), calculate its hash value in sequence. (Alternatively, other cryptographic hash algorithms may be used, such as SM3. This application uses SHA256 as an example only and does not constitute a limitation.) Each hash value That is, the first step in reconstructing the Merkle tree. There are 10 leaf nodes. The hash algorithm described above must be consistent with the hash algorithm used in the pre-set stage when comparing the root hash value.

[0189] Finally, the reconstructed leaf nodes are recursively concatenated pairwise and their hash values ​​are calculated until the second hash value is obtained, which is then compared with the first hash value.

[0190] TEE pairs the m leaf nodes obtained in the same order as the preset stage, and for each pair of leaf nodes... After concatenation, a hash calculation is performed to obtain the node at the next higher level: (When the number of leaf nodes is odd, the last node can be concatenated with itself or directly promoted to the next level; this embodiment does not limit this.) The above pairwise hash concatenation operation is recursively performed layer by layer, with the number of nodes calculated halved at each layer, until a unique root node, i.e., the second root hash value Root′, is finally obtained. Then, the second root hash value Root′ is fully compared with the decrypted first root hash value Root.

[0191] If Root′ = Root, the terminal device confirms that the original quantum key material in the storage medium is completely consistent with the original material generated by the pre-installed workstation, and has not been tampered with, replaced, or rolled back in any form throughout its entire lifecycle (storage, transportation, deployment). This integrity verification process is performed entirely locally on the terminal, without needing to connect to any remote authentication server or key center. Leveraging the data structure characteristics of the Merkle tree, the terminal device can autonomously prove the integrity of the key material with cryptographic-level security even when offline, effectively preventing attackers from using old versions to inject containers for rollback attacks (i.e., attackers replacing obsolete or cracked old version key material into the storage medium, inducing the terminal to use a downgraded key).

[0192] In an optional embodiment, to further illustrate the detailed process of activation key derivation and business session key pool generation, this application provides a specific implementation of the method.

[0193] See Figure 7 This is a flowchart illustrating a method for activation key derivation and business session key pool generation provided in an embodiment of this application. Figure 7 As shown, the method includes steps 701 to 702.

[0194] Step 701: The target terminal device uses the original quantum key material as the input key material and the activation seed derived from the root key of the second device as the salt value to generate an activation key through a key derivation function.

[0195] Step 702: The target terminal device generates multiple service session keys sequentially using a pseudo-random function based on the activation key and the current count value of the hardware monotonic counter, and fills them into the service session key pool.

[0196] First, using the original quantum key material as the input key material and the activation seed derived from the second device root key as the salt value, the activation key is generated through the key derivation function.

[0197] Specifically, the TEE of the terminal device will recover the original quantum key material. The activation seed obtained from the PUF-derived chain will be used as the input key material (IKM). As the salt, the activation key is calculated using an HMAC-based key derivation function (e.g., a two-stage mode of HKDF-Extract and HKDF-Expand, which is not limited in this embodiment) combined with context information (e.g., the string "ACT", used to identify the scope of the key's use and prevent the key from being used for different purposes). The derivation process of the activation key is encapsulated within the TEE, and its input materials... Decryption and recovery from the injected container, salt value The derivation chain originating from the PUF hardware root of trust—both have different origins and independent paths, but together determine the activation key. Ultimate security.

[0198] Then, based on the activation key and the current count value of the hardware monotonic counter, multiple business session keys are generated sequentially through a pseudo-random function and filled into the business session key pool.

[0199] The TEE allocates a dedicated area within the SE's secure memory space as a business session key pool (Pool). The pool's capacity is N (N is a positive integer, which can be preset according to business needs and security policies). The TEE reads the current count value (ctr) of a hardware monotonic counter (initially 0) stored in the rollback-resistant non-volatile storage area. For each index value from 0 to N-1... To activate the key The master key is used, with the current count value ctr as one of the input parameters (or the index). As input parameters, each service session key is generated sequentially using a pseudo-random function (PRF, such as HMAC-SHA256 or AES-CMAC, which is not limited in this embodiment). All generated business session keys They are sequentially populated into the business session key pool (Pool).

[0200] After the business session key pool is filled, the TEE immediately processes the original quantum key material. and activation key The memory region where it resides executes low-level memory overwrite instructions, using cryptographic pseudo-random numbers to overwrite it multiple times before clearing it to zero. At this point, the original quantum key material and activation key are immediately destroyed after fulfilling their mission. Even if the business layer subsequently suffers a memory dump attack, the attacker will not be able to trace back and obtain the pre-set quantum root material.

[0201] In an optional embodiment, in order to further prevent the business session key from being exhausted and abused and to provide the key level monitorability, this application embodiment provides a key exhaustion early warning and self-locking protection method.

[0202] See Figure 8 This is a flowchart illustrating a key exhaustion warning and self-locking protection method provided in an embodiment of this application. Figure 8 As shown, the method includes steps 801 to 803.

[0203] Step 801: Each time a service session key is allocated from the service session key pool, the target terminal device controls the hardware monotonic counter to perform an atomic increment operation.

[0204] Step 802: If the count value of the hardware monotonic counter is greater than or equal to the warning threshold and less than the capacity limit of the service session key pool, the target terminal device triggers a key exhaustion warning to indicate that the target terminal device needs to re-inject the original quantum key material.

[0205] Step 803: If the count value of the hardware monotonic counter is greater than or equal to the capacity limit, the target terminal device triggers self-locking protection to prevent the continued allocation of service session keys from the service session key pool and clear the service session key pool.

[0206] In this embodiment of the application, after generating the business session key pool, the terminal device sets a hardware monotonic counter to unidirectionally count and record the key usage, and performs corresponding control operations based on the comparison result of the count value and the preset threshold.

[0207] First, each time a business session key is allocated from the business session key pool, the hardware monotonic counter is controlled to perform an atomic increment operation.

[0208] In this embodiment, when the upper-layer service module requests the TEE to allocate a service session key, the TEE first reads the current value of the hardware monotonic counter, ctr, retrieves the ctr-th service session key (i.e., SK_{ctr}) from the service session key pool, and delivers it to the hardware encryption / decryption engine. Then, it controls the hardware monotonic counter to increment atomically, and writes the allocation record and increment operation to the anti-tampering log. An atomic increment operation means that the read, increment, and write-back operations of the counter are indivisible at the hardware level, with no possibility of interruption or tampering in the intermediate state, thus ensuring that the monotonic increment property of the counter is not violated under any circumstances.

[0209] Secondly, a key exhaustion warning is triggered when the count value of the hardware monotonic counter is greater than or equal to the warning threshold and less than the capacity limit of the business session key pool.

[0210] In this embodiment, an early warning threshold is set. ,in For the early warning ratio (e.g.) (This application embodiment does not limit this), N is the upper limit of the capacity of the service session key pool. When and When the TEE finishes processing the current key request, it may illuminate a yellow warning indicator light via a hardware GPIO port, send an alarm message to the device management module, or record the warning event in the system log (this embodiment may adopt one or more of the above methods, which is not limited). The purpose of the warning is to indicate to the administrator or upper-layer system that the key stock of the current device is about to be exhausted, and that a key material re-injection operation needs to be arranged as soon as possible to avoid service interruption after the key is exhausted.

[0211] Finally, if the count value of the hardware monotonic counter is greater than or equal to the capacity limit, a self-locking protection is triggered to prevent further allocation of business session keys from the business session key pool and to clear the business session key pool.

[0212] In this embodiment, when When the TEE determines that the key pool has been exhausted, it immediately triggers a self-locking mechanism: it stops responding to any new key allocation requests; it clears all residual derived keys within the SE; it performs a secure erasure of all keys in the business session key pool (each key in the pool can be overwritten multiple times using cryptographically strong pseudo-random numbers); and optionally, it sends a power management command to the motherboard to put the system into a deep sleep mode or a complete power-off state to prevent attackers from using the system for illegal operations during the window of opportunity after the keys are exhausted.

[0213] Through the aforementioned key depletion early warning and self-locking protection mechanism, the entire lifecycle of the key pool level can be monitored, from the key pool being full, through normal consumption entering the early warning state, to depletion and self-locking, with corresponding control strategies for each stage. At the cryptographic level, each business session key is discarded after one use (because the counter increments unidirectionally, and a different key is allocated next time), effectively preventing key reuse attacks.

[0214] In an optional embodiment, in order to further enhance the protection capabilities of the terminal device at the physical security level, this application provides an emergency erasure method based on tamper detection.

[0215] In this embodiment of the application, before performing the step of generating a second device root key based on the inherent physical characteristics of the hardware, the terminal device first detects the status of its anti-tamper sensor signal to determine whether the device casing has been illegally opened.

[0216] The system detects the tamper sensor signal status of the target terminal device. When the signal status indicates that the device casing has been illegally opened, it triggers an emergency erase sequence to destroy the pre-installed random mask and asymmetric private key in the target terminal device.

[0217] Specifically, when the terminal device is powered on, its tamper-proof security unit (SE) reads signals from a series of tamper-proof sensors connected to the motherboard in real time. These tamper-proof sensors include, but are not limited to, one or more of the following types of sensors: microswitches (installed at the seams of the device housing, whose switch state changes when the housing is opened), photosensitive sensors (installed inside the device, whose readings change when the ambient light intensity changes when the housing is opened), capacitive proximity sensors (detecting changes in capacitance between the housing and the internal structure), and conductive adhesive strips (embedded in the seams of the housing to form a closed loop, which breaks when the housing is opened). This application does not limit the specific type of sensor described herein.

[0218] If the tamper sensor's signal status indicates that the device casing has been illegally opened (e.g., a microswitch changes from closed to open, a photosensor detects light intensity exceeding a preset threshold, or the resistance of the conductive adhesive strip circuit becomes infinite), the SE immediately triggers an emergency erase sequence. This emergency erase sequence includes: First, the SE immediately destroys all sensitive data stored internally (including the random mask M and the asymmetric private key SK). T(This includes auxiliary data such as HelperData and device root key). Secondly, the SE sends a secure erase command to the storage controller targeting the physical sector where the injection container is located, using cryptographically strong pseudo-random numbers to repeatedly overwrite the storage sector. After the emergency erase, all key materials and sensitive data within the terminal device are completely erased. Even if an attacker physically disassembles the device casing, they cannot recover any valuable key information from the storage medium, and the device enters a locked state.

[0219] This tamper detection mechanism provides active physical protection for terminal devices. Traditional key storage schemes rely on external physical encapsulation (such as seals and tamper-evident tags) and only provide a "passive alarm" function. However, the tamper detection mechanism of this application can automatically trigger key destruction as soon as physical intrusion is detected, realizing a leap from "passive defense" to "active erasure" and effectively resisting physical attack methods against terminal devices.

[0220] To more intuitively demonstrate the application of the technical solution of this application in real-world scenarios, the following explanation will be based on a specific application scenario.

[0221] See Figure 9 This is a flowchart illustrating a quantum key presetting and activation method provided in an embodiment of this application. The following example uses a data acquisition scenario at a remote substation of a power company. Figure 9 The application of the technical solution in this application is explained.

[0222] like Figure 9 As shown, the substation is located in a remote mountainous area with no internet coverage or fiber optic communication links, relying solely on satellite communication to periodically upload small amounts of data. Due to the sensitivity of the environment (involving power grid operation data), communication between the terminal equipment and the data center requires high-strength encryption, but the bandwidth and latency of the satellite link prevent it from obtaining quantum keys through real-time QKD.

[0223] Deployment and implementation process:

[0224] First, in a dedicated secure computer room within the power company, the administrator initiates the key pre-configuration process on an offline pre-configured workstation. The workstation's built-in QRNG module generates a raw quantum key material (K) of 4096 bytes in length. raw The workstation divides the key material into 128 fragments (32 bytes each), constructs a Merkle tree, and records the root hash value Root. Simultaneously, the workstation generates a 4096-byte random mask M, which, along with K... raw Bit-by-bit XOR yields whitened key material K white .

[0225] Then, the administrator connects the data acquisition terminal to be deployed to the pre-configured workstation via a dedicated data cable. The workstation applies an excitation to the terminal's PUF module, acquires the raw physical response, and processes it through a fuzz extractor to obtain the first device root key K. root This leads to the derivation of the first packaging key K. wrap and the first message authentication key K mac The SE chip inside the terminal generates an SM2 key pair (SK). T PK T ), will PK T Data is transmitted to the workstation via data cable. The workstation uses the PK within the TEE. T For K wrap and K mac The authentication tag is obtained through encryption and then injected into a container C, which, along with a random mask M, is written to the terminal's secure storage area. After the write operation is complete, the workstation securely erases the sensitive data in memory.

[0226] Afterwards, the administrator transported the pre-configured data acquisition terminal to a substation in a remote mountainous area. In a completely disconnected environment, the on-site technicians powered on the terminal. The terminal SE first detected the tamper sensor signal (the device casing was in a normally closed state, and the signal was normal), then powered on the PUF module again, reconstructing the second device root key K. root ′, Derived second packaging key K wrap ′ and second message authentication key K mac ′.

[0227] TEE reads the injection container C and the random mask M, performs a double verification and decryption process, and recovers the original quantum key material K. raw The Merkle tree is reconstructed and compared with the first hash value—if the verification passes, it indicates that the injected container has not been tampered with and the terminal identity is legitimate. Subsequently, the TEE is based on K... raw Activation seed K derived from PUF seed Activation key K is generated via HKDF. act A business session key pool with a capacity of 10,000 is established in the SE's secure memory. All original key materials and activation keys are erased immediately after the pool is loaded.

[0228] During subsequent data collection and reporting, each time a business session requires data encryption, the TEE sequentially retrieves a business session key from the key pool, with the hardware monotonic counter atomically incrementing. When the number of used keys reaches 8500 (85% of the capacity), the terminal alerts the administrator via a warning indicator to prepare for re-injecting key materials; when the counter reaches 10000, the terminal triggers self-locking protection and enters deep sleep mode until new key materials are injected.

[0229] As can be seen from the above application scenarios, the technical solution of this application embodiment can securely complete the pre-installation, local activation and service loading of quantum key materials in an environment with complete network disconnection and no remote interaction. It is suitable for scenarios with insufficient communication link coverage but high requirements for data security, such as unmanned base stations in deep mountains, underground bunkers, remote sensor networks, and offshore platforms.

[0230] This application also provides a quantum key offline pre-setting and local activation system, which includes a pre-setting workstation and a target terminal device.

[0231] The pre-configured workstation is designed to execute the aforementioned offline quantum key pre-configuration method. Specifically, the pre-configured workstation includes the following functional modules: a quantum random number generator (QRNG) module for generating raw quantum key materials; a cryptographic operation module (running in the workstation's TEE environment) for constructing Merkle trees, generating random masks, performing XOR operations, deriving keys, and constructing injection containers; a physical communication module for establishing a connection with the target terminal device via a physical data line to exchange data (including PUF stimulus injection, public key acquisition, container writing, etc.); and a secure erasure module for thoroughly erasing sensitive data in memory after pre-configuration is completed.

[0232] The target terminal device is configured to execute the aforementioned quantum key local activation method. Specifically, the target terminal device includes the following core hardware components: a Physically Unclonable Function (PUF) module for generating a unique physical response based on semiconductor manufacturing process variations; a Tamper-Proof Security Unit (SE) for securely storing asymmetric private keys, random masks, and sensitive data, and executing an emergency erase sequence; a Trusted Execution Environment (TEE) for performing double-checked decryption, Merkle tree integrity verification, key derivation, and loading of the business session key pool; tamper-proof sensor components (such as microswitches, photosensors, etc.) for detecting whether the device casing has been illegally opened; a hardware monotonic counter (stored in a rollback-proof non-volatile storage area) for unidirectionally counting the usage of the business session key; and a storage controller for executing secure erase commands.

[0233] The pre-configured workstation and the target terminal device are connected via an offline physical interface (such as a USB cable or a custom debugging cable) to complete the pre-installation of key materials. After pre-configuration, the target terminal device is deployed to the offline site to independently complete local activation of the key and service loading.

[0234] It should be noted that the above-described method embodiments, or the various possible implementations of the method embodiments, can be executed individually, or, provided there is no conflict, they can be combined with each other. The specific implementation can be determined according to actual usage requirements, and this application embodiment does not impose any restrictions on this.

[0235] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in 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.

[0236] This application embodiment can divide the quantum key offline pre-setting device and the quantum key local activation device into functional modules according to the above method examples. For example, each function can be divided into a separate 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. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0237] In an optional embodiment, this application also provides an offline quantum key presetting device. This offline quantum key presetting device may include one or more functional modules for implementing the offline quantum key presetting method of the above method embodiments.

[0238] For example, Figure 10 This is a schematic diagram of a quantum key offline pre-setting device provided in an embodiment of this application. Figure 10 As shown, the quantum key offline pre-setting device 1000 includes: a generation module 1001, a calculation module 1002, an acquisition module 1003, an encryption module 1004, and a writing module 1005.

[0239] The generation module 1001 is used to generate the original quantum key material based on the quantum random number source; and to construct a Merkle tree based on the original quantum key material to generate the first hash value.

[0240] The computation module 1002 is used to generate a random mask of the same length as the original quantum key material, and to perform a bit-by-bit XOR operation between the original quantum key material and the random mask to generate whitened key material.

[0241] The acquisition module 1003 is used to generate a first device root key based on the inherent physical characteristics of the hardware obtained from the target terminal device, and derive a first packaging key and a first message authentication key based on the first device root key;

[0242] The encryption module 1004 is used to encrypt the first packaging key and the first message authentication key using the asymmetric public key in the asymmetric key pair to generate an authentication tag. The asymmetric key pair is generated in the target terminal device.

[0243] The writing module 1005 is used to encrypt the whitening key material and the first hash value based on the first packaging key, generate an injection container containing the encryption result and the authentication label, and write the injection container and the random mask into the target terminal device.

[0244] In an alternative embodiment, the injection container includes:

[0245] The encryption key material field is used to store the whitened key material encrypted with the first packaging key;

[0246] The authentication label field is used to store the authentication label;

[0247] The root hash field is used to store the first root hash of the Merkle tree encrypted with the first wrapping key.

[0248] In an optional embodiment, the acquisition module 1003 is specifically used for:

[0249] Apply an excitation signal to the Physically Unclonable Function (PUF) module of the target terminal device to obtain the original physical response of the PUF module caused by semiconductor manufacturing process deviations.

[0250] The original physical response is corrected and extracted to generate the first device root key.

[0251] In an optional embodiment, this application also provides a quantum key local activation device. This quantum key local activation device may include one or more functional modules for implementing the quantum key local activation method of the above method embodiments.

[0252] For example, Figure 11 This is a schematic diagram of a quantum key local activation device provided in an embodiment of this application. Figure 11 As shown, the quantum key local activation device 1100 includes: a generation module 1101, a verification and decryption module 1102, a construction module 1103, and an execution module 1104.

[0253] The generation module 1101 is used to generate a second device root key based on the inherent physical characteristics of the target terminal device in the offline state, and derive a second packaging key and a second message authentication key based on the second device root key.

[0254] The verification and decryption module 1102 is used to perform double verification and decryption on the injection container pre-installed in the target terminal device using the second packaging key and the asymmetric private key in the pre-installed asymmetric key pair to obtain the original quantum key material and the first hash value. The injection container includes the encryption result obtained by encrypting the whitened key material and the first hash value using the first packaging key, and the authentication tag generated by encrypting the first packaging key and the first message authentication key using the asymmetric public key.

[0255] Module 1103 is used to reconstruct the Merkle tree based on the original quantum key material obtained from decryption, and compare the regenerated second hash value with the first hash value obtained from decryption;

[0256] The generation module 1101 is also used to derive an activation key based on the original quantum key material if the comparison is successful, generate a business session key pool through the activation key to complete the local activation of the quantum key, and securely erase the original quantum key material, the activation key, and the injection container.

[0257] In an optional embodiment, the verification and decryption module 1102 is specifically used for:

[0258] The encryption result injected into the container is decrypted using the second packaging key to obtain the whitened key material and the first hash value;

[0259] The authentication tag injected into the container is decrypted using the asymmetric private key to obtain the first packaging key and the first message authentication key;

[0260] The decrypted first packaging key and first message authentication key are compared with the second packaging key and second message authentication key derived from the second device root key;

[0261] If the comparison passes, the original quantum key material is recovered by performing a bit-by-bit XOR operation on the whitened key material using a preset random mask.

[0262] In an optional embodiment, the construction module 1103 is specifically used for:

[0263] The original quantum key material is divided into multiple pieces, and the hash value of each piece is calculated to obtain the reconstructed leaf nodes;

[0264] The reconstructed leaf nodes are recursively concatenated pairwise and their hash values ​​are calculated until a second hash value is obtained. The second hash value is then compared with the first hash value.

[0265] In an optional embodiment, the generation module 1101 is specifically used for:

[0266] Using the original quantum key material as the input key material and the activation seed derived from the second device root key as the salt value, the activation key is generated through the key derivation function;

[0267] Based on the activation key and the current count value of the hardware monotonic counter, multiple business session keys are generated sequentially using a pseudo-random function and then added to the business session key pool.

[0268] In an optional embodiment, after generating the business session key pool, execution module 1104 is used to:

[0269] Each time a business session key is allocated from the business session key pool, the hardware monotonic counter is controlled to perform an atomic increment operation;

[0270] If the count value of the hardware monotonic counter is greater than or equal to the warning threshold and less than the capacity limit of the business session key pool, a key exhaustion warning is triggered to indicate that the target terminal device needs to re-inject the original quantum key material.

[0271] If the count value of the hardware monotonic counter is greater than or equal to the capacity limit, a self-locking protection is triggered to prevent further allocation of business session keys from the business session key pool and to clear the business session key pool.

[0272] In an optional embodiment, before generating the second device root key based on the inherent physical characteristics of the target terminal device, the execution module 1104 is further configured to:

[0273] The system detects the tamper sensor signal status of the target terminal device. When the signal status indicates that the device casing has been illegally opened, it triggers an emergency erase sequence to destroy the pre-installed random mask and asymmetric private key in the target terminal device.

[0274] It should be noted that the quantum key offline pre-setting device and the quantum key local activation device can implement the various processes implemented in the above embodiments of the quantum key offline pre-setting method and the quantum key local activation method, and can achieve the same beneficial effects. To avoid repetition, they will not be described again here.

[0275] In the case where the functions of the integrated modules described above are implemented in hardware, this application provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 12As shown, the electronic device 1200 includes: a processor 1202, a communication interface 1203, and a bus 1204. Optionally, the electronic device 1200 may also include a memory 1201.

[0276] Processor 1202 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 1202 may be a central processing unit, a general-purpose processor, a digital signal processor, 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 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 1202 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0277] The communication interface 1203 is used to connect with other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0278] The memory 1201 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0279] As one possible implementation, the memory 1201 can exist independently of the processor 1202. The memory 1201 can be connected to the processor 1202 via a bus 1204 and is used to store instructions or program code. When the processor 1202 calls and executes the instructions or program code stored in the memory 1201, it can implement the quantum key offline preset and local activation method provided in the embodiments of this application.

[0280] In another possible implementation, the memory 1201 can also be integrated with the processor 1202.

[0281] Bus 1204 can be an Extended Industry Standard Architecture (EISA) bus, etc. Bus 1204 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 12 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0282] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the quantum key offline preset device or the quantum key local activation device can be divided into different functional modules to complete all or part of the functions described above.

[0283] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above-described quantum key offline preset and local activation method embodiments, and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0284] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0285] This application also provides a readable storage medium storing a program or instructions. When executed by a computer, the program or instructions implement the quantum key offline presetting and local activation method provided in the above embodiments. It is understood that all or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware. The readable storage medium can be any of the foregoing embodiments or memory. The readable storage medium can also be an external storage device for the quantum key offline presetting device or quantum key local activation device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the quantum key offline presetting device or quantum key local activation device. Further, the readable storage medium can include both internal storage units of the quantum key offline presetting device or quantum key local activation device and external storage devices. The readable storage medium is used to store the computer program and other programs and data required by the quantum key offline presetting device or quantum key local activation device. The readable storage medium can also be used to temporarily store data that has been output or will be output.

[0286] This application also provides a computer program product, which is stored in a storage medium and, when executed by a computer, implements the quantum key offline preset and local activation method provided in the above embodiments.

[0287] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0288] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0289] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for offline quantum key pre-setting, characterized in that, Applied to pre-built workstations, including: Generating original quantum key materials based on quantum random number sources; A Merkle tree is constructed based on the original quantum key material to generate the first hash value; A random mask of the same length as the original quantum key material is generated, and the original quantum key material and the random mask are XORed bit by bit to generate whitened key material. Based on the inherent physical characteristics of the hardware obtained from the target terminal device, a first device root key is generated, and a first packaging key and a first message authentication key are derived based on the first device root key. The first packaging key and the first message authentication key are encrypted using the asymmetric public key in the asymmetric key pair to generate an authentication tag. The asymmetric key pair is generated on the target terminal device. The whitening key material and the first hash value are encrypted based on the first packaging key to generate an injection container containing the encryption result and the authentication tag, and the injection container and the random mask are written into the target terminal device.

2. The method according to claim 1, characterized in that, The injection container includes: The encryption key material field is used to store the whitened key material encrypted with the first packaging key; The authentication label field is used to store the authentication label; The root hash value field is used to store the first root hash value of the Merkle tree after it has been encrypted with the first packaging key.

3. The method according to claim 1, characterized in that, The step of generating a first device root key based on the inherent physical characteristics of the hardware obtained from the target terminal device includes: An excitation signal is applied to the Physically Unclonable Function (PUF) module of the target terminal device to obtain the original physical response of the PUF module caused by semiconductor manufacturing process deviations. The original physical response is subjected to error correction and extraction processing to generate the first device root key.

4. A quantum key local activation method, characterized in that, Applied to target terminal devices, including: In the offline state, a second device root key is generated based on the inherent physical characteristics of the target terminal device, and a second packaging key and a second message authentication key are derived based on the second device root key; Using the second packaging key and the asymmetric private key in the preset asymmetric key pair, the injection container preset in the target terminal device is double-verified and decrypted to obtain the original quantum key material and the first hash value. The injection container includes the encryption result obtained by encrypting the whitened key material and the first hash value with the first packaging key, and the authentication tag generated by encrypting the first packaging key and the first message authentication key with the asymmetric public key. Based on the original quantum key material obtained from decryption, the Merkle tree is reconstructed, and the newly generated second hash value is compared with the first hash value obtained from decryption. If the comparison passes, an activation key is derived based on the original quantum key material, and a business session key pool is generated using the activation key to complete the local activation of the quantum key. The original quantum key material, the activation key, and the injection container are then securely erased.

5. The method according to claim 4, characterized in that, The process of using the second packaging key and the asymmetric private key from the pre-set asymmetric key pair to perform double verification and decryption on the injection container pre-installed in the target terminal device to obtain the original quantum key material and the first hash value includes: The encryption result in the injection container is decrypted using the second packaging key to obtain the whitened key material and the first hash value; The authentication tag in the injection container is decrypted using the asymmetric private key to obtain the first packaging key and the first message authentication key; The first packaging key and the first message authentication key obtained by decryption are compared with the second packaging key and the second message authentication key derived from the second device root key; If the comparison passes, the original quantum key material is recovered by performing a bit-by-bit XOR operation on the whitened key material using a preset random mask.

6. The method according to claim 4, characterized in that, The Merkle tree is reconstructed based on the original quantum key material obtained from decryption, and the newly generated second hash value is compared with the first hash value obtained from decryption, including: The original quantum key material is divided into multiple pieces, and the hash value of each piece is calculated to obtain the reconstructed leaf nodes; The reconstructed leaf nodes are recursively concatenated pairwise and their hash values ​​are calculated until the second root hash value is obtained, which is then compared with the first root hash value.

7. The method according to claim 4, characterized in that, The process of deriving an activation key based on the original quantum key material and generating a business session key pool using the activation key includes: Using the original quantum key material as the input key material and the activation seed derived from the second device root key as the salt value, the activation key is generated through a key derivation function; Based on the activation key and the current count value of the hardware monotonic counter, multiple service session keys are generated sequentially using a pseudo-random function and filled into the service session key pool.

8. The method according to claim 7, characterized in that, After generating the business session key pool, the following is also included: Each time a service session key is allocated from the service session key pool, the hardware monotonic counter is controlled to perform an atomic increment operation; If the count value of the hardware monotonic counter is greater than or equal to the warning threshold and less than the capacity limit of the service session key pool, a key exhaustion warning is triggered to indicate that the target terminal device needs to re-inject the original quantum key material. If the count value of the hardware monotonic counter is greater than or equal to the capacity limit, a self-locking protection is triggered to prevent further allocation of service session keys from the service session key pool and to clear the service session key pool.

9. The method according to claim 4, characterized in that, Before generating the second device root key based on the inherent physical characteristics of the target terminal device, the method further includes: The tamper sensor signal status of the target terminal device is detected. When the signal status indicates that the device casing has been illegally opened, an emergency erase sequence is triggered to destroy the random mask and the asymmetric private key pre-installed in the target terminal device.

10. A quantum key offline pre-setting and local activation system, characterized in that, Includes pre-installed workstations and target terminal devices; The preset workstation is used to execute the quantum key offline preset method as described in any one of claims 1-3; The target terminal device is used to execute the quantum key local activation method as described in any one of claims 4-9.

11. A quantum key offline pre-setting device, characterized in that, include: The generation module is used to generate raw quantum key materials based on a quantum random number source; The generation module is also used to construct a Merkle tree based on the original quantum key material to generate the first hash value; The computation module is used to generate a random mask of the same length as the original quantum key material, and to perform a bit-by-bit XOR operation between the original quantum key material and the random mask to generate whitened key material. The acquisition module is used to generate a first device root key based on the inherent physical characteristics of the hardware obtained from the target terminal device, and derive a first packaging key and a first message authentication key based on the first device root key; An encryption module is used to encrypt the first packaging key and the first message authentication key using the asymmetric public key in the asymmetric key pair to generate an authentication tag, wherein the asymmetric key pair is generated on the target terminal device; The writing module is used to encrypt the whitening key material and the first root hash value based on the first packaging key, generate an injection container containing the encryption result and the authentication tag, and write the injection container and the random mask into the target terminal device.

12. A quantum key local activation device, characterized in that, include: The generation module is used to generate a second device root key based on the inherent physical characteristics of the target terminal device in the offline state, and derive a second packaging key and a second message authentication key based on the second device root key; The verification and decryption module is used to perform dual verification and decryption on the injection container pre-installed in the target terminal device using the second packaging key and the asymmetric private key in the pre-installed asymmetric key pair to obtain the original quantum key material and the first hash value. The injection container includes an encryption result obtained by encrypting the whitened key material and the first hash value using the first packaging key, and an authentication tag generated by encrypting the first packaging key and the first message authentication key using the asymmetric public key. The construction module is used to reconstruct the Merkle tree based on the original quantum key material obtained from decryption, and compare the regenerated second hash value with the first hash value obtained from decryption; The generation module is further configured to, upon successful comparison, derive an activation key based on the original quantum key material, generate a business session key pool using the activation key, thereby completing the local activation of the quantum key, and securely erase the original quantum key material, the activation key, and the injection container.

13. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a program or instructions that can run on the processor, the program or instructions being executed by the processor to implement the quantum key offline presetting method as described in any one of claims 1-3 or the quantum key local activation method as described in any one of claims 4-9.

14. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions, which, when executed by a computer, implement the quantum key offline presetting method as described in any one of claims 1-3 or the quantum key local activation method as described in any one of claims 4-9.

15. A computer program product, characterized in that, The computer program product is stored in a storage medium, and when executed by a computer, it implements the quantum key offline pre-setting method as described in any one of claims 1-3 or the quantum key local activation method as described in any one of claims 4-9.

Images