Bidirectional encryption verification method and device for key file and storage medium

Abstract

The embodiment of the invention discloses a key file bidirectional encryption verification method and device and a storage medium, and the method comprises the steps: selecting one of processes pulled up from a verification background process as a verification application process when a system is started; the verification application process and the verification background process generate starting verification parameters according to the starting parameters of the two pre-selected services, and the verification application process generates handshake verification character strings according to confusion of the starting verification parameters and the verification data character strings; the verification background process receives a handshake verification character string sent by the verification application process and carries out handshake verification, and after the handshake verification succeeds, the verification background process and the verification application process utilize preset verification parameters to carry out verification background process integrity verification; and when the integrity requirement is met, decrypting the binary file by using a public key held by the verification background process, and obtaining a binary file integrity detection result according to a decryption result.

Description

Technical Field

[0001] The present invention relates to the field of digital security technology, and particularly to a method, device and storage medium for two-way encryption verification of key files. Background Art

[0002] In today's digital age, software security is of crucial importance. On the one hand, low software security may lead to serious security vulnerabilities; on the other hand, low software security may also affect the reputation of enterprises and the operation of businesses. Therefore, ensuring the integrity and security of software during the distribution process is the key to protecting the interests of enterprises and users. Currently, in the Linux system, security prevention technologies such as Trusted Platform Module technology, Integrity Measurement Architecture, and digital signature technology are mainly adopted.

[0003] The Trusted Platform Module (TPM) technology aims to provide hardware-based security-related functions. The TPM chip is a secure encryption processor that can perform encryption operations. The chip is embedded with multiple physical security mechanisms to ensure its integrity and security, and malicious software cannot easily modify the security functions of the TPM.

[0004] The Integrity Measurement Architecture (IMA) is mainly implemented by patching the kernel. When an application runs, a dynamic link library is loaded, or a kernel module is loaded, IMA measures the code and key data (such as configuration files and structured data) used, and extends the measurement result to the Platform Configuration Register (PCR) PCR10. It also creates and maintains a measurement list (ML). During verification, the verifier compares the measurement list ML with the PCR measurement value signed by the TPM to determine the credibility of the program.

[0005] The digital signature technology generates a signature by encrypting the hash value of a file with the private key SK of the sender. The receiver can use the public key PK of the sender to verify the signature, thereby ensuring that the file has not been maliciously modified and was indeed sent by the sender. Only users with the corresponding public key can verify the integrity and authenticity of the data, effectively preventing data forgery or malicious modification.

[0006] Currently, TPM technology relies on dedicated TPM hardware chips and requires complex system integration and configuration, which increases costs and complexity and limits its application scope and popularity. In terms of current operating systems on the market, including Windows (only a few versions are configured with TPM), Linux (Ubuntu, CentOS, SUSE), etc., there are situations where the environment is untrusted, and the binary files of programs can be easily modified. For the file measurement mechanism based on IMA or the digital signature verification mechanism based on GPG, on the Linux operating system, the IMA file measurement mechanism can be turned off and the digital signature check of GPG can be ignored through high-privilege operations (such as root privilege), and the integrity of critical files cannot be fundamentally guaranteed. Summary of the Invention

[0007] Embodiments of the present invention provide a method, device, and storage medium for two-way encryption verification of critical files to solve the technical problem in the prior art that the integrity of critical files cannot be guaranteed.

[0008] In a first aspect, an embodiment of the present invention provides a method for two-way encryption verification of critical files, including:

[0009] When the system starts, select one process from the processes pulled up by the verification background process as the verification application process;

[0010] The verification application process and the verification background process generate startup verification parameters according to the startup parameters of two pre-selected services, and the verification application process generates a handshake verification string by confusing the startup verification parameters and the verification data string;

[0011] The verification background process receives the handshake verification string sent by the verification application process and performs handshake verification. After the handshake verification is successful, the verification background process and the verification application process use the preset verification parameters to perform integrity verification of the verification background process;

[0012] When the integrity requirement is met, decrypt the binary file using the public key held by the verification background process, and obtain the integrity detection result of the binary file according to the decryption result. In a second aspect, an embodiment of the present invention further provides a device for two-way encryption verification of critical files, including:

[0013] A selection module, configured to select one process from the processes pulled up by the verification background process as the verification application process when the system starts;

[0014] A confusion module, configured to generate startup verification parameters by using the verification application process and the verification background process according to the startup parameters of two pre-selected services, and the verification application process generates a handshake verification string by confusing the startup verification parameters and the verification data string;

