Equipment offline authorization verification method and system

Abstract

The invention is suitable for the technical field of software authorization, and provides an equipment offline authorization verification method and system.The method comprises the steps that an authorization server receives authorization request data in an offline mode, a server-side private key packaged in a local compiled code is used for signing a Hash digest value of the authorization request data, and the signature is sent to the server-side private key; packaging and encrypting the authorization request data and the digital signature to generate an offline authorization certificate; a current client device uses an upper-layer application program written by a high-level programming language, calls a security verification module packaged in a local compiled code through a cross-language calling interface, decrypts an off-line authorization certificate through the security verification module, and verifies the signature through a client public key. And verifying whether the authorization request data is matched with the acquired equipment information and system time of the current client equipment, and judging that authorization activation is successful only when signature verification is passed and verification is matched currently. According to the method and the device, the problem of low authorization verification security of the existing software in an offline environment is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software authorization, in particular to a device offline authorization verification method and system. BACKGROUND

[0002] Software authorization management is a key link in commercial software development, which aims to protect the intellectual property rights of software developers and realize flexible business charging mode. At present, the mainstream software authorization technologies mainly include the following:

[0003] 1. Online activation based on cloud service: This method requires the software to be connected to the developer's server during installation or running, and the validity of the authorization information is verified in real time through the network. The disadvantage is that it depends heavily on the Internet connection and cannot be applied to physically isolated intranet, offline or poor network environment, limiting the application scope of the software.

[0004] 2. Hardware encryption lock (USB Dongle): This method stores authorization certificates in physical hardware devices, and the software needs to detect the existence of the hardware when running. This method is highly secure, but the disadvantages are also obvious: high hardware cost, increasing the overall price of the software; users need to store physical devices, which may be lost or damaged; for large-scale deployment or virtualization environment, the management and distribution of hardware locks are extremely inconvenient.

