Key updating method and system and electronic equipment

Abstract

The invention relates to the technical field of information security, and discloses a secret key updating method and system and electronic equipment. In the method, an application terminal is connected with a security medium; the application terminal sends a key updating request message to the key management platform, the key updating request message at least comprises a security medium type, a key index and a key library identifier, and the key index is used for indicating a key in a key library corresponding to the key library identifier; receiving encrypted key data issued by the key management platform, determining a target key library from a master key library and a standby key library of the security medium according to the key library identifier, and determining a decryption key from the target key library according to the key index; the application terminal decrypts the encrypted key data based on the decryption key to obtain a set of keys to be updated; and the application terminal writes the to-be-updated key in the set into a standby key library of the security medium. Through the method, the key in the security medium can be safely updated, and the service use of a user is not influenced.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to key update methods, systems and electronic devices. Background Technology

[0002] Quantum key distribution (QKD) networks provide secure symmetric quantum key distribution to connected application nodes for encrypted data transmission between nodes. However, this method requires nodes to be permanently connected to the QKD network, making it suitable for fixed server nodes and difficult to support mobile terminal devices. To overcome this limitation, the industry currently widely builds quantum key management platforms based on QKD networks as the underlying infrastructure. This platform imports the quantum keys distributed by the QKD network into a quantum-secure medium, and mobile terminal devices use the quantum keys stored in the medium to achieve data protection.

[0003] However, the number of quantum keys stored in quantum-safe media is limited and non-reusable, leading to key depletion and the need for updates after long-term use. Currently, there are two main methods used in the industry for updating quantum-safe media:

[0004] Before the distribution of quantum-safe media, quantum keys are obtained from the quantum key management platform via the device and written into the media. Once the media is delivered to the user, the keys are not updated; the media must be replaced when the keys are exhausted. This method, where the keys are not updated after the quantum-safe media is delivered and put into use, increases the possibility of key theft over long-term use. If stolen, it will lead to data leakage and pose a security risk.

[0005] Quantum-secure media are pre-loaded with a portion of quantum keys upon issuance. After delivery to users, if the number of keys in the secure media is insufficient, the terminal application can initiate a request to the quantum key management platform to obtain new keys and write them into the media for updating. This method requires active user intervention and involves a full update of the entire keystore file within the secure media, resulting in a long update time and service unavailability during the update period. Summary of the Invention

[0006] The purpose of this application is to provide a key update method, system, and electronic device that enables secure updates of quantum keys within a secure medium without affecting user services.

[0007] One aspect of this application provides a key update method applied to a key management platform, the key management platform being configured with multiple key libraries; the method includes: acquiring a key update request message sent by an application terminal, wherein the key update request message includes at least a security medium type, a key index, and a key library identifier; determining the number of keys to be generated based on the security medium type, and generating a corresponding number of keys to be updated; determining a target key library from the multiple key libraries based on the key library identifier, and determining an encryption key from the target key library based on the key index; encrypting the set of keys to be updated based on the encryption key to generate encrypted key data; and sending the encrypted key data to the application terminal.

[0008] One aspect of this application also provides a key update method applied to an application terminal, the application terminal being connected to a secure medium, the secure medium being provided with a master key repository and a backup key repository; the method includes: sending a key update request message to a key management platform, wherein the key update request message includes at least a secure medium type, a key index, and a key repository identifier, the key index being used to indicate the key in the key repository corresponding to the key repository identifier; receiving encrypted key data issued by the key management platform; determining a target key repository from the master key repository and backup key repository of the secure medium according to the key repository identifier, and determining a decryption key from the target key repository according to the key index; decrypting the encrypted key data based on the decryption key to obtain a set of keys to be updated; and writing the keys to be updated in the set into the backup key repository of the secure medium.

[0009] In one aspect of this application, a key update system is also provided. The system includes a key management platform and multiple application terminals. The key management platform includes: an update request receiving module, configured to receive a key update request message sent by an application terminal, wherein the key update request message includes at least a security medium type, a key index, and a key repository identifier; an update key generation module, configured to determine the number of keys to be generated based on the security medium type, and generate a corresponding number of keys to be updated; an encryption key determination module, configured to determine a target key repository from multiple key repositories configured on the key management platform based on the key repository identifier, and determine an encryption key from the target key repository based on the key index; encrypt the set of keys to be updated based on the encryption key to generate encrypted key data; and an update response sending module, configured to send the encrypted key data to the application terminals.

[0010] The application terminal includes: an update request sending module, used to send a key update request message to the key management platform, wherein the key update request message includes at least a security medium type, a key index, and a key repository identifier, and the key index is used to indicate the key in the key repository corresponding to the key repository identifier; an update response receiving module, used to receive encrypted key data issued by the key management platform; a decryption key determination module, used to determine a target key repository from the main key repository and backup key repository of the security medium according to the key repository identifier, and determine a decryption key from the target key repository according to the key index; decrypt the encrypted key data based on the decryption key to obtain a set of keys to be updated; and an update key writing module, used to write the keys to be updated in the set into the backup key repository of the security medium.

[0011] In one aspect of this application, an electronic device is also provided, comprising at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the key update method described above.

[0012] The technical solutions provided in this application have at least the following beneficial effects:

[0013] In the technical solution provided in this application embodiment, the application terminal is connected to a secure medium, which contains a master key repository and a backup key repository. Under normal operating conditions, the secure medium uses keys from the master key repository to execute relevant business functions. When a key update requirement is triggered, the application terminal sends a key update request message to the key management platform; this message includes a secure medium type identifier, a target key index, and a master key repository identifier. Responding to the request message, the key management platform uses the matching key index and key repository identifier to determine the quantum key used for encryption and generates a response message containing new key data encrypted with that quantum key. After receiving the response message, the application terminal extracts the corresponding decryption key from the secure medium based on the key index and master key repository identifier. Since the key management platform and the application terminal use the same key index and logic, the application terminal can successfully decrypt the new key data and obtain the target key to be updated. During this process, the key management platform protects the distribution of the new quantum key based on the quantum key shared with the application terminal. This encryption mode enables the transmitted quantum key data to resist quantum computer attacks, effectively solving the security vulnerabilities faced by traditional key distribution methods. Furthermore, the backup keystore configured with secure media provides business continuity assurance during the update process. When an application terminal performs a key update operation on the primary keystore, user services can seamlessly switch to the keys in the backup keystore and continue operating. This mechanism ensures that the key update process is completely transparent to users, and business processes are uninterrupted. Attached Figure Description

[0014] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0015] Figure 1 This is a schematic diagram of the operating environment for a key update method designed according to some embodiments of this application;

[0016] Figure 2 This is a schematic diagram illustrating the process of issuing secure media and filling the initial keystore according to some embodiments of this application;

[0017] Figure 3 This is an exemplary flowchart of a key update method performed by an application terminal according to some embodiments of this application;

[0018] Figure 4 This is an exemplary flowchart of a method for determining and triggering a key update based on the remaining key quantity according to some embodiments of this application;

[0019] Figure 5 This is an exemplary flowchart of a method for determining and triggering a key update based on the remaining key availability time, according to some embodiments of this application.

[0020] Figure 6 This is an exemplary flowchart of a method for exchanging a master key store and a backup key store according to some embodiments of this application;

[0021] Figure 7 This is an exemplary flowchart illustrating a key update method performed by a key management platform according to some embodiments of this application;

[0022] Figure 8 This is an exemplary flowchart illustrating an example of a quantum key update process according to some embodiments of this application;

[0023] Figure 9 This is an exemplary block diagram of a key update system according to some embodiments of this application;

[0024] Figure 10 This is an exemplary block diagram of an electronic device according to some embodiments of this application specification. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to help readers better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and modifications based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0026] It should be understood that the terms "system," "device," "unit," and / or "module" used in this specification are a method of distinguishing different components, elements, parts, sections, or assemblies at different levels. However, if other words can achieve the same purpose, they may be replaced by other expressions.

[0027] Unless otherwise specified, the technical terms used to describe components, elements, etc. in this specification are not singular but may include plural. Generally speaking, terms such as "comprising" or "including" only indicate that explicitly identified steps, elements, or components are included, and these steps, elements, and components do not constitute an exclusive list, as the described method or apparatus may also include other steps or components.

[0028] This specification uses flowcharts to illustrate the operational steps performed by the apparatus or system of related embodiments. However, unless otherwise specified, the order in which these steps are described should not be construed as a limitation on the order of execution. Those skilled in the art can adjust the order of these steps based on the knowledge and information conveyed by the embodiments in this specification. Adjustments include, but are not limited to, reversing the order of steps, merging multiple steps, and splitting a step.

[0029] Please see Figure 1 , Figure 1 This is a schematic diagram of the operating environment of the key update method shown in some embodiments of this application, such as... Figure 1 As shown, the operating environment may include: a quantum key management platform, an application terminal, and a secure medium. In this environment, the secure medium is connected to the application terminal, which in turn connects to the quantum key management platform via a network. In this environment, the administrator connects to the quantum key management platform through the application terminal and writes the quantum key obtained from the platform into the secure medium for the first time, completing the issuance of the medium and the initial key filling.

[0030] It should be noted that, Figure 1The illustrated operating environment diagram is merely an example. The operating environment described in the embodiments of this specification is intended to more clearly illustrate the technical solutions of the embodiments of this specification and does not constitute a limitation on the technical solutions provided in the embodiments of this specification, nor is it intended to limit the scope of protection of this application. Depending on the actual situation, any number of quantum key management platforms and application terminals can be included. As those skilled in the art will understand, with the development of technology and the emergence of new business scenarios, the technical solutions provided in the embodiments of this specification are also applicable to similar technical problems.

[0031] Please see Figure 2 , Figure 2 This is a schematic diagram illustrating the process of issuing secure media and filling the initial keystore according to some embodiments of this application. For example... Figure 2 As shown, in a secure operating environment, the administrator connects the quantum key security medium to a dedicated quantum key filling device, which is connected to a quantum key management platform. The quantum key management platform obtains quantum keys from a quantum key source (e.g., a QKD quantum key distribution network or a QRNG quantum random number generator). The administrator operates the device to complete the issuance of the security medium, filling it with quantum keys, and then delivers the medium to the user. The filled security medium contains two quantum key repositories: a primary quantum key repository and a backup quantum key repository. The primary quantum key repository is used for key consumption during daily business operations. When the remaining key quantity in the primary key repository falls below a preset threshold, the system performs a primary / backup key repository switching operation: the backup key repository becomes the new primary key repository, and the original primary key repository becomes the new backup key repository. At this time, the new backup key repository can be replenished with keys using the key update method provided in this embodiment.

[0032] Currently, there are two main methods in the industry for updating quantum-safe media: Method 1: Before the quantum-safe media is issued, the device obtains quantum keys from the quantum key management platform and writes them into the media. The keys are not updated after the media is delivered to the user; the media needs to be replaced when the keys are exhausted. With this method, the possibility of key theft increases over long-term use, leading to data leakage and security risks. Method 2: A portion of quantum keys is pre-filled into the quantum-safe media upon issuance. After delivery to the user, when the key quantity in the secure media is insufficient, the terminal application can initiate a request to the quantum key management platform to obtain new keys and write them into the media for updating. This method requires active user intervention and involves a full update of the entire key store file within the secure media, resulting in long update times and service unavailability during the update period.

