A multi-level security protection system and method for a service-oriented artificial intelligence model

Abstract

The application relates to the technical field of cross technology of artificial intelligence and information security, and discloses a multi-level security protection system and method of a service-oriented artificial intelligence model. The system comprises a model producer terminal used for enabling a model producer to initiate an identity authentication request to a model security platform and upload an original model file after authentication; a model user terminal used for enabling a model user to initiate an identity authentication request to the model security platform and initiate a model calling request after authentication; and a model security platform used for receiving the original model file uploaded by the model producer terminal, encrypting the original model file, and performing security encapsulation on the model type, model serial number, check value and security token to generate a model security container. A model registration module synchronously generates a globally unique model identity, and the model identity and the model security container are bound and stored after encryption. The application can guarantee the security and credibility of the model from development to retirement.

Description

Technical Field

[0001] This application relates to the field of interdisciplinary technology of artificial intelligence and information security, and in particular to a multi-level security protection system and method for a service-oriented artificial intelligence model. Background Technology

[0002] With the development of deep learning technology, artificial intelligence models have been widely used in fields such as computer vision and natural language processing. Currently, model deployment largely utilizes container technology, but significant shortcomings remain in security protection.

[0003] Existing technologies primarily focus on model performance optimization and static storage security, such as protecting intellectual property rights through model structure obfuscation and encryption. Some solutions attempt to use container technology for model deployment, but lack deep integration with cryptographic techniques.

[0004] Currently, the deployment and application of the model mainly face the following problems: Fragmented model development and supply model: Existing technologies generally adopt a "chimney" development model, with different model file formats, interface definitions, and calling methods. The lack of standardized service encapsulation and on-demand supply mechanism leads to low model reuse rate and low efficiency of downstream application integration.

[0005] The security protection system is inadequate: mainstream solutions mainly focus on the security of model files during static storage or transmission (such as encryption and integrity verification), but there are gaps in the security protection of the entire lifecycle of the model, from registration, authorized use, concurrent calls by multiple model users to secure deregistration. Models are vulnerable to attacks such as replacement and data poisoning during runtime, and there is a lack of a security control mechanism that is deeply integrated with business processes and covers the entire process.

[0006] The application of cryptographic technology is not autonomous and controllable: Existing model security solutions mostly rely on internationally used cryptographic algorithms (such as RSA and AES), which pose supply chain security risks in critical infrastructure and sensitive data processing scenarios, making it difficult to meet the hard requirements for autonomous and controllable cryptographic applications.

[0007] Therefore, how to achieve efficient service provision of artificial intelligence models and build a systematic and controllable security protection capability covering their entire life cycle has become an urgent technical challenge to be solved. Summary of the Invention

[0008] Addressing the industry pain points of chaotic development models, lack of full lifecycle security protection, and insufficient independent controllability of cryptographic technologies in the current artificial intelligence model industry, this application provides a multi-level security protection system and method for service-oriented artificial intelligence models. It constructs a three-tiered progressive security protection system—registration level, application level, and deregistration level—covering the entire lifecycle of artificial intelligence models. Registration-level protection covers model uploading, identity authentication, secure encapsulation, and encrypted storage; application-level protection covers permission verification, secure signature verification, decryption loading, and isolated operation by multiple model users; and deregistration-level protection covers key destruction, data overwriting, and audit solidification. This achieves standardized service-oriented encapsulation of models, unified registration management, and multi-level, independently controllable security protection.

[0009] This application discloses a multi-level security protection system for service-oriented artificial intelligence models, which consists of a model producer terminal, a model user terminal, and a model security platform; The model producer terminal is used for model producers to initiate identity authentication requests to the model security platform and upload the original model file after successful authentication; The model user terminal is used to allow model users to initiate an identity authentication request to the model security platform and, after successful authentication, initiate a model invocation request. The model security platform performs registration-level protection: receiving the original model file uploaded by the model producer terminal, securely encapsulating and encrypting the original model file, and generating and binding a globally unique model identity identifier; performing application-level protection: upon receiving a model call request initiated by the model user terminal, verifying the model user's identity and permissions, and upon successful verification, verifying and decrypting the model security container to obtain the original model file, and allocating an independent Docker container for the model user to load the original model file; and performing deregistration-level protection: when the model reaches the retirement condition, irreversibly destroying the model encryption key, locating and reading the corresponding model security container based on the model identity identifier, and repeatedly overwriting the model security container to achieve irreversible deletion.

[0010] Furthermore, the model security platform includes a commercial cryptography module, a user management module, a model registration module, a model management module, and a model application module; The commercial cryptography module is used to provide cryptographic operation services based on SM2 / SM3 / SM4 algorithms to other modules, including encryption and decryption, signature verification, and digest calculation; the commercial cryptography module is also used to generate model encryption keys based on the platform master key through key derivation functions; The user management module is used to receive the identity authentication request initiated by the model producer terminal or the model user terminal, call the commercial cryptography module to perform two-way identity authentication based on SM2 digital signature, and after successful authentication, assign operation permissions to the model user. The model registration module receives original model files uploaded by authenticated and authorized model producers, forwarded by the user management module. It then calls the commercial cryptography module to calculate the SM3 checksum of the original model file and uses the model security platform's private key to perform an SM2 signature on the SM3 checksum to generate a security token. This security token verifies the model's source credibility and content integrity, generating a globally unique model identity. This identity is used for unique model identification and rapid retrieval; the integrity of its association is guaranteed by the security audit module. The original model file is encrypted using the SM4 algorithm. The encrypted original model file, along with the model type, model serial number, checksum, and security token, is encapsulated in TLV format into a model security container, generating a globally unique model identity. The model security container and the model identity are externally bound and then pushed to the model management module. The model identity is used for indexing and locating; its uniqueness is guaranteed by the platform's generation strategy, and its unforgeability is guaranteed by the SM2 signature mechanism of the security token. The model management module is used to receive the model security container and the bound model identity identifier pushed by the model registration module, call the commercial cryptography module to encrypt and store the model security container using the SM4 algorithm, and save the model identity identifier in plaintext or independent index form for quick retrieval; the model management module is also used to implement access control on model call requests based on the model user role; The model application module is used to receive model call requests initiated by model user terminals and verified for identity and permissions by the user management module. Based on the model identity identifier, it obtains the corresponding model security container from the model management module, calls the commercial cryptography module to perform SM2 signature verification on the security token using the model security platform public key, and after successful signature verification, decrypts the model security container using the SM4 algorithm to obtain the original model file. It then allocates an independent Docker container to the model user to load the original model file.

[0011] Furthermore, the model security platform also includes a policy generation module; The strategy generation module receives user role data pushed by the user management module and uses a sliding time window to statistically analyze the model calling behavior characteristics of model users. The model calling behavior characteristics include calling frequency, calling time period, and historical model calls. Based on the FP-Growth frequent pattern growth algorithm, the module mines the association rules between the user role data, the model calling behavior characteristics, and the model identity identifier, and selects high-confidence association rules from the mined association rules according to a preset confidence threshold. When a model user initiates a model call request, the strategy generation module extracts the user role data and model call behavior features of the current model user, matches them with the high-confidence association rule, and calculates the matching degree. If the matching degree reaches the preset high-confidence standard, the module directly and intelligently recommends a list of models with the model identity corresponding to the high-confidence association rule to the model user. Otherwise, the module switches to a collaborative filtering recommendation algorithm based on model call popularity, selects the global Top-K high-popularity models as a candidate set, and then filters out the models that the user is authorized to access from the candidate set based on the current user role, forming a recommendation list and returning it.

