Large model service security verification method and device, medium, equipment and product

Abstract

A security verification method and apparatus for a large model service, a medium, a device and a product relate to the technical field of computers, when a private key check request sent by an intermediate link service is received based on a key management service, the intermediate link service is added to a trusted execution environment in response to determining that the intermediate link service is not trusted according to the private key check request, and the security verification of the large model service is realized. Wherein the private key checking request is sent when the intermediate link service receives an encryption reasoning request sent by the client, the private key checking request indicates to check a private key of the client, the private key of the client is sent to the intermediate link service in response to the fact that the intermediate link service is determined to be credible according to the private key checking request, and the private key of the client is sent to the intermediate link service. Therefore, the intermediate link service requesting the private key can be ensured to be in the trusted execution environment, namely the security of the intermediate link service is ensured.

Description

Technical Field

[0001] The technical solution relates to the field of computer technology, specifically to a security verification method, apparatus, medium, equipment, and product for large-scale model services. Background Technology

[0002] MaaS (Model as a Service) is a type of PaaS (Platform as a Service). MaaS is a cloud computing model that delivers artificial intelligence models as services. This model enables model training, fine-tuning, evaluation, inference deployment, and more. Users have high requirements for the security of service providers during the service delivery process. Therefore, effectively ensuring the security of user data is a critical technical problem that needs to be solved when providing inference services. Summary of the Invention

[0003] This summary section is provided to briefly introduce the concepts, which will be described in detail in the subsequent detailed description section. 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, a security verification method for large model services is provided, including: The key management service receives a private key viewing request sent by the intermediate link service. The private key viewing request is sent by the intermediate link service when it receives a cryptographic inference request sent by the client. The private key viewing request indicates that the client's private key should be viewed. In response to determining that the intermediate link service is untrusted based on the private key viewing request, the intermediate link service is added to the trusted execution environment; In response to determining that the intermediate link service is trustworthy based on the private key viewing request, the client's private key is sent to the intermediate link service.

[0005] Secondly, a security verification device for large model services is provided, including: The receiving module is configured to receive a private key viewing request sent by the intermediate link service based on the key management service. The private key viewing request is sent by the intermediate link service when it receives a cryptographic inference request sent by the client. The private key viewing request indicates that the client's private key should be viewed. The module is configured to add the intermediate link service to the trusted execution environment in response to determining that the intermediate link service is untrusted based on the private key viewing request. The sending module is configured to send the client's private key to the intermediate link service in response to determining that the intermediate link service is trustworthy based on the private key viewing request.

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

[0007] Fourthly, an electronic device is provided, comprising: 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 described in the first aspect.

[0008] Fifthly, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0009] Through the above technical solution, when the key management service receives a private key viewing request from the intermediate link service, it determines that the intermediate link service is untrusted based on the private key viewing request. The key management service then adds the untrusted intermediate link service to the trusted execution environment. The private key viewing request is sent by the intermediate link service when it receives a cryptographic inference request from the client. This request instructs the service to view the client's private key. In response to determining that the intermediate link service is trustworthy based on the private key viewing request, the service sends the client's private key to the intermediate link service. By detecting whether the intermediate link service is trustworthy and adding it to the trusted execution environment when it is determined to be untrustworthy, the illegal interception of user data at the intermediate link service can be prevented, thus greatly ensuring the security of user data.

[0010] Other features and advantages of the technical solution will be described in detail in the following detailed implementation section. Attached Figure Description

[0011] The above and other features, advantages, and aspects of the technical solution will become more apparent when taken in conjunction with 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: Figure 1 This is a flowchart illustrating a security verification method for a large model service according to an exemplary embodiment.

[0012] Figure 2 This is an example diagram illustrating the relationship between the client, intermediate link service, and key management service in a security verification method for a large-scale service according to an exemplary embodiment.

[0013] Figure 3 This is an example diagram illustrating the addition of intermediate link services to a trusted execution environment in a security verification method for a large model service, according to an exemplary embodiment.

[0014] Figure 4 This is an example diagram illustrating a framework for detecting intermediate link services in a security verification method for a large model service, according to an exemplary embodiment.

[0015] Figure 5 This is an architecture diagram of a large model service in a security verification method for a large model service, as illustrated in an exemplary embodiment.

[0016] Figure 6 This is an interactive example diagram illustrating a security verification method for a large model service according to an exemplary embodiment.

[0017] Figure 7 This is a block diagram illustrating a security verification device for a large model service according to an exemplary embodiment.

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

[0019] The technical solution will now be described in more detail with reference to the accompanying drawings. Although certain scenarios are shown in the drawings, it should be understood that the technical solution can be implemented in various forms and should not be construed as limited to the scenarios described herein. Rather, these scenarios are provided to provide a more thorough and complete understanding of the technical solution. It should be understood that the accompanying drawings and the scenarios described are for illustrative purposes only and are not intended to limit the scope of protection of the technical solution.

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

[0021] The term "comprising" and its variations as used herein can be open-ended, meaning "including but not limited to". The term "based on" can mean "at least partially based on". The term "one case" means "at least one case"; the term "another case" means "at least one additional case"; the term "some cases" means "at least some cases". Definitions of other terms will be given in the following description.

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

[0023] It should be noted that the terms "one" and "more" used here 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".

[0024] The names of messages or information exchanged between the multiple devices in the implementation are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0025] It is understandable that before using the technical solutions provided here, users should be informed of the type, scope of use, and usage scenarios of the personal information involved in accordance with relevant laws and regulations, and their permission should be obtained.

[0026] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations described herein.

[0027] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0028] It is understood that the above notification and user permission acquisition process are merely illustrative and do not constitute a limitation on the implementation of the technical solution. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the technical solution.

[0029] At the same time, it is understood that the data involved in the technical solution (including but not limited to the data itself, the acquisition or use of the data) should comply with the requirements of relevant laws, regulations and related provisions.

