Security verification method and device of large model service, medium, equipment and product

Abstract

A security verification method, apparatus, medium, device, and product for a large model service, relating to the field of computer technology, is disclosed. It receives an encrypted service request, obtains the client's private key from a key management service running in a trusted execution environment (TEA) through an encryption / decryption service, and decrypts the encrypted service request based on the private key. The decrypted request is then sent to the large model service to obtain its inference result. This result is then encrypted using the client's public key and returned to the client. This approach not only ensures that the user's service request is visible in plaintext only within the TEA, greatly enhancing user data security, but also prevents user data leakage through the use of user-level public-private key pairs. Furthermore, since both the key management service and the encryption / decryption service run in a TEA, attacks originating from the IaaS layer can be shielded.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically, to a method, apparatus, medium, device, and product for security verification of large model services. Background Technology

[0002] In scenarios where large-scale model services are deployed via PaaS (Platform as a Service), users have very high requirements for the security of the services provided by the service provider. Generally, service providers can offer application-layer encryption schemes to ensure that user data is only visible in a limited number of modules within the large-scale model service chain. However, currently available application-layer encryption schemes cannot effectively guarantee the security of user data. Summary of the Invention

[0003] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0004] Firstly, this disclosure provides a security verification method for large model services, including:

[0005] Receive encrypted service requests sent by clients to the large model service, which runs in a trusted execution environment;

[0006] In response to the encryption service request, the encryption type is a preset encryption type. Based on the encryption / decryption service and the identity information carried in the encryption service request, the client's private key is obtained from the key management service. The preset encryption type indicates that the encryption service request is encrypted using the client's public key, and the encryption / decryption service and the key management service run in a trusted execution environment.

[0007] The encrypted service request is decrypted based on the client's private key to obtain the decryption service request;

[0008] The decryption service request is sent to the large model service to obtain the inference result of the large model service;

[0009] The inference result is encrypted using the client's public key, and the encrypted inference result is returned to the client.

[0010] Secondly, this disclosure provides a security verification device for large model services, comprising:

[0011] The receiving module is configured to receive encrypted service requests sent by clients to the large model service, which runs in a trusted execution environment;

[0012] The acquisition module is configured to respond to the encryption service request with a preset encryption type, and to obtain the client's private key from the key management service based on the encryption / decryption service and the identity information carried in the encryption service request; wherein, the preset encryption type indicates that the encryption service request is encrypted with the client's public key, and the encryption / decryption service and the key management service run in a trusted execution environment;

[0013] The decryption module is configured to decrypt the encrypted service request based on the client's private key to obtain the decrypted service request;

[0014] The input module is configured to send the decryption service request to the large model service and obtain the inference result of the large model service.

[0015] The sending module is configured to encrypt the inference result using the client's public key and return the encrypted inference result to the client.

[0016] Thirdly, this disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the method described in the first aspect.

[0017] Fourthly, this disclosure provides an electronic device, comprising:

[0018] A storage device on which computer programs are stored;

[0019] A processing device for executing the computer program in the storage device to implement the steps of the method described in the first aspect.

[0020] Fifthly, this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0021] Based on the above technical solution, by receiving encrypted service requests sent by clients, and assuming the encryption type of the encrypted service request is a preset encryption type, the encryption and decryption service running in the trusted execution environment (TEA) retrieves the client's private key from the key management service running in the TEA based on the identity information carried in the encrypted service request. The TEA then decrypts the encrypted service request using the client's private key, obtaining the decrypted service request. This decrypted service request is then sent to the large model service to obtain the inference result. The inference result is then encrypted using the client's public key and returned to the client. Through the trusted key management service and trusted encryption and decryption service, it can be ensured that the user's service request is only visible in plaintext within the TEA, greatly guaranteeing the security of user data. Furthermore, the use of user-level public-private key pairs avoids the data leakage problem that could occur with encryption using a general public key. Additionally, since both the key management service and the encryption and decryption service run in the TEA, attacks from the IaaS layer can be shielded.

[0022] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0023] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale. In the drawings:

[0024] Figure 1 This is a flowchart illustrating a security verification method for a large model service according to an exemplary embodiment.

[0025] Figure 2 This is an interactive schematic diagram illustrating a security verification method for a large model service according to an exemplary embodiment.

[0026] Figure 3 This is an interactive schematic diagram illustrating a security verification method for a large model service according to another exemplary embodiment.

