Method and device for checking and managing offline device without networking, and storage medium

Abstract

The application discloses a check and management method and device for offline devices without networking and a storage medium, relates to the technical field of computer information security and operation and maintenance management, and comprises a management server and an offline check client arranged on an offline device. The management server generates an offline check data file, the offline check client loads the file, performs a security compliance check, and generates a check result code. The management server acquires the check result code, reconstructs the offline check result by decoding and verifying, and realizes the automation, online and trusted management of the security compliance check of the offline device by using a very short check result code as a data carrier without destroying the network isolation. The application effectively solves the problems of low efficiency, unstructured result, error-prone and "security island" and the like in the traditional manual check of offline devices.

Description

Technical Field

[0001] This invention relates to the field of computer information security and operation and maintenance management technology, specifically to a method, device and storage medium for inspecting and managing offline devices that are not connected to the internet. Background Technology

[0002] In sectors with extremely high information security requirements, such as energy, finance, military, and critical infrastructure, a large number of computer devices are required to operate in a network-offline isolated manner to avoid data leakage. These computer devices that are not connected to any network are called offline devices.

[0003] Effective, unified, and routine inspections (such as baseline checks, vulnerability scans, and asset inventory) and status monitoring of these numerous and dispersed offline devices are a significant pain point in current security and operations management. Since offline devices are not connected to any network, traditional inspection methods rely primarily on manual on-site operations, which have limitations mainly reflected in: 1. Manual inspection is inefficient and produces unstructured data: Traditional methods often rely on inspectors to manually inspect and analyze each item based on a paper checklist, and then handwrite the inspection results. This method is not only inefficient and prone to errors, but the resulting paper records are unstructured data, making it difficult to input into a system for effective digital statistics, trend analysis, and long-term traceability.

[0004] 2. Restricted Export of Electronic Media, Possessing Security Risks: Another common method is to export device logs or inspection reports using removable storage media such as USB flash drives. However, in many high-security scenarios, the use of removable storage media is strictly controlled or even completely prohibited (to prevent viruses from entering or sensitive data from being exported illegally). Therefore, file-based electronic data return is often difficult to implement, or the approval process is extremely cumbersome, resulting in long inspection cycles, poor timeliness of results, and potential monitoring blind spots.

[0005] 3. Results lack credible verification and are easily tampered with or confused: The offline inspection process lacks supervision, and inspectors may make subjective errors when manually recording or transcribing data. This could even lead to tampering with inspection results (e.g., changing non-compliant to compliant), misattribution (confusing device IDs), or duplicate submission of old data. The management system cannot verify the authenticity, completeness, and timeliness of the reported data.

[0006] 4. Management suffers from "data silos" and lacks a global perspective: Due to the reasons mentioned above, the compliance status of offline devices is often only stored locally or in scattered paper documents. Administrators cannot uniformly and online grasp the real-time compliance status of all offline devices on the server side, making it difficult to respond quickly to security risks.

[0007] Therefore, there is an urgent need for a new inspection and management method that can achieve structured, reliable, and efficient feedback of offline device inspection results while strictly adhering to the requirements for offline device network isolation and data export control, thereby achieving the goal of unified, online, fast, and reliable security management. Summary of the Invention

[0008] The purpose of this invention is to overcome the problems of low efficiency and unstructured data in the existing technology of offline device inspection relying on paper records, or security and compliance risks due to reliance on mobile storage media for export, as well as the difficulty in verifying the authenticity of manual inspection results, and to provide a method, device and storage medium for the inspection and management of offline devices that are not connected to the network.

[0009] This invention enables the structured, reliable, and efficient transmission of offline device inspection results by generating short codes suitable for manual input, while strictly adhering to the requirements for offline device network physical isolation and data export control.

[0010] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a method for inspecting offline devices that are not connected to the internet. The inspection method is executed by an offline inspection client deployed on the offline device, including: Load the offline inspection data file, which contains inspection rules; Perform the inspection according to the aforementioned inspection rules and generate offline inspection results; The offline inspection results are compressed to generate compressed inspection result data. The compressed inspection result data and the integrity verification information used to verify integrity are spliced ​​or combined to generate an inspection result code.

[0011] In an optional implementation, the inspection method further includes: Obtain the local hardware information of the offline device; Based on the predetermined generation strategy, the corresponding device identifier code is determined according to the local hardware information; The step of generating the inspection result code includes: splicing or combining the device identification code, the compressed inspection result data, and the integrity verification information.

[0012] Furthermore, the step of determining the corresponding device identifier code based on the local hardware information according to a predetermined generation strategy includes any one of the following: (a) Obtain directly from the offline inspection data file a digital identifier that is pre-associated with the local hardware information, and use it as the device identification code; (b) Determine the arrangement position index of the local hardware information in the offline inspection data file list, and use the arrangement position index as the device identification code; (c) The local hardware information is calculated and transformed according to a preset algorithm, and bits of a preset length are extracted as the device identifier code; wherein the preset length is determined in advance based on the total number of offline devices to be inspected and the allowed hash collision probability.

[0013] In an optional implementation, the method further includes: the inspection method further includes: Before generating the inspection result code, the local hardware information is matched with the device authentication information preset in the offline inspection data file to verify the offline device identity; The check result code can only be generated after offline device authentication is successful.

[0014] In one optional implementation, the step of generating the inspection result code further includes: The offline inspection data file contains embedded version identification information for identifying the offline inspection data file on which the inspection is based, and the version identification information is encoded into the inspection result code.

[0015] In one optional implementation, the process of generating the check result code is as follows: The compressed inspection result data and the integrity verification information used to verify integrity are spliced ​​or combined to obtain a plaintext sequence; The plaintext sequence is encrypted using pre-set key data to preserve its format or undergo reversible obfuscation to obtain a ciphertext sequence, which is then converted into a character-based check result code.

[0016] Furthermore, the preset key data is any one of the following: Pre-set, time-invariant encryption keys obtained from offline inspection data files or data used to generate encryption keys; The time key is derived based on the current inspection time.

[0017] In a second aspect, the present invention provides an offline inspection client device deployed on an offline device, including a memory and a processor, wherein the processor executes a computer program to implement an inspection method for an offline device without internet access as described in the first aspect.

[0018] Thirdly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for checking offline devices without network access as described in the first aspect.

[0019] Fourthly, the present invention provides a management method for offline devices that are not connected to the internet, the management method being executed by a management server, including: Generate an offline inspection data file for use by the offline inspection client, the offline inspection data file containing inspection rules; Obtain the inspection result code generated by the offline inspection client after performing the inspection according to the inspection rules through non-network methods; The inspection result code is decoded to parse out the data block to be verified and the integrity verification information; The integrity of the inspection result code is verified based on the integrity verification information. After the integrity verification is passed, the compressed inspection result data is parsed from the data block to be verified. The compressed inspection result data is decompressed or reverse-mapped in sequence to reconstruct the offline inspection result.

