WO2023160375A1 - Session key generation method, control device, and device clustering system - Google Patents

Abstract

The present application discloses a session key generation method, a control device, and a device clustering system. KDEs are deployed in all service components in control devices, and authentication and session establishment can be performed between two service components in different control devices by means of the KDEs deployed inside the service components. During the establishment of a session, two KDEs negotiate to generate a session key, and perform authentication on the basis of the determined session key, without the need for performing authentication by means of a digital certificate, so that authentication efficiency can be improved, and system performance is improved. Moreover, when two KDEs negotiate to generate a session key without the need for establishing a session between the two KDEs, one of the KDEs applies to a KDC for a session key of this session, i.e., there is no need for the KDE to access the KDC before each session is established, so that the number of accesses to the KDC can be greatly reduced, performance bottlenecks caused by blockings resulting from a large number of accesses to the KDC are avoided, and the performance and reliability of the KDC are improved.

Description

Session secret key generation method, control device and device cluster system technical field

The present application relates to the technical field of communication, and in particular to a method for generating a session key, a control device and a device cluster system.

Background technique

In a device cluster system such as a distributed storage system, a microservice system, or a cloud computing system, it usually includes multiple control devices, which can be understood as devices that can run software programs, such as computers, servers, virtual computers, or controllers.

One or more service components can be deployed on each control device. The service components can be understood as software programs, and the service components can provide services for user terminals or other service components. For example, the second service component deployed on the control device B may provide services for the first service component deployed on the control device A, such as data access services and the like. In order to ensure the security of data transmission, when the second service component provides services for the first service component, that is, when the second service component establishes a session with the first service component, it needs to authenticate the identity of the first service component.

Currently, each service component has a unique corresponding digital certificate, and service components can be authenticated through digital certificates. However, the certification speed of digital certificates is low, which cannot meet the needs of large-scale and high-efficiency business.

Contents of the invention

Embodiments of the present application provide a method for generating a session key, a control device, and a device cluster system, which can improve authentication efficiency and system performance.

In a first aspect, an embodiment of the present application provides a control device. For the convenience of understanding, the control device is referred to as a first control device hereinafter, and the first control device is applied in a device cluster system. The device cluster system may include multiple control devices, wherein the first control device may include a key distribution center KDC and a first service component, and the first service component is deployed with a first key distribution entity KDE.

The KDC may be configured to: provide key generation information for the first KDE in response to the key application request of the first KDE. The first KDE is used to generate the first entity key according to the key generation information provided by the KDC.

The first KDE can be used to send the identification information of the first KDE and the identification information of the KDC to the second KDE during the process of establishing a session with the second KDE of the service component of another control device, so that the second KDE can send the identification information of the first KDE to the second KDE according to the second KDE The entity key of KDE, the identification information of the first KDE and the identification information of KDC generate a session key for authentication between the first KDE and the second KDE; the first KDE receives the second KDE's The identification information and the identification information of the KDC generate a session key for authentication between the first KDE and the second KDE according to the first entity key, the identification information of the second KDE, and the identification information of the KDC.

In the embodiment of the present application, KDE is deployed in the service components in the control device, and two service components in different control devices can be authenticated and establish a session through the KDE deployed in the service components. During the session establishment process, the two KDEs negotiate to generate a session key and perform authentication based on the determined session key without the need for digital certificate authentication, which reduces management complexity; at the same time, there is no need to use complex digital certificate authentication algorithms , can improve authentication efficiency and improve system performance.

Moreover, the session key is generated through negotiation between the two KDEs, without the need for one of the KDEs to establish a session when the two KDEs establish a session Apply to the KDC for the session key of this session, that is, it is not necessary for KDE to visit the KDC before each session is established, so that the number of communications between KDE and KDC can be greatly reduced, the number of times KDC is visited, and the congestion caused by a large number of visits to KDC can be avoided. It can reduce the data processing pressure of KDC and improve the performance and reliability of KDC. At the same time, it can avoid the problem that the KDC saves the session keys of all sessions, which leads to the loss of security of the entire system due to the KDC being invaded.

In the embodiment of this application, during the process of negotiating and generating a session key between the first KDE and the second KDE, the identification information of the first KDE and the identification information of the second KDE used are unique, so the session key generated through negotiation The key is also unique, which can prevent external malicious attacks and improve session security.

In a possible implementation manner, the first control device may include multiple service components, each of which is deployed with KDE, and the first KDE may be any one of the KDEs of the multiple service components, or in other words, The first KDE may be KDE in any service component of the first control device. The second control device may also include a plurality of service components, each of which is equipped with KDE, and the second KDE may also be any one of the KDEs of the plurality of service components, or in other words, the second KDE may be the second Control KDE in any of the service components of the device. Both the first control device and the second control device are devices in the above-mentioned device cluster system.

In a possible implementation, the first control device may further include a key distribution agent KDA, which is used to save the entity key of KDE included in each service component in the first control device, including the first entity Correspondingly, the first KDE is also used to save the first entity key in the KDA of the first control device after generating the first entity key, and at each startup, from the first control device Obtain the first entity key from the KDA of the device.

In the above embodiment, KDA is deployed in the first control device, which is used to save the entity key of KDE included in each service component in the first control device. Each KDE can obtain the key generation information provided by the main KDC only when it is started for the first time or when the entity key is lost, and generate the entity key, which is stored in KDA. At each startup, the entity key can be obtained from the KDA, without obtaining the key generation information from the KDC, which can further reduce the data processing pressure of the KDC. At the same time, KDE does not need to generate an entity key every time it is started, which can also reduce the computing resources occupied by KDE. In addition, KDA saves the physical keys of each KDE in the first control device, avoiding the problem of safe storage of secret keys caused by multiple KDEs separately storing their own physical keys and unable to deploy a secure storage mechanism in each KDE , which can improve the security of the entity key and reduce the risk of key leakage.

In a possible implementation, the KDA of the first control device can also be used to: receive the key application request sent by the first KDE, and forward the first KDE's key application request to the KDC; and receive the key application request sent by the KDC; key generation information, and forward the key generation information to the first KDE.

In the above device cluster system, each KDE deployed in the same control device as the KDA can perform data communication with the KDC through the KDA. Since there are multiple service components in one control device, each service component is deployed with a KDE, the KDE in multiple service components is connected to the KDC through a KDA, and the number of KDAs connected to the KDC is much smaller than the number of KDEs, so It can reduce the number of occupied KDC external communication interfaces, and reduce the external communication pressure of KDC.

In a possible implementation, the KDC can also be used to: receive and save the registration information of each KDE included in the device cluster system; and when receiving the key application request of the first KDE, include the Verify the consistency between the carried key application information and the saved registration information of the first KDE, and provide key generation information for the first KDE after the verification is passed.

In the above-mentioned embodiment, no matter when the KDC is used as the main KDC or the standby KDC, the registration information of each KDE can be saved, so that when it is used as the main KDC, the key application information carried in the key application request sent by the KDE is verified. Therefore, during active/standby switchover, there is no need to perform data synchronization between KDCs, avoiding the problem of data synchronization between KDCs during active/standby switchover.

In a possible implementation manner, the first KDE may also be used to: obtain and save the identification information and central key of the KDC, and when negotiating with the second KDE to generate a session key, the first KDE may Identification information, obtain the central key of the KDC, and generate a session key according to the first entity key, the identification information of the second KDE and the central key of the KDC.

Exemplarily, multiple KDCs may be deployed in the device cluster system, and different KDCs may be deployed in different control devices in the device cluster system; the multiple KDCs may include an active KDC and a standby KDC. The first KDE may be used to: obtain and save the identification information and central key of each KDC included in the device cluster system. The master KDC may be used to provide key generation information for the first KDE in response to the key application request of the first KDE. For example, after receiving the key application request sent by the first KDE, the KDA can forward the key application request of the first KDE to the main KDC; and receive the key generation information sent by the main KDC, and forward the key generation information to the first KDE , the first KDE generates the first entity key according to the key generation information provided by the master KDC. When negotiating with the second KDE to generate a session key, the first KDE can obtain the central key of the primary KDC according to the identification information of the primary KDC, and obtain the central key of the primary KDC according to the first entity key, the identification information of the second KDE, and the central The secret key generates a session key.

In the above embodiment, each KDE stores the identification information of each KDC and the central key. When the two KDEs negotiate to generate a session key, they send the identification information of the master KDC to each other, that is, negotiate to determine the master KDC, so that the second KDC can The first KDE and the second KDE generate the session key based on the same central key of the main KDC, so as to avoid the inconsistency of the session key caused by the inconsistency of the central key of the used main KDC. In addition, each KDE stores the central secret key of each KDC, and the two KDEs determine the KDC to be used in a negotiated manner, which can avoid the problem of data synchronization during the KDC master-standby switchover, so as to solve the problem of master-standby switchover. The problem of synchronizing two KDE keys.

In a possible implementation, the KDC can also be used to: receive the key revocation command sent by the management node, sign the revocation list carried in the key revocation command and distribute it to the standby KDC of the KDC; the revocation list includes the The KDE identification information corresponding to the leaked entity key and/or the KDC identification information corresponding to the leaked central key.

In the above embodiment, the leaked secret key is revoked in time through the secret key revocation instruction, which can prevent external attacks by using the leaked secret key, and further improve the security of the system.

Exemplarily, the master KDC in the device cluster system is used to receive the key revocation command sent by the management node, sign the revocation list carried in the key revocation command and distribute it to each standby KDC in the device cluster system.

In a second aspect, the embodiment of the present application provides a method for generating a session key, including:

The first key distribution entity KDE obtains the key generation information provided by the key distribution center KDC for the first KDE, and generates the first entity key according to the key generation information; the first control device deployed by the first KDE in the device cluster system within the service component of the device;

In the process of establishing a session with the second KDE, the first KDE sends the identification information of the first KDE and the identification information of the KDC to the second KDE; the second KDE is deployed in the service component of the second control device in the device cluster system;

The first KDE receives the identification information of the second KDE and the identification information of the KDC sent by the second KDE;

The first KDE generates a session key for authentication between the first KDE and the second KDE according to the first entity key, the identification information of the second KDE, and the identification information of the KDC.

In a possible implementation, after the first KDE generates the first entity key, it can save the first entity key to the key distribution agent KDA deployed in the first control device, and , to obtain the first entity key from KDA.

In a possible implementation manner, the first KDE may send a key application request to the KDC through the KDA, and receive the key generation information obtained from the KDC forwarded by the KDA.

In a possible implementation, before the first KDE obtains the key generation information from the KDC, the first KDE may also generate registration information and send the registration information of the first KDE to the KDC, so that the KDC saves the key generation information of the first KDE. registration message.