[0027] Figure 4 This is a schematic diagram of the structure of a security verification device for a large model service, according to an exemplary embodiment.

[0028] Figure 5 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

[0029] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0030] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0031] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0032] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0033] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0034] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0035] Figure 1 This is a flowchart illustrating a security verification method for a large model service according to an exemplary embodiment. For example... Figure 1 As shown, this disclosure provides a security verification method for large model services. Specifically, this method can be executed using a security verification device for large model services, which can be implemented in software and / or hardware. Figure 1 As shown, the method may include the following steps.

[0036] In step 110, the encrypted service request sent by the client to the large model service is received.

[0037] Here, "large model service" can refer to a large language model (LMM) service. For example, a large model service could refer to the training task or inference service of a large language model deployed by a user. Large model services are deployed in container groups (Pods) created within virtual machines. For machine learning platforms, users can purchase corresponding IaaS (Infrastructure as a Service) resources (such as file systems, networks, ECS (Elastic Compute Service) etc.) from cloud service providers and deploy large model services within these IaaS resources.

[0038] The large model service runs in a Trusted Execution Environment (TEE). The TEE where the large model service resides can be a hardware-based TEE. For example, a hardware-based TEE can be a CPU (Central Processing Unit) TEE. A CPU TEE is an isolated region that runs on the CPU. In other words, a hardware-based Trusted Execution Environment (TEE) can be used to harden the virtual machines used to deploy the large model service, ensuring that the large model service runs within a trusted execution environment.

[0039] The encrypted service request sent by the client can be a service request encrypted with a key. This encrypted service request is used as input to the large model service to obtain the inference result corresponding to the large model service.

[0040] In step 120, the encryption type in response to the encryption service request is a preset encryption type, and the client's private key is obtained from the key management service based on the encryption / decryption service and the identity information carried in the encryption service request.

[0041] In this embodiment of the disclosure, the encryption type of the encrypted service request may include a first encryption type, a second encryption type, and a preset encryption type. The first encryption type indicates that the encrypted service request is not encrypted; the second encryption type indicates that the encrypted service request is encrypted using a general public key; and the preset encryption type indicates that the encrypted service request is encrypted using the client's public key. The general public key can be a general public key provided by the service provider. For example, the service provider provides the same general public key to different users, and different users use the same general public key to encrypt their respective service requests. On the service provider's server, the server can use the private key corresponding to the general public key to decrypt the encrypted service request. However, in the scheme using a general public key for encryption, since the private key corresponding to the general public key can also be obtained in an untrusted environment, the security of the scheme using a general public key for encryption is low, and there may be a problem of user data being decrypted and obtained.

[0042] In this embodiment of the disclosure, a preset encryption type is provided, which allows users to encrypt service requests generated by the client using the client's public key. It should be understood that the client's public key and private key constitute a public-private key pair; that is, the client's public-private key pair includes the client's public key and private key.

[0043] It should be understood that the client's public-private key pair refers to a user-specific public-private key pair, distinct from a general public key. A user-specific public-private key pair is unique to a specific user, and each user can possess their own private public-private key pair. Therefore, both the client's public key and private key belong to that specific client and are for the exclusive use of that client.

[0044] An encrypted service request may include a field indicating the encryption type to which the encrypted service request belongs. Different field values ​​can be used to characterize the encryption type of the encrypted service request. Therefore, the encryption type of the encrypted service request can be determined by the field values ​​carried in the encrypted service request.

[0045] If the encryption type of the encrypted service request is the first encryption type, the encrypted service request is essentially not encrypted, and can be directly sent to the large model service.

[0046] When the encryption type of the encryption service request is the second encryption type, the encryption and decryption service can obtain the private key corresponding to the general public key from the key management service, and use the private key corresponding to the general public key to decrypt the encryption service request to obtain the decryption service request, and then send the decryption service request to the large model service.

[0047] When the encryption type requested by the encryption service is a preset encryption type, the encryption / decryption service retrieves the client's private key corresponding to the identity information carried in the encryption service request from the key management service. It's important to note that the encryption / decryption service can directly retrieve the client's public / private key pair from the key management service based on the identity information carried in the encryption service request, thereby obtaining the client's private key.

[0048] It's worth noting that the encryption / decryption service runs within a Trusted Execution Environment (TEE). In other words, the TEE is used to harden the encryption / decryption service. For example, the TEE where the encryption / decryption service resides can be a hardware-based TEE. Similarly, the key management service runs within a TEE, which can also be a hardware-based TEE.

[0049] Because the key management service runs in a trusted execution environment, the unauthorized tampering of user-level public-private key pairs maintained in the key management service can be prevented. Similarly, because the encryption / decryption service runs in a trusted execution environment, the trustworthiness of user-level public-private key pairs obtained in the encryption / decryption service can also be guaranteed.

[0050] In this embodiment of the disclosure, the key management service is used to maintain user-level public-private key pairs and to maintain a general public key and its corresponding private key. The encryption / decryption service is used to decrypt encrypted service requests sent to the large model service and to encrypt the inference results output by the large model service.

[0051] The encrypted service request can carry identity information, which uniquely identifies the client sending the request. The key management service can store the public and private key pairs for each client using key-value pairs. In each key-value pair, the key is the identity information, and the value is the public and private key pair.

[0052] It should be understood that if the encryption / decryption service itself has cached the client's public / private key pair, step 130 can be executed directly. If the encryption / decryption service itself does not have cached the client's public / private key pair, the client's public / private key pair can be obtained from the key management service through step 120.

[0053] In step 130, the encryption service request is decrypted based on the client's private key to obtain the decryption service request.

[0054] Here, since the encrypted service request is encrypted using the public key in the public-private key pair, after obtaining the user-level private key, the encrypted service request can be decrypted using the user-level private key to obtain the decrypted service request.

[0055] In step 140, the decryption service request is sent to the large model service to obtain the inference result of the large model service.

[0056] Here, after decrypting the encrypted service request through the encryption / decryption service to obtain the decryption service request, the decryption service request is input into the large model service through the encryption / decryption service to obtain the inference result output by the large model service.

[0057] In step 150, the inference result is encrypted using the client's public key, and the encrypted inference result is returned to the client.

[0058] Here, the encryption / decryption service encrypts the inference result using the public key in the public-private key pair and returns the encrypted inference result to the client. On the client side, the client can decrypt the encrypted inference result using the private key in the user-level public-private key pair to obtain the decrypted inference result.

[0059] It should be understood that the process of obtaining the client's public key is the same as the process of obtaining the client's private key, and will not be repeated here. Of course, the encryption and decryption service can directly obtain the client's public and private key pair from the key management service, thereby obtaining both the client's public key and private key at the same time.

[0060] Therefore, by receiving encrypted service requests from clients, and assuming the encryption type of the encrypted service request is a preset encryption type, the encryption / decryption service running in the trusted execution environment (TEA) retrieves the client's private key from the key management service running in the TEA based on the identity information carried in the encrypted service request. The TEA then decrypts the encrypted service request using the client's private key, obtaining the decrypted service request. This decrypted service request is then sent to the large model service to obtain the inference result. The inference result is then encrypted using the client's public key and returned to the client. Through the trusted key management service and trusted encryption / decryption service, it can be ensured that user service requests are only visible in plaintext within the TEA, greatly guaranteeing the security of user data. Furthermore, the use of user-level public / private key pairs avoids the data leakage problem that could occur with encryption using a generic public key. Additionally, since both the key management service and the encryption / decryption service run in the TEA, attacks from the IaaS layer can be shielded.

[0061] In some feasible implementations, in step 120, a first remote proof report corresponding to the key management service can be obtained through the encryption / decryption service. Then, in response to the encryption / decryption service, the key management service is determined to be trustworthy based on the first remote proof report. Based on the encryption / decryption service and identity information, the client's private key is obtained from the key management service.

[0062] Here, the first remote proof report can be obtained by measuring the key management service through a remote proof service. The remote proof service is a security mechanism used to verify the platform's trustworthiness and code integrity. Measurement refers to the integrity verification and security checks performed on each component of the trusted execution environment. Measurements can be presented in the form of hash values ​​or digital signatures to prove that the trusted execution environment has not been tampered with and is trustworthy. For example, hash calculations can be performed on software, configuration files, etc., within the trusted execution environment to generate corresponding hash values, which are used to verify whether the corresponding software or configuration files have been tampered with.

[0063] In this embodiment, before requesting the client's private key from the key management service, the encryption / decryption service can first obtain a first remote verification report corresponding to the key management service. Then, the encryption / decryption service verifies the trustworthiness of the key management service using the first remote verification report. If the key management service is determined to be trustworthy, the encryption / decryption service obtains the client's private key from the key management service based on the client's identity information.

[0064] It should be understood that, through the first remote proof report, the encryption / decryption service can verify whether the key management service is running in a trusted execution environment, in order to avoid obtaining unauthorized user-level private keys due to tampering with the key management service.

[0065] In some embodiments, a first key request can be sent to a key management service based on the encryption / decryption service. Then, based on the key management service, a second remote proof report corresponding to the encryption / decryption service can be obtained in response to the first key request. Subsequently, in response to the key management service determining that the encryption / decryption service is trustworthy based on the second remote proof report, the private key corresponding to the identity information can be returned to the encryption / decryption service.

[0066] The second remote proof report can be obtained through a remote proof service, and its acquisition process is the same as that of the first remote proof report, so it will not be described again here. The encryption / decryption service can construct a first key request based on the identity information carried in the encryption service request. This first key request carries the identity information and is used to request the private key corresponding to the identity information from the key management service.

[0067] The key management service is used to obtain the second remote proof report corresponding to the encryption and decryption service, and, if the encryption and decryption service is deemed trustworthy based on the second remote proof report, returns the private key corresponding to the identity information to the encryption and decryption service.

[0068] In other words, in this embodiment, the encryption / decryption service and the key management service can mutually verify each other's trustworthiness. The encryption / decryption service verifies the trustworthiness of the key management service through a first remote proof report. Only after confirming the trustworthiness of the key management service will the encryption / decryption service request the user-level private key from the key management service. Conversely, the key management service also verifies the trustworthiness of the encryption / decryption service through a second remote proof report. Only after confirming the trustworthiness of the encryption / decryption service will the key management service respond to the first key request sent by the encryption / decryption service and return the user-level private key to the encryption / decryption service, thus preventing the sending of the user-level private key to a forged encryption / decryption service. This ensures that the user-level public / private key pair can always circulate within a trusted execution environment, preventing the leakage of the user-level public / private key pair.

[0069] In some embodiments, the encryption / decryption service runs in the trusted execution environment (TEX) where the large model service resides. That is, the encryption / decryption service can be deployed in the same TEX environment as the large model service. In this way, decryption service requests obtained by the encryption / decryption service can be sent directly to the large model service within the TEX environment, preventing the plaintext of the decryption service request from appearing in an untrusted execution environment. Furthermore, the inference results output by the large model service can also be directly encrypted by the encryption / decryption service deployed in the same TEX environment, thereby preventing the inference results output by the large model service from appearing in an untrusted execution environment.

[0070] In some feasible implementations, the second key request sent by the client can be received based on the intermediate service layer, and then, based on the encryption and decryption service, the client's public key can be obtained from the key management service in response to the second key request, and the client's public key can be returned to the client.

[0071] Here, the intermediate service layer can be a service layer used for interaction between the client and backend services (such as key management service, large model service). The client can send a second key request to the intermediate service layer, which is used to request the client's public key.

[0072] The encryption / decryption service can run at an intermediate service layer. Accordingly, the encryption / decryption service running at the intermediate service layer responds to the second key request by obtaining the client's public key from the key management service using the identity information carried in the second key request, and then returns the client's public key to the client. The client's public key is used by the client to encrypt the generated service requests.

[0073] In some embodiments, the client's public key may be stored in a first remote verification report of the key management service. Accordingly, the first remote verification report may be returned to the client, enabling the client to obtain and verify the trustworthiness of the client's public key based on the first remote verification report.

[0074] As examples, the encryption / decryption service can obtain the first remote proof report corresponding to the key management service, write the client's public key into the first remote proof report, and return the first remote proof report to the client, so that the client can obtain and verify the trustworthiness of the client's public key based on the first remote proof report.

[0075] As other examples, a first remote proof report carrying the client's public key can be returned to the encryption / decryption service via a key management service.

[0076] For a detailed description of the first remote proof report, please refer to the relevant description in the above embodiments, which will not be repeated here.

[0077] By storing the client's private public key in the first remote proof report, the user-level public key can be carried in the first remote proof report. Since the first remote proof report can be used to verify the trustworthiness of the key management service, correspondingly, if the trustworthiness of the key management service is verified through the first remote proof report, then the public key obtained from the key management service is also trustworthy.

[0078] Therefore, by including the client's public key in the first remote verification report, not only can the user-level public key be transmitted to the client, but the user can also verify the trustworthiness of the key management service and the client's public key through the first remote report.