[0030] In related technologies, MaaS-related tasks can be divided into inference and training, involving three types of roles. The first type is the Cloud Service Provider (CSP), which mainly provides cloud services to different model vendors. The second type is the model vendor, which can use the resources provided by the cloud service provider to build its own inference service. The third type is the client, which is the entity that can run the applications provided by the cloud service provider and the model vendor. It can be seen that the third type of role is a common customer of the model vendor and the cloud service provider, and has certain requirements for the security of the application when using the applications provided by the vendor and the cloud service provider.

[0031] To ensure user data security, a key management service based on model units is proposed. This key management service, also known as a confidential inference service or a trusted key management service, can prevent user data from being illegally obtained by cloud service providers. During inference, plaintext data input by the user can only appear in the TEE VM (Trusted Execution Environment Virtual Machine). When the plaintext data leaves the TEE VM, it needs to be encrypted, such as during transmission (data-in-transit) and at rest (data-at-rest), to ensure that user data is not illegally intercepted.

[0032] When the cloud receives an inference request, it can perform inference operations based on the large model service to obtain the inference result. The large model service can refer to a Large Language Model (LLM) service, such as a user-deployed training task or inference service for a large language model. The large model service can be deployed in a container group (Pod) created within a virtual machine.

[0033] For machine learning platforms, users can purchase corresponding IaaS (Infrastructure as a Service) resources from cloud service providers and deploy large model services within these IaaS resources. These large model services can run 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 running on a CPU. In other words, a hardware-based Trusted Execution Environment (TEE) can be used to harden the virtual machines used to deploy large model services, ensuring that the large model services run within a trusted execution environment.

[0034] The process of obtaining inference results usually involves multiple intermediate link services, and these intermediate link services may be dynamically adjusted. If these intermediate link services need plaintext in the process of processing inference operations, they usually need to request the client's private key from the key management service. In this process, if a certain intermediate link service is insecure, it will lead to the risk of user data being illegally obtained.

[0035] To address the aforementioned issues, a security verification method for large model services is provided. This method can determine whether the intermediate link service corresponding to the private key viewing request is untrusted when it receives such a request. If it is determined to be untrusted, the untrusted intermediate link service can be added to the trusted execution environment. Conversely, if the intermediate link service is determined to be trustworthy, the client's private key can be sent to the trusted intermediate link service. This effectively improves the security of user data while ensuring the normal operation of inference.

[0036] 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, the technical solution provides a security verification method for large model services. Specifically, this method can be executed through 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.

[0037] In step S110, the key management service receives a private key viewing request sent by the intermediate link service.

[0038] In one scenario, the security verification methods for large-scale services can be applied to a key management service, which can be a trusted key management service running in a trusted execution environment (TEE). Here, the trusted execution environment where the key management service resides can be a hardware-based trusted execution environment, meaning that a hardware trusted execution environment can be used to protect virtual machines (VMs), thereby providing additional protection for container groups running within VMs.

[0039] In addition, key management services can be dedicated services responsible for generating, storing, managing and distributing keys. For example, they can be used to manage the client's public key and private key, that is, to manage the client's public and private key pairs.

[0040] When the key management service receives a private key viewing request from the intermediate link service, it can determine whether the intermediate link service is trustworthy based on the private key viewing request. Specifically, the private key viewing request can be sent by the intermediate link service upon receiving a cryptographic inference request from a client; this request instructs the service to view the client's private key.

[0041] In other words, upon receiving a cryptographic inference request from a client, if the intermediate link service determines that the request needs to be decrypted, it can send a private key viewing request to the key management service. The cryptographic inference request can be sent by the client to the intermediate link service, or it can be sent by the client to the intermediate link service through a specified interface (client initialization).

[0042] For example, a cryptographic inference request can be a session key ciphertext obtained by encrypting a prompt input by the SDK (Software Development Kit) using the public key and the user's private key when it receives the prompt from the user and the client's public key sent by the key management service. In other words, the cryptographic inference request can be a prompt encrypted by the SDK. Furthermore, the user here can be a test user or a user actually using the large-scale model service.

[0043] The public key of the aforementioned client can be a user-level public key. This client's public key can be obtained from the key management service when the intermediate link service receives a public key request sent by the client. That is, when the key management service receives a public key request sent by the intermediate link, it can send the client's public key to the intermediate link service so that the intermediate link service can forward the client's public key to the client.

[0044] It should be noted that when the intermediate link service receives a public key request from a client, it can also determine the type of the public key request, i.e., whether the public key request carries a specified identifier. If it is determined that the public key request sent by the client carries a specified identifier, the intermediate link service can send the public key request to the key management service. Otherwise, the intermediate link service can send the public key request to a regular key management service, which has lower security because it is not placed in a trusted execution environment. For example, the specified identifier can be a header identifier. Here, whether or not a header identifier is carried is used to indicate whether the inference operation uses trusted inference or confidential inference.

[0045] Additionally, the client can also include a specified identifier in its cryptographic inference request. When the intermediate link service receives the request, it can determine whether it contains this identifier. If it does, the intermediate link service can send a private key viewing request to the key management service. Otherwise, it can send the private key viewing request to the regular key management service.

[0046] It's worth noting that different cryptographic inference requests correspond to different intermediate link services, and these services may also change at different times; in other words, the intermediate link services can be dynamically changing. That is, the entire inference service or inference framework corresponding to the inference request is dynamically evolving. Here, the intermediate link service can also be called the intermediate inference link or the user inference link. Some of these intermediate link services require plaintext when providing inference services, while others do not.

[0047] To better illustrate the relationships between intermediate link services, and their relationships with the client and key management services, the following are given: Figure 2 The example diagram shown is based on Figure 2 It is understood that users can input a prompt (plaintext) through a client on the customer network and encrypt the prompt to obtain an encrypted inference request. The cloud network may include large model services, multiple intermediate link services, and key management services.

