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

Abstract

Embodiments of the present application provide a private key protection and server access method, system, device and storage medium. In the embodiments of the present application, TEE and KMS are introduced to protect the private key in the security protocol. Specifically, the TEE calls the KMS to obtain the data key of the user of the client and the ciphertext of the data key, and encrypts the private key in the TEE by 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 to the client, so that the encrypted storage of the private key is realized, and the risk of private key leakage 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 the confidential calculation, and the untrusted environment outside cannot access the private key, so that the security of the private key can be further improved.

Description

Technical Field

[0001] This 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 Technology

[0002] With the rapid development of privacy computing, this technology has been widely applied across various industries. A key technology in privacy computing is cryptography. The security of the private key determines the data security of various environments during the privacy computing process. Improving private key security and reducing the risk of private key leakage has become a pressing technical problem to be solved in this field. Summary of the Invention

[0003] This application provides a method, system, device, and storage medium for private key protection and server access, in order to reduce the risk of private key leakage and improve private key security.

[0004] In a first aspect, embodiments of this application provide a private key protection method, including:

[0005] Using a Trusted Execution Environment (TEE), obtain the public-private key pair of the target user that needs protection;

[0006] The target user's data key and its ciphertext are obtained from the Key Management Service (KMS) using the TEE.

[0007] 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;

[0008] 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.

[0009] Secondly, embodiments of this application also provide a server access method, including:

[0010] The decryption request initiated by the client is obtained using a Trusted Execution Environment (TEE); the decryption request includes the ciphertext of a 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 by encrypting the 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.

[0011] The TEE is used to call KMS to decrypt the ciphertext of the data key to obtain the data key;

[0012] In the TEE, the ciphertext of the private key is decrypted using the data key to obtain the private key;

[0013] The private key is used in the TEE to decrypt the ciphertext of the random number to obtain the plaintext of the random number;

[0014] The plaintext of the random number is returned to the client so that the client can access the server based on the plaintext of the random number.

[0015] Thirdly, embodiments of this application also provide a private key protection method, including:

[0016] The Trusted Execution Environment (TEE) is invoked to encrypt the private key in the public-private key pair of the target user, so that the TEE can call 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;

[0017] 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;

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

[0019] Fourthly, embodiments of this application also provide a server access method, including:

[0020] An access request is sent to the server, and the server responds to the access request by encrypting a random number using the public key of the public-private key pair of the target user corresponding to the client to obtain the ciphertext of the random number; the client stores the ciphertext of the private key of the public-private key pair and the ciphertext of the target user's data key;

[0021] Receive the ciphertext of the random number returned by the server;

[0022] A decryption request is initiated 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. The TEE calls the KMS to decrypt the ciphertext of the data key to obtain the data key, and uses the data key to decrypt the ciphertext of the private key to obtain the private key; and uses the private key to decrypt the ciphertext of the random number to obtain the plaintext of the random number.

[0023] Receive the plaintext of the random number returned by the TEE;

[0024] Access the server based on the plaintext of the random number.

[0025] Fifthly, embodiments of this application also provide 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 key management services.

[0026] The first service node is used to perform the steps in the methods provided in the first and / or second aspects described above;

[0027] The client is used to perform the steps in the methods provided in the third and / or fourth aspects described above.

[0028] Sixthly, embodiments of this application also provide a computing device, including: a memory and a processor; wherein the memory is used to store computer programs;

[0029] The processor is coupled to the memory for executing the computer program to perform the steps in the methods executed by the first service node and / or the client in the fifth aspect.

[0030] In a seventh aspect, embodiments of this application also provide a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the method executed by the first service node and / or the client in the fifth aspect described above.

[0031] In this embodiment, a Trusted Execution Environment (TEE) and a Key Management Service (KMS) are introduced to protect the private key in the security protocol. Specifically, the TEE calls the KMS to obtain the client's user data key and its ciphertext. The TEE then uses the data key to encrypt the private key, obtaining its ciphertext. Subsequently, the ciphertext of the private key and the ciphertext of the data key are stored on the client, achieving encrypted storage of the private key and reducing the risk of private key leakage. Furthermore, the encryption of the private key by the TEE ensures that the plaintext of the private key remains within the confidential computation TEE, preventing untrusted external environments from accessing the private key, thus further enhancing its security. Attached Figure Description

[0032] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0033] Figure 1 A diagram illustrating the traditional login process using public and private key pairs provided by the SSH protocol for authentication.

[0034] Figure 2 and Figure 3 A schematic diagram illustrating the process of private key protection for the communication system provided in this application embodiment;

[0035] Figure 4 A schematic diagram illustrating the process of trusted authentication of a TEE by a communication system provided in an embodiment of this application;

[0036] Figure 5 A schematic diagram illustrating the process of server access in the communication system provided in this application embodiment;

[0037] Figure 6 and Figure 7 A flowchart illustrating the private key protection method provided in this application embodiment;

[0038] Figure 8 and Figure 9 A schematic diagram illustrating the server access process provided in this application embodiment;

[0039] Figure 10 A schematic diagram of the structure of a computing device provided in an embodiment of this application. Detailed Implementation

[0040] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0041] Figure 1 This diagram illustrates the traditional login process using public and private key pairs provided by the Secure Shell (SSH) protocol. SSH is a protocol used for secure remote login and other secure network services over insecure networks. Figure 1 As shown, the communication system includes: client 10 and server 20.

