A key sharing method, device, control device and readable storage medium

Abstract

The present application provides a key sharing method, device, control device and readable storage medium, the method comprising: in response to a received key request, the key management device determines the pre-written first root key and second root key through the identification information in the key request; through a preset generation strategy, generates a session key based on the first root key and an encryption key based on the second root key; sends the session key to the second instance through the encryption key, so that the second instance obtains the session key. By presetting the same root key and generation strategy in the trusted execution environment of the key management device and the instance, the same key can be directly generated between the key management device and the instance. On this basis, key sharing between different instances is achieved through encrypted transmission, which greatly improves confidentiality.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a key sharing method, apparatus, control device and readable storage medium. Background Art

[0002] In cloud computing scenarios, communication between instances needs to be encrypted and protected. The current common encryption protection scheme is AK / SK. AK is used to identify the user, and SK is the key used by the user to encrypt the authentication string and by the cloud vendor to verify the authentication string.

[0003] However, in AK / SK, AK is usually written directly in the product code, which allows third parties to illegally obtain AK by parsing the product code, violating the security principle. Summary of the invention

[0004] The problem solved by this application is that the existing password protection schemes in cloud computing scenarios have low confidentiality.

[0005] To solve the above problems, the present application provides a key sharing method in a first aspect, comprising:

[0006] In response to the received key request, the key management device determines, by identification information in the key request, a first root key and a second root key that are pre-written, wherein the first root key is pre-written in a trusted execution environment associated with the first instance, and the second root key is pre-written in a trusted execution environment associated with the second instance;

[0007] Generate a session key based on the first root key and an encryption key based on the second root key through a preset generation strategy; the generation strategy is also preset in a trusted execution environment associated with the first instance and the second instance, so as to generate the session key and the encryption key in the trusted execution environment associated with the first instance and the second instance respectively;

[0008] The session key is sent to the second instance through the encryption key, so that the second instance obtains the session key.

[0009] A second aspect of the present application provides a key sharing device, comprising:

[0010] a root key determination module, configured to, in response to a received key request, determine, by the key management device, a first root key and a second root key that are pre-written in advance through identification information in the key request, wherein the first root key is pre-written in advance in a trusted execution environment associated with the first instance, and the second root key is pre-written in advance in a trusted execution environment associated with the second instance;

[0011] A key generation module, which is used to generate a session key based on the first root key and an encryption key based on the second root key through a preset generation strategy; the generation strategy is also preset in a trusted execution environment associated with the first instance and the second instance, so as to generate the session key and the encryption key in the trusted execution environment associated with the first instance and the second instance respectively;

[0012] The key sending module is used to send the session key to the second instance through the encryption key, so that the second instance obtains the session key.

[0013] A third aspect of the present application provides a control device, comprising: a memory and a processor;

[0014] The memory is used to store programs;

[0015] The processor, coupled to the memory, is configured to execute the program to:

[0016] In response to the received key request, the key management device determines, by identification information in the key request, a first root key and a second root key that are pre-written, wherein the first root key is pre-written in a trusted execution environment associated with the first instance, and the second root key is pre-written in a trusted execution environment associated with the second instance;

[0017] Generate a session key based on the first root key and an encryption key based on the second root key through a preset generation strategy; the generation strategy is also preset in a trusted execution environment associated with the first instance and the second instance, so as to generate the session key and the encryption key in the trusted execution environment associated with the first instance and the second instance respectively;

[0018] The session key is sent to the second instance through the encryption key, so that the second instance obtains the session key.

[0019] A fourth aspect of the present application provides a computer-readable storage medium on which a computer program is stored, and the program is executed by a processor to implement the key sharing method described above.

[0020] By presetting the same root key and generation strategy in the trusted execution environment of the key management device and the instance, the same key can be directly generated between the key management device and the instance. On this basis, key sharing between different instances is achieved through encrypted transmission, greatly improving confidentiality.

[0021] By dynamically generating session keys through instance identification, the second instance can be distinguished from instance pairs of other instances. Combined with extended parameters, the instance pair of the first instance and the second instance, as well as the keys of multiple connections of the instance pair can be distinguished to avoid replay attacks and other leakage attacks. This method can also be used between different instances of the same physical machine to avoid virtual machine escape problems.

[0022] This application uses the TEE of the physical machine to implement secure pre-set root keys, and then dynamically generate session keys to ensure the compliance of the key exchange process; dynamically generate session keys through the root keys preset by the physical machine; avoid the use of AK, and there is no need to consider AK updates. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 is a flowchart of a key sharing method according to an embodiment of the present application;

[0024] Figure 2 is an example diagram of key sharing according to the present application;

[0025] Figure 3 is a flowchart of a key sharing method according to another embodiment of the present application;

[0026] Figure 4 is a flowchart of a key sharing method S100 according to an embodiment of the present application;

[0027] Figure 5 is a flowchart of a key sharing method S200 according to an embodiment of the present application;

[0028] Figure 6 is a flowchart of a key sharing method S300 according to an embodiment of the present application;

[0029] Figure 7 is a structural block diagram of a key sharing device according to an embodiment of the present application;

[0030] Figure 8 4 is a structural block diagram of a control device according to an embodiment of the present application. DETAILED DESCRIPTION

[0031] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the specific embodiments of the present application are described in detail below in conjunction with the accompanying drawings. Although the exemplary embodiments of the present application are shown in the accompanying drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present application and to fully convey the scope of the present application to those skilled in the art.

[0032] It should be noted that, unless otherwise specified, the technical terms or scientific terms used in this application should have the common meanings understood by technicians in the field to which this application belongs.

[0033] In cloud computing scenarios, communication between instances needs to be encrypted and protected. The current common encryption protection scheme is AK / SK. AK is used to identify the user, and SK is the key used by the user to encrypt the authentication string and by the cloud vendor to verify the authentication string.

[0034] However, in AK / SK, AK is usually written directly in the product code, which allows third parties to illegally obtain AK by parsing the product code, violating the security principle.

[0035] In addition, it is difficult for cloud vendors to detect such violations of security principles, and they can only be determined by scanning the product code.

[0036] Currently, cloud vendors have also introduced a new security concept: zero trust, which is a network security concept with resource protection as the core. It believes that the trust relationship between the subject and the object of access to resources, whether from inside or outside, is not naturally established, and it is necessary to continuously evaluate its trust and then implement access control. Regardless of the internal or external network, all access to resources needs to be encrypted. The subject accessing the resources may be located in the internal network or from the external network. All access is based on encryption to build a secure channel to ensure confidentiality and integrity, and provide source identity authentication.

[0037] Compared with existing security principles, the security principles of zero trust are more stringent and extensive. The current AK / SK encryption method is far from meeting the security requirements of zero trust.

[0038] In order to meet the requirements of zero trust, 3GPP TS33.220 in the mobile communications field provides a new solution, Generic Bootstrapping Architecture (GBA). However, when applied to cloud computing scenarios, entities such as SIM cards and HSS (Home Subscriber System) need to be introduced, which is a huge change to the overall technical architecture of cloud service providers.

[0039] In response to the above problems, the present application provides a new key sharing solution, which can solve the problem of low confidentiality of current encryption solutions by pre-setting root keys on instances and password management devices for key derivation.

[0040] For ease of understanding, the following terms that may be used are explained here:

[0041] KDF: key derivation function

[0042] AK / SK: Access Key Id / Secret Access Key encryption mechanism. The cloud host needs to verify the identity of the sender of a request by using the Access Key Id / Secret Access Key encryption method. AccessKey Id (AK) is used to identify the user, and Secret Access Key (SK) is the key used by the user to encrypt the authentication string and the cloud vendor to verify the authentication string. SK must be kept confidential. During specific use, after the cloud host receives the user's request, the system will use the same SK corresponding to AK and the same authentication mechanism to generate an authentication string, and compare it with the authentication string contained in the user request. If the authentication strings are the same, the system assumes that the user has the specified operation permission and performs the relevant operation; if the authentication strings are different, the system will ignore the operation and return an error code.

[0043] Trusted execution environment (TEE) is an independent processing environment with computing and storage functions that can provide security and integrity protection. The basic idea is to allocate an isolated memory for sensitive data in the hardware. All sensitive data calculations are performed in this memory, and other parts of the hardware cannot access the information in this isolated memory except for authorized interfaces, so as to achieve privacy computing of sensitive data.

[0044] The embodiment of the present application provides a key sharing method, which can be performed by a key sharing device, and the key sharing device can be integrated in electronic devices such as pads, computers, servers, computers, server clusters, data centers, etc. Figure 1 Combination Figure 2 As shown, it is a flowchart of a key sharing method according to an embodiment of the present application; wherein the key sharing method includes:

[0045] S100, in response to the received key request, the key management device determines the pre-written first root key and the second root key according to the identification information in the key request, the first root key is pre-written in the trusted execution environment associated with the first instance, and the second root key is pre-written in the trusted execution environment associated with the second instance;

[0046] Among them, the first instance and the second instance are a pair of instances that need to perform encrypted communication in the cloud computing scenario. Multiple paired instances that need to perform encrypted communication may exist simultaneously in the cloud computing scenario. The instances in the multiple paired instances may be crossed or not. For example, a paired instance consisting of the first instance and the second instance, a paired instance consisting of the second instance and the third instance, and a paired instance consisting of the third instance and the fourth instance may all exist at the same time without affecting each other.

[0047] Among them, the first instance and the second instance do not specifically refer to certain instances. In this application, the specific reference to the first instance and the second instance is not limited.

[0048] It should be noted that the "first" and "second" in the first instance and the second instance are only used to distinguish that they are not the same instance, and have no other limitations. For example, referring to the first instance as a specific instance A and the second instance as a specific instance B, and referring to the first instance as a specific instance B and the second instance as a specific instance A, do not affect the meaning and protection scope thereof.

[0049] The first root key is simultaneously written into the key management device and the trusted execution environment associated with the first instance. The second root key is simultaneously written into the key management device and the trusted execution environment associated with the second instance.

[0050] In one embodiment, the first instance is hosted on a physical machine, and the trusted execution environment associated with the first instance / second instance is a module with TEE capability of the physical machine.

[0051] In one implementation, the trusted execution environment associated with the first instance / second instance is a TEE module of a MOC card of the physical machine.

[0052] Among them, the MOC card is the core component of the server, and its specific functions are not repeated here.

[0053] like Figure 2 As shown, it is an example diagram of key sharing of the present application. In the diagram, a first instance and a second instance are set on a physical machine, and the second instance is connected to a key management device.

[0054] In one embodiment, the trusted execution environment associated with the first instance / second instance can also be other hardware devices with a trusted execution environment or a trusted execution environment program on the device, such as an external TEE device of a physical machine. It only needs to be able to connect directly to the first instance / second instance without going through the network. Apart from this, the present application does not impose any other restrictions on this.

[0055] It should be noted that the trusted execution environment of the first instance and the second instance can be the same device type or different device types. For example, the trusted execution environment of the first instance is the TEE module of the MOC card of the physical machine, and the second instance is an external TEE device of the physical machine.

[0056] In one implementation, the trusted execution environments of the first instance and the second instance may be different trusted execution environments or the same trusted execution environment; when they are the same trusted execution environment, the first root key and the second root key are the same root key.

[0057] In one implementation, the first root key / the second root key is written into the trusted execution environment of the physical machine when the physical machine leaves the factory.

[0058] In one implementation, the first root key / the second root key is manually written into the key management device during online deployment.

[0059] In one implementation, the key management device is a key center. The key center is a hardware cryptographic machine, which is a dedicated hardware cryptographic device.

[0060] In one embodiment, the key management device may also be a key distribution center, and the key distribution center (KDC Key Distribution Center) is a service running on a physical security server; or the key management device may also be other devices that serve as a trusted execution environment, and the specific device type is not limited in this application.

[0061] S200, generating a session key based on the first root key and an encryption key based on the second root key through a preset generation strategy; the generation strategy is also preset in a trusted execution environment associated with the first instance and the second instance, so as to generate the session key and the encryption key in the trusted execution environment associated with the first instance and the second instance respectively;

[0062] The generation strategy preset in the key management device is the same as the generation strategy in the trusted execution environment associated with the first instance / second instance, and the same encryption key / session key can be generated based on the same root key.

[0063] In one embodiment, a generation strategy for generating a session key based on the first root key within the key management device is the same as a generation strategy preset within a trusted execution environment associated with the first instance, thereby generating the same session key within the trusted execution environment associated with the key management device and the first instance.

[0064] In one embodiment, a generation strategy for generating an encryption key based on the second root key within the key management device is the same as a generation strategy preset within a trusted execution environment associated with the second instance, thereby generating the same encryption key within the trusted execution environment associated with the key management device and the second instance.

[0065] In one implementation, there are multiple preset generation strategies in the key management device, and different identifiers are associated with different preset generation strategies.

[0066] In one implementation, the key management device has one preset generation strategy, and the encryption key and the session key are generated based on the same generation strategy.

[0067] In one implementation, the generation policy is written into the trusted execution environment of the physical machine when the physical machine leaves the factory.

[0068] In one implementation, the generation strategy is manually written into the key management device when deployed online.

[0069] In one embodiment, the generation policy is written into the trusted execution environment of the physical machine and / or into the key management device via a network. In this way, the trusted execution environment ensures that even if the generation policy is intercepted by a third party, the confidentiality of the session key and the communication can still be guaranteed if the root key is not disclosed.

[0070] S300: Send the session key to the second instance through the encryption key, so that the second instance obtains the session key.

[0071] The first instance generates the session key based on the associated trusted execution environment, and the second instance receives the session key sent by the key management device, so that both the first instance and the second instance obtain the session key and complete key sharing.

[0072] By presetting the same root key and generation strategy in the trusted execution environment of the key management device and the instance, the same key can be directly generated between the key management device and the instance. On this basis, key sharing between different instances is achieved through encrypted transmission, greatly improving confidentiality.

[0073] By presetting the same root key and generation policy in the trusted execution environment of the first instance, the same session key can be generated on the first instance, and the communication between the instances is protected by the session key shared between the instances.

[0074] In one embodiment, if Figure 3 As shown, the method also includes:

[0075] S400: The first instance and the second instance perform encrypted communication using the session key.

[0076] In encrypted communication using a session key, when the first instance / second instance sends communication data to the second instance / first instance, the communication data can be encrypted using the session key; after receiving the encrypted communication data, the decrypted communication data can be decrypted using the session key to obtain the decrypted communication data; thus, encrypted communication between the first instance and the second instance is achieved.

[0077] In one implementation, the identification information in the key request includes a first identification for associating with the first root key and a second identification for associating with the second root key.

[0078] like Figure 4 As shown, the key management device determines the pre-written first root key and the second root key through the identification information in the key request, including:

[0079] S101, obtaining a mapping table recording the association relationship between the identifier and the root key;

[0080] In one implementation, the first identifier is the ID of a physical machine that hosts the first instance; the second identifier is the ID of a physical machine that hosts the second instance.

[0081] In one implementation, the first identifier is information associated with the physical machine hosting the first instance, such as a factory label, an allocation serial number in a cloud computing network, etc., or other information that can identify the trusted execution environment associated with the first instance one by one.

[0082] Similarly, the second identifier may be information associated with the physical machine hosting the second instance, or may be other information that can determine the trusted execution environment associated with the second instance one by one.

[0083] The mapping table records the association relationship or mapping relationship between the identifier and the root key. In the mapping table, the identifier and the root key correspond one to one.

[0084] In one implementation, the mapping table is manually written into the key management device during online deployment.

[0085] S102: Determine, according to the mapping table, the first root key associated with the first identifier and the second root key associated with the second identifier.

[0086] The first root key and the second root key are determined through a preset mapping table, and then the session key and the encryption key are generated.

[0087] In one embodiment, the key request further includes an instance identifier and an extended parameter for identifying the second instance;

[0088] like Figure 5 As shown, the generating of the session key based on the first root key and the encryption key based on the second root key by a preset generating strategy includes:

[0089] S201, generating the session key according to the preset generation strategy using the instance identifier, the extended parameter and the first root key;

[0090] In one implementation, the instance identifier of the second instance is the instance ID of the second instance.

[0091] In one implementation, the instance identifier of the second instance is a MAC address or an IP address of the second instance.

[0092] In an implementation manner, the instance identifier of the second instance may be information associated with the second instance, or may be other information that can identify the second instance one by one.

[0093] In one implementation, the instance identifier of the second instance can not only identify the second instance, but also simultaneously identify the instance pair of the first instance and the second instance, so that the instance can be distinguished from the instance pairs of other instances.

[0094] In one embodiment, the extended parameter may be a timestamp, a counter, a random number, or other data or information that can distinguish the current connection from the previous connection; by using the extended parameter, the session keys of multiple connections between the first instance and the second instance can be distinguished, thereby preventing replay attacks.

[0095] In one implementation, there are multiple extended parameters, and at least one extended parameter is a timestamp, a counter, or a random number.

[0096] S202: Generate the encryption key according to the preset generation strategy using the instance identifier, the extended parameter and the second root key.

[0097] By dynamically generating session keys through instance identification, the second instance can be distinguished from instance pairs of other instances. Combined with extended parameters, the instance pair of the first instance and the second instance, as well as the keys of multiple connections of the instance pair can be distinguished to avoid replay attacks and other leakage attacks. This method can also be used between different instances of the same physical machine to avoid virtual machine escape problems.

[0098] In one implementation, in the response to the received key request, the key request is sent by the second instance to the key management device when the second instance receives the first identifier and the extended parameter sent by the first instance.

[0099] The extended parameters are generated by the first instance and forwarded by the second instance, thereby completing the unification of the extended parameters among the first instance, the second instance, and the key management device.

[0100] In one implementation, the first instance, the second instance, and the key management device may obtain the same extended parameters in other ways, such as a third-party device directly generating extended parameters and transmitting them to the first instance, the second instance, the key management device, etc. at the same time.

[0101] In one implementation, the first instance, the second instance, and the key management device transmit the first identifier, the second identifier, the instance identifier, or the extended parameter to each other in an unencrypted manner. The trusted execution environment can ensure that even if the above parameters are intercepted by a third party, the confidentiality of the session key and the communication can still be guaranteed if the root key is not disclosed.

[0102] In one embodiment, after the second instance receives the first identifier and extended parameters sent by the first instance, it generates the encryption key in an associated trusted execution environment according to the same generation strategy as the key management device, using the extended parameters, the preset instance identifier and the second root key.

[0103] In one implementation, the second instance transmits the extended parameter to an associated trusted execution environment, and then generates the encryption key in the trusted execution environment according to the generation policy.

[0104] In one implementation, the second instance transmits the extended parameter, the generation policy, and the instance identifier to an associated trusted execution environment, and then generates the encryption key according to the generation policy in the trusted execution environment.

[0105] In one embodiment, when the first instance generates the extended parameters and sends the first identifier and the extended parameters to the second instance, the instance identifier of the second instance is obtained, and in the associated trusted execution environment, the session key is generated by the instance identifier, the extended parameters and the first root key according to the generation strategy that is the same as that of the key management device.

[0106] In one implementation, the first instance transmits the instance identification to an associated trusted execution environment, and then generates the session key in the trusted execution environment according to the generation policy.

[0107] In one implementation, the first instance transmits the extended parameter, the generation policy, and the instance identifier to an associated trusted execution environment, and then generates the session key according to the generation policy in the trusted execution environment.

[0108] In one implementation, the extended parameter may be generated by the second instance and sent to the first instance.

[0109] In one implementation, the session key is generated based on the instance identifier, the extended parameter and the first root key by using a key derivation function. Through the key derivation function, a root key can be used to derive multiple keys.

[0110] In one implementation, in generating the session key based on the instance identifier, the extended parameters and the first root key through a key derivation function, the instance identifier, the extended parameters and the first root key are input into the key derivation function, and the session key is output.

[0111] In one implementation, the encryption key is generated based on the instance identifier, the extended parameter and the second root key by using a key derivation function. Through the key derivation function, a root key can be used to derive multiple keys.

[0112] In one implementation, in generating the encryption key through a key derivation function based on the instance identifier, the extended parameters and the second root key, the instance identifier, the extended parameters and the second root key are input into the key derivation function, and the encryption key is output.

[0113] In one implementation, the preset generation strategy is a preset derivation strategy.

[0114] Among them, a key derivation function (KDF) is a function whose function is to generate one or more keys from a secret key. Some key derivation functions have a (usually optional) salt parameter, which can solve the problem of producing the same output key for the same input key. In some other cryptographic systems, salts are essentially different from the input key, and salts usually do not need to be private and can be reused.

[0115] In one embodiment, if Figure 6 As shown, the S300, sending the session key to the second instance through the encryption key so that the second instance obtains the session key, includes:

[0116] S301, encrypting the session key by using the encryption key;

[0117] S302: Send the encrypted session key to the second instance, so that the second instance decrypts the encrypted session key by using the encryption key to obtain the session key.

[0118] The session key is transmitted through an encryption key, which ensures the confidentiality of the transmitted session key and prevents the session key from being obtained by a third party.

[0119] In one embodiment, the second instance decrypts the encrypted session key within an associated trusted execution environment.

[0120] In one implementation, the second instance sends the encrypted session key to an associated trusted execution environment, decrypts the key in the trusted execution environment using the encryption key, obtains the session key, and returns the key to the second instance.

[0121] In one implementation, after a session key / encryption key is generated in a trusted execution environment associated with the first instance / second instance, the session key / encryption key is returned to the first instance / second instance.

[0122] In one embodiment, after the encryption key is generated in the trusted execution environment associated with the second instance, the encryption key is stored in the trusted execution environment for decrypting the encrypted session key, and the decrypted session key is returned to the second instance.

[0123] This application uses the TEE of the physical machine to implement secure pre-set root keys, and then dynamically generate session keys to ensure the compliance of the key exchange process; dynamically generate session keys through the root keys preset by the physical machine; avoid the use of AK, and there is no need to consider AK updates.

[0124] Taking the key sharing process between instance A carried by physical machine 1 and instance B carried by physical machine 2 as an example, the specific process of the key sharing method is illustrated. The specific process is as follows:

[0125] When the physical machine is produced, the preset root key is written into the module with TEE capability; when it is deployed online, the root key is manually written into the Key Center and becomes the shared key between the physical machine and the Key Center. r1 , K is preset in physical machine 2 r2 , K r1 , K r2 Also saved in the Key center.

[0126] Instance A initiates communication with instance B. The message includes the ID of physical machine 1 and a timestamp.

[0127] Instance B sends the physical machine ID of instance A and its own physical machine ID to the key center;

[0128] The key center determines the corresponding K through the ID of physical machine 1 r1, and the ID value of instance B as the necessary input parameters to generate the session key K AB , K AB =KDF(K r1 , ID B , [timestamp, …]);

[0129] Key center uses the K r2 , the ID of instance B is used as a necessary input parameter to generate the encryption key K B , K B =KDF(K r2 , ID B ,[timestamp,…],…);

[0130] Use K B Encryption K AB Get {K AB} KB And return it to instance B;

[0131] Instance B calls the password module of physical machine 2; the password module uses the K r2 , instance B ID and other input parameters to generate the key K B , instance B uses K B Decryption {K AB} KB Decryption gives K AB ;

[0132] Instance A calls the cryptographic module of the physical machine and provides the ID value of instance B as the necessary input parameter; the cryptographic module of the physical machine generates the session key K AB , K AB =KDF(K r1 , ID B , [timestamp, ...]) and returns it to instance A;

[0133] Instance A and instance B use the session key for encrypted communication.

[0134] An embodiment of the present application provides a key sharing device for executing the key sharing method described in the above content of the present application. The key sharing device is described in detail below.

[0135] like Figure 7 As shown, the key sharing device comprises:

[0136] A root key determination module 101, configured to, in response to a received key request, determine, by the key management device, a first root key and a second root key that are pre-written in advance through identification information in the key request, wherein the first root key is pre-written in advance in a trusted execution environment associated with the first instance, and the second root key is pre-written in advance in a trusted execution environment associated with the second instance;

[0137] A key generation module 102, which is used to generate a session key based on the first root key and an encryption key based on the second root key through a preset generation strategy; the generation strategy is also preset in a trusted execution environment associated with the first instance and the second instance, so as to generate the session key and the encryption key in the trusted execution environment associated with the first instance and the second instance respectively;

[0138] The key sending module 103 is used to send the session key to the second instance through the encryption key, so that the second instance obtains the session key.

[0139] In one embodiment, the device further comprises:

[0140] A communication module (not shown in the figure) is used for the first instance to perform encrypted communication with the second instance through the session key.

[0141] In one implementation, the identification information in the key request includes a first identification for associating the first root key and a second identification for associating the second root key, and the root key determination module 101 is further configured to:

[0142] Obtain a mapping table recording the association relationship between identifiers and root keys; and determine the first root key associated with the first identifier and the second root key associated with the second identifier according to the mapping table.

[0143] In one implementation, the key request further includes an instance identifier and an extended parameter for identifying the second instance; the key generation module 102 is further configured to:

[0144] According to the preset generation strategy, the session key is generated through the instance identifier, the extended parameters and the first root key; according to the preset generation strategy, the encryption key is generated through the instance identifier, the extended parameters and the second root key.

[0145] In one embodiment, the key generation module 102 is further configured to:

[0146] The key request is sent to the key management device by the second instance when the second instance receives the first identifier and the extended parameter sent by the first instance.

[0147] In one embodiment, the key generation module 102 is further configured to:

[0148] After the second instance receives the first identifier and extended parameters sent by the first instance, it generates the encryption key in the associated trusted execution environment according to the same generation strategy as the key management device, using the extended parameters, the preset instance identifier and the second root key.

[0149] In one embodiment, the key generation module 102 is further configured to:

[0150] When the first instance generates the extended parameters and sends the first identifier and the extended parameters to the second instance, the instance identifier of the second instance is obtained, and in the associated trusted execution environment, the session key is generated by the instance identifier, the extended parameters and the first root key according to the generation strategy that is the same as that of the key management device.

[0151] In one implementation, the key sending module 103 is further used to:

[0152] The session key is encrypted by using the encryption key; and the encrypted session key is sent to the second instance, so that the second instance decrypts the encrypted session key by using the encryption key to obtain the session key.

[0153] In one implementation, the key sending module 103 is further used to:

[0154] The second instance decrypts the encrypted session key within an associated trusted execution environment.

[0155] The key sharing device provided in the above-mentioned embodiment of the present application and the key sharing method provided in the embodiment of the present application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the application programs stored therein.

[0156] The above describes the internal functions and structure of the key sharing device, such as Figure 8 As shown, in practice, the key sharing device can be implemented as a control device, including: a memory 301 and a processor 303.

[0157] The memory 301 may be configured to store programs.

[0158] In addition, the memory 301 may also be configured to store various other data to support operations on the control device. Examples of such data include instructions for any application or method operating on the control device, contact data, phone book data, messages, pictures, videos, etc.

[0159] The memory 301 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0160] The processor 303 is coupled to the memory 301 and is configured to execute a program in the memory 301 to:

[0161] In response to the received key request, the key management device determines, by identification information in the key request, a first root key and a second root key that are pre-written, wherein the first root key is pre-written in a trusted execution environment associated with the first instance, and the second root key is pre-written in a trusted execution environment associated with the second instance;

[0162] Generate a session key based on the first root key and an encryption key based on the second root key through a preset generation strategy; the generation strategy is also preset in a trusted execution environment associated with the first instance and the second instance, so as to generate the session key and the encryption key in the trusted execution environment associated with the first instance and the second instance respectively;

[0163] The session key is sent to the second instance through the encryption key, so that the second instance obtains the session key.

[0164] In one implementation, the processor 303 is specifically configured to:

[0165] The first instance and the second instance perform encrypted communication via the session key.

[0166] In one implementation, the identification information in the key request includes a first identification for associating the first root key and a second identification for associating the second root key, and the processor 303 is specifically configured to:

[0167] Obtain a mapping table recording the association relationship between identifiers and root keys; and determine the first root key associated with the first identifier and the second root key associated with the second identifier according to the mapping table.

[0168] In one implementation, the key request further includes an instance identifier and an extended parameter for identifying the second instance; the processor 303 is specifically configured to:

[0169] According to the preset generation strategy, the session key is generated through the instance identifier, the extended parameters and the first root key; according to the preset generation strategy, the encryption key is generated through the instance identifier, the extended parameters and the second root key.

[0170] In one implementation, the processor 303 is specifically configured to:

[0171] The key request is sent to the key management device by the second instance when the second instance receives the first identifier and the extended parameter sent by the first instance.

[0172] In one implementation, the processor 303 is specifically configured to:

[0173] After the second instance receives the first identifier and extended parameters sent by the first instance, it generates the encryption key in the associated trusted execution environment according to the same generation strategy as the key management device, using the extended parameters, the preset instance identifier and the second root key.

[0174] In one implementation, the processor 303 is specifically configured to:

[0175] When the first instance generates the extended parameters and sends the first identifier and the extended parameters to the second instance, the instance identifier of the second instance is obtained, and in the associated trusted execution environment, the session key is generated by the instance identifier, the extended parameters and the first root key according to the generation strategy that is the same as that of the key management device.

[0176] In one implementation, the processor 303 is specifically configured to:

[0177] The session key is encrypted by using the encryption key; and the encrypted session key is sent to the second instance, so that the second instance decrypts the encrypted session key by using the encryption key to obtain the session key.

[0178] In one implementation, the processor 303 is specifically configured to:

[0179] The second instance decrypts the encrypted session key within an associated trusted execution environment.

[0180] In this application, Figure 8 Only some components are shown schematically, which does not mean that the control device only includes Figure 8 Components shown.

[0181] The control device provided in this embodiment is based on the same inventive concept as the key sharing method provided in the embodiment of the present application, and has the same beneficial effects as the method adopted, run or implemented by the application program stored therein.

[0182] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0183] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0184] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0185] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0186] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0187] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0188] The present application also provides a computer-readable storage medium corresponding to the key sharing method provided in the aforementioned embodiment, on which a computer program (ie, a program product) is stored. When the computer program is executed by a processor, the key sharing method provided in any of the aforementioned embodiments is executed.

[0189] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0190] The computer-readable storage medium provided in the above-mentioned embodiments of the present application and the key sharing method provided in the embodiments of the present application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the application programs stored therein.

[0191] It should be noted that in the description provided herein, a large number of specific details are described. However, it is understood that the embodiments of the present application can be practiced without these specific details. In some instances, well-known structures and technologies are not shown in detail so as not to obscure the understanding of this description.