[0048] Among them, the multiple intermediate link services can be divided into the first type of intermediate link services and the second type of intermediate link services. The first type of intermediate link services can be link services that do not require plaintext, such as the first intermediate link service 201 and the third intermediate link service 203. The second type of intermediate link services can be link services that require plaintext, such as the second intermediate link service 202 and the fourth intermediate link service 204.

[0049] For example, intermediate link services requiring plaintext can include external MCP (Model Context Protocol) services, such as the fourth intermediate link service 204, which could be an order query service. In other words, calling intermediate link services can include calling various MCP services, etc.

[0050] It should be noted that the relationship between multiple intermediate link services can be serial, such as the first intermediate link service 201, the second intermediate link service 202, and the third intermediate link service 203 being serially connected. Alternatively, multiple intermediate link services may also be parallel, such as the fourth intermediate link service 204 being parallel to the second intermediate link service 202. The specific relationship between multiple intermediate link services is not explicitly defined here and can be adjusted according to the actual situation.

[0051] Figure 2 In this scenario, only the main model service operates within a trusted execution environment, while multiple intermediate link services, especially those requiring plaintext access, are not. This compromises user data security. Therefore, to ensure the security of the entire inference chain, upon receiving a private key viewing request from an intermediate link service, the key management service can verify the trustworthiness of the intermediate inference link requiring plaintext access. In other words, the key management service can determine the trustworthiness of an intermediate link service based on the private key viewing request; specifically, trustworthiness can be determined by whether the intermediate link service has joined a trusted execution environment.

[0052] In one scenario, when the key management service receives an intermediate link service, it can determine whether a remote verification report corresponding to that intermediate link service exists in the trusted execution environment. This remote verification report can be a security audit report. Here, the remote verification report can be stored on a designated node of the VM in the trusted execution environment. This remote verification report can be created when the intermediate link service is added to the trusted execution environment, and it can be dynamically changed.

[0053] Here, when the intermediate link service sends a private key viewing request to the key management service, if it has joined the trusted execution environment, the intermediate link service can obtain its corresponding remote proof report from the trusted execution environment and send the remote proof report to the key management service. Based on this, the key management service can determine that the intermediate link service has a corresponding remote proof report.

[0054] Conversely, if the intermediate link service is not part of the trusted execution environment when it sends a private key viewing request to the key management service, it cannot obtain its corresponding remote proof report from the trusted execution environment. Therefore, the intermediate link service cannot provide its corresponding remote proof report to the key management service. Based on this, the key management service can determine that the intermediate link service does not have a corresponding remote proof report, and thus the intermediate link service is untrusted.

[0055] Optionally, the key management service can also check whether a remote verification report corresponding to the intermediate link service exists in the trusted execution environment when it receives a private key viewing request from the intermediate link service. The private key viewing request may include the identity information of the intermediate link service. This identity information is used to determine whether a remote verification report corresponding to the intermediate link service exists in the trusted execution environment. If a remote verification report corresponding to the intermediate link service is found in the trusted execution environment, the intermediate link service is determined to be trustworthy. Otherwise, the intermediate link service is determined to be untrustworthy.

[0056] The aforementioned remote verification report can be obtained by measuring the intermediate link service through the remote verification service. The remote verification service is a security mechanism primarily used to verify the platform's trustworthiness and code integrity. Here, the measurement can be an integrity check and security verification of the intermediate link service.

[0057] In another scenario, upon receiving a private key viewing request from an intermediate link service, the key management service can determine whether the intermediate link service requesting the client's private key is a newly added intermediate link service. If it is determined that the intermediate link service sending the private key viewing request is a newly added intermediate link service, the key management service can further determine whether the newly added intermediate link service is trustworthy. If it is determined that the newly added intermediate link service is untrustworthy, the key management service can add the newly added intermediate link service to the trusted execution environment, i.e., proceed to step S120. Conversely, if it is determined that the newly added intermediate link service is trustworthy, the key management service can send the client's private key to the intermediate link service, i.e., proceed to step S130.

[0058] Optionally, if it is determined that the intermediate link service sending the private key viewing request is not a newly added intermediate link service, the key management service can send the client's private key to the intermediate link service.

[0059] For example, a private key viewing request may include the identity information of the intermediate link service. If the key management service determines that the intermediate link service is a newly added intermediate link service based on the identity information of the intermediate link service, and if it determines that the newly added intermediate link service is untrusted, then the newly added intermediate link service will be added to the trusted execution environment.

[0060] As an example, when a client sends a cryptographic inference request to the cloud at the first moment, its corresponding intermediate link services include intermediate link service A, intermediate link service B, intermediate link service C, and intermediate link service D. When the client sends the same request again at the second moment, its corresponding intermediate link services include intermediate link service A, intermediate link service B, intermediate link service C, intermediate link service D, and intermediate link service E. Intermediate link service E is the one that requires plaintext. It is evident that the cloud-based inference framework is constantly changing; that is, its inference layer is dynamic rather than static. When the key management service receives a private key viewing request from intermediate link service E, it uses the identity information carried by the request to determine that intermediate link service E is a newly added intermediate link service, thus detecting a change in the inference link.

[0061] At this point, the key management service can further determine whether a remote proof report corresponding to the intermediate link service E exists in the trusted execution environment. If it is determined that a remote proof report corresponding to the newly added intermediate link service E exists in the trusted execution environment, then the intermediate link service E is determined to be trustworthy. Conversely, if it is determined that a remote proof report corresponding to the newly added intermediate link service E does not exist in the trusted execution environment, then the intermediate link service E is determined to be untrustworthy.