[0042] In this context, Client 10 refers to a computer device used by a user that possesses the necessary computing, internet access, and communication functions. This could be a smartphone, tablet, personal computer, wearable device, etc. Of course, Client 10 can also be a server device. For example, it could be a single server device, a cloud-based server array, or a virtual machine (VM) running within a cloud-based server array. Alternatively, it can refer to other computing devices with corresponding service capabilities, such as computers or other terminal devices (running service programs).

[0043] Server 20 refers to the server-side device that responds to the request from client 10 and provides services to the user. It generally possesses the capability to undertake and guarantee the service. Server 20 can be a single server device, a cloud-based server array, or a virtual machine (VM) running within a cloud-based server array. Alternatively, server 20 can also refer to other computing devices with corresponding service capabilities, such as computers or other terminal devices (running service programs). In this embodiment, the specific implementation form of the service provided by server 20 is not limited. Optionally, the service provided by server 20 can be a live streaming service, online shopping service, instant messaging service, email service, video service, audio service, or other services, etc.

[0044] In this embodiment, when client 10 accesses server 20, server 20 can verify the access permissions of the target user of client 10. Client 10's access to server 20 can be for logging into server 20 or accessing services provided by server 20.

[0045] In some embodiments, access permission verification can be performed using the public-private key pairing mechanism provided by the SSH protocol. Specifically, such as Figure 1 As shown, client 10 can generate a public-private key pair and store it in a specified directory (corresponding to...). Figure 1 Step 1, "Generate and store a public / private key pair." This is typically done in the " / .ssh" directory. Further, client 10 can register the public key from the public / private key pair with server 20 (corresponding to...). Figure 1 Step 2).

[0046] When client 10 accesses server 20, it can send an access request to server 20 (corresponding to...). Figure 1 Step 3). This access request can also be called an SSH connection request. Server 20 can respond to this access request by generating a random number; and encrypting the random number using the public key from the public-private key pair to obtain the ciphertext of the random number (corresponding to...). Figure 1 Step 4, "Public key encryption of random number"; afterwards, the ciphertext of the random number can be returned to client 10 (corresponding to...). Figure 1 Step 5).

[0047] Client 10 receives the ciphertext of the random number and reads the private key from the public-private key pair in the " / .ssh" directory to decrypt the random number, thus obtaining the plaintext of the random number (corresponding to...). Figure 1 Step 6, "Decrypt the ciphertext of the random number with the private key"; afterwards, client 10 can send the plaintext of the random number to server 20 (corresponding to...). Figure 1Step 7). The server 20 can compare the received random number with its own stored random number to verify the access rights of the client 10 (corresponding to...). Figure 1 Step 8) obtains the access permission verification result. This access permission verification result indicates whether the client has access permission or not. Further, the server 20 can send the access permission verification result to the client 10 (9 corresponds to...). Figure 1 (Step 9) If the random number received by server 20 is the same as the random number it stores, it determines that client 10 has access rights, and then establishes an SSH connection with client 10, allowing client 10 to access server 20. If the random number received by server 20 is different from the random number it stores, server 20 returns a message to client 10 indicating that access is denied, etc.

[0048] Based on the above process of accessing the server using the SSH protocol, it is known that the private key in the public-private key pair is stored in plaintext in the client's " / .ssh" directory. Although the " / .ssh" directory is hidden, those skilled in the art generally know 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, they can remotely control access to the client or even the server, or perform other attacks.

[0049] To address the aforementioned technical issues, in some embodiments of this application, a Trusted Execution Environment (TEE) and a Key Management Service (KMS) are introduced to protect the private key in the security protocol. Specifically, the TEE calls the KMS to obtain the client's user data key and its ciphertext. The TEE then uses the data key to encrypt the private key, obtaining its ciphertext. Subsequently, the ciphertext of the private key and the ciphertext of the data key are stored on the client, achieving encrypted storage of the private key and reducing the risk of private key leakage. Furthermore, the encryption of the private key by the TEE ensures that the plaintext of the private key remains within the confidential computation TEE, preventing untrusted external environments from accessing the private key, thus further enhancing its security.

[0050] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0051] It should be noted that the same reference numerals denote the same object in the following figures and embodiments. Therefore, once an object is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0052] Figures 2-5 This is a schematic diagram of the communication system provided in an embodiment of this application. (In conjunction with...) Figures 2-5 The communication system includes: client 10, first service node 30 and second service node 40.

[0053] For details on the implementation of client 10, please refer to [link / reference]. Figure 1 The relevant details will not be elaborated here. The first service node 30 runs a Trusted Execution Environment (TEE). In confidential computing, the computing entity running on the TEE is called an Enclave. Computations and memory operations performed within the Enclave are invisible to user applications and the operating system kernel.

[0054] Enclave provides a trusted, isolated space where software can be encapsulated, ensuring the confidentiality and integrity of software code and data, and protecting them from malware attacks.

[0055] The first service node 30 can create enclaves based on Software Guard Extensions (SGX) technology, serving as a Trusted Execution Environment (TEE). It can also allocate a portion of its memory as an enclave page cache (EPC) to house these enclaves. The central processing unit (CPU) of the first service node 30 can simultaneously create one or more enclaves. The code running on different enclaves can be the same or different, depending on the purpose of each enclave. The CPU can allocate computing resources to create enclaves as trusted execution environments. Computing resources may include virtual CPUs (vCPUs) and memory. The vCPUs and memory allocated to the enclaves are isolated from other CPUs and memory on the host machine of the first service node 30.

[0056] 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, serving as a functional module providing TEE on the client 10, etc.

[0057] In this embodiment, the second service node 40 can provide a Key Management Service (KMS). The KMS provides 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.

[0058] To enhance key security, KMS provides a Customer Master Key (CMK). Each user has a unique CMK. This user is typically the same user as client 10. The CMK is a key created by the user or cloud service through key management, primarily used to encrypt and protect data keys (DKs). One customer master key can encrypt multiple data keys. One CMK can derive multiple DKs. Different applications of a user can use different DKs for data encryption, so even if one DK is lost, it will not affect the use of other applications. However, if the same CMK is used to encrypt all application data of a user, the loss of the CMK will compromise the security of all application data.

[0059] Based on the above Figure 1 The illustration depicts a scenario where client 10 and server 20 communicate based on a security protocol. Client 10 can access server 20 based on the security protocol. Client 10 can be a client of the security protocol, and server 20 can be a server of the security protocol. Specifically, client 10 can access server 20 using the public-private key pair mechanism provided by the security protocol. A security protocol is a message exchange protocol based on cryptography, whose purpose is to provide various security services in a network environment. The security protocol can be SSH, Telnet, or Secure Socket Layer (SSL), but is not limited to these. For the process of client 10 accessing server 20 using the public-private key pair mechanism provided by the security protocol, please refer to the above. Figure 1 The relevant content will not be repeated here.

[0060] In this embodiment, to improve private key security, TEE and KMS are introduced to protect the private key in the public-private key pair of the security protocol. Specifically, combined with Figure 2 and Figure 3 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...). Figure 2 Step 1 and Figure 3 Step 1). The target user is the user of client 10.

[0061] It is worth noting that before using the TEE running on the first service node 30, client 10 needs to ensure that the TEE is trustworthy. This requires trustworthy authentication of the TEE. Remote Attestation (RA) can be used for trustworthy authentication of the Enclave. RA refers to a technique where a computing system (Prover) proves its software and / or hardware configuration and state to a remote system (Verifier). A remote attestation system typically consists of two parts: the Prover and the Verifier. The Prover has an Integrity Measurement mechanism, which, according to the Remote Attestation Protocol (RAP) between the Prover and Verifier, reports its own system's measurement value to the Verifier so that the Verifier can verify the Prover's system integrity.

[0062] In this embodiment, client 10 can act as a validator, also known as a challenger. The TEE in the first service node 30 acts as a prover. RA service node 50 refers to a device, module, or virtual instance that provides remote proof services. A virtual instance can be a virtual machine, a container group (such as a Pod), or a container. The remote proof service provided by RA service node 50 can be a SaaS product. The following describes the process in conjunction with... Figure 4 An exemplary illustration is provided of the remote verification process for TEE.

[0063] Before using the TEE provided by the first service node 30, client 10 needs to verify the trustworthiness of the TEE. If the TEE is verified to be a trusted executable environment, client 10 can call the TEE to encrypt the private key in the public-private key pair of the target user.

[0064] like Figure 4 As shown, client 10 can use remote certification (RA) technology to verify the trustworthiness of the TEE. Specifically, client 10 can initiate a remote certification (RA) request to the TEE in the first service node 30 (corresponding to...). Figure 4 Step 1). 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 a remote proof report (corresponding to...) Figure 4 Step 2). The first service node 30 can provide the TEE's identity key and remote proof report (Report) to the RA service node 50 (corresponding to...). Figure 4 Step 3).

[0065] RA service node 50 can verify the legitimacy of the TEE's identity key based on the remote proof report; and if the verification result indicates that the TEE is legitimate, it will issue an identity authentication certificate for the TEE. Furthermore, RA service node 50 can obtain the TEE's quotation information and encrypt it using its local public key to obtain encrypted quotation information (corresponding to...). Figure 4 Step 4). Citation information may include: Enclave's authentication certificate, measurement logs, and signature values, etc. Measurement logs may include: TEE's running status, Security Version Number (SVN), hardware signature information (such as PCK cert), and Trusted Computing Base (TCB) information, etc.

[0066] Furthermore, RA service node 50 can send encrypted citation information to client 10 (corresponding to...). Figure 4 Step 5). Client 10 can call RA service node 50 to remotely verify the encrypted citation information (corresponding to...). Figure 4 Step 6).

[0067] Specifically, client 10 can provide encrypted citation information to RA service node 50. RA service node 50 can decrypt the encrypted citation information using its local private key to obtain the citation information of the TEE. Furthermore, the trustworthiness of the TEE can be verified based on the citation information of the TEE (corresponding to...). Figure 4 Step 7), and return the verification result (corresponding to) to client 10. Figure 4 Step 8). The verification result is used to indicate whether the TEE is trustworthy, that is, whether the verification result is that the TEE is trustworthy or untrustworthy.

[0068] The above embodiments exemplify the trustworthiness verification process of a TEE, but are not intended to limit it. Figure 2 As shown, if the client 10 confirms that the TEE is trustworthy, it can call the TEE to encrypt the private key in the public-private key pair of the target user (corresponding to...). Figure 2 Step 1 and Figure 3 Step 1). The target user is the user of client 10.

[0069] Accordingly, the first service node 30 can use the TEE to obtain the target user's public and private key pair to be protected (corresponding to...). Figure 2 Step 2 and Figure 3 Step 2). This public-private key pair can be generated by the first service node 30 for the target user in the TEE, or it can be a public-private key pair imported into the TEE by the client 10.

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

[0071] 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...). Figure 3 Step 1, "Import Public / Private Key Pair"). Accordingly, the TEE can receive the public / private key pair provided by client 10 as the public / private key pair to be protected (corresponding to...). Figure 3 In step 2, "obtain the imported public / private key pair".

[0072] After obtaining the target user's public and private key pair to be protected, TEE can retrieve the target user's data key and its ciphertext (corresponding to) from KMS. Figure 2 Step 3 and Figure 3 Steps 3-5).

[0073] Specifically, the TEE can initiate a key request to the KMS (corresponding to...). Figure 3 Step 3, "Request DK". This key request may include the target user's identifier. Accordingly, the KMS receives the key request and, based on the target user's identifier carried in the request, obtains the target user's master key, i.e., the target user's DMK. The target user's DMK is pre-created by the KMS for the target user, meaning the target user has already requested KMS. Further, the KMS can generate the target user's data key (corresponding to...) based on the target user's DMK. Figure 2 Steps 3 and 4, “Deriving DK from CMK”. Optionally, KMS can use a key derivation function to derive at least one data key (DK) based on the target user’s DMK.

[0074] Furthermore, KMS can encrypt the data key to obtain the ciphertext of the data key (corresponding to...). Figure 3Step 4, "Generate the ciphertext of DK". In this embodiment, the key used to encrypt the data key is not limited. In some embodiments, the target user's DMK can be used as the key to encrypt the data key, obtaining the ciphertext of the data key. In other embodiments, KMS can use a key derivation function to derive multiple data keys (such as two data keys, DK1 and DK2) based on the target user's DMK. One of the multiple data keys (such as DK1) can be used as the target user's data key; the other (such as DK2) can be used as the data key to encrypt the target user's data key. Accordingly, the target user's data key DK1 can be encrypted using data key DK2 to obtain the ciphertext of the target user's data key DK1.

[0075] Furthermore, KMS can return the target user's data key and its ciphertext to the TEE (corresponding to...). Figure 2 Step 3 and Figure 3 Step 5). The 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...). Figure 2 Step 4 and Figure 3 Step 6); furthermore, 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 client 10 (corresponding to...). Figure 2 Step 5 and Figure 3 Step 7).

[0076] Client 10 can receive the ciphertext of the private key, the ciphertext of 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 ciphertext of the public key in the public-private key pair, and the ciphertext of the data key (corresponding to...) Figure 2 Step 6 and Figure 3 Step 8). Optionally, for the SSH protocol, 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.

[0077] In this embodiment, a TEE and a KMS are introduced to protect the private key in the security protocol. Specifically, the TEE calls the KMS to obtain the client's user data key and its ciphertext. The private key is then encrypted within the TEE using the data key, resulting in its ciphertext. Subsequently, both the ciphertext of the private key and the ciphertext of the data key are stored on the client, achieving encrypted storage of the private key and reducing the risk of leakage. Furthermore, the encryption of the private key by the TEE ensures that the plaintext of the private key remains within the confidentially computed TEE, preventing untrusted external environments from accessing the private key and further enhancing its security.

[0078] Since the target user's data key is managed and controlled by KMS, the lifecycle of the private key in the public-private key pair can be managed through KMS's management of the data key's lifecycle, maintaining a consistent key management method with KMS. For example, the private key can be revoked by revoking the data key through KMS. Since the private key's ciphertext is encrypted using the data key as the decryption key, the ciphertext of the private key naturally becomes invalid after the data key is revoked, as there is no decryption key. Another example is that private key rotation can be achieved through KMS's data key rotation system.

[0079] Key rotation refers to the requirement in high-security scenarios that the encrypted data key must be changed periodically, preventing the use of the same key for data encryption over extended periods. This method of periodically changing the key is called key rotation. Specifically, KMS can be used to rotate and update the data key; the updated key pair is then sent to TEE, where the TEE encrypts the private key in the public-private key pair to obtain the updated ciphertext, thus achieving private key rotation.

[0080] In this embodiment of the application, the client 10 can also register the public key of the public-private key pair with the server 20 (corresponding to...). Figure 2 Step 7 and Figure 3 Step 9). Based on the private key protection method provided in the above embodiments, this application also provides a corresponding server access method. The server access process provided in this application embodiment will be described by way of example below.

[0081] like Figure 5 As shown, when client 10 accesses server 20, it can initiate an access request to server 20 (corresponding to...). Figure 5 Step 1). The server 20 receives the access request and generates a random number in response. It then encrypts the random number using the public key from the target user's public-private key pair to obtain the ciphertext of the random number (corresponding to...). Figure 5 Step 2, "Public key encryption of random number". Afterwards, server 20 can return the ciphertext of the random number to client 10 (corresponding to...). Figure 5 Step 3).

[0082] Client 10 receives the ciphertext of the random number and sends a decryption request to the TEE in the first service node 30 (corresponding to...). Figure 5 Step 4). Specifically, 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 target user's public-private key pair. This decryption request includes the ciphertext of the random number, the ciphertext of the data key, and the ciphertext of the private key in the target user's public-private key pair.

[0083] Optionally, client 10 can invoke the TEE via the `ecall` method to request the TEE to decrypt the ciphertext of the random number. The `ecall` method is a method provided by the TEE (such as the Enclave) that can be invoked by external programs (i.e., untrusted environments) of the TEE. In other words, the `ecall` method is the only channel for external access to the TEE's internal workings, but its execution is protected by a trusted environment. Alternatively, client 10 can invoke the TEE via the Application Programming Interface (API) to request the TEE to decrypt the ciphertext of the random number, etc.

