Industrial AI model security management and control system

Abstract

The invention discloses an industrial AI model security management and control system, and the system comprises a permission granularity control module which is used for declaring a required minimum permission set when an AI model is registered, and generating a dynamic access token containing a permission list for the model; wherein the identifier is a resource operation authority identifier; the permission mapping table module is used for maintaining a mapping relation from the resource operation permission identifier to the actual resource address; the access verification module is used for verifying the validity and the permission range of the dynamic access token when the model requests the system resources, and refusing the non-permission access; and the dynamic permission recovery module is used for removing the target permission identifier in the authorized permission set of the model in real time to update the permission set, marking that the old token is invalid, and generating a new token containing a timestamp based on the new permission set. According to the method, the industrial AI model can be effectively prevented from abusing the authority, and the system security is improved.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence technology, and in particular to an industrial AI model safety management system. Background Technology

[0002] With the acceleration of industrial intelligence, industrial AI models (such as equipment vibration prediction and production anomaly detection models) are being used more and more widely in fields such as intelligent manufacturing, energy monitoring, and rail transportation. However, there are still key pain points in the safety management aspect that are difficult to overcome with existing technologies: Regarding access control, existing systems often employ a crude access control model, frequently granting models excessive permissions beyond their actual needs. They lack dynamic access token mechanisms with clearly defined permission lists and the ability to revoke permissions in real time, leading to abuses such as unauthorized access to industrial sensor data and misoperation of production control systems. In the model parameter transmission stage, core assets such as the weight vectors of industrial AI models are often transmitted between the edge and the cloud using plaintext or simple symmetric encryption, making them vulnerable to model theft and reverse engineering due to parameter leaks. Regarding training data security, existing training architectures generally rely on centralized cloud training, requiring the uploading of real-world operating data (such as equipment operating parameters and process ratios) containing core enterprise production processes. This not only poses a risk of data leakage after "shipping" but also lacks effective obfuscation and hiding strategies for training data. Attackers can use training data to infer industrial production logic, seriously threatening industrial data privacy and production security.

[0003] The aforementioned issues collectively result in the current industrial AI model's security management capabilities being unable to meet the high security and confidentiality requirements of industrial scenarios, necessitating targeted technical solutions. Summary of the Invention

[0004] The technical problem to be solved by this invention is to provide an industrial AI model security management system that can effectively prevent industrial AI models from abusing their permissions and improve system security.

[0005] To address the aforementioned technical problems, this invention discloses an industrial AI model security management system, comprising: a permission granularity control module, used to declare the minimum set of permissions required by the AI ​​model during registration. It also generates dynamic access tokens containing a list of permissions for the model. ;in This module identifies resource operation permission identifiers and maps them to actual resource addresses. The access verification module verifies the dynamic access token when the model requests system resources. The module defines the validity and scope of permissions, denying unauthorized access; it also includes a dynamic permission revokement module for real-time removal of the set of authorized permissions from the model. Target permission identifier within Update the permission set: and mark the old tokens. Invalid, based on the new permission set Generate a new token with a timestamp .

[0006] As an optional implementation, the specific process by which the permission granularity control module generates dynamic access tokens for the model is defined by the following formula: ;in, The minimum set of permissions declared when the model is registered; The validity period of the token; the payload of the generated JWT token contains the model's unique identifier, the list of authorized resources, and the validity period.

[0007] As another optional implementation, it also includes: a cloud, serving as one of the communication entities for encrypted transmission of model parameters, comprising a cloud key negotiation module and a cloud receiving / decryption module; and an edge, serving as another communication entity for encrypted transmission of model parameters, comprising an edge key negotiation module and an edge receiving / decryption module; wherein the cloud key negotiation module randomly selects a private key. Large prime numbers based on convention and original roots Calculate the public key After exchanging public keys with the edge device, a shared key is calculated based on the edge device's public key. Among them, large prime numbers and original roots These are public parameters pre-shared between the cloud and the edge; the edge key negotiation module randomly selects a private key. Large prime numbers based on convention and original roots Calculate the public key After exchanging public keys with the cloud, a shared key is calculated based on the cloud's public key. The key derivation module will generate the shared key. Converted into an AES encryption key using a hash algorithm. The key derivation module is associated with both the cloud-based key negotiation module and the edge-based key negotiation module via a shared key K, ensuring that both ends... Consistent; parameter transmission module, using For model weight vector Encryption yields ciphertext and ciphertext The data is transmitted to a cloud-based receiving and decryption module or an edge-based receiving and decryption module; the cloud-based receiving and decryption module utilizes the key generated by the key derivation module. For ciphertext Decrypt and restore the original model parameters The edge-end receiving decryption module uses the key generated by the key derivation module. For ciphertext Decrypt and restore the original model parameters .

[0008] As another optional implementation, the step of converting the shared key K into an AES encryption key... The hash algorithm used is SHA-256. The shared key K is hashed using the SHA-256 algorithm to generate a symmetric key that meets the AES encryption requirements. The model weight vector W is the model weight vector deployed by the AI ​​model.

[0009] As another optional implementation, a federated learning module is also included, which adopts an architecture that keeps data out of the factory, enabling the AI ​​model to complete iterative training at the edge. The edge uploads the gradient or weight difference of the model to the cloud aggregation center through Diffie-Hellman negotiation combined with AES encryption. After decryption, the cloud aggregation center performs global model aggregation and then sends the new model parameters to the edge through the AES encrypted channel.

[0010] As another optional implementation, an AI attack detection module is also included, comprising an input monitoring submodule, an anomaly detection submodule, an adversarial example identification submodule, and a linked permission contraction submodule that work in sequence. The input monitoring submodule is used to perform statistical analysis and feature extraction on the model input traffic to establish a normal input distribution. The anomaly detection submodule is used to immediately trigger an alarm when input data deviates from the normal input distribution. The adversarial example identification submodule is used to identify suspected adversarial attack data using feature compression and gradient sensitivity detection. The linked permission contraction submodule is used to automatically revoke relevant model permissions and block potential intrusion links when attack behavior is detected.

[0011] As another optional implementation, in the adversarial example identification submodule, feature compression uses a dimensionality reduction algorithm to extract and simplify key features of the input data, and gradient sensitivity detection identifies adversarial attack data by analyzing the degree of influence of small changes in the input data on the model gradient.

[0012] As another optional implementation, a real-time stream encryption module is also included. The real-time stream encryption module uses the TLS1.3 protocol or ZeroTrust architecture to build an encryption channel to encrypt and protect the real-time data transmission stream between the model and the system.

[0013] As another optional implementation, a data anonymization module is also included, which can scan the logs generated by the system in real time and automatically identify and mask confidential information in the logs.

[0014] As another optional implementation, a training data obfuscation module is also included, which hides the real operating condition data by adding fake noise to the training data.

[0015] Compared with the prior art, the embodiments of the present invention have the following beneficial effects: Compared with the prior art, the embodiments of the present invention declare the minimum set of permissions required when registering the model, and the system generates a dynamic access token containing a list of permissions for the model. The model must carry the token when requesting system resources. The system verifies the scope of permissions and refuses access beyond the authorization. At the same time, it supports real-time revocation of model permissions, which can effectively prevent industrial AI models from abusing permissions and improve system security. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the structure of an industrial AI model safety management and control system disclosed in an embodiment of the present invention; Figure 2 This is another structural schematic diagram of an industrial AI model safety management system disclosed in an embodiment of the present invention. Detailed Implementation

[0017] See Figures 1-2 This invention discloses an industrial AI model safety management system, comprising: The permission granularity control module is used to declare the minimum set of permissions required by an AI model when it is registered. It also generates dynamic access tokens containing a list of permissions for the model. ;in This module identifies resource operation permission identifiers and maps them to actual resource addresses. The access verification module verifies the dynamic access token when the model requests system resources. The module defines the validity and scope of permissions, denying unauthorized access; it also includes a dynamic permission revokement module for real-time removal of the set of authorized permissions from the model. Target permission identifier within Update the permission set: and mark the old tokens. Invalid, based on the new permission set Generate a new token with a timestamp .

[0018] In this embodiment of the invention, the minimum set of permissions required is declared during model registration. The system generates a dynamic access token (hereinafter referred to as "token") containing a list of permissions for the model. The model must carry the token when requesting system resources. The system verifies the scope of permissions and refuses access beyond the authorized scope. At the same time, it supports real-time revocation of model permissions, which can effectively prevent industrial AI models from abusing permissions and improve system security.

[0019] Minimum Authority Set This refers to the "minimum set of resource operation permission identifiers" declared by the system or model stakeholders during the industrial AI model registration phase, which only satisfies the needs of the AI ​​model to complete its core business tasks. Its mathematical expression is: ,in Here, k represents the total number of resource operation permission identifiers required for the model to complete its core tasks, and the set contains no redundant or excessive permission identifiers. This restricts the model from accessing only the resources necessary to complete the tasks, preventing security risks caused by over-authorization. The mapping relationship maintenance and implementation of the permission mapping table module are as follows: The core function of the permission mapping table module is to establish "resource operation permission identifiers". A precise association between "and actual resource endpoint" forms a mapping relationship. The specific maintenance logic is as follows: 1. Core definition of mapping relationship: The mapping relationship maintained by the module uses "permission identifier as key and resource address as value", where... It is the minimum set of permissions declared when an industrial AI model is registered. The resource operation permission identifier (such as "read sensor data from workshop A" or "control the joint movement of a four-axis robot") in the system, and the Resource Endpoint is the specific access address of the corresponding resource in the industrial system (such as network interface address, hardware device port address, etc.), to ensure that the abstract permission declaration can be implemented at the actual resource access level.

[0020] 2. Instantiation and maintenance of mapping relationships: The module will establish a mapping relationship between permission identifiers and actual addresses for each specific resource type in the industrial scenario.

[0021] 3. The relevance of the mapping relationship: When an industrial AI model requests resources carrying an access token, the access verification module will use this mapping table to verify the model's request. It is converted into an actual ResourceEndpoint, and then the model is verified to see if it has the right to access the resource corresponding to the address, so as to realize the linkage of "permission verification - resource location".

[0022] II. The storage structure of the mapping table adopts a two-tier architecture of "memory cache + persistent storage", as detailed below: 1. Memory caching layer: Hash Table The access verification module needs to verify the correlation between the permissions of the model request and the resource address in real time (e.g., model request permissions). When it is necessary to quickly locate the corresponding joint control interface address), the hash table has the characteristic of "fast key-value pair query" (the average query time complexity is O(1)), which can meet the low latency requirements of real-time permission verification in industrial scenarios.

