Identity authentication method and authentication platform for dynamic quantum key

Abstract

This application relates to an authentication method, authentication platform, and IoT device for dynamic quantum keys. It is applicable to authentication platforms and IoT devices, and includes: constructing a Redis-based caching model; receiving authentication requests initiated by IoT devices; querying the corresponding dynamic session key of the IoT device from the caching model based on the authentication request; if the query is successful, sending a first random number to the IoT device based on the dynamic session key; receiving a response value generated from the first random number from the IoT device; and determining that authentication is successful when the response value matches the pre-stored response value. This method reduces the request volume of the quantum key distribution network by only initiating requests to the backend quantum key distribution network in a few necessary situations, such as cache misses, natural expiration, or security threats. This allows a large number of key requests to be directly retrieved and returned from Redis memory.

Description

Technical Field

[0001] This application relates to the field of encrypted communication, and in particular to authentication methods, authentication platforms and Internet of Things devices for dynamic quantum keys. Background Technology

[0002] The contradiction between quantum resources and high concurrency: Existing QKD (quantum key distribution) applications often rely on real-time interaction. When faced with tens of millions of IoT devices, the quantum key distribution network (QKMS) cannot support such a high frequency of raw key requests, leading to system crashes. Summary of the Invention

[0003] This application provides an authentication method, authentication platform, and IoT device for dynamic quantum keys, to at least solve the problem that quantum key distribution networks (QKMS) in related technologies cannot support such a high frequency of raw key requests.

[0004] In a first aspect, embodiments of this application provide an authentication method for dynamic quantum keys, applicable to authentication platforms, including: Build a Redis-based caching model; Receive an authentication request initiated by an IoT device, and query the dynamic session key corresponding to the IoT device from the cache model based on the authentication request; If the query is successful, a first random number is sent to the IoT device based on the dynamic session key, and a response value generated based on the first random number is received from the IoT device. When the response value matches the pre-stored response value, the identity authentication is deemed successful.

[0005] In one embodiment, prior to receiving the authentication request initiated by the IoT device, the procedure includes: A random number generated by a quantum key distribution network is injected into the authentication platform, and the random number is used as the quantum root key.

[0006] In one embodiment, constructing a Redis-based caching model includes: In the Redis cache space, a data structure representing the lifecycle state of each dynamic session key, including an identifier, key body, and metadata, is constructed to form a finite state machine model. The lifecycle states include at least: The active state indicates that the dynamic session key is within its validity period and is used for data encryption or identity authentication; The expired state indicates that the natural lifespan of the dynamic session key has expired, but the dynamic session key and its metadata are still retained in the Redis cache space for a grace period. The "failed" state indicates that, based on external threat intelligence input, the dynamic session key is determined to have a potential risk of leakage, and its state is forcibly marked as "failed," indicating a miss.

[0007] In one embodiment, querying the dynamic session key corresponding to the IoT device from the cache model based on the authentication request includes: Extract the device identifier of the IoT device from the authentication request, and query the dynamic session key corresponding to the device identifier from the cache model.

[0008] In one embodiment, it further includes: If the query fails, a key generation request is initiated to the quantum key distribution network to obtain the first quantum root key regenerated by the quantum key distribution network; A dynamic session key is obtained by performing a double hash derivation algorithm based on the first quantum root key; The dynamic session key is stored in the cache model.

[0009] In one embodiment, the step of performing a double hash derivation algorithm based on the first quantum root key to obtain a dynamic session key includes: The original random number is hashed with the timestamp in the authentication request to obtain an intermediate digest value. The intermediate digest value is hashed a second time with the first quantum root key to obtain the derived seed; The derived seed is hashed a third time with the device identifier in the authentication request to obtain the dynamic session key.

[0010] Secondly, embodiments of this application provide an authentication method for dynamic quantum keys, applicable to Internet of Things (IoT) devices, including: Obtain the original random number generated by the quantum key distribution network, and store the original random number as the quantum root key; Send an authentication request containing a timestamp and device identifier to the authentication platform, and receive a first random number returned by the authentication platform based on the authentication request; A response value is generated based on the first random number and the quantum root key, and the response value is sent to the authentication platform; Receive the authentication result from the authentication platform.

