CN116346341A

CN116346341A - Private key protection and server access method, system, equipment and storage medium

Info

Publication number: CN116346341A
Application number: CN202310333675.7A
Authority: CN
Inventors: 路放
Original assignee: Alibaba Cloud Computing Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2023-03-29
Filing date: 2023-03-29
Publication date: 2023-06-27

Abstract

The embodiment of the application provides a private key protection and server access method, a system, equipment and a storage medium. In the embodiment of the application, the TEE and the KMS are introduced to protect private keys in a security protocol. Specifically, the TEE calls the KMS to acquire a data key of a user of the client and a ciphertext of the data key, and encrypts a private key by using the data key in the TEE to obtain the ciphertext of the private key; and then, storing the ciphertext of the private key and the ciphertext of the data key to the client, so that the encryption storage of the private key is realized, and the risk of leakage of the private key can be reduced. On the other hand, the private key is encrypted by the TEE, so that the plaintext of the private key is kept in the TEE of confidential calculation, the external untrusted environment cannot access the private key, and the security of the private key can be further improved.

Description

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

Technical Field

The present disclosure relates to the field of communications technologies, and in particular, to a method, a system, an apparatus, and a storage medium for protecting a private key and accessing a server.

Background

With the vigorous development of Privacy computing (Privacy computer), privacy computing technology has been widely used in various industries. One key technology in the art of privacy computing is cryptography. The security of the private key determines the data security of each environment in the privacy calculation process. How to improve the security of the private key and reduce the risk of disclosure of the private key becomes a technical problem to be solved in the field.

Disclosure of Invention

Aspects of the present application provide a method, a system, a device, and a storage medium for protecting a private key and accessing a server, so as to reduce risk of disclosure of the private key and improve security of the private key.

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

acquiring a public and private key pair to be protected of a target user by utilizing a trusted execution environment TEE;

acquiring a data key of the target user and a ciphertext of the data key from a key management service KMS by using the TEE;

in the TEE, encrypting a private key in the public-private key pair by using the data key to obtain a ciphertext of the private key;

and returning 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 of the user by using the TEE 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:

acquiring a decryption request initiated by the client by using a Trusted Execution Environment (TEE); the decryption request comprises 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 encrypting the random number by using the public key in the public-private key pair by the server in response to the access request of the client; the client stores the ciphertext of the data key and the ciphertext of the private key;

Decrypting ciphertext of the data key by using the TEE call KMS to obtain the data key;

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

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

and returning the plaintext of the random number to the client for the client to access the server based on the plaintext of the random number.

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

invoking a Trusted Execution Environment (TEE) to encrypt a private key in a public-private key pair of a target user, so that the TEE invokes a KMS to acquire a data key of the target user and a ciphertext of the data key, and encrypting the private key by using the data key to obtain the ciphertext of the private key;

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

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

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

Initiating an access request to a server, so that the server responds to the access request and encrypts a random number by utilizing a public key in a public-private key pair of a target user corresponding to a client to obtain a 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 ciphertext of the random number returned by the server;

initiating a decryption request to a Trusted Execution Environment (TEE), wherein the decryption request comprises a ciphertext of a random number, a ciphertext of the data key and a 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 decrypts the ciphertext of the private key by using the data key to obtain the private key; decrypting ciphertext of the random number by utilizing the private key to obtain plaintext of the random number;

receiving a plaintext of the random number returned by the TEE;

and accessing the server based on the plaintext of the random number.

In a fifth aspect, embodiments of the present application further provide a communication system, including: the system 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 for providing key management service;

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

the client is adapted to perform the steps of the method provided in the third and/or fourth aspect of the claims.

In a sixth aspect, embodiments of the present application further provide a computing device, including: a memory and a processor; wherein the memory is used for storing a computer program;

the processor is coupled to the memory for executing the computer program for performing the steps of the method performed by the first serving node in the fifth aspect and/or the client in the fifth aspect described above.

In a seventh aspect, embodiments of the present application further provide a computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps in the method performed by the first serving node and/or the client in the fifth aspect described above.

In an embodiment of the application, a trusted execution environment (Trusted Execution Environment, TEE) and a key management service (Management Service, KMS) are introduced to protect private keys in a security protocol. Specifically, the TEE calls the KMS to acquire a data key of a user of the client and a ciphertext of the data key, and encrypts a private key by using the data key in the TEE to obtain the ciphertext of the private key; and then, storing the ciphertext of the private key and the ciphertext of the data key to the client, so that the encryption storage of the private key is realized, and the risk of leakage of the private key can be reduced. On the other hand, the private key is encrypted by the TEE, so that the plaintext of the private key is kept in the TEE of confidential calculation, the external untrusted environment cannot access the private key, and the security of the private key can be further improved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiments of the application and together with the description serve to explain the application and do not constitute an undue limitation to the application. In the drawings:

FIG. 1 is a schematic diagram of a process for performing authentication login using a public-private key pair provided by an SSH protocol according to a conventional scheme;

fig. 2 and fig. 3 are schematic diagrams illustrating a private key protection process of the communication system according to the embodiments of the present application;

fig. 4 is a schematic diagram of a process of trusted authentication of a TEE by a communication system according to an embodiment of the present application;

fig. 5 is a schematic diagram of a process of accessing a server by using the communication system according to the embodiment of the present application;

fig. 6 and fig. 7 are schematic flow diagrams of a private key protection method according to an embodiment of the present application;

fig. 8 and fig. 9 are schematic flow diagrams of server access provided in the embodiments of the present application;

fig. 10 is a schematic structural diagram of a computing device according to an embodiment of the present application.

Detailed Description

For the purposes, technical solutions and advantages of the present application, the technical solutions of the present application will be clearly and completely described below with reference to specific embodiments of the present application and corresponding drawings. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

Fig. 1 is a schematic diagram of a process for performing authentication login using public-private key pairs provided by Secure Shell (SSH) protocol provided by a conventional scheme. Among other things, the SSH protocol is a protocol for secure telnet and other secure network services over an unsecure network. As shown in fig. 1, the communication system includes: a client 10 and a server 20.

