End-cloud interaction method and device, computer program product

Abstract

Embodiments of the present application disclose an end-cloud interaction method and device, and a computer program product. The method comprises: sending a proof report to a terminal device, the proof report being used to indicate whether a condition for encrypted data transmission between a cloud server and the terminal device is met; receiving user request information sent by the terminal device, the user request information being request information encrypted in a trusted execution environment of the terminal device; performing decryption processing on the user request information to obtain plaintext data; performing processing on the plaintext data to obtain target reply information, and sending the target reply information to the terminal device. The security of data transmission in an artificial intelligence reasoning scenario can be improved.

Description

Technical Field

[0001] This application relates to secure interaction technology, including but not limited to a cloud-edge interaction method and device, and a computer program product. Background Technology

[0002] Currently, in edge-cloud collaboration scenarios, encrypted transmission is typically used to protect data security when terminal devices and cloud servers interact. After receiving a request from the terminal device, the cloud server performs corresponding business processing and returns the processing result. Existing edge-cloud interaction solutions mainly focus on encryption protection during data transmission and the cloud server's routine processing flow for request information.

[0003] However, in existing solutions, when cloud servers receive request information from terminal devices, they assume that their own operating environment is secure and trustworthy. This approach ignores the potential security risks inherent in the cloud server's operating environment itself, such as server system tampering or malware infection. This could result in encrypted request information sent by terminal devices being processed in an untrusted environment, posing a risk of data leakage or tampering with processing results. Summary of the Invention

[0004] In view of this, the edge-cloud interaction method, device, and computer program product provided in this application can improve the security of data transmission in artificial intelligence inference scenarios. The edge-cloud interaction method, cloud server, and terminal device provided in this application are implemented as follows: One aspect of this application provides a cloud-edge interaction method applied to a cloud server, wherein the cloud server and a terminal device are communicatively connected, and the method includes: A verification report is sent to the terminal device, which indicates whether the conditions for encrypted data transmission are met between the cloud server and the terminal device. Receive user request information sent by the terminal device. The user request information is encrypted in the trusted execution environment of the terminal device. The user request information is decrypted to obtain plaintext data; The plaintext data is processed to obtain the target response information, which is then sent to the terminal device.

[0005] Another aspect of this application provides a terminal-cloud interaction method, applied to a terminal device, wherein the terminal device is communicatively connected to a cloud server, the method comprising: Send a verification request to the cloud server; Receive the verification report returned by the cloud server. The verification report is generated by the cloud server in response to the verification request. The verification report is used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device. Send user request information to the cloud server. The user request information is encrypted in the trusted execution environment of the terminal device. The target response information is sent by the receiving server. The target response information is the information obtained by the cloud server after decrypting the user's request information to obtain plaintext data and then processing the plaintext data.

[0006] In another aspect of the embodiments of this application, an end-to-cloud interaction device is provided, which is applied to a cloud server and communicates with a terminal device. The device includes: a sending module, a first receiving module, a processing module, and a reply module. The sending module is used to send a verification report to the terminal device. The verification report is used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device. The first receiving module is used to receive user request information sent by the terminal device under the condition that the integrity and trust requirements are met in the operating environment of the cloud server. The user request information is the request information encrypted in the trusted execution environment of the terminal device. The processing module is used to decrypt user request information to obtain plaintext data; The response module is used to process plaintext data, obtain the target response information, and send the target response information to the terminal device.

[0007] In another aspect of the embodiments of this application, an end-to-cloud interaction device is provided, which is applied to a terminal device and communicates with a cloud server. The device includes: a request module and a second receiving module. The request module is used to send a proof request to the cloud server; The second receiving module is used to receive the proof report returned by the cloud server. The proof report is generated by the cloud server in response to the proof request and is used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device. The request module is also used to send user request information to the cloud server when the integrity and trust requirements are met in the cloud server's operating environment. The user request information is encrypted in the trusted execution environment of the terminal device. The second receiving module is also used to receive target response information sent by the server. The target response information is the information obtained by the cloud server after decrypting the user request information to obtain plaintext data and then processing the plaintext data.

[0008] The cloud server provided in this application includes a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements the method of this application.

[0009] The terminal device provided in this application includes a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement the method of this application.

[0010] The computer-readable storage medium provided in this application embodiment stores a computer program thereon, which, when executed by a processor, implements the method provided in this application embodiment.

[0011] The end-to-cloud interaction method, cloud server, and terminal device provided in this application embodiment can send a verification report to the terminal device. The verification report indicates whether the conditions for encrypted data transmission are met between the cloud server and the terminal device. The method receives user request information sent by the terminal device, which is encrypted within the trusted execution environment of the terminal device. The user request information is decrypted to obtain plaintext data. The plaintext data is then processed to obtain the target response information, which is then sent to the terminal device. Before receiving the user request information from the terminal device, the cloud server ensures that its operating environment meets integrity and trust requirements, guaranteeing that the cloud environment for processing user request information is trustworthy. Based on this, it receives the encrypted user request information from the terminal device within the trusted execution environment, achieving dual trust assurance on both the terminal and cloud sides. By decrypting the user request information to obtain plaintext data, processing the plaintext data to obtain the target response information, and then sending it to the terminal device, end-to-end trusted data interaction is completed. This ensures that the encrypted request information from the terminal device is only received and processed when the cloud server is in a trusted state, thus guaranteeing end-to-end security of data from the terminal's transmission to the cloud's processing during the entire end-to-cloud interaction process. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram illustrating the application scenario provided in the embodiments of this application; Figure 2 This is a schematic diagram of the cloud-side process of the end-to-cloud interaction method provided in the embodiments of this application; Figure 3This is a schematic diagram of the terminal-side process of the terminal-cloud interaction method provided in the embodiments of this application; Figure 4 This is an interactive schematic diagram of the end-to-cloud interaction method provided in the embodiments of this application; Figure 5 This is a schematic diagram illustrating the complete inference request process of the end-to-cloud interaction method provided in the embodiments of this application; Figure 6 This is a flowchart illustrating the encryption and decryption process provided in the embodiments of this application; Figure 7 This is a flowchart illustrating the initialization process before encryption and decryption and the remote verification process provided in the embodiments of this application; Figure 8 This is a flowchart illustrating the measurement and proof process provided in the embodiments of this application; Figure 9 This is a schematic diagram illustrating the process of verification between the terminal device and the verification party provided in the embodiments of this application; Figure 10 This is a schematic diagram of the malicious behavior monitoring process provided in the embodiments of this application; Figure 11 This is a schematic diagram of the cloud-side structure of the end-to-cloud interaction device provided in the embodiments of this application; Figure 12 This is a schematic diagram of the terminal-side structure of the terminal-cloud interaction device provided in the embodiments of this application; Figure 13 This is a schematic diagram of the structure of the cloud server provided in the embodiments of this application; Figure 14 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. Detailed Implementation

[0014] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the specific technical solutions of this application will be further described in detail below with reference to the accompanying drawings of the embodiments of this application. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application.

[0015] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0016] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0017] It should be noted that the terms "first, second, third" used in the embodiments of this application are used to distinguish similar or different objects and do not represent a specific order of objects. It can be understood that "first, second, third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0018] The following is a detailed explanation of an application scenario provided in the embodiments of this application.

[0019] Figure 1 This is a schematic diagram of the application scenario provided in the embodiments of this application. Please refer to it. Figure 1 In this application scenario, it may include terminal device 110, cloud server 120, and verification party 130.

[0020] The terminal device 110 can be an electronic device with artificial intelligence inference requirements, such as a smartphone, tablet, personal computer, wearable device, or IoT terminal. The terminal device 110 internally houses a Trusted Execution Environment (TEE), a hardware-isolated secure zone that protects internally running applications and sensitive data from theft or tampering even if the operating system is compromised. For example, the TEE can be implemented using TrustZone technology based on the ARM architecture or Intel SGX (Software Protection Extensions) technology; no specific limitations are specified here.

[0021] Terminal device 110 includes artificial intelligence applications, trusted transmission channels, and trusted execution environments.

[0022] Among them, artificial intelligence applications can be applications running on terminal devices, responsible for initiating AI inference requests and interacting with the cloud through a secure communication link.

[0023] A trusted transmission channel can establish a trusted connection with the cloud environment, remotely verify the security and trustworthiness of the cloud environment, and ensure the security of the transmission process.

[0024] Trusted execution environments can provide an isolated and secure execution space for artificial intelligence applications, protecting sensitive data and code from malware attacks.

[0025] The cloud server 120 can be a standalone physical server, a server cluster consisting of multiple servers, or a cloud-native application platform running in a containerized manner. The cloud server 120 establishes a communication connection with the terminal device 110 via a wireless or wired network. Internally, the cloud server comprises a host layer, a virtualization layer, and an application layer. The host layer includes a physically trusted platform module or a secure virtual trusted platform module, which is a hardware-level root of trust chip capable of securely storing keys, platform configuration register values, and proof key certificates. The virtualization layer includes a virtual trusted platform module, client agents, and proven Kubernetes nodes. The application layer includes proven container groups, artificial intelligence applications, model files, and data files.

[0026] The terminal device and the cloud server use HTTPS encryption; at the same time, business layer encryption is added on the basis of HTTPS encryption to ensure the confidentiality and integrity of end-to-end data.

[0027] Cloud servers include several core components, such as virtual machine environments, trusted computing components, trusted devices, and containers.

[0028] The virtual machine environment can be a K8s node, which is a virtual machine running on the host. The "Attested" label indicates that its integrity has been verified, and it serves as a K8s node to host artificial intelligence inference services.

[0029] Trusted computing components can include Kubernetes components, responsible for integrity measurements of Kubernetes nodes and containers, ensuring that nodes and containers have not been tampered with; interacting with agents to provide trust roots to containers. They can also perform neural network inference, with a trusted convolutional neural network inference engine working in collaboration with agents to execute artificial intelligence inference, enabling the detection and analysis of malicious program behavior. Furthermore, they can act as agents, coordinating interactions with trusted devices and transmitting integrity measurement information to various components.

[0030] Trusted devices can include virtual trusted platform modules, which are virtual trusted platform modules within virtual machines that provide platform functionality for Kubernetes nodes, supporting key management, encryption operations, and integrity measurements. They can also include physical / secure trusted platform modules, which are hardware roots of trust, providing secure key storage and encryption functions, performing platform integrity measurements, and ensuring security during startup and runtime environments.

[0031] Artificial intelligence applications can run within containers, securely operating in an isolated environment to handle user inference requests. They can also include models and data, including the data resources required for inference, protected through integrity verification.

