A trusted program authentication method, device and law enforcement data recording equipment

Abstract

The application provides a trusted program identification method, which comprises the following steps: S1, intercepting an interrupt of opening a file initiated by a file system driver; S2, obtaining head data of a target file; S3, judging whether the target file is an executable program, and executing step S4 when the target file is an executable program; S4, reading all the remaining file data of the executable program, and performing SM3 password hash calculation on the remaining file data to calculate a message digest M2 of the trusted program; S5, performing SM2 signature verification calculation on the message digest M2, a program vaccine file and a vaccine public key; and S6, if the signature verification passes, responding to the interrupt of the target file by the system, and enabling the operating system to continue opening the target file and executing. The file system driver is loaded into the memory space and starts to execute when the operating system starts, so that all processes can be monitored before starting.

Description

Technical Field

[0001] This invention relates to the field of data security, and more specifically, to a trusted program authentication method, apparatus, and law enforcement data recording device. Background Technology

[0002] Trusted program authentication commonly employs remote code injection and API hooking, with the main process as follows: Step S1, Remote Code Injection (see reference) Figure 1 Step S2: Inject the detection program into the target process and wait for it to be executed. (See reference) Figure 2 ): Responsible for monitoring the specified API of the host process and filtering before and after API execution.

[0003] Typically, when controlling whether a program runs, the program's path is captured before it is launched as a process to determine if it is a trusted process. This process can be called "monitoring the process startup process." The application calls one of four system functions—CreateProcess, CreateProcessAsUser, ShellExecute, or ShellExecuteEx—to launch the program as a process. The parameter used to mark the process is the program's location.

[0004] When it's necessary to monitor the creation of child processes by a specified process in the operating system, code needs to be injected into the memory space of that specified process. Then, at a specific trigger, the hook program is executed, installing the corresponding hook program, thereby achieving the process of "monitoring the creation of a specified process in the operating system".

[0005] However, code injection requires that the target process is either starting up or already started. During the period between process startup and code injection, the process is out of control; this period is known as the "out-of-control period."

[0006] For program feature identification, current methods primarily use path recognition or program hashing. That is, when a process is detected attempting to create a new process, the path of the process's host program is compared with the paths of programs in a whitelist. If the paths match, the process is considered whitelisted and allowed to start. Otherwise, the actual startup function is not executed. Alternatively, based on the path of the process's host program, a message digest is calculated using MD5 or SHA-1 algorithms and compared.

[0007] Existing methods using code injection and API hooks present several risks:

[0008] 1. The prerequisite for code injection is that the target process is starting or has already started.

[0009] 2. Code injection may fail in the following situations: for example, the version of the public library that the hook program depends on may conflict with the version of the public library of the host program; the host program may have anti-injection capabilities, etc.

[0010] 3. The process of identifying trusted processes uses path comparison or program entity message digest comparison, which is vulnerable to impersonation.

[0011] The background description provided herein is for the purpose of generally presenting the context of this disclosure. Unless otherwise indicated herein, the material described in this section is not prior art to the claims of this application and should not be acknowledged as prior art by virtue of its inclusion in this section. Summary of the Invention

[0012] To address the aforementioned technical problems in related technologies, this invention proposes a trusted program authentication method, which includes the following steps:

[0013] S1 intercepts the interruption initiated by the file system driver to open a file;

[0014] S2, retrieve the header data of the target file;

[0015] S3, determine whether the target file is an executable program; if the target file is an executable program, execute step S4.

[0016] S4: Read out all the remaining file data of the executable program, perform SM3 cryptographic hash calculation on it, and calculate the message digest M2 of the trusted program.

[0017] Step S5: Perform SM2 signature verification calculation on message digest M2, program vaccine file, and vaccine public key;

[0018] Step S6: If the signature verification passes, respond to the system's interruption of the target file, allowing the operating system to continue opening and executing the target file.

[0019] Specifically, the interrupt for opening the file is IRP_MJ_CREATE.

[0020] Specifically, in step S3, determining whether the target file is an executable program is based on the DOS header and PE header data of the target file.

