A key management system based on version management

Abstract

The present invention discloses a key management system based on version management, comprising: a cryptographic device and a key backup central server; the cryptographic device comprises: a key card, which is used to generate keys of different version numbers according to a time baseline in a hardware security environment, and encrypt the keys of different version numbers through a device key; a local key synchronization service module, which is used to detect key changes and synchronize them to a central server; a key backup central server, which stores the key version directory and encrypted key files of all devices; the cryptographic device and the key backup central server communicate via a 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. The present invention manages the key life cycle of the cryptographic device based on the version number, making the management work clearer; multiple version key backups can be used for fusion recovery to meet more key recovery scenarios.

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 cipher machines, encryption machines, SSL VPN gateways, IPSec VPN gateways, signature verification servers, financial data cipher machines, etc. Background Art

[0002] Keys are the key to protecting sensitive data in cryptographic information systems. Once lost, they may lead to irrecoverable data access rights. Therefore, the key lifecycle management process of cryptographic devices, such as key generation, update, destruction, backup and recovery, is extremely important.

[0003] Existing key lifecycle management is based on the granularity of a single key object. This management method essentially relies on manually recording the usage of each key on a device at a certain point in time and performing key backups based on that point in time. If there are update operations such as key deletion or generation, the key lifecycle status needs to be recorded again, resulting in duplicate key backups. This cumbersome management work also makes it impossible to merge key backups from two or more time points, and the device key can only be restored to its state at a certain point in time.

[0004] Therefore, the following questions arise:

[0005] Version tracing is difficult: key status cannot be marked according to timeline, and operation and maintenance are highly complex.

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

[0007] Inadequate conflict handling: There is a lack of automated solutions when multi-version key index conflicts occur. 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 version 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, comprising: a key backup central server and at least one cryptographic device, wherein the keys of the cryptographic device are centrally stored in the key backup central server;

[0011] The cryptographic device is deployed on the user side and includes:

[0012] The key card is used to generate keys of different versions according to the time baseline in the hardware security environment and encrypt the keys of different versions using the device key;

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

[0014] The cryptographic device key management system provides an interactive interface for administrators to create versions, generate keys, delete keys, restore keys, and trigger backup operations;

[0015] The key management module is used for key generation and encryption, local storage management, and unified interface services;

[0016] Local key object file repository, which stores key object files and reference file directory trees organized by version numbers;

[0017] The key backup central server is deployed on the remote side and includes:

[0018] Central key object file repository, storing key version directories and encryption key files for all devices;

[0019] KMS, which provides compliant key storage and redundant backup with the central warehouse;

[0020] The central warehouse key synchronization service module receives and verifies the synchronization data from the cryptographic device and updates the central warehouse content;

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

[0022] Furthermore, the reference file directory tree is organized in the following levels:

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

[0024] The subdirectory is the version number, which stores the key reference file of the corresponding version;

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

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

[0027] The directory tree structure corresponds to the local directory mirror of the cryptographic device, with the root directory being / root;

[0028] The key reference file is stored in each version directory and is associated with the key object file in KMS through a hash value.

[0029] Furthermore, the workflow of the local key synchronization service module includes:

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

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

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

[0033] Furthermore, the system's multiple version merging and recovery process includes:

[0034] Create a new version directory on the password device side;

[0035] Pull multiple historical versions of data from the central warehouse to the local password device;

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

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

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

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

[0040] If the hash values ​​are the same, only one key is retained.

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

[0042] The present invention uses the timeline as the baseline, treating all key objects on a cryptographic device at a certain point in time as a version. Different time points correspond to different versions. The key lifecycle of the cryptographic device is managed based on the version number, making management 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 versions of key backups can be used for integrated recovery to meet more key recovery scenarios.

[0045] 3. High reliability: Supports automatic backup and ensures key security through dual storage in KMS and central warehouse.

[0046] 4. Automated conflict handling: Reduce manual intervention and ensure data consistency. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0048] Figure 1 This is a schematic diagram of the structure of the key management system based on version management provided by the present invention.

[0049] Figure 2 This is a schematic diagram of the key object reference file structure provided by the present invention.

[0050] Figure 3 This is a schematic diagram of the key object file structure provided by the present invention.

[0051] Figure 4 This is the overall flow chart of key recovery provided by the present invention.

[0052] Figure 5 This is a schematic diagram of the multi-version key fusion processing process provided by the present invention. DETAILED DESCRIPTION

[0053] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

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

