KR20140020414A - Method of malware scanning using a checksum list and terminal apparatus using the same - Google Patents

Abstract

According to an embodiment of the present inventive concept, a terminal device is provided. The terminal device comprises: a central processing unit (CPU); a memory connected to the central processing unit, and storing a list management unit executed by the central processing unit and managing a checksum list; and a system on a chip connected to a bus and having a cipher/authentication (CA) engine. The list management unit requests the cipher/authentication engine of the system on the chip to obtain a checksum for a scan object file as a malware scan object, receives the checksum for the scan object file from the cipher/authentication engine of the system on the chip, and determines whether to perform malware scan for the scan object file according to a result obtained by determining whether the received checksum is in the checksum list. [Reference numerals] (31) First list; (32) Second list; (55) C/A engine; (70) AM application; (71) AM UI; (72) AM engine; (73) Pattern DB; (80) List management unit

Description

Method of malware scanning using a checksum list and Terminal apparatus using the same}

The present invention relates to a malware scanning method using a checksum list and a terminal device using the same.

With the widespread use of the Internet, malicious malware of various types such as worms, Trojan horses, viruses, DDoS, etc. have appeared and the damage is increasing. Thus, there is a need for network breach response methods and devices such as anti-malware engines and / or firewall engines to protect devices from external networks.

In particular, in the case of a mobile device, available resources are limited. Therefore, there is a need for a technique that can quickly and effectively perform malware scanning within a limited range of resources.

According to an exemplary embodiment of the present invention, an object of the present invention is to provide a malware scanning method using a checksum list and a terminal device using the same, which can quickly perform malware scanning even in a situation where available resources are limited.

According to an embodiment of the present invention, a central processing unit (CPU); A memory coupled to the central processing unit, the memory storing a list management unit executed by the central processing unit and managing a checksum list; And a system on chip connected to the bus and having a cryptographic / authentication (CA) engine, wherein the list manager is configured to obtain a checksum for a scan target file to be a malware scan target. Requesting a cipher / authentication engine, receiving a checksum for the scan target file from the cipher / authentication engine of the system on chip, and determining whether or not the checksum provided is in the checksum list. There is provided a terminal device for determining whether to perform a malware scan.

According to an embodiment of the present invention, an anti-malware scanning method in a mobile terminal device, the method comprising: storing a checksum list; Calculating a checksum of the scan target file by the encryption / authentication engine; Determining whether to perform an antimalware scan operation on the scan target file according to whether or not the checksum calculated by the cipher / authentication engine is in the checksum list. Provided are an anti-malware scanning method in a mobile terminal provided in a system on chip provided in a terminal.

According to an embodiment of the inventive concept, storing and managing a checksum list in a mobile terminal device; Allowing a system on chip included in the mobile terminal device to calculate a checksum of a scan target file; And determining whether to perform an anti-malware scan operation on the scan target file according to whether or not the checksum calculated by the cipher / authentication engine is in the checksum list. A recording medium is provided.

According to an exemplary embodiment of the inventive concept, malware scanning can be performed quickly, and malware scanning can be performed quickly even in a situation where available resources are limited.

1 is a block diagram of a terminal device according to an exemplary embodiment of the inventive concept;
2 is a diagram illustrating a malware scan operation according to an embodiment performed by a terminal device;
3 is a flowchart illustrating a malware scanning method of FIG.
4 is a diagram illustrating a malware scan operation according to another embodiment performed by a terminal device;
5 is a flowchart illustrating a malware scanning method of FIG.
6 is a diagram illustrating a malware scan operation according to another embodiment performed by a terminal device;
FIG. 7 is a flowchart illustrating a malware scanning method of FIG. 6.
8 is a diagram illustrating a malware scan operation according to another embodiment performed by a terminal device;
9 is a flowchart illustrating a malware scanning method of FIG. 8.

BRIEF DESCRIPTION OF THE DRAWINGS The above and other objects, features, and advantages of the present invention will become more readily apparent from the following description of preferred embodiments with reference to the accompanying drawings. However, the present invention is not limited to the embodiments described herein but may be embodied in other forms. Rather, the embodiments disclosed herein are provided so that the disclosure can be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

In this specification, when an element is referred to as being on another element, it may be directly formed on another element, or a third element may be interposed therebetween.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. In the present specification, the singular form includes plural forms unless otherwise specified in the specification. As used herein, the terms "comprises" and / or "comprising" do not exclude the presence or addition of one or more other elements.