[0012] Furthermore, the model security platform also includes a security audit module and a model deregistration module; The security audit module is used to collect operation logs completed by the user management module, model registration module, model management module, model application module, and model deregistration module based on model identity identifiers in real time. It calculates SM3 digest values ​​for the operation logs, performs SM2 signature solidification using the model security platform's private key, and writes the digest value and signature value to the blockchain. The operation logs include model user login / logout, model upload / download, model call, abnormal termination events, and information such as IP address, timestamp, model identity identifier, operator, inference time, and error code. The model deregistration module is used to receive a model deregistration instruction containing the model identity identifier pushed by the model management module, call the commercial cryptography module to irreversibly destroy the model encryption key, locate the model security container in the storage medium based on the model identity identifier and overwrite it multiple times to achieve irreversible deletion after the model is retired.

[0013] Furthermore, if the model security platform adopts a hardware cryptographic machine accelerated deployment mode, in the hardware cryptographic machine accelerated deployment mode, the model deregistration module is also used to send a key handle destruction instruction to the hardware cryptographic machine to destroy the corresponding key handle, thereby realizing the encrypted destruction of the model.

[0014] Furthermore, the model application module allocates an independent Docker container as a model user session for each model user's call request; the Docker container only mounts a memory copy of the model security container that the model user has the right to access and which has been decrypted after matching the model identity identifier; the Docker container is allocated independent process namespaces, network namespaces, and mount namespaces to achieve strong isolation among multiple model users, and fine-grained resource management is achieved through control groups cgroups; during the model running phase, the Docker container runs on the host machine where the model application module is located, and the host machine communicates with the Docker container through the virtual Ethernet network card veth, and iptables rules are configured to implement whitelist control of outbound access of the Docker container; the container root file system is mounted in read-only mode.

[0015] Furthermore, the model security platform supports three deployment modes: pure software, hardware cryptographic machine acceleration, and lightweight signature verification at edge nodes. In the pure software deployment mode, the commercial cryptography module is deployed in the operating system kernel as a dynamic link library. The private key of the model security platform is periodically injected into memory by the key management service and is automatically cleared after the session times out. The user management module, model registration module, model management module, model application module, policy generation module, security audit module, and model deregistration module are all deployed in the same server cluster as microservices. In the hardware cryptographic machine accelerated deployment mode, the commercial cryptographic module is deployed on the host machine and connected to the dedicated server cryptographic machine via the PCI-E interface. The core cryptographic operations of SM2 / SM3 / SM4 are offloaded to the hardware cryptographic machine for execution. The private key of the model security platform is pre-installed in the security chip of the hardware cryptographic machine. The deployment method of the remaining business modules is the same as that of the pure software mode. The remaining business modules include user management module, model registration module, model management module, model application module, policy generation module, security audit module, and model deregistration module. In the lightweight signature verification deployment mode of edge nodes, a distributed architecture is adopted, in which the central cloud platform generates tokens and the edge verifies signatures locally. The central cloud platform is the cloud-based deployment form of the architecture, which is responsible for unified identity authentication, generation and management of model security containers, and issuance of security tokens. The edge nodes, as lightweight terminals, only have a built-in lightweight cryptographic proxy library and only complete the SM2 signature verification of security tokens and model decryption operations locally. They do not carry the complex business management functions of the central cloud platform and are suitable for large-scale edge computing scenarios.

[0016] This application also discloses a multi-level security protection method for service-oriented artificial intelligence models, applicable to the aforementioned multi-level security protection system for service-oriented artificial intelligence models, comprising: Step 1: Model Registration: The model producer initiates an identity authentication request to the user management module through the model producer terminal. After successful two-way identity authentication based on SM2 digital signature, the original model file is uploaded through an encrypted channel. The model registration module receives the original model file and completes the integrity verification. It calls the commercial cryptography module to calculate the SM3 checksum of the original model file, uses the private key of the model security platform to perform SM2 signature on the checksum to generate a security token, and encrypts the original model file using the SM4 algorithm. The encrypted original model file, along with the model type, model serial number, checksum, and security token, is encapsulated into a model security container. A globally unique model identity identifier is generated synchronously. The model security container is bound to the model identity identifier and pushed to the model management module. The model management module encrypts and stores the model security container and synchronizes the model identity identifier to the model application module, policy generation module, security audit module, and model deregistration module. Step 2: Model Application: The model user initiates an authentication request to the user management module through the model user terminal. After successful authentication, the user initiates a model invocation request to the model application module. The model application module calls the user management module to verify the identity and permissions of the requesting model user. After successful verification, the module calls the policy generation module to generate and return a candidate model recommendation list based on the model user's model invocation behavior characteristics and pre-generated high-confidence association rules. After the model user selects a model, the model application module obtains the corresponding model security container from the model management module according to the model identity identifier. The module calls the commercial cryptography module to perform SM2 signature verification on the security token using the model security platform's public key. After successful signature verification, the module decrypts the model security container using the SM4 algorithm to obtain the original model file. The module then allocates an independent Docker container to the model user to load the original model file. Step 3: Model Deregistration: When a model reaches the retirement conditions, the model management module pushes a deregistration instruction containing the model's identity identifier to the model deregistration module; the model deregistration module calls the commercial cryptography module to irreversibly destroy the model encryption key, locates the model security container in the storage medium based on the model's identity identifier, and performs multiple overwrites to achieve irreversible deletion of the model.

[0017] Furthermore, after step 3, the following steps are also included: The security audit module collects operation logs based on model identity identifiers from each module in the entire process of model registration, application, and deregistration in real time. It performs SM3 digest calculation and SM2 signature solidification on the operation logs and writes the digest value and signature value into the blockchain.

[0018] Furthermore, in step 1, a one-model-one-key strategy is adopted when encrypting the original model file with SM4; the SM4 encryption key of each model is independently derived from the master key of the model security platform through a key derivation function based on SM3, ensuring that even if the master key is leaked, it is impossible to reverse derive the encryption key of the historical model; the master key is only used for key derivation and does not directly participate in the encryption of model data. In step 2, the Docker container is allocated an independent process namespace, network namespace and mount namespace, and the container session is set with a timeout. After the timeout, the container instance is automatically destroyed and the hardware memory resources are released. In step 3, if the hardware cryptographic machine accelerated deployment mode is adopted, a key handle destruction instruction is sent to the hardware cryptographic machine simultaneously to destroy the corresponding key handle; In step 3, the model encryption key is derived from the model security platform master key through a key derivation function based on SM3. The derivation process introduces the model identity and the current date as derivation factors, and generates a 128-bit SM4 encryption key through iterative calculation using the SM3 hash algorithm.

[0019] Due to the adoption of the above technical solution, this application has the following advantages: 1. By standardizing and encapsulating models into services and designing unified interfaces, the heterogeneity differences of underlying models are eliminated, enabling unified management and invocation of models, reducing the complexity of model integration, and improving model reusability and system adaptability.

[0020] 2. Deeply integrate password protection with the entire process of model registration, storage, application, and deregistration to form a three-level progressive security protection mechanism, which improves the confidentiality, integrity, and availability of the model throughout its lifecycle and reduces the risk of the model being illegally stolen or tampered with.

[0021] 3. The SM2, SM3, and SM4 national cryptographic algorithms are adopted throughout the entire process of model security protection to achieve independent control of cryptographic technology, meet relevant security standards, and improve system security and trustworthiness.

[0022] 4. A lightweight containerized isolation and multi-model user independent operation mechanism is adopted to achieve environment isolation and resource control between different users, prevent unauthorized access and data leakage, and improve the security of the model running environment.

[0023] 5. By analyzing user behavior and mining model association rules, we can achieve intelligent model recommendation and efficient retrieval, improve model query and retrieval efficiency, and optimize the overall system performance.

[0024] 6. Supports multiple deployment modes, adaptable to application scenarios with different security levels, performance requirements, and deployment locations, improving the system's scalability and scenario adaptability. Attached Figure Description

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

