Digital asset protection method, device, equipment, medium and product

Abstract

The invention discloses a digital asset protection method and device, equipment, a medium and a product, and the method comprises the steps: obtaining authorization metadata corresponding to a target digital asset based on a mixed authorization mode which is an authorization mode combining a physical lock with soft authorization; the target resource in the authorization metadata is verified; and if the verification is passed, loading the target digital assets in a target loading mode. According to the invention, through the authorization mode of combining the physical lock and the soft authorization, the flexible adjustment of the authorization strategy is realized, the business change can be responded without replacing the hardware, and the flexibility of authorization management is greatly improved while the safety base line is ensured.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a method, apparatus, device, medium, and product for protecting digital assets. Background Technology

[0002] Currently, in the process of enterprise intelligent transformation driven by AI technology, suppliers face risks such as illegal copying, misuse, version theft, and leakage of core algorithms when it comes to key digital assets, such as AI engines and related knowledge bases and model weights.

[0003] Currently, encryption mechanisms are the primary means of protecting digital assets. For different types of digital assets, different encryption algorithms and independent keys are typically used for protection to balance security and loading efficiency.

[0004] However, the above methods lack flexibility. Summary of the Invention

[0005] The main objective of this application is to provide a digital asset protection method, apparatus, device, medium, and product that can improve the balance between the rigor and flexibility of authorization strategies for digital assets, avoid over- or under-authorization, and thus enhance the security of digital assets.

[0006] To achieve the above objectives, firstly, this application provides a method for protecting digital assets, comprising: Based on the hybrid authorization mode, the authorization metadata corresponding to the target digital asset is obtained. The hybrid authorization mode is an authorization mode that combines physical locks and soft authorization. Verify the target resource in the authorized metadata; If the verification passes, the target digital asset is loaded using the target loading method.

[0007] In one embodiment, the physical lock is an authorization server deployed on a physical server, and the soft authorization is an authorization client configured in the target digital asset; Based on the hybrid licensing model, license metadata is obtained, including: Obtain soft license metadata from the authorized client, and obtain resource license metadata from the target digital asset; The physical lock authorization metadata is obtained through an encrypted communication channel established between the authorized client and the authorized server. The physical lock authorization metadata is configured on the lock authorization server. Authorization metadata consists of soft authorization metadata, resource authorization metadata, and physical lock authorization metadata.

[0008] In one embodiment, validating the target resource in the authorized metadata includes: When the target digital resource is started, the authorization of the target resource in the authorization metadata is verified; When the target digital resource is running, the timeliness of the target resource in the authorized metadata is verified.

[0009] In one embodiment, performing authorization verification on the target resource in the authorization metadata includes: Calculate the resource identifier of the target digital asset and compare it with the resource identifier in the soft authorization metadata to determine the authorization legality of the target digital resource; The user identifier in the resource authorization metadata is compared with the user identifier in the physical lock authorization metadata to determine the legitimacy of the current user; Compare the resource version in the soft license metadata with the resource version in the resource license metadata to determine resource version consistency; Based on the scope of open functions in the soft license metadata, determine the target open functions corresponding to the target digital asset.

[0010] In one embodiment, loading a target digital asset via a target loading method includes: Obtain disguised digital assets, where the disguised digital assets are binary files; The disguised digital assets are analyzed using a pre-set decryption algorithm to locate the data block storing the target digital assets; Obtain the loading interface from the data block of the target digital asset; The target digital asset is retrieved from the loading interface according to the preset call sequence rules.

[0011] In one embodiment, obtaining disguised digital assets includes: The target digital asset is encrypted and compressed to obtain the compressed digital asset. The compressed digital assets are segmented to obtain the segmented digital assets. The segmented digital assets are embedded into a file of a preset format, and a fake file is added to obtain a fake digital asset. The fake file includes at least fake data and fake interfaces.

[0012] In one embodiment, loading a target digital asset via a target loading method includes: When the target digital asset is an AI model, the corresponding offsets are configured for the weight parameters of each layer of the AI ​​model to obtain the packaged AI model. The offsets configured for different layers of the AI ​​model are different. The AI ​​model is obtained by performing a reverse offset operation on the weight parameters of each layer of the packaged AI model according to the pre-stored offset lookup table. The pre-stored offset lookup table stores the mapping relationship between the weight parameters of each layer of the AI ​​model and the offset.

[0013] In one embodiment, loading a target digital asset via a target loading method includes: Construct a mapping table, which includes an input transformation mapping table and an output restoration mapping table; Based on the input deformation mapping table, the original data in the target digital asset is converted into the corresponding deformation data; Based on the output restoration mapping table, the deformed data is restored to the original data to obtain the target digital asset.

[0014] In one embodiment, the method further includes: Insert at least one set of tracking feature data with a preset output pattern into the target digital asset; Periodically send probe requests containing tracking feature data to the target service interface and obtain the corresponding output response; Judge the output response; If the output response contains features that match the tracking feature data, a resource leak alarm is generated, and the source of the leak is traced based on the authorization identifier associated with the tracking feature data.