The client 10 is a computer device used by a user and having functions of computing, surfing the internet, and communicating, and may be, for example, a smart phone, a tablet computer, a personal computer, and a wearable device. Of course, the client 10 may also be implemented as a server device. For example, the server may be a single server device, a cloud server array, or a Virtual Machine (VM) running in the cloud server array. In addition, other computing devices having corresponding service capabilities, such as a terminal device (running a service program) such as a computer, may be referred to.

The server 20 is a server device that provides a service to a user in response to a request from the client 10, and generally has the capability of assuming the service and securing the service. The server 20 may be a single server device, a cloud server array, or a Virtual Machine (VM) running in the cloud server array. The server 20 may refer to other computing devices having corresponding service capabilities, such as a terminal device (running a service program) such as a computer. In the embodiment of the present application, the specific implementation form of the service provided by the service end 20 is not limited. Alternatively, the service provided by the service terminal 20 may be a live service, an online shopping service, an instant messaging service, a mailbox 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 perform access right verification on 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 a service provided by the server 20.

In some embodiments, the mechanism may be authenticated for access rights using public and private keys provided by the SSH protocol. Specifically, as shown in fig. 1, the client 10 may generate a public-private key pair and store the public-private key pair under a specified directory (corresponding to step 1 "generate a public-private key pair and store" of fig. 1). Typically "/. Ssh" directory. Further, the client 10 may register the public key in the public-private key pair in the server 20 (corresponding to step 2 of fig. 1).

When the client 10 accesses the server 20, an access request may be initiated to the server 20 (corresponding to step 3 in fig. 1). This 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; encrypting the random number by using a public key in the public-private key pair to obtain a ciphertext of the random number (corresponding to the step 4 'public key encrypted random number' in the step 1); the ciphertext of the random number may then be returned to the client 10 (corresponding to step 5 of fig. 1).

The client 10 receives the ciphertext of the random number, reads the private key in the public-private key pair from the "/. Ssh" directory, and decrypts the random number to obtain the plaintext of the random number (corresponding to step 6 "private key decrypting ciphertext of the random number" in fig. 1); the client 10 may then send the plaintext of the random number to the server 20 (corresponding to step 7 of fig. 1). The server 20 may compare the received random number with the random number stored in itself to perform access right verification on the client 10 (corresponding to step 8 in fig. 1), so as to obtain an access right verification result. The access right verification result indicates that the client has or has no access right to the service. Further, the server 20 may send the result of the access right verification to the client 10 (9 corresponds to step 9 of fig. 1). If the random number received by the server 20 is the same as the random number stored by the server, and it is determined that the client 10 has access rights, an SSH connection with the client 10 is established, 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 the server 20, the server 20 returns a prompt message without access rights to the client 10, and so on.

Based on the above process of accessing the server using the SSH protocol, the private key in the public-private key pair is stored in the "/. SSH" directory of the client in a plaintext form. Although the "/. Ssh" directory is a hidden directory, it is generally known to those skilled in the art that public-private key pairs are stored under the directory, and thus there is a risk of leakage of the private keys in the public-private key pairs. If an attacker steals the SSH private key, the attacker can carry out remote access control or other attack actions on the client and even the server.

To address the above technical issues, in some embodiments of the present application, a trusted execution environment (Trusted Execution Environment, TEE) and a key management service (Management Service, KMS) are introduced to protect private keys in a security protocol. Specifically, the TEE calls the KMS to acquire a data key of a user of the client and a ciphertext of the data key, and encrypts a private key by using the data key in the TEE to obtain the ciphertext of the private key; and then, storing the ciphertext of the private key and the ciphertext of the data key to the client, so that the encryption storage of the private key is realized, and the risk of leakage of the private key can be reduced. On the other hand, the private key is encrypted by the TEE, so that the plaintext of the private key is kept in the TEE of confidential calculation, the external untrusted environment cannot access the private key, and the security of the private key can be further improved.

The following describes in detail the technical solutions provided by the embodiments of the present application with reference to the accompanying drawings.

It should be noted that: like reference numerals denote like objects in the following figures and embodiments, and thus once an object is defined in one figure or embodiment, further discussion thereof is not necessary in the subsequent figures and embodiments.

Fig. 2 to fig. 5 are schematic structural diagrams of a communication system according to an embodiment of the present application. With reference to fig. 2-5, the communication system includes: client 10, first service node 30 and second service node 40.

For the implementation of the client 10, refer to fig. 1, and details thereof are not described herein. The first service node 30 runs a trusted execution environment (Trusted Execution Environment, TEE). The computational entity that the TEE runs in confidential computing is called the Enclave (Enclave), and both the computation and memory operations performed in Enclave are invisible to the user application and to the operating system kernel.

The Enclave can provide a trusted isolation space, and can encapsulate software into the Enclave, so that confidentiality and integrity of software codes and data are guaranteed, and the software is not attacked by malicious software.

The first service node 30 may create Enclave as a trusted execution environment (Trusted Execution Environment, TEE) based on software guard extensions (Software Guard Extensions, SGX) technology; and may allocate a portion of the Enclave page cache (Enclave Page Cache, EPC) in the memory of the first serving node 30 for hosting the Enclave described above. The central processor (Central Processing Unit, CPU) of the first service node 30 may create one or more enclasvs simultaneously, and the code run by different enclasvs may be the same or different, depending on the use of the respective enclasvs. The CPU may slice the computing resources, creating Enclave as a trusted execution environment. The computing resources may include Virtual CPUs (vcpus) and memory. The vCPU and memory allocated to enclaspe are isolated from other CPUs and memory on the host of the first service node 30.

In this embodiment, the first service node 30 may be implemented as an independent physical machine, and provides TEE services. Of course, the first service node 30 may be disposed on the same physical machine as the client 10, as a functional module for providing a TEE on the client 10, and so on.

