KR20100054940A - Apparatus and method for preventing malware using signature verification for embedded linux - Google Patents

Abstract

PURPOSE: An apparatus and a method for preventing malware using signature verification for an embedded Linux are provided to intercept a root kit which installs a virus and a backdoor influencing an EFL(Executable and Linking Format) binary execution file. CONSTITUTION: An encryption decryption module(140) provides a control module for decoding and/or encoding required for authenticating a signature of a binary file. If the signature for the binary file does not exist or the binary file is changed, a first transmission unit(150) provides the binary file to an external device. The first transmission unit receives a malicious program test result for the binary file.

Description

Apparatus and method for blocking malware using signature verification in embedded Linux {APPARATUS AND METHOD FOR PREVENTING MALWARE USING SIGNATURE VERIFICATION FOR EMBEDDED LINUX}

The present invention relates to a security apparatus and method in embedded Linux, and more particularly, to an apparatus and method for preventing malicious programs in embedded Linux.

Over the years, the rapidly developing information and communication technology has been the foundation for improving the quality of human life, but security threats are steadily increasing accordingly. As mobile devices evolve, these security threats are spreading beyond mobile PCs and servers to mobile embedded systems. As mobile devices such as mobile phones and PDAs become smaller and lighter, they have various functions, and advanced communication networks such as 3G become more practical, creating an environment that can transmit large amounts of information at a higher speed than before. Security threats can occur that can leak or prevent the use of certain devices. In particular, as e-commerce is added to mobile devices through the convergence of telecommunications-financial systems, huge economic losses are expected if the program fails to properly respond to malicious programs.

Therefore, researches are being actively conducted to apply Linux to embedded systems as a way to maximize performance by using embedded systems that will be further developed in the future. However, compared with the development of embedded Linux, the development of security programs to protect such systems is relatively incomplete because of the fact that Linux is relatively smaller than the general user base, and is divided into root and user rights. Even if a malicious program penetrates, it can be found that it can not cause great damage to the system unless root is obtained. However, Linux systems built for embedded systems have limited performance and resources, and are difficult to maintain quickly, so they cannot guarantee a stable environment even when exposed to weak attacks. Given that the number of malicious programs running on the system is increasing every year, it is necessary to develop a security program that can protect embedded Linux in order to be successfully settled.

Malicious programs that threaten Linux often try to insert and execute malicious code by transforming binary files in the Executable and Linking Format (ELF) format. In addition to the classical forms of viruses that infect other files and cause self-replication to continue, they are used in many types of attacks, including worms, Trojan horses, and rootkits. For example, RST (Remote Shell Trojan) infects all ELF binary files in the / bin directory so that a shell with root privileges can be run through the back door. Many previous studies have suggested firewalls, intrusion detection systems, antiviruses, etc. to prevent these malicious programs. However, the limitations of signature-based detection methods show weaknesses in zero-day attacks and various variant attacks. It is difficult to fully guarantee the stability and availability of the system. This problem must be solved when considering the environment of an embedded system that can be damaged by weak attacks. In addition, in order to ensure stability and availability, it is necessary to confirm in real time whether the system is kept safe. However, existing application-based methods must consume some of the resources of the embedded system because they must reside in memory as an independent process. This occurs. Therefore, there is a need for a method of using resources of an embedded system more efficiently than a security system used in an environment such as a PC and a server.

On the other hand, considering that embedded Linux used in each system is optimized for hardware for a specific purpose unlike general purpose Linux, it is necessary to develop a method that can be applied to and released from the system quickly and easily without requiring modification of the existing system. .

Signature verification techniques are primarily used to prevent forgery and tampering that can occur during the transmission of data. 1 is a conceptual diagram illustrating a signature generation and verification process in a signature verification technique. Referring to FIG. 1, the signature verification technique can be divided into two parts, generation and verification. In the signature generation phase, the sender creates a message digest from the original data using a hash function such as MD5 or SHA-1. Encrypting the generated message digest with the sender's private key creates an electronic signature to be delivered to the recipient. The signature thus generated is sent to the recipient with the data. The recipient of the data goes through a signature verification step, where the receiver creates a new message digest using the same hash function that the sender used in the signature generation phase. Then, the transmitted signature is decrypted with the sender's public key to obtain the message digest generated by the sender in the signature generation step, and then compared with the newly created message digest. As such, the signature verification technique has the advantage of not encrypting all the data, thereby reducing the system resources and time required for the operation, while preventing the forgery and tampering of the data. These characteristics can help effectively protect the system in embedded environments where performance is limited.