[0015] Secondly, embodiments of this application provide a digital asset protection device, comprising: The data acquisition module is used to acquire the authorization metadata corresponding to the target digital asset based on the hybrid authorization mode, which is an authorization mode that combines physical locks and soft authorization. The verification module is used to verify the target resources in the authorization metadata; The loading module is used to load the target digital asset using the target loading method if the verification passes.

[0016] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the methods described above.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described above.

[0018] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the methods described above.

[0019] This application provides a digital asset protection method, apparatus, device, medium, and product, including: firstly, obtaining authorization metadata corresponding to the target digital asset based on a hybrid authorization mode, wherein the hybrid authorization mode is an authorization mode combining physical locks and soft authorization; then, verifying the target resource in the authorization metadata; if the verification passes, loading the target digital asset through a target loading method. This application, through an authorization method combining physical locks and soft authorization, achieves flexible adjustment of authorization strategies, responding to business changes without replacing hardware, and significantly improving the flexibility of authorization management while ensuring a bottom line of security. Attached Figure Description

[0020] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 This is a flowchart illustrating a digital asset protection method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating an authorized metadata acquisition method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a resource verification method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a digital asset protection method according to another embodiment of this application; Figure 5 This is a flowchart illustrating a digital asset protection method according to another embodiment of this application; Figure 6 This is a schematic diagram of the structure of a digital asset protection device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the computer device provided in the embodiments of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0022] The terms "first," "second," "third," "fourth," etc. (if present) 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 data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein.

[0023] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0024] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0025] It should be understood that in this application, "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.

[0026] It should be understood that in this application, "multiple" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, "and / or B" can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Contains A, B, and C", "Contains A, B, and C" means that all three A, B, and C are contained; "Contains A, B, or C" means that one of A, B, and C is contained; "Contains A, B, and / or C" means that any one, two, or three of A, B, and C are contained.

[0027] It should be understood that in this application, "B corresponding to A", "B corresponding to A", "A corresponds to B", or "B corresponds to A" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Matching A and B is defined as a similarity between A and B that is greater than or equal to a preset threshold.

[0028] Depending on the context, "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection."

[0029] The data involved in this application may be data authorized by the tester or fully authorized by all parties. The collection, dissemination, and use of the data shall comply with the relevant laws, regulations and standards of the relevant countries and regions. The implementation methods / executives of this application may be combined with each other.

[0030] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0031] The present application will now be described in conjunction with the accompanying drawings and specific embodiments.

[0032] Currently, with the rapid development of AI technology, more and more enterprises are promoting intelligent transformation to improve service levels and reconstructing business processes using AI technology. In this process, AI engines and models, as core functional units, play a crucial role. To balance cost and effectiveness, many enterprises tend to directly purchase mature third-party AI technologies. Businesses that are not sensitive to data security usually use cloud services, while enterprises that prioritize data compliance and independent control choose to deploy their AI engines on their own servers and data centers, i.e., private deployment scenarios.

[0033] Meanwhile, as suppliers of AI engines and technologies, it is essential to implement effective protection for the engine and its critical resource files to prevent misuse and technology leaks. Specific risks include: users copying the engine and resources without authorization for expansion or even resale; indefinite trial periods for beta versions of the engine; obtaining the latest version of resources for free upgrades through unofficial channels; and data leaks caused by competitors reverse engineering and cracking core files. Currently, the mainstream protection method is to use encryption locks, but this method has a coarse-grained protection and lacks flexibility, only partially addressing the first two types of risks and failing to achieve fine-grained control over resources and functional characteristics.

[0034] Existing encryption lock technologies essentially achieve authorization verification by binding software to specific hardware, such as PCs / servers, encrypted USB drives, or network devices. When the software starts, it reads and calculates a unique identifier from the corresponding hardware, comparing it with the license information in the authorization file. This ensures the software can only run on authorized devices, preventing unauthorized copying and abuse. In AI engine scenarios, resource files typically include various forms such as knowledge bases, vocabularies, and model weights. Based on readability, they can be divided into two categories: one is highly readable resources such as text and images, easily parsed and utilized by competitors, requiring strong encryption protection; the other, such as model weights, are low-readable resources, difficult to use directly even if leaked, and have a high barrier to cracking. For different types of resources, existing solutions typically employ differentiated encryption algorithms to balance security and loading efficiency, and assign independent and dynamically adjustable keys to each model.

[0035] While traditional encryption lock technology can provide basic protection for the engine itself, it has significant shortcomings in resource version management, encryption algorithm coordination, and user association control. Specific pain points include: (1) inability to effectively control resource version updates and authorization timeliness; (2) lack of authorization segmentation capabilities for the internal functional characteristics of the engine; (3) the diversity of encryption algorithms for different types of resources and the core logic of the engine, resulting in complex and costly key management; and (4) authorization is not bound to user identity, making it difficult to prevent different users from copying resources. These defects can easily lead to risks during private delivery: too small an authorization scope will not meet the actual project needs, while too large an authorization will not prevent abuse. Therefore, it is urgent to develop a fine-grained authorization control method to overcome the limitations of traditional encryption lock solutions in the delivery of private AI engines, which have low flexibility and many blind spots in control, thereby achieving more accurate risk control and lower operation and maintenance costs.

[0036] To address the aforementioned issues, this application provides a method for protecting digital assets.

[0037] Please see Figure 1 , Figure 1 This is a flowchart illustrating a digital asset protection method provided in an embodiment of this application. Figure 1 As shown, it includes the following steps: Step S101: Based on the hybrid licensing mode, obtain the licensing metadata corresponding to the target digital asset.

[0038] The hybrid authorization mode is an authorization mode that combines physical locks and soft authorizations; the physical lock is the authorization server deployed on the physical server, and the soft authorization is the authorization client configured in the target digital asset.

[0039] For obtaining authorization metadata based on the hybrid authorization mode, it is necessary to first obtain soft authorization metadata from the authorization client and resource authorization metadata from the target digital asset. Then, through the encrypted communication channel established between the authorization client and the authorization server, physical lock authorization metadata is obtained. The physical lock authorization metadata is configured on the lock authorization server and consists of soft authorization metadata, resource authorization metadata and physical lock authorization metadata.

[0040] Specifically, such as Figure 2 As shown, the authorization client (i.e., soft authorization) is launched, and soft authorization metadata is read from its local configuration. This soft authorization client is pre-embedded as a software module in the target AI engine that needs to be protected (e.g., Figure 2 (Referring to "Engine A1" and "Engine A2" in the diagram). The soft license metadata contains the resource management policy bound to the engine instance. Typical fields include: a unique resource identifier (such as a hash value) that matches the resources allowed to be loaded by this instance, the license validity period (start and end time) of the resource, the version number of the resource being licensed, and a list of open functionalities that the engine is allowed to enable under this license (represented in the diagram as "soft license bound to unique resource identifier, resource validity period, version and functionalities").

[0041] When the engine attempts to load a specific resource file (i.e., the target digital asset), it parses the resource authorization metadata from a specific storage location of the resource file (such as the file header or a dedicated data segment). This metadata is written when the resource file is generated or delivered and is part of its inherent attributes. It mainly includes: which user ID (UID) the resource is authorized to use (as shown in "Resource Bound to User 1" in the figure), and the version number of the resource itself.

[0042] Then, a request is sent to the authorization server deployed on the authorization server (i.e., the physical lock) via a secure, encrypted communication channel to obtain the physical lock's authorization metadata. As the root of trust for hardware binding, the physical lock's authorization metadata represents the highest level of authorization (represented in the diagram as "Physical Lock Bound to User 1" or "Physical Lock Bound to User 2"). This data typically includes: the user identifier bound to the physical lock, a list of engine identifiers authorized to run on this hardware, and a list of resource identifiers authorized for use. Transmission via an encrypted channel ensures the confidentiality and integrity of the authorization information during transmission.

[0043] Finally, the three parts of metadata—soft authorization metadata from the client, resource authorization metadata from the resource file, and physical lock authorization metadata from the server—are logically integrated in memory to form a complete set of authorization metadata for subsequent multi-level verification. This set incorporates all constraints regarding which hardware (physical lock), which engine (soft authorization policy), and which version of which resource (resource's own attributes) a user can use.

[0044] Legitimate scenario (User 1 side): When "User 1's" "A Engine 1" attempts to load "Resource 1", the user identifier (all "User 1") in the metadata of the three parties matches, and the resource identifier, version and other information are verified, so the resource is successfully loaded.

[0045] Illegal Scenario (User 2's Side): When "User 2's" "A Engine 2" attempts to obtain "Resource 2" belonging to "User 1" through illegal channels, the system finds a mismatch when comparing the user identifier ("User 1") in the resource authorization metadata with the user identifier ("User 2") in the physical lock authorization metadata. The verification fails, and therefore the engine "refuses to load" the resource. This effectively prevents the illegal sharing and abuse of resources between different users.

[0046] This complete process provides a solid and reliable data foundation for subsequent fine-grained verification of authorization legitimacy, user legitimacy, version consistency, and functional scope control.

[0047] Step S102: Verify the target resource in the authorization metadata.

[0048] Verify the target resource in the authorization metadata, including: performing authorization verification on the target resource in the authorization metadata when the target digital resource starts up; and performing timeliness verification on the target resource in the authorization metadata when the target digital resource is running.

[0049] The authorization verification of the target resource in the authorization metadata includes: calculating the resource identifier of the target digital asset and comparing it with the resource identifier in the soft authorization metadata to determine the authorization legitimacy of the target digital resource; comparing the user identifier in the resource authorization metadata with the user identifier in the physical lock authorization metadata to determine the legitimacy of the current user; comparing the resource version in the soft authorization metadata with the resource version in the resource authorization metadata to determine resource version consistency; and determining the target open functions corresponding to the target digital asset based on the scope of open functions in the soft authorization metadata.

[0050] Specifically, such as Figure 3As shown, after obtaining the complete set of authorized metadata, the verification phase begins. This verification process is designed to be layered and triggered at different times to ensure that the target resource remains under the constraints of the authorized license throughout its entire lifecycle of loading and use. Verification is mainly performed at two key points in time: a comprehensive authorization legality verification is performed when the target digital resource (i.e., the AI ​​engine) starts; and an expiration verification is performed periodically during the operation of the target digital resource to prevent unauthorized use after the authorization has expired.

[0051] First, when the engine starts and attempts to load resources, a multi-level authorization verification is performed. This verification utilizes integrated authorization metadata to verify the legitimacy of this resource loading behavior from multiple dimensions: Resource authorization legitimacy verification: The cryptographic digest (e.g., SHA-256 hash value) of the resource file to be loaded (e.g., "Resource 1") is calculated in real time as its resource identifier. This identifier is then compared with the unique resource identifier pre-defined in the soft authorization metadata. Figure 2 In the "User 1" scenario shown, only if the two match completely can it be proven that the resource is a specific file that is loaded with an authorized license, thus preventing the loading of unauthorized or tampered resources.

[0052] User legitimacy verification: This involves verifying the user's identity (e.g., as recorded in the resource authorization metadata) through the database. Figure 2 The "Resource-Bound User 1" in the data and the bound user identifier in the physical lock authorization metadata obtained from the physical lock (e.g., Figure 2 The system compares the physical lock bound to user 1. This step is crucial for preventing resource abuse across users. Figure 2 As shown in the illegal scenario of "User 2", when the system detects that a resource belongs to "User 1" and attempts to load it on the hardware bound to "User 2", the verification immediately fails and the engine refuses to load it, thus effectively preventing the illegal sharing of resources between users.

[0053] Resource version consistency verification: Compares the resource version authorized in the software license metadata with the actual resource version recorded in the resource license metadata. This ensures that the engine will only load resources that strictly match its authorized version, preventing users from obtaining and attempting to use unauthorized upgraded or incompatible resource files through unofficial channels.

[0054] Functionality Scope Control: After successful verification, the corresponding functionalities of the AI ​​engine will be dynamically configured or unlocked based on the open functionality scope specified in the software license metadata. Even for the same engine binary file, the advanced functions available to different users or different license packages will be precisely controlled.

[0055] Secondly, after the engine successfully starts and enters the running phase, continuous runtime monitoring is implemented, primarily for validity verification. The validity period of resources in the software license metadata is checked periodically (e.g., by timed polling). Once the system time exceeds the valid time range of the license, the engine will proactively refuse to continue using the controlled resource or downgrade its functionality to an unauthorized state. This mechanism solves the problem of traditional solutions being unable to limit "indefinite trial use of the trial version," ensuring that the validity of the license is enforced.

[0056] In summary, a comprehensive and dynamic protection network is formed by authorization verification at startup and periodic validity verification during runtime. This not only ensures that "the right resources are used by the right users on the right hardware," but also finely controls available functions and their usage periods, thereby elevating authorization management from the traditional "whether it can run" to a comprehensive and refined management of resources, users, versions, functions, and validity periods.

[0057] Step S103: If the verification passes, load the target digital asset using the target loading method.

[0058] To load a target digital asset using the target loading method, a disguised digital asset must first be obtained. This disguised digital asset is a binary file. Then, the disguised digital asset is parsed according to a pre-set decryption algorithm to locate the data block storing the target digital asset. From the data block of the target digital asset, the loading interface is obtained, and the target digital asset is retrieved from the loading interface according to a preset call sequence rule.

[0059] The process of obtaining disguised digital assets includes: encrypting and compressing the target digital asset to obtain a compressed digital asset; segmenting the compressed digital asset to obtain a segmented digital asset; embedding the segmented digital asset into a file of a preset format and adding a disguise file to obtain a disguised digital asset, wherein the disguise file includes at least fake data and fake interfaces.

[0060] Specifically, the process is executed according to a predefined protection strategy, ultimately generating a standard format (such as...). Figure 4 The binary file (in ELF format as shown) is used as a disguise carrier.

[0061] First, the original target digital assets undergo preliminary security processing. High-strength encryption algorithms (such as AES) are used to encrypt the resource data, ensuring that even if data blocks are separated and extracted, they cannot be directly deciphered. Subsequently, the encrypted data is further compressed to reduce its size and alter its entropy characteristics, resulting in compressed digital assets.

[0062] Next, the compressed data is segmented and mixed. The compressed data blocks are divided into multiple data fragments according to a preset size or a random strategy. These fragments containing the actual content are not stored contiguously, but are embedded in a container file with a preset format. These real resource data (encrypted and compressed) blocks are placed as multiple independent data segments in specific sections of the ELF file.

[0063] Then, active interference and camouflage are implemented. To completely hide the real data within the noise, the system adds numerous fake files to the container files. This mainly consists of two parts: first, injecting a large amount of fake data (such as...). Figure 4 The fake resource data (labeled as 1, 2, 3, 4, etc.) is usually much larger than the real data, and its content may simulate the real resource structure or be randomly generated to mislead the judgment of reverse engineers; secondly, it defines multiple fake exported function interfaces (such as...). Figure 4 These are fake exported functions (interfaces with deceptive names), whose internal logic may return incorrect data, meaningless results, or contain only trap codes. Meanwhile, the only true exported function that can correctly retrieve real data is cleverly hidden within these fake interfaces.

[0064] Ultimately, a complex and indistinguishable fake digital asset file is generated. After the above steps, the resulting ELF file appears to standard analysis tools as a simple or complex binary file containing massive data segments and numerous exported functions. Crackers will find it difficult to locate the few "real resource data" blocks from the vast amount of "fake resource data," and also difficult to identify the unique "real exported function" from among the numerous "fake exported functions."

[0065] More importantly, the actual resource loading logic requires the caller to invoke multiple interfaces in a specific, non-contiguous sequence (potentially involving alternating calls to real and fake interfaces) to obtain the complete data. Any incorrect call order will result in obtaining invalid, fake data. This deep camouflage mechanism makes it extremely difficult to effectively extract and utilize resource files even if they are illegally obtained, thus achieving a high level of proactive anti-cracking protection.

[0066] In one embodiment, loading a target digital asset via a target loading method includes: when the target digital asset is an AI model, configuring corresponding offsets for the weight parameters of each layer of the AI ​​model to obtain a packaged AI model, wherein the offsets configured for different layers of the AI ​​model are different; performing a reverse offset operation on the weight parameters of each layer of the packaged AI model according to a pre-stored offset lookup table to obtain the AI ​​model, wherein the pre-stored offset lookup table stores the mapping relationship between the weight parameters and offsets of each layer of the AI ​​model.

[0067] Specifically, before the model is ready for delivery or release, a packaging operation is performed on the originally trained AI model: This involves iterating through each layer of the model and configuring a preset offset for each layer's weight parameters. This offset can be a fixed value or a value generated based on specific rules. Crucially, the offsets configured for different layers of the model are not the same. For example, ... Figure 5 As shown, 1 can be uniformly subtracted from all weights in the first layer, and 2 can be uniformly added to all weights in the second layer.

[0068] After this step, the weight distribution of the original model is intentionally and non-uniformly perturbed, generating a "wrapped AI model". If this wrapped model is directly loaded by a standard open-source loader that does not integrate the customized logic of this solution, the model will exhibit unpredictable and severely degraded performance (i.e., "unknown effect") because the weights of each layer have deviated from the original optimal values, thus losing its usability.

[0069] At the same time, an "offset lookup table" uniquely corresponding to the packaged model is generated and securely stored. This table records precisely the offset values ​​and their directions (positive or negative) applied to the weight parameters of each layer in a structured form (such as a dictionary or configuration file). This lookup table is crucial for subsequent correct recovery and is usually encrypted and stored on an authorized server or securely embedded into a custom loader.

[0070] When an authorized user loads the wrapper model using a custom loader that integrates verification logic, the loader securely obtains the corresponding offset lookup table after passing all authorization checks. Subsequently, the loader reads the weight parameters of the wrapper model layer by layer and performs precise inverse operations based on the offsets recorded in the lookup table. For example, if the original offset operation for a layer is "-1", then all parameters for that layer are incremented by "+1"; if the original offset is "+2", then "-2" is performed. Through this completely symmetrical inverse offset calculation, the perturbed weights in the wrapper model are restored layer by layer to their optimal values ​​obtained during original training, resulting in an AI model that is mathematically equivalent to the original model and can perform inference tasks correctly.

[0071] This embodiment constructs an effective defense in the model distribution process through a mechanism of "offset packaging first, authorization restoration later". Even if an attacker bypasses the outer encryption and obtains the model file, they will only get a distorted and useless model because they cannot obtain the correct offset lookup table or reverse compensation logic. This greatly increases the difficulty of the model being illegally cracked and directly exploited.

[0072] In another embodiment, loading a target digital asset through a target loading method includes: constructing a mapping relationship table, where the mapping relationship table includes an input transformation mapping table and an output restoration mapping table; converting the original data in the target digital asset into corresponding transformed data according to the input transformation mapping table; and restoring the transformed data into the original data according to the output restoration mapping table to obtain the target digital asset.

[0073] Specifically, first, construct and encrypt and store a complete mapping relationship table in a secure environment. This table usually contains two reciprocal parts: an input transformation mapping table and an output restoration mapping table. The input transformation mapping table defines the conversion rules from the original semantic space to the disguised semantic space. For example, map the common word "hello" to "he is here" which has no direct association, and map "China" to "supermarket". The output restoration mapping table stores the completely opposite mapping relationship, which is used to restore the results generated by the engine in the disguised space to the original space. This mapping relationship table itself, as a key protection component, is usually strongly bound to specific user authorizations or resource versions and encrypted to ensure that it cannot be easily extracted or analyzed.

[0074] When an authorized user submits the original input through an engine integrated with this protection mechanism, the loading process first calls the input transformation module. This module decrypts and reads the input transformation mapping table in memory, and then performs real-time, element-by-element mapping replacement on the original data submitted by the user. For example, the original text "hello China" input by the user becomes "he is here supermarket" after being transformed by the mapping table, and this transformed input is actually sent to the core computing unit of the engine. This transformation process is transparent to the user and ensures that the original semantics are completely hidden under an openly meaningless "code word" expression.

[0075] The core resources of the engine (such as models, knowledge bases) are optimized based on the above-mentioned disguised semantic space during the training or construction phase. This means that the resources "understand" and are good at processing the transformed corpus such as "he is here supermarket", and their internal logic matches the transformed input. Therefore, when the engine receives the transformed input "he is here supermarket", its internal processing process is completely normal, and it generates corresponding transformed outputs based on its resources, such as maybe outputting "today's weather".

[0076] Finally, the output processing module of the engine will apply the output restoration mapping table. Taking the transformed output "today's weather" generated by the engine as the input, and through looking up the inverse mapping table, restore it to the expression in the original semantic space, such as restoring it to "nice to meet you", and finally return the result to the user.

[0077] This embodiment achieves effective isolation and obfuscation at the input / output interface by constructing a closed, authorized "semantic transformation-reversion" loop. For attackers, even if they successfully extract the engine's core resource files through reverse engineering, they only obtain a set of logic for processing the "code language" system. Because they cannot obtain the encrypted, authorization-bound two-way mapping table, these stolen resources cannot be used to process normal user input, greatly improving asset protection.

[0078] In one embodiment, the method further includes: inserting at least one set of tracking feature data with a preset output pattern into the target digital asset; periodically sending probe requests containing tracking feature data to the target service interface and obtaining corresponding output responses; judging the output responses; if the output responses contain features that match the tracking feature data, generating a resource leakage alarm, and tracing the source of leakage based on the authorization identifier associated with the tracking feature data.

[0079] Specifically, during the production or construction phase of a target digital asset (such as an AI model, knowledge base, or graph library), at least one set of special tracking feature data is securely embedded into it. This feature data cannot be naturally input or used by a real user under normal circumstances, and it is mapped to a preset, fixed, and unique output pattern. For example, for a text model, it might be a specific and meaningless combination of phrases (such as "quantum roses snow in July"); for an image model, it might be a set of pixel blocks with specific noise patterns or steganographic features. Each set of embedded tracking feature data is strongly encrypted and associated with specific authorized metadata (such as user identifier, resource version number, delivery timestamp), forming a hidden "digital fingerprint."

[0080] Deploy a background monitoring service that periodically (e.g., daily or weekly) sends probe requests to pre-defined target service interfaces that need to be monitored (such as the public APIs of suspicious competitors). Each probe request's input includes previously embedded tracking feature data. The monitoring service then captures the output responses returned by the target interfaces.

[0081] After receiving the response, the analysis module is invoked to automatically evaluate the output response. The core evaluation logic is to detect whether the response content contains features that highly match the preset output pattern corresponding to the implanted tracking feature data. This matching can be completely identical text output, or it can be an image or structured data with specific statistical features.

[0082] Once the analysis module determines that an output response contains matching features, the monitoring system immediately triggers an alarm process. A detailed resource leak alarm is generated, containing not only information such as the time of the leak and the target service, but more importantly, it quickly correlates and decrypts the authorization identifier information linked to the triggering feature data. This "digital fingerprint" precisely pinpoints which resource the feature data was initially embedded in, which specific user (user identifier) ​​it was delivered to, and the corresponding resource version and delivery time. This allows resource providers to quickly trace the potential source of the leak—a specific authorized user or a specific batch of resource deliveries—providing crucial and direct evidence for subsequent legal investigations, accountability, or technical remediation. This mechanism transforms reactive, post-incident response into proactive monitoring and tracing, significantly enhancing the ability to handle resource leaks.

[0083] This application provides a digital asset protection method, comprising: first, obtaining authorization metadata corresponding to the target digital asset based on a hybrid authorization mode, wherein the hybrid authorization mode is an authorization mode combining physical locks and soft authorization; then, verifying the target resource in the authorization metadata; if the verification passes, loading the target digital asset through a target loading method. This application, through the authorization method combining physical locks and soft authorization, achieves flexible adjustment of the authorization strategy, responding to business changes without replacing hardware, and significantly improving the flexibility of authorization management while ensuring a bottom line of security.

[0084] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0085] The following are device embodiments of this application. For details not described in detail, please refer to the corresponding method embodiments described above.

[0086] Figure 6 This diagram illustrates a digital asset protection device according to an embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown. The digital asset protection device includes: The data acquisition module 601 is used to acquire the authorization metadata corresponding to the target digital asset based on the hybrid authorization mode, wherein the hybrid authorization mode is an authorization mode that combines physical lock and soft authorization; The verification module 602 is used to verify the target resource in the authorization metadata; Loading module 603 is used to load the target digital asset via the target loading method if the verification passes.

[0087] In one embodiment, the physical lock is an authorization server deployed on a physical server, and the soft authorization is an authorization client configured in the target digital asset; The data acquisition module 601 is also used to acquire soft license metadata from the licensed client and resource license metadata from the target digital asset; The physical lock authorization metadata is obtained through an encrypted communication channel established between the authorized client and the authorized server. The physical lock authorization metadata is configured on the lock authorization server. Authorization metadata consists of soft authorization metadata, resource authorization metadata, and physical lock authorization metadata.

[0088] In one embodiment, the verification module 602 is further configured to perform authorization verification on the target resource in the authorization metadata when the target digital resource is started; When the target digital resource is running, the timeliness of the target resource in the authorized metadata is verified.

[0089] In one embodiment, the verification module 602 is further configured to calculate the resource identifier of the target digital asset and compare the resource identifier of the target digital asset with the resource identifier in the soft authorization metadata to determine the authorization legality of the target digital resource; The user identifier in the resource authorization metadata is compared with the user identifier in the physical lock authorization metadata to determine the legitimacy of the current user; Compare the resource version in the soft license metadata with the resource version in the resource license metadata to determine resource version consistency; Based on the scope of open functions in the soft license metadata, determine the target open functions corresponding to the target digital asset.

[0090] In one embodiment, the loading module 603 is further configured to acquire a disguised digital asset, wherein the disguised digital asset is a binary file; The disguised digital assets are analyzed using a pre-set decryption algorithm to locate the data block storing the target digital assets; Obtain the loading interface from the data block of the target digital asset; The target digital asset is retrieved from the loading interface according to the preset call sequence rules.

[0091] In one embodiment, the loading module 603 is further configured to encrypt and compress the target digital asset to obtain the compressed digital asset; The compressed digital assets are segmented to obtain the segmented digital assets. The segmented digital assets are embedded into a file of a preset format, and a fake file is added to obtain a fake digital asset. The fake file includes at least fake data and fake interfaces.

[0092] In one embodiment, the loading module 603 is further configured to configure corresponding offsets for the weight parameters of each layer of the AI ​​model when the target digital asset is an AI model, so as to obtain the packaged AI model, wherein the offsets configured for different layers of the AI ​​model are different. The AI ​​model is obtained by performing a reverse offset operation on the weight parameters of each layer of the packaged AI model according to the pre-stored offset lookup table. The pre-stored offset lookup table stores the mapping relationship between the weight parameters of each layer of the AI ​​model and the offset.

[0093] In one embodiment, the loading module 603 is further configured to construct a mapping table, wherein the mapping table includes an input deformation mapping table and an output restoration mapping table; Based on the input deformation mapping table, the original data in the target digital asset is converted into the corresponding deformation data; Based on the output restoration mapping table, the deformed data is restored to the original data to obtain the target digital asset.

[0094] In one embodiment, the apparatus further includes: a tracing module, which is used to insert at least one set of tracking feature data with a preset output pattern into the target digital asset; Periodically send probe requests containing tracking feature data to the target service interface and obtain the corresponding output response; Judge the output response; If the output response contains features that match the tracking feature data, a resource leak alarm is generated, and the source of the leak is traced based on the authorization identifier associated with the tracking feature data.

[0095] This application provides a digital asset protection device, specifically used for: firstly, acquiring the authorization metadata corresponding to the target digital asset based on a hybrid authorization mode, wherein the hybrid authorization mode is an authorization mode combining physical locks and soft authorization; then, verifying the target resource in the authorization metadata; if the verification passes, loading the target digital asset through a target loading method. This application, through the authorization method combining physical locks and soft authorization, achieves flexible adjustment of the authorization strategy, responding to business changes without replacing hardware, and significantly improving the flexibility of authorization management while ensuring a bottom line of security.

[0096] This application Figure 7 A schematic diagram of a computer device is provided. (Example) Figure 7 As shown, the computer device 7 in this embodiment includes a processor 701, a memory 702, and a computer program 707 stored in the memory 702 and executable on the processor 701. When the processor 701 executes the computer program 707, it implements the steps described in the various digital asset protection method embodiments above, for example... Figure 1Steps 101 to 103 are shown. Alternatively, when processor 701 executes computer program 707, it implements the functions of each module / unit in the above-described embodiments of digital asset protection devices, for example... Figure 6 The functions of modules / units 601 to 603 shown.

[0097] This application also provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the digital asset protection methods provided in the various embodiments described above.

[0098] The readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of computer programs from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application-Specific Integrated Circuit (ASIC). Alternatively, the ASIC can be located in a user equipment. Of course, the processor and the readable storage medium can also exist as discrete components in a communication device. The readable storage medium can be a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0099] This application also provides a program product including executable instructions stored in a readable storage medium. At least one processor of the device can read the executable instructions from the readable storage medium, and executing the executable instructions causes the device to implement the digital asset protection methods provided in the various embodiments described above.

[0100] In the embodiments of the above-described device, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0101] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for protecting digital assets, characterized in that, include: Based on the hybrid authorization mode, the authorization metadata corresponding to the target digital asset is obtained, wherein the hybrid authorization mode is an authorization mode that combines physical lock and soft authorization; Verify the target resource in the authorized metadata; If the verification passes, the target digital asset is loaded using the target loading method.

2. The digital asset protection method as described in claim 1, characterized in that, The physical lock is an authorization server deployed on a physical server, and the soft authorization is an authorization client configured in the target digital asset; The acquisition of authorization metadata based on the hybrid authorization mode includes: Obtain soft authorization metadata from the authorized client, and obtain resource authorization metadata from the target digital asset; The physical lock authorization metadata is obtained through the encrypted communication channel established between the authorized client and the authorized server, wherein the physical lock authorization metadata is configured in the lock authorization server; The authorization metadata consists of the soft authorization metadata, the resource authorization metadata, and the physical lock authorization metadata.

3. The digital asset protection method as described in claim 1, characterized in that, The verification of the target resource in the authorized metadata includes: When the target digital resource is started, the authorization of the target resource in the authorization metadata is verified. When the target digital resource is running, the timeliness of the target resource in the authorized metadata is verified.

4. The digital asset protection method as described in claim 3, characterized in that, The authorization verification of the target resource in the authorization metadata includes: Calculate the resource identifier of the target digital asset and compare it with the resource identifier in the soft authorization metadata to determine the authorization legality of the target digital resource; The user identifier in the resource authorization metadata is compared with the user identifier in the physical lock authorization metadata to determine the legitimacy of the current user; The resource version in the soft license metadata is compared with the resource version in the resource license metadata to determine that the resource versions are consistent. Based on the scope of open functions in the soft license metadata, the target open functions corresponding to the target digital asset are determined.

5. The digital asset protection method as described in claim 1, characterized in that, The loading of the target digital asset via the target loading method includes: Obtain a disguised digital asset, wherein the disguised digital asset is a binary file; The disguised digital asset is parsed according to a pre-set decryption algorithm to locate the data block storing the target digital asset; Obtain the loading interface from the data block of the target digital asset; The target digital asset is obtained from the loading interface according to the preset call sequence rules.

6. The digital asset protection method as described in claim 5, characterized in that, The acquisition of disguised digital assets includes: The target digital asset is encrypted and compressed to obtain the compressed digital asset. The compressed digital assets are segmented to obtain segmented digital assets. The segmented digital assets are embedded into a file of a preset format, and a fake file is added to obtain the fake digital assets, wherein the fake file includes at least fake data and fake interfaces.

7. The digital asset protection method as described in claim 1, characterized in that, The loading of the target digital asset via the target loading method includes: When the target digital asset is an AI model, corresponding offsets are configured for the weight parameters of each layer of the AI ​​model to obtain the packaged AI model. The offsets configured for different layers of the AI ​​model are different. The AI ​​model is obtained by performing a reverse offset operation on the weight parameters of each layer of the packaged AI model according to the pre-stored offset lookup table, wherein the pre-stored offset lookup table stores the mapping relationship between the weight parameters of each layer of the AI ​​model and the offset.

8. The digital asset protection method as described in claim 1, characterized in that, The loading of the target digital asset via the target loading method includes: Construct a mapping table, wherein the mapping table includes an input deformation mapping table and an output restoration mapping table; Based on the input deformation mapping table, the original data in the target digital asset is converted into corresponding deformation data; Based on the output restoration mapping table, the deformed data is restored to the original data to obtain the target digital asset.

9. The digital asset protection method as described in claim 1, characterized in that, The method further includes: Insert at least one set of tracking feature data with a preset output pattern into the target digital asset; Periodically send probe requests containing the tracking feature data to the target service interface and obtain the corresponding output response; The output response is evaluated. If the output response contains features that match the tracking feature data, a resource leakage alarm is generated, and the source of the leakage is traced based on the authorization identifier associated with the tracking feature data.

10. A digital asset protection device, characterized in that, include: The data acquisition module is used to acquire the authorization metadata corresponding to the target digital asset based on the hybrid authorization mode, wherein the hybrid authorization mode is an authorization mode that combines physical lock and soft authorization; The verification module is used to verify the target resources in the authorized metadata; The loading module is used to load the target digital asset using the target loading method if the verification passes.

11. A computer device, characterized in that, Includes a memory, and one or more processors communicatively connected to the memory; The memory stores instructions that can be executed by the one or more processors to cause the one or more processors to implement the digital asset protection method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, Includes a program or instructions that, when run on a computer, implement the digital asset protection method of any one of claims 1 to 9.

13. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the digital asset protection method according to any one of claims 1 to 9.

Images