In a possible implementation, the key generation information of the first KDE is that the KDC receives the key generation information of the first KDE When requesting, verify the consistency between the key application information carried in the key application request and the stored registration information of the first KDE, and provide it to the first KDE after the verification is passed.

In a possible implementation manner, before the first KDE obtains the key generation information from the KDC, the first KDE may also receive and save the identification information of the KDC and the central key.

In a possible implementation, the first KDE can obtain the central key of the KDC according to the identification information of the KDC, and generate a session key according to the first entity key, the identification information of the second KDE, and the central key of the KDC .

In a third aspect, an embodiment of the present application provides a device cluster system, where the device cluster system includes a plurality of control devices; the plurality of control devices include any control device provided in the first aspect.

In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, where computer-executable instructions are stored in the computer-readable storage medium, and the computer-executable instructions are used to make a computer perform any one of the above-mentioned second aspects. method.

In a fifth aspect, an embodiment of the present application provides a computer program product, including computer executable instructions, where the computer executable instructions are used to cause a computer to execute any one of the methods provided in the second aspect above.

For the technical effects that can be achieved by any one of the above-mentioned second to fifth aspects, reference can be made to the description of the beneficial effects in the above-mentioned first aspect, which will not be repeated here.

Description of drawings

FIG. 1 is a schematic diagram of an application scenario of an embodiment of the present application;

FIG. 2 is a schematic structural diagram of a device cluster system provided by an embodiment of the present application;

Fig. 3 is an interactive diagram between KDE and KDC in a kind of registration process that the embodiment of the present application provides;

Fig. 4 is an interaction diagram between KDE and the main KDC in a kind of secret key application process provided by the embodiment of the present application;

FIG. 5 is an interaction diagram between KDE1 and KDE2 in a session establishment process provided by an embodiment of the present application;

FIG. 6 is an interaction diagram between KDE1 and KDE2 in another session establishment process provided by the embodiment of the present application;

FIG. 7 is a schematic structural diagram of another device cluster system provided by an embodiment of the present application;

FIG. 8 is an interaction diagram between KDE, KDA and KDC in a registration process provided by an embodiment of the present application;

Fig. 9 is an interaction diagram between KDE, KDA and master KDC in a kind of secret key application process provided by the embodiment of the present application;

FIG. 10 is an interaction diagram between KDE, KDA and KDC in a secret key update process provided by the embodiment of the present application;

Figure 11 is an interaction diagram between KDE, KDA and the master KDC in a secret key update process provided by the embodiment of the present application;

FIG. 12 is an interaction diagram between the management node, KDA and KDC in the key revocation process provided by the embodiment of the present application;

FIG. 13 is a schematic structural diagram of a control device provided by an embodiment of the present application;

FIG. 14 is a schematic structural diagram of another control device provided in the embodiment of the present application;

FIG. 15 is a flow chart of a method for generating a session key provided by an embodiment of the present application.

Detailed ways

In order to make the purpose, technical solutions, and advantages of the embodiments of the present application clearer, the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings. The terms used in the embodiments of the present application are only used to explain specific embodiments of the present application, and are not intended to limit the present application. Apparently, the described embodiments are only some of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the scope of protection of this application.

"Multiple" in the embodiment of the present application refers to two or more, in view of this, "multiple" can also be understood as "at least two" in the embodiment of the present application. "At least one" can be understood as one or more, such as one, two or more indivual. For example, including at least one means including one, two or more, and does not limit which ones are included, for example, including at least one of A, B and C, then what is included can be A, B, C, A and B, A and C, B and C, or A and B and C. "And/or" describes the association relationship of associated objects, indicating that there may be three types of relationships, for example, A and/or B may indicate: A exists alone, A and B exist simultaneously, and B exists independently. In addition, the character "/", unless otherwise specified, generally indicates that the associated objects before and after are in an "or" relationship.

Unless otherwise specified, ordinal numerals such as "first" and "second" mentioned in the embodiments of the present application are used to distinguish multiple objects, and are not used to limit the sequence, timing, priority or importance of multiple objects.

Figure 1 shows a schematic diagram of a typical application scenario of the embodiment of the present application. The application scenario takes a distributed storage system as an example, wherein the control device A, control device A1, control device B, and control device B1 can be distributed storage The computers, servers, virtual computers, or controllers in the system are not limited in this embodiment of the present application. Exemplarily, the distributed storage system may include one or more cabinets, each cabinet is provided with multiple blade servers, and each blade server may have multiple controllers, such as the above-mentioned control device A, control device A1 and Control device B, control device B1, each controller can be equivalent to a virtual computer.

As shown in Figure 1, one or more service components are deployed in each control device. For example, the first service component is deployed on the control device A, the second service component is deployed on the control device B, the third service component is deployed on the control device A1, and the fourth service component is deployed on the control device B1. Among them, the first service component can be understood as any service component in the control device A, the second service component can be understood as any service component in the control device B, and the third service component can be understood as any one in the control device A1 The service component, the fourth service component can be understood as any service component in the control device B1. The second service component deployed on the control device B may provide services for the first service component deployed on the control device A and the third service component deployed on the control device A1, such as data access services and the like. The fourth service component deployed on the control device B1 can provide services for the first service component deployed on the control device A and the third service component deployed on the control device A1.

When data is transmitted between service components, in order to ensure the security of data transmission, identity authentication is required. For example, when the first service component requests the second service component to provide services, the second service component and the first service component need to authenticate each other.

Currently, each service component has a unique corresponding digital certificate, and service components can be authenticated through digital certificates. For example, the access links between service components can be digitally authenticated using the Transport Layer Security (TLS) protocol or Datagram Transport Layer Security (DTLS) protocol authenticated by x.509 digital certificates. Certificate authentication and link protection. However, the management complexity of digital certificates is relatively high, and the speed of authentication using the TLS protocol or DTLS protocol is low, which cannot meet large-scale and high-performance business needs. In order to improve authentication efficiency and improve system performance, the embodiments of the present application provide a method for generating a session key, a control device, and a device cluster system. The session key generation method provided by the embodiment of this application can be applied not only to distributed storage application scenarios, but also to cloud scenarios, microservice scenarios, and other cross-controller authentication, cross-operating system authentication or cross-host authentication in the scene. The more service components are included in the application scenario, the more prominent the effect of the session key generation method provided by the embodiment of the present application in improving system performance.

FIG. 2 shows a schematic structural diagram of a device cluster system provided by an embodiment of the present application. In some embodiments, as shown in FIG. 2, the device cluster system may include multiple control devices, some control devices may deploy a key distribution center (key distribution center, KDC), and some other control devices may not deploy KDC; For example, KDC is deployed on control device A and control device A1, but no KDC is deployed on control device B and control device B1. Each control device includes at least one service component, and each service component is deployed with a key distribution entity (key distribution entity, KDE). The standby cluster system can be applied to the application scenario shown in Figure 1. It can also be understood that the device cluster system provided by the embodiment of the present application includes multiple KDCs and multiple KDEs respectively deployed in each service component.

Multiple KDCs can be deployed in different control devices. Each KDC generates a pair of asymmetric algorithm keys Akey as the root key. The root key includes the KDC’s public key Akey_pub and the KDC’s private key Akey_sec. Different KDCs Inside, the root keys are different. Wherein, at the same time, among multiple KDCs, one KDC serves as the active KDC, and the other KDCs serve as standby KDCs. The master KDC is used to distribute key generation information to each KDE, so that each KDE generates its own entity key Key_e according to the key generation information. When the active KDC fails or can no longer serve as the active KDC due to other reasons, an active-standby switchover will be performed, and any KDC in the standby KDC may serve as the new active KDC.

Multiple KDEs are deployed in multiple service components, and each service component has one KDE deployed. It can also be understood that each KDE and its corresponding service components are deployed in the same process. KDE is used for access control between service components, including authentication between service components and establishment of access channels. Each KDE has unique identification information (identifier, ID). KDE can use the ID of the service component it belongs to as its own identification information, and KDE performs access control based on the identification information.

Each KDE stores the identification information and central key of all KDCs, where the central key of the KDC refers to the public key Akey_pub in the root key of the KDC. For any KDE, it can obtain and save the identification information and central key of each KDC during the registration process. Each KDC can save the registration information of all registered KDEs.

The following describes the registration process of KDE in conjunction with Figure 3. The KDE shown in Figure 3 can be understood as the KDE in any service component. When each KDE is started, if it is determined that the entity key has not been applied for, such as the first startup or the entity key When missing, KDE initiates the registration process to all online KDCs. Since the interaction steps between KDE and each KDC are the same during the registration process, Figure 3 only illustrates the interaction process between KDE and a KDC as an example. The KDC shown in Figure 3 can be understood as any online KDC, It can be the active KDC or the standby KDC. As shown in Figure 3, the registration process may include the following steps:

S301. KDE sends a KDC key information request to the KDC.

During the registration process, KDE and KDC can exchange information through a pre-established secure channel. The secure channel can be a dedicated channel during deployment, a management channel, or a TLS secure channel established based on certificates. This application does not make any comment on this limited.

The KDC key information request sent by KDE to KDC carries the random number C1 generated by KDE and the identification information of KDE.

S302. The KDC sends the key information of the KDC to the KDE.

After the KDC receives the KDC key information request sent by the KDE, the KDC sends the KDC’s key information to the KDE according to the KDE’s identification message. The key information includes the KDC’s identification message and the KDC’s central key. Among them, the KDC’s The central secret key can be understood as the KDC’s public key AKey_pub, which is contained in the KDC’s public key information C2, and the KDC’s public key AKey_pub can be composed of two parts, PK1 and PK2. Therefore, the KDC’s public key information C2 can be expressed as: C2=PK1||PK2||CipherSuite, where || represents the concatenation between data, and CipherSuite represents the encryption algorithm suite, which can be understood as the encryption algorithm used in the encryption process A collection of all encryption algorithms used, including combinations of encryption algorithms used by different processes.

S303, KDE extracts the identification message of the KDC and the central key of the KDC from the key information of the KDC and saves them.

KDE can extract the identification message of KDC and PK1 and PK2 in the central key of KDC from the key information of KDC respectively, and save them.

S304. KDE generates registration information.

KDE generates a random number K and a random number Nonce, splices the KDE identification information ID_i and the random number Nonce, generates R_i according to the random number K and the spliced data, and then generates n_i according to the random number K and R_i; according to n_i, and The spliced data of ID_i, R_i and the character "MAC" generates the registration information AuthValue_i. The above KDE build note The process of registering information AuthValue_i can be expressed as:

K=Random()

Nonce=Random()

R_i=PRF(K,ID_i||Nonce)

n_i=PRF(K,R_i)

AuthValue_i=AES-CMAC(n_i, ID_i||R_i||"MAC")

Among them, Random() means to generate random numbers, PRF() is a pseudo-random generation algorithm, and AES-CMAC() is a symmetric encryption algorithm.

S305. KDE sends registration information to KDC.

When KDE sends registration information to KDC, it can send KDE identification information ID_i and KDE registration information AuthValue_i to KDC together. Exemplarily, KDE may use PK1 in the KDC's central key to encrypt the data after the concatenation of KDE's identification information ID_i and KDE's registration information AuthValue_i to obtain a data packet C3, and send the data packet C3 to the KDC. Wherein, the data packet C3 can be expressed as: C3=Enc(PK1, ID_i||AuthValue_i), Enc() represents an asymmetric encryption algorithm.

After KDE sends registration information to KDC, it saves ID_i, K and R_i used in the process of generating registration information. This process can be expressed as: Store(ID_i, K, R_i).

S306. The KDC saves the registration information of KDE.

The KDC can use SK1 in the private key of the KDC to decrypt the data packet C3 sent by the KDE, obtain the identification information ID_i of the KDE and the registration information AuthValue_i of the KDE, and store them. The process can be expressed as:

ID_i||AuthValue_i=Dec(SK1,C3)

Store(ID_i, AuthValue_i)

Among them, Dec() represents the decryption algorithm.

S307. The KDC sends a registration completion notification to the KDE.

KDE can perform the above registration process with each online KDC, through the above registration process, KDE can store the identification information and central key of each online KDC.

The above registration process is applicable to every KDE, that is, any KDE can be registered according to the above registration process. After registration, each KDE can save the identification information and central secret key of all online KDCs. Each KDC can save the identification information ID_i and registration information AuthValue_i of all registered KDEs. Therefore, during active/standby switchover, data synchronization between KDCs and between KDC and KDE is not required to avoid the problem of data synchronization during active/standby switchover.

After KDE completes the above registration process, it can initiate a key application process to the main KDC, where KDE can be understood as any KDE. Figure 4 shows the interaction process between KDE and the master KDC during the key application process. As shown in Figure 4, the KDE key application process may include the following steps:

S401. KDE generates key application information.

KDE generates random number a_i, and uses R_i and random number K generated during the registration process to generate n_i. KDE obtains A_i based on the dot product of a_i and g, where g is a preset parameter. KDE uses PK1 in the central key of the main KDC to encrypt the data obtained by concatenating KDE's identification information ID_i, the above-mentioned R_i, n_i, and A_i, and obtain the key application information C4. The process of KDE generating the key request information C4 can be expressed as:

a_i=Random()

n_i=PRF(K,R_i)

A_i=a_i·g

C4＝Enc(PK1,ID_i||R_i||n_i||A_i)

Among them, "·" means dot product.

S402, KDE sends a key application request to the main KDC, and the key application request carries key application information C4.

S403. The master KDC verifies the key application information in the key application request.

The master KDC receives the key application request sent by KDE, uses SK1 in the private key of the master KDC to decrypt the key application information C4 in the key application request, and obtains the identification information ID_i, R_i, n_i and A_i of KDE. The master KDC calculates the authorization value AuthValue_I corresponding to the key application information based on ID_i, R_i, n_i and the character "MAC". The above process can be expressed as:

ID_i||R_i||n_i||A_i=Dec(SK1,C4)

AuthValue_I=AES-CMAC(n_i, ID_i||R_i||"MAC")

The master KDC searches the saved registration information AuthValue_i of the KDE according to the identification information ID_i of the KDE, and compares the authorization value AuthValue_I corresponding to the key application information with the registration information AuthValue_i of the KDE to verify the key application information. If the authorization value AuthValue_I corresponding to the key application information is consistent with the KDE registration information AuthValue_i, the verification is passed.

S404. The master KDC determines key generation information.

If the verification is passed, the master KDC determines the key generation information for the KDE. Exemplarily, the master KDC generates a random number b_i, and generates B_i according to the dot product of b_i and g, and A_i obtained by decrypting the key application information C4. The master KDC uses SK2 in the private key of the master KDC to encrypt the data obtained by splicing the identification information ID_i of KDE, the identification information ID_KDC of the master KDC and B_i through hash operation, and generates S_i according to the encrypted data and the random number b_i . The master KDC determines the key generation information C5 of the KDE according to n_i, the KDE identification information ID_i, the master KDC identification information ID_KDC, A_i, B_i, and S_i concatenated data. The process for the master KDC to determine the key generation information C5 can be expressed as:

b_i=Random()

B_i=b_i·g+A_i

S_i=b_i+Hash(ID_i||ID_KDC||B_i)SK2

C5＝AES-GCM(n_i, ID_i||ID_KDC||A_i||B_i||S_i)

Among them, AES-GCM () represents a symmetric encryption algorithm.

S405. The master KDC sends key generation information to KDE.

S406, KDE generates and saves an entity key of KDE according to the key generation information.

Wherein, KDE entity key Key_e may include KDE private key sk_i and KDE public key pk_i. KDE receives the secret key generation information C5 sent by the master KDC, extracts the identification information ID_i of KDE, the identification information ID_KDC, A_i, B_i and S_i of the master KDC from the secret key generation information C5, and generates the private key of KDE according to a_i and S_i sk_i, dot multiplication of KDE’s identification information ID_i, primary KDC’s identification information ID_KDC, and B_i concatenated data with PK2 in the saved central key of the primary KDC, and generate KDE based on the hash value of the point multiplication result and B_i The public key pk_i. KDE saves B_i, as well as KDE's private key sk_i and KDE's public key pk_i. The above process can be expressed as:

ID_i||ID_KDC||A_i||B_i||S_i＝AES-GCM(n_i,C5)

sk_i=a_i+S_i

pk_i=B_i+Hash(ID_i||ID_KDC||B_i)·PK2

Store(B_i,sk_i,pk_i)

The entity key Key_e generated by KDE can be used for authentication with another KDE during session establishment. For example, when the first service component requests the second service component to provide services, KDE1 deployed in the first service component and KDE2 deployed in the second service component are used to establish a data link between the first service component and the second service component or access channel, the process can Called the session establishment process. Wherein, both the first service component and the second service component may refer to any service component in the distributed storage system. During the session establishment process, KDE1 and KDE2 negotiate and determine the session key based on their respective entity keys, and perform authentication and information exchange based on the determined session key. Exemplarily, during the process of establishing a session, KDE1 and KDE2 negotiate and determine the session key based on the identification information and entity key of KDE1, the identification information and entity key of KDE2, the identification information of the master KDC and the central key, and Authentication and information exchange are performed based on the determined session key.

In an embodiment, during the session establishment process, KDE1 and KDE2 may negotiate to determine the session key. After determining the session key, KDE1 and KDE2 can use the implicit confirmation method for authentication based on the determined session key. Fig. 5 shows an interactive flowchart of a session establishment process between KDE1 and KDE2. As shown in Fig. 5, the session establishment process between KDE1 and KDE2 may include the following steps:

S501. KDE1 generates first session key negotiation information.

KDE1 generates a random number x, and obtains the first random factor X according to the point multiplication of the random number x and the preset parameter g. KDE1 generates the first session key negotiation information according to the first random factor X, the identification information ID_1 of KDE1 and the identification information ID_KDC of the master KDC. Exemplarily, KDE1 concatenates the identification information ID_1 and B_1 of KDE1, the first random factor X and the identification information ID_KDC of the master KDC to obtain the first session key negotiation information C6. Among them, B_1 is B_i generated by KDE1 during the key application process. The process of KDE1 generating the first session key negotiation information C6 can be expressed as:

x=Random()

X=x·g

C6＝ID_1||B_1||X||ID_KDC

S502. KDE1 sends first session key negotiation information to KDE2.

A data link is established between KDE1 and KDE2, or called an access channel, which can be understood as an access channel between the first service component and the second service component. KDE1 sends the first session key negotiation information C6 to KDE2 through the access channel.

S503, KDE2 confirms the access authority of KDE1.

KDE2 receives the first session key negotiation information C6 sent by KDE1, and obtains the identification information ID_1 of KDE1 from the first session key negotiation information C6. KDE2 checks whether KDE1 has access rights according to the identification information ID_1 of KDE1 and the saved white list or access control list (access control list, ACL), wherein, the identification information of all KDEs with access rights are stored in the white list; ACL The corresponding relationship between the identification information of each KDE and the access authority is stored in . If KDE1 has the access authority, continue to execute step S504, and if KDE1 does not have the access authority, disconnect the connection with KDE1.

S504, KDE2 generates a first session key according to the first session key negotiation information.

KDE2 generates a random number y, and obtains the second random factor Y according to the point multiplication of the random number y and the preset parameter g. KDE2 obtains the first random factor X and the identification information ID_KDC of the primary KDC from the first session key negotiation information, determines PK2 in the central key of the primary KDC according to the identification information ID_KDC of the primary KDC, and obtains the entity key of KDE2 The private key sk_2 in . KDE2 generates the first session key masterKey1 according to the first random factor X, the identification information ID_1 of KDE1, PK2 in the central key of the master KDC, the private key sk_2 of KDE2 and the second random factor Y. Exemplarily, KDE2 can perform a hash operation on the spliced data of KDE1's identification information ID_1 and master KDC's identification information ID_KDC and B_1, and according to the dot product of the result of the hash operation and PK2 in the master KDC's central key, And B_1, determine pkID1. KDE2 generates the first session key masterKey1 according to the dot product of the random number y and the sum of the first random factor X plus pkID1, and the dot product of KDE2’s private key sk_2 and the sum of pkID1 plus the first random factor X. The process of KDE2 generating the first session key masterKey1 can be expressed as:

y=Random()

Y=y·g

pkID1=B_1+Hash(ID_1||ID_KDC,B_1)·PK2

masterKey1=y·(X+pkID1)+sk_2·(pkID1+X)

Optionally, after KDE2 generates the first session key masterKey1, it can generate the first authentication key Kauth1 and the first encryption key KEnc1 according to the first session key masterKey1. The first authentication key Kauth1 and the first encryption key KEnc1 can also be understood as part of the first session key masterKey1. Exemplarily, KDE2 can concatenate B_1, B_2, identification information ID_1 of KDE1, identification information ID_2 of KDE2, first random factor X and second random factor Y to obtain W. According to the first session key masterKey1, W and The character "workKey" generates the first authentication key Kauth1 and the first encryption key KEnc1. The first authentication key Kauth1 and the first encryption key KEnc1 can be used to encrypt service data during subsequent transmission of service data. The above process can be expressed as:

W＝B_1||B_2||ID_1||ID_2||X||Y

Kauth1||KEnc1=PRF(masterKey1,W||"workKey").

S505. KDE2 generates second session key negotiation information.

KDE2 generates the second session key negotiation information according to the second random factor Y, the identification information ID_2 of KDE2, and the identification information ID_KDC of the master KDC. Exemplarily, KDE2 concatenates KDE2's identification information ID_2, B_2, the second random factor Y and the main KDC's identification information ID_KDC to obtain the second session key negotiation information C7, where B_1 is KDE2's key application process Generated B_i. The process of KDE2 generating the second session key negotiation information C7 can be expressed as:

C7＝ID_2||B_2||Y||ID_KDC

S506, KDE2 sends the second session key negotiation information to KDE1.

S507, KDE1 generates a second session key according to the second session key negotiation information.

KDE1 obtains the identification information ID_2 of KDE2, the second random factor Y, and the identification information ID_KDC of the master KDC from the second session key negotiation information, determines PK2 in the central key of the master KDC according to the identification information ID_KDC of the master KDC, and Obtain the private key sk_1 in the entity key of KDE1. KDE1 generates the second session key masterKey2 according to the first random factor X, the identification information ID_2 of KDE2, PK2 in the central key of the master KDC, the private key sk_1 of KDE1 and the second random factor Y. Exemplarily, KDE1 can perform hash operation on the spliced data of KDE2's identification information ID_2 and master KDC's identification information ID_KDC and B_2, and according to the dot product of the result of the hash operation and PK2 in the master KDC's central key, And B_2, determine pkID2. KDE1 generates the second session key masterKey2 according to the dot product of the random number x and the sum of the second random factor Y plus pkID2, and the dot product of KDE1's private key sk_1 and the sum of pkID2 plus the second random factor Y. The process of KDE1 generating the second session key masterKey2 can be expressed as:

pkID2=B_2+Hash(ID_2||ID_KDC,B_2)·PK2

masterKey2＝x·(Y+pkID2)+sk_1·(pkID2+Y)

Optionally, after KDE1 generates the second session key masterKey2, it may generate a second authentication key Kauth2 and a second encryption key KEnc2 according to the second session key masterKey2. The second authentication key Kauth2 and the second encryption key KEnc2 can also be understood as part of the second session key masterKey2. For example, KDE1 can concatenate B_1, B_2, identification information ID_1 of KDE1, identification information ID_2 of KDE2, the first random factor X and the second random factor Y to obtain W. According to the second session key masterKey2 and W, Generate a second authentication key Kauth2 and a second encryption key KEnc2. The second authentication key Kauth2 and the second encryption key KEnc2 can be used to encrypt service data during subsequent transmission of service data. The above process can be expressed as:

W＝B_1||B_2||ID_1||ID_2||X||Y

Kauth2||KEnc2＝PRF(masterKey2,W||"workKey")

The above process is the process of KDE1 and KDE2 negotiating to generate a session key. The second session key is generated in KDE1, and KDE2 After generating the first session key, KDE1 and KDE2 can exchange service data based on the session key generated through negotiation, and determine whether KDE1 and KDE2 have the same session key during the exchange of service data. For example, when KDE1 sends business data to KDE2, it encrypts the business data with the second session key, and KDE2 decrypts the encrypted business data with the first session key after receiving the encrypted business data sent by KDE1. If it can be successfully decrypted, KDE2 determines that the first session key is consistent with the second session key, and returns the response data to KDE1; otherwise, KDE2 considers that the first session key is inconsistent with the second session key, and KDE2 disconnects from KDE1. between access channels. When KDE2 disconnects from KDE1, it can send an authentication failure message to KDE1 or not. If KDE1 receives the response data returned by KDE2, it means that KDE1 and KDE2 have the same session key, indicating that ID_1 is the unique identification information of KDE1, ID_2 is the unique identification information of KDE2, and the authentication is passed; if KDE1 receives the authentication returned by KDE2 If the message fails or KDE1 detects that the access channel between KDE2 and KDE2 is disconnected, it means that the session keys of KDE1 and KDE2 are inconsistent, and the authentication fails.

Since the identification information of KDE1 and KDE2 used by KDE1 and KDE2 in the process of negotiating to generate a session key are unique, the session key generated through negotiation is also unique, which can prevent external malicious attacks and improve Session security.

The above method of confirming whether both parties have the same session key by transmitting service data may be called an implicit confirmation method.

In another embodiment, during the session establishment process, KDE1 and KDE2 may negotiate to determine the session key, and based on the determined session key, perform authentication in an explicit confirmation manner. Figure 6 shows an interactive flowchart of another session establishment process between KDE1 and KDE2, as shown in Figure 6, the session establishment process between KDE1 and KDE2 may include the following steps:

S601. KDE1 generates first session key negotiation information.

KDE1 generates a random number x, and obtains the first random factor X according to the point multiplication of the random number x and the preset parameter g. KDE1 generates the first session key negotiation information according to the first random factor X, the identification information ID_1 of KDE1 and the identification information ID_KDC of the master KDC. Exemplarily, KDE1 concatenates the identification information ID_1 and B_1 of KDE1, the first random factor X and the identification information ID_KDC of the master KDC to obtain the first session key negotiation information C6. The process of KDE1 generating the first session key negotiation information C6 can be expressed as:

x=Random()

X=x·g

C6＝ID_1||B_1||X||ID_KDC

S602. KDE1 sends first session key negotiation information to KDE2.

A data link is established between KDE1 and KDE2, or called an access channel, which can be understood as an access channel between the first service component and the second service component. KDE1 sends the first session key negotiation information C6 to KDE2 through the access channel.

S603, KDE2 confirms the access authority of KDE1.

KDE2 receives the first session key negotiation information C6 sent by KDE1, and obtains the identification information ID_1 of KDE1 from the first session key negotiation information C6. KDE2 checks whether KDE1 has access rights according to the identification information ID_1 of KDE1 and the saved white list or ACL. If KDE1 has the access authority, continue to execute step S504, and if KDE1 does not have the access authority, disconnect the access channel with KDE1.

S604, KDE2 generates a first session key according to the first session key negotiation information, and generates first session key verification information according to the first session key.

KDE2 generates a random number y, and obtains the second random factor Y according to the point multiplication of the random number y and the preset parameter g. KDE2 Obtain the first random factor X and the identification information ID_KDC of the primary KDC from the first session key negotiation information, determine the PK2 in the central key of the primary KDC according to the identification information ID_KDC of the primary KDC, and obtain the entity key of KDE2 private key sk_2. KDE2 generates the second session key masterKey2 according to the first random factor X, the identification information ID_1 of KDE1, PK2 in the central key of the master KDC, the private key sk_2 of KDE2 and the second random factor Y. Exemplarily, KDE2 can perform a hash operation on the spliced data of KDE1's identification information ID_1 and master KDC's identification information ID_KDC and B_1, and according to the dot product of the result of the hash operation and PK2 in the master KDC's central key, And B_1, determine pkID1. KDE2 generates the first session key masterKey1 according to the dot product of the random number y and the sum of the first random factor X plus pkID1, and the dot product of KDE2’s private key sk_2 and the sum of pkID1 plus the first random factor X. The process of KDE2 generating the first session key masterKey1 can be expressed as:

y=Random()

Y=y·g

pkID1=B_1+Hash(ID_1||ID_KDC,B_1)·PK2

masterKey1=y·(X+pkID1)+sk_2·(pkID1+X)

After KDE2 generates the first session key masterKey1, it may generate first session key verification information Mac1 according to the first session key masterKey1. For example, KDE2 can concatenate B_1, B_2, identification information ID_1 of KDE1, identification information ID_2 of KDE2, the first random factor X and the second random factor Y to obtain W. According to the first session key masterKey1 and W, Generate Kmac1, and then generate first session key verification information Mac1 according to Kmac1. The above process can be expressed as:

W＝B_1||B_2||ID_1||ID_2||X||Y

Kmac1=PRF(masterKey1,W||"MAC")

Mac1=AES-CMAC(Kmac1,W||"1")

S605. KDE2 generates second session key negotiation information, where the second session key negotiation information includes first session key verification information.

KDE2 generates the second session key negotiation information according to the second random factor Y, the identification information ID_2 of KDE2, the identification information ID_KDC of the master KDC, and the first session key verification information Mac1. Exemplarily, KDE2 concatenates the identification information ID_2 and B_2 of KDE2, the second random factor Y, the identification information ID_KDC of the master KDC and the first key verification information Mac1 to obtain the second session key negotiation information C7. The process of KDE2 generating the second session key negotiation information C7 can be expressed as:

C7＝ID_2||B_2||Y||ID_KDC||Mac1

S606, KDE2 sends the second session key negotiation information to KDE1.

S607, KDE1 generates a second session key according to the second session key negotiation information, and generates first key confirmation information according to the second session key.

KDE1 obtains the identification information ID_2 of KDE2, the second random factor Y, and the identification information ID_KDC of the master KDC from the second session key negotiation information, determines PK2 in the central key of the master KDC according to the identification information ID_KDC of the master KDC, and Obtain the private key sk_1 in the entity key of KDE1. KDE1 generates the second session key masterKey2 according to the first random factor X, the identification information ID_2 of KDE2, PK2 in the central key of the master KDC, the private key sk_1 of KDE1 and the second random factor Y. Exemplarily, KDE1 can perform hash operation on the spliced data of KDE2's identification information ID_2 and master KDC's identification information ID_KDC and B_2, and according to the dot product of the result of the hash operation and PK2 in the master KDC's central key, And B_2, determine pkID2. KDE1 generates the second session key masterKey2 according to the dot product of the random number x and the sum of the second random factor Y plus pkID2, and the dot product of KDE1's private key sk_1 and the sum of pkID2 plus the second random factor Y. The process of KDE1 generating the second session key masterKey2 can be expressed as:

pkID2=B_2+Hash(ID_2||ID_KDC,B_2)·PK2

masterKey2＝x·(Y+pkID2)+sk_1·(pkID2+Y)

After KDE1 generates the second session key masterKey2, it may generate first key confirmation information according to the second session key masterKey2. For example, KDE1 can concatenate B_1, B_2, identification information ID_1 of KDE1, identification information ID_2 of KDE2, the first random factor X and the second random factor Y to obtain W. According to the first session key masterKey1 and W, Generate Kmac2, and then generate the first secret key confirmation information Mac1Local according to Kmac2. The above process can be expressed as:

W＝B_1||B_2||ID_1||ID_2||X||Y

Kmac2=PRF(masterKey2,W||"MAC")

Mac1Local=AES-CMAC(Kmac2,W||"1")

S608. If the first key confirmation information generated by KDE1 is consistent with the first session key verification information carried in the second session key negotiation information, KDE1 generates second session key verification information.

KDE1 verifies whether the generated first key confirmation information Mac1Local is consistent with the first session key verification information Mac1 carried in the second session key negotiation information. If they are consistent, that is, Mac1Local==Mac1, then KDE1 generates the second session key verification information according to the second session key masterKey2, otherwise, KDE1 disconnects the access channel with KDE2, and then tries to establish a connection again. Exemplarily, if Mac1Local==Mac1, KDE1 may generate second session key verification information Mac2 according to Kmac2 obtained in the above steps, and assign the second session key verification information Mac2 to C8. The process can be expressed as:

Mac2=AES-CMAC(Kmac2,W||"2")

C8 = Mac2

Optionally, KDE1 may generate a second authentication key Kauth2 and a second encryption key KEnc2 according to the second session key masterKey2 and W. The second authentication key Kauth2 and the second encryption key KEnc2 can be used to encrypt service data during subsequent transmission of service data. The above process can be expressed as:

Kauth2||KEnc2＝PRF(masterKey2,W||"workKey")

S609, KDE1 sends the second session key verification information to KDE2.

KDE1 sends information C8 to KDE2, C8=Mac2.

S610, KDE2 generates second key confirmation information, and verifies whether the second key confirmation information is consistent with the second session key verification information.

KDE2 may generate second key confirmation information according to the second session key masterKey2. Exemplarily, KDE2 may generate second key confirmation information Mac2Local according to Kmac1 generated in step S604. The above process can be expressed as:

Mac2Local=AES-CMAC(Kmac1,W||"2")

KDE2 verifies whether the generated second key confirmation information Mac2Local is consistent with the received second session key verification information Mac2. If they are consistent, that is, Mac2Local==Mac2, it is determined that KDE1 and KDE2 have the same session key, that is, the first session key generated in the above steps is consistent with the second session key, indicating that ID_1 is the unique identification information of KDE1, ID_2 It is the unique identification information of KDE2, and the authentication is passed. KDE1 and KDE2 can exchange business data through the established access channel. Otherwise, KDE2 determines that the first session key is inconsistent with the second session key, the authentication fails, and KDE2 disconnects the access channel with KDE1.

Optionally, after or before the authentication is passed, KDE2 may generate the first authentication key Kauth1 and the first encryption key KEnc1 according to the first session key masterKey1 and W. The first authentication key Kauth1 and the first encryption key KEnc1 can be used to encrypt service data during subsequent transmission of service data. The above process can be expressed as:

Kauth1||KEnc1＝PRF(masterKey1,W||"workKey")

In the above process, KDE1 and KDE2 negotiate to generate a session key, and send session key verification information to each other to confirm whether the two parties have the same session key, which can be called an explicit confirmation method.

The explicit confirmation method authenticates by sending session key verification information to each other instead of transmitting business data, so there is no requirement for business data. The implicit confirmation method is authenticated through the transmission of business data, which can reduce one data interaction, so the performance is higher. In actual use, you can choose to use the explicit confirmation method or the implicit confirmation method according to the actual needs of different business scenarios.

In the embodiment of this application, KDE is deployed in each service component, and an access channel is established between two service components through the KDE deployed in the service component. During the process of establishing the access channel, the two KDEs determine the same The method of session secret key is used for mutual authentication without digital certificate authentication, which reduces the complexity of management; at the same time, it does not need to use complex digital certificate authentication algorithms, which can improve authentication efficiency and system performance.

In the embodiment of this application, the KDE of each service component initiates the registration process and key application process to the KDC only when it is started for the first time or when the entity key is lost, and saves the generated entity key in preparation for establishing with other KDEs. Negotiate the session key to use during the session. In the embodiment of the present application, when two KDEs establish a session, one of the KDEs does not need to apply for the session key of the session from the KDC, that is, there is no need for the KDE to visit the KDC before each session is established, thereby greatly reducing the number of communications between the KDE and the KDC , reduce the number of times KDC is accessed, avoid the performance bottleneck caused by blocking caused by a large number of accesses to KDC, and can reduce the data processing pressure of KDC, and improve the performance and reliability of KDC. At the same time, it can avoid the problem that the KDC saves the session keys of all sessions, which leads to the loss of security of the entire system due to the KDC being invaded.

Moreover, the two KDEs in the embodiment of the present application use the identification information of the two KDEs when negotiating to generate the session key, so that the two KDEs can authenticate each other through the session key to realize the function of access control. The two KDEs in the embodiment of this application use dot multiplication instead of traditional digital signatures when negotiating to generate session keys, and the calculation speed is about 10 times that of digital certificate-based authentication.

In some embodiments, in order to further ensure the security of each key and prevent the key from being leaked or cracked, the central key of each KDC and the entity key of each KDE can be updated according to a set time period, exemplarily , the set time period can be several hours, one day or one week. The key update process is similar to the KDE registration process shown in Figure 3, and it can be understood that each KDE re-registers with each KDC.

Still taking the interaction process between a KDE and a KDC as an example, the key update process may include the following steps: KDE downloads new key information from the KDC, and KDE extracts the new ID and new center of the KDC from the new key information key and save it. KDE generates new registration information. The process of KDE generating new registration information can be performed by referring to the process of generating registration information in step S304 above, and details will not be repeated here. KDE generates a new data packet C3_new according to KDE’s identification information and new registration information. KDE sends the old data packet C3 and the new data packet C3_new to the KDC. The KDC verifies the old data packet C3. After the verification is passed, the KDC To register a new data packet C3_new, that is, to store the identification information of KDE and the new registration information.

After KDE updates the registration information to each KDC, it obtains a new entity key. Exemplarily, KDE generates new key application information C4_new according to the identification information of KDE and the new central key of the main KDC. The process of KDE generating new key application information C4_new can refer to the above step S401 to generate key application information The process execution of C4 will not be repeated here. KDE sends a key application request to the master KDC, and the key application request carries new key application information C4_new. The main KDC verifies the new key application information C4_new according to the saved new registration information of the KDE. After the verification is passed, the main KDC sends new key generation information to KDE, and KDE generates a new entity based on the new key generation information key and save it.

Exemplarily, if KDE1 or KDE2 updates the key during the session establishment process, in order to avoid service interruption, the session establishment process can still continue without updating the session key. When the session duration expires or a new session establishment process is initiated, a new session key is renegotiated.

During the above session establishment process, considering reasons such as key update and KDC active-standby switchover, the central key of the KDC used by KDE1 and KDE2 may be inconsistent when generating session keys, so that KDE1 and KDE2 cannot generate the same session key. In order to avoid the occurrence of the above situation, in the embodiment of this application, KDE1 sends KDE2 the first session key agreement The provider information carries the identification information of the primary KDC, and KDE2 also carries the identification information of the primary KDC in the second session key negotiation information sent to KDE1, so that KDE1 and KDE2 can generate session keys based on the same KDC central key , to avoid the inconsistency of the session key caused by the inconsistency of the central key of the KDC used. To sum up, each KDE stores the central key of a different KDC, and the two KDEs determine the common KDC through negotiation, which can avoid the problem of data out-of-sync during KDC master-standby switchover, and solve the problem of master-standby How to synchronize the two KDE keys during switching.

In some embodiments, if there are multiple sets of valid KDC information stored in KDE1, the first session key negotiation information sent to KDE2 may also carry identification information of multiple KDCs, that is, the first session key negotiation information The identification information of the master KDC carried in the KDC may include the identification information of multiple KDCs. KDE2 selects a valid identification information of the target KDC from the identification information of multiple KDCs, and generates the first session key according to the central key of the target KDC. key. KDE2 carries the identification information of the target KDC in the second session key negotiation information sent to KDE1, so that KDE1 generates the second session key according to the central key of the target KDC, thus ensuring that KDE1 and KDE2 use the same KDC central The secret key generates a session key.

In some embodiments, if the administrator finds that some keys are leaked, the key revocation process can be initiated at the management node. A management node can be understood as a control device, virtual device or control component that can communicate with the master KDC. The administrator can determine the relevant information of the leaked secret key, and input the relevant information of the leaked secret key into the management node, and the management node can generate a revocation list (revocation list, RL) according to the relevant information of the leaked secret key input by the administrator, and send the RL to to the master KDC. Wherein, the relevant information of the leaked key may include the identification information of the KDE corresponding to the leaked entity key or the identification information of the KDC corresponding to the leaked central key. The primary KDC signs the received RL, that is, the primary KDC signs the RL and distributes it to each standby KDC, so that each standby KDC updates the saved RL.

KDE can download RL from KDC according to the set time interval, and delete the leaked central key and the corresponding identification information of KDC according to RL. In the process of establishing a session with other KDEs, KDE can determine whether the entity key of the peer end is revoked according to the downloaded RL. For example, after KDE2 above receives the first session key negotiation information sent by KDE1, it can obtain the identification information ID_1 of KDE1 carried in it, and check whether the downloaded RL contains the identification information ID_1 of KDE1. The entity key of KDE1 has been revoked due to leakage. At this time, the connection with KDE1 is not safe. KDE2 disconnects the connection with KDE1; By revoking the leaked secret key, the security of the system can be further improved.

FIG. 7 shows a schematic structural diagram of another device cluster system provided by an embodiment of the present application. As shown in FIG. 7, in other embodiments, the device cluster system may also include a key distribution agent (Key Distribution Agent, KDA) in addition to multiple KDEs and multiple KDCs. The device cluster system can also be applied to the application scenario shown in Figure 1. A KDA can be deployed in each control device, and the KDA in a control device can act as an agent for the data communication between each KDE and KDC in the control device. , that is, each KDE deployed in the same control device as the KDA performs data communication with the KDA, and the KDA performs data communication with each KDC. Usually, there are multiple service components in one control device, and one KDE is deployed in each service component. KDE in multiple service components is connected to KDC through one KDA. The number of KDAs connected to KDC is much smaller than the number of KDEs, so it can Reduce the number of KDC external communication interfaces occupied. The KDA in a control device can save the entity key of each KDE in the control device. For example, the KDA can store the entity key of each KDE and the identification information correspondingly, avoiding the inconvenience caused by multiple KDEs separately storing the key. The problem of safe storage of secret keys. KDA can use trusted platform module (trusted platform module, TPM), trusted execution environment (trusted execution environment, TEE) and other secure storage mechanisms to store secret keys, which can ensure no interference from conventional operating systems and further improve the security of secret keys , to reduce the risk of key leakage.