[0079] It is worth noting that in this embodiment, the encryption / decryption service can be deployed in an intermediate service layer, which also runs in a trusted execution environment. By deploying the intermediate service layer and the encryption / decryption service in a trusted execution environment, it can be ensured that the public / private key pair and unencrypted user data obtained by the encryption / decryption service will not appear in an untrusted execution environment.

[0080] Following the above implementation methods, in this embodiment, the encryption / decryption service can be deployed in the trusted execution environment where the large model service resides, or it can be deployed in the trusted execution environment of the intermediate service layer, depending on the actual situation. Regardless of whether the encryption / decryption service is deployed in the intermediate service layer or in the large model service, the encryption / decryption service is hardened through the trusted execution environment to prevent the unauthorized acquisition of user-level public / private key pairs and unencrypted user data.

[0081] In some feasible implementations, when the client creates a large model service, it registers the large model service with the key management service. Then, based on the key management service, in response to the registration request of the large language model service, it verifies the trustworthiness of the large model service. In response to determining that the large model service is trustworthy, it generates a public-private key pair for the client and stores the client's public-private key pair in the key management service.

[0082] Here, creating a large model service can refer to launching a large model service. For example, creating a large model service can involve launching the large model service within a trusted execution environment; that is, the launched large model service is also hardened through the trusted execution environment.

[0083] When launching a large model service, the large model service can initiate a registration request to the key management service. In response, the key management service obtains a third-party remote proof report corresponding to the large model service and verifies its trustworthiness using this report. If the large model service is deemed trustworthy, the key management service generates a public-private key pair for the client and stores it in its own database. Subsequently, the client and the encryption / decryption service can request the public key and / or private key from the public-private key pair from the key management service.

[0084] It should be understood that large model services can be deployed in at least one container group (Pod), and correspondingly, the key management service can also record the node information corresponding to the node where the container group is located.

[0085] The following is in conjunction with the appendix Figure 2 and attached Figure 3 The above-described embodiments will be described in detail.

[0086] Figure 2 This is an interactive schematic diagram illustrating a security verification method for a large model service according to an exemplary embodiment. For example... Figure 2 As shown, the client can request the general public key through steps S201 to S204.

[0087] S201, the client requests a general public key from the intermediate service layer through the interface; wherein, the client can send a third key request to the intermediate service layer through the interface to request the general public key.

[0088] S202, the intermediate service layer requests a general public key from the key management service; wherein, the encryption and decryption service running in the intermediate service layer can respond to the third key request and send a fourth key request to the key management service to request the general public key.

[0089] S203, the key management service returns a general public key to the intermediate service layer; wherein, in response to the fourth key request, the key management service returns a general public key to the encryption and decryption service running in the intermediate service layer.

[0090] S204, the intermediate service layer returns a general public key to the interface. Specifically, the encryption / decryption service running in the intermediate service layer receives the general public key returned by the key management service and returns it to the interface. It should be understood that the general public key can also be stored in the first remote verification report of the key management service. The encryption / decryption service can return the first remote verification report carrying the general public key to the interface, allowing the user to obtain the general public key through the first remote verification report and verify the trustworthiness of the key management service through the first remote verification report.

[0091] Through steps S201 to S204, the client can obtain a general public key from the key management service to encrypt service requests generated by the client.

[0092] like Figure 2 As shown, the client can request the client's private public key through steps S205 to S208.

[0093] S205, the client requests its public key from the intermediate service layer through the interface; wherein, the client can send a second key request to the intermediate service layer through the interface to request the client's public key.

[0094] S206, the intermediate service layer requests the client's public key from the key management service; wherein, the encryption and decryption service running in the intermediate service layer can receive the second key request and, in response to the second key request, request the client's public key from the key management service using the identity information carried in the second key request.

[0095] S207, the key management service returns the client's public key to the intermediate service layer; wherein, the key management service finds the corresponding client's public key through the received identity information and returns the client's public key to the encryption and decryption service deployed in the intermediate service layer.

[0096] S208, the intermediate service layer returns the client's public key to the interface. Specifically, the encryption / decryption service running in the intermediate service layer receives the client's public key returned by the key management service and returns it to the interface. It should be understood that the client's public key can also be stored in the first remote verification report of the key management service. The encryption / decryption service can return the first remote verification report carrying the client's public key to the interface, allowing the user to obtain the client's public key through the first remote verification report and verify the trustworthiness of the key management service through the first remote verification report.