[0011] In one embodiment, after receiving the authentication result from the authentication platform, the method further includes: Hash message authentication code calculation is performed on the interaction messages between the dynamic session key and the authentication platform.

[0012] Thirdly, embodiments of this application provide an authentication platform for dynamic quantum keys, including: The setup end is used to build a Redis-based caching model; The first receiving end is used to receive an authentication request initiated by an IoT device, and query the dynamic session key corresponding to the IoT device from the cache model based on the authentication request. The first sending end is configured to, if the query is successful, send a first random number to the IoT device based on the dynamic session key, and receive a response value generated based on the first random number from the IoT device; The authentication terminal determines that identity authentication is successful when the response value matches the pre-stored response value.

[0013] Fourthly, embodiments of this application provide an Internet of Things (IoT) device for dynamic quantum key distribution, comprising: The second receiving end is used to obtain the original random number generated by the quantum key distribution network and store the original random number as the quantum root key. The second sending end is used to send an authentication request containing a timestamp and a device identifier to the authentication platform, and to receive a first random number returned by the authentication platform based on the authentication request; The second sending end is further configured to generate a response value based on the first random number and the quantum root key, and send the response value to the authentication platform; The second receiving end is also used to receive the authentication result of the authentication platform.

[0014] The identity authentication method for dynamic quantum keys provided in this application has at least the following technical effects.

[0015] By only sending requests to the backend QKMS in rare, necessary situations such as cache misses, natural expiration, or security threats, a large number of key requests are directly retrieved and returned from Redis memory, thus significantly reducing the number of QKMS requests.

[0016] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating an identity authentication method for dynamic quantum keys, provided by relevant technologies. Figure 2This is a schematic diagram of the execution flow of the double hash derivation algorithm according to an embodiment of this application; Figure 3 This is a structural diagram of the authentication platform provided based on relevant technologies; Figure 4 It is a structural block diagram of IoT devices provided based on relevant technologies; Figure 5 It is a structural diagram of an electronic device provided based on relevant technologies. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0019] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

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

[0021] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0022] Firstly, this application proposes an authentication method for dynamic quantum keys, mainly involving two entities: an IoT device and an authentication platform. Authentication is performed using a quantum root key during data interaction between the two entities. Figure 1 As shown, the specific steps are as follows: Before authentication, both the IoT device and the authentication platform are pre-injected with random numbers generated by a quantum key distribution (QKD) network through a secure channel. These random numbers serve as the quantum root keys (QRKs) for the IoT device and the authentication platform, respectively. Each QRK corresponds one-to-one with an IoT device and is the foundation for subsequent authentication. Furthermore, apart from the pre-allocation method, the QRKs are only used internally by the IoT device and the authentication platform and do not appear in network transmission.

[0023] Step S10: (IoT device) obtains the original random number generated by the quantum key distribution network and stores the original random number as the quantum root key.

[0024] Specifically, the QRK is stored in the QRK storage area within the SE security chip of the IoT device, which can be easily retrieved in subsequent steps.

[0025] Step S20: The (IoT device) sends an authentication request containing a timestamp and device identifier to the authentication platform.

[0026] Step S30: The authentication platform receives an identity authentication request initiated by an IoT device and queries the dynamic session key of the corresponding IoT device from the cache model based on the identity authentication request.

[0027] Specifically, based on the authentication request, the dynamic session key of the corresponding IoT device is queried from the cache model, including: Extract the device identifier of the IoT device from the authentication request, and query the dynamic session key corresponding to the device identifier from the cache model.

[0028] In practice, the authentication platform stores a large number of Dynamic Session Keys (DSKs). When responding to authentication requests initiated by IoT devices, it is necessary to use the device ID to query the DSK corresponding to each IoT device.

[0029] Step S40: If the query is successful, the authentication platform sends a first random number to the IoT device based on the dynamic session key and receives a response value generated from the IoT device based on the first random number.

[0030] If the DSK corresponding to the IoT device that sent the identity request is found based on the Device ID, it indicates that the IoT device and the authentication platform have been pre-bound. Next, the authentication platform sends a first random number to the IoT device. This first random number represents the current authentication time and limits the timeliness of the authentication behavior.