[0021] Specifically, in step S3, determining whether the target file is an executable program involves:

[0022] Step 31: Take the first two bytes of the target file address and determine whether its value is "M" or "Z";

[0023] Step 32: Obtain 4 bytes of data at the starting address of the PE header and determine whether its value is "P", "E", "0x00", or "0x00".

[0024] If the results of steps 31 and 32 are yes, then the target file is an executable program.

[0025] Specifically, the production method of the programmed vaccine is as follows:

[0026] Step B1: Read the file entity data of the trusted program into memory and save it;

[0027] In step B2, the file entity data of the trusted program is used as input parameters for the SM3 cryptographic hash algorithm to calculate the message digest M1 of the trusted program. The message digest M1 serves as the unique identifier of the trusted program.

[0028] Step B3: Using the private key of the SM2 cryptographic algorithm, perform digital signature calculation on the message digest M1 to obtain digital signature S1;

[0029] The digital signature S1 serves as the program vaccine for the WORD.EXE program and is stored in the vaccine file.

[0030] Secondly, another embodiment of the present invention provides a trusted program authentication device, which includes the following units:

[0031] The interception unit is used to intercept interrupts initiated by the file system driver to open files;

[0032] An executable program determination unit is used to obtain the header data of the target file and determine whether the target file is an executable program;

[0033] The target file message digest calculation unit is used to read out all the remaining file data of the executable program, perform SM3 cryptographic hash calculation on it, and calculate the message digest M2 of the trusted program.

[0034] The signature verification unit is used to perform SM2 signature verification calculation on the message digest M2, the program vaccine file, and the vaccine public key.

[0035] The execution unit is used to respond to the system's interruption of the target file when the signature verification is successful, so that the operating system can continue to open and execute the target file.

[0036] Specifically, the executable program determination unit determines whether the target file is an executable program based on the DOS header and PE header data of the target file.

[0037] Specifically, the executable program determination unit further includes:

[0038] The first fixed value judgment unit is used to obtain the address of the first two bytes of the target file and determine whether its value is "M" or "Z".

[0039] The second fixed value judgment unit is used to obtain 4 bytes of data at the starting address of the PE header and determine whether its value is "P", "E", "0x00", or "0x00".

[0040] Specifically, the device further includes:

[0041] The first unit of the programmed vaccine production process: used to read and store the file entity data of a trusted program into memory;

[0042] The second unit of the programmed vaccine production process: The file entity data of the trusted program is used as input parameters for the SM3 cryptographic hash algorithm to calculate the message digest M1 of the trusted program. The message digest M1 serves as the unique identifier of the trusted program.

[0043] The third unit of the vaccine production process: using a private key to perform digital signature calculation on the message digest M1 using the SM2 cryptographic algorithm, to obtain digital signature S1.

[0044] Thirdly, another embodiment of the present invention provides a law enforcement data recording device, the device including the trusted procedure authentication device as described above.

[0045] The trusted program identification method disclosed in this invention utilizes the priority loading characteristic of file system system drivers, loading them into memory and starting execution when the operating system boots up. This ensures that all processes can be monitored before startup, thus avoiding the need for code injection after program startup and better guaranteeing system security. Furthermore, when intercepting program files, this application first determines whether they are executable program files, thereby avoiding the file system driver's interception of all open files and improving interception efficiency. Further, this embodiment performs encrypted calculations on trusted program files. This embodiment uses the SM2 algorithm to encrypt the calculated message digest instead of directly using a whitelist, avoiding the problem of program file misuse or misuse due to leaked vaccine files. Attached Figure Description

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

[0047] Figure 1This is a flowchart of remote code injection;

[0048] Figure 2 This is a flowchart of API hooks;

[0049] Figure 3 This is a schematic diagram of a trusted program authentication method provided by an embodiment of the present invention;

[0050] Figure 4 This is a schematic diagram of the file structure of an executable program provided in an embodiment of the present invention;

[0051] Figure 5 This is a flowchart of the vaccine manufacturing process provided in an embodiment of the present invention;