[0015] A handshake verification module is used to receive a handshake verification string sent by a verification application process by means of a verification background process and perform handshake verification. After the handshake verification is successful, a process is selected from the processes launched by the verification background process as the verification application process;

[0016] A verification module is used to use the verification background process and the verification application process to perform integrity verification of the verification background process by using preset verification parameters;

[0017] A decryption module is used to decrypt a binary file by using the public key held by the verification background process when the integrity requirement is met, and obtain a binary file integrity detection result according to the decryption result. Thirdly, an embodiment of the present invention further provides a storage medium containing computer-executable instructions, and the computer-executable instructions are used to execute the key file two-way encryption verification method provided in the above embodiment when executed by a computer processor.

[0018] The key file two-way encryption verification method, device and storage medium provided by the embodiments of the present invention include: when the system starts, selecting one of the processes launched by the verification background process as the verification application process; the verification application process and the verification background process generate startup verification parameters according to the startup parameters of two pre-selected services, and the verification application process generates a handshake verification string by confusing the startup verification parameters and the verification data string; the verification background process receives the handshake verification string sent by the verification application process and performs handshake verification. After the handshake verification is successful, a process is selected from the processes launched by the verification background process as the verification application process; the verification background process and the verification application process use preset verification parameters to perform integrity verification of the verification background process; when the integrity requirement is met, decrypt the binary file by using the public key held by the verification background process, and obtain a binary file integrity detection result according to the decryption result. For a maliciously modified binary background, it not only gets rid of the dependence on the support of the hardware chip, encrypts the key file to be verified, but also uses a two-way encryption verification mechanism to ensure the integrity of the verification background; on this basis, a digital signature technology is adopted to ensure the integrity of the key file in the system by judging whether the hash values obtained by verifying the signatures of the key files are the same. And a non-critical data matching and confusion algorithm is used to isolate maliciously modified binary files that cannot be directly transplanted between different versions of the operating system and between different machines burned with the same version, increasing the workload of malicious modification and the difficulty of malicious modification, and ensuring the security of the entire system at the macroscopic level. Description of the Drawings

[0019] By reading the detailed description of the non-restrictive embodiments with reference to the following drawings, other features, objects and advantages of the present invention will become more obvious:

[0020] Figure 1It is a schematic flowchart of the two-way encryption verification method for critical files provided in Embodiment 1 of the present invention;

[0021] Figure 2 It is a schematic flowchart of the two-way encryption verification method for critical files provided in Embodiment 2 of the present invention;

[0022] Figure 3 It is a schematic structural diagram of an ELF file in the two-way encryption verification method for critical files provided in Embodiment 2 of the present invention;

[0023] Figure 4 It is a schematic structural diagram of the two-way encryption verification device for critical files provided in Embodiment 3 of the present invention. Detailed implementation manners

[0024] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the present invention, rather than limiting the present invention. Additionally, it should be noted that for the convenience of description, only parts related to the present invention are shown in the drawings rather than all the structures.

[0025] Embodiment 1

[0026] Figure 1 It is a flowchart of the two-way encryption verification method for critical files provided in Embodiment 1 of the present invention. This embodiment is applicable to the situation of non-hardware two-way encryption verification of critical files in an untrusted environment based on a domestic operating system. This method can be executed by a two-way encryption verification device for critical files, and specifically includes the following steps:

[0027] Step 110, when the system starts, select one process from the processes pulled up by the verification background process as the verification application process.

[0028] In this embodiment, when the system starts for the first time, that is, during the first startup process after the system is burned, select one process from a preset system core process set as the verification background process. The system core process set may include the system startup daemon systemd of the Kylin operating system, the graphics service process Xorg, the key auxiliary process ukui-settings-daemon of the system, the core process ukui-session of the system, etc. Select one process from them as the verification background process.

[0029] Correspondingly, select one process from the processes pulled up by the verification background process as the verification application process. Optionally, the verification application process is also one of the processes in the system core integration set.

[0030] Step 120, the verification application process and the verification background process generate startup verification parameters based on the startup parameters of two pre-selected services. The verification application process generates a handshake verification string by confusing the startup verification parameters and the verification data string.

[0031] Exemplarily, the verification application process and the verification background process generate startup verification parameters based on the startup parameters of two pre-selected services, and the verification application process generates a handshake verification string by confusing the preset verification parameters and the verification data string, which may include: obtaining the remainders of the milliseconds when two pre-selected services are started during the system startup process divided by a specified prime number as the starting point and the ending point of the handshake verification field respectively; the verification application process replaces the binary numbers of other parts of the position where the original verification string is embedded except for the starting point and the ending point of the handshake verification field with random binary numbers to generate the verification string for the verification application process to be verified.

