CN112800439B

CN112800439B - Key management protocol design method and system for secure storage

Info

Publication number: CN112800439B
Application number: CN202011392351.3A
Authority: CN
Inventors: 赵越; 易仲强; 苏宏; 郝尧; 陈宇翔
Original assignee: CETC 30 Research Institute
Current assignee: CETC 30 Research Institute
Priority date: 2020-12-02
Filing date: 2020-12-02
Publication date: 2022-02-08
Anticipated expiration: 2040-12-02
Also published as: CN112800439A

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

Key management protocol design method and system for secure storage

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＝CW_max-CW_min

wherein CW_maxThe maximum competition window represents the maximum time threshold for the key management client to wait for key distribution; CW_minThe minimum competition window represents the minimum time threshold for the key management client to wait for key distribution; the higher the priority, CW_minThe smaller the value; the lower the priority, the larger the TXOP value, CW_maxThe 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.

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 parameters
		1	Key agreement subprotocol
2	Key generation subprotocol
		3	Key distribution subprotocol
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 parameters
		1	Messages sent by KC
2	Messages sent by KMC
		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 K_KMC＝KDF(x_V||y_V||Z_KC||Z_KMCKlen), KDF () is a key derivation function, Z_KCIs the hash value of the distinguishable identification of KC, partial elliptic curve system parameters and KC public key, Z_KMCIs a hash value of the KMC, the partial elliptic curve system parameter and the KC public key.

R is to be_KCCoordinate x of₁Y1 and R_KMCCoordinate x of₂、y₂Class of dataConverting the pattern into a bit string, calculating S_KMC＝Hash(0x02||y_V|||Hash(x_V||Z_KC||Z_KMC||x₁||y₁||x₂||y₂))。

Step a4(KMC → KC):

verification passes, and R is_KMC，S_KMCSending 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.t_KC](PK_KMC+x₁R_KMC)＝(x_U,y_U) If U is an infinite point, KC judges that the negotiation fails; otherwise will x_U、y_UIs converted into a bit string, wherein PK_KMCA public key that is KMC;

calculating K_KC＝KDF(x_V||y_V||Z_KC||Z_KMCKlen), KDF () is a key derivation function;

r is to be_KCCoordinate x of₁Y1 and R_KMCCoordinate x of₂、y₂Is converted into a bit string, S is calculated₁＝Hash(0x02||y_U|||Hash(x_U||Z_KC||Z_KMC||x₁||y₁||x₂||y₂) And checking S)₁And S_KMCWhether the key authentication is established or not is judged, if the key authentication is not established, the KMC to KC key authentication fails;

calculating S_KC＝Hash(0x03||y_U|||Hash(x_U||Z_KC||Z_KMC||x₁||y₁||x₂||y₂))。

Step a6(KC → KMC):

passes verification and sends S_KCSending 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 S₂＝Hash(0x03||y_V||Hash(x_V||Z_KC||Z_KMC||x₁||y₁||x₂||y₂) And checking S)₂＝S_KCIf 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 K_KC＝K_KMC。

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):

KSC 1 generating a key (component) DEK₁And adopts the public key PK of KC (secure storage device)_KCFor DEK₁Performing encryption to generate a secret stateKey (component)

The ID based on the logical volume is stored in KSC 1. Step B6(KSC 1 → KMC):

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 unsatisfied verification conditions.

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) DEK_NAnd adopts the public key PK of KC (secure storage device)_KCFor DEK_NEncrypting 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 KC_minIs a minimum contention window, which represents a minimum time threshold for KC to wait for key allocation, and the higher the priority, the CW_minThe smaller the value. CW_maxThe maximum contention window represents the maximum time threshold for the KC to wait for key allocation. TXOP (TXOP) ═ CW_max-CW_min. The lower the priority, the larger the TXOP value, CW_maxThe 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):

KSC 1 reads a secret key (component) of a secret state based on the ID of the logical volume as

Step C6(KSC 1 → KMC):

if the response is successful, KSC 1 sends to the 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):

KSC N reads secret keys (components) based on the ID of the logical volume

Step C9(KSC 1 → KMC):