[0033] To address the aforementioned issues, some embodiments of this application provide a key update method. This method is applied to an application terminal connected to a secure medium, which is equipped with a master key repository and a backup key repository. In this method, the application terminal is connected to a secure medium containing both a master key repository and a backup key repository. Under normal operating conditions, the secure medium uses keys from the master key repository to execute relevant business functions. When a key update request is triggered, the application terminal sends a key update request message to a key management platform. This message includes a secure medium type identifier, a target key index, and a master key repository identifier. Responding to the request message, the key management platform uses the matching key index and key repository identifier to determine the quantum key used for encryption and generates a response message containing new key data encrypted with that quantum key. After receiving the response message, the application terminal extracts the corresponding decryption key from the secure medium based on the key index and the master key repository identifier. Since the key management platform and the application terminal use the same key index and logic, the application terminal can successfully decrypt the new key data and obtain the target key to be updated. During this process, the key management platform protects the distribution of new quantum keys based on quantum keys shared with application terminals. This encryption mode enables the transmitted quantum key data to resist cracking attacks by quantum computers, effectively solving the security vulnerabilities faced by traditional key distribution methods. Furthermore, the backup key repository configured with secure media provides business continuity assurance during the update process. When an application terminal performs a key update operation on the primary key repository, user services can seamlessly switch to the keys in the backup key repository to continue operating. This mechanism ensures that the key update process is completely transparent to users, and business processes are uninterrupted.

[0034] Figure 3 This is an exemplary flowchart of a key update method according to some embodiments of this application, which can be derived from... Figure 1 The application terminal shown is connected to a secure medium, which is equipped with a master key store and a backup key store.

[0035] In some embodiments, Figure 3 The process shown may include the following steps:

[0036] Step 310: The application terminal sends a key update request message to the key management platform.

[0037] The key update request message includes at least a security medium type, a key index, and a key repository identifier, wherein the key index is used to indicate the key in the key repository corresponding to the key repository identifier.

[0038] In one example, the application terminal is a user terminal device configured with a business application that integrates a quantum-safe SDK. The security medium is a quantum key security medium storing several quantum keys. This quantum key security medium is a universal smart key conforming to the "GM / T0016 Smart Cryptographic Key Cryptographic Application Interface Specification," and can be in the form of a USB key, TF card, etc. After secondary issuance and refilling by the key management platform, quantum keys can be securely stored within the medium. The security medium contains a master key repository and a backup key repository. The master key repository stores keys consumed by the business application, while the backup key repository stores newly updated keys, ensuring that the update process does not affect business usage. The quantum-safe SDK serves as the application API interface provided by the key management platform and the security medium. Various user applications can use this interface to perform cryptographic functions such as key remaining quantity query, key update threshold query, key update, session key handle application, and data encryption / decryption. The key management platform is a quantum key management platform. This platform mainly realizes the management of quantum key media issuance, key filling or updating, extension, cancellation, and loss reporting, and realizes full life cycle management of all filled or updated quantum keys.

[0039] In one example, the application terminal sends an update request message to the key management platform through the quantum security SDK. The update request message contains three types of information: "security media type" (such as USB key, TF card), "key vault identifier" (such as master key vault ID and backup key vault ID), and "key index" (indicating the key used for encryption in the target key vault). Through these three types of information, the key management platform can clearly identify the type of security media to be updated and the key used to encrypt the new key, thus ensuring the accuracy of the subsequent encryption process.

[0040] Step 320: The application terminal receives encrypted key data issued by the key management platform.

[0041] Step 330: The application terminal determines the target key library from the master key library and the backup key library based on the key library identifier, and determines the decryption key from the target key library based on the key index.

[0042] Step 340: The application terminal decrypts the encrypted key data based on the decryption key to obtain a set of keys to be updated.

[0043] In one example, the application terminal first locates the master key repository using the key repository identifier, then finds the basic key used for encryption in the master repository using the key index, and uses this key to decrypt the encrypted key data issued by the platform to obtain the plaintext key to be updated. In this way, by using the key already stored in the secure medium, which is known to both the application terminal and the key management platform, the new key is encrypted and decrypted, ensuring that only legitimate terminals can obtain the new key and guaranteeing the security of the update.

[0044] Step 350: The application terminal writes the keys to be updated from the set into the backup key library of the security medium.

[0045] In one example, the backup keystore is only used to store newly updated keys and does not affect the business consumption of the master keystore, thus ensuring that the update process does not interrupt business operations.

[0046] Through the execution of steps 310 to 350 above, the key management platform protects the distribution of new quantum keys based on the quantum key shared with the application terminal. This encryption mode enables the transmitted quantum key data to resist cracking attacks by quantum computers, effectively solving the security vulnerabilities faced by traditional key distribution methods. Furthermore, the backup key store configured with secure media provides business continuity assurance during the update process. When the application terminal performs a key update operation on the primary key store, user services can seamlessly switch to the keys in the backup key store to continue operating. This mechanism ensures that the key update process is completely transparent to users, and business processes are uninterrupted.

[0047] The basic key update process described above (steps 310 to 350) addresses how to perform the key update. However, in real-world business scenarios, the timing of the update is equally crucial for ensuring key availability and preventing business interruptions. If the update is triggered too early, it increases unnecessary communication and encryption overhead; if it is triggered too late, it may lead to business interruptions due to key depletion.