[0062] Understandably, the key management service may include a decryption detection module, which can be used to detect whether the intermediate link service is trustworthy. Optionally, the decryption detection module can also be used to detect whether the intermediate link service has changed / been updated, such as detecting whether there is a newly added intermediate link service that also requires plaintext among the multiple intermediate link services corresponding to the client. If detected, the key management service can further determine whether the newly added intermediate link service is a trustworthy intermediate link service.

[0063] As can be seen, the key management service can detect dynamic changes in intermediate link services, especially whether there are any new intermediate link services. If so, it can specifically test the security or trustworthiness of the intermediate link service, thereby enabling the entire inference link to meet high confidentiality requirements.

[0064] In another scenario, to ensure user data security, in response to the existence of a remote verification report corresponding to the intermediate link service within the trusted execution environment, the key management service can further determine whether registration information corresponding to the intermediate link service exists within the trusted execution environment, such as whether such registration information exists within the key management service itself. If it is determined that the registration information for the intermediate link service does not exist within the key management service, then the intermediate link service is deemed untrustworthy. Conversely, if it is determined that the registration information for the intermediate link service exists within the key management service, then the intermediate link service is deemed trustworthy.

[0065] It is evident that if the intermediate link service that sent the private key viewing request can provide a remote verification report, it can be further determined whether the corresponding registration information of the remote link service exists in the key management service, thus further ensuring the security of the user's private key.

[0066] For example, when the key management service receives a private key viewing request from intermediate link service D, it determines that intermediate link service D can provide a remote proof report. Based on this, the key management service can further obtain its service configuration information, which includes pre-registered secure intermediate link service information. By searching, it is determined that the service configuration information includes the registration information of intermediate link services A, B, and C, but does not include the registration information of intermediate link service D. At this time, the key management service can determine that intermediate link service D is untrusted and can reject the private key viewing request sent by intermediate link service D.

[0067] Optionally, the key management service can obtain a scan report of the intermediate link service and determine, based on the scan report, whether the intermediate link service to be verified has been authenticated. If it is determined that the intermediate link service has been scanned by a security scanning tool, then the intermediate link service to be verified is determined to be authenticated, and at this point, the intermediate link service can also be determined to be trustworthy. Additionally, the key management service can also determine whether the intermediate link service has vulnerabilities, in order to perform further security authentication on the intermediate link service.

[0068] Optionally, the intermediate link service responding to the private key viewing request can provide a remote verification report, and the key management service can further determine whether there is identity information related to the intermediate link service in the trusted execution environment, that is, whether the intermediate link service is deployed in the trusted execution environment. If it is determined that the intermediate link service is deployed in the trusted execution environment, then the intermediate link service is determined to be trustworthy.

[0069] For example, the key management service can obtain the category of the client that sent the private key viewing request, and search for intermediate link services belonging to the same category in the trusted execution environment. Then, it searches for the existence of identity information related to the intermediate link service among these intermediate link services of the same category. This not only ensures data security, but also speeds up the search rate of intermediate link services.

[0070] In summary, the key management service can verify the trustworthiness of the intermediate link service based on at least one verification method, such as whether the intermediate link service is a newly added intermediate link service, whether it can provide a remote proof report, whether it has corresponding registration information, whether it has been scanned, and whether it has vulnerabilities, so as to ensure that the security level of the intermediate link service is high enough.

[0071] As an example, when the key management service receives a private key viewing request from an intermediate link service, it can determine whether the intermediate link service is a newly added service requiring plaintext access. If it determines that the intermediate link service sending the private key viewing request is a newly added service, it then determines whether the newly added intermediate link service can provide a remote proof report. If it can provide a remote proof report, it further determines whether the key management service includes the relevant registration information for that intermediate link service. If it includes the corresponding registration information, the intermediate link service is deemed trustworthy. Otherwise, the intermediate link service is deemed untrustworthy.

[0072] As another example, when the key management service receives a private key viewing request from an intermediate link service, it can determine whether the intermediate link service is a newly added service requiring plaintext access. If it determines that the intermediate link service sending the private key viewing request is a newly added service, it then determines whether the newly added service can provide a remote proof report. If it can provide a remote proof report, it further determines whether the key management service includes the registration information related to the intermediate link service. If it includes the corresponding registration information and detects that the intermediate link service has been scanned without omissions, it determines that the intermediate link service is trustworthy. Otherwise, it determines that the intermediate link service is untrustworthy.

[0073] The above are just examples and are not intended to be limiting. The specific methods for determining whether an intermediate link service is trustworthy can be selected based on the actual situation, and will not be elaborated on here.

[0074] As an alternative approach, anomaly information of the key management service can be obtained based on the decryption detection module. On this basis, the target information corresponding to the intermediate link service can be found from the anomaly information, and the security information of the intermediate link service can be obtained based on the target information. Based on the security information, it can be further determined whether the intermediate link service is trustworthy.

[0075] When the key management service receives a private key viewing request from the intermediate link service and determines, based on the request, that a remote proof report corresponding to the intermediate link service does not exist in the trusted execution environment, it can either continue to determine the trustworthiness of the intermediate link service using other verification methods, or generate and store anomaly information. To ensure the accuracy of the intermediate link service verification, the key management service can retrieve the generated anomaly information from the storage space and search for the target information corresponding to the intermediate link service within it. Based on this, it analyzes the target information to determine the trustworthiness of the intermediate link service. Finally, it comprehensively determines whether the verification results obtained from the two methods are the same. If they are the same, the unified verification result is used as the target verification result. Otherwise, the result of the anomaly information analysis is used as the target verification result.

[0076] As an example, if the trustworthiness of intermediate link service A is determined by remote verification reports and registration information, and the trustworthiness of intermediate link service A is also determined by analyzing the anomaly information of key management service, then the target verification result is that intermediate link service A is trustworthy.

