CN112800439B - Key management protocol design method and system for secure storage - Google Patents
Key management protocol design method and system for secure storage Download PDFInfo
- Publication number
- CN112800439B CN112800439B CN202011392351.3A CN202011392351A CN112800439B CN 112800439 B CN112800439 B CN 112800439B CN 202011392351 A CN202011392351 A CN 202011392351A CN 112800439 B CN112800439 B CN 112800439B
- Authority
- CN
- China
- Prior art keywords
- key
- storage
- encryption
- password
- management
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/45—Structures or tools for the administration of authentication
- G06F21/46—Structures or tools for the administration of authentication by designing passwords or checking the strength of passwords
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Storage Device Security (AREA)
Abstract
The invention discloses a method and a system for designing a key management protocol facing safe storage, wherein the method comprises the following steps: constructing a key request message through a key management client and sending the key request message to a key management center, receiving and analyzing a response message of the key management center, and providing a processing result of the request message for an application program; when the key management client side obtains the key, the key is loaded into the password card to realize password operation; providing centralized password management through a key management center, providing services including key registration, inquiry and revocation, partitioning, configuring and managing a key resource pool, and providing administrator access, log recording and audit trail; and respectively generating and storing the key by a key generator and a key storage center in the key resource pool. The invention can ensure the safety of the whole life cycle of key generation, distribution, storage, update and destruction in the storage environment.
Description
Technical Field
The invention relates to the technical field of key management, in particular to a method and a system for designing a key management protocol for secure storage.
Background
Cloud computing and big data are emerging, data storage is rapidly developed, but related security problems are not well solved. The core of storage security is to protect the confidentiality and integrity of data information in the storage process by using a modern cryptographic algorithm and provide good availability guarantee for user application, the current mainstream cryptographic algorithm is mainly based on a secret key, the security of the secret key is the premise and the basis of guaranteeing the data security, and the key management also becomes the core of storage security. Therefore, the design of the key management protocol is particularly important, and the security and the efficiency of the key management protocol are related to the security and the performance of the whole storage system.
At present, the same or similar technical fields disclose the following patents:
"distributed storage system and data processing method thereof" (patent application No. CN201910020649.2) discloses: the client acquires data and key information corresponding to the write operation; the client encrypts data corresponding to the write operation based on the key information to obtain encrypted data; and the client sends the encrypted data to the data storage node. The method solves the technical problems that a data processing method of a distributed storage system in the related art is low in processing efficiency and large in occupied memory.
"method and apparatus for key data management" (patent application No. CN202010111906.6) discloses: collecting key information of a user in a first door lock; encrypting the key information by adopting an encryption algorithm in the first door lock to generate an encryption key data packet, and sending the encryption key data packet to a mobile phone key APP in a wireless mode, wherein the mobile phone key APP stores the encryption key data packet locally and generates a decryption key corresponding to the encryption key data packet; the mobile phone key APP sends the encryption key data packet to a second door lock in a wireless mode; and inputting a decryption key corresponding to the encryption key data packet into the second door lock for decryption, and storing decrypted key information in the second door lock.
A quantum three-level key system realization method and a system (patent application number: CN201811606589.4) relate to the technical field of quantum communication, and the technical scheme is as follows: comprising a cryptographic device for managing tertiary keys, said tertiary keys being respectively: a master key, a key encryption key and a quantum key; wherein the master key is used as a primary key; the key encryption key is used as a secondary key; the quantum key serves as a tertiary key. The method solves the potential safety hazard of the session key generated based on the algorithm in the traditional three-level key system, solves the potential safety hazard of quantum key storage in the quantum key system, simultaneously removes the requirement of symmetry of the key encryption keys at two ends, and reduces the complexity of updating the key encryption keys.
Disclosure of Invention
The invention provides a method and a system for designing a key management protocol facing safe storage, which take the key management application requirement of the safe storage as traction, design a high-safety, high-reliability and extensible key management protocol cluster, construct a key management system to ensure the full life cycle safety of keys in a safe storage environment, and can effectively meet the requirements of safety, high efficiency and the like.
The invention relates to a key management protocol design method facing safe storage, which comprises the following steps:
constructing a key request message through a key management client and sending the key request message to a key management center, receiving and analyzing a response message of the key management center, and providing a processing result of the request message for an application program; when the key management client side obtains the key, the key is loaded into the password card to realize password operation;
providing centralized password management through the key management center, providing services including key registration, inquiry and revocation, partitioning, configuring and managing a key resource pool, and providing administrator access, log recording and audit trail;
generating and storing keys respectively by a key generator and a key storage center in the key resource pool, wherein the key generator generates the keys by adopting a quantum noise source, and the key storage center is formed by a cluster of hardware security modules; the hardware security module can be used as a trust root of the whole encryption infrastructure and can be divided into a plurality of encryption isolated partitions, and each partition can be used as a trust root for independently protecting the whole life cycle of a plurality of independent keys.
Further, the key management protocol design method further includes a key exchange subprotocol:
when a user opens the user interface of the key management client, or the key management client does not have any data interaction with the server within the past set time, the key agreement is triggered; and the key management client and the key management center use respective private keys and the public key of the other side to agree a key encryption key based on an elliptic curve public key cryptographic algorithm.
Further, after the key encryption key is started to the set time, if the link does not transmit data, the key encryption key is updated; when the key storage center at local and different places backs up the key, the key exchange subprotocol can be adopted to generate the key encryption key for link encryption protection.
Further, the key management protocol design method further includes a key agreement subprotocol:
selecting quantum key distribution to perform key agreement on the key encryption key; the single photon quantum key distribution system adopts BB84 protocol and Cascade coordination algorithm to realize unconditional safe key negotiation between two points; the continuous variable quantum key distribution system adopts GG02 protocol and LDPC negotiation algorithm to realize unconditional secure key negotiation between two points.
Further, the key management protocol design method further includes a key generation subprotocol:
the method comprises the following steps that a main secret key is generated by injecting a secret key in a manual off-line mode, and the main secret key is mainly used for carrying out encryption protection on a secret key encryption secret key and a data encryption secret key; a key encryption key is generated by a security algorithm under the control of the master key; the generation of the data encryption key comprises: when the logical volume is created, the key management client receives a data encryption key request message sent by the block storage client, and sends a key generation application to the key management center to generate a data encryption key.
Further, the key management protocol design method further includes a key distribution subprotocol:
when the logic volume carries out read-write operation, the key management client applies for obtaining a key from the key management center; when the key management center receives a large amount of data encryption key applications initiated by the key management client at the same time, a request/response message queue is established, and priority access and delayed access of key distribution are solved; the key management center judges the user grade intensity; in the same thread, the lower the security and reliability strength is, the higher the priority is, the prior to obtaining a transmission opportunity (TXOP) of key distribution, wherein the TXOP represents the time interval of data encryption key distribution transmission of the key management client and satisfies the following conditions:
TXOP=CWmax-CWmin
wherein CWmaxThe maximum competition window represents the maximum time threshold for the key management client to wait for key distribution; CWminThe minimum competition window represents the minimum time threshold for the key management client to wait for key distribution; the higher the priority, CWminThe smaller the value; the lower the priority, the larger the TXOP value, CWmaxThe larger the value.
Further, the key management protocol design method further includes a key storage subprotocol:
the data encryption key is generated and stored in the key resource pool and stored in a plurality of local and allopatric key storage centers; and after the key storage center receives a data encryption key or component generation response sent by the key management center, the key storage center generates and stores a key and sends a data encryption key or component storage request to the key storage center at a local place and a remote place.
Further, the key management protocol design method further includes a key exchange subprotocol:
according to a secret management method for data safe storage, a data encryption key is replaced regularly to generate a new key component, and key updating is driven by user requirements; the key storage center needs to send the original key component to the key management center first and then send the new key component.
Further, the key management protocol design method further includes a key destruction sub-protocol:
the block storage client side completes data deletion or applies for destroying a key before zero filling so that the data can not be recovered; after the key is successfully replaced, starting a destroying process for the original key or the component stored in the key resource pool; if the key management client requests to replace the key, the key management center inquires the position of an original key or a component stored in the key storage center according to a storage linked list, only erases the original key or the component stored in the key storage center at local and different places, and does not execute data deletion or zero padding operation; and if the key storage center responds successfully, erasing the original key.
Further, the key generation in the key management protocol design method includes the following processes:
importing an original password resource: the original password resource comprises a prefabricated secret key, algorithm logic, algorithm parameters and password software; the facility key management equipment carries out encryption protection on the plain-state original password resource to form a secret-state original password resource, and then leads the secret-state resource into the original password resource and leads the secret-state resource into the management server in an off-line/on-line mode;
encryption, conversion and storage of original password resources: after the password resource is imported, the original password resource import management server calls a password resource encryption conversion server interface to carry out encryption conversion and necessary fragmentation and encryption encapsulation processing on the password resource, so that basic password resource data are stored in a centralized mode, and a data directory is issued to a password resource directory server in real time;
original password resource distribution: the password management node applies for original password resources from the key resource pool, the resource pool pushes the corresponding password resources to a database server of the password management node, and the password management comprehensive service server extracts the password resources as required.
The invention relates to a key management system facing safe storage, which comprises:
the key management client is adapted to the storage terminal in the form of application software, is responsible for constructing a key request message and sending the key request message to the key management center, receives and analyzes a response message of the key management center, and provides a processing result of the request message for an application program; when the key management client side obtains the key, the key is loaded into the password card to realize password operation;
the key management center provides centralized password management in the form of hardware equipment, provides services including key registration, inquiry and revocation, partitions, configures and manages a key resource pool, and provides administrator access, log recording and audit tracking;
the key resource pool mainly comprises a key generator and a key storage center, wherein the key generator generates a key by adopting a quantum noise source, and the key storage center consists of a cluster of hardware security modules; the hardware security module can be used as a trust root of the whole encryption infrastructure and can be divided into a plurality of encryption isolated partitions, and each partition can be used as a trust root for independently protecting the whole life cycle of a plurality of independent keys.
Further, the key management client is deployed on each storage device, the key management center is connected with the secure storage device through an IP/FC network, and the key resource pool is built according to a two-place multi-center architecture, i.e., a plurality of local and off-site key storage centers.
The invention has the beneficial effects that:
the invention can ensure the safety of the whole life cycle of key generation, distribution, storage, update and destruction in the storage environment; the key management technology based on the similar homomorphism not only protects the privacy security of users, but also effectively reduces the maintenance cost of a key management center and the loss caused by key leakage; the key agreement technology related to the key encryption key has strictly proven security, and ensures the absolutely secure shared key between remote entities; the random generation of the key meets the characteristics of high speed, true randomness and the like, and the key generation efficiency of the key management system is effectively improved.
According to the key management system for the secure storage, which is constructed by the invention, the key requirements of more than 1000 clients can be supported in parallel through practical test verification, the generation rate of random numbers required by key generation is not lower than 500MB/s, the processing capacity of a symmetric encryption algorithm of more than 20Gbps can be provided, and the real-time key distribution of 100KB/s of a 50-kilometer optical fiber line can be met.
Compared with the prior art, the invention has the advantages that:
compared with CN201910020649.2, the invention is not limited to the management of data encryption key, but provides a systematic key management protocol cluster of main key, key encryption key and data encryption key facing safe storage application environment based on three-level key, and designs protocol message format and protocol message flow in detail;
compared with CN202010111906.6, the invention adopts the key management technology based on the similar homomorphism, which not only protects the privacy security of the user, but also effectively reduces the maintenance cost of the key management center and the loss caused by key leakage;
compared with CN201811606589.4, the invention provides a management scheme facing to the whole process of the key, which can effectively ensure the safety of the whole life cycle of key generation, distribution, storage, update and destruction in the storage environment.
Drawings
FIG. 1 is a key management client function block assembly;
FIG. 2 is a block diagram of a key management center;
FIG. 3 is a secure storage oriented key management system deployment;
FIG. 4 is a secure storage oriented key management system composition;
FIG. 5 is a secure storage oriented key management protocol cluster;
FIG. 6 KEK Key exchange subprotocol flow;
FIG. 7 DEK Key Generation subprotocol flow;
FIG. 8 is a timing diagram of a co-thread key distribution response;
FIG. 9 DEK Key distribution subprotocol flow;
FIG. 10 DEK Key storage subprotocol flow;
FIG. 11 DEK rekeying subprotocol flow;
FIG. 12 DEK Key destruction subprotocol flow;
fig. 13 shows a key generation management flow.
Detailed Description
In order to more clearly understand the technical features, objects, and effects of the present invention, specific embodiments of the present invention will now be described. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments of the present invention without making any creative effort, shall fall within the protection scope of the present invention.
The embodiment provides a method and a system for designing a key management protocol for secure storage, which are specifically as follows.
1. System architecture
The key management system facing the secure storage is composed of a key management client (KC), a Key Management Center (KMC) and a Key Resource Pool (KRP).
(1) Key management client
The key management client is adapted to the storage terminal in the form of application software, and is responsible for constructing a key request message, sending the key request message to the key management center, receiving and analyzing a response message of the key management center, and providing a processing result of the request message for an application program. And when the key management client side obtains the key, loading the key into the password card to realize password operation. The functional module composition of the key management client is shown in figure 1.
(2) Key management center
The key management center provides centralized password management in the form of hardware equipment, provides services such as key registration, inquiry, revocation and the like, partitions, configures and manages a key resource pool, and provides administrator access, log recording, audit trail and the like. The functional module composition of the key management center is shown in figure 2.
(3) Key resource pool
The key resource pool is composed of a key generator and a Key Storage Center (KSC). The key generator generates a key using a quantum noise source. The KSC consists of a cluster of dedicated hardware security modules that can act as a root of trust for the entire cryptographic infrastructure. The hardware security module can be divided into a plurality of encrypted and isolated partitions, and each partition can be used as a trust root for independently protecting the full life cycle of a plurality of independent keys, so that great expansion performance and flexibility are provided.
2. Key management system deployment
A secure storage oriented key management system implementation deployment diagram is shown in fig. 3. The key management client is deployed on each storage device, the key management center is connected with the safe storage device through an IP/FC network, and the key resource pool is built according to a two-place multi-center (namely a plurality of key storage centers at local and different places) architecture. The key management system oriented to the secure storage is shown in figure 4.
The key management client: 3, 1 encryption card is embedded into each storage terminal, self-calling program is executed for data encryption and decryption, and a large amount of data of the storage terminals are encrypted and decrypted.
The key management server side: the 1 host computer is used as a key management center, bears the key management and control function, and constructs a database to record a data encryption key storage address.
Key management back end: and 3 key storage servers store data encryption keys according to the 'two places and three centers'.
3. Kind of key
(1) Master Key (MK)
The key management center, each secure storage device and each hardware security module of the key storage of the key resource pool are injected into the MK in an artificial off-line mode, the MK is based on a public key system and comprises a Public Key (PK) and a Secret Key (SK), and the MK is mainly used for carrying out encryption protection on a key encryption key and a data encryption key.
(2) Key encryption key (KEK, named transmission encryption key)
The KEK is used for protecting keys used when the KMC and the KRP and the KMC and the KC transmit the DEK, and is replaced at any time based on a symmetric key system without storage. The KEK negotiation methods mainly include two types: one is a key exchange scheme, two parties carry out KEK negotiation according to a certain time period, and the KEK is kept constant in the time period; the other is to negotiate the KEK through the QKD continuously and confirm the KEK used by the two parties at the current moment based on the serial number mode. In this embodiment, the key exchange subprotocol and Quantum Key Distribution (QKD) key agreement subprotocol are used for the KEK negotiation.
(3) Data encryption key (DEK, rename store encryption key)
The data encryption key is a key for encrypting and protecting the stored data, is generated by a key generator of the KRP based on a symmetric key system, and is stored by a hardware security module of the KRP. The data encryption key can be encrypted in a similar manner to realize the secret synthesis of the DEK, and can also be stored in the storage device in a short time after being encrypted by the PK.
4. Key management protocol message composition
The key management protocol standardizes the message interaction flow and the message composition format of the key management system. By using a unified management protocol among the key client, the key management center and the key storage center, the problem of interoperation among the three is solved. The elements included in the key management message specifically include: protocol identification field, message length, key subprotocol, initiator, security object, object-oriented operation, object attribute and content field.
The key management protocol belongs to an application layer protocol in a network protocol.
(1) Protocol message format
The key management message format is divided into a header field and a content field, and header information is not encrypted at the time of communication between the key management client and the key management server. The message content field is encrypted using the KEK. The message format, message header and message content are shown in tables 1-3, respectively.
Table 1 key management protocol message format
Table 2 key management protocol message header
Description of field | Field length (Bytes) | Parameter(s) | Parameter Length (Bytes) | Separator symbol | Optionally |
Identifier: | 11 | Key management:0x11 | 19 | \r\n | NO |
Context Len: | 12 | 4 | \r\n | NO | |
SubProtocol: | 12 | 1~6 | 4 | \r\n | NO |
Who: | 4 | 1~3 | 4 | \r\n\r\n | NO |
Table 3 key management protocol message content
(2) Description of field
The specific contents of the key management protocol identification field (Identifier) are shown in table 4.
Table 4 key management protocol identification field contents
Parameter value | Description of parameters |
Key management:0x11 | For key management protocol identification, 0x11 is protocol version number identification |
The specific content of the message length field (Context Len) is shown in table 5.
Table 5 message length field contents
Parameter(s) | Description of parameters |
Length of | Indicating the length of the message content field. No message header field is included. |
The specific contents of the key management SubProtocol field (SubProtocol) are shown in table 6.
Table 6 key management subprotocol field contents
Parameter(s) | Description of |
1 | |
2 | |
3 | |
4 | Key storage subprotocol |
5 | Key exchange subprotocol |
The details of the message sender field (Who) are shown in Table 7.
Table 7 message sender field contents
Parameter(s) | Description of |
1 | Messages sent by |
2 | Messages sent by |
3 | Messages sent by KSC |
The security Object element field (Object) contains all security objects transmitted by the key management system, such as symmetric keys, public keys, secret keys, shared secrets, etc. The details are shown in table 8.
Table 8 secure object element field contents
Parameter(s) | Description of parameters |
Policy Template | Correlation policy attributes |
Private Key | Secret part in asymmetric key pair |
Public Key | Public part of asymmetric key pair |
Secret Data | Shared secret |
Split Key | Key component |
Symmetric Key | Symmetric encryption key or message authentication code key |
Template | Element list |
An Action field (Action) represents an operation performed on the object. The operation type is changed according to the type of the object, and is also related to the subject of the operation. The specific contents of operations initiated by KC to KMC, KMC to KSC, KSC to other KSC are shown in table 9.
TABLE 9 operation field Contents (part 1)
The KMC initiates an operation to KC as shown in the detailed table 10.
Table 10 operation field content (part 2)
Parameter(s) | Description of parameters |
Notify | Notification key client |
Put | Pushing key objects to key clients |
5. Key management protocol cluster
The key management protocol cluster for secure storage is shown in fig. 5.
(1) Key exchange subprotocol
The key agreement is triggered when the user opens the client UI or the client has not had any data interaction with the server within a set time (e.g. 2 hours) in the past. The KC and the KMC use respective private keys and the public key of the other party to agree the KEK based on an elliptic curve public key cryptographic algorithm. The KEK is klen in length. The specific interaction flow is shown in fig. 6 and table 11.
Table 11 detailed flow explanation of key exchange subprotocol
Step a1 (KC):
the KEK timeout management thread is started. The KEK is updated every 2 hours, and the KEK key exchange request is reinitiated.
Step a2(KC → KMC):
and creating Socket connection and connecting the Socket connection with the key management center.
Step a3 (KMC):
calculating KKMC=KDF(xV||yV||ZKC||ZKMCKlen), KDF () is a key derivation function, ZKCIs the hash value of the distinguishable identification of KC, partial elliptic curve system parameters and KC public key, ZKMCIs a hash value of the KMC, the partial elliptic curve system parameter and the KC public key.
R is to beKCCoordinate x of1Y1 and RKMCCoordinate x of2、y2Class of dataConverting the pattern into a bit string, calculating SKMC=Hash(0x02||yV|||Hash(xV||ZKC||ZKMC||x1||y1||x2||y2))。
Step a4(KMC → KC):
verification passes, and R isKMC,SKMCSending the data to KC; if the authentication fails, a key agreement response (failure) is sent to the KC, and the authentication failure reason (failure to establish a link or authentication unsatisfied condition) is noted.
Step a5 (KC):
calculating elliptic curve point U ═ h.tKC](PKKMC+x1RKMC)=(xU,yU) If U is an infinite point, KC judges that the negotiation fails; otherwise will xU、yUIs converted into a bit string, wherein PKKMCA public key that is KMC;
calculating KKC=KDF(xV||yV||ZKC||ZKMCKlen), KDF () is a key derivation function;
r is to beKCCoordinate x of1Y1 and RKMCCoordinate x of2、y2Is converted into a bit string, S is calculated1=Hash(0x02||yU|||Hash(xU||ZKC||ZKMC||x1||y1||x2||y2) And checking S)1And SKMCWhether the key authentication is established or not is judged, if the key authentication is not established, the KMC to KC key authentication fails;
calculating SKC=Hash(0x03||yU|||Hash(xU||ZKC||ZKMC||x1||y1||x2||y2))。
Step a6(KC → KMC):
passes verification and sends SKCSending the data to the KMC; if the authentication fails, a key agreement response (failure) is sent to the KC, and the authentication failure reason (failure to establish a link or authentication unsatisfied condition) is noted.
Step a7 (KMC):
calculating S2=Hash(0x03||yV||Hash(xV||ZKC||ZKMC||x1||y1||x2||y2) And checking S)2=SKCIf the key is not confirmed, the key confirmation fails if the equation is not confirmed, if the equation is confirmed, the key confirmation results, and the KEK shared by the KC and the KMC is KKC=KKMC。
Step A8(KMC → KC):
if the verification is passed, sending a key negotiation response (success) to the KC, and noting the starting time of the KEK; if the authentication fails, a key agreement response (failure) is sent to the KC, and the authentication failure reason (failure to establish a link or authentication unsatisfied condition) is noted.
Note:
the effective period of the KEK is 2 hours after the KEK is started, and the KEK is updated after 2 hours if the link does not transmit data; when the local KSC and the foreign KSC perform key backup, the key exchange subprotocol may also be used to generate the KEK for link encryption protection (refer to the KC and KMC key exchange process, which is not described in detail here).
(2) QKD key agreement subprotocol
The KEK may select QKD for key agreement. The single-photon QKD system adopts a BB84 protocol + Cascade coordination algorithm to realize unconditional safe KEK key negotiation between two points; the continuous variable QKD system adopts GG02 protocol + LDPC negotiation algorithm to realize unconditional safe KEK key negotiation between two points.
(3) Key generation subprotocol
And MK adopts a manual off-line mode to inject and generate the key. The KEK is generated by a security algorithm under MK control (reference may be made to the key exchange subprotocol), and the generation of the DEK is described with emphasis here.
When a logical volume is created, the KC receives a DEK request message sent by a RBD (RADOS Block Device, Block storage) client, and sends a key generation application to the KMC, where a specific interaction flow is shown in fig. 7 and table 12.
Table 12 detailed flow explanation of key generation subprotocol
Step B1 (KC):
the KC can provide dialog boxes according to different requirements of users on safety and reliability, and the user selects the key management system to provide key management services with different strengths:
first-order strength: the DEK is multi-controlled and is backed up in multiple places.
Secondary strength: and the DEK is multi-tube and multi-control, and is locally backed up.
Third-order strength: the DEK is singly controlled by a single tube, and is backed up in multiple places.
Fourth-order strength: and the DEK single tube is singly controlled, and the DEK is locally backed up.
The KC knows its key requirements (including key length, security policy, etc.).
Step B2(KC → KMC):
the KC sends a security Policy Attribute and a Key request message to the KMC, Policy Template is a security Policy corresponding to the encryption of the logical volume, Get Attribute is a set security intensity level, Owner is a logical volume ID, symmetry Key is a created Symmetric Key DEK, Create is a request for creating a new Key, and Cryptographic Algorithm is an encryption Algorithm used by the encryption of the logical volume.
Step B3 (KMC):
the KMC records registration information of the current logical volume key service. The KMC decides to generate N key components, N ═ 1,2, …, at KRP local N KSCs based on the security policy attributes.
Step B4(KMC → KSC 1):
the KMC sends a DEK (component) generation and save request to KSC 1. Split Key is the Key component and Archive requests the KSC to store the Key object for KMC.
Step B5(KSC 1):
Optionally, the method further comprises the following steps:
step B7(KMC → KSC N):
the KMC sends a DEK (component) generation and save request to the KSC N.
Step B8(KSC N):
KSC N Generation Key (component) DEKNAnd adopts the public key PK of KC (secure storage device)KCFor DEKNEncrypting to generate secret key (component)The logical volume based ID is stored in the KSC N.
Step B9(KSC 1 → KMC):
the KSC N sends a key response message to the KMC.
Optionally, the method further comprises the following steps:
step B10 (KMC):
the KMC collects DEK (component) generation responses fed back by the KSC and establishes a DEK (component) generation linked list. Step B11(KMC → KC):
the KMC transmits a key response message to the KC.
Note:
for step B2 or B11, if multiple link establishment fails, the KC sends a message to the RBD client to change the iSCSI server that created the logical volume. For step B6 or B9, if the DEK (component) generation response fed back by a certain KSC is not received within a specified time, the DEK (component) generation request is sent to the KSC again, and if the response sent back by the KSC is not received yet, the DEK (component) generation request is sent to other KSCs again.
(4) Key distribution subprotocol
When the logic volume carries out read-write operation, the KC applies to the KMC to obtain the key.
As shown in fig. 8, when the KMC receives a large number of KC-initiated DEK applications at the same time, a request/response message queue is established to solve the priority access and the delay access of key distribution. The KMC assesses user rating strength. In the same thread, the lower the security and reliability strength is, the higher the priority is, and the transmission opportunity (TXOP) of key distribution is preferentially obtained. TXOP denotes the time interval, CW, of a DEK-allocated transmission of KCminIs a minimum contention window, which represents a minimum time threshold for KC to wait for key allocation, and the higher the priority, the CWminThe smaller the value. CWmaxThe maximum contention window represents the maximum time threshold for the KC to wait for key allocation. TXOP (TXOP) ═ CWmax-CWmin. The lower the priority, the larger the TXOP value, CWmaxThe larger the value.
The specific interaction flow of the DEK key generation subprotocol is shown in fig. 9 and table 13.
Table 13 detailed flow explanation of key distribution subprotocol
Step C1 (KC):
when the logical volume carries out read-write operation, the KC constructs a key request message.
Step C2(KC → KMC):
the KC sends a Key request message to the KMC, the symmetry Key is a queried Symmetric Key DEK, the Get is an application acquisition Key, and the Owner is a logical volume ID.
Step C3 (KMC):
the KMC queries the DEK (component) to store the corresponding KSC based on the registration information of the logical volume key service. Step C4(KMC → KSC 1):
the KMC sends a DEK (component) acquisition request to KSC 1. Split Key is the Key component.
Step C5(KSC 1):
Step C6(KSC 1 → KMC):
If the response fails, the KSC 1 sends a key response message to the KMC. Wherein, Notify is a notification message, and Reject Reason is the Reason for request rejection, including failure to establish a link or damage or loss of stored DEK (component).
Optionally, the method further comprises the following steps:
step C7(KMC → KSC N):
the KMC sends a DEK (component) acquisition request to the KSC N.
Step C8(KSC N):
Step C9(KSC 1 → KMC):
If the response fails, the KSC N sends a key response message to the KMC. Wherein, Notify is a notification message, and Reject Reason is the Reason for request rejection, including failure to establish a link or damage or loss of stored DEK (component).
Optionally, the method further comprises the following steps:
step C10 (KMC):
the KMC collects DEK (component) acquisition response fed back by the KSC, and performs secret state synthesis of the DEK (component) based on a homomorphic cryptographic algorithm:step C11(KMC → KC):
the KMC sends a key challenge response to the KC.
(5) Key storage subprotocol
After the DEK is generated, the KRP is properly preserved. Considering backup disaster tolerance, the DEK needs a plurality of KSCs stored locally and remotely, and prevents the HSM from being damaged due to power failure, hardware damage or loss, natural disasters and the like. Take a typical "two places three centers" key storage architecture as an example: two KSCs (KSC 1 and KSC 2) are local and one key storage center (KSC 3) is off-site.
The specific interaction flow of the DEK key storage subprotocol is shown in fig. 10 and table 14. When the KSC receives the DEK (component) generation response sent by the KMC to the KSC, the KSC generates and stores the key and sends a DEK (component) storage request to the KSC which is local and remote.
Table 14 detailed flow explanation of key distribution subprotocol
Step D1(KSC 1 → KSC 2, KSC 3):
Step D2(KSC 2):
Step D3(KSC 2 → KSC 1):
if the response is successful, KSC 2 feeds back a DEK (component) backup success message to KSC 1. Notify is a notification message.
If the response fails, KSC 2 feeds back a DEK (component) backup failure message to KSC 1. Reject Reason is the Reason for request rejection and includes KSC 2 failing to verify KSC 1 or KSC 2 storage hard disk failing, etc.
Optionally, the method further comprises the following steps:
step D4(KSC 3):
Step D5(KSC 3 → KSC 1):
if the response is successful, KSC 3 feeds back a DEK (component) backup success message to KSC 1. Notify is a notification message.
If the response fails, KSC 3 feeds back a DEK (component) backup failure message to KSC 1. Reject Reason is the Reason for request rejection and includes KSC 3 failing to verify KSC 1 or KSC 3 storage hard disk failing, etc.
Optionally, the method further comprises the following steps:
step D6(KSC 1):
Step D9(KSC 1):
Step D10(KSC 1 → KSC 2):
if the response is successful, KSC 1 feeds back a DEK (component) backup success message to KSC 2. If the response fails, KSC 1 feeds back a DEK (component) backup failure message to KSC 2. Reject Reason is the Reason for request rejection and includes KSC 2 failing to verify KSC 1 or KSC 2 storage hard disk failing, etc.
Optionally, the method further comprises the following steps:
step D11(KSC 2 → KSC 3):
Step D12(KSC 3):
Optionally, the method further comprises the following steps:
step D14(KSC 2)
1) when DEK is stored locally, KSC are backed up with each other pairwise;
2) when exchanging DEK in different places, the KSC need to negotiate the KEK and carry out encryption protection, and the process can use the key exchange subprotocol for reference.
3) In idle period when the read-write operation of the logical volume is finished, PK is used for DEKKCAnd after encryption protection, the data is stored in a secure storage device for a short time (the survival time tau is less than or equal to 30min), so that the performance of the key management system is prevented from being reduced due to frequent reading and writing of the logical volume.
(6) Key exchange subprotocol
According to a secret management method for data safe storage, the DEK is replaced regularly, a new secret key component needs to be generated, secret key updating is driven by user requirements and is set manually, and data of the current logical volume cannot be read and written in the process. Meanwhile, the user can also select to adjust the security intensity and replace the security strategy. The specific interaction flow of the DEK key storage subprotocol is shown in fig. 11 and table 15.
Table 15 detailed flow explanation of rekeying subprotocol
Step E1 (KC):
the KC applies for rekeying (including key length, security policy, etc.).
Step E2(KC → KMC):
the KC sends a request message of updating a Key and a security Policy to the KMC, Policy Template is a security Policy corresponding to the encryption of the logical volume, Re-attribute is the updated security intensity level, Owner is a logical volume ID, Symmetric Key is a created Symmetric Key DEK, Re-Key is a request replacement Key, and Cryptographic Algorithm is an encryption Algorithm used by the encryption of the logical volume.
Step E3 (KMC):
the KMC identifies the key type and the security intensity level, and queries the original key (component) storage linked list. And (3) generating N key components by N KSCs local to the KRP based on the security policy attribute decision, wherein N is (1,2, …).
Step E4(KMC → KSC 1):
the KMC sends a DEK (component) replace and save request to KSC 1. Split Key is the Key component, Cryptographic Length is the Key Length of the logical volume new application DEK, and Archive requests the KSC to store the newly generated Key (component) for the KMC.
Step E5(KSC 1):
Step E6(KSC 1 → KMC):
Optionally, the method further comprises the following steps:
step E7(KMC → KSC N):
the KMC sends a DEK (component) replace and save request to the KSC N.
Step E8(KSC N):
KSC N reads the original key (component) based on the ID of the logical volumeAt the same time, the KSC N generates a new key (component) DEKN', and adopts the public key PK of KC (secure storage device)KCFor DEKN' encryption is performed to generate secret keys (components)The logical volume based ID is stored in the KSC N.
Step E9(KSC 1 → KMC):
the KSC N sends a key response message to the KMC. If the response is successful, the key component is sent firstPost-issuance of new key componentsTo the KMC.
Optionally, the method further comprises the following steps:
step E10 (KMC):
the KMC collects the DEK (component) replacement response fed back by the KSC and establishes a new DEK (component) generation linked list. Respectively carrying out dense synthesis on the original DEK (component) and the new DEK (component) to generateAndstep E11(KMC → KC):
the KMC sends a key exchange response message to the KC, and if the response is successful, the KMC sends the key exchange response messageAndif the response fails, the Reason for the request rejection is identified in the Reject Reason of the key response message, including failure to establish a link or an unsatisfied condition for authentication.
Step E12 (KC):
Note:
1) the KC can change the key and also can change the security policy.
2) The KSC needs to send the original key component to the KMC first and then send the new key component.
3) If the E6, E9 responses fail, the KSC does not generate a new key (component) and saves the original key (component).
4) After the key is successfully replaced by the logical volume, a destruction flow needs to be started for the original key (component) stored by the KRP, which is detailed in a key destruction subprotocol.
(7) Key destruction subprotocol
And the RBD client side completes data deletion or applies for destroying the key before zero filling, so that the data can not be recovered. In addition, when the key is replaced successfully, the destruction process is started for the original key (component) stored in the KRP. The specific interaction flow of the DEK key destruction sub-protocol is shown in fig. 12 and table 16.
TABLE 16 detailed flow explanation of the Key destroy subprotocol
Step F1 (KC):
the KC applies for destroying the key. Symmetry Key is the destroyed Symmetric Key DEK, Destroy is the notification KMC to Destroy the Key, and Owner is the logical volume ID.
Step F2(KC → KMC):
and the KMC inquires a key (component) storage linked list and comprehensively judges the key (component) storage linked list based on factors such as time, context association and the like, if the original DEK (component) storage linked list exists, only destroying the original DEK (component), and if not, destroying the DEK (component) corresponding to the logical volume.
A DEK destruction request is constructed.
Step F3(KMC → KSC 1):
the KMC sends a DEK (component) destruction request to KSC 1. Split Key is the Key component.
Step F4(KSC 1):
Step F5(KSC 1 → KMC):
Optionally, the method further comprises the following steps:
step F6(KMC → KSC N):
the KMC sends a DEK (component) destruction request to the KSC N.
Step F7(KSC N):
KSC N reads keys (components) based on the ID of the logical volumeAnd then carrying out safe erasing.
Step F8(KSC 1 → KMC):
the KSC N sends a key destruction response to the KMC.
Optionally, the method further comprises the following steps:
step F9 (KMC):
the KMC collects the DEK (component) destruction response fed back by the KSC, and if the DEK (component) destruction response accords with the key (component) storage linked list record, the storage linked list is deleted.
Step F10(KMC → KC):
the KMC sends a key destruction response message to the KC.
Step E12 (KC):
and if the response is successful, the logical volume completes the data deletion or zero filling operation, otherwise, the logical volume applies for destroying the key to the KMC again according to the Reason of the project Reason identification.
Note:
1) if the KC requests to replace the key, the KMC inquires the KSC position stored by the original key (component) according to the storage linked list, only erases the original key (component) stored by the KSC at the local place and the different places, and does not execute the F11 operation.
2) The KSC response is successful, the original key is erased.
6. Key production management process
As shown in fig. 13, the key generation of the system mainly includes the following three processes:
(1) raw password resource import
The original password resources mainly comprise a pre-manufactured secret key, algorithm logic, algorithm parameters, password software and the like. The facility key management equipment carries out encryption protection on the plain-state original password resource to form a secret-state original password resource, and then leads the secret-state resource into the original password resource and leads the secret-state resource into the management server in an off-line/on-line mode.
(2) Raw cryptographic resource encryption transform storage
After the password resource is imported, the original password resource import management server calls a password resource encryption conversion server interface to carry out encryption conversion and necessary fragmentation and encryption encapsulation processing on the password resource, basic password resource data are formed to be stored in a centralized mode, and a data directory is issued to a password resource directory server in real time.
(3) Original cryptographic resource distribution
The password management node applies for original password resources from the key resource pool, the resource pool pushes the corresponding password resources to a database server of the password management node, and the password management comprehensive service server extracts the password resources as required.
The foregoing is illustrative of the preferred embodiments of this invention, and it is to be understood that the invention is not limited to the precise form disclosed herein and that various other combinations, modifications, and environments may be resorted to, falling within the scope of the concept as disclosed herein, either as described above or as apparent to those skilled in the relevant art. And that modifications and variations may be effected by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (12)
1. A method for designing a key management protocol oriented to secure storage is characterized by comprising the following steps:
constructing a key request message through a key management client and sending the key request message to a key management center, receiving and analyzing a response message of the key management center, and providing a processing result of the request message for an application program; when the key management client side obtains the key, the key is loaded into the password card to realize password operation;
providing centralized password management through the key management center, providing services including key registration, inquiry and revocation, partitioning, configuring and managing a key resource pool, and providing administrator access, log recording and audit trail;
generating and storing keys respectively by a key generator and a key storage center in the key resource pool, wherein the key generator generates the keys by adopting a quantum noise source, and the key storage center is formed by a cluster of hardware security modules; the hardware security module can be used as a trust root of the whole encryption infrastructure and can be divided into a plurality of encryption isolated partitions, and each partition can be used as a trust root for independently protecting the whole life cycle of a plurality of independent keys.
2. A method for designing a key management protocol for secure storage according to claim 1, comprising a key exchange subprotocol:
when a user opens the user interface of the key management client, or the key management client does not have any data interaction with the server within the past set time, the key agreement is triggered; and the key management client and the key management center use respective private keys and the public key of the other side to agree a key encryption key based on an elliptic curve public key cryptographic algorithm.
3. The method for designing a key management protocol for secure storage according to claim 2, wherein the key encryption key is updated if the link does not transmit data after the key encryption key is enabled for a set time; when the key storage centers at the local place and the different places perform key backup, the key exchange subprotocol can also be adopted to generate a key encryption key for link encryption protection.
4. The method for designing a key management protocol for secure storage according to claim 1, comprising a key agreement subprotocol:
selecting quantum key distribution to perform key agreement on the key encryption key; the single photon quantum key distribution system adopts BB84 protocol and Cascade coordination algorithm to realize unconditional safe key negotiation between two points; the continuous variable quantum key distribution system adopts GG02 protocol and LDPC negotiation algorithm to realize unconditional secure key negotiation between two points.
5. A method for designing a key management protocol for secure storage according to claim 1, comprising a key generation subprotocol:
the method comprises the following steps that a main secret key is generated by injecting a secret key in a manual off-line mode, and the main secret key is mainly used for carrying out encryption protection on a secret key encryption secret key and a data encryption secret key; a key encryption key is generated by a security algorithm under the control of the master key; the generation of the data encryption key comprises: when the logical volume is created, the key management client receives a data encryption key request message sent by the block storage client, and sends a key generation application to the key management center to generate a data encryption key.
6. A method for designing a key management protocol for secure storage according to claim 1, comprising a key distribution subprotocol:
when the logic volume carries out read-write operation, the key management client applies for obtaining a key from the key management center; when the key management center receives a large amount of data encryption key applications initiated by the key management client at the same time, a request/response message queue is established, and priority access and delayed access of key distribution are solved; the key management center judges the user grade intensity; in the same thread, the lower the security and reliability strength is, the higher the priority is, the prior to obtaining a transmission opportunity (TXOP) of key distribution, wherein the TXOP represents the time interval of data encryption key distribution transmission of the key management client and satisfies the following conditions:
TXOP=CWmax-CWmin
wherein CWmaxThe maximum competition window represents the maximum time threshold for the key management client to wait for key distribution; CWminThe minimum competition window represents the minimum time threshold for the key management client to wait for key distribution; the higher the priority, CWminThe smaller the value; the lower the priority, the larger the TXOP value, CWmaxThe larger the value.
7. A method for designing a key management protocol for secure storage according to claim 1, comprising the key storage subprotocol:
the data encryption key is generated and stored in the key resource pool and stored in a plurality of local and allopatric key storage centers; and after the key storage center receives a data encryption key or component generation response sent by the key management center, the key storage center generates and stores a key and sends a data encryption key or component storage request to the key storage center at a local place and a remote place.
8. A method for designing a key management protocol for secure storage according to claim 1, comprising a rekeying sub-protocol:
according to a secret management method for data safe storage, a data encryption key is replaced regularly to generate a new key component, and key updating is driven by user requirements; the key storage center needs to send the original key component to the key management center first and then send the new key component.
9. The method for designing a key management protocol for secure storage according to claim 1, comprising a key destruction sub-protocol:
the block storage client side completes data deletion or applies for destroying a key before zero filling so that the data can not be recovered; after the key is successfully replaced, starting a destroying process for the original key or the component stored in the key resource pool; if the key management client requests to replace the key, the key management center inquires the position of an original key or a component stored in the key storage center according to a storage linked list, only erases the original key or the component stored in the key storage center at local and different places, and does not execute data deletion or zero padding operation; and if the key storage center responds successfully, erasing the original key.
10. The method of claim 1, wherein the key generation comprises the following steps:
importing an original password resource: the original password resource comprises a prefabricated secret key, algorithm logic, algorithm parameters and password software; the facility key management equipment carries out encryption protection on the plain-state original password resource to form a secret-state original password resource, and then leads the secret-state resource into the original password resource and leads the secret-state resource into the management server in an off-line/on-line mode;
encryption, conversion and storage of original password resources: after the password resource is imported, the original password resource import management server calls a password resource encryption conversion server interface to carry out encryption conversion and necessary fragmentation and encryption encapsulation processing on the password resource, so that basic password resource data are stored in a centralized mode, and a data directory is issued to a password resource directory server in real time;
original password resource distribution: the password management node applies for original password resources from the key resource pool, the resource pool pushes the corresponding password resources to a database server of the password management node, and the password management comprehensive service server extracts the password resources as required.
11. A secure storage oriented key management system, comprising:
the key management client is adapted to the storage terminal in the form of application software, is responsible for constructing a key request message and sending the key request message to the key management center, receives and analyzes a response message of the key management center, and provides a processing result of the request message for an application program; when the key management client side obtains the key, the key is loaded into the password card to realize password operation;
the key management center provides centralized password management in the form of hardware equipment, provides services including key registration, inquiry and revocation, partitions, configures and manages a key resource pool, and provides administrator access, log recording and audit tracking;
the key resource pool mainly comprises a key generator and a key storage center, wherein the key generator generates a key by adopting a quantum noise source, and the key storage center consists of a cluster of hardware security modules; the hardware security module can be used as a trust root of the whole encryption infrastructure and can be divided into a plurality of encryption isolated partitions, and each partition can be used as a trust root for independently protecting the whole life cycle of a plurality of independent keys.
12. A key management system for secure storage according to claim 11, wherein the key management client is deployed on each storage device, the key management center is connected to the secure storage device through an IP/FC network, and the key resource pool is built according to a two-place multi-center architecture, i.e. a plurality of key storage centers located locally and remotely.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011392351.3A CN112800439B (en) | 2020-12-02 | 2020-12-02 | Key management protocol design method and system for secure storage |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011392351.3A CN112800439B (en) | 2020-12-02 | 2020-12-02 | Key management protocol design method and system for secure storage |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112800439A CN112800439A (en) | 2021-05-14 |
CN112800439B true CN112800439B (en) | 2022-02-08 |
Family
ID=75806248
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011392351.3A Active CN112800439B (en) | 2020-12-02 | 2020-12-02 | Key management protocol design method and system for secure storage |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112800439B (en) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113190833B (en) * | 2021-06-01 | 2022-11-18 | 浙江大华技术股份有限公司 | Authority processing method and device, storage medium and electronic device |
CN113342467B (en) * | 2021-06-22 | 2023-12-05 | 海光信息技术股份有限公司 | Virtual machine snapshot storage and reading method and device and related equipment |
CN113676318B (en) * | 2021-07-15 | 2024-02-27 | 北京思特奇信息技术股份有限公司 | Method for key rotation without affecting original cipher encryption and decryption |
CN113792295A (en) * | 2021-08-23 | 2021-12-14 | 中国电子科技集团公司第三十研究所 | Unmanned platform data security service system and working method thereof |
CN113630249B (en) * | 2021-09-18 | 2022-09-09 | 国科量子通信网络有限公司 | Quantum network access security trusteeship client platform |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108123978A (en) * | 2016-11-30 | 2018-06-05 | 天津易遨在线科技有限公司 | A kind of ERP optimizes server cluster system |
CN108737079A (en) * | 2017-04-14 | 2018-11-02 | 广东国盾量子科技有限公司 | Distributed quantum key manages system and method |
CN110266483A (en) * | 2019-06-25 | 2019-09-20 | 如般量子科技有限公司 | Based on unsymmetrical key pond to and the quantum communications service station cryptographic key negotiation method of QKD, system, equipment |
CN110489996A (en) * | 2019-07-31 | 2019-11-22 | 山东三未信安信息科技有限公司 | A kind of database data method for managing security and system |
CN110505055A (en) * | 2019-07-12 | 2019-11-26 | 如般量子科技有限公司 | Based on unsymmetrical key pond to and key card outer net access identity authentication method and system |
CN110519046A (en) * | 2019-07-12 | 2019-11-29 | 如般量子科技有限公司 | Quantum communications service station cryptographic key negotiation method and system based on disposable asymmetric key pair and QKD |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105681031B (en) * | 2016-01-08 | 2018-12-21 | 成都卫士通信息产业股份有限公司 | A kind of storage encryption gateway key management system and method |
CN109274646B (en) * | 2018-08-22 | 2020-12-22 | 华东计算技术研究所(中国电子科技集团公司第三十二研究所) | Key management client server side method, system and medium based on KMIP protocol |
CN110808829B (en) * | 2019-09-27 | 2023-04-18 | 国电南瑞科技股份有限公司 | SSH authentication method based on key distribution center |
CN112000975B (en) * | 2020-10-28 | 2021-02-09 | 湖南天琛信息科技有限公司 | Key management system |
-
2020
- 2020-12-02 CN CN202011392351.3A patent/CN112800439B/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108123978A (en) * | 2016-11-30 | 2018-06-05 | 天津易遨在线科技有限公司 | A kind of ERP optimizes server cluster system |
CN108737079A (en) * | 2017-04-14 | 2018-11-02 | 广东国盾量子科技有限公司 | Distributed quantum key manages system and method |
CN110266483A (en) * | 2019-06-25 | 2019-09-20 | 如般量子科技有限公司 | Based on unsymmetrical key pond to and the quantum communications service station cryptographic key negotiation method of QKD, system, equipment |
CN110505055A (en) * | 2019-07-12 | 2019-11-26 | 如般量子科技有限公司 | Based on unsymmetrical key pond to and key card outer net access identity authentication method and system |
CN110519046A (en) * | 2019-07-12 | 2019-11-29 | 如般量子科技有限公司 | Quantum communications service station cryptographic key negotiation method and system based on disposable asymmetric key pair and QKD |
CN110489996A (en) * | 2019-07-31 | 2019-11-22 | 山东三未信安信息科技有限公司 | A kind of database data method for managing security and system |
Non-Patent Citations (2)
Title |
---|
Study on User Certificate in Public Key Infrastructure with High Efficiency and Robust;Xiangdong Yin等;《2008 International Conference on Computer Science and》;20080912;第199-203页 * |
密钥管理***(KMC中⼼);CFCA;《https://www.cfca.com.cn/20180510/100003081.html》;20180510;第2-4页 * |
Also Published As
Publication number | Publication date |
---|---|
CN112800439A (en) | 2021-05-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112800439B (en) | Key management protocol design method and system for secure storage | |
CN112910840B (en) | Medical data storage and sharing method and system based on alliance blockchain | |
CN112272094B (en) | Internet of things equipment identity authentication method, system and storage medium based on PUF (physical unclonable function) and CPK (compact public key) algorithm | |
Kohl et al. | The evolution of the Kerberos authentication service | |
CN111783128B (en) | Verifiable distributed database access control method | |
WO2012071728A1 (en) | Data encryption method, apparatus and system for cloud storage | |
CN113259453B (en) | Cross-chain interaction method and device | |
CN112436936B (en) | Cloud storage method and system with quantum encryption function | |
Giri et al. | A survey on data integrity techniques in cloud computing | |
CN109284426B (en) | Multi-data document classification system based on permission level | |
CN113824551B (en) | Quantum key distribution method applied to secure storage system | |
CN112732695A (en) | Cloud storage data security deduplication method based on block chain | |
CN109981271A (en) | A kind of network multimedia security protection encryption method | |
CN111563980B (en) | Bluetooth lock key generation and authentication method | |
CN114510734B (en) | Data access control method, device and computer readable storage medium | |
Blundo et al. | On self-healing key distribution schemes | |
CN113037483A (en) | Distributed key management method based on threshold | |
CN115412236A (en) | Method for key management and password calculation, encryption method and device | |
CN101646172A (en) | Method and device for generating key in distributed MESH network | |
CN114844649A (en) | Secret key distribution method containing trusted third party based on superlattice PUF | |
CN114154185A (en) | Data encryption storage method based on national cryptographic algorithm | |
CN110958211B (en) | Data processing system and method based on block chain | |
CN102255724A (en) | Hypergraph-model-based multicast key management method | |
CN111866000A (en) | Account password management method of computer medium management system | |
Raza et al. | Design and implementation of a security manager for WirelessHART networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |