WO2024198933A1

WO2024198933A1 - Private key protection method, server access method, system, device, and storage medium

Info

Publication number: WO2024198933A1
Application number: PCT/CN2024/081369
Authority: WO
Inventors: 路放
Original assignee: 杭州阿里云飞天信息技术有限公司
Priority date: 2023-03-29
Filing date: 2024-03-13
Publication date: 2024-10-03
Also published as: CN116346341A

Abstract

Embodiments of the present application provide a private key protection method, a server access method, a system, a device, and a storage medium. In the embodiments of the present application, a TEE and a KMS are introduced to protect a private key in a security protocol. Specifically, a TEE calls a KMS to acquire a data key of a user of a client and a ciphertext of the data key, and the TEE encrypts a private key by using the data key to obtain a ciphertext of the private key; and then the ciphertext of the private key and the ciphertext of the data key are stored in the client, so that encrypted storage of the private key is realized, and the risk of leakage of the private key can be reduced. Additionally, the TEE encrypts the private key, so that a plaintext of the private key is kept in the TEE of confidential computing, and the private key cannot be accessed by an external untrusted environment, thereby further improving the security of the private key.

Description

Private key protection and server access method, system, device and storage medium

This application claims priority to a Chinese patent application filed with the Chinese Patent Office on March 29, 2023, with application number 202310333675.7 and application name “Private Key Protection and Server Access Method, System, Device and Storage Medium”, the entire contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the field of communication technology, and in particular to a method, system, device and storage medium for private key protection and server access.

Background Art

With the vigorous development of privacy computing, privacy computing technology has been widely used in all walks of life. A key technology in privacy computing technology is cryptography. Among them, the security of private keys determines the data security of each environment in the privacy computing process. How to improve the security of private keys and reduce the risk of private key leakage has become a technical problem that needs to be solved in this field.

Summary of the invention

Multiple aspects of the present application provide a private key protection and server access method, system, device and storage medium to reduce the risk of private key leakage and improve private key security.

In a first aspect, an embodiment of the present application provides a private key protection method, including:

Use the trusted execution environment TEE to obtain the target user's public and private key pairs to be protected;

Using the TEE to obtain the data key of the target user and the ciphertext of the data key from the key management service KMS;

In the TEE, the private key in the public-private key pair is encrypted using the data key to obtain a ciphertext of the private key;

The TEE is used to return the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key to the user's client, so that the client can store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key.

In a second aspect, an embodiment of the present application further provides a server access method, including:

The trusted execution environment TEE is used to obtain a decryption request initiated by the client; the decryption request includes a ciphertext of a random number, a ciphertext of the data key, and a ciphertext of the private key; the ciphertext of the random number is obtained by the server responding to the client's access request by encrypting the random number using the public key in the public-private key pair; the client The client stores the ciphertext of the data key and the ciphertext of the private key;

Using the TEE to call KMS to decrypt the ciphertext of the data key to obtain the data key;

Decrypting the ciphertext of the private key using the data key in the TEE to obtain the private key;

Decrypting the ciphertext of the random number using the private key in the TEE to obtain the plaintext of the random number;

The plain text of the random number is returned to the client, so that the client can access the server based on the plain text of the random number.

In a third aspect, an embodiment of the present application further provides a private key protection method, including:

Call the trusted execution environment TEE to encrypt the private key in the public-private key pair of the target user, so that the TEE can call the KMS to obtain the data key of the target user and the ciphertext of the data key, and use the data key to encrypt the private key to obtain the ciphertext of the private key;

Receive the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key returned by the TEE;

The ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key are stored.

In a fourth aspect, an embodiment of the present application further provides a server access method, including:

Initiate an access request to the server, so that the server responds to the access request and uses the public key of the public-private key pair of the target user corresponding to the client to encrypt the random number to obtain the ciphertext of the random number; the client stores the ciphertext of the private key in the public-private key pair and the ciphertext of the data key of the target user;

Receiving the ciphertext of the random number returned by the server;

Initiate a decryption request to the trusted execution environment TEE, the decryption request including the ciphertext of the random number, the ciphertext of the data key and the ciphertext of the private key, so that the TEE calls the KMS to decrypt the ciphertext of the data key to obtain the data key, and use the data key to decrypt the ciphertext of the private key to obtain the private key; and use the private key to decrypt the ciphertext of the random number to obtain the plaintext of the random number;

Receive the plaintext of the random number returned by the TEE;

Based on the plain text of the random number, access the server.

In a fifth aspect, an embodiment of the present application further provides a communication system, including: a client, a first service node and a second service node; the first service node runs a trusted execution environment TEE; the second service node is used to provide a key management service;

The first service node is used to perform the steps in the method provided in the first aspect and/or the second aspect above;

The client is used to execute the steps in the method provided in the third aspect and/or the fourth aspect of the claim.

In a sixth aspect, an embodiment of the present application further provides a computing device, comprising: a memory and a processor; wherein the memory is used to store a computer program;

The processor is coupled to the memory, and is configured to execute the computer program to execute the steps in the method performed by the first service node in the fifth aspect and/or the client in the fifth aspect.

In a seventh aspect, an embodiment of the present application further provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the steps in the method executed by the first service node in the fifth aspect and/or the client in the fifth aspect.

In the embodiments of the present application, a Trusted Execution Environment (TEE) and a Key Management Service (KMS) are introduced to protect the private key in the security protocol. Specifically, TEE calls KMS to obtain the data key and ciphertext of the data key of the client user, and encrypts the private key in TEE using the data key to obtain the ciphertext of the private key; then, the ciphertext of the private key and the ciphertext of the data key are stored in the client, thereby realizing the encrypted storage of the private key and reducing the risk of private key leakage. On the other hand, TEE encrypts the private key so that the plaintext of the private key remains in the TEE for confidential computing, and the private key cannot be accessed by an external untrusted environment, which can further improve the security of the private key.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

FIG1 is a schematic diagram of a process for verifying login using a public and private key pair provided by the SSH protocol provided by a traditional solution;

2 and 3 are schematic diagrams of a process for private key protection by a communication system provided in an embodiment of the present application;

FIG4 is a schematic diagram of a process of performing trusted authentication on a TEE by a communication system provided in an embodiment of the present application;

FIG5 is a schematic diagram of a process of accessing a server by a communication system according to an embodiment of the present application;

6 and 7 are schematic flow diagrams of a private key protection method provided in an embodiment of the present application;

8 and 9 are schematic diagrams of a process of accessing a server provided in an embodiment of the present application;

FIG. 10 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application.

DETAILED DESCRIPTION

In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

FIG1 is a schematic diagram of a traditional solution for verifying a login using a public-private key pair provided by a secure shell (SSH) protocol. The SSH protocol is a protocol used for secure remote login and other secure network services on an insecure network. As shown in FIG1 , the communication system includes a client 10 and a server 20.

The client 10 refers to a computer device used by a user and having the functions of computing, surfing the Internet, communicating, etc. required by the user, such as a smart phone, a tablet computer, a personal computer, a wearable device, etc. Of course, the client 10 can also be implemented as a server device. For example, it can be a single server device, a cloud server array, or a virtual machine (VM) running in a cloud server array. In addition, it can also refer to other computing devices with corresponding service capabilities, such as computers and other terminal devices (running service programs), etc.

The server 20 refers to a server device that responds to requests from the client 10 and provides services to users. The service end 20 can be a single server device, a cloud server array, or a virtual machine (VM) running in a cloud server array. In addition, the server end 20 can also refer to other computing devices with corresponding service capabilities, such as computers and other terminal devices (running service programs), etc. In the embodiment of the present application, the specific implementation form of the service provided by the server end 20 is not limited. Optionally, the service provided by the server end 20 can be a live broadcast service, an online shopping service, an instant messaging service, an email service, a video service, an audio service or other services, etc.

In this embodiment, when the client 10 accesses the server 20, the server 20 may verify the access rights of the target user of the client 10. The client 10 accessing the server 20 may be implemented as the client 10 logging into the server 20 or the client 10 accessing the service provided by the server 20.

In some embodiments, the public-private key pair mechanism provided by the SSH protocol can be used to verify access rights. Specifically, as shown in FIG1 , the client 10 can generate a public-private key pair and store the public-private key pair in a specified directory (corresponding to step 1 “generate a public-private key pair and store it” in FIG1 ). This is generally the “/.ssh” directory. Furthermore, the client 10 can register the public key in the public-private key pair in the server 20 (corresponding to step 2 in FIG1 ).

When accessing the server 20, the client 10 may initiate an access request to the server 20 (corresponding to step 3 of FIG. 1 ). The access request may also be referred to as an SSH connection request. The server 20 may generate a random number in response to the access request; and encrypt the random number using the public key in the public-private key pair to obtain a ciphertext of the random number (corresponding to step 4 “public key encryption of random number” of FIG. 1 ); thereafter, the ciphertext of the random number may be returned to the client 10 (corresponding to step 5 of FIG. 1 ).

The client 10 receives the ciphertext of the random number, and reads the private key in the public-private key pair from the "/.ssh" directory to decrypt the random number to obtain the plaintext of the random number (corresponding to step 6 "private key decrypts the ciphertext of the random number" in Figure 1); thereafter, the client 10 may send the plaintext of the random number to the server 20 (corresponding to step 7 in Figure 1). The server 20 may perform access permission verification on the client 10 based on the comparison between the received random number and the random number stored by itself (corresponding to step 8 in Figure 1) to obtain the access permission verification result. The access permission verification result indicates that the client has access permission to the service or does not have access permission. Further, the server 20 may send the access permission verification result to the client 10 (9 corresponds to step 9 in Figure 1). If the random number received by the server 20 is the same as the random number stored by itself, it is determined that the client 10 has access permission, and then an SSH connection is established with the client 10, and the client 10 can access the server 20. If the random number received by the server 20 is different from the random number stored by itself, the server 20 returns a prompt message of no access permission to the client 10, etc.

Based on the above process of using the SSH protocol to access the server, it can be known that the private key in the public-private key pair is stored in plain text in the "/.ssh" directory of the client. Although the "/.ssh" directory is a hidden directory, it is generally known to those skilled in the art that the public-private key pair is stored in this directory. Therefore, the private key in the public-private key pair is at risk of leakage. If an attacker steals the SSH private key, he can remotely access the client or even the server or perform other attacks.

In order to solve the above technical problems, in some embodiments of the present application, a trusted execution environment (TEE) and a key management service (KMS) are introduced to protect the private key in the security protocol. Specifically, TEE calls KMS to obtain the data key and data of the user of the client. The private key is encrypted with the data key in the TEE to obtain the ciphertext of the private key; then, the ciphertext of the private key and the ciphertext of the data key are stored on the client, realizing the encrypted storage of the private key and reducing the risk of private key leakage. On the other hand, the private key is encrypted by the TEE, so that the plaintext of the private key remains in the TEE for confidential computing, and the private key cannot be accessed by an external untrusted environment, which can further improve the security of the private key.

The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

It should be noted that the same reference numerals denote the same objects in the following drawings and embodiments, and therefore, once an object is defined in one drawing or embodiment, it does not need to be further discussed in the subsequent drawings and embodiments.

2 to 5 are schematic diagrams of the structure of the communication system provided in the embodiment of the present application. In conjunction with FIG2 to 5 , the communication system includes: a client 10 , a first service node 30 and a second service node 40 .

Regarding the implementation form of the client 10, please refer to the relevant content of Figure 1, which will not be repeated here. The first service node 30 runs a trusted execution environment (TEE). In confidential computing, the computing entity running TEE is called an enclave. The calculations and memory operations performed in the enclave are invisible to user applications and the operating system kernel.

Enclave can provide a trusted isolation space to encapsulate software into the Enclave, ensuring the confidentiality and integrity of software code and data and protecting them from attacks by malicious software.

The first service node 30 may create an Enclave based on the Software Guard Extensions (SGX) technology as a Trusted Execution Environment (TEE); and may allocate a portion of the Enclave Page Cache (EPC) in the memory of the first service node 30 for the above-mentioned Enclave to reside. The central processing unit (CPU) of the first service node 30 may create one or more Enclaves at the same time, and the codes run by different Enclaves may be the same or different, depending on the purpose of the corresponding Enclave. The CPU may divide the computing resources and create the Enclave as a Trusted Execution Environment. The computing resources may include a virtual CPU (vCPU) and memory. The vCPU and memory allocated to the Enclave are isolated from other CPUs and memories on the host of the first service node 30.

In this embodiment, the first service node 30 can be implemented as an independent physical machine to provide TEE services. Of course, the first service node 30 can also be deployed on the same physical machine as the client 10, as a functional module providing TEE on the client 10.

In this embodiment, the second service node 40 can provide a key management service (KMS). KMS can provide a key management and data encryption service platform with simple, reliable, secure, and compliant data encryption protection capabilities. The key management service can be implemented as a software as a service (SaaS) product and deployed in the cloud.

To improve key security, KMS can provide a customer master key (CMK). Each user corresponds to a unique CMK. The user is generally a client 10 user. CMK is a key created by a user or cloud service through key management, mainly used to encrypt and protect a data key (DK). A customer master key can encrypt multiple data keys. A CMK can derive multiple DKs. Different applications of users can adopt Use different DKs to encrypt data, so that even if a DK is lost, it will not affect the use of other applications. If the same CMK is used to encrypt all application data of the user, once the CMK is lost, the security of all application data will be affected.

Based on the scenario of communication between the client 10 and the server 20 based on a security protocol as shown in FIG1 above, the client 10 can access the server 20 based on the security protocol. The client 10 can be a client of the security protocol. The server 20 can be a server of the security protocol. Specifically, the client 10 can access the server 20 using the public-private key pair mechanism provided by the security protocol. A security protocol refers to a message exchange protocol based on cryptography, the purpose of which is to provide various security services in a network environment. The security protocol may be the SSH protocol, the Telnet protocol, or the Secure Socket Layer (SSL) protocol, but is not limited thereto. Regarding the process of the client 10 accessing the server 20 using the public-private key pair mechanism provided by the security protocol, please refer to the relevant content of FIG1 above, which will not be repeated here.

In this embodiment, in order to improve the security of the private key, TEE and KMS are introduced to protect the private key in the public-private key pair of the security protocol. Specifically, in conjunction with Figures 2 and 3, the client 10 can call the TEE provided by the first service node 30 to encrypt the private key in the public-private key pair of the target user (corresponding to step 1 in Figure 2 and step 1 in Figure 3). Among them, the target user is the user of the client 10.

It is worth noting that before using the TEE running on the first service node 30, the client 10 needs to ensure that the TEE is trustworthy. This requires trusted authentication of the TEE. Remote Attestation (RA) can be used for trusted authentication of the Enclave. Among them, RA refers to a technology in which a computing system (prover) proves its software and/or hardware configuration and status to a remote system (verifier). A remote attestation system usually consists of two parts: a prover and a verifier. The prover side has a system integrity measurement (Integrity Measurement) mechanism, which can report the measurement value of its own system to the verifier through the remote attestation protocol (RAP) based on the remote attestation protocol (Remote Attestation Protocol, RAP) between the prover and the verifier, so that the verifier can verify the integrity of the prover system.

In this embodiment, the client 10 can act as a verifier, also known as a challenger. The TEE in the first service node 30 acts as a prover. The RA service node 50 refers to a device, module or virtual instance that provides remote attestation services. A virtual instance can be a virtual machine, a container group (such as a Pod) or a container. The remote attestation service provided by the RA service node 50 can be a SaaS product. The remote attestation process of TEE is exemplified below in conjunction with Figure 4.

Before using the TEE provided by the first service node 30, the client 10 needs to perform trustworthy verification on the TEE. Under the condition that the TEE is verified to be a trusted executable environment, the TEE can be called to encrypt the private key in the public-private key pair of the target user.

As shown in Figure 4, the client 10 can use remote attestation technology to verify the credibility of the TEE. Specifically, the client 10 can initiate a remote attestation (RA) request to the TEE in the first service node 30 (corresponding to step 1 in Figure 4). The TEE in the first service node 30 receives the RA request, and in response to the RA request, generates the TEE's identity key and remote attestation report (Report) (corresponding to step 2 in Figure 4). The first service node 30 can provide the TEE's identity key and remote attestation report (Report) to the RA service node 50 (corresponding to step 3 in Figure 4).

The RA service node 50 can verify the legitimacy of the TEE's identity key based on the remote attestation report (Report); and if the verification result shows that the TEE is legal, it will issue an identity authentication certificate for the TEE. Further, the RA service node 50 can obtain the TEE's citation information (Quotes), and use the local public key to encrypt the TEE's citation information to obtain the encrypted citation information (corresponding to step 4 of Figure 4). The citation information may include: the Enclave's identity authentication certificate, measurement log, and signature value. The measurement log may include: the TEE's operating status, security version number (Security Version Number, SVN), hardware signature information (such as PCK cert) and Trusted Computing Base (TCB) information, etc.

Furthermore, the RA service node 50 may send the encrypted reference information to the client 10 (corresponding to step 5 in FIG. 4 ). The client 10 may call the RA service node 50 to perform remote certification on the encrypted reference information (corresponding to step 6 in FIG. 4 ).

Specifically, the client 10 may provide the encrypted citation information to the RA service node 50. The RA service node 50 may use the local private key to decrypt the encrypted citation information to obtain the citation information of the TEE. Further, the credibility of the TEE may be verified based on the citation information of the TEE (corresponding to step 7 of Figure 4), and the verification result may be returned to the client 10 (corresponding to step 8 of Figure 4). The verification result is used to indicate whether the TEE is credible, that is, the verification result is whether the TEE is credible or not.

The above embodiment describes the TEE credibility verification process by way of example, but does not constitute a limitation. As shown in FIG2 , when the client 10 confirms that the TEE is credible, it can call the TEE to encrypt the private key in the public-private key pair of the target user (corresponding to step 1 in FIG2 and step 1 in FIG3 ). The target user is the user of the client 10.

Accordingly, the first service node 30 can use TEE to obtain the public-private key pair to be protected of the target user (corresponding to step 2 of Figure 2 and step 2 of Figure 3). The public-private key pair can be generated by the first service node 30 for the target user in TEE, or it can be the public-private key pair imported into TEE by the client 10.

In some embodiments, the client 10 may initiate a key application request to the TEE (corresponding to step 1 in Figure 3). The first service node 30 may use the TEE to receive the key application request, and use the TEE to generate a public-private key pair for the target user in response to the key application request as the public-private key pair to be protected (corresponding to step 2 in Figure 3). In the embodiment of the present application, the specific implementation method of TEE generating a public-private key pair for the target user is not limited. Optionally, TEE may use a key generator to generate a public-private key pair for the target user. Alternatively, TEE may call the KMS provided by the second service node 40 to generate a public-private key pair for the target user.

In other embodiments, the public-private key pair to be protected may also be the public-private key pair provided by the client 10 to the TEE (corresponding to step 1 "Importing the public-private key pair" in FIG. 3). Accordingly, the TEE may receive the public-private key pair provided by the client 10 as the public-private key pair to be protected (corresponding to step 2 "Obtaining the imported public-private key pair" in FIG. 3).

After obtaining the target user's public and private key pair to be protected, TEE can obtain the target user's data key and the ciphertext of the data key from KMS (corresponding to step 3 of Figure 2 and steps 3-5 of Figure 3).

Specifically, TEE can initiate a key application request to KMS (corresponding to step 3 "Apply for DK" in Figure 3). The key application request may include the identity of the target user. Accordingly, KMS receives the key application request and obtains the target user's master key, that is, the target user's DMK, based on the identity of the target user carried in the key application request. The target user's DMK is pre-created for the target user by KMS, that is, the target user has applied for KMS. In the first step, KMS can generate a data key of the target user based on the DMK of the target user (corresponding to step 3 and step 4 of Figure 2 "CMK derives DK"). Optionally, KMS can derive at least one data key (DK) based on the DMK of the target user using a key derivation function.

Further, KMS can encrypt the data key to obtain the ciphertext of the data key (corresponding to step 4 of Figure 3 "Generate ciphertext of DK"). In this embodiment, the key for encrypting the data key is not limited. In some embodiments, the DMK of the target user can be used as a key to encrypt the data key to obtain the ciphertext of the data key. In other embodiments, KMS can use a key derivation function based on the DMK of the target user to derive multiple data keys (such as 2 data keys DK1 and DK2), and one of the multiple data keys (such as DK1) can be used as the data key of the target user; the other (such as DK2) can be used as the data key for encrypting the data key of the target user. Accordingly, the data key DK2 can be used to encrypt the data key DK1 of the target user to obtain the ciphertext of the data key DK1 of the target user.

Furthermore, KMS can return the target user's data key and the ciphertext of the data key to TEE (corresponding to step 3 of Figure 2 and step 5 of Figure 3). TEE can use the data key to encrypt the private key in the public-private key pair to obtain the ciphertext of the private key (corresponding to step 4 of Figure 2 and step 6 of Figure 3); further, the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key can be returned to the client 10 (corresponding to step 5 of Figure 2 and step 7 of Figure 3).

The client 10 may receive the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key; and store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key (corresponding to step 6 of FIG. 2 and step 8 of FIG. 3 ). Optionally, for the SSH protocol, the client 10 may store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key in the .ssh directory.

In this embodiment, TEE and KMS are introduced to protect the private key in the security protocol. Specifically, TEE calls KMS to obtain the data key and ciphertext of the data key of the client user, and encrypts the private key in TEE using the data key to obtain the ciphertext of the private key; then, the ciphertext of the private key and the ciphertext of the data key are stored in the client, thereby realizing the encrypted storage of the private key and reducing the risk of private key leakage. On the other hand, TEE encrypts the private key so that the plaintext of the private key remains in the confidential computing TEE, and the external untrusted environment cannot access the private key, which can further improve the security of the private key.

Since the target user's data key is managed and controlled by KMS, the life cycle of the private key in the public-private key pair can be managed through the life cycle of the data key managed by KMS, and the key management method consistent with KMS can be maintained. For example, the private key can be cancelled by canceling the data key through KMS. Since the ciphertext of the private key is encrypted with the data key as the key, after the data key is cancelled, the ciphertext of the private key will naturally become invalid because there is no decryption key. For another example, the rotation of the data key can be achieved through KMS to rotate the private key.

Among them, key rotation means: in scenarios with high security requirements, the key of the encrypted data must be changed periodically, and the same key cannot be used to encrypt and protect the data for a long time. This encryption method of regularly changing the key is called key rotation. Specifically, the data key can be rotated and updated through KMS; and the updated data key pair can be sent to TEE, which encrypts the private key in the public-private key pair to obtain the updated ciphertext of the private key, thereby realizing private key rotation.

In the embodiment of the present application, the client 10 can also register the public key in the public-private key pair to the server 20 (corresponding to step 7 of FIG. 2 and step 9 of FIG. 3). Based on the private key protection method provided in the above embodiment, the embodiment of the present application also provides a corresponding server access method. The following is an exemplary description of the server access process provided in the embodiment of the present application.

As shown in FIG5 , when the client 10 accesses the server 20, it may initiate an access request to the server 20 (corresponding to step 1 in FIG5 ). The server 20 receives the access request, generates a random number in response to the access request, and encrypts the random number using the public key in the public-private key pair of the target user to obtain the ciphertext of the random number (corresponding to step 2 “public key encryption of random number” in FIG5 ). Afterwards, the server 20 may return the ciphertext of the random number to the client 10 (corresponding to step 3 in FIG5 ).

The client 10 receives the ciphertext of the random number and initiates a decryption request to the TEE in the first service node 30 (corresponding to step 4 in FIG. 5 ). Specifically, the client 10 can generate a decryption request based on the ciphertext of the random number, the ciphertext of the data key, and the ciphertext of the private key in the public-private key pair of the target user. The decryption request includes the ciphertext of the random number, the ciphertext of the data key, and the ciphertext of the private key in the public-private key pair of the target user.

Optionally, the client 10 can call the TEE through the ecall method and request the TEE to decrypt the ciphertext of the random number. The ecall method is a method provided by the TEE (such as Enclave) and called by an external program (i.e., an untrusted environment) of the TEE (such as Enclave). In other words, the ecall method is the only channel for the outside of the TEE to access the inside of the TEE, but its execution process is protected by a trusted environment. Alternatively, the client 10 can call the TEE through the Application Programming Interface (API) and request the TEE to decrypt the ciphertext of the random number, etc.

Correspondingly, TEE receives the decryption request and calls KMS to decrypt the ciphertext of the data key to obtain the data key of the target user (corresponding to steps 5-7 in Figure 5).

Specifically, TEE can call KMS and send the ciphertext of the data key and the identifier of the target user to KMS (corresponding to step 5 of Figure 5). KMS can decrypt the ciphertext of the data key to obtain the data key of the target user (corresponding to step 6 of Figure 5). Specifically, for the above-mentioned KMS using the user master key (DMK) of the target user as the key to encrypt the data key of the target user, KMS can obtain the user master key (DMK) of the target user based on the identifier of the target user, and use the DMK to decrypt the ciphertext of the data key of the target user to obtain the data key of the target user. For the above-mentioned KMS, another data key DK2 derived from the DMK of the target user is used to decrypt the ciphertext of the data key DK1 of the target user to obtain the data key DK1 of the target user.

Furthermore, KMS can return the data key of the target user to TEE (corresponding to step 7 of Figure 5). TEE receives the data key and uses the data key of the target user to decrypt the ciphertext of the private key to obtain the plaintext of the private key (corresponding to step 8 of Figure 5). Furthermore, TEE can use the private key to decrypt the ciphertext of the random number to obtain the plaintext of the random number (corresponding to step 9 of Figure 5).

Furthermore, the TEE may return the plain text of the random number to the client 10 (corresponding to step 10 in FIG. 5 ). The client 10 may access the server 20 based on the plain text of the random number.

Specifically, the client 10 may send the plain text of the random number to the server 20 (corresponding to step 11 in FIG. 5 ). The server 20 may perform access rights on the client 10 based on the random number received from the client and the random number generated by itself. Verify (corresponding to step 12 in FIG. 5 ), and return the permission verification result to the client 10 (corresponding to step 13 in FIG. 5 ). If the random number provided by the client received by the server 20 is consistent with the random number generated by itself, it means that the client 10 has the private key corresponding to the public key, that is, the client 10 has access rights, then it is determined that the client 10 has access rights to the server 20, and the client 10 is allowed to access the server 20. Correspondingly, if the random number provided by the client received by the server 20 is inconsistent with the random number generated by itself, it means that the client 10 does not have the private key corresponding to the public key, then it is determined that the client 10 does not have access rights to the server 20, and the client 10 is blocked from accessing the server 20. Of course, a prompt message indicating that there is no access right can also be returned to the client 10.

In this embodiment, during the access rights verification process of the client accessing the server based on the public-private key pair mechanism, the private key in the public-private key pair of the security protocol is kept in the trusted execution environment (TEE) of confidential computing, and the private key cannot be accessed by an external untrusted environment. Even if the user's client, such as a virtual machine, is hacked, it can be guaranteed that the private key will not be lost, which can reduce the risk of private key leakage. On the other hand, the private key is stored and transmitted in ciphertext, which can reduce the risk of plaintext exposure of the private key.

In addition, the above-mentioned interaction process between the client and the server is compatible with the original security protocol process (such as the SSH protocol process), and no changes are required to the server of the security protocol (such as SSH). The client of the security protocol (such as SSH) can add a calling interface for TEE, such as an application programming interface (Application Programming Interface, API), to implement the call to TEE, thereby realizing the interaction process between the client and the server. This lightweight modification can maintain good compatibility and improve the universality and versatility of the solution provided in this embodiment.

In addition to the above system embodiments, the embodiments of the present application also provide a private key access method and a server access method. The following is an exemplary description of the private key access method and the server access method provided in the embodiments of the present application from the perspectives of the client and the first service node running TEE.

FIG6 is a flow chart of a private key access method provided in an embodiment of the present application. The method can be applied to a service node running a TEE. As shown in FIG6 , the method mainly includes:

601. Using TEE, obtain the public and private key pair to be protected of the target user.

602. Use TEE to obtain the target user's data key and the ciphertext of the data key from KMS.

603. In the TEE, the private key in the public-private key pair is encrypted using the data key to obtain the ciphertext of the private key.

604. Using TEE, the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key are returned to the user's client, so that the client can store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key.

FIG7 is a flow chart of another private key access method provided by an embodiment of the present application. The method can be applied to a client of a security protocol. As shown in FIG7 , the method mainly includes:

701. Call TEE to encrypt the private key in the public-private key pair of the target user, so that TEE can call KMS to obtain the data key and ciphertext of the data key of the target user, and use the data key to encrypt the private key to obtain the ciphertext of the private key.

702. Receive the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key returned by the TEE.

703. Store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key.

In this embodiment, the client can access the server based on the security protocol. The client can be a client of the security protocol. The server may be a server of a security protocol. Specifically, the client may access the server using a public-private key pair mechanism provided by the security protocol.

In this embodiment, in order to improve the security of the private key, TEE and KMS are introduced to protect the private key in the public-private key pair of the security protocol. Specifically, for the client, as shown in step 701 of Figure 7, TEE can be called to encrypt the private key in the public-private key pair of the target user. The target user is the user of the client.

It is worth noting that before using TEE, the client needs to ensure that TEE is trustworthy. This requires trustworthy authentication of TEE. For the specific implementation of trustworthy authentication of TEE, please refer to the relevant content of Figure 4 above, which will not be repeated here.

When the client confirms that the TEE is credible, in step 701 , the TEE may be called to encrypt the private key in the public-private key pair of the target user, where the target user is the user of the client 10 .

Accordingly, for a service node running TEE, the public-private key pair to be protected of the target user can be obtained by using TEE in step 601. The public-private key pair can be generated for the target user in TEE, or can be a public-private key pair imported into TEE by the client.

In some embodiments, the client may initiate a key application request to the TEE. The service node running the TEE may use the TEE to receive the key application request, and use the TEE to generate a public-private key pair for the target user in response to the key application request as the public-private key pair to be protected.

In other embodiments, the public-private key pair to be protected may also be a public-private key pair provided by the client to the TEE. Accordingly, the TEE may be used to receive the public-private key pair provided by the client as the public-private key pair to be protected.

After obtaining the public and private key pair to be protected of the target user, TEE can use TEE to obtain the data key and the ciphertext of the data key of the target user from KMS in step 602.

Specifically, TEE may initiate a key application request to KMS. The key application request may include the identifier of the target user. Accordingly, KMS receives the key application request and obtains the target user's master key, that is, the target user's DMK, based on the identifier of the target user carried in the key application request. Among them, the target user's DMK is pre-created by KMS for the target user, that is, the target user has applied for KMS. Further, KMS may generate a data key for the target user based on the target user's DMK. Optionally, KMS may use a key derivation function to derive at least one data key based on the target user's DMK. Further, KMS may encrypt the data key to obtain a ciphertext of the data key.

Furthermore, KMS can return the target user's data key and the ciphertext of the data key to TEE. Accordingly, TEE can receive the target user's data key and the ciphertext of the data key. Furthermore, in step 602, the private key in the public-private key pair can be encrypted in TEE using the data key to obtain the ciphertext of the private key; further, in step 603, TEE can be used to return the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key to the client.

In step 702, the client can receive the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key; and in step 703, store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key (corresponding to step 6 of Figure 2 and step 8 of Figure 3). Optionally, for the SSH protocol, the client can store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key. The ciphertext of the public key and data key in the .ssh directory.

In this embodiment, TEE and KMS are introduced to protect the private key in the security protocol. Specifically, TEE calls KMS to obtain the data key and ciphertext of the data key of the client user, and encrypts the private key in TEE using the data key to obtain the ciphertext of the private key; then, the ciphertext of the private key and the ciphertext of the data key are stored in the client, thereby realizing the encrypted storage of the private key and reducing the risk of private key leakage. On the other hand, TEE encrypts the private key so that the plaintext of the private key remains in the confidential computing TEE, and the private key cannot be accessed by an external untrusted environment, which can further improve the security of the private key.

Specifically, the data key can be rotated and updated through KMS; and the updated data key pair is sent to TEE, which encrypts the private key in the public-private key pair to obtain the updated ciphertext of the private key, thereby realizing private key rotation.

In the embodiment of the present application, the client can also register the public key in the public-private key pair to the server. Based on the private key protection method provided in the above embodiment, the embodiment of the present application also provides a corresponding server access method. The following is an exemplary description of the server access process provided in the embodiment of the present application.

FIG8 is a flow chart of a method for accessing a server provided in an embodiment of the present application. The method is applicable to a client of a security protocol. As shown in FIG8 , the method mainly includes:

801. Initiate an access request to the server, so that the server responds to the access request and uses the public key in the public-private key pair of the target user corresponding to the client to encrypt the random number to obtain the ciphertext of the random number; the client stores the ciphertext of the private key in the public-private key pair and the ciphertext of the data key of the target user.

802. Receive the ciphertext of the random number returned by the server.

803. Initiate a decryption request to TEE, where the decryption request includes the ciphertext of the random number, the ciphertext of the data key, and the ciphertext of the private key, so that TEE can call KMS to decrypt the ciphertext of the data key to obtain the data key, and use the data key to decrypt the ciphertext of the private key to obtain the private key; and use the private key to decrypt the ciphertext of the random number to obtain the plaintext of the random number.

804. Receive the plaintext of the random number returned by TEE.

805. Access the server based on the plain text of the random number.

FIG9 is a flow chart of another server access method provided in an embodiment of the present application. The method can be applied to a service node running a TEE. As shown in FIG9 , the method mainly includes:

901. Use TEE to obtain the decryption request initiated by the client; the decryption request includes the ciphertext of the random number, the ciphertext of the data key and the ciphertext of the private key; the ciphertext of the random number is obtained by the server responding to the client's access request, using the public key in the public-private key pair to encrypt the random number; the client stores the ciphertext of the data key and the ciphertext of the private key.

902. Use TEE to call KMS to decrypt the ciphertext of the data key to obtain the data key.

903. Decrypt the ciphertext of the private key using the data key in the TEE to obtain the private key.

904. Decrypt the ciphertext of the random number using the private key in the TEE to obtain the plaintext of the random number.

905. Use TEE to return the plain text of the random number to the client, so that the client can access the server based on the plain text of the random number.

In this embodiment, when the client accesses the server, in step 801, it may initiate an access request to the server. The server receives the access request, generates a random number in response to the access request, and encrypts the random number using the public key in the public-private key pair of the target user to obtain a ciphertext of the random number. Afterwards, the server may return the ciphertext of the random number to the client.

For the client, in step 802, the ciphertext of the random number returned by the server can be received; and in step 803, a decryption request can be initiated to the TEE. Specifically, a decryption request can be generated based on the ciphertext of the random number, the ciphertext of the data key, and the ciphertext of the private key in the public-private key pair of the target user. The decryption request includes the ciphertext of the random number, the ciphertext of the data key, and the ciphertext of the private key in the public-private key pair of the target user.

Optionally, the TEE can be called through the ecall method to request the TEE to decrypt the ciphertext of the random number. Alternatively, the client can call the TEE through the API to request the TEE to decrypt the ciphertext of the random number.

Correspondingly, for the service node running TEE, in step 901, the decryption request can be received; and in step 902, TEE is used to call KMS to decrypt the ciphertext of the data key to obtain the data key of the target user.

Specifically, TEE can call KMS and send the ciphertext of the data key and the identifier of the target user to KMS. KMS can decrypt the ciphertext of the data key to obtain the data key of the target user. Specifically, for the above-mentioned embodiment in which KMS uses the user master key (DMK) of the target user as the key to encrypt the data key of the target user, KMS can obtain the user master key (DMK) of the target user according to the identifier of the target user, and use the DMK to decrypt the ciphertext of the data key of the target user to obtain the data key of the target user. For the above-mentioned KMS, another data key DK2 derived from the DMK of the target user is used to decrypt the ciphertext of the data key DK1 of the target user to obtain the data key DK1 of the target user.

Furthermore, KMS can return the data key of the target user to TEE. For the service node running TEE, the data key can be received, and in step 903, the ciphertext of the private key is decrypted in TEE using the data key of the target user to obtain the plaintext of the private key. Further, in step 904, the ciphertext of the random number is decrypted in TEE using the private key to obtain the plaintext of the random number.

Further, in step 905, the plain text of the random number is returned to the client using TEE. Accordingly, in step 804, the client can receive the plain text of the random number returned by TEE; and in step 805, the server 20 is accessed based on the plain text of the random number.

Specifically, the plain text of the random number can be sent to the server. The server can verify the access rights of the client based on the random number provided by the client and the random number generated by itself, and return the result of the access rights verification to the client. If the random number provided by the client received by the server is consistent with the random number generated by itself, it means that the client has the private key corresponding to the public key, that is, the client has access rights, then it is determined that the client has access rights of the server, and the client is allowed to access. Server. The client can access the server. Accordingly, if the random number provided by the client received by the server is inconsistent with the random number generated by itself, it means that the client does not have the private key corresponding to the public key, that is, the client does not have the access rights of the server, then it is determined that the client does not have the access rights of the server, and the client is blocked from accessing the server. Of course, a prompt message of no access rights can also be returned to the client.

In this embodiment, during the access rights verification process of the client accessing the server based on the public-private key pair mechanism, the private key in the public-private key pair of the security protocol is kept in the trusted execution environment (TEE) of confidential computing, and the private key cannot be accessed by an external untrusted environment. Even if the user's client, such as a virtual machine, is hacked, it can ensure that the private key will not be lost, which can reduce the risk of private key leakage. On the other hand, the private key is stored and transmitted in ciphertext, which can reduce the risk of plaintext exposure of the private key.