In this embodiment, the second service node 40 may provide a key management service (Management Service, KMS). The 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 may be implemented as a software as a service (Software as a Service, saaS) product deployed at the cloud.

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

Based on the scenario of communication between the client 10 and the server 20 based on the security protocol shown in fig. 1, the client 10 may access the server 20 based on the security protocol. The client 10 may be a client of a security protocol. The server 20 may be a server of a security protocol. Specifically, the client 10 may access the server 20 using a public-private key pair mechanism provided by a security protocol. The security protocol refers to a cryptographic-based message exchange protocol, the purpose of which is to provide various security services in a network environment. The security protocol may be, but is not limited to, SSH protocol, remote terminal (Telnet) protocol, or secure socket layer (Secure Socket Layer, SSL) protocol, etc. For the process that the client 10 accesses the server 20 by using the public-private key pair mechanism provided by the security protocol, refer to the relevant content of fig. 1, and will not be described herein.

In this embodiment, in order to improve security of the private key, a TEE and a KMS are introduced to protect the private key in the public-private key pair of the security protocol. Specifically, referring to fig. 2 and 3, the client 10 may 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 fig. 2 and step 1 in fig. 3). Wherein the target user is the user of the client 10.

It should be noted that the client 10 needs to ensure that the TEE is trusted before using the TEE operated by the first service node 30. This requires trusted authentication of the TEE. Remote attestation (Remote Attestation, RA) can be used for trusted authentication of Enclave. Where RA refers to a technique by which a computing system (Prover) proves its software and/or hardware configuration and status to a remote system (Verifier). A remote attestation system typically includes two parts, an attestation and a verifier. The prover side has a system integrity measurement (Integrity Measurement) mechanism capable of reporting the measurement value of the own system to the verifier through a remote attestation protocol (Remote Attestation Protocol, RAP) according to the remote attestation protocol between the prover and the verifier, so that the verifier verifies the system integrity of the prover.

In this embodiment, the client 10 may act as a verifier, and may also be referred to 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, virtual instance, or the like that provides a remote attestation service. The virtual instance may be a virtual machine, a set of containers (e.g., pod), or a Container (Container). The remote attestation service provided by RA service node 50 may be a SaaS-like product. The remote attestation process of the TEE is illustrated in connection with fig. 4.

The client 10 needs to perform a trusted verification on the TEE before using the TEE provided by the first service node 30, and may invoke the TEE to encrypt the private key in the public-private key pair of the target user under the condition that the TEE is verified to be a trusted executable environment.

As shown in fig. 4, the client 10 may utilize remote attestation techniques to verify the trustworthiness of the TEE. Specifically, the client 10 may initiate a Remote Attestation (RA) request to a TEE in the first serving node 30 (corresponding to step 1 of fig. 4). The TEE in the first serving node 30 receives the RA request and generates an identity key and remote attestation Report (Report) of the TEE in response to the RA request (corresponding to step 2 of fig. 4). The first serving node 30 may provide the identity key of the TEE and a remote attestation Report (Report) to the RA serving node 50 (corresponding to step 3 of fig. 4).

RA service node 50 may verify the identity key of the TEE based on a remote attestation Report (Report); and issuing an identity authentication certificate for the TEE under the condition that the verification result is that the TEE is legal. Further, the RA service node 50 may obtain the quote information (Quotes) of the TEE, and encrypt the quote information of the TEE with the local public key to obtain encrypted quote information (corresponding to step 4 of fig. 4). The quote information may include: an identity authentication certificate, a measurement log, a signature value, and the like of enclaspe. The metrics log may include: the TEE's running state, security version number (Security Version Number, SVN), hardware signature information (e.g., PCK cert), trusted computing base (Trusted Computing Base, TCB) information, etc.

Further, RA service node 50 may send the encrypted quote information to client 10 (corresponding to step 5 of fig. 4). The client 10 may invoke the RA service node 50 to remotely attest to the encrypted quote information (corresponding to step 6 of fig. 4).

In particular, the client 10 may provide the encrypted quote information to the RA service node 50. The RA service node 50 may decrypt the encrypted quote information using the local private key to obtain TEE quote information. Further, the TEE may be validated for trustworthiness according to the quote information of the TEE (corresponding to step 7 of fig. 4), and the validation result may be returned to the client 10 (corresponding to step 8 of fig. 4). The verification result is used to indicate whether the TEE is trusted, i.e., the verification result is whether the TEE is trusted or untrusted.

The above-described embodiments exemplarily describe the process of verifying the trustworthiness of the TEE, but do not constitute a limitation. As shown in fig. 2, when the ue is confirmed to be trusted, the client 10 may call the ue to encrypt the private key in the public-private key pair of the target user (corresponding to step 1 in fig. 2 and step 1 in fig. 3). Wherein the target user is the user of the client 10.

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

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

In other embodiments, the public-private key pair to be protected may also be the public-private key pair provided to the TEE by the client 10 (corresponding to step 1 "import public-private key pair" of 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 "obtain imported public-private key pair" in step 2 of fig. 3).

After the TEE obtains the public-private key pair to be protected of the target user, the data key of the target user and the ciphertext of the data key can be obtained from the KMS (corresponding to step 3 of fig. 2 and steps 3-5 of fig. 3).

Specifically, the TEE may initiate a key application request to the KMS (corresponding to step 3 "application DK" of fig. 3). The key application request may include an identification of the target user. Correspondingly, the KMS receives the key application request, and obtains a master key of the target user, namely the DMK of the target user, based on the identification of the target user carried by the key application request. The target user DMK is created for the target user in advance for the KMS, namely the target user has applied for the KMS. Further, the KMS may generate a data key for the target user based on the DMK for the target user (corresponding to step 4"cmk derives DK" of fig. 2, step 3). Alternatively, the KMS may derive at least one Data Key (DK) based on the DMK of the target user using a key derivation function.