[0048] To address this, this embodiment further provides two optional key update triggering mechanisms to adapt to the needs of different business scenarios: In one method, the application terminal determines whether to perform a key update based on a threshold of the remaining key quantity (e.g., unused keys are below a preset quantity); in the other method, the application terminal determines the key availability time by combining the average daily consumption and the remaining quantity, and then determines whether to perform a key update. Both triggering methods can be selected according to actual business needs, ensuring both the timeliness of key updates and avoiding resource waste caused by invalid updates, making the overall solution more universal and reliable.

[0049] Figure 4 This is a flowchart illustrating how to determine and trigger a key update based on the remaining key quantity, according to some embodiments of this application. In some embodiments, such as... Figure 4 As shown, the method includes the following steps.

[0050] Step 410: The application terminal obtains the key usage status of the master key store in the security medium.

[0051] In one example, the master key store on a secure medium (such as a USB key) stores the quantum keys currently used by business applications. Each quantum key is identified by a unique index (e.g., ID = 001, 002, etc.) and its "used" or "unused" status is recorded (updated by the quantum safety SDK). The application terminal reads the master key store's status data through the integrated quantum safety SDK's API. For example, the application terminal calls the update method provided by the quantum safety SDK, which establishes communication with the master key store through the secure medium's hardware interface (e.g., USB protocol). The secure medium returns metadata about the master key store, which may include: the total number of keys (e.g., a preset capacity of 1000), the number of used keys (e.g., 300, with indexes recording which IDs have been consumed by business applications), and the number of unused keys (calculated, e.g., 1000 - 300 = 700). The application terminal temporarily stores the number of unused keys in its local memory for subsequent processing.

[0052] Step 420: If the number of unused quantum keys is lower than a preset first threshold, the application terminal sends a key update request message to the key management platform.

[0053] In one example, the first threshold is a critical value set based on the minimum security margin of the business, used to determine whether an update needs to be initiated. The size of the first threshold needs to be determined in combination with the "single update key quantity" (e.g., 1KB corresponds to approximately 200 keys) and the "minimum buffer requirement of the business". The application terminal uses the first threshold to determine whether to initiate the key update process, avoiding service interruption due to key exhaustion, and preventing resource waste (such as network communication and encryption computing overhead) caused by premature updates. For example, the administrator configures the first threshold for the application terminal to be 100 unused quantum keys through the console of the key management platform (i.e., when the number of unused keys is ≤100, an update is triggered). This first threshold is synchronized to the application terminal's local configuration file through an encrypted channel. The application terminal reads the first threshold from the local configuration and compares it with the number of unused keys obtained in step 410. If the number of unused keys (e.g., 80) is less than the first threshold (100), the update process is triggered, and a key update request message is generated. If the number of unused keys (e.g., 150) is greater than the first threshold (100), no update is triggered. Step 410 will be executed again when the next business is triggered or a scheduled check is performed.

[0054] Obviously, Figure 4 Steps 430 to 460 are similar to steps 320 to 350, and will not be described in detail here.

[0055] Thus, by execution Figure 4Steps 410 to 420 shown implement a mechanism for determining whether to trigger a key update based on the remaining number of keys. That is, when the remaining amount of the master key in the security medium is lower than the first threshold (key update threshold), an update is forcibly started to ensure that the keys in the security medium are available. This mechanism is suitable for situations with stable business volume and avoids the risk of key exhaustion through pre-judgment.

[0056] Figure 5 This is a flowchart illustrating how to determine and trigger a key update based on the remaining key availability time, according to some embodiments of this application. In some embodiments, such as... Figure 5 As shown, the method includes the following steps.

[0057] Step 510: After executing the service, the application terminal records the key consumption and the service timestamp.

[0058] In one example, the application terminal uses a quantum-safe SDK to record key usage in real time, such as the number of keys consumed and the time of occurrence, providing basic data for subsequent computational consumption rates. This record must be tamper-proof (e.g., stored via a chip-based log in the medium) to ensure data accuracy. For instance, whenever the application terminal completes an encryption or decryption transaction (such as user login or data transmission), the quantum-safe SDK automatically triggers the recording operation. The recorded content may include: the actual number of quantum keys used in this transaction, the transaction completion time, and a tag distinguishing the transaction type. The recorded data is encrypted and stored in the application terminal's local database, retaining records for a specified period (e.g., 30 days).

[0059] Step 520: The application terminal determines the average daily key consumption within a preset time range based on the recorded key consumption and business timestamp.

[0060] In one example, the application terminal calls the corresponding interface to read all key consumption and business timestamps within a preset time range from the local database, filtering out invalid data. The total key consumption after filtering is accumulated, and the total is divided by the number of days in the time range to obtain the average daily key consumption. If there is no business on a certain day, it is calculated as 0.

[0061] Step 530: The application terminal calculates the key availability time based on the average daily key consumption, the number of unused keys, and a preset first threshold.

[0062] In one example, the key availability time is defined as: the estimated duration for which the remaining unused keys can be maintained until they drop to a first threshold, based on the current number of unused keys and the average daily key consumption rate. In an optional implementation, the key availability time can be calculated using the following formula: Key availability time = (Number of unused keys - First threshold) ÷ Average daily key consumption. It should be noted that the above calculation method is merely an example, and those skilled in the art should understand that other equivalent or alternative methods can be used to calculate the key availability time; this embodiment does not specifically limit this. For example, the application terminal obtains the number of unused keys (e.g., the current master key repository has 150 unused keys), and performs calculations through the quantum security SDK interface based on the first threshold and the average daily consumption rate, such as (150-100) ÷ 28 ≈ 1.79 days (rounded to two decimal places). To ensure smooth business execution, a rounding down method is used, ultimately determining the key availability time to be approximately 1 day.

