WO2018052166A1

WO2018052166A1 - Device and method for verifying application

Info

Publication number: WO2018052166A1
Application number: PCT/KR2016/013760
Authority: WO
Inventors: 김동욱; 김지훈; 안창섭
Original assignee: 삼성전자 주식회사
Priority date: 2016-09-13
Filing date: 2016-11-28
Publication date: 2018-03-22
Also published as: US20210216635A1; KR20180029737A; US11281778B2; KR102538096B1

Abstract

The method for verifying an application according to one embodiment comprises the steps of: storing an application code; loading a portion of the application code in a memory; and verifying the application using the code loaded in the memory.

Description

Devices and Methods for Validating Applications

An apparatus and method for verifying an application are described.

The user can install the application on the device and execute the application. An application is created by a service provider that produces and provides content. An application executed by the user may be hacked. Therefore, it is necessary to verify that the application has been hacked.

The device may directly verify whether the application has been hacked or may verify whether the application has been hacked through the security server.

An apparatus and method for verifying an application are provided.

The present invention also provides a computer-readable recording medium having recorded thereon a program for executing the method on a computer.

According to an embodiment, a method of verifying an application may include: storing an application code; Loading some of the application code into a memory; And verifying the application by using the code loaded in the memory.

1 is a diagram illustrating a system for providing content according to an exemplary embodiment.

2 is a diagram illustrating a system for providing content according to an exemplary embodiment.

3 is a diagram illustrating a system for providing content according to an exemplary embodiment.

4 is a diagram for describing a form in which application code is used.

5 is a diagram for describing a method of verifying an application by using a code loaded in a physical memory, according to an exemplary embodiment.

6 is a diagram for describing a method of generating an entire hash, according to an exemplary embodiment.

7 is a diagram for describing a method of generating an entire hash, according to an exemplary embodiment.

8 is a diagram for describing a method of generating an entire hash, according to an exemplary embodiment.

9 is a diagram for describing a method of generating an entire hash, according to an exemplary embodiment.

10 is a block diagram illustrating a device according to an exemplary embodiment.

11 is a flowchart illustrating a method of verifying an application according to an embodiment.

According to an embodiment, a device may include a disk storing an application code; Memory; And a processor, wherein the processor loads a part of the application code into the memory and verifies the application using the code loaded in the memory.

Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present disclosure. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. In addition, in order to clearly describe the present disclosure in the drawings, irrelevant parts are omitted, and like reference numerals designate like parts throughout the specification.

The terms used in the present disclosure are described as general terms currently used in consideration of the functions mentioned in the present disclosure, but they may mean various other terms according to the intention or precedent of a person skilled in the art, the emergence of new technologies, and the like. Can be. Therefore, the terms used in the present disclosure should not be interpreted only by the names of the terms, but should be interpreted based on the meanings of the terms and the contents throughout the present disclosure.

Also, terms such as first and second may be used to describe various components, but the components should not be limited by these terms. These terms are used to distinguish one component from another.

Also, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present disclosure. Expression in the singular includes the plural unless the context clearly indicates the singular. In addition, throughout the specification, when a part is "connected" to another part, it is not only "directly connected", but also "electrically connected" between other elements in between. Include. In addition, when a part is said to "include" a certain component, this means that it may further include other components, without excluding other components unless otherwise stated.

As used in this specification (in particular, in the claims), “the” and the like may be used to indicate both the singular and the plural. In addition, if there is no description explicitly specifying the order of steps describing the method according to the present disclosure, the described steps may be performed in a suitable order. The present disclosure is not limited to the order of description of the described steps.

The phrases “in some embodiments” or “in one embodiment” appearing in various places in the specification are not necessarily all referring to the same embodiment.

Some embodiments of the present disclosure may be represented by functional block configurations and various processing steps. Some or all of these functional blocks may be implemented in various numbers of hardware and / or software configurations that perform particular functions. For example, the functional blocks of the present disclosure may be implemented by one or more microprocessors or by circuit configurations for a given function. In addition, for example, the functional blocks of the present disclosure may be implemented in various programming or scripting languages. The functional blocks may be implemented in algorithms running on one or more processors. In addition, the present disclosure may employ the prior art for electronic configuration, signal processing, and / or data processing. Terms such as "mechanism", "element", "means" and "configuration" may be used widely and are not limited to mechanical and physical configurations.