[0084] Accordingly, the TEE receives the decryption request and calls KMS to decrypt the ciphertext of the data key to obtain the target user's data key (corresponding to...). Figure 5 Steps 5-7).

[0085] Specifically, the TEE can invoke KMS and send the encrypted data key and the target user's identifier (corresponding to...) to KMS. Figure 5 Step 5). KMS can decrypt the ciphertext of the data key to obtain the target user's data key (corresponding to...). Figure 5 Step 6). Specifically, in the embodiment where the KMS encrypts the target user's data key using the target user's master key (DMK), the KMS can obtain the target user's master key (DMK) based on the target user's identifier, and use the DMK to decrypt the ciphertext of the target user's data key to obtain the target user's data key. Similarly, in the embodiment where the KMS decrypts the ciphertext of the target user's data key DK1 using another data key DK2 derived from the target user's DMK, to obtain the target user's data key DK1.

[0086] Furthermore, KMS can return the target user's data key to the TEE (corresponding to...). Figure 5 Step 7). The TEE receives the data key and uses the target user's data key to decrypt the ciphertext of the private key to obtain the plaintext of the private key (corresponding to...). Figure 5 Step 8). Further, the TEE can use its private key to decrypt the ciphertext of the random number to obtain the plaintext of the random number (corresponding to...). Figure 5 Step 9).

[0087] Furthermore, the TEE can return the plaintext of the time count to the client (corresponding to 10). Figure 5 Step 10). Client 10 can access server 20 in plaintext based on a random number.

[0088] Specifically, client 10 can send the plaintext of the random number to server 20 (corresponding to...). Figure 5Step 11). The server 20 can verify the access rights of the client 10 based on the random number received from the client and the random number it generates itself (corresponding to...). Figure 5 Step 12), and return the permission verification result to client 10 (corresponding to Figure 5 Step 13). If the random number received by server 20 from the client matches the random number it generated, it means that client 10 possesses the private key corresponding to the public key, i.e., client 10 has access permission. Therefore, client 10 is granted access to server 20. Conversely, if the random number received by server 20 from the client does not match the random number it generated, it means that client 10 does not possess the private key corresponding to the public key. Therefore, client 10 is denied access to server 20. Alternatively, a message indicating no access permission may be returned to client 10.

[0089] In this embodiment, during the access permission verification process for clients accessing the server based on the public-private key pair mechanism, the private key in the security protocol's public-private key pair is kept in a Trusted Execution Environment (TEE) for confidential computing, and cannot be accessed by untrusted external environments. Even if the user's client, such as a virtual machine, is compromised, the private key can be guaranteed not to be lost, reducing the risk of private key leakage. On the other hand, storing and transmitting the private key in encrypted form reduces the risk of plaintext exposure of the private key.

[0090] Furthermore, the aforementioned client-server interaction process is compatible with existing security protocol processes (such as the SSH protocol process), requiring no modifications to the server-side security protocol (such as SSH). The client-side can simply add a TEE (Technical Application Programming Interface) call interface, such as an API, to enable calls to the TEE, thereby facilitating the interaction between the client and server. This lightweight modification maintains good compatibility and enhances the universality and versatility of the solution provided in this embodiment.

[0091] In addition to the system embodiments described above, this application also provides a private key access method and a server access method. The private key access method and server access method provided in this application are described below from the perspectives of the client and the first service node running the TEE, respectively.

[0092] Figure 6 This is a flowchart illustrating a private key access method provided in an embodiment of this application. This method is applicable to service nodes running a TEE (Service Execution Environment). Figure 6 As shown, the method mainly includes:

[0093] 601. Use TEE to obtain the public and private key pair of the target user to be protected.

[0094] 602. Use TEE to obtain the target user's data key and its ciphertext from KMS.

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

[0096] 604. Use TEE to return the ciphertext of the private key, the ciphertext of 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 ciphertext of the public key in the public-private key pair, and the ciphertext of the data key.

[0097] Figure 7 This is a flowchart illustrating another private key access method provided in an embodiment of this application. This method is applicable to clients using security protocols. Figure 7 As shown, the method mainly includes:

[0098] 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 target user's data key 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.

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

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

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

[0102] In this embodiment, to improve private key security, TEE and KMS are introduced to protect the private key in the public-private key pair of the security protocol. Specifically, for the client, such as... Figure 7 As shown in step 701, the TEE can be invoked to encrypt the private key in the public-private key pair of the target user. Here, the target user is the client user.

[0103] It is worth noting that before using a TEE, the client needs to ensure that the TEE is trusted. This requires trusted authentication of the TEE. For specific implementation details on trusted authentication of TEEs, please refer to the above. Figure 4 The relevant content will not be repeated here.

[0104] If the client confirms that the TEE is trustworthy, in step 701, the client can invoke the TEE to encrypt the private key in the public-private key pair of the target user. The target user is the user of client 10.

[0105] Accordingly, for service nodes running a TEE, in step 601, the public-private key pair to be protected for the target user can be obtained using the TEE. This public-private key pair can be generated for the target user in the TEE, or it can be a public-private key pair imported into the TEE by the client.

[0106] In some embodiments, a client may initiate a key request to the TEE. A service node running a TEE may use the TEE to receive the key request and use the TEE to generate a public-private key pair for the target user in response to the key request, which will serve as the public-private key pair to be protected.

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

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