[0026] Figure 1 This is a schematic diagram of the overall architecture of a multi-level security protection system for a service-oriented artificial intelligence model according to an embodiment of this application; Figure 2 This is a flowchart illustrating the generation and encapsulation process of the model security container in an embodiment of this application. Detailed Implementation

[0027] The present application will be further described in conjunction with the accompanying drawings and embodiments. The described embodiments are only some, not all, of the embodiments of the present application. All other embodiments obtained by those skilled in the art should fall within the protection scope of the embodiments of the present application.

[0028] See Figure 1 This application provides an embodiment of a multi-level security protection system for service-oriented artificial intelligence models, which consists of a model producer terminal, a model user terminal, and a model security platform; The model producer terminal is used for model producers to initiate identity authentication requests to the model security platform and upload the original model file after successful authentication; The model user terminal is used to allow model users to initiate an identity authentication request to the model security platform and, after successful authentication, initiate a model invocation request. The model security platform performs registration-level protection: receiving the original model file uploaded by the model producer terminal, securely encapsulating and encrypting the original model file, and generating and binding a globally unique model identity identifier; performing application-level protection: upon receiving a model call request initiated by the model user terminal, verifying the model user's identity and permissions, and upon successful verification, verifying and decrypting the model security container to obtain the original model file, and allocating an independent Docker container for the model user to load the original model file; and performing deregistration-level protection: when the model reaches the retirement condition, irreversibly destroying the model encryption key, locating and reading the corresponding model security container based on the model identity identifier, and repeatedly overwriting the model security container to achieve irreversible deletion.

[0029] Optionally, the model security platform includes a commercial cryptography module, a user management module, a model registration module, a model management module, and a model application module; The commercial cryptography module is used to provide other modules with cryptographic operation services based on the SM2 elliptic curve public key cryptography algorithm, SM3 cryptographic hash algorithm, and SM4 block cipher algorithm (hereinafter collectively referred to as SM2 / SM3 / SM4 algorithms) issued by the State Cryptography Administration, including encryption and decryption, signature verification, and digest calculation; the commercial cryptography module is also used to generate model encryption keys based on the platform master key through key derivation functions; The user management module is used to receive the identity authentication request initiated by the model producer terminal or the model user terminal, call the commercial cryptography module to perform two-way identity authentication based on SM2 digital signature, and after successful authentication, assign operation permissions to the model user. The model registration module receives original model files uploaded by authenticated and authorized model producers, forwarded by the user management module. It then calls the commercial cryptography module to calculate the SM3 checksum of the original model file and uses the model security platform's private key to perform an SM2 signature on the SM3 checksum to generate a security token. This security token verifies the model's source credibility and content integrity, generating a globally unique model identity. This identity is used for unique model identification and rapid retrieval; the integrity of its association is guaranteed by the security audit module. The original model file is encrypted using the SM4 algorithm. The encrypted original model file, along with the model type, model serial number, checksum, and security token, is encapsulated in TLV format into a model security container, generating a globally unique model identity. The model security container and the model identity are externally bound and then pushed to the model management module. The model identity is used for indexing and locating; its uniqueness is guaranteed by the platform's generation strategy, and its unforgeability is guaranteed by the SM2 signature mechanism of the security token. The model management module is used to receive the model security container and the bound model identity identifier pushed by the model registration module, call the commercial cryptography module to encrypt and store the model security container using the SM4 algorithm, and save the model identity identifier in plaintext or independent index form for quick retrieval; the model management module is also used to implement access control on model call requests based on the model user role; The model application module is used to receive model call requests initiated by model user terminals and verified for identity and permissions by the user management module. Based on the model identity identifier, it obtains the corresponding model security container from the model management module, calls the commercial cryptography module to perform SM2 signature verification on the security token using the model security platform public key, and after successful signature verification, decrypts the model security container using the SM4 algorithm to obtain the original model file. It then allocates an independent Docker container to the model user to load the original model file.

[0030] Optionally, the model security platform further includes a policy generation module; The strategy generation module receives user role data pushed by the user management module and uses a sliding time window to statistically analyze the model calling behavior characteristics of model users. The model calling behavior characteristics include calling frequency, calling time period, and historical model calls. Based on the FP-Growth frequent pattern growth algorithm, the module mines the association rules between the user role data, the model calling behavior characteristics, and the model identity identifier, and selects high-confidence association rules from the mined association rules according to a preset confidence threshold. When a model user initiates a model call request, the strategy generation module extracts the user role data and model call behavior features of the current model user, matches them with the high-confidence association rule, and calculates the matching degree. If the matching degree reaches the preset high-confidence standard, the module directly and intelligently recommends a list of models with the model identity corresponding to the high-confidence association rule to the model user. Otherwise, it switches to a collaborative filtering recommendation algorithm based on model call popularity, selects the global Top-K high-popularity models as a candidate set, and then filters out the models that the user is authorized to access from the candidate set based on the current user role, forming a recommendation list and returning it.

[0031] Optionally, the model security platform further includes a security audit module and a model deregistration module; The security audit module is used to collect operation logs completed by the user management module, model registration module, model management module, model application module, and model deregistration module based on model identity identifiers in real time. It calculates SM3 digest values ​​for the operation logs, performs SM2 signature solidification using the model security platform's private key, and writes the digest value and signature value to the blockchain. The operation logs include model user login / logout, model upload / download, model call, abnormal termination events, and information such as IP address, timestamp, model identity identifier, operator, inference time, and error code. The model deregistration module receives a model deregistration command containing the model's identity identifier from the model management module, invokes the commercial cryptography module to irreversibly destroy the model encryption key, locates the model security container in the storage medium based on the model's identity identifier, and performs multiple overwrites to achieve irreversible deletion of the model after retirement. Due to the adoption of a 'one model, one key' derivation strategy, destroying the model encryption key only affects the currently deregistered model and does not affect the model security platform master key or the keys of other active models, thus achieving fine-grained key lifecycle management.

[0032] Optionally, if the model security platform adopts a hardware cryptographic machine accelerated deployment mode, in the hardware cryptographic machine accelerated deployment mode, the model deregistration module is also used to send a key handle destruction instruction to the hardware cryptographic machine to destroy the corresponding key handle, thereby realizing the encrypted destruction of the model.

[0033] Optionally, the model application module allocates an independent Docker container as a model user session for each model user's call request; the Docker container only mounts a decrypted memory copy of the model security container that the model user has the right to access and which has been matched with the model identity identifier; the Docker container is allocated independent process namespaces, network namespaces, and mount namespaces to achieve strong isolation among multiple model users, and fine-grained resource management is achieved through control groups cgroups; during the model runtime phase, the Docker container runs on the host machine where the model application module is located, and the host machine communicates with the Docker container through a virtual Ethernet interface card veth, and iptables rules are configured to implement outbound access whitelist management for the Docker container; the container root file system is mounted in read-only mode. Compared with traditional virtual machine isolation schemes, the Docker container scheme adopted in this application can achieve millisecond-level startup and near-zero performance loss, fully meeting the elastic scaling and real-time response requirements in AI model service scenarios.

[0034] Optionally, the model security platform supports three deployment modes: pure software, hardware cryptographic machine acceleration, and lightweight signature verification at edge nodes. In the pure software deployment mode, the commercial cryptography module is deployed in the operating system kernel as a dynamic link library. The private key of the model security platform is periodically injected into memory by the key management service and is automatically cleared after the session times out. The user management module, model registration module, model management module, model application module, policy generation module, security audit module, and model deregistration module are all deployed in the same server cluster as microservices. In the hardware cryptographic machine accelerated deployment mode, the commercial cryptographic module is deployed on the host machine and connected to the dedicated server cryptographic machine via the PCI-E interface. The core cryptographic operations of SM2 / SM3 / SM4 are offloaded to the hardware cryptographic machine for execution. The private key of the model security platform is pre-installed in the security chip of the hardware cryptographic machine. The deployment method of the remaining business modules is the same as that of the pure software mode. The remaining business modules include user management module, model registration module, model management module, model application module, policy generation module, security audit module, and model deregistration module. In the lightweight signature verification deployment mode of edge nodes, a distributed architecture is adopted, in which the central cloud platform generates tokens and the edge verifies signatures locally. The central cloud platform is the cloud-based deployment form of the architecture, which is responsible for unified identity authentication, generation and management of model security containers, and issuance of security tokens. The edge nodes, as lightweight terminals, only have a built-in lightweight cryptographic proxy library and only complete the SM2 signature verification of security tokens and model decryption operations locally. They do not carry the complex business management functions of the central cloud platform and are suitable for large-scale edge computing scenarios.