[0032] Verifier 130 can be the terminal device 110 itself, a trusted third-party institution independent of the terminal device 110 and the cloud server 120, or a decentralized verification network based on blockchain technology. Verifier 130 is used to receive the proof report forwarded by the terminal device 110, independently verify the signature, platform configuration register value, and integrity of the trust chain in the proof report, and generate a verification result to return to the terminal device 110.

[0033] exist Figure 1 In the illustrated application scenario, terminal device 110 first sends a verification request to cloud server 120. Responding to this verification request, cloud server 120 reads the platform configuration register value from the physical trusted platform module or secure virtual trusted platform module at the host layer and the virtual trusted platform module at the virtualization layer, signs it using the verification key, generates a verification report, and returns it to terminal device 110. Terminal device 110 sends the verification report to verifier 130, who returns the verification result after completing the verification. If the verification result indicates that the operating environment of cloud server 120 meets the integrity and trust requirements, terminal device 110 encrypts the original request information in the trusted execution environment, generates user request information, and sends it to cloud server 120 through an encrypted channel. Upon receiving the user request information, cloud server 120 decrypts it to obtain plaintext data, performs artificial intelligence reasoning on the plaintext data to obtain the target response information, and then returns it to terminal device 110 through an encrypted channel.

[0034] In this scenario, it could be a process where a user uses artificial intelligence to ask a question. The plaintext data could be text, images, files, or other content entered by the user. After the encryption and decryption processes described above, the reasoning model configured on the cloud server, such as a large language model, can perform reasoning. The reasoning result can be a response to the plaintext data, which is the target response information mentioned above. This target response information can be sent back to the terminal device, allowing the user to receive an answer from the artificial intelligence.

[0035] The following section will explain the specific implementation process of the end-to-cloud interaction method provided in the embodiments of this application, taking into account the above application scenarios.

[0036] Figure 2 This is a schematic diagram of the cloud-side process of the edge-cloud interaction method provided in the embodiments of this application. Please refer to... Figure 2 An edge-cloud interaction method is applied to a cloud server, where the cloud server and a terminal device communicate and connect. The method includes: S210: Send a certification report to the terminal device.

[0037] The certification report is used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device.

[0038] It should be noted that the certification report is a digital document generated by the cloud server that contains integrity measurement information of its operating environment. This report is used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device.

[0039] Specifically, the core function of the verification report is to enable terminal devices to independently verify the trusted status of cloud servers. The verification report contains tiered metrics of the cloud server, starting from the hardware root of trust, passing through the virtualization layer, and down to the application layer, along with the digital signatures of these metrics. Upon receiving the verification report, the terminal device can verify the signatures and compare the metrics to confirm whether the cloud server's operating environment meets the predetermined integrity and trust requirements. Only when these conditions are met will the terminal device continue to send encrypted user request information to the cloud server; otherwise, the terminal device will refuse communication or attempt to connect to other trusted servers.

[0040] S220: Receive user request information sent by the terminal device.

[0041] The user request information is encrypted within the trusted execution environment of the terminal device.

[0042] It should be noted that the integrity requirement refers to the consistency between the system software, firmware, configuration parameters, and application hash values ​​of the cloud server and their expected values, indicating that they have not been maliciously tampered with or replaced. The trustworthiness requirement refers to the ability of the cloud server's hardware root of trust (such as a physical trusted platform module or a secure virtual trusted platform module) to provide verifiable evidence that the integrity measurement process of the operating environment is genuine, reliable, and has not been bypassed.

[0043] In practice, the cloud server can first prove the integrity and trustworthiness of its operating environment to the terminal device through a remote verification mechanism. The specific implementation of this remote verification mechanism can be as follows: the cloud server reads the platform configuration register values ​​from the physical trusted platform module, the secure virtual trusted platform module, and the virtual trusted platform module, signs them using the verification key, generates a verification report, and sends it to the terminal device. After the terminal device verifies the verification report itself or through a verifier, confirming that the cloud server's operating environment meets the integrity and trustworthiness requirements, it then sends the user request information to the cloud server.

[0044] For example, in one use case, the terminal device is a smartphone, and the cloud server is an AI inference service platform deployed on a public cloud. The user opens an AI-powered photo editing application on the phone, which first triggers a remote authentication process. The cloud server sends its integrity verification reports for both the host layer and virtualization layer to the phone. After the phone verifies the cloud server's operating environment by using its built-in verification module or requesting verification from a third-party verification service, it confirms that the cloud server's operating environment is secure and trustworthy. Subsequently, the phone sends the encrypted user request information within the trusted execution environment to the cloud server.

[0045] User request information is encrypted within the Trusted Execution Environment (TEE) of the terminal device. The TEE is a secure, isolated area within the terminal device that ensures the confidentiality and integrity of code executed and data accessed within it. Encryption can be performed using symmetric encryption algorithms (such as the Advanced Encryption Standard (AES)) or asymmetric encryption algorithms; no specific restrictions are specified here.

[0046] S220: Decrypt the user request information to obtain plaintext data.

[0047] After receiving a user request, the cloud server decrypts the request using the decryption algorithm and key corresponding to the encryption used by the terminal device. The decryption operation can be performed within the cloud server's trusted execution environment, or it can be accomplished by the cloud server calling a hardware security module or a virtual trusted platform module; no specific restrictions are imposed here.

[0048] For example, after the cloud server receives the encrypted photo data sent by the terminal device, it uses the pre-stored server private key and the temporary public key contained in the user request information to calculate the shared key through a key exchange algorithm, then uses the shared key to derive the decryption key, and finally uses the decryption key to decrypt the encrypted ciphertext to obtain the original plaintext photo data.

[0049] S230: Process the plaintext data to obtain the target response information, and send the target response information to the terminal device.

[0050] The cloud server performs artificial intelligence inference processing on the decrypted plaintext data. This AI inference processing can include, but is not limited to, computational operations based on deep learning models such as image recognition, speech recognition, natural language processing, object detection, and image generation. The cloud server then sends the inference result, obtained after processing, back to the terminal device as the target response information via an encrypted channel (e.g., an encrypted connection based on the Transport Layer Security (TLS) protocol).

[0051] For example, the cloud server runs an AI-powered image editing model on the decrypted photo data. This model could be a convolutional neural network used for operations such as beautifying faces, blurring backgrounds, or removing objects. The cloud server then sends the edited photo data back to the mobile phone via an encrypted channel as the target response. The terminal device decrypts and displays the editing result in a trusted execution environment.

[0052] The end-to-cloud interaction method provided in this application embodiment can send a proof report to the terminal device. The proof report indicates whether the conditions for encrypted data transmission are met between the cloud server and the terminal device. The method receives user request information sent by the terminal device, which is encrypted within the trusted execution environment of the terminal device. The user request information is decrypted to obtain plaintext data. The plaintext data is then processed to obtain the target response information, which is then sent to the terminal device. Before receiving the user request information from the terminal device, the cloud server ensures that its operating environment meets integrity and trust requirements, guaranteeing that the cloud environment for processing the user request information is trustworthy. Based on this, the cloud server receives the encrypted user request information from the terminal device within the trusted execution environment, achieving dual trust assurance on both the terminal and cloud sides. By decrypting the user request information to obtain plaintext data, processing the plaintext data to obtain the target response information, and then sending it to the terminal device, end-to-end trusted data interaction is completed. This ensures that the encrypted request information from the terminal device is only received and processed when the cloud server is in a trusted state, thereby guaranteeing end-to-end data security from the terminal's transmission to the cloud's processing during the entire end-to-cloud interaction process.

[0053] The following explanation will focus on the specific implementation process of the end-to-cloud interaction method provided in this application embodiment from the perspective of the terminal device.

[0054] Figure 3 This is a schematic diagram of the terminal-side process of the terminal-cloud interaction method provided in the embodiments of this application. Please refer to... Figure 3 An edge-cloud interaction method is applied to a terminal device, which communicates with a cloud server. The method includes: S310: Send a verification request to the cloud server.

[0055] S320: Receive the verification report returned by the cloud server.

[0056] The proof report is generated by the cloud server in response to the proof request, and it is used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device.

[0057] It's important to note that the verification request is the initiating message of the remote verification process by the terminal device. Before sending the user request information to the cloud server, the terminal device first sends a verification request to verify the cloud server's trustworthiness. The verification request may include a challenge nonce and a range of platform configuration register indices to be verified. The challenge nonce is a randomly generated one-time value used to prevent replay attacks. Specifying the range of platform configuration register indices allows the cloud server to return only the register values ​​relevant to the terminal device, reducing data transmission volume.

[0058] After receiving the verification request, the cloud server generates a verification report based on the request. The verification report includes platform configuration register values, digital signature, verification key certificate, and version information. After receiving the verification report returned by the cloud server, the terminal device can verify the report itself or forward it to a third-party verification party for verification. After successful verification, the terminal device confirms that the cloud server's operating environment meets the integrity and trust requirements before proceeding with the encryption and sending of user request information.

[0059] S330: Sends user request information to the cloud server.

[0060] The user request information is encrypted within the trusted execution environment of the terminal device.

[0061] Specifically, the terminal device sends a proof request to the cloud server, which then generates a proof report and returns it to the terminal device. The terminal device verifies the proof report itself or sends it to a verifier for verification. The verification includes: whether the signature of the proof report is valid, whether the platform configuration register value matches the expected value, and whether the trust chain is complete.

[0062] The terminal device encrypts the original request information in a trusted execution environment. The encryption process may include: obtaining the server's public key from the cloud server, generating a temporary key pair, generating a shared key based on the temporary private key and the server's public key, processing the shared key with preset parameters to obtain an encryption key, encrypting the original request information with the encryption key to generate encrypted ciphertext, and finally generating user request information based on the encrypted ciphertext and the temporary public key.

[0063] For example, in one use case, the terminal device is a smartwatch used to send voice commands to a cloud server for intelligent question answering. The smartwatch first requests a verification report from the cloud server. After successful verification, the smartwatch encrypts the user's voice data in a trusted execution environment, generates the user request information, and then sends it to the cloud server.

[0064] S340: Receive the target response information sent by the server.

[0065] The target response information is the information obtained by the cloud server after decrypting the user's request information to obtain plaintext data, and then processing the plaintext data.

[0066] The terminal device receives the target response information returned by the cloud server through an encrypted channel. Since the target response information is also encrypted during transmission, the terminal device needs to decrypt it in a trusted execution environment to obtain the final inference result.

[0067] For example, after the cloud server decrypts the received voice data, it runs a natural language processing model for semantic understanding and question-and-answer generation, obtaining the response text as the target reply information, which is then sent back to the smartwatch through an encrypted channel. The smartwatch decrypts and displays the response text in a trusted execution environment, or plays it back through speech synthesis.