[0055] 1. Password device, deployed on the user side, including password device key management system, local key synchronization service module, key management module, password card key management interface, local key object reference file directory tree, password card, local password object file warehouse, local disk,

[0056] The cryptographic device key management system provides interactive capabilities. Administrators 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 synchronization instructions from the cryptographic device key management system, communicates with the central repository key synchronization service module to synchronize the device's local key object reference file directory tree and key objects to the key backup central server. Specifically, this module automatically detects changes, periodically scans the local key repository, and compares the current key status with the previous version (e.g., changes in key quantity and hash values). When changes occur, further data synchronization is implemented:

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

[0059] The password card provides key operation capabilities. The key needs to be loaded into the key card and used in the form of an index number. For example, key number 1 is used 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. These operations are implemented through the password card key management interface.

[0060] The Password Card Key Management Interface allows you to call the Password Card to generate a raw key. This raw key is encrypted using the device key built into the Password Card to generate a key object file that can be stored externally. Additionally, you can call the decrypted key from the Password Card based on an index number (e.g., "Key 1") for encryption / decryption operations. The Password Card Key Management Interface is a software implementation of the Key Card's key management capabilities, and is used by the local key synchronization service module and key management module.

[0061] The local key object references the file directory tree, which stores the key reference information in a tree directory structure (such as / local / SN001 / v1.0 / 1). Figure 2 As shown, this includes: version number, key hash value (unique fingerprint), key index number, SN of the cloud cryptographic machine virtual machine, and key creation time. Key reference files of different versions are stored in separate directories (e.g., v1.0, v2.0) to avoid confusion. Additionally, soft links (e.g., current → v2.0) can be used to point to the currently active version. This refers to the hierarchical organization of the reference file directory tree, with the root directory containing the device serial number; subdirectories containing version numbers storing key reference files of corresponding versions; and a cursor file pointing to the currently active version directory.

[0062] The key management module is a link between the upper and lower levels. It calls the password card key management interface of the key card to generate the key in the key card, export the key generated in the password card, and encrypt the exported key with the password card device key. It reads and writes the local key object file repository and the local key object reference file directory. It provides a unified functional interface to facilitate the unified management of the lower-level components by the password device key management system. The key management module is based on Figure 3 Format assembled key object.

[0063] A local key object file repository, used for centralized storage and retrieval of key objects. Key object files store the actual encrypted key contents (in ciphertext) generated by the Password Card. Key hash values ​​can be linked to metadata in the reference file directory tree to ensure fast retrieval.

[0064] The local disk, as the physical storage medium, carries all local data, including the reference file directory tree, key object file repository, cursor files, etc. It ensures that the metadata and encryption keys of the key management system are retained even after the device is powered off.

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

[0066] The central key object file repository stores key version directories and encryption key files for all devices. Key hash values ​​are bound to reference files to ensure a one-to-one correspondence between metadata and actual content. Each key object file is associated with a specific device and version. As a "central database" for key content, it supports efficient storage and on-demand retrieval. The directory tree structure mirrors the local directory of the cryptographic device, with the root directory being / root. Key reference files are stored in each version directory and are linked to key object files in the KMS via hash values. Redundant backup with the KMS is implemented to avoid single points of failure (e.g., if the repository is damaged, the KMS can still provide key recovery).

[0067] KMS (Key Management Service) provides compliant key storage and redundant backup with a central repository. KMS is a security management service that helps users easily create, manage, and protect encryption keys, ensuring their confidentiality, integrity, and availability. It is widely used in cloud environments and within enterprises, meeting the key management needs of multiple applications and businesses while complying with regulatory and compliance requirements. In this invention, it is used to assist in the storage of key objects and improve the reliability of key storage.

[0068] The central repository key synchronization service module receives and verifies synchronization data from cryptographic devices and updates the central repository content. Specific functions include: receiving key reference files and key objects from the local synchronization modules of cryptographic devices and storing them in the central repository and KMS. Based on device requests (such as restoring a specified version), data is pushed from the central repository to the local device. The module checks the integrity of synchronized data (such as hash value matching). It rejects illegal or tampered data (such as mismatches between reference files and key objects). When multiple devices operate in parallel, it detects and marks version conflicts (such as two devices modifying the same version simultaneously). This ensures key data consistency between the central repository and all cryptographic devices. Acting as a "data bridge" between the central server and cryptographic devices, it ensures a secure and reliable synchronization process.

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

[0070] The key object reference file structure is as follows Figure 2 As shown, the key object reference file mainly stores the metadata information of the key, including version number, key index, creation time, key HASH value, and the key object file stores the actual content of the key. Figure 3 As shown, it includes: key hash value and key; key object files are uniformly stored in the key object warehouse to facilitate unified management and retrieval, and a one-to-one correspondence is established between the key object reference file and the key object file 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 key object's external storage.

