Key management system based on version management

Abstract

The invention discloses a key management system based on version management. The key management system comprises cryptographic equipment and a key backup central server, the cryptographic device comprises a key card used for generating keys of different version numbers according to a time baseline in a hardware security environment and encrypting the keys of different version numbers through a device key; the local key synchronization service module is used for detecting key changes and synchronizing the key changes to the central server; the key backup central server is used for storing a key version directory and an encryption key file of the full-quantity equipment; the cryptographic device communicates with the key backup central server through a network to realize two-way synchronization of key version data, support selection of multiple version keys for combination and recovery, and solve index conflicts through hash comparison. According to the invention, the key life cycle of the cryptographic equipment is managed based on the version number, and the management work is clearer; and fusion recovery can be carried out by using multiple version key backups, so that more key recovery scenes can be met.

Description

Technical Field

[0001] The present invention relates to the field of information security technology, and more specifically, to a key management system based on version management, which is applicable to cryptographic machines, encryption machines, SSL VPN gateways, IPSec VPN gateways, signature verification servers, financial data cryptographic machines, etc. Background Art

[0002] Keys are the key to protecting sensitive data in a cryptographic information system. Once lost, it may lead to irrecoverable data access permissions. Therefore, the key life cycle management processes such as key generation, update, destruction, backup, and recovery of cryptographic devices are extremely important.

[0003] Existing key life cycle management is carried out based on the granularity of a single key object. The management method basically relies on manual records of the usage of each key on the device at a certain time point, and key backups are performed based on the time point. If there are update operations such as key deletion and generation, the key life cycle status needs to be recorded, and key backups are repeated. The management work is trivial, and it is impossible to fuse key backups at two or more time points. It can only restore the device key to the state at a certain time point;

[0004] Therefore, the following problems exist:

[0005] Difficult version tracing: It is impossible to mark the key status along the time line, and the operation and maintenance complexity is high.

[0006] Single recovery scenario: Only single-version recovery is supported, and it is difficult to meet the multi-version fusion requirements.

[0007] Insufficient conflict handling: There is a lack of an automated solution when there are conflicts in multi-version key indexes. Summary of the Invention

[0008] In view of this, the present invention provides a key management system based on version management, which solves the above problems through versioned management and multi-version fusion recovery.

[0009] In order to achieve the above object, the present invention adopts the following technical solutions:

[0010] An embodiment of the present invention provides a key management system based on version management, including: a key backup central server and at least one cryptographic device, and the keys of the cryptographic device are centrally stored in the key backup central server;

[0011] Among them, the cryptographic device is deployed on the user side and includes:

[0012] A key card, which is used to generate keys with different version numbers according to the time baseline in a hardware security environment, and encrypt the keys with different version numbers through the device key;

[0013] Local key synchronization service module, used to detect key changes and synchronize them to the central server;

[0014] Password device key management system, providing an interactive interface for administrators to create versions, generate keys, delete keys, key recovery, and trigger backup operations;

[0015] Key management module, used for key generation and encryption, performing local storage management, and providing a unified interface service;

[0016] Local key object file repository, storing key object files and a reference file directory tree organized by version number;

[0017] The key backup central server is deployed on the remote side, including:

[0018] Central key object file repository, storing the key version directory of all devices and encrypted key files;

[0019] KMS, providing compliant key storage and redundant backup with the central repository;

[0020] Central repository key synchronization service module, receiving and verifying synchronization data from the password device and updating the content of the central repository;

[0021] The password device communicates with the key backup central server through the network to achieve two-way synchronization of key version data, support the selection of multiple version keys for merge recovery, and resolve index conflicts through hash comparison.

[0022] Further, the reference file directory tree is organized in the following hierarchy:

[0023] The root directory is the device serial number;

[0024] The subdirectory is the version number, storing the key reference file corresponding to the version;

[0025] The cursor file points to the current active version directory.

[0026] Further, in the central key object file repository:

[0027] The directory tree structure is mirrored corresponding to the local directory of the password device, and the root directory is / root;