In addition, the connecting lines or connecting members between the components shown in the drawings are merely illustrative of functional connections and / or physical or circuit connections. In an actual device, the connections between components may be represented by various functional connections, physical connections, or circuit connections that are replaceable or added.

Hereinafter, the present disclosure will be described in detail with reference to the accompanying drawings.

1 is a diagram illustrating a system for providing content according to an exemplary embodiment. 1, the device 10 verifies an application, and the content providing server 30 receives a verification result from the security server 20. The content providing server 30 may provide the content to the device 10 according to the verification result. Verifying an application refers to determining whether the application has been forged or tampered with. In other words, verifying the application indicates whether the application produced by the content providing server 30 and the application executed in the device 10 are the same.

The device 10 executes an application. The user may select content using an application. The device 10 requests the content providing server 30 for the content selected by the user. The content providing server 30 does not provide the content until the verification result of the application is received. Alternatively, the content providing server 30 may provide only a part of the content until the verification result of the application is received.

The device 10 verifies the application. The device 10 may verify the application by using the application code loaded in the memory. When the application code is stored in the disk (or storage), the application code is not forged or modulated, the application code loaded in the memory may be forged or modulated. Accordingly, the device 10 may verify whether the application is forged or modulated by comparing the application code loaded in the memory with the original code. The original code can be stored on disk or in a safe area. How the device 10 verifies an application is described in detail below.

The device 10 transmits the result of verifying the application to the security server 20. When the device 10 transmits the verification result to the security server 20, the device 10 may transmit a sign. The sign is information shared only by the device 10 and the security server 20. The sign may be a secret key shared only by the device 10 and the security server 20. The security server 20 may verify the signature and trust the verification result received from the device 10. In other words, if the signature is forged or tampered, the security server 20 does not trust the verification result of the application received from the device 10.

The device 10 is an electronic device capable of installing and executing an application such as a TV, a mobile device (mobile phone, tablet, etc.), a wearable device (smart watch, etc.) and a PC. The application may be a program designed to perform a specific function. For example, the application may be a program for receiving content from the content providing server 30 and playing the content.

The security server 20 transmits an authentication result to the content providing server 30. The authentication result includes the verification result of the application and the verification result of the signature. If both the verification result of the application and the verification result of the sign are normal, the security server 20 authenticates the integrity of the application. If any of the verification result of the application and the verification result of the signature are not normal, the security server 20 determines that the application is forged or forged.

The content providing server 30 provides the content to the device 10 according to the authentication result received from the security server 20. The content providing server 30 provides the content to the device 10 only when the application is not forged or tampered with.

2 is a diagram illustrating a system for providing content according to an exemplary embodiment. 2, the security server 20 verifies an application, and the content providing server 30 may provide content to the device 10 according to the verification result.

The device 10 executes an application. The user may select content using an application. The device 10 requests the content providing server 30 for the content selected by the user.

The device 10 generates verification data. Verification data is generated using application code loaded into memory. For example, the verification data can be application code loaded into memory. In addition, the device 10 may generate a hash using application code loaded in the memory, and the generated hash may be used as verification data. In addition, the device 10 may generate a hash using some of the application code loaded in the memory. In addition, the device 10 may generate a hash by using the application code loaded in the memory and the application code stored in the disk.

The device 10 transmits the verification data to the security server 20. For example, the device 10 generates a hash and transmits the generated hash to the security server 20 as verification data. In addition, the device 10 may transmit the application code loaded in the memory to the security server 20 as verification data. In addition, the device 10 may combine the application code loaded in the memory and the code stored in the disk to transmit the hash of the entire code to the security server 20 as verification data.

The security server 20 verifies the application using the verification data. The security server 20 stores the code of the application or the code when the application is loaded into the memory. The code stored by the security server 20 is a code that has not been forged or tampered with. The security server 20 may determine whether the verification data is forged or tampered with the stored code. For example, the security server 20 may generate a hash of the code stored in the security server 20, and compare the hash generated by the security server 20 with the hash received from the device 10.

The security server 20 verifies the signature. The security server 20 verifies the signature received from the device 10 to verify the authenticity of the verification data received from the device 10.