[0109] Specifically, the TEE can initiate a key request to the KMS. This key request may include the identifier of the target user. Accordingly, the KMS receives the key request and, based on the target user's identifier carried in the key request, obtains the target user's master key, i.e., the target user's DMK. The target user's DMK is pre-created by the KMS for the target user, meaning the target user has already requested KMS. Further, the KMS can generate the target user's data key based on the target user's DMK. Optionally, the KMS can use a key derivation function to derive at least one data key based on the target user's DMK. Further, the KMS can encrypt the data key to obtain its ciphertext.

[0110] Furthermore, KMS can return the target user's data key and its ciphertext to the TEE. Correspondingly, the TEE can receive the target user's data key and its ciphertext. Further, in step 602, the 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; further, in step 603, the TEE can use the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key to return to the client.

[0111] In step 702, the client can receive the ciphertext of the private key, the public key of the public-private key pair, and the ciphertext of the data key; and in step 703, it stores the ciphertext of the private key, the public key of the public-private key pair, and the ciphertext of the data key (corresponding to...). Figure 2 Step 6 and Figure 3 Step 8). 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 in the .ssh directory.

[0112] In this embodiment, a TEE and a KMS are introduced to protect the private key in the security protocol. Specifically, the TEE calls the KMS to obtain the client's user data key and its ciphertext. The private key is then encrypted within the TEE using the data key, resulting in its ciphertext. Subsequently, both the ciphertext of the private key and the ciphertext of the data key are stored on the client, achieving encrypted storage of the private key and reducing the risk of leakage. Furthermore, the encryption of the private key by the TEE ensures that the plaintext of the private key remains within the confidentially computed TEE, preventing untrusted external environments from accessing the private key and further enhancing its security.

[0113] Since the target user's data key is managed and controlled by KMS, the lifecycle of the private key in the public-private key pair can be managed through KMS's management of the data key's lifecycle, maintaining a consistent key management method with KMS. For example, the private key can be revoked by revoking the data key through KMS. Since the private key's ciphertext is encrypted using the data key as the decryption key, the ciphertext of the private key naturally becomes invalid after the data key is revoked, as there is no decryption key. Another example is that private key rotation can be achieved through KMS's data key rotation system.

[0114] Specifically, the data key can be rotated and updated via KMS; the updated data key pair is then sent to TEE, where TEE encrypts the private key in the public-private key pair to obtain the updated ciphertext of the private key, thus realizing the private key rotation.

[0115] In this embodiment, the client can also register the public key of the public-private key pair with the server. Based on the private key protection method provided in the above embodiments, this embodiment also provides a corresponding server access method. The server access process provided in this embodiment is described below by way of example.

[0116] Figure 8 This is a flowchart illustrating a server access method provided in an embodiment of this application. This method is applicable to clients using security protocols. Figure 8 As shown, the method mainly includes:

[0117] 801. Send an access request to the server so that the server can respond to the access request by encrypting the random number using the public key in the public-private key pair of the target user corresponding to the client 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 target user's data key.

[0118] 802. Receive the encrypted random number returned by the server.

[0119] 803. Send 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. The TEE calls KMS to decrypt the ciphertext of the data key to obtain the data key, and uses the data key to decrypt the ciphertext of the private key to obtain the private key; and uses the private key to decrypt the ciphertext of the random number to obtain the plaintext of the random number.

[0120] 804. Receive the plaintext of the random number returned by the TEE.

[0121] 805. Access the server based on plaintext with a random number.

[0122] Figure 9 This is a flowchart illustrating another server-side access method provided in an embodiment of this application. This method is applicable to service nodes running a TEE. For example... Figure 9 As shown, the method mainly includes:

[0123] 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 and encrypting the 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.

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

[0125] 903. In the TEE, use the data key to decrypt the ciphertext of the private key to obtain the private key.

[0126] 904. Use the private key in the TEE to decrypt the ciphertext of the random number to obtain the plaintext of the random number.

[0127] 905. Use TEE to return the plaintext of the random number to the client, so that the client can access the server based on the plaintext of the random number.

[0128] 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, and encrypts the random number using the public key from the target user's public-private key pair to obtain the ciphertext of the random number. The server can then return the ciphertext of the random number to the client.

[0129] For the client, in step 802, it can receive the ciphertext of the random number returned by the server; and in step 803, it initiates a decryption request 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 target user's public-private key pair. This decryption request includes the ciphertext of the random number, the ciphertext of the data key, and the ciphertext of the private key in the target user's public-private key pair.

[0130] Optionally, the client can invoke the TEE via the `ecall` method to request the TEE to decrypt the ciphertext of the random number. Alternatively, the client can invoke the TEE via the API to request the TEE to decrypt the ciphertext of the random number, etc.

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

[0132] Specifically, the TEE can invoke the KMS and send the ciphertext of the data key and the target user's identifier to the KMS. The KMS can decrypt the ciphertext of the data key to obtain the target user's data key. Specifically, in the embodiment where the KMS encrypts the target user's data key using the target user's master key (DMK), the KMS can obtain the target user's master key (DMK) based on the target user's identifier and use this DMK to decrypt the ciphertext of the target user's data key to obtain the target user's data key. Alternatively, in the embodiment where the KMS decrypts the ciphertext of the target user's data key DK1 using another data key DK2 derived from the target user's DMK to obtain the target user's data key DK1.

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

[0134] Furthermore, in step 905, the plaintext of the random number is returned to the client using the TEE. Correspondingly, in step 804, the client can receive the plaintext of the random number returned by the TEE; and in step 805, the client accesses the server 20 based on the plaintext of the random number.