[0071] The cryptographic device locally stores a key object reference file directory tree and a key object file warehouse. When the password on the cryptographic device changes, the key device promptly pushes the local key object reference file directory tree and key object to the central warehouse. 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 consistent with that at the previous moment, such as whether the number of keys is the same, and whether the summary value of the same index key is the same. If not, it is considered that the key on the device has 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 KMS. KMS meets security compliance requirements. Storing a copy in KMS improves the reliability of static key storage.

[0072] The above-mentioned cryptographic devices communicate 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.

[0073] Reference Figure 4 As shown below, the overall process of key recovery is as follows:

[0074] Step 1. Trigger the recovery operation

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

[0076] Step 2. Select the target version

[0077] Specify the source version to be restored (such as v1.0, v2.0). Multiple selections are supported to achieve integrated recovery.

[0078] Step 3. Pull central warehouse data

[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 object of the corresponding version.

[0080] Step 4. Multi-version fusion processing

[0081] When multiple versions are selected, the version fusion algorithm is executed to create a new key object directory tree after fusion; the key object reference file is read and parsed, the password card is refreshed, and the original key is cleared; the key object is loaded into the password card, and the cursor file (soft link) is updated to point to the new version directory.

[0082] The key generation process is described as follows:

[0083] 1. The password device initially has no key and version. The password device key management system creates a version. Figure 1 For example, to create version "v1.0", the key management module creates the " / local / SN001 / v1.0" directory in the cryptographic device file system and creates a cursor file in the " / local / SN001 / " directory. This is a soft link file pointing to " / local / SN001 / v1.0".

[0084] 2. Operate the password device key management system and select a version to create a key. Figure 1 For 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. Figure 2The structure is filled with 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 with the cryptographic card device key and returned to the key management module. The key management module creates a key object file, which is stored in the local key object file repository. At this point, a new key is added to the cryptographic device. The local key synchronization service module on the cryptographic device automatically synchronizes the key object reference file and the key object file to the key backup central server.

[0085] 3. The central warehouse 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 it does not exist, it will be created first. After the directory is ready, the key object reference file is copied to the corresponding directory. The key object is stored in the central key object file warehouse and a copy is also stored in the KMS.

[0086] 4. If a large number of key changes are required at a certain time point, 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 keys 2 and 3 are created based on version 2.0. If you want to use the key of version v1.0, you can select v1.0 as the base version, create version v2.0, and then create a new key under version v2.0. In this way, version V2.0 will natively have the key of version V1.0.

[0087] Reference for multi-version key fusion processing during key recovery Figure 5 As shown, the symbol definitions and calculation process of the version fusion process are described as follows:

[0088] 1) V i :V i The key set of the version Figure 5 For example

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

[0090] 2) U j : The jth result of set intersection, ,n is the number of versions, is the number of groups, Figure 5 For 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, such as Figure 5 Key 3 in V1 and V2 has key 3, the index is the same. Let's assume that the HASH values ​​of these two keys 3 are different, then these two keys 3 are two different keys, and both of them need to be retained. Key 4 exists in V1, V2, and V3. Let's assume that the HASH values ​​are the same, and only one key 4 needs to be retained in the union. Figure 5 For example, ,S={3 v1 ,3 v2 ,4}

[0093] 4) Conflict resolution algorithm: 3 v1 and 3 v2 The index is the same, but the HASH value of the key is different. v1 and 3 v2 An index conflict has occurred and the index needs to be reallocated to resolve the conflict. v1、 3 v2 Sort by creation time from earliest to latest, the first key uses the original index, 3 v1 Use index 3 to query the maximum value MAX of the key index currently used in the warehouse. Conflicting indexes are assigned starting from MAX+1. Figure 5 For example, MAX is 8,3 v2 Then take index value 9, and the union set after resolving the conflict is {3,9,4}.

[0094] 5) The non-conflicting set is {1, 2, 5, 6, 7, 8}, which is merged into the conflict-resolved set to get the final set {1, 2, 3, 4, 5, 6, 7, 8, 9}, where 9 corresponds to 3. v2 .

[0095] 6) The final merged set should correspond to a new version. You can use the current maximum version number incremented by 1 or manual input. Taking automatic increment by 1 as an example, the current maximum version is V3.0, and the final merged set corresponds to version V4.0. First create version directory V4.0, and create a new directory and key object reference file based on the final set. Be careful not to have version conflicts when manually inputting. If there is a conflict, the system prompts you to try again with another version.

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

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