[0032] Since the absolute startup order of services between different devices is different, and the hardware conditions of the devices are not completely the same (even if the hardware models are the same, there are differences in the performance of memory, CPU, and disk under the same voltage between devices), for two specified services, their millisecond-level startup times will surely not be exactly the same, including two startups of the same machine, and their startup times are also different. Therefore, it can be used as the basis for device isolation and used for confusion during system startup.

[0033] Among them, the verification data string can be written during system flashing. For the verification application process, after the verification background process is compiled, the corresponding verification data string can be embedded into the specified position of the verification application process so that the verification application process can read the verification data string. Further, a specified string encryption algorithm can be used to encrypt the verification data string for the one-to-one mapping relationship of the string to further improve security.

[0034] Step 130, the verification background process receives the handshake verification string sent by the verification application process and performs handshake verification.

[0035] Exemplarily, it may include: the verification background process reads characters from the starting point to the ending point of the handshake verification field in the handshake verification string and performs handshake verification with the data obtained at the corresponding position of the pre-stored verification parameters.

[0036] The verification application process sends the handshake verification string after obfuscation to the verification background process through the above obfuscation process. Since the verification background process also knows the verification data string, and also knows the starting point and the ending point therein, and can obtain the data within the range of the starting point and the ending point. It compares the data within the same range with the data in the verification data string. When they are consistent, it can be determined that the handshake verification is successful and it is determined that no attack has occurred. Exemplarily, the verification application process and the verification background process communicate through DBus. DBus is a message-based bus system that allows different applications and components to communicate through message passing. It uses message queues to transfer information and supports asynchronous operations. DBus has the characteristics of low latency, low overhead, and high availability. It provides a standardized method for software components written in different languages to cooperate with each other and share information. Since DBus is divided into a server side and a client side. If an application sends a message as a client, an intruder only needs to hijack this DBus and then return the wrong DBus information to the client, so that the core information of the critical file can be easily modified, affecting the authenticity of the system data, and the traditional file security prevention technology cannot effectively identify this type of behavior. Therefore, in this embodiment, handshake verification is required to prevent the wrong DBus information after being hijacked from affecting the handshake verification between the verification background process and the verification application process, as well as the subsequent integrity verification. In addition, the socket method can also be used for communication.

[0037] Step 140, after the handshake verification is successful, the verification background process and the verification application process perform integrity verification of the verification background process using preset verification parameters.

[0038] Exemplarily, it may include: when the verification application process starts, sending the preset verification parameters of the verification application process to the verification background process; the verification background process verifies the identity of the verification application process according to the preset verification parameters, and when the verification is successful, sends its own key field corresponding to the identity to the verification application process; the verification application process decrypts the own key field and returns the decryption result to the verification background process; the verification background process matches the decryption result with the decryption information of its own key field, and when the matching is successful, determines that the verification background process has integrity.

[0039] Optionally, the verification parameters can be pre-written into the system during the system flashing process. Among them, there can be multiple verification parameters, and each verification parameter corresponds to a process that may be launched. The verification background process stores the verification parameters corresponding to all processes that may be launched, and each process stores the corresponding verification parameter. The verification application process can send the verification parameter it holds to the verification background process. The verification background process can determine the identity of the verification application process based on the verification parameter and send its own key field pre-written during system flashing to the verification application process. The verification application process decrypts the own key field and returns the decryption result to the verification background process; the verification background process matches the decryption result with the decryption information of its own key field. When the match is successful, it is determined that the verification background process is complete. Further, communication can also be carried out through the DBus or socket method.

[0040] Step 150, when the integrity requirement is met, use the public key held by the verification background process to decrypt the binary file, and obtain the binary file integrity detection result according to the decryption result.

[0041] When it is determined that the verification background process meets the integrity requirement, that is, the verification background process has not been hijacked or modified, the public key set by the verification background process can be used to decrypt the key binary file encrypted and signed with the corresponding private key, and according to the decryption result, the signature is verified to determine that all binary files meet the integrity verification detection result.