[0023] Storage content: The key of the hash table is a resource operation permission identifier. (e.g., string format "r_1_robot_joint_control"), the value is the actual resource address (e.g., string format "192.168.2.100 / joint_control"), and at the same time stores the address type identifier (e.g. "network interface" "hardware port"), so that the access verification module can distinguish the resource type.

[0024] 2. Persistent storage layer: Relational database tables (such as MySQL tables) Industrial systems need to ensure the long-term stable storage of mapping relationships (such as the mapping relationships not being lost after equipment restarts or system upgrades), and need to support collaborative access by multiple modules (such as permission granularity control modules and resource management modules). Relational database tables have the characteristics of "data persistence", "transaction consistency" and "structured query", making them suitable for storing core mapping data.

[0025] III. The update mechanism of the mapping table is divided into three parts: "triggering conditions", "update process", and "consistency guarantee", as detailed below: 1. Update trigger conditions Resource address change trigger: When industrial equipment (such as sensors and robots) changes its deployment location or network configuration is adjusted, resulting in a change of Resource Endpoint (e.g., the IP address of sensor in workshop A changes from 192.168.1.100 to 192.168.1.101), the resource management module will send an update notification to the permission mapping table module, triggering the corresponding... The mapping relationship is updated. Permission identifier lifecycle change trigger: When the industrial AI model adds or cancels permissions, the permission granularity control module will synchronously trigger the "add mapping" or "mark invalid" operation in the mapping table.

[0026] 2. Update process Step 1: Update Request Verification: Update requests must include the operator's authorization credentials (such as an administrator token) and the basis for the change (such as a resource address change approval form or permission adjustment notification). Updates are only allowed after the module verifies the request to prevent unauthorized tampering.

[0027] Step 2: Two-tier storage synchronous update: First, update the persistent database table: if it's an "Add Mapping", insert a new row; if it's an "Address Change", update the `resource_endpoint` field; if it's a "Permission Deregistration", set the `is_valid` field to 0 (logical deletion, retaining historical records). Then, update the in-memory hash table: if it's an "Add / Address Change", update the corresponding hash table... The value; if it is "authorization deregistration", then delete it from the hash table. The key-value pairs ensure consistency between the memory cache and the database table data.

[0028] Step 3: Update Notification Synchronization: After the update is completed, the module sends a "mapping table update notification" to the access verification module to ensure that the access verification module uses the latest mapping relationship in the future, and avoids permission verification errors due to data lag.

[0029] 3. Consistency Guarantee Mechanism Transaction control: Database table update operations are implemented through transactions. If an exception occurs during the update process (such as network interruption), the transaction will be rolled back to avoid data inconsistency caused by "partial updates".

[0030] Cache expiration policy: To prevent the memory hash table from failing to update synchronously due to anomalies, a cache expiration time (e.g., 5 minutes) is set. After expiration, all valid mapping relationships are automatically reloaded from the database table to ensure data consistency.

[0031] Update log records: All update operations (operator, update time, value before change, value after change) are recorded in the system audit log, which facilitates subsequent traceability and investigation and meets the security audit requirements of industrial scenarios.

[0032] Additionally, dynamic access tokens The generation mechanism, specific format, and key technical characteristics are as follows: I. The dynamic access token is generated by the permission granularity control module. Its core is based on the "minimum permission set" and "token validity period" declared during AI model registration. A verifiable permission credential is constructed using a standardized algorithm. The specific generation process and technical basis are as follows: 1. Triggering timing: During the AI ​​model registration phase, when the model declares its minimum set of permissions. ( After the resource operation permission identifier is set, the permission granularity control module automatically triggers the token generation process.

[0033] 2. Core Generation Formula: Token generation uses the JWT (JSON Web Token) standard algorithm, and the formula is defined as follows: ,in, It is the minimum set of permissions declared during model registration (serving as the core basis for the scope of token permissions). It is the token's validity period (used to control the token's validity duration and prevent long-term abuse).

[0034] Optional extended formula (enhanced security): New The pre-shared signature key is used to digitally sign JWTs, ensuring that the tokens are not tampered with or forged.

[0035] 3. Generation process: Step 1: Extract core model information, including the minimum permission set during model registration. (including all) The first step is to assign a unique identifier to the model by the system; the second step is to determine the token's validity period. (e.g., 12 hours, 24 hours, which can be configured according to the security requirements of industrial scenarios); Step 3: If a signature mechanism is enabled, use The fourth step is to sign the JWT payload and header; assemble the JWT token and output it as a string, which will serve as the "authorization credential" for the model to access system resources in the future.

[0036] II. The token adopts the JWT standard format, which consists of three parts: Header, Payload, and Signature. These parts are connected by a ".". Example format: The specific contents of Header.Base64UrlEncode.Payload.Base64UrlEncode.Signature are as follows: 1. Header: Declares the token type and core fields of the signature algorithm: typ: Token type, fixed as "JWT", indicating that the token conforms to the JWT standard; alg: Signature algorithm, if using the system's pre-shared key. If the algorithm is not specified, the HMAC-SHA256 (or SHA-256) algorithm will be used; if only basic generation is used, the algorithm type will be marked by default (e.g., "none").

[0037] That is, {"typ":"JWT","alg":"HS256"} (HS256 is HMAC-SHA256, corresponding to...) (The scene of signing).

[0038] 2. Payload: Stores core business information of the token. The payload is the core data area of ​​the token, containing key fields such as model permissions, identity identifier, and validity period. All fields are structured data that the system can parse.

[0039] 3. Signature: Ensures token integrity and authenticity. Generation logic: If enabled. Then, the algorithm declared in the Header (such as HS256) is used to encrypt "Base64Url encoded Header + "." + Base64Url encoded Payload" to generate a signature value; Its function is to: when the access verification module verifies the token, it will use the same... The algorithm recalculates the signature. If it matches the signature in the token, it proves that the token has not been tampered with; if it does not match, the token is deemed invalid and access is denied.

[0040] III. Key Technical Characteristics of Tokens Permission binding: The minimum set of permissions between a token and a model. Strong binding: the permission_list in the payload directly determines the scope of resources that the model can access, and the access verification module will strictly verify whether the resource operation permissions requested by the model are within the permission_list.

[0041] Validity: The expiration date of the token is controlled by the exp field. After expiration, the access verification module will directly determine that the token is invalid. If it is necessary to extend the validity period, it must be based on the updated version. Regenerate a token containing the new exp.

[0042] Dynamic correlation: When the dynamic permission revocation module updates the model permission set (e.g.) When this happens, the old token will be marked as invalid, and based on... Generate a new token containing a new permission_list and a timestamp, ensuring that the token permissions are consistent with the current authorized permissions of the model.

[0043] In addition, the "real-time removal" of the dynamic permission revokement module refers to the following: when the system detects a risk of permission abuse or a security threat event in the model through preset mechanisms (such as the AI ​​attack detection module identifying attack behavior, the access verification module detecting abnormal permission requests, and external threat warning signals triggering), it executes a full-process operation of "removing the target permission identifier, updating the permission set, marking the old token as invalid, and generating a new token" within a pre-set time threshold that meets the real-time requirements of industrial scenarios. This quickly cuts off the risk propagation path and avoids security risks to the industrial system caused by permission abuse. The time granularity of "real-time removal" must meet the requirements of "rapid response without affecting the continuity of industrial production." The time granularity of "real-time removal" is set to within 100 milliseconds (ms) to 5 seconds (s) after the risk event is detected. This range is suitable for the real-time requirements of industrial AI models (such as four-axis robotic arm control and production line sensor data access) (avoiding delays that could lead to equipment misoperation or data leakage) and also allows the system necessary operation time (such as permission set updates and token signature generation). Threshold setting basis: For permissions involving the physical control of industrial equipment (such as joint movement permissions of a four-axis robot and control permissions of an end effector), since they are directly related to production safety, the time threshold should be set within 100ms-1s to ensure that the model’s equipment control capabilities are quickly stripped after a risk is triggered, preventing accidents such as accidental collisions of the robotic arm and damage to the workpiece. For permissions involving non-real-time data access (such as the permission to read historical operating logs), the time threshold can be relaxed to within 1-5 seconds, balancing system resource consumption while ensuring security.

[0044] Additionally, "target permission identifier" refers to a specific resource operation permission identifier within the already authorized permission set of the industrial AI model that needs to be removed in real time due to security risks, operational needs, or permission adjustments. Mathematically, it is expressed as... (j≤k). Its core function is to accurately locate the permissions that need to be revoked, ensuring that permission updates only apply to the target range and do not affect the normal use of other legitimate permissions in the model.

[0045] The source of "target permission identifiers" needs to be combined with system security mechanisms and industrial scenario requirements, and can be mainly divided into the following three categories: 1. AI Attack Detection Module Linkage Trigger (Security Risk Driven): When the AI ​​attack detection module identifies malicious attack behaviors targeting industrial AI models (such as adversarial sample injection, abnormal input data attacks), it will automatically determine the "target permission identifier" that needs to be revoked through the "linkage permission contraction submodule". The specific process is as follows: The input monitoring submodule establishes a normal input distribution, and the anomaly detection submodule triggers an alarm upon detecting data deviations. The adversarial example identification submodule further confirms the attack data (e.g., through feature compression and gradient sensitivity detection). The linked permission contraction submodule determines the corresponding permission identifier as the "target permission identifier" based on the resource operations associated with the attack (e.g., the attack data involves "robotic arm joint control"), triggering the dynamic permission revocation module to perform the removal operation. For example, in a four-axis robotic arm grasping scenario, if an adversarial example is detected attempting to mislead the robotic arm into misoperation, the "joint motion control permission identifier" will be revoked. "Pneumatic gripper control authority identifier" "Set as the target permission identifier and quickly revoke it to block the risk."

[0046] 2. System administrator actively designates (driven by maintenance / permission adjustment needs) When there are planned maintenance (such as equipment maintenance, process adjustment) or permission optimization needs in industrial scenarios, system administrators can directly specify the "target permission identifier" in the permission management interface to trigger dynamic permission revocation based on business needs. Equipment maintenance scenario: If the end effector gripper enters the maintenance phase, the administrator needs to temporarily disable model control of the gripper. In this case, the "gripper control permission flag" will be set. "Designated as the target permission identifier, the dynamic permission revokement module starts from..." Remove from Updated to (Only joint movement and sensor reading permissions are retained); Permission optimization scenario: If the model functionality is simplified (e.g., it no longer needs to read sensor data from workshop B), the administrator specifies the corresponding permission identifier (e.g., ...). The target is to remove [the privilege] to avoid over-authorization.