[0031] The original approach required the quantum key distribution (QKD) network to respond to the DSK verification request. After the adjustment, the platform will only send a request to the QKMS (quantum key distribution network) to pull the QRK (quantum root key) and re-execute the derivation algorithm to update the Redis cache space when the Redis cache space is not hit, expires, or the system detects a potential security threat (suspected replay attack, key leakage risk, abnormal behavior of the business layer, abnormal instructions issued by the upper-layer security audit system).

[0032] It is important to note that if the query fails, it indicates that there are no valid DSKs in the current Redis cache. In this case, the authentication platform will perform the following: 1) Initiate a key generation request to the quantum key distribution (QKD) network to obtain the first quantum root key regenerated by the quantum key distribution (QKD) network.

[0033] 2) Execute the double hash derivation algorithm based on the first quantum root key to obtain the dynamic session key.

[0034] Here, the double hash derivation algorithm refers to performing three hash operations in sequence.

[0035] The execution flow of the double hash derivation algorithm is as follows: Figure 2 As shown, it specifically includes: Step S41: Perform the first hash operation on the original random number and the timestamp in the identity authentication request to obtain the intermediate digest value.

[0036] Step S42: Perform a second hash operation on the intermediate digest value and the first quantum root key to obtain the derived seed.

[0037] Step S43: Perform a third hash operation on the derived seed and the device identifier in the authentication request to obtain the dynamic session key.

[0038] The input factors for the double hash derivation algorithm include the original random number (Nonce D), the timestamp, and the first quantum root key.

[0039] First, the original random number (Nonce D), timestamp, and counter are selected to perform the first hash operation based on the SM3 algorithm to obtain the intermediate digest value R1. The algorithm expression is as follows: R1 = SM3(Timestamp || Nonce_D || Counter); In the formula, the added Counter factor is a session auto-incrementing counter synchronized between the platform and the device. Even if the timestamp of the IoT device is maliciously tampered with or fixed, the auto-incrementing factor forces a unidirectional step each time authentication or cache invalidation occurs. Utilizing the avalanche effect of the hash algorithm, even if only 1 bit of the auto-incrementing factor changes, the generated intermediate digest R1 will be completely randomized. This achieves a dual dynamic binding of "time dimension + state dimension," fundamentally eliminating replay attacks in high-concurrency scenarios.

[0040] The Counter factor is lightweight and directly encapsulated in Redis. Redis only needs to perform an atomic operation to increment the Counter of the device (HINCRBY) to generate a completely new cryptographic context, thus achieving a lightweight, high-performance caching architecture that gracefully schedules high-strength cryptographic algorithms.

[0041] Next, the intermediate digest value R1 is hashed with the first quantum root key (QRK) using the SM3 algorithm to obtain the derived seed Seed. The algorithm expression is as follows: Seed = SM3(R1 || QRK); The first two steps construct a dual hash obfuscation architecture. The first step involves fusing all externally disclosed dynamic variables (timestamps, random numbers, incrementing factors) into a high-entropy intermediate digest R1. The second step then fuses R1 with the quantum root key (QRK) located within a secure region. Through this cryptographic isolation, the core quantum credential (QRK) will never be directly linearly associated with any known plaintext, significantly extending the secure lifespan of the QRK at IoT endpoints.

[0042] Finally, the derived seed (Seed) and the device ID are subjected to a third hash operation (Keyed-Hashing for Message Authentication, HMAC) based on the SM3 algorithm to obtain the dynamic session key. The algorithm expression is as follows: DSK = HMAC_SM3(Seed, Device_ID).

[0043] In this step, the device's unique physical identifier, Device_ID, is used as the context message. This ensures that the Dynamic Session Keys (DSKs) generated between different devices also have forward security. Even if a single device is compromised, an attacker will never be able to deduce the DSKs of other nodes across devices.

[0044] 3) Store the dynamic session key in the cache model.

[0045] The newly generated first quantum root key is sent to the Redis cache space for storage, and a Time To Live (TTL) flag is added to limit the validity period of the first quantum root key.

[0046] Step S50: The (IoT device) receives the first random number returned by the authentication platform based on the authentication request.

[0047] In this process, after the authentication platform confirms that the IoT device that initiated the authentication request is valid, the IoT device receives a first random number (Nonce P) representing the time of the current authentication, which allows the IoT device to generate a response value based on the first random number (Nonce P).

[0048] Step S60: The (IoT device) generates a response value based on the first random number and the quantum root key, and sends the response value to the authentication platform.

[0049] In this process, the IoT device performs a hash operation based on the SM3 algorithm locally using a first random number (Nonce P) representing the latest timeliness, obtains a response value Res, and sends the response value Res to the authentication platform for identity verification.

[0050] Step S70: When the response value matches the pre-stored response value, the authentication platform determines that the identity authentication is successful.

[0051] This step involves comparing the response values ​​numerically; if the values ​​match, the identity authentication is considered successful.

[0052] Step S80: The (IoT device) receives the authentication result from the authentication platform.

[0053] Upon receiving the authentication result, it indicates that the identity of the IoT device has been verified, and the IoT device can communicate with the authentication platform.

[0054] In implementation, after receiving the authentication result from the authentication platform, the following is also included: Hash message authentication code calculation is performed based on the interaction messages between the dynamic session key pair and the authentication platform.

[0055] Furthermore, step S40 discloses a quantum key derivation management mechanism based on Redis state machine and on-demand refresh strategy, which aims to solve the technical problems of high request pressure and insufficient key management security in quantum key distribution network (QKMS) under high concurrency environment.

[0056] The solution comprises three core components: state machine cache model construction, lazy loading and on-demand refresh mechanism, and security threat-linked refresh mechanism.

[0057] 1) Construction of a DSK state machine caching model based on Redis This solution abandons the simple "existence / non-existence" binary state in traditional caching. Instead, it constructs a data structure within the Redis cache space for each Dynamic Session Key (DSK), containing a lifecycle state identifier, the key itself, and metadata, forming a finite state machine model. The lifecycle states of the DSK include at least: Activated: Indicates that the DSK is within its validity period and can be directly used for data encryption or identity authentication.

[0058] EXPIRED: This indicates that the natural time-to-live (TTL) of the DSK has been exhausted, but the key itself and its metadata are still kept in the Redis cache for a grace period and are not immediately physically deleted.

[0059] Invalid state (INVALID): This indicates that the system actively determines that DSK has a potential risk of leakage based on external threat intelligence input, and its state is forcibly marked as invalid, which is equivalent to a cache miss.

[0060] This state machine is built on top of Redis hash data structures. Each DSK key contains multiple fields: key_data (key body), state (state identifier), created_at (creation timestamp), and ttl (time to live). The state transition is driven by Redis keyspace notifications and scheduled inspection tasks within the application.

[0061] 2) On-demand refresh mechanism based on "lazy loading" strategy This solution transforms the acquisition of DSK from active, periodic network requests to a "lazy loading" model passively driven by business needs. The specific process is as follows: Cache hit and active state: When an authentication request arrives, the system first queries the Redis cache. If the target DSK exists and is active, it is read directly from memory at high speed and returned, completely avoiding calls to QKMS. This is the "memory-efficient read" path.

[0062] On-demand refresh for cache misses, expired or invalidated data: Triggering Condition 1 (Natural Expiration): When a query finds that the DSK state is expired, the system will not immediately delete the key, but will instead initiate an atomic asynchronous refresh task. This task holds a distributed lock and sends a request to QKMS to pull a brand new quantum root key (QRK).

[0063] Triggering condition two (explicit failure): When the query finds that the DSK status is invalid (INVALID), it indicates that the key may have been compromised. The system immediately blocks the current session and forces the synchronous refresh task to start.

[0064] Triggering condition 3 (cache penetration): When a query finds that the target DSK does not exist in the cache at all, the system also starts a refresh task.

[0065] Derivation and Update: After obtaining the QRK, the refresh task calls the Key Derivation Function (KDF) in the local hardware security module (HSM), combines the session identifier and other context parameters, derives a new DSK, and writes it to the Redis cache in an active state, completing a full on-demand refresh closed loop.

[0066] 3) Proactive failure and refresh mechanism based on external threat intelligence This solution innovatively integrates a network security threat detection system with a key caching management system. The system receives threat intelligence from external systems such as Intrusion Detection Systems (IDS) and Security Information and Event Management (SIEM) platforms through a single interface. When threat intelligence indicates abnormal behavior (such as brute-force attacks, replay attacks, or access from unusual geographic locations) by a specific session ID, user, or IP address, this solution performs the following operations: Precise state switching: Without waiting for the entire cache cycle to expire, the corresponding DSK key in Redis is located directly based on the session ID, and the state field is atomically changed from ACTIVE to INVALID through a Redis transaction (MULTI / EXEC).

[0067] Cascading failure (optional): Depending on the security policy, this can be expanded to batch mark all non-expired DSKs associated with risky users as failed.

[0068] Subsequent processing: When the next request from the same session arrives, the "explicit failure" trigger condition in the "on-demand refresh" mechanism will be automatically triggered, thereby forcing the suspicious session to renegotiate and derive the quantum root key without interrupting the overall service, achieving seamless key replacement and security hardening.

[0069] Furthermore, if a large number of concurrent authentication requests flood in when the DSK in Redis is expired, the system will not allow all requests to simultaneously penetrate to the backend quantum key distribution network (QKMS). The authentication platform uses Redis's atomic operations to issue a temporary distributed lock for the device. The single thread that acquires the lock acts as the "refresher," asynchronously pulling the first quantum root key from the backend QKMS and performing derivation; the remaining concurrent threads do not need to be blocked or report errors, and the system allows them to continue using the expired DSK for timed authentication within a specified "grace period." Additionally, inconsistencies in the increment factor Counter also trigger DSK expiration.

[0070] Based on the above description, the technical solution provided in this embodiment has the following effects: 1. This invention reduces resource consumption in quantum key distribution networks by over 90%, overcoming performance bottlenecks. Existing solutions typically employ an "active pull" model, where clients or gateways periodically request new keys from QKMS, regardless of whether the keys are actually used. This results in significant bandwidth and processing overhead for QKMS in high-concurrency scenarios. This invention addresses this by constructing a "lazy loading" and "on-demand refresh" mechanism, shifting the driving force for key acquisition from a "fixed period" to "business needs." Requests are only sent to the backend QKMS in a few necessary situations, such as cache misses, natural expiration, or security threats. Statistical analysis shows that under normal business traffic, over 90% of key requests are directly retrieved and returned from Redis memory, thereby reducing QKMS request volume by over 90% and freeing the system's overall throughput from the performance limitations of QKMS.

[0071] 2. Achieving fine-grained management and transient protection of key lifecycle through a state machine caching model. Traditional caching strategies physically delete keys immediately upon expiration. If a surge of legitimate requests occurs at this time, it can cause a sudden influx of requests to penetrate the backend QKMS (i.e., "cache breakdown" or "avalanche"), resulting in service instability. This invention's unique "state machine caching" model introduces an expired state with a grace period. This state allows the system to trigger an asynchronous refresh with the first request upon detecting key expiration, while subsequent concurrent requests temporarily wait or are degraded during this grace period. This effectively avoids a large influx of requests into QKMS simultaneously, smooths out key transition spikes, and greatly improves the system's stability and availability during the key transition window.

[0072] 3. Upgrading passive security defense to proactive, immune-based dynamic key control. Existing key management systems often respond to security incidents as they occur (e.g., manually revoking certificates after an intrusion is detected), resulting in a response delay window. This invention achieves a millisecond-level automatic closed loop from "threat detected" to "key invalidation" by deeply integrating an external threat intelligence interface with the Redis cache state control plane. When the system detects a potential attack, it no longer requires lengthy administrator approvals and manual operations; instead, it programmatically marks the cache state of a specific DSK as invalid, forcibly triggering key re-derivation and negotiation. This mechanism transforms "static encryption protection" into a "dynamic, self-healing immune system," ensuring that even if an attacker steals a key at a certain moment, it cannot be used within a very short time due to key invalidation, creatively elevating the proactive security defense capabilities of quantum keys to a new level.

[0073] 4. Optimize key space and memory utilization efficiency. By encapsulating key status, metadata, and key body within a unified Redis hash structure and managing it using a state machine, this solution avoids the complexity and memory overhead of maintaining multiple independent key-value pairs for storing expiration information. Expired and invalid keys are retained in memory, serving both as a means of decrypting historical data and as a basis for audit tracing. Simultaneously, scheduled inspection tasks can batch-clean up truly useless key data, achieving optimal utilization of memory resources while ensuring functionality.

[0074] Secondly, embodiments of this application provide an authentication platform and an Internet of Things (IoT) device for dynamic quantum keys, such as... Figure 3 As shown, the authentication platform 300 includes: Set up terminal 310, which is used to build a Redis-based caching model.