[0097] Through steps S205 to S208, the client can obtain its public key from the key management service, and use the client's public key to encrypt service requests generated by the client.

[0098] It is worth noting that the client can obtain the general public key and the client's public key through a unified interface, so that the scheme requesting the encryption service through the general public key and the scheme requesting the encryption service through the client's public key can share the unified interface. This allows users to choose to request the encryption service through the general public key or the client's public key.

[0099] like Figure 2 As shown, the service request sent by the client can be processed through steps S209 to S217.

[0100] S209, the client sends an encryption service request to the intermediate service layer through an interface; specifically, the client can send the encryption service request to the encryption / decryption service deployed in the intermediate service layer through the interface. It should be understood that the encryption service request can be encrypted using a general public key or using the client's public key.

[0101] S210, the intermediate service layer requests the client's private key from the key management service; the encryption and decryption service deployed in the intermediate service layer receives the encryption service request sent by the interface and determines the encryption type to which the encryption service request belongs. When the encryption type is a preset encryption type, the encryption and decryption service obtains the first remote proof report corresponding to the key management service, and if the key management service is deemed trustworthy based on the first remote proof report, the encryption and decryption service sends a first key request to the key management service to request the client's private key.

[0102] S211, the key management service returns the client's private key to the intermediate service layer; wherein, in response to the first key request, the key management service obtains the second remote proof report corresponding to the encryption and decryption service, and if the key management service determines that the encryption and decryption service is trustworthy based on the second remote proof report, the key management service returns the client's private key to the encryption and decryption service.

[0103] S212, the intermediate service layer decrypts the encrypted service request using the client's private key to obtain the decryption service request; wherein, the encryption and decryption service deployed in the intermediate service layer decrypts the encrypted service request based on the client's private key to obtain the decryption service request.

[0104] S213, the intermediate service layer sends a decryption service request to the large model service; wherein, after obtaining the decryption service request through the encryption and decryption service deployed in the intermediate service layer, the encryption and decryption service inputs the decryption service request to the large model service.

[0105] S214, The large model service outputs the inference result; wherein, the large model service outputs the inference result corresponding to the decryption service request and sends the inference result to the encryption and decryption service deployed in the intermediate service layer.

[0106] S215, the intermediate service layer encrypts the inference result and obtains the encrypted inference result; wherein, the encryption and decryption service deployed in the intermediate service layer receives the inference result, and the encryption and decryption service encrypts the inference result using the client's public key to obtain the encrypted inference result.

[0107] S216, the intermediate service layer returns the encrypted inference result to the interface; wherein, the encryption and decryption service deployed in the intermediate service layer returns the encrypted inference result to the interface.

[0108] S217, the client decrypts the encrypted inference result through the interface. The client interface can obtain the client's private key from the key management service through the encryption / decryption service, and use the client's private key to decrypt the inference result encrypted with the client's public key. It should be understood that the principle of the interface obtaining the client's private key from the key management service through the encryption / decryption service is the same as the principle of obtaining the client's public-private key pair from the key management service through the encryption / decryption service in the above embodiment.

[0109] It is worth noting that since the encryption / decryption service, key management service, and large model service all run in a trusted execution environment, user data (service requests, inference results) will only be presented in plaintext after authentication in the trusted execution environment. In other links of the large model service, it will be presented in ciphertext, thus ensuring the security of user data.

[0110] Figure 3 This is an interactive schematic diagram illustrating a security verification method for a large model service according to another exemplary embodiment. For example... Figure 3 As shown, the interface initializes the client and requests the client's public key from the server's backend service. The server's backend service requests the client's public key from the key management service and returns it to the interface. The interface encrypts the service request using the client's public key, obtaining an encrypted service request, and sends it to the server's gateway. The server's gateway sends the encrypted service request to the proxy service used to schedule service requests. The proxy service sends the encrypted service request to the encryption / decryption service of the corresponding node. The encryption / decryption service requests the client's private key from the key management service and decrypts the encrypted service request using the client's private key, obtaining a decrypted service request. Then, the encryption / decryption service sends the decrypted service request to the large model service to obtain the inference result of the large model service.

[0111] It should be understood that the backend service can be a control plane service, and this backend service can be... Figure 2 The diagram shows the intermediate service layer. Of course, the backend service can also be an encryption / decryption service. Figure 3 In this context, the encryption / decryption service and the large model service are deployed in the same executable environment, and the encryption / decryption service can be a workset of the large model service. For example... Figure 3As shown, the large model service, encryption / decryption service, and key management service all run in a trusted execution environment, thus avoiding attacks from the IaaS layer.