[0047] 3. Triggered by abnormal access behavior (driven by compliance risks) When the access verification module continuously detects abnormal permission requests in the model (such as frequent requests for unauthorized resources or permission usage frequency exceeding the normal range), or when the external threat warning system indicates that specific permissions are at risk of leakage, the system will automatically determine the "permission identifier associated with abnormal access" as the target permission identifier. The dynamic permission revoke module needs to "adjust model permissions in real time," and this selection of target permission identifiers triggered by abnormal access is the core manifestation of "timely cutting off potential risk propagation paths."

[0048] The permission mapping table module is responsible for maintaining "resource operation permission identifiers". To the actual resource address The mapping relationship between " This mapping establishes a precise link between "abstract permission declarations" and "specific system resources," enabling permission control to be implemented at the actual resource access level.

[0049] When an AI model requests system resources, the access verification module verifies the dynamic access token. First, determine if the token is valid (e.g., whether it has expired or been marked as invalid); second, check if the token's permission scope includes the permissions for the currently requested resource. If the token is invalid or the permissions do not match, directly deny access to ensure that unauthorized models cannot illegally obtain resources.

[0050] Taking the "automatic workpiece gripping" scenario of a four-axis industrial robot as an example, the functions of each module in the industrial AI model safety management system are explained as follows: 1. Permission granularity control module A factory needs to deploy a "workpiece intelligent gripping" AI model on its four-axis industrial robot (to automatically control the robotic arm to grip workpieces based on visual recognition results). During the registration phase of this AI model, the minimum set of permissions required to complete the task must be declared. : : Four-axis robot joint motion control authority (used to control the movement and rotation of each joint of the robotic arm and adjust the grasping posture). End effector (pneumatic gripper) control authority (used to control the opening / closing of the pneumatic gripper to complete the "grabbing / releasing" action of the workpiece); Workpiece vision sensor reading permission (used to read camera data of the workpiece so that the AI ​​model can identify the workpiece position and posture).

[0051] The system will generate a dynamic access token for this "intelligent workpiece grasping" model. The token is embedded with the above The permission list serves as the "permission credentials" for the model to access resources subsequently.

[0052] 2. Permission Mapping Table Module This module maintains the mapping relationship between "resource operation permission identifier" and "robot actual resource address". This associates abstract "authorization identifiers" with specific "robot hardware / data interfaces," for example: "Four-axis robot joint control interface (network address: 192.168.2.100 / joint_control)"; "End-effector control interface (network address: 192.168.2.101 / gripper_control)"; "Workpiece vision sensor data interface (network address: 192.168.2.102 / workpiece_camera)".

[0053] When a model requests resources carrying an "authorization identifier", the system can accurately locate the robot hardware or data interface that actually needs to be accessed through a mapping table.

[0054] 3. Access Verification Module When the "intelligent workpiece gripping" AI model is running, if it is necessary to control the movement of the robotic arm joints (i.e., request the resource corresponding to r_1), the system will use its dynamic access token. Perform double validation: First, verify the token's validity (e.g., whether it's expired or marked as "invalid"); second, check the token's permission scope (whether it includes the currently requested r_1). If the validation passes, the model can access the "joint control interface" normally; otherwise, if the model attempts to access an unauthorized resource (e.g., the control interface of a factory safety door, which is not within the scope of the joint control interface), it will be denied access. In the middle), the access verification module will directly reject the request to prevent the AI ​​model from overstepping its authority and endangering the safety of the production line.

[0055] 4. Dynamic permission revocation module If the end effector enters the maintenance phase (AI model control of the end effector is temporarily prohibited), it must be retrieved. Permissions: The dynamic permission revoke module will retrieve permissions from the set of permissions already granted by the model. Remove the target permission identifier. Update to the new permission set: Simultaneously mark the old tokens. Invalid; based on the new permission set Generate a new token containing a timestamp. After that, the "intelligent workpiece gripping" model could only use... (Joint movement) and Once the sensor read permission is lost, the gripper can no longer be controlled until maintenance is completed and permissions are reassigned.

[0056] In an optional embodiment, the specific process by which the permission granularity control module generates dynamic access tokens for the model is defined by the following formula: ;in, The minimum set of permissions declared when the model is registered; The validity period of the token; the payload of the generated JWT token contains the model's unique identifier, the list of authorized resources, and the validity period.

[0057] Optional, it can also be described as ,in A pre-shared signature key for use in the system. Digital signatures are performed to ensure token integrity. The access verification module then verifies the dynamic access token when the model requests system resources. The signature validity, validity (not expired / revoked), and scope of permissions are checked to deny access to unauthorized or forged tokens. The JWT (JSON Web Token) signature algorithm and key management mechanism are as follows: I. JWT Signature Algorithm Dynamic access tokens are generated in JWT format. The core function of their signature algorithm is to ensure token integrity (prevent tampering). The specific algorithm and technical basis are as follows: 1. Signature Algorithm Type: System-pre-shared signature key Used for digital signatures of JWTs, the default signature algorithm for JWTs is HMAC-SHA256 (Hash Message Authentication Code). This algorithm generates signatures through "pre-shared key + hash calculation", which ensures both signing efficiency and resistance to tampering attacks.

[0058] 2. Signature Function: The signing process is strongly bound to the JWT Header and Payload. The access verification module will use the same header and payload when verifying the token. Using the HMAC-SHA256 algorithm, the signature value of "Header.Base64UrlEncode+"."+Payload.Base64UrlEncode" is recalculated. If it matches the Signature in the token, the token is determined to be tamper-proof; otherwise, access is denied to avoid the risk of privilege abuse caused by forged tokens.

[0059] II. JWT Key Management Method The management of JWT signing keys strictly follows the principles of "secure storage, pre-sharing, and system-only control," with the specific mechanism as follows: 1. Key Types and Generation: The system-level pre-shared symmetric key is generated by the core management module of the industrial AI model security management system (such as the key management subunit of the permission granularity control module). The generation process must meet cryptographic security requirements (such as a key length of not less than 256 bits, which meets the security standard of AES encryption key).

[0060] 2. Key sharing scope: The key is pre-shared only between the "permission granularity control module (signing when generating JWT)" and the "access verification module (verifying signature when verifying JWT)," and is not exposed to any AI model or edge device. This ensures that the key only circulates within the core security domain of the system, reducing the risk of leakage.

[0061] 3. Closed-loop key usage and verification: Generation Phase: The permission granularity control module automatically calls [the relevant function] when generating JWTs. The token is signed, and the signature result is used as the Signature field of the JWT, which together with the Header and Payload form a complete token; Verification Phase: After receiving the token request from the model, the access verification module retrieves the token from the system's secure storage. The signature verification operation is performed, and only tokens that pass the verification will enter the subsequent "validity (expired / invalid)" and "authorization scope" verification stages. 4. Secure key storage: The key must be stored in the system's "secure encrypted storage area" (such as the hardware security module HSM, encrypted database), rather than in plaintext in ordinary files or memory, to prevent the key from being illegally read or stolen.

[0062] In yet another optional embodiment, it further includes: The cloud, as one of the communication entities for encrypted transmission of model parameters, includes a cloud key negotiation module and a cloud receiving and decryption module; the edge, as another communication entity for encrypted transmission of model parameters, includes an edge key negotiation module and an edge receiving and decryption module; the cloud key negotiation module randomly selects a private key. Large prime numbers based on convention and original roots Calculate the public key After exchanging public keys with the edge device, a shared key is calculated based on the edge device's public key. Among them, large prime numbers and original roots These are public parameters pre-shared between the cloud and the edge; the edge key negotiation module randomly selects a private key. Large prime numbers based on convention and original roots Calculate the public key After exchanging public keys with the cloud, a shared key is calculated based on the cloud's public key. The key derivation module will generate the shared key. Converted into an AES encryption key using a hash algorithm. The key derivation module is associated with both the cloud-based key negotiation module and the edge-based key negotiation module via a shared key K, ensuring that both ends... Consistent; parameter transmission module, using For model weight vector Encryption yields ciphertext and ciphertext The data is transmitted to a cloud-based receiving and decryption module or an edge-based receiving and decryption module; the cloud-based receiving and decryption module utilizes the key generated by the key derivation module. For ciphertext Decrypt and restore the original model parameters The edge-end receiving decryption module uses the key generated by the key derivation module. For ciphertext Decrypt and restore the original model parameters .

[0063] In this embodiment, large prime numbers It is the core foundation of Diffie-Hellman key negotiation, and its selection directly determines the attack resistance of key negotiation. It must meet the following four core criteria: 1. Sufficiently large prime number length: To resist brute-force attacks on the "discrete logarithm problem" and potential threats from quantum computing, the binary length of p must be no less than 2048 bits (4096 bits recommended). Model parameter transmission uses AES encryption (the key is derived from the shared key associated with p), and the length of p must match the AES encryption strength (e.g., AES-256) to avoid the key negotiation process becoming a security weakness due to insufficient p length.

[0064] 2. Secure Prime Structure: p must satisfy the "secure prime" property, i.e., p = 2q + 1 (where q is also a prime number, called the "secure prime factor" of p). This structure can significantly improve the ability to resist attacks targeting discrete logarithms, such as "Pollard's Rho algorithm", and ensure that the shared key K for cloud and edge computing cannot be reverse-engineered.

[0065] 3. Pass rigorous primality tests: p must undergo multiple rounds of cryptographic-level primality tests, including at least the Miller-Rabin probabilistic primality test (recommended test rounds ≥ 5 rounds) and the Lucas deterministic primality test, to ensure that p has no risk of being a "pseudo-prime" number. If p is a pseudo-prime number, it will lead to the leakage of the shared key K generated by key negotiation, which directly threatens the security of encrypted transmission of model parameters.

[0066] 4. Avoid the "weak prime" property: p must not be a "weak prime" number, and the following cases must be excluded: ① All prime factors of p-1 are small (it is necessary to ensure that p-1 contains at least one large prime factor of ≥2048 bits, i.e., q that matches the length of p); ② p belongs to a known "special set of primes" (such as Smooth primes), and such primes are easy to solve the discrete logarithm problem with targeted algorithms.