[0052] Figure 6 This is a schematic diagram of a trusted program authentication device provided in an embodiment of the present invention;

[0053] Figure 7 This is a schematic diagram of a trusted program authentication device provided in an embodiment of the present invention. Detailed Implementation

[0054] 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 are within the scope of protection of the present invention.

[0055] Example 1

[0056] refer to Figure 3 This embodiment discloses a trusted program authentication method, which includes the following steps:

[0057] S0: Waiting for the file system driver to open the file;

[0058] S1 intercepts the interruption initiated by the file system driver to open a file;

[0059] This embodiment uses a Windows system as an example. The File System Minifilter Driver is a filter driver framework developed by Microsoft for the Windows operating system, used to develop extended functions of the file system. The operating system sends an IRP_MJ_CREATE request to open a handle to a file object or device object. When the driver calls ZwCreateFile, the operating system sends an IRP_MJ_CREATE request to perform the actual open operation.

[0060] Specifically, in this embodiment, the interrupt for opening a file is IRP_MJ_CREATE.

[0061] S2, retrieve the header data of the target file;

[0062] In this embodiment, the target file is the file corresponding to the file open operation initiated by the file driver in step S1. For example, when the driver calls ZwCreateFile, the operating system sends an IRP_MJ_CREATE request to perform the actual open operation, and the corresponding target file is ZwCreateFile.

[0063] When the IRP_MJ_CREATE interrupt is detected, this embodiment intercepts the target file opening process, that is, it does not immediately perform the file opening operation.

[0064] The specific interception method can be a callback function or other commonly used interception method in this field, which will not be elaborated in this embodiment.

[0065] S3, determine whether the target file is an executable program. If the target file is an executable program, execute step S4; otherwise, return to step S0.

[0066] This embodiment reads the DOS header and PE header data of the target file to determine whether the target file is an executable program. When an executable program is opened, it generates an executable process. In this embodiment, "executable program" describes a static file, while "executable process" describes how the executable program will be executed as a process in the operating system when it is executed. More generally, an executable program file only generates a corresponding executable process when it is executed. Therefore, this embodiment uses the terms "executable program file" and "executable process" interchangeably, but these two terms merely describe two states of a program depending on whether it is executed by the operating system.

[0067] An executable program consists of a DOS header, a PE header, a section table, and section data. The overall structure is shown in Table 1 below.

[0068] Table 1. Schematic diagram of executable program file structure

[0069]

[0070] In order to accurately identify an executable program, you only need to identify the first 176 bytes (B0h in hexadecimal) of the file, which contains the complete DOS header and part of the PE header data.

[0071] Specifically, step S3, determining whether the target file is an executable program, involves:

[0072] 31. Take the first two bytes of the target file and determine whether their values ​​are "M" or "Z";

[0073] refer to Figure 4 , Figure 4 It is an executable program. The data in its first two bytes of address, namely 00h and 01h, is a total of 2 bytes, and its value is fixed as "M" and "Z".

[0074] 32. Obtain 4 bytes of data at the starting address of the PE header and determine whether its value is "P", "E", "0x00", or "0x00".

[0075] The specific method for obtaining the starting address of the PE header is as follows: Take bytes 3C-3F of the target file; this gives the starting address of the PE header. (See reference) Figure 4 In this embodiment, the starting address of the PE header is 80h. At address 80h, four bytes of data are taken from addresses 80h, 81h, 82h, and 83h, and their values ​​are fixed as "P", "E", "0x00", and "0x00".

[0076] Specifically, in this embodiment, the address is stored in little-endian (i.e., the lowest byte at the lowest address is a 32-bit hexadecimal data: 12345678H, stored in a 32-bit storage unit, with the storage order from low byte to high byte being 0x78, 0x56, 0x34, and 0x12).

[0077] If the results of judgments 31 and 32 are yes, then the target file is an executable program.

[0078] S4: Read out all the remaining file data of the executable program, perform SM3 cryptographic hash calculation on it, and calculate the message digest M2 of the trusted program.