[0112] Figure 4 This is a schematic diagram illustrating the structure of a security verification device for a large-scale model service according to an exemplary embodiment. For example... Figure 4 As shown, this disclosure provides a security verification device 400 for a large model service, which includes:

[0113] The receiving module 401 is configured to receive encrypted service requests sent by the client to the large model service, which runs in a trusted execution environment;

[0114] The acquisition module 402 is configured to respond to the encryption type of the encryption service request as a preset encryption type, and obtain the client's private key from the key management service based on the encryption / decryption service and the identity information carried in the encryption service request; wherein, the preset encryption type indicates that the encryption service request is encrypted with the client's public key, and the encryption / decryption service and the key management service run in a trusted execution environment;

[0115] The decryption module 403 is configured to decrypt the encrypted service request based on the client's private key to obtain the decryption service request;

[0116] Input module 404 is configured to send the decryption service request to the large model service and obtain the inference result of the large model service;

[0117] The sending module 405 is configured to encrypt the inference result using the public key of the client and return the encrypted inference result to the client.

[0118] Optionally, the acquisition module 402 is specifically configured as follows:

[0119] The encryption / decryption service obtains the first remote proof report corresponding to the key management service;

[0120] In response to the encryption / decryption service determining that the key management service is trustworthy based on the first remote proof report, the client's private key is obtained from the key management service based on the encryption / decryption service and the identity information.

[0121] Optionally, the acquisition module 402 is specifically configured as follows:

[0122] Based on the encryption / decryption service, a first key request is sent to the key management service, wherein the first key request is used to request the private key corresponding to the identity information;

[0123] Based on the key management service, respond to the first key request and obtain the second remote proof report corresponding to the encryption / decryption service;

[0124] In response to the key management service determining that the encryption / decryption service is trustworthy based on the second remote proof report, the key management service returns the private key corresponding to the identity information to the encryption / decryption service.

[0125] Optionally, the encryption / decryption service runs in the trusted execution environment where the large model service resides.

[0126] Optionally, the security verification device 400 for the large model service further includes:

[0127] The request sending unit is configured to receive a second key request sent by the client based on the intermediate service layer, the second key request being used to request the client's public key;

[0128] The return unit is configured to, based on the encryption / decryption service, respond to the second key request by obtaining the client's public key from the key management service and returning the client's public key to the client, wherein the encryption / decryption service runs in the intermediate service layer and the client's public key is used by the client to encrypt the generated service requests.

[0129] Optionally, the client's public key is stored in the first remote verification report of the key management service; the return unit is specifically configured as follows:

[0130] The first remote proof report is returned to the client so that the client can obtain and verify the trustworthiness of the client's public key based on the first remote proof report.

[0131] Optionally, the security verification device 400 for the large model service further includes:

[0132] The registration unit is configured to register the large model service with the key management service when the client creates the large model service;

[0133] The verification unit is configured to verify the trustworthiness of the large language model service in response to the registration request of the large language model service, based on the key management service.

[0134] The generation unit is configured to generate a public-private key pair for the client in response to determining that the large model service is trustworthy, and to store the public-private key pair for the client in the key management service, wherein the public-private key pair includes the client's public key and the client's private key.

[0135] Regarding the security verification device 400 for the large model service in the above embodiments, the method logic executed by each functional module has been described in detail in the section on methods, and will not be repeated here.

[0136] The following is for reference. Figure 5 The diagram illustrates a structural schematic of an electronic device (e.g., a terminal device or a server) 500 suitable for implementing embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0137] like Figure 5 As shown, electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 502 or a program loaded from storage device 508 into random access memory (RAM) 503. RAM 503 also stores various programs and data required for the operation of electronic device 500. Processing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0138] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0139] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the methods of embodiments of this disclosure.

[0140] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0141] In some implementations, the client and server can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol), and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0142] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0143] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the following: to receive an encryption service request sent by a client to a large model service, the large model service running in a trusted execution environment; in response to the encryption type of the encryption service request being a preset encryption type, to obtain the client's private key from a key management service based on an encryption / decryption service and the identity information carried in the encryption service request; wherein the preset encryption type indicates that the encryption service request is encrypted using the client's public key, and the encryption / decryption service and the key management service run in a trusted execution environment; to decrypt the encryption service request based on the client's private key to obtain a decryption service request; to send the decryption service request to the large model service to obtain the inference result of the large model service; and to encrypt the inference result using the client's public key and return the encrypted inference result to the client.

