AI model operation protection and credible evidence storage method and system, and storage medium

Abstract

The invention belongs to the technical field of artificial intelligence trusted computing, and particularly relates to an AI model operation protection and trusted evidence storage method and system and a storage medium. The method comprises the steps that a model provider encrypts an AI model; the model operator generates a key pair of an asymmetric cryptographic algorithm in the trusted execution environment; the model provider encapsulates the model encryption key by using the public key after verifying that the remote certification report is valid; the model operator decrypts the key packaging block in the trusted execution environment, and decrypts the encrypted AI model by using the key; the model operator provides reasoning service in the trusted execution environment; acquiring evidence storage data at a model operation side, performing digital signature by using the private key through the trusted execution environment, and sending the evidence storage data to the evidence storage platform for storage; and checking based on the evidence storage data stored in the evidence storage platform. According to the method, the trusted execution environment is combined with the block chain to construct a dual security guarantee system, and the limitation of a single technology is solved.

Description

Technical Field

[0001] This invention belongs to the technical field of trusted computing in artificial intelligence, and specifically relates to a method, system and storage medium for protecting the operation and trusted storage of AI models. Background Technology

[0002] With the rapid development of artificial intelligence (AI) technology, AI models are playing an increasingly important role in various key business applications, becoming a core force driving business innovation and efficiency improvement. The successful application of AI models requires deep integration with actual business scenarios and necessitates close collaboration and efficient coordination among multiple stakeholders, including data providers, model developers, model users, business environments, and operators. During the operation of many models, there are frequent and multi-dimensional data exchanges. This is especially crucial for models focusing on data computation, analysis, and decision-making, where the secure flow and value release of data and models are paramount. To address the integration of data elements and AI technology and provide clear guidance for the healthy development of the industry, a trusted data space can be constructed. This allows relevant data elements and AI models to be incorporated into the closed-loop data flow of the system and business systems, ensuring the security, trustworthiness, and compliance of data and models throughout the entire process and ecosystem operation.

[0003] In the production environments of the aforementioned trusted data space ecosystem applications and actual business scenarios, to integrate AI models into the system and fully leverage their core driving value, the primary task is to effectively address the security concerns of model providers. Currently, AI models themselves and their entire operational process face multiple security threats, primarily including:

[0004] 1. Model theft and reverse engineering: Attackers can obtain model parameters through side-channel attacks, memory dumps, debugging interfaces, etc., leading to the leakage of intellectual property rights or the malicious copying of the model.

[0005] 2. Model tampering and poisoning attacks: If integrity protection is not implemented during model deployment or operation, attackers may replace or modify model files, resulting in manipulation of inference results.

[0006] 3. Leakage of inference data: Sensitive input data submitted by users (such as medical records, financial transactions, and personal identification information) may be stolen during transmission or processing.

[0007] 4. Untrusted operating environment: If the model runs in a normal operating system environment, it is vulnerable to threats such as malware, rootkits, and kernel vulnerabilities, and the isolation and integrity of the execution environment cannot be guaranteed.

[0008] 5. Lack of auditability and verifiability: Traditional AI systems struggle to provide complete operational logs and evidence, making it difficult for third parties to effectively verify whether a particular inference actually occurred in a trusted environment or whether the inputs and outputs were tampered with.

[0009] To address these challenges, the industry has proposed various security enhancement solutions. Among them, Trusted Execution Environment (TEE) technology, due to its hardware-level isolation, memory encryption, and remote authentication features, has become an important means of protecting the secure operation of AI models. For example, Intel SGX, ARM TrustZone, and AMD SEV all provide TEE capabilities. However, existing solutions generally have the following shortcomings:

[0010] 1. Model Distribution Security: How to securely deliver encrypted models and keys to TEEs and ensure that only the target TEE can decrypt them.

[0011] 2. Reliance on foreign TEE platforms: Most solutions are based on foreign technologies such as Intel SGX, which pose supply chain security risks and make it difficult to meet the requirements of independent control of my country's critical information infrastructure.

[0012] 3. Lack of support for domestic cryptographic algorithms: Existing TEE solutions mostly use international algorithms such as RSA and AES, and do not fully integrate the national cryptographic algorithms SM2 / SM4, which does not comply with my country's cryptographic management regulations.

[0013] 4. Weak Evidence Storage Mechanism: Although some solutions attempt to put operational logs on the blockchain, they lack reliable guarantees regarding the source of log generation and have not established a closed-loop evidence storage system covering the entire chain from model deployment to inference execution. There is a lack of a full-lifecycle evidence storage and traceability log system covering model loading, model operation, model output, and model usage. Furthermore, the lack of operational and management evidence storage means that there is a lack of reliable records and evidence for operational and maintenance behaviors such as start / stop control, security detection, and anomaly monitoring of TEE nodes, making it difficult to achieve full lifecycle security management.

[0014] 5. Incomplete verification mechanism: Existing verification relies heavily on centralized log servers and lacks the ability to automatically verify evidence based on blockchain and smart contracts, making it difficult for third parties to independently verify the authenticity of the reasoning.

[0015] In recent years, domestic CPU platforms such as Hygon's have supported hardware-based trusted execution environments and are compatible with national cryptographic algorithms, providing a foundation for building an independent and controllable AI security system. However, how to deeply integrate domestically produced TEEs with technologies such as AI model protection, end-to-end evidence storage, and smart contract verification to form a complete, efficient, and compliant solution remains a pressing technical challenge.

[0016] Therefore, there is an urgent need for a trusted data space operation protection and end-to-end trusted evidence storage and verification method and system for AI models, which can realize a closed loop of the entire process of encrypted model deployment, secure inference, trusted log collection, consortium blockchain evidence storage and third-party verifiable verification, to ensure that AI models run in a "trusted environment", their behavior is "auditable" and their results are "verifiable". Summary of the Invention

[0017] To address the aforementioned problems in existing technologies, namely high risk of model leakage, untrustworthy operating environments, inadequate evidence storage mechanisms, weak verification capabilities, and lack of operation and maintenance management, the first aspect of this invention provides a method for protecting the operation and reliable evidence storage of AI models, comprising:

[0018] The model provider encrypts the AI ​​model;

[0019] The model operator generates a key pair for an asymmetric cryptographic algorithm within a trusted execution environment and provides a remote proof report containing the public key to the model provider, wherein the private key corresponding to the public key is restricted to the trusted execution environment;

[0020] After verifying the validity of the remote proof report, the model provider uses the public key to encapsulate the model encryption key and sends the key encapsulation block to the model operator.

[0021] The model operator uses the private key corresponding to the public key to decrypt the key encapsulation block in the trusted execution environment to obtain the model encryption key, and uses the model encryption key to decrypt the encrypted AI model in the trusted execution environment. The model operator uses the decrypted AI model in the trusted execution environment to provide inference services to the model user.

[0022] On the model execution side, evidence storage data is collected during model deployment, model inference, and system operation. The trusted execution environment uses the private key to digitally sign at least a portion of the evidence storage data and sends the signed evidence storage data to the evidence storage platform for storage.

[0023] The credibility of the AI ​​model's operation process is verified based on the evidence storage data stored in the evidence storage platform.

[0024] In some preferred embodiments, the trusted execution environment is a trusted execution environment based on the domestic Hygon processor; the asymmetric cryptographic algorithm is the national standard SM2 algorithm; and the algorithm for encrypting the AI ​​model is the national standard SM4 algorithm.

[0025] In some preferred embodiments, the step of verifying the validity of the remote proof report is performed by the remote proof service, including: downloading the certificate chain corresponding to the trusted execution environment from the official certificate server, verifying the authenticity of the certificate chain using the root certificate, and verifying the validity of the SM2 signature of the remote proof report.

[0026] In some preferred embodiments, after verifying the validity of the remote proof report, the model provider also sends the platform identifier of the trusted execution environment, the public key, and the success status information to the blockchain in the proof storage platform for proof storage.

[0027] In some preferred embodiments, the step of collecting and storing evidence data includes establishing a secure, two-way authenticated channel between a trusted data collection terminal running within the trusted execution environment and the evidence storage platform for transmission.

[0028] The evidence storage data includes at least one or a combination of the following:

[0029] The model deployment storage data includes the remote proof report, model metadata, and model hash value;

[0030] The model inference evidence storage data includes inference session information, inference request and response information, and an inference evidence storage structure signed by the private key in the TEE; the inference evidence storage structure includes at least the hash value of the inference input data, the hash value of the inference output data, and the platform identifier of the TEE;

[0031] System management and maintenance data storage includes control commands, operating parameters, security test results, and system operation logs for the TEE nodes.

[0032] In some preferred embodiments, the evidence storage platform includes an off-chain log platform and a consortium blockchain; the method further includes:

[0033] The detailed inference session information, as well as inference request and response information, are saved to the off-chain log platform.

[0034] The inference evidence storage structure, signed by the private key within the trusted execution environment, is submitted to the consortium blockchain for evidence storage.

[0035] In some preferred embodiments, the step of verifying the credibility of the AI ​​model's operation includes a verification process for at least one inference task, the verification process comprising:

[0036] Receive a verification request, the request containing an identifier of the target inference task;

[0037] Obtain detailed inference data corresponding to the identifier from the off-chain log platform;

[0038] Obtain the signed reasoning and evidence storage structure corresponding to the identifier from the consortium blockchain;

[0039] The digital signature of the signed reasoning notarization structure is verified using the public key corresponding to the TEE platform identifier, which is pre-deposited on the consortium blockchain.

[0040] Compare the hash value of the inference data obtained from the off-chain log platform with the hash value stored in the inference evidence storage structure obtained from the consortium blockchain to see if they are consistent.

[0041] Based on the signature verification result and the hash value comparison result, a comprehensive judgment is made on whether the inference task is trustworthy.

[0042] In some preferred embodiments, the verification process is executed automatically via smart contracts deployed on a consortium blockchain.

[0043] In a second aspect, this invention proposes an AI model runtime protection and trusted evidence storage system, applicable to the method described in any of the first aspects, the system comprising:

[0044] The model provider is configured to encrypt the AI ​​model and, after verifying the validity of the remote proof report, encapsulate the model encryption key with the public key and send the key encapsulation block to the model operator.

[0045] The model operator is configured to generate a key pair for an asymmetric cryptographic algorithm within a trusted execution environment, provide a remote proof report containing the public key to the model provider, and decrypt the key encapsulation block using the private key corresponding to the public key within the trusted execution environment to obtain the model encryption key. The model operator then uses the model encryption key to decrypt the encrypted AI model within the trusted execution environment. The model operator provides inference services to the model user using the decrypted AI model within the trusted execution environment. The private key corresponding to the public key is restricted to the trusted execution environment.

[0046] The evidence storage module is configured to collect evidence storage data during model deployment, model inference, and system operation on the model running side, and the trusted execution environment uses the private key to digitally sign at least part of the evidence storage data, and send the signed evidence storage data to the evidence storage platform for storage.

[0047] The verification module is configured to verify the credibility of the AI ​​model's operation process based on the evidence storage data stored in the evidence storage platform.

[0048] In a third aspect, the present invention provides a computer-readable storage medium storing computer instructions that are executed by the computer to implement the method for protecting the operation and providing trusted evidence of an AI model as described in the first aspect.

[0049] The beneficial effects of this invention are:

[0050] Compared with the prior art, the present invention has the following significant advantages:

[0051] 1. This invention deeply integrates the hardware-level runtime security of the Trusted Execution Environment with the immutable evidence storage capability of blockchain, constructing a dual security system of "trusted runtime environment" + "trusted operation record", thus overcoming the limitations of a single technology.

[0052] 2. Through a process of remote verification, key encapsulation, and decryption in a trusted execution environment, the AI ​​model is ensured to be in a state of encryption or secure memory protection from the moment it leaves the provider until it runs in the target environment. This effectively prevents model leakage and provides strong protection for the intellectual property rights of the model.

[0053] 3. End-to-end trusted traceability: From model deployment, key distribution, inference execution to system operation and maintenance, as well as basic environment and internal operation logs, each key link has corresponding trusted data collected and stored, forming a complete, continuous and tamper-proof evidence chain, which greatly enhances the ability of post-event auditing and accountability.

[0054] 4. Credibility of data source: By deploying the trusted data collection terminal directly within the trusted execution environment, the authenticity and integrity of the data are ensured from the source of data generation, avoiding the risk of logs being maliciously tampered with after generation in traditional solutions, thus laying the foundation for the credibility of the entire evidence storage system.

[0055] 5. Independent verification by third parties: Based on consortium blockchain and smart contracts, any third party can independently verify the authenticity and integrity of reasoning and various log data without trusting a centralized institution.

[0056] 6. Domestic Production and Compliance: It adopts the national cryptographic algorithms (SM2, SM4) and domestically independent and controllable Hygon TEE technology, which complies with the national information security strategy and relevant industry standards, and is suitable for government, finance, judicial and other fields with extremely high requirements for security and compliance. Attached Figure Description

[0057] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0058] Figure 1 This is a flowchart illustrating a method for protecting the operation and providing trusted evidence of an AI model according to an embodiment of the present invention.

[0059] Figure 2 This is a schematic diagram of a specific implementation architecture of an AI model operation protection and trusted evidence storage method provided in an embodiment of the present invention;

[0060] Figure 3 This is a schematic diagram of the computer system structure of the server implementing the methods and system embodiments of this application. Detailed Implementation

[0061] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0062] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0063] To more clearly explain the operational protection and trusted evidence storage method of the AI ​​model of this invention, the following will be combined with... Figure 1 The steps in the embodiments of the present invention will be described in detail below.

[0064] The first embodiment of the present invention provides a method for protecting the operation and providing trusted evidence of an AI model, including steps S10-S60, each step of which is described in detail below:

[0065] Step S10: The model provider encrypts the AI ​​model;

[0066] Step S20: The model operator generates a key pair for an asymmetric cryptographic algorithm within a trusted execution environment and provides a remote proof report containing the public key to the model provider, wherein the private key corresponding to the public key is restricted to the trusted execution environment;

[0067] Step S30: After verifying the validity of the remote proof report, the model provider encapsulates the model encryption key using the public key and sends the key encapsulation block to the model operator.

[0068] In step S40, the model operator uses the private key corresponding to the public key to decrypt the key encapsulation block in the trusted execution environment to obtain the model encryption key, and uses the model encryption key to decrypt the encrypted AI model in the trusted execution environment. The model operator then uses the decrypted AI model in the trusted execution environment to provide inference services to the model user.

[0069] Step S50: On the model running side, evidence storage data during model deployment, model inference and system operation are collected, and the trusted execution environment uses the private key to digitally sign at least part of the evidence storage data, and sends the signed evidence storage data to the evidence storage platform for storage.

[0070] Step S60: Based on the evidence storage data stored in the evidence storage platform, verify the credibility of the AI ​​model operation process.

[0071] This embodiment proposes a trusted data space operation protection and end-to-end trusted evidence storage and verification method for AI models. Its core lies in using the domestic Hygon TEE as the root of trust, verifying the trustworthiness of the environment through remote proof, using national cryptographic algorithms to achieve secure distribution and decryption of model keys, completing model loading and inference within the TEE, and collecting end-to-end operation data in real time through the trusted data acquisition terminal embedded in the TEE, submitting it to the evidence storage platform through a secure channel, and finally achieving third-party verifiable evidence storage and verification through consortium blockchain and smart contracts.

[0072] Specifically, the trusted execution environment is a trusted execution environment based on the domestic Hygon processor; the asymmetric cryptographic algorithm is the national standard SM2 algorithm; and the algorithm for encrypting the AI ​​model is the national standard SM4 algorithm.

[0073] More specifically, the step of verifying the validity of the remote proof report is performed by the remote proof service, including: downloading the certificate chain corresponding to the trusted execution environment from the official certificate server, verifying the authenticity of the certificate chain using the root certificate, and verifying the validity of the SM2 signature of the remote proof report.

[0074] More specifically, after verifying the validity of the remote proof report, the model provider will also send the platform identifier of the trusted execution environment, the public key, and the success status information to the blockchain in the proof storage platform for proof storage.

[0075] More specifically, the step of collecting and storing evidence data includes establishing a secure, two-way authenticated channel between the evidence storage platform and a trusted data collection terminal running within the trusted execution environment for transmission.

[0076] The evidence storage data includes at least one or a combination of the following:

[0077] The model deployment storage data includes the remote proof report, model metadata, and model hash value;

[0078] The model inference evidence storage data includes inference session information, inference request and response information, and an inference evidence storage structure signed by the private key in the TEE; the inference evidence storage structure includes at least the hash value of the inference input data, the hash value of the inference output data, and the platform identifier of the TEE;

[0079] System management and maintenance data storage includes control commands, operating parameters, security test results, and system operation logs for the TEE nodes.

[0080] More specifically, the evidence storage platform includes an off-chain log platform and a consortium blockchain; the method further includes:

[0081] The detailed inference session information, as well as inference request and response information, are saved to the off-chain log platform.

[0082] The inference evidence storage structure, signed by the private key within the trusted execution environment, is submitted to the consortium blockchain for evidence storage.

[0083] More specifically, the steps for verifying the credibility of the AI ​​model's operation include a verification process for at least one inference task, the verification process comprising:

[0084] Receive a verification request, the request containing an identifier of the target inference task;

[0085] Obtain detailed inference data corresponding to the identifier from the off-chain log platform;

[0086] Obtain the signed reasoning and evidence storage structure corresponding to the identifier from the consortium blockchain;

[0087] The digital signature of the signed reasoning notarization structure is verified using the public key corresponding to the TEE platform identifier, which is pre-deposited on the consortium blockchain.

[0088] Compare the hash value of the inference data obtained from the off-chain log platform with the hash value stored in the inference evidence storage structure obtained from the consortium blockchain to see if they are consistent.

[0089] Based on the signature verification result and the hash value comparison result, a comprehensive judgment is made on whether the inference task is trustworthy.

[0090] More specifically, the verification process is executed automatically through smart contracts deployed on the consortium blockchain.

[0091] In conjunction with the above embodiments, the method of the present invention comprises six core parts:

[0092] Part 1: Creating a trusted, secure, end-to-end evidence storage channel;

[0093] Specifically, a two-way authentication secure channel based on the TLS 1.3 protocol can be established between the trusted data acquisition terminal within the Hygon TEE node and the evidence storage center platform. Both parties exchange and verify digital certificates (issued using the national cryptographic algorithm SM2) to ensure the confidentiality, integrity, and two-way authentication of the channel. All evidence storage data is transmitted through this secure channel, preventing man-in-the-middle attacks and data leakage.

[0094] Part Two: Secure Deployment of the Model;

[0095] This section ensures that the AI ​​model is safely loaded only in a verified, trusted TEE environment. The specific process is as follows:

[0096] 1. Model Encryption and Preparation. The model provider uses the national standard SM4 symmetric encryption algorithm to encrypt the original AI model file and metadata, generating an encrypted model file. Simultaneously, the encryption key (KEY) is securely stored locally. The encrypted model file can be submitted to the model deployment party via offline storage media (such as USB flash drive, hard drive, etc.) or stored in the cloud for the model deployment party to download locally.

[0097] 2. Generating SM2 key pair within TEE: The model operator generates an SM2 public-private key pair within the Hygon TEE. The private key is permanently locked within the TEE and cannot be exported.

[0098] 3. Generate and send a remote verification report. The model operator generates a remote verification report within the TEE. This report includes not only the content of the Hygon TEE standard remote verification report (such as platform ID, TEE version number, chip unique ID, signature algorithm, PEK certificate, etc.), but also the SM2 public key generated in the above steps. The entire report is signed using the SM2 private key to prove that the public key indeed originated from this specific TEE. Subsequently, the signed report is sent to the model provider.

[0099] 4. Submit the report to a remote verification service. After receiving the remote verification report, the model provider submits it to a trusted remote verification service.

[0100] 5. Remote Verification. Upon receiving the report, the remote verification service executes a rigorous verification process: First, based on the chip ID in the report, it downloads the corresponding certificate chain from Hygon's official certificate server; then, using the root certificate provided by Hygon, it verifies the authenticity of the certificates in the report (such as the PEK certificate) level by level, and finally verifies the validity of the report signature. If the entire certificate chain verification passes and the signature is valid, it proves that the model's runtime environment is a genuine Hygon trusted execution environment, and that the SM2 public key in the report does indeed come from this trusted TEE. The verification service then returns the "Platform Trusted" result to the model provider. If any step of the verification fails, it returns "Failure".

[0101] 6. Key Encapsulation and Information Uploading to the Blockchain. After receiving the "Platform Trustworthy" verification result, the model provider performs two key operations:

[0102] 1) Key Encapsulation: Using the SM2 public key extracted from the remote proof report, the previously saved model encryption key KEY is encrypted using SM2 to generate a key encapsulation block (KEB). This KEB can only be decrypted by the holder of the corresponding SM2 private key (i.e., the target TEE). The KEB is then sent to the model operator.

[0103] 2) Information Uploading to the Blockchain: The core information of this successful verification, including the platform ID, chip ID, SM2 public key, and the authentication status "successful," will be submitted to the evidence storage center's consortium blockchain for storage. This aims to establish a public and tamper-proof "trusted platform whitelist," providing anchor points for subsequent reasoning and verification.

[0104] 7. Authentication Session Data Submission: The trusted data acquisition terminal within the TEE submits remote proof authentication session data to the evidence storage center. The evidence storage data includes: the remote proof report submitted by the TEE node and the authentication result from the model provider. The evidence storage data is stored both on-chain and off-chain (log center).

[0105] 8. Decryption and recovery key within TEE: After receiving the KEB, the model operator uses its protected SM2 private key within the TEE to decrypt the KEB and recover the model encryption key KEY.

[0106] 9. Secure Model Loading: The TEE uses the recovered model encryption key KEY to decrypt the encrypted model file using SM4 in the TEE's secure memory. The decrypted plaintext AI model is then stored in the TEE's secure memory, ready to execute the inference task.

[0107] 10. Model Metadata Storage: The trusted data acquisition terminal submits the decrypted model metadata and model hash value to the storage center for storage through a secure channel.

[0108] At this point, the model exists only in plaintext form within the security boundary of the target TEE, completing the secure deployment, and the entire process is verifiable and verifiable.

[0109] Part Three: Model Execution Reasoning and Trustworthy Evidence Storage;

[0110] Model users include: model inference clients, data participants, agent APIs, etc. When using the model, the user submits inference data, the model runs inference tasks, outputs inference results and returns them to the user, and simultaneously submits evidence-based data to the evidence-based center. The specific implementation is as follows:

[0111] 1. Establish a secure communication channel: Establish a TLS 1.3 two-way authentication channel between the model user and the inference service agent.

[0112] 2. Sending an inference request: The model user inputs data and transmits it to the inference service agent via a secure channel.

[0113] 3. Decryption request within TEE: The inference service agent decrypts the request within the TEE and submits it to the inference service engine.

[0114] 4. Secure Inference and Return Results: The inference service performs inference calculations within the TEE, and the results are returned to the model user after being encrypted by the proxy.

[0115] 5. Generate trusted evidence storage data: The inference service agent submits the following trusted evidence storage data to the trusted data collection terminal:

[0116] 1) Session Data: Used to record a complete inference task session. Fields include: Session ID, User ID, Session Creation Time, Time of the Last Message in the Session, Session Title, API Key, Client Information (e.g., Client Type, IP Address, User-Agent, etc.), Model Name Used, Model Version, and Model Hash Value.

[0117] 2) Message Data: Used to record a specific inference request and response. Fields include: Request ID, Session ID, Input Data, Output Data, Request Time, and Response Time.

[0118] 3) Evidence stored on the TEE platform: The system generates a structured log for on-chain evidence storage. This log is crucial for verifying the authenticity of the inference. Its content is carefully designed and includes: request message ID, user ID, session ID, hash value of input data, hash value of output data, request time, response time, and platform ID (identifying the TEE platform performing the inference). All content of this log is digitally signed using the SM2 private key within the TEE.

[0119] 6. Submission of Evidence Data: The trusted data collection terminal submits the data to the evidence storage center through a secure channel. The evidence storage center processes the evidence data as follows:

[0120] 1) Reasoning data log storage: including session data and message data, is stored in the log platform of the evidence storage center.

[0121] 2) On-chain storage of signature evidence data: By calling the API of the consortium blockchain node, the structured log of signature evidence storage is submitted to the consortium blockchain network, and the "log storage smart contract" deployed on the chain is responsible for permanently recording it on the blockchain.