[0005] 3. Local license file: This method realizes activation by storing a license file containing authorization information locally. However, the traditional local license scheme has significant security flaws. First, many schemes only use simple string matching or conventional encryption algorithms (such as AES, RSA) for protection. If the authorization verification logic is implemented in a high-level language (such as Java, C#), its compiled intermediate code can be easily reverse analyzed by reverse engineering tools, resulting in the leakage of encryption keys and verification logic, and the authorization certificate can be easily forged or cracked. Second, for authorization with time limit (such as trial version, annual subscription version), existing offline authorization schemes mostly rely on the local system time of the client device to determine whether it has expired. However, this method is extremely insecure, as users can simply roll back the system time to within the authorized period to achieve permanent use of the software, making the authorization period meaningless and causing significant commercial losses to software developers. Furthermore, many encryption implementations rely on internationally recognized encryption algorithms (such as RSA, AES) or widely used third-party open source libraries (such as OpenSSL). These algorithms may have known attack methods, and relying on third-party libraries may introduce potential security vulnerabilities or technical dependency risks.

[0006] In summary, the prior art has obvious deficiencies in realizing a software authorization scheme that can simultaneously meet high security, complete offline, and tamper-proof time control. SUMMARY

[0007] Therefore, the present application aims to provide a device offline authorization verification method and system to fundamentally solve the problem of low security of existing software authorization verification in offline environment.

[0008] According to an embodiment of the present application, a device offline authorization verification method comprises:

[0009] The authorization server receives authorization request data provided by the client device in an offline manner, the authorization request data containing device information and authorization period, uses a server-side private key pre-generated and encapsulated in a local compiled code to sign a hash digest value obtained by performing a hash value calculation on the authorization request data to obtain a digital signature, and encapsulates and encrypts the authorization request data and the digital signature to generate an encrypted offline authorization certificate;

[0010] The upper application program written by the current client device using a high-level programming language calls a pre-set security verification module encapsulated in a local compiled code through a cross-language calling interface, decrypts the imported encrypted offline authorization certificate using the security verification module, performs signature verification on the offline authorization certificate through a pre-set client-side public key paired with the server-side private key, checks whether the authorization request data of the offline authorization certificate matches the obtained device information and system time of the current client device, and only when the signature verification passes and the check matches, determines that the authorization activation is successful.

[0011] In addition, according to the device offline authorization verification method of the above-mentioned embodiments of the present application, the following additional technical features can also be provided:

[0012] Further, the step of encapsulating and encrypting the authorization request data and the digital signature to generate an encrypted offline authorization certificate comprises:

[0013] Based on a pre-set system master key and the device information in the authorization request data, a symmetric encryption key uniquely bound to the client device is generated through a key derivation algorithm;

[0014] The symmetric encryption key is used to perform symmetric encryption on the encapsulated data containing the authorization request data and the digital signature through the SM4 symmetric encryption algorithm to generate an encrypted offline authorization certificate.

[0015] Further, the step of decrypting the imported encrypted offline authorization certificate using the security verification module comprises:

[0016] collecting device information of the current client device;

[0017] reconstructing the symmetric encryption key dynamically based on the system master key preset same as the authorization server and the obtained device information, through the same key derivation algorithm;

[0018] using the reconstructed symmetric encryption key, performing symmetric decryption on the encrypted offline authorization certificate through the national SM4 symmetric decryption algorithm.

[0019] Further, the step of checking whether the authorization request data of the offline authorization certificate matches the obtained device information of the current client device and the system time includes:

[0020] parsing the device information and the authorization period from the authorization request data in the decrypted offline authorization certificate;

[0021] Collecting real-time device information of the current client device and comparing it with the parsed device information to complete the device matching check;

[0022] Obtaining the local system time of the current client device and obtaining a network reference time returned from an external network time source independent of the current client device;

[0023] When the deviation between the local system time and the network reference time is within a preset threshold range, determine whether the local system time is within the start and end time range defined by the authorization period to complete the system time matching check.

[0024] Further, the authorization request data further includes a function authorization set for defining software available functions and a usage quota set for metering the number of times of using specific functions;

[0025] The step of determining authorization activation success further includes:

[0026] According to the function authorization set, opening or limiting specific function modules of the current client device;

[0027] According to the usage quota set, metering and limiting the number of times of using specific functions in the current client device.

[0028] Further, the step of signing the hash digest value obtained by hashing the authorization request data to obtain a digital signature includes:

[0029] Using the national SM3 algorithm to perform hash operation on the authorization request data to generate a hash digest;

[0030] The hash digest is signed to generate a digital signature by using a server-side private key pre-generated in a local compiled code and a national SM2 algorithm.

[0031] Further, the step of verifying the offline authorization certificate by using a pre-configured client-side public key paired with the server-side private key comprises:

[0032] Separating the authorization request data and the digital signature from the decrypted offline authorization certificate;

[0033] Calculating a hash value of the separated authorization request data by using the same national SM3 algorithm as used by the authorization server to generate the hash digest, to obtain a locally calculated hash digest value;

[0034] Decrypting the separated digital signature by using the pre-configured client-side public key and the national SM2 algorithm, to restore the original hash digest value generated by the authorization server;

[0035] Comparing the locally calculated hash digest value with the original hash digest value, and determining that the verification is passed only when the two values are completely consistent.

[0036] Further, the step of decrypting the separated digital signature by using the pre-configured client-side public key and the national SM2 algorithm comprises:

[0037] Calculating a hash value of the pre-configured client-side public key by using the same national SM3 algorithm as used by the authorization server to generate the hash digest;

[0038] Comparing the hash value calculation result with a pre-stored public key standard hash value hardcoded in the security verification module;

[0039] Decrypting the separated digital signature by using the pre-configured client-side public key and the national SM2 algorithm only when the comparison result is completely consistent.

[0040] Further, after the step of determining that the authorization activation is successful, the method further comprises:

[0041] The current client device automatically repeats the step of checking whether the authorization request data of the offline authorization certificate and the obtained device information and system time of the current client device match, at a preset time interval or when a specific event is triggered.

[0042] Another embodiment of the present application also aims to provide a device offline authorization verification system, which comprises:

[0043] An authorization server configured to receive, in an offline manner, authorization request data provided by a client device, the authorization request data containing device information and an authorization period, sign a hash digest value calculated from the authorization request data using a server-side private key pre-generated and encapsulated in native compiled code to obtain a digital signature, and encapsulate and encrypt the authorization request data and the digital signature to generate an encrypted offline authorization certificate;

[0044] A current client device configured to use an upper-layer application program written in a high-level programming language to call a pre-configured security verification module encapsulated in native compiled code through a cross-language calling interface, decrypt the imported encrypted offline authorization certificate using the security verification module, verify the offline authorization certificate using a client-side public key pre-configured to be paired with the server-side private key, and check whether the authorization request data of the offline authorization certificate matches the obtained device information and system time of the current client device, and only when the verification passes and the check matches, determine that the authorization activation is successful.

[0045] The device offline authorization verification method provided by the embodiment of the application realizes layered security isolation between the business logic easy to be decompiled and the core cryptographic operation difficult to be reverse engineered by calling the security verification module encapsulated in the local compiled code through the upper application program written in a high-level programming language, fundamentally eliminates the risk that the core verification logic, the key and the algorithm are cracked or bypassed, and solves the technical problems of low security and easy cracking of the traditional pure high-level language authorization scheme; the strong binding of the encrypted offline authorization certificate and the specific hardware is realized by deriving the symmetric encryption key uniquely bound with the device based on the system master key and the client device information, the authorization certificate is ensured to be invalid on any unauthorized device, and the problems of unauthorized copying and abuse of authorization are effectively eliminated; a high-trust double-signal source time verification mechanism is established by cross-comparing the local system time of the client device with the network reference time obtained from an independent external network time source, the attack behavior of bypassing the authorization period by maliciously modifying the local system time can be effectively identified and rejected; the continuity and silence monitoring of the authorization state in the entire software life cycle is realized by automatically and repeatedly executing the complete authorization verification process at a preset interval or when a specific event is triggered in the background, and any environmental change or tampering behavior that causes the authorization to be invalid after activation can be ensured to be discovered in time; the self-checking ability of the core credentials in the security verification module is realized by performing hash calculation on the preset client public key before use and comparing it with the standard hash value hardcoded, the high-level attack of replacing the public key by tampering with the binary file of the module can be resisted, and the anti-cracking barrier of the system is further reinforced; the flexible and configurable fine-grained authorization control mode is realized by parsing and enforcing the function authorization set and the usage quota set contained in the authorization request data, powerful technical support is provided for diversified business strategies such as hierarchical functions, subscription services and pay-per-use, and the problem that the traditional authorization scheme mode is single and cannot adapt to complex business needs is solved. The problem of low security of existing software in offline environment is solved. BRIEF DESCRIPTION OF DRAWINGS

[0046] Figure 1 The flowchart of the device offline authorization verification method in the first embodiment of the application is shown in the figure.

[0047] Figure 2 The structure diagram of the device offline authorization verification system in the second embodiment of the application is shown in the figure.

[0048] The following specific embodiments will further illustrate the application in conjunction with the above figures. DETAILED DESCRIPTION

[0049] For the purpose of clarity, the present application will be described in greater detail below with reference to the accompanying drawings. The embodiments of the present application are shown in the drawings. However, the present application can be realized in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete. Embodiments of the present application are illustrated by way of example and not limitation in the figures of the accompanying drawings in which:

[0050] It is to be understood that where an element is referred to as being "on" another element, it can be directly on the other element or intervening elements can also be present. Where an element is referred to as being "connected", "coupled", "attached" or "linked" to another element, it can be directly connected, coupled, attached or linked to the other element or intervening elements can also be present. The terms "vertical", "horizontal", "left", "right" and similar expressions as used herein are for illustration only and do not limit the scope of the present application.

[0051] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0052] Embodiment one

[0053] Please refer to Figure 1 , which shows the device offline authorization verification method in the first embodiment of the present application. For the purpose of illustration, only the parts related to the embodiments of the present application are shown. The device offline authorization verification method provided by the embodiments of the present application includes:

[0054] In step S10, the authorization server receives the authorization request data provided by the client device in an offline manner, which contains device information and authorization period. The authorization server uses the server-side private key encapsulated in the locally compiled code to sign the hash digest value obtained by hashing the authorization request data to obtain a digital signature, and then encapsulates and encrypts the authorization request data and the digital signature to generate an encrypted offline authorization certificate.

[0055] In one embodiment of the present application, the method is applied to a device offline authorization verification system, which includes an authorization server and a client device. The authorization server is usually deployed in the internal network of the developer or the authorization management party and is responsible for generating and issuing offline authorization certificates. The client device refers to the end-user device that needs to be authorized to normally use specific software, such as industrial personal computers, special servers, embedded devices, etc.

[0056] Wherein, its authorization server core is configured as a native national cryptographic algorithm module encapsulated in a locally compiled code (for example, written in C / C++ language and compiled into a dynamic link library or an executable file). The module securely stores a server-side private key in a pair of asymmetric keys inside. The authorization server also includes an upper-layer business management system for receiving authorization request data from the client and interacting with the underlying national cryptographic algorithm module through a cross-language calling interface (such as JNI, P / Invoke) to perform signature and encryption operations, and finally generate an encrypted offline authorization certificate.

[0057] First, the authorization server is deployed in a secure internal network environment isolated from the public network, and its core is a native national cryptographic algorithm module encapsulated in a locally compiled code. The national cryptographic algorithm module is developed using low-level compiled languages such as C / C++ and compiled into a local dynamic link library (DLL / SO) to ensure that its internal logic and key storage are not decompiled. When the national cryptographic algorithm module is first initialized, a globally unique pair of national SM2 asymmetric keys is generated, and the server-side private key is securely stored in the private memory area of the national cryptographic algorithm module or a strictly access-controlled hardware security national cryptographic algorithm module (HSM), which is completely transparent to the upper-layer business application and cannot be directly accessed.

[0058] Then, the entire offline authorization certificate generation process starts. When an operator (such as a customer service or sales staff) receives authorization request data from the end user through a secure channel (such as encrypted email or internal ticket system), the process officially begins. The authorization request data is usually a structured text string, such as a JSON object, whose content directly reflects the unique identity of the client device and the user's purchased authorization scope, for example: {"deviceInfo":"A1B2C3D4E5F6-XYZ123-CPU789","startDate":"2024-01-01T00:00:00Z","endDate":"2025-01-01T00:00:00Z"} The operator pastes or uploads this complete string to a dedicated management interface of the upper-layer business application of the authorization server and clicks the "Generate Certificate" button.

[0059] Further, after the upper-layer business application receives the string, the complete authorization request data is called as a parameter through a cross-language calling interface (for example, JNI of Java) to call the underlying native national encryption algorithm module. After the national encryption algorithm module receives the data, it first performs double processing of data integrity digest and source authenticity signature. The step of signing the hash digest value obtained by calculating the hash value of the authorization request data using the server-side private key encapsulated in the locally compiled code to obtain a digital signature includes:

[0060] The national encryption SM3 algorithm is used to perform hash operation on the authorization request data to generate a hash digest;

[0061] The server-side private key encapsulated in the locally compiled code and the national encryption SM2 algorithm are used to sign the hash digest to generate a digital signature.

[0062] Specifically, the national encryption algorithm module first calls the national encryption SM3 cryptographic hash algorithm implemented internally to perform hash operation on the entire authorization request data string. This process is like taking a unique fingerprint photo of this data to generate a 256-bit hash digest value. Then, the national encryption algorithm module takes the server-side private key from its secure storage area and calls the national encryption SM2 digital signature algorithm implemented internally to perform asymmetric encryption operation on the hash digest value just generated. This process produces a digital signature that is strongly bound to the original data content and the server private key, which directly proves that the authorization request data is confirmed by the server and has not been tampered with.

[0063] Further, after the signature is completed, the national encryption algorithm module performs the final processing of device binding and encapsulated encryption to generate the final certificate file. The step of encapsulating and encrypting the authorization request data and the digital signature to generate an encrypted offline authorization certificate includes:

[0064] Based on a preset system master key and device information in the authorization request data, a symmetric encryption key uniquely bound to the client device is generated through a key derivation algorithm;

[0065] The encapsulated data containing the authorization request data and the digital signature are symmetrically encrypted through the national encryption SM4 symmetric encryption algorithm using the generated symmetric encryption key to generate an encrypted offline authorization certificate.

[0066] Specifically, the national secret algorithm module first encapsulates the original, plaintext authorization request data and the just-generated digital signature into a temporary binary data packet. Then, in order to achieve strong binding of the certificate to a specific device, the national secret algorithm module does not use a fixed key for encryption, but performs a dynamic, device-specific key derivation process. The national secret algorithm module takes out a preset, globally unique system master key (a high-strength secret string) from the inside, and extracts the key device information field (deviceInfo) from the authorization request data. The national secret algorithm module uses a standard key derivation algorithm (KDF) to mix the system master key and the device information as two inputs, and derives a unique 128-bit symmetric encryption key that belongs to the device through mathematical operations. Finally, the national secret algorithm module uses the dynamically derived symmetric key and the internally implemented national secret SM4 symmetric encryption algorithm to perform high-strength symmetric encryption on the entire temporary binary data packet. The output of this encryption process is a final, fully encrypted, device-bound encrypted offline authorization certificate, which is usually saved as a binary file (e.g. license.dat) and delivered to the end user by the operator in an offline manner.

[0067] In step S20, the upper application program written in a high-level programming language calls a preset security verification module encapsulated in the native compiled code through a cross-language calling interface. After the security verification module decrypts the imported encrypted offline authorization certificate, the offline authorization certificate is verified by the preset client public key paired with the server private key. The authorization request data of the offline authorization certificate is checked for matching with the obtained device information and system time of the current client device. Only when the verification passes and the check matches, it is determined that the authorization activation is successful.

[0068] In an embodiment of the present application, first, the authorization verification mechanism in the embodiment of the present application is embedded in the main program of the software on the current client device of the end user. The mechanism works cooperatively by two parts: an upper application program written in a high-level programming language (such as Java), which is responsible for displaying the activation interface, processing file I / O, and other routine tasks; and a security verification module encapsulated in the native compiled code, which is a core component written in C / C++ language and compiled as a native dynamic link library (DLL / SO), and internally solidifies all key cryptography algorithms, a preset client public key, and a system master key, and is a functionally clear black box to the upper application. When the user selects and imports the encrypted offline authorization certificate file obtained from the service provider through the activation interface of the upper application, the entire verification process starts.

[0069] Then, the upper-layer application reads the complete binary data stream of the certificate file, and calls a predefined function in the security verification module through a cross-language calling interface (for example, JNI of Java) with the data stream as a parameter. Further, after receiving the encrypted certificate data, the security verification module first performs device binding verification and dynamic key reconstruction decryption. The step of decrypting the imported encrypted offline authorization certificate by the security verification module includes:

[0070] collecting device information of the current client device;

[0071] based on a system master key preset same as the authorization server and the obtained device information, a symmetric encryption key is dynamically reconstructed through the same key derivation algorithm;

[0072] using the reconstructed symmetric encryption key, the encrypted offline authorization certificate is symmetrically decrypted through the national standard SM4 symmetric decryption algorithm.

[0073] Specifically, the security verification module performs real-time environment fingerprint collection. The security verification module does not rely on any device information passed by the upper-layer application, but actively and directly collects the device information of the current client device by calling the underlying API functions of the operating system. Specifically, the security verification module concurrently obtains a series of relatively stable and difficult-to-fake hardware identifiers, such as the MAC address of the network card, the serial number of the motherboard, the unique ID of the CPU, and the volume serial number of the system disk. In order to enhance the uniqueness and tamper resistance, the security verification module does not directly use these original values, but splices them in a fixed and predefined order to form a long string, and then calls the national standard SM3 cryptographic hash algorithm implemented internally to perform a hash operation on the string, and finally generates a unique and fixed-length device fingerprint. This fingerprint is the device information in the current environment.

[0074] Further, after obtaining the real-time device information, the security verification module initiates a dynamic and instant key reconstruction process. The core of this process is reconstruction rather than reading. There is no decryption key that can be directly used in the local storage of the security verification module. Specifically, the security verification module loads a preset system master key, which is identical to that of the authorized server side, from an internal read-only data segment that has been subjected to obfuscation and encryption processing into its private memory. Then, it calls an internally implemented key derivation algorithm (KDF), which is a standard and public cryptography function, such as a key derivation function based on HMAC (HKDF). The security verification module inputs the just-loaded system master key and the real-time collected and calculated device information (device fingerprint) into the KDF algorithm for operation. After a series of complex hash, expansion, and extraction operations, the KDF algorithm outputs a 128-bit symmetric encryption key that is specific to the current device. This process is completely dynamically completed in memory, and the reconstructed key has a very short life cycle and is only used for this decryption operation.

[0075] Finally, after the key is successfully reconstructed in the memory, the security verification module performs the final symmetric decryption operation. It uses the just-reconstructed symmetric encryption key as the decryption key and calls the internally implemented SM4 symmetric decryption algorithm to decrypt the imported binary data of the complete encrypted offline authorization certificate. If the current device is identical to the device specified during authorization, the real-time collected device information will be identical to the device information used by the authorization server side at that time, thereby causing the symmetric key reconstructed by the client to be identical to the symmetric key used by the authorization server side during encryption, and the decryption can be successful, restoring the internal encapsulated plaintext data packet containing the original authorization request data and digital signature. Conversely, if the devices do not match, the reconstructed key will be incorrect, and the SM4 decryption algorithm will directly report an error due to data padding error or check failure, thereby effectively preventing the certificate from being used on an unauthorized device.

[0076] Further, after the security verification module successfully decrypts the offline authorization certificate and loads the internal encapsulated plaintext data packet into the memory, the entire verification process immediately enters the signature verification stage. The core task of this stage is to accurately verify whether the content of the offline authorization certificate is complete and tamper-free, and whether its source is indeed the legal authorization server. The above-mentioned step of verifying the offline authorization certificate by the preset client public key paired with the server side private key includes:

[0077] Separating the authorization request data and the digital signature from the decrypted offline authorization certificate;

[0078] The separated authorization request data is calculated by using the same SM3 algorithm as the authorization server to generate the hash digest value, to obtain the locally calculated hash digest value;

[0079] The separated digital signature is decrypted by using the preset client public key and SM2 algorithm to restore the original hash digest value generated by the authorization server;

[0080] The locally calculated hash digest value is compared with the original hash digest value, and only when the two values are completely consistent, the signature verification is determined to be passed.

[0081] Specifically, the security verification module accurately separates two key parts from the decrypted offline authorization certificate according to the pre-defined data structure format: one part is the original authorization request data string containing device information and authorization period and other authorization details; the other part is the compact binary digital signature generated by the authorization server. After separation, in order to generate a local sample for comparison, the security verification module calls its internally implemented SM3 algorithm, which is the same as the algorithm used by the authorization server to generate the hash digest value, to perform a new and independent hash value calculation on the just separated authorization request data string. This process compresses the entire authorization request data into a unique 256-bit locally calculated hash digest value.

[0082] Further, while generating the local sample, the security verification module starts to extract the official sample of the authorization server from the digital signature. Specifically, the security verification module loads the preset client public key from an internally obfuscated and encrypted read-only data segment, where the client public key is uniquely paired with the server private key used for signing by the authorization server. Then, the security verification module calls its internally implemented SM2 signature verification algorithm to decrypt the previously separated digital signature using the preset client public key and SM2 algorithm. Since the essence of the digital signature is the encryption result of the original hash digest value by the server private key, using the paired client public key for decryption can accurately restore the original hash digest value generated by the authorization server at that time. This restored value is the required official sample.

[0083] Finally, after both the local sample and the official sample are ready, the security verification module performs the final authoritative comparison verdict. The security verification module compares the locally computed hash digest value with the original hash digest value recovered from the digital signature. Due to the avalanche effect of the hash algorithm (any tiny input difference will lead to a completely different output result), the two values must be exactly the same to prove that the original authorized request data has not been tampered with during the entire process from server generation to client verification. Only when they are exactly the same, the security verification module will determine that the signature verification passes and allow the verification process to continue to the next step. If there is any difference in the comparison result, the security verification module will immediately interrupt the entire verification process and return an error code to the upper layer application indicating that the certificate is tampered or invalid.

[0084] Further, before performing the formal signature verification, in order to ensure that the public key pre-installed in the security verification module itself is not tampered with, a public key self-check is performed, and the above step of decrypting the separated digital signature using the pre-installed client public key and the SM2 algorithm of the national cryptography includes:

[0085] Using the same SM3 algorithm of the national cryptography as used when generating the hash digest value by the authorized server, the hash value of the pre-installed client public key is calculated;

[0086] The hash value calculation result is compared with the pre-stored standard hash value of the public key hardcoded in the security verification module;

[0087] Only when the comparison result is exactly the same, the separated digital signature is decrypted using the pre-installed client public key and the SM2 algorithm of the national cryptography.

[0088] Specifically, the security verification module performs instant generation of the public key fingerprint. The security verification module loads the complete binary representation of the pre-installed client public key from a confused and encrypted read-only data segment in its internal. This public key itself is a specific data that defines elliptic curve parameters and public key points. Then, the security verification module calls its internal implementation of the same SM3 algorithm of the national cryptography as used when generating the hash digest value by the authorized server, to perform a hash value calculation on this complete client public key binary data just loaded into memory. This process compresses the long public key data into a unique 256-bit hash value, which can be regarded as a unique and unforgeable digital fingerprint of the public key.

[0089] Further, after generating the instant digital fingerprint of the public key, the security verification module starts the comparison with the official standard template. The security verification module reads a pre-stored public key standard hash value, which is hardcoded in the security verification module, from another, usually physically isolated, more covert location of the code segment of the security verification module. This standard hash value is calculated by the developer in an absolutely secure environment before the security verification module is compiled out of the factory, using the exact same SM3 algorithm on the original, correct client public key, and is written directly into the code as a constant. Then, the security verification module compares the just calculated instant public key hash value with this hardcoded standard hash value bit by bit.

[0090] Finally, only under the most stringent conditions, the signature verification operation will be approved to be executed. Only when the comparison result of the instant calculated hash value and the hardcoded standard hash value is completely consistent, the security verification module confirms that the client public key loaded in the current memory is real, complete and has not been tampered with in any way. At this time, the security verification module will continue to perform the subsequent signature verification process, i.e. using this self-verified, trusted pre-set client public key and the SM2 algorithm of the national secret, to decrypt the digital signature separated out previously (signature verification operation). If there is any difference in the comparison result, the security verification module will immediately determine that the environment has been destroyed and the public key is not trustworthy, thereby refusing to perform the signature verification operation and directly interrupting the entire authorization verification process, returning a serious security error code to the upper layer application.

[0091] Further, after the signature verification is also successfully passed, the security verification module performs the final authorization compliance check, and the step of checking whether the authorization request data of the offline authorization certificate and the obtained device information of the current client device and the system time match includes:

[0092] parsing the device information and the authorization period in the authorization request data from the decrypted offline authorization certificate;

[0093] collecting real-time device information of the current client device, and comparing the real-time device information with the parsed device information to complete the device matching check;

[0094] obtaining a local system time of the current client device, and obtaining a network reference time returned from an external network time source independent of the current client device;

[0095] when the deviation between the local system time and the network reference time is within a preset threshold range, determining whether the local system time is within a start and end time range defined by the authorization period to complete the system time matching check.

[0096] In particular, the security verification module first parses the device information and authorization period recorded at the time of issuance from the decrypted authorization request data. Then, the security verification module collects the real-time device information of the current client device by calling the operating system underlying interface, that is, in the same way as the authorization server side, the fingerprint string of the current hardware environment is calculated in real time. Then, the security verification module compares the real-time device information with the device information parsed from the certificate. Only when the two strings are exactly the same, it means that the current device is the device authorized at the beginning, thereby completing the device matching verification. Any change of hardware will cause the real-time device information to change, thereby failing to pass the comparison. Next, in order to achieve high-strength anti-time tampering, the security verification module first obtains the local system time of the current client device. But the security verification module does not immediately believe this time, but also starts an independent network communication task to try to connect one or more external network time sources (such as the time server of the national time center) independent of the current client device, and obtains a high-precision network reference time. Then, the security verification module performs a time credibility evaluation: it calculates the deviation of the local system time and the network reference time, and judges whether the deviation is within a preset threshold range (for example, five minutes). This step effectively identifies whether the user has significantly rolled back the local system time in order to bypass authorization. When the deviation is within the acceptable range, that is, the local time is confirmed to be basically credible, the security verification module will continue to judge whether the local system time is within the start and end time range defined by the authorization period in the certificate. Only when the local time is credible and within the valid period, the security verification module finally completes the system time matching verification. If the network time source cannot be connected, the verification can fail according to the preset strategy, or be downgraded to rely only on the local time, but this will reduce the security.

[0097] Finally, only when all four checkpoints of decryption success, signature verification, device matching, and system time matching are successfully passed, the security verification module returns the authorization activation success state to the upper layer application. After activation, the management of the device offline authorization verification system does not end, but enters the continuous authorization execution and monitoring phase. After the above step of determining that the authorization is activated successfully, the method further comprises:

[0098] The current client device automatically repeats the step of verifying whether the authorization request data of the offline authorization certificate matches the device information and system time of the current client device at a preset time interval in the background or when a specific event is triggered.

[0099] Specifically, when the upper-layer application program receives a signal indicating that the activation is successful, it registers and starts a background daemon service or creates a separate background thread at the operating system level. This background service is configured to run in a completely user-unaware manner, it consumes extremely low system resources, and its execution logic is completely decoupled from the interface and business operations of the main program, thereby ensuring the independence and stability of monitoring.

[0100] Further, this background daemon service is given a clear trigger strategy, i.e., it automatically wakes up and performs a complete authorization check at a preset time interval or at a specific event trigger in the background. Specifically, this trigger strategy can be flexibly configured:

[0101] Based on a preset time interval: for example, the daemon service can have a built-in timer set to trigger every twenty-four hours (i.e., once a day). After the timer reaches the point, the service automatically performs a complete authorization status check.

[0102] Based on a specific event trigger: in addition to the timed trigger, the daemon service also listens to a series of key system or application events. For example, each time the software program starts, the system wakes up from hibernation, or even when it detects a change in the system network connection state, it will immediately trigger a check. This event-driven mode can respond more timely to changes in the environment that may affect the authorization status.

[0103] Further, once triggered, the background daemon service automatically repeats the same rigorous verification process as the first activation. Specifically, it silently reads the offline authorization certificate file stored locally, and then passes the certificate data to the underlying security verification module through a cross-language call interface. The security verification module will again perform a complete decryption, signature verification, and matching check of the authorization request data with the real-time device information and system time of the current client device. If the verification result is still "successful", the daemon service will record the check time and re-enter the hibernation or waiting state. However, if any step fails, for example, the user replaces the key hardware causing the device information to be mismatched, or the system time is abnormal causing it to be outside the authorized period, the security verification module will return a failure status code. At this time, the background daemon service will take action immediately, it will update a global authorization status flag, and the upper-layer application program will check this flag before performing the next key operation. If it finds that the authorization is invalid, it will immediately lock part or all of the software's functions and guide the user to re-activate or contact customer service, thereby ensuring the strict execution of the authorization rules.

[0104] Further, the above authorization request data also includes a function authorization set for defining the available functions of the software and a usage quota set for measuring the number of times a specific function is used.

[0105] The step of determining the success of the authorization activation further comprises:

[0106] According to the function authorization set, open or limit the specific function security verification module of the current client device;

[0107] According to the use quota set, the number of uses of the specific function in the current client device is metered and limited.

[0108] Specifically, when the upper application program receives the signal of successful authorization, it also receives the decrypted and verified complete authorization request data from the security verification module. This data is usually a general structured data format. The upper application will immediately parse it and load the configuration information in it into a global and unified authorization management component for the entire application to query at any time during runtime.

[0109] Further, the upper application starts to execute the dynamic function decision based on the function authorization set. Specifically, it finds the field named "function authorization set" from the parsed authorization request data, which may be a list containing specific function names, such as a list containing "professional editing", "cloud synchronization", "advanced export", etc. The authorization management component will dynamically update the permission configuration of the application according to this list. For the user interface level, the application will traverse all menu items, toolbar buttons and function panels, and if the function name exists in the function authorization set list, it will be set to enabled or visible state; otherwise, it will be grayed out or directly hidden, thus visually opening or limiting the specific function module of the current client device. For the internal logic level, when the user tries to call a function through a shortcut or the like, the corresponding code will first query the permission from the authorization management component, for example, ask "whether the professional editing function is enabled", and only when a positive answer is obtained, the function code will continue to execute.

[0110] Further, after completing the on-off control of the function module, the upper application starts to deploy the refined metering system based on the use quota set. Specifically, it finds the field named "use quota set" from the authorization request data, which is usually a list recording the number of uses of each function, such as "one hundred reports can be generated" and "five thousand interface calls can be made per month". For each function that needs to be metered, the authorization management component will initialize or update a corresponding counter in a secure and encrypted local storage area of the client. When the user performs a metered operation (such as clicking the "generate report" button), the corresponding business code will execute an uninterruptible "check before deduction" operation sequence:

[0111] First, the authorization control component is queried for the remaining quota of the "generate report" function. The authorization control component reads the current number of uses from the secure storage and compares it with the total quota (one hundred) obtained from the authorization certificate. If the number of uses is less than the total quota, the authorization control component immediately increments the number of uses by one and writes the new value back to the secure storage, then returns a "permit" signal to the business code, which continues to execute the logic of generating a report. If the number of uses has reached the total quota, the authorization control component directly returns a "reject" signal, and the business code will interrupt the execution and pop up a prompt to the user, such as "You have used up your monthly report generation quota". In this way, the system can accurately measure and limit the number of uses of a specific function in the current client device according to the use quota set.

[0112] In summary, the device offline authorization verification method in the above embodiments of the present application, the device offline authorization verification method provided by the embodiments of the present application, by using the upper application program written in a high-level programming language to call the security verification module encapsulated in the local compiled code, the layered security isolation between the business logic easy to decompile and the core cryptography operation difficult to reverse engineering is realized, the risk of core verification logic, key and algorithm being cracked or bypassed is fundamentally eliminated, and the technical problem of low security and easy cracking of the traditional pure high-level language authorization scheme is solved; by deriving a symmetric encryption key uniquely bound to the device based on the system master key and the client device information, the strong binding of the encrypted offline authorization certificate and the specific hardware is realized, and it is ensured that the authorization certificate is invalid on any unauthorized device, effectively eliminating the problem of unauthorized copying and abuse of authorization; by cross-comparing the local system time of the client device with the network reference time obtained from an independent external network time source, a high-trust double-signal source time verification mechanism is established, which can effectively identify and reject the attack behavior of bypassing the authorization period by maliciously modifying the local system time; by automatically repeatedly executing the complete authorization verification process at a preset interval or when a specific event is triggered in the background, the continuity and silent monitoring of the authorization state in the entire software life cycle are realized, and it is ensured that any environmental change or tampering behavior that causes the authorization to be invalid after activation can be discovered in time; by performing hash calculation on the pre-set client public key before use and comparing it with the standard hash value hardcoded, the self-checking ability of the core credentials in the security verification module is realized, which can resist advanced attacks by replacing the public key by tampering with the module binary file, further strengthening the anti-cracking barrier of the system; by parsing and enforcing the function authorization set and the usage quota set contained in the authorization request data, a flexible and configurable fine-grained authorization control mode is realized, which provides strong technical support for diversified business strategies such as hierarchical functions, subscription services, and pay-per-use, and solves the problem of single mode of traditional authorization schemes that cannot adapt to complex business needs. The problem of low security of existing software in offline environment is solved.

[0113] Embodiment two

[0114] Please refer to Figure 2 is a structural schematic diagram of a device offline authorization verification system provided by the second embodiment of the present application, only part related to the embodiments of the present application is shown for convenience of description, and the system comprises:

[0115] An authorization server 11 configured to receive, in an offline manner, authorization request data provided by a client device, the authorization request data containing device information and an authorization period, sign a hash digest value calculated from the authorization request data using a server-side private key pre-generated and encapsulated in a native compiled code, and encapsulate and encrypt the authorization request data and the digital signature to generate an encrypted offline authorization certificate;

[0116] A current client device 12 configured to use an upper-layer application program written in a high-level programming language to call a pre-configured security verification module encapsulated in a native compiled code through a cross-language calling interface, decrypt the imported encrypted offline authorization certificate using the security verification module, verify the offline authorization certificate through a pre-configured client-side public key paired with the server-side private key, and check whether the authorization request data of the offline authorization certificate matches the obtained device information and system time of the current client device, and only when the verification passes and the check matches, determine that the authorization activation is successful.

[0117] In an embodiment of the present application, the authorization server is deployed in a secure environment within a software provider. The core configuration is a native national cryptographic algorithm module encapsulated in a native compiled code (for example, written in C / C++ language and compiled into a dynamic link library or an executable file). The module securely stores a server-side private key in a pair of asymmetric keys. The server also includes an upper-layer business management system for receiving authorization request data from a client and interacting with the underlying national cryptographic algorithm module through a cross-language calling interface (such as JNI, P / Invoke) to perform signature and encryption operations, and finally generate an encrypted offline authorization certificate.