[0077] As another example, if the trustworthiness of intermediate link service A is determined through remote verification reports and registration information, but anomaly information from the key management service is determined to make intermediate link service A untrustworthy, the target verification result can be that intermediate link service A is untrustworthy. The main reason is that the anomaly information contains more complete information, thus allowing for more accurate security verification based on this.

[0078] Alternatively, when the two verification methods are not consistent, an untrusted result can be used as the target verification result, which can strictly guarantee the security of the intermediate link service.

[0079] In step S120, in response to determining that the intermediate link service is untrusted based on the private key viewing request, the intermediate link service is added to the trusted execution environment.

[0080] As an alternative approach, in response to the determination that the intermediate link service sending the private key viewing request is untrusted based on the private key viewing request, the intermediate link service can be added to the trusted execution environment. In other words, when the key management service detects that the intermediate link service is untrusted, it can be modified to be added to the trusted execution environment, switching it from an untrusted state to a trusted state.

[0081] For example, a trusted image of the intermediate link service is obtained, and the corresponding trusted image is deployed to the target resource of the trusted execution environment. Based on this, a remote verification report of the intermediate link service is obtained and verified. Upon successful verification, the intermediate link service is confirmed to have successfully joined the trusted execution environment, meaning the transformation of the intermediate link service is complete. By automatically transforming untrusted intermediate link services from an untrusted state to a trusted state, not only can the security of user data be guaranteed, but the efficiency of intermediate link service transformation can also be improved, reducing unnecessary costs associated with manual transformation.

[0082] The above-described process of adding the intermediate link service to the trusted execution environment (TEX) involves deploying the intermediate link service within the TEX. During deployment, a trusted image of the intermediate link service can be obtained first. For example, when obtaining the trusted image, a code metric can be generated first. This metric can be a unique hash value generated after compiling the intermediate link service. The subsequent remote authentication service can use this metric to detect whether the intermediate link service has been tampered with. Afterward, the service code, dependent libraries, and components required for the TEX runtime are packaged to obtain the trusted image.

[0083] After obtaining the trusted image, deployment operations can be performed, including requesting target resources and starting the corresponding instance to deploy the trusted image onto the target resources in the trusted execution environment. Additionally, when starting the instance, initialization information corresponding to the intermediate link service can be injected into the instance through user data or configuration management. Based on this, a remote verification report is obtained and verified. If the verification passes, the intermediate link service deployment is successful. Verifying the remote verification report can involve comparing the metrics in the report with pre-recorded baseline values, and can also verify the validity of the hardware signature.

[0084] In addition, after adding the intermediate link service to the trusted execution environment, communication tests can also be performed on the intermediate link service, such as determining whether the intermediate link service can maintain continuous and trusted communication with other trusted intermediate link services, and / or determining whether the intermediate link service can maintain continuous and trusted communication with the large model service. If it is detected that continuous and trusted communication cannot be maintained, an alarm message will be output.

[0085] Continuing with the example above, since both the second intermediate link service 202 and the fourth intermediate link service 204 are intermediate link services that require plaintext, and these two intermediate link services are newly added and unauthenticated intermediate link services, meaning that these two intermediate link services are untrusted, a decryption detection module is introduced to ensure the security of user data.

[0086] Here, the decryption detection module can be part of the key management service, or it can be independent of the key management service, as detailed below. Figure 3 As shown, the specific relationship between the key management service 305 and the decryption detection module 306 is not explicitly defined here; the choice can be made based on the actual situation. It should be noted that, similar to the key management service 305, the decryption detection module 306 is also deployed in a trusted execution environment to ensure data security.

[0087] The decryption detection module 306 can detect whether the entire inference chain undergoes dynamic changes. For example, it can detect whether any new intermediate link services requiring plaintext have been added. When a new intermediate link service is detected, and this new service requires plaintext, it can be modified to add the service to the trusted execution environment. For example, if both the second intermediate link service 202 and the fourth intermediate link service 204 meet the above conditions, after adding them to the trusted execution environment, their states become as follows: Figure 3 The trustworthy state is shown.

[0088] Optionally, if the key management service determines that the intermediate link service is untrusted through the decryption detection module, it can determine that the decryption has failed. In this case, on the one hand, it can generate an exception message indicating the decryption failure, and on the other hand, the key management service can also output a modification prompt message to the developers. This prompt message can instruct the developers to modify the untrusted intermediate link service so that it can be deployed in a trusted execution environment. In this process, automatic modification and manual modification can be combined.

[0089] In other words, alarm configuration information can be pre-configured in the key management service. During subsequent security testing, if information that meets the alarm conditions is detected, abnormal information can be output, which may include alarm information.

[0090] As an alternative approach, when the key management service determines that an intermediate link service is untrusted, it can generate anomaly information. During this generation, a specified error identifier can be added to the anomaly information. Subsequent analysis of this anomaly information to identify target information allows the key management service to filter the anomaly information based on this specified error identifier. In other words, upon receiving anomaly information from the key management service, logs containing the specified error identifier can be filtered out and used as target information. Based on this, target information meeting the above conditions can be uniformly processed—that is, the untrusted intermediate link services involved in these target information can be uniformly processed to deploy them in a trusted execution environment.

[0091] It should be noted that immutable logs can be generated during the process of adding the intermediate link service to the trusted execution environment, allowing users to easily review the modification process later. Furthermore, the client involved in the above technical solution can be a test client, and the encrypted inference request can be an encrypted test request input by testers. That is, the security verification method for the large model service can be executed before the large model service goes live. Complete testing ensures that users meet the data security requirements before the service goes live, preventing unexpected key acquisition by the intermediate link service during online deployment, thereby improving the security of the confidential large model service.

[0092] Optionally, the client can also be an actual user terminal, and the encrypted inference request can be an encrypted inference request input by the actual user according to their needs. That is, the security verification method of the above-mentioned large model service can be executed after the large model service goes online, and the security of user data can be guaranteed through continuous detection.