[0122] Part Four: Reliable Evidence Storage of TEE Management Control and Safety Testing Information;

[0123] 1. The management module issues control commands to the TEE nodes, such as start and stop commands. The control commands, operating parameters, TEE parameters, command execution results, and exception information are submitted to the trusted data acquisition terminal and then to the evidence storage center through a secure channel.

[0124] 2. Obtain the operating status of TEE nodes and the model through security operation and maintenance detection software, generate security detection operation and maintenance evidence data, and submit it to the evidence storage center through trusted data acquisition terminal.

[0125] Part 5: Collection and Trusted Storage of Basic Environment and Internal Operation Log Information for TEE Nodes;

[0126] 1. Collect basic environment logs using relevant software. The collected logs may include the following content:

[0127] 1) TEE node startup and initialization logs;

[0128] 2) Abnormal exit logs (such as enclave exceptions, memory tampering detection);

[0129] 3) System logs, security logs, audit logs, etc.

[0130] 2. Collect internal operation logs using relevant software. The collected logs may include the following content:

[0131] 1) Initialization log: Information such as model loading success / failure and parameter validation;

[0132] 2) Input / Output Summary: Input data and output result summary;

[0133] 3) Execution status log: inference start / end time;

[0134] 4) Error and exception logs: Insufficient memory, incorrect model format, encryption verification failure, etc.

[0135] 5) Performance metrics: execution time, CPU cycles, memory usage, etc.

[0136] 3. All logs are submitted to the evidence storage center by a trusted data collection terminal to ensure the credibility of the log source.

[0137] Part Six: Verification of End-to-End Evidence Storage Information;

[0138] This section provides third parties with the ability to verify the authenticity and completeness of all stored evidence.

[0139] 1. Initiating a verification request: When any third party wants to verify the trusted evidence information of a certain inference task or operation through the trusted evidence verification client, it can initiate a query request based on the evidence information ID (such as the message ID of the inference request) and the verification type (such as "inference").

[0140] 2. Collaborative Query and Verification by the Evidence Storage Center: The evidence storage center queries the log platform (to obtain detailed data) and the consortium blockchain (to obtain the signed evidence storage records) in parallel based on the evidence storage information ID. Different verification logic is executed according to different verification types.

[0141] The following example, using the model user as the model inference client, illustrates the verification process and business logic:

[0142] a. The verification client initiates a verification request based on the inference message ID, with the verification type being "inference";

[0143] b. The evidence storage center queries the log platform to obtain detailed log information corresponding to the message ID, including complete input data, output data, timestamps, session information, etc.

[0144] c. The evidence storage center constructs a verification request, which calls the "Verification Reasoning Message Smart Contract" deployed on the consortium blockchain via the consortium blockchain API. This smart contract automatically executes the following core logic:

[0145] - Query on-chain evidence storage: Based on the "request message ID" in the verification request, find the corresponding on-chain evidence storage record on the blockchain.

[0146] - Obtain the platform public key: Based on the "Platform ID" in the evidence record, find the SM2 public key corresponding to the platform ID that has been remotely verified from the "Trusted Platform Whitelist" pre-stored on the blockchain.

[0147] - Signature Verification: Using the SM2 public key obtained above, verify the signature field in the on-chain evidence record. If the verification passes, it proves that the evidence record was indeed issued by a trusted TEE platform with the corresponding SM2 private key, i.e., the inference source is trustworthy.

[0148] - Verify data consistency: Calculate the hash values ​​of the input and output data (obtained from the log platform) carried in the verification request, and compare them with the "input data hash" and "output data hash" stored in the on-chain evidence storage record. If they match, it proves that the detailed data queried from the log platform is completely consistent with the summary data of the on-chain evidence storage, that is, the data has not been tampered with.

[0149] - Comprehensive judgment and return: The smart contract only returns "verification successful" when both "signature verification" and "hash comparison" are successful; otherwise, it returns "verification failed" and indicates the reason for the failure (such as invalid signature, hash mismatch, record not found, etc.).

[0150] 3. Return the verification result: The evidence storage center will return the verification result returned by the smart contract, along with the relevant evidence storage details queried from the log platform, to the trusted evidence storage verification client to complete this verification.

[0151] Further, please refer to Figure 2 , Figure 2 The diagram shows a specific implementation architecture of this embodiment, which consists of seven core components: model provider, remote proof service, model operator, model user, TEE manager, evidence storage platform, and trusted evidence storage and verification client.

[0152] 1. Model Provider:

[0153] Model providers are typically AI model development companies or organizations, and their responsibilities include:

[0154] 1) Model Encryption Module: The SM4 algorithm is used to encrypt the AI ​​model and its metadata (model name, version, description, input and output specifications, etc.), generate an .enc file, and securely store the SM4 key in the HSM (Hardware Security Module) or key management service.

[0155] 2) Remote Proof Verification Module: Receives the verification result returned by the remote proof service. If the result is "Platform Trusted", it performs key encapsulation and on-chain operations.

[0156] 3) Key Encapsulation Module: Calls the national cryptographic SM2 encryption interface, uses the SM2 public key extracted from the remote proof report to encrypt the KEY, and generates KEB (Key Encapsulation Block).

[0157] 4) Blockchain operation module: Construct a JSON object containing platform ID, chip ID, SM2 public key, authentication status, and timestamp, and call the consortium blockchain API to write it into the "trusted platform registration contract".

[0158] 2. Remote verification service:

[0159] This service is operated by an authoritative third party, ensuring neutrality and credibility.

[0160] Certificate Chain Verification Module: Based on the chip ID in the report, download the corresponding certificate chain from Hygon's official certificate server; then, using the root certificate provided by Hygon, verify the authenticity of the certificates in the report (such as the PEK certificate) level by level. Successful verification proves that the TEE environment is genuine.

[0161] SM2 signature verification module: After the Hygon certificate chain verification is successful, the SM2 public key in the report is used to verify the signature of the private key in the TEE. If the verification is successful, it proves that the SM2 public key in the report does indeed come from the trusted TEE.

[0162] Once verification is complete, a result indicating "platform trustworthy" or "verification failed" will be returned to the model provider.

[0163] 3. Model Runner (Haiguang TEE Node):