Since the release of the SELinux project in 2001, Linux kernel developers, including Linus Torvalds, have become aware of the need for general access control structures inside the kernel to make the Linux kernel more secure. In addition to SELinux, there are various access control models such as POSIX.1e capabilities and DTE (Domain and Type Enforcement), so that the Linux security module can be freely selected and applied to the Linux kernel. (Linux Security Module, LSM) project was carried out. As a result, since June 2002, the LSM framework has been included in the standard Linux kernel.

The LSM framework defines a dummy function for security policies that must be passed before accessing kernel internal objects such as tasks, inodes, and open files. Therefore, the security policy developer can easily implement the desired security policy by redefining the dummy function provided by the LSM basic structure as the kernel module, and the user can apply the desired security policy simply by loading the kernel module.

Accordingly, a first object of the present invention is to provide a malicious program blocking device using signature verification in embedded Linux.

A second object of the present invention is to provide a malicious program blocking method using signature verification in embedded Linux.

It is also a third object of the present invention to provide a computer-readable recording medium having recorded thereon a program for executing a malicious program blocking method using a signature verification method in embedded Linux.

In order to achieve the first object of the present invention, an apparatus for blocking malicious programs using signature verification in embedded Linux according to an aspect of the present invention includes a binary to be executed in an apparatus for blocking malware using signature verification in embedded Linux. A control module for verifying a signature on a file and determining whether to execute the binary file based on at least one of the signature verification result and a malicious program inspection result, and encrypting and decrypting required for signature verification on the binary file The cryptographic decryption module providing a result for at least one to the control module and the signature on the binary file do not exist, and when the binary file is changed as a result of the signature verification, the binary file is stored in an external device. Offering to, awards And a first transceiver configured to receive a malicious program test result of the binary file from an external device and provide the result to the control module.

The first transceiver may further receive a signature for the binary file from the external device and additionally provide the signature to the control module, and the control module may insert the received signature into the binary file.

The control module may insert the provided signature into the binary file when a malicious program is not included in the binary file and there is no signature on the binary file.

The control module verifies a signature for the binary file and an execution control module for determining whether to execute the binary file based on at least one of a signature verification result and a malicious program inspection result, and a signature verification result for the binary file. And a file integrity verification module for providing at least one of malicious program inspection results for the binary file to the execution control module.

The first transceiver may further receive a signature for the binary file from the external device and provide the signature to the control module via the file integrity verification module, and the control module may provide the received signature to the binary file. Can be inserted.

The binary file may be in Executable and Linking Format (ELF).

The control module and the cryptographic decryption module may operate at a kernel level of an embedded Linux system, and the first transceiver may operate at a user level of an embedded Linux system.

The control module may determine whether to execute the binary file based on at least one of the signature verification result and the malicious program inspection result before the binary file is loaded into the memory and executed.

The control module may hook at a kernel level in a process of executing the binary file.

The control module may change the file_mmap function in the Linux Security Modules (LSM) framework.

The control module may be configured to perform keyed-hash message authentication code message-digest algorithm 5 (HMAC-MD5), keyed-hash message authentication code secure hash agorithm-1 (HMAC-SHA-1), and RSA when verifying a signature on the binary file. At least one can be used.

The first transceiver may use ISAKMP (Internet Security Association & Key Management Protocol) in exchanging a secret key required for signature verification of the binary file with the external device.

An apparatus for blocking malicious programs using a signature verification method in embedded Linux according to another aspect of the present invention for achieving the first object of the present invention includes an external device in the apparatus for blocking malicious programs using a signature verification method in embedded Linux. And a second transmission / reception unit receiving a binary file from the binary file and checking whether the binary file includes a malicious program, and providing a malicious program inspection module that provides the malicious program inspection result to the external device via the second transmission / reception unit. Compared.