[0068] In the end-to-cloud interaction method provided in this application, the terminal device sends encrypted user request information in a trusted execution environment to the cloud server, provided that the cloud server's operating environment meets integrity and trust requirements, and receives the target response information processed by the cloud server. These steps enable the terminal device to transmit data under the premise of confirming the trustworthiness of the cloud environment, and protect the confidentiality and integrity of data on the terminal side through a trusted execution environment, thereby improving the security of end-to-cloud interaction.

[0069] The following explains one feasible implementation process for information interaction between terminal devices and cloud servers.

[0070] Figure 4 This is an interactive diagram illustrating the edge-cloud interaction method provided in the embodiments of this application. Please refer to... Figure 4 The method includes: S410: The terminal device sends a verification request to the cloud server.

[0071] S420: The cloud server generates a proof report based on the proof request and sends the proof report to the terminal device.

[0072] S430: The cloud server receives user request information sent by the terminal device.

[0073] S440: The cloud server decrypts the user's request information to obtain plaintext data.

[0074] S450: The cloud server processes the plaintext data to obtain the target response information.

[0075] S460: The cloud server sends the target response information to the terminal device.

[0076] The above steps correspond to the aforementioned steps S210-S240 and S310-S340, and will not be explained again here.

[0077] The following sections will explain the specific steps performed by the cloud server and the terminal device.

[0078] For cloud servers: In one embodiment, the user request information includes at least encrypted ciphertext and a temporary public key; decrypting the user request information to obtain plaintext data includes: generating a decryption key based on the temporary public key and a pre-stored server private key; and using the decryption key to decrypt the encrypted ciphertext to obtain plaintext data.

[0079] It should be noted that the pre-stored server private key is a private key generated and stored by the cloud server in a secure environment (such as within a physical trusted platform module or a virtual trusted platform module). This private key, together with the server public key obtained by the terminal device, forms a key pair. The temporary public key is generated by the terminal device during encryption and sent to the cloud server via the user request information. The cloud server combines the temporary public key with the locally pre-stored server private key, calculates a shared secret value using a key exchange algorithm, and then performs a key derivation operation on this shared secret value to obtain the decryption key. Decryption typically uses symmetric encryption algorithms. These algorithms verify the integrity of the ciphertext during decryption; if the ciphertext is tampered with during transmission, the decryption operation will automatically fail and report an error.

[0080] For example, in a specific application scenario, the terminal device is a smartphone. The user sends a piece of Chinese text to be translated to a cloud server through an AI translation application on the phone. The phone generates a temporary elliptic curve key pair in a trusted execution environment (TEA). The temporary private key is stored within the phone's TEA, and the temporary public key is packaged together with the encrypted text into the user request information. After receiving the user request information, the cloud server extracts the temporary public key and the encrypted ciphertext. The cloud server reads the pre-stored server private key from its virtual trusted platform module, which is paired with the server public key previously obtained by the phone. The cloud server performs an elliptic curve Diffie-Hellman algorithm using the temporary public key and the server private key to obtain a shared key. Then, the cloud server applies a hash key derivation function (e.g., HKDF-SHA256) to the shared key to derive a decryption key. Finally, the cloud server uses the decryption key to decrypt the encrypted ciphertext to obtain the original Chinese text to be translated.

[0081] In the end-to-cloud interaction method provided in this application, encrypted ciphertext and a temporary public key can be combined and sent together with the user request information. The cloud server can generate the decryption key using only the temporary public key and its own pre-stored server private key, without knowing the terminal device's temporary private key. Even if the temporary private key of a certain session is leaked, it will not affect the security of other sessions. At the same time, the server private key is always stored inside the trusted platform module or virtual trusted platform module and is never exported, further enhancing the security of key storage.

[0082] In one embodiment, generating a decryption key based on a temporary public key and a pre-stored server private key includes: generating a shared key based on the temporary public key and the server private key; and processing the shared key using preset parameters to obtain the decryption key, wherein the preset parameters are preset parameters used by the terminal device during the encryption process.

[0083] In one embodiment, a key exchange algorithm (such as the Elliptic Curve Diffie-Hellman algorithm, or ECDH) can be used to calculate the temporary public key and the server private key. Specifically, the basic mathematical principle of the Elliptic Curve Diffie-Hellman algorithm is: for a base point G on the elliptic curve, the temporary public key pkE is equal to the scalar multiplication of the temporary private key skE and the base point G (pkE = skE * G), and the server public key pkR is equal to the scalar multiplication of the server private key skR and the base point G (pkR = skR * G). The cloud server uses the temporary public key pkE and its own private key skR to calculate the shared key shared_secret = skR * pkE. According to the commutative law of elliptic curve scalar multiplication, skR * pkE = skR * (skE * G) = skE * (skR * G) = skE * pkR, therefore the shared key calculated by the cloud server is exactly the same as the shared key calculated by the terminal device.

[0084] It should be noted that the preset parameters are the same set of parameters used by the terminal device during the encryption process, including the algorithm identifier of the key derivation function (e.g., HKDF-SHA256), the salt value used during derivation, the context information (info), and the expected output key length. The cloud server uses the exact same preset parameters as the terminal device to perform key derivation operations on the shared key to obtain the decryption key. Since the encryption key and decryption key are derived from the same shared key and use the same preset parameters, they have a corresponding relationship, enabling paired encryption and decryption operations.

[0085] For example, during the encryption process, the smartphone first generates a temporary elliptic curve private key skE and a corresponding temporary public key pkE. The phone obtains the public key pkR from the cloud server. The phone calculates the shared key shared_secret = skE * pkR. Then, the phone sets the following preset parameters: the key derivation algorithm is HKDF-SHA256, the salt value is a fixed string (e.g., "AI-Inference-Salt"), the context information is the identifier of this session (e.g., session ID), and the output key length is 256 bits. The phone inputs the shared key and these preset parameters into the HKDF-SHA256 function to derive the encryption key. After receiving the temporary public key pkE sent by the phone, the cloud server retrieves the server private key skR from the virtual trusted platform module and calculates the shared key shared_secret = skR * pkE. The cloud server uses the same preset parameters (the same HKDF-SHA256 algorithm, the same salt value, the same context information, and the same output length) to derive the decryption key from the shared key. Since the shared keys are equal and the preset parameters are exactly the same, the decryption key derived from the cloud server and the encryption key derived from the mobile phone are functionally paired, meaning that data encrypted with the encryption key can be correctly decrypted by the decryption key.

[0086] The edge-cloud interaction method provided in this application can generate a shared key through a key exchange algorithm, and then derive a decryption key through preset parameters, realizing the collaborative generation of encryption and decryption keys without directly transmitting the decryption key during communication. The key exchange algorithm ensures that the shared key is calculated independently by each communicating party. Even if an eavesdropper intercepts the temporary public key and the server's public key, they cannot calculate the shared key (because they lack the private key). The use of preset parameters makes the key derivation process reproducible and verifiable; as long as both parties use the same parameters, they can obtain the same encryption and decryption keys. This scheme combines the high security of asymmetric key exchange with the high efficiency of symmetric encryption, avoiding both the performance overhead of asymmetric encryption under large data volumes and the risk of symmetric key leakage during transmission.

[0087] In one embodiment, before receiving user request information sent by a terminal device, the method further includes: generating a proof report, which indicates whether the conditions for encrypted data transmission are met between the cloud server and the terminal device; and sending the proof report to the terminal device.

[0088] For example, in a specific application scenario, the cloud server is an AI image recognition service platform deployed on a public cloud. Before the platform officially receives user requests, its management system triggers a verification report generation process. The host agent program in the platform reads platform configuration register values ​​from the physical trusted platform module. These registers store hash metrics from UEFI firmware, bootloader, operating system kernel, and virtualization platform components. Simultaneously, the client agent program reads hash metrics from the virtual trusted platform module for the virtual machine boot chain and Kubernetes components. The cloud server packages these metrics along with a digital signature into a JSON-formatted verification report and sends it to the terminal device (e.g., a smartphone) via an HTTPS interface. Upon receiving the verification report, the application on the smartphone sends it to an online verification service (or verifies it itself). The verification service checks whether the signature was issued by a trusted certificate authority and compares the metrics to expected values ​​in a whitelist. If they match, the verification passes, the smartphone confirms the cloud server is trusted, and can continue sending encrypted image recognition requests; if they do not match, the verification fails, and the smartphone refuses to send any data to the server.

[0089] The edge-cloud interaction method provided in this application embodiment allows the cloud server to publicly demonstrate the trusted state of its operating environment to the terminal device in a verifiable manner by generating and sending a verification report. This proactive verification mechanism changes the traditional model where the terminal device passively trusts the cloud server, enabling the terminal device to actively verify the security of the cloud server before data transmission. The verification report builds a trust chain starting from the hardware root of trust. Any tampering with the cloud server's system software, configuration, or application will cause changes in the metric, which will be captured by the verification report and detected by the terminal device. This prevents the cloud server from receiving and processing sensitive user data even after being infected with malware or having its configuration tampered with.

[0090] In one embodiment, generating a proof report includes: receiving a proof request sent by a terminal device; reading the current target register value in response to the proof request; signing the target register value and the proof request using a proof key to generate signature information; and generating a proof report based on the target register value, the signature information, the certificate and version information of the proof key.

[0091] It should be noted that the proof request is the initiating message of the remote proof process by the terminal device. This request may include a challenge nonce and a range of platform configuration register indices to be verified. The challenge nonce is a one-time random value generated by the terminal device and included in the proof request to prevent replay attacks.

[0092] The target register value refers to the current metric value stored in the Physical Trusted Platform Module (PTM) or Secure Virtual Trusted Platform Module (SVPPM) of the cloud server, as well as the Platform Configuration Register (PCR) of the SVPPM. These registers are progressively extended during system startup and operation, recording the complete trust chain from firmware to applications.

[0093] The proof key is an asymmetric key pair specifically designed for remote proof. Its private key is stored internally within the trusted platform module, while the public key is publicly released via a certificate. The cloud server instructs the trusted platform module to digitally sign the target register value and the challenge random number in the proof request using the proof private key, generating a signature.

[0094] The cloud server assembles all the above information into a structured data object (such as JSON or CBOR format) to form a complete proof report.

[0095] For example, before sending an image recognition request, a smartphone, acting as the terminal device, first sends a verification request to the cloud server. This verification request contains a randomly generated 16-byte challenge random number (e.g., "a3f5c2e8d1b4a7c9e6f2b8d3a5c7e9f1") and specifies that it needs to read eight platform configuration registers at indices 0, 1, 2, 3, 4, 5, 6, and 7. Upon receiving this verification request, the cloud server calls the interface of the Physical Trusted Platform module to read the values ​​of these eight platform configuration registers.