[0063] Step 540: The application terminal compares the calculated key availability time with the preset second threshold. If the key availability time is less than the preset second threshold, it sends a key update request message to the key management platform.

[0064] In one example, the second threshold is the minimum allowed key availability time. If the availability time is less than this second threshold, it means that even if the current reserve does not reach the first threshold, an update is required in advance to cope with sudden surges in business volume. For example, the administrator configures the second threshold (e.g., 7 days) through the key management platform. This second threshold indicates that the key availability time must be buffered for at least 7 days to avoid insufficient supply due to sudden consumption, and this second threshold is synchronized to the application terminal. The application terminal compares the key availability time (1 day) calculated in step 530 with the second threshold (7 days). If 1 < 7, the triggering condition is met, and a request message is generated. If the availability time is ≥ the second threshold, no update is triggered, and sufficient availability time is recorded (e.g., 8 days ≥ 7 days). The business process is returned, and step 510 is executed again after the next business.

[0065] Obviously, Figure 5 Steps 550 to 580 shown are similar to steps 320 to 350, and will not be described in detail here.

[0066] By execution Figure 5 Steps 550 to 590, as shown, implement key updates triggered based on a key availability time threshold. Even if the current key balance has not reached the first threshold, risks can be predicted by consumption trends, allowing for early updates to address business fluctuations. This further enhances the adaptability of the solution.

[0067] In the key update process implemented in steps 310 to 350 above, secure key updates have been achieved. However, in actual business scenarios, the state management of the primary and backup key repositories and the guarantee of business continuity under extreme conditions still need further refinement. Ignoring historical key remnants in the backup repository or sudden depletion of the primary repository may lead to risks such as key index confusion and business interruption. Therefore, this application also provides a method for exchanging the states of the primary and backup key repositories before the key to be updated is written to the medium, thereby ensuring the purity of the backup key repository during regular updates.

[0068] Figure 6 This is an exemplary flowchart illustrating a method for exchanging a master key store and a backup key store and writing the key to be updated, according to some embodiments of this application. In some embodiments, such as Figure 6 As shown, the method includes the following steps.

[0069] Step 650: The application terminal switches the status of the master key store to the backup key store, and switches the status of the backup key store to the master key store, and deletes all keys in the key store that is now the backup key store after the status switch.

[0070] In one example, the quantum-safe SDK interacts with the quantum key security medium to read the identifiers of the current primary and backup key libraries (e.g., primary key library ID "MK1", backup key library ID "BK1"). The quantum-safe SDK sends a state switching command to the security medium, marking "MK1" as the "backup key library" and "BK1" as the "primary key library". Simultaneously, the SDK sends a synchronization notification to the key management platform, carrying the switched primary and backup key library IDs. The platform updates its local records of the medium's key library status to ensure consistency between the two ends. After confirming the primary / backup state switch is complete, the quantum-safe SDK sends a command to the security medium to locate the new backup key library (e.g., the switched "MK1"). The quantum-safe SDK performs a "full deletion" operation on the backup key store through the encryption interface of the quantum-safe medium, ensuring that residual keys are completely removed. After the operation is completed, the quantum-safe SDK sends a "backup key store cleared successfully" message to the key management platform. The platform records this status to prepare for subsequent key updates.

[0071] Step 660: Write the keys to be updated in the set into the key library of the backup key library after the state switch of the security medium.

[0072] In one example, after the application terminal decrypts the key to be updated, it writes it into the new backup database (“MK1”) using the quantum security SDK, completing the update. Finally, the quantum security SDK reports a successful update to the management platform, which records the number of keys in the new backup database and the update time, completing full lifecycle management.

[0073] Obviously, Figure 6 Steps 610 to 640 shown are similar to steps 310 to 340 described above. They will not be repeated here.

[0074] Through steps 650 and 660, before writing the new key to the backup key repository, the application terminal can thoroughly remove any remaining used and unused keys from the original primary key repository by switching the states of the primary and backup key repositories and cleaning up the old backup repository. (These keys may be at risk of leakage due to long-term storage or cause management chaos due to index overlap.) This design ensures that the newly written key set has an independent and clean storage environment, avoiding confusion between old and new keys, and ensuring that the business can still use the keys from the original backup repository (which has been switched to the primary repository) through state switching, thus achieving the core goal of parallel updates and business operations.

[0075] The basic key update process described above (steps 310 to 350) addresses how to perform key updates. However, in real-world business scenarios, there may be situations where business operations cannot be interrupted, resulting in no key request being sent even after switching between the primary and backup key stores. In this case, the key terminal will obtain the usage status of the keys in the primary key store. If no unused keys are found, the primary key store will be switched to the backup key store status, and the backup key store will be switched back to the primary key store status, sending a key update request message to the key management platform.

[0076] Thus, if no usable keys are available in the master keystore, simply waiting for the update to complete would lead to business interruption (such as encryption failure or transaction termination). The emergency master / backup keystore switching mechanism allows the backup keystore to be immediately switched to the master keystore to support business operations, while simultaneously triggering an update request to replenish the new keys to the original master keystore (which has already been switched to the backup keystore), forming a seamless connection between "emergency support and background replenishment." This design compensates for the shortcomings of the advance prevention logic in the basic key update process (such as steps 310 to 350), providing a safety net for unexpected key depletion situations and ensuring zero business interruption.

