KR101816022B1

KR101816022B1 - Appratus and method for controlling the same

Info

Publication number: KR101816022B1
Application number: KR1020150162651A
Authority: KR
Inventors: 황수익
Original assignee: 시큐리티플랫폼 주식회사
Priority date: 2015-11-19
Filing date: 2015-11-19
Publication date: 2018-01-31
Also published as: KR20170059055A

Abstract

BACKGROUND OF THE INVENTION 1. Field of the Invention [0001] The present invention relates to an apparatus and a control method thereof that improve security during a booting process. The apparatus comprises: a memory for storing reference data; And a step of calculating a hash value of the file and extracting a reference hash value corresponding to the file from the reference data before executing the file for booting of the embedded Linux and if the hash value coincides with the reference hash value , And a control unit for executing the file.

Description

[0001] APPARATUS AND METHOD FOR CONTROLLING THE SAME [0002]

BACKGROUND OF THE INVENTION 1. Field of the Invention [0001] The present invention relates to an apparatus and a control method thereof that improve security during a booting process.

Most of the devices that use the Internet use Embedded Linux as an operating system (OS). Embedded Linux has the advantage of being faster and more secure than normal Linux because it is designed to match the device features.

Objects Internet devices are basically communicating, so they are always exposed to security threats. The case of the DDoS attack using the zombie wireless router and the case of sending the spam message of 750000 through the hacked smart TV and the refrigerator shows that the device using the Internet is exposed to security threats.

The number of devices using the Internet is expected to reach 50 billion in 2020, from 900 million in 2009. As the number of devices using the Internet has increased exponentially, the security of devices using the Internet has become an increasingly important issue.

Because embedded Linux devices are typically designed to perform specific functions, it is common for hardware specifications to be lower than for multifunctional computing devices. Accordingly, there is a problem that it is difficult to increase the security of the device by installing a separate security program in the device to which the embedded Linux is applied.

It is an object of the present invention to provide an apparatus with improved security and a control method thereof.

Specifically, it is an object of the present invention to provide an apparatus and method for controlling the validity of a boot file and a system file at each stage of an embedded Linux boot.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not intended to limit the invention to the precise forms disclosed. It will be possible.

According to an aspect of the present invention, there is provided a data processing apparatus including: a memory for storing reference data; And a step of calculating a hash value of the file and extracting a reference hash value corresponding to the file from the reference data before executing the file for booting of the embedded Linux and if the hash value coincides with the reference hash value And a control unit for executing the file.

According to another aspect of the present invention, there is provided a method for booting an embedded Linux, the method comprising: calculating a hash value of the file prior to executing a file for booting embedded Linux; Extracting a reference hash value corresponding to the file from the reference data; And executing the file in which the hash value matches the reference hash value.

The present invention is not limited to the above-mentioned solving means, and other solving means which is not mentioned may be apparent from the following description to those skilled in the art to which the present invention belongs It can be understood.

Effects of the mobile terminal and the control method according to the present invention will be described as follows.

According to at least one of the embodiments of the present invention, it is possible to provide an apparatus with improved security and a control method thereof.

Specifically, the present invention has the effect of enhancing the security of the device by checking the validity of the boot file and the system file at each stage of the embedded Linux boot.

The effects achieved by the present invention are not limited to the effects mentioned above, and other effects not mentioned can be clearly understood by those skilled in the art from the following description .

1 is a block diagram of an apparatus according to the present invention.
2 is a diagram showing a general boot flow of embedded Linux.
3 is a flowchart illustrating an operation of an apparatus for performing a secure boot according to the present invention.
4 is a diagram showing an example of calculating a hash value of a large capacity system file.
5 is a diagram showing an example of calculating a root hash value.
FIG. 6 is a diagram illustrating a process of isolating and restoring a boot file.
Figure 7 is an illustration of an analysis system.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings, wherein like reference numerals are used to designate identical or similar elements, and redundant description thereof will be omitted. The suffix "module" and " part "for the components used in the following description are given or mixed in consideration of ease of specification, and do not have their own meaning or role. In the following description of the embodiments of the present invention, a detailed description of related arts will be omitted when it is determined that the gist of the embodiments disclosed herein may be blurred. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed. , &Lt; / RTI > equivalents, and alternatives.

Terms including ordinals, such as first, second, etc., may be used to describe various elements, but the elements are not limited to these terms. The terms are used only for the purpose of distinguishing one component from another.

The singular expressions include plural expressions unless the context clearly dictates otherwise.

In the present application, the terms "comprises", "having", and the like are used to specify that a feature, a number, a step, an operation, an element, a component, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