[0042] In this embodiment, when the system starts, one process is selected from the processes pulled up by the verification background process as the verification application process; the verification application process and the verification background process generate startup verification parameters according to the startup parameters of two pre-selected services, and the verification application process mixes and generates a handshake verification string according to the startup verification parameters and the verification data string; the verification background process receives the handshake verification string sent by the verification application process and performs handshake verification. After the handshake verification is successful, one process is selected from the processes pulled up by the verification background process as the verification application process; the verification background process and the verification application process use the preset verification parameters to verify the integrity of the verification background process; when the integrity requirements are met, the public key held by the verification background process is used to decrypt the binary file, and the integrity detection result of the binary file is obtained according to the decryption result. For the maliciously modified binary background, it not only gets rid of the dependence on the support of the hardware chip, encrypts the key files to be verified, but also uses a two-way encryption verification mechanism to ensure the integrity of the verification background; on this basis, digital signature technology is adopted to ensure the integrity of the key files in the system by judging whether the hash values obtained by verifying the signatures of the key files are the same. And a non-critical data matching and confusion algorithm is used to isolate the maliciously modified binary files between different versions of the operating system and between different machines burned with the same version, which cannot be directly transplanted, increasing the workload of malicious modification and the difficulty of malicious modification, and ensuring the security of the entire system at the macro level.

[0043] In a preferred implementation manner of this embodiment, before selecting one process from the processes pulled up by the verification background process as the verification application process when the system starts, the following steps can be further added to the method: when the system starts for the first time, one process is selected from the preset system core process set as the verification background process; the verification background process randomly generates a random string with a specified length, and arranges the characters in the random string according to the difference of the set position order in the pre-set feature protection sequence to form its own verification string; correspondingly, the step of selecting one process from the processes pulled up by the verification background process as the verification application process when the system starts can be specifically optimized as: when the system starts and after the verification background process starts, characters are extracted from the self-verification string according to the set position, and the extracted string is matched with the feature protection sequence. After the matching is successful, one process is selected from the processes pulled up by the verification background process as the verification application process. And the step of the verification background process randomly generating a random string with a specified length can be specifically optimized as: defining a region as a preset number of characters corresponding to the ASCII values from the first position to the second position, randomly sampling the defined region to generate uniformly distributed random numbers; by mapping the generated random numbers to the characters in the character set, a random string is constructed to form a random string with a specified length.

[0044] Exemplarily, a pseudo-random number generator can be utilized to randomly generate a random string segment of a specified length K (K >> 87) from 87 characters with ASCII values ranging from 33 to 119. Meanwhile, an encrypted feature protection sequence customized by the operating system publisher is sequentially inserted into multiple specified positions of this generated string of data, and they are mixed into a verification data string. After the verification background is started, when the data at the specified positions of the verification data string is extracted, the read feature protection sequence is compared with the encrypted result of the feature sequence built into the system. If they do not match, it is considered that the feature field has been maliciously modified, and the system startup is terminated. And at each system startup, the feature protection sequence comparison is first performed, and whether to normally execute the handshake verification is determined according to the comparison result. Further, it is avoided that the verification background process is hijacked and tampered with.

[0045] Embodiment 2

[0046] Figure 2 FIG. is a schematic flowchart of the key file two-way encryption verification method provided by Embodiment 2 of the present invention. This embodiment is optimized based on the above embodiment. Decrypting the binary file using the public key held by the verification background process, and obtaining the integrity detection result of the binary file according to the decryption result is specifically optimized as: embedding the public key PK into the code segment executed by the verification background process for subsequent signature verification; obtaining the encrypted binary file *_en.so; obtaining the digital signature section H_en from the encrypted binary file using a preset offset value; performing signature verification on H_en using the public key PK to obtain the encrypted hash value H_p; recalculating the hash value H_n of the key section of the binary file *_en.so and comparing H_p and H_n; when they are consistent, it is determined that the binary file is complete and has not been tampered with. Correspondingly, the method can also add the following steps: using the libelf library to read a preset part of the ELF section of the protected key binary file, encrypting using an algorithm to obtain the feature value H; signing the feature value H using the private key SK to generate the digital signature H_en; embedding the signature H_en into a specific offset position of the file, and repackaging it into a new binary file without affecting the function of the binary file.

[0047] See Figure 2 For the key file two-way encryption verification method, it includes:

[0048] Step 210, at system startup, select one of the processes pulled up by the verification background process as the verification application process.

[0049] Step 220, the verification application process and the verification background process generate startup verification parameters according to the startup parameters of two pre-selected services, and the verification application process mixes the startup verification parameters and the verification data string to generate a handshake verification string.

[0050] Step 230: The verification background process receives the handshake verification string sent by the verification application process and conducts handshake verification. After the handshake verification is successful, the verification background process and the verification application process use preset verification parameters to perform integrity verification on the verification background process.

[0051] Step 240: When the integrity requirement is met, a public-private key pair is generated and maintained, and the public key PK is embedded into the code segment executed by the verification background process for subsequent signature verification processes.