[0164] Deployed within Hygon TEE nodes, running various customized applications, including:

[0165] SM2 Key Generation Module: This module uses the Hygon TEE SDK and Chinese cryptographic algorithms to generate SM2 key pairs. The SM2 private key is locked within the TEE and protected by hardware throughout its lifecycle, while the public key is used for subsequent communication.

[0166] Authentication and Key Receiving Module: Initiates remote authentication and receives the KEB sent by the model provider, and calls the SM2 private key to decrypt and recover the KEY.

[0167] Model decryption module: Reads the encrypted model file stored locally, decrypts it using SM4 using the KEY within the TEE, and loads the plaintext model into the inference service.

[0168] Inference Service Engine: Integrates an AI inference framework to perform model inference within the TEE.

[0169] Inference Service Proxy: Acting as a gateway between the inference service and the external network, it handles TLS connections, request decryption, and result encryption. The proxy itself runs within a TEE (Translation over Environment) to ensure data integrity.

[0170] Log collection module: Responsible for collecting basic environment and internal operation logs of TEE nodes and submitting the collected log data.

[0171] Trusted Data Acquisition Terminal: A core component running within the TEE, responsible for: establishing a TLS 1.3 secure channel with the evidence storage platform; receiving evidence storage data from modules such as inference services, log collection, and system monitoring; signing key evidence storage logs (such as inference signature logs) using an SM2 private key; and submitting data to the evidence storage center through a secure channel. The Trusted Data Acquisition Terminal runs entirely within the TEE, and its code and data are protected by hardware, ensuring that the acquisition process cannot be maliciously tampered with externally, and that the data source is absolutely trustworthy.

[0172] 4. Model users, including various client applications:

[0173] Model inference clients: such as web front-ends and mobile apps, which call the inference API via HTTPS / TLS.

[0174] Data participants, such as banking systems, submit user transaction data for fraud detection.

[0175] Agent API: An automated agent that periodically calls the model for batch inference.

[0176] 5. The TEE administrator is responsible for node operation and maintenance:

[0177] Management module: Allows administrators to send start / stop and other related control commands.

[0178] Security detection and maintenance module: Periodically calls the security detection interface within TEE to obtain indicators such as memory integrity and model loading status, and generates maintenance reports.

[0179] Both management instructions and test results are captured and stored by the trusted data acquisition terminal within the TEE.

[0180] 6. Evidence Storage Center, Evidence Storage Center Consortium Blockchain:

[0181] It adopts domestic consortium blockchain frameworks such as FISCO BCOS.

[0182] Deploy the following core smart contracts:

[0183] TrustedPlatformRegistry: Register with a trusted platform; LogStorageContract: Receive and store evidence logs; VerificationContract: Provide inference verification services.

[0184] The nodes are jointly maintained by regulatory agencies, model providers, and operators to ensure decentralization and trustworthiness.

[0185] Evidence Preservation Center Log Platform:

[0186] Built on Elasticsearch + Kafka, it supports high-throughput log writing and fast querying.

[0187] Stores detailed information such as session data, message data, and operation and maintenance logs.

[0188] 7. Trusted Evidence Verification Client: Provides a web interface or SDK for auditors, regulatory agencies, and users. It supports queries based on message ID, session ID, time range, and other criteria, calls the evidence center API to initiate verification, and displays the verification results and original data.

[0189] Based on the above implementation architecture, the method described in this embodiment will be described in more detail:

[0190] Part 1: Creating a trusted, secure, end-to-end evidence storage channel;

[0191] The trusted data collection terminal within the TEE acts as a TLS client, initiating a connection request to the evidence storage center platform. The evidence storage center acts as the TLS server, and both parties establish a secure communication channel through a two-way TLS 1.3 handshake protocol. During this process, both parties exchange and verify their respective certificates to ensure the confidentiality, integrity, and two-way authentication of the communication. This channel is maintained indefinitely for all subsequent submissions of evidence storage data.

[0192] Part Two: Secure Deployment of the Model;

[0193] Step 1: Model Encryption and Preparation

[0194] 1. The model provider uses the SM4 algorithm to encrypt the model file and metadata, resulting in model.enc;

[0195] 2. The SM4 key (128 bits) is stored in the HSM and marked as ModelKey_001;

[0196] 3. The encrypted model file is submitted to the model operator offline.

[0197] Step 2: Generate an SM2 key pair within the TEE:

[0198] 1. The domestic Hygon server starts the Hygon CSV security virtual machine as a TEE computing node to deploy the model running software;

[0199] 2. Using Hygon's CSV key sealing technology, a key is derived from the machine root key and virtual machine-related information from the Hygon security firmware. This key is stored in a secure storage area within the TEE. This key is used as the private key for asymmetric encryption, denoted as sk. Then, based on this private key, the national cryptographic SM2 algorithm library is called to generate its corresponding public key, denoted as pk.

[0200] Step 3: Generate a remote proof report:

[0201] 1. Call the report retrieval SDK in the Hygon CSV virtual machine to obtain the standard certification report, which includes key information such as platform ID (ID=CSV-8765-20250188), chip ID (CHIP_ID =SN123456), and PEK certificate;

[0202] 2. Attach the pk to the report to create an extended report, Report_ext;

[0203] 3. Use sk to perform an SM2 signature on the hash value of Report_ext to obtain Sig;

[0204] 4. Send {Report_ext, Sig} to the model provider.

[0205] Steps 4-5: Remote verification:

[0206] 1. The model provider forwards {Report_ext, Sig} to the remote proof service;

[0207] 2. Download the PEK certificate chain corresponding to chip ID=SN123456;

[0208] 3. Verify the PEK certificate chain;

[0209] 4. Verify the signature Sig of Report_ext (using Report_ext.pk);

[0210] 5. Return to provider: {"status": "trusted", "id": "CSV-8765-20250188", "chip_id": "SN123456","sm2_pubkey": pk}.

[0211] Step 6: Key Encapsulation and On-Chain Setup

[0212] 1. The model provider uses pk to perform SM2 encryption on the KEY: KEB = sm2_encrypt(pk, KEY);

[0213] 2. Construct the on-chain data: {"platform_id": "CSV-8765-20250188", "chip_id": "SN123456", "sm2_pubkey": pk, "status": "success", "timestamp": 1729483200};