[0079] Step S5: Perform SM2 signature verification calculation on message digest M2, program vaccine file, and vaccine public key.

[0080] Specifically, this embodiment requires the pre-creation of a program vaccine file. The program vaccine file should be created on a computer that is not infected with malicious computer programs. The program used to create the vaccine is a genuine, safe, and reliable computer program.

[0081] A programmed vaccine is a program's unique identifier. (Reference) Figure 5 The figure is a flowchart of the vaccine production process in this embodiment, including the following steps:

[0082] Step B1: Read the file entity data of the trusted program into memory and save it.

[0083] In step B2, the file entity data of the trusted program is used as input parameters for the SM3 cryptographic hash algorithm to calculate the message digest M1 of the trusted program. The message digest M1 serves as the unique identifier of the trusted program.

[0084] For example, a user needs to make WORD.EXE a trusted program. The contents of WORD.EXE are read into memory, and then the SM3 algorithm is used to calculate the message digest data M1.

[0085] Step B3: Using the private key of the SM2 cryptographic algorithm, perform digital signature calculation on the message digest M1 to obtain digital signature S1.

[0086] The digital signature S1 serves as the program vaccine for the WORD.EXE program and is stored in the vaccine file.

[0087] Step S6: If the signature verification passes, the response system interrupts the IRP_MJ_CREATE of the target file, allowing the operating system to continue opening and executing the target file.

[0088] In step S7, if the signature verification fails, the IRP_MJ_CREATE interrupt ends, and the operating system is notified that "this program does not have permission to run".

[0089] This embodiment leverages the priority loading feature of the file system driver, loading it into memory and starting execution when the operating system boots up. This ensures all processes are monitored before startup, avoiding code injection after program launch and thus better guaranteeing system security. Furthermore, when intercepting program files, this application first determines if they are executable, avoiding the file system driver's interception of all open files and improving interception efficiency. Moreover, this embodiment performs encrypted calculations on trusted program files. Instead of using a whitelist, it uses the SM2 algorithm to encrypt the calculated message digest, preventing misuse of program files or misuse due to leaked vaccine files.

[0090] Example 2

[0091] refer to Figure 6 This embodiment discloses a trusted program authentication device, which includes the following units:

[0092] The interception unit is used to intercept interrupts initiated by the file system driver to open files;

[0093] An executable program determination unit is used to obtain the header data of the target file and determine whether the target file is an executable program;

[0094] This embodiment reads the DOS header and PE header data of the target file to determine whether the target file is an executable program.

[0095] In order to accurately identify an executable program, you only need to identify the first 176 bytes (B0h in hexadecimal) of the file, which contains the complete DOS header and part of the PE header data.

[0096] The specific executable program determination unit also includes the following sub-units:

[0097] The first fixed value judgment unit is used to obtain the address of the first two bytes of the target file and determine whether its value is "M" or "Z".

[0098] refer to Figure 4 , Figure 4 It is an executable program. The data in its first two bytes of address, namely 00h and 01h, is a total of 2 bytes, and its value is fixed as "M" and "Z".

[0099] The second fixed value judgment unit is used to obtain 4 bytes of data at the starting address of the PE header and determine whether its value is "P", "E", "0x00", or "0x00".

[0100] The specific method for obtaining the starting address of the PE header is as follows: Take bytes 3C-3F of the target file; this gives the starting address of the PE header. (See reference) Figure 4 In this embodiment, the starting address of the PE header is 80h. At address 80h, four bytes of data are taken from addresses 80h, 81h, 82h, and 83h, and their values ​​are fixed as "P", "E", "0x00", and "0x00".

[0101] Specifically, in this embodiment, the address is stored in little-endian (i.e., the lowest byte at the lowest address is a 32-bit hexadecimal data: 12345678H, stored in a 32-bit storage unit, with the storage order from low byte to high byte being 0x78, 0x56, 0x34, and 0x12).

[0102] If the results of the first fixed value judgment unit and the second fixed value judgment unit are both yes, then the target file is an executable program.