In addition, the above-mentioned interaction process between the client and the server is compatible with the original security protocol process (such as the SSH protocol process), and no changes are required to the server of the security protocol (such as SSH). The client of the security protocol (such as SSH) can add a calling interface for TEE, such as API, to implement the call to TEE, thereby realizing the interaction process between the client and the server. This lightweight change can maintain good compatibility and improve the universality and versatility of the solution provided by this embodiment.

It should be noted that the execution subject of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 701 and 702 can be device A; for another example, the execution subject of step 701 can be device A, and the execution subject of step 702 can be device B; and so on.

In addition, in some of the processes described in the above embodiments and the accompanying drawings, multiple operations appearing in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this document or may be executed in parallel, and the sequence numbers of the operations, such as 701, 702, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel.

Accordingly, an embodiment of the present application also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the steps in the above-mentioned private key protection method and/or each server access method.

Fig. 10 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. As shown in Fig. 10, the computing device may include: a memory 100a and a processor 100b. The memory 100a is used to store computer programs.

In some embodiments, the computing device runs a TEE, which can be implemented as a service node running the TEE. Accordingly, the processor 100b is coupled to the memory 100a, and is used to execute a computer program for: using the trusted execution environment (TEE) to obtain the public-private key pair to be protected of the target user; using the TEE to obtain the data key and the ciphertext of the data key from the key management service KMS of the target user; in the TEE, using the data key to encrypt the private key in the public-private key pair to obtain the ciphertext of the private key; and using the TEE to return the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key to the user's client, so that the client can store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key.

Optionally, when the processor 100b uses TEE to obtain the user's data key and the ciphertext of the data key from the key management service KMS, it is specifically used to: use TEE to call KMS so that KMS can The master key generates the user's data key and encrypts the data key to obtain the ciphertext of the data key; TEE is used to receive the data key and the ciphertext of the data key returned by KMS.

Optionally, when the processor 100b uses the trusted execution environment TEE to obtain the public-private key pair to be protected, it is specifically used to: use TEE to obtain a key application request provided by the client; use TEE to generate a public-private key pair for the target user in response to the key application request as the public-private key pair to be protected; or, use TEE to receive the public-private key pair provided by the client as the public-private key pair to be protected.

In some embodiments, the processor 100b is also used to: use TEE to obtain a decryption request initiated by the client; the decryption request includes a ciphertext of a random number, a ciphertext of a data key, and a ciphertext of a private key; the ciphertext of the random number is obtained by the server responding to the client's access request, by encrypting the random number using the public key in the public-private key pair; use TEE to call KMS to decrypt the ciphertext of the data key to obtain the data key; use the data key in TEE to decrypt the ciphertext of the private key to obtain the private key; use the private key in TEE to decrypt the ciphertext of the random number to obtain the plaintext of the random number; return the plaintext of the random number to the client, so that the client can request the server to verify the access rights of the client based on the plaintext of the random number.

In some embodiments of the present application, the computing device can also be implemented as a client of the security protocol. Accordingly, the processor 100b is used to: call the trusted execution environment (TEE) to encrypt the private key in the public-private key pair of the target user, so that the TEE can call the KMS to obtain the data key and the ciphertext of the data key of the target user, and use the data key to encrypt the private key to obtain the ciphertext of the private key; receive the ciphertext of the private key returned by the TEE, the public key in the public-private key pair, and the ciphertext of the data key; store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key.

In some embodiments, the processor 100b is also used to: initiate an access request to the server through the communication component 100c, so that the server responds to the access request and uses the public key to encrypt the random number to obtain the ciphertext of the random number; receive the ciphertext of the random number returned by the server through the communication component 100c; and, initiate a decryption request to the TEE, the decryption request includes the ciphertext of the random number, the ciphertext of the data key and the ciphertext of the private key, so that the TEE calls the KMS to decrypt the ciphertext of the data key to obtain the data key, and use the data key to decrypt the ciphertext of the private key to obtain the private key; and use the private key to decrypt the ciphertext of the random number to obtain the plaintext of the random number; and receive the plaintext of the random number returned by the TEE; thereafter, based on the plaintext of the random number, access the server.

In some optional implementations, as shown in FIG10 , the computing device may further include optional components such as a power supply component 100d. In some embodiments, the computing device may be implemented as a terminal device such as a computer. Accordingly, the computing device may further include components such as a display component 100e and an audio component 100f. FIG10 only schematically shows some components, which does not mean that the computing device must include all the components shown in FIG10 , nor does it mean that the computing device can only include the components shown in FIG10 .

The computing device provided in this embodiment introduces TEE and KMS to protect the private key in the security protocol. Specifically, TEE calls KMS to obtain the data key and ciphertext of the data key of the client user, and encrypts the private key in TEE using the data key to obtain the ciphertext of the private key; then, the ciphertext of the private key and the ciphertext of the data key are stored in the client, thereby realizing the encrypted storage of the private key and reducing the risk of private key leakage. On the other hand, TEE encrypts the private key so that the plaintext of the private key remains in the confidential computing TEE, and the private key cannot be accessed by an external untrusted environment, which can further improve the security of the private key.

In an embodiment of the present application, the memory is used to store a computer program and can be configured to store various other data to support operations on the device where it is located. Among them, the processor can execute the computer program stored in the memory to implement the corresponding control logic. The memory 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, disk or optical disk.

In the embodiment of the present application, the processor can be any hardware processing device that can execute the logic of the above method. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU) or a microcontroller unit (MCU); it can also be a field programmable gate array (FPGA), a programmable array logic device (PAL), a general array logic device (GAL), a complex programmable logic device (CPLD) and other programmable devices; or an application specific integrated circuit (ASIC) chip; or an advanced reduced instruction set (RISC) processor (Advanced RISC Machines, ARM) or a system on chip (SoC), etc., but not limited to this.

In an embodiment of the present application, the communication component is configured to facilitate wired or wireless communication between the device in which it is located and other devices. The device in which the communication component is located can access a wireless network based on a communication standard, such as Wireless Fidelity (WiFi), 2G or 3G, 4G, 5G or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component can also be based on Near Field Communication (NFC) technology, Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, Bluetooth (BT) technology or other technologies.

In an embodiment of the present application, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensor may not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

In an embodiment of the present application, a power supply component is configured to provide power to various components of the device in which it is located. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component is located.

In the embodiment of the present application, the audio component can be configured to output and/or input audio signals. For example, the audio component includes a microphone (MIC). When the device where the audio component is located is in an operating mode, such as a call mode, In recording mode and speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in a memory or sent via a communication component. In some embodiments, the audio component also includes a speaker for outputting an audio signal. For example, for a device with a language interaction function, voice interaction with a user can be achieved through the audio component.

