A security authorization method based on a trusted subsystem to other subsystems

CN117131512BActive Publication Date: 2026-10-30SHENZHEN QIANKUN IOT TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202311106060.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-08-30
Publication Date
2026-10-30
Estimated Expiration
2043-08-30

AI Technical Summary

Technical Problem

[0008]冲突问题:如果在同一硬件系统上使用多个同种加密狗,可能会导致冲突问题,例如加密狗驱动程序的冲突、加密狗的识别问题等;

Benefits of technology

[0029]本发明基于可信子系统对其他子系统的安全授权方法,子系统授权后功能正常,如果未授权或授权失败,将提示系统未授权,因采用系统中必备子系统作为可信授权,授权不需要对外网授权专用服务器访问,也不会因为多个加密狗授权导致的冲突、安全、稳定性等问题;

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117131512B_ABST
    Figure CN117131512B_ABST
Patent Text Reader

Abstract

The application discloses a kind of based on the security authorization method of trusted subsystem to other subsystem, it is related to software system authorization technical field.The application first uses environment feature extraction tool in the running environment of the subsystem to be authorized to extract environment feature file;Environment feature file is sent back to company offline authorized personnel by network approach;The authorized personnel use authorization tool to calculate production authorization file with environment feature file and the product code of authorized system, version, use validity period information;Authorization file is uploaded to the specific path of the subsystem to be authorized;The environment extraction dynamic library is called to extract running environment feature data by the subsystem to be authorized.The application based on the security authorization method of trusted subsystem to other subsystem, solves the problem of multiple dongle authorization, also solves the problem of activation code or serial number decompilation cracking, also solves the problem of private network authorization.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of software system authorization technology, and in particular to a secure authorization method for other subsystems based on a trusted subsystem. Background Technology

[0002] Software encryption and licensing can ensure the legal use of software and protect the intellectual property rights of software developers. Through licensing, software developers can control the scope and method of software use, prevent unauthorized copying and distribution, and thus protect their own commercial interests.

[0003] Current licensing methods generally employ the following approaches:

[0004] ① Dongle: A dongle is a hardware device used to store and verify software license information. Software developers store the license information in the dongle, and users need to insert the dongle to use the software.

[0005] ② Activation code or serial number: Activation code or serial number is a common authorization technology. Users need to enter the activation code or serial number when installing software to verify the legality and authorization information of the software;

[0006] ③ Online authorization: Online authorization is a technology that stores authorization information on a server. Users need to connect to the server via the network to verify the authorization information.

[0007] The above authorization is effective for the independent use of a single system. However, when multiple systems that require authorization work together and each needs to be authorized separately, there are certain limitations. In particular, systems developed using languages ​​such as Java are easily decompiled and cracked by using activation codes or serial numbers for authorization, which can bypass the authorization detection logic and lead to authorization failure. When multiple software systems on a hardware system use dongles for authorization, in addition to managing the dongles, the following problems may occur.

[0008] Conflict issues: Using multiple dongles of the same type on the same hardware system may cause conflict issues, such as conflicts between dongle drivers or dongle recognition problems.

[0009] Security concerns: Using multiple identical dongles on the same hardware system may reduce system security, such as increasing the risk of the dongle being stolen or damaged.

[0010] Stability issues: Using multiple dongles of the same type on the same hardware system may affect system stability. For example, incompatibility or conflict between dongle drivers may cause system crashes or freezes.

[0011] Online authorization is not feasible for systems that need to operate on a private network; therefore, we propose a secure authorization method for other subsystems based on a trusted subsystem. Summary of the Invention

[0012] The purpose of this invention is to provide a secure authorization method for other subsystems based on a trusted subsystem, which securely authorizes other subsystems through a trusted subsystem that has been authorized using a dongle.

[0013] This invention is achieved through the following technical solution:

[0014] This invention relates to a secure authorization method for other subsystems based on a trusted subsystem, comprising the following steps:

[0015] S1: Use an environment feature extraction tool to extract environment feature files from the runtime environment of the subsystem requiring authorization;

[0016] S2: Send the environmental characteristics document back to the company's authorized personnel offline via the network;

[0017] S3: Authorized personnel use the authorization tool to calculate the production authorization document from the environmental characteristics file and the product code, version, and validity period information of the authorized system;

[0018] S4: Upload the authorization file to the specific path of the subsystem to be authorized;

[0019] S5: Authorized subsystems need to call the environment to extract dynamic libraries and extract runtime environment characteristic data;

[0020] S6: The authorized subsystem needs to send the authorization file, environmental characteristic data, model, and version to the trusted subsystem through the authorization API interface;

[0021] S7: The trusted subsystem decrypts and decodes the authorization file, and verifies the environmental characteristic data, signals, and version. If the matching values ​​match, it returns authorization success through the API interface; otherwise, it returns authorization failure.

[0022] The environmental feature extraction tool in S1 extracts hardware-related data information from the target environment in which the authorized subsystem runs and generates an environmental feature file.

[0023] The environmental feature file in S2 is a feature data file composed of unique information related to the hardware of the operating environment, calculated by a specific algorithm.

[0024] The authorization tool in S3 reads the environment feature file and the product code, version, and validity period information of the subsystem to be authorized, and generates an authorization file through encryption.

[0025] The authorization file in S4 is an authorization file generated by the authorization tool and is used to authorize the subsystem to be authorized; the subsystem to be authorized refers to the target object system to be authorized.

[0026] The S5 environment feature extraction dynamic library refers to the authorized target system that extracts runtime environment features by calling the API interface of the environment feature extraction dynamic library, ensuring consistency with the content extracted by the environment feature extraction tool; the environment feature data is composed of unique information related to the runtime environment hardware and is calculated by a specific algorithm.

[0027] The trusted subsystem in S7 is an essential subsystem in the entire system. It uses a dongle for authorization, verifies the authorization file and environmental feature data submitted by the system to be authorized, and thus completes the authorization.

[0028] The present invention has the following beneficial effects:

[0029] This invention is a secure authorization method for other subsystems based on a trusted subsystem. After authorization, the subsystem functions normally. If authorization is not granted or fails, a message will be displayed indicating that the system is not authorized. Because an essential subsystem in the system is used as a trusted authorization method, authorization does not require access to a dedicated authorization server on the external network, and there are no issues such as conflicts, security, or stability caused by authorization from multiple dongles.

[0030] Meanwhile, subsystem authorization is tied to the running hardware system, so even if the software system is copied as an image, authorization cannot be completed.

[0031] This invention is based on a secure authorization method for other subsystems by a trusted subsystem. It uses a dongle (Ukey) to authorize an essential subsystem of a system to ensure its security and trustworthiness, and registers other subsystems that need authorization to this subsystem through a defined API interface, and performs verification and authorization through this subsystem.

[0032] Furthermore, while authorizing other subsystems, it is also necessary to bind these other subsystems to the running hardware system to prevent them from being mirrored and copied.

[0033] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0034] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1This invention provides a security authorization logic flow and related object diagram for a trusted subsystem to other subsystems.

[0036] Figure 2 This is a data structure diagram of the environmental feature data of the present invention;

[0037] Figure 3 This is a flowchart illustrating the process of generating environmental feature files for this invention.

[0038] Figure 4 This is a diagram of the authorized data structure of this invention;

[0039] Figure 5 This is a flowchart for generating the authorization document for this invention;

[0040] Figure 6 This is a data structure diagram for the patent application of this invention;

[0041] Figure 7 This is a flowchart of the application process for the authorized subsystem of this invention;

[0042] Figure 8 This is a flowchart illustrating the trusted authorization process of this invention;

[0043] Figure 9 This is a flowchart illustrating the data extraction process authorized by this invention.

[0044] Figure 10 This is a flowchart of the secure authorization method for other subsystems based on a trusted subsystem according to the present invention. Detailed Implementation

[0045] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] Please refer to Figure 1 and Figure 10 As shown, the present invention provides a secure authorization method for other subsystems based on a trusted subsystem, which includes first using an environment feature extraction tool to extract an environment feature file in the operating environment of the subsystem to be authorized. The environment feature extraction tool extracts hardware-related data information in the target environment in which the subsystem to be authorized is running and generates an environment feature file.

[0047] The environmental feature file is sent back to the company's authorized personnel offline via the network. The environmental feature file is a feature data file composed of unique information related to the hardware of the operating environment and calculated by a specific algorithm.

[0048] Authorized personnel use an authorization tool to calculate and generate an authorization document from the environmental characteristics file and the product code, version, and validity period information of the authorized system. The authorization tool generates the authorization document by reading the environmental characteristics file and the product code, version, and validity period information of the subsystem to be authorized, and then encrypting it.

[0049] Upload the authorization file to a specific path of the subsystem to be authorized. The authorization file is generated by the authorization tool and is used to authorize the subsystem to be authorized. The subsystem to be authorized refers to the target object system to be authorized.

[0050] The authorized subsystem needs to call the environment extraction dynamic library to extract runtime environment feature data. The environment feature extraction dynamic library refers to the authorized target system to extract runtime environment features by calling the API interface of the environment feature extraction dynamic library, ensuring that it is consistent with the content extracted by the environment feature extraction tool. The environment feature data is composed of unique information related to the runtime environment hardware and is calculated by a specific algorithm.

[0051] The authorized subsystem must send the authorization file, environmental characteristic data, model, and version to the trusted subsystem via the authorization API interface;

[0052] The trusted subsystem decrypts and decodes the authorization file and verifies the environmental characteristic data, signals, and version. If the matching values ​​match, it returns authorization success through the API interface; otherwise, it returns authorization failure. The trusted subsystem is an essential subsystem in the entire system. It uses a dongle for authorization and verifies the authorization file and environmental characteristic data submitted by the system to be authorized, thereby completing the authorization.

[0053] This invention includes: 1. Environmental feature data extraction, content composition, and data structure:

[0054] The subsystem is deployed in a virtualized manner on the server cluster. In order to facilitate expansion and adjustment, the CPUID of the first CPU in the operating environment and the MAC address of the main communication network card are used as features.

[0055] Use the "Environment Feature Extraction Tool" to extract the CPU ID, main communication network card MAC address, and current timestamp from the operating environment of the authorized subsystem. Figure 2 The data structures shown are assembled into feature content;

[0056] The feature data structure consists of 80 bytes in total, containing ASCII codes; CPUID: occupies bytes 0-31, totaling 32 bytes, with trailing spaces if necessary; MAC: occupies bytes 32-55, totaling 24 bytes, in the format AA:BB:CC:DD:EE:FF:00, with uppercase letters and colons, with trailing spaces if necessary; Timestamp: occupies bytes 56-79, totaling 24 bytes, containing the feature extraction timestamp, converted to a decimal unsigned integer string, such as the timestamp "1686489719" for the current time June 10, 2023, 11:21:59, with trailing spaces if necessary.

[0057] 2. Environmental characteristics file content, data structure, and generation method

[0058] The original content and data structure of the "Environmental Characteristics File" are consistent with the content and data of the "Environmental Characteristics Data," see [link / reference]. Figure 2 Feature data structure.

[0059] File generation algorithm:

[0060] 1) The MD5 algorithm is used to sign the 80-byte "environmental feature data" to obtain a 16-byte MD5 digest;

[0061] 2) Combine the 80-byte "environmental feature data" and the 16-byte content summary into a new 96-byte data, with the environmental feature data first and the summary second;

[0062] 3) The 96 bytes of new data are encrypted using the 3DES encryption and decryption algorithm to obtain a ciphertext;

[0063] 4) Then use the base64 encoding algorithm to encode the content and write it into a text file to generate an environment feature file.

[0064] Algorithm flowchart as follows Figure 3 As shown.

[0065] 3. Authorization file content, data structure, and generation method

[0066] The license file is obtained by processing the "environment signature file" using an authorization tool. The processing algorithm is as follows:

[0067] 1) Decode the "environment feature file" using base64 to obtain 96 bytes of data. If decoding fails, indicate that generation failed.

[0068] 2) The 96-byte content is decrypted using the 3DES encryption and decryption algorithm to obtain 96 bytes of decrypted data.

[0069] 3) Compare the digest information obtained by MD5 hashing the first 80 bytes of the decrypted data with the last 16 bytes of the decrypted data. If the contents are different, indicate that the generation failed.

[0070] 4) Enter the 8-byte product code, 16-byte version code, and 24-byte license validity period on the tool interface. Add the first 80 bytes of the decrypted data and the current 24-byte timestamp to obtain 152 bytes of new license data. The data structure format is as follows: Figure 4 As shown in the “Authorization Data Structure”.

[0071] Among them, Product id: occupies 0 to 7 bytes, with a total length of 8 bytes. It is the product code. If it is not long enough, add a space "" at the end.

[0072] Version: Occupies 8-23 bytes, total length 16 bytes, product version number, add spaces "" at the end if necessary;

[0073] Period of validity: occupies 24 to 47 bytes, with a total length of 24 bytes. The timestamp format indicates the last valid time of the authorization. When the content is 24 bytes of "-", it indicates a permanent authorization.

[0074] CPU ID: Occupies 48-79 bytes, total length 32 bytes. If insufficient, add spaces "" at the end.

[0075] MAC: Occupies 80-103 bytes, with a total length of 24 bytes. The format is AA:BB:CC:DD:EE:FF:00, with uppercase letters and colons ":". If the number of bytes is insufficient, add spaces "" at the end.

[0076] Timestamp: Occupies 104-127 bytes, with a total length of 24 bytes. The content is the feature extraction timestamp, converted into a decimal unsigned integer string, such as the timestamp "1686489719" for the current time June 10, 2023, 11:21:59. If the timestamp is insufficient, add spaces "" at the end.

[0077] current timestamp: Occupies 128-151 bytes, with a total length of 24 bytes. The content is the feature extraction timestamp, converted into a decimal unsigned integer string, such as the timestamp "1686489719" for the current time June 10, 2023, 11:21:59. If it is not enough, add a space " at the end.

[0078] 1) The 128-byte "authorized data" is signed using the MD5 algorithm to obtain a 16-byte MD5 digest;

[0079] 2) Combine the 128 bytes of "authorization data" with the 16 bytes of MD5 digest information to obtain a new 144 bytes of data;

[0080] 3) Encrypt the 144 bytes of new data using the public key corresponding to Ukey to obtain the encrypted data content;

[0081] 4) Encode the encrypted data using base64 and write it to a file to obtain the authorization file.

[0082] Authorization document production process as follows Figure 5 As shown.

[0083] 4. Authorization application required for subsystems.

[0084] Upload the authorization file to the specified path of the subsystem to be authorized. The authorization application process is as follows:

[0085] 1) The "Authorization Subsystem" reads the content and length of the authorization file from the specified path. If reading fails, an authorization failure message will be displayed.

[0086] 2) The "Authorized Subsystem" calls the "Environment Feature Extraction Dynamic Library" to extract runtime environment data;

[0087] 3) Assemble the authorization data; the data structure format is as follows: Figure 6 As shown.

[0088] Among them, Product id: occupies 0 to 7 bytes, with a total length of 8 bytes. It is the product code. If it is not long enough, add a space "" at the end.

[0089] Version: Occupies 8-23 bytes, total length 16 bytes, product version number, add spaces "" at the end if necessary;

[0090] CPU ID: Occupies 48-79 bytes, total length 32 bytes, padding with spaces "" at the end if necessary;

[0091] MAC: Occupies 80-103 bytes, with a total length of 24 bytes. The format is AA:BB:CC:DD:EE:FF:00, with uppercase letters and colons ":". If the number of bytes is insufficient, add spaces "" at the end.

[0092] authorized encrypted content: The content of the authorization file.

[0093] 4) Submit authorized data to the trusted subsystem for verification through the authorization verification structure. If the verification passes, the system will run normally. If the verification fails, the system will indicate that the authorization failed.

[0094] The authorization subsystem application process is as follows: Figure 7 As shown.

[0095] 5. Trusted Subsystem Authorization Verification

[0096] Upon receiving an authorization verification request, the trusted subsystem verifies and authorizes the request according to the following process:

[0097] 1) Parse the authorization request data structure and extract product id, version, CPU ID, MAC, and authorizedencrypted content;

[0098] 2) Use the "authorized encrypted content data decoding" process to extract the Product ID, Version, period of validity, CPU ID, and MAC information from the authorized encrypted data. If extraction fails, return an authorization failure message.

[0099] 3) Compare the data structure of the authorization application with the product id, version, CPU ID, and MAC extracted by the "authorized encrypted content data decoding and data extraction" process. If they are inconsistent, return authorization failure.

[0100] 4) Compare the period of validity with the current time to see if it has expired. If it has expired, return an authorization failure message.

[0101] 5) Authorization successful.

[0102] Trusted authorization verification process as follows Figure 8 As shown.

[0103] 6. Decoding and extracting authorized encrypted content data

[0104] Use the following procedure to decode and verify the "authorized encrypted content" to prevent tampering.

[0105] 1) Decode "authorized encrypted content" using base64; if decoding fails, return an extraction failure message.

[0106] 2) Use the Ukey private key to decrypt the base64 decoded content, resulting in 144 bytes of decrypted content;

[0107] 3) Perform an MD5 hash on the first 128 bytes of the 144-byte data, and compare the resulting 16-byte hash with the last 16 bytes. If the hash does not match, return an extraction failure message.

[0108] 4) Returns the Product ID, Version, Period of Validity, CPU ID, and MAC data extracted from the first 128 bytes.

[0109] Authorized data extraction process as follows Figure 9 As shown.

[0110] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0111] The preferred embodiments of the present invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to any specific implementation. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention. The invention is limited only by the claims and their full scope and equivalents.

Claims

1. A secure authorization method for other subsystems based on a trusted subsystem, characterized in that, Includes the following steps: S1: Use an environment feature extraction tool to extract environment feature files from the runtime environment of the subsystem requiring authorization; S2: Send the environmental characteristics document back to the company's authorized personnel offline via the network; S3: Authorized personnel use the authorization tool to calculate the production authorization document from the environmental characteristics file and the product code, version, and validity period information of the authorized system; S4: Upload the authorization file to the specific path of the subsystem to be authorized; S5: Authorized subsystems need to call the environment to extract dynamic libraries and extract runtime environment characteristic data; S6: The authorized subsystem needs to send the authorization file, environmental characteristic data, model, and version to the trusted subsystem through the authorization API interface; S7: The trusted subsystem decrypts and decodes the authorization file and verifies the environmental characteristic data, signals, and version. If the matching values ​​match, it returns authorization success through the API interface; otherwise, it returns authorization failure.

2. The secure authorization method for other subsystems based on a trusted subsystem according to claim 1, characterized in that, The environmental feature extraction tool in S1 extracts hardware-related data information from the target environment in which the authorized subsystem runs and generates an environmental feature file.

3. The secure authorization method for other subsystems based on a trusted subsystem according to claim 1, characterized in that, The environmental feature file in S2 is a feature data file composed of unique information related to the hardware of the operating environment, calculated by a specific algorithm.

4. The secure authorization method for other subsystems based on a trusted subsystem according to claim 1, characterized in that, The authorization tool in S3 reads the environment feature file and the product code, version, and validity period information of the subsystem to be authorized, and generates an authorization file through encryption.

5. A secure authorization method for other subsystems based on a trusted subsystem, as described in claim 1, characterized in that, The authorization file in S4 is an authorization file generated by the authorization tool and is used to authorize the subsystems that need to be authorized.

6. The secure authorization method for other subsystems based on a trusted subsystem according to claim 1, characterized in that, The subsystem to be authorized in S4 refers to the target object system to be authorized.

7. A secure authorization method for other subsystems based on a trusted subsystem, as described in claim 1, characterized in that, The S5 environment feature extraction dynamic library refers to the system that is authorized to extract runtime environment features by calling the API interface of the environment feature extraction dynamic library, ensuring that the content extracted by the environment feature extraction tool is consistent with the content extracted by the environment feature extraction tool.

8. A secure authorization method for other subsystems based on a trusted subsystem, as described in claim 1, characterized in that, The environmental feature data in S5 is composed of unique information related to the hardware of the operating environment and is calculated by a specific algorithm.

9. A secure authorization method for other subsystems based on a trusted subsystem, as described in claim 1, characterized in that, The trusted subsystem in S7 is an essential subsystem in the entire system. It uses a dongle for authorization, verifies the authorization file and environmental feature data submitted by the system to be authorized, and thus completes the authorization.

Citation Information

Patent Citations

  • Tracing subsystem of digital copyright management proxy system and working method thereof

    CN101458745A

  • Authorization authentication method, device and system

    CN101997684A