[0035] This application also provides an embodiment of a multi-level security protection method for service-oriented artificial intelligence models, applicable to the multi-level security protection system for service-oriented artificial intelligence models described in the above embodiments, comprising: Step 1: Model Registration: The model producer initiates an identity authentication request to the user management module through the model producer terminal. After successful two-way identity authentication based on SM2 digital signature, the original model file is uploaded through an encrypted channel. The model registration module receives the original model file and completes the integrity verification. It calls the commercial cryptography module to calculate the SM3 checksum of the original model file, uses the private key of the model security platform to perform SM2 signature on the checksum to generate a security token, and encrypts the original model file using the SM4 algorithm. The encrypted original model file, along with the model type, model serial number, checksum, and security token, is encapsulated into a model security container. A globally unique model identity identifier is generated synchronously. The model security container is bound to the model identity identifier and pushed to the model management module. The model management module encrypts and stores the model security container and synchronizes the model identity identifier to the model application module, policy generation module, security audit module, and model deregistration module. Step 2: Model Application: The model user initiates an authentication request to the user management module through the model user terminal. After successful authentication, the user initiates a model invocation request to the model application module. The model application module calls the user management module to verify the identity and permissions of the requesting model user. After successful verification, the module calls the policy generation module to generate and return a candidate model recommendation list based on the model user's model invocation behavior characteristics and pre-generated high-confidence association rules. After the model user selects a model, the model application module obtains the corresponding model security container from the model management module according to the model identity identifier. The module calls the commercial cryptography module to perform SM2 signature verification on the security token using the model security platform's public key. After successful signature verification, the module decrypts the model security container using the SM4 algorithm to obtain the original model file. The module then allocates an independent Docker container to the model user to load the original model file. Step 3: Model Deregistration: When a model reaches the retirement conditions, the model management module pushes a deregistration instruction containing the model's identity identifier to the model deregistration module; the model deregistration module calls the commercial cryptography module to irreversibly destroy the model encryption key, locates the model security container in the storage medium based on the model's identity identifier, and performs multiple overwrites to achieve irreversible deletion of the model.

[0036] Optionally, after step 3, the method further includes: The security audit module collects operation logs based on model identity identifiers from each module in the entire process of model registration, application, and deregistration in real time. It performs SM3 digest calculation and SM2 signature solidification on the operation logs and writes the digest value and signature value into the blockchain.

[0037] Optionally, in step 1, SM4 encryption adopts a one-model-one-key strategy. The encryption key for each model is independently derived from the platform master key through a key derivation function (KDF) based on SM3, and generated through multiple rounds of iterative calculations using SM3. The master key is stored in a hardware security module or a key management service (KMS) and is only used for key derivation operations, without directly participating in model data encryption and decryption. Even if the master key is leaked in extreme cases, since the derivation factors of each model key contain independent random salt values, it is impossible to reverse-construct the historical model encryption key, thus ensuring the substantial independence of one model, one key. In step 2, the Docker container is allocated an independent process namespace, network namespace and mount namespace, and the container session is set with a timeout. After the timeout, the container instance is automatically destroyed and the hardware memory resources are released. In step 3, if the hardware cryptographic machine accelerated deployment mode is adopted, a key handle destruction instruction is sent to the hardware cryptographic machine simultaneously to destroy the corresponding key handle; In step 3, the model encryption key is derived from the model security platform master key through a key derivation function based on SM3. The KDF conforms to the GM / T 0003.4-2012 standard "SM2 Elliptic Curve Public Key Cryptography Algorithm Part 4: Public Key Encryption Algorithm". The derivation process introduces the model identity identifier and the current date as derivation factors, and generates a 128-bit SM4 encryption key through iterative calculation using the SM3 hash algorithm, realizing one key per model.

[0038] This application innovatively integrates service-oriented architecture with proprietary commercial cryptographic technology. Through a three-tiered progressive protection mechanism of "registration level, application level, and deregistration level," it achieves standardized on-demand supply and full lifecycle security management of models. This fills the gaps in existing technologies in dynamic security protection of models, deep algorithm integration, and fine-grained isolation of multiple model users. It ensures the security and reliability of artificial intelligence models throughout the entire process from development to retirement, providing core technical support for the large-scale and secure implementation of artificial intelligence technology.

[0039] For ease of understanding, this application provides a more specific embodiment. The following embodiment is a specific implementation of this application and does not constitute a limitation on the scope of protection of the claims: Example 1: The multi-level security protection system for service-oriented artificial intelligence models provided in this application is composed of model producer terminals, model user terminals, and a model security platform. The model security platform is deployed in the cloud or data center, adopts a microservice architecture design, and has high scalability, high availability, and high security. It integrates eight core functional modules, each with independent functions and collaborative linkage, forming a full-process security control system. Commercial cryptographic module: Provides cryptographic operation services such as encryption and decryption, signature verification, and digest calculation based on SM2 / SM3 / SM4 algorithms, providing independent and controllable cryptographic technology support for the entire system; User Management Module: Responsible for user registration, two-way authentication based on the SM2 algorithm, role-based hierarchical authorization, and permission lifecycle management to achieve trusted control over user identity; Model registration module: responsible for the security review of models, the encapsulation of secure data formats based on algorithms, the generation of secure model containers and the triggering of the platform to generate unforgeable model identity identifiers, thereby ensuring the credibility of the model's origin; Model Management Module: Responsible for the encrypted storage of model algorithms, the formulation and management of access control policies, and the control of model version iteration, so as to achieve secure model storage and controllable access; Model application module: responsible for model instantiation and loading, lightweight containerized isolation of multiple model users, real-time runtime monitoring and exception alarms, to achieve safe and efficient model operation; Model deregistration module: responsible for the secure destruction of models, destruction of encryption keys, and overwriting of storage media, achieving irreversible deletion of models after retirement; Policy generation module: Based on user behavior analysis and frequent pattern mining, dynamically generate intelligent recommendation policies and access control policies for the model, improving model calling efficiency and protection accuracy; Security audit module: responsible for collecting operation logs throughout the entire process, solidifying algorithm signatures, tracing and auditing security incidents, and realizing the traceability and immutability of operation behavior.

[0040] Core security mechanism: algorithm-based model secure data encapsulation.

[0041] To address the issues of reliable model source, complete content, and confidential storage, this application proposes a model secure data encapsulation format based on SM2 / SM3 / SM4 algorithms. The standardized encapsulation process, executed by the model registration module, forms a unified model security container consisting of an encrypted payload and a plaintext security header. The specific steps are as follows: Step S1: Receive the original model binary stream (M). The model producer uploads the original artificial intelligence model file through the encrypted channel via the terminal. The platform completes the initial verification of file integrity. Step S2: Calculate the model check value (H). Call the SM3 hash algorithm interface of the commercial cryptography module to perform irreversible digest calculation on the model file and generate a 256-bit unique check value. The formula is: H=SM3(M). Step S3: Generate a security token. Call the SM2 elliptic curve signature algorithm and use the platform-specific private key (SK_P) to digitally sign the verification value (H) to generate an unforgeable and tamper-proof security token. The formula is: Token=SM2_Sign(SK_P,H). Step S4: Encapsulate the model security container. The model data (E_M) encrypted by the SM4 algorithm, along with the model type (T), model serial number (ID), checksum (H), and security token (Token), are encapsulated into a unified model security container in TLV format. The original model file is encrypted with SM4 as the ciphertext payload, i.e., the model entity. The remaining fields form a security header in plaintext form, achieving an integrated encapsulation that is "verifiable, encryptable, and identifiable". The encapsulated data structure is shown in Table 1.