[0214] 3. Call the Evidence Storage Center API and write the TrustedPlatformRegistry contract through the Evidence Storage Center's consortium blockchain SDK.

[0215] Steps 7-10: Model Loading and Verification

[0216] 1. The model runner receives KEB and executes KEY = sm2_decrypt(sk, KEB) within the TEE;

[0217] 2. Decrypt model.enc using the KEY → Obtain the model file and metadata. Submit the model file to the inference service;

[0218] 3. The trusted data acquisition terminal calculates the model hash;

[0219] 4. Submit evidence data, specifically for both on-chain and off-chain methods:

[0220] On-chain:

[0221] {"type": "model_deployment", "platform_id": " CSV-8765-20250188", "model_hash": H_model, "model_name": "fraud_detection_v3", "model_version": "1.0", "timestamp": ...} (signed by SM2).

[0222] Off-chain: Complete remote proof report, authentication result log, and model metadata.

[0223] Part Three: Model Execution Reasoning and Trustworthy Evidence Storage;

[0224] Scenario: A bank's risk control system (the model user) submits a transaction for fraud detection.

[0225] 1. Establish a secure channel: The bank client and the inference service agent establish a TLS 1.3 connection (mutual SM2 certificate authentication).

[0226] 2. Send inference request: The client sends JSON:

[0227] {"req_id": "R1001", "input": {"amount": 50000, "merchant": "XXX",...}};

[0228] 3. TEE internal processing:

[0229] 1) Proxy decryption request → Submitted to the inference engine.

[0230] 2) Engine execution model → Output {"result": "fraud", "score": 0.92}.

[0231] 3) Proxy encryption result → Return to client.

[0232] 4. Generate evidence data:

[0233] 1) Session data:

[0234] {"session_id": "S2001",

[0235] "user_id": "bank_user_001",

[0236] "model_name": "fraud_detection_v3",

[0237] "model_hash": "a1b2c3...",

[0238] "client_ip": "202.101.1.100",

[0239] "start_time": "2025-10-21T10:00:00Z"}

[0240] 2) Message data:

[0241] {"msg_id": "R1001",

[0242] "session_id": "S2001",

[0243] "input": {"amount": 50000, ...},

[0244] "output": {"result": "fraud", ...},

[0245] "req_time": "2025-10-21T10:00:01Z",

[0246] "resp_time": "2025-10-21T10:00:02Z"}

[0247] 3) Signature Evidence Log:

[0248] {"msg_id": "R1001",

[0249] "user_id": "bank_user_001",

[0250] "input_hash": "sha256(input)",

[0251] "output_hash": "sha256(output)",

[0252] "platform_id": "CSV-8765-20250188",

[0253] "timestamp": 1729483202}

[0254] Use the sk signature within the TEE to sign this JSON and obtain Sig_log.

[0255] 5. Submit evidence for recordation:

[0256] 1) Session / message data → Evidence storage center log platform.

[0257] 2) {log_json, Sig_log} → Consortium blockchain LogStorageContract.

[0258] Parts Four and Five: Operation and Maintenance and Log Preservation;

[0259] 1. Management Command Evidence Storage: The administrator sends {"cmd": "stop", "target": "fraud_model"} → executed within the TEE → the collection terminal records {"cmd": "stop", "result": "success", "time": ...} → evidence storage.

[0260] 2. Security Detection and Evidence Storage: Every 5 minutes, the operation and maintenance module calls get_model_status() in the TEE → returns the model running status → generates a report → stores the evidence.

[0261] 3. System log storage: The log module within the TEE captures errors, exceptions, CPU and memory usage information → the data is submitted by the collection terminal → and stored as evidence.

[0262] Part Six: Verification of End-to-End Evidence Storage Information;

[0263] Verification scenario: A regulatory agency suspects that the result of a certain reasoning has been tampered with and initiates verification.

[0264] 1. Initiate a request: The client inputs msg_id = "R1001" and selects the verification type "Inference".

[0265] 2. Processing by the evidence storage center:

[0266] 1) Query the log platform to obtain the complete input / output data of message R1001.

[0267] 2) Construct the verification request: {"msg_id": "R1001", "input": {...}, "output": {...}}.

[0268] 3) Call the consortium blockchain VerificationContract.verify().

[0269] 3. Smart contract execution:

[0270] Step 1: Query the LogStorageContract on the chain to obtain the evidence storage record log_on_chain with msg_id=R1001.

[0271] Step 2: Query the TrustedPlatformRegistry contract from log_on_chain.platform_id = "CSV-8765-20250188" to obtain the corresponding SM2 public key pk_trusted.

[0272] Step 3: Verify log_on_chain.signature using pk_trusted → If it fails, return "Invalid signature".

[0273] Step 4: Calculate the hash H_in_req of the input in the request and compare it with log_on_chain.input_hash; similarly compare the output hash.

[0274] Step 5: If the signature is valid and the hash is consistent, return {"result": "verified", "details":log_on_chain}; otherwise, return the error reason.

[0275] 5. Returned results:

[0276] 1) The evidence storage center will return the verification results and the original evidence storage data to the verification client.

[0277] 2) Client display: Verification successful! This inference was indeed executed by the trusted platform CSV-8765-20250188, and the input and output have not been tampered with.

[0278] Furthermore, a second embodiment of the present invention proposes an AI model operation protection and trusted evidence storage system for executing the above-described AI model operation protection and trusted evidence storage method, comprising:

[0279] The model provider is configured to encrypt the AI ​​model and, after verifying the validity of the remote proof report, encapsulate the model encryption key with the public key and send the key encapsulation block to the model operator.

[0280] The model operator is configured to generate a key pair for an asymmetric cryptographic algorithm within a trusted execution environment, provide a remote proof report containing the public key to the model provider, and decrypt the key encapsulation block using the private key corresponding to the public key within the trusted execution environment to obtain the model encryption key. The model operator then uses the model encryption key to decrypt the encrypted AI model within the trusted execution environment. The model operator provides inference services to the model user using the decrypted AI model within the trusted execution environment. The private key corresponding to the public key is restricted to the trusted execution environment.

[0281] The evidence storage module is configured to collect evidence storage data during model deployment, model inference, and system operation on the model running side, and the trusted execution environment uses the private key to digitally sign at least part of the evidence storage data, and send the signed evidence storage data to the evidence storage platform for storage.