[0192] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0193] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A key sharing method, characterized in that: include: In response to the received key request, the key management device determines, by identification information in the key request, a first root key and a second root key that are pre-written, wherein the first root key is pre-written in a trusted execution environment associated with the first instance, and the second root key is pre-written in a trusted execution environment associated with the second instance; Generate a session key based on the first root key and an encryption key based on the second root key through a preset generation strategy; the generation strategy is also preset in a trusted execution environment associated with the first instance and the second instance, so as to generate the session key and the encryption key in the trusted execution environment associated with the first instance and the second instance respectively; Sending the session key to the second instance through the encryption key so that the second instance obtains the session key; The key request further includes an instance identifier and an extended parameter for identifying the second instance; and the generating of a session key based on the first root key and an encryption key based on the second root key by a preset generation strategy includes: Generate the session key according to the preset generation strategy, using the instance identifier, the extended parameter and the first root key; According to the preset generation strategy, the encryption key is generated through the instance identifier, the extended parameter and the second root key.

2. The method according to claim 1, characterized in that The method further comprises: The first instance and the second instance perform encrypted communication via the session key.

3. The method according to claim 1 or 2, characterized in that: The identification information in the key request includes a first identification for associating the first root key and a second identification for associating the second root key, and the key management device determines the pre-written first root key and second root key according to the identification information in the key request, including: Obtain a mapping table recording the association relationship between the identifier and the root key; The first root key associated with the first identifier and the second root key associated with the second identifier are determined according to the mapping table.

4. The method according to claim 1 or 2, characterized in that: In the response to the received key request, the key request is sent by the second instance to the key management device when the second instance receives the first identifier and the extended parameter sent by the first instance.

5. The method according to claim 4, characterized in that After the second instance receives the first identifier and extended parameters sent by the first instance, it generates the encryption key in the associated trusted execution environment according to the same generation strategy as the key management device, using the extended parameters, the preset instance identifier and the second root key.

6. The method according to claim 4, characterized in that When the first instance generates the extended parameters and sends the first identifier and the extended parameters to the second instance, the instance identifier of the second instance is obtained, and in the associated trusted execution environment, the session key is generated by the instance identifier, the extended parameters and the first root key according to the generation strategy that is the same as that of the key management device.

7. The method according to claim 1 or 2, characterized in that: The sending the session key to the second instance by using the encryption key so that the second instance obtains the session key includes: encrypting the session key by the encryption key; The encrypted session key is sent to the second instance, so that the second instance decrypts the encrypted session key by using the encryption key to obtain the session key.

8. The method according to claim 7, characterized in that The second instance decrypts the encrypted session key within an associated trusted execution environment.

9. A key sharing device, characterized in that: include: a root key determination module, configured to respond to a received key request, and the key management device determines a first root key and a second root key that are pre-written in advance through identification information in the key request, wherein the first root key is pre-written in advance in a trusted execution environment associated with the first instance, and the second root key is pre-written in advance in a trusted execution environment associated with the second instance; the key request also includes an instance identifier and an extended parameter for identifying the second instance; A key generation module, which is used to generate a session key based on the first root key and an encryption key based on the second root key through a preset generation strategy; including: generating the encryption key through the extended parameter, the preset instance identifier and the second root key according to the generation strategy that is the same as that of the key management device; generating the session key through the instance identifier, the extended parameter and the first root key according to the generation strategy that is the same as that of the key management device, and wherein the "instance identifier" is the "instance identifier of the second instance"; the generation strategy is also preset in a trusted execution environment associated with the first instance and the second instance, so as to generate the session key and the encryption key in the trusted execution environment associated with the first instance and the second instance respectively; A key sending module is used to send the session key to the second instance through the encryption key, so that the second instance obtains the session key.

10. A control device, characterized in that: include: Memory and processor; The memory is used to store programs; The processor, coupled to the memory, is configured to execute the program to: In response to the received key request, the key management device determines the pre-written first root key and the second root key through the identification information in the key request, the first root key is pre-written in the trusted execution environment associated with the first instance, and the second root key is pre-written in the trusted execution environment associated with the second instance; the key request also includes an instance identifier and an extended parameter for identifying the second instance; Generate a session key based on the first root key and an encryption key based on the second root key through a preset generation strategy; including: according to the preset generation strategy, generate the session key through the instance identifier, the extended parameter and the first root key; according to the preset generation strategy, generate the encryption key through the instance identifier, the extended parameter and the second root key; the generation strategy is also preset in a trusted execution environment associated with the first instance and the second instance, so as to generate the session key and the encryption key in the trusted execution environment associated with the first instance and the second instance respectively; The session key is sent to the second instance through the encryption key, so that the second instance obtains the session key.

Images