[0028] Under each version directory, key reference files are stored and associated with the key object files in KMS through hash values.

[0029] Further, the working process of the local key synchronization service module includes:

[0030] Periodically compare the hash value and quantity of the key at the current moment with those at the previous moment;

[0031] When a difference is detected, automatically push the newly added or modified key reference file directory tree and key objects to the key backup central server;

[0032] Receive the synchronization instruction from the central server and pull the key reference file directory tree and key objects of the specified version to the local cryptographic device.

[0033] Furthermore, the multi-version merging and recovery process of the system includes:

[0034] Create a new version directory at the cryptographic device side;

[0035] Pull multiple historical version data from the central repository to the local cryptographic device;

[0036] Merge the keys through a conflict resolution algorithm to generate the final key set and update the cursor file.

[0037] Furthermore, the conflict resolution algorithm is specifically:

[0038] Take the union of the intersection results of all versions and compare the hash values of the same-index keys in different versions;

[0039] If the hash values are different, retain the key index of the earliest version and assign a new index to the conflicting key; the new index is MAX + 1, where MAX is the maximum value of the currently used key indexes;

[0040] If the hash values are the same, retain only one copy of the key.

[0041] From the above technical solutions, it can be seen that compared with the prior art, the present invention has the following technical advantages:

[0042] The present invention takes the time line as the baseline, regards all key objects on the cryptographic device at a certain time point as a version, different time points correspond to different versions, and manages the key life cycle of the cryptographic device based on the version number, making the management work clearer;

[0043] 1. Improved operation and maintenance efficiency: The version number marks the key status, supporting fast backtracking and statistics.

[0044] 2. Recovery flexibility: Multiple version key backups can be used for fusion recovery to meet more key recovery scenarios.

[0045] 3. High reliability: Supports automatic backup, and ensures the security of keys through dual storage of KMS and the central repository.

[0046] 4. Automatic conflict handling: Reduces manual intervention and ensures data consistency. Description of the Drawings

[0047] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only the embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on the provided drawings.

[0048] Figure 1 Schematic diagram of the key management system based on version management provided by the present invention.

[0049] Figure 2 Schematic diagram of the key object reference file structure provided by the present invention.

[0050] Figure 3 Schematic diagram of the key object file structure provided by the present invention.

[0051] Figure 4 General flowchart of key recovery provided by the present invention.

[0052] Figure 5 Schematic diagram of the multi-version key fusion processing process provided by the present invention. Detailed implementation manners

[0053] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0054] As Figure 1 shown, the embodiments of the present invention disclose a key management system based on version management, including: at least one cryptographic device and a key backup central server; they have a many-to-one relationship, and the keys of the cryptographic devices are centrally stored in the key backup central server; where:

[0055] 1. The cryptographic device is deployed on the user side and includes a cryptographic device key management system, a local key synchronization service module, a key management module, a cryptographic card key management interface, a local key object reference file directory tree, a cryptographic card, a local cryptographic object file repository, and a local disk.

[0056] The cryptographic device key management system provides an interaction ability, and the management personnel use the cryptographic device key management system to complete operations such as version creation, key generation, key deletion, key backup, and key recovery.

[0057] The local key synchronization service module automatically or upon receiving a synchronization instruction from the password device key management system communicates with the central repository key synchronization service module to synchronize the key object reference file directory tree and key objects of the device locally to the key backup central server. That is, this module can detect changes automatically, periodically scan the local key repository, and compare the current key status with the previous version (such as changes in the number of keys and hash values). When changes exist, it further realizes data synchronization:

[0058] For example, push: when changes are detected, upload the newly added / modified key reference files and key object files to the central server. Pull: when recovering, download the key data of the specified version from the central server to the local.

[0059] The password card provides key operation capabilities. The key needs to be loaded into the password card and used in the form of an index number. For example, use key No. 1 to encrypt a piece of data. To ensure the security of the key, the key is generated inside the password card; the key can only be stored and transmitted externally in the form of a key object after being encrypted by the password card device key. These operations are implemented through the password card key management interface.