[0067] In this embodiment, the selection criteria for the original root g are as follows: The primitive root g is a generator modulo p. Its selection must ensure that the public keys generated in the cloud and at the edge can cover a sufficiently large key space. The specific criteria are as follows: 1. Verification of the primitive root property: g must be a primitive root modulo p, that is, the order of g modulo p is equal to \({p}-1\) (when p is a safe prime number, the order is equal to 2q). This means that through (a is the edge private key) or The public key generated (b is the cloud private key) can be evenly distributed in the remaining class set modulo p, avoiding the risk of key guessing caused by too small a public key space.

[0068] 2. Avoid "weak generators": g needs to exclude "weak generators", specifically including: ① g values ​​that are too small (e.g., g=1 or g=2 need to be carefully verified. Although g=2 is a common primitive root, it is necessary to ensure that its order modulo p is p-1); ② g's order in small prime factors modulo p is too small (e.g., its order modulo q is 1 or 2). Such g will limit the range of public key generation and reduce the randomness of the shared key K.

[0069] 3. Matching with p: The selection of g must strictly match the large prime number p. If p is a safe prime number (p=2q+1), then g must satisfy: , where q is a safe prime factor of p. This verification ensures that g is a primitive root modulo p, and not merely a generator of a subgroup.

[0070] In this embodiment, the key derivation module adopts a "distributed collaborative deployment" mode, deploying independent "key derivation sub-modules" on both the cloud and edge. These two sub-modules are physically separated on different hardware carriers, but follow a unified key derivation algorithm and parameters to ensure that a consistent business encryption key (such as an AES key) is generated based on the negotiated shared key, supporting the coordination of encryption / decryption operations at both ends, as detailed below: 1. The "key derivation submodule" in the cloud is part of the core cloud security components, and its physical deployment and association logic are as follows: Physical deployment location: It is directly integrated into the "secure computing domain" of the cloud server cluster. The specific hardware carrier is a cloud encryption server (or a physical server equipped with a hardware security module HSM). It is physically part of the same cloud security hardware unit as the "key negotiation module" in the cloud (responsible for generating cloud private / public keys and calculating shared key K), thus avoiding the transmission of sensitive shared key K across hardware.

[0071] Physical association module: It has a physical-level data interaction link with the "model parameter management module" and "encrypted transmission module" in the cloud. The AES key generated by the key derivation submodule (derived from the shared key K) is transmitted to the model parameter management module through the cloud's internal encryption bus. It is used to encrypt sensitive data such as the weight vector W and configuration parameters of the industrial AI model. At the same time, the AES key is also synchronized to the encrypted transmission module to verify the encryption integrity of the data uploaded from the edge.

[0072] Physical isolation requirements: The hardware unit where the cloud key derivation submodule is located must be physically isolated from cloud-based insecure components (such as model training modules and log statistics modules) (e.g., through server hardware partitioning or independent PCIe encryption cards) to prevent unauthorized modules from stealing key data during the derivation process through physical-level memory reading and bus eavesdropping.

[0073] 2. The "key derivation submodule" at the edge is a core component of the edge device's security functions. Its physical deployment closely aligns with the real-time requirements and hardware limitations of industrial scenarios, as detailed below: Physical deployment location: Deployed in the hardware carrier of "industrial-grade edge computing devices" on the edge side, preferably integrated in the security chip (such as SE chip) of the edge device or the encryption module of the edge gateway, rather than in the ordinary CPU memory area.

[0074] Physical association module: It has a localized physical data link with the "key negotiation submodule", "data decryption module" and "device control module" at the edge. After the edge key negotiation submodule calculates the shared key K, it will transmit it to the key derivation submodule through the hardware encryption channel inside the edge device (rather than the software-level Socket communication) to prevent K from being leaked locally at the edge. The derived AES key is directly written into the edge data decryption module to decrypt the model parameters sent from the cloud, and is also synchronized to the device control module to ensure the encrypted transmission of control commands.

[0075] Physical adaptation characteristics: It needs to adapt to the hardware resource limitations of edge devices (such as low power consumption and low computing power), and adopt a lightweight hardware design (such as a simplified encryption circuit based on FPGA) to avoid the key derivation calculation consuming too much computing power of edge devices and affecting the real-time performance of industrial control tasks (such as robotic arm action response and real-time processing of sensor data).

[0076] This embodiment of the industrial AI model parameter encryption transmission system achieves secure transmission of core parameters such as model weights through key negotiation based on the Diffie-Hellman (DH) algorithm, AES key derivation, encrypted transmission, and decryption recovery between the cloud and edge terminals. This prevents the leakage of industrial AI model parameters and enhances system security. The system consists of a cloud terminal (including a cloud key negotiation module and a cloud receiving / decryption module), an edge terminal (including an edge receiving / decryption module), a key derivation module, and a parameter transmission module. These modules work together to ensure security throughout the entire process of "key generation → parameter encryption → transmission → decryption recovery." The functions and collaborative processes of each module are as follows: (1) Key negotiation phase (Diffie-Hellman algorithm) The cloud and edge devices generate the same shared key through the DH key exchange protocol without directly transmitting the shared key: Cloud-based key negotiation module: Randomly selects private key (p is a large prime number pre-shared between the cloud and the edge, and g is a pre-shared primitive root; both are public parameters), compute the public key. and will Send to the edge device; subsequently, based on the public key transmitted from the edge device... Calculate the shared key .

[0077] Edge-end key negotiation module: randomly selects private key Calculate the public key and will Send to the cloud; then, based on the public key transmitted from the cloud... Calculate the shared key .

[0078] Due to the mathematical properties of the DH algorithm, the final calculated K is completely identical between the cloud and the edge, and even if a third party intercepts the public key... , Furthermore, it is impossible to quickly derive the shared key K through factoring large prime numbers, thus ensuring key security.

[0079] (2) AES key derivation stage The key derivation module converts the shared key K into an AES encryption key using a hash algorithm (such as SHA-256). Since the shared key K is the same on both the cloud and the edge, and is processed by the same hash algorithm, the generated hashes at both ends will be identical. Completely identical, providing a foundation for subsequent symmetric encrypted transmission.

[0080] (3) Parameter encryption transmission stage Parameter transmission module uses The model weight vector W (or other model parameters to be transmitted) is encrypted using AES to obtain the ciphertext. The encrypted text C is then transmitted to the target device (cloud or edge).

[0081] (4) Parameter decryption and recovery stage If ciphertext C is transmitted to the cloud, the cloud receiving and decryption module uses the key derivation module to generate... Perform AES decryption on C to restore the original model parameters. ; If ciphertext C is transmitted to the edge, the edge receiving and decryption module will similarly use... Decryption yields W.

[0082] Taking the "intelligent workpiece sorting" scenario of a four-axis industrial robotic arm as an example, the process of encrypted transmission of model parameters is explained: 1. Scene Background A four-axis robotic arm in a factory is responsible for the "workpiece sorting" task on the production line. It needs to automatically adjust the posture of the robotic arm and the movement of the end effector based on the shape and color of the workpiece. The core weight parameters of the AI ​​model for "sorting decision" are stored on a cloud server and need to be encrypted and transmitted to the edge computing box (edge ​​end) next to the robotic arm to ensure that the parameters are not stolen or tampered with when transmitted through the workshop network.

[0083] 2. Collaboration process of each module (1) Key negotiation between the cloud and the edge (based on the Diffie-Hellman algorithm) Public parameter agreement: The cloud and the edge agree on two public parameters in advance: a large prime number p (selecting a large prime number that satisfies cryptographic security and ensures the difficulty of cracking) and a primitive root g (the primitive root of p, ensuring the mathematical security of key negotiation).

[0084] Cloud-based key negotiation module action: Randomly select private key Through formula Calculate the public key and will Send to the edge.

[0085] Edge-side key negotiation module action: Randomly select private key Through formula Calculate the public key and will Send to the cloud.

[0086] Shared key generation: Received in the cloud Then, calculate the shared key. ; received at the edge Then, calculate the shared key. .

[0087] According to the Diffie-Hellman algorithm, the calculated K at both ends is completely identical, and a third party cannot use the public key. , K is directly derived to achieve "secure key exchange".

[0088] (2) Key derivation module: Generates AES encryption keys The key derivation modules at the cloud and edge convert the shared key K into an AES encryption key using a hash algorithm (such as SHA-256). Since both ends share K, the derived Completely consistent, providing a foundation for subsequent "symmetric encryption transmission model parameters".

[0089] (3) Parameter transmission module: encrypts and transmits model weights. The cloud needs to transmit the weight vectors of the "four-axis robotic arm sorting model" (e.g., core parameters in a neural network that control the range of motion of the robotic arm joints). The parameter transmission module uses... Encrypt W using AES to obtain the ciphertext: The ciphertext C is then transmitted to the edge receiving and decryption module via the workshop network (such as Wi-Fi or industrial Ethernet).

[0090] (4) Receiving and decrypting: restoring model parameters to drive the robotic arm The edge-end receiving and decryption module utilizes locally derived... Decrypt the ciphertext C using AES: After decryption, the edge device obtains the original model weights W, which can drive the four-axis robotic arm to perform "intelligent workpiece sorting".

[0091] If the cloud needs to receive data such as "model inference results" and "real-time status of the robotic arm" from the edge, the cloud's receiving and decryption module will also use the same... Decryption ensures the security of bidirectional transmission between the cloud and the edge.

[0092] In yet another optional embodiment, the step of converting the shared key K into an AES encryption key... The hash algorithm used is SHA-256. The shared key K is hashed using the SHA-256 algorithm to generate a symmetric key that meets the AES encryption requirements. The model weight vector W is the model weight vector deployed by the AI ​​model.