[0118] The current client device refers to an end-user device that needs to install and use the authorization software. The software architecture is innovatively designed as a layered structure of an upper-layer application program and a security verification module. The upper-layer application program is written in a high-level programming language (such as Java, C#, Python) and is responsible for user interaction, business logic, and calling the underlying module. The security verification module is a core component corresponding to the server-side module and is also encapsulated in a native compiled code. The security verification module pre-configures a client-side public key paired with the server-side private key and implements all core decryption, verification, and check logic. The upper-layer application program communicates with its security verification module through a cross-language calling interface.

[0119] The device offline authorization verification system provided by the embodiment of the present application has the same implementation principle, technical effects, and the foregoing method embodiment. For brevity, the part of the device embodiment not mentioned can be referred to the corresponding content in the foregoing method embodiment.

[0120] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the 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 can be combined in any one or more embodiments or examples in a suitable manner.

[0121] The above-described embodiments only express several implementation manners of the present application, which are described in a more specific and detailed manner, but cannot be understood as a limitation on the scope of the present application. It should be noted that, for those skilled in the art, several modifications and improvements can be made without departing from the concept of the present application, which are all within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the appended claims.

Claims

1. A device offline authorization verification method, characterized in that, The method includes: The authorization server receives authorization request data from the client device offline, which includes device information and authorization period. Using a server-side private key pre-generated in the local compiled code, the server signs the hash digest value obtained by hashing the authorization request data to obtain a digital signature. The server then encapsulates and encrypts the authorization request data and the digital signature to generate an encrypted offline authorization certificate. The current client device uses a high-level programming language to write an upper-layer application. It calls a pre-built security verification module encapsulated in the locally compiled code through a cross-language call interface. After decrypting the imported encrypted offline authorization certificate, the security verification module verifies the offline authorization certificate using a pre-built client public key paired with the server's private key. It also verifies whether the authorization request data of the offline authorization certificate matches the obtained device information and system time of the current client device. Currently, authorization activation is considered successful only if the verification passes and the verification matches.

2. The device offline authorization verification method according to claim 1, characterized in that, The step of encapsulating and encrypting the authorization request data and the digital signature to generate an encrypted offline authorization certificate includes: Based on a preset system master key and the device information in the authorization request data, a symmetric encryption key uniquely bound to the client device is generated through a key derivation algorithm. Using the generated symmetric encryption key, the encapsulated data containing the authorization request data and the digital signature is symmetrically encrypted using the national standard SM4 symmetric encryption algorithm to generate an encrypted offline authorization certificate.

3. The device offline authorization verification method according to claim 2, characterized in that, The step of decrypting the imported encrypted offline authorization certificate using the security verification module includes: Collect device information of the current client device; Based on the same system master key and obtained device information as the authorized server, the same key derivation algorithm is used to dynamically reconstruct the symmetric encryption key. Using the reconstructed symmetric encryption key, the encrypted offline authorization certificate is symmetrically decrypted using the national standard SM4 symmetric decryption algorithm.

4. The device offline authorization verification method according to claim 1, characterized in that, The step of verifying whether the authorization request data of the offline authorization certificate matches the obtained device information and system time of the current client device includes: Extract the device information and authorization period from the authorization request data using the decrypted offline authorization certificate; Collect real-time device information of the current client device and compare it with the parsed device information to complete device matching verification; Get the local system time of the current client device, and get a network reference time returned from an external network time source independent of the current client device; When the deviation between the local system time and the network reference time is within a preset threshold range, it is determined whether the local system time is within the start and end time range defined by the authorized period, so as to complete the system time matching verification.

5. The device offline authorization verification method according to claim 1, characterized in that, The authorization request data also includes a set of function authorizations for defining the available functions of the software and a set of usage quotas for measuring the number of times a specific function is used. Following the step of determining successful authorization activation, the following steps are also included: Based on the aforementioned function authorization set, specific functional modules of the current client device may be enabled or restricted; Based on the usage quota set, the number of times a specific function is used on the current client device is measured and limited.

6. The device offline authorization verification method according to claim 1, characterized in that, The step of signing the hash digest value obtained by hashing the authorization request data using the server-side private key pre-generated in the locally compiled code to obtain a digital signature includes: The authorization request data is hashed using the national cryptographic SM3 algorithm to generate a hash digest; A digital signature is generated by signing the hash digest using a pre-generated server-side private key encapsulated in the locally compiled code and the national cryptographic SM2 algorithm.

7. The device offline authorization verification method according to claim 6, characterized in that, The step of verifying the offline authorization certificate using a pre-set client public key paired with the server-side private key includes: Separate the authorization request data and the digital signature from the decrypted offline authorization certificate; Using the same national cryptographic algorithm SM3 used by the authorization server to generate hash digest values, the separated authorization request data is hashed to obtain a locally calculated hash digest value; The separated digital signature is decrypted using the preset client public key and the national cryptographic SM2 algorithm to restore the original hash digest value generated by the authorization server; The locally calculated hash digest value is compared with the original hash digest value. The signature verification is deemed successful if and only if the two are completely identical.

8. The device offline authorization verification method according to claim 7, characterized in that, The step of decrypting the separated digital signature using the preset client public key and the Chinese national cryptographic SM2 algorithm includes: The hash value of the pre-set client public key is calculated using the same national cryptographic SM3 algorithm used when generating the hash digest value as the authorization server. The hash value calculation result is compared with the pre-stored public key standard hash value hard-coded in the security verification module; The separated digital signature is decrypted using the preset client public key and the national cryptographic SM2 algorithm only if the comparison results are completely consistent.

9. The device offline authorization verification method according to claim 1, characterized in that, After the step of determining successful authorization activation, the method further includes: In the background, at preset time intervals or when a specific event is triggered, the current client device automatically repeats the step of verifying whether the authorization request data of the offline authorization certificate matches the obtained device information and system time of the current client device.

10. A device offline authorization verification system, characterized in that, The system includes: An authorization server is configured to receive authorization request data from a client device, containing device information and authorization period, in an offline manner. Using a server-side private key pre-generated in locally compiled code, the server signs the hash digest value obtained by hashing the authorization request data to obtain a digital signature. The server then encapsulates and encrypts the authorization request data and the digital signature to generate an encrypted offline authorization certificate. The current client device, configured as a high-level application written in a high-level programming language, calls a pre-built security verification module encapsulated in locally compiled code via a cross-language call interface. This security verification module decrypts the imported encrypted offline authorization certificate and then verifies the certificate using a pre-built client public key paired with the server's private key. It also verifies whether the authorization request data of the offline authorization certificate matches the obtained device information and system time of the current client device. Currently, authorization activation is considered successful only if the verification passes and the data matches.

Images