The present invention provides a method for enhancing security of a device by porting embedded Linux embedded with a security function. For convenience of explanation, the boot loader file, the kernel file, and the initial file used during the boot process of the embedded Linux will be referred to as a 'boot file'.

1 is a block diagram of an apparatus according to the present invention. Referring to FIG. 1, the apparatus may include a communication unit 110, a memory 120, and a control unit 130.

The communication unit 110 performs communication with an external device. The communication unit 110 may perform communication with an external device according to mobile communication technology or wireless Internet technologies. Communication technologies between the communication unit 110 and external devices include Global System for Mobile communication (GSM), Code Division Multi Access (CDMA), Enhanced Voice-Data Optimized or Enhanced Voice-Data Only (EV-DO) Wideband CDMA), High Speed Downlink Packet Access (HSDPA), High Speed Uplink Packet Access (HSUPA), Long Term Evolution (LTE), Long Term Evolution-Advanced (LTE-A) (WiBro), Wi-Fi (Wireless Fidelity) Direct, DLNA (Digital Living Network Alliance), WiBro (Wireless Broadband) and WiMAX (World Interoperability for Microwave Access). The communication unit 110 may operate as a component for performing the object Internet.

The memory 120 stores boot files, system files, and the like for execution of embedded Linux and various data to be processed on the embedded Linux. For example, the memory 120 may be a hard disk drive (HDD), a flash memory, a SD (Secure Digital) memory, a UICC (Universal IC Card), a RAM &Lt; / RTI >

The memory 120 may have at least a plurality of repositories. The plurality of repositories may be constituted by dividing one module into a plurality of partitions or may be constituted by a plurality of modules. Hereinafter, for convenience of explanation, it is assumed that a plurality of storages are configured by dividing one module into a plurality of partitions.

One of the plurality of repositories stores a boot file and a system file for execution of embedded Linux, and the other one stores backup data of a boot file and a system file. In addition, another repository can be used as a space for isolating a boot file or a system file in which a security risk is detected.

For convenience of explanation, in the embodiments described below, a repository for storing boot files and system files for execution of embedded Linux is referred to as a boot partition, and a repository for storing backup data of boot files and system files is called a backup partition . In addition, a boot file or a system file that detects a security risk is referred to as a quorum partition (or sandbox).)

The control unit 130 performs various operations for controlling devices such as booting of embedded Linux, execution of system files, and data processing. Specifically, the control unit 130 executes the boot file and can process the commands that the boot file specifies. The control unit 130 may include a data processing device such as a CPU (Central Processing Unit) or an MCU (Micro Controller Unit).

The mobile terminal according to the present invention will be described in detail based on the above description.

2 is a diagram showing a general boot flow of embedded Linux.

When power is applied to the apparatus, the boot loader can be executed by receiving the control from the BIOS (S210). The boot loader, the device performs preliminary work for the kernel to start up correctly. For example, the boot loader may perform preliminary tasks such as initialization of the hardware, synchronization of the memory 120 and the CPU, and setting of an Ethernet port. When the boot menu is selected, the boot loader can execute the kernel corresponding to the selected boot menu (S220).

The kernel initializes each device and then loads the init process. Specifically, the controller 130 can determine the format of the data block for performing the initial process through the kernel.

When the initial program is executed (S230), the control unit 130 can set the hardware and execute the script corresponding to the specified run level. The initial process can be performed by executing an initial file such as an Init file or an Initrd (initial ramdisk) file.

Thereafter, the control unit 130 can execute the system file necessary for the embedded Linux to operate (S240). In addition, the control unit 130 may execute a log file, a user file, and other files to complete the booting of embedded Linux (S250).

If one of the many boot files and system files that are run during the boot process is infected with malicious code, it is difficult to ensure a safe boot of the device. Thus, the apparatus can check the validity of the boot file and the system file used in each booting step, and control the booting step to be performed only when the validity of the file is confirmed.

For example, FIG. 3 is a flowchart illustrating an operation of an apparatus for performing a secure boot according to the present invention.

Referring to FIG. 3, the controller 130 can confirm the validity of each boot file before executing each boot file for booting embedded Linux. For example, if it is determined that the boot loader file is valid (S301), the control unit 130 executes the boot loader file (S302). If the kernel file is found valid (S304), the control unit 130 executes the kernel file (S305) If it is determined that the initial file is valid (S307), the initial file can be executed (S308). The system file may also be executed (S311), provided that the validity is verified (S310).

Hereinafter, a method of verifying the validity of the boot file and the system file will be described in detail.

In the memory 120, a reference hash value for verifying the validity of each boot file and the system file can be stored. At this time, in order to ensure data integrity of the reference hash value, the signature of the manufacturer may be added to the reference hash value.

Before execution of the boot file or the system file, the control unit 130 calculates a hash value of the boot file or system file to be executed, and extracts a reference hash value corresponding to the boot file or the system file to be executed. If the hash value of the boot file or the system file to be executed is equal to the reference hash value, the control unit 130 can execute the corresponding boot file or system file.

For example, when a Linux Loader (LILO) file is to be executed as a boot loader file, the control unit 130 may compare the hash value of the LILO file with the reference hash value stored in the memory 120 before executing the LILO file . If the hash value of the LILO file matches the reference hash value, the control unit 130 can execute the LILO file.

The hash value used to identify each file has a shorter length than the corresponding file. Accordingly, if the hash value is used to check the validity of the boot file or the system file, the storage capacity required to store the reference data (i.e., the reference hash value) necessary for validation can be reduced.

However, a hash value of a large file such as a system file has a large hash value. In order to reduce the size of the hash value, the control unit 130 may divide the large-capacity file into reference units and generate a hash value of the large-capacity file from the hash value of each fragmented file.

For example, FIG. 4 is a diagram illustrating an example of calculating a hash value of a large capacity system file.

If the size of the system file is larger than the first reference value, the controller 130 divides the system file into reference unit intervals, and then calculates a hash value of each piece. As an example, in the example shown in Fig. 4, the system file is illustrated as being carved in units of 4 Kbytes. The first reference value and the reference unit may have the same value (for example, 4 Kbytes) or may have different values.

Then, the control unit 130 can calculate the hash value of the system file based on the hash value of each file fragment. For example, the control unit 130 may calculate the hash value 410 of the system file by adding the hash value of each file fragment.

If the size of the hash value of the boot file or the system file is larger than the second reference value, the controller 130 compares the root hash value calculated from the hash value with the reference hash value, .

For example, FIG. 5 shows an example of calculating a root hash value.

If the size of the system file is larger than the first reference value, the controller 130 divides the system file into reference unit intervals and generates a hash value of each piece.

At this time, if the first hash value 510 calculated from the hash value of each piece is larger than the second reference value, the controller 130 may divide the first hash value 510 into reference unit intervals again. Then, the control unit 130 may reassemble the hash value for each first hash value fragment. At this time, the second reference value and the reference unit may have the same value (for example, 4 Kbytes) or may have different values.

The control unit 130 may calculate the second hash value 520 based on the hash value of the first hash value fragment. For example, the control unit 130 may calculate the second hash value 520 by summing the hash values of the first hash value fragments.

If the size of the second hash value is smaller than the second reference value, the controller 130 may verify the validity of the system file by comparing the second hash value with the reference hash value. Although not shown, if the size of the second hash value is larger than the second reference value, the second hash value is divided by the unit fragment interval, and the operation of computing the third hash value from the hash value of each unit fragment is performed again .

5, if the size of the N-th hash value is larger than the second reference value, the controller 130 divides the N-th hash value into unit pieces, calculates a hash value of each piece, The (N + 1) -th hash value can be calculated from the hash value. If the size of the (N + 1) hash value is less than the second reference value, the controller 130 may use the (N + 1) hash value as the root hash value and compare the (N + 1) hash value with the reference hash value. The control unit 130 can verify the validity of the boot file and the system file by comparing the (N + 1) hash value (i.e., the root hash value) with the reference hash value.

As described above, the control unit 130 can check the validity of the boot file before executing the boot file necessary for booting the embedded Linux, such as the boot loader file, the kernel file, the initial file, and the system file, have.

If the boot file is determined to be invalid (for example, the hash value of the boot file is different from the reference hash value) as the boot file is falsified or tampered, the control unit 130 moves the invalid boot file to the quarantine partition, An invalid boot file can be restored using the backup boot file (S303, S306, S309, S312).

For example, FIG. 6 is a diagram illustrating a process of isolating and restoring a boot file.

If the hash value of the boot file stored in the boot partition is inconsistent with the reference hash value, the control unit 130 can move the boot file to the quarantine partition. 6 (a), when it is determined that the hash value of the boot loader file stored in the boot partition is incompatible with the reference hash value, The boot loader file can be moved to the quarantine partition, as in the example shown in FIG. Then, the controller 130 may restore the boot loader file to the boot partition using the boot loader file stored in the backup partition, as in the example shown in (c) of FIG.

When the boot file is restored, the control unit 130 reboots to restart the embedded Linux boot (S313). As another example, the control unit 130 may verify the validity of the restored boot file, or execute the restored boot file, without performing the reboot, to continue the booting process.