[0042] Table 1. Encapsulated Data Structure

[0043] Multi-level security protection process: This application constructs a three-tiered, progressive security protection process—registration level, application level, and deregistration level—deeply binding algorithms with business processes to achieve layered protection throughout the model's entire lifecycle, providing comprehensive and seamless control. Registration-level protection: After two-way authentication based on SM2 digital signature, the model producer uploads the model through an encrypted channel; the model registration module performs a security audit on the model, and after passing the audit, executes the above-mentioned secure data encapsulation process. While encapsulating the model security container, a globally unique model identity identifier is generated simultaneously. The model identity identifier is bound to the model security container and stored together.

[0044] Application-level protection: After a model user initiates a call request, the model application module first uses the platform's public key to perform SM2 verification on the security token to verify that the model has not been tampered with and that its source is legitimate. After the verification is successful, the model is decrypted and loaded in an independent Docker container using the SM4 algorithm. Strong isolation of model users in terms of network and file system is achieved through Linux namespaces, and fine-grained management of resource usage is achieved through cgroups to prevent cross-influence and attacks between multiple model users.

[0045] Deregistration-level protection: After the model reaches the retirement conditions, the model deregistration module performs multi-dimensional secure destruction operations: irreversibly destroying the model encryption key, and repeatedly overwriting the model security container in the storage medium to achieve unrecoverable deletion of data; if a hardware cryptographic machine solution is adopted, the key handle is further destroyed to achieve "encrypted destruction", fundamentally preventing the retired model from being illegally recovered and used.

[0046] Intelligent policy generation and strong isolation mechanism for multiple model users: Intelligent Strategy Generation: The strategy generation module incorporates a model user behavior analysis engine and a model association rule base. It uses a sliding time window (default 24 hours, dynamically adjustable from 12 to 72 hours) to statistically analyze model user behavior characteristics, including call frequency, call time period, and historical called models. Based on the Frequent Pattern Growth (FP-Growth) algorithm, it mines association rules between model user role, call time period, historical model type, and model identity, generating rules in the form of "{Model User Role: Algorithm Engineer, Call Time Period: 09-12, The module uses a high-confidence association rule that is set to "Historical Type: NLP" → "{Model Identity: BERT-base}". When a user initiates a model call request, this module extracts the user's role data and model call behavior characteristics in real time, matches them with the high-confidence association rule, and calculates the matching degree. If the matching degree exceeds a threshold (e.g., 85%), it directly and intelligently recommends a list of models with the model identity corresponding to the high-confidence association rule to the user. Otherwise, it switches to a collaborative filtering recommendation algorithm based on model call popularity, selects the global Top-K high-popularity models as a candidate set, and then filters out the models that the user is authorized to access from the candidate set based on the current user role, forming a recommendation list and returning it to achieve intelligent and efficient model calling.

[0047] Strong isolation for multiple model users: Lightweight virtualization technology is used to achieve strong isolation at the instance level for multiple model users. An independent Docker container is allocated to each model user session. The container only mounts a decrypted memory copy of the model security container that the model user has the right to access, preventing cross-model user data access. The host machine and the container communicate using a veth virtual network interface card, and iptables rules are configured to implement whitelist control for container outbound access (only allowing connections to specified endpoints). The container root file system is mounted in read-only mode to prevent malicious programs or runtime processes from tampering with the container's underlying file system, enhancing environmental integrity. Model user isolation is achieved from multiple dimensions such as environment, network, and file system, reducing the side-channel attack surface to a zero shared memory area.

[0048] This application achieves significant progress in model reuse efficiency, full lifecycle security, cryptographic security, multi-model user isolation, and scenario adaptability through service-oriented encapsulation, deep algorithm integration, three-level protection, and intelligent isolation mechanisms. Model reuse efficiency is greatly improved: standardized encapsulation enables "plug and play", the integration cycle is shortened by 60%, and the rate of repeated development is reduced from 40% to 12%.

[0049] Full lifecycle security loop: Three-level protection covers the entire process of registration, application, and deregistration, resisting more than 90% of mainstream attacks and reducing risks by 90%.

[0050] Fully autonomous and controllable process: SM2 / SM3 / SM4 are deeply integrated into business processes, halving the key length and improving signature verification efficiency by 30%.

[0051] Strong isolation and efficient invocation for multi-model users: Containerized isolation + behavior-aware recommendation, hit rate of 82%, response time reduced by 37%, and zero side-channel attack surface.

[0052] Flexible adaptation to multiple scenarios: Supports three deployment modes: pure software, hardware acceleration, and edge signature verification, improving horizontal scalability by two orders of magnitude.

[0053] This embodiment is a basic software-based implementation solution, suitable for scenarios with low to medium security levels and conventional performance requirements (such as the development of general artificial intelligence models and the deployment of intelligent applications for small and medium-sized enterprises). It features low deployment cost, convenient implementation, and strong scalability.

[0054] The hardware foundation of this embodiment consists of a server cluster and a distributed storage array. The user management module, model registration module, model management module, model application module, policy generation module, security audit module, and model deregistration module of the model security platform are all deployed in the same server cluster in the form of microservices. The implementation details of the key modules are as follows: Commercial cryptographic module: Deployed in the operating system kernel as a dynamic link library, encapsulating the SM2 (256-bit prime field curve, GM / T 0003.1-2012), SM3 (256-bit hash value, GM / T 0004-2012), and SM4 (128-bit block length, GM / T 0002-2012) algorithm interfaces conforming to national standards; the module does not store persistent keys internally, but only acts as a cryptographic operation proxy. The platform's master private key is periodically injected into memory through the Key Management Service (KMS) and is automatically cleared after the session times out to prevent key leakage.

[0055] User management module: integrates with PostgreSQL + relational database; during user registration, the password is stored after being hashed with SM3 salt (salt length ≥ 16 bytes, randomly generated) to eliminate the risk of plaintext storage; during login, challenge-response two-way authentication based on SM2 digital signature is adopted, with a challenge random number length of 256 bits and a validity period of ≤ 5 minutes to prevent replay attacks.

[0056] Model registration module: according to Figure 2 The encapsulation process securely encapsulates the uploaded model, and the resulting secure model container is stored in the MinIO distributed object storage cluster (using a 4+2 erasure coding redundancy strategy) to ensure high availability and data recovery capabilities for model storage.

[0057] Model application module: integrates the Docker LTS engine; upon receiving a model call request, it pulls an encrypted container from object storage, verifies and decrypts the signature, and mounts it to a temporary container in read-only mode. It restricts outbound access to the container through the veth virtual network interface (by configuring a whitelist of outbound access to the container through iptables rules, allowing only connections to the specified inference result receiving end), thereby achieving network isolation for model users.

[0058] Security audit module: Real-time collection of operation logs throughout the entire process, instant calculation of SM3 digests of the logs and signing and solidification using the platform's private key, and then writing them into the blockchain to achieve the immutability and traceability of the logs and prevent repudiation afterward.

