A Trusted Computing Software Whitelist Management Method and System

Abstract

The present invention relates to a method and system for managing a trusted computing software whitelist. This system adopts a C / S architecture, is easy to deploy, and is applicable to both local area networks and the Internet. It includes a whitelist management background and terminal devices. The whitelist management background is deployed on the server side and includes a Web service, a file service subsystem, a software package management subsystem, and a terminal device management subsystem. The terminal devices include a security client, a TEE, and a TCM. In the present invention, the entire whitelist generation does not require the intervention of software package developers, and the original software package data is modified without intrusion. The whitelist is only related to the file HASH and has nothing to do with the software path. Modifying the software installation path or file name does not affect the whitelist. The operation data is entirely signed. When there is a man-in-the-middle attack, the tampered data cannot pass the signature verification. The operation includes the whitelist data of the entire dependency chain of the software package, and it can still be used even if the software environments of different terminals are inconsistent. The packaging format can support deb, rpm, tar, and zip at the same time.

Description

Technical Field

[0001] The present invention relates to the field of computer security technology, and particularly to a method and system for managing a trusted computing software whitelist. Background Art

[0002] In the Linux system, programs are stored on the disk in the form of executable files. The executable files include both the object code of the functions to be executed and the data used by these functions. With the rapid increase in the number of security issues, passive defenses such as simple antivirus software and firewalls are no longer sufficient to protect computers from security vulnerabilities. And with the increasing importance of digital assets, the losses caused by security incidents are also growing. Therefore, a software whitelist is a more suitable active defense solution for protecting digital assets in a computer.

[0003] To manage the software installed on terminal devices in a target network, client detection software is usually deployed on the terminal devices. Using whitelist technology, the client detection software adds trusted and secure application programs to the whitelist and monitors the software installed and running on the terminal devices in real time. Only the application programs within the whitelist can run, and the application programs outside the whitelist cannot run on the terminal devices.

[0004] Traditional software whitelists are mainly for single-machine devices of Windows. However, the existing common whitelist management systems have the following problems:

[0005] 1. Adopting the background active connection terminal mode, the deployment is not convenient, or it can only be applied in a local area network;

[0006] 2. The whitelist has path restrictions, and the same software cannot be used after changing the path;

[0007] 3. It cannot solve the problem that the software environments already installed on the terminals are different and the dependencies are different when the same software package needs to be installed;

[0008] 4. There is a risk of man-in-the-middle attack in the whitelist distribution method;

[0009] 5. The generation of the whitelist requires the intervention of application software development, increasing the workload of application software development;

[0010] 6. The supported packaging formats are limited and cannot support deb, rpm, tar, and zip at the same time;

[0011] 7. The whitelist data is stored in the SPI Flash and shares the storage space with the BIOS, and the storage capacity is small. Summary of the Invention

[0012] Based on this, this patent provides a software whitelist management method and system in the Linux system (including domestic Linux systems), and through this system, whitelist management services can be provided for all terminal devices accessing the system.

[0013] A trusted computing software whitelist management system includes a whitelist management background and terminal devices. The whitelist management background is deployed on the server side and includes a Web service, a file service subsystem, a software package management subsystem, and a terminal device management subsystem; the terminal devices include a security client, a TEE, and a TCM.

[0014] The Web service is used to provide a Web management interface. Through a Web browser, users can access the Web page for various operations; the file service subsystem is used to store whitelist files; the software package management subsystem includes a whitelist generation tool, which automatically generates a whitelist, stores software packages, and distributes software packages; the terminal device management subsystem includes terminal access verification and terminal information management; the background provides an HTTPS interface, integrates with DevOps, and supports integrating the whitelist generation process into the DevOps system.

[0015] A trusted computing software whitelist management method includes the above system, and is characterized in that it includes the following steps:

[0016] S1. Whitelist generation process;

[0017] S2. Terminal connection process;

[0018] S3. Whitelist distribution process;

[0019] S4. Process for the security client to update the whitelist.