For log files, user files, and other files, the validation process by comparing hash values may be omitted.

If booting of the embedded Linux is completed and an invalid boot file is added to the isolation partition (S315), the control unit 130 may transmit an invalid boot file to the collection server for malicious code analysis (S316). When the transfer of the boot file is completed, the controller 130 may delete the invalid boot file that has been transferred from the isolated partition.

The analysis system for malicious code analysis may include a collection server for collecting malicious code, a signature diagnosis server, a behavior analysis server, and an analysis server.

As an example, FIG. 7 is a diagram illustrating an analysis system.

The collection server is responsible for receiving a boot file (i.e., an invalid boot file) from various devices. In addition, the collection server can database the collected boot files (analysis management database).

The signature diagnostic server can check whether the boot file recorded in the analysis management database is a new type. If the boot file is a new type, the signature diagnostic server can send the boot file to the behavior analysis server.

The action server determines whether the received boot file is malware. At this time, as a criterion for judging malware, the following evaluation factors may be applied.

- Whether or not the malicious file was created

- whether to attempt to connect to outside communication

- whether it runs in an abnormal way

- Whether to trigger bulk traffic

- Whether to make changes to system files

- Whether to change the system settings

If the boot file is determined to be malware, the action server may extract the signature of the boot file and store it in the signature database.

It is to be understood that the above-described embodiments of the present invention are not limited to the above-described embodiments, and the present invention may be embodied with various other modifications and alternative embodiments. have.

110:
120: Memory
130:

Claims

A memory for storing reference data; And
The method comprising: calculating a hash value of the file before executing a file for booting embedded Linux; extracting a reference hash value corresponding to the file from the reference data; and if the hash value matches the reference hash value, And a control unit for executing the file,
The memory including a first storage for storing the file and a second storage for storing an invalid file,
Wherein the control unit moves the file to the second storage when the hash value does not match the reference hash value.

The method according to claim 1,
Wherein the memory further comprises a third storage for storing backup data of the file,
Wherein the control unit restores the file based on the backup data when the hash value does not match the reference hash value.

3. The method of claim 2,
Wherein the control unit performs a system reboot when the file is restored.

3. The method of claim 2,
Wherein the control unit immediately executes the restored file when the file is restored.

delete

The method according to claim 1,
The apparatus further includes a communication unit,
Wherein when the booting of the embedded Linux is completed, the controller transmits the file stored in the second storage to the pre-designated server.

The method according to claim 1,
When the size of the file is equal to or larger than a preset reference value,
Wherein the hash value is calculated based on a hash value of each file fragment after dividing the file into a plurality of fragments.

8. The method of claim 7,
And the hash value is calculated by summing the hash values of the respective file fragments.

The method according to claim 1,
When the size of the initial hash value of the file is equal to or larger than a preset reference value,
Wherein the hash value is calculated based on a hash value of each initial hash value fragment after dividing the initial hash value into a plurality of fragments.

10. The method of claim 9,
Wherein the hash value is computed by summing the hash values of each initial hash value fragment.

The method according to claim 1,
Wherein the boot file comprises at least one of a boot loader, a kernel, an initial file, and a system file.

Computing a hash value of the file prior to executing the file for booting embedded Linux;
Extracting a reference hash value corresponding to the file from the reference data; And
Executing the file in which the hash value matches the reference hash value
, &Lt; / RTI &
If the hash value does not match the reference hash value, moving the file to another repository distinct from the repository where the file is stored.

13. The method of claim 12,
And restoring the file based on the backup data if the hash value does not match the reference hash value.

14. The method of claim 13,
Further comprising performing a system reboot after the file is restored.

14. The method of claim 13,
And when the file is restored, immediately executing the restored file.

delete

13. The method of claim 12,
And when the booting of the embedded Linux is completed, transferring the file stored in the another repository to a pre-designated server.

13. The method of claim 12,
When the size of the file is equal to or larger than a preset reference value,
Wherein the hash value is calculated based on a hash value of each file fragment after dividing the file into a plurality of fragments.

19. The method of claim 18,
And the hash value is calculated by summing the hash values of the respective file fragments.

13. The method of claim 12,
When the size of the initial hash value of the file is equal to or larger than a preset reference value,
Wherein the hash value is calculated based on a hash value of each initial hash value fragment after dividing the initial hash value into a plurality of fragments.

21. The method of claim 20,
And the hash value is calculated by summing the hash values of the respective initial hash value fragments.

13. The method of claim 12,
Wherein the boot file comprises at least one of a boot loader, a kernel, an initial file, and a system file.