The malicious program blocking device further includes a signature generation module that provides a signature for the binary file to the second transceiver when the malicious file does not include a malicious program as a result of the malicious program inspection, wherein the second transmission / reception is performed. The unit may additionally provide a signature for the binary file to the external device.

The signature generation module generates keyed-hash message authentication code message-digest algorithm 5 (HMAC-MD5), keyed-hash message authentication code secure hash algorithm-1 (HMAC-SHA-1), and RSA when generating a signature for the binary file. At least one of may be used.

The second transceiver may use ISAKMP (Internet Security Association & Key Management Protocol) in exchanging a secret key required for generating a signature for the binary file with the external device.

The binary file may be in Executable and Linking Format (ELF).

In addition, the malicious program blocking method using the signature verification method in the embedded Linux according to another aspect of the present invention for achieving the second object of the present invention, to the malicious program blocking method using the signature verification method in embedded Linux Determining whether a signature exists for the binary file to be executed; determining whether a malicious program is included in the binary file when the signature for the binary file does not exist; and when the binary file is malicious. Blocking the execution of the binary file when the program is included.

The malicious program blocking method may further include determining whether a malicious program is included in the binary file when there is no signature on the binary file, and then, when the binary file does not include a malicious program, the binary file. The method may further include generating a signature, inserting the generated signature into the binary file, and allowing execution of the binary file.

If the binary file does not contain a malicious program, generating a signature for the binary file may include keyed-hash message authentication code message-digest algorithm 5 (HMAC-MD5) and HMAC- when generating a signature for the binary file. At least one of Keyed-Hash Message Authentication Code Secure Hash Algorithm-1 (SHA-1) and RSA may be used.

If the binary file does not contain a malicious program, the step of generating a signature for the binary file may include ISAKMP (Internet Security Association & Key Management Protocol) in exchanging a secret key required for generating a signature for the binary file. Can be used.

The malicious program blocking method may further include: verifying a signature on the binary file when the signature on the binary file exists after determining whether a signature on the binary file to be executed exists; The method may further include allowing execution of the binary file when the binary file has not been changed, and determining whether a malicious program is included in the binary file when the signature of the binary file does not exist. It may be determined whether a malicious program is included in the binary file when the signature of the binary file does not exist and when the binary file is changed as a result of the verification.

If the signature on the binary file exists, verifying the signature on the binary file may include keyed-hash message authentication code message-digest algorithm 5 (HMAC-MD5) and HMAC-SHA upon signature verification of the binary file. At least one of -1 (keyed-Hash Message Authentication Code Secure Hash Algorithm-1) and RSA may be used.

If the signature on the binary file exists, verifying the signature on the binary file may use ISAKMP (Internet Security Association & Key Management Protocol) in exchanging a secret key required for signature verification on the binary file. Can be.

The binary file may be in Executable and Linking Format (ELF).

The malicious program blocking method may operate before the binary file is loaded into memory and executed.

The malicious program blocking method may hook at a kernel level in the execution process of the binary file.

The malicious program blocking method may change a file_mmap function in a Linux Security Modules (LSM) framework.

In addition, a computer-readable recording medium having recorded thereon a program for performing a malicious program blocking method using a signature verification method in embedded Linux according to another aspect of the present invention for achieving the third object of the present invention is A computer readable recording medium having recorded thereon a program for performing the method.

According to the above-described apparatus and method for blocking malicious programs using signature verification in embedded Linux, a virus that infects ELF binary executable files, as well as a rootkit for installing a backdoor by tampering with a shared library can be blocked.

In addition, LSM type kernel module can be applied to and removed from embedded Linux easily and quickly, and it can efficiently detect malicious programs in real time without resident process in memory without additional hardware equipment. Safe system maintenance is possible.

In addition, it is possible to secure time to respond by not immediately exposed to unknown new attacks, and because it is verified using an authorized server, the inspection results are reliable and the maintenance of the system can be made easily and quickly.

As the invention allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description. However, this is not intended to limit the present invention to specific embodiments, it should be understood to include all modifications, equivalents, and substitutes included in the spirit and scope of the present invention. Like reference numerals are used for like elements in describing each drawing.

Terms such as first, second, A, and B may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component. And / or < / RTI > includes any combination of a plurality of related listed items or any of a plurality of related listed items.

