1 Introduction With the continuous development of Linux, more and more people have begun to promote and use Linux, and their security is also more and more challenges. ELF (Executable and Linkable Format) [1] As the most important enforcement binary file format under Linux, it is naturally an attack objective for viruses and various malicious code. It turns out that there are many virus programs under Linux to achieve intrusion by directly modifying the ELF file [10]. The traditional UNIX system (including Linux) does not integrate and legality detection of the executed code, so many virus programs and Trojans are organically multiplied.
Code signature verification is a method that can effectively prevent viruses and other malicious code intrusion. For the code signature verification mechanism under Linux, it has been studied in the past few years. Wen [2] proposes a method of signing the verification at the time of installation, and by modifying the executable attribute of the CHMOD system call control file, this method cannot detect any modification of the code after the program is installed, there is a certain limit. The method described in [3] [4] [5] is performed at the time of execution, [4] [5] uses the policy of cache the verified file, which has greatly improved the efficiency [3]. However, they will "one go to colleagues" in all ELF files, and there is no reason for the main second, lack of flexibility.
This paper proposes an improved ELF file-based code signature verification mechanism to further improve verification efficiency by providing a more flexible hierarchical verification method, and makes the system a balance in terms of security and efficiency.
2 Signature verification principle We use the signature verification algorithm that fully comply with the PKCS [8] series, and compatible with all the X509 formats, the ELF file code is completed based on the RSA [6] [7] asymmetric key system. Signature verification.
2.1 Signature Set the signature of the data is M, the number of numbers is h.
H = Hash (M)
Among them, Hash is a hash sub-hashing algorithm, such as MD5, SHA-1, etc.
Set P, Q, D as the private data of the signer, which is included in the private key SK of the signature; n, e is the public key of the signature, and is included in the list of public key PKs of the signature. These data meet the following requirements:
n = pq, P ≠ Q, P Q is a large number; E, D∈RZN and E = D-1, ED ≡ 1MOD (N); Here, (N) = (P-1) (Q-1). So, use the signature private key to encrypt H to get the signature value S:
s = e (x) = HDMOD N
2.2 Verify that the verified data is m ', its numeric summary is h'.
h '= Hash (M')
Suppose we have acquired the real public key PK of the signature, and then we decrypt the S using the public data E in the PK to obtain the reduced digital summary h '', where h '' is equivalent to h in ○ 1.
h '' = d (s) = SE MOD N
Now, we compare if H 'and h' 'are exactly the same. If the same is verified, the verification failed.
3 Design and Implementation For easy description, we introduce the following basic concepts:
1. Full summary value - refers to the summary value calculated on all data on the ELF file and the signature related data;
2. Incomplete Summary - Refers to a summary value calculated from part of an important data (mainly ELF file header) and the signature related data;
3. Fully signature value - refers to the signature value obtained on the full summary value encryption;
4. Incomplete signature value - point the signature value obtained by incomplete summary value;
5. System Verification Level - refers to the system-level verification level, it applies to all ELF files in the system; 6. File Verification Level - Refers to a single ELF file verification level, which only applies to a specified ELF file.
Signature related data refers to data such as original file size, signature public key identifier ID, signature algorithm, signature time, and signer basic information.
3.1 Signature Policy The signature of the ELF file is completed by the signature tool, regardless of the operating system core, and also has nothing to do with the platform. The signature process fully follows the standards and principles described in Section 2.
First, we calculate two summary values by ○ 1: Incomplete Summary (HPART) and a full summary value (HCOMP). Then use a 2-style encrypted summary value to obtain two signature values: Incomplete Sign Value (Spart) and a Full Signature Value (SCOMP).
Finally, we will combine the incomplete signing values and the full signature value in a fixed format and placed in the end of the signed file. As shown in Figure 3-1 (the number in parentheses indicates the number of bytes of this field).
Figure 3-1 Code Signature Process and Signature Value
3.2 Verification Policy The verification of the executed ELF file sign value is based on "System Verification Level" and "File Verification Level" of the file. "File Verification Level" is the validation level set for a single file, divided into three levels, indicated by 0 to 2, respectively. "File Verification Level" Saves in the Inode node flag of each file, the system administrator can set the verification level of the file as needed. The specific meaning of the "file verification level" is shown in Table 3-1.
Table 3-1: File verification level
Level Name Description 0 No Protected Level Do not verify the signature value of the file. 1 Protection Level Verify the incomplete signature value of the file. 2 High Protection Level Verified the full signature value of the file.
"System Verification Level" is divided into four levels, respectively from 0 to 3, respectively. "System Verification Level" is controlled by the PROC file system, which can be set by the administrator as needed. The specific meaning of "System Verification Level" is shown in Table 3-2.
Table 3-2: System Verification Level
Level Name Description 0 No Protected Level Performs all programs without any verification. 1 Low Protection Level Verified the signature value of the executed file based on the "File Verification Level". 2 When the protection level "file verification level" is 0, the signature value of the executed file is verified according to the "System Verification Level"; "File Verification Level" is not 0, according to the "File Verification Level" verified the signature value of the executed file . 3 High Protection Level Verifys the full signature value of all executed files.
3.3 Verify Algorithm When the user requests an ELF file, the system will determine how to verify the signature value of the file according to the flow shown in Figure 3-2. In order to improve system efficiency, we will maintain the corresponding cache for ELF files that have been verified "incomplete signatures" and "full signature value". When requesting these files again, you can repeat its signature value.
Figure 3-2: System-level signature value verification mechanism
In Figure 3-2, "Verify Incomplete Signing Values" and "Verify Full Signature Values" are important steps for the entire verification process. The verification value of the signature value corresponds to the generation of the signature value. When verifying, the summary value (H'Part or H'Comp) is first calculated by 3, and then use the signator's public key (PKSIGN) to pass ○ 4 Decrypt the corresponding signature value, resulting in the corresponding summary value (H''Part or H''Comp). Finally, comparing if H 'and h' 'is completely consistent, the verification is verified, and the verification failed.
3.4 Public Key Management When decrypting the signature data, you need to use the signature of the certificate. Since the code that may have multiple signature issues, there is a certificate of multiple signers. In order to save system overhead, minimize the impact on system performance, we must manage these certificate public keys efficiently. To this end, we maintain a trust public key chain in the system core space, and all the public keys of the trusted person will be placed in the public key chain list. When the system verifies the signature value of the code, the corresponding public key can be obtained directly from the public key chain list. If there is no corresponding public key in the public key chain list, the signature of the code is not trusted, so the verification failed. The trusted public key in the system is configurable. The system will automatically initialize the core public key chain table according to the configuration file at startup, and the system administrator can also refresh or modify it at any time. 3.5 Software Structure This Mechanism The implementation of this mechanism mainly includes two parts of the signature verification mechanism module of the user space signature verification tool and the core space. Among them, the signature verification tool for the user space is the auxiliary tool for this mechanism. Its main function is to sign and set the ELF file, and can also verify the signature value of the ELF file, and will not be described again; the core space signature verification Mechanism modules can be divided into verification policy modules and public key management modules.
3.5.1 Verification Policy Module
The verification policy module is responsible for executing the verification policy for the signature value, and is responsible for managing the cache chain table of the verified file. When the user requests the ELF file, the module performs the verification policy as shown in Figure 3-2.
When verifying the signature value, the system will first query the verified file cache chain list, and if the verified file has been verified, no need to repeat the verification, directly adopt the last verification result. If the file is not executed in the cached chain list, the signator public key is requested to the public key management module, and then verify its signature value. If the verification is correct, it means that the executed file is complete and credible, let it execute; otherwise it is forbidden.
In addition, in order to ensure the consistency of the verified file cache chain table and the actual file, we must monitor the modification of the ELF file. When a ELF file is modified, we should immediately clear the verification related to the file in the verified file cache chain table. result.
3.5.2 Public Key Management Module
The public key management module is mainly responsible for managing the trusted public key chain, such as initialized chain, acquisition, add, and delete public key nodes.
The trust public key chain consists of a series of public key nodes, as shown in Figure 3-3.
Figure 3-3 Core public key chain list
Where KEY_ID is the MD5 hash value corresponding to the public key, with a length of 16 bytes. In theory, the same probability of KEY_ID of different public keys is close to one of 2128. In a large range, I can think that Key_ID and public key are one or one. Therefore, we use key_id as the unique identifier of each public key.
3.6 Performance Test Table 3-3 is a simple set of test data, which is the average value obtained by multiple execution. It can be seen from it that the system overhead increases by less than 5% by using a grading mechanism and a cache mechanism, which greatly reduces the impact on system performance.
Table 3-3 Verify the system overhead of the signature
The executed file LS / GCC Test.c does not verify the signature value 1489μs567041μs verification incomplete signature value without buffer 3264μs569763μs Cache 1513μs567054μs verification full signature value without buffer 8955μs683295μs Cache 1547μs567482μs
Environment: CPU PIV 1.7G, Kernel Linux-2.4.18, the signature key length is 1024 bits.
4 Conclusion Code Signature and Validation The main purpose is to prevent malicious code such as viruses and Trojans, improve the security of the operating system; simultaneously protect software developers and users, software developers can prevent others from implying the replacement, and Software users can also confirm the authenticity and integrity of the software.
At present, there are many systems that use the mechanism for verifying the code signature when installing, such as Microsoft's Windows Series operating system. However, only the verification code signature is very limited when the installation is installed, and it cannot detect any modifications to the code after the program is installed. Therefore, the mechanism for verifying the code signature when using execution will greatly improve the security of the system. But safety is enhanced, but the system efficiency is reduced. In order to obtain the balance of safety and efficiency, this paper proposes a grading verification mechanism. For systems with high security requirements, sacrifice a certain efficiency to improve system security; the system is low, and a certain security is sacrificed to improve system efficiency. Reference
Tool Interface Standard (TIS) Portable Formats Specification Version 1.1:? TIS Committee, October 1993 Juha-Petri K rn and Mika Leppinen:? Signing executables in Linux April 7th, 1998 WLF tutorial, http:. //Libeccio.dia.unisa. it / wlf / wlf_tutorial.html WA Arbaugh, G.Ballintijn, L.van Doorn: Signed Executables for Linux Tech Report CS-TR-4259 University of Maryland, June 4,2001 Luigi Catuogno and Ivan Visconti:... A Format- . Independent Architecture for Run-Time Integrity Checking of Executable Code Dipartimento di Informatica ed Applicazioni Università di Salerno Via S. Allende, 84081 Baronissi (SA), Italy OpenSSL cryptographic library man page, http: //www.openssl.org/docs/ Crypto / Crypto.html OpenSSL SSL / TLS Library Man Page, http://www.openssl.org/docs/ssl/ssl.html PKCS: Public-Key Cryptography Standards. http://www.rsarated.com/rsalabs/ PKCS / TIGRAN AIVAZIAN: Linux Kernel Internals. Tigran @ Veritas.com, 22 August, 2000 Linux Viruses - Elf File Format: Marius Van Oers Avert-Nai Labs, Gatwickstraat 25, 1043 GL Amsterdam, The Netherlands, Europe
About the author Wu Zhigang, Linux enthusiasts, engaged in research and development of kernel security mechanisms. You can contact him with Alex_Wzg@yahoo.com.cn.