[0282] The verification module is configured to verify the credibility of the AI ​​model's operation process based on the evidence storage data stored in the evidence storage platform.

[0283] It should be noted that the AI ​​model operation protection and trusted evidence storage method and system provided in the above embodiments are only illustrative examples of the above functional module division. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of the present invention can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of the present invention are only for distinguishing the various modules or steps and are not considered as an improper limitation of the present invention.

[0284] A computer-readable storage medium according to a third embodiment of the present invention stores computer instructions, which are executed by the computer to implement the above-described method for protecting the operation and providing trusted evidence of an AI model.

[0285] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the storage device and processing device described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0286] The following is for reference. Figure 3 It shows a schematic diagram of the structure of a computer system used to implement the methods and system embodiments of this application. Figure 3 The server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0287] like Figure 3As shown, the computer system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read Only Memory (ROM) 302 or programs loaded from storage section 308 into Random Access Memory (RAM) 303. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0288] The following components are connected to I / O interface 305: an input section 306 including a keyboard, mouse, etc.; an output section 307 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0289] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

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

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

[0292] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0293] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0294] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A method for protecting the operation and providing trusted evidence of an AI model, characterized in that, include: The model provider encrypts the AI ​​model; The model operator generates a key pair for an asymmetric cryptographic algorithm within a trusted execution environment and provides a remote proof report containing the public key to the model provider, wherein the private key corresponding to the public key is restricted to the trusted execution environment; After verifying the validity of the remote proof report, the model provider uses the public key to encapsulate the model encryption key and sends the key encapsulation block to the model operator. The model operator uses the private key corresponding to the public key to decrypt the key encapsulation block in the trusted execution environment to obtain the model encryption key, and uses the model encryption key to decrypt the encrypted AI model in the trusted execution environment. The model operator uses the decrypted AI model in the trusted execution environment to provide inference services to the model user. On the model execution side, evidence storage data is collected during model deployment, model inference, and system operation. The trusted execution environment uses the private key to digitally sign at least a portion of the evidence storage data and sends the signed evidence storage data to the evidence storage platform for storage. The credibility of the AI ​​model's operation process is verified based on the evidence storage data stored in the evidence storage platform.

2. The method according to claim 1, characterized in that, The trusted execution environment is a trusted execution environment based on the domestic Hygon processor; the asymmetric cryptographic algorithm is the national standard SM2 algorithm; and the algorithm for encrypting the AI ​​model is the national standard SM4 algorithm.

3. The method according to claim 1, characterized in that, The step of verifying the validity of the remote proof report is performed by the remote proof service, including: downloading the certificate chain corresponding to the trusted execution environment from the official certificate server, verifying the authenticity of the certificate chain using the root certificate, and verifying the validity of the SM2 signature of the remote proof report.

4. The method according to claim 1, characterized in that, After verifying the validity of the remote proof report, the model provider will also send the platform identifier of the trusted execution environment, the public key, and the success status information to the blockchain in the proof storage platform for proof storage.

5. The method according to claim 1, characterized in that, The step of collecting and storing evidence data includes establishing a secure, two-way authenticated channel between a trusted data collection terminal running within the trusted execution environment and the evidence storage platform for transmission. The evidence storage data includes at least one or a combination of the following: The model deployment storage data includes the remote proof report, model metadata, and model hash value; The model inference evidence storage data includes inference session information, inference request and response information, and an inference evidence storage structure signed by the private key in the TEE; The inference evidence storage structure includes at least the hash value of the inference input data, the hash value of the inference output data, and the platform identifier of the TEE; System management and maintenance data storage includes control commands, operating parameters, security test results, and system operation logs for the TEE nodes.

6. The method according to claim 5, characterized in that, The evidence storage platform includes an off-chain log platform and a consortium blockchain; the method further includes: The detailed inference session information, as well as inference request and response information, are saved to the off-chain log platform. The inference evidence storage structure, signed by the private key within the trusted execution environment, is submitted to the consortium blockchain for evidence storage.

7. The method according to claim 6, characterized in that, The steps for verifying the credibility of the AI ​​model's operation include a verification process for at least one inference task, the verification process comprising: Receive a verification request, the request containing an identifier of the target inference task; Obtain detailed inference data corresponding to the identifier from the off-chain log platform; Obtain the signed reasoning and evidence storage structure corresponding to the identifier from the consortium blockchain; The digital signature of the signed reasoning notarization structure is verified using the public key corresponding to the TEE platform identifier, which is pre-deposited on the consortium blockchain. Compare the hash value of the inference data obtained from the off-chain log platform with the hash value stored in the inference evidence storage structure obtained from the consortium blockchain to see if they are consistent. Based on the signature verification result and the hash value comparison result, a comprehensive judgment is made on whether the inference task is trustworthy.

8. The method according to claim 7, characterized in that, The verification process is executed automatically through smart contracts deployed on the consortium blockchain.

9. An AI model operation protection and trusted evidence storage system, characterized in that, The system, applicable to the method of any one of claims 1-8, comprises: The model provider is configured to encrypt the AI ​​model and, after verifying the validity of the remote proof report, encapsulate the model encryption key with the public key and send the key encapsulation block to the model operator. The model operator is configured to generate a key pair for an asymmetric cryptographic algorithm within a trusted execution environment, provide a remote proof report containing the public key to the model provider, and decrypt the key encapsulation block using the private key corresponding to the public key within the trusted execution environment to obtain the model encryption key. The model operator then uses the model encryption key to decrypt the encrypted AI model within the trusted execution environment. The model operator provides inference services to the model user using the decrypted AI model within the trusted execution environment. The private key corresponding to the public key is restricted to the trusted execution environment. The evidence storage module is configured to collect evidence storage data during model deployment, model inference, and system operation on the model running side, and the trusted execution environment uses the private key to digitally sign at least a portion of the evidence storage data, and send the signed evidence storage data to the evidence storage platform for storage. The verification module is configured to verify the credibility of the AI ​​model's operation process based on the evidence storage data stored in the evidence storage platform.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The computer-readable storage medium stores computer instructions that are executed by the computer to implement the method for protecting the operation and providing trusted evidence of the AI ​​model as described in any one of claims 1-8.

Images