A device binding software encryption method and system based on multi-layer nested encryption
By employing multi-layered nested encryption and closed-loop device ID verification, the problem of preventing reverse engineering and copying of software encryption in offline environments is solved, achieving highly secure and robust software protection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SICHUAN HAIGE HENGTONG PRIVATE NETWORK TECH CO LTD
- Filing Date
- 2026-04-08
- Publication Date
- 2026-07-03
AI Technical Summary
In environments with strong offline conditions and no reliable network connection, existing software encryption protection mechanisms cannot effectively prevent reverse engineering, copying, and static analysis.
A multi-layered nested encryption method is adopted, including AES encryption, ECC signature and ZUC stream cipher algorithm, to construct a three-layer nested encryption sequence. Combined with closed-loop verification of device ID, it ensures that the software license file cannot be reverse-analyzed and copied in an offline environment.
It improves the security of software encryption, prevents reverse engineering and illegal copying, achieves high-strength identity authentication and anti-tampering in offline environments, and enhances the robustness and flexibility of the system.
Smart Images
Figure CN122339760A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of software copyright protection technology, and in particular to a device binding software encryption method and system based on multi-layer nested encryption. Background Technology
[0002] In the field of software copyright protection, existing technologies mainly rely on the following solutions, but all of them have significant technical shortcomings: 1. Online Activation / Verification Solution: The software must connect to an authorization server for verification upon startup. However, this method is highly dependent on the environment and cannot be used in environments without a network or in isolated locations (such as intranets or confidential environments). It also suffers from a single point of failure: if the centralized verification server crashes or is attacked, all legitimate users will be unable to use the software, resulting in poor system robustness. User experience and privacy are also compromised: continuous network interaction affects startup speed, and user behavior may be recorded by the server.
[0003] 2. Binding schemes based on single encryption or simple hardware information: The technical essence of a dongle (USB dongle) or serial number is "verifying an external key." Dongles are easily emulated (by simulating their communication protocol through software), and serial numbers are easily brute-forced or shared. These schemes cannot resist professional memory debugging and reverse engineering attacks. Simple hardware fingerprint binding only uses hardware information such as the CPU serial number and hard drive ID as input parameters to generate a license, or simply encrypts it and stores it in a configuration file. Attackers can easily crack and illegally copy the license by forging hardware information (hooking related API calls) or by directly copying the entire license file to another device.
[0004] 3. Insufficient encryption strength: This includes schemes using only a single symmetric encryption method (such as AES) or only digital signatures. The former cannot verify file integrity and the identity of the issuer, while the latter cannot protect the privacy of the licensed content. Even when combined, if a common "sign first, then encrypt" approach or simple parallel processing is used, the internal structure is relatively fixed, making it easy for analysis tools to identify and locate critical code segments, and resulting in weak resistance to static analysis and dynamic debugging.
[0005] CN119094167A describes a communication encryption method based on Chinese national cryptographic algorithms. It achieves multi-layered encryption protection through different national cryptographic algorithms, balancing data privacy and security, and ensuring encryption effectiveness while achieving efficient data processing and transmission. However, it does not mention anti-reverse engineering measures and cannot provide software encryption protection against reverse engineering in environments with strong offline conditions and no reliable network connection. Summary of the Invention
[0006] The purpose of this invention is to address the problem that existing software encryption protection mechanisms cannot prevent reverse engineering, copying, and static analysis in environments with strong offline conditions and no reliable network connection. This invention provides a device binding software encryption method and system based on multi-layer nested encryption, which can effectively resist copying, tampering, reverse analysis, and illegal porting.
[0007] To achieve the above objectives, the present invention adopts the following technical solution: A device binding software encryption method based on multi-layer nested encryption includes the following steps: S1: Generate the issuance key and verification key; S2: Construct the plaintext license information and perform three-layer nested encryption on it: Encrypt the plaintext license information using AES and output the AES ciphertext and authentication label; Elliptic curve digital signature is performed on the AES ciphertext using ECC to obtain the ECC signature value; The AES ciphertext and ECC signature value are concatenated, and the concatenated data is encrypted using the ZUC stream cipher algorithm to obtain the ciphertext obfuscation. S3: Reverse decrypt the encrypted obfuscated text and verify whether the device ID in the decrypted plaintext license information matches the read real-time device ID.
[0008] The device binding software encryption method based on multi-layer nested encryption provided by this invention adopts a fixed nesting order of "AES-ECC-ZUC" and uses ZUC to mask the fixed characteristics of AES ciphertext blocks and ECC signatures, making them unrecognizable in static analysis and improving security.
[0009] Preferably, step S1 includes: randomly generating AES_KEY, ZUC_KEY, and ECC key pairs using a key generator; constructing a signing key structure and a verification key structure, wherein the signing key structure includes public keys ECC_PRI, AES_KEY, and ZUC_KEY, and the verification key structure includes private keys ECC_PUB, AES_KEY, and ZUC_KEY; encrypting the signing key structure using a pre-programmed master key to generate a signing key file; and encrypting the verification key structure using the master key to generate a verification key file.
[0010] Preferably, step S3 includes: decrypting the ciphertext obfuscation using the verification key structure .ZUC_KEY to obtain the decrypted data, and parsing out the AES ciphertext and ECC signature value; verifying the AES ciphertext and ECC signature value using the verification key structure .ECC_PUB; if the verification fails, immediately returning an error code and terminating subsequent steps; if the verification succeeds, decrypting the AES ciphertext using the verification key structure .AES_KEY to obtain the original license information plaintext; extracting the verification key field from the decrypted license information plaintext, comparing it byte-by-byte with the read device real-time ID; if the two are completely consistent and the current time has not exceeded the expiration time in the license information plaintext, returning the function flag bit in the license information plaintext; if the verification key is inconsistent or has expired, returning an error code.
[0011] Preferably, in step S3, before performing the decryption operation, the following steps are also included: calling the verification interface of the license verification library, the library function reads the real-time device ID of the current device in real time through the device driver, loads the verification key and encrypted_equip_verify_sec from the device storage area, and decrypts them with the pre-burned master key to obtain the verification key structure and the ciphertext obfuscation body, respectively.
[0012] As a preferred method, before performing multi-layer nested encryption: the verification key file is written to the non-volatile storage area of the target device, and the licensee reads the verification key of the target device through the device driver interface; the licensee loads and uses the master key to decrypt the issuance key to obtain the issuance key structure.
[0013] Preferably, a device-specific password lock structure is constructed by constructing a ciphertext obfuscation, and the device-specific password lock structure is encrypted using a pre-programmed master key. The encrypted device-specific password lock structure is then written into the non-volatile storage area of the target device.
[0014] Preferably, the license information in plaintext includes the device ID, expiration time, and function flags.
[0015] Preferably, the device ID includes CPU-ID, motherboard ID, storage ID, and network card MAC address.
[0016] A device binding software encryption system based on multi-layer nested encryption, comprising: Key generator, generates issuance keys and verification keys; The license issuer generates a unique license file for each device based on the verification key of the target device and the issuance key generated in the previous stage, and performs three-layer nested encryption on the plaintext license information. The license verification library, either as a static or dynamic library, is compiled and linked into the software of the device that needs protection, and performs verification at runtime.
[0017] As a preferred approach, the key generator, license issuer, and license verification library are subjected to strong code obfuscation, virtual machine protection, and anti-debugging hardening; the verification logic part in the license verification library is ported to the inside of the security chip for execution.
[0018] Therefore, this invention has the following beneficial effects: It uses the JSON-based markup language JPML to dynamically define the user interface, completely decoupling UI presentation from business logic. This allows the same client-side rendering program to serve devices with different functionalities, improving code reusability. The server can dynamically generate JPML page content at any time; the interface layout, text, and even control types can be changed without updating the client firmware, achieving rapid response to interface changes and enhancing flexibility. Attached Figure Description
[0019] Figure 1 This is a flowchart of the steps in the device binding software encryption method based on multi-layer nested encryption in this invention.
[0020] Figure 2 This is a schematic diagram of the multi-layered nested encryption process in this invention.
[0021] Figure 3 This is a schematic diagram of the reverse decryption and closed-loop verification process in this invention.
[0022] Figure 4 This is a schematic diagram of the device binding software encryption system based on multi-layer nested encryption in this invention. Detailed Implementation
[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this application will be further described in detail below through embodiments and in conjunction with the accompanying drawings. It should be understood that the specific embodiments described herein are only one preferred embodiment of this application and are only used to explain this application. They do not limit the scope of protection of this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.
[0024] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.
[0025] Example 1: This embodiment provides a device binding software encryption method based on multi-layer nested encryption, such as... Figure 1As shown, the operation process is as follows: Step 1, generate the issuance key and verification key; Step 2, construct the plaintext of the license information and perform three-layer nested encryption processing on the plaintext of the license information: encrypt the plaintext of the license information using AES, output the AES ciphertext and authentication tag; use ECC to perform elliptic curve digital signature on the AES ciphertext to obtain the ECC signature value; concatenate the AES ciphertext and the ECC signature value, and encrypt the concatenated data using the ZUC stream cipher algorithm to obtain the ciphertext obfuscation; Step 3, reverse decrypt the ciphertext obfuscation and verify whether the device ID in the decrypted plaintext of the license information is consistent with the read real-time device ID.
[0026] This embodiment designs a technical solution that couples a "multi-layered nested encryption signature process in a specific order" with "closed-loop verification logic based on hardware information," which can be used to solve the following technical problems: 1. Solve the problem of high-strength identity authentication and anti-tampering in offline environments: By introducing asymmetric cryptography (ECC) to sign the core ciphertext, the license file can still be verified for its authenticity and integrity in offline mode.
[0027] 2. Addressing the vulnerability of single-layer encryption to reverse engineering: By employing a specific, irreversible nested sequence of AES encryption → ECC signature → ZUC encryption, a "defense-in-depth" system is constructed. The core function of the outermost ZUC encryption is to obfuscate and conceal the internal AES ciphertext and ECC signature structure, greatly increasing the difficulty for attackers to perform static analysis and locate key verification code.
[0028] 3. Solve the problem of traditional hardware binding being easily bypassed: Through the closed-loop design of "collecting during writing and reading and comparing in real time during verification", the device hardware ID (equip_id) is used as both the encrypted content of the license file and the ultimate criterion for runtime verification, thereby eliminating the possibility of simply copying the license file to another device for use in terms of technical logic.
[0029] The following examples and specific application scenarios further illustrate the technical solution and effects of the present invention. The following examples are explanations of the present invention, but the present invention is not limited to the following examples.
[0030] This embodiment provides a device binding software encryption method based on multi-layer nested encryption, such as... Figure 1 As shown, it includes the following steps: Step 1: System initialization, generating issuance and verification keys.
[0031] Specifically, it includes: Step (1.1): In a secure environment, run the key generator tool pc_equip_key_gen.
[0032] Step (1.2): The tool is generated randomly.
[0033] This includes AES_KEY (32 bytes), ZUC_KEY (16 bytes), and ECC_KEY_PAIR. ECC_KEY_PAIR is an ECC key pair containing the public key ECC_PUB and the private key ECC_PRI.
[0034] Step (1.3): Construct the data structure.
[0035] Construct the issuance key structure (pc_key_struct) and the verification key structure (equip_key_struct).
[0036] The pc_key_struct includes {ECC_PRI, AES_KEY, ZUC_KEY}.
[0037] The equip_key_struct includes {ECC_PUB, AES_KEY, ZUC_KEY}.
[0038] Step (1.4): Use a fixed master key (MASTER_KEY) pre-programmed into the key generator to encrypt the two structures respectively, generating the encrypted issuance key file (pc.key file) and verification key file (equip.key file).
[0039] pc.key is the signing key. In this embodiment, a hardware dependency is introduced for the signing key: the core ECC_PRI in the signing key is stored in the Hardware Security Module (HSM) or the TPM on the administrator's computer. When the key generator tool is called, the signing operation is completed internally in the hardware, and the private key is never exported.
[0040] equip.key is the verification key.
[0041] The master key can be generated and stored by a secure chip.
[0042] Step 2: Production and issuance of licenses: Construct the plaintext license information and perform three-layer nested encryption on the plaintext license information.
[0043] like Figure 2 As shown, Figure 2 It clearly demonstrates each step from reading the equipment_id to outputting the equipment_verify_sec, especially the order and data transformation process of AES encryption → ECC signing → ZUC encryption.
[0044] Figure 2In this process, the key operations in the input and preparation phases are reading the device ID and decrypting the issuance key. The input at this stage consists of the device hardware and the pc.key file, and the output is the original ID and the pc.key structure. The purpose is to obtain the device's unique identity and the system's cryptographic root of trust, preparing for binding and signing.
[0045] Based on the above, the specific steps for issuing a production license are as follows: Step (2.1): On the production line, write the equip.key file to the non-volatile memory area of the target device.
[0046] Step (2.2): Run the license issuer (pc_equip_verify_gen) tool. The license issuer reads the unique identifier of the device, equip_id (device ID), through the device driver interface (such as IOCTL).
[0047] Step (2.3): The license issuer loads and decrypts the pc.key file using the master key MASTER_KEY to obtain pc_key_struct.
[0048] Step (2.4): Construct the plaintext license information `license_info`. The structure of the plaintext license information is `{Device ID: equip_id, Expiry Date: expiry_date, Feature Flags: features, ...}`. The purpose is to bind the business rules that need to be protected (such as the expiry date) with the device ID to form the object to be protected.
[0049] The device ID can employ multiple physical unique identifiers within the device, using SHA256 (CPU_id + motherboard ID + storage ID + network card MAC address, etc.) to increase the difficulty of copying. The Physically Unclonable Function (PUF) feature of the security chip can also be used simultaneously.
[0050] SHA256 is a 256-bit cryptographic hash algorithm.
[0051] Step (2.5): Core encryption process.
[0052] Specifically, it includes: Step (2.5.1): AES encryption layer encryption.
[0053] Use the issuance key structure .AES_KEY (pc_key_struct.AES_KEY) to encrypt the plaintext license information in AES-GCM or AES-CBC mode, and output the AES ciphertext (aes_ciphertext) and the authentication tag (such as GCM Tag).
[0054] The purpose of the AES encryption layer is to achieve confidentiality, ensure that licensed information is unreadable in plaintext, and provide the first layer of protection for core content.
[0055] Step (2.5.2): ECC signature layer signing.
[0056] Using the issue key structure ECC_PRI(pc_key_struct.ECC_PRI), perform an elliptic curve digital signature (such as ECDSA with SHA256) on the aes_ciphertext (or the data packet containing the aes_ciphertext and its authentication label) to obtain the ECC signature value (ecc_signature).
[0057] The purpose of the ECC signature layer is to achieve integrity and authentication, ensure that the AES ciphertext is not tampered with in subsequent processes, and prove that the license was generated by the issuer who rightfully holds the private key.
[0058] Step (2.5.3): The ZUC encryption obfuscation layer obfuscates the first two layers of the structure.
[0059] The AES ciphertext is concatenated with the ECC signature value. The ZUC_KEY (pc_key_struct.ZUC_KEY) structure is used as the key, and the entire concatenated data is encrypted using the ZUC stream cipher algorithm to obtain the final ciphertext obfuscation (zuc_ciphertext).
[0060] The purpose of the ZUC encryption obfuscation layer is to achieve both obfuscation and secondary confidentiality. Obfuscation refers to masking the inherent data characteristics of the internal AES ciphertext and ECC signature, resisting static analysis. Simultaneously, it adds another layer of encryption protection to the already signed ciphertext, enhancing confidentiality.
[0061] This embodiment also includes constructing the key obfuscation body into an equip_verify_sec structure, encrypting it with MASTER_KEY, and writing it into the non-volatile storage area of the target device.
[0062] Secure storage is achieved by packaging the key obfuscation into multiple parts and encrypting them with the master key. This ensures encrypted storage of the final output, preventing the file from being directly parsed or replaced.
[0063] Step 3: Reverse decrypt and verify the encrypted obfuscated text. If the verification is successful, return the function flag bit in the plaintext of the license information; otherwise, return an error code.
[0064] The third step involves verification during device runtime, which is a reverse decryption and closed-loop verification process.
[0065] The specific process is as follows: Figure 3 As shown, Figure 3It clearly demonstrates every step from reading the device's current equip_id and license file to the final output verification result, especially the order and decision points of ZUC decryption → ECC signature verification → AES decryption → ID comparison.
[0066] Figure 3 In the initialization step, the key operations are reading the current ID and decrypting the local file. The inputs are the device hardware and storage files, and the outputs are the device real-time ID (equip_id_current), the key, and the ciphertext to be verified. Its purpose is to prepare the dynamic identity flattening, verification key, and object to be verified required for verification.
[0067] Therefore, the reverse decryption and closed-loop verification process includes the following specific steps: Step (3.1): After the device software starts, it calls the verification interface of the license verification library (equip_verify_judge).
[0068] Step (3.2): The library functions of the license verification library read the current device's equip_id_current in real time through the device driver.
[0069] Step (3.3): Load equip.key and encrypted_equip_verify_sec from the device storage area, and decrypt them with MASTER_KEY to obtain equip_key_struct and zuc_ciphertext respectively.
[0070] Step (3.4): Core decryption process.
[0071] Step (3.4.1): ZUC decryption layer.
[0072] Use the verification key structure .ZUC_KEY (equip_key_struct.ZUC_KEY) to decrypt zuc_ciphertext, obtain the decrypted data, and parse out the AES ciphertext and ECC signature value.
[0073] Its purpose is to remove the obfuscation layer, restore the protected ciphertext and signature inside, and prepare for signature verification.
[0074] Step (3.4.2): ECC verification layer.
[0075] The AES ciphertext and ECC signature value are verified using the verification key structure .ECC_PUB(equip_key_struct.ECC_PUB). If verification fails, an "Invalid License" error code is immediately returned, terminating all subsequent steps.
[0076] The ECC verification layer is the first decision point. Its purpose is to verify the integrity and the identity of the issuer. This is the first and most critical security valve. If the signature is invalid, it means that the document has been tampered with or not officially issued. The process will be terminated immediately, and no further operations will be carried out.
[0077] Step (3.4.3): AES decryption layer.
[0078] Use the verification key structure .AES_KEY(equip_key_struct.AES_KEY) to decrypt the AES ciphertext and obtain the original plaintext license information.
[0079] The purpose of the AES decryption layer is to restore the plaintext of the license information and decrypt its contents only after confirming that the file is complete and trustworthy.
[0080] Step (3.5): Key closed-loop comparison.
[0081] Extract the device ID field from the decrypted plaintext license information and compare it byte by byte with the equip_id_current read in step (3.2).
[0082] Device ID comparison is the second decision point, the purpose of which is to achieve closed-loop verification and anti-copying. This is the second security valve to ensure that the running device is the specific device authorized by the license document. If they do not match, the process will be terminated immediately, effectively preventing document copying attacks.
[0083] Step (3.6): Final decision.
[0084] If both are completely identical, and the current time has not exceeded the expiry_date in the plaintext license information, then "Verification successful" and the function flag in the plaintext license information are returned. If the equip_id is inconsistent or has expired, then "License mismatch" or "License expired" error codes are returned.
[0085] The purpose of the above business rule verification is to execute business logic and perform application layer rule verification after the first two layers of cryptographic security have been passed.
[0086] The device binding software encryption method based on multi-layer nested encryption provided in this embodiment has the following beneficial effects: 1. Significantly enhanced security: A triple technical barrier is formed, consisting of "AES" → "ECC" → "ZUC" (Zero Unlocked and Unlocked). Attackers must simultaneously crack all three algorithms, obtain all keys, and understand their nested logic to forge valid permissions, which raises the cost of attacks to an unacceptable level from an engineering practice perspective.
[0087] 2. Enhanced resistance to reverse engineering: Because the final stored license file (equip_verify_sec) is a binary stream encrypted with ZUC, its original AES blocks and ECC signature points with fixed characteristics are completely masked. This renders automated cracking tools based on signature scanning or structural analysis ineffective, forcing attackers to perform more difficult dynamic tracking throughout the entire process.
[0088] 3. Achieves true offline strong binding: The verification closed loop established by this invention (binding hardware ID at generation → real-time reading and comparison of hardware ID at runtime) ensures the unique association between the license and the physical hardware of the target device without relying on any external server, thus blocking the path of illegal copying and dissemination from a technical principle perspective.
[0089] 4. System Robustness and Reliability: The entire verification process is completed locally, eliminating network latency and single point of failure risks. Furthermore, the layered key design (separation of pc_key and equip_key) securely separates issuance and verification permissions, adhering to the principle of least privilege in security architecture design. Even if an attacker obtains all files on the device, without the issuance private key, their attempt to crack the system will face insurmountable technical obstacles.
[0090] Example 2: Based on Embodiment 1, this embodiment provides a device binding software encryption system based on multi-layer nested encryption, which is used to implement the device binding software encryption method based on multi-layer nested encryption in Embodiment 1.
[0091] Specifically, this embodiment takes an embedded device requiring authorization as an example. A device binding software encryption system based on multi-layer nested encryption includes three software modules running in different environments: Key generator (pc_equip_key_gen): Runs on the licensed administrator's secure PC and is used to generate the system root key.
[0092] License issuer (pc_equip_verify_gen): A dedicated PC running in the production workshop, used to generate a unique license file for each device.
[0093] The license verification library (equip_verify_judge) is compiled and linked into the software of the device that needs protection, either as a static or dynamic library, and performs verification at runtime.
[0094] The core working principle of a device binding software encryption system based on multi-layered nested encryption is a phased, one-way key and permission derivation process. Its data flow strictly follows the order of "generate first, then issue, then verify," and is irreversible.
[0095] System workflow as follows Figure 4 As shown, Figure 4 The document illustrates the roles of administrator, producer, and device, as well as the interaction relationships and file streams (issue key pc_key, verification key equip_key, and device-specific password lock equip_verify_sec) between the three core modules: key generator pc_equip_key_gen, license issuer pc_equip_verify_gen, and license verification library equip_verify_judge.
[0096] The administrator, production end, and device end represent three logical roles performing software encryption operations, reflecting the separation of permissions. The issuance key `pc_key`, verification key `equip_key`, and device-specific password lock `equip_verify_sec` (device-specific license) are critical security data generated and circulated by the system, and their flow defines the system's security boundaries. The verification decision represents the core judgment logic within the license verification library; its result is either verification success or verification failure, reflecting the system's decisive output.
[0097] Figure 4 The core operation of the system is divided into three spatiotemporal stages, highlighting the unidirectional and irreversible nature of the process.
[0098] Specifically: Phase 1: Root key generation (offline preparation).
[0099] Action: The administrator executes the key generator pc_equip_key_gen.
[0100] Output: Generates a pair of cryptographically linked key files: pc_key (signing key, top secret) and equip_key (verification key, for distribution).
[0101] Relationship: This stage provides a trust anchor for the entire system. `pc_key` is the source of all subsequent signing actions, while `equip_key` is the basis for verification on the device side.
[0102] Phase Two: Issuance of License Documents (Production Stage).
[0103] Input: The target device's issuance key equip_id + the verification key pc_key generated in the previous stage.
[0104] Action: The production side executes pc_equip_verify_gen, according to... Figure 2 The process shown is a three-level nested process.
[0105] Output: Generates an equipment_verify_sec file that is strongly bound to the device's equipment_id.
[0106] Relationship: This stage combines the static key (pc_key) with the dynamic device identity (equip_id) and uses the core encryption process of this invention to generate a "device-specific password lock" (equip_verify_sec).
[0107] Phase 3: Runtime license verification (executed on the device).
[0108] Input: The device's locally stored equip_key and equip_verify_sec + the current device equip_id read in real time.
[0109] Action: The protected software calls the subject verification library, according to... Figure 3 The process shown is used for reverse decryption and comparison.
[0110] Output: Verification successful or failed.
[0111] Relationship: This stage is crucial for closed-loop verification. It uses the `equip_key` to attempt to open the "password lock" (`equip_verify_sec`) and verifies whether the "owner information" (encrypted `equip_id`) recorded in the lock matches the current device's "identity card information" (`equip_id` read in real time). Failure at any stage (incorrect key, invalid signature, ID mismatch) will result in verification failure.
[0112] This embodiment also includes: strong code obfuscation, virtual machine protection, and anti-debugging hardening of the key generator pc_equip_key_gen, the license issuer pc_equip_verify_gen, and the license verification library equip_verify_judge, significantly increasing reverse engineering costs. The verification logic of the license verification library is ported to the inside of the security chip for execution, ensuring that the core comparison process does not appear in the general operating system memory.
[0113] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any way. Other variations and modifications are possible without departing from the technical solutions described in the claims.
Claims
1. A device binding software encryption method based on multi-layer nested encryption, characterized in that, include: S1: Generate the issuance key and verification key; S2: Construct the plaintext license information and perform three-layer nested encryption on it: Encrypt the plaintext license information using AES and output the AES ciphertext and authentication label; Elliptic curve digital signature is performed on the AES ciphertext using ECC to obtain the ECC signature value; The AES ciphertext and ECC signature value are concatenated, and the concatenated data is encrypted using the ZUC stream cipher algorithm to obtain the ciphertext obfuscation. S3: Reverse decrypt the encrypted obfuscated text and verify whether the device ID in the decrypted plaintext license information matches the read real-time device ID.
2. The device binding software encryption method based on multi-layer nested encryption according to claim 1, characterized in that, S1 includes: randomly generating AES_KEY, ZUC_KEY, and ECC key pairs using a key generator; constructing a signing key structure and a verification key structure, wherein the signing key structure includes public keys ECC_PRI, AES_KEY, and ZUC_KEY, and the verification key structure includes private keys ECC_PUB, AES_KEY, and ZUC_KEY; encrypting the signing key structure using a pre-programmed master key to generate a signing key file; and encrypting the verification key structure using the master key to generate a verification key file.
3. The device binding software encryption method based on multi-layer nested encryption according to claim 1, characterized in that, S3 includes: decrypting the ciphertext obfuscation using the verification key structure .ZUC_KEY to obtain the decrypted data, and parsing out the AES ciphertext and ECC signature value; verifying the AES ciphertext and ECC signature value using the verification key structure .ECC_PUB; if the verification fails, immediately returning an error code and terminating subsequent steps; if the verification succeeds, decrypting the AES ciphertext using the verification key structure .AES_KEY to obtain the original license information plaintext; extracting the verification key field from the decrypted license information plaintext, and comparing it byte-by-byte with the read current device real-time ID; if the two are completely consistent and the current time has not exceeded the expiration time in the license information plaintext, returning the function flag bit in the license information plaintext; if the verification key is inconsistent or has expired, returning an error code.
4. A device binding software encryption method based on multi-layer nested encryption according to claim 1 or 3, characterized in that, In step S3, before performing the decryption operation, the following steps are also included: calling the verification interface of the license verification library. The library function loads the verification key and encrypted_equip_verify_sec from the device storage area by reading the current device real-time ID from the device driver in real time, and decrypts them with the pre-burned master key to obtain the verification key structure and the ciphertext obfuscation body, respectively.
5. A device binding software encryption method based on multi-layer nested encryption according to claim 1 or 2, characterized in that, Before performing multi-layer nested encryption: the verification key file is written to the non-volatile storage area of the target device, and the licensee reads the verification key of the target device through the device driver interface; The license issuer loads and decrypts the issuance key using the master key to obtain the issuance key structure.
6. A device binding software encryption method based on multi-layer nested encryption according to claim 1, 2, or 3, characterized in that, The encrypted text is used to construct a device-specific password lock structure, and the device-specific password lock structure is encrypted using a pre-programmed master key. The encrypted device-specific password lock structure is then written into the non-volatile storage area of the target device.
7. A device binding software encryption method based on multi-layer nested encryption according to claim 1, 2, or 3, characterized in that, The license information in plaintext includes the device ID, expiration time, and function flags.
8. A device binding software encryption method based on multi-layer nested encryption according to claim 7, characterized in that, The device ID includes the CPU-ID, motherboard ID, storage ID, and network card MAC address.
9. A device binding software encryption system based on multi-layer nested encryption, employing the device binding software encryption method based on multi-layer nested encryption as described in any one of claims 1-8, characterized in that, include: Key generator, generates issuance keys and verification keys; The license issuer generates a unique license file for each device based on the verification key of the target device and the issuance key generated in the previous stage, and performs three-layer nested encryption on the plaintext license information. The license verification library, either as a static or dynamic library, is compiled and linked into the software of the device that needs protection, and performs verification at runtime.
10. A device binding software encryption system based on multi-layer nested encryption according to claim 9, characterized in that, The key generator, license issuer, and license verification library are subjected to strong code obfuscation, virtual machine protection, and anti-debugging hardening; the verification logic part in the license verification library is ported to the inside of the security chip for execution.