In this embodiment, KDE can establish a connection with the KDA in the control device through the communication mechanism in the operating system (Operating System, OS) of the control device at each startup. The KDE can be any KDE. KDA can use the authentication mechanism that comes with the OS, such as domain socket (domain socket), shared memory, etc., combined with the white name Confirm the legitimacy of KDE by other means such as list or ACL. Since KDA stores the entity keys of each KDE in the control device, KDE can request KDA to obtain its entity keys. Exemplarily, KDE can send a key acquisition request to KDA, and the key acquisition request can carry the identification information ID_i of KDE, and KDA can check whether the entity key of KDE is saved according to the identification information ID_i of KDE. The entity key of the KDE, then send the entity key of the KDE to KDE; if the entity key of the KDE is not found, for example, the KDE has not applied for the entity key for the first deployment, or the entity key of the KDE is lost or is revoked, KDA sends an acquisition failure message to KDE. KDE receives the acquisition failure message sent by KDA, and performs the registration process with each KDC respectively. The following takes the registration process with any KDC as an example to illustrate.

Any KDE can communicate with KDC through the KDA in its control device. When KDE communicates with KDC through KDA, the registration process of KDE is shown in Figure 8, which can include the following steps:

S801. KDE sends a KDC key information request to KDA.

KDA stores KDC's secret key message, that is, before KDE sends KDC secret key message request to KDA, KDA has obtained its secret key message from KDC in advance and saved it. Exemplarily, KDA can obtain its secret key information from KDC in the following manner: KDA can exchange information with KDC through a secure channel, which can be a dedicated channel during deployment, a management channel, or a TLS security channel established based on a certificate. channel, which is not limited in this application. KDA sends KDC key information acquisition request to KDC, KDC key information acquisition request carries KDA identification information, and uses random number C1 to encrypt KDA identification information. After receiving the KDC key information acquisition request sent by the KDA, the KDC uses the random number C1 to decrypt the information carried in the KDC key information acquisition request to obtain the identification information of the KDA. According to the identification information of KDA, KDC sends the secret key information of KDC to the KDA. The key information may include the identification information of KDC and the central secret key of KDC. The central secret key of KDC can be understood as the public key AKey_pub of KDC. Included in the KDC's public key information C2, the public key information C2 is obtained by encrypting the KDC's public key AKey_pub with an encryption algorithm, and the KDC's public key AKey_pub can be composed of two parts, PK1 and PK2. Therefore, the public key information C2 of the KDC can be expressed as: C2=PK1||PK2||CipherSuite. KDA receives and saves the key information of KDC.

S802. The KDA sends the key information of the KDC to the KDE.

The KDC key information request sent by KDE to KDA carries the identification information of KDE, and uses the random number C1 to encrypt the identification information of KDE. After receiving the KDC key information request sent by KDE, KDA uses the random number C1 to decrypt the information carried in the KDC key information request to obtain the identification information of KDE. KDA sends KDC's secret key information to KDE according to KDE's identification information. KDE extracts the identification information of KDC and PK1 and PK2 in the central key of KDC from the secret key information of KDC sent by KDA, and saves them.

S803. KDE generates registration information.

KDE generates a random number K and a random number Nonce, splices the KDE identification information ID_i and the random number Nonce, generates R_i according to the random number K and the spliced data, and then generates n_i according to the random number K and R_i; according to n_i, and The spliced data of ID_i, R_i and the character "MAC" generates the registration information AuthValue_i. The above process of KDE generating registration information AuthValue_i can be expressed as:

K=Random()

Nonce=Random()

R_i=PRF(K,ID_i||Nonce)

n_i=PRF(K,R_i)

AuthValue_i=AES-CMAC(n_i, ID_i||R_i||"MAC")

S804, KDE sends KDE registration information to KDA.

When KDE sends registration information to KDA, it can use KDE's identification information ID_i and KDE's registration information AuthValue_i is sent to KDA together. Exemplarily, KDE can use PK1 in the central key of KDC to encrypt the data after the concatenation of KDE's identification information ID_i and KDE's registration information AuthValue_i to obtain data packet C3, and send the data packet C3 to KDA. Wherein, the data packet C3 can be expressed as: C3=Enc(PK1, ID_i||AuthValue_i).

S805. The KDA sends the KDE registration information to the KDC.

S806. The KDC saves the registration information of the KDE.

KDC receives the data packet C3 sent by KDA, and can use SK1 in the private key of KDC to decrypt the data packet C3 sent by KDA, obtain the identification information ID_i of KDE and the registration information AuthValue_i of KDE, and save them. The process can be expressed as:

ID_i||AuthValue_i=Dec(SK1,C3)

Store(ID_i, AuthValue_i)

S807. The KDC sends a registration completion notification to the KDA.

S808, KDA sends a registration completion notification to KDE.

S809, KDE sends the information to be saved to KDA.

S810. The KDA saves the information to be saved sent by the KDE.

Wherein, the information to be saved may include the identification information ID_i of KDE, and the random number K and data R_i used in the process of generating the registration information. This process can be expressed as: Store(ID_i, K, R_i).

Optionally, after KDA saves the information to be saved sent by KDE, it may also send a notification of successful saving to KDE.

Through the above registration process, KDE can store the identification information and central key of each online KDC, and each KDC can store the identification information ID_i and registration information AuthValue_i of all registered KDEs.

After KDE completes the above registration process, it can initiate a key application process to the main KDC through the KDA in the control device. As shown in Figure 9, the key application process may include the following steps:

S901. KDE generates key application information.

KDE generates random number a_i, and generates n_i according to R_i and random number K generated during the registration process. KDE obtains A_i based on the dot product of a_i and g, where g is a preset parameter. KDE uses PK1 in the central key of the main KDC to encrypt the data obtained by concatenating KDE's identification information ID_i, the above-mentioned R_i, n_i, and A_i, and obtain the key application information C4. The process of KDE generating the key request information C4 can be expressed as:

a_i=Random()

n_i=PRF(K,R_i)

A_i=a_i·g

C4＝Enc(PK1,ID_i||R_i||n_i||A_i)

S902. KDE sends a key application request to KDA.

Among them, KDA is the KDA deployed in the control device to which KDE belongs. The key application request carries the key application information C4.

S903. The KDA sends a key application request to the master KDC.

Exemplarily, KDA can access the master KDC through a floating Internet Protocol (IP) address, that is, KDA sends a secret key application request to a set target IP address, and KDA does not perceive which KDC provides services for it, but Each KDC negotiates to determine which KDC is currently the primary KDC, and the primary KDC receives the key application request sent to the target IP address and responds to the key application request.

S904. The master KDC verifies the key application information in the key application request.

The master KDC receives the key application request sent by KDA, uses SK1 in the private key of the master KDC to decrypt the key application information C4 in the key application request, and obtains the identification information ID_i, R_i, n_i and A_i of KDE. The master KDC calculates the authorization value AuthValue_I corresponding to the key application information based on ID_i, R_i, n_i and the character "MAC". The above process can Expressed as:

ID_i||R_i||n_i||A_i=Dec(SK1,C4)

AuthValue_I=AES-CMAC(n_i, ID_i||R_i||"MAC")

The master KDC searches the saved registration information AuthValue_i of the KDE according to the identification information ID_i of the KDE, and compares the authorization value AuthValue_I corresponding to the key application information with the registration information AuthValue_i of the KDE to verify the key application information. If the authorization value AuthValue_I corresponding to the key application information is consistent with the KDE registration information AuthValue_i, the verification is passed.

S905. The master KDC determines key generation information.

If the verification is passed, the master KDC determines the key generation information for the KDE. Exemplarily, the master KDC generates a random number b_i, and generates B_i according to the dot product of b_i and g, and A_i obtained by decrypting the key application information C4. The master KDC uses SK2 in the private key of the master KDC to encrypt the data obtained by splicing the identification information ID_i of KDE, the identification information ID_KDC of the master KDC and B_i through hash operation, and generates S_i according to the encrypted data and the random number b_i . The master KDC determines the key generation information C5 of the KDE according to n_i, the KDE identification information ID_i, the master KDC identification information ID_KDC, A_i, B_i, and S_i concatenated data. The process for the master KDC to determine the key generation information C5 can be expressed as:

b_i=Random()

B_i=b_i·g+A_i

S_i=b_i+Hash(ID_i||ID_KDC||B_i)SK2

C5＝AES-GCM(n_i, ID_i||ID_KDC||A_i||B_i||S_i)

S906, the master KDC sends secret key generation information to the KDA.

S907, KDA sends secret key generation information to KDE.

S908, KDE generates an entity key of KDE according to the key generation information.

Wherein, KDE entity key Key_e may include KDE private key sk_i and KDE public key pk_i. KDE receives the secret key generation information C5 sent by the master KDC, extracts the identification information ID_i of KDE, the identification information ID_KDC, A_i, B_i and S_i of the master KDC from the secret key generation information C5, and generates the private key of KDE according to a_i and S_i sk_i, dot multiplication of KDE’s identification information ID_i, primary KDC’s identification information ID_KDC, and B_i concatenated data with PK2 in the saved central key of the primary KDC, and generate KDE based on the hash value of the point multiplication result and B_i The public key pk_i. The above process can be expressed as:

ID_i||ID_KDC||A_i||B_i||S_i＝AES-GCM(n_i,C5)

sk_i=a_i+S_i

pk_i=B_i+Hash(ID_i||ID_KDC||B_i)·PK2

S909, KDE sends KDE's entity key to KDA.

S910. The KDA saves the KDE entity key.

KDE sends B_i, KDE private key sk_i and KDE public key pk_i to KDA for storage. The process can be expressed as:

Store(B_i,sk_i,pk_i)

Optionally, after KDA saves the entity key sent by KDE, it can also send a notification that the key has been saved to KDE.

KDE completes the key application process and sends the generated entity key to KDA for storage. When KDE starts up again, KDE's entity key can be obtained from KDA for authentication with another KDE during session establishment.

The process of establishing a session between two KDEs can be performed with reference to the flow shown in FIG. 5 or FIG. 6 above, and will not be repeated here.

The key update process is similar to the first key application, including the registration phase and the key application phase. When KDE communicates with KDC through KDA, the registration phase of the secret key update process is shown in Figure 10, which may include the following steps:

S1001. The KDA sends a KDC key information update request to the KDC.

KDA can be understood as any KDA, and KDC can be understood as any KDC. The KDC key information update request carries the identification information of the KDA, and uses the random number C1 to encrypt the identification information of the KDA.