[0060] The password card key management interface can call the password card to generate the original key; use the built-in device key of the password card to encrypt the original key to generate a key object file that can be stored externally. In addition, the decrypted key can be called from the password card according to the index number (such as "key No. 1") for encryption / decryption operations. The password card key management interface is the software implementation of the key card key management capabilities and is called by the local key synchronization service module and the key management module;

[0061] The local key object reference file directory tree stores the reference information of the key in a tree-like directory structure (such as / local / SN001 / v1.0 / 1), such as Figure 2 shown, including: version number, key hash value (unique fingerprint), key index number, SN of the cloud cipher machine virtual machine to which it belongs, key creation time. Key reference files of different versions are stored in independent directories (such as v1.0, v2.0) to avoid confusion. In addition, the current active version can be pointed to through a soft link (such as current → v2.0). That is, the hierarchical organization of the reference file directory tree includes: the root directory is the device serial number; the subdirectory is the version number, storing the key reference files corresponding to the version; the cursor file points to the current active version directory.

[0062] The key management module serves as a link between the upper and lower layers. It calls the password card key management interface of the key card downward to generate keys in the key card, export the keys generated in the password card, and the exported keys need to be encrypted by the password card device key. It reads and writes the local key object file repository and the local key object reference file directory, and provides a unified functional interface upward to facilitate the unified management of the lower-layer components by the password device key management system. The key management module assembles key objects in the Figure 3 format.

[0063] The local key object file repository is used to centrally store and retrieve key objects. It stores key object files: saving the actual content (in ciphertext form) of the encrypted keys generated by the password card. It can be associated with the metadata in the reference file directory tree through the key hash value to ensure fast retrieval.

[0064] The local disk, as a physical storage medium, bears all local data, including the reference file directory tree, the key object file repository, the cursor file, etc. It can ensure that the metadata and encrypted keys of the key management system can still be retained after the device power-off.

[0065] 2. The key backup central server is deployed on the remote side, including: the key object reference file directory tree, the central key object file repository, the KMS, and the central repository key synchronization service module;

[0066] The central key object file repository stores the key version directory and encrypted key files of all devices; it is bound to the reference file through the key hash value to ensure one-to-one correspondence between the metadata and the actual content. Each key object file is associated with a specific device and version. As the "central database" of the key content, it supports efficient storage and on-demand retrieval. Among them, the directory tree structure mirrors the local directory of the password device, and the root directory is / root; the key reference file is stored under each version directory and is associated with the key object file in the KMS through the hash value; it realizes redundant backup with the KMS to avoid single-point failure (for example, when the warehouse is damaged, the KMS can still provide key recovery).

[0067] The KMS (Key Management Service) provides compliant key storage and redundant backup with the central repository; the KMS is a security management service used to help users easily create, manage, and protect encryption keys, ensuring the confidentiality, integrity, and availability of the keys. It is widely used in cloud environments and enterprises to meet the key management needs of multiple applications and multiple services, and at the same time comply with regulatory and compliance requirements. In the present invention, it is used to assist in storing key objects to improve the reliability of key storage.

[0068] The Central Warehouse Key Synchronization Service Module receives and verifies the synchronization data from the cryptographic device and updates the content of the central warehouse. Its specific functions include: receiving the key reference file and key object from the local synchronization module of the cryptographic device and storing them in the central warehouse and KMS. Pushing data from the central warehouse to the device local according to the device request (such as restoring a specified version). Checking the integrity of the synchronization data (such as hash value matching). Rejecting illegal or tampered data (such as mismatch between the reference file and the key object). Detecting and marking version conflicts during multi-device parallel operations (such as two devices modifying the same version simultaneously). Ensuring the consistency of key data between the central warehouse and all cryptographic devices. As the "data bridge" between the central server and the cryptographic device, it guarantees the security and reliability of the synchronization process.