if the response is successful, the KSC N sends the 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):

KSC 1 sends DEK (component) backup requests to KSC 2, respectively. Split Key is the Key component generated by KSC 1, Copy is KSC 1 requesting KSC 2 backup Key object, and Owner is logical volume ID.

KSC 1 may choose to send a DEK (component) backup request to KSC 3 depending on the need for whether the key is backed up too much.

Step D2(KSC 2):

KSC 2 saves key components based on KSC 1 sequence number and ID of logical volume

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):

KSC 3 saves key components based on KSC 1 sequence number and ID of logical volume

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):

KSC 1 collects DEK (component) storage backup responses fed back by KSC 2 and KSC 3, and if the storage backup fails, sends DEK (component) storage backup requests to other local or off-site KSCs. Generating

A key storage group that records which KSCs are stored or backed up locally or remotely

Step D7(KSC 1 → KMC):

KSC 1 sends the DEK (component) storage backup advertisement to the KMC. The KMC establishes a DEK (component) storage linked list. Step D8(KSC 2 → KSC 1):

KSC 2 sends a DEK (component) backup request to KSC 1.

Step D9(KSC 1):

KSC 1 saves key components based on KSC 2 sequence numbers and logical volume IDs

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):

KSC 2 sends a DEK (component) backup request to KSC 3.

Step D12(KSC 3):

KSC 3 maintains key components based on KSC 2 sequence numbers and the ID of logical volumes

Step D13(KSC 3 → KSC 2):

KSC 3 feeds back a DEK (component) backup success/failure message to KSC 1.

Optionally, the method further comprises the following steps:

step D14(KSC 2)

KSC 2 collects DEK (component) storage backup responses fed back by KSC 1 and KSC 3, and if the storage backup fails, the DEK (component) storage backup request is sent to other local or off-site KSCs. Generating

Step D15(KSC 2 → KMC)

KSC 2 sends the DEK (component) storage backup advertisement to the KMC. The KMC establishes a DEK (component) storage linked list. Note:

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 DEK_KCAnd 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):

KSC 1 reads the original key (component) based on the ID of the logical volume

At the same time, a new key (component) DEK is generated₁', and adopts the public key PK of KC (secure storage device)_KCFor DEK₁' encryption is performed to generate secret keys (components)

The ID based on the logical volume is stored in KSC 1.

Step E6(KSC 1 → KMC):

KSC 1 sends a key response message to the KMC. If the response is successful, the key component is sent first

Post-issuance of new key components

To the KMC. If the response fails, the request rejection cause is identified in the Reject Reason, including a link establishment failure or an authentication unsatisfied condition.

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 volume

At the same time, the KSC N generates a new key (component) DEK_N', and adopts the public key PK of KC (secure storage device)_KCFor DEK_N' 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 first

Post-issuance of new key components

To 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 generate

And

step 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 message

And

if 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):

if the response is successful, the logical volume is used

After decryption, reuse

And (4) encrypting.

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):

KSC 1 query key (component) based on logical volume ID

And then carrying out safe erasing.

Step F5(KSC 1 → KMC):

KSC 1 sends a key response message to the KMC. Notify is a notification message. If the response fails, the request rejection cause is identified in the Reject Reason, including a link establishment failure or an authentication unsatisfied condition.

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 volume

And 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

1. A method for designing a key management protocol oriented to secure storage is characterized by comprising the following steps:

2. A method for designing a key management protocol for secure storage according to claim 1, comprising a key exchange subprotocol:

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:

5. A method for designing a key management protocol for secure storage according to claim 1, comprising a key generation subprotocol:

6. A method for designing a key management protocol for secure storage according to claim 1, comprising a key distribution subprotocol:

TXOP=CW_max-CW_min

7. A method for designing a key management protocol for secure storage according to claim 1, comprising the key storage subprotocol:

8. A method for designing a key management protocol for secure storage according to claim 1, comprising a rekeying sub-protocol:

9. The method for designing a key management protocol for secure storage according to claim 1, comprising a key destruction sub-protocol:

10. The method of claim 1, wherein the key generation comprises the following steps:

11. A secure storage oriented key management system, comprising:

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.