[0052] In this embodiment, the asymmetric encryption algorithm RSA can be used. Compared with the symmetric encryption algorithm, asymmetric encryption provides higher security and a wider range of applications. The security of RSA depends on the difficulty of factoring large numbers, and there is currently no effective attack method. In addition, RSA integrates encryption and digital signature functions and is widely used in many fields such as digital certificates and VPNs. The specific process of key generation and maintenance is as follows: Use the openssl tool to generate the public key of RSA (the public key PK is used to verify signatures) and the private key (the private key SK is used for digital signatures). The public key PK is embedded into the code segment in the verification background for subsequent signature verification processes, while the private key SK will be passed to the encryption feedback mechanism for the key segment encryption module to generate digital signatures.

[0053] Step 250: Use the libelf library to read the preset part ELF section of the protected critical binary file, use an algorithm to encrypt it to obtain the eigenvalue H; use the private key SK to sign the eigenvalue H to generate the digital signature H_en; embed the signature H_en at a specific offset of the file, and repackage it into a new binary file without affecting the function of the binary file.

[0054] Figure 3 It is a schematic diagram of the structure of the ELF file in the key file two-way encryption verification method provided by the second embodiment of the present invention. Refer to Figure 3 , The ELF (Executable and Linkable Format) file of the Linux system, that is, the binary file, is a widely used file format that represents executable files, relocatable object code, and shared libraries on Unix and Unix-like systems, such as Figure 3As shown, the ELF file consists of four parts: a file header, a program header table, a section header table, and sections. The file header (FileHeader) is at the beginning of the ELF file and contains information about the overall structure of the file, such as the file type, architecture, entry point address, etc. The program header table: defines how to map the file into memory. It contains information for loading the file into memory, such as the location and size of each segment. This is crucial for the loading and running of executable files. The section header table: describes the attributes of each section in the file. Sections usually include a code segment, a data segment, a symbol table, a string table, etc. The section header table provides detailed information about the location, size, and other attributes of these sections. Sections can be relocatable, meaning that the linker can modify them during linking. Sections are the actual content part of the ELF file, including the program's code, data, symbol information, and other additional information for linking and debugging. Each section has a specific purpose and is managed and described by the section header table. Common sections include:.text: stores the executable instructions of the program;.data: stores initialized global variables and static variables;.bss: stores uninitialized global variables and static variables;.symtab: symbol table, containing symbol information used in the program;.strtab: string table, storing the names in the symbol table.

[0055] The encrypted backhaul mechanism uses the private key SK. First, it uses the libelf library to read the preset part of the ELF sections of the protected critical binary file. Exemplarily, a preset part of the ELF sections can be specified. An algorithm is used to encrypt and obtain the eigenvalue H to ensure the integrity of the file. The private key SK is used to sign the eigenvalue H to generate the digital signature H_en. Only the party holding the corresponding public key can verify its signature, thus ensuring that the encrypted field cannot be directly cracked. The signature is embedded at a specific offset in the file, and the file is repackaged into a new binary file without affecting the binary file's functionality. First, the digital signature H_en can be embedded as a new ELF section into the binary file to form *_en.so, and then *_en.so is passed into the list of encrypted binary files. Exemplarily, encryption and digital signature can be performed on the.text section and.data section of the protected binary file. The.text section stores the executable instructions of the program, and the.data section stores the initialized global variables and static variables. Encrypting and digitally signing these two critical ELF sections can ensure that changes to the binary file are recognized in a timely manner. Additionally, the digital signature H_en is embedded as a new ELF section into the binary file, which is packaged into a new binary file and stored in the list of encrypted binary files.

[0056] Step 260: Obtain the digital signature section H_en from the encrypted binary file using a pre-set offset value, verify the signature of H_en using the public key PK, and obtain the encrypted hash value H_p.

[0057] Among them, the pre-set offset value corresponds to the previously mentioned pre-agreed part of the ELF section, thereby determining the corresponding digital signature section H_en of this part, and verifying the signature of H_en using the previously saved public key PK to obtain the encrypted hash value H_p.

[0058] Step 270: Recalculate the hash value H_n of the key section of the binary file *_en.so, and compare H_p and H_n. When they are consistent, it is determined that the binary file is complete and has not been tampered with.

[0059] If the hash values are inconsistent, it means that the file integrity has been damaged, and a corresponding system prompt will be popped up on the system desktop through the system's notification interface.