[0093] As an alternative approach, after adding the intermediate link service to the trusted execution environment, test requests can be generated for the added intermediate link service, and the security of the newly added intermediate link service can be tested specifically based on these test requests.

[0094] Additionally, the intermediate link service integrated into the trusted execution environment can use the SDK provided by the key management service. This SDK can obtain the remote proof report of the intermediate link service within the trusted execution environment, enabling communication with the key management service. In other words, the remote proof report corresponding to the intermediate link service can be used when communicating with the key management service. Therefore, the software SDK can be pre-built before performing security verification.

[0095] Understandably, if the intermediate link service wants to obtain the plaintext service, i.e., request the client's private key, it needs to access the key management service. This is primarily because the user's key (the client's private key) is stored in the key management service. To better illustrate the above process, the following is given: Figure 4 The example diagram shown is based on Figure 4 As can be seen, the key management service can be pre-configured with alarm information. This alarm information can be related to abnormal requests. For example, if a certain intermediate link service is not joined to the trusted execution environment, it can output alarm information when sending a private key viewing request, thus generating exception information. Additionally, a software SDK can be pre-built. If a certain intermediate link service needs to request the client's private key, it can access the key management service through this SDK to request the client's private key.

[0096] In the technical solution, the security verification method for the large model service can be applied to testing scenarios. For example, end-to-end encrypted load testing can be performed intermittently to detect whether any new intermediate link services requiring plaintext have appeared in the inference chain, and to detect whether the key management service outputs alarms. Here, alarms can be output by the key management service when it detects an untrusted intermediate link service, or they can be output as anomaly information. Furthermore, alarms can be handled automatically by the key management service or manually; regardless of whether they are handled automatically or manually, immutable logs can be generated for easy traceability.

[0097] The generated abnormal information can be filtered to locate the target information. Based on this, the intermediate link services related to the target information can be modified, that is, the deployment and configuration of the intermediate link services can be modified to add them to the trusted execution environment.

[0098] In step S130, in response to determining that the intermediate link service is trustworthy based on the private key viewing request, the client's private key is sent to the intermediate link service.

[0099] As an optional approach, if the intermediate link service is deemed trustworthy based on the private key viewing request, the client's private key can be sent to the intermediate link service. The intermediate link service can then decrypt the client's private key viewing request based on this private key. For example, the intermediate link service can perform a decryption operation based on the client's private key sent by the key management service to obtain the session key for the encrypted content. Then, the intermediate link service can decrypt the plaintext sent by the client using this session key to obtain the plaintext request. Based on this, the intermediate link service can send the plaintext request to the large model service, which will then perform inference operations based on the plaintext request to obtain the inference result. In other words, the intermediate link service can receive the inference result sent by the large model service, encrypt the inference result, and return the encrypted result to the client.

[0100] The aforementioned large model service can adopt, for example... Figure 5 The PD (Prefill Decode) architecture shown is based on Figure 5As can be seen, the PD architecture can include multiple large model instances for prefilling and decoding stages to handle inference requests. The controller receives inference requests and, based on current system load and resource usage, appropriately distributes them to the large model instances responsible for the prefilling stages. During the prefilling stage, parallel computation can be performed using a parallel runtime in conjunction with multiple GPUs (Graphics Processing Units) to improve the inference speed of the large model instances.

[0101] The initialization results generated in the pre-filling stage (such as attention cache) can be passed to the large model instance responsible for the decoding stage as key-value pair data (KV Cache). The large model instance responsible for the decoding stage can then gradually generate the final output text sequence based on the initialization results from the pre-filling stage. Furthermore, during the decoding stage, parallel computation using multiple GPUs can be employed to improve the inference speed of the large model instance.

[0102] It should be noted that multiple large model instances responsible for the pre-filling stage and multiple large model instances responsible for the decoding stage can be deployed on different nodes. Furthermore, Figure 5 The distributed large model service shown is only for illustrative purposes. In real-world applications, other types of distributed architectures can also be used for distributed large model services, and no specific limitations are made here.

[0103] The following is in conjunction with the appendix Figure 6 The above-described embodiments will be described in detail.

[0104] Figure 6 This is an interactive example diagram illustrating a security verification method for a large model service according to an exemplary embodiment.

[0105] based on Figure 6 It is known that the client can obtain its public key from the key management service through the intermediate link service. Specifically, when the key management service receives a public key request from the client forwarded by the intermediate link service, it can return the client's public key to the intermediate link service, which then distributes the client's public key to the client. Based on this, the client can use the received public key and a temporarily generated private key to generate a session key ciphertext.

[0106] Therefore, when the intermediate link service receives an encrypted inference request, if it needs plaintext, it needs to send a private key viewing request to the key management service. That is, the key management service can receive private key viewing requests from the intermediate link service, which are used to request the client's private key. At this point, the key management service can determine whether the intermediate link service is trustworthy, such as whether the intermediate link service sending the private key viewing request has a corresponding remote proof report. If it is determined to exist, the key management service can distribute the client's stored private key to the intermediate link service. Subsequently, the intermediate link service can decrypt the session ciphertext of the dialogue content using this private key. Based on this ciphertext, it can obtain the plaintext request sent by the client. After sending the plaintext request to the large model service, it can obtain the plaintext inference result. After receiving the inference result, the intermediate link service can encrypt it using the public and private keys to obtain the encrypted result. Finally, the client can decrypt the encrypted result to obtain the final inference result. It is evident that throughout the entire inference process, user data remains secure, and the possibility of it being obtained without authorization is extremely small.

[0107] Optionally, when it is determined that the intermediate link service is untrusted, the key management service can add the untrusted intermediate link service to the trusted execution environment. That is, the newly added intermediate link service that requires plaintext can be modified. Based on this, when a private key viewing request related to the intermediate link service is received, the client's private key can be obtained and the private key can be sent to the corresponding intermediate link service.

[0108] It should be noted that, in order to further ensure the security of the client's private key, the client's private key can be automatically rotated periodically to ensure that it is unusable after being forwarded without authorization. For example, the client's private key can be updated irregularly, and the rotation time can be adjusted according to the user's level of privacy requirements during the update process. For example, the higher the user's level of privacy requirements, the shorter the corresponding rotation time, and vice versa.

[0109] For example, the privacy requirement level of a user can be obtained, the corresponding rotation duration can be determined, and based on this, the client's private key can be automatically rotated according to the rotation duration. The privacy requirement level and the rotation duration are inversely correlated.

[0110] Optionally, the key management service can restrict the intermediate link service from forwarding the client's private key, such as by detecting private key forwarding operations. Additionally, for services in a trusted execution environment, code metrics can be performed periodically to ensure the security of the intermediate link service.

[0111] Furthermore, network isolation can be implemented for multiple intermediate link services, i.e., network isolation control, to prevent unauthorized forwarding of client private keys between intermediate link services, thereby preventing the unauthorized acquisition of client private keys through intermediate link services. Optionally, a Data Loss Protection (DLP) mechanism can be specified to inspect data related to intermediate link services to further ensure user data security. For example, it can detect whether intermediate link services exhibit abnormal traffic behavior. If abnormal traffic behavior is found, the intermediate link service can be subject to focused inspection, or a prompt message can be output. Moreover, services in a trusted execution environment have verifiable security records throughout the entire invocation process, which can greatly reduce the risk of client keys being leaked.

[0112] It should be noted that for newly added intermediate link services, targeted security checks can be performed on them. For example, the security of the intermediate link service can be verified at preset intervals. The preset interval can be dynamically adjusted based on the results of the security verification and the time spent in the trusted environment. For example, the better the security verification results and / or the longer the time spent in the trusted execution environment, the shorter the corresponding preset interval can be. The specific method for adjusting this interval is not explicitly limited here and can be adjusted according to the actual situation, which will not be elaborated here.

[0113] When the key management service receives a private key viewing request from the intermediate link service, if it determines that the intermediate link service is untrusted based on the request, it adds the untrusted intermediate link service to the Trusted Execution Environment (TEE). The private key viewing request is sent by the intermediate link service upon receiving a cryptographic inference request from the client. This request instructs the service to view the client's private key. If the intermediate link service is deemed trustworthy based on the request, it sends the client's private key to the intermediate link service. By detecting the trustworthiness of the intermediate link service and adding it to the TEE when it is determined to be untrustworthy, user data can be prevented from being illegally intercepted at the intermediate link service, thus greatly ensuring user data security. Furthermore, this technical solution can more effectively detect the deployment status of the cloud-based confidential inference service, ensuring the security of the link during the engineering iteration process of the trusted confidential inference service. This can, to some extent, prevent unexpected situations from occurring during continuous iteration and operation, such as plaintext keys appearing in a non-TEE environment, leading to user data loss or misuse.

[0114] Figure 7 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 7As shown, the technical solution provides a security verification device 700 for large model services. The security verification device 700 for large model services may include a receiving module 710, a joining module 720, and a sending module 730.

[0115] The receiving module 710 is configured to receive a private key viewing request sent by an intermediate link service based on a key management service. The private key viewing request is sent by the intermediate link service when it receives a cryptographic inference request sent by a client. The private key viewing request indicates that the client's private key should be viewed. The addition module 720 is configured to add the intermediate link service to the trusted execution environment in response to determining that the intermediate link service is untrusted based on the private key viewing request. The sending module 730 is configured to send the client's private key to the intermediate link service in response to determining that the intermediate link service is trustworthy based on the private key viewing request.

[0116] In some implementations, the security verification device 700 for large model services may further include: The determination module is configured to determine that the intermediate link service is untrusted in response to the absence of a remote authentication report corresponding to the intermediate link service.

[0117] In some implementations, the determining module is further configured to determine that the intermediate link service is untrusted in response to the existence of a remote proof report corresponding to the intermediate link service and the absence of registration information corresponding to the intermediate link service in the key management service.

[0118] In some implementations, the joining module 720 is further configured to obtain a trusted image of the intermediate link service, deploy the trusted image to a target resource of the trusted execution environment; obtain a remote proof report of the intermediate link service, verify the remote proof report; and, in response to the verification being passed, determine that the intermediate link service has successfully joined the trusted execution environment.

[0119] In some implementations, the private key viewing request is sent by the intermediate link service when it determines that the cryptographic inference request carries a specified identifier.

[0120] In some implementations, the private key viewing request includes the identity information of the intermediate link service, and the joining module 720 is further configured to add the newly added intermediate link service to the trusted execution environment in response to determining, based on the identity information, that the intermediate link service is a newly added intermediate link service and that the newly added intermediate link service is untrusted.

[0121] In some implementations, the key management service includes a decryption detection module, and the determination module is further configured to obtain abnormal information of the key management service based on the decryption detection module; search for target information corresponding to the intermediate link service from the abnormal information; obtain security information of the intermediate link service based on the target information; and determine whether the intermediate link service is trustworthy based on the security information.

[0122] In the technical solution, when the key management service receives a private key viewing request from the intermediate link service, it determines that the intermediate link service is untrusted based on the private key viewing request. Then, the key management service adds the untrusted intermediate link service to the trusted execution environment. The private key viewing request is sent by the intermediate link service when it receives a cryptographic inference request from the client. This request instructs the service to view the client's private key. In response to determining that the intermediate link service is trustworthy based on the private key viewing request, the service sends the client's private key to the intermediate link service. By detecting whether the intermediate link service is trustworthy and adding it to the trusted execution environment when it is determined to be untrustworthy, the illegal interception of user data at the intermediate link service can be prevented, thus greatly ensuring the security of user data.

[0123] The following is for reference. Figure 8 The diagram illustrates a structural schematic of an electronic device 800 suitable for implementing the above-described technical solution. The terminal device may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Tablet Personal Computers), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs (Televisions), desktop computers, etc. Figure 8 The electronic device shown is merely an example and should not be construed as limiting its functionality or scope of use.