The security server 20 transmits the authentication result to the content providing server 30. The security server 20 transmits the authentication result to the content providing server 30 according to the verification result of the application and the verification result of the sign.

3 is a diagram illustrating a system for providing content according to an exemplary embodiment. 3, the content providing server 30 may verify an application, and the content providing server 30 may provide content to the device 10 according to the verification result.

The device 10 generates verification data using the application code loaded in the memory. The device 10 transmits the verification data to the security server 20. The device 10 sends the signature to the security server 20 together with the verification data.

The security server 20 verifies the signature. The security server 20 does not verify the verification data, but verifies only the signature.

The security server 20 transmits the verification result of the sign and the verification data to the content providing server 30.

The content providing server 30 verifies the application executed in the device 10 using the verification data. The content providing server 30 may verify the application only when the verification result of the sign is normal. If the verification result of the signature is not normal, the content providing server 30 does not trust the integrity of the verification data, and the content providing server 30 does not provide the content to the device 10. The content providing server 30 compares the verification data with the application code stored in the content providing server 30 to verify the application executed in the device 10.

4 is a diagram for describing a form in which application code is used.

The device 10 may download the application code, and the downloaded application code is stored in the disk 100.

The application code may be loaded into the virtual memory 200. The virtual memory 200 is allocated to a processor executing an application.

Some of the application code is loaded into the physical memory 300. Since the space of the physical memory 300 is limited, the entire application code is not loaded into the physical memory 300, and only the application code being used is loaded into the physical memory 300.

The application code may be forged or modulated when stored in the disk 100, and the code loaded in the physical memory 300 may be forged or modulated. The device 10 may verify the code stored in the disk 100 and the code loaded in the physical memory 300.

For example, the application code may include first to fifth codes. The first through fifth codes each represent a part of the application code.

The first code, the third code, and the fifth code may be loaded into the physical memory 300. The location of the physical memory 300 loaded with each code may be tracked using a Loadable Kernel Module (LKM).

The first code, the third code, and the fifth code may be forged or modulated when loaded into the physical memory 300. For example, the first code loaded in the physical memory 300 may be a modulated code.

The device 10 may verify the application using the first code, the third code, and the fifth code. For example, the device 10 verifies whether the first code is forged or modulated. In addition, the device 10 may verify whether the first code, the third code, and the fifth code are forged or modulated. The first code, the third code and the fifth code may be used as verification data and may be transmitted to the security server 20.

6 is a diagram for describing a method of generating an entire hash, according to an exemplary embodiment. Referring to FIG. 6, the device 10 may generate the entire hash 610 using a hash of code stored in the disk 100 and a hash of code loaded in the physical memory 300.

For example, the entire application code includes the first to fifth codes. The first code, the third code, and the fifth code are loaded in the physical memory 300, and the entire application code is stored in the disk 100.

The device 10 generates a first hash for the first code from the physical memory 300, generates a third hash for the third code, and generates a fifth hash for the fifth code. The device 10 reads the second code from the disk 100 to generate a second hash for the second code. The device 10 reads the fourth code from the disk 100 to generate a fourth hash for the fourth code. The device 10 combines (or connects) the first through fifth hashes in order to generate the entire hash 610.

The entire hash 610 may be used as verification data. The entire hash 610 may be verified by the device 10 or transmitted to the security server 20. The device 10 may verify the original hash 610 by generating the original hash from the application code stored in the safe area and comparing the original hash with the entire hash 610. The original hash may be generated in the same way as the full hash 610.

7 is a diagram for describing a method of generating an entire hash, according to an exemplary embodiment. Referring to FIG. 7, the device 10 may generate the entire hash 720 by using the code stored in the disk 100 and the code loaded in the physical memory 300.

The device 10 reads the first code, the third code, and the fifth code from the physical memory 300, and reads the second code and the fourth code from the disk 100. The device combines the read first through fifth codes to generate a full code 710 and generates a full hash 720 for the full code 710.

The entire hash 720 may be verified by the device 10 or transmitted to the security server 20. The device 10 may verify the original hash 720 by generating the original hash from the application code stored in the safe area, comparing the original hash with the entire hash 720. The original hash may be generated in the same way as the full hash 720.

8 is a diagram for describing a method of generating an entire hash, according to an exemplary embodiment. Referring to FIG. 8, the device 10 may generate the entire hash 810 using only the code loaded in the physical memory 300.