[0077] This application provides another key update method in some embodiments, applied to a key management platform configured with multiple key stores. In this method, the key management platform configures multiple key stores for each terminal device. During the execution of the specific method, the key management platform passively receives key update request messages sent by the application terminal. These messages include a security medium type, a key index, and a key store identifier. The key index and key store identifier jointly specify a quantum key shared by the key management platform and the terminal. This key is used as a "channel key" to encrypt the communication data for this update, thereby ensuring the security of the update process itself. Furthermore, the key management platform dynamically customizes appropriate update amounts for different types of devices based on the "security medium type" provided in the key update request message. This avoids slow device response or failure due to excessive data being written in a single operation, thereby optimizing hardware performance and overall system compatibility. Finally, the key management platform protects the distribution of new quantum keys based on the quantum keys shared with the terminals. This encryption mode enables the transmitted quantum key data to resist cracking attacks by quantum computers, solves the security risks of traditional technologies, and effectively ensures the confidentiality of the key to be updated during the distribution process.

[0078] Figure 7 This is an exemplary flowchart of another key update method shown in some embodiments of this application, which can be derived by... Figure 1 The key management platform shown is executed. In some embodiments, Figure 2 The process shown may include the following steps:

[0079] Step 710: The key management platform obtains the key update request message sent by the application terminal.

[0080] The key update request message includes at least the security medium type, key index, and key vault identifier.

[0081] Step 720: The key management platform determines the number of quantum keys to be generated based on the type of security medium, and generates a corresponding number of keys to be updated.

[0082] In some embodiments, different security media have different hardware capabilities. For example, a low-end USB Key may only support storing 100 256-bit keys, while a high-end security chip may support storing 1000 512-bit keys. The key management platform needs to generate the number of keys that the terminal can support based on the terminal's media type to avoid over-pushing and causing terminal storage overflow. Therefore, the key management platform determines the maximum number of keys corresponding to the type of security media by performing performance tests on the security media. After receiving a request message for key updates sent by the application terminal, the key management platform determines the number of keys to be generated based on the maximum number of keys corresponding to the type of security media in the request message. For example, if the terminal media is "USBKey-32G", the platform determines after querying its specifications that the maximum update quantity per time is 200 keys, and thus generates 200 128-bit symmetric keys as the set of keys to be updated.

[0083] Step 730: The key management platform determines the target key library from multiple key libraries based on the key library identifier, and determines the encryption key from the target key library based on the key index.

[0084] In one example, the key management platform is the core control node of the entire key update system. It is responsible for generating, storing, and distributing quantum keys, and managing the keystore information of all secure media (such as the primary and backup keystore identifiers and key index ranges for each media). Specifically, the key management platform locally stores the keystore mapping relationship of all secure media (e.g., "the primary keystore identifier for media type USB-key-001 is main_001, and the corresponding keystore ID stored on the platform is K1001"). When the platform receives "keystore identifier = main_001" in a key update request message, it will locate the platform-side keystore corresponding to that identifier (i.e., the "target keystore," which is essentially a key management record reserved by the platform for the primary keystore of this terminal) through the mapping relationship. For example, if the terminal sends "keystore identifier = main_001," the platform will query and find that the identifier corresponds to "the primary keystore of terminal A," and its associated keystore on the platform side is "K1001" (which stores the key generation records and index ranges of this primary keystore), thus determining that the target keystore is K1001. After the platform generates a new key to be updated, it needs to encrypt it using a key already existing on the terminal side (a shared base key) before it can be securely sent to the terminal (ensuring that only that terminal can decrypt it). This "base key" is the encryption key determined by the key index. The platform queries the target key store (e.g., K1001) for the key content corresponding to the key index (e.g., ID=500). This key is an unused key already stored in the target key store on the terminal side (e.g., main_001), and both the platform and the terminal know its content (through previous issuance or update synchronization).

[0085] Step 740: The key management platform encrypts the set of keys to be updated based on the encryption key to generate encrypted key data.

[0086] Step 750: The key management platform sends the encrypted key data to the application terminal.

[0087] Through the above process, the key management platform dynamically customizes appropriate update amounts for different types of devices based on the "security medium type" provided in the key update request message. This avoids slow device response or failure due to excessive data being written in a single instance, thereby optimizing hardware performance and overall system compatibility. Finally, the key management platform protects the distribution of new quantum keys based on the quantum key shared with the terminal. This encryption mode enables the transmitted quantum key data to resist cracking attacks by quantum computers, solving the security vulnerabilities of traditional technologies and effectively ensuring the confidentiality of the key to be updated during the distribution process.

[0088] In the core update process of the aforementioned key management platform (such as steps 710 to 750), a passive response to terminal requests is implemented, but it relies on the application terminal actively sending update requests. However, if the terminal fails to trigger the request in a timely manner due to abnormal local monitoring mechanisms (such as program failures), network latency, or business fluctuations, the risk of key exhaustion may be overlooked, affecting business continuity. To address this, this application provides a method for the key management platform to actively trigger key updates in some embodiments, which can be implemented as follows: the key management platform sends a key update notification to the application terminal, so that the application terminal can send a key update request message after receiving the key update notification.