[0020] In the step S1, the user opens the Web page, logs in to the whitelist management background through two-factor authentication, and enters the software package management; uploads the developed software package to the background through the Web page. Here, the software package format can be deb, rpm, tar, or zip; the software package management subsystem calls the whitelist generation tool to scan the software package to generate a whitelist, and signs it with the SM2 private key. The whitelist generation method refers to the whitelist generation method below; after the whitelist is generated, the software package management subsystem sends the whitelist and its signature file to the file service subsystem; uploads it to the corresponding software source according to the software package format. After completion, the software package management subsystem will generate a software package entry for whitelist distribution.

[0021] The whitelist generation method includes: (1) Using the national cryptography SM2 algorithm to generate an asymmetric public-private key pair. The public key is placed in the TCM of the terminal for whitelist and operation signature verification; the private key is placed on the server for whitelist and operation signature. (2) The whitelist signature tool determines the software package format and calls the decompression command corresponding to the format to decompress the software package into a temporary directory. (3) Search for ELF files, executable files, and script files in the directory, calculate the HASH value through the national cryptography SM3 algorithm calculator to generate a HASH list, store the HASH list in a specified file, and this file is the whitelist data file. Sign the whitelist data file with the SM2 private key. The HASH list file and its signature constitute the whitelist of the software. Delete the temporary directory where the decompressed files are stored.

[0022] In the step S2, the user creates a device type according to the terminal device model / usage to obtain the ClassID; adds devices according to the number of terminal devices installed under the device type to obtain the SecretID of each terminal device; configures the ClassID and SecretID into the security client in the terminal device; the security client connects to the whitelist management background using the ClassID and SecretID through the MQTT protocol; the terminal management subsystem of the whitelist management background processes the MQTT to verify the ClassID and SecretID; the terminal management subsystem updates the status of the terminal device.

[0023] In the step S3, select a software package entry to be distributed; select the type of terminal device or terminal device to be distributed and execute the distribution. The distribution operation can be adding or deleting the whitelist. The whitelist management background sends the software package name and its version information to the terminal device through MQTT; the security client of the terminal device processes the message, parses the local dependency information of the software package, and sends the dependency package list back to the whitelist management background; the whitelist management background retrieves the software package entry according to the dependency information.

[0024] The results of the whitelist management background retrieving the software package entry according to the dependency information include: ① If the dependency is not satisfied, an error is returned; ② If the dependency is satisfied, the whitelist operation data is encapsulated and the data is signed with the SM2 private key, and the whitelist distribution method is adopted.

[0025] The whitelist distribution method includes that the whitelist operation data carries the whitelist information of the software package dependency chain and is signed.

[0026] In the step S4, after receiving the whitelist operation data, the security client passes the operation data to the TEE-TA through the D-Bus interface provided by the TEE-CA; the TEE-TA calls the TCM in the secure state to verify the whitelist operation data signature and returns the signature verification result to the security client.

[0027] The returned signature verification result includes: ① If the signature verification passes, the secure client downloads the whitelist and its signature file according to the whitelist download address in the operation data; ② If the signature verification fails, the secure client returns the status to the whitelist management background.

[0028] The beneficial effects of the present invention are as follows: The above software whitelist management method and system adopt a C / S architecture, which is easy to deploy and applicable to both local area networks and the Internet; the entire whitelist generation does not require the intervention of software package developers, and the original software package data is modified without intrusion; the whitelist is only related to the file HASH and has nothing to do with the software path, and modifying the software installation path or file name does not affect the whitelist; the entire operation data is signed, and when there is a man-in-the-middle attack, the tampered data cannot pass the signature verification; the operation includes the whitelist data of the entire dependency chain of the software package, and it can still be used in different terminal software environments with inconsistent software environments. The packaging format can support deb, rpm, tar, and zip at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 It is a composition diagram of the whitelist management system;

[0030] Figure 2 It is a system operation flow chart;

[0031] Figure 3 It is a whitelist update process diagram;

[0032] Figure 4 It is a composition diagram of the whitelist operation data;

[0033] Figure 5 It is a whitelist cache diagram. DETAILED DESCRIPTION OF THE INVENTION

[0034] To facilitate the understanding of the present invention, the present invention will be described more comprehensively below with reference to the relevant drawings. The preferred embodiments of the present invention are shown in the drawings. However, the present invention can be implemented in many different forms and is not limited to the embodiments described herein. On the contrary, these embodiments are provided to make the disclosure of the present invention more thorough and comprehensive.