[0069] The directory tree of the key object reference file in the central warehouse is a tree-like directory structure implemented based on the operating system files. The key backup in the central server has / root as the root directory, the cloud cryptographic machine virtual machine has / local as the root directory, the second-level directory is named after the virtual machine serial number SN, the third-level directory is named after the version number, and the key object reference files are stored under the third-level directory.

[0070] The structure of the key object reference file is as Figure 2 shown. The key object reference file mainly stores the metadata information of the key, including the version number, key index, creation time, key HASH value. The key object file stores the actual content of the key. Referring to Figure 3 shown, it includes: key hash value and key. The key object files are uniformly stored in the key object warehouse for convenient unified management and retrieval. The key object reference file and the key object file establish a one-to-one correspondence through the key HASH value. The HASH value can uniquely identify a key. In addition, the key in the key object file is encrypted by the device key in the key card to ensure the confidentiality of the external storage of the key object.

[0071] The cryptographic device locally stores a directory tree of the key object reference file and a key object file warehouse. When the password on the cryptographic device changes, the key device pushes the local key object reference file directory tree and key object to the central warehouse in a timely manner. The local key synchronization service module periodically obtains all the current key information of the device and compares whether the key information at the current moment is the same as that at the previous moment, such as whether the number of keys is the same and whether the digest values of keys with the same index are the same. If they are different, it is considered that the keys on the device have changed. Or a new device needs to pull the specified version of the key object reference file directory tree and key object from the central warehouse to the local. A copy of the key object file in the central warehouse is also stored in the KMS. The KMS meets the security and compliance requirements, and storing a copy in the KMS improves the reliability of the static storage of the key.

[0072] The above password device communicates with the key backup central server through the network to achieve two-way synchronization of key version data, supports selecting multiple version keys for merging and recovery, and resolves index conflicts through hash comparison.

[0073] Refer to Figure 4 As shown, it is the overall process of key recovery:

[0074] Step 1. Trigger the recovery operation

[0075] The administrator initiates a recovery request through the key management system, or the system automatically detects the scenario that needs to be recovered (such as key loss, version rollback requirements).

[0076] Step 2. Select the target version

[0077] Specify the source version that needs to be recovered (such as v1.0, v2.0), and support multiple selections to achieve fusion recovery.

[0078] Step 3. Pull data from the central repository

[0079] When the above source version does not exist locally, the local synchronization module requests the central server to pull the key reference file directory tree and key objects of the corresponding version.

[0080] Step 4. Multi-version fusion processing

[0081] When multiple versions are selected, execute the version fusion algorithm to create a new key object directory tree after fusion; read and parse the key object reference file, refresh the password card, clean up the original key; load the key object into the password card, update the cursor file (soft link), and point to the new version directory.

[0082] And the key generation process is described as follows:

[0083] 1. Initially, the password device has no key and version. Operate the password device key management system to create a version. Taking Figure 1 as an example, create version "v1.0". The key management module creates a directory " / local / SN001 / v1.0" under the password device file system, and creates a cursor file in the " / local / SN001 / " directory, which is a soft link file pointing to " / local / SN001 / v1.0";

[0084] 2. Operate the password device key management system to select a certain version to create a key. Taking Figure 1 as an example, create key No. 1 under v1.0. The key management module creates a key object reference file " / local / SN001 / v1.0 / 1" under the password device file system. According to Figure 2The structure fills the key object reference file. The key management module calls the key card key management interface to generate Key No. 1 in the card. Key No. 1 is encrypted by the password card device key and returned to the key management module. The key management module creates a key object file, and the key object file is stored in the local key object file repository. At this time, a new key is added to the password device, and the local key synchronization service module on the password device automatically synchronizes the key object reference file and the key object file to the key backup central server;

[0085] 3. The central repository key synchronization service module of the key backup central server first checks whether there is a directory corresponding to the password device SN and version number. If not, it creates one first. After the directory is ready, it copies the key object reference file to the corresponding directory, and the key object is stored in the central key object file repository, and a copy is also stored in the KMS;

[0086] 4. If a large number of key changes need to be made at a certain time node, a new version v2.0 can be created, which is equivalent to archiving and marking the historical keys. Figure 1 For example, version v2.0 is created based on version v1.0, and Key No. 2 and Key No. 3 are created based on version 2.0; if you want to use the keys of version v1.0, you can select v1.0 as the base version, create version v2.0, and then create new keys under version v2.0. In this way, the keys of version V1.0 are natively included in version V2.0;

[0087] The process of multi-version key fusion during key recovery is referred to Figure 5 as shown below. The definitions of relevant symbols and the calculation process of the version fusion process are described as follows:

[0088] 1). V i : The set of keys of version V i , taking Figure 5 as an example

[0089] V1 = {1, 2, 3, 4}, V2 = {3, 4, 5, 6}, V3 = {4, 7, 8}

[0090] 2). U j : The j-th result of the set intersection, , n is the number of versions, is the number of groups. Taking Figure 5 as an example, when n = 3, , , , ,

[0091] Example: U1 = {3, 4}, U2 = {4}, U3 = {4};

[0092] 3), S: The union of all intersection results. When performing the union operation, for keys with the same index, check whether the HASH values of the keys with the same index in each version are the same. For example, for the key No. 3 in Figure 5 , both V1 and V2 have the key No. 3 with the same index. First, assume that the HASH values of these two keys No. 3 are different. Then these two keys No. 3 are two different keys and both need to be retained. The key No. 4 exists in V1, V2, and V3. First, assume that the HASH values are the same. Only one key No. 4 needs to be retained in the union. Taking Figure 5 as an example, , S = {3 v1 , 3 v2 , 4}

[0093] 4), Conflict resolution algorithm: 3 v1 and 3 v2 have the same index but different HASH values of the keys, so 3 v1 and 3 v2 have an index conflict and need to reassign indexes to resolve the conflict. Sort 3 v1、 3 v2 in ascending order of creation time. The key ranked first uses the original index. 3 v1 uses the index 3. Query the maximum value MAX of the currently used key indexes in the repository. The conflicting indexes are assigned starting from MAX + 1. Taking Figure 5 as an example, MAX is 8, and 3 v2 takes the index value 9. The union set after resolving the conflict is {3, 9, 4}.

[0094] 5), The non-conflicting set is {1, 2, 5, 6, 7, 8}. Incorporating it into the set after resolving the conflict gives the final set {1, 2, 3, 4, 5, 6, 7, 8, 9}, where 9 corresponds to 3 v2 .

[0095] 6), The finally merged set should correspond to a new version. The current maximum version number can be incremented by 1 or manually input. Taking the automatic increment by 1 as an example, the current maximum version is V3.0, and the version corresponding to the finally merged set is V4.0. First, create the version directory V4.0, create new directories and key object reference files according to the final set. Note that there should be no version conflicts when manually inputting. If there is a conflict, the system prompts to retry with another version.

[0096] 7), Load the keys of the set according to the final set. This process is completed by the key management module calling the cryptographic card management interface. The key object is first decrypted with the device key in the cryptographic card, and then the key is imported into the cryptographic card according to the index information;

[0097] 8), Update the cursor file to point to V4.0.

[0098] Next, the implementation process of the present invention will be described from three consecutive scenarios of key generation, key backup, and key recovery:

[0099] I. Key Generation

[0100] Referring to the content described in the above key generation process, it will not be elaborated here.

[0101] II. Key Backup

[0102] 1. The local key synchronization service module on the cryptographic device automatically detects whether the key on the cryptographic device has changed. When a change is detected, it actively pushes the local key object reference file directory tree and the key object to the key backup central server in a timely manner;

[0103] 2. It is also possible to operate the key management system of the cryptographic device for manual backup. Select the corresponding version to trigger the backup, and the local key synchronization service module pushes the local key object reference file directory tree and the key object file to the key backup central server;

[0104] III. Multi - version Key Recovery

[0105] Taking the cryptographic device SN001 as an example, there are currently two versions of backups, V1.0 and V2.0, in the current cloud cryptographic machine virtual machine SN001. Now, V1.0 and V2.0 need to be merged for recovery, and the execution process is as follows