[0089] For example, the key management platform monitors that the key availability time of terminal B has dropped to 5 days (close to the terminal's preset second threshold of 7 days), but the terminal does not actively send a request (possibly due to a local computing module failure). The platform automatically generates an update notification with the content: "Terminal B needs to update its key, recommended size 1KB, valid until 2023-10-02 00:00", and pushes it to terminal B through an encrypted channel.

[0090] This design avoids update delays caused by terminal monitoring mechanism failures (such as local program anomalies), enhancing the platform's control over the global key status. It also optimizes the collaboration efficiency between the key management platform and application terminals. The key management platform can more accurately predict terminal key needs based on historical data (such as industry peak and off-peak season patterns), proactively pushing notifications to guide terminals to complete updates during off-peak periods (such as 3 AM), avoiding bandwidth consumption during peak hours and improving overall system performance.

[0091] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this patent. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this patent.

[0092] To facilitate understanding, an example of a quantum key update process is given here. For example... Figure 8 As shown.

[0093] The quantum key update process mainly includes: key update threshold query, key remaining quantity query, key update request, media key update, and master / backup key store switching. Specifically, the quantum key management platform can also initiate the quantum key update process by sending a key update notification to the quantum security SDK.

[0094] Key update threshold query: After the user starts the quantum security business application, the application calls the quantum security SDK initialization interface to initialize the quantum security SDK. After the initialization is completed, it queries the quantum key management platform for the quantum key update threshold of the quantum key security medium. The quantum key management platform returns the corresponding update threshold according to the security medium type (such as different media such as ukey, TF card, SIM card, etc.).

[0095] Key Remaining Amount Query: During business operations, applications will call the quantum-safe SDK to consume quantum keys in the security medium. After each key consumption, the quantum-safe SDK will automatically query the security medium for the current remaining key amount and determine whether the remaining key amount is lower than the previously queried key update threshold. If it is lower than the threshold, a subsequent key update will be performed; if it is higher than the threshold, no key update will be performed.

[0096] Key Update Request: When the quantum-safe SDK determines that the remaining key quantity in the security medium is below the key update threshold, or receives a key update notification from the quantum key management platform, and the backup quantum key repository is in a state where no quantum key updates have been performed, it will initiate a key update request to the quantum key management platform. First, the quantum-safe SDK establishes a secure channel with the quantum key management platform. This secure channel uses a usable quantum key from the security medium as the encryption protection for transmitted data. The quantum key management platform possesses the same quantum key, so both the SDK and the platform can encrypt or decrypt the transmitted data. Second, the quantum-safe SDK generates a key update request message. The message carries the security medium type and device ID, the master quantum key repository ID, the backup quantum key repository ID, and the master key repository quantum key index information for encrypting the quantum key data to be updated. The message is encrypted using the quantum key of the secure channel, and then the quantum-safe SDK sends the encrypted key update request to the quantum key management platform through the secure channel. Third, after receiving the encrypted key update request message, the quantum key management platform decrypts the message using the quantum key of the secure channel to obtain the plaintext key update request. It then parses the request to obtain the secure medium type and device ID, the primary and backup quantum key store IDs, and the quantum key index of the primary quantum key store used to encrypt the quantum key data to be updated. Fourth, the quantum key management platform generates a certain number of quantum keys to be updated based on the secure medium type. This number of keys is pre-determined and configured on the quantum key management platform according to the performance of different types of media. It then uses the quantum key index of the primary quantum key store obtained from the previous key update request parsing to retrieve the corresponding quantum key. This quantum key is used to encrypt the previously generated quantum keys to be updated, resulting in the encrypted quantum keys to be updated. Finally, a key update response message is generated, carrying the encrypted quantum keys to be updated, and sent to the quantum security SDK through the secure channel.

[0097] Medium Key Update: After receiving the quantum key update response message, the quantum-safe SDK decrypts the message using the quantum key of the secure channel to obtain the plaintext key update response, and then parses the response message to obtain the ciphertext quantum key to be updated. Next, it uses the quantum key corresponding to the quantum key index of the master quantum key store carried in the aforementioned key update request to decrypt the ciphertext quantum key to be updated, obtaining the plaintext quantum key to be updated. Finally, it writes the plaintext quantum key to be updated into the backup quantum key store in the secure medium, completing the medium key update.

[0098] Master-Slave Key Repository Switching: When the remaining quantum keys in the master quantum key repository are nearly exhausted, the quantum security SDK can initiate a master-slave key repository switch and notify the quantum key management platform to perform the switch synchronously. After the switch is completed, the original master quantum key repository becomes the new backup quantum key repository, and the original backup quantum key repository becomes the new master quantum key repository. Subsequent quantum key consumption for business operations will be carried out on the new master quantum key repository, while quantum key updates will be carried out on the new backup quantum key repository.

[0099] Thus, by using the method described above for automatically triggering updates to the quantum key in the quantum-secure medium based on application services, the quantum key within the secure medium can be securely updated without affecting user services, and users are unaware of the key update. This method does not rely on asymmetric encryption techniques and has the ability to resist quantum computer attacks, effectively improving the security of quantum key usage.

[0100] The embodiments of this application specification also relate to a key update system. Figure 9 This is an exemplary block diagram of a key update system according to some embodiments of this application. Figure 9 As shown, in some embodiments, the key update system includes a key management platform and multiple application terminals.

[0101] The key management platform includes an update request receiving module, an update key generation module, an encryption key determination module, and an update response sending module. The update request receiving module receives key update request messages sent by the application terminal. The update key generation module determines the number of keys to be generated based on the security medium type and generates the corresponding number of keys to be updated. The encryption key determination module determines the target key library from multiple key libraries configured on the key management platform based on the key library identifier, and determines the encryption key from the target key library based on the key index. It then encrypts the set of keys to be updated using the encryption key to generate encrypted key data. The update response sending module sends the encrypted key data to the application terminal.

[0102] The application terminal includes an update request sending module, an update response receiving module, a decryption key determination module, and an update key writing module. The update request sending module sends a key update request message to the key management platform. The update response receiving module receives encrypted key data from the key management platform. The decryption key determination module determines the target key library from the master and backup key libraries of the security medium based on the key library identifier, and determines the decryption key from the target key library based on the key index. It then decrypts the encrypted key data using the decryption key to obtain a set of keys to be updated. The update key writing module writes the keys to be updated from the set into the backup key library of the security medium.

[0103] It is not difficult to see that this embodiment is a system implementation corresponding to the first embodiment, and this embodiment can be implemented in conjunction with the first embodiment. The relevant technical details mentioned in the first embodiment are still valid in this embodiment, and will not be repeated here to reduce repetition. Accordingly, the relevant technical details mentioned in this embodiment can also be applied to the first embodiment.

[0104] It is worth mentioning that all modules involved in this embodiment are logical modules. In practical applications, a logical unit can be a physical unit, a part of a physical unit, or a combination of multiple physical units. Furthermore, to highlight the innovative aspects of this application, this embodiment does not introduce units that are not closely related to solving the technical problem proposed in this application; however, this does not mean that other units are absent from this embodiment.

[0105] Another embodiment of this application relates to an electronic device, such as... Figure 10 As shown, it includes at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the key update method as described above.

[0106] The memory and processor are connected via a bus, which can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors and memories. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0107] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0108] Those skilled in the art will understand that the above embodiments are specific implementations of this application, and in practical applications, various changes can be made in form and detail without departing from the spirit and scope of this application.