[0135] Specifically, a random number can be sent in plaintext to the server. The server can verify the client's access rights by comparing the received random number with its own generated random number and return the verification result to the client. If the random number received by the client matches the server's generated random number, it means the client possesses the private key corresponding to the public key, i.e., the client has access rights, and the client is allowed to access the server. Conversely, if the random number received by the client does not match the server's generated random number, it means the client does not possess the private key corresponding to the public key, i.e., the client does not have access rights, and the client is prevented from accessing the server. Alternatively, the server can also return an access restriction message to the client.

[0136] In this embodiment, during the access permission verification process for clients accessing the server based on the public-private key pair mechanism, the private key in the security protocol's public-private key pair is kept in a Trusted Execution Environment (TEE) for confidential computing, and cannot be accessed by untrusted external environments. Even if the user's client, such as a virtual machine, is compromised, the private key can be guaranteed not to be lost, reducing the risk of private key leakage. On the other hand, storing and transmitting the private key in encrypted form reduces the risk of plaintext exposure of the private key.

[0137] Furthermore, the aforementioned client-server interaction process is compatible with existing security protocol processes (such as the SSH protocol process), requiring no modifications to the server-side security protocol (such as SSH). The client-side can simply add a TEE call interface, such as an API, to enable calls to the TEE, thus facilitating the interaction between the client and server. This lightweight modification maintains good compatibility and enhances the universality and versatility of the solution provided in this embodiment.

[0138] It should be noted that the execution subject of each step of the method provided in the above embodiments 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; or the execution subject of step 701 can be device A, and the execution subject of step 702 can be device B; and so on.

[0139] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 701, 702, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0140] Accordingly, embodiments of this application also provide a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause one or more processors to perform the steps in the aforementioned private key protection method and / or each server access method.

[0141] Figure 10 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application. Figure 10 As shown, the computing device may include a memory 100a and a processor 100b. The memory 100a is used to store computer programs.

[0142] In some embodiments, the computing device operates a Trusted Execution Environment (TEE) and can be implemented as a service node running the TEE. Accordingly, the processor 100b is coupled to the memory 100a for executing a computer program to: obtain a target user's public-private key pair to be protected using the TEE; obtain the target user's data key and its ciphertext from a Key Management Service (KMS) using the TEE; encrypt the private key in the public-private key pair using the data key in the TEE to obtain the ciphertext of the private key; and 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 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.

[0143] Optionally, when the processor 100b obtains the user's data key and the ciphertext of the data key from the Key Management Service (KMS) using the TEE, it specifically performs the following: calls the KMS using the TEE so that the KMS can generate the user's data key based on the target user's master key and encrypt the data key to obtain the ciphertext of the data key; and receives the data key and the ciphertext of the data key returned by the KMS using the TEE.

[0144] Optionally, when the processor 100b obtains the public-private key pair to be protected using the Trusted Execution Environment (TEE), it is specifically used to: obtain a key request request provided by the client using the TEE; generate a public-private key pair for the target user in response to the key request request using the TEE, as the public-private key pair to be protected; or, receive a public-private key pair provided by the client using the TEE, as the public-private key pair to be protected.

[0145] In some embodiments, the processor 100b is further configured to: acquire a decryption request initiated by the client using the TEE; the decryption request includes ciphertext of a random number, ciphertext of a data key, and ciphertext of a private key; the ciphertext of the random number is obtained by encrypting the random number using the public key in the public-private key pair in response to the client's access request; decrypt the ciphertext of the data key using the TEE to obtain the data key; decrypt the ciphertext of the private key using the data key in the TEE to obtain the private key; decrypt the ciphertext of the random number using the private key in the TEE to obtain the plaintext of the random number; and return the plaintext of the random number to the client so that the client can request the server to perform access permission verification based on the plaintext of the random number.

[0146] In some embodiments of this application, the computing device may also be implemented as a client of a security protocol. Accordingly, the processor 100b is configured to: invoke a Trusted Execution Environment (TEE) to encrypt the private key in the public-private key pair of the target user, so that the TEE can invoke KMS to obtain the target user's data key and 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; and store the ciphertext of the private key, the public key in the public-private key pair, and the ciphertext of the data key.

[0147] In some embodiments, the processor 100b is further configured to: initiate an access request to the server via the communication component 100c, so that the server responds to the access request by encrypting the random number using the public key to obtain the ciphertext of the random number; receive the ciphertext of the random number returned by the server via the communication component 100c; and 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 KMS to decrypt the ciphertext of the data key to obtain the data key, and uses 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; and then, access the server based on the plaintext of the random number.

[0148] In some alternative implementations, such as Figure 10 As shown, 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 also include components such as a display component 100e and an audio component 100f. Figure 10 The diagram only shows some components and does not mean that the computing device must contain them. Figure 10 The inclusion of all components does not imply that a computing device can only include... Figure 10 The components shown.

[0149] The computing device provided in this embodiment introduces a TEE (Transfer Execution Environment) and a KMS (Knowledge Management System) to protect the private key in the security protocol. Specifically, the TEE calls the KMS to obtain the user's data key and its ciphertext within the client. The private key is then encrypted using the data key within the TEE to obtain its ciphertext. Subsequently, the ciphertext of the private key and the ciphertext of the data key are stored on the client, achieving encrypted storage of the private key and reducing the risk of private key leakage. Furthermore, the encryption of the private key by the TEE ensures that the plaintext of the private key remains within the confidential computing TEE, preventing untrusted external environments from accessing the private key and further enhancing its security.