[0096] The cloud server instructs the physical trusted platform module to sign the set of platform configuration register values ​​and challenge random numbers using the proof private key, obtaining the signature information. Then, the cloud server packages the platform configuration register values, signature information, proof key certificate (including proof public key and certificate chain), version information of the physical trusted platform module (e.g., "TPM 2.0"), and relevant information of the virtual trusted platform module at the virtual machine layer (including virtual platform configuration register values ​​and virtual proof key certificate) together to generate a complete proof report.

[0097] The edge-cloud interaction method provided in this application embodiment can prove that the report generation process involves two-way verification between the terminal device and the cloud server. The use of challenge random numbers effectively prevents attackers from deceiving the terminal device by recording and replaying old proof reports, because the challenge random number in each proof request is different, and the corresponding signature information is also different. The proof key signs the target register value and the proof request, making the content of the proof report unforgeable; any tampering with the target register value will cause signature verification to fail. By reading the platform configuration register value, the proof report can reflect the complete state changes of the cloud server from startup to the current moment.

[0098] In one embodiment, the method further includes: determining at preset intervals whether the operating environment of the cloud server meets the integrity requirements and the trust requirements; and refusing to receive user request information sent by the terminal device if the operating environment of the cloud server does not meet the integrity requirements or the trust requirements.

[0099] It should be noted that the preset duration can be configured according to the security policy, for example, it can be set to 30 seconds, 1 minute, 5 minutes or longer. Shorter time intervals can provide stronger security, but will consume more computing resources; longer time intervals can reduce performance overhead, but may miss some brief security events.

[0100] Cloud servers can determine whether the integrity and trust requirements of the operating environment are still met in a variety of ways, including but not limited to: rereading the platform configuration register values ​​of the physical trusted platform module or the virtual trusted platform module and comparing them with the baseline values, re-executing the remote proof process and verifying the signature, or periodically sending proof reports to the verifier and receiving the verification results.

[0101] For example, in a specific application scenario, an AI speech recognition service is deployed on a cloud server. The system administrator configures the preset duration of periodic verification to 60 seconds. An internal timer on the cloud server automatically triggers an integrity check every 60 seconds. In the first check, the cloud server reads PCR8 and PCR10 of the physically trusted platform module and finds that these values ​​are completely consistent with the baseline values ​​recorded at system startup, thus determining that the operating environment meets the integrity requirements. At the 30-minute mark, the timer triggers the check again. This time, the cloud server finds that the value of PCR8 has changed because the system administrator installed a new kernel module without security approval. After detecting this change, the cloud server determines that the operating environment no longer meets the integrity requirements. Subsequently, the cloud server sets an internal flag to an "untrusted" state. When a terminal device (such as a smart speaker) sends a speech recognition request at this time, the cloud server checks this flag, finds it in an "untrusted" state, rejects the request, returns an error code to the smart speaker (e.g., "Service unavailable, please try again later"), and logs a security alert.

[0102] In the end-to-cloud interaction method provided in this application, the cloud server can continuously monitor the security status of its environment during operation through periodic automatic verification, rather than performing verification only once at startup. This continuous verification mechanism can promptly detect malicious tampering behaviors that occur during runtime, such as kernel module injection, modification of critical configuration files, and replacement of trusted processes. Once the environment is detected as no longer trustworthy, the cloud server can proactively reject subsequent user requests, avoiding the processing of sensitive data in an untrusted state.

[0103] In one embodiment, the method further includes: monitoring program behavior characteristics, including: executing programs, calling data, or network interface data; determining whether a target behavior exists based on the program behavior characteristics, including: malicious behavior; and generating a prompt message if the target behavior exists, including at least one of the following: isolation information, termination information, and alarm information.

[0104] In one embodiment, program behavior characteristics refer to a series of observable actions and events generated by a process or container running on a cloud server during runtime. Execution program characteristics include process creation, process termination, loading of program code segments, loading of dynamic link libraries, etc. Call data characteristics include file system access (open, read, write, delete, modify permissions, etc.), modifications to the registry or configuration database, parameters and return values ​​of system calls, etc. Network interface data characteristics include the establishment and disconnection of network connections, the content of sent and received data packets, the target IP address and port number of the connection, DNS query requests and responses, etc.

[0105] Targeted behavior refers to pre-defined patterns of malicious or suspicious behavior. These patterns can be identified by training convolutional neural network (CNN) or recurrent neural network (RNN) models. For example, a well-trained RNN model can determine whether a process is performing ransomware behavior (such as extensively modifying files, renaming files, and writing specific ransom messages within a short period) based on a sequence of consecutive system calls. Similarly, a CNN model can determine whether there is communication with a known command and control server based on the spatiotemporal characteristics of network traffic.

[0106] In the event of targeted behavior, the cloud server generates corresponding alerts. Isolation information instructs the movement of suspicious processes or container groups to an isolation environment (e.g., a separate network namespace or a sandbox with restricted resource access) to prevent them from further impacting other normal services. Termination information instructs the forced termination of suspicious processes or the deletion of suspicious container groups. Alert information notifies system administrators or security operations centers and may include detailed information such as the type of malicious behavior, the time of occurrence, the identifiers of the involved processes or container groups, and related file paths or network addresses.

[0107] For example, in a specific application scenario, a cloud server runs multiple AI inference containers. Host and client agents continuously monitor the behavioral characteristics of programs within each container. A process running in one container begins to exhibit anomalous behavior: it accesses over 1000 files in different paths within 10 seconds, attempting to change the file extension after each access. The host agent collects these system call sequences and sends them to a pre-deployed recurrent neural network model. This model, after training, recognizes that this pattern is highly similar to known ransomware behavior, thus outputting a "malicious behavior - suspected ransomware" result. Based on this result, the cloud server generates a termination message, sending the container's identifier and termination command to the Kubernetes component. The Kubernetes component performs a forced deletion operation, terminating the container. Simultaneously, the cloud server generates an alert message stating "Suspected ransomware behavior detected in container ai-inference-pod-3, automatically terminated," and sends this alert to the security information and event management platform.

[0108] The edge-cloud interaction method provided in this application can identify unknown threats and zero-day attacks that are difficult to detect by traditional signature- or rule-based malware detection methods by monitoring program behavior characteristics and analyzing them using a neural network model. Behavioral feature monitoring does not rely on specific malware signatures but focuses on whether the program's behavior pattern deviates from the normal baseline, thus it is equally effective against new and variant malware. Multi-level response measures, including isolation, termination, and alerts, provide flexible security handling capabilities. Different response strategies can be adopted according to the severity and credibility of malicious behavior, which can quickly block attacks while avoiding misjudgments that could disrupt normal services. Incorporating the neural network model into the credibility measurement scope ensures the integrity of the model itself and the reliability of the inference results, preventing attackers from bypassing detection by tampering with the model.

[0109] For terminal devices: In one embodiment, before sending user request information to the cloud server, the method further includes: obtaining the server public key of the cloud server; generating a temporary key pair, the temporary key pair including a temporary private key and a temporary public key; generating a shared key based on the temporary private key and the server public key; processing the shared key using preset parameters to obtain an encryption key; encrypting plaintext data using the encryption key to generate encrypted ciphertext; and generating user request information based on the encrypted ciphertext and the temporary public key.

[0110] It should be noted that obtaining the public key of a cloud server refers to the terminal device obtaining the public key pre-published by the cloud server through secure means. This public key, together with the private key stored internally by the cloud server, forms a key pair.

[0111] Generating a temporary key pair refers to the process where the terminal device randomly generates a new key pair within the Trusted Execution Environment (TEE) at the start of each encrypted session. The temporary private key is stored internally within the TEE and is not sent externally; the temporary public key is used for subsequent key exchange and encapsulation.

[0112] A shared key is generated based on a temporary private key and the server's public key, and is calculated using a key exchange algorithm. The terminal device uses its own temporary private key and the cloud server's public key to calculate the shared key. Due to the commutative law of elliptic curve scalar multiplication, this shared key is exactly the same as the shared key calculated by the cloud server using its own private key and the terminal device's temporary public key.

[0113] The shared key is processed using preset parameters to obtain the encryption key. These preset parameters include the key derivation function type (e.g., HKDF-SHA256), salt value, context information, and output key length. The terminal device inputs the shared key and these parameters into the key derivation function, which outputs the encryption key used for encryption.

[0114] Plaintext data is encrypted using an encryption key to generate encrypted ciphertext. The encryption operation typically employs authenticated encryption algorithms, such as AES-256-GCM or ChaCha20-Poly1305. These algorithms generate authentication tags during encryption, which are used to verify the integrity of the ciphertext during decryption.

[0115] Based on the encrypted ciphertext and the temporary public key, a user request message is generated. The terminal device packages the encrypted ciphertext, the temporary public key, and other information that may be needed (such as algorithm identifiers and key derivation parameters) into a data structure and sends it as the user request message to the cloud server.

[0116] For example, in a specific application scenario, the terminal device is a laptop computer. The user uses an AI code completion plugin on the laptop to send a code snippet to a cloud server to receive completion suggestions. The laptop first obtains the server's public key from the cloud server's key service interface. The laptop then generates a temporary elliptic curve P-256 key pair in a trusted execution environment. Using the temporary private key and the server's public key, the laptop performs an elliptic curve Diffie-Hellman computation to obtain a shared key. Next, the laptop inputs the shared key into the HKDF-SHA256 function, setting the salt to "CodeCompletionSalt" and the context information to a unique identifier for the current session, outputting a 256-bit encryption key. The laptop encrypts the code snippet using the AES-256-GCM algorithm and this encryption key, generating encrypted ciphertext and an authentication tag. Finally, the laptop combines the encrypted ciphertext, the temporary public key, the authentication tag, and the algorithm identifier into a user request message and sends it to the cloud server via HTTPS.

[0117] The edge-cloud interaction method provided in this application embodiment enables end-to-end encryption within a trusted execution environment on the terminal device side, completing the entire process from public key acquisition, temporary key pair generation, shared key calculation, key derivation, to data encryption. The one-time pad characteristic of the temporary key pair ensures that a different temporary key is used for each encryption session; even if the temporary private key of one session is leaked, it will not affect the security of other sessions. The shared key calculation is based on an asymmetric key exchange algorithm, meaning that even if an eavesdropper intercepts the temporary public key and the server's public key, they cannot calculate the shared key. The use of key derivation functions ensures that the conversion process from the shared key to the encryption key is unidirectional, meaning that the shared key cannot be derived from the encryption key. The use of authentication encryption algorithms simultaneously guarantees the confidentiality and integrity of the data; any tampering with the ciphertext will be detected during decryption.