In addition, the malware scanning of any file in this specification is to check whether the file contains a specific pattern of malware, and in this sense, generally, "scan a file" and "scan for malware" in the art. "Or" Scan a file ". Therefore, in this specification, the expressions "scan for malware", "scan for file", "scan for malware", and "scan for file" all have the same meaning.

Hereinafter, the present invention will be described in detail with reference to the drawings. In describing the specific embodiments below, various specific details have been set forth in order to explain the invention in greater detail and to assist in understanding it. However, those skilled in the art can understand that the present invention can be used without these various specific details. In some instances, it should be noted that portions of the invention that are well known in the description of the invention and are not significantly related to the invention do not describe confusion in describing the invention.

1 is a block diagram of a terminal device according to an exemplary embodiment of the inventive concept.

Referring to FIG. 1, a terminal device 100 according to an embodiment includes a central processing unit (CPU) 10, a first memory 20, a second memory 30, a storage unit 40, and a system on. Chip (SOC) 50 may be included.

The terminal device 100 may be one of a personal computer (PC), a smart phone, a PDA, a mobile device, an embedded device capable of networking, or any device such as a cellular phone.

In the illustrated embodiment, the terminal device 100 may further include various hardware and drivers installed on the hardware, firmware, an operating system (OS), and various applications, but are omitted in the present specification so as not to obscure the subject matter of the present invention.

The CPU 10 corresponds to a main processor of the terminal device 100. For example, when the terminal device 100 is a mobile device such as a smartphone, the CPU 10 may mean a processor included in the application processor (AP). Those skilled in the art will understand.

The first memory 20 is a main memory of the terminal device 100, and is a volatile storage device capable of storing program codes and data for executing a program or temporarily storing data. The first memory 20 may be implemented with, for example, a memory device such as DRAM or SRAM, but is not limited thereto.

The second memory 30 is a volatile storage device that can be additionally installed, but may be implemented as an SRAM or a DRAM, but is not limited thereto. The second memory 30 may be, for example, a cache memory, and in this case, the second memory 30 may be embodied in the CPU 10.

The storage unit 40 is a nonvolatile storage device capable of semi-permanently storing various software, firmware, and data. The storage unit 40 may be implemented as, for example, a solid state disk (SSD) such as a hard disk drive (HDD) or a flash memory, but is not limited thereto.

The storage unit 40 may store one or more antimalware (AM) applications and firmware for controlling the antimalware (AM) engine, and the AM application and firmware are loaded into the first memory 20. One or more files to be executed and scanned may also be loaded into the first memory 20 and scanned by the AM engine. Malware here refers to software or code that disrupts the operation of the system or exposes it to risk, such as viruses, adware, spyware, or Trojan horses.

The system on chip (SOC) 50 illustrates an example of a system on chip (SOC) having an antimalware (AM) function, a firewall (FW) function, and a password / authentication (Crypto-Auth) function. 50 may include its own CPU 51 and memory 52, and anti-malware (AM) engine 53, firewall (FW) engine, and crypto / authentication (CA) engine 55. have.

However, the above-described embodiment is only one example in which the present invention can be implemented. That is, in alternative embodiments, AM engine 53, FW engine, and CA engine 55 may be implemented without using SOC 50. In this case, the CPU 51 or the memory 52 is not necessary, and the device 100 may directly include the AM engine 53, the FW engine, and the CA engine 55. In yet another alternative embodiment, only some of the AM engine 53, the FW engine, and the CA engine 55 may be configured to be implemented in the SOC 50.

2 is a diagram illustrating a malware scanning operation according to an embodiment performed by a terminal device.

Referring to FIG. 2, the terminal device 100 includes an antimalware (AM) application 70 having an antimalware function, a pattern DB 73 storing a malware pattern, and lists of files 31 and 32 for malware scanning. , And a list manager 80 that manages the list.

In one embodiment, the AM application 70 may include an AM user interface (UI) 71 and an AM engine 72. The AM UI 71 is an interface function unit that receives an anti-malware related command from a user and shows a result of a malware scan to the user. The AM engine 72 is an engine unit that performs a malware scan. The malware scan may be performed by performing an operation of matching files with malware patterns stored in the pattern DB 73.

On the other hand, it should be noted that the AM application 70 may be separate from the AM engine 53 in the SOC 50 shown in FIG. That is, as shown in FIG. 1, the terminal device 100 may include only the AM engine 53 in the SOC 50, but FIG. 2 shows a separate anti-not included in the system on chip 50. The case where the malware application 70 is installed and executed in the terminal device 100 is shown, and the same applies to the subsequent drawings (FIGS. 4, 6, and 8).