When a component is referred to as being "connected" or "connected" to another component, it may be directly connected to or connected to that other component, but it may be understood that other components may be present in between. Should be. On the other hand, when a component is said to be "directly connected" or "directly connected" to another component, it should be understood that there is no other component in between.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, the terms "comprise" or "have" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art and shall not be construed in ideal or excessively formal meanings unless expressly defined in this application. Do not.

Hereinafter, with reference to the accompanying drawings, it will be described in detail a preferred embodiment of the present invention. Hereinafter, the same reference numerals are used for the same components in the drawings, and duplicate descriptions of the same components are omitted.

Figure 2 is a block diagram showing the configuration of a malicious program blocking device using a signature verification method in embedded Linux according to an embodiment of the present invention.

Referring to FIG. 2, a malicious program blocking device using a signature verification method in embedded Linux may be largely divided into a signature verification device 100 and a signature generation device 200.

The signature verification apparatus 100 includes an execution control module 122, a file integrity verification module 124, an encryption decryption module 140, and a first transceiver 150. In this case, the signature verification apparatus 100 may be an embedded system.

The execution control module 122 determines whether to execute the specific binary file 110 when an execution command is executed for a specific binary file 110 executable by a user or a program in embedded Linux. That is, the execution control module 122 determines whether to execute the binary file 110 according to whether the binary file 110 includes a malicious program before the binary file 110 is loaded into the memory and executed. do. In this case, the binary file 110 may be in an Executable and Linking Format (ELF) format.

The general binary file execution process is as follows. When a user or a program issues an execution command for a specific binary file at the user level of the embedded Linux system, the execution command is executed in the form of a system call to the embedded Linux operating system. It is handled at the kernel level. When the execution command is allowed at the kernel level, virtual memory is allocated, and memory mapping is set between the allocated virtual memory and the available physical memory so that the specific binary file 110 can be set. ) May be executed.

The execution control module 122 operates at the kernel level, and if a command is executed for a binary file such as an ELF binary file and a system call is executed for the binary file 110 at the kernel level, whether a malicious program is included in the execution control module 122. It is determined whether or not to execute the binary file 110 according to.

The execution control module 122 performs kernel level hooking on the system call in order to ensure that all the binary files undergo the signature authentication. Hooking typically means intercepting and converting an event or function on an event handler-based operating system. For example, if you are using the Linux Security Module (LSM), you can use hooking to perform signature authentication without having to recompile your existing embedded Linux kernel.

FIG. 3 is a block diagram illustrating a hooking function for each binary file execution step when an LSM is used in an apparatus for blocking malicious programs using signature verification in embedded Linux according to an embodiment of the present invention.

Referring to FIG. 3, the integrity of the binary file may be checked before the binary file is loaded and executed by changing a file_mmap function performed after the do_mmap function. Through this, Code Injection Attack that modifies the contents of binary executable files or dynamic library files by using vulnerabilities of existing programs in addition to malicious programs such as viruses and worms that exist in the form of binary executable files It can also prevent rootkits from running, which keeps your system safe.

Referring back to FIG. 2, the execution control module 122 requests the file integrity verification module 124 for signature verification of the binary file 110 to determine whether a malicious program is included and the file integrity. The execution of the binary file 110 is determined based on the signature verification result and the malware inspection result provided from the verification module 124.

The execution control module 122, from the file integrity verification module 124 which will be described later when the malicious program does not include a malicious program in the binary file 110 and there is no signature on the binary file 110. The signature for the provided binary file 110 is inserted into the binary file 110.

The file integrity verification module 124 receives a signature verification request for the binary file 110 from the execution control module 122, and as a result of the signature verification for the binary file 110, the file integrity verification module 124. At least one of a malicious program check result and a signature for the binary file 110 is provided to the execution control module 122.

The file integrity verification module 124 uses the signature verification technique when the signature on the binary file 110 exists, that is, when the binary file 110 includes a signature. Check first to see if it has changed.

The file integrity verification module 124 provides the execution verification module 122 to the signature verification result when the binary file 110 is not changed as a result of the verification.

The file integrity verification module 124 checks the malware and generates a signature when the binary file 110 does not exist or the binary file 110 is changed as a result of the verification. For this purpose, the binary file 110 is transmitted to the signature generator 200 via the first transceiver 150. Whenever the binary file 110 is executed, it does not check whether it is infected by malicious programs, but first checks whether the binary file 110 to be executed is changed by using signature verification techniques to reduce system resource consumption of the entire embedded Linux system. It can be minimized.

The file integrity verification module 124 uses a keyed-Hash Message Authentication Code Message-Digest algorithm 5 (HMAC-MD5) and a keyed-Hash Message Authentication Code (HMAC-SHA-1) as a signature verification scheme for the binary file 110. Secure Hash Algorithm-1) and RSA may be used.

For example, if you simply generate a signature using the MD5 algorithm, an attacker can attach an MD5-generated signature to an infected file and distribute it as if it were a signed file. On the other hand, HMAC-MD5 verifies the signature using the secret key shared with the server in advance for each embedded system, so if the shared secret is not known, the forged signature cannot be generated, so the shared key of the server and the embedded system is leaked. Unless otherwise forged, signature forgery can be prevented. The secret key will be described later with reference to the first transceiver 150.

The encryption decryption module 140 receives a request from the file integrity verification module 124 for at least one of encryption and decryption required when verifying a signature on the binary file 110, and encrypts and decrypts corresponding to the request. Provide results for at least one of the file integrity verification modules 124. That is, the encryption decryption module 140 supports an encryption decryption process used for the signature verification scheme selected by the file integrity verification module 124. In this case, the encryption decryption algorithm may be Message-Digest algorithm 5 (MD5), Secure Hash Algorithm-1 (SHA-1), and RSA.

The first transceiver 150 receives a file transfer request for the binary file 110 from the file integrity verification module 124, performs a malicious program check result on the binary file 110, and the binary file 110. Provide the file integrity verification module 124 with at least one of the signatures. In this case, the first transceiving unit 150 provides the binary file 110 to the signature generator 200, and a result of the malicious program test for the binary file 110 from the signature generator 200. And at least one of a signature for the binary file 110 is provided to the file integrity verification module 124.

The first transceiver 150 may use an ISAKMP (Internet Security Association & Key Management Protocol) in exchanging the secret key required for signature verification of the signature generator 200 and the binary file 110. have. When the file integrity verification module 124 uses HMAC-MD5 and HMAC-SHA-1 as signature verification methods, a secret key exchange protocol such as ISAKMP is required.However, when using a public key RSA, ISAKMP and The same secret key exchange protocol is not required.

Hereinafter, the secret key exchange will be described in detail. The signature verification device 100 and the signature generation device 200 undergo mutual authentication and key distribution to generate a secret key used by the file integrity verification module 124 for signature verification of binary files. For example, when using the ISAKMP protocol, a server and an embedded system verify each other's information and authenticate, establish a security association (SA), and exchange keys. The ISAKMP protocol automatically updates SAs and keys at fixed times, thus preventing cryptographic attacks that can occur due to the nature of the encryption protocol. In addition, since a random number is included in the message transmission, a reply attack can be prevented. Since ISAKMP protocol can apply various technologies to the authentication method, it is possible to use strong authentication technology such as OTP (One Time Passward) in addition to performing authentication using commonly used public certificate. .

The signature generator 200 includes a second transceiver 210, a malicious program inspection module 220, and a signature generation module 230. In this case, the signature generation device 200 may be a server.

 The signature generation device 200 examines the binary file 110 received from the signature verification device 100 and determines that the signature file is a safe file that does not include a malicious program. Generates and transmits the signature to the signature verification apparatus 100, and the signature verification apparatus inserts the signature into the binary file 110 by the execution control module 122 as described above. Thereafter, when the binary file 110 is executed, the signature verification apparatus 100 determines that the binary file 110 is a safe binary file through a signature verification process of the binary file 110 and allows execution. However, if the signature verification process fails, since the change to the binary file 110 occurs after the signature generation, the signature file is sent to the signature generator 200 again to verify that the binary file 110 is secure.

The second transceiver 210 receives a binary file 110 that is a target of malicious program inspection and signature generation from the signature verification apparatus 100, and the binary file 110 to the malicious program inspection module 220. Request a check, and display at least one of a result of the malicious program inspection of the binary file 110 by the malicious program inspection module 220 and a signature of the binary file by the signature generation module 230. It is provided to the signature verification device (100).