[0103] The target file message digest calculation unit is used to read out all the remaining file data of the executable program, perform SM3 cryptographic hash calculation on it, and calculate the message digest M2 of the trusted program.

[0104] The signature verification unit is used to perform SM2 signature verification calculation on the message digest M2, the program vaccine file, and the vaccine public key.

[0105] Specifically, this embodiment requires the pre-creation of a program vaccine file. The program vaccine file should be created on a computer that is not infected with malicious computer programs. The program used to create the vaccine is a genuine, safe, and reliable computer program.

[0106] A programmed vaccine is a program's unique identifier. The device also includes the following units:

[0107] The first unit of the programmed vaccine production is used to read and store the file entity data of the trusted program into memory.

[0108] The second unit of the programmed vaccine production process uses the file entity data of the trusted program as input parameters for the SM3 cryptographic hash algorithm to calculate the message digest M1 of the trusted program. The message digest M1 serves as the unique identifier of the trusted program.

[0109] For example, a user needs to make WORD.EXE a trusted program. The contents of WORD.EXE are read into memory, and then the SM3 algorithm is used to calculate the message digest data M1.

[0110] In the third unit of the vaccine production process, the private key of the SM2 cryptographic algorithm is used to perform digital signature calculation on the message digest M1 to obtain digital signature S1.

[0111] The digital signature S1 serves as the program vaccine for the WORD.EXE program and is stored in the vaccine file.

[0112] If the signature verification passes, the execution unit responds to the system's IRP_MJ_CREATE interrupt for the target file, allowing the operating system to continue opening and executing the target file; if the signature verification fails, the IRP_MJ_CREATE interrupt ends, and the operating system is notified that "this program does not have permission to run".

[0113] This embodiment leverages the priority loading feature of the file system driver, loading it into memory and starting execution when the operating system boots up. This ensures all processes are monitored before startup, avoiding code injection after program launch and thus better guaranteeing system security. Furthermore, when intercepting program files, this application first determines if they are executable, avoiding the file system driver's interception of all open files and improving interception efficiency. Moreover, this embodiment performs encrypted calculations on trusted program files. Instead of using a whitelist, it uses the SM2 algorithm to encrypt the calculated message digest, preventing misuse of program files or misuse due to leaked vaccine files.

[0114] Example 3

[0115] refer to Figure 7 , Figure 7 This is a schematic diagram of the structure of a trusted program authentication device according to this embodiment. The trusted program authentication device 20 of this embodiment includes a processor 21, a memory 22, and a computer program stored in the memory 22 and executable on the processor 21. When the processor 21 executes the computer program, it implements the steps in the above method embodiments. Alternatively, when the processor 21 executes the computer program, it implements the functions of each module / unit in the above device embodiments.

[0116] Specifically, the trusted program authentication device in this embodiment can be a law enforcement data recording device.

[0117] For example, the computer program can be divided into one or more modules / units, which are stored in the memory 22 and executed by the processor 21 to complete the present invention. The one or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the trusted program authentication device 20. For example, the computer program can be divided into the modules shown in Embodiment 2. The specific functions of each module are described in the working process of the device described in the above embodiments, and will not be repeated here.

[0118] The trusted program authentication device 20 may include, but is not limited to, a processor 21 and a memory 22. Those skilled in the art will understand that the schematic diagram is merely an example of the trusted program authentication device 20 and does not constitute a limitation on the trusted program authentication device 20. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, the trusted program authentication device 20 may also include input / output devices, network access devices, buses, etc.

[0119] The processor 21 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor 21 is the control center of the trusted program authentication device 20, connecting all parts of the trusted program authentication device 20 via various interfaces and lines.

[0120] The memory 22 can be used to store the computer program and / or modules. The processor 21 implements various functions of the trusted program authentication device 20 by running or executing the computer program and / or modules stored in the memory 22 and calling the data stored in the memory 22. The memory 22 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital card (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0121] If the modules / units integrated in the trusted program authentication device 20 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by the processor 21, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content contained in the computer-readable medium may be appropriately added to or subtracted from the content as required by the legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium may not include electrical carrier signals and telecommunication signals.