[0093] In this embodiment, SHA-256 provides a secure key generation foundation and data integrity verification support for AES. AES uses the result of SHA-256 processing to encrypt sensitive data. Together, they meet the triple requirements of "data confidentiality + integrity + key security". The specific matching method is elaborated in the following dimensions: I. Matching during the key derivation process: SHA-256 generates a security key for AES, which is the AES encryption key in the material file (such as for model parameter encryption). The key for signing the authorization token must be generated using SHA-256 processing to ensure that the AES key has sufficient randomness and resistance to cracking. The specific matching process is as follows: Initial key material preprocessing: When the system obtains the shared key K through Diffie-Hellman key negotiation (generated collaboratively by the cloud and edge), or obtains the initial key seed (such as the system's pre-shared key) through the permission module. After that, the initial material needs to be hashed using SHA-256. SHA-256 converts the initial key material of arbitrary length (such as shared key K, model ID + timestamp combination data) into a 256-bit fixed-length hash value. This hash value has "irreversibility" and "avalanche effect", which can eliminate the weak randomness that may exist in the initial material (such as short keys, duplicate fields).

[0094] AES Key Generation Adaptation: The 256-bit hash value output by SHA-256 is directly used as the encryption key for the AES-256 algorithm. This achieves seamless matching of the hash result and the encryption key. For example, when encrypting the weight vector W (sensitive parameter) of an industrial AI model, the cloud first uses SHA-256 to match the shared key K with the model's unique identifier (…). The combined data hashes generate a 256-bit hash value as... Then, AES-256 is used to encrypt W in blocks; this matching method ensures that the AES key has no redundant information and is aligned with the security strength of SHA-256, avoiding the AES encryption being cracked due to insufficient key randomness.

[0095] II. Linkage between integrity verification and encryption: SHA-256 ensures the authenticity of AES encrypted data. In the file, AES is only responsible for the "confidentiality" of sensitive data (preventing data leakage after theft), while SHA-256 is responsible for verifying the "integrity" of AES encrypted data (preventing data tampering). The two achieve a security loop through the linkage of "encryption + hash verification." The specific matching logic is as follows: Data hashing before encryption: Before AES encryption of sensitive data (such as model parameters W, operating condition sensor data D), the system first calculates the "raw hash digest" of the data using SHA-256. =SHA-256(data)), this digest uniquely corresponds to the original data, and any slight tampering will result in a completely different digest.

[0096] AES encryption and digest binding: The system binds the AES-encrypted data ( =AES-256(data, )) with the original hash digest Packaged for transmission (or storage).

[0097] Integrity verification after decryption: The recipient (e.g., the cloud) first decrypts the data using AES-256. After obtaining the original data, the "verification hash digest" of the decrypted data is recalculated using SHA-256. =SHA-256 (decrypted data)), if and If they match perfectly, it proves that the AES encrypted data has not been tampered with; if they do not match, the data is deemed invalid and processing is rejected. This matching method complements the "confidentiality" of AES with the "integrity" of SHA-256, preventing attackers from tampering with the encrypted data and causing the receiver to decrypt and obtain incorrect information (such as incorrect model parameters leading to device malfunction).

[0098] III. Security Strength Compatibility: Strength Alignment of SHA-256 and AES-256 The encryption algorithm must meet "industrial-grade security standards," and the matching of SHA-256 and AES must follow the "no weak link" principle to ensure that their security strengths are consistent. Output / key length matching: The hash value of SHA-256 is 256 bits long, and AES-256 algorithm (key length 256 bits) is preferred, so the two lengths are perfectly aligned.

[0099] Combined anti-attack capabilities: SHA-256 can resist "collision attacks" (it is difficult to find two different data that generate the same hash value), and AES-256 can resist "brute force" attacks (breaking the key requires attempts). (This is possible, but current computing power is insufficient to achieve this). Both algorithms have similar anti-attack capabilities, preventing the overall security system from failing due to insufficient strength of one algorithm. The collaboration between SHA-256 and AES-256 can simultaneously prevent parameter theft (AES encryption) and tampering (SHA-256 verification), providing double protection for model security.

[0100] In another optional embodiment, a federated learning module is also included. This federated learning module adopts a data-without-leaving-factory architecture, enabling the AI ​​model to complete iterative training at the edge. The edge uploads the model's gradient or weight difference to the cloud aggregation center through Diffie-Hellman negotiation combined with AES encryption. After decryption, the cloud aggregation center performs global model aggregation and then sends the new model parameters to the edge through an AES encrypted channel.

[0101] The core function of the federated learning module is to enable distributed federated training of AI models in industrial scenarios (local training at edge nodes and aggregation of model parameters in the cloud, avoiding cross-node transmission of raw industrial data). The core permission control module (including granular permission control, access verification, dynamic permission revocation, and permission mapping tables) provides end-to-end permission protection for "secure training, secure parameter transmission, and compliant node participation" in federated learning. The core logic of their interaction and collaboration is as follows: the federated learning module uses "permission control rules" as the security boundary, while the core permission control module allocates, verifies, and adjusts permissions for each stage of federated learning, ensuring that federated training meets distributed privacy protection requirements while mitigating risks such as "unauthorized participation, parameter leakage, and interference from abnormal nodes." Specific interaction and collaboration scenarios and mechanisms are as follows: I. Before Federated Training: Permission Pre-assignment – ​​Binding “Admission Permissions” to Federated Learning Nodes Before the federated learning module starts distributed training, it needs to rely on the permission granularity control module to complete the "pre-assignment of participating node permissions" to ensure that only authorized nodes can access the training. The specific collaboration process is as follows: The federated learning module submits a "list of training nodes" (including the IDs of each edge node, such as "factory_A_robot_01" and "factory_B_sensor_02") and "training permissions required for each node" (such as "local model parameter upload permission") to the system. "Cloud aggregation parameter download permission" "Training log read permission" (”); The permission granularity control module is based on the "least necessary principle" and generates a unique "minimum permission set for the training period" for each node. (e.g., node "factory_A_robot_01") (No extra permissions), and generate a dynamic access token (JWT format, payload includes) by associating the node ID. (Valid within the training period) The federated learning module distributes tokens to each edge node as "admission credentials" for nodes to access training. Nodes that do not obtain a token or whose token permissions do not match cannot be included in the training cluster by the federated learning module. This achieves the coordination of "permission pre-allocation - node admission" and prevents unauthorized nodes from participating in training and stealing parameters.

[0102] II. In Federated Training: Parameter Transmission Permission Verification – Controlling the “Secure Interaction” of Federated Learning Parameters The core process of the federated learning module (edge ​​nodes uploading local model parameters and the cloud sending aggregated parameters to the nodes) requires the access verification module and the permission mapping table module to achieve "permission verification-resource location" linkage to ensure the security of parameter transmission. The specific collaboration mechanism is as follows: when the edge node uploads local training parameters to the cloud, it must carry the dynamic access token distributed by the federated learning module; the access verification module first verifies the validity of the token (verifies the JWT signature and checks whether the exp has expired), and then extracts the token's contents. of Permissions can be queried through the permission mapping table module. The corresponding "parameter aggregation interface resource address" (e.g., "192.168.3.100 / fl_aggregate"); if the token is valid and If permissions match the resource address, the access verification module allows parameters to be uploaded to the interface. The federated learning module receives the parameters and performs aggregation. If the token is invalid (e.g., tampered with) or has no... The permission and access verification module refuses to transmit, and the federated learning module discards the parameter request for that node to prevent parameter leakage or malicious parameter injection.

[0103] III. In Federated Training: Dynamic Risk Permission Adjustment – ​​Linked "Permission Revoking" for Abnormal Nodes in Federated Learning When the federated learning module detects training anomalies (such as model parameters uploaded by a node deviating from the aggregation trend or abnormal gradient data), it needs to coordinate with the AI ​​attack detection module and the dynamic permission revocation module to revoke the training permissions of the abnormal node in real time. The specific collaborative logic is as follows: The "parameter anomaly detection subunit" of the federated learning module finds that the parameter gradient uploaded by a certain edge node (such as "factory_B_sensor_02") deviates from the normal distribution by more than a threshold, and synchronizes the anomaly information to the AI ​​attack detection module. The AI ​​attack detection module, through the "adversarial example identification submodule," confirms that the parameters have a "risk of malicious tampering" (such as gradient injection attacks), and then identifies the node's " (Parameter upload permission) is marked as "Target permission identifier". , and synchronize to the dynamic permission revocation module; The dynamic permission revocation module, within a real-time time granularity of "100ms-5s", retrieves permissions from the node. Remove from The old token is marked as invalid; at the same time, the federated learning module is notified that "node permissions have been revoked". The federated learning module immediately suspends the receiving and aggregation of parameters for that node to prevent malicious parameters from affecting the global model, thus realizing a collaborative closed loop of "anomaly detection - permission revocation - training protection".

[0104] IV. Post-Federated Training: Model Deployment Permission Binding – Connecting the “Permission Implementation” of the Federated Learning Output Model After the federated learning module completes training and outputs the final industrial AI model, it needs to collaborate with the permission granularity control module and the permission mapping table module to bind the model to the "minimum permission set for deployment," ensuring that the model can only access authorized resources after deployment. The specific collaboration process is as follows: The federated learning module submits a "model deployment request" to the permission granularity control module (e.g., the model needs to "read production line sensor data"). "Control the robotic arm to perform actions" (”); The permission granularity control module is based on the "deployment-phase least privilege set" of the requirement generation model. And generate a dynamic access token for deployment (Payload included) for the model. , = ); Permission mapping table module creation Various permissions (such as) , The mapping relationship between the sensor interface "192.168.2.102 / sensor" and the robotic arm control interface "192.168.2.100 / joint"; The model output by the federated learning module and After the token and permission mapping relationship is bound, when deployed to an industrial scenario, the model needs to verify the token and permissions through the access verification module during runtime to ensure that only access is permitted. The corresponding resources enable the deployment and integration of "federated training model - access control", which aligns with the system's goal of "controllable access throughout the entire model lifecycle".

[0105] Fifth, the essence of their interaction and collaboration is: the federated learning module addresses the business needs of "distributed privacy training" for industrial AI models, while the core permission control module addresses the issues of "secure access, data transmission, risk blocking, and deployment compliance during the privacy training process." This avoids security risks caused by federated learning due to "lack of control over node access, lack of verification of parameter transmission, and lack of handling of abnormal nodes" (such as model parameter leakage and contamination of aggregated models), ultimately achieving the dual goals of "industrial data privacy protection" and "security of model training / deployment permissions."

[0106] In this embodiment, the federated learning module stores and processes training data locally only at the edge, without uploading it to the cloud, thus ensuring that data does not leave the factory. Optionally, the edge is a factory or edge device used to locally store raw production data and train the model based on the raw production data to obtain gradients or weight differences. Optionally, after receiving the encrypted gradients or weight differences, the cloud aggregation center decrypts them using a decryption method negotiated with the edge, and then processes the decrypted gradients or weight differences using a preset aggregation algorithm to complete global model aggregation.