As described above, the second transmission / reception unit 210 exchanges a secret key required for generating a signature for the binary file 110 with the signature verification device 100. The ISAKMP (Internet Security Association & Key Management Protocol) Can be used. As described above, when the file integrity verification module 124 of the signature verification apparatus 100 uses HMAC-MD5 and HMAC-SHA-1 as signature verification methods, a secret key exchange protocol such as ISAKMP is required. When using public key method RSA, no secret key exchange protocol such as ISAKMP is required.

The malicious program inspection module 220 receives a file inspection request for the binary file 110 from the second transceiver 210, and checks whether a malicious program is included in the binary file 110. The file check result is provided to the transceiver, and when the malicious file is not included in the binary file 110, the signature generation module 230 requests the signature generation module 230 to generate a signature for the binary file 110. The malicious program inspection module 220 may use a verification method based on a malicious program sample database (DB), a verification program based on a malicious program definition file, or a malicious program pattern file in performing the malicious program inspection. The control method may be implemented in a manner similar to that of a scan engine used by an anti-virus program, a vaccine program, a spyware removal program, and the like.

The signature generation module 230 receives a request for generating a signature for the binary file 110 from the malicious program inspection module 230, generates a signature for the binary file 110, and generates a signature for the second transceiver 210. To provide. In this case, the signature generation module may use keyed-hash message authentication code message-digest algorithm 5 (HMAC-MD5) and keyed-hash message authentication code secure hash (HMAC-SHA-1) as a signature generation technique for the binary file 110. At least one of Algorithm-1) and RSA may be used.

Figure 4 is a diagram comparing the overhead of the embedded system when applying the present invention and the non-applied invention. The overhead of the embedded system is compared based on the execution time from execution of binary file to completion of application and non-application. The ELF executables used to compare run times are / bin / busybox ls and / bin / busybox pwd.

Experimental results show that the execution time in the kernel increases when applied. However, there is little execution time at the user level and very short execution time at the kernel level. The worst case condition in performance evaluation and the difference in performance speed felt by users participating in the experiment are felt. Almost no enemy. In addition, since a user program generally performs most tasks at the user level, the present invention is performed only once at the kernel level during the first execution of the program, and thus does not significantly affect the overall system performance. Also, considering that the size of ELF binary files used in the existing embedded Linux system is mostly 512KB or less, the increase in execution time due to the increase in the size of the binary file used in the embedded system should not be a big concern. Therefore, we can confirm that the proposed method effectively protects the system.

5 is a flowchart illustrating a procedure of a malicious program blocking method using signature verification in embedded Linux according to an embodiment of the present invention.

Referring to FIG. 5, it is first determined whether a binary file to be executed exists (S310). When an executable command is issued for a binary file such as an ELF binary file, a system call for the binary file is executed at the kernel level. Kernel-level hooking is done on the system call to ensure that all binary files are signed. For example, if you are using the Linux Security Module (LSM), you can use hooking to perform signature authentication without having to recompile your existing embedded Linux kernel. The kernel level hooking process may be understood in the same manner as described with reference to the execution control module 122 among the components of the malicious program blocking device using the signature verification method in the embedded Linux illustrated in FIG. 2. In order to avoid confusion of duplicate contents, the following description will be omitted.

Next, if there is a binary file to be executed as a result of the determination, it is determined whether a signature for the binary file exists (S320), and if a signature for the binary file exists, the signature on the binary file is verified (S330). . The signature verification process S330 may be easily understood as described with reference to the file integrity verification module 124 among the components of the malicious program blocking device using the signature verification method in the embedded Linux illustrated in FIG. 2. In order to avoid confusion of one understanding and overlapping contents, the following description will be omitted.

Signature verification result for the binary file (S330) If the binary file is not changed (S340), the execution of the binary file is allowed (S390).

As a result of determining whether a signature exists for the binary file (S320), if the signature for the binary file does not exist or if the signature verification result for the binary file (S330) changes the binary file (S340) It is determined whether a malicious program exists (S350). The process of determining whether the malicious program exists (S350) will be understood as described with reference to the malicious program inspection module 220 in the configuration of the malicious program blocking device using the signature verification method in the embedded Linux shown in FIG. In order to avoid confusion of easy understanding and overlapping contents, the following description will be omitted.