It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

It should also be noted that the descriptions such as "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent the order of precedence, nor do they limit "first" and "second" to different types.

It should be understood by those skilled in the art that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

The present application is described with reference to the flowchart and/or block diagram of the method, device (or system) and computer program product according to the embodiment of the present application. It should be understood that each process and/or box in the flowchart and/or block diagram, and the combination of the process and/or box in the flowchart and/or block diagram can be realized 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 produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one process or multiple processes in the flowchart and/or one box or multiple boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

In a typical configuration, a computing device includes one or more processors (such as a CPU, etc.), an input/output interface, a network interface, and a memory.

Memory may include non-permanent storage in computer-readable media, random-access memory (RAM) and/or non-volatile memory such as read-only memory (ROM). Memory, ROM) or Flash RAM. Memory is an example of a computer-readable medium.

The storage medium of a computer is a readable storage medium, which may also be referred to as a readable medium. The readable storage medium includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, modules of programs, 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 Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, magnetic cassettes, disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carriers.

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 further 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 above elements.

The above contents are only embodiments of the present application and are 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 within the scope of the claims of the present application.

Claims

A private key protection method, characterized by comprising:

Use the trusted execution environment TEE to obtain the target user's public and private key pairs to be protected;

Using the TEE to obtain the data key of the target user and the ciphertext of the data key from the key management service KMS;

In the TEE, the private key in the public-private key pair is encrypted using the data key to obtain a ciphertext of the private key;

The TEE is used to return the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key to the user's client, so that the client can store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key.
The method according to claim 1, characterized in that the using the TEE to obtain the user's data key and the ciphertext of the data key from the key management service KMS includes:

Using the TEE to call the KMS, the KMS generates a data key of the user based on the master key of the target user, and encrypts the data key to obtain a ciphertext of the data key;

The TEE is used to receive the data key and the ciphertext of the data key returned by the KMS.
The method according to claim 1, characterized in that the step of obtaining the public and private key pair to be protected by using the trusted execution environment TEE comprises:

Using the TEE, obtaining a key application request provided by the client; using the TEE to generate a public-private key pair for the target user in response to the key application request as the public-private key pair to be protected;

or,

The TEE is used to receive the public-private key pair provided by the client as the public-private key pair to be protected.
The method according to claim 1, further comprising:

The TEE is used to obtain a decryption request initiated by the client; the decryption request includes a ciphertext of a random number, a ciphertext of the data key, and a ciphertext of the private key; the ciphertext of the random number is obtained by the server responding to the client's access request by encrypting the random number using the public key in the public-private key pair;

Using the TEE to call the KMS to decrypt the ciphertext of the data key to obtain the data key;

Decrypting the ciphertext of the private key using the data key in the TEE to obtain the private key;

Decrypting the ciphertext of the random number using the private key in the TEE to obtain the plaintext of the random number;

The plain text of the random number is returned to the client, so that the client can request the server to perform access rights verification on the client based on the plain text of the random number.
A server access method, characterized by comprising:

The trusted execution environment TEE is used to obtain the decryption request initiated by the client; the decryption request includes the ciphertext of the random number, the ciphertext of the data key, and the ciphertext of the private key in the public-private key pair; the ciphertext of the random number is the ciphertext of the server response. The access request of the client is obtained by encrypting a random number using the public key in the public-private key pair; the client stores the ciphertext of the data key and the ciphertext of the private key;

Using the TEE to call KMS to decrypt the ciphertext of the data key to obtain the data key;

Decrypting the ciphertext of the private key using the data key in the TEE to obtain the private key;

Decrypting the ciphertext of the random number using the private key in the TEE to obtain the plaintext of the random number;

The plain text of the random number is returned to the client, so that the client can access the server based on the plain text of the random number.
A private key protection method, characterized by comprising:

Call the trusted execution environment TEE to encrypt the private key in the public-private key pair of the target user, so that the TEE can call the KMS to obtain the data key of the target user and the ciphertext of the data key, and use the data key to encrypt the private key to obtain the ciphertext of the private key;

Receive the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key returned by the TEE;

The ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key are stored.
The method according to claim 6, characterized in that it comprises:

Initiate an access request to the server, so that the server responds to the access request and encrypts the random number using the public key to obtain a ciphertext of the random number;

Receiving the ciphertext of the random number returned by the server;

Initiate a decryption request to the TEE, the decryption request including the ciphertext of the random number, the ciphertext of the data key and the ciphertext of the private key, so that the TEE calls the KMS to decrypt the ciphertext of the data key to obtain the data key, and use the data key to decrypt the ciphertext of the private key to obtain the private key; and use the private key to decrypt the ciphertext of the random number to obtain the plaintext of the random number;

Receive the plaintext of the random number returned by the TEE;

Based on the plain text of the random number, access the server.
A server access method, characterized by comprising:

Initiate an access request to the server, so that the server responds to the access request and uses the public key of the public-private key pair of the target user corresponding to the client to encrypt the random number to obtain the ciphertext of the random number; the client stores the ciphertext of the private key in the public-private key pair and the ciphertext of the data key of the target user;

Receiving the ciphertext of the random number returned by the server;

Initiate a decryption request to the trusted execution environment TEE, the decryption request includes the ciphertext of the random number, the ciphertext of the data key and the ciphertext of the private key, so that the TEE calls the KMS to decrypt the ciphertext of the data key to obtain the data key, and use the data key to decrypt the ciphertext of the private key to obtain the private key; and use the private key to decrypt the ciphertext of the random number to obtain the plaintext of the random number;

Receive the plaintext of the random number returned by the TEE;

Based on the plain text of the random number, access the server.
A communication system, characterized in that it comprises: a client, a first service node, and a second service node; the first service node runs a trusted execution environment TEE; the second service node is used to provide a key management service;

The first service node is used to perform the steps in the method according to any one of claims 1 to 5;

The client is used to execute the steps in the method according to any one of claims 6 to 8.
A computing device, comprising: a memory and a processor; wherein the memory is used to store a computer program;

The processor is coupled to the memory, and is configured to execute the computer program for performing the steps of the method performed by the first service node and/or the client in claim 9.
A computer-readable storage medium storing computer instructions, characterized in that when the computer instructions are executed by one or more processors, the one or more processors are caused to execute the steps in the method executed by the first service node and/or the client in claim 9.