[0075] The first receiving end 320 is used to receive an authentication request initiated by an IoT device and query the dynamic session key of the corresponding IoT device from the cache model based on the authentication request.

[0076] Specifically, based on the authentication request, the dynamic session key of the corresponding IoT device is queried from the cache model, including: Extract the device identifier of the IoT device from the authentication request, and query the dynamic session key corresponding to the device identifier from the cache model.

[0077] In practice, the authentication platform stores a large number of Dynamic Session Keys (DSKs). When responding to authentication requests initiated by IoT devices, it is necessary to use the device ID to query the DSK corresponding to each IoT device.

[0078] The first sending end 330 is used to send a first random number to the IoT device based on the dynamic session key if the query is successful, and to receive a response value generated based on the first random number from the IoT device.

[0079] If the DSK corresponding to the IoT device that sent the identity request is found based on the Device ID, it indicates that the IoT device and the authentication platform have been pre-bound. Next, the authentication platform sends a first random number to the IoT device. This first random number represents the current authentication time and limits the timeliness of the authentication behavior.

[0080] The original approach required the quantum key distribution (QKD) network to respond to the DSK verification request. After the adjustment, the platform will only send a request to the QKMS (quantum key distribution network) to pull the QRK (quantum root key) and re-execute the derivation algorithm to update the Redis cache space when the Redis cache space is not hit, expires, or the system detects a potential security threat (suspected replay attack, key leakage risk, abnormal behavior of the business layer, abnormal instructions issued by the upper-layer security audit system).

[0081] The authentication terminal 340 is used to determine that the identity authentication is successful when the response value matches the pre-stored response value.

[0082] This step involves comparing the response values ​​numerically; if the values ​​match, the identity authentication is considered successful.

[0083] like Figure 4 As shown, the Internet of Things (IoT) device 400 includes: The second receiver 410 is used to obtain the original random number generated by the quantum key distribution network and store the original random number as the quantum root key.

[0084] Specifically, the QRK is stored in the QRK storage area within the SE security chip of the IoT device, which can be easily retrieved in subsequent steps.

[0085] The second sending end 420 is used to send an authentication request containing a timestamp and device identifier to the authentication platform, and to receive a first random number returned by the authentication platform based on the authentication request.

[0086] In this process, after the authentication platform confirms that the IoT device that initiated the authentication request is valid, the IoT device receives a first random number (Nonce P) representing the time of the current authentication, which allows the IoT device to generate a response value based on the first random number (Nonce P).

[0087] The second transmitter 420 is also used to generate a response value based on the first random number and the quantum root key, and send the response value to the authentication platform.

[0088] In this process, the IoT device performs a hash operation based on the SM3 algorithm locally using a first random number (Nonce P) representing the latest timeliness, obtains a response value Res, and sends the response value Res to the authentication platform for identity verification.

[0089] The second receiving end 410 is also used to receive the authentication results from the authentication platform.

[0090] Upon receiving the authentication result, it indicates that the identity of the IoT device has been verified, and the IoT device can communicate with the authentication platform.

[0091] In implementation, after receiving the authentication result from the authentication platform, the following is also included: Hash message authentication code calculation is performed based on the interaction messages between the dynamic session key pair and the authentication platform.

[0092] In summary, the authentication platform and IoT device for dynamic quantum keys provided in this application embodiment... The technical solution provided in this embodiment has the following effects: 1. This invention reduces resource consumption in quantum key distribution networks by over 90%, overcoming performance bottlenecks. Existing solutions typically employ an "active pull" model, where clients or gateways periodically request new keys from QKMS, regardless of whether the keys are actually used. This results in significant bandwidth and processing overhead for QKMS in high-concurrency scenarios. This invention addresses this by constructing a "lazy loading" and "on-demand refresh" mechanism, shifting the driving force for key acquisition from a "fixed period" to "business needs." Requests are only sent to the backend QKMS in a few necessary situations, such as cache misses, natural expiration, or security threats. Statistical analysis shows that under normal business traffic, over 90% of key requests are directly retrieved and returned from Redis memory, thereby reducing QKMS request volume by over 90% and freeing the system's overall throughput from the performance limitations of QKMS.