[0107] This federated learning module mainly consists of two parts: the edge devices and the cloud aggregation center. The edge devices can be various factories or edge devices, responsible for raw data storage and local model training; the cloud aggregation center is responsible for receiving encrypted parameters uploaded from the edge devices, performing global model aggregation, and encrypting and distributing new model parameters. The workflow is as follows: 1. Local training and parameter acquisition: Each factory or edge device acts as an edge terminal, storing raw production data locally. The AI ​​model is trained based on this local data, and the gradient or weight difference of the model is obtained during the training process. 2. Encrypted parameter upload: The edge device first determines the encryption key information with the cloud aggregation center through Diffie-Hellman negotiation, then uses the AES encryption algorithm to encrypt the obtained gradient or weight difference, and then uploads the encrypted parameters to the cloud aggregation center. 3. Global Model Aggregation: After receiving the encrypted gradient or weight difference, the cloud aggregation center decrypts it according to the agreed decryption method, and then performs a global model aggregation operation to integrate the parameters uploaded from each edge terminal to form new global model parameters. 4. Encrypted distribution of new parameters: After the cloud aggregation center completes global model aggregation, it encrypts the new model parameters through an AES encryption channel and then distributes them to each edge device. After receiving the new parameters, the edge devices can continue iterative training of the model. In this embodiment, raw production data is always stored locally at the edge and is never uploaded to the cloud or other external nodes, effectively ensuring the local privacy of the data. Parameters are encrypted using AES during both uploading and distribution. Even if intercepted during transmission, the interceptor cannot decipher the parameter content due to the lack of a decryption key, ensuring the security of parameter transmission. On the one hand, this avoids the cross-regional data compliance risks that may arise from data transmission between different factories, complying with the data regulatory requirements of various regions; on the other hand, it eliminates the need to transmit large amounts of raw data, only transmitting model parameters, reducing data transmission volume and improving the overall efficiency of model training.

[0108] Taking the collaborative optimization scenario of "intelligent workpiece grasping" by a four-axis robotic arm in multiple factories as an example, the workflow of the federated learning module is explained: 1. Assume there are three factories (auto parts factory, electronic component factory, and hardware processing factory). Each factory has a four-axis robotic arm responsible for intelligently grasping different types of workpieces (such as automotive bearings, microchips, and hardware parts), and edge devices (such as edge computing gateways) are deployed next to the robotic arms.

[0109] Each edge device locally stores raw production data (strictly adhering to the "data never leaves the factory" principle to avoid leakage of process privacy), including: Automotive parts factory: Visual images (position, posture) of the workpiece when a four-axis robotic arm grasps a "heavy-duty bearing", sequence of joint motion angles of the robotic arm, pressure curve of the gripper, and other data; Electronic component manufacturers: High-precision positioning data and micro-force control parameters for grippers when grasping "microchips" (to prevent chip scratches and deformation); Hardware processing plant: Data such as the complex posture adjustment trajectory when grabbing "irregular hardware parts" and the statistics of success rate of grabbing multiple batches.

[0110] Based on this local data, the edge devices iteratively train the initial "four-axis robotic arm intelligent grasping AI model" delivered from the cloud, calculating the model's gradient or weight difference. The three factories then obtain the results. , , .

[0111] 2. Edge devices in each factory area and the cloud aggregation center negotiate a shared key using the Diffie-Hellman algorithm (pre-agreed large prime numbers and primitive roots; after exchanging public keys, a shared key consistent with both ends is generated). This is then combined with AES encryption to encrypt the gradient or weight difference before uploading. Taking an automotive parts factory as an example, edge devices use the negotiated AES key to... Encrypt and generate ciphertext: It is uploaded to the cloud via the factory network.

[0112] 3. After the cloud aggregation center receives the encrypted gradient / weight difference from each factory area: Decryption: The decryption is restored using a method agreed upon with the edge device (based on a shared Diffie-Hellman key). , , (original gradient or weight difference); Global aggregation: Aggregation algorithms such as "FedAvg" are used to aggregate the gradient / weight differences of each plant area (e.g., calculating...). , , The weighted average of the parameters is used to obtain the global model parameter update amount that integrates experience from multiple scenarios (for example, enabling the model to simultaneously have the ability to "smoothly grasp heavy bearings" and "precisely grasp microchips").

[0113] 4. The cloud aggregation center distributes the aggregated new model parameters to the edge devices in each factory area via an AES encrypted channel. After decryption, the edge devices update their local "four-axis robotic arm intelligent grasping AI model". At this point, the robotic arm in the automotive parts factory can not only grasp bearings more smoothly, but also draw on the "micro-force control" experience of the electronic component factory; the robotic arm in the electronic component factory can also use the aggregated model to more flexibly handle irregular grasping scenarios such as "small hardware parts".

[0114] In another optional embodiment, an AI attack detection module is also included, comprising an input monitoring submodule, an anomaly detection submodule, an adversarial example identification submodule, and a linked permission contraction submodule that work in sequence. The input monitoring submodule is used to perform statistical analysis and feature extraction on the model input traffic to establish a normal input distribution. The anomaly detection submodule is used to immediately trigger an alarm when input data deviates from the normal input distribution. The adversarial example identification submodule is used to identify suspected adversarial attack data using feature compression and gradient sensitivity detection. The linked permission contraction submodule is used to automatically revoke relevant model permissions and block potential intrusion links when attack behavior is detected.

[0115] In this embodiment, the core function of the AI ​​attack detection module is to provide a "risk trigger signal" to the core permission control module (including permission granularity control, access verification, dynamic permission revocation, and permission mapping table) by monitoring input data locally at the edge and identifying adversarial samples and abnormal attack behaviors. The core permission control module then performs "precise permission adjustment" based on this signal, achieving a security closed loop of "attack identification - permission blocking." The core logic of their interaction and collaboration is as follows: the AI ​​attack detection module uses "permission control rules" as the security operation boundary, and the core permission control module transforms the attack detection results into "permission adjustment actions," jointly blocking the transmission path of "attack behavior → permission abuse → system risk," ensuring that permission control is always dynamically optimized around "risk-driven" principles. The specific collaboration mechanism is as follows: I. Attack Detection Triggers Dynamic Permission Revocation: The "Risk Response Trigger Source" of Core Permission Control. When the AI ​​attack detection module identifies a clear attack behavior (such as adversarial sample injection or abnormal input data attack), it directly outputs a "risk command + target permission identifier" to the dynamic permission revoke module, triggering the core permission control module to execute real-time permission revoke. This is the core collaborative scenario between the two. The specific process is as follows: 1. Attack Behavior Identification and Target Permission Location: The "Anomaly Detection Submodule" of the AI ​​Attack Detection Module compares "real-time input data" with "pre-established normal input distributions" (such as Gaussian distributions and kernel density estimation models) to detect data deviations from thresholds (e.g., input feature density values ​​< 0.05). With a false positive rate ≤ 0.1%, the "Adversarial Example Identification Submodule" further verifies the attack attributes (e.g., confirming adversarial examples through feature compression and gradient sensitivity analysis); subsequently, the "Linkage Permission Shrinking Submodule" associates the attack with resource operations (e.g., if the adversarial example attempts to mislead the robotic arm into performing incorrect actions, it associates "Joint Motion Control Permissions"). "End gripper control authority" ), determine the "target permission identifier" that needs to be revoked. The text includes information such as the attack type (e.g., "adversarial sample attack") and risk level (e.g., "high risk").

[0116] 2. Passing and Execution of Privilege Revoking Commands: The AI ​​attack detection module will transmit and execute the "target privilege identifier". The attack-associated model ID / edge node ID is synchronized to the dynamic permission revoke module; the dynamic permission revoke module, based on a "real-time removal" time granularity (100ms-5s), retrieves the current permission set of the model / node. Remove from ,generate At the same time, it marks the old dynamic access token (JWT) as invalid and updates the validity of the "permission identifier-resource address" association through the permission mapping table module (e.g., ...). The corresponding robotic arm control interface address is marked as "temporarily inaccessible"; the access verification module synchronizes this update in real time, and subsequent model requests... By directly denying permissions, a seamless collaboration between "attack identification and permission blocking" is achieved, preventing attacks from causing device malfunctions or data leaks through the abuse of permissions.

[0117] 2. When performing data monitoring and attack identification, the AI ​​attack detection module relies on the core permission control module to allocate "necessary data access permissions" to ensure that it can only legally read local input data on the edge (without unauthorized access to other resources), conforming to the "minimum necessary" principle. Specific collaborative logic is as follows: 1. Pre-application and allocation of required permissions: When deploying the AI ​​attack detection module, a "local data access permission request" is submitted to the permission granularity control module, specifying the data types of the edge devices to be accessed (such as "real-time input feature data" and "normal input distribution model parameters"), with the corresponding permission identifier as follows. (Input data read permission) (Distributed model read permissions); The permission granularity control module generates a unique set of permissions based on the principle of least privilege. And associate the module ID to generate a dynamic access token (JWTPayload contains) The validity period is consistent with the module's operating cycle.

[0118] 2. Access Control Authentication: When the AI ​​attack detection module reads local data from the edge (such as real-time input robotic arm torque data or image features from a visual model), it must send a request to the access authentication module along with this token. The access authentication module then queries the access control mapping table. The corresponding "edge data storage address" (e.g., 192.168.2.103 / detect_data) verifies the token's validity (signature verification, permission matching, validity period) before allowing the detection module to read data; if the token is invalid or the permissions do not match (e.g., the detection module attempts to access device control permissions), the module is not allowed to read the data. If the AI ​​attack detection module is blocked, access will be blocked directly to ensure that its operation is always within the scope of permission control and to prevent it from becoming a new security risk.

[0119] III. After the core permission control module adjusts the permissions, it will feed the results back to the AI ​​attack detection module to help it optimize attack identification rules, forming a closed-loop collaboration of "detection-permission-re-detection". The specific mechanism is as follows: Permission adjustment status synchronization: The dynamic permission revocation module completes the "target permission identifier" process. After "removal", a "permission adjustment confirmation notification" is sent to the AI ​​attack detection module, containing "permissions have been revoked". "Associated Model / Node ID" and "Permission Expiration Time"; for example, retracting the robotic arm. After granting permissions, notify the detection module. This permission is no longer valid and there is no need to monitor attack activities associated with it.

[0120] Detection strategy dynamic optimization: The AI ​​attack detection module adjusts the monitoring scope based on this feedback—if a certain type of attack (such as targeting...) is detected... The permissions corresponding to the adversarial sample have been revoked, so the monitoring priority for this type of attack can be temporarily reduced, and computing power can be concentrated on related data for which permissions have not been revoked (such as...). (Input data corresponding to sensor read permissions); Simultaneously, if the same type of attack is still detected after the permissions are adjusted, feedback can be sent to the permission control module stating "further revocation of associated permissions is required" (e.g., from...). Expand to (Log read permission) drives the core permission control module to perform more thorough permission contraction, achieving synergistic optimization between the two.