[0020] In one optional implementation, the data block to be verified includes a device identifier code and compressed check result data. After the integrity verification is passed, the device authentication process is further performed on the check result code, specifically including: By utilizing the correspondence between device authentication information and device identification code pre-stored on the management server, or by using the same preset generation strategy as offline devices, the identity of the offline device from which the compressed inspection result data originates can be determined based on the device identification code; The identified offline devices will be verified against a pre-defined list of legitimate devices.

[0021] In one optional implementation, version identification information is embedded in the offline inspection data file, and the data block to be verified also includes version identification information. After the integrity verification is passed, version verification is also performed on the inspection result code. The specific process includes: The latest version identification information from the management server is compared with the version identification information in the data block to be verified to obtain the version verification result.

[0022] In one optional implementation, the step of decoding the inspection result code includes: performing reverse decryption or deobfuscation on the inspection result code to obtain the data block to be verified and integrity verification information.

[0023] Furthermore, the reverse decryption or deobfuscation process includes: within a preset time window, deriving multiple time keys based on different times, and using the multiple time keys to perform iterative decryption attempts on the check result code; when the validity verification of the data obtained in the iterative decryption attempts passes, the decryption is confirmed to be successful; if the validity verification of the data obtained in all iterative decryption attempts within the entire preset time window fails, the decryption is determined to have failed.

[0024] Fifthly, the present invention provides a management server device, including a memory and a processor, wherein the processor executes a computer program to implement a management method for offline devices that are not connected to the network as described in the fourth aspect.

[0025] In a sixth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements a method for managing offline devices that are not connected to the network as described in the fourth aspect.

[0026] Compared with the prior art, the present invention has the following beneficial effects: 1. Overcoming physical isolation limitations to achieve structured data transmission: This invention generates character sequences (inspection result codes) suitable for manual input by deeply compressing and encoding inspection results. This method is completely independent of network connections, USB or other mobile storage media, and additional hardware such as barcode scanners or cameras. While meeting the highest level of physical isolation security requirements, it transforms unstructured paper records into structured electronic data, solving the problem of difficult offline data collection.

[0027] 2. High data compression rate, reducing manual workload: This invention adopts efficient compression strategies such as bitmap mapping and state enumeration to compress complex inspection reports into extremely short strings, greatly reducing the workload and error rate of manual transcription by inspectors.

[0028] 3. A strong "device-result" binding mechanism was established to prevent fraud: By generating a device identification code based on local hardware information and encoding it into the result code, the management server can verify the true identity of the result source through reverse parsing. This effectively prevents inspectors from misusing equipment, confusing devices, or forging inspection results, thus plugging security vulnerabilities in the "server-side verification" scenario.

[0029] 4. Introducing time-based keys and iterative decryption to ensure timeliness and security: By using dynamic encryption based on the inspection time (such as format-preserving encryption) and a time-window iterative decryption mechanism, the inspection result code is ensured to be timely (preventing replay attacks) without increasing the length of the result code, while also solving the problem of potential time discrepancies on offline devices.

[0030] 5. Closed-loop management improves operational efficiency: This invention achieves a complete closed loop from server-side policy definition (rule distribution) to client-side execution feedback (short code return). Combined with version identification information, it ensures the consistency of the inspection baseline and solves the problems of "security silos" and unknown status of offline devices. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0032] Figure 1 This is an overall architecture diagram of an offline device inspection and management system provided in an embodiment of the present invention; Figure 2 This is a flowchart of the offline inspection client-side execution process provided in an embodiment of the present invention; Figure 3 This is a schematic diagram illustrating the internal data structure and generation logic of the inspection result code provided in this embodiment of the invention; Figure 4 This is a flowchart of the processing on the management server side provided in an embodiment of the present invention; Figure 5 This is a flowchart of a dynamic encryption process based on a time key, provided in an embodiment of the present invention. Figure 6 This is a flowchart of the iterative decryption process based on a time key provided in an embodiment of the present invention. Detailed Implementation

[0033] 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. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0034] Example 1: Overall Architecture Diagram of an Offline Device Inspection and Management System Please see Figure 1 This embodiment provides an offline device inspection and management system. The system aims to solve the challenges of device inspection and management in physically isolated network scenarios, particularly addressing the problems of low efficiency, unstructured data, and difficulty in verifying the authenticity of traditional manual records.

[0035] like Figure 1 As shown, the system described in this embodiment mainly consists of a management server 100 deployed in an online environment and an offline inspection client 210 deployed on an offline device 200.

[0036] 1. Management Server 100: Deployment location: Deployed in an online environment connected to a network.

[0037] Core Functions: As the system's management and data center, it is responsible for generating offline inspection data files containing inspection rules (such as baseline verification strategies and classified information checks). These files are intended for transfer to offline devices via compliant hardware media such as CDs and USB drives. Simultaneously, the management server 100 also receives inspection result codes manually entered by inspectors through a human-machine interface, and decodes, verifies, and reconstructs the data to achieve digital management of the offline device status.

[0038] 2. Offline check client 210: Deployment location: Deployed and running in offline device 200. The offline device 200 is in an offline environment without network access and is the target object for inspection by this system (e.g., classified terminals, offline debugging machines, etc.).

[0039] Core Function: The offline inspection client 210 loads imported offline inspection data files and performs automated security checks on the offline device 200 according to the rules in the files. After generating the raw inspection results, the client 210 further converts the results into character-based inspection result codes and displays them on the screen of the offline device 200 for manual transcription or input by inspectors.

[0040] When the generated check result code is long, it can be displayed in multiple segments using a connector (such as "-"). Each segment is recommended to be three to five characters long, making the generated check result code suitable for manual transcription and input. For example, a 10-character check result code can be displayed as ABCDE-EADCD, and a 12-character check result code can be displayed as ABCD-EFGH-MLNS.

[0041] During the actual inspection, an offline inspection client 210 is deployed for each offline device to be inspected.

[0042] Figure 1 Note: The dashed boxes in the diagram represent different network security domains (online and offline environments). Solid arrows indicate the one-way import path for offline inspection data files, while dashed arrows indicate the manual return path for inspection result codes (across physical isolation). This embodiment's system constructs a complete data loop through the collaboration of the two core components described above.

[0043] This embodiment will serve as the system architecture basis for subsequent embodiments.

[0044] Example 2: Basic Inspection Plan This embodiment focuses on explaining how to select the most suitable data compression strategy based on different inspection scenarios in a non-networked environment, and how to solve the problems of large workload, unstructured data, and difficulty in exporting and transmitting inspection results in the prior art through character encoding.