[0093] 2. Achieving fine-grained management and transient protection of key lifecycle through a state machine caching model. Traditional caching strategies physically delete keys immediately upon expiration. If a surge of legitimate requests occurs at this time, it can cause a sudden influx of requests to penetrate the backend QKMS (i.e., "cache breakdown" or "avalanche"), resulting in service instability. This invention's unique "state machine caching" model introduces an expired state with a grace period. This state allows the system to trigger an asynchronous refresh with the first request upon detecting key expiration, while subsequent concurrent requests temporarily wait or are degraded during this grace period. This effectively avoids a large influx of requests into QKMS simultaneously, smooths out key transition spikes, and greatly improves the system's stability and availability during the key transition window.

[0094] 3. Upgrading passive security defense to proactive, immune-based dynamic key control. Existing key management systems often respond to security incidents as they occur (e.g., manually revoking certificates after an intrusion is detected), resulting in a response delay window. This invention achieves a millisecond-level automatic closed loop from "threat detected" to "key invalidation" by deeply integrating an external threat intelligence interface with the Redis cache state control plane. When the system detects a potential attack, it no longer requires lengthy administrator approvals and manual operations; instead, it programmatically marks the cache state of a specific DSK as invalid, forcibly triggering key re-derivation and negotiation. This mechanism transforms "static encryption protection" into a "dynamic, self-healing immune system," ensuring that even if an attacker steals a key at a certain moment, it cannot be used within a very short time due to key invalidation, creatively elevating the proactive security defense capabilities of quantum keys to a new level.

[0095] 4. Optimize key space and memory utilization efficiency. By encapsulating key status, metadata, and key body within a unified Redis hash structure and managing it using a state machine, this solution avoids the complexity and memory overhead of maintaining multiple independent key-value pairs for storing expiration information. Expired and invalid keys are retained in memory, serving both as a means of decrypting historical data and as a basis for audit tracing. Simultaneously, scheduled inspection tasks can batch-clean up truly useless key data, achieving optimal utilization of memory resources while ensuring functionality.

[0096] Thirdly, embodiments of this application provide an electronic device, Figure 5 This is a block diagram illustrating an electronic device according to an exemplary embodiment. (e.g.) Figure 5 As shown, the electronic device may include a processor 51 and a memory 52 storing computer program instructions.

[0097] Specifically, the processor 51 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0098] The memory 52 may include a large-capacity memory for data or instructions. For example, and not limitingly, the memory 52 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 52 may include removable or non-removable (or fixed) media. Where appropriate, the memory 52 may be internal or external to a data processing device. In a particular embodiment, the memory 52 is non-volatile memory. In a particular embodiment, the memory 52 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random-Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random-Access Memory (FPMDRAM), Extended Data Out Dynamic Random-Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0099] The memory 52 can be used to store or cache various data files that need to be processed and / or used for communication, as well as possible computer program instructions executed by the processor 51.

[0100] The processor 51 implements any of the authentication methods for dynamic quantum keys in the above embodiments by reading and executing computer program instructions stored in the memory 52.

[0101] In one embodiment, the electronic device may further include a communication interface 53 and a bus 50. Wherein, as... Figure 5 As shown, the processor 51, memory 52, and communication interface 53 are connected through bus 50 and complete communication with each other.

[0102] The communication interface 53 is used to enable communication between the various modules, devices, units, and / or equipment in the embodiments of this application. The communication port 53 can also enable data communication with other components such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations.

[0103] Bus 50 includes hardware, software, or both, that couples the components of the electronic device together. Bus 50 includes, but is not limited to, at least one of the following: data bus, address bus, control bus, expansion bus, and local bus. For example, and not as a limitation, bus 50 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 50 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0104] Fourthly, embodiments of this application provide a computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the authentication method for dynamic quantum keys provided in the first aspect.

[0105] The readable storage medium may be more specifically adopted, including but not limited to: portable disk, hard disk, random access memory, read-only memory, erasable programmable read-only memory, optical storage device, magnetic storage device, or any suitable combination thereof.

[0106] In a possible implementation, the present invention can also be implemented as a program product comprising program code that, when the program product is run on a terminal device, causes the terminal device to perform steps implementing the authentication method for dynamic quantum keys provided in the first aspect.

[0107] The program code for executing the present invention can be written in any combination of one or more programming languages. The program code can be executed entirely on the user device, partially on the user device, as a standalone software package, partially on the user device and partially on a remote device, or entirely on a remote device.