[0060] In this embodiment, by decrypting the binary file using the public key held by the verification background process and obtaining the binary file integrity detection result according to the decryption result, it is specifically optimized as follows: embedding the public key PK into the code segment executed by the verification background process for subsequent signature verification; obtaining the encrypted binary file *_en.so; obtaining the digital signature section H_en from the encrypted binary file using a pre-set offset value; verifying the signature of H_en using the public key PK to obtain the encrypted hash value H_p; recalculating the hash value H_n of the key section of the binary file *_en.so and comparing H_p and H_n; when they are consistent, it is determined that the binary file is complete and has not been tampered with. Correspondingly, the method can also add the following steps: using the libelf library to read the pre-set part of the ELF section of the protected key binary file, using an algorithm to encrypt to obtain the eigenvalue H; signing the eigenvalue H using the private key SK to generate the digital signature H_en; embedding the signature H_en into a specific offset position of the file and repackaging it into a new binary file without affecting the function of the binary file. Using an asymmetric encryption algorithm to digitally sign the encrypted file and re-embedding the signature into the file in the form of an ELF section to ensure the security and integrity of the encrypted file during transmission.

[0061] Embodiment III

[0062] Figure 4 It is a structural schematic diagram of the key file two-way encryption verification device provided by Embodiment III of the present invention. Refer to Figure 4 The key file two-way encryption verification device includes:

[0063] The selection module 310 is used to select one of the processes pulled up by the verification background process as the verification application process when the system starts;

[0064] The obfuscation module 320 is used to generate startup verification parameters by using the verification application process and the verification background process according to the startup parameters of two pre-selected services. The verification application process obfuscates and generates a handshake verification string according to the startup verification parameters and the verification data string;

[0065] The handshake verification module 330 is used to receive the handshake verification string sent by the verification application process by using the verification background process and perform handshake verification. After the handshake verification is successful, select one of the processes pulled up by the verification background process as the verification application process;

[0066] The verification module 340 is used to use the verification background process and the verification application process to perform integrity verification of the verification background process by using preset verification parameters;

[0067] The decryption module 350 is used to decrypt the binary file by using the public key held by the verification background process when the integrity requirement is met, and obtain the integrity detection result of the binary file according to the decryption result.

[0068] The key file two-way encryption verification device provided in this embodiment, by selecting one of the processes pulled up by the verification background process as the verification application process when the system starts; the verification application process and the verification background process generate startup verification parameters according to the startup parameters of two pre-selected services, and the verification application process obfuscates and generates a handshake verification string according to the startup verification parameters and the verification data string; the verification background process receives the handshake verification string sent by the verification application process and performs handshake verification. After the handshake verification is successful, select one of the processes pulled up by the verification background process as the verification application process; the verification background process and the verification application process use preset verification parameters to perform integrity verification of the verification background process; when the integrity requirement is met, decrypt the binary file by using the public key held by the verification background process, and obtain the integrity detection result of the binary file according to the decryption result. For the maliciously modified binary background, it not only gets rid of the dependence on the support of the hardware chip, encrypts the key file to be verified, but also uses the two-way encryption verification mechanism to ensure the integrity of the verification background; on this basis, the digital signature technology is adopted to ensure the integrity of the key files in the system by judging whether the hash values obtained by verifying the signatures of the key files are the same. And the non-critical data matching obfuscation algorithm is used to isolate the maliciously modified binary files between different versions of the operating system and between different machines burned with the same version, increasing the workload of malicious modification and the difficulty of malicious modification, and ensuring the security of the entire system at the macroscopic level.

[0069] Based on the above embodiments, the handshake verification module includes:

[0070] An acquisition unit, configured to obtain, as the starting point and the ending point of the handshake verification field respectively, the remainders obtained by dividing the number of milliseconds when two services selected in advance during the system startup process are completed by a specified prime number.

[0071] A generation unit, configured to use the verification application process to randomly replace the binary numbers in other parts of the position where the original verification string is embedded except for the starting point and the ending point of the handshake verification field, and generate a verification application process-verified string.

[0072] A reading unit, configured to use the verification background process to read characters from the handshake verification string from the starting point and the ending point of the handshake verification field, and perform handshake verification with the data obtained at the positions corresponding to the pre-stored verification parameters.

[0073] Based on the above embodiments, the device further includes:

[0074] A verification background process selection module, configured to select a process from a preset system core process set as the verification background process when the system is started for the first time.

[0075] A formation module, configured to use the verification background process to randomly generate a random string with a specified length, and form its own verification string by arranging the characters in the random string according to the set position sequence difference in a preset feature protection sequence.

[0076] Correspondingly, the selection module includes:

[0077] A selection unit, configured to, when the system is started, after the verification background process is started, extract characters from the own verification string according to the set positions, match the extracted string with the feature protection sequence, and after successful matching, select one of the processes pulled up by the verification background process as the verification application process.

