Model incremental training security protection method and related device
By encrypting and dynamically obfuscating model parameters and embedding an active protection mechanism, the problems of feature leakage and malicious tampering in incremental training are solved, and the security and traceability of the model deployment process are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- ANHUI IFLYTEK UNIVERSAL LANGUAGE TECH CO LTD
- Filing Date
- 2026-02-14
- Publication Date
- 2026-05-29
AI Technical Summary
Incremental training presents risks of feature leakage and difficulty in identifying malicious tampering of intermediate layer gradient information, which affects the security of the model deployment process.
By encrypting model parameters, embedding proactive protection mechanisms, and performing model solidification and dynamic obfuscation, a traceable and verifiable security boundary is constructed. This includes model parameter fragment encryption, static encryption, runtime dynamic token generation and verification logic, as well as the encapsulation of model training code and the lightweighting of image files.
While ensuring model performance, the training code, parameters, and model structure are prevented from being spied on, thus achieving security and traceability in the model deployment process.
Smart Images
Figure CN122113135A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of model training technology, and in particular to a method and related device for ensuring the security of incremental model training. Background Technology
[0002] With the rapid development of deep learning technology, the traditional batch retraining mode has been gradually phased out due to its huge resource consumption. Incremental parameter updates based on new data (i.e., incremental training) have significantly improved efficiency, and incremental training has become the mainstream paradigm for continuous optimization of large-scale models. However, incremental training also introduces security risks: on the one hand, frequent model version replacements may lead to a significant increase in the risk of feature leakage, and attackers can reverse-engineer sensitive training data by observing the behavioral differences before and after the update; on the other hand, malicious tampering with intermediate layer gradient information or injection of adversarial samples is difficult to be effectively identified by existing protection systems.
[0003] Therefore, how to provide a method for ensuring the security of incremental model training, and how to build a traceable and verifiable security boundary while ensuring model performance, so as to prevent the model training code, training parameters, and trained model structure and parameters from being spied on during subsequent model deployment, has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0004] In view of the above problems, this application provides a method and related apparatus for ensuring security during incremental model training. This aims to construct a traceable and verifiable security boundary while guaranteeing model performance, thereby preventing the model training code, training parameters, and the trained model structure and parameters from being spied on during subsequent model deployment. The specific solution is as follows:
[0005] The first aspect of this application provides a method for ensuring security during incremental model training, including:
[0006] After incrementally training the pre-trained model, obtain the original model file after the incremental training is completed. The original model file includes the model training code, model structure and model parameters.
[0007] The model parameters are encrypted to obtain encrypted model parameters;
[0008] Based on the original model file, the model is solidified to obtain an intermediate model representation. An active protection mechanism is embedded in the intermediate model representation. The active protection mechanism includes model parameter fragmentation encryption key verification logic, model parameter static encryption key verification logic, and runtime dynamic token generation and verification logic, which are integrated into the model computation flow.
[0009] The intermediate representation of the model is dynamically obfuscated to obtain the dynamically obfuscated intermediate representation of the model.
[0010] The version of the model to be deployed is determined based on the encrypted model parameters and the intermediate representation of the model after dynamic obfuscation.
[0011] In one possible implementation, the process of solidifying the model based on the original model file to obtain an intermediate model representation includes:
[0012] Based on the original model file, the torch.jit.trace function is used to solidify the model and obtain an intermediate representation of the model.
[0013] In one possible implementation, encrypting the model parameters to obtain encrypted model parameters includes:
[0014] Based on the features of the input sample of the torch.jit.trace function, a fragmented encryption key is generated, and the fragmented encryption key is used to encrypt the model parameters in fragments to obtain the fragmented encrypted model parameters;
[0015] Obtain the first sub-key from the preset key system and perform static encryption on the core parameters in the model parameters to obtain the statically encrypted model core parameters.
[0016] In one possible implementation, the model parameter fragmentation encryption key verification logic includes:
[0017] Before forward propagation of the model, verify whether the features of the model input are consistent with the features of the input sample of the torch.jit.trace function. If they are consistent, decrypt the fragmented encrypted model parameters and use them in the calculation.
[0018] In one possible implementation, the static encryption key verification logic for the model parameters includes:
[0019] Verify whether the operating environment is legitimate. If the operating environment is legitimate, decrypt the core parameters of the statically encrypted model and use them in the calculation.
[0020] In one possible implementation, the runtime dynamic token generation and verification logic includes:
[0021] After the forward propagation of each layer of the model is completed, the feature values of the output tensor of the current layer are extracted;
[0022] The current layer token is generated using the second subkey in the preset key system and the feature value of the current layer output tensor.
[0023] The current layer token is embedded into the computation flow of the next layer. Before the next layer is executed, the current layer token is decrypted and the feature value of the current layer output tensor is verified to match the current input feature. If the verification fails, the model self-destruct logic is triggered.
[0024] For dynamically calculated branches, an independent token is generated for each branch to ensure the integrity verification of the branch execution path.
[0025] In one possible implementation, the method further includes:
[0026] The model training code is encapsulated using a third-party tool to obtain the encapsulated model training code;
[0027] Build a lightweight image file;
[0028] The process of determining the model version to be deployed based on the encrypted model parameters and the intermediate model representation after dynamic obfuscation includes:
[0029] The encapsulated model training code, the encrypted model parameters, the dynamically obfuscated intermediate model representation, and the lightweight image file are identified as the model version to be deployed.
[0030] In one possible implementation, the method further includes:
[0031] During incremental training of the pre-trained model, the key used to encrypt the gradient of the newly generated parameters is rotated periodically based on the data batch and the iteration round of the model parameters.
[0032] A second aspect of this application provides a model incremental training security protection device, comprising:
[0033] The acquisition unit is used to acquire the original model file after incremental training of the pre-trained model. The original model file includes model training code, model structure and model parameters.
[0034] A model parameter encryption unit is used to encrypt the model parameters to obtain encrypted model parameters;
[0035] The model solidification unit is used to solidify the model based on the original model file to obtain an intermediate model representation. The intermediate model representation is embedded with an active protection mechanism, which includes model parameter fragmentation encryption key verification logic, model parameter static encryption key verification logic, and runtime dynamic token generation and verification logic integrated in the model computation flow.
[0036] A dynamic obfuscation processing unit is used to perform dynamic obfuscation processing on the intermediate representation of the model to obtain a dynamically obfuscated intermediate representation of the model.
[0037] The model version determination unit is used to determine the model version to be deployed based on the encrypted model parameters and the intermediate model representation after dynamic obfuscation.
[0038] In one possible implementation, the model solidification unit is specifically used for:
[0039] Based on the original model file, the torch.jit.trace function is used to solidify the model and obtain an intermediate representation of the model.
[0040] In one possible implementation, the model parameter encryption unit is specifically used for:
[0041] Based on the features of the input sample of the torch.jit.trace function, a fragmented encryption key is generated, and the fragmented encryption key is used to encrypt the model parameters in fragments to obtain the fragmented encrypted model parameters;
[0042] Obtain the first sub-key from the preset key system and perform static encryption on the core parameters in the model parameters to obtain the statically encrypted model core parameters.
[0043] In one possible implementation, the model parameter fragmentation encryption key verification logic includes:
[0044] Before forward propagation of the model, verify whether the features of the model input are consistent with the features of the input sample of the torch.jit.trace function. If they are consistent, decrypt the fragmented encrypted model parameters and use them in the calculation.
[0045] In one possible implementation, the static encryption key verification logic for the model parameters includes:
[0046] Verify whether the operating environment is legitimate. If the operating environment is legitimate, decrypt the core parameters of the statically encrypted model and use them in the calculation.
[0047] In one possible implementation, the runtime dynamic token generation and verification logic includes:
[0048] After the forward propagation of each layer of the model is completed, the feature values of the output tensor of the current layer are extracted;
[0049] The current layer token is generated using the second subkey in the preset key system and the feature value of the current layer output tensor.
[0050] The current layer token is embedded into the computation flow of the next layer. Before the next layer is executed, the current layer token is decrypted and the feature value of the current layer output tensor is verified to match the current input feature. If the verification fails, the model self-destruct logic is triggered.
[0051] For dynamically calculated branches, an independent token is generated for each branch to ensure the integrity verification of the branch execution path.
[0052] In one possible implementation, the device further includes:
[0053] The code encapsulation unit is used to encapsulate the model training code using third-party tools to obtain the encapsulated model training code.
[0054] The image processing unit is used to build lightweight image files;
[0055] The unit for determining the version of the model to be deployed is specifically used for:
[0056] The encapsulated model training code, the encrypted model parameters, the dynamically obfuscated intermediate model representation, and the lightweight image file are identified as the model version to be deployed.
[0057] In one possible implementation, the device further includes:
[0058] The key rotation unit is used to periodically rotate the key used to encrypt the newly generated parameter gradients based on data batches and model parameter iteration rounds during incremental training of the pre-trained model.
[0059] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the model incremental training security protection method described in the first aspect or any implementation thereof.
[0060] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:
[0061] The memory is used to store computer programs;
[0062] The processor is used to execute the computer program so that the electronic device can implement the model incremental training security protection method of the first aspect or any implementation thereof.
[0063] The fifth aspect of this application provides a computer-readable storage medium carrying one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the model incremental training security protection method described in the first aspect or any implementation thereof.
[0064] By employing the above technical solution, the incremental training security protection method and apparatus provided in this application, after incrementally training the pre-trained model, encrypts the model parameters, solidifies the model to obtain an intermediate representation, and dynamically obfuscates the intermediate representation to obtain the model version to be deployed. During the deployment of the model version, because the model parameters are encrypted, and the intermediate representation incorporates proactive protection mechanisms including logic for verifying model parameter shard encryption keys fused in the model computation flow, logic for verifying static encryption keys for model parameters, and logic for dynamic token generation and verification at runtime, and also undergoes dynamic obfuscation, a traceable and verifiable security boundary is constructed while ensuring model performance. Therefore, it can prevent the training code, training parameters, and the trained model structure and parameters from being spied on. Attached Figure Description
[0065] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.
[0066] Figure 1 A flowchart illustrating a model incremental training security protection method provided in this application embodiment;
[0067] Figure 2 This application provides a schematic diagram of the runtime dynamic token generation and verification logic execution flow.
[0068] Figure 3 A flowchart illustrating another model incremental training security protection method provided in this application embodiment;
[0069] Figure 4 A schematic diagram of a model incremental training security protection device provided in this application embodiment;
[0070] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0071] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.
[0072] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.
[0073] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.
[0074] With the rapid development of deep learning technology, the traditional batch retraining mode has been gradually phased out due to its huge resource consumption. Incremental parameter updates based on new data (i.e., incremental training) have significantly improved efficiency, and incremental training has become the mainstream paradigm for continuous optimization of large-scale models. However, incremental training also introduces security risks: on the one hand, frequent model version replacements may lead to a significant increase in the risk of feature leakage, and attackers can reverse-engineer sensitive training data by observing the behavioral differences before and after the update; on the other hand, malicious tampering with intermediate layer gradient information or injection of adversarial samples is difficult to be effectively identified by existing protection systems.
[0075] Therefore, how to provide a method for ensuring the security of incremental model training, and how to build a traceable and verifiable security boundary while ensuring model performance, so as to prevent the model training code, training parameters, and trained model structure and parameters from being spied on during subsequent model deployment, has become a technical problem that urgently needs to be solved by those skilled in the art.
[0076] To address the aforementioned issues, this application provides a method for ensuring security during incremental model training. The method for ensuring security during incremental model training according to this application will be described in detail below with reference to the accompanying drawings.
[0077] Reference Figure 1 , Figure 1 This is a flowchart illustrating a model incremental training security protection method provided in an embodiment of this application, as shown below. Figure 1As shown in the embodiments of this application, a model incremental training security protection method may include the following steps, which are described in detail below.
[0078] S101: After incrementally training the pre-trained model, obtain the original model file after the incremental training is completed. The original model file includes the model training code, model structure and model parameters.
[0079] In this application, the PyTorch framework can be used to incrementally train and test the model in a Python-based development environment. After incremental training is completed, the original model file is obtained, which includes the model training code, model structure, and model parameters; the original model file is in PyTorch format, which can only be deployed in an environment with a Python interpreter.
[0080] S102: Encrypt the model parameters to obtain encrypted model parameters;
[0081] In this application, various encryption methods can be used to encrypt the model parameters to obtain encrypted model parameters. In one possible implementation, the model parameters can be encrypted in segments and the core parameters can be statically encrypted to obtain encrypted model parameters.
[0082] S103: Based on the original model file, the model is solidified to obtain an intermediate model representation; an active protection mechanism is embedded in the intermediate model representation, which includes model parameter fragmentation encryption key verification logic, model parameter static encryption key verification logic, and runtime dynamic token generation and verification logic fused in the model computation flow;
[0083] In this application, during the process of model solidification based on the original model file, the runtime dynamic token generation and verification logic is compiled into nodes of the model intermediate representation, so that the runtime dynamic token generation and verification logic is embedded in the model intermediate representation, which can ensure the integration of dynamic verification and model computation flow.
[0084] The original model file is in PyTorch format, which can only be deployed in an environment with a Python interpreter. The torch.jit.trace function can convert the PyTorch format model to TorchScript format so that it can run in environments without a Python interpreter (such as Android systems).
[0085] In one possible implementation, the step of solidifying the model based on the original model file to obtain an intermediate model representation includes: using the torch.jit.trace function to solidify the model based on the original model file to obtain an intermediate model representation.
[0086] Specifically, the `torch.jit.trace` function generates an Intermediate Representation (IR) by tracing the model's forward propagation process, exporting the model in TorchScript format. TorchScript is a serialized script that contains not only the model's structure and parameters but also its forward inference logic, enabling the model to run without a Python interpreter environment.
[0087] The traditional process of using the torch.jit.trace function for model solidification can be summarized as follows:
[0088] Loading the model: Receives an nn.Module instance, parses the layers defined in its __init__ and the data flow logic defined in its forward (from the model training code);
[0089] Inject current parameters: Read the current values of all parameters in the model (weights after training or random values) and use them as constant inputs to the operator;
[0090] Perform forward propagation: Run the model(example_input) with the example input, strictly following the logic of forward (the path in the training code);
[0091] Generate IR: Record the sequence of all tensor operators, parameter references, and input / output shapes during propagation to generate a static TorchScript graph.
[0092] It should be noted that generating an IR using the torch.jit.trace function requires an input sample.
[0093] For example: dummy_input = torch.rand(1, 3, 224, 224)
[0094] # IR generation
[0095] with torch.no_grad():
[0096] jit_model = torch.jit.trace(model, dummy_input)
[0097] Unlike the traditional method of using the torch.jit.trace function for model solidification, this application embeds an active protection mechanism during the process of using the torch.jit.trace function for model solidification, so that the active protection mechanism is embedded in the intermediate representation of the final generated model.
[0098] S104: Perform dynamic obfuscation processing on the intermediate representation of the model to obtain the intermediate representation of the model after dynamic obfuscation processing;
[0099] Conventional intermediate model representations maintain the readability of the original computational flow. In this application, the intermediate model representation is dynamically obfuscated so that it cannot be directly mapped to the original model structure.
[0100] In one possible implementation, dynamic obfuscation of the intermediate model representation includes inserting "pseudo-operators" into the intermediate model representation, performing equivalent substitutions on the order of operators in the intermediate model representation, and replacing some native operators with custom encrypted operators.
[0101] It should be noted that, in this application, the "pseudo-operators" inserted into the intermediate representation of the model are redundant operations that do not affect the calculation results. Examples of equivalent substitution of the operator order in the intermediate representation of the model include swapping the order of two independent additions, and replacing some native operators with custom encryption operators, such as splitting nn.Linear into multiple encryption sub-steps. The specific dynamic obfuscation processing method can be set based on scenario requirements, and this application does not impose any limitations on it.
[0102] S105: Determine the model version to be deployed based on the encrypted model parameters and the intermediate model representation after dynamic obfuscation.
[0103] In this application, the model version to be deployed includes the encrypted model parameters and the intermediate model representation after dynamic obfuscation processing, and the model version to be deployed can be directly used for model deployment.
[0104] In this solution, during the deployment of the model version to be deployed, the model parameters are encrypted, and the intermediate model representation is embedded with an active protection mechanism that includes the logic for verifying the model parameter shard encryption key in the model computation flow, the logic for verifying the model parameter static encryption key, and the logic for generating and verifying dynamic tokens at runtime. In addition, dynamic obfuscation is performed, which realizes the construction of a traceable and verifiable security boundary while ensuring model performance. Therefore, it can prevent the training code, training parameters, and the trained model structure and model parameters from being spied on.
[0105] In one possible implementation, encrypting the model parameters to obtain encrypted model parameters includes:
[0106] Based on the features of the input sample of the torch.jit.trace function, a fragmented encryption key is generated, and the fragmented encryption key is used to encrypt the model parameters in fragments to obtain the fragmented encrypted model parameters;
[0107] Obtain the first sub-key from the preset key system and perform static encryption on the core parameters in the model parameters to obtain the statically encrypted model core parameters.
[0108] In this application, a fragmented encryption key can be generated based on the hash value of the input sample of the torch.jit.trace function, and then used to perform fragmented encryption on the model parameters.
[0109] In this application, the core parameters in the model parameters refer to the convolution kernel weights, attention matrix, etc. Other parameters besides the core parameters can be called non-core parameters (such as biases). In this application, non-core parameters can be preserved in plaintext to balance efficiency.
[0110] In this application, the preset key system is as follows:
[0111] A root key is generated and stored in trusted hardware to avoid hardcoding. First and second subkeys are derived from the root key, with the subkeys generated using Fernet's key derivation algorithm to ensure strong binding to the root key. Fernet's advantage lies in "encapsulating complexity while preserving security"—it shields developers from the underlying details of cryptography, allowing them to implement industry-standard secure encryption without needing to be encryption experts, while also balancing performance and ease of use.
[0112] It should be noted that in this application, the order of fragmented encryption and static encryption can be set based on the needs of the scenario, and this application does not impose any restrictions on this.
[0113] In one possible implementation, the model parameter fragmentation encryption key verification logic includes:
[0114] Before forward propagation of the model, verify whether the features of the model input are consistent with the features of the input sample of the torch.jit.trace function. If they are consistent, decrypt the fragmented encrypted model parameters and use them in the calculation.
[0115] As stated in the foregoing embodiments, in this application, a fragmented encryption key can be generated based on the hash value of the input sample of the torch.jit.trace function, and this key can be used to perform fragmented encryption on the model parameters. Therefore, in this application, verifying whether the features of the model input are consistent with the features of the input sample of the torch.jit.trace function before model forward propagation can specifically involve verifying whether the hash value of the model input is consistent with the hash value of the input sample of the torch.jit.trace function before model forward propagation.
[0116] In one possible implementation, the static encryption key verification logic for the model parameters includes:
[0117] Verify whether the operating environment is legitimate. If the operating environment is legitimate, decrypt the core parameters of the statically encrypted model and use them in the calculation.
[0118] In this application, after the model parameter fragment encryption key verification logic is executed and passes verification, it is also necessary to verify whether the running environment is legitimate. Only when the running environment is legitimate can the statically encrypted model core parameters be decrypted and used in calculations to ensure the security of the model core parameters.
[0119] In one possible implementation, refer to Figure 2 , Figure 2 This application provides a schematic diagram of the runtime dynamic token generation and verification logic execution flow, as shown in the embodiment of the present application. Figure 2 As shown, the runtime dynamic token generation and verification logic execution flow may include the following steps:
[0120] S201: After the forward propagation of each layer of the model is completed, extract the feature values of the output tensor of the current layer;
[0121] In this application, the feature value of the output tensor of the current layer can be the hash value of the tensor.
[0122] S202: Generate the current layer token using the second subkey in the preset key system and the feature value of the current layer output tensor;
[0123] In this application, the current layer token can be generated based on the Fernet encryption algorithm using the second subkey in the preset key system and the feature value of the current layer output tensor. Assuming the current layer token is represented as T, the second subkey is represented as (K-auth), and the feature value of the current layer output tensor is represented as H. The current layer token can then be generated based on the following formula: T = Fernet(K_auth).encrypt(H).
[0124] S203: Embed the current layer token into the computation flow of the next layer. Before the next layer is executed, the current layer token is decrypted and the feature value of the current layer output tensor is verified to match the current input feature. If the verification fails, the model self-destruct logic is triggered.
[0125] In this application, embedding the current layer token into the computational flow of the next layer refers to using the current layer token as an additional dimension of the input tensor. In this application, validation failure indicates that the feature value of the current layer output tensor does not match the current input feature, or that the current layer token has expired. Model self-destruct logic refers to clearing the parameters in memory and terminating model execution.
[0126] S204: For dynamically calculated branches, generate an independent token for each branch to ensure the integrity verification of the branch execution path.
[0127] In this application, dynamic calculation branches can be like if-else branches.
[0128] In one possible implementation, refer to Figure 3 , Figure 3 A flowchart illustrating another model incremental training security protection method provided in this application embodiment is shown below. Figure 3 As shown in the embodiments of this application, a model incremental training security protection method may include the following steps, which are described in detail below.
[0129] S301: After incrementally training the pre-trained model, obtain the original model file after the incremental training is completed. The original model file includes model training code, model structure and model parameters.
[0130] S302: Encrypt the model parameters to obtain encrypted model parameters;
[0131] S303: Based on the original model file, the torch.jit.trace function is used to solidify the model to obtain an intermediate model representation; the intermediate model representation embeds an active protection mechanism, which includes integrating model parameter fragmentation encryption key verification logic, model parameter static encryption key verification logic, and runtime dynamic token generation and verification logic in the model computation flow;
[0132] S304: Perform dynamic obfuscation processing on the intermediate representation of the model to obtain the intermediate representation of the model after dynamic obfuscation processing;
[0133] It should be noted that the specific implementation methods of the aforementioned steps can be found in the relevant embodiments mentioned above, and will not be repeated here.
[0134] S305: Use a third-party tool to encapsulate the model training code to obtain the encapsulated model training code;
[0135] Currently, most model training code is written in Python. The main tools for encapsulating and protecting Python code are PyInstaller and Cython.
[0136] PyInstaller is a tool that packages Python applications and their dependencies into standalone executable files, supporting multiple platforms including Windows, Linux, and macOS. Its core function is to bundle Python code, dependent libraries, and the Python interpreter together to generate an executable file that can run without requiring a Python environment to be installed.
[0137] Cython is a Python extension language that allows C language features to be embedded in Python code. Its primary purpose is to compile Python code into C extension modules (.so or .pyd files), thereby improving code execution speed and protecting source code.
[0138] Due to Cython's strong source code protection capabilities, significantly improved code execution speed, and ease of integration, it can be chosen as the method for encapsulating model training code in this application.
[0139] S306: Build a lightweight image file;
[0140] Docker itself is a containerization technology (operating system-level virtualization), which enables access to GPU / NPU resources through direct mapping between containers and the host machine's GPU / NPU. By packaging the Python runtime environment, dependent third-party libraries, etc., into an image, and then creating a container, the program runs in its own container. If the environment is modified, a new image can be submitted. Together, these two constitute the core workflow of Docker container technology.
[0141] In this application, a lightweight Dockerfile can be built that contains only the necessary dependencies (such as CUDA toolkit version locking).
[0142] S307: The encapsulated model training code, the encrypted model parameters, the dynamically obfuscated intermediate model representation, and the lightweight image file are determined as the model version to be deployed.
[0143] In this application, the model version to be deployed includes the encapsulated model training code, the encrypted model parameters, the model intermediate representation after dynamic obfuscation, and the lightweight image file. The model version to be deployed can be directly used for model deployment.
[0144] In this solution, during the deployment of the model version to be deployed, proactive protection mechanisms are embedded in the intermediate model representation, including model parameter sharding encryption key verification logic integrated in the model computation flow, model parameter static encryption key verification logic, and runtime dynamic token generation and verification logic. In addition, dynamic obfuscation processing is performed, the model training code is encapsulated, and the image file is lightweight. These multi-dimensional security protections achieve enterprise-level security protection without modifying the underlying model through a triple insurance mechanism of "code hardening + data encryption + sandbox isolation". It is especially suitable for the standardized deployment needs of AI as a service platforms. It realizes the construction of traceable and verifiable security boundaries while ensuring model performance. Therefore, it can prevent the training code, training parameters, and trained model structure and parameters from being spied on.
[0145] In another embodiment of this application, during the incremental training of the pre-trained model, the key used to encrypt the newly generated parameter gradient is periodically rotated based on the data batch and the model parameter iteration round, so as to further improve the security protection effect of the incremental training model.
[0146] In this application, the lifecycle of the key used to encrypt the newly generated parameter gradients is strongly correlated with the data batches and parameter iterations of incremental training, thus achieving adaptability of the key rotation training scenario. In one possible implementation, an example of a periodic key rotation strategy is as follows:
[0147] Data is dynamically generated in batches. For example, after every 10 batches of incremental data training, the keys are automatically rotated. This means that the next set of 10 batches will generate keys for different batches. The generation of data encryption keys depends on the characteristic hash value of the batch of data and is combined with the chip hardware information of the training nodes to ensure that the encryption keys for the same batch of data are unique and cannot be reused across different training nodes.
[0148] It is tied to the iteration cycle of model parameters, and a rotation is triggered after every 50 rounds of parameter updates.
[0149] It should be noted that during the rotation process, a smooth switch is achieved through a "dual-key transition mechanism": the new parameter encryption key encrypts the newly generated parameter gradient, and the old parameter encryption key is retained until the historical parameter archiving is completed, thus avoiding parameter fusion failure caused by key rotation.
[0150] The above describes a model incremental training security protection method provided by the embodiments of this application. The following will describe the apparatus for implementing the above model incremental training security protection method.
[0151] Please see Figure 4 , Figure 4 This is a schematic diagram of a model incremental training security protection device provided in an embodiment of this application. Figure 4 As shown, the incremental training security protection device for this model includes:
[0152] The acquisition unit 11 is used to acquire the original model file after incremental training of the pre-trained model. The original model file includes model training code, model structure and model parameters.
[0153] The model parameter encryption unit 12 is used to encrypt the model parameters to obtain encrypted model parameters;
[0154] The model solidification unit 13 is used to solidify the model based on the original model file to obtain an intermediate model representation; the intermediate model representation embeds an active protection mechanism, which includes fusion of model parameter fragmentation encryption key verification logic, model parameter static encryption key verification logic, and runtime dynamic token generation and verification logic in the model computation flow.
[0155] The dynamic obfuscation processing unit 14 is used to perform dynamic obfuscation processing on the intermediate representation of the model to obtain the intermediate representation of the model after dynamic obfuscation processing.
[0156] The model version determination unit 15 is used to determine the model version to be deployed based on the encrypted model parameters and the intermediate representation of the model after dynamic obfuscation.
[0157] In one possible implementation, the model solidification unit is specifically used for:
[0158] Based on the original model file, the torch.jit.trace function is used to solidify the model and obtain an intermediate representation of the model.
[0159] In one possible implementation, the model parameter encryption unit is specifically used for:
[0160] Based on the features of the input sample of the torch.jit.trace function, a fragmented encryption key is generated, and the fragmented encryption key is used to encrypt the model parameters in fragments to obtain the fragmented encrypted model parameters;
[0161] Obtain the first sub-key from the preset key system and perform static encryption on the core parameters in the model parameters to obtain the statically encrypted model core parameters.
[0162] In one possible implementation, the model parameter fragmentation encryption key verification logic includes:
[0163] Before forward propagation of the model, verify whether the features of the model input are consistent with the features of the input sample of the torch.jit.trace function. If they are consistent, decrypt the fragmented encrypted model parameters and use them in the calculation.
[0164] In one possible implementation, the static encryption key verification logic for the model parameters includes:
[0165] Verify whether the operating environment is legitimate. If the operating environment is legitimate, decrypt the core parameters of the statically encrypted model and use them in the calculation.
[0166] In one possible implementation, the runtime dynamic token generation and verification logic includes:
[0167] After the forward propagation of each layer of the model is completed, the feature values of the output tensor of the current layer are extracted;
[0168] The current layer token is generated using the second subkey in the preset key system and the feature value of the current layer output tensor.
[0169] The current layer token is embedded into the computation flow of the next layer. Before the next layer is executed, the current layer token is decrypted and the feature value of the current layer output tensor is verified to match the current input feature. If the verification fails, the model self-destruct logic is triggered.
[0170] For dynamically calculated branches, an independent token is generated for each branch to ensure the integrity verification of the branch execution path.
[0171] In one possible implementation, the device further includes:
[0172] The code encapsulation unit is used to encapsulate the model training code using third-party tools to obtain the encapsulated model training code.
[0173] The image processing unit is used to build lightweight image files;
[0174] The unit for determining the version of the model to be deployed is specifically used for:
[0175] The encapsulated model training code, the encrypted model parameters, the dynamically obfuscated intermediate model representation, and the lightweight image file are identified as the model version to be deployed.
[0176] In one possible implementation, the device further includes:
[0177] The key rotation unit is used to periodically rotate the key used to encrypt the newly generated parameter gradients based on data batches and model parameter iteration rounds during incremental training of the pre-trained model.
[0178] Each unit in the above-mentioned incremental training security protection device can be implemented entirely or partially through software, hardware, or a combination thereof. These units can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each unit.
[0179] This application also provides an electronic device in its embodiments. (See reference...) Figure 5 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 5 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.
[0180] like Figure 5 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. When the electronic device is powered on, the RAM 603 also stores various programs and data required for the operation of the electronic device. The processing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.
[0181] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, memory cards, hard drives, etc.; and communication devices 609. Communication device 609 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead.
[0182] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the model incremental training security protection methods provided in this application.
[0183] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the model incremental training security protection methods provided in this application.
[0184] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.
[0185] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0186] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.
[0187] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).
Claims
1. A method for ensuring security during incremental model training, characterized in that, include: After incrementally training the pre-trained model, obtain the original model file after the incremental training is completed. The original model file includes the model training code, model structure and model parameters. The model parameters are encrypted to obtain encrypted model parameters; Based on the original model file, the model is solidified to obtain an intermediate model representation. An active protection mechanism is embedded in the intermediate model representation. The active protection mechanism includes model parameter fragmentation encryption key verification logic, model parameter static encryption key verification logic, and runtime dynamic token generation and verification logic, which are integrated into the model computation flow. The intermediate representation of the model is dynamically obfuscated to obtain the dynamically obfuscated intermediate representation of the model. The version of the model to be deployed is determined based on the encrypted model parameters and the intermediate representation of the model after dynamic obfuscation.
2. The method according to claim 1, characterized in that, The process of solidifying the model based on the original model file to obtain an intermediate representation of the model includes: Based on the original model file, the torch.jit.trace function is used to solidify the model and obtain an intermediate representation of the model.
3. The method according to claim 1, characterized in that, The step of encrypting the model parameters to obtain encrypted model parameters includes: Based on the features of the input sample of the torch.jit.trace function, a fragmented encryption key is generated, and the fragmented encryption key is used to encrypt the model parameters in fragments to obtain the fragmented encrypted model parameters; Obtain the first sub-key from the preset key system and perform static encryption on the core parameters in the model parameters to obtain the statically encrypted model core parameters.
4. The method according to claim 3, characterized in that, The model parameter fragmented encryption key verification logic includes: Before forward propagation of the model, verify whether the features of the model input are consistent with the features of the input sample of the torch.jit.trace function. If they are consistent, decrypt the fragmented encrypted model parameters and use them in the calculation.
5. The method according to claim 3, characterized in that, The static encryption key verification logic for the model parameters includes: Verify whether the operating environment is legitimate. If the operating environment is legitimate, decrypt the core parameters of the statically encrypted model and use them in the calculation.
6. The method according to claim 1, characterized in that, The runtime dynamic token generation and verification logic includes: After the forward propagation of each layer of the model is completed, the feature values of the output tensor of the current layer are extracted; The current layer token is generated using the second subkey in the preset key system and the feature value of the current layer output tensor. The current layer token is embedded into the computation flow of the next layer. Before the next layer is executed, the current layer token is decrypted and the feature value of the current layer output tensor is verified to match the current input feature. If the verification fails, the model self-destruct logic is triggered. For dynamically calculated branches, an independent token is generated for each branch to ensure the integrity verification of the branch execution path.
7. The method according to claim 1, characterized in that, The method further includes: The model training code is encapsulated using a third-party tool to obtain the encapsulated model training code; Build a lightweight image file; The process of determining the model version to be deployed based on the encrypted model parameters and the intermediate model representation after dynamic obfuscation includes: The encapsulated model training code, the encrypted model parameters, the dynamically obfuscated intermediate model representation, and the lightweight image file are identified as the model version to be deployed.
8. The method according to claim 1, characterized in that, The method further includes: During incremental training of the pre-trained model, the key used to encrypt the gradient of the newly generated parameters is rotated periodically based on the data batch and the iteration round of the model parameters.
9. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the model incremental training security protection method as described in any one of claims 1 to 8.
10. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the model incremental training security protection method as described in any one of claims 1 to 8.
11. A computer-readable storage medium, characterized in that, The storage medium carries one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the model incremental training security protection method as described in any one of claims 1 to 8.