When the first code, the third code, and the fifth code are loaded in the physical memory 300, the device 10 may store the first hash for the first code, the third hash for the third code, and the fifth code. Generate a fifth hash for.

The device 10 combines the first hash, the third hash, and the fifth hash to generate an overall hash 810. The entire hash 810 may be used as verification data.

9 is a diagram for describing a method of generating an entire hash, according to an exemplary embodiment. Referring to FIG. 9, the device 10 may generate the entire hash 910 using only the code loaded in the physical memory 300.

When the first code, the third code, and the fifth code are loaded in the physical memory 300, the device 10 generates a code combining the first code, the third code, and the fifth code, and generates the code. Generate a full hash 910 for the. In FIG. 8, the hashes generated after generating the hash for each code are combined. In FIG. 9, the entire hash 910 for the code combining the respective codes (the entire code combining the first code, the third code, and the fifth code) is shown. )

10 is a block diagram illustrating a device according to an exemplary embodiment. Referring to FIG. 10, the device 1000 includes a processor 1010, a disk 1020, and a memory 1030.

The processor 1010 controls the disk 1020 and the memory 1030. The processor 1010 may store or read data on the disk 1020. The processor 1010 may load data stored in the disk 1020 into the memory 1030. For example, the data may be a program, application code, or the like.

The processor 1010 loads the data into the memory 1030 to use the data stored in the disk 1020. The processor 1010 may load only necessary data from the data stored in the disk 1020 into the memory 1030.

The processor 1010 may verify data stored in the disk 1020. The processor 1010 may compare the data stored in the safe area with the data stored in the disk 1020. The device 1000 may use a partial area or a separate space of the disk 1020 as a safe area.

The processor 1010 may verify data loaded in the memory 1030. The processor 1010 may verify only data loaded in the memory 1030 or only a part of data loaded in the memory 1030. The processor 1010 may verify the combined data by combining the data loaded in the memory 1030 and the data stored in the disk 1020. The processor 1010 may generate a hash of the data and verify the data using the hash.

The processor 1010 may compare the data loaded in the memory 1030 with the data stored in the safe area. Alternatively, the device 1000 may transmit data loaded in the memory 1030 to an external server. The external server may verify the received data by comparing the data received from the device 1000 with the original data.

The disk 1020 stores data. The specific area of the disk 1020 may be a safe area. The disk 1020 may be a nonvolatile memory.

The memory 1030 may store data to be executed. The processor 1010 may load data stored in the disk 1020 into the memory 1030. The memory 1030 may be a volatile memory.

In operation 1110, the processor 1010 stores the application code on the disk 1020. The processor 1010 may store the application code in the disk 1020 and the safe area. Application code may be received from an external server. The safe area may be set in a partial area of the disk 1020 or a specific area inside the device 1000.

In operation 1120, the processor 1010 loads some of the application code into the memory 1030. The processor 1010 loads only necessary codes among the application codes into the memory 1030.

In operation 1130, the processor 1010 verifies the application using the code loaded in the memory 1030. The processor 1010 may compare the code stored in the disk 1020 with the code loaded in the memory 1030.

The processor 1010 may generate various types of hashes. For example, the processor 1010 reads code not loaded into the memory 1030 from the disk 1020, and generates a hash (hash A) of the read code and the code loaded into the memory 1030. Processor 1010 generates hash B corresponding to hash A. The processor 1010 generates a hash (hash B) of the application code stored in the disk 1020. The method for generating hash A is illustrated in FIGS. 6 and 7. The entire hash 610 or the entire hash 720 may be hash A.

In addition, the processor 1010 generates a hash (hash C) using only code loaded in the memory 1030. The processor 1010 generates a hash (hash D) using only codes corresponding to codes loaded in the memory 1030 among application codes stored in the disk 1020. The method for generating the hash C is shown in FIGS. 8 and 9. The entire hash 810 or the entire hash 910 may be hash C.

In addition, the processor 1010 generates a hash (hash E) using only some codes (first codes) among codes loaded in the memory 1030. The processor 1010 generates a hash (hash F) using only the code corresponding to the first code among the application codes stored in the disk 1020.