[0035] A trusted computing software whitelist management system. This system adopts a C / S architecture, is easy to deploy, and is applicable to both local area networks and the Internet. The system composition is as Figure 1 shown, including a whitelist management background and a terminal device. The whitelist management background is deployed on the server side and includes a Web service, a file service subsystem, a software package management subsystem, and a terminal device management subsystem; the terminal device includes a secure client, a TEE (Trusted Execution Environment), and a TCM (Trusted Cryptography Module).

[0036] Furthermore, the Web service provides a Web management interface. Through a Web browser, users can access Web pages to perform various operations. The file service subsystem is used to store the whitelist file. The software package management subsystem includes a whitelist generation tool that automatically generates a whitelist, stores software packages, and distributes software packages. The terminal device management subsystem includes terminal access verification and terminal information management. The background provides an HTTPS interface, integrates with DevOps, and supports integrating the whitelist generation process into the DevOps system.

[0037] Furthermore, the security client runs in the Linux system, accesses the whitelist management background, responds to background messages, and downloads the whitelist file. TEE, i.e., the Trusted Execution Environment, stores the whitelist file data, provides whitelist verification services, and provides signature verification services relying on TCM. TCM, i.e., the Trusted Cryptography Module, saves keys and provides key signature verification services.

[0038] A method for managing a trusted computing software whitelist, as shown in the appendix Figure 2 shown, includes the following steps:

[0039] S1. Whitelist generation process;

[0040] S2. Terminal connection process;

[0041] S3. Whitelist distribution process;

[0042] S4. Process for the security client to update the whitelist.

[0043] Furthermore, in the S1 step, the user opens a Web page, logs in to the whitelist management background through two-factor authentication, and enters the software package management. The developed software package is uploaded to the background through the Web page. Here, the software package format can be deb, rpm, tar, or zip. The software package management subsystem calls the whitelist generation tool to scan the software package to generate a whitelist, and signs it with the SM2 private key. The whitelist generation method refers to the whitelist generation method below. After the whitelist is generated, the software package management subsystem sends the whitelist and its signature file to the file service subsystem. According to the software package format, it is uploaded to the corresponding software source, such as the deb package is uploaded to the apt source, the rpm package is uploaded to the yum source, and tar and zip are uploaded to the sftp. After completion, the software package management subsystem will generate a software package entry for whitelist distribution.

[0044] Further, in step S2, the user opens a Web page, logs in to the whitelist management background through two-factor authentication, and enters terminal management; the user creates a device type according to the terminal device model / usage to obtain a ClassID; adds devices under the device type according to the number of installed terminal devices to obtain a SecretID for each terminal device; configures the ClassID and SecretID into the security client in the terminal device; the security client uses the ClassID and SecretID to connect to the whitelist management background through the MQTT (TLS) protocol; the terminal management subsystem of the whitelist management background processes the MQTT (TLS) to verify the ClassID and SecretID; the terminal management subsystem updates the status of the terminal device.

[0045] Further, in step S3, the user opens a Web page, logs in to the whitelist management background through two-factor authentication, and enters software package management; selects a software package entry to be distributed; selects the terminal device type or terminal device to be distributed, and executes the distribution. The distribution operation can be adding or deleting. The whitelist management background sends the software package name and its version information to the terminal device through MQTT (TLS); the security client of the terminal device processes the message, parses the local dependency information of the software package, and sends the dependency package list back to the whitelist management background; the whitelist management background retrieves the software package entry according to the dependency information:

[0046] 1) If the dependency is not satisfied, an error is returned;

[0047] 2) If the dependency is satisfied, the whitelist operation data is encapsulated, and the data is signed using the SM2 private key. The format refers to the whitelist distribution method below.

[0048] Further, in step S4, after receiving the whitelist operation data, the security client passes the operation data to the TEE-TA through the D-Bus interface provided by the TEE-CA; the TEE-TA calls the TCM in the secure state to verify the signature of the whitelist operation data and returns the signature verification result to the security client:

[0049] 1) If the signature verification passes, the security client downloads the whitelist and its signature file according to the whitelist download address in the operation data