[0121] In this embodiment, the establishment of a normal input distribution requires a four-step closed loop: "data acquisition - preprocessing - feature engineering - distribution modeling". All steps are completed collaboratively by the local module at the edge. The specific technical path is as follows: 1. Data Preparation: The input monitoring submodule is responsible for collecting the raw input data from the edge device during normal operation of the industrial AI model (a stable production stage without attacks, equipment failures, or process anomalies). The data types of the input data must cover all core input dimensions of the model.

[0122] 2. Data Preprocessing: The local "data cleaning subunit" removes initial interference and retains valid normal samples. It preprocesses the collected raw data to ensure data purity: Deduplication: Redundant data from repeated collections (such as consecutive identical values ​​caused by sensor signal lag) is deleted. Unique samples are selected using the "adjacent data difference threshold method" (e.g., difference < 0.01% is considered duplicate). Preliminary outlier filtering: Extreme values ​​that significantly deviate from physical principles (non-model-detected anomalies, such as "negative torque values" or "out-of-range angle values" caused by sensor malfunctions) are removed using the "3σ criterion" (based on the mean and standard deviation of initial statistics) or the "box plot method" (IQR = Q3 - Q1, removing data < Q1 - 1.5IQR or > Q3 + 1.5IQR). Data standardization: Z-score standardization is performed on input data of different dimensions (e.g., "angle (°)" and "load (kg)"). (The mean and standard deviation of the initial normal data) eliminate the influence of units and unify the data scale for subsequent distribution modeling.

[0123] 3. Feature Engineering: Extracting Core Representation Dimensions of Input Data. For the preprocessed raw data, extract key dimensions that reflect "normal input features" to avoid redundant dimensions in the raw data that lead to low modeling efficiency: Time-series input data (such as sensor signals): Extract statistical features (mean, standard deviation, peak value, valley value, time-domain correlation) and frequency domain features (extract main frequency components and power spectral density through Fourier transform); Image input data (such as workpiece visual data): Extract texture features (gray-level co-occurrence matrix), shape features (profile moments, area, perimeter), and color features (RGB channel mean, saturation variance); Feature extraction should be completed in local memory at the edge, without generating temporary files, and the feature vector dimension should be controlled within 50 dimensions to balance modeling accuracy and computational efficiency.