[0059] Model registration process: Model producers upload raw model files such as ResNet-50 (PyTorch format, approximately 98MB) via an HTTPS (TLS 1.3) encrypted channel. The model registration module calls the commercial cryptography module to calculate the SM3 digest (takes 45±5ms) and generate the SM2 signature token (takes 12±3ms). The original model file is encrypted using the SM4 algorithm (in this embodiment, CBC mode is used, and a 16-byte IV is randomly generated and stored together with the ciphertext). The SM4 encryption key is obtained by the platform master key via HKDF. SHA256 derivation, the derivation process introduces the model identity and the current date as derivation factors to achieve one model, one key; The model registration module generates a globally unique and unforgeable model identity identifier, and the platform returns a registration success response along with this model identity identifier.

[0060] Model invocation process: Model users submit an access token in JWT format (containing user ID, permission role, and validity period, which is 30 minutes by default) to initiate a model call request; The model application module verifies the JWT signature and user permissions, and calls the strategy generation module to obtain the model preloading strategy. Pull the model encryption container from object storage, complete SM2 signature verification using the platform public key (takes 8±2ms), and decrypt the model using the SM4 algorithm (throughput 800±50Mbps). Start an independent Docker container loading model, assign an independent PID, Network, and Mount namespace to the container, and return a RESTful API call endpoint; The default timeout for container sessions is 30 minutes (configurable from 15 minutes to 4 hours). After the timeout, the container instance is automatically destroyed and hardware memory resources are released (e.g., by clearing the memory cache through GPU management tools) to prevent resource occupation and session hijacking.

[0061] Security audit process: The security audit module collects four core events in real time: user login / logout, model upload / download, model invocation, and abnormal termination. It records key information about each event (IP address, timestamp, model identity, operator, inference time, error code, etc.). Every 10 minutes, an audit digest block is generated using the formula: AuditBlock_N=SM3(Timestamp||EventCount||PreviousBlockHash||EventListHash). The digest block is then signed using the SM2 algorithm: Signature_N=SM2_Sign(SK_P,AuditBlock_N). The signed audit digest block Signature_N is written to the blockchain, enabling full-process traceability.

[0062] The core parameters of this embodiment meet network security requirements, and the specific settings and explanations are shown in Table 2.

[0063] Table 2 Specific Settings and Explanations

[0064] Example 2: Hardware cryptographic machine acceleration (preferred example): This embodiment is a preferred implementation for high security and high performance requirements, suitable for scenarios with extremely high requirements for cryptographic efficiency and security, such as financial risk control, target recognition, and core government systems. Based on Embodiment 1, this embodiment directly connects the commercial cryptographic module to a dedicated server cryptographic machine via a PCI-E 3.0 x8 interface, constructing a hardware cryptographic machine accelerated deployment architecture.

[0065] Differences from Example 1: Hardware-based cryptographic operations: Commercial cryptographic modules connect to the host machine deployed in the server cluster via a PCI-E 3.0 x8 interface, and interface with a dedicated server cryptographic machine that conforms to national standards. Core cryptographic operations (encryption, decryption, signature verification) are offloaded to the FPGA hardware computing unit in the dedicated server cryptographic machine for execution, which greatly improves computing efficiency compared to pure software implementation. Hardware-level protection of keys: The platform's private key is pre-installed in the EEPROM security chip of the cryptographic machine. The private key never leaves the hardware and only supports internal operation and call, thus preventing key leakage at the hardware level. Encryption destruction capability: When the model is deregistered, in addition to overwriting the data, the DESTROY_KEY_HANDLE instruction is sent to the cryptographic machine to destroy the corresponding key handle. Even if the encrypted data in the storage array is not completely erased, it cannot be decrypted and recovered, thus achieving "encryption destruction". High-performance computing: SM4 encryption and decryption throughput reaches 3.2±0.1Gbps (implemented on Xilinx Virtex-7 FPGA with a clock frequency of 300MHz), which is 4 times higher than the pure software implementation in Example 1.

[0066] Hardware cryptographic machine specifications: The dedicated server cryptographic machine used in this embodiment all conforms to relevant specifications, and the specific specifications are shown in Table 3.

[0067] Table 3 Specific Specifications

[0068] This embodiment achieves a dual improvement in security level and computing performance by hardware-based modification of core cryptographic operations without changing the original system architecture and business processes. It can meet the high throughput requirements of QPS≥5,000 in financial anti-fraud scenarios and the high security authentication requirements of EAL4+, while maintaining the system's compatibility and scalability.

[0069] Lightweight verification and labeling at edge nodes (modified embodiment): This embodiment is a modified implementation for large-scale edge deployment scenarios, suitable for distributed scenarios with 1000+ edge nodes, such as smart cities, industrial IoT, and smart security. This embodiment constructs a distributed architecture of "central cloud platform + edge nodes" to solve the performance bottlenecks and network latency issues of centralized signature verification, and achieves distributed security protection of "unified management by the central cloud platform + local signature verification by edge nodes".

[0070] The core difference from Example 1: Distributed signature verification capability: Construct an architecture of "central token generation - edge local signature verification". The central cloud platform is only responsible for generating model security tokens and issuing certificates to edge nodes. The tokens are distributed to edge nodes through an encrypted channel. Edge nodes complete SM2 signature verification locally through a built-in lightweight cryptographic proxy library without sending back to the center. The peak SM2 signature request is reduced from 10,000 QPS to 200 QPS, reducing the central side's computing pressure by 98%. Lightweight cryptographic computation at edge nodes: Edge gateways (such as ARM architecture AI boxes) have a built-in cryptographic agent library (Crypto Agent, provided in the form of static link library .a or dynamic link library .so) with a size of less than 2MB. It supports local SM2 / SM3 / SM4 lightweight computation with a signature verification latency of only 0.3±0.1ms (based on ARM Cortex-A72 @1.8GHz, NEON instruction set optimized). Dual verification of model integrity: When the edge node loads the model, it first verifies the validity of the token through the local signature verification of the cryptographic proxy library, and then calculates the SM3 digest of the model memory image in real time and compares it with the verification value in the container to prevent runtime tampering (TOCTOU attack) and achieve dual integrity protection. Automated public key certificate management: Upon initial startup, edge nodes securely obtain the platform public key for signature verification from the central cloud platform via a TLCP encrypted channel. This platform public key has an expiration date; the system automatically issues warnings and rotates the certificate before its expiration, while simultaneously synchronizing the Certificate Revocation List (CRL) to ensure the validity of signature verification.

[0071] This embodiment is specifically designed for distributed deployment scenarios with 1000+ edge nodes. Stress testing verifies that in a scenario where 1000 edge nodes simultaneously start model loading, the system's horizontal scaling capability is improved by approximately two orders of magnitude (from a single center supporting 100 nodes to 10,000 nodes). A single center node can support model distribution and management for 100,000+ edge devices. At the same time, local edge signature verification significantly reduces network latency and computational pressure on the central side, ensuring the efficiency and security of model invocation in large-scale edge scenarios.

[0072] A model security data encapsulation format based on national cryptographic algorithms. The original model is digested with SM3, signed with SM2, and encrypted with SM4, and then encapsulated in TLV format as a model security container with "encrypted payload + plaintext security header", achieving integrated protection of trusted model source, complete content, and confidential storage.

[0073] A three-tiered, progressive, full lifecycle security protection process. Registration level: SM2 two-way authentication + secure container generation + SM4 encrypted storage; Application level: Containerized isolation (Docker + namespace / cgroups) + runtime signature verification + memory digest comparison; Deregistration level: Key destruction + storage overwrite + encrypted destruction (supported by hardware cryptographic machines).

[0074] Intelligent policy generation mechanism. The policy generation module analyzes user behavior based on the FP-Growth frequent pattern growth algorithm to discover model recommendation rules that meet preset confidence thresholds. When a model user requests a match with a high-confidence rule, the corresponding model is directly recommended; otherwise, the collaborative filtering algorithm is switched to generate a recommendation list.