The lists 31 and 32 are lists of files for malware scanning, and preferably include a first list 31 and a second list 32. In one embodiment, the first list 31 is a list of files to be scanned and the second list 32 is a list of scanned files. According to an embodiment, the second list 32 may be a list of files (ie, a white list) that is found to be not malware as a result of scanning, or a list of files (ie, a black list) that is determined to be malware as a result of scanning. It may be a list including both the white list and the black list.

In one embodiment, the first list 31 includes information of a file to be scanned by any AM application in the terminal device 100. The information of the file may include, for example, information of one or more of the name, location, size, and checksum of the file.

The second list 32 contains the information of the files already scanned. As information of this file, for example, it may include one or more of the name, location, size, and checksum of each file. In one embodiment, the second list 32 may include at least a checksum. Accordingly, the second list 32 is also referred to herein as a "checksum list."

The list manager 80 is a functional module having a management function such as input and deletion of the lists 31 and 32. In one embodiment, the list manager 80 may be implemented as software or firmware.

In the above-described configuration, while the terminal device 100 is operating, the lists 31 and 32 may be loaded and maintained in the second memory 30, and the AM application 70 and the list manager 80 may be respectively. The program codes and data may be loaded into the first memory 20 from the storage 40 and executed.

Meanwhile, as described with reference to FIG. 1, the SOC 50 may include a cipher / authentication (CA) engine 55. As shown in Fig. 2, the CA engine 55 includes a function for calculating a checksum. For example, the CA engine 55 may obtain a checksum of each file with respect to various files stored in the storage 40. This function can be implemented as hardware, software, and / or firmware in the CA engine 55. As a method of obtaining a checksum, a hash algorithm of MD5, SHA1, or SHA2 can be used, but is not limited thereto. Of course it can be used.

In the illustrated embodiment, if the lists 31 and 32 include checksums in the information of each file, the list manager 80 obtains a checksum from the CA engine 55 and adds the checksums to the lists 31 and 32. You can enter

A malware scanning method according to the above configuration will be described below with reference to FIG. 3 is a flowchart illustrating a malware scanning method of FIG. 2.

In the embodiment of Fig. 3, it is assumed that file information for a predetermined file is previously stored in the list. As an example, the second list 32 includes information of the file that is found to be not malware as a result of the scan (ie, the second list is a white list) and includes the file name and checksum value of the file as file information. Assume that

Referring to FIG. 3, in step S301, the list manager 80 may receive a scan command of a file. In one embodiment, the AM UI 71 of the AM application 70 receives a malware inspection command from the user, and the AM application 70 notifies the list manager 80 of the command so that the list manager 80 The scan command can be received. As another embodiment, for example, the list manager 80 may receive a scan command due to a malware inspection cycle or a predetermined event set in the AM application 70.

When the scan command is received, the list manager 80 adds the file to be scanned to the first list 31 in step S302. In an embodiment, the list manager 80 may add the file information of the file to be scanned to the first list 31, and as a specific example, the file name and location (address in memory or storage) of the file to be scanned. ) May be input to the first list 31.

In step S303, at the request of the list manager 80, the CA engine 55 may calculate respective checksums for the scan target files in the first list 31. The checksum can be calculated by any one of the hash algorithms, such as MD5, SHA1, SHA2. As an example, when the checksum of the malware pattern is stored in the pattern DB 73 used by the AM application 70, the scan target file is determined by the same checksum algorithm as the checksum algorithm used when obtaining the checksum of the malware pattern. You can also obtain the checksum of.

In step S304, the list manager 80 compares the checksum calculated by the CA engine 55 with the checksum of the second list, and branches in step S305 according to the comparison result.

Since the second list 32 is assumed to be a white list in the embodiment of Fig. 3, it means that for any file, if the checksum calculated by the CA engine 55 is in the second list, this file is not malware do. Therefore, since there is no need to perform a malware check on the file, the process proceeds to step S306, the deletion from the first list (i.e., the list of files to be scanned) and the step S311 of notifying the user of the result. Can be.

If as a result of the comparison of step S305, the checksum calculated by the CA engine 55 for any file is not in the second list, it is not confirmed that the file is not malware, the process proceeds to step S307 and AM. Scanned by the application 70. In this step S307, for example, the AM engine 72 of the AM application 70 may refer to the pattern DB 73 to perform malware inspection of the file.