[0118] In one embodiment, before sending user request information to the cloud server, the method further includes: sending a verification request to the cloud server; receiving a verification report returned by the cloud server, the verification report being generated by the cloud server in response to the verification request, the verification report being used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device.

[0119] For example, in a specific application scenario, the terminal device is a smart camera. This camera sends captured images to a cloud server for facial recognition. Upon initial startup and connection to the cloud server, the smart camera first constructs a verification request. This request contains a 16-byte challenge random number and specifies eight registers (indexes 0, 1, 2, 3, 4, 5, 6, and 7) to be verified. These registers typically contain metrics for UEFI firmware, bootloader, kernel, and critical system components. The smart camera sends this verification request to the cloud server via HTTPS. In response, the cloud server reads the specified platform configuration register values ​​from its physical trusted platform module and virtual trusted platform module, signs them using the verification key, generates a verification report, and returns it to the smart camera. Upon receiving the verification report, the smart camera sends it to an online verification service. The verification service verifies the signature is valid and that the platform configuration register values ​​match a pre-configured whitelist in the smart camera, returning a "verification passed" result. Only after confirming the cloud server's trustworthiness does the smart camera begin encrypting the captured images and sending them to the cloud server for facial recognition.

[0120] In the end-to-cloud interaction method provided in this application embodiment, the terminal device can proactively initiate a verification request before encrypted data transmission, allowing the cloud server's trusted verification to serve as a prerequisite for data transmission. This verification-before-transmission mechanism avoids sending sensitive data to untrusted or tampered cloud servers. The inclusion of a challenge random number in the verification request effectively prevents replay attacks, preventing attackers from deceiving the terminal device by recording old verification reports. The terminal device can flexibly choose to verify the verification report itself or delegate verification to a third party, adapting to different trust models and security requirements. This scheme organically combines a remote verification mechanism with an encrypted data transmission mechanism, constructing a complete secure link from verification to encryption.

[0121] In one embodiment, after receiving the proof report returned by the cloud server, the method further includes: sending the proof report to the verifier; and receiving the verification result returned by the verifier, wherein the verification result is generated by the verifier after verifying the proof report.

[0122] It's important to note that the verifier is a third-party entity independent of the terminal device and cloud server, or it can be an independent verification module within the terminal device. The verifier's role is to objectively and impartially verify the authenticity and validity of the certification report. Sending the certification report to the verifier reduces the computational burden on the terminal device itself, especially when the terminal device is resource-constrained (such as IoT sensors or wearable devices). Offloading the verification task to a dedicated verification service can significantly reduce the terminal device's power consumption and computational resource consumption.

[0123] Upon receiving the proof report, the verifier performs the following verification operations: verifies the validity of the proof key certificate and checks whether the certificate chain was issued by a trusted root certificate authority; verifies the signature information to confirm that the signature was generated by the private key corresponding to the proof key, and that the signature content is consistent with the platform configuration register value and challenge random number in the proof report; compares the platform configuration register value with the expected value to check for any unauthorized modifications; checks whether the challenge random number is consistent with the one sent in the proof request to prevent replay attacks; and checks the integrity of the trust chain to ensure that each level from the hardware root of trust to the application is not compromised.

[0124] After verification, the verifier generates a verification result report. The report includes the overall verification status (verification passed or failed) and detailed verification results for each layer (e.g., host layer verification passed, virtual machine layer verification failed, container layer verification passed, etc.). The verifier returns the verification result to the terminal device. The terminal device determines its subsequent actions based on the verification result: if the verification result is passed, the terminal device continues to perform encryption and send the user request information; if the verification result is failed, the terminal device aborts the operation and may choose to attempt to connect to another trusted server or issue a security warning to the user.