[0045] Please combine Figure 2 (Offline client inspection process) Figure 3 (Logic for generating the inspection result code) Figure 4 (Management Server-Side Process) Understand this embodiment. It should be noted that, in Figure 2 and Figure 4 The sub-steps that appear in the process are connected by the symbol "&". Each sub-step can be used independently in the process description. The sub-step of loading the file in S201 is represented by "S201-Load File". Other sub-steps are referenced in a similar way.

[0046] I. Overall Process (1) Offline inspection of client-side processing flow: S201 - Load File: Offline inspection client 210 loads the offline inspection data file and reads the inspection rules.

[0047] S203 - Perform Inspection: The offline inspection client 210 performs an inspection on the offline device according to the inspection rules and obtains the original inspection results.

[0048] S203-Data Compression: According to the preset data compression strategy, the original inspection result is converted into compressed inspection result data according to the inspection rules. The data compression strategy is as follows: for each inspection rule, a corresponding Boolean state value or state enumeration value is generated, and the generated multiple Boolean state values ​​or state enumeration values ​​are mapped or concatenated in a preset order to generate a bit sequence; see the compression strategies in two typical scenarios in the following embodiment (II) for details.

[0049] S205 - Combination Encoding: Calculate the integrity verification information (such as CRC8) of the compressed check result data, and concatenate the compressed check result data and the integrity verification information in sequence to obtain a combined binary sequence.

[0050] S205 - Character Encoding to Generate Inspection Result Code: The combined binary sequence is converted into a character-type inspection result code (such as A7X9-K2M4) through character encoding (Base32 encoding is used in this embodiment) for manual transcription.

[0051] (2) Management server-side processing flow: S401 - Obtain and decode the inspection result code: The management server 100 obtains the combined binary sequence by character decoding (Base32 decoding is used in this embodiment).

[0052] S402 - Integrity Verification of Check Result Code: The management server 100 divides the combined binary sequence obtained from character decoding into data to be verified (including compressed check result data) and the received integrity verification information. It calculates the integrity verification value of the compressed check result data and compares it with the received integrity verification information. If the two do not match, the check code is invalid. This step prevents accidental copying of the check result code.

[0053] S405 - Reconstruct and Archive Results: The integrity check of the result code has passed. The management server reconstructs and archives the result.

[0054] II. Compression Strategies in Two Typical Scenarios The core of the data compression strategy of this invention lies in utilizing "pre-defined consensus". Since the order of the checking rules R1, R2... Rn is known between the server and the client, the client does not need to return "rule ID + result" (e.g., "Rule01:Pass"), but only needs to return a result in a fixed format.

[0055] To adapt to different offline inspection needs, this embodiment uses bitmap mapping as the basic compression strategy, and can use state enumeration method alone or in combination depending on the specific scenario.

[0056] Scenario A: Standard compliance baseline check (Applicable strategy: pure bitmap mapping method) Applicable scenarios: The number of checks is fixed and moderate (e.g., 50 operating system baseline checks), and the result is only a binary "pass / fail" status.

[0057] Compression principle: For each inspection rule, a Boolean status value (1 = pass, 0 = fail) is generated. The system maps these 50 Boolean values ​​into a 50-bit sequence in a preset order.

[0058] Example: 11111001... (50 characters in total).

[0059] Data volume: Only about 7 bytes required.

[0060] Advantages: Extremely high coding efficiency, fixed data length, suitable for standardized inspection.

[0061] Scenario B: Complex configuration verification (Applicable strategy: bitmap mapping + state enumeration method) Applicable scenarios: When the inspection results have a variety of statuses, including not only "pass / fail", but also "not applicable (N / A)", "manual confirmation (Manual)" or "risk level (High / Low)", and the code length needs to be shortened as much as possible.

[0062] Compression principle: It adopts a layered encoding method of "basic status + detailed information".

[0063] 1. Base Layer (Bitmap Mapping): First, Boolean state values ​​(1 = no need to pay attention / pass, 0 = need to pay attention / fail / other) are generated for all inspection rules (e.g., 50 items) and mapped to the first bit sequence (50 bits). This ensures that all inspection items have a basic binary state record.

[0064] 2. Extension Layer (State Enumeration): This layer then includes generating corresponding state enumeration values ​​for check items (or specific configuration-related check items) with a state of "0" in the base layer. For example, it defines: 00 = Critical Violation, 01 = Not Applicable (N / A), 10 = Requires Manual Review, 11 = General Risk.

[0065] 3. Combination: Combine the first bit sequence with the subsequent concatenated state enumeration value sequence.

[0066] Example: Suppose there are 50 checks in total, of which items 5 and 10 failed and their details need to be recorded.

[0067] Bitmap portion: 1111011110... (50 bits in total, approximately 7 bytes) Enumeration section: Generate "00" (critical) for item 5, and generate "10" (requires manual review) for item 10. (Total 4 digits) Final data: [Bitmap sequence] +

[0010] .

[0068] Advantages: It satisfies the requirement of full coverage of all checked items (in accordance with claim 1) and supplements rich text information with minimal additional overhead, saving more space than simply using the full enumeration method.

[0069] Obviously, depending on the actual needs of the inspection items, the results can also be recorded using only the state enumeration values.

[0070] III. Character Encoding Regardless of the compression strategy used, the result is a binary bitstream. To meet the requirement of "suitable for manual input via a human-computer interaction interface" in claim 1, in this embodiment, the offline inspection client 210 performs Base32 encoding on the combined binary sequence to convert the combined binary sequence into a character sequence. Base32 encoding is case-insensitive and excludes easily confused characters (such as I, 1, O, 0), minimizing the error rate during manual transcription.

[0071] It should be noted that the use of Base32 encoding in this embodiment is merely illustrative and does not limit the character encoding scheme used in this invention. In specific implementations, other character encoding schemes can be used. For example, custom Base32 encoding can be implemented through a custom character set, or other character encodings can be used.

[0072] IV. Example of generating inspection result codes on the offline inspection client side To visually demonstrate the implementation of the basic inspection scheme, the following section, in conjunction with the aforementioned Scenario A (standard compliance baseline inspection, bitmap mapping method), provides a detailed explanation of the data composition and generation process.

[0073] Assuming the offline device needs to report the results of 52 baseline checks, the check result code encoding process is as follows: 1. Generate compressed inspection result data (Payload): The offline inspection client 210 maps 52 inspection results (pass / fail) into a 52-bit bit sequence.

[0074] Data example: 1111100000...101 (52 bits in total).

[0075] Generate integrity verification information (Checksum): In order to prevent manual transcription or input errors (such as mistyped characters or omissions), the client calculates the checksum value of the above 52-bit data (CRC-8 checksum is used in this embodiment) to obtain an 8-bit checksum.