As a result of determining whether a malicious program exists in the binary file (S350), when a malicious program exists in the binary file, execution of the binary file is blocked (S380).

As a result of determining whether a malicious program exists in the binary file (S350), if a malicious program exists in the binary file, a signature is generated for the binary file (S360), and the generated signature is added to the binary file. Insert (S370) and allow the execution of the binary file (S390). The signature generation process S360 may be easily understood as described with reference to the signature generation module 230 among the components of the malicious program blocking device using the signature verification scheme in the embedded Linux illustrated in FIG. 2. In order to avoid confusion of understanding and overlapping contents, the following description will be omitted.

Although described with reference to the above embodiments, those skilled in the art will understand that various modifications and changes can be made without departing from the spirit and scope of the invention as set forth in the claims below. Could be.

1 is a conceptual diagram illustrating a signature generation and verification process in a signature verification technique.

Figure 2 is a block diagram showing the configuration of a malicious program blocking device using a signature verification method in embedded Linux according to an embodiment of the present invention.

FIG. 3 is a block diagram illustrating a hooking function for each binary file execution step when an LSM is used in an apparatus for blocking malicious programs using signature verification in embedded Linux according to an embodiment of the present invention.

Figure 4 is a chart comparing the embedded system overhead when applying the present invention and when the present invention is not applied.

5 is a flowchart illustrating a procedure of a malicious program blocking method using signature verification in embedded Linux according to an embodiment of the present invention.

Explanation of symbols on the main parts of the drawings

100: signature verification device 110: binary file

120: control module 122: execution control module

124: file integrity verification module 140: encryption decryption module

150: first transceiver 200: signature generating device

210: second transceiver 220: malware inspection module

230: signature generation module

Claims (29)