[0125] For example, in a specific application scenario, the terminal device is a smart lock. This lock sends the captured facial image to a cloud server for authentication. The smart lock's battery capacity is limited, making it unsuitable for performing complex verification calculations. Therefore, after receiving the verification report from the cloud server, the smart lock does not verify it itself but instead sends the report to an online verification service provided by a security service provider. This online verification service is deployed on a server with powerful computing capabilities, enabling it to quickly perform operations such as certificate verification, signature verification, and metric comparison. After completing the verification, the online verification service generates a JSON-formatted verification result report, which includes a "status" field (with a value of "pass" or "fail"), a "timestamp" field (verification timestamp), and a "details" field (verification details at each level). The online verification service signs the verification result report using its private key and then returns it to the smart lock. Upon receiving the verification result report, the smart lock verifies the report's signature (using the online verification service's public key) to confirm that the report comes from a trusted verifier. If the "status" value in the report is "pass", the smart lock continues to encrypt the face image and send it to the cloud server; if the "status" value is "fail", the smart lock stops operating and records a "cloud server untrusted" event in the local log.

[0126] The edge-cloud interaction method provided in this application can reduce the computational burden on terminal devices by introducing an independent verifier, offloading the verification work of the proof report from the terminal device to a dedicated verification service. This is particularly suitable for resource-constrained terminal devices. As a third party independent of both communicating parties, the verifier can provide objective and impartial verification results, avoiding the risk of being bypassed or deceived by attackers if the terminal device performs verification itself. The verifier can centrally manage and update verification policies. When security policies change, only the verifier's configuration needs to be updated, without updating all terminal devices, improving system maintainability. The digital signature mechanism of the verification result report ensures the non-repudiation and integrity of the verification results, allowing the terminal device to confirm that the verification results indeed come from a trusted verifier and have not been tampered with.

[0127] The following section will explain in detail several implementation processes for interaction between cloud servers, terminal devices, and devices in the verification process.

[0128] Figure 5 For a complete flowchart of the inference request of the end-to-cloud interaction method provided in this application embodiment, please refer to... Figure 5 , Figure 5 It demonstrates the complete process from initiating the AI ​​inference service on the cloud server to completing the terminal request.

[0129] The proven Kubernetes component (i.e., a Kubernetes component that has undergone remote verification) on the cloud server first starts the business container group (Pod). The business container group is the smallest deployment unit in Kubernetes, containing an AI application along with the dependencies and configuration files required for its operation. After starting the business container group, the proven Kubernetes component performs remote verification on it in parallel. This remote verification checks the integrity and trustworthiness of the business container group's runtime environment, including whether the container image's hash matches expectations, whether the container startup parameters comply with security policies, and whether the mounted configuration files and keys have been tampered with.

[0130] If the verification passes, it is proven that the Kubernetes component allows the business container group to run, the business container group enters the running state, and the artificial intelligence application within the container group is ready to receive business requests from terminal devices. If the verification fails, it is proven that the Kubernetes component refuses to start the business container group and can generate alarm information for operations and maintenance personnel to investigate.

[0131] After the business container group successfully starts and runs, the AI ​​application on the terminal device initiates an AI inference request within the Trusted Execution Environment (TEE). The terminal device utilizes the security features of the TEE to encrypt the request data. The encrypted request data is then sent to the verified business container group on the cloud server via a dual-encryption channel. This dual-encryption channel includes transport layer encryption (e.g., HTTPS) and application layer encryption (e.g., hybrid public-key encryption based on a virtual trusted platform module).

[0132] The business container group receives encrypted requests from end devices. The AI ​​application within the container group decrypts the requests to obtain the raw inference data. The AI ​​application then performs inference computations, such as running a convolutional neural network model to classify images or a recurrent neural network model to perform semantic understanding of text. After the inference computation is complete, the AI ​​application generates the inference result and returns it to the end device via an encrypted channel.

[0133] After receiving the encrypted response, the terminal device decrypts and processes the final result in a trusted execution environment, such as displaying the identified object category or translated text on the screen.

[0134] After the business container group is started and running, the proven Kubernetes component continuously verifies the runtime environment of the business container group through remote verification. Continuous verification can be periodic, for example, initiating a remote verification request every certain interval (e.g., 30 seconds, 1 minute, or 5 minutes) to check whether the runtime environment of the business container group has undergone unexpected changes during operation. If, during continuous verification, it is found that the runtime environment of the business container group no longer meets the integrity or trust requirements, the proven Kubernetes component can take appropriate security measures, such as isolating the business container group, terminating the business container group, or issuing an alert notification.

[0135] pass Figure 5 The process shown in this application embodiment realizes a complete end-to-cloud secure inference chain from cloud service startup, encrypted terminal request sending, cloud trusted processing, encrypted result return to runtime continuous proof.

[0136] Figure 6 This is a flowchart illustrating the encryption and decryption process provided in the embodiments of this application. Please refer to it. Figure 6 After successful remote authentication, the terminal device executes the encryption process. The terminal device generates a temporary key pair, including a temporary private key and a temporary public key. The key type uses the same algorithm as the cloud server's identity public key, for example, elliptic curve cryptography (P-256 curve). The terminal device then obtains the temporary public key and temporary private key.

[0137] The terminal device performs key derivation operations for Hybrid Public Key Encryption (HPKE). First, the terminal device executes a key exchange algorithm, calculating a shared key using a temporary private key and the identity public key from the cloud server. For example, if elliptic curve cryptography is used, the shared key is the result of an elliptic curve Diffie-Hellman (ECDH) calculation of the temporary private key and the identity public key. Then, the terminal device executes a key derivation function, such as a hash-based message authentication code key derivation function (HKDF-SHA256), to derive the encryption key and nonce required for Authenticated Encryption (AEAD) from the shared key. Hybrid public key encryption can use Base mode, Auth mode, PSK mode, or AuthPSK mode; no specific restrictions are imposed here.

[0138] The terminal device uses the derived authentication encryption key and a random number to encrypt the plaintext data. The encryption algorithm can employ either Advanced Encryption Standard - Galois / Counter Mode (AES-256-GCM) or ChaCha20-Poly1305, both of which are authentication encryption algorithms that generate an authentication tag during encryption, ensuring the confidentiality and integrity of the data. After encryption, the terminal device obtains the ciphertext and the authentication tag.

[0139] The terminal device encapsulates a hybrid public-key encrypted ciphertext structure, which includes a pattern identifier, an algorithm identifier, a temporary public key, ciphertext, an authentication tag, and optional application information. After encapsulation, the terminal device sends the hybrid public-key encrypted ciphertext to the cloud server via a secure transmission channel (such as HTTPS). The encapsulated result is the aforementioned user request information.

[0140] After receiving the ciphertext encrypted with the mixed public key, the cloud server executes the decryption process. The cloud server parses the ciphertext structure, extracting the temporary public key, ciphertext, authentication tag, and algorithm parameters. The cloud server requests the virtual trusted platform module to calculate the shared key using the identity private key and the temporary public key. The virtual trusted platform module internally performs an elliptic curve Diffie-Hellman algorithm and returns the shared key to the cloud server. The cloud server uses the same key derivation function and parameters as the terminal device to derive the authentication encryption / decryption key and a random number from the shared key. The cloud server uses the derived decryption key and random number to decrypt the ciphertext; the authentication encryption / decryption process automatically verifies the integrity of the authentication tag. If decryption and verification are successful, the cloud server obtains the original plaintext data.

[0141] Figure 7 This is a flowchart illustrating the initialization process before encryption and decryption and the remote verification process provided in the embodiments of this application. Please refer to... Figure 7The cloud server connects to and initializes the Virtual Trusted Platform Module (VTPM) device. An identity key pair, consisting of a private key and a public key, is generated within the VTPM. The private key is stored internally and never exported to ensure security. The public key, however, can be exported and publicly released. The cloud server reads platform configuration register values, which store the hash metrics of components at each stage of the system startup chain. The cloud server also generates a proof key and a proof key certificate bound to the platform configuration register values.

[0142] After initialization, the cloud server publishes the identity public key to the key server, or provides it to the terminal device via application programming interface, configuration file, or other means. Simultaneously, the cloud server prepares the platform configuration register value and proof key certificate for subsequent remote verification.

[0143] Before initiating an encryption request, the terminal device needs to obtain the identity public key from the cloud server. The terminal device requests the identity public key from the cloud server or key server and verifies the format and validity of the obtained public key. Optionally, the terminal device can also verify the validity of the public key certificate to confirm that the public key indeed belongs to the target cloud server.

[0144] The terminal device also needs to prepare a proof verification environment, which includes configuring a whitelist of platform configuration register values ​​(i.e., the expected set of platform configuration register values), loading a certificate authorization chain to verify the signature of the proof key certificate, and preparing a proof verification strategy (e.g., which platform configuration registers to verify, what verification standard to use, etc.).

[0145] In the remote verification process, the terminal device sends a verification request to the cloud server. This request can specify the range of platform configuration register indices to be verified and includes a challenge random number to prevent replay attacks. Upon receiving the verification request, the cloud server requests the Virtual Trusted Platform Module (VTPM) to generate a verification report. The VTPM reads the current platform configuration register value, signs the platform configuration register value and the challenge random number using the verification key, and returns the signed report to the cloud server. The cloud server assembles the verification report, which includes the platform configuration register value, signature information, verification key certificate, VTPM version information, and the challenge random number. The cloud server then sends the verification report to the terminal device.

[0146] After receiving the proof report, the terminal device performs verification operations. These operations include: verifying the validity of the proof key certificate using the certificate authorization chain; verifying whether the signature was issued by the proof key; comparing the received platform configuration register value with the expected value in the whitelist; checking whether the challenge random number matches the challenge random number sent in the request to prevent replay attacks; and checking the version and status information of the virtual trusted platform module. If all verification items pass, the remote proof is successful, and the terminal device confirms that the cloud server's operating environment is trustworthy. If any verification fails, the terminal device refuses to connect and terminates the subsequent process.

[0147] pass Figure 6 and Figure 7 As shown in the process, this embodiment of the application implements hybrid public key encrypted transmission based on the virtual trusted platform module. It adds application layer encryption on top of traditional transport layer encryption (such as HTTPS), and the generation of encryption keys depends on the identity private key stored in the virtual trusted platform module, thereby providing stronger security.

[0148] Figure 8 This is a flowchart illustrating the measurement and proof process provided in the embodiments of this application. Please refer to... Figure 8 , Figure 8 It demonstrates the detailed process of integrity measurement and certification report generation within a cloud server, from the host layer to the virtual machine layer.

[0149] The first step is the measurement phase. Host-level metrics are written by host system components into registers of the Physical Trusted Platform Module (PTP) or the Secure Virtual Trusted Platform Module (SVTP). Host-level metrics include hashes of the system boot chain (from the Unified Extensible Firmware Interface (UEFI), bootloader, kernel to drivers), as well as runtime persistent metrics such as hashes of system components, host agents, and convolutional neural network or recurrent neural network components used for malware detection. These metrics are then extended into the platform configuration registers of the PTP or SVTP. The extension operation involves hashing the new metric with an existing value in the register, writing the result back into the register, thus forming an accumulated metric chain.

[0150] Metrics at the virtual machine layer (Guest) are written to the registers of the Virtual Trusted Platform Module by the virtual machine system components. These metrics include hashes of the virtual machine boot chain (virtual machine UEFI, kernel, initial memory disk initrd) and persistent runtime metrics, such as hashes of virtual machine system components, guest agents, Kubernetes components, and convolutional neural network or recurrent neural network components used for malware detection. These metrics are then extended to the platform configuration registers of the Virtual Trusted Platform Module.

[0151] After the measurement phase is completed, the initialization phase begins. The guest agent initializes and establishes a connection with the virtual trusted platform module. The host agent initializes and establishes a connection with either the physical trusted platform module or the secure virtual trusted platform module. The agents are resident processes running in their respective environments, responsible for coordinating interactions with trusted devices and transmitting integrity measurement information to each component.

[0152] Then comes the proof generation phase. The AI ​​application on the terminal device (running within a trusted execution environment) can request a remote proof report from the client agent on the cloud server. Upon receiving the request, the client agent requests the virtual trusted platform module to generate a virtual machine layer proof. The virtual trusted platform module generates proof information, which includes metrics for the virtual machine startup process, application metrics, and container group metrics, and returns it to the client agent.

[0153] The client agent also requests host-layer authentication from the host agent. The host agent requests the generation of host-layer authentication from the Physical Trusted Platform Module or the Secure Virtual Trusted Platform Module. The Physical Trusted Platform Module or the Secure Virtual Trusted Platform Module generates the authentication information and returns it to the host agent. The host agent then returns the host-layer authentication to the client agent.

[0154] The client agent combines the virtual machine layer proof and the host layer proof to generate complete proof information, which is then returned to the end device. This complete proof information includes end-to-end integrity metrics from physical hardware to virtual machines, container groups, and applications.

[0155] pass Figure 8 The process shown in this application embodiment realizes end-to-end integrity measurement from the host hardware root of trust to the virtual machine and then to the container application, providing reliable raw data for subsequent remote proof.

[0156] Figure 9 This is a schematic diagram illustrating the verification process between the terminal device and the verification party provided in this application embodiment. Please refer to... Figure 9 ,exist Figure 9 The verification process shown illustrates the detailed procedure for verifying the certification report between the terminal device and the verification party.

[0157] First, the AI ​​application on the terminal device (running within a trusted execution environment) requests proof from the client agent on the cloud server. The client agent returns complete proof information, which includes proof at the virtual machine layer, proof at the container group layer, and proof at the host layer.

[0158] The terminal device sends complete proof information to the remote verifier. The remote verifier can be the terminal device itself (i.e., the verification module built into the terminal device), a trusted third-party institution independent of the terminal device and cloud server, or a decentralized trust organization based on blockchain technology. After receiving the proof information, the remote verifier performs the verification operation.

[0159] The verification process includes the following sub-steps: First, the remote verifier parses the proof information, extracting platform configuration register values, signature information, and system trusted logs. Second, the remote verifier verifies the virtual machine layer proof, including verifying the validity of the virtual trusted platform module signature and whether the platform configuration register value matches expectations. Third, the remote verifier verifies the host layer proof, including verifying the validity of the physical trusted platform module or secure virtual trusted platform module signature and whether the platform configuration register value matches expectations. Fourth, the remote verifier verifies metric consistency, comparing expected and actual metric values. Fifth, the remote verifier verifies the integrity of the trust chain, verifying that the complete trust chain from hardware to virtual machines to container groups and applications has not been broken. Verification of trust chain integrity includes checking the integrity of system logs, the validity of signature certificates at each level, and the binding relationships between levels.

[0160] After verification is complete, the remote verifier generates a verification result report. The report includes the overall verification status (e.g., verification passed, verification failed, or partially passed), the verification status at each level (e.g., host-level verification passed, virtual machine-level verification failed), the verification timestamp, and the verifier's signature. The remote verifier then returns the verification result to the terminal device.

[0161] After receiving the verification result, the AI ​​application on the terminal device decides whether to continue with subsequent operations based on the result. If the verification result indicates that the cloud server's operating environment meets the integrity and trust requirements, the terminal device continues to send the encrypted request; if the verification result indicates that the verification failed, the terminal device refuses to send the request to that cloud server and may attempt to switch to another trusted cloud server or issue a security warning to the user.

[0162] pass Figure 9 The process shown in this application embodiment enables independent third-party verification or terminal self-verification of the verification report. The verification process does not rely on any statement from the cloud server, thus ensuring the objectivity and reliability of the verification results.

[0163] Figure 10 This is a schematic diagram of the malicious behavior monitoring process provided in the embodiments of this application. Please refer to it. Figure 10 ,exist Figure 10The malicious behavior monitoring process shown demonstrates the detailed process by which the cloud server continuously monitors program behavior and uses a neural network model to identify malicious behavior.

[0164] First, the program behavior monitoring phase begins. This phase is an ongoing process, not limited by specific requests or points in time. The cloud server intercepts and analyzes the program execution process, generating system call data (such as file opening, process creation, network connection system calls) and network input / output data (such as the content of sent data packets, the content of received data packets, the target address and port of the connection, etc.). Inside the virtual machine, program behavior data is collected by the guest agent program. On the host side, program behavior data is collected by the host agent program.

[0165] The collected behavioral data is sent to a convolutional neural network (CNN) or recurrent neural network (RNN) model for analysis. At the virtual machine layer, the client agent sends the collected behavioral data to the CNN or RNN model. This model uses pre-trained neural network weights to extract features and classify the behavioral data, identifying any malicious behavioral patterns. Malicious behavioral patterns may include, but are not limited to: abnormally frequent file access, abnormal privilege escalation operations, abnormal registry or configuration modifications, communication with known malicious domains or IP addresses, and the bulk file modification behavior characteristic of ransomware. The CNN model at the virtual machine layer returns the analysis results to the client agent.

[0166] At the host layer, the host agent sends the collected behavioral data to a convolutional neural network or recurrent neural network model. This model analyzes the host-side behavioral data to identify any malicious behavior targeting the host operating system, virtualization platform, or hardware resources. The host-layer neural network model then returns the analysis results to the host agent.

[0167] If the analysis results indicate malicious behavior, the malicious behavior handling path is initiated. The client agent reports the malicious behavior to the proven Kubernetes component. The host agent also reports the malicious behavior to the proven Kubernetes component. Upon receiving the report, the proven Kubernetes component takes appropriate security measures. These measures include: isolating the affected program or container group (e.g., moving the suspicious container group to an isolated network namespace), terminating the affected program or container group (e.g., forcibly deleting or stopping a running container group), and issuing alerts (e.g., logging security events, sending alert emails, or calling the monitoring system's API). If the analysis results indicate normal behavior, the normal status handling path is initiated. The client agent and host agent report normal status information to the proven Kubernetes component for status logging and statistical analysis.

[0168] pass Figure 10 As shown in the process, this application embodiment realizes runtime malicious behavior detection based on a neural network model, which makes up for the shortcomings of traditional trusted platform module solutions that can only perform static measurement and cannot detect runtime malicious behavior, and improves the runtime security protection capability of cloud servers.

[0169] In one embodiment, the remote proof report is a structured data document generated by a cloud server, used to prove the integrity and trustworthiness of its operating environment to end devices or verifiers. The report is encapsulated in a network token-based format and organized in accordance with entity proof token configuration specifications.

[0170] It should be noted that the remote proof report consists of three parts: header, payload, and signature value.

[0171] The header describes the signature algorithm and token type used in the report. The signature algorithm can be a digest signature algorithm or an elliptic curve digital signature algorithm, and the token type is fixed as a network token format.

[0172] The payload is the core content of the report, containing the identity information, time information, integrity metrics, and proof information at each level of the entity being proven. The payload includes two types of information: general fields and supplementary fields.

[0173] The signature value is encrypted data obtained by digitally signing the header and payload, and is used to verify the integrity and authenticity of the report.

[0174] In one embodiment, common fields in the payload are used to describe the basic metadata of the report.

[0175] The issuer field is used to identify the entity that generated the certification report, and is usually filled with the Uniform Resource Identifier of the remote certification service.

[0176] The subject field is used to identify the entity being certified, such as the name or identifier of the certified Kubernetes node.

[0177] The audience field is used to identify the recipient of the certification report. It can be the identifier of a single terminal device or a list of identifiers of a group of recipients.

[0178] The issuance time field records the time the report was generated, using a globally unified timestamp format, expressed in seconds as the number of seconds elapsed since the start of Coordinated Universal Time.

[0179] The expiration time field records the expiration date of the report; reports are considered invalid after this time.

[0180] The unique identifier field assigns a globally unique identifier string to the report to distinguish different certification reports.

[0181] The challenge random number segment contains a one-time random number sent by the terminal device in the proof request to prevent replay attacks.

[0182] The configuration specification identifier field is used to identify the version of the entity proof token configuration specification followed by this report.

[0183] In one embodiment, host layer authentication information is encapsulated in a separate data object that describes the trusted state of the host layer.

[0184] The host agent information includes: the agent's unique identifier, the agent's version number, the hash value of the agent's code, the agent's running status, and the agent's verification status. The running status can be running or stopped, and the verification status can be verified or verification failed.

[0185] Information for either a physically trusted platform module or a secure virtual trusted platform module includes: module type, module version, module manufacturer, public key for proof, certificate for proof, and system event logs. The module type is used to distinguish between a physically trusted platform module and a secure virtual trusted platform module.

[0186] The platform configuration register values ​​include metrics for multiple registers. For example, register zero stores metrics for the Basic Input / Output System or the Unified Extensible Firmware Interface firmware; register one stores metrics for platform configuration; register two stores metrics for optional read-only memory code; register seven stores metrics for the secure boot policy; register eight stores metrics for booting the device; and register ten stores metrics for the integrity metrics architecture.

[0187] The platform configuration register reference information includes the referenced encoded value and digital signature, which is used to prove the authenticity of the platform configuration register value at the time of its generation.

[0188] The boot chain metrics include: metrics for the Unified Extensible Firmware Interface (UE) firmware, metrics for the bootloader, kernel metrics, hashes of kernel command-line arguments, metrics for the initial memory disk, a list of driver metrics, metrics for the virtualization platform, and a list of graphics processing unit (GPU) drivers. Each entry for a GPU driver includes the driver name, driver version, driver file hash, driver file path, kernel module name, kernel module hash, firmware version, firmware hash, and a metric timestamp.

[0189] Platform attribute information includes: CPU model, CPU manufacturer, virtualization platform type, virtualization platform version, operating system type, whether Secure Boot is enabled, and graphics processing unit (GPU) hardware information. GPU hardware information includes a list of GPU devices, with each device entry including a unique device identifier, manufacturer name, model, device identifier, subsystem manufacturer identifier, subsystem device identifier, peripheral component interconnect bus identifier, video memory size, computing power, maximum clock frequency, serial number, globally unique device identifier, and GPU certification status.

[0190] In one embodiment, virtual machine layer authentication information is encapsulated in a separate data object to describe the trusted state of the virtual machine layer.

[0191] Client agent information includes: agent's unique identifier, agent version number, agent code hash value, agent running status, and agent proof status.

[0192] The information for the Virtual Trusted Platform Module includes: the module's unique identifier, version number, type, public key for proof, certificate for proof, and system event logs.

[0193] The platform configuration register values ​​of the Virtual Trusted Platform module include the metrics of multiple registers, similar to those at the host layer but specific to the virtual machine environment. For example, register zero stores the metrics of the virtual machine's Basic Input / Output System or Unified Extensible Firmware Interface firmware; register one stores the metrics of the virtual machine platform configuration; register seven stores the metrics of the virtual machine's secure boot policy; register eight stores the metrics of the virtual machine's boot device; and register ten stores the metrics of the virtual machine's integrity measurement architecture.

[0194] The platform configuration register reference information of the virtual trusted platform module includes the referenced encoded value and digital signature.

[0195] The virtual machine boot chain metrics include: metrics of the virtual machine unified extensible firmware interface firmware, metrics of the virtual machine kernel, metrics of the virtual machine initial memory disk, a list of virtual machine driver metrics, and a list of virtual machine graphics processing unit drivers.

[0196] The virtual machine platform attribute information includes: virtual machine identifier, virtual machine name, virtual machine operating system type, virtual machine operating system version, virtual machine secure boot status, and virtual machine graphics processing unit (GPU) information. The GPU information includes whether GPU passthrough is enabled, whether GPU virtualization is enabled, virtual GPU type, virtual GPU identifier, and the list of GPUs allocated to the virtual machine.

[0197] In one embodiment, container group layer authentication information is encapsulated in a separate data object that describes the trusted state of container groups and Kubernetes components.

[0198] Kubernetes environment information includes: cluster identifier, cluster name, node name, node unique identifier, namespace to which the container group belongs, container group name, container group unique identifier, container group network address, and service account name.

[0199] Verified Kubernetes component information includes: component name, component version, component code hash, component verification status, and component metric. The component name can be a node proxy component, network proxy component, or other Kubernetes core component.

[0200] The verified container group information includes: a unique identifier for the container group, a configuration hash value for the container group, a timestamp for the container group creation, a timestamp for the container group verification, and the verification status of the container group.

[0201] Application programming interface (API) service information includes: service name, service version, service code hash, service endpoint, protocol type, service port number, transport layer security certificate hash, and whether remote authentication is enabled.

[0202] The container group's graphics processing unit (GPU) resource information includes: the requested number of GPUs, the GPU limit, GPU type requirements, the allocated GPU list, the GPU device plugin name, and the device plugin version. Each entry in the allocated GPU list includes a GPU identifier, a globally unique GPU identifier, and the name of the node it resides on.

[0203] The container group's container image information includes: image name, image tag, image summary, image identifier, image repository address, and image certification status.

[0204] Container group runtime information includes: runtime type, runtime version, runtime binary hash, container runtime component version, and container runtime component binary hash. The runtime type can be one of the standard implementations of the container runtime interface, such as a container runtime or a container engine.

[0205] In one embodiment, the AI ​​model layer proof information is encapsulated in a separate data object to describe the trustworthiness of the AI ​​application, model, and data.

[0206] Artificial intelligence application information includes: application unique identifier, application name, application version, application code hash value, security enclave identifier, enclave metric value, and enclave signer value.

[0207] Artificial intelligence model information includes: a unique model identifier, model name, model version, model type, model file hash value, model size, model format, and model certification status. The model type can be a convolutional neural network, recurrent neural network, transformer network, or large language model, etc. The model format can be an open neural network exchange format, tensor stream format, or petochet format.

[0208] Model metric information includes: model file hash, model configuration file hash, model weight file hash, and metric timestamp.

[0209] Data information includes: unique data identifier, data name, data version, data type, data file hash value, data size, data format, whether the data is encrypted, and data verification status. The data type can be training data, inference data, or validation data. The data format can be comma-separated value format, JSON format, or columnar storage format.

[0210] Data metric information includes: data file hash value, data index file hash value, data pattern hash value, and metric timestamp.

[0211] In one embodiment, the proof chain information is encapsulated in a separate data object that describes the complete trust chain from hardware to application.

[0212] The proof chain structure information includes: a unique identifier for the proof chain, the proof chain type, and the verification status. The proof chain type can be a complete proof chain or a partial proof chain, and the verification status can be verified, failed to verify, or pending verification.

[0213] The proof chain hierarchy information is a list of levels, each level including: level name, level proof status, level comprehensive hash value, level proof timestamp, parent level name, and a list of child level names. Level names can be host level, virtual machine level, container group level, or artificial intelligence model level, etc.

[0214] In one embodiment, the remote authentication report is encoded using a network token-based encoding method. The report header, payload, and signature value are encoded separately and then concatenated into a single string separated by periods. This string can be transmitted via Hypertext Transfer Protocol or other communication protocols.

[0215] In one embodiment, the verification report is a conclusive document generated by the verifier after verifying the remote proof report, used to inform the terminal device of the verification result. This report is also encapsulated in a network token-based format.

[0216] It should be noted that the verification report consists of three parts: header, payload, and signature value.

[0217] The header describes the signature algorithm used in the verification report, the token type, and the key identifier of the verifier. The signature algorithm can be a digest signature algorithm or an elliptic curve digital signature algorithm, the token type is fixed to the network token format, and the key identifier is used to identify the key used by the verifier to sign the verification report.

[0218] The payload is the core content of the verification report, which includes verification metadata, overall verification results, and verification status at each level.

[0219] The signature value is encrypted data obtained by digitally signing the header and payload, and is used to ensure the integrity and authenticity of the verification report.

[0220] In one embodiment, the verification metadata is used to describe basic information about the current verification operation.

[0221] The verification identifier field assigns a globally unique identifier to the verification report.

[0222] The Validator Identifier field is used to identify the entity that performs the validation operation; it can be the name or identifier of the validation service.

[0223] The verification timestamp field records the time when verification was completed. It uses a globally unified timestamp format and is expressed in seconds as the number of seconds that have elapsed since the start of Coordinated Universal Time.

[0224] The verification time field records the time elapsed from receiving the proof report to generating the verification result, in milliseconds.

[0225] The Verified Proof Report Identifier field records the unique identifier of the verified proof report.

[0226] The Verified Proof Report Network Token Identifier field records the network token identifier of the verified proof report.

[0227] The verified entity identifier field records the identifier of the cloud server or container being verified.

[0228] The verified entity type field records the type of the entity being verified, which can be a Kubernetes node, container group, or virtual machine, etc.

[0229] The validation strategy identifier field records the identifier of the strategy used in this validation.

[0230] The verification strategy version field records the version number of the verification strategy.

[0231] The validation strategy name field records the name of the validation strategy.

[0232] The validation policy type field records the severity level of the policy, which can be strict, medium, or lenient.

[0233] The validation strategy rule list field records the specific list of rules applied in this validation.

[0234] In one embodiment, the overall verification result is used to describe the overall conclusion of the verification.

[0235] The overall verification status field records the overall verification status, which can be verified, failed, partially passed, or a warning.

[0236] The validation result field records the final validation conclusion, which can be pass, fail, or warning.

[0237] The Trust Level field records the level of trust assessed based on the verification results, which can be high trust level, medium trust level, low trust level, or no trust level.

[0238] The verification status field for each level is a composite object, containing the host layer status, virtual machine layer status, container group layer status, AI model layer status, and proof chain status. Each status can be verified, verified failed, or a warning.

[0239] The total number of checks performed in this verification process is recorded in the total number of checks performed.

[0240] The number of checks that passed verification is recorded in the check item number field.

[0241] The Failed Checks field records the number of checks that failed to be validated.

[0242] The Warning Check Items field records the number of checks that generated warnings.

[0243] The Skip Checks field records the number of checks that were skipped because the conditions were not met.

[0244] In one embodiment, the verification report as a whole adopts the same network token-based encoding method as the remote proof report. The verifier uses its own private key to digitally sign the header and payload, generating a signature value. Each part of the verification report is encoded separately and then concatenated with periods to form a complete string, which is returned to the terminal device. The terminal device can use the verifier's public key to verify the signature of the verification report, confirming that the report comes from a trusted verifier and has not been tampered with.

[0245] It should be understood that although the steps in the above flowcharts are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the above flowcharts may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0246] Based on the foregoing embodiments, this application provides an edge-cloud interaction device, which includes various modules and units included in each module, and can be implemented by a processor; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), microprocessor (MPU), digital signal processor (DSP) or field programmable gate array (FPGA), etc.