[0098] The following describes the implementation process of the present invention from three consecutive scenarios: key generation, key backup, and key recovery:

[0099] 1. Key Generation

[0100] Please refer to the above description of the key generation process and will not be repeated here.

[0101] 2. 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 proactively pushes the local key object reference file directory tree and key object to the key backup central server in a timely manner;

[0103] 2. You can also operate the cryptographic device key management system to perform manual backup, select the corresponding version to trigger the backup, and the local key synchronization service module will push the local key object reference file directory tree and key object file to the key backup central server;

[0104] 3. Multi-version key recovery

[0105] Taking the cryptographic device SN001 as an example, there are currently two versions of backup for the cloud cryptographic machine virtual machine SN001, V1.0 and V2.0. Now we need to merge V1.0 and V2.0 for recovery. The execution process is as follows

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

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

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

[0109] V2.0 contains {Key 2, Key 3}. V1.0 and V2.0 do not conflict and are directly merged. The merged version is {Key 1, Key 2, Key 3}. Create key object reference files for keys 1 to 3 in version directory V3.0. The key object reference files contain time information. Create new ones and fill in the content according to the format.

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

[0111] The version management-based key management system provided by the present invention supports the use of version numbers to manage key backups, facilitating operation and maintenance management, and the organization and statistics of cryptographic assets; and supports the use of multiple versions of key backups for recovery, meeting more key recovery scenarios; in addition, it also supports the storage of 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, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

[0113] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present invention. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not limited to the embodiments shown herein but is intended to conform to 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: include: A key backup central server and at least one cryptographic device, wherein the key of the cryptographic device is centrally stored on the key backup central server; The cryptographic device is deployed on the user side and includes: The key card is used to generate keys of different versions according to the time baseline in the hardware security environment, and encrypt the keys of different versions using the device key built into the key card; Local key synchronization service module, used to detect key changes and synchronize them to the central server; The cryptographic device key management system provides an interactive interface for administrators to create versions, generate keys, delete keys, restore keys, and trigger backup operations; The key management module is used to call the key card key management interface of the key card to generate the key in the key card, read and write the local key object file repository, and provide a unified functional interface to the cryptographic device key management system; A local key object file repository stores key object files and a reference file directory tree organized by version number; the key object files include a key hash value and an encrypted key; the reference file directory tree includes key reference files of different versions; the key reference files include a version number, a key index, and a key hash value, and are associated with the key object files through the hash value; The key backup central server is deployed on the remote side and includes: Central key object file repository, which stores the reference file directory tree and key object files of all cryptographic devices; KMS, which provides compliant key storage and redundant backup with the central key object file repository; The central repository key synchronization service module receives and verifies synchronization data from cryptographic devices and updates the content of the central key object file repository; The cryptographic device communicates with the key backup central server through the network to achieve two-way synchronization of key version data; the cryptographic device supports the selection of multiple version keys for merge recovery, and resolves index conflicts locally by comparing the hash values ​​of keys with the same index in different versions.

2. A key management system based on version management according to claim 1, characterized in that: The reference file directory tree stored in the local key object file repository is organized in the following hierarchy: The root directory is the device serial number; The subdirectory is the version number, which stores the key reference file of the corresponding version; The cursor file points to the currently 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 reference file directory tree mirrors the local reference file directory tree of the password device, and the root directory is / root; The key reference file is stored in each version directory and is associated with the key object file in KMS through a hash value.

4. A key management system based on version management according to claim 1, characterized in that: The workflow of the local key synchronization service module includes: Periodically compare the hash value and quantity of the current key with the previous key; When a difference is detected, the newly added or modified reference file directory tree and key object file are automatically pushed to the key backup central server; Receive synchronization instructions from the central server and pull the specified version of the reference file directory tree and key object file to the local cryptographic device.

5. A key management system based on version management according to claim 2, characterized in that: The system's multiple version merging and recovery process includes: Create a new version directory on the password device; Pull multiple historical versions of data from the central key object file repository to the local cryptographic device; The keys are merged through a conflict resolution algorithm to generate a final key set and update the cursor file. Specifically, the union of the intersection results of all versions is taken, and the hash values ​​of the same index key in different versions are compared. If the hash values ​​are different, the key index of the earliest version is retained and a new index is assigned to the conflicting key. The new index is the maximum value MAX+1 of the currently used key index. If the hash values ​​are the same, only one key is retained.

Images