S1002. The KDC sends the new key information of the KDC to the KDA.

After receiving the KDC key information update request sent by the KDA, the KDC uses the random number C1 to decrypt the information carried in the KDC key information update request to obtain the identification information of the KDA. The KDC sends the new key information of the KDC to the KDA according to the identification information of the KDA. The new key information may include the new identification information of the KDC and the new central key of the KDC, wherein the new central key of the KDC is contained in the KDC's In the new public key information C2, the new public key information C2 is obtained by encrypting the KDC's new central key with an encryption algorithm, and the KDC's new central key may include PK1_New and PK2_New. Therefore, the new public key information C2 of the KDC can be expressed as: C2 = PK1_New, PK2_New, CipherSuite. KDA receives and saves the new key information of KDC.

S1003. KDE sends a KDC key update request to KDA.

S1004, the KDA sends the new key information of the KDC to the KDE.

KDE extracts the new identification information of KDC and the new central key from the new key information of KDC and saves them.

S1005, KDE generates new registration information.

The process of KDE generating new registration information can be performed with reference to the process of KDE generating registration information in step S803, and will not be repeated here.

S1006, KDE sends old registration information and new registration information to KDA.

KDE generates new data message C3_new according to KDE's identification information and new registration information, and KDE sends old data message C3 and new data message C3_new to KDA. The process can be expressed as:

Register(C3,C3_New)

S1007, the KDA sends the old registration information and the new registration information of KDE to the KDC.

S1008. The KDC saves the new registration information of the KDE.

The KDA sends the old data packet C3 and the new data packet C3_new to the KDC. The KDC verifies the old data message C3, and after the verification is passed, the KDC registers the new data message C3_new, that is, extracts the KDE identification information and new registration information from the new data message C3_new, and saves them. The process can be expressed as:

Store(ID_i, AuthValue_i_New)

S1009, the KDC sends a notification that the registration information has been updated to the KDA.

S1010, the KDA sends a notification that the registration information has been updated to the KDE.

S1011, KDE sends information to be updated to KDA.

S1012. The KDA saves the information to be updated sent by the KDE.

Wherein, the information to be saved may include identification information ID_i of KDE, and random number K_new and data R_i_new used in the process of generating new registration information. This process can be expressed as: Store(ID_i, K_new, R_i_new).

Optionally, after KDA saves the information to be updated sent by KDE, it can also send an update success notification to KDE.

When KDE communicates with KDC through KDA, the key application phase of the key update process is shown in Figure 11, which may include the following steps:

S1101. KDE sends new key application information to KDA.

After KDE updates the registration information to each KDC, it needs to obtain a new entity key. KDE can generate new key application information C4_new according to the identification information of KDE and the new central key of the main KDC. The process of KDE generating new key application information C4_new can be performed by referring to the process of generating key application information C4 in the above step S901. I won't repeat them here. KDE sends a new key application request to KDA, and the new key application request carries the new key application information C4_new.

S1102, the KDA sends KDE's new key application information to the master KDC.

S1103, the master KDC sends new secret key generation information to the KDA.

The master KDC verifies the new key application information C4_new according to the saved new registration information of the KDE. After the verification is passed, the master KDC determines the new key generation information C5_new for the KDE. The process for the KDC to determine the new key generation information C5_new may be performed by referring to the process for determining the key generation information C5 in the above step S905, which will not be repeated here. The master KDC sends the new key generation information C5_new to the KDA.

S1104, KDA sends new secret key generation information to KDE.

S1105, KDE generates a new KDE entity key according to the new key generation information.

KDE's new entity key may include KDE's new private key sk_i_new and KDE's new public key pk_i_new. The process of KDE generating a new entity key can be performed by referring to the process of generating an entity key in step S908 above, and will not be repeated here.

S1106, KDE sends KDE's new entity key to KDA.

S1107, KDA saves the new entity key of KDE.

KDE sends B_i_new used in the process of generating the new entity key, as well as KDE's new private key sk_i_new and KDE's new public key pk_i_new to KDA for storage. The process can be expressed as:

Store(B_i_new, sk_i_new, pk_i_new)

Optionally, after KDA saves the new entity key sent by KDE, it can also send a key update success notification to KDE.

Exemplarily, if KDE1 or KDE2 updates the key during the session establishment process, in order to avoid service interruption, the session establishment process can still continue without updating the session key. When the session duration expires or a new session establishment process is initiated, a new session key is renegotiated.

When the device cluster system includes KDA, the key revocation process is shown in Figure 12, which may include the following steps:

S1201. The management node sends a key revocation instruction to the master KDC.

If the administrator finds that some keys are leaked, the key revocation process can be initiated on the management node. A management node can be understood as a control device, virtual device or control component that can communicate with the master KDC. The management node can generate RL according to the relevant information of the leaked key input by the administrator, and send the key revocation command to the main KDC, and the key revocation command carries the RL. Wherein, the relevant information of the leaked key may include the identification information of the KDE corresponding to the leaked entity key or the identification information of the KDC corresponding to the leaked central key.

S1202. The master KDC signs the RL carried in the key revocation command.

S1203. The master KDC sends the signed RL to the KDA.

Wherein, the KDA is a KDA deployed in the same control device as the main KDC. This step can also be understood as, the KDA downloads the RL from the master KDC.

S1204. The KDA sends the signed RL to each standby KDC respectively.

The above step S1203 and step S1204 can also be understood as, the active KDC distributes the signed RL to each standby KDC through the KDA deployed in the same control device as the active KDC. In Fig. 12, only one standby KDC is used for illustration.

S1205. The standby KDC updates the saved RL according to the received RL.

Each standby KDC updates the stored RL based on the newly received RL.

KDE can download RL from KDC through KDA according to the set time interval, and delete the leaked central key and the corresponding identification information of KDC according to RL. In the process of establishing a session with other KDEs, KDE can determine whether the entity key of the peer end is revoked according to the downloaded RL.

In some embodiments, multiple KDEs deployed in the same control device can respectively obtain different entity keys through the registration process shown in FIG. 8 and the key application process shown in FIG. 9 . In some other embodiments, in order to further reduce resource consumption, the execution times of the key application process can be reduced, and multiple KDEs deployed in the same control device can share the real body secret key. That is to say, a control device can generate a common entity key, which is shared by all KDEs in the control device. Exemplarily, a control device may generate a common entity key through a KDA deployed in the control device. The process of KDA generating a common entity key is similar to the process of KDE generating an entity key, including the KDA registration process and the KDA key generation process. Wherein, the registration process of KDA can be performed with reference to the registration process of KDE shown in FIG. 3 , and the process of KDA generating a key can be performed with reference to the process of KDE generating an entity key shown in FIG. 4 , which will not be repeated here.

When each KDE in the control device is started, the common entity key can be obtained from the KDA in the control device. Take KDE1 as an example for illustration. KDE1 is KDE deployed in the first service component of control device A. When KDE1 starts, it obtains the common entity key from KDA in control device A. The common entity key is the Entity key shared by all KDEs. In the process of establishing a session with KDE2 deployed in other control devices, KDE1 will add the identification information of KDE1 in addition to using the common entity key. Since the identification information of KDE1 is unique, it can still be guaranteed that KDE1 and KDE2 negotiates the uniqueness of the generated session keys. By sharing a common entity key with all KDEs in the same control device, the number of entity keys stored in each control device can be significantly reduced, and without the need for each KDE to perform a separate registration process, the registration information stored in the KDC can be reduced to improve the performance of the device cluster system.

In some embodiments, when all KDEs in the same control device share a common entity key, KDA can update the common entity key according to a set time period, generate and save a new common entity key. The common entity key update process can be performed by referring to the KDE key update process described above, and will not be repeated here.

In some embodiments, when all KDEs in the same control device share a common entity key, the key revocation process may include the following steps: the management node sends a key revocation command to the master KDC, and the key revocation command carries RL . The RL includes related information about the leaked key, that is, related information about the revoked key. The related information about the leaked key may include the identification information of all KDEs in the same control device corresponding to the leaked common entity key or the leaked The identification information of the KDC corresponding to the central key. The primary KDC signs the RL carried in the received key revocation command, and the primary KDC distributes the signed RL to each standby KDC through the KDA deployed in the same control device, so that each standby KDC updates the saved RL.

KDE can download RL from KDC through KDA according to the set time interval, and delete the leaked central key and the corresponding identification information of KDC according to RL. In the process of establishing a session with other KDEs, KDE can determine whether the common entity key of the other end is revoked according to the downloaded RL.

Based on the same inventive concept as the above-mentioned embodiments, the embodiments of the present application further provide a control device, which can be applied to the above-mentioned device cluster system.

Fig. 13 exemplarily shows a schematic structural diagram of a control device provided by an embodiment of the present application. As shown in FIG. 13 , in some embodiments, the control device 100 may include KDC and at least one service component, and KDE is deployed in each service component. It can also be understood that the control device 100 includes the first service component, the second A first key distribution entity KDE is deployed in a service component.

The KDC may be used to provide key generation information for the first KDE in response to the key application request of the first KDE. The first KDE is used to generate the first entity key according to the key generation information provided by the KDC. Exemplarily, the first KDE may send a key application request to the KDC when it is started for the first time or when the entity key is lost, and the KDC provides key generation information for the first KDE in response to the key application request of the first KDE.

The first KDE can also be used to send the identification information of the first KDE and the identification information of the KDC to the second KDE during the process of establishing a session with the second KDE, so that the second KDE can use the entity key of the second KDE, the second KDE The identification information of the KDE and the identification information of the KDC generate a session key for authentication between the first KDE and the second KDE; the first KDE receives the identification information of the second KDE and the identification information of the KDC sent by the second KDE , generating a session key for authentication between the first KDE and the second KDE according to the first entity key, the identification information of the second KDE, and the identification information of the KDC. Wherein, the second KDE is deployed in the service component of the second control device in the device cluster system.

In a possible implementation, the KDC can also be used to: receive and save the registration information of each KDE included in the device cluster system; and when receiving the key application request of the first KDE, include the Verify the consistency between the carried key application information and the saved registration information of the first KDE, and provide key generation information for the first KDE after the verification is passed.

In a possible implementation manner, the first KDE may also be used to: obtain and save the identification information and the central key of the KDC. When negotiating with the second KDE to generate a session key, the first KDE can obtain the central key of the KDC according to the identification information of the KDC, and generate a session key based on the first entity key, the identification information of the second KDE, and the central key of the KDC session key.