[0247] Figure 11 This is a schematic diagram of the cloud-side structure of the edge-cloud interaction device provided in the embodiments of this application. Please refer to... Figure 11 In another aspect of the embodiments of this application, an end-to-cloud interaction device is provided, which is applied to a cloud server and communicates with a terminal device. The device includes: a first receiving module 1110, a processing module 1120, a reply module 1130 and a sending module 1140. The sending module 1140 is used to send a certificate report to the terminal device. The certificate report is used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device. The first receiving module 1110 is used to receive user request information sent by the terminal device under the condition that the integrity and trust requirements are met in the operating environment of the cloud server. The user request information is the request information encrypted in the trusted execution environment of the terminal device. Processing module 1120 is used to decrypt user request information to obtain plaintext data; The response module 1130 is used to process plaintext data, obtain target response information, and send the target response information to the terminal device.

[0248] Figure 12 This is a schematic diagram of the terminal-side structure of the edge-cloud interaction device provided in the embodiments of this application. Please refer to... Figure 12In another aspect of the embodiments of this application, an end-to-cloud interaction device is provided, which is applied to a terminal device and communicates with a cloud server. The device includes: a request module 1210 and a second receiving module 1220. Request module 1210 is used to send a proof request to the cloud server; The second receiving module 1220 is used to receive a proof report returned by the cloud server. The proof report is generated by the cloud server in response to the proof request. The proof report is used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device. The request module 1210 is also used to send user request information to the cloud server when the integrity and trust requirements are met in the cloud server's operating environment. The user request information is the request information encrypted in the trusted execution environment of the terminal device. The second receiving module 1220 is also used to receive target response information sent by the server. The target response information is information obtained by the cloud server after decrypting the user request information to obtain plaintext data and then processing the plaintext data.