At this time, the AM application 70 may be an application that checks the malware using a checksum. In this case, the CA engine 55 of the system on chip 50 may be used to calculate the checksum of the malware pattern of the pattern DB 73. That is, the CA engine 55 may calculate the checksum of the malware pattern using the same algorithm as the algorithm used for the checksum calculation in the AM application 70 and provide the same to the AM application 70.

Then, in step S308, the next step branches according to the scan result of the AM application 70. If the AM application 70 determines that the scanned file does not exist in the pattern DB 73, it means that the file is not malware. Therefore, the process proceeds to step S309, where the list manager 80 stores the file of the file. The information may be added to the second list 32 (ie, the white list), and the step S311 of notifying the user of the result may be proceeded.

If the scanned file is in the pattern DB 73 in step S308, it means that the file is malware and processes the file according to the AM policy preset in the AM application 70. For example, an action may be taken to treat the file, send it to a quarantine or delete it, and then notify the user of the result of the action (step S311).

Although not shown in the drawing, when the AM application 70 scans the file in step S307, the scanned file may be deleted from the first list.

By the above operation, since the file to be scanned is first compared with the second list 32, since the malware inspection can be completed without scanning all the files to be scanned, the terminal apparatus 100 There is an advantage in that the malware scan operation can be performed quickly and effectively within the limited resource range.

4 is a diagram for describing a malware scan operation according to another embodiment performed by a terminal device.

Referring to FIG. 4, the terminal device 100 further includes a third list 33. The third list 33 is a list (ie, a black list) of files that are found malware as a result of scanning. In one embodiment, the third list 33 may include information of a file that is found to be malware, and may include, for example, one or more of the name, location, size, and checksum of each file as the information of the file.

The configuration of FIG. 4 is the same as or similar to that of FIG. 2 except for further including a third list 33, and thus, the description of the remaining components is omitted.

A malware scanning method according to the above configuration will be described below with reference to FIG. 5. 5 is a flowchart illustrating a malware scanning method of FIG. 4.

In the embodiment of Fig. 5, it is assumed that file information for a predetermined file is previously stored in the list. As an example, the second list 32 contains the information of the file that is found to be not malware as a result of the scan, and the third list 33 contains the information of the file that is found to be malware, and the file as the respective file information. Suppose you include the name and checksum of a file.

Referring to FIG. 5, steps S501 to S503 may be the same as or similar to steps S301 to S303 of FIG. 3. For example, in step S501, when the list manager 80 receives a scan command of a file and receives the scan command, the list manager 80 sends the scan target file to the first list 31 in step S502. Add. Then, in step S503, at the request of the list management unit 80, the CA engine 55 calculates each checksum for the scan target file in the first list 31.

In step S504, the list manager 80 compares the checksum calculated by the CA engine 55 with the checksum of the list. At this time, the list manager 80 compares the calculated checksum with the second list 32 and the third list 33, respectively, and branches in step S505 according to the comparison result.

In the illustrated embodiment, for any file the calculated checksum can first be compared with a third list 33, so that if the calculated checksum is in the third list 33, the file is malware. In other words, the file may be processed according to the AM policy preset in step S506. The AM policy may be a policy set in the list management unit 80 or a policy set in the AM application unit 70. For example, an action such as treating the file, sending it to a quarantine, or deleting the file may be taken.

In step S505, if the calculated checksum is not in the third list 33, the flow advances to step S507 to determine whether the second list 32 is also present.

In step S507, if the calculated checksum is in the second list 32, it means that the file is not a malware, so there is no need to perform a malware check on the file. Therefore, the flow advances to step S508, deletes from the first list (i.e., the list of files to be scanned) and notifies the user of the result (step S513).

However, if the result of the comparison in step S507 is that the checksum is not in the second list 32, the file is not confirmed as not malware, and the process proceeds to step S509 and is scanned by the AM application 70. In this step S509, for example, the AM engine 72 of the AM application 70 may refer to the pattern DB 73 to perform malware inspection of the file.

At this time, the AM application 70 may be an application that checks the malware using a checksum. In this case, the CA engine 55 of the system on chip 50 may be used to calculate the checksum of the malware pattern of the pattern DB 73. That is, the CA engine 55 may calculate the checksum of the malware pattern using the same algorithm as the algorithm used for the checksum calculation in the AM application 70 and provide the same to the AM application 70.

The order of comparing with the third list (S505) and the comparing with the second list (S507) may be reversed.

Then, in step S510, the next step branches according to the scan result of the AM application 70. If the scanned file is in the pattern DB 73, it means that the file is malware. In step S511, the file is processed according to the AM policy preset in the AM application 70, and the result is displayed. Is notified (step S513).

If in step S510, the AM application 70 determines that the scanned file is not in the pattern DB 73, it means that the file is not malware and the process proceeds to step S512 and the list manager 80. ) May add the file information of the file to the second list 32 (ie, the white list), and notify the user of the result (step S311).

By the above operation, since the file to be scanned is first compared with the second list and the third list, the malware inspection can be completed without scanning all the files to be scanned, so that the terminal apparatus 100 There is an advantage that can perform a malware scan operation quickly and effectively within the limited resource range of.

6 is a diagram illustrating a malware scan operation according to another embodiment performed by a terminal device.

Referring to FIG. 6, the terminal device 100 includes a first AM application 701 and a second AM application 702. Such a situation may correspond to, for example, a case where a user purchases two or more kinds of anti-malware software and installs the terminal device 100. As shown in FIG. 2, each of the AM applications 701 and 702 may include a user interface and an AM engine. In addition, each of the AM applications 701 and 702 may include a first pattern DB 731 and a second pattern DB 732.

Compared with FIG. 2, the remaining components of FIG. 6 are the same as or similar to those of FIG. 2, and thus description thereof will be omitted.

A malware scanning method according to the above configuration will be described below with reference to FIG. 7 is a flowchart illustrating a malware scanning method of FIG. 6.

In the embodiment of Fig. 7, it is assumed that file information for a predetermined file is stored in advance in the list. As an example, it is assumed that the second list 32 includes information of a file which is found to be not malware as a result of scanning, and includes a file name and a checksum of the file as file information.

Referring to FIG. 7, steps S801 to S803 may be the same as or similar to the steps S301 to S303 described with reference to FIG. 3. For example, in step S801, when the list manager 80 receives a scan command of a file and receives the scan command, in step S802, the list manager 80 sends the scan target file to the first list 31. Add. Then, in step S803, at the request of the list management unit 80, the CA engine 55 calculates each checksum for the scan target file in the first list 31.

However, in step S801, the list manager 80 may receive a scan command from any of the first AM application 701 or the second AM application 702.

In step S804, the list management unit 80 compares the checksum calculated by the CA engine 55 with the checksum of the second list 32. For any file, if the checksum calculated by the CA engine 55 is in the second list 32, it means that the file is not malware, so there is no need for malware checking for this file. Therefore, the process proceeds to step S805 and deletes from the first list (ie, a list of files to be scanned), and proceeds to step S810 of notifying the user of the result.

If, as a result of the comparison of step S804, the checksum calculated by the CA engine 55 for any file is not in the second list 32, the file is not confirmed as not malware, and therefore, step S806 is performed. Proceed and scanned by the AM application.

In this step S806, however, the file may be scanned by both the first and second AM applications 701 and 702. That is, for example, even if the scan command is generated by the first AM application 701 in the first step S801, in step S806, not only the first AM application 701 but also the second AM application 702 are the same file. The scan operation may be performed on. In this case, each of the first and second AM applications 701 and 702 may perform a malware check on the file by referring to the first and second pattern DBs 731 and 732 respectively corresponding thereto.

In this case, the first AM application 701 or the second AM application 702 may be an application that checks the malware using a checksum. In this case, the CA engine 55 of the system on chip 50 may be used to calculate the checksum of the malware pattern of the first and / or second pattern DBs 731, 732. That is, the CA engine 55 may calculate a checksum using the same algorithm as the algorithm used for calculating the checksum in the first or second AM applications 701 and 702 and provide the same to the corresponding AM application.

Then, in step S807, the next step branches according to the scan result of the first and second AM applications 701 and 702. If it is determined that the file is not in the DB of either or both of the first and second pattern DBs 731 and 732, it means that the file is not malware, and the process proceeds to step S808, where the list manager 80 The file information of the file is added to the second list 32 (ie, the white list), and the result is notified to the user (step S810).

In step S807, if the scanned file is in any one or more of the first and second pattern DBs 731 and 732, it means that the file is malware and processes the file according to a preset AM policy. In one embodiment, the AM policy at this time may be a policy of an AM application that determines the file as malware, and when both AM applications determine the file as malware, for example, an AM application that is determined to be malware by first scanning in time May be selected.

If an action according to the AM policy for the file found to be malware is taken in step S809, the user is then notified of the result of this action (step S810).

6 and 7 illustrate that the terminal device 100 includes two AM applications, the number of AM applications may be greater depending on the embodiment. Those skilled in the art will understand that the terminal device 100 according to the inventive concept can be extended to an embodiment including any plurality of AM applications.

8 is a diagram illustrating a malware scan operation according to another embodiment performed by a terminal device.

Referring to FIG. 8, the terminal device 100 may communicate with an external device 300 through the network 200. Since the terminal device 100 is the same as or similar to the terminal device 100 shown in FIG. 2, description thereof will be omitted.

The network 200 may be a combination of any one or two or more of various types of mobile communication networks and data communication networks, such as the Internet, a local area network (LAN), a long-distance communication network (WAN), WiFi, Bluetooth, 3G network, and 4G network. , Wired or wireless, or a combination thereof.

The device 300 may be implemented by, for example, one or more server devices included in a cloud AM system. In the illustrated embodiment, when the device 300 is a server, the device 300 may include a manager 310, an AM engine 320, and a server-side list 330.

In addition, the device 300 may simultaneously communicate with a plurality of terminal devices having the same or similar configuration as the terminal device 100 through the network 200.

The management unit 310 may include a function of managing communication with the terminal device 100, execution of the AM engine 320, and input / output of the server-side list 330. In alternative embodiments, the aforementioned communication with the terminal device 100, execution of the AM engine 320, and management functions of the server-side list 330 may all be performed by separate management units.

The server-side list 330 may have a file list similar to the first or second lists 31 and 32 of the terminal device 100. In one embodiment, the server-side list 330 may be a list (ie, a white list) that contains information of files that are found to be not malware as a result of scanning, and a list that includes information of files that are found to be malware as a result of scanning. (Ie, a black list) or a list including both the white list and the black list.

In one embodiment, the server-side list 330 may be a white list, and may include, for example, file information of one or more of each file's name, location, size, and checksum.

A malware scanning method according to the above configuration will be described below with reference to FIG. 9 is a flowchart illustrating a malware scanning method of FIG. 8.

In the embodiment of Fig. 9, it is assumed that file information for a predetermined file is previously stored in the list. As an example, the second list 32 includes information of files that are found to be not malware as a result of scanning, and the server-side list 330 also includes information of files that are found to be not malware. It is assumed that each of the lists 32 and 330 includes a file name and a checksum value of the file as file information.

Referring to FIG. 9, steps S1001 to S1003 may be the same as or similar to steps S301 to S303 of FIG. 3. For example, in step S1001, when the list manager 80 receives a scan command of a file and receives the scan command, in step S1002, the list manager 80 adds a scan target file to the first list 31. do. Then, in step S1003, at the request of the list management unit 80, the CA engine 55 calculates each checksum for the scan target file in the first list 31.

In step S1004, the list management unit 80 compares the checksum calculated by the CA engine 55 with the checksum of the second list 32, and branches in step S1005 according to the comparison result.

If the checksum of any file calculated by the CA engine 55 is in the second list 32, it means that the file is not malware. Therefore, since there is no need to perform a malware check on the file, the process proceeds to step S1006, the deletion from the first list (i.e., the list of files to be scanned), and the step S1017 of notifying the user of the result. Can be.

If, as a result of the comparison of step S1005, the checksum calculated by the CA engine 55 is not in the second list, the file is not confirmed as not malware, the flow advances to step S1007 to the AM application 70. Is scanned. In this step S1007, for example, the AM engine 72 of the AM application 70 may refer to the pattern DB 73 to perform malware inspection of the file.

At this time, the AM application 70 may be an application that checks the malware using a checksum. In this case, the CA engine 55 of the system on chip 50 may be used to calculate the checksum of the malware pattern of the pattern DB 73. That is, the CA engine 55 may calculate a checksum using the same algorithm as that used for the checksum calculation in the AM application 70 and provide the same to the AM application 70.

In step S1008, the next step branches according to the scan result of the AM application 70.

If the scanned file is in the pattern DB 73 in step S1008, it means that the file is malware and processes the file according to a preset AM policy. For example, an action may be taken to treat the file, send it to quarantine, delete it, or the like, and then notify the user of the result of the action (step S1017).

In step S1008, if the AM application 70 determines that the scanned file is not in the pattern DB 73, the flow advances to step S1010, through the network 200 of the file and / or this file. The checksum may be sent to the device 300.

In operation S1011, when the device 300 receives the checksum, the management unit 310 compares the received checksum with the checksum of the server-side list 330.

In an alternative embodiment, when the list manager 80 transmits only a file to the device 300 in step S1010, the device 300 calculates a checksum for the received file and in step S1011. This calculated checksum may be compared with the checksum of the server-side list 330.

If it is determined in step S1012 that the checksum of the file is in the server-side list 330, it means that the file is not malware, and the flow proceeds to step S1013, where the device 300 reads the result of the determination. The terminal 100 transmits the information of the file to the second list 32. The result is then notified to the user (step S1017).

If it is determined in step S1012 that the checksum of the file is not in the server-side list 330, the process proceeds to step S1014 where the AM engine 320 of the device 300 may perform a scan for the file. . In this step S1014, for example, the AM engine 320 may perform the scan by referring to an arbitrary malware pattern DB (not shown) on the device 300 side.

Thereafter, if it is determined in step S1015 that the file scanned by the AM engine 320 is not in the pattern DB of the device 300, it means that the file is not malware, and the process proceeds to step S1013 and the device. The 300 transmits the determination result to the terminal device 100. The terminal device 100 adds the information of the file to the second list 32 (step S1013), and notifies the user of this result (step S1017).

If the scanned file is in the pattern DB of the device 300 in step S1015, it means that the file is malware. Then, in step S1016, the determination result is transmitted to the terminal device 100, and the terminal device 100 processes the file according to a preset AM policy, and then notifies the user of the action result (step S1017). ).

Embodiments according to the present invention described above can also be embodied as computer readable codes on a computer readable recording medium. A computer-readable recording medium includes all kinds of recording apparatuses in which data that can be read by a computer system is stored. Examples of the computer-readable recording medium include a ROM, a RAM, a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like, and may be implemented in the form of a carrier wave (for example, transmission via the Internet) . The computer readable recording medium may also be distributed over a networked computer system so that computer readable code can be stored and executed in a distributed manner.

While the present invention has been described with reference to the particular embodiments and drawings, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. This is possible. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined by the equivalents of the claims, as well as the claims.

10: central processing unit 20: first memory
30: second memory 31, 32: file list
40: storage 50: system on a chip (SOC)
53: anti-malware engine 54: firewall (FW) engine
55: password / authentication engine 70: AM application
73: pattern DB 80: list management unit
100: terminal device 300: server
310: management unit 320: AM engine
330: server-side list

Claims (22)