[0078] Based on the above embodiments, the verification module includes:

[0079] A sending unit, configured to send the preset verification parameters of the verification application process to the verification background process when the verification application process is started.

[0080] A verification unit, configured to use the verification background process to verify the identity of the verification application process according to the preset verification parameters, and when the verification is successful, send the own key field corresponding to the identity to the verification application process.

[0081] A decryption unit, configured to decrypt the own key field by using a verification application process and return the decryption result to a verification background process;

[0082] A matching unit, configured to match the decryption result with the decryption information of the own key field by using the verification background process, and determine that the verification background process is complete when the matching is successful.

[0083] Based on the above embodiments, the decryption module includes:

[0084] A production unit, configured to generate and maintain a public key and private key pair;

[0085] An embedding unit, configured to embed the public key PK into a code segment executed by the verification background process for subsequent signature verification;

[0086] A binary file acquisition unit, configured to acquire an encrypted binary file *_en.so;

[0087] A digital signature section acquisition unit, configured to acquire a digital signature section H_en from the encrypted binary file by using a preset offset value;

[0088] A signature verification unit, configured to perform signature verification on H_en by using the public key PK to obtain an encrypted hash value H_p;

[0089] A comparison unit, configured to recalculate a hash value H_n of a key section of the binary file *_en.so and compare H_p and H_n;

[0090] A determination unit, configured to determine that the binary file is complete and not tampered with when they are consistent.

[0091] Based on the above embodiments, the decryption module further includes:

[0092] An encryption unit, configured to read a preset part of an ELF section of a protected key binary file by using the libelf library and encrypt it by using an algorithm to obtain a feature value H;

[0093] A signature unit, configured to sign the feature value H by using the private key SK to generate a digital signature H_en;

[0094] An encapsulation unit, configured to embed the signature H_en into a specific offset position of the file and repackage it into a new binary file without affecting the function of the binary file.

[0095] Based on the above embodiments, the device further includes:

[0096] A writing unit, configured to write a verification data string, an own key field, and verification parameters during system flashing.

[0097] An embedding unit, configured to, after the compilation is completed by the verification background process, embed the corresponding verification data string into a specified position of the verification application process.

[0098] Based on the above embodiments, the forming module includes:

[0099] A generating unit, configured to define a region as a preset number of characters corresponding to ASCII values from a first position to a second position, perform random sampling on the defined region, and generate uniformly distributed random numbers;

[0100] A constructing unit, configured to construct a random string by mapping the generated random numbers to the characters in the character set, and form a random string with a specified length.

[0101] The key file two-way encryption verification device provided by the embodiments of the present invention can execute the key file two-way encryption verification method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects for executing the method.

[0102] Embodiment 4

[0103] Embodiment 4 of the present invention further provides a storage medium including computer-executable instructions, and the computer-executable instructions are used to execute any one of the key file two-way encryption verification methods provided by the above embodiments when executed by a computer processor.

[0104] The computer storage medium of the embodiments of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (non-exhaustive list) of the computer-readable storage medium include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, the computer-readable storage medium can be any tangible medium that contains or stores a program, and this program can be used by or combined with an instruction execution system, apparatus, or device.

[0105] A computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device.

[0106] The program code contained on a computer-readable medium may be transmitted using any appropriate medium, including - but not limited to - wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0107] The computer program code for performing the operations of the present invention may be written in one or more programming languages or combinations thereof. The programming languages include object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or device. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network - including a local area network (LAN) or a wide area network (WAN) - or, alternatively, may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0108] Note that the above is only the preferred embodiment of the present invention and the technical principles applied. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein. Various obvious changes, re-adjustments, and substitutions can be made by those skilled in the art without departing from the protection scope of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments. Without departing from the concept of the present invention, more other equivalent embodiments may be included, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A two-way encryption verification method for key files, characterized in that: include: When the system starts, one of the processes started by the verification background process is selected as the verification application process; The verification application process and the verification background process generate startup verification parameters according to the startup parameters of the two pre-selected services, and the verification application process generates a handshake verification string by confusing the startup verification parameters and the verification data string; The verification background process receives the handshake verification string sent by the verification application process and performs handshake verification. After the handshake verification is successful, the verification background process and the verification application process use preset verification parameters to perform integrity verification of the verification background process; When the integrity requirements are met, the binary file is decrypted using the public key held by the verification background process, and the binary file integrity detection result is obtained based on the decryption result.