[0075] A strong isolation mechanism for multiple model users is implemented. Each model user is allocated an independent Docker container, which only mounts a decrypted memory copy of the model authorized by that model user. Outbound connections to containers are restricted through a network whitelist, and the container's root file system is mounted in read-only mode, completely preventing cross-model user attacks and data leaks.

[0076] Multimodal deployment architecture. Pure software implementation (low cost, easy to expand); hardware cryptographic machine acceleration (PCI-E direct connection, SM4 throughput ≥ 3.2Gbps, encrypted destruction); lightweight edge signature verification (central token generation, local edge signature verification, 0.3ms latency, supports 100,000+ edge nodes).

[0077] Deep integration of national cryptographic algorithms with business processes. SM2 / SM3 / SM4 are embedded into all aspects of identity authentication, model encapsulation, storage encryption, signature verification loading, and audit persistence, achieving atomic fusion of cryptographic applications and business logic.

[0078] Alternative cryptographic algorithms: If the requirement for independent control is not considered, the SM2 / SM3 / SM4 national cryptographic algorithms can be replaced with the internationally accepted RSA / SHA-256 / AES algorithms. However, this solution poses supply chain security risks, cannot meet the cryptographic application requirements of critical information infrastructure in China, and its performance and key management efficiency are also lower than those of the national cryptographic solutions.

[0079] Alternative isolation technologies: ① Virtual Machine (VM) isolation: Heavyweight virtual machines (such as KVM) can be used to allocate an independent VM instance to each model user. This solution offers stronger isolation, but incurs high resource overhead, slow startup, and poor scalability, failing to meet the demands of high concurrency and low latency model calls. ② Process-level isolation: Process-level isolation can be achieved using native Linux technologies such as namespaces and seccomp. This solution has lower overhead, but weaker isolation strength, making it difficult to completely defend against complex side-channel attacks and escape risks, and its security is inferior to containerized solutions.

[0080] Alternative encapsulation formats: Model information can be encapsulated using text formats such as JSON and XML, or custom binary formats. However, the TLV (Type-Length-Value) format has the advantages of high parsing efficiency, flexible expansion, and good compactness, making it more suitable for security scenarios with high performance requirements, fixed data structures, and backward compatibility.

[0081] Alternative architecture: For purely centralized deployment scenarios, edge signature verification can be omitted, and all signature verification and inference requests can be handled by the central platform. However, this approach suffers from serious problems such as high network latency and central-side performance bottlenecks when the model call frequency is extremely high or the number of edge nodes is huge, and it does not have the high scalability of the proposed solution.

[0082] Figure 1 It demonstrates the interaction between the model producer terminal, the model user terminal, and the model security platform, as well as the logical connection structure of the eight core functional modules within the model security platform, clearly reflecting the overall collaborative working mechanism of the system. Figure 2This paper details the generation, signing, and encapsulation logic between the original model (M), verification value (H), and security token (Token) during the model registration phase, fully demonstrating the entire process from uploading the original model to generating it in the secure container. A hardware cryptographic machine acceleration deployment solution for high-security scenarios is presented: the commercial cryptographic module connects directly to the dedicated server cryptographic machine via a PCI-E 3.0 x8 interface, offloading core cryptographic operations to hardware execution; the core processing unit of the model security platform corresponds to the set of user management, model registration, model management, model application, policy generation, security audit, and model deregistration modules in the model security platform described in this application, excluding the commercial cryptographic module, and is responsible for business process scheduling and non-cryptographic business logic processing; the dedicated server cryptographic machine has a built-in EEPROM security chip for pre-setting the platform's private key, achieving hardware-level key protection, and accelerates SM2 / SM3 / SM4 algorithm operations through dedicated hardware, significantly improving security level and computational performance. The distributed architecture of "central cloud platform + edge nodes" is as follows: The central cloud platform is responsible for generating model security tokens and issuing certificates to edge nodes. It establishes communication with model producer terminals, model user terminals and edge nodes through encrypted channels. The edge nodes have built-in lightweight cryptographic proxy libraries. After receiving the model security tokens issued by the central cloud platform, they complete the SM2 signature verification operation locally. This realizes a distributed collaborative working mechanism of "central token generation and edge local signature verification", which effectively solves the centralized performance bottleneck and network latency problem in large-scale edge deployment scenarios.

[0083] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and not to limit them. Although this application has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of this application. Any modifications or equivalent substitutions that do not depart from the spirit and scope of this application should be covered within the protection scope of the claims of this application.

Claims

1. A multi-level security protection system for a service-oriented artificial intelligence model, characterized in that, It consists of a model producer terminal, a model user terminal, and a model security platform; The model producer terminal is used for model producers to initiate identity authentication requests to the model security platform and upload the original model file after successful authentication; The model user terminal is used to allow model users to initiate an identity authentication request to the model security platform and, after successful authentication, initiate a model invocation request. The model security platform performs registration-level protection: receiving the original model file uploaded by the model producer terminal, securely encapsulating and encrypting the original model file, and generating and binding a globally unique model identity identifier; performing application-level protection: upon receiving a model call request initiated by the model user terminal, verifying the model user's identity and permissions, and upon successful verification, verifying and decrypting the model security container to obtain the original model file, and allocating an independent Docker container for the model user to load the original model file; and performing deregistration-level protection: when the model reaches the retirement condition, irreversibly destroying the model encryption key, locating and reading the corresponding model security container based on the model identity identifier, and repeatedly overwriting the model security container to achieve irreversible deletion.

2. The multi-level security protection system for service-oriented artificial intelligence models according to claim 1, characterized in that, The model security platform includes a commercial cryptography module, a user management module, a model registration module, a model management module, and a model application module; The commercial cryptography module is used to provide cryptographic operation services based on SM2 / SM3 / SM4 algorithms to other modules, including encryption and decryption, signature verification, and digest calculation; the commercial cryptography module is also used to generate model encryption keys based on the platform master key through key derivation functions; The user management module is used to receive the identity authentication request initiated by the model producer terminal or the model user terminal, call the commercial cryptography module to perform two-way identity authentication based on SM2 digital signature, and after successful authentication, assign operation permissions to the model user. The model registration module receives original model files uploaded by authenticated and authorized model producers, forwarded by the user management module. It then calls the commercial cryptography module to calculate the SM3 checksum of the original model file and uses the model security platform's private key to perform an SM2 signature on the SM3 checksum to generate a security token. This security token verifies the model's source credibility and content integrity, generating a globally unique model identity. This identity is used for unique model identification and rapid retrieval; the integrity of its association is guaranteed by the security audit module. The original model file is encrypted using the SM4 algorithm. The encrypted original model file, along with the model type, model serial number, checksum, and security token, is encapsulated in TLV format into a model security container, generating a globally unique model identity. The model security container and the model identity are externally bound and then pushed to the model management module. The model identity is used for indexing and locating; its uniqueness is guaranteed by the platform's generation strategy, and its unforgeability is guaranteed by the SM2 signature mechanism of the security token. The model management module is used to receive the model security container and the bound model identity identifier pushed by the model registration module, call the commercial cryptography module to encrypt and store the model security container using the SM4 algorithm, and save the model identity identifier in plaintext or independent index form for quick retrieval; the model management module is also used to implement access control on model call requests based on the model user role; The model application module is used to receive model call requests initiated by model user terminals and verified for identity and permissions by the user management module. Based on the model identity identifier, it obtains the corresponding model security container from the model management module, calls the commercial cryptography module to perform SM2 signature verification on the security token using the model security platform public key, and after successful signature verification, decrypts the model security container using the SM4 algorithm to obtain the original model file. It then allocates an independent Docker container to the model user to load the original model file.