[0122] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can be specifically implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0123] 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, improvements, etc., 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 authenticating a trusted program, comprising the following steps: S1 intercepts the interruption initiated by the file system driver to open a file; S2, retrieve the header data of the target file; S3, determine whether the target file is an executable program. If the target file is an executable program, proceed to step S4; otherwise, continue to wait for the file system driver to open the file. S4: Read out all the remaining file data of the executable program, perform SM3 cryptographic hash calculation on it, and calculate the message digest M2 of the trusted program. Step S5: Perform SM2 signature verification calculation on message digest M2, program vaccine file, and vaccine public key; Step S6: If the signature verification passes, respond to the system's interruption of the target file, and allow the operating system to continue opening and executing the target file; Step S7: If the signature verification fails, the interruption ends and the operating system is notified that "this program does not have permission to run".

2. The method according to claim 1, wherein the interrupt for opening the file is IRP_MJ_CREATE.

3. According to the method of claim 1, in step S3, determining whether the target file is an executable program is based on the DOS header and PE header data of the target file.

4. The method according to claim 3, wherein step S3, determining whether the target file is an executable program, specifically comprises: Step 31: Take the first two bytes of the target file address and determine whether its value is "M" or "Z"; Step 32: Obtain 4 bytes of data at the starting address of the PE header and determine whether its value is "P", "E", "0x00", or "0x00". If the results of steps 31 and 32 are yes, then the target file is an executable program.

5. The method for producing the programmed vaccine according to claim 1 is as follows: Step B1: Read the file entity data of the trusted program into memory and save it; Step B2: The file entity data of the trusted program is used as the input parameter for the SM3 cryptographic hash algorithm to calculate the message digest M1 of the trusted program. The message digest M1 serves as the unique identifier of the trusted program. Step B3: Using the private key of the SM2 cryptographic algorithm, perform digital signature calculation on the message digest M1 to obtain digital signature S1; The digital signature S1 serves as the program vaccine for the WORD.EXE program and is stored in the vaccine file.

6. A trusted program authentication device, comprising the following units: An interception unit is used to intercept interruptions initiated by the file system driver to open files; An executable program determination unit is used to obtain the header data of the target file and determine whether the target file is an executable program; otherwise, it continues to wait for the file system driver to open the file. The target file message digest calculation unit is used to read out all the remaining file data of the executable program, perform SM3 cryptographic hash calculation on it, and calculate the message digest M2 of the trusted program. The signature verification unit is used to perform SM2 signature verification calculation on the message digest M2, the program vaccine file, and the vaccine public key. The execution unit is used to respond to the system's interruption of the target file when the signature verification is successful, allowing the operating system to continue opening and executing the target file; if the signature verification fails, the interruption is terminated and the operating system is notified that "this program does not have permission to run".

7. The apparatus according to claim 6, wherein the executable program determination unit determines whether the target file is an executable program based on the DOS header and PE header data of the target file.

8. The apparatus according to claim 7, wherein the executable program determination unit further comprises: The first fixed value judgment unit is used to obtain the address of the first two bytes of the target file and determine whether its value is "M" or "Z". The second fixed value judgment unit is used to obtain 4 bytes of data at the starting address of the PE header and judge whether its value is "P", "E", "0x00" or "0x00".

9. The apparatus according to claim 6, further comprising: The first unit of the programmed vaccine production process: used to read and store the file entity data of a trusted program into memory. The second unit of the program vaccine production: The file entity data of the trusted program is used as the input parameter for the SM3 cryptographic hash algorithm to calculate the message digest M1 of the trusted program. The message digest M1 serves as the unique identifier of the trusted program. The third unit of the vaccine production process: using a private key to perform digital signature calculation on the message digest M1 using the SM2 cryptographic algorithm, to obtain digital signature S1.

10. A law enforcement data recording device, the device comprising a trusted procedure authentication device as described in any one of claims 6-9.

Images