In a possible implementation, the KDC can also be used to: receive the key revocation command sent by the management node, sign the revocation list carried in the key revocation command and distribute it to the standby KDC of the KDC; the revocation list includes the The KDE identification information corresponding to the leaked entity key and/or the KDC identification information corresponding to the leaked central key.

Fig. 14 exemplarily shows a schematic structural diagram of another control device provided by an embodiment of the present application. As shown in FIG. 14 , in some other embodiments, the control device 200 may include KDC, KDA and at least one service component, and KDE is deployed in each service component. Wherein, KDA is used to save the KDE entity key included in each service component in the first control device, including the first entity key; correspondingly, the first KDE is also used to store the first entity key after generating the first entity key , saving the first entity key in the KDA of the first control device, and obtaining the first entity key from the KDA of the first control device at each startup.

In a possible implementation manner, each KDE in the first control device may also perform information transmission with each KDC through the KDA of the first control device. Exemplarily, the KDA of the first control device can also be used to: receive the key application request sent by the first KDE, and forward the key application request of the first KDE to the KDC; and receive the key generation information sent by the KDC, and The key generation information is forwarded to the first KDE.

It can be understood that the structure shown in the embodiment of the present application does not constitute a specific limitation on the control device. In some other embodiments of the present application, the control device may include more or less components than shown in the illustration, or combine some components, or separate some components, or arrange different components. The illustrated components can be realized in hardware, software or a combination of software and hardware.

Based on the same inventive concept as the above-mentioned embodiment, the embodiment of the present application further provides a method for generating a session key, which can be applied to the control device in the above-mentioned device cluster system. FIG. 15 shows a flow chart of a method for generating a session key provided by an embodiment of the present application. As shown in Figure 15, the method may include the following steps:

S1501. The first KDE acquires key generation information provided by the KDC for the first KDE, and generates a first entity key according to the key generation information.

Wherein, the first KDE is deployed in the service component of the first control device; the first control device is one of the multiple control devices included in the device cluster system, and the KDC is located in any one of the multiple control devices.

In some embodiments, before the first KDE obtains the key generation information from the KDC, the first KDE may also generate registration information and send the registration information of the first KDE to the KDC, so that the KDC saves the registration information of the first KDE.

The key generation information of the first KDE is that when the KDC receives the key application request of the first KDE, it will verify the consistency between the key application information carried in the key application request and the stored registration information of the first KDE, And it is provided by the first KDE after the verification is passed.

In some embodiments, before the first KDE obtains the key generation information from the KDC, the first KDE may also receive and save the identification information and central key of each KDC included in the device cluster system.

S1502. In the process of establishing a session with the second KDE, the first KDE sends the identification information of the first KDE and the identification information of the KDC to the second KDE.

Wherein, the second KDE is deployed in the service component of the second control device in the device cluster system. The second KDE can obtain the central key of the KDC according to the identification information of the KDC, and according to the entity key of the second KDE, the identification information of the second KDE Information and the central key of the KDC to generate a session key.

S1503. The first KDE receives the identification information of the second KDE and the identification information of the KDC sent by the second KDE.

S1504. The first KDE generates a session key for authentication between the first KDE and the second KDE according to the first entity key, the identification information of the second KDE, and the identification information of the KDC.

In some embodiments, the first KDE can obtain the central key of the KDC according to the identification information of the KDC, and generate a session key according to the first entity key, the identification information of the second KDE, and the central key of the KDC.

The first KDE and the second KDE can perform authentication and session based on the session key generated through negotiation.

In a possible implementation manner, a KDA is deployed in the first control device. After the first KDE generates the first entity key, it may store the first entity key in the KDA deployed in the first control device, and obtain the first entity key from the KDA each time it is started.

The first KDE can also send a key application request to the KDC through the KDA, and receive the key generation information obtained from the KDC forwarded by the KDA.

The method steps in the embodiments of the present application may be implemented by means of hardware, or by means of a processor executing computer programs or instructions. A computer program or instructions may constitute a computer program product. The embodiment of the present application also provides a computer program product including computer executable instructions. In one embodiment, the computer-executable instructions are used to cause a computer to execute the functions in the method embodiment shown in FIG. 15 .

Computer-executable instructions may be stored in a computer-readable storage medium, and the embodiment of the present application further provides a computer-readable storage medium, and the computer-readable storage medium stores executable instructions. In one embodiment, the computer-executable instructions are used to cause a computer to execute the functions in the method embodiment shown in FIG. 15 .

The computer-readable storage medium provided by the embodiment of the present application may be random access memory (random access memory, RAM), flash memory, read-only memory (read-only memory, ROM), programmable read-only memory (programmable ROM, PROM), Erasable programmable read-only memory (erasable PROM, EPROM), electrically erasable programmable read-only memory (electrically ePROM, EEPROM), registers, hard disk, removable hard disk, CD-ROM or any other form known in the art computer readable storage medium.

Computer-executable instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer programs or instructions may be transmitted from a website, computer, server or A data center transmits to another website site, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any available medium that can be accessed by a computer, or a data storage device such as a server or a data center integrating one or more available media. The available medium may be a magnetic medium, such as a floppy disk, a hard disk, or a magnetic tape; it may also be an optical medium, such as a digital video disc (digital video disc, DVD); it may also be a semiconductor medium, such as a solid-state hard disk.

In each embodiment of the present application, if there is no special explanation and logical conflict, the terms and/or descriptions between different embodiments are consistent and can be referred to each other, and the technical features in different embodiments are based on their inherent Logical relationships can be combined to form new embodiments. Furthermore, the terms "comprising" and "deploying", as well as any variations thereof, are intended to cover a non-exclusive inclusion, eg, a series of steps or elements. A method, system, product or device is not necessarily limited to those steps or elements explicitly listed, but may include other steps or elements not explicitly listed or inherent to the process, method, product or device.

Although the application has been described in conjunction with specific features and embodiments thereof, it will be apparent that various modifications and combinations can be made thereto without departing from the spirit and scope of the application. Accordingly, the specification and drawings are merely illustrative of the solutions defined by the appended claims, and are deemed to cover any and all modifications, changes, combinations or equivalents within the scope of the application.

Apparently, those skilled in the art can make various changes and modifications to the present application without departing from the scope of the present application. In this way, if the modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these modifications and variations.

Claims (17)

A control device, characterized in that it is applied in a device cluster system, the control device includes a key distribution center KDC and a first service component, and a first key distribution entity KDE is deployed in the first service component; The KDC is configured to provide key generation information for the first KDE in response to the key application request of the first KDE; The first KDE is configured to generate a first entity key according to the key generation information provided by the KDC; The first KDE is further configured to send the identification information of the first KDE and the identification information of the KDC to the second KDE during the process of establishing a session with the second KDE of the service component of another control device; and receiving the identification information of the second KDE and the identification information of the KDC sent by the second KDE; generating A session key used for authentication between the first KDE and the second KDE. The control device according to claim 1, wherein the control device further includes a key distribution agent KDA, The first KDE is further configured to store the first entity key in the KDA after the first entity key is generated, and obtain the first entity key from the KDA each time it is started. Entity key. The control device according to claim 2, wherein the KDA is further configured to: receive the key application request sent by the first KDE, and forward the key application request of the first KDE to the KDC; and receiving the key generation information sent by the KDC, and forwarding the key generation information to the first KDE. The control device according to any one of claims 1-3, wherein the KDC is further configured to: receive and save the registration information of each KDE included in the device cluster system; and receive the first When requesting a KDE key application, verify the consistency between the key application information carried in the key application request and the stored registration information of the first KDE, and provide the first KDE with Key generation information. The control device according to any one of claims 1-4, wherein the first KDE is further configured to: obtain and save the identification information and the central key of the KDC. The control device according to claim 5, wherein the first KDE is specifically configured to obtain the central key of the KDC according to the identification information of the KDC, and obtain the central key of the KDC according to the first entity key, The session key is generated by the identification information of the second KDE and the central key of the KDC. The control device according to any one of claims 1-6, wherein the KDC is also used for: receiving the key revocation command sent by the management node, signing the revocation list carried in the key revocation command and distributing it to the standby KDC of the KDC; The revocation list includes identification information of the KDE corresponding to the leaked entity key and/or identification information of the KDC corresponding to the leaked central key. A method for generating a session key, comprising: The first key distribution entity KDE obtains the key generation information provided by the key distribution center KDC for the first KDE, and Generate a first entity key according to the key generation information; the first KDE is deployed in the service component of the first control device in the device cluster system; In the process of establishing a session with the second KDE, the first KDE sends the identification information of the first KDE and the identification information of the KDC to the second KDE; the second KDE is deployed in the device cluster system within the service component of the second control device; The first KDE receives the identification information of the second KDE and the identification information of the KDC sent by the second KDE; The first KDE generates an authentication session between the first KDE and the second KDE according to the first entity key, the identification information of the second KDE, and the identification information of the KDC Secret key. The method according to claim 8, characterized in that the method further comprises: After the first KDE generates the first entity key, it saves the first entity key to the key distribution agent KDA deployed in the first control device, and at each startup, from the The KDA obtains the first entity key. The method according to claim 9, wherein the first key distribution entity KDE acquires the key generation information provided by the key distribution center KDC for the first KDE, including: The first KDE sends a key application request to the KDC through the KDA; The first KDE receives the key generation information obtained from the KDC forwarded by the KDA. The method according to any one of claims 8-10, wherein before the first key distribution entity KDE obtains the key generation information from the key distribution center KDC, the method further includes: The first KDE generates registration information, and sends the registration information of the first KDE to the KDC, so that the KDC saves the registration information of the first KDE. The method according to claim 11, wherein the key generation information is that when the KDC receives the key application request from the first KDE, it applies the key application information carried in the key application request. The information is verified for consistency with the stored registration information of the first KDE, and is provided by the first KDE after the verification is passed. The method according to claim 11 or 12, wherein, before the first key distribution entity KDE obtains the key generation information from the key distribution center KDC, the method further comprises: The first KDE receives and saves the identification information and central key of the KDC. The method according to claim 13, wherein the generating the first entity key according to the key generation information comprises: The first KDE obtains the central secret key of the KDC according to the identification information of the KDC; The first KDE generates the session key according to the first entity key, the identification information of the second KDE, and the central key of the KDC. A device cluster system, characterized by comprising a plurality of control devices; the plurality of control devices include the control device according to any one of claims 1-7. A computer-readable storage medium, characterized in that computer-executable instructions are stored, and the computer-executable The instructions are used to make the computer execute the method according to any one of claims 8 to 14. A computer program product, characterized by comprising computer-executable instructions for causing a computer to execute the method according to any one of claims 8-14.