[0108] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0109] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. An authentication method for dynamic quantum keys, suitable for authentication platforms, characterized in that, include: Build a Redis-based caching model; Receive an authentication request initiated by an IoT device, and query the dynamic session key corresponding to the IoT device from the cache model based on the authentication request; If the query is successful, a first random number is sent to the IoT device based on the dynamic session key, and a response value generated based on the first random number is received from the IoT device. When the response value matches the pre-stored response value, the identity authentication is deemed successful.

2. The authentication method for dynamic quantum keys according to claim 1, characterized in that, Before receiving the authentication request initiated by the IoT device, the process includes: A random number generated by a quantum key distribution network is injected into the authentication platform, and the random number is used as the quantum root key.

3. The authentication method for dynamic quantum keys according to claim 1, characterized in that, The construction of the Redis-based caching model includes: In the Redis cache space, a data structure representing the lifecycle state of each dynamic session key, including an identifier, key body, and metadata, is constructed to form a finite state machine model. The lifecycle states include at least: The active state indicates that the dynamic session key is within its validity period and is used for data encryption or identity authentication; The expired state indicates that the natural lifespan of the dynamic session key has expired, but the dynamic session key and its metadata are still retained in the Redis cache space for a grace period. The "failed" state indicates that, based on external threat intelligence input, the dynamic session key is determined to have a potential risk of leakage, and its state is forcibly marked as "failed," indicating a miss.

4. The authentication method for dynamic quantum keys according to claim 1, characterized in that, The step of querying the dynamic session key corresponding to the IoT device from the cache model based on the identity authentication request includes: Extract the device identifier of the IoT device from the authentication request, and query the dynamic session key corresponding to the device identifier from the cache model.

5. The authentication method for dynamic quantum keys according to claim 2, characterized in that, Also includes: If the query fails, a key generation request is initiated to the quantum key distribution network to obtain the first quantum root key regenerated by the quantum key distribution network; A dynamic session key is obtained by performing a double hash derivation algorithm based on the first quantum root key; The dynamic session key is stored in the cache model.

6. The authentication method for dynamic quantum keys according to claim 5, characterized in that, The process of obtaining a dynamic session key by performing a double hash derivation algorithm based on the first quantum root key includes: The original random number is hashed with the timestamp in the authentication request to obtain an intermediate digest value. The intermediate digest value is hashed a second time with the first quantum root key to obtain the derived seed; The derived seed is hashed a third time with the device identifier in the authentication request to obtain the dynamic session key.

7. An authentication method for dynamic quantum keys, suitable for Internet of Things (IoT) devices, characterized in that, include: Obtain the original random number generated by the quantum key distribution network, and store the original random number as the quantum root key; Send an authentication request containing a timestamp and device identifier to the authentication platform; Receive the first random number returned by the authentication platform based on the authentication request; A response value is generated based on the first random number and the quantum root key, and the response value is sent to the authentication platform; Receive the authentication result from the authentication platform.

8. The authentication method for dynamic quantum keys according to claim 7, characterized in that, After receiving the authentication result from the authentication platform, the method further includes: Hash message authentication code calculation is performed on the interaction messages between the dynamic session key and the authentication platform.

9. An identity authentication platform for dynamic quantum keys, characterized in that, include: The setup end is used to build a Redis-based caching model; The first receiving end is used to receive an authentication request initiated by an IoT device, and query the dynamic session key corresponding to the IoT device from the cache model based on the authentication request. The first sending end is configured to, if the query is successful, send a first random number to the IoT device based on the dynamic session key, and receive a response value generated based on the first random number from the IoT device; The authentication terminal determines that identity authentication is successful when the response value matches the pre-stored response value.

10. An Internet of Things (IoT) device for dynamic quantum key distribution, characterized in that, include: The second receiving end is used to obtain the original random number generated by the quantum key distribution network and store the original random number as the quantum root key. The second sending end is used to send an authentication request containing a timestamp and a device identifier to the authentication platform, and to receive a first random number returned by the authentication platform based on the authentication request; The second sending end is further configured to generate a response value based on the first random number and the quantum root key, and send the response value to the authentication platform; The second receiving end is also used to receive the authentication result of the authentication platform.

Images