[0249] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0250] It should be noted that, in the embodiments of this application... Figure 11 and Figure 12 The module division shown in the edge-cloud interaction device is illustrative and represents only one logical functional division; in actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical units, or be integrated into one unit by two or more units. The integrated units can be implemented in hardware, as software functional units, or a combination of both.

[0251] It should be noted that, in the embodiments of this application, if the above-described methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0252] It should be noted that the devices in this application embodiment may include the cloud server and terminal devices mentioned above. The structures of these two devices will be explained below.

[0253] Figure 13 This is a schematic diagram of the cloud server structure provided in the embodiments of this application. Please refer to... Figure 13 This application provides a cloud server whose internal structure diagram is as follows: Figure 13 As shown, the cloud server includes a first processor 1320, a first memory, and a first network interface 1340 connected via a first system bus 1310. The first processor 1320 provides computing and control capabilities. The first memory includes a first non-volatile storage medium 1331 and a first internal memory 1332. The first non-volatile storage medium 1331 stores an operating system, computer programs, and a database. The first internal memory 1332 provides an environment for the operation of the operating system and computer programs in the first non-volatile storage medium 1331. The cloud server's database stores data. The first network interface 1340 of the cloud server communicates with external terminal devices via a network connection. When the computer program is executed by the first processor 1320, it implements the aforementioned method.

[0254] Figure 14 This is a schematic diagram of the terminal device provided in the embodiments of this application. Please refer to... Figure 14 This application provides a terminal device whose internal structure diagram can be as follows: Figure 14As shown, the terminal device includes a second processor 1420, a second memory, and a second network interface 1440 connected via a second system bus 1410. The second processor 1420 provides computing and control capabilities. The second memory includes a second non-volatile storage medium 1431 and a second internal memory 1432. The second non-volatile storage medium 1431 stores an operating system, computer programs, and a database. The second internal memory 1432 provides an environment for the operation of the operating system and computer programs in the second non-volatile storage medium 1431. The database of the terminal device is used to store data. The second network interface 1440 of the terminal device is used to communicate with an external cloud server or authentication party via a network connection. When the computer program is executed by the second processor 1420, it implements the aforementioned methods.

[0255] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method provided in the above embodiments.

[0256] This application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the steps in the method provided in the above-described method embodiments.

[0257] Those skilled in the art will understand that Figure 13 and Figure 14 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0258] In one embodiment, the edge-cloud interaction device provided in this application can be implemented as a computer program, and the computer program can be implemented in such a way as... Figure 13 and Figure 14 The device operates on the device shown. The device's memory can store the various program modules that make up the above-described apparatus. The computer program comprised of the various program modules causes the processor to execute the steps of the methods in the various embodiments of this application described in this specification.

[0259] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium, storage medium, and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0260] It should be understood that the phrases "one embodiment," "an embodiment," or "some embodiments" mentioned throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment," "in one embodiment," or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. The descriptions of the various embodiments above tend to emphasize the differences between the various embodiments; their similarities or commonalities can be referred to mutually, and for the sake of brevity, they will not be repeated here.

[0261] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three kinds of relationships. For example, object A and / or object B can represent three situations: object A exists alone, object A and object B exist simultaneously, and object B exists alone.

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

[0263] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple modules or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or modules can be electrical, mechanical, or other forms.

[0264] The modules described above as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules. They may be located in one place or distributed across multiple network units. Some or all of the modules may be selected to achieve the purpose of this embodiment according to actual needs.

[0265] In addition, each functional module in the various embodiments of this application can be integrated into one processing unit, or each module can be a separate unit, or two or more modules can be integrated into one unit; the integrated modules can be implemented in hardware or in the form of hardware plus software functional units.

[0266] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0267] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0268] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0269] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0270] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0271] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for end-to-end cloud interaction, characterized in that, The method includes: A verification report is sent to the terminal device, the verification report indicating whether the conditions for encrypted data transmission are met between the cloud server and the terminal device; Receive user request information sent by the terminal device, wherein the user request information is encrypted in the trusted execution environment of the terminal device; The user request information is decrypted to obtain plaintext data; The plaintext data is processed to obtain the target response information, and the target response information is sent to the terminal device.

2. The method according to claim 1, characterized in that, The user request information includes at least encrypted ciphertext and a temporary public key; The process of decrypting the user request information to obtain plaintext data includes: A decryption key is generated based on the temporary public key and the pre-stored server private key; The encrypted ciphertext is decrypted using the decryption key to obtain the plaintext data.

3. The method according to claim 2, characterized in that, The process of generating a decryption key based on the temporary public key and the pre-stored server private key includes: A shared key is generated based on the temporary public key and the server private key; The shared key is processed using preset parameters to obtain a decryption key. The preset parameters are those used by the terminal device during the encryption process.

4. The method according to claim 1, characterized in that, Sending the proof report to the terminal device includes: Receive the proof request sent by the terminal device; In response to the proof request, read the current target register value; The target register value and the proof request are signed using the proof key to generate signature information; The proof report is generated based on the target register value, the signature information, the certificate and version information of the proof key.

5. The method according to claim 1, characterized in that, The method further includes: Every preset time interval, determine whether the operating environment of the cloud server meets the integrity and trust requirements; If the cloud server's operating environment does not meet the integrity or trust requirements, the user request information sent by the terminal device will not be accepted.

6. A method for end-to-end cloud interaction, characterized in that, The method includes: Send a verification request to the cloud server; The system receives a proof report returned by the cloud server, which is generated by the cloud server in response to the proof request. The proof report is used to indicate whether the conditions for encrypted data transmission are met between the cloud server and the terminal device. Send user request information to the cloud server, wherein the user request information is encrypted in the trusted execution environment of the terminal device; The system receives a target response message sent by the server. The target response message is information obtained by the cloud server after decrypting the user request message to obtain plaintext data and then processing the plaintext data.

7. The method according to claim 6, characterized in that, Before sending the user request information to the cloud server, the method further includes: Obtain the public key of the cloud server; Generate a temporary key pair, which includes a temporary private key and a temporary public key; A shared key is generated based on the temporary private key and the server public key; The shared key is processed using preset parameters to obtain an encryption key; The plaintext data is encrypted using the encryption key to generate encrypted ciphertext; The user request information is generated based on the encrypted ciphertext and the temporary public key.

8. The method according to claim 6, characterized in that, After receiving the verification report returned by the cloud server, the method further includes: Send the proof report to the verifyer; The verification result returned by the verification party is received. The verification result is generated by the verification party after verifying the proof report.

9. A device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1-5 or 6-7.

10. A computer program product, characterized in that, When run on a computer, it causes the computer to perform the steps of the method as described in any one of claims 1-5 or 6-7.

Images