[0050] 2) If the signature verification fails, the security client returns the status to the whitelist management background

[0051] After the security client finishes downloading the whitelist, it notifies the TEE-TA through the D-Bus of the TEE-CA; the TEE-TA reads the whitelist and performs an SM3 digest comparison with the operation data obtained in the previous step. If the comparison passes, the whitelist is updated, and the update result is returned to the security client through the TEE-CA; the security client feeds back the result to the whitelist management background.

[0052] Furthermore, the above white list generation method refers to the process of generating a software package by the white list generation tool after the software package is uploaded to the white list management background, including the following steps:

[0053] (1) Generate an asymmetric public-private key pair using the national cryptography SM2 algorithm. The public key is placed in the TCM of the terminal for white list and operation signature verification; the private key is placed on the server for white list and operation signature.

[0054] (2) The white list signature tool determines the software package format and calls the decompression command corresponding to the format to decompress the software package into a temporary directory.

[0055] (3) Search for ELF files, executable files, and script files in the directory, calculate the HASH value through the national cryptography SM3 algorithm calculator to generate a HASH list, store the HASH list in a specified file. This file is the white list data file, and use the SM2 private key to sign the white list data file. The HASH list file and its signature constitute the white list of the software.

[0056] (4) Delete the temporary directory where the decompressed files are stored.

[0057] Advantages of this method:

[0058] ① The entire white list generation does not require the intervention of the software package developer, and the original software package data is modified with zero intrusion.

[0059] ② The white list is only related to the file HASH and has nothing to do with the software path. Modifying the software installation path or file name does not affect the white list.

[0060] Furthermore, as Figure 4 shown, the above white list distribution method includes: the white list information of the software package dependency chain is carried in the white list operation data and signed;

[0061] Composition of the white list operation data: ① Operation type: add, delete; ② Number of software packages: that is, the number of "software package information" included in this message; ③ Signature length: the number of bytes of the "operation data signature"; ④ Software package information: the white list information of the software package and its dependent packages, one for each package; ⑤ Operation signature data: perform SM2 signature for the operation type, number of software packages, signature length, software package information [1...n].

[0062] Composition of a single software package information:

[0063] ① Software package name: includes name, version, platform architecture, package format

[0064] ② HASH length: the number of bytes of the HASH value of the white list data file

[0065] ③Whitelist file HASH value: The HASH value of the whitelist data file

[0066] Advantages of this method:

[0067] ①The entire signature of the operation data. When there is a man-in-the-middle attack, the tampered data cannot pass the signature verification;

[0068] ②Operate on the whitelist data including the entire dependency chain of the software package, which can still be used even if the software environments of different terminals are inconsistent.

[0069] Such as Figure 5 As shown, the whitelist storage method used in this method includes the following steps:

[0070] ①The whitelist is encrypted and stored in the file system of the REE through the TEE-TA, with relatively no storage capacity limit;

[0071] ②The storage of the whitelist is a typical application scenario of a large number of reads and a small number of writes. To cope with the situation of a large number of whitelist storage lookups, the whitelist data is loaded into the memory for caching when the TEE-TA is started;

[0072] ③Caching method:

[0073] Construct a lookup table with a length of 255, and each table element has a pointer to a HASH list;

[0074] For example, if the lookup table

[00] points to a HASH list, the HASH values starting with "00" are stored in this table. Excluding "00", the sub-table only saves the values after "00";

[0075] ④When it is necessary to verify whether the HASH is in the whitelist, use the first byte of the HASH value to be verified as the index. This index is the subscript of the hash_prefix_table, and loop through the comparison in the list pointed to by hash_prefix_table[index], reducing the amount of comparison. In the extreme case, only 1 / 256 of the comparison amount;

[0076] ⑤When the whitelist is updated, synchronously update the cache table and the storage file. The data is completely cached in the memory and can be compared at high speed.

[0077] After the whitelist is updated, the TEE can support various application software in the REE to perform various application security management based on the whitelist by providing the REE driver and library.

[0078] The technical features of the above-described embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this specification.

[0079] The above-described embodiments merely represent several implementation manners of the present invention. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several modifications and improvements can still be made, and these all fall within the protection scope of the present invention. Therefore, the protection scope of the invention patent shall be subject to the appended claims.