[0124] 4. Distribution Modeling: Combining Parametric and Non-parametric Statistical Methods. Based on the distribution characteristics of the input features, an appropriate statistical method is selected to construct a normal input distribution model. The two core methods are as follows: (1) Parameterization method: Preset distribution form and model based on statistics. It is suitable for scenarios where the feature data conforms to a clear mathematical distribution (such as the statistical characteristics of sensor time series data, which mostly conform to a normal distribution), and the core is the Gaussian distribution (normal distribution) or Gaussian mixture model (GMM): 1. Univariate Gaussian distribution (suitable for single-dimensional features): For each feature dimension, calculate the mean of the normal samples. With variance Construct a normal distribution N( ) in this dimension , The formula is: ; 2. Gaussian Mixture Model (GMM, suitable for multimodal distributions): When there are multiple normal operating conditions in an industrial scenario (such as "processing workpiece A" and "processing workpiece B" corresponding to different input feature distributions), GMM is used to fit the multimodal data as a weighted sum of K single Gaussian distributions, and the mean of each sub-Gaussian distribution is estimated by the Expectation-Maximization (EM) algorithm. Covariance With weight ( The total distribution is as follows: The K value is determined by the Bayesian Information Criterion (BIC) to avoid overfitting. Typically, K = 2 to 5 (corresponding to 2 to 5 normal operating conditions).

[0125] (2) Non-parametric method: No preset distribution, data-driven modeling It is suitable for scenarios with irregular feature distributions (without explicit mathematical forms), and its core is kernel density estimation (KDE): By applying a kernel function, such as a Gaussian kernel, to each normal sample point: The overall probability density is estimated by the weighted sum of all kernel functions, as shown in the formula: , Where n is the number of normal samples, and h is the bandwidth (controlling the smoothness of the kernel function); Key parameter selection: A Gaussian kernel is preferred for the kernel function (to adapt to the continuity of industrial data). The bandwidth h is determined using cross-validation (normal samples are divided into training and validation sets, and the h value that minimizes the validation set density estimation error is selected; h is typically between 0.1 and 1.0). KDE is suitable for modeling the distribution of image input features (such as texture features), as image feature distributions are often asymmetric and multi-modal, and no fixed parameterized distribution can be adapted. The establishment of the normal input distribution is completed entirely locally at the edge: data is collected from edge devices, and preprocessing, feature engineering, and distribution modeling are all executed collaboratively by the federated learning submodule and the attack detection submodule locally at the edge. No raw data or feature data is uploaded to the cloud; only the final distribution model parameters are stored in local encrypted memory.

[0126] Optionally, in the adversarial example identification submodule, feature compression uses a dimensionality reduction algorithm to extract and simplify key features of the input data, and gradient sensitivity detection identifies adversarial attack data by analyzing the impact of small changes in the input data on the model gradient. Optionally, the input monitoring submodule collects historical normal input data within a preset time period and constructs the normal input distribution using probabilistic statistical methods. Optionally, in the anomaly detection submodule, the criteria for determining whether input data deviates from the normal distribution include the extreme noise level of the data and abnormal fluctuations in the request frequency.

[0127] The industrial AI model security protection module in this embodiment consists of an input monitoring submodule, an anomaly detection submodule, an adversarial example identification submodule, and a linked permission reduction submodule. These modules work in tandem according to the process of "traffic analysis → anomaly alarm → attack identification → permission reduction," constructing multiple layers of security protection before the model receives input, intercepting malicious input at the source, and preventing harm to the model and downstream industrial systems. The input monitoring submodule is responsible for constructing a "benchmark distribution of normal input data." By collecting input traffic (such as physical quantity data collected by sensors, equipment control command flow, etc.) during normal model operation in industrial scenarios (such as intelligent manufacturing production lines, industrial control systems), it analyzes and extracts features from the data's numerical range, fluctuation frequency, and feature correlation using probabilistic statistical methods (such as Gaussian distribution fitting, kernel density estimation), ultimately establishing a distribution model of normal input. Based on the normal distribution established by the input monitoring submodule, the anomaly detection submodule compares the deviation of the current input data with the benchmark in real time. When the input data exhibits extreme noise (such as values ​​exceeding three times the normal distribution standard deviation) or abnormal request frequency (such as the number of requests per unit time being far higher than the normal peak frequency), it is determined that the data deviates from the normal distribution, and an alarm is immediately triggered, providing an initial signal for subsequent attack identification.

[0128] To address adversarial attacks in industrial scenarios (such as tampering with sensor data to mislead model decisions), the adversarial example identification submodule employs a combined strategy of "feature compression + gradient sensitivity detection." Feature compression: Extracting key features from input data and simplifying dimensions using dimensionality reduction algorithms (such as PCA and LDA), removing redundant interference, and focusing on the rationality of core features. Gradient sensitivity detection: Analyzing the impact of minor changes in input data on the gradient of the AI ​​model (the basis for parameter updates). Adversarial examples often exploit the characteristic of "minor data tampering significantly affecting the model gradient." If a minor change in input is detected to cause drastic fluctuations in the model gradient, it is identified as data suspected of being used in an adversarial attack. When an anomaly or attack is identified, the linked permission contraction submodule works in conjunction with the system's "least privilege control mechanism" to automatically revoke the access permissions (such as inference calls and parameter reading permissions) of the requesting entity (such as edge devices or remote terminals) to the relevant AI model, while simultaneously blocking the communication link, cutting off potential intrusion paths at the permission level.

[0129] Taking a four-axis robotic arm intelligently grasping automotive parts as an example, the workflow of the AI ​​attack detection module is explained: In a factory, the four-axis robotic arm automatically grasps automotive parts (such as bearings and housings) from a conveyor belt. The AI ​​model outputs the robotic arm's movement (joint angles) and grasping (gripper opening and closing) commands based on the "workpiece image captured by the vision system." The AI ​​attack detection module needs to monitor in real time to prevent attacks on the model from causing malfunctions in the robotic arm (such as collisions with equipment, damage to workpieces, or even threats to the safety of factory personnel). The collaborative working process of each submodule is as follows: 1. Input Monitoring Submodule: Establishes Normal Input Distribution Two types of core input data are collected during the normal production period of the robotic arm, and a "normal input distribution" is constructed through probability statistics: workpiece visual data: "clear images of automotive parts" captured by the vision system within a continuous week (recording the size range, color distribution, and position range on the conveyor belt of the parts); control command flow: during normal production, the "grabbing command frequency" (e.g., once every 5 seconds) received by the model, and the numerical range of "joint angle parameters" and "pneumatic gripper pressure parameters" within the commands (e.g., joint rotation angle between 0° and 90°, and pneumatic gripper pressure between 0.3 and 0.5 MPa).

[0130] Through probabilistic statistical methods (such as Gaussian distribution fitting), the rule is finally established: the workpiece center coordinates should be within the conveyor belt area. The image noise level is below the threshold Y, and the command frequency is stable at 5±1 seconds / time.

[0131] 2. Anomaly Detection Submodule: Identifies input that "deviates from normal". When the input data shows the following conditions, an alarm is triggered immediately: Extreme image noise: The part image transmitted by the vision system suddenly becomes blurry and distorted (the noise level far exceeds the threshold Y), seemingly "maliciously tampered with"; Abnormal command frequency: 3 grab commands are received in a short period of time (such as within 1 second) (far higher than the normal "once every 5 seconds" rhythm), breaking the statistical law of "normal command flow".

[0132] 3. Adversarial Example Identification Submodule: Accurately identifies "attack data" For suspicious inputs that trigger alarms, determine whether they are adversarial attack data through "feature compression + gradient sensitivity detection" (this type of data may seem normal, but it can actually mislead the AI ​​model to output incorrect instructions): (1) Feature compression: Use dimensionality reduction algorithms (such as PCA) to extract key features of the image (such as the outline, corners, and center coordinates of the part) to assess whether the image features match the features of a normal part; (2) Gradient sensitivity detection: Add tiny pixel perturbations (such as slight adjustments to the brightness of individual pixels) to the input image and observe the gradient of the robotic arm motion output by the AI ​​model (i.e., the calculated gradient of joint angles and gripper control). The gradient change of a normal image will be very smooth. If a tiny perturbation causes the gradient to fluctuate violently, it is judged as suspected adversarial attack data, because this type of data can cause the model to misjudge the position / shape of the part and thus output incorrect control instructions.

[0133] 4. Linked permission-based shrinking submodule: Blocking the "attack → misoperation" chain. If "adversarial attack data" is identified, this submodule will automatically revoke the core permissions of the AI ​​model: for example, immediately revoke the "four-axis robotic arm joint motion control permissions" ( "End gripper control authority ()" This prevents the model from sending "movement" and "grasping" commands to the robotic arm, blocking the risk of "attack → erroneous model command → robotic arm malfunction" at the source and ensuring the safety of production line and workshop personnel. The AI ​​attack detection module can proactively defend against "malicious attacks targeting the model": it not only prevents the robotic arm from colliding with equipment / injuring people due to erroneous commands, but also prevents core production data from being stolen or tampered with due to attacks.

[0134] In another optional embodiment, a real-time stream encryption module is also included. This module uses the TLS 1.3 protocol or ZeroTrust architecture to construct an encrypted channel and encrypt the real-time data transmission stream between the model and the system. To ensure the security of the "real-time data transmission between the model and the system," this module uses the TLS 1.3 protocol or ZeroTrust architecture to construct an encrypted channel and provides end-to-end encryption protection for the real-time transmitted data stream (such as model parameter update streams, device status reporting streams, etc.). If the TLS 1.3 protocol is used: the module completes a "secure handshake" before data transmission, quickly negotiates a "session key," and then uses this key to encrypt the real-time data stream. Even if the data is intercepted, it cannot be decrypted without the key. If the ZeroTrust architecture is used: following the principle of "never trust, always verify," each transmission stream undergoes "authentication + fine-grained access control + encryption" to ensure that only strictly verified entities can transmit / obtain data.

[0135] In another optional embodiment, a data anonymization module is also included. This module is capable of scanning system-generated logs in real time, automatically identifying and masking confidential information in the logs. System operation generates a large number of logs (such as access logs, operation logs, model training logs, etc.), which may contain confidential content such as "device ID, user information, and core parameters." The data anonymization module scans the system logs in real time, using techniques such as "regular expression matching" and "key field detection" to automatically identify and mask confidential information in the logs (e.g., replacing real IDs with virtual IDs, using "*" to cover sensitive fields), preventing the leakage of confidential information during log storage, auditing, and sharing.

[0136] In another optional embodiment, a training data obfuscation module is also included. This module hides real-world operating condition data by adding spurious noise to the training data, preventing the leakage of real-world operating condition information during model training. The core objective of this module is to hide the core features of real-world operating condition data. By adding spurious noise to the training data, it obfuscates and protects information such as the distribution patterns and precise values ​​of the original data without compromising the effectiveness of model training. Specifically, the module injects an appropriate amount of "meaningless but statistically consistent" spurious noise into real-world operating condition data (such as temperature and pressure sequences in industrial production, and amount and time series in financial transactions) based on a preset noise generation algorithm (such as Gaussian noise, uniform noise algorithm, etc.). This preserves the "effective trend features" of the data for AI model training while preventing the direct leakage of core secrets of real-world operating conditions through the data.

[0137] In another optional embodiment, a model watermarking and verification module is also included. This module embeds a unique watermark in the AI ​​model and provides watermark verification functionality to confirm model ownership. The core function of the model watermarking and verification module is to assign a "digital identity" to the AI ​​model by embedding unique watermark information in the model parameters, structure, or output, thereby enabling traceability and verification of model ownership. The overall operation is divided into two core stages: "watermark embedding" and "watermark verification." Watermark embedding stage: The module employs robust watermarking technology to integrate a pre-set unique watermark (which can consist of a specific sequence, digital signature, or encrypted information) into the AI ​​model in a way that has minimal impact on model performance and is difficult to detect. Specific embedding methods are flexible and diverse. For example: in the model weight parameters, "minor statistical perturbations based on the attribution identifier (such as enterprise patent number, trademark hash value)" are added to non-critical weights; at specific levels of the model structure (such as the attention layer of a Transformer, the output layer of a neural network), logical branches or feature codes associated with the watermark are implanted; in the model's output results (such as predicted labels, visualization results), "invisible feature patterns" corresponding to the watermark (unrecognizable to the human eye, but analyzable by the algorithm) are hidden.

[0138] In addition, during the watermark verification stage: when it is necessary to confirm the ownership of a model, the verifier uses a pre-set verification algorithm or tool to perform "watermark extraction and comparison" on the target model. The extraction process specifically analyzes the model's parameters, structure, or output to decode the embedded watermark information; then, the extracted watermark is matched with the "owner's watermark library". If the two match, the original ownership of the model can be determined.

[0139] In another optional embodiment, a multi-tenant access control module is also included, which employs a mechanism combining device authorization and IP binding to allow only authorized devices and access requests initiated from bound IP addresses to access the system.

[0140] For scenarios where "multi-tenants share system resources but require isolated access," this module employs a dual authentication mechanism of "device authorization + IP binding" to ensure that only requests initiated by legitimate devices from legitimate network locations can access the system. The specific process is as follows: Device Authorization: The system generates a unique "authorization identifier" (such as a device certificate or hardware key) for each tenant's access device (e.g., server, edge terminal). Devices without a valid identifier are directly blocked. IP Binding: Authorized devices are bound to the tenant's dedicated IP address (or IP range), allowing devices to initiate access only from "pre-bound trusted IPs". When an access request arrives, the module first verifies whether the "device authorization identifier is valid", and then verifies whether the "request source IP is bound to the device". Access is only allowed after both verifications are successful.

Claims

1. An industrial AI model safety management and control system, characterized in that, include: The permission granularity control module is used to declare the minimum set of permissions required by an AI model when it is registered. It also generates dynamic access tokens containing a list of permissions for the model. ;in This serves as an identifier for resource operation permissions. The permission mapping table module is used to maintain the mapping relationship between resource operation permission identifiers and actual resource addresses. ; The access verification module verifies the dynamic access token when the model requests system resources. The validity and scope of permissions should be determined, and unauthorized access should be denied. The dynamic permission revoke module is used to remove the set of authorized permissions for a model in real time. Target permission identifier within Update the permission set: and mark the old tokens Invalid, based on the new permission set Generate a new token with a timestamp .

2. The system according to claim 1, characterized in that, The specific process by which the permission granularity control module generates dynamic access tokens for the model is defined by the following formula: ； in, The minimum set of permissions declared when the model is registered; The expiration date of this token; The payload of the generated JWT token contains a unique identifier for the model, a list of authorized resources, and an expiration date.

3. The system according to claim 1, characterized in that, Also includes: The cloud, as one of the main communication entities for encrypted transmission of model parameters, includes a cloud key negotiation module and a cloud receiving and decryption module; The edge end, as another communication entity for the encrypted transmission of model parameters, includes an edge end key negotiation module and an edge end receiving and decryption module; The cloud-based key negotiation module randomly selects a private key. Large prime numbers based on convention and original roots Calculate the public key After exchanging public keys with the edge device, a shared key is calculated based on the edge device's public key. Among them, large prime numbers and original roots These are publicly shared parameters between the cloud and the edge. The edge-end key negotiation module randomly selects a private key. Large prime numbers based on convention and original roots Calculate the public key After exchanging public keys with the cloud, a shared key is calculated based on the cloud's public key. ; The key derivation module will generate the shared key. Converted into an AES encryption key using a hash algorithm. The key derivation module is associated with both the cloud-based key negotiation module and the edge-based key negotiation module via a shared key K, ensuring that both ends... Consistent; Parameter transmission module, using For model weight vector Encryption yields ciphertext and ciphertext Transmitted to the cloud to receive the decryption module or to the edge to receive the decryption module; The cloud-based receiving and decryption module utilizes the key generated by the key derivation module. For ciphertext Decrypt and restore the original model parameters ; The edge terminal receiving decryption module uses the key generated by the key derivation module. For ciphertext Decrypt and restore the original model parameters .

4. The system according to claim 3, characterized in that, The shared key K is converted into an AES encryption key. The hash algorithm used is SHA-256. The shared key K is hashed using the SHA-256 algorithm to generate a symmetric key that meets the AES encryption requirements. The model weight vector W is the model weight vector deployed by the AI ​​model.

5. The system according to any one of claims 1 to 4, characterized in that, It also includes a federated learning module, which adopts a data-free architecture to enable AI models to complete iterative training at the edge. The edge uploads the model's gradient or weight difference to the cloud aggregation center through Diffie-Hellman negotiation combined with AES encryption. The cloud aggregation center performs global model aggregation after decryption and then sends the new model parameters to the edge through an AES encrypted channel.

6. The system according to any one of claims 1 to 4, characterized in that, It also includes an AI attack detection module, comprising an input monitoring submodule, an anomaly detection submodule, an adversarial example identification submodule, and a linked permission reduction submodule that work in sequence; the input monitoring submodule is used to perform statistical analysis and feature extraction on the model input traffic and establish a normal input distribution; The anomaly detection submodule is used to immediately trigger an alarm when it detects that the input data deviates from the normal input distribution; The adversarial sample identification submodule is used to identify suspected adversarial attack data by using feature compression and gradient sensitivity detection; the linked permission contraction submodule is used to automatically revoke relevant model permissions and block potential intrusion links when attack behavior is detected.

7. The system according to claim 6, characterized in that, In the adversarial example identification submodule, feature compression uses a dimensionality reduction algorithm to extract and simplify key features of the input data, while gradient sensitivity detection identifies adversarial attack data by analyzing the impact of small changes in the input data on the model gradient.

8. The system according to any one of claims 1 to 4, characterized in that, It also includes a real-time stream encryption module, which uses the TLS1.3 protocol or ZeroTrust architecture to build an encrypted channel to encrypt and protect the real-time data transmission stream between the model and the system.

9. The system according to any one of claims 1 to 4, characterized in that, It also includes a data anonymization module, which can scan the logs generated by the system in real time and automatically identify and mask confidential information in the logs.

10. The system according to any one of claims 1 to 4, characterized in that, It also includes a training data obfuscation module, which hides the real working condition data by adding fake noise to the training data.

Images