Apparatus for Blocking Malware Using Signature Verification in Embedded Linux, A control module for verifying a signature of a binary file to be executed and determining whether to execute the binary file based on at least one of the signature verification result and a malicious program inspection result; An encryption decryption module for providing a result of at least one of encryption and decryption required for verifying a signature on the binary file to the control module; And In the case where there is no signature on the binary file and when the binary file is changed as a result of the signature verification, the binary file is provided to an external device, and a malicious program check for the binary file is performed from the external device. Malicious program blocking device provided with a first transceiver for receiving a result provided to the control module. The method of claim 1, The first transceiver may further receive a signature for the binary file from the external device and provide the signature to the control module. And the control module inserts the received signature into the binary file. The method of claim 2, And the control module inserts the provided signature into the binary file when the malicious file does not contain a malicious program and there is no signature on the binary file. The method of claim 1, The control module, An execution control module for determining whether to execute the binary file based on at least one of a signature verification result and a malicious program inspection result; And And a file integrity verification module for verifying a signature of the binary file and providing at least one of a signature verification result of the binary file and a malicious program inspection result of the binary file to the execution control module. Malware Blocker. The method of claim 4, wherein The first transceiver may further receive a signature for the binary file from the external device and provide the signature to the control module via the file integrity verification module. And the control module inserts the received signature into the binary file. The method of claim 1, The binary file is a malicious program blocking device, characterized in that the Executable and Linking Format (ELF) format. The method of claim 1, The control module and the cryptographic decryption module operate at a kernel level of an embedded Linux system, The first transceiver unit is a malicious program blocking device, characterized in that for operating at a user level (User Level) of the embedded Linux system. The method of claim 1, And the control module determines whether to execute the binary file based on at least one of the signature verification result and the malicious program inspection result before the binary file is loaded into the memory and executed. The method of claim 8, The control module is a malicious program blocking device, characterized in that for hooking (Hooking) at the kernel level (Kernel Level) in the execution process of the binary file. 10. The method of claim 9, The control module is a malicious program blocking device, characterized in that for changing the file_mmap function in the Linux Security Modules (LSM) framework. The method of claim 1, The control module may be configured to perform keyed-hash message authentication code message-digest algorithm 5 (HMAC-MD5), keyed-hash message authentication code secure hash agorithm-1 (HMAC-SHA-1), and RSA when verifying a signature on the binary file. Malware blocking device, characterized in that using at least one. The method of claim 1, And the first transceiver uses ISAKMP (Internet Security Association & Key Management Protocol) in exchanging a secret key required for signature verification of the binary file with the external device. Apparatus for Blocking Malware Using Signature Verification in Embedded Linux, A second transceiver for receiving a binary file from an external device; And And a malicious program inspection module configured to inspect whether the binary file includes a malicious program and provide the malicious program inspection result to the external device via the second transceiver. The method of claim 13, The malicious program blocking device further includes a signature generation module that provides a signature for the binary file to the second transceiver when the malicious file does not include a malicious program as a result of the malicious program inspection. The second transceiver unit further provides a signature for the binary file to the external device, characterized in that the malicious program blocking device. The method of claim 14, The signature generation module generates keyed-hash message authentication code message-digest algorithm 5 (HMAC-MD5), keyed-hash message authentication code secure hash algorithm-1 (HMAC-SHA-1), and RSA when generating a signature for the binary file. Malware blocking device, characterized in that using at least one of. The method of claim 14, And the second transmitter / receiver uses ISAKMP (Internet Security Association & Key Management Protocol) in exchanging a secret key required for generating a signature for the binary file with the external device. The method of claim 13, The binary file is a malicious program blocking device, characterized in that the Executable and Linking Format (ELF) format. A method for blocking malicious programs using signature verification in embedded Linux, Determining whether a signature exists for the binary file to be executed; Determining whether a malicious program is included in the binary file when a signature for the binary file does not exist; And Blocking the execution of the binary file when the binary file includes a malicious program. The method of claim 18, The malicious program blocking method may include determining whether a malicious program is included in the binary file when there is no signature on the binary file. Generating a signature for the binary file if the malicious file does not contain a malicious program; Inserting the generated signature into the binary file; And And blocking the execution of the binary file. The method of claim 19, If the binary file does not contain a malicious program, generating a signature for the binary file may include At least one of HMAC-MD5 (keyed-Hash Message Authentication Code Message-Digest algorithm 5), HMAC-SHA-1 (keyed-Hash Message Authentication Code Secure Hash Algorithm-1) and RSA is used to generate the signature for the binary file. Malicious program blocking method characterized in that. The method of claim 19, If the binary file does not contain a malicious program, generating a signature for the binary file may include A method for blocking malicious programs, comprising using ISAKMP (Internet Security Association & Key Management Protocol) in exchanging a secret key required to generate a signature for the binary file. The method of claim 18, The malicious program blocking method, after determining whether a signature exists for the binary file to be executed, Verifying a signature on the binary file if a signature exists on the binary file; And Allowing execution of the binary file when the binary file has not changed as a result of the verification, In the case where the signature for the binary file does not exist, determining whether the binary file includes a malicious program And determining whether a binary program is included in the binary file when the signature on the binary file does not exist and when the binary file is changed as a result of the verification. The method of claim 22, Verifying the signature on the binary file if the signature exists on the binary file At least one of HMAC-MD5 (keyed-Hash Message Authentication Code Message-Digest algorithm 5), HMAC-SHA-1 (keyed-Hash Message Authentication Code Secure Hash Algorithm-1) and RSA is used to verify the signature on the binary file. Malicious program blocking method characterized in that. The method of claim 22, Verifying the signature on the binary file if the signature exists on the binary file A method for blocking malicious programs, comprising using ISAKMP (Internet Security Association & Key Management Protocol) in exchanging a secret key required for signature verification of the binary file. The method of claim 18, The binary file is a malicious program blocking method characterized in that the Executable and Linking Format (ELF) format. The method of claim 18, The malicious program blocking method is operable before the binary file is loaded into memory and executed. The method of claim 26, The malicious program blocking method is characterized in that the hooking (Hooking) at the kernel level (Kernel) in the execution process of the binary file. The method of claim 27, The malicious program blocking method, characterized in that for changing the file_mmap function in the Linux Security Modules (LSM) framework. A computer-readable recording medium having recorded thereon a program for performing the method according to any one of claims 18 to 28.

Images