[0076] Data example: 10110011 (8 bits in total).

[0077] Note: The total length of the combined binary sequence is 60 bits at this time.

[0078] 2. Assembly: The verification information is appended to the compressed data to form the final sequence to be encoded. Structure: [Compression check result data (52 bits)] + [Integrity check information (8 bits)].

[0079] 3. Generate inspection result code (Short Code): Use Base32 encoding (each character carries 5 bits of information) to convert 60 bits into characters.

[0080] Calculation: 60 ÷ 5 = 12 characters.

[0081] Example of final result: MQ4T-7Z2W-9P1X (12 characters).

[0082] In Example 3, the process of generating the inspection result code will be further explained with specific data.

[0083] V. Example of Management Server-Side Processing Logic 1. Manual data entry and association: Since the inspection result code generated in this embodiment does not include the device ID, when operators enter the information on the human-computer interaction interface of the management server, they need to first select the currently reported offline device from the list (for example, manually select "Finance Department - Confidential Terminal 01"), and then enter the above 12 characters.

[0084] Special note: Although this method relies on manual selection of equipment, in scenarios with extremely strict physical isolation and a controllable number of devices, the requirements can be met through standardized management processes (such as "one person, one machine" inspection), while achieving the shortest code length.

[0085] 2. Decoding and Verification: The server decodes the MQ4T-7Z2W-9P1X into a 60-bit binary stream and extracts the last 8 bits as a checksum for verification. If the verification passes, it means the manual input was correct; if it fails, the system immediately displays "Invalid check result code".

[0086] VI. Summary of Implementation Examples This embodiment serves as a basic inspection scheme. It primarily generates inspection result codes suitable for manual transcription and reporting by performing extreme data compression and character encoding on the original inspection results. The inspection result codes are character sequences composed of human-readable characters, suitable for manual input through a human-computer interaction interface. This greatly improves the feasibility and accuracy of offline data return, and solves the problems of large workload, unstructured data, and difficulty in exporting and returning inspection results in the prior art.

[0087] Example 3: Enhanced Equipment Traceability Scheme This embodiment, based on Embodiment 2 (Basic Inspection Scheme), introduces a "strong binding mechanism between equipment and results." This embodiment is suitable for scenarios where the authenticity of inspection results is highly critical, and where it is necessary to prevent inspectors from confusing equipment or falsifying sources.

[0088] Before detailing this embodiment, the following assumptions are made to clarify the information in subsequent embodiments. These assumptions are for illustrative purposes only and are not intended to limit the scope of protection or numerical limitations of this invention. The assumptions are as follows: 1. There are a total of 20 items to be checked; 2. The data compression method adopts bitmap mapping, which maps each inspection result to pass (e.g., mapping "0") / fail (e.g., mapping "1"). For example, 20 compressed inspection result data is: 10101100011010111011; 3. The CRC8 integrity verification algorithm is adopted; 4. Use 14 bits of data to represent the device identification code; 5. The inspection result code is encoded using Base32.

[0089] Please combine Figure 2 (Offline client inspection process) Figure 3 (Check result code generation logic) and Figure 4 (Management Server Process) Understand this embodiment.

[0090] I. Offline Inspection Client-Side Processing Flow S201 - Load File, Obtain Local Hardware Information: The offline inspection client 210 loads the offline inspection data file, reads the inspection rules and device authentication information; in addition, it obtains local hardware information, such as a combination of one or more hardware identifiers, such as MAC address, hard drive serial number, motherboard serial number, etc.

[0091] In this embodiment, the MAC address of the local device is obtained as local hardware information.

[0092] S202 - Pre-authentication: Before performing the check, the local hardware information (MAC address in this embodiment) is matched with the device authentication information in the offline check data file. If the match fails, it means that the device is not within the scope of the check, and the offline check client 210 will terminate the process and display an error message.

[0093] This step is the preferred one, as it reduces invalid device checks. If pre-authentication is not available, the management server can also perform post-authentication.

[0094] S203 - Perform check and compress data: Same as the basic check scheme S203 in Example 2. For example, the result of compressing the check data is a 20-bit binary sequence 10101100011010111011 (20-bit).

[0095] S204 - Determine the device identification code: In order to embed lengthy hardware information into a short code, it needs to be compressed or mapped. This embodiment describes the three methods in claim 3 respectively, and any one of them can be selected in specific implementation.

[0096] (a) Pre-defined associated identifier method: The offline inspection data file contains a key-value pair mapping table (Map / Dictionary), for example, { "AA-BB-CC-11-22-33": 0x2ECB, ...}. The offline inspection client obtains the pre-assigned device identifier (0x2ECB, i.e., binary 10111011001011) by matching local hardware information. The advantage of this method is that the server has complete control over ID allocation, and there will be no device identifier conflict.

[0097] (b) List Position Index Method: The offline inspection data file contains an ordered list of valid devices (Array / List). The offline inspection client finds the index of the local hardware information by matching it with the local hardware information. For example, if the index of the matched device is 0x2ECB, then the device identification code of that device is 0x2ECB, and the binary format is 10111011001011. The advantage of this method is that it reuses the position index, but it may result in invalid device identification codes (such as devices that are scrapped / deregistered).

[0098] (c) Calculation-conversion-truncation method: A hash operation is performed on the locally obtained local hardware information (such as the MAC address), and the lower 14 bits (14 bits) are extracted from the resulting hash value as the device identifier. For example, Hash("AA-BB-CC-11-22-33") -> 10111011001011 (14 bits). The advantage of this method is that it does not require pre-checking any mapping table stored or retrieved on the offline client; it is generated entirely dynamically. However, different devices may calculate the same device identifier, leading to device identifier conflicts. Therefore, the calculation-conversion-truncation method is suitable for scenarios with a small number of devices.

[0099] In this embodiment, the preset associated identifier method is used, assuming the device identification code (0x2ECB, i.e., binary 10111011001011).

[0100] S205 - Combined Encoding: After obtaining the device identification code, the offline inspection client 210 concatenates the compressed inspection result and the device identification code in sequence, and calculates the CRC8 check value of the inspection result code. Since Base32 encoding requires the length of the combined binary sequence to be divisible by 5, but the current length of the combined binary sequence is 20 (compressed inspection result data) + 14 (device identification code) + 8 (integrity check code) = 42, three zeros are padded to the combined binary sequence, resulting in a 45-bit combined binary sequence. The structure of the combined encoding is as follows: Combined structure: [zero padding (3 bits)] + [compression check result (20 bits)] + [device identifier (14 bits)] + [integrity check (8 bits)], totaling 45 bits.

[0101] Combined binary sequence:

[000] +[10101100011010111011]+[10111011001011]+[11000100].