[0124] like Figure 8As shown, the electronic device 800 may include a processing unit 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage device 808 into a random access memory (RAM) 803. The random access memory 803 also stores various programs and data required for the operation of the electronic device 800. The processing unit 801, the read-only memory 802, and the random access memory 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0125] Typically, the following devices can be connected to the input / output interface 805: input devices 806 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 807 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 808 including, for example, magnetic tape, hard disk, etc.; and communication devices 809. Communication device 809 allows electronic device 800 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 An electronic device 800 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.

[0126] In particular, depending on certain circumstances, the process described in the above-referenced flowchart can be implemented as a computer software program. For example, a computer program product is provided, 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 flowchart. This computer program can be downloaded and installed from a network via a communication device 809, or installed from a storage device 808, or installed from a read-only memory 802. When the computer program is executed by the processing device 801, it performs the functions defined in the above-described method.

[0127] It should be noted that the aforementioned computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may 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 disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In one case, a computer-readable storage medium may 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 another case, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also 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.

[0128] In some implementations, clients and servers 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.

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

[0130] The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: receive a private key viewing request sent by an intermediate link service based on a key management service, wherein the private key viewing request is sent by the intermediate link service upon receiving a cryptographic inference request sent by a client, and the private key viewing request instructs the viewing of the client's private key; in response to determining that the intermediate link service is untrusted based on the private key viewing request, add the intermediate link service to a trusted execution environment; and in response to determining that the intermediate link service is trustworthy based on the private key viewing request, send the client's private key to the intermediate link service.