A central processing unit (CPU);
A memory coupled to the central processing unit by a bus and stored by the central processing unit to store a list management unit for managing a checksum list; And
A system on chip connected to the bus and having a cryptographic / authentication engine (C / A);
The list manager requests a cryptographic / authentication engine of the system on chip to obtain a checksum for a scan target file to be scanned for malware, and checks the scansum file for the scan target file from the cryptographic / authentication engine of the system on chip. The terminal device, characterized in that for determining whether to perform a malware scan on the scan target file according to the result of determining whether or not the checksum provided in the checksum list. The method of claim 1,
An anti-malware application executed by the CPU, the anti-malware application not included in the system on chip;
And wherein the anti-malware application scans whether or not malware exists in the scan target file only when the list manager determines to perform a malware scan on the scan target file. 3. The method of claim 2,
And a malware is not present in the scan target file as a result of the malware scan by the anti-malware application, the list manager adds a checksum for the scan target file to the checksum list. 3. The method of claim 2,
As a result of the malware scan by the anti-malware application, when the malware does not exist in the scan target file, the list manager transmits a checksum for the scan target file to an external anti-malware system connected through the network with the terminal device. And receiving a result of whether or not malware exists in the scan target file from the external anti-malware system. 5. The method of claim 4,
The terminal management unit adds a checksum of the scan target file to the checksum list when the result provided from the external anti-malware system indicates that malware does not exist in the scan target file. 3. The method of claim 2,
If the anti-malware application scans an anti-malware using a checksum, the anti-malware application performs an anti-malware scan on the scan target file using the checksum provided from the encryption / authentication engine of the system on chip. Terminal device, characterized in that. The method according to claim 6,
If the anti-malware application scans the anti-malware using a checksum, the cryptographic / authentication engine of the system on chip calculates the checksum using the same algorithm used to calculate the checksum in the anti-malware application. Terminal device, characterized in that provided to the anti-malware application. 3. The method of claim 2,
When the list manager receives a scan command from the anti-malware application, the list manager requests and receives the encryption / authentication engine to calculate a checksum for a scan target file, and determines whether the provided checksum is in the checksum list. Decide,
And wherein the anti-malware application performs a malware scan operation on the scan target file only when it is determined that a checksum for the scan target file is not in the checksum list. The method of claim 1,
A first anti-malware application executed by the central processing unit, the first anti-malware application not included in the system on chip; And
A second anti-malware application executed by the CPU, the second anti-malware application not included in the system on chip;
When the list manager receives a malware scan command from at least one of the anti-malware applications, the list manager requests and receives a checksum for a scan target file from an encryption / authentication engine, and the checksum for the scan target file is determined. And determining whether or not it is on the list. The method of claim 9,
The anti-malware applications perform a malware scan on the scan target file only when it is determined that the checksum provided from the encryption / authentication engine is not in the checksum list.
And the list manager adds the scan target file to the checksum list only when it is determined by the antimalware applications that no malware exists in the scan target file. The method of claim 1,
A first anti-malware application executed by the central processing unit and performing a malware scan operation based on a checksum calculated using a first algorithm, the first anti-malware application not included in the system on chip; And
A second antimalware application executed by the central processing unit and performing a malware scan operation based on a checksum calculated using a second algorithm, the second antimalware application not included in the system on chip; More,
When the malware scan operation by the first anti-malware application is performed, the encryption / authentication engine calculates and provides a checksum to the first anti-malware application using the first algorithm, and scans the malware by the second anti-malware application. When the operation is performed, a terminal device, characterized in that for calculating a checksum using a second algorithm and providing the second antimalware application. In the anti-malware scanning method in a mobile terminal device,
Storing a checksum list;
Calculating, by the encryption / authentication engine, the checksum of the scan target file;
Determining whether to perform an anti-malware scan operation on the scan target file according to whether the checksum calculated by the cipher / authentication engine is in the checksum list.
The encryption / authentication engine is an anti-malware scan method in a mobile terminal device, characterized in that provided in the system on a chip provided in the mobile terminal device. 13. The method of claim 12,
When the checksum calculated by the encryption / authentication engine is not in the checksum list, an anti-malware application not included in the system on chip performs a malware scan on the scan target file. Anti-malware scanning on Windows. The method of claim 13,
And adding a checksum for the scan target file to the checksum list when malware is not present in the scan target file as a result of the malware scan by the anti-malware application. How to scan anti-malware. The method of claim 13,
Transmitting a checksum for the scan target file to an external anti-malware system connected to the mobile terminal through a network when malware is not present in the scan target file as a result of the malware scan by the anti-malware application; And
And receiving a result of whether or not there is malware for the scan target file from the external anti-malware system. The method of claim 15,
And adding a checksum of the scan target file to the checksum list when the result provided from the external anti-malware system indicates that malware does not exist in the scan target file. Anti-malware scanning method on terminal device. 13. The method of claim 12,
If the checksum calculated by the cipher / authentication engine is not in the checksum list, an anti-malware application not included in the system on chip uses the checksum calculated by the cipher / authentication engine to check the file to be scanned. An anti-malware scanning method in a mobile terminal device, characterized in that for performing a malware scan. On the mobile terminal,
Storing and managing a checksum list;
Allowing a system on chip included in the mobile terminal device to calculate a checksum of a scan target file; And
Determining whether to perform an anti-malware scan operation on the scan target file according to whether or not the checksum calculated by the encryption / authentication engine is in the checksum list; media. The method of claim 18,
The program also,
In the mobile terminal device,
If the checksum calculated by the encryption / authentication engine is not in the checksum list, causing the anti-malware application not included in the system on chip to perform a malware scan of the scan target file; A computer readable recording medium having recorded thereon a program. The method of claim 19,
The program also,
In the mobile terminal device,
And adding a checksum for the scan target file to the checksum list when malware is not present in the scan target file as a result of the malware scan by the anti-malware application. Readable Recording Media. The method of claim 19,
The program also,
In the mobile terminal device,
Transmitting a checksum for the scan target file to an external anti-malware system connected to the mobile terminal through a network if no malware exists in the scan target file as a result of the malware scan by the anti-malware application; A computer-readable recording medium having recorded thereon a program which is executed. 22. The method of claim 21,
The program also,
In the mobile terminal device,
And adding a checksum of the scan target file to the checksum list when the result provided from the external anti-malware system is that malware does not exist in the scan target file. A computer-readable recording medium that has been recorded.

Images