[0102] Then, calculate the CRC8 check value of the data block consisting of zero-padding data (3 bits), compression check result (20 bits), and device identifier code (14 bits), i.e., CRC8(

[000] [10101100011010111011] +[10111011001011])=[11000100]. Then, combine the zero-padding data (if any), compression check result, device identifier code, and integrity check information in sequence.

[0103] S205 - Character Encoding to Generate Check Result Code: The combined binary sequence is converted into a character-type check result code using character encoding (Base32 encoding is used in this embodiment). The steps for converting binary to a Base32 character sequence are as follows: Group mapping: Group every 5 bits and convert them. For example, 00010 corresponds to the number 2, and the character at index 2 is C. Continue in this manner to complete the entire group mapping.

[0104] 00010-10110-00110-10111-01110-11101-10010-11110-00100 (9 groups) Generate check result code: Output the mapped characters sequentially. To improve the convenience of manual transcription, the connector “-” can be used to assist in generating the check result code. In this embodiment, the 9-character check result code generated is C-WGXO-5S6E.

[0105] II. Processing Flow on the Management Server Side After receiving the manually entered character sequence, the management server 100 executes the decoding process.

[0106] S401 - Obtain and decode the inspection result code: The management server 100 obtains the combined binary sequence by character decoding (Base32 decoding is used in this embodiment).

[0107] S402 - Integrity Verification of Check Result Code: The management server 100 divides the combined binary sequence obtained from character decoding into a data block to be verified (containing compressed check result data and device identification code) and the received integrity verification information. It calculates the integrity verification value of the data composed of compressed check result data and device identification code and compares it with the received integrity verification information. If the two are inconsistent, the check code is invalid.

[0108] S403 - Data Parsing: The integrity check of the result code has passed. The compressed check result data and device identification code are parsed from the data block to be checked.

[0109] S404 - Post-authentication: The management server 100 performs post-authentication based on the authentication method that matches the offline inspection client 210.

[0110] For (a) the pre-set associated identifier method and (b) the list position index method, the management server 100 directly searches for the device in the asset list based on the device ID (or index).

[0111] For (c) the calculation-transformation-intercepting method, the management server 100 performs the same hash algorithm on the MAC addresses of all devices in the asset list, searching for devices whose calculation results match the parsed device IDs. The management server 100 can also pre-calculate and store the intercepted results for each device. During post-authentication, the device identification code is used directly for querying.

[0112] This embodiment uses a method corresponding to the pre-set associated identifier method for post-authentication. If the post-authentication is successful, the management server 100 can automatically lock the archive target; if the post-authentication fails, the check result code is discarded and an error message is displayed to prevent misattribution.

[0113] This step is the preferred step and, when used in conjunction with pre-authentication, can provide double protection for authentication.

[0114] S405 - Reconstruction Results and Archiving: Once all verifications are successful, the management server 100 automatically binds the reconstruction check results to the offline device based on the device identification code and archives them.

[0115] III. Summary of Implementation Examples The three device identification code generation methods provided in this embodiment can be selected and used according to the device inspection scenario. Meanwhile, by implicitly embedding the hardware fingerprint into the inspection code, this embodiment ensures a one-to-one correspondence between the code and the device, effectively preventing common problems in manual inspections such as substitution, missed inspections, or misidentification. Inspectors do not need to memorize device numbers or perform additional operations when generating codes, further reducing manual work and improving inspection efficiency.

[0116] Example 4: Enhanced Version Management Solution Offline devices are prone to using outdated rules for checks due to a failure to import the latest inspection rules in a timely manner. In such cases, a "check passed" result is invalid (pseudo-compliance). This embodiment, based on Embodiment Two (Basic Inspection Scheme), introduces an "inspection rule version consistency verification" mechanism to ensure that the server can identify such "expired checks." This embodiment is particularly suitable for scenarios where inspection standards are frequently updated (such as the latest virus signature database or quarterly security baseline updates).

[0117] Before detailing this embodiment, the following assumptions are made to clarify the information in subsequent embodiments. These assumptions are for illustrative purposes only and are not intended to limit the scope of protection or numerical limitations of this invention. The assumptions are as follows: 1. There are a total of 20 items to be checked; 2. The data compression method adopts bitmap mapping, which maps each inspection result to pass (e.g., mapping "0") / fail (e.g., mapping "1"). For example, 20 compressed inspection result data is: 10101100011010111011; 3. The CRC8 integrity verification algorithm is adopted; 4. Use 8-bit data to represent version identification information.

[0118] 5. The inspection result code is encoded using Base32.

[0119] Please combine Figure 2 (Offline client inspection process) Figure 3 (Logic for generating the inspection result code) Figure 4 (Management Server Process) Understand this embodiment.

[0120] I. Pre-configuration phase: Offline check of data file generation (management server) Before the inspection begins, the management server 100 performs the following operations when generating the offline inspection data file for offline devices: Embedded version identification information: When encapsulating the inspection rules, the server embeds the current version identifier (such as version ID, version number "V2.4", release timestamp "202310" or file content hash value) into the offline data inspection file.

[0121] In this example, the version identification information uses version ID 12 (00001100 in binary) to indicate that the latest checked file version is version 12.

[0122] II. Offline Inspection Client-Side Processing Flow The offline inspection client 210 adds a step of extracting and encoding version information when performing inspections and generating result codes. The specific process is as follows: S201 - Load File: The offline inspection client 210 loads the offline inspection data file and reads the inspection rules and version identification information (such as the binary format of the version ID 00001100).

[0123] S203 - Perform check and compress data: Same as the basic check scheme S203 in Example 2. For example, the result of compressing the check data is a 20-bit binary sequence 10101100011010111011 (20-bit).

[0124] S205-Combined Encoding: Similar to Example 3, since the compression check data result (20 bits) + version identification information (8 bits) + integrity check information (8 bits) = 36 bits, zeros need to be padded in the high bits. Then, the CRC8 check value of [zero-padded data (4 bits) + compression check data result (20 bits) + version identification information (8 bits)] is calculated to be 10010000. Then, a 40-bit combined binary sequence is formed as follows:

[0000] [10101100011010111011][00001100][10010000].

[0125] S205 - Character Encoding to Generate Inspection Result Code: The combined binary sequence is converted into a character-type inspection result code through character encoding. The result is BLDL-WDEQ, which is used for manual transcription.

[0126] III. Processing Flow on the Management Server Side S401 - Obtain and decode the inspection result code: The management server 100 obtains the combined binary sequence by character decoding of the obtained inspection result code.

[0127] S402 - Integrity Verification of Check Result Code: The management server 100 divides the combined binary sequence obtained from character decoding into a data block to be verified (containing compressed check result data and version identification information) and the received integrity verification information. It calculates the integrity verification value of the compressed check result data and compares it with the received integrity verification information. If the two are inconsistent, the check code is invalid.