[0131] Computer program code for performing the above operations can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include, but are not limited to, object-oriented programming languages, as well as conventional procedural 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).

[0132] The flowcharts and block diagrams in the accompanying figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products under various scenarios. In this respect, 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 the 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 figures. 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.

[0133] The modules mentioned above can be implemented in software or hardware. In some cases, the name of a module does not necessarily limit its functionality; for example, a receiving module can also be described as "a module that receives private key viewing requests sent by an intermediate link service based on the key management service."

[0134] The functions described above 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 Parts (ASSPs), Systems on Chips (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0135] In this context, 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 fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0136] The above description is merely illustrative and explains the technical principles employed. Those skilled in the art should understand that the scope of the technical solution is not limited to specific combinations of the above-described technical features, but also includes other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features provided herein that have similar functions.

[0137] 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. Multitasking and parallel processing may be advantageous in certain environments. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limitations on the scope of the technical solution. Certain features described in the context of a single example can also be implemented in combination in a single example. Conversely, various features described in the context of a single example can also be implemented individually or in any suitable sub-combination in multiple examples.

Claims

1. A security verification method for large model services, comprising: The key management service receives a private key viewing request sent by the intermediate link service. The private key viewing request is sent by the intermediate link service when it receives a cryptographic inference request sent by the client. The private key viewing request indicates that the client's private key should be viewed. In response to determining that the intermediate link service is untrusted based on the private key viewing request, the intermediate link service is added to the trusted execution environment; In response to determining that the intermediate link service is trustworthy based on the private key viewing request, the client's private key is sent to the intermediate link service.

2. The security verification method for large model services according to claim 1, further comprising: In response to the absence of a remote verification report corresponding to the intermediate link service, the intermediate link service is determined to be untrusted.

3. The security verification method for large model services according to claim 1, the method further includes: In response to the existence of a remote verification report corresponding to the intermediate link service, and the absence of registration information corresponding to the intermediate link service in the key management service, the intermediate link service is determined to be untrusted.

4. The security verification method for large model services according to claim 1, wherein adding the intermediate link service to the trusted execution environment includes: Obtain a trusted image of the intermediate link service and deploy the trusted image to the target resource of the trusted execution environment; Obtain the remote proof report of the intermediate link service and verify the remote proof report; Upon successful verification, it is determined that the intermediate link service has successfully joined the trusted execution environment.

5. The security verification method for large model services according to claim 1, wherein the private key viewing request is sent by the intermediate link service when it determines that the encrypted inference request carries a specified identifier.

6. The security verification method for large model services according to claim 1, wherein the private key viewing request includes the identity information of the intermediate link service, and the method further includes: In response to determining, based on the identity information, that the intermediate link service is a newly added intermediate link service and that the newly added intermediate link service is untrusted, the newly added intermediate link service is added to the trusted execution environment.

7. The security verification method for large model services according to claim 1, wherein the key management service includes a decryption detection module, and the method further includes: Based on the decryption detection module, obtain abnormal information about the key management service; Find the target information corresponding to the intermediate link service from the anomaly information; Based on the target information, obtain the security information of the intermediate link service, and determine whether the intermediate link service is trustworthy based on the security information.

8. A security verification device for a large model service, comprising: The receiving module is configured to receive a private key viewing request sent by the intermediate link service based on the key management service. The private key viewing request is sent by the intermediate link service when it receives a cryptographic inference request sent by the client. The private key viewing request indicates that the client's private key should be viewed. The module is configured to add the intermediate link service to the trusted execution environment in response to determining that the intermediate link service is untrusted based on the private key viewing request. The sending module is configured to send the client's private key to the intermediate link service in response to determining that the intermediate link service is trustworthy based on the private key viewing request.

9. A computer-readable medium having a computer program stored thereon, wherein, When executed by a processing device, the computer program performs the steps of the method according to any one of claims 1-7.

10. An electronic device, comprising: 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-7.

11. A computer program product comprising a computer program, wherein, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1-7.

Images