A webassembly model protection system for browser security inference
By encapsulating the browser-side AI model into a WebAssembly sandbox and performing multi-level obfuscation, the problem of easy theft of browser-side models is solved, and secure inference and stable deployment of the model in the browser environment are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NANJING UNIV OF AERONAUTICS & ASTRONAUTICS
- Filing Date
- 2026-02-02
- Publication Date
- 2026-06-19
AI Technical Summary
AI models running on the browser are vulnerable to theft due to the untrusted environment, and their structure and parameters are easily stolen. Existing encryption methods are difficult to effectively protect against this in the browser environment, resulting in a high risk of theft and abuse, which affects secure applications.
The model structure, weights, and computation logic are encapsulated in the WebAssembly sandbox. The model parsing and storage module extracts and converts them into a standardized representation, compiles them into a WebAssembly model file, and introduces a security enhancement module for multi-level obfuscation processing to generate an independent front-end calling interface.
It improves the security of the model in the browser environment, reduces the model's exposure surface, enhances its resistance to static analysis and dynamic reverse engineering attacks, reduces the risk of misuse and malicious calls, and improves the controllability and stability of the model in the front-end environment.
Smart Images
Figure CN122241686A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of browser security, artificial intelligence model security, and binary obfuscation, and particularly to a WebAssembly model protection system for browser security reasoning. Background Technology
[0002] The rapid integration of artificial intelligence into web applications has profoundly changed the way users interact with online services. Leveraging front-end inference frameworks such as TensorFlow.js, ONNX Runtime Web, and Brain.js, as well as browser execution and acceleration technologies like WebAssembly and WebGL, neural network models can perform inference calculations directly within the browser environment. This model breaks the traditional limitation of running models only on the server side, enabling web applications to provide intelligent capabilities locally on the client side, becoming a crucial development direction for front-end intelligence.
[0003] Running AI models on the browser side offers significant engineering advantages. Firstly, the inference process is completed locally, significantly reducing network communication latency and improving real-time interaction. Secondly, distributing the computational load across terminal devices alleviates server-side computing pressure and enhances system scalability in large-scale concurrent scenarios. Furthermore, some data can be processed without uploading to the server, reducing data transmission and thus considered to possess certain privacy-friendly characteristics. These advantages have driven the rapid deployment and application of front-end inference models in real-world web scenarios.
[0004] However, along with these advantages lie inherent security vulnerabilities in the browser-side model execution method. Because the model needs to be fully distributed and executed on the client side, its runtime environment is inherently untrusted, and the model structure and parameters are inevitably exposed to the end user. This security risk is not caused by improper implementation, but rather is determined by the fundamental mode of front-end model execution, and is difficult to eliminate through simple configuration or localized optimization under the current technological framework.
[0005] From an operational perspective, front-end inference is typically handled by the JavaScript layer, which is responsible for model loading, parsing, and scheduling. The model structure file and weight parameters are downloaded from the server to the browser as static resources. After parsing on the client side, the inference computation is handled by a WASM, WebGL, or JavaScript backend. To improve performance, the browser caches the model file in local storage media such as memory, disk cache, cache storage, or IndexedDB. The model generally exists in plaintext during loading and execution, allowing JavaScript direct access to its content and execution flow.
[0006] This very mechanism makes front-end models extremely vulnerable to theft. Attackers don't need to compromise the server or exploit system vulnerabilities; they can obtain the model's structure files and weight parameters simply through browser developer tools, network interception techniques, or malicious extensions. Browser caching mechanisms leave a persistent copy of the model locally, allowing attackers to bypass the transport layer and directly extract the complete model from local storage even if HTTPS is used for model transmission. Because the model is completely exposed, the cost of theft is extremely low, and the attack is difficult to detect or prevent.
[0007] Furthermore, front-end inference frameworks heavily rely on JavaScript as the control layer, making the model execution logic completely transparent to the user. JavaScript code is easy to decompile and debug; the model's input / output interfaces, operator call order, and inference flow can all be analyzed and reproduced. Even if WebAssembly is used for computation at the underlying level, model parameters are still directly exposed in the browser cache and need to be loaded and passed into WASM linear memory through the JavaScript layer. WASM's sandbox feature cannot form an effective security boundary. Existing model encryption, differential privacy, or homomorphic encryption methods suffer from problems such as invalidation after client-side decryption, excessive computational overhead, and difficulty in practical deployment in browser environments. Therefore, under the current front-end model operation system, the risk of model theft and misuse cannot be fundamentally resolved, becoming a core issue restricting its secure application. Summary of the Invention
[0008] Purpose of the invention: The technical problem to be solved by the present invention is to address the shortcomings of the existing technology. The present invention encapsulates the structure, weights and calculation logic of the model into a WebAssembly sandbox for execution, and combines it with security enhancement measures for the characteristics of the model. Without relying on external inference frameworks and operator libraries, the present invention enables the secure inference execution of the model in the front-end environment, thereby effectively improving the model's resistance to static analysis and dynamic reverse attacks.
[0009] The basic principle of this invention is as follows: A model parsing and storage module uniformly parses model files exported from different training frameworks, extracting model structure and weight parameter information, and converting them into a standardized intermediate representation. Subsequently, a model conversion and compilation module reconstructs the model computation logic in native language form, compiling it along with the operator implementations and runtime environment required for model operation into a WebAssembly model file, thus eliminating the dependence of the model inference process on external frameworks and operator libraries. Building upon this, to address the issue that WebAssembly models may still be susceptible to static analysis at the binary level, this invention introduces a security enhancement module. This module performs multi-level obfuscation and perturbation processing on model weight data, operator implementation logic, and model computation graph structure, increasing the difficulty of reverse engineering the model without affecting the inference results. Finally, a standardized calling method is provided through a front-end call interface generation module, enabling front-end applications to complete model inference without accessing the internal details of the model.
[0010] Specifically, this invention provides a WebAssembly model protection system for browser security inference, including a model parsing and storage module, a model conversion and compilation module, a security enhancement module, and a front-end call interface generation module;
[0011] The model parsing and storage module is used to read and parse the input model file, automatically identify the training framework type to which the model belongs, extract the network structure information and model weight parameter information of the model, and convert the model structure information and model weight parameter information into a unified intermediate representation.
[0012] The model conversion and compilation module generates local model code containing a complete model computation graph based on the intermediate representation, and compiles the local model code and the runtime environment required for model operation together to generate a WebAssembly model file, so that the WebAssembly model file does not need to depend on external model files or operator libraries when running on the front end.
[0013] The security enhancement module is used to encrypt, obfuscate, or perturb the model weight data, operator implementation logic, and model computation graph structure in the WebAssembly model file, so as to reduce the risk of the model being statically analyzed or reverse-engineered in the front-end runtime environment.
[0014] The front-end call interface generation module is used to generate a call interface file corresponding to the WebAssembly model file, so that the front-end application can directly call the WebAssembly model file through the script interface to complete model inference.
[0015] The system, through the collaborative work of the model parsing and storage module, model conversion and compilation module, security enhancement module, and front-end call interface generation module, converts model files from different machine learning training frameworks into WebAssembly model files that can run independently on the browser. During the conversion process, the system integrates, encapsulates, and enhances the security of model structure information, model weight information, and model calculation logic, thereby achieving comprehensive security protection for the front-end model.
[0016] During the model parsing process, the model parsing and storage module calls the corresponding parsing logic for model files exported from different training frameworks to parse the model configuration, hierarchical connection relationship and corresponding model weight parameters contained in the model file, so that the model structure information and model weight parameter information are completely extracted from the original model file. The corresponding parsing logic refers to the parsing rules and processing flow predefined for the model file format of different training frameworks, which is used to convert the different model description methods in each training framework into a unified structured data representation.
[0017] After parsing is completed, the model parsing and storage module organizes and stores the model structure information and model weight parameter information in a standardized data format, so that models from different training frameworks have a consistent data input format in the subsequent model conversion and compilation process.
[0018] During the model conversion process, the model conversion and compilation module implements the neural network operators involved in the model in the form of local language functions according to the model structure information, and calls the corresponding operators in sequence according to the model network layer order and passes in the model weight parameters, thereby constructing a complete model calculation process in the local model code; the neural network operator refers to the basic operation unit that constitutes the model calculation process.
[0019] When generating local model code, the model conversion and compilation module integrates the operator implementation logic required during model operation into the local model code, so that the model does not need to load operator implementation or model file from the outside when performing inference tasks. The operator implementation logic is a description of the specific calculation process, parameter processing method and execution order of the basic operation unit at the local code level.
[0020] After the local model code is generated, the model conversion and compilation module compiles the local model code into a WebAssembly format model file through a compilation toolchain. During the compilation process, the runtime environment required for the model to run is also encapsulated into the WebAssembly model file, so that the generated WebAssembly model file can run independently in the front-end environment.
[0021] Regarding model weight protection, the security enhancement module encrypts and stores the model weight data in the WebAssembly model file, ensuring that the model weight parameters exist in a non-plaintext form within the WebAssembly model file. During model execution, the model weight parameters are recovered through corresponding decryption logic for calculation. Simultaneously, false weight data and pseudo-decryption paths are introduced into the model weight data or decryption process. The false weight data refers to interfering weight information introduced without affecting the actual inference results of the model, and the pseudo-decryption path refers to a non-real decryption execution path set in parallel or overlapping with the real weight decryption process, used to mislead static or dynamic analysis.
[0022] In the operator-level security enhancement process, the security enhancement module perturbs the execution paths and internal decision-making processes of key operator functions in the model, and obfuscates the intermediate calculation results within the operators. This includes: achieving control flow obfuscation through execution path perturbation, dividing basic blocks according to control instructions and recording stack changes, assigning a unique state ID to each basic block, then randomly shuffling the order of the basic blocks, introducing a state machine scheduling mechanism, and dynamically allocating execution paths based on the state through br_table (a control flow instruction in WebAssembly, whose Chinese meaning is usually translated as "branch table" or "jump table"). Its innovation lies in combining state-driven execution with basic block rearrangement, significantly disrupting the original control flow structure while maintaining semantic correctness, thus increasing the difficulty of reverse analysis.
[0023] In the security enhancement process at the model computation graph level, the security enhancement module obfuscates the calling relationships and scheduling order between operators, thereby breaking down the correspondence between the function call paths in the WebAssembly model file and the original computation graph structure.
[0024] When generating the front-end call interface file, the front-end call interface generation module constructs a corresponding interface description based on the input and output information of the WebAssembly model file, so that the front-end application can complete model initialization, input data transmission and inference result acquisition according to the interface description.
[0025] The interface description defines the model's calling process in a standardized form, providing a clear calling method for front-end applications, so that the model's loading and inference processes can be executed according to predetermined steps;
[0026] The front-end application only needs to load the corresponding WebAssembly model file according to the interface description to complete the model calculation when performing model inference by generating the interface file through the front-end interface generation module.
[0027] The API call file can be used in conjunction with the security-enhanced WebAssembly model file, enabling the front-end application to complete the model inference process while following the call method, thereby supporting the direct deployment and use of the model in the front-end environment.
[0028] The present invention also provides an electronic device, including a processor and a memory, the memory storing program code that, when executed by the processor, causes the processor to run the system.
[0029] The present invention also provides a storage medium storing a computer program or instructions that execute the system when the computer program or instructions are run on a computer.
[0030] Beneficial Effects: This invention offers significant advantages in terms of model front-end deployment and operational security. Firstly, encapsulating the model as a WebAssembly instance that can run independently in a browser environment reduces the model's reliance on external files and components, lowers its exposure surface, and enhances overall deployment security. Secondly, protecting model weights, operator logic, and computational structure prevents direct access to key parameters and core computational logic, strengthening the model's resistance to static analysis and dynamic reverse engineering attacks. Furthermore, providing inference capabilities through a unified interface isolates the front-end application from the model's internal implementation details, reducing the risk of misuse and malicious calls, and improving the model's controllability and stability in the front-end environment. In summary, this invention effectively improves the security of front-end model operation while ensuring the correctness of model inference functionality, making it suitable for browser application scenarios with high model security requirements. Attached Figure Description
[0031] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention in the above and / or other aspects will become clearer.
[0032] Figure 1 A general overview of the WebAssembly model protection framework for browser-oriented security reasoning.
[0033] Figure 2 It is an operator library diagram of the model conversion and compilation module.
[0034] Figure 3 This is a diagram showing the obfuscation effect of the security enhancement module on the model calculation graph.
[0035] Figure 4 This is the algorithm diagram for operator execution path perturbation. Detailed Implementation
[0036] This invention provides a WebAssembly model protection system for browser-based security inference, such as... Figure 1 As shown, the overall system framework of the present invention consists of four modules working together: a model parsing and storage module, a model conversion and compilation module, a security enhancement module, and a front-end call interface generation module. Among them, the model conversion and compilation module and the security enhancement module are the core functional modules of the system.
[0037] (1) Model parsing and storage module
[0038] The model parsing and storage module is used to uniformly read, parse, and store model files exported from different training frameworks. It is a fundamental component for the entire system to complete model conversion and secure deployment. This module supports model files exported from various mainstream training frameworks, including TensorFlow, PyTorch, and ONNX formats, and can automatically identify the training framework type based on the characteristics of the model file.
[0039] During the model parsing phase, the model parsing and storage module automatically identifies the training framework type of the model based on the format characteristics of the input model file and selects the corresponding parsing logic to process the model file. During parsing, the system traverses each layer of the model, extracting the network layer type, input / output shapes, and connections between layers, while simultaneously reading the model weights and bias parameters corresponding to each network layer. To facilitate subsequent use in environments without deep learning framework support, the model weight parameters are uniformly converted to basic numerical types and organized and stored in list format.
[0040] After extracting the model structure and weights, the model parsing and storage module organizes all the parsed layer information into a standardized intermediate representation. This intermediate representation not only fully describes the model's computational structure but also explicitly records the weight parameters and configuration attributes required for each layer. This ensures that the model's structural and parameter information remain logically related while facilitating independent access and processing at the data level. In this way, models derived from different training frameworks all have a consistent data representation when entering subsequent processes.
[0041] To adapt to the subsequent local model building process, the model parsing and storage module further embeds the intermediate representation into the C++ header file template, storing the model configuration and weight information as constant data. This allows the model to directly access the corresponding structure and parameter information in the C++ environment without relying on the original training framework or its runtime library. Through this module's processing, the model file completes the transformation from a "framework-dependent format" to an "independent and usable description format," providing a stable and unified input foundation for the model conversion and compilation module.
[0042] (2) Model conversion and compilation module
[0043] The model conversion and compilation module converts the intermediate representation generated by the model parsing and storage module into a WebAssembly model file containing complete inference logic. It is one of the core modules for implementing secure front-end inference in the system. This module aims to reconstruct the semantic equivalence of the model's forward computation flow. Without relying on external deep learning frameworks and operator libraries, it transforms the model structure, computational logic, and weight parameters into a local model form that can be executed independently in the WebAssembly runtime environment.
[0044] During the model conversion phase, the model conversion and compilation module constructs the overall computational graph of the model based on the model structure information described in the intermediate representation. The system represents the model as a computational network composed of multiple layers of neural networks, organized according to the hierarchical relationships defined in the original model. The neural network operators involved in the model are encapsulated as C++ functions, implementing the operators required by common models such as convolutional neural networks, recurrent neural networks, long short-term memory networks, and Transformers as native computational logic. To achieve a unified representation of the model structure, the system adopts an object-oriented approach to abstract the network layers, managing different types of network layers through a unified base class, thereby supporting the combination and conversion of various network structures.
[0045] In the actual calculation process, the model conversion and compilation module completes the forward computation of each network layer by calling a pre-built operator library. To address the security and compatibility requirements of the WebAssembly runtime environment, this invention constructs a WASM-friendly C++ operator library, avoiding dependence on external operator libraries during model inference. The operator library encapsulates various neural network operators in function form, clearly defining the input and output interfaces of the operators. Model weights, biases, and other parameters are passed as function inputs, and the specific mathematical operation logic is completed internally by the operator functions, achieving modular reuse of operators.
[0046] The operator library covers the types of operators required by various common models, such as Figure 2 As shown, this includes activation function operators, recurrent neural network (RNN) related operators, convolution related operators, and attention mechanism related operators. Activation function operators are used to perform nonlinear transformations on the input data; RNN related operators are used to implement state updates in time series models; attention operators are used to perform weighted calculations on the input sequence and generate context representations. The model conversion and compilation module traverses each network layer according to the hierarchical order defined in the model structure information, and calls the corresponding operator functions based on the network layer type. The operator functions receive the output data from the previous layer and the weight parameters required by the current layer, complete the calculation, and pass the result to the next layer, thereby constructing a complete model forward computation process in the local environment.
[0047] After constructing the model computation logic, the model conversion and compilation module takes the C++ source files and header files containing operator implementations, computation graph construction logic, and model weight data as input, and calls the Emscripten compilation toolchain for compilation to generate a WebAssembly model file containing the complete inference process. The generated WASM model file does not require external deep learning frameworks or operator libraries during front-end runtime; the model inference process is executed entirely within the WebAssembly sandbox environment, providing a unified and stable model foundation for subsequent security enhancements and front-end deployment.
[0048] (3) Security Enhancement Module
[0049] This invention introduces a security enhancement module after model conversion to perform multi-layered security hardening on the WebAssembly model file, thereby improving the model's resistance to reverse engineering in the front-end runtime environment, such as... Figure 3 As shown.
[0050] Regarding model weight protection, this invention addresses the issue that weights in WebAssembly models are typically stored centrally in the data segment and easily extracted. It introduces a protection mechanism combining weight encryption and obfuscation. During model generation, the system encrypts the weight data and re-embeds the encrypted weights in floating-point form into the model file, making them difficult to directly identify at the binary level. At runtime, an on-demand decryption strategy is employed, dynamically restoring the required weights only during inference execution, preventing weights from existing in plaintext form in memory for extended periods.
[0051] Building upon this, the security enhancement module further introduces a fake decryption obfuscation mechanism. By constructing forged decryption logic during the module loading process, it creates the illusion that the weights have been decrypted during the initialization phase, thereby misleading attackers in their judgment of the real decryption path. To further enhance the interference effect, the system also injects a large amount of forged parameter data with a structure similar to the real weights into the data segment and stores them in different offset positions, making it difficult for attackers to distinguish between real parameters and fake data during analysis, thus significantly increasing the difficulty of restoring the model weights.
[0052] At the operator level, this invention protects the computational logic within the model through operator obfuscation. The security enhancement module perturbs the execution structure within operator functions, reconstructing the execution path and internal decision-making logic while maintaining the semantics of operator computation. By flattening and rearranging the execution path of operator functions, the originally clear control flow relationship is encapsulated into a unified scheduling structure, obscuring the actual execution order with jump logic driven by state variables, such as... Figure 4As shown. Simultaneously, the system perturbs the conditional judgment structure within the operator, disrupting the execution sequence by adjusting the conditional logic and path order. Furthermore, the security enhancement module introduces intermediate computation obfuscation within the operator, interfering with static analysis tools' inferences about data dependencies and intermediate results by inserting redundant operations, identity transformations, and computational paths without side effects, thereby reducing the likelihood of the operator logic being accurately reconstructed.
[0053] At the overall model structure level, this invention further obfuscates the model's computation graph. The security enhancement module introduces a fake operator filling mechanism, inserting several operator functions that do not participate in the actual inference process into the WebAssembly module and constructing forged function call relationships. This makes it difficult for attackers to distinguish between the real computation path and the interference path when analyzing function dependencies and the call network. Simultaneously, the system reconstructs some operator call methods, replacing the original explicit static calls with an index-based dynamic scheduling method. This ensures that the call relationships between operators are determined only at runtime, thereby increasing the difficulty of statically reconstructing the computation graph. Through these methods, the model's true computation graph structure is effectively masked, making it difficult for attackers to accurately reproduce the model's inference process through function call relationships.
[0054] In addition to the computational obfuscation mentioned above, this invention also leverages the characteristic that custom segments in the WebAssembly module do not participate in execution to introduce a metadata obfuscation mechanism. The security enhancement module inserts multiple forged custom segments into the model file, embedding fake compiler information, debugging information, and platform characteristic descriptions within them. This makes it difficult for attackers to determine the model's true origin, compilation environment, and construction method during static analysis. The forged metadata does not affect the normal loading and execution of the model, but it effectively interferes with the analysis tools' inference of the module's background information, thereby further enhancing the model's overall resistance to reverse engineering.
[0055] Through the synergistic effect of various security enhancement methods such as model weight obfuscation, operator obfuscation, computation graph obfuscation, and metadata obfuscation, this invention achieves multi-layered protection for WebAssembly model files, enabling the model to have higher security and anti-analysis capabilities in the front-end runtime environment, while not affecting the correctness and usability of the model's inference function.
[0056] (3) Front-end API call generation module
[0057] This invention further provides a front-end call interface generation module to support the direct deployment and use of models in actual front-end pages. This module not only generates script interface descriptions that match the WebAssembly model file, but also provides directly runnable front-end call examples tailored to specific use cases, enabling developers to complete model inference calls without needing to understand the internal implementation details of the model.
[0058] The front-end API generation module, based on the input and output definitions of the WebAssembly model file, organizes and encapsulates the model initialization process, input data format, and inference result return method. In the generated front-end API page, the system uses JavaScript to load and instantiate the WebAssembly module. After instance creation, the system writes the input data required for model inference into the WebAssembly linear memory according to a predefined data layout. This input data can come from user interaction components on the page or from preset data sources. The script ensures that the input data can be correctly read by the model's computation logic through memory address mapping and type conversion.
[0059] During the model inference execution phase, the front-end API calls the exported WebAssembly model file to trigger forward computation of the model, and reads the inference results from the specified memory area after computation is complete. To facilitate use by front-end applications, the call case uniformly encapsulates the model output, converting the raw computation results in WebAssembly memory into data structures that JavaScript can directly process, and then displays or further processes them on the page. The entire call process relies only on a single WebAssembly model file and the corresponding front-end script, without requiring the loading of external operator libraries or additional model resources.
[0060] By employing the above method, this invention completely encapsulates the model inference process within the front-end page, avoiding the security risks associated with model file transfer and back-end calls in traditional front-end and back-end collaborative inference processes. The provided front-end call examples are presented in web page format, clearly demonstrating the complete process of model loading, input settings, and result acquisition. This allows the model to complete inference tasks on the browser as an independent file, making it suitable for web application scenarios with high requirements for model security and ease of deployment.
[0061] This embodiment uses a convolutional neural network model for image classification in cat and dog recognition to illustrate the complete process of the model, from parsing, transformation, security enhancement to front-end invocation. This embodiment selects an image classification model trained on TensorFlow / Keras as the test object. This model is saved in .h5 format, and the original model is run on the browser using TensorFlow.js for binary classification inference of the input image. The model contains a total of 10 network layers, mainly including an input layer, three convolutional layers, two ReLU activation layers, two pooling layers, one flattening layer, and one fully connected output layer. Following the system flow of this invention, the model processing is executed sequentially according to each functional module, as detailed below.
[0062] Module 1: Model parsing and storage module;
[0063] First, the user clicks "Select Model" in the system interface to load the .h5 file of the image classification model, and selects Keras (HDF5 format) from the "Model Framework" dropdown. The model parsing and storage module automatically calls the corresponding parser based on the user's selection to read and parse the model file. The system traverses the model's network structure, extracting the type, input / output dimensions, and parameter configuration of each layer in sequence. For example, the first layer is Conv2D(32, 3×3), followed by a ReLU activation layer and a MaxPooling layer, performing three sets of convolution and pooling operations in sequence. Then, the feature map is flattened into a one-dimensional vector through a Flatten layer, and finally, the classification result is output through a fully connected layer.
[0064] During the parsing process, the model weight parameters are uniformly converted into floating-point array format and organized together with the network structure information into an intermediate representation. This intermediate representation describes the model's computation order, operator types, and weight data in a standardized structure, providing a unified input for subsequent model conversion. After parsing, the system generates an intermediate file containing model structure and weight information locally, realizing the conversion of the model from the original framework representation to a general representation.
[0065] Module 2: Model Conversion and Compilation Module;
[0066] During the model conversion phase, the model conversion and compilation module constructs the complete computational graph of the model based on the intermediate representation. The system, according to the network layer order, calls the corresponding operator functions from the local operator library to reconstruct the model's forward computation logic. For convolutional layers, the convolution operator is called, passing in the convolution kernel weights and stride parameters; for ReLU layers, the activation function operator is called to perform nonlinear transformations; for flattening layers, the flatten operator is called to map multidimensional features into one-dimensional vectors; and for fully connected layers, matrix multiplication and bias addition operators are called to complete the output calculation.
[0067] All the above operators are implemented as C++ functions. The computations of each layer of the model are chained together sequentially through these operator functions to form a complete computation graph. The system encapsulates the operator implementation code, computation graph construction logic, and model weight data into a unified file named `cat_dog.cpp` and its corresponding header file. Subsequently, the system automatically calls the Emscripten toolchain to execute the compilation instructions.
[0068] ,
[0069] After completion, a WebAssembly model file that can run in a browser is generated. The original TensorFlow.js model is approximately 7579KB in size, and the converted, unobfuscated WASM model file is approximately 10815KB in size. At this point, the model can run independently in the front end without relying on TensorFlow.js or external operator libraries.
[0070] Module 3: Security Enhancement Module;
[0071] To prevent the model from being statically analyzed or reverse engineered in the front-end environment, the system performs security enhancement processing on the generated WASM model file. Users can select the generated WASM file in the interface and check all obfuscation methods in the "Binary Obfuscation Options," including model weight encryption, fake decryption obfuscation, fake operator padding, operator execution path perturbation, operator scheduling index obfuscation, operator internal decision point obfuscation, operator intermediate computation obfuscation, and metadata obfuscation.
[0072] The security enhancement module encrypts and stores model weights, and introduces a fake decryption process and pseudo-weight data into the WASM module. It also perturbs the execution path and intermediate computation processes within operator functions; inserts fake operators at the computation graph level and introduces an index scheduling mechanism to obfuscate the real call relationships; finally, it obfuscates module metadata by adding fake custom segments. After these processes, the obfuscated WASM model file size is approximately 17596KB.
[0073] Module 4: Front-end API Call Generation Module;
[0074] During the front-end deployment phase, the system generates a corresponding front-end API for the obfuscated WASM model and provides a sample webpage for demonstration. The front-end page loads the obfuscated WASM file via JavaScript, completes module instantiation, writes the input image data into the WebAssembly linear memory, and calls the exported inference function to execute model calculations. After inference is complete, the front-end script reads the output results from the specified memory area and displays the classification results on the page.
[0075] Comparing browser behavior before and after the conversion reveals that when using TensorFlow.js, the model loading process requires transferring the .bin weight file and .json configuration file from the server, and these files can be directly viewed in the browser's network request list. However, after adopting the method of this invention, the browser only needs to load a single obfuscated WASM model file. The model weights and structural information are no longer exposed in the transfer list, enabling secure deployment and inference of the model in the front-end environment. Experimental tests show that the control flow complexity increased by approximately 60% before and after the conversion, significantly increasing model security. With only a 65% increase in model file size, the front-end model inference speed improved by approximately 58%, and the model conversion did not affect the model's inference accuracy.
[0076] This invention provides a WebAssembly model protection system for browser security inference. Many methods and approaches exist for implementing this technical solution; the above description is merely a preferred embodiment. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.
Claims
1. A WebAssembly model protection system for browser-based security inference, characterized in that, It includes a model parsing and storage module, a model conversion and compilation module, a security enhancement module, and a front-end call interface generation module; The model parsing and storage module is used to read and parse the input model file, automatically identify the training framework type to which the model belongs, extract the network structure information and model weight parameter information of the model, and convert the model structure information and model weight parameter information into a unified intermediate representation. The model conversion and compilation module generates local model code containing a complete model computation graph based on the intermediate representation, and compiles the local model code and the runtime environment required for model operation together to generate a WebAssembly model file, so that the WebAssembly model file does not need to depend on external model files or operator libraries when running on the front end. The security enhancement module is used to encrypt, obfuscate, or perturb the model weight data, operator implementation logic, and model computation graph structure in the WebAssembly model file, so as to reduce the risk of the model being statically analyzed or reverse-engineered in the front-end runtime environment. The front-end call interface generation module is used to generate a call interface file corresponding to the WebAssembly model file, so that the front-end application can directly call the WebAssembly model file through the script interface to complete model inference.
2. The system according to claim 1, characterized in that, The system, through the collaborative work of the model parsing and storage module, model conversion and compilation module, security enhancement module, and front-end call interface generation module, converts model files from different machine learning training frameworks into WebAssembly model files that can run independently on the browser. During the conversion process, the system integrates, encapsulates, and enhances the security of model structure information, model weight information, and model calculation logic, thereby achieving comprehensive security protection for the front-end model.
3. The system according to claim 2, characterized in that, During the model parsing process, the model parsing and storage module calls the corresponding parsing logic for model files exported from different training frameworks to parse the model configuration, hierarchical connection relationship and corresponding model weight parameters contained in the model file, so that the model structure information and model weight parameter information are completely extracted from the original model file. The corresponding parsing logic refers to the parsing rules and processing flow predefined for the model file format of different training frameworks, which is used to convert the different model description methods in each training framework into a unified structured data representation. After parsing is completed, the model parsing and storage module organizes and stores the model structure information and model weight parameter information in a standardized data format, so that models from different training frameworks have a consistent data input format in the subsequent model conversion and compilation process.
4. The system according to claim 3, characterized in that, During the model conversion process, the model conversion and compilation module implements the neural network operators involved in the model in the form of local language functions according to the model structure information, and calls the corresponding operators in sequence according to the model network layer order and passes in the model weight parameters, thereby constructing a complete model calculation process in the local model code; the neural network operator refers to the basic operation unit that constitutes the model calculation process.
5. The system according to claim 4, characterized in that, When generating local model code, the model conversion and compilation module integrates the operator implementation logic required during model operation into the local model code, so that the model does not need to load operator implementation or model file from the outside when performing inference tasks. The operator implementation logic is a description of the specific calculation process, parameter processing method and execution order of the basic operation unit at the local code level. After the local model code is generated, the model conversion and compilation module compiles the local model code into a WebAssembly format model file through a compilation toolchain. During the compilation process, the runtime environment required for the model to run is also encapsulated into the WebAssembly model file, so that the generated WebAssembly model file can run independently in the front-end environment.
6. The system according to claim 5, characterized in that, Regarding model weight protection, the security enhancement module encrypts and stores the model weight data in the WebAssembly model file, ensuring that the model weight parameters exist in a non-plaintext form within the WebAssembly model file. During model execution, the model weight parameters are recovered through corresponding decryption logic for calculation. Simultaneously, false weight data and pseudo-decryption paths are introduced into the model weight data or decryption process. The false weight data refers to interfering weight information introduced without affecting the actual inference results of the model, and the pseudo-decryption path refers to a non-real decryption execution path set in parallel or overlapping with the real weight decryption process, used to mislead static or dynamic analysis.
7. The system according to claim 6, characterized in that, In the security enhancement process at the operator level, the security enhancement module perturbs the execution path and internal decision-making process of key operator functions in the model, and obfuscates the intermediate calculation results inside the operator, including: achieving control flow obfuscation through execution path perturbation, dividing basic blocks according to control instructions and recording stack changes, assigning a unique state ID to each basic block, then randomly shuffling the order of the basic blocks, introducing a state machine scheduling mechanism, and dynamically assigning execution paths based on the state through br_table; In the security enhancement process at the model computation graph level, the security enhancement module obfuscates the calling relationships and scheduling order between operators, thereby breaking down the correspondence between the function call paths in the WebAssembly model file and the original computation graph structure.
8. The system according to claim 7, characterized in that, When generating the front-end call interface file, the front-end call interface generation module constructs a corresponding interface description based on the input and output information of the WebAssembly model file, so that the front-end application can complete model initialization, input data transmission and inference result acquisition according to the interface description. The interface description defines the model's calling process in a standardized form, providing a clear calling method for front-end applications, so that the model's loading and inference process can be executed according to predetermined steps; The front-end application only needs to load the corresponding WebAssembly model file according to the interface description to complete the model calculation when performing model inference by generating the interface file through the front-end interface generation module. The API call file can be used in conjunction with the security-enhanced WebAssembly model file, enabling the front-end application to complete the model inference process while following the call method, thereby supporting the direct deployment and use of the model in the front-end environment.
9. An electronic device, characterized in that, It includes a processor and a memory, the memory storing program code that, when executed by the processor, causes the processor to run the system as described in any one of claims 1 to 8.
10. A storage medium, characterized in that, The system contains computer programs or instructions that, when run on a computer, execute the system as described in any one of claims 1 to 8.