[0128] S403 - Data Parsing: The integrity check of the result code has passed. The compressed check result data and version identification information are parsed from the data block to be checked.

[0129] S404 - Version Verification: The parsed version identification information is compared with the latest version identification information of the management server 100. If they are inconsistent, it means that the offline check data file version on which the check result code is based is incorrect, and the check result code is determined to be invalid.

[0130] S405 - Rebuild Results and Archive: If version verification passes, the management server rebuilds and archives the results.

[0131] IV. Summary of Implementation Examples Based on Example 2, this embodiment introduces version identification information to prevent inspectors from using outdated inspection rules to generate "pseudo-compliance" results. It achieves a complete management loop from "policy issuance (via file)" to "policy execution verification (via short code)," solving the problem of "unknown status and uncontrollable version" for offline devices.

[0132] Example 5: Full-featured dual-enhancement solution This embodiment combines all the technical features of Embodiment 2 (data compression), Embodiment 3 (identity binding), and Embodiment 4 (version verification) to construct a high-security offline device inspection and management solution.

[0133] Before detailing this embodiment, the following assumptions are made to clarify the information in subsequent embodiments. These assumptions are for illustrative purposes only and are not intended to limit the scope of protection or numerical limitations of this invention. The assumptions are as follows: 1. There are a total of 20 items to be checked; 2. The data compression method adopts bitmap mapping, which maps each inspection result to pass (e.g., mapping "0") / fail (e.g., mapping "1"). For example, 20 compressed inspection result data is: 10101100011010111011; 3. The CRC8 integrity verification algorithm is adopted; 4. Use 14 bits of data to represent the device identification code; 5. Use 8-bit data to represent version identification information; 6. The inspection result code is encoded using Base32.

[0134] Please combine Figure 2 (Offline client inspection process) Figure 3 (Logic for generating the inspection result code) Figure 4 (Management Server Process) Understand this embodiment.

[0135] I. Offline Inspection Client-Side Processing Flow S201 - Load File, Obtain Local Hardware Information: The offline inspection client 210 loads the offline inspection data file and reads the inspection rules, device authentication information, and version identification information; in addition, it obtains local hardware information (such as MAC address).

[0136] S202 - Pre-authentication: Same as the device traceability enhancement scheme S202 pre-authentication in Implementation Example 3.

[0137] S203 - Perform check and compress data: Same as the device traceability enhancement scheme S203 in Embodiment 3. For example, the result of compressing the check data is a 20-bit binary sequence 10101100011010111011 (20-bit).

[0138] S204 - Determine the equipment identification code: Same as the equipment traceability enhancement scheme in Example 3, S204 - Determine the equipment identification code.

[0139] S205 - Combined Encoding: In this embodiment, the length of the combined binary sequence is 20 (compressed check result data) + 14 (device identification code) + 8 (version identification information) + 8 (integrity check code) = 50, without padding with zeros. The offline check client 210 concatenates the compressed check result, device identification code, and version identification information in sequence, calculates the CRC8 check value of the check result code, and obtains the integrity check information as 01110110 based on the example value. The structure of the combined binary sequence is as follows: Combined structure: [Compression check result (20 bits)][Device identifier (14 bits)][Version identification information (8 bits)][Integrity check (8 bits)], totaling 50 bits.

[0140] Combined binary sequence: [10101100011010111011][10111011001011][00001100][01110110].

[0141] S205 - Character Encoding Generation Check Result Code: The combined binary sequence of the combined encoding obtained in this embodiment is as follows: 10101-10001-10101-11011-10111-01100-10110-00011-00011-10110 Then, it is grouped and mapped to obtain a 10-character check result code: VRV3X-MWDDW.

[0142] II. Processing Flow on the Management Server Side After receiving the manually entered character sequence, the management server 100 will perform a strict multi-level verification mechanism. If any level of verification fails, the process will immediately terminate and an error will be reported. It should be noted that the verification execution order in this embodiment is merely illustrative and not intended to limit the scope of protection or technical solutions of this invention. The decoding process is as follows: S401 - Obtain and decode the inspection result code: Same as the equipment traceability enhancement scheme in Example 3, S401 - Obtain and decode the inspection result code.

[0143] S402 - Check Result Code Integrity Verification: Same as S402 - Check Result Code Integrity Verification in the Equipment Traceability Enhancement Scheme of Example 3.

[0144] S403 - Data Parsing: The integrity check of the result code has passed. The compressed check result data, device identification code, and version identification information are parsed from the data block to be checked.

[0145] S404 - Post-Authentication: Same as the Device Traceability Enhancement Scheme S404 - Post-Authentication in Implementation Example 3.

[0146] S404 - Version Verification: Same as the S404 - Version Verification solution in Example 4, which enhances version management.

[0147] S405 - Reconstruction Results and Archiving: Once all verifications are successful, the management server 100 automatically binds the reconstruction check results to the offline device based on the device identification code and archives them.

[0148] III. Summary of Implementation Examples This embodiment integrates the technical features of Embodiment 2 (data compression), Embodiment 3 (identity binding), and Embodiment 4 (version verification), combining "inspection results," "device identity," and "rule version" into one. While maintaining the short code feature suitable for manual input, it achieves efficient feedback of inspection results, automatic binding of inspection results and device identity, and consistency of inspection basis. This not only enables comprehensive compliance control of offline devices but also greatly reduces the pressure of device management and maintenance.

[0149] Example 6: Security Encryption and Timeliness Scheme This embodiment serves as a "Security Wrapper" mechanism, which can be superimposed on any of the data structures described in Embodiments 2 to 5 above. This embodiment focuses on addressing the issues of data confidentiality (preventing eavesdropping), tamper resistance, and timeliness verification (preventing replay attacks) during the transmission of the inspection result code. This embodiment provides two selectable encryption modes: Mode A (static encryption based on a preset key) and Mode B (dynamic encryption based on a time key).

[0150] I. Mode A: Static encryption based on a pre-set key This mode is suitable for scenarios where strict time synchronization is not required, but data format protection is still necessary. It is also suitable for scenarios where strict prevention of replay attacks is not required, but data format protection is still necessary to prevent the inspection results from being directly read by the naked eye or easily tampered with by non-technical personnel. Its core lies in using time-invariant keys for processing.

[0151] 1. Key Pre-setting and Agreement: The management server 100 generates an offline inspection data file for offline devices, containing a pre-set encryption key or data used to generate the encryption key. Depending on the management granularity, this key may include: (a) Organizational shared key: All offline devices under the same organizational form, such as the same unit, the same department, or the same project group, use the same key, which facilitates unified distribution and management.

[0152] (b) One-time task key: A unique key is randomly generated for each imported inspection task file. This key is only valid within the current task cycle and will not affect historical or future tasks even if it is leaked.