According to an embodiment, the device may verify an application code by verifying a code loaded in a memory.

According to an embodiment, the device may transmit the code loaded in the memory to the security server, and the security server may verify the code loaded in the memory.

Meanwhile, the above-described embodiments can be written as a program that can be executed in a computer, and can be implemented in a general-purpose digital computer which operates the program using a computer-readable medium. In addition, the structure of the data used in the above-described embodiment can be recorded on the computer-readable medium through various means. In addition, the above-described embodiments may be implemented in the form of a recording medium including instructions executable by a computer, such as a program module executed by a computer. For example, methods implemented with a software module or algorithm may be stored on a computer readable recording medium as code or program instructions that the computer can read and execute.

Computer readable media can be any recording media that can be accessed by a computer, and can include volatile and nonvolatile media, removable and non-removable media. For example, computer readable media may include storage media such as magnetic storage media (eg, ROM, floppy disk, hard disk, etc.) and optical reading media (eg, CD-ROM, DVD, etc.) This is not restrictive. In addition, the computer readable medium may include computer storage media and communication media.

In addition, a plurality of computer-readable recording media may be distributed in networked computer systems, and data (eg, program instructions and codes) stored in the distributed recording media may be executed by at least one computer. have.

The terms "... unit", "module", and the like described herein refer to a unit for processing at least one function or operation, which may be implemented in hardware or software, or a combination of hardware and software.

The "unit" and "module" may be implemented by a program stored in a storage medium that can be addressed and executed by a processor.

For example, "part", "module" means components such as software components, object-oriented software components, class components, and task components, and processes, functions, properties, and pro- grams. It can be implemented by procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays and variables.

Claims

In the method of verifying the application,

Storing the application code;

Loading some of the application code into a memory; And

Verifying the application using the code loaded in the memory.
The method of claim 1, wherein the verifying step comprises:

Reading code not loaded in the memory among the application code;

Generating a hash A of the code loaded into the memory and the read code;

Generating a hash B of the application code; And

Comparing the hash B with the hash A to verify the application.
The method of claim 1, wherein the verifying step comprises:

Generating a hash C of code loaded into the memory;

Generating a hash D of code corresponding to code loaded in the memory among the application codes; And

Comparing the hash C with the hash D to verify the application.
The method of claim 1, wherein the verifying step comprises:

Generating a hash E of a first code among the codes loaded into the memory;

Generating a hash F of a code corresponding to the first code among the application codes; And

And comparing the hash E and the hash F to verify the application.
The method of claim 1, wherein the verifying step comprises:

And comparing the code loaded in the memory with a code corresponding to the code loaded in the memory among the application codes to verify the application.
The method of claim 1,

Generating a hash C of code loaded into the memory; And

And transmitting the hash C to a security server.
The method of claim 6, wherein transmitting the hash C to a security server comprises:

Send a sign with the hash C to the secure server,

The signature is an application verification method, characterized in that the device containing the memory and the secret key used by the security server.
In the device for verifying the application,

A disk for storing application code;

Memory; And

Includes a processor,

The processor loads some of the application code into the memory,

Verifying the application using code loaded into the memory.
The method of claim 8, wherein the processor,

Read code not loaded in the memory among the application codes;

Generate a hash A of the code loaded into the memory and the read code,

Generate a hash B of the application code,

And compare the hash B with the hash A to verify the application.
The method of claim 8, wherein the processor,

Generate a hash C of the code loaded into the memory,

Generate a hash D of the code corresponding to the code loaded in the memory of the application code,

And comparing the hash C with the hash D to verify the application.
The method of claim 8, wherein the processor,

Generate a hash E of the first code among the codes loaded into the memory,

Generating a hash F of a code corresponding to the first code among the application codes,

And compare the hash E and the hash F to verify the application.
The method of claim 8, wherein the processor,

And comparing the code corresponding to the code loaded in the memory with the code loaded in the memory and the application code to verify the application.
The method of claim 8, wherein the processor,

Generate a hash C of the code loaded into the memory,

And send the hash C to a secure server.
The processor of claim 13, wherein the processor comprises:

Send a sign with the hash C to the secure server,

And the sign is a device containing the memory and a secret key used by the security server.
A computer readable non-transitory recording medium having recorded thereon a program for executing the method of claim 1 on a computer.