2. The method according to claim 1, characterized in that: The verification application process and the verification background process generate startup verification parameters according to the startup parameters of the two pre-selected services, and the verification application process generates a handshake verification string according to the preset verification parameters and the verification data string confusion, including: Obtain the modulo value of the number of milliseconds of two services pre-selected in the system startup process divided by a specified prime number as the handshake check field start point and the handshake check field end point respectively; The verification application process performs random binary number replacement on the binary of the other parts of the original verification string embedding position except the handshake verification field starting point and the handshake verification field ending point to generate the verification string of the verification application process; Correspondingly, the verification background process receives the handshake verification string sent by the verification application process and performs handshake verification, including: The verification background process reads characters from the handshake verification string from the handshake verification field starting point and the handshake verification field ending point, and performs handshake verification on the data obtained at the position corresponding to the pre-stored verification parameter.

3. The method according to claim 1, characterized in that When the system is started, before selecting one of the processes started by the verification background process as the verification application process, the method further includes: When the system is started for the first time, a process is selected from the preset system core process set as the verification background process; The verification background process randomly generates a random string of a specified length, and adds the characters in the random string to a pre-set feature protection sequence according to a set position order difference to form a self-verification string; Accordingly, when the system is started, one of the processes started by the verification background process is selected as the verification application process, including: When the system starts, after the verification background process starts, characters are extracted from the self-verification string according to the set position, and the extracted character string is matched with the feature protection sequence. After the match is successful, one of the processes started by the verification background process is selected as the verification application process.

4. The method according to claim 1, characterized in that The verification background process and the verification application process use preset verification parameters to verify the integrity of the verification background process, including: When the verification application process is started, sending preset verification parameters of the verification application process to the verification background process; The verification background process verifies the identity of the verification application process according to the preset verification parameters, and when the verification succeeds, sends its own key fields corresponding to the identity to the verification application process; The verification application process decrypts the key field of itself and returns the decryption result to the verification background process; The verification background process matches the decryption result with the decryption information of its own key field, and when the match is successful, it is determined that the verification background process has integrity.

5. The method according to claim 1, characterized in that The binary file is decrypted using the public key held by the verification background process, and the binary file integrity detection result is obtained according to the decryption result, including: Generate and maintain public and private key pairs; Embed the public key PK into the code segment executed by the verification background process for subsequent signature verification process; Get the encrypted binary file *_en.so; Obtain the digital signature section H_en from the encrypted binary file using a preset offset value; Use the public key PK to verify the signature of H_en and obtain the encrypted hash value H_p; Recalculate the hash value H_n for the key section of the binary file *_en.so and compare H_p with H_n; When they are consistent, it is determined that the binary file is intact and has not been tampered with.

6. The method according to claim 5, characterized in that The method further comprises: Use libelf library to read the pre-set ELF section of the protected key binary file, and encrypt it using the algorithm to obtain the characteristic value H; Use the private key SK to sign the characteristic value H and generate a digital signature H_en; The signature H_en is embedded into a specific offset position of the file and repackaged into a new binary file without affecting the binary file’s functionality.

7. The method according to claim 1, characterized in that The method further comprises: When the system is burned, the verification data string, its own key fields and verification parameters are written. After the verification background process completes compilation, the corresponding verification data string is embedded into the specified location of the verification application process.

8. The method according to claim 3, characterized in that The verification background process randomly generates a random string of a specified length, including: The defined area is a preset number of characters corresponding to ASCII values ​​from the first position to the second position, and the defined area is randomly sampled to generate uniformly distributed random numbers; Builds a random string by mapping the generated random numbers to characters in a character set, forming a random string of a specified length.

9. A key file bidirectional encryption verification device, characterized in that: include: A selection module is used to select one of the processes started by the verification background process as the verification application process when the system starts; An obfuscation module is used to generate a startup verification parameter according to the startup parameters of two pre-selected services using a verification application process and a verification background process, and the verification application process generates a handshake verification string according to the startup verification parameter and the verification data string; The handshake verification module is used to use the verification background process to receive the handshake verification string sent by the verification application process and perform handshake verification. After the handshake verification is successful, a process is selected from the processes started by the verification background process as the verification application process; A verification module, used to verify the integrity of the verification background process using the verification background process and the verification application process using preset verification parameters; The decryption module is used to decrypt the binary file using the public key held by the verification background process when the integrity requirements are met, and obtain the binary file integrity detection result based on the decryption result.

10. A storage medium containing computer executable instructions, characterized in that: The computer executable instructions are used to execute the key file bidirectional encryption verification method as described in any one of claims 1-8 when executed by a computer processor.

Images