[0153] (c) Device binding key: The management server 100 and the offline inspection client 210 implement "one key per device" by calculating the derived key (such as Hash(RootKey + DeviceID)) based on the pre-stored root key and the device's unique identifier (such as the device's MAC address).

[0154] 2. S205 - The format retains encryption or reversible obfuscation. The offline inspection of the client's encryption process in Mode A is as follows: After generating the original combined binary sequence (including compressed check results, device identification code (if any), version identification information (if any), and integrity verification information, i.e., "plaintext"), the offline inspection client 210 reads or calculates the preset encryption key from the loaded data file.

[0155] This key can be used to perform format-preserving encryption or reversible obfuscation on plaintext sequences.

[0156] Finally, the encrypted ciphertext sequence is converted into a character-based check result code.

[0157] 3. S402 - Reverse Decryption: The decryption process on the management server side is as follows: After receiving the inspection result code, the management server 100 retrieves the corresponding preset encryption key based on the currently parsed task context or device identity.

[0158] The key is used to decrypt the data in reverse, and the integrity verification information (such as CRC) of the decrypted data is verified. If the verification passes, the data is confirmed to be valid and has not been tampered with.

[0159] II. Mode B: Dynamic Encryption Based on Time Key This mode prevents replay attacks (i.e., repeatedly submitting old compliance codes to impersonate today's inspection), but requires the offline inspection client to submit the inspection result code generated after the inspection within the result code's validity period. The result code's validity period is the preset time window when the server attempts iterative decryption.

[0160] 1. Offline inspection of the client's dynamic generation process: corresponding to Figure 2 The S205 format retains encryption steps that are either encrypted or reversibly obfuscated, and the dynamic encryption process based on time keys is as follows: Figure 5 As shown, the encryption process is as follows: S501 - Get Time Factor: Offline check client obtains the current system time.

[0161] In some scenarios, if the system time error of offline devices is large, the time factor can be obtained by manually setting the check time. Since decryption requires the accurate system time of the management server, the check time set by the inspector can only be within the server's preset time window; otherwise, the generated check result code will be invalid. Therefore, even by manually setting the check time, the time error can be guaranteed to be within the validity period. In this embodiment, the time factor... T The usage date is valid for 2 days, which means the preset time window for decryption is 2 days.

[0162] S502 - Derived Time Key: The client uses a preset root secret and the current time factor. T The currently valid time key is dynamically calculated through the key derivation function. K T .

[0163] S503 - Dynamic Encryption: Uses a time-based key. K T Perform format-preserving encryption or reversible obfuscation on combined binary sequences.

[0164] Through dynamic encryption based on time keys, even if the inspection results are exactly the same, due to the time factor... T The check result codes generated on different dates exhibit drastically different character representations. For example, the check result code generated yesterday was X9J2, while the result code generated today is P4L8.

[0165] 3. Iterative decryption and verification process of the management server: In this embodiment, the preset time window for decryption is 2 days. The steps of the S402 iterative decryption attempt of the management server 100 are as follows: Figure 6 As shown: S601 - Retrieve the next time point Ti: When starting iterative decryption, the management server 100 retrieves the current system date. If decryption fails on the currently retrieved date, the next date is used for iteration.

[0166] S602 - Derived corresponding time key K (Ti): Derive the corresponding time key using the selected date. K (Ti).

[0167] S603 - Attempt to decrypt: Using the time key K (Ti) Perform reverse decryption or reverse obfuscation on the binary ciphertext sequence obtained by Base32 decoding.

[0168] S604 - Validity Verification The management server 100 verifies the validity of the combined binary sequence obtained from the decryption attempt, using the integrity check information (CRC) within the data packet as the basis for judgment. If the data obtained from a reverse decryption fails the CRC check, it indicates that the key does not match, and the process proceeds to step S605.

[0169] If the data obtained from a reverse decryption passes the CRC check, the decryption is successful, and the date corresponding to the time key is recorded. The management server 100 then proceeds with S403 data parsing, S404 post-authentication, and version verification. Only after all verifications pass will the management server 100 reconstruct the check results, automatically bind them to the associated device, and record the time corresponding to the time key as the check time.

[0170] S605 - Determine if there are any unattended decryption time points: If there are any unattended decryption time points, select the next time point and proceed to step S601 for the next decryption attempt. If all time points within the preset time window have been used for decryption attempts, decryption is considered to have failed, and the result code is invalid.

[0171] III. Summary of Implementation Examples This embodiment provides both "static" and "dynamic" modes, applicable to embodiments two through five, improving data protection of the inspection result code while maintaining the same final inspection result code length. Those skilled in the art will understand the inspection result code generation process described in embodiments two through six, and... Figure 2 , Figure 3 , Figure 4 The flowchart and structural diagram of the inspection result code shown are for illustrative purposes only. Regardless of how the order in which the compressed result data, device identification code, version identification information, and integrity verification information are combined or concatenated in the combined binary sequence changes, whether partial or complete encryption of the combined binary sequence is performed, or whether the data in the combined binary sequence is encrypted first and then combined, or combined first and then encrypted, it only affects the specific decoding steps of the inspection result code. Similarly, using data other than date to represent time to generate a time key, the core idea is to utilize the dynamic change characteristics of the time key to protect the key information of the inspection result code while iteratively attempting decryption and verification to achieve verification and identification of the inspection time; this does not depart from the scope of protection of this invention.

[0172] Example 7 This embodiment provides a management server device deployed on an offline inspection client, including a memory and a processor. The program of the method implemented in the offline inspection client in embodiments 1-6 is burned into the corresponding processor, so that the processor implements the offline inspection method of the offline inspection client when executing the computer program.

[0173] Example 8 This embodiment provides a computer-readable storage medium storing a computer program that can be inserted into an offline inspection client. The computer program implements the methods described in embodiments 1-6 above in the offline inspection client.

[0174] Example 9 This embodiment provides a management server device, deployed on a management server, including a memory and a processor. The program of the method implemented in the management server in embodiments 1-6 is burned into the corresponding processor, so that the processor can implement the offline management method of the management server when executing the computer program.

[0175] Example 10 This embodiment provides a computer-readable storage medium storing a computer program that can be inserted into a management server. The computer program implements the management methods described in Embodiments 1-6 above in the management server.

[0176] It should be noted that the processor mentioned in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0177] The various methods, steps, and logic diagrams disclosed in the embodiments of this invention can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this invention can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The processor reads information from the storage medium and, in conjunction with its hardware, completes the steps of the above methods.

[0178] Computer-readable storage media can be memory, such as volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0179] Among them, non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory.

[0180] Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (Synchlink DRAM, SLDRAM), and direct memory bus RAM (DRRAM).