[0150] In this embodiment, the memory is used to store computer programs and can be configured to store various other data to support operation on its host device. The processor can execute the computer programs stored in the memory to implement 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), Electrically Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0151] In the embodiments of this application, the processor can be any hardware processing device capable of executing the above-described method logic. 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 programmable device such as a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), or a complex programmable logic device (CPLD); or an application-specific integrated circuit (ASIC) chip; or an advanced RISC machine (ARM) or system-on-chip (SoC), etc., but is not limited thereto.

[0152] In this embodiment, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device housing the communication component can access wireless networks based on communication standards, such as Wireless Fidelity (WiFi), 2G or 3G, 4G, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In another exemplary embodiment, the communication component may also be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), or other technologies.

[0153] In embodiments of this 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 can be implemented as a touchscreen 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 sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0154] In this embodiment, a power supply component is configured to provide power to various components of the device in which it resides. 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 resides.

[0155] In embodiments of this application, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), which is configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. For example, in devices with voice interaction capabilities, voice interaction with the user can be achieved through the audio component.

[0156] 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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0157] It should also be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0158] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can 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.

[0159] This 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 this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can 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, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0160] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0161] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0163] Memory may include non-persistent storage in computer-readable media, such as random-access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0164] Computer storage media are readable storage media, also known as removable media. Removable and non-removable media can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device. As defined in this article, computer-readable media do not include transient computer-readable media, such as modulated data signals and carrier waves.

[0165] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the aforementioned element.

[0166] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A private key protection method, characterized in that, include: Using a Trusted Execution Environment (TEE), obtain the public-private key pair of the target user that needs protection; The target user's data key and its ciphertext are obtained from the Key Management Service (KMS) using the TEE. 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; 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 target 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 further includes: The 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; the ciphertext of the random number is obtained by the server responding to the client's access request and encrypting the random number using the public key in the public-private key pair. The TEE is used to call the KMS to decrypt the ciphertext of the data key to obtain the data key; In the TEE, the ciphertext of the private key is decrypted using the data key to obtain the private key; The private key is used in the TEE to decrypt the ciphertext of the random number to obtain the plaintext of the random number; The plaintext of the random number is returned to the client so that the client can request the server to perform access permission verification based on the plaintext of the random number.

2. The method according to claim 1, characterized in that, The step of obtaining the user's data key and the ciphertext of the data key from the Key Management Service (KMS) using the TEE includes: The TEE is used to call the KMS, so that the KMS can generate the user's data key based on the target user's master key, and encrypt the data key to obtain the 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.

3. The method according to claim 1, characterized in that, The process of obtaining the public-private key pair to be protected using a Trusted Execution Environment (TEE) includes: Using the TEE, obtain the key request provided by the client; using the TEE to respond to the key request, generate a public-private key pair for the target user, which serves as the public-private key pair to be protected; or, The TEE receives the public / private key pair provided by the client, which serves as the public / private key pair to be protected.

4. A server-side access method, characterized in that, include: Use a Trusted Execution Environment (TEE) to obtain decryption requests 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 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 stores the ciphertext of the data key and the ciphertext of the private key; The TEE is used to call KMS to decrypt the ciphertext of the data key to obtain the data key; In the TEE, the ciphertext of the private key is decrypted using the data key to obtain the private key; The private key is used in the TEE to decrypt the ciphertext of the random number to obtain the plaintext of the random number; The plaintext of the random number is returned to the client so that the client can access the server based on the plaintext of the random number.

5. A private key protection method, characterized in that, include: The Trusted Execution Environment (TEE) is invoked to encrypt the private key in the public-private key pair of the target user, so that the TEE can call 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, 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 further includes: initiating an access request to the server, so that the server responds to the access request by encrypting the random number using the public key to obtain the ciphertext of the random number; Receive the ciphertext of the random number returned by the server; A decryption request is initiated to the TEE, which includes the ciphertext of the random number, the ciphertext of the data key, and the ciphertext of the private key. The TEE calls the KMS to decrypt the ciphertext of the data key to obtain the data key, and uses the data key to decrypt the ciphertext of the private key to obtain the private key; and uses 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; Access the server based on the plaintext of the random number.

6. A server-side access method, characterized in that, include: An access request is sent to the server, and the server responds to the access request by encrypting the random number using the public key in the public-private key pair of the target user corresponding to the client 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 target user's data key; Receive the ciphertext of the random number returned by the server; A decryption request is initiated to the Trusted Execution Environment (TEE). The decryption request includes the ciphertext of a random number, the ciphertext of the data key, and the ciphertext of the private key. The TEE calls KMS to decrypt the ciphertext of the data key to obtain the data key, and uses the data key to decrypt the ciphertext of the private key to obtain the private key. And the ciphertext of the random number is decrypted using the private key to obtain the plaintext of the random number; Receive the plaintext of the random number returned by the TEE; Access the server based on the plaintext of the random number.

7. A communication system, characterized in that, include: Client, first service node, and second service node; The first service node runs a Trusted Execution Environment (TEE); The second service node is used to provide key management services; The first service node is used to execute the steps in the method according to any one of claims 1-4; The client is used to perform the steps in the method according to any one of claims 5-6.

8. A computing device, characterized in that, include: A memory and a processor; wherein the memory is used to store computer programs; The processor is coupled to the memory for executing the computer program to perform the steps in the method executed by the first service node and / or the client in claim 7.

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 cause the processors to perform the steps in the method performed by the first service node and / or the client in claim 7.

Images