Claims

1. A key update method, characterized in that, It is applied to an application terminal, which is connected to a security medium, and the security medium is equipped with a master key store and a backup key store. The method includes: Send a key update request message to the key management platform, wherein the key update request message includes at least the security medium type, key index, and key vault identifier, and the key index is used to indicate the key in the key vault corresponding to the key vault identifier; Receive encrypted key data issued by the key management platform; The target key library is determined from the master key library and the backup key library based on the key library identifier, and the decryption key is determined from the target key library based on the key index; the encrypted key data is decrypted based on the decryption key to obtain a set of keys to be updated; The keys to be updated from the set are written into the backup key store of the security medium.

2. The key update method according to claim 1, characterized in that, Before sending a key update request message to the key management platform, the method further includes: Obtain the usage status of the keys in the master key store; If the number of unused keys is lower than a preset first threshold, a key update request message is sent to the key management platform.

3. The key update method according to claim 1, characterized in that, The method further includes: After executing the business transaction, record the key consumption and the business timestamp; Based on the recorded key consumption and business timestamps, determine the average daily key consumption within a preset time range; The key availability time is calculated based on the average daily key consumption, the number of unused keys, and a preset first threshold. If the key's availability time is less than a preset second threshold, a key update request message is sent to the key management platform.

4. The key update method according to claim 1, characterized in that, Before writing the keys to be updated from the set into the backup key store of the secure medium, the following steps are included: Switch the state of the master key store to the backup key store, and switch the state of the backup key store to the master key store; Delete all keys in the keystore that serves as the backup keystore after the state switch.

5. The key update method according to claim 1, characterized in that, The method further includes: The system retrieves the usage status of the keys in the master key repository. If no unused keys are found, the system switches the status of the master key repository to the backup key repository and then switches the status of the backup key repository to the master key repository. Finally, a key update request message is sent to the key management platform.

6. A key update method, characterized in that, It is applied to a key management platform, which is configured with multiple key stores; The method includes: Obtain a key update request message sent by the application terminal, wherein the key update request message includes at least the security medium type, key index, and key store identifier; The number of keys to be generated is determined based on the type of security medium, and a corresponding number of keys to be updated are generated. The target key library is determined from the plurality of key libraries based on the key library identifier, and the encryption key is determined from the target key library based on the key index; the set of keys to be updated is encrypted based on the encryption key to generate encrypted key data; The encrypted key data is sent to the application terminal.

7. The key update method according to claim 6, characterized in that, Before obtaining the request message for key update sent by the application terminal, the method further includes: By performing performance tests on the security medium, the maximum key size corresponding to the type of security medium can be determined. The step of determining the number of keys generated based on the security medium type includes: The number of keys to be generated is determined based on the maximum number of keys corresponding to the security medium type.

8. The key update method according to claim 6, characterized in that, The method further includes: A key update notification is sent to the application terminal so that the application terminal can send the key update request message after receiving the key update notification.

9. A key update system, characterized in that, The system includes: a key management platform and multiple application terminals; The key management platform includes: An update request receiving module is used to obtain a key update request message sent by the application terminal, wherein the key update request message includes at least the security medium type, key index, and key store identifier; The key generation module is used to determine the number of keys to be generated based on the type of security medium, and to generate a corresponding number of keys to be updated. An encryption key determination module is used to determine a target key library from multiple key libraries configured in the key management platform based on the key library identifier, and to determine an encryption key from the target key library based on the key index; and to encrypt the set of keys to be updated based on the encryption key to generate encrypted key data. Update the response sending module to send the encrypted key data to the application terminal; The application terminal includes: The update request sending module is used to send a key update request message to the key management platform. The key update request message includes at least a security medium type, a key index, and a key store identifier. The key index is used to indicate the key in the key store corresponding to the key store identifier. Update the response receiving module to receive encrypted key data issued by the key management platform; The decryption key determination module is used to determine the target key library from the master key library and backup key library of the security medium according to the key library identifier, and to determine the decryption key from the target key library according to the key index; and to decrypt the encrypted key data based on the decryption key to obtain a set of keys to be updated; The update key writing module is used to write the keys to be updated in the set into the backup key library of the security medium.

10. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the key update method as described in any one of claims 1 to 5, or the key update method as described in any one of claims 6 to 8.

Images