3. The multi-level security protection system for service-oriented artificial intelligence models according to claim 2, characterized in that, The model security platform also includes a policy generation module; The strategy generation module receives user role data pushed by the user management module and uses a sliding time window to statistically analyze the model call behavior characteristics of model users. These characteristics include call frequency, call time period, and historical model calls. Based on the FP-Growth frequent pattern growth algorithm, the module mines association rules between the user role data, the model call behavior characteristics, and the model identity identifier. High-confidence association rules are then selected from the mined association rules according to a preset confidence threshold. When a model user initiates a model call request, the strategy generation module extracts the current model user's user role data and model call behavior characteristics, matches them with the high-confidence association rules, and calculates the matching degree. If the matching degree reaches the preset high confidence standard, the model list corresponding to the model identity identifier of the high confidence association rule is directly and intelligently recommended to the model user; otherwise, the algorithm switches to the collaborative filtering recommendation algorithm based on model access popularity, selects the global Top-K high-popularity models as the candidate set, and then filters out the models that the user is authorized to access from the candidate set in combination with the current user role, forming a recommendation list and returning it.

4. The multi-level security protection system for service-oriented artificial intelligence models according to claim 2, characterized in that, The model security platform also includes a security audit module and a model deregistration module; The security audit module is used to collect operation logs completed by the user management module, model registration module, model management module, model application module, and model deregistration module based on model identity identifiers in real time. It calculates SM3 digest values ​​for the operation logs, performs SM2 signature solidification using the model security platform's private key, and writes the digest value and signature value to the blockchain. The operation logs include model user login / logout, model upload / download, model call, abnormal termination events, and information such as IP address, timestamp, model identity identifier, operator, inference time, and error code. The model deregistration module is used to receive a model deregistration instruction containing the model identity identifier pushed by the model management module, call the commercial cryptography module to irreversibly destroy the model encryption key, locate the model security container in the storage medium based on the model identity identifier and overwrite it multiple times to achieve irreversible deletion after the model is retired.

5. The multi-level security protection system for service-oriented artificial intelligence models according to claim 1, characterized in that, If the model security platform adopts a hardware cryptographic machine accelerated deployment mode, the model deregistration module is also used to send a key handle destruction instruction to the hardware cryptographic machine to destroy the corresponding key handle, thereby realizing the encrypted destruction of the model.

6. The multi-level security protection system for service-oriented artificial intelligence models according to claim 2, characterized in that, The model application module allocates an independent Docker container as a model user session for each model user's call request. The Docker container only mounts a decrypted memory copy of the model's secure container, which the model user has the right to access and whose identity has been matched with the model's identifier. The Docker container is allocated independent process namespaces, network namespaces, and mount namespaces to achieve strong isolation among multiple model users, and fine-grained resource management is achieved through cgroups. During model execution, the Docker container runs on the host machine where the model application module is located. The host machine and the Docker container communicate through a virtual Ethernet interface card (veth), and iptables rules are configured to implement outbound access whitelist management for the Docker container. The container's root file system is mounted in read-only mode.

7. The multi-level security protection system for service-oriented artificial intelligence models according to claim 1, characterized in that, The model security platform supports three deployment modes: pure software, hardware cryptographic machine acceleration, and lightweight signature verification at edge nodes. In the pure software deployment mode, the commercial cryptography module is deployed in the operating system kernel as a dynamic link library, and the private key of the model security platform is periodically injected into memory by the key management service and automatically cleared after the session times out. The user management module, model registration module, model management module, model application module, policy generation module, security audit module, and model deregistration module are all deployed as microservices on the same server cluster. In the hardware cryptographic machine accelerated deployment mode, the commercial cryptographic module is deployed on the host machine and connected to the dedicated server cryptographic machine via the PCI-E interface. The core cryptographic operations of SM2 / SM3 / SM4 are offloaded to the hardware cryptographic machine for execution. The private key of the model security platform is pre-installed in the security chip of the hardware cryptographic machine. The deployment method of the remaining business modules is the same as that of the pure software mode. The remaining business modules include user management module, model registration module, model management module, model application module, policy generation module, security audit module, and model deregistration module. In the lightweight signature verification deployment mode of edge nodes, a distributed architecture is adopted, in which the central cloud platform generates tokens and the edge verifies signatures locally. The central cloud platform is the cloud-based deployment form of the architecture, which is responsible for unified identity authentication, generation and management of model security containers, and issuance of security tokens. The edge nodes, as lightweight terminals, only have a built-in lightweight cryptographic proxy library and only complete the SM2 signature verification of security tokens and model decryption operations locally. They do not carry the complex business management functions of the central cloud platform and are suitable for large-scale edge computing scenarios.

8. A multi-level security protection method for service-oriented artificial intelligence models, applicable to the multi-level security protection system for service-oriented artificial intelligence models as described in any one of claims 1 to 7, characterized in that, include: Step 1: Model Registration: The model producer initiates an identity authentication request to the user management module through the model producer terminal. After the two-way identity authentication based on SM2 digital signature is successful, the original model file is uploaded through an encrypted channel. The model registration module receives the original model file and completes the integrity verification. It calls the commercial cryptography module to calculate the SM3 checksum of the original model file, uses the private key of the model security platform to perform SM2 signature on the checksum to generate a security token, encrypts the original model file using the SM4 algorithm, and encapsulates the encrypted original model file, model type, model serial number, checksum, and security token into a model security container. It synchronously generates a globally unique model identity identifier, binds the model security container and the model identity identifier, and pushes it to the model management module. The model management module encrypts and stores the model in a secure container, and synchronizes the model identity to the model application module, policy generation module, security audit module, and model deregistration module. Step 2: Model Application: The model user initiates an identity authentication request to the user management module through the model user terminal. After successful authentication, the model user initiates a model call request to the model application module. The model application module calls the user management module to verify the identity and permissions of the model user who initiated the request. After successful verification, the module calls the strategy generation module to generate and return a candidate model recommendation list based on the model user's model call behavior characteristics and pre-generated high-confidence association rules. After the model user selects a model, the model application module obtains the corresponding model security container from the model management module based on the model identity identifier, calls the commercial cryptography module to perform SM2 signature verification on the security token using the model security platform public key, and after the signature verification is successful, the model security container is decrypted using the SM4 algorithm to obtain the original model file, and an independent Docker container is allocated to the model user to load the original model file; Step 3: Model Deregistration: When a model reaches the retirement conditions, the model management module pushes a deregistration instruction containing the model's identity identifier to the model deregistration module; the model deregistration module calls the commercial cryptography module to irreversibly destroy the model encryption key, locates the model security container in the storage medium based on the model's identity identifier, and performs multiple overwrites to achieve irreversible deletion of the model.

9. The multi-level security protection method for service-oriented artificial intelligence models according to claim 8, characterized in that, After step 3, the following is also included: The security audit module collects operation logs based on model identity identifiers from each module in the entire process of model registration, application, and deregistration in real time. It performs SM3 digest calculation and SM2 signature solidification on the operation logs and writes the digest value and signature value into the blockchain.

10. The multi-level security protection method for service-oriented artificial intelligence models according to claim 8, characterized in that, In step 1, a one-model-one-key strategy is adopted when encrypting the original model file with SM4. The SM4 encryption key for each model is independently derived from the master key of the model security platform through a key derivation function based on SM3, ensuring that even if the master key is leaked, it is impossible to reverse derive the encryption key of the historical model. The master key is only used for key derivation and does not directly participate in the encryption of model data. In step 2, the Docker container is allocated an independent process namespace, network namespace and mount namespace, and the container session is set with a timeout. After the timeout, the container instance is automatically destroyed and the hardware memory resources are released. In step 3, if the hardware cryptographic machine accelerated deployment mode is adopted, a key handle destruction instruction is sent to the hardware cryptographic machine simultaneously to destroy the corresponding key handle; In step 3, the model encryption key is derived from the model security platform master key through a key derivation function based on SM3. The derivation process introduces the model identity and the current date as derivation factors, and generates a 128-bit SM4 encryption key through iterative calculation using the SM3 hash algorithm.

Images