[0181] The storage media described in the embodiments of the present invention are intended to include, but are not limited to, these and any other suitable types of memory.

[0182] It should be understood that the system disclosed in the embodiments of the present invention can be implemented in other ways. For example, the division of units is merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the communication connection between units may be through some interface, server, or indirect coupling or communication connection, and may be electrical or other forms.

[0183] Furthermore, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one processing unit. The integrated unit described above can be implemented in hardware or as a software functional unit.

[0184] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0185] Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner for ease of understanding.

[0186] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for inspecting offline devices that are not connected to the internet, characterized in that, The inspection method is performed by an offline inspection client deployed on offline devices, and includes: Load the offline inspection data file generated by the management server, which contains inspection rules; both the management server and the offline inspection client know the order of the inspection rules. Perform the inspection according to the aforementioned inspection rules and generate offline inspection results; The offline inspection results are compressed to generate compressed inspection result data. The data compression method is based on bitmap mapping as the basic compression strategy, and state enumeration method is used alone or in combination according to the specific scenario: For each inspection rule, a corresponding Boolean state value or state enumeration value is generated, and the generated multiple Boolean state values ​​or state enumeration values ​​are mapped or concatenated according to the order of the inspection rules to generate compressed inspection result data of bit sequence. The compressed inspection result data and the integrity verification information used to verify integrity are concatenated or combined to generate a combined binary plaintext sequence. The plaintext sequence is then subjected to format-preserving encryption or reversible obfuscation using preset key data to obtain a ciphertext sequence. Finally, the ciphertext sequence is converted into a character-type inspection result code.

2. The method for inspecting offline devices without internet access according to claim 1, characterized in that, The inspection method also includes: Obtain the local hardware information of the offline device; Based on the predetermined generation strategy, the corresponding device identifier code is determined according to the local hardware information; The step of generating the inspection result code includes: splicing or combining the device identification code, the compressed inspection result data, and the integrity verification information.

3. The method for inspecting offline devices without internet access according to claim 2, characterized in that, The step of determining the corresponding device identifier code based on the local hardware information according to a predetermined generation strategy includes any one of the following: (a) Obtain directly from the offline inspection data file a digital identifier that is pre-associated with the local hardware information, and use it as the device identification code; (b) Determine the arrangement position index of the local hardware information in the offline inspection data file list, and use the arrangement position index as the device identifier code; (c) The local hardware information is calculated and transformed according to a preset algorithm, and bits of a preset length are extracted as the device identifier code; wherein the preset length is determined in advance based on the total number of offline devices to be inspected and the allowed hash collision probability.

4. The method for inspecting offline devices without internet access according to claim 2, characterized in that, The inspection method also includes: Before generating the inspection result code, the local hardware information is matched with the device authentication information preset in the offline inspection data file to verify the offline device identity; The check result code can only be generated after offline device authentication is successful.

5. A method for inspecting offline devices without internet access according to claim 1 or 2, characterized in that, The step of generating the inspection result code further includes: The offline inspection data file contains embedded version identification information for identifying the offline inspection data file on which the inspection is based, and the version identification information is encoded into the inspection result code.

6. The method for inspecting offline devices without internet access according to claim 1, characterized in that, The preset key data is any one of the following: Pre-set, time-invariant encryption keys obtained from offline inspection data files or data used to generate encryption keys; The time key is derived from the current inspection time.

7. An offline inspection client device, deployed on an offline device, including a memory and a processor, wherein the processor executes a computer program to implement an inspection method for a non-networked offline device as described in any one of claims 1 to 6.

8. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for inspecting an offline device not connected to the network as described in any one of claims 1 to 6.

9. A method for managing offline devices that do not connect to the internet, characterized in that, The management method is executed by the management server and includes: The management server generates an offline inspection data file for use by the offline inspection client. The offline inspection data file contains inspection rules. Both the management server and the offline inspection client know the order of the inspection rules. The management server obtains the inspection result code generated by the offline inspection client through non-network means. The inspection result code generation process is as follows: The offline inspection client performs inspections according to the inspection rules and performs data compression processing on the generated offline inspection results: For each inspection rule, a corresponding Boolean state value or state enumeration value is generated, and multiple generated Boolean state values ​​or state enumeration values ​​are mapped or concatenated according to the order of the inspection rules to generate compressed inspection result data of bit sequence. The data compression processing method is based on bitmap mapping as the basic compression strategy, and the state enumeration method is used alone or in combination according to the specific scenario; The compressed inspection result data and the integrity verification information used to verify integrity are concatenated or combined to generate a combined binary plaintext sequence. The plaintext sequence is encrypted with format preservation or reversibly obfuscated using preset key data to obtain a ciphertext sequence, and the ciphertext sequence is converted into a character-type inspection result code; The management server decodes the inspection result code to parse out the data block to be verified and the integrity verification information; it performs integrity verification on the inspection result code based on the integrity verification information; after the integrity verification is passed, it parses the compressed inspection result data from the data block to be verified, and decompresses or reverse maps the compressed inspection result data according to the order of the inspection rules to reconstruct the offline inspection result.

10. A method for managing offline devices without internet access according to claim 9, characterized in that, The data block to be verified includes a device identifier code and compressed check result data. After the integrity verification is passed, the device authentication process is also performed on the check result code. The specific process includes: By utilizing the correspondence between device authentication information and device identification code pre-stored on the management server, or by using the same preset generation strategy as offline devices, the identity of the offline device from which the compressed inspection result data originates can be determined based on the device identification code; The identified offline devices will be verified against a pre-defined list of legitimate devices.

11. A method for managing offline devices without internet access according to claim 9 or 10, characterized in that, Version identification information is embedded in the offline inspection data file. The data block to be verified also includes version identification information. After the integrity verification is passed, version verification is performed on the inspection result code. The specific process includes: The latest version identification information from the management server is compared with the version identification information in the data block to be verified to obtain the version verification result.

12. The management method for offline devices without internet access according to claim 9, characterized in that, The steps for decoding the inspection result code include: The inspection result code is reverse decrypted or deobfuscated to obtain the data block to be verified and the integrity verification information.

13. The management method for offline devices without internet access according to claim 12, characterized in that, The specific process of reverse decryption or deobfuscation includes: Within a preset time window, multiple time keys are derived based on different times, and the inspection result code is iteratively decrypted using the multiple time keys. When the validity of the data obtained in the iterative decryption attempt is verified, the decryption is confirmed to be successful; If the validity verification of the data obtained by all iterative decryption attempts fails within the entire preset time window, the decryption is deemed to have failed.

14. A management server device, comprising a memory and a processor, wherein the processor executes a computer program to implement a method for managing offline devices not connected to the network as described in any one of claims 9 to 13.

15. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for managing a non-networked offline device as described in any one of claims 9 to 13.

Images