[0106] 1. Create version V3.0, update the cursor file, and point it to version V3.0;

[0107] 2. Operate the key management system of the cloud cryptographic machine virtual machine, select the source versions V1.0 and V2.0, and the target version V3.0;

[0108] 3. Since two versions are selected, first execute the version fusion algorithm. V1.0 contains {key No. 1},

[0109] V2.0 contains {key No. 2, key No. 3}. There are no conflicts between V1.0 and V2.0, so they are directly merged. After merging, it is {key No. 1, key No. 2, key No. 3}. Create key object reference files for keys No. 1 to 3 in the version directory V3.0. There is time information in the key object reference file, and a new one needs to be created and filled with content according to the format;

[0110] 4. Push the local key object reference file directory tree to the key backup central server.

[0111] The key management system based on version management provided by the present invention supports managing key backups using version numbers, facilitating operation and maintenance management, sorting and statistics of password assets; and supports restoring using multiple versions of key backups to meet more key recovery scenarios; in addition, it also supports storing key backups on a central server, improving the reliability of key backup file storage.

[0112] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the various embodiments, reference can be made to each other. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and reference can be made to the description of the method part for related parts.

[0113] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be obvious to those skilled in the art. The general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to these embodiments shown herein, but will be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A key management system based on version management, characterized in that, It includes: A key backup central server and at least one cryptographic device, where the keys of the cryptographic device are centrally stored in the key backup central server; Among them, the cryptographic device is deployed on the user side and includes: A key card, which is used to generate keys with different version numbers according to the time baseline in a hardware security environment, and encrypt the keys with different version numbers through the device key; A local key synchronization service module, which is used to detect key changes and synchronize them to the central server; A cryptographic device key management system, which provides an interactive interface for administrators to create versions, generate keys, delete keys, recover keys, and trigger backup operations; A key management module, which is used for key generation and encryption, performs local storage management, and provides a unified interface service; A local key object file repository, which stores key object files and a reference file directory tree organized by version number; The key backup central server is deployed on the remote side and includes: A central key object file repository, which stores the key version directory of all devices and encrypted key files; KMS, which provides compliant key storage and redundant backup with the central repository; A central repository key synchronization service module, which receives and verifies the synchronization data from the cryptographic device and updates the content of the central repository; The cryptographic device communicates with the key backup central server through the network to achieve two-way synchronization of key version data, supports selecting multiple version keys for merge recovery, and resolves index conflicts through hash comparison.

2. The key management system based on version management according to claim 1, wherein, The reference file directory tree is organized in the following levels: The root directory is the device serial number; The subdirectory is the version number, and stores the key reference file corresponding to the version; The cursor file points to the current active version directory.

3. A key management system based on version management according to claim 1, characterized in that, In the central key object file repository: The directory tree structure is mirrored with the local directory of the cryptographic device, and the root directory is / root; Under each version directory, key reference files are stored and associated with the key object files in KMS through hash values.

4. A key management system based on version management according to claim 1, characterized in that, The working process of the local key synchronization service module includes: Periodically compare the hash values and quantities of the keys at the current moment and the previous moment; When a difference is detected, automatically push the newly added or modified key reference file directory tree and key objects to the key backup central server; Receive the synchronization instruction from the central server and pull the key reference file directory tree and key objects of the specified version to the local cryptographic device.

5. A key management system based on version management according to claim 1, characterized in that, The multiple version merge recovery process of the system includes: Create a new version directory on the cryptographic device side; Pull multiple historical version data from the central repository to the local cryptographic device; Merge the keys through a conflict resolution algorithm, generate the final key set and update the cursor file.

6. The key management system based on version management according to claim 5, characterized in that, The conflict resolution algorithm is specifically: Take the union of the intersection results of all versions, and compare the hash values of the same index keys in different versions; If the hash values are different, retain the key index of the earliest version and assign a new index to the conflicting key; the new index is MAX + 1, which is the maximum value of the currently used key index; If the hash values are the same, only retain one copy of the key.

Images