Further, the KMS may encrypt the data key to obtain a ciphertext of the data key (ciphertext of the DK generated corresponding to step 4 "of fig. 3). In the present embodiment, a key that encrypts the data key is not limited. In some embodiments, the data key may be encrypted using the DMK of the target user as a key to obtain the ciphertext of the data key. In other embodiments, the KMS may derive a plurality of data keys (e.g., 2 data keys DK1 and DK 2) based on the DMK of the target user using a key derivation function, and may use one of the plurality of data keys (e.g., DK 1) as the data key of the target user; the other (e.g., DK 2) serves as a data key for encrypting the data key of the target user. Accordingly, the data key DK1 of the target user may be encrypted by using the data key DK2 to obtain the ciphertext of the data key DK1 of the target user.

Further, the KMS may return the data key of the target user and ciphertext of the data key to the TEE (corresponding to step 3 of fig. 2 and step 5 of fig. 3). The TEE may encrypt the private key in the public-private key pair with the data key to obtain a ciphertext of the private key (corresponding to step 4 of fig. 2 and step 6 of fig. 3); further, the ciphertext of the private key, the ciphertext of the public key and the data key in the public-private key pair may be returned to the client 10 (corresponding to step 5 of fig. 2 and step 7 of fig. 3).

The client 10 may receive the ciphertext of the private key, the public key of the public-private key pair, and the ciphertext of the data key; and stores the ciphertext of the private key, the ciphertext of the public key and the data key in the public-private key pair (corresponding to step 6 of fig. 2 and step 8 of fig. 3). Alternatively, for SSH protocols, the client 10 may store the ciphertext of the private key, the public key of the public-private key pair, and the ciphertext of the data key under the SSH directory.

In this embodiment, the TEE and KMS are introduced to protect the private key in the security protocol. Specifically, the TEE calls the KMS to acquire a data key of a user of the client and a ciphertext of the data key, and encrypts a private key by using the data key in the TEE to obtain the ciphertext of the private key; and then, storing the ciphertext of the private key and the ciphertext of the data key to the client, so that the encryption storage of the private key is realized, and the risk of leakage of the private key can be reduced. On the other hand, the private key is encrypted by the TEE, so that the plaintext of the private key is kept in the TEE of confidential calculation, the external untrusted environment cannot access the private key, and the security of the private key can be further improved.

Because the data key of the target user is managed and controlled by the KMS, the management of the life cycle of the private key in the public key pair can be realized through the life cycle of the data key managed by the KMS, and the key management method consistent with the KMS is maintained. For example, the private key may be revoked by the KMS revoked data keys. Since the ciphertext of the private key is obtained by encrypting the data key as the key, after the data key is logged off, the ciphertext of the private key is naturally disabled due to the fact that the decrypting key is not available. For another example, private key rotation may be achieved through rotation of data keys by KMS, etc.

Wherein, key rotation refers to: in a scene with high security requirement, the encrypted data is required, the key of the encrypted data must be periodically changed, and the data cannot be encrypted and protected by using the same key for a long time. This way of periodically changing the encryption of the key is called key rotation. Specifically, the data key can be rotated through the KMS to update the data key; and the updated data key pair is sent to the TEE, the TEE encrypts the private key in the public-private key pair to obtain an updated ciphertext of the private key, and the rotation of the private key is realized.

In the embodiment of the present application, the client 10 may 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 manner provided in the above embodiment, the embodiment of the present application further provides a corresponding server access method. The following describes an exemplary server access procedure provided in the embodiment of the present application.

As shown in fig. 5, when the client 10 accesses the server 20, an access request may be initiated to the server 20 (corresponding to step 1 of fig. 5). 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 of the public-private key pair of the target user to obtain a ciphertext of the random number (corresponding to step 2 "public key encrypted random number" of fig. 5). After that, the server 20 may return the ciphertext of the random number to the client 10 (corresponding to step 3 of fig. 5).

The client 10 receives the ciphertext of the random number; and initiates a decryption request to the TEE in the first serving node 30 (corresponding to step 4 of fig. 5). Specifically, the client 10 may generate the decryption request according to 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 a ciphertext of the random number, a ciphertext of the data key, and a ciphertext of a private key of the public-private key pair of the target user.

Alternatively, the client 10 may call the TEE through the ecall method, requesting the TEE to decrypt the ciphertext of the random number. The ecall method is a method provided by the TEE (e.g., enclave) and called by a program (i.e., an untrusted environment) external to the TEE (e.g., enclave). In other words, the ecall method is the only channel that the TEE externally accesses inside the TEE, but its execution is protected by a trusted environment. Alternatively, the client 10 may call the TEE through an application programming interface (Application Programming Interface, API), request the TEE to decrypt the ciphertext of the random number, or the like.

Accordingly, the TEE receives the decryption request; and invokes the KMS to decrypt the ciphertext of the data key to obtain the data key of the target user (corresponding to steps 5-7 of fig. 5).

Specifically, the TEE may invoke the KMS and send the ciphertext of the data key and the identity of the target user to the KMS (corresponding to step 5 of fig. 5). The KMS may decrypt the ciphertext of the data key to obtain the data key of the target user (corresponding to step 6 of fig. 5). Specifically, for the embodiment in which the KMS encrypts the data key of the target user with the user master key (DMK) of the target user, the KMS may obtain the user master key (DMK) of the target user according to the identifier of the target user, and decrypt the ciphertext of the data key of the target user using the DMK to obtain the data key of the target user. And decrypting the ciphertext of the data key DK1 of the target user by using another data key DK2 derived based on the DMK of the target user by the KMS so as to obtain the data key DK1 of the target user.

Further, the KMS may return the data key of the target user to the TEE (corresponding to step 7 of fig. 5). The TEE receives the data key and decrypts the ciphertext of the private key using the data key of the target user to obtain plaintext of the private key (corresponding to step 8 of fig. 5). Further, the TEE may decrypt the ciphertext of the random number using the private key to obtain plaintext of the random number (corresponding to step 9 of fig. 5).

Further, the TEE may return the plaintext of the nonce to the client 10 (corresponding to step 10 of fig. 5). The client 10 may access the server 20 based on the plaintext of the random number.

Specifically, the client 10 may send the plaintext of the random number to the server 20 (corresponding to step 11 of fig. 5). The server 20 may perform access rights verification on the client 10 according to the received random number provided by the client and the random number generated by itself (corresponding to step 12 of fig. 5), and return the rights verification result to the client 10 (corresponding to step 13 of fig. 5). If the random number provided by the client and received by the server 20 is consistent with the random number generated by the client, which indicates that the client 10 has a private key corresponding to the public key, that is, the client 10 has access right, it is determined that the client 10 has the access right of the server 20, and the client 10 is allowed to access the server 20. Accordingly, if the random number provided by the client and received by the server 20 is inconsistent with the random number generated by the client, which means that the client 10 does not have the private key corresponding to the public key, the client 10 is determined to have no access authority of the server 20, and the client 10 is prevented from accessing the server 20. Of course, no access right prompt information and the like can also be returned to the client 10.

In this embodiment, in the process of verifying the access authority of the client to the mechanism access server based on the public and private keys, the private key in the public and private key pair of the security protocol is kept in the Trusted Execution Environment (TEE) of the confidential calculation, and the external untrusted environment cannot access the private key. The client of the instant user, such as a virtual machine, is invaded, so that the private key can be prevented from being lost, and the risk of revealing the private key can be reduced. On the other hand, the private key is stored and transmitted in a ciphertext form, so that the risk of exposing the plaintext of the private key can be reduced.

In addition, the interaction flow between the client and the server can be compatible with the original security protocol flow (such as SSH protocol flow), the server of the security protocol (such as SSH) does not need to be changed, and the calling interface (such as application programming interface (Application Programming Interface, API)) of the TEE can be added to the client of the security protocol (such as SSH), so that the calling of the TEE can be realized, and the interaction flow between the client and the server is realized. The light modification can keep better compatibility, and improves universality and universality of the scheme provided by the embodiment.

In addition to the above system embodiments, the embodiments of the present application further provide a private key access method and a server access method. The private key access method and the server access method provided in the embodiments of the present application are described below in an exemplary manner from the perspective of the client and the first service node running with the TEE, respectively.

Fig. 6 is a flow chart of a private key access method according to an embodiment of the present application. The method may be applicable to a service node running a TEE. As shown in fig. 6, the method mainly includes:

601. and acquiring a public and private key pair to be protected of the target user by using the TEE.

602. And acquiring the data key of the target user and the ciphertext of the data key from the KMS by using the TEE.

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

604. And returning the ciphertext of the private key, the ciphertext of the public key and the ciphertext of the data key in the public-private key pair to the client of the user by using the TEE so as to store the ciphertext of the private key, the ciphertext of the public key and the ciphertext of the data key in the public-private key pair.

Fig. 7 is a flowchart of another private key access method according to an embodiment of the present application. The method is applicable to clients of security protocols. As shown in fig. 7, the method mainly includes:

701. and calling the TEE to encrypt the private key in the public-private key pair of the target user so that the TEE calls the KMS to acquire the data key of the target user and the ciphertext of the data key, and encrypting the private key by using the data key to obtain the ciphertext of the private key.

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

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

In this embodiment, the client may access the server based on a security protocol. The client may be a client of a 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 a security protocol.

In this embodiment, in order to improve security of the private key, a TEE and a 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 fig. 7, the TEE may be invoked to encrypt a private key in the public-private key pair of the target user. Wherein the target user is a user of the client.

It is worth noting that the client needs to ensure that the TEE is trusted before using the TEE. This requires trusted authentication of the TEE. For a specific embodiment of trusted authentication of the TEE, refer to the relevant content of fig. 4, and will not be described herein.

In the case that the ue confirms that the TEE is trusted, in step 701, the TEE may be invoked to encrypt a private key in a public-private key pair of the target user. Wherein the target user is the user of the client 10.

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

In some embodiments, the client may initiate a key application request to the TEE. The service node running the TEE can receive the key application request by using the TEE, and generate a public-private key pair for a target user by using the TEE 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 the public-private key pair provided to the TEE by the client. Accordingly, the TEE may be utilized to receive the public-private key pair provided by the client as the public-private key pair to be protected.

After the TEE obtains the public-private key pair to be protected of the target user, in step 602, the TEE may be utilized to obtain the data key of the target user and the ciphertext of the data key from the KMS.

Specifically, the TEE may initiate a key application request to the KMS. The key application request may include an identification of the target user. Correspondingly, the KMS receives the key application request, and obtains a master key of the target user, namely the DMK of the target user, based on the identification of the target user carried by the key application request. The target user DMK is created for the target user in advance for the KMS, namely the target user has applied for the KMS. Further, the KMS may generate a data key for the target user based on the DMK for the target user. Alternatively, the KMS may derive at least one data key based on the DMK of the target user using a key derivation function. Further, the KMS may encrypt the data key to obtain ciphertext of the data key.

Further, the KMS may return the data key of the target user and ciphertext of the data key to the TEE. Accordingly, the data key of the target user and the ciphertext of the data key may be received for the TEE. Further, in step 602, the private key in the public-private key pair may be encrypted with the data key in the TEE to obtain a ciphertext of the private key; further, in step 603, the ciphertext of the private key, the public key of the public-private key pair, and the ciphertext of the data key may be returned to the client using the TEE.

In step 702, the client may receive ciphertext of the private key, ciphertext of the public key and the data key of the public-private key pair; and in step 703, the ciphertext of the private key, the ciphertext of the public key and the data key in the public-private key pair (corresponding to step 6 of fig. 2 and step 8 of fig. 3) is stored. Optionally, for the SSH protocol, the client may store the ciphertext of the private key, the public key of the public-private key pair, and the ciphertext of the data key under the SSH directory.

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

In the embodiment of the application, the client may also register the public key in the public-private key pair to the server. Based on the private key protection manner provided in the above embodiment, the embodiment of the present application further provides a corresponding server access method. The following describes an exemplary server access procedure provided in the embodiment of the present application.

Fig. 8 is a flowchart of a server access method according to an embodiment of the present application. The method is applicable to clients of security protocols. As shown in fig. 8, the method mainly includes:

801. an access request is initiated to a server, so that the server responds to the access request, and the random number is encrypted by utilizing a public key in a public-private key pair of a target user corresponding to the client to obtain a 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. And receiving the ciphertext of the random number returned by the server.

803. Initiating a decryption request to the TEE, wherein the decryption request comprises a ciphertext of a random number, a ciphertext of a data key and a ciphertext of a private key, so that the TEE calls a KMS to decrypt the ciphertext of the data key to obtain the data key, and decrypting the ciphertext of the private key by using the data key to obtain the private key; and decrypting the ciphertext of the random number by using the private key to obtain a plaintext of the random number.

804. And receiving the plaintext of the random number returned by the TEE.

805. Based on the plaintext of the random number, the server is accessed.

Fig. 9 is a flowchart of another method for accessing a server according to an embodiment of the present application. The method may be applicable to a service node running a TEE. As shown in fig. 9, the method mainly includes:

901. Obtaining a decryption request initiated by a client by using a TEE; the decryption request comprises a ciphertext of the random number, a ciphertext of the data key and a ciphertext of the private key; the ciphertext of the random number is obtained by encrypting the random number by using a public key in a public-private key pair by a server in response to an access request of a client; the client stores the ciphertext of the data key and the ciphertext of the private key.

902. And decrypting the ciphertext of the data key by using the TEE call KMS to obtain the data key.

903. And decrypting the ciphertext of the private key by using the data key in the TEE to obtain the private key.

904. And decrypting the ciphertext of the random number by using the private key in the TEE to obtain a plaintext of the random number.

905. And returning the plaintext of the random number to the client by using the TEE so that the client can access the server based on the plaintext of the random number.

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

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

Alternatively, the TEE may be called by an ecall method, requesting the TEE to decrypt the ciphertext of the random number. Alternatively, the client may call the TEE through an API, request the TEE to decrypt the ciphertext of the random number, and so on.

Accordingly, for the service node running the TEE, the decryption request may be received in step 901; and in step 902, the ciphertext of the data key is decrypted by the TEE call KMS to obtain the data key of the target user.

Specifically, the TEE may invoke the KMS and send the ciphertext of the data key and the identity of the target user to the KMS. The KMS may decrypt the ciphertext of the data key to obtain the data key of the target user. Specifically, for the embodiment in which the KMS encrypts the data key of the target user with the user master key (DMK) of the target user, the KMS may obtain the user master key (DMK) of the target user according to the identifier of the target user, and decrypt the ciphertext of the data key of the target user using the DMK to obtain the data key of the target user. And decrypting the ciphertext of the data key DK1 of the target user by using another data key DK2 derived based on the DMK of the target user by the KMS so as to obtain the data key DK1 of the target user.

Further, the KMS may return the data key of the target user to the TEE. For the service node running the TEE, the data key may be received, and in step 903, the ciphertext of the private key is decrypted in the 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 the TEE using the private key to obtain the plaintext of the random number.

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

Specifically, the plaintext of the random number may be sent to the server. The server side can carry out access right verification on the client side according to the received random number provided by the client side and the random number generated by the server side, and returns a right verification result to the client side. If the random number provided by the client received by the server is consistent with the random number generated by the client, the client is informed of having the private key corresponding to the public key, namely, the client has the access right, the client is determined to have the access right of the server, and the client is allowed to access the server. The client may access the server. Correspondingly, if the random number provided by the client received by the server is inconsistent with the random number generated by the client, the private key corresponding to the public key is not provided for the client, namely, the client has no access right of the server, the client is determined to have no access right of the server, and the client is prevented from accessing the server. Of course, no access right prompt information and the like can also be returned to the client.

In addition, the interaction flow between the client and the server can be compatible with the original security protocol flow (such as SSH protocol flow), the server of the security protocol (such as SSH) does not need to be changed, and the calling interface, such as API, of the TEE can be added to the client of the security protocol (such as SSH), so that the TEE can be called, and the interaction flow between the client and the server is realized. The light modification can keep better compatibility, and improves universality and universality of the scheme provided by the embodiment.

It should be noted that, the execution subjects of each step of the method provided in the above embodiment may be the same device, or the method may also be executed by different devices. For example, the execution subject of

steps

701 and 702 may be device a; for another example, the execution body of step 701 may be device a, and the execution body of step 702 may be device B; etc.

In addition, in some of the above embodiments and the flows described in the drawings, a plurality of operations appearing in a specific order are included, but it should be clearly understood that the operations may be performed out of the order in which they appear herein or performed in parallel, the sequence numbers of the operations such as 701, 702, etc. are merely used to distinguish between the various operations, and the sequence numbers themselves do not represent any order of execution. In addition, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel.

Accordingly, embodiments of the present application also provide a computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps in the private key protection method and/or the respective server access method described above.

Fig. 10 is a schematic structural diagram of a computing device according to an embodiment of the present application. As shown in fig. 10, the computing device may include: a memory 100a and a processor 100b. Wherein the memory 100a is used for storing a computer program.

In some embodiments, the computing device is running a TEE, which may be implemented as a service node running the TEE. Accordingly, the processor 100b is coupled to the memory 100a for executing a computer program for: acquiring a public and private key pair to be protected of a target user by using a Trusted Execution Environment (TEE); acquiring a data key of a target user and a ciphertext of the data key from a key management service KMS by using a TEE; in the TEE, encrypting the private key in the public-private key pair by using the data key to obtain a ciphertext of the private key; and returning the ciphertext of the private key, the ciphertext of the public key and the ciphertext of the data key in the public-private key pair to the client of the user by using the TEE so that the client can store the ciphertext of the private key, the ciphertext of the public key and the ciphertext of the data key in the public-private key pair.

Optionally, the processor 100b is specifically configured to, when acquiring the data key of the user and the ciphertext of the data key from the key management service KMS by using the TEE: calling the KMS by using the TEE to enable the KMS to generate a data key of a user based on a master key of a target user, and performing encryption processing on the data key to obtain a ciphertext of the data key; and receiving the ciphertext of the data key returned by the KMS by using the TEE.

Optionally, the processor 100b is specifically configured to, when acquiring the public-private key pair to be protected by using the trusted execution environment TEE: acquiring a key application request provided by a client by using a TEE; generating a public-private key pair for a target user by using the TEE in response to a key application request, wherein the public-private key pair is used as a public-private key pair to be protected; or, receiving the public and private key pair provided by the client by using the TEE as the public and private key pair to be protected.

In some embodiments, the processor 100b is further configured to: obtaining a decryption request initiated by a client by using a TEE; the decryption request comprises a ciphertext of the random number, a ciphertext of the data key and a ciphertext of the private key; the ciphertext of the random number is obtained by encrypting the random number by using a public key in a public-private key pair by a server in response to an access request of a client; decrypting the ciphertext of the data key by using the TEE call KMS to obtain the data key; decrypting the ciphertext of the private key in the TEE by using the data key to obtain the private key; decrypting the ciphertext of the random number in the TEE by using a private key to obtain a plaintext of the random number; and returning the plaintext of the random number to the client so that the client can check the access right of the client based on the plaintext request server of the random number.

In some embodiments of the present application, the computing device may also be implemented as a client of the security protocol. Accordingly, the processor 100b is configured to: invoking a Trusted Execution Environment (TEE) to encrypt a private key in a public-private key pair of a target user, so that the TEE invokes the KMS to acquire a data key of the target user and a ciphertext of the data key, and encrypting the private key by using the data key to obtain the ciphertext of the private key; receiving ciphertext of a private key returned by the TEE, a public key in a public-private key pair and ciphertext of a data key; and storing ciphertext of the private key, the public key in the public-private key pair and ciphertext of the data key.

In some embodiments, the processor 100b is further configured to: initiating an access request to a server through a communication component 100c, so that the server responds to the access request and encrypts the random number by utilizing a public key to obtain a ciphertext of the random number; receiving ciphertext of the random number returned by the server through the communication component 100 c; and initiating a decryption request to the TEE, wherein the decryption request comprises a ciphertext of the random number, a ciphertext of the data key and a 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 decrypts the ciphertext of the private key by using the data key to obtain the private key; decrypting the ciphertext of the random number by using the private key to obtain a plaintext of the random number; receiving a plaintext of the random number returned by the TEE; and then, accessing the server based on the plaintext of the random number.

In some alternative implementations, as shown in fig. 10, the computing device may further include: power supply assembly 100d, and the like. In some embodiments, the computing device may be implemented as a terminal device such as a computer. Accordingly, the computing device may further include: display component 100e, audio component 100f, etc. Only a portion of the components are schematically shown in fig. 10, which does not mean that the computing device must contain all of the components shown in fig. 10, nor that the computing device can only include the components shown in fig. 10.

According to the computing device provided by the embodiment, the TEE and the KMS are introduced to protect the private key in the security protocol. Specifically, the TEE calls the KMS to acquire a data key of a user of the client and a ciphertext of the data key, and encrypts a private key by using the data key in the TEE to obtain the ciphertext of the private key; and then, storing the ciphertext of the private key and the ciphertext of the data key to the client, so that the encryption storage of the private key is realized, and the risk of leakage of the private key can be reduced. On the other hand, the private key is encrypted by the TEE, so that the plaintext of the private key is kept in the TEE of confidential calculation, the external untrusted environment cannot access the private key, and the security of the private key can be further improved.

In embodiments of the present application, the memory is used to store a computer program and may be configured to store various other data to support operations on the device on which it resides. Wherein the processor may execute a computer program stored in the memory to implement the corresponding control logic. The Memory may be implemented by any type or combination of volatile or non-volatile Memory devices, such as Static Random-Access Memory (SRAM), electrically erasable programmable Read-Only Memory (Electrically Erasable Programmable Read Only Memory, EEPROM), erasable programmable Read-Only Memory (Electrical Programmable Read Only Memory, EPROM), programmable Read-Only Memory (Programmable Read Only Memory, PROM), read Only Memory (ROM), magnetic Memory, flash Memory, magnetic or optical disk.

In the embodiments of the present application, the processor may be any hardware processing device that may execute the above-described method logic. Alternatively, the processor may be a central processing unit (Central Processing Unit, CPU), a graphics processor (Graphics Processing Unit, GPU) or a micro control unit (Microcontroller Unit, MCU); programmable devices such as Field programmable gate arrays (Field-Programmable Gate Array, FPGA), programmable array logic devices (Programmable Array Logic, PAL), general array logic devices (General Array Logic, GAL), complex programmable logic devices (Complex Programmable Logic Device, CPLD), and the like; or an application specific integrated circuit (Application Specific Integrated Circuit, ASIC) chip; or an advanced reduced instruction set (Reduced Instruction Set Compute, RISC) processor (Advanced RISC Machines, ARM) or System on Chip (SoC), etc., but is not limited thereto.

In embodiments of the present application, the communication component is configured to facilitate wired or wireless communication between the device in which it resides and other devices. The device in which the communication component is located may access a wireless network based on a communication standard, such as wireless fidelity (Wireless Fidelity, wiFi), 2G or 3G,4G,5G or a combination thereof. In one exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component may also be implemented based on near field communication (Near Field Communication, NFC) technology, radio frequency identification (Radio Frequency Identification, RFID) technology, infrared data association (Infrared Data Association, irDA) technology, ultra Wide Band (UWB) technology, bluetooth (BT) technology, or other technologies.

In embodiments of the present application, the display assembly may include a liquid crystal display (Liquid Crystal Display, LCD) and a Touch Panel (TP). If the display assembly includes a touch panel, the display assembly 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, swipes, and gestures on the touch panel. The touch sensor may sense not only the boundary of a touch or sliding action, but also the duration and pressure associated with the touch or sliding operation.

In embodiments of the present application, the power supply assembly is configured to provide power to the various components of the device in which it is located. The power components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the devices in which the power components are located.

In embodiments of the present application, the audio component may be configured to output and/or input audio signals. For example, the audio component includes a Microphone (MIC) configured to receive external audio signals when the device in which the audio component is located is in an operational mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal may be further stored in a memory or transmitted via a communication component. In some embodiments, the audio assembly further comprises a speaker for outputting audio signals. For example, for a device with language interaction functionality, voice interaction with a user, etc., may be accomplished through an audio component.

It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or fully authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and provide corresponding operation entries for the user to select authorization or rejection.

It should be further noted that, the descriptions of "first" and "second" herein are used to distinguish between different messages, devices, modules, etc., and do not represent a sequence, nor do they limit that "first" and "second" are different types.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, magnetic disk storage, CD-ROM (Compact Disc Read-Only Memory), optical storage, etc.) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (or systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

In a typical configuration, a computing device includes one or more processors (e.g., CPUs, etc.), input/output interfaces, network interfaces, and memory.

The Memory may include volatile Memory, random-Access Memory (RAM), and/or nonvolatile Memory in a computer-readable medium, such as Read Only Memory (ROM) or Flash Memory (Flash RAM). Memory is an example of computer-readable media.

The storage medium of the computer is a readable storage medium, which may also be referred to as a readable medium. Readable storage media, including both permanent and non-permanent, removable and non-removable media, may be implemented in any method or technology for information storage. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase-Change Memory (PRAM), static Random-Access Memory (SRAM), dynamic Random-Access Memory (Dynamic Random Access Memory, DRAM)), other types of Random-Access Memory (RAM), read-only Memory (ROM), electrically erasable programmable read-only Memory (Electrically Erasable Programmable Read Only Memory, EEPROM), flash Memory or other Memory technology, read-only compact disc read-only Memory (CD-ROM), digital versatile discs (Digital Video Disc, DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by the computing device. Computer-readable Media, as defined herein, does not include Transitory computer-readable Media (transmission Media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The foregoing is merely exemplary of the present application and is not intended to limit the present application. Various modifications and changes may be made to the present application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. which are within the spirit and principles of the present application are intended to be included within the scope of the claims of the present application.

Claims

1. A method of protecting a private key, comprising:

2. The method of claim 1, wherein the obtaining, by the TEE, the user's data key and the ciphertext of the data key from a key management service KMS, comprises:

invoking the KMS by using the TEE to enable the KMS to generate a data key of the user based on a master key of the target user, and performing encryption processing on the data key to obtain ciphertext of the data key;

and receiving the data key returned by the KMS and the ciphertext of the data key by using the TEE.

3. The method of claim 1, wherein the obtaining, with the trusted execution environment TEE, the public-private key pair to be protected comprises:

acquiring a key application request provided by the client by using the TEE; generating a public-private key pair for the target user by using the TEE in response to the key application request, wherein the public-private key pair is used as the public-private key pair to be protected;

Or alternatively, the process may be performed,

and receiving the public and private key pair provided by the client by using the TEE as the public and private key pair to be protected.

4. The method as recited in claim 1, further comprising:

acquiring a decryption request initiated by the client by using the TEE; the decryption request comprises 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 encrypting the random number by using the public key in the public-private key pair by the server in response to the access request of the client;

the TEE is used for calling the KMS to decrypt ciphertext of the data key so as to obtain the data key;

and returning the plaintext of the random number to the client so that the client requests the server to check the access authority of the client based on the plaintext of the random number.

5. The server access method is characterized by comprising the following steps:

Acquiring a decryption request initiated by a client by using a Trusted Execution Environment (TEE); the decryption request comprises a ciphertext of a random number, a ciphertext of a data key and a ciphertext of a private key in a public-private key pair; the ciphertext of the random number is obtained by encrypting the random number by using the public key in the public-private key pair by the server in response to the access request of the client; the client stores the ciphertext of the data key and the ciphertext of the private key;

6. A method of protecting a private key, comprising:

7. The method according to claim 6, comprising:

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

receiving ciphertext of the random number returned by the server;

initiating a decryption request to the TEE, wherein the decryption request comprises a random number ciphertext, a data key ciphertext and a private key ciphertext, so that the TEE calls the KMS to decrypt the data key ciphertext to obtain the data key, and decrypts the private key ciphertext by using the data key to obtain the private key; decrypting ciphertext of the random number by utilizing the private key to obtain plaintext of the random number;

receiving a plaintext of the random number returned by the TEE;

and accessing the server based on the plaintext of the random number.

8. The server access method is characterized by comprising the following steps:

receiving ciphertext of the random number returned by the server;

initiating a decryption request to a Trusted Execution Environment (TEE), wherein the decryption request comprises a random number ciphertext, a data key ciphertext and a private key ciphertext, so that the TEE calls a KMS to decrypt the data key ciphertext to obtain the data key, and decrypts the private key ciphertext by using the data key to obtain the private key; decrypting ciphertext of the random number by utilizing the private key to obtain plaintext of the random number;

receiving a plaintext of the random number returned by the TEE;

and accessing the server based on the plaintext of the random number.

9. A communication system, comprising: the system 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 for providing key management service;

Said first service node being adapted to perform the steps of the method of any of claims 1-5;

the client being adapted to perform the steps of the method of any of claims 6-8.

10. A computing device, comprising: a memory and a processor; wherein the memory is used for storing a computer program;

the processor is coupled to the memory for executing the computer program for performing the steps of the method performed by the first serving node and/or the client as claimed in claim 9.

11. A computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps in the method performed by the first serving node and/or the client of claim 9.