[0144] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0145] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0146] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules are not, in some cases, intended to limit the functionality of the module itself.

[0147] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0148] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0149] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0150] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0151] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims. Regarding the apparatus in the above embodiments, the specific manner in which the various modules perform their operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.

Claims

1. A security verification method for large model services, characterized in that, include: Receive encrypted service requests sent by clients to the large model service, which runs in a trusted execution environment; In response to the encryption service request, the encryption type is a preset encryption type. Based on the encryption / decryption service and the identity information carried in the encryption service request, the client's private key is obtained from the key management service. The preset encryption type indicates that the encryption service request is encrypted using the client's public key. The encryption / decryption service and the key management service run in a trusted execution environment. The encryption / decryption service runs in the trusted execution environment where the large model service is located. The encrypted service request is decrypted based on the client's private key to obtain the decryption service request; The decryption service request is sent to the large model service to obtain the inference result of the large model service; The inference result is encrypted using the client's public key, and the encrypted inference result is returned to the client. The step of obtaining the client's private key from the key management service based on the identity information carried in the encryption / decryption service and the encryption service request includes: The encryption / decryption service obtains the first remote proof report corresponding to the key management service; In response to the encryption / decryption service determining that the key management service is trustworthy based on the first remote proof report, the encryption / decryption service sends a first key request to the key management service based on the encryption / decryption service. The first key request is used to request the private key corresponding to the identity information. Based on the key management service, respond to the first key request and obtain the second remote proof report corresponding to the encryption / decryption service; In response to the key management service determining that the encryption / decryption service is trustworthy based on the second remote proof report, the key management service returns the private key corresponding to the identity information to the encryption / decryption service.

2. The method according to claim 1, characterized in that, The method further includes: The intermediate service layer receives a second key request sent by the client, the second key request being used to request the client's public key; Based on the encryption / decryption service, in response to the second key request, the client's public key is obtained from the key management service and returned to the client. The encryption / decryption service runs in the intermediate service layer, and the client's public key is used by the client to encrypt the generated service requests.

3. The method according to claim 2, characterized in that, The client's public key is stored in the first remote verification report of the key management service; returning the client's public key to the client includes: The first remote proof report is returned to the client so that the client can obtain and verify the trustworthiness of the client's public key based on the first remote proof report.

4. The method according to claim 1, characterized in that, The method further includes: When the client creates the large model service, it registers the large model service with the key management service; Based on the key management service, in response to the registration request of the large model service, the trustworthiness of the large model service is verified; In response to determining that the large model service is trustworthy, a public-private key pair for the client is generated and stored in the key management service, wherein the public-private key pair includes the client's public key and the client's private key.

5. A security verification device for large model services, characterized in that, include: The receiving module is configured to receive encrypted service requests sent by clients to the large model service, which runs in a trusted execution environment; The acquisition module is configured to respond to the encryption service request with a preset encryption type, and to obtain the client's private key from the key management service based on the encryption / decryption service and the identity information carried in the encryption service request; wherein, the preset encryption type indicates that the encryption service request is encrypted using the client's public key, and the encryption / decryption service and the key management service run in a trusted execution environment; the encryption / decryption service runs in the trusted execution environment where the large model service is located; The decryption module is configured to decrypt the encrypted service request based on the client's private key to obtain the decrypted service request; The input module is configured to send the decryption service request to the large model service and obtain the inference result of the large model service. The sending module is configured to encrypt the inference result using the client's public key and return the encrypted inference result to the client; The acquisition module is specifically configured as follows: The encryption / decryption service obtains the first remote proof report corresponding to the key management service; In response to the encryption / decryption service determining that the key management service is trustworthy based on the first remote proof report, the encryption / decryption service sends a first key request to the key management service based on the encryption / decryption service. The first key request is used to request the private key corresponding to the identity information. Based on the key management service, respond to the first key request and obtain the second remote proof report corresponding to the encryption / decryption service; In response to the key management service determining that the encryption / decryption service is trustworthy based on the second remote proof report, the key management service returns the private key corresponding to the identity information to the encryption / decryption service.

6. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processing device, it implements the steps of the method according to any one of claims 1-4.

7. An electronic device, characterized in that, include: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the method according to any one of claims 1-4.

8. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-4.

Images