Claims

1. A trusted computing software whitelist management method, characterized in that The method is based on a trusted computing software whitelist management system, and the method includes the following steps: S1. Whitelist generation process; S2. Terminal connection process; S3. Whitelist distribution process; S4. Process for the security client to update the whitelist; Among them, the trusted computing software whitelist management system includes a whitelist management background and terminal devices. The whitelist management background is deployed on the server side and includes a Web service, a file service subsystem, a software package management subsystem, and a terminal device management subsystem; the terminal devices include a security client, a TEE, and a TCM; In the S1 step, the user opens a Web page, logs in to the whitelist management background through two-factor authentication, and enters the software package management; uploads the developed software package to the background through the Web page, and the software package format is any one of deb, rpm, tar, or zip; the software package management subsystem calls the whitelist generation tool to scan the software package to generate a whitelist, and signs it with the SM2 private key; The whitelist generation method includes: ① Using the national secret SM2 algorithm to generate an asymmetric public-private key pair, placing the public key in the TCM of the terminal for whitelist and operation signature verification; placing the private key on the server for whitelist and operation signature; ② The whitelist signature tool determines the software package format and calls the decompression command corresponding to the format to decompress the software package to a temporary directory; ③ Search for ELF files, executable files, and script files in the directory, calculate the HASH value through the national secret SM3 algorithm calculator to generate a HASH list, store the HASH list in a specified file, and this file is the whitelist data file. Sign the whitelist data file with the SM2 private key. The HASH list file and its signature constitute the whitelist of the software; delete the temporary directory where the decompressed files are stored; In the S3 step, select a software package entry to be distributed; select the type of terminal device or terminal device to be distributed, and execute the distribution. The distribution operation can be adding or deleting the whitelist. The whitelist management background sends the software package name and its version information to the terminal device through MQTT; the terminal device security client processes the message, parses the local dependency information of the software package, and sends the dependency package list back to the whitelist management background; the whitelist management background retrieves the software package entry according to the dependency information; The results of the whitelist management background retrieving the software package entry according to the dependency information include: ① If the dependency is not satisfied, an error is returned; ② If the dependency is satisfied, the whitelist operation data is encapsulated and signed with the SM2 private key, and the whitelist distribution method is adopted; among them, the whitelist operation data consists of: ① Operation type; ② Number of software packages; ③ Signature length; ④ Software package information: whitelist information of the software package and its dependency packages, one for each package; ⑤ Operation signature data; The whitelist distribution method includes that the whitelist operation data carries the whitelist information of the software package dependency chain and is signed.

2. The method according to claim 1, wherein, In the step S2, the user creates a device type according to the terminal device model or usage to obtain a ClassID; adds devices according to the number of terminal devices under the device type to obtain a SecretID for each terminal device; and configures the ClassID and SecretID into the security client in the terminal device. The security client connects to the whitelist management backend using the ClassID and SecretID through the MQTT protocol. The terminal management subsystem of the whitelist management backend processes the MQTT verification of the ClassID and SecretID. The terminal management subsystem updates the status of the terminal device.

3. The method according to claim 1, wherein In the step S4, after receiving the whitelist operation data, the security client transfers the operation data to the TEE-TA through the D-Bus interface provided by the TEE-CA; the TEE-TA calls the TCM in the secure state to verify the signature of the whitelist operation data and returns the signature verification result to the security client.

4. The method according to claim 3, wherein The returned signature verification result includes: ① If the signature verification passes, the security client downloads the whitelist and its signature file according to the whitelist download address in the operation data; ② If the signature verification fails, the security client returns the status to the whitelist management backend.

5. A trusted computing software whitelist management system, which applies the trusted computing software whitelist management method described in any one of claims 1-4, characterized in that, The Web service is used to provide a Web management interface. Through a Web browser, users can access the Web page to perform various operations; the file service subsystem is used to store the whitelist file; the software package management subsystem includes a whitelist generation tool, automatically generates the whitelist, stores the software package, and distributes the software package. The terminal device management subsystem includes terminal access verification and terminal information management; the backend provides an HTTPS interface, integrates with DevOps, and supports integrating the whitelist generation process into the DevOps system.

Images