KR20160134055A

KR20160134055A - Method for Verifying a Integrity of Application

Info

Publication number: KR20160134055A
Application number: KR1020150067455A
Authority: KR
Inventors: 문화신
Original assignee: 한국전자통신연구원
Priority date: 2015-05-14
Filing date: 2015-05-14
Publication date: 2016-11-23

Abstract

The present invention relates to a method for verifying an integrity of an application, the method comprising: receiving a security certificate of an application from a certification authority to protect the integrity of the application; Adding the verification information to an application as a resource and distributing the verification information through an existing application store; Checking whether the verification information exists in the application in response to a verification request of an application installed in the terminal; Verifying the certification authority that issued the verification information if the verification information exists; Determining whether the developer information included in the verification information and the developer information used in the application signature are identical if the certification authority is verified; And checking if the information generated by the operating system in the user terminal matches the information included in the verification information if the determination result is the same.

Description

[0001] The present invention relates to a method for verifying an integrity of an application,

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method for verifying an integrity of an application, and a method for verifying whether a user forgives or falsifies an application at a user terminal.

Much of the mobile malware is being made and distributed through forged methods. Forgery is a method of distributing malicious code similar to existing applications or malicious code embedded in existing applications, pretending to be an existing application. This forgery-and-fake method is widely used because fundamentally the user terminal operating system (eg, Android) system does not guarantee the relationship between the application and the application developer.

On the basis of this fact, conventionally, methods for verifying and ensuring the integrity of the application have been suggested by assuring the developer identity for the application. In one of these ways, KFTC opened a financial app store site that provides only proven financial applications provided by real banks. However, these sites ensure integrity for registered applications, but do not include assurance information in the application itself.

Thus, such a site still has room to be exploited by a malicious user, such as a phishing site for a financial app store.

In addition, methods for validating and ensuring developer identity through the App Store are also presented. As an example of such a method, Korean Patent Registration No. 10-2012-0134418 (Mobile App Integrity Guarantee Device and Method) verifies an app in an App Store, and then transmits an App Store signature value And distribute it in the app. These app store signatures may be distributed by including only one value signed by the app store certificate in the app after removing the developer signature from the existing app. In addition to the signature of the developer as well as the Korean patent registration No. 10-2012-0134418, The store signatures are also included in the app together with multiple signatures. However, such an application-based signature-based method has a problem of limiting the management and operation of the app on the Android system. This is because the Android system not only performs the management of apps such as updates with the signing certificate included in the app, but also supports the interaction between apps developed by the same developer.

Accordingly, embodiments of the present invention aim to provide a means by which a user can verify whether a mobile application has been tampered with on a smart phone. In particular, it is an object of the present invention to provide a method for verifying whether application forgery or falsification has compatibility with existing application and user terminal operating system systems for application of the above technology.

To this end, an application integrity verification method according to an aspect of the present invention includes: a step in which a developer who wants to protect the integrity of an application receives a security certificate of the application from an authentication authority; Adding the verification information to an application as a resource and distributing the verification information through an existing application store; Checking whether the verification information exists in the application in response to a verification request of an application installed in the terminal; Verifying the certification authority that issued the verification information if the verification information exists; Determining whether the developer information included in the verification information and the developer information used in the application signature are identical if the certification authority is verified; And checking if the information generated by the operating system in the user terminal matches the information included in the verification information if the determination result is the same.

The present invention proposes a method for ensuring and verifying the integrity of an application without modifying the existing operating system system for managing the application with the developer signature. Therefore, compatibility with existing user terminal operating system can be maintained and it can be easily applied to existing system.

In addition, the present invention can be utilized as an access control means for the corresponding security modules for enhancing security when providing a user safe execution environment through a security module such as MTM.

1 is a view for explaining a process of generating and distributing verification information according to an embodiment of the present invention.
2 is a view for explaining a process of issuing verification information by an authentication authority according to an embodiment of the present invention.
3 is a diagram illustrating an example of verification information according to an embodiment of the present invention.
4 is a diagram illustrating a method for verifying application integrity in a terminal according to an embodiment of the present invention.

While the present invention has been described in connection with certain exemplary embodiments, 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 similarities. It is to be understood, however, that the invention is not to be limited to the specific embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In the following description of the present invention, detailed description of known related arts will be omitted when it is determined that the gist of the present invention may be unnecessarily obscured.

Furthermore, the singular terms used in this specification and the claims should generally be construed to mean one or more unless otherwise stated.

The present invention provides a means for providing verification information for confirming whether or not an application is integrity to a user terminal, and for verifying integrity of an application in a user terminal based on verification information. At this time, the previously deployed applications can be installed / operated by the proposed method, and the applications generated by applying the proposed method can be installed and operated in the user terminal to which the proposed method is not applied.

In order to satisfy the above-described characteristics, in the present invention, the verification information (hereinafter referred to as the security certificate means verification information) for confirming the integrity of the application is generated and stored as a resource in the application of the user terminal And the like. The Trusted APP shown in the following description refers to an application created by the present invention, i.e., an application having verification information, and an application and an app are used in the same sense.

In addition, the present invention is basically applied to a secure execution environment provided by utilizing a H / W security module such as MTM or a S / W-based security module, so that only the applications verified through the invention can access the security environment Thereby further enhancing the stability of the security environment.

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

1 is a view for explaining a process of generating and distributing verification information according to an embodiment of the present invention.

Referring to FIG. 1, the generation of the verification information starts when a developer who desires to generate a trusted APP signs his application with his own certificate.

In step S100, the developer requests the trust agency to generate the verification information for the created application. These certification bodies can use existing institutions such as financial app stores, national standardized certification information centers, and so on.

As in step S110, the certification authority performs verification of the application and the application developer with respect to the requested application. The manner in which the certification body performs the verification will be described later in detail in FIG.

If the verification of the application and the application developer performed in step S110 passes, then in step S120, the certification authority issues the verification information to the verified application and delivers it to the developer.

In step S130, the developer places the verification information issued by the certification authority in the asset folder of the created application, and then generates the trusted APP by signing the application including the verification information with its own certificate. For compatibility with the operating system of the existing user terminal, the verification information is not located in the existing META_INF folder but located in the asset folder. However, the location of the verification information does not have to be limited to the asset folder, and the operating system of the user terminal, such as the res folder, can recognize the resource as a resource and be designated as a location other than META_INF.

The Trusted APP generated as in step S140 can be distributed to users through various means such as an existing android market such as a Play Store, a third party market, an e-mail or an SNS.

In step S150, the user can also receive the application through various paths. When the received application is installed in the user terminal, the integrity verification of the application is performed based on the verification information included in the application. Hereinafter, an application integrity verification method will be described in detail with reference to FIG.

2 is a view for explaining a process of issuing verification information by an authentication authority according to an embodiment of the present invention.

Referring to FIG. 2, the certification authority receives a request for issuing verification information for an application as in step S200.

In step S201, the certification authority performs a task of verifying whether the developer who signed the application and the developer who requested the issuance of the verification information are the same person. At this time, verification can be performed based on the reliability of the developer based on the existing verification result. If developer verification fails, step S206 is performed.

If the verification is successful, it is checked in step S202 whether the requested developer has already been verified with the same application. At this time, it can be determined whether past verification information exists whether or not the same application has been verified. If past verification information does not exist, step S208 is performed.

If past verification information exists, the application is analyzed for harmfulness in step S203. To analyze these harmful effects, you can use existing malicious code analysis tools. Also, the hazard analysis step is not a part that must be performed for integrity verification, and it can be selectively performed according to the characteristics of the certification body. If it is determined that the application is harmful, step S206 is performed.

If it is determined in step S204 that the application is not harmful, the result is updated in the developer DB, and then the verification information for the application is issued in step S205.

If the developer verification fails in step S206, the developer verification failure information is updated to the developer DB for later verification. Further, even when it is determined that the application is harmful, the developer reflects in the developer DB information that the harmful application has been created.

In step S207, it is refused to issue the verification information for the application that has failed the developer verification or is determined to be a harmful application.

In step S208, the application that has requested the issuance of the verification information is checked with a line job for verifying whether the requested application is a forged application, and whether there is a similar application on the source code and the image. In particular, at this stage, it is possible to investigate the similarity between popular applications that are frequently used for forgery and falsification and applications with reliability. If a similar application is not detected, step S203 is performed.

If similarity to another application is found, it is determined in step S209 whether or not the other application in which the similarity is found is identical to the developer. If the similarity is found between the other application and the developer, the step S203 may be performed.

If the developers are not the same, in step S210, whether or not the similar application is developed by the developer is reflected in the developer DB for later verification.

In step S211, the issuance of the verification information for the request is rejected.

3 is a diagram illustrating an example of verification information according to an embodiment of the present invention.

Referring to FIG. 3, the certification authority includes certification authority information 300 that has issued verification information to verification information to be used for application integrity verification, developer information 310 that has been verified by the certification authority, and application integrity information 320 . At this time, the developer information 310 and the application integrity information 320 may be encrypted using various algorithms to ensure confidentiality. As an example of such encryption, a private key of the certification authority can be used.

The application integrity information 320 may include a hash value for each component of an application used in verification.

In consideration of the verification speed of the application, the application integrity information 320 may include a developer signature result and a generated file such as MANIFEST.SF or CERT.SF and a hash value for specific files including the file.

4 is a diagram illustrating a method for verifying application integrity in a terminal according to an embodiment of the present invention.

Referring to FIG. 4, an installation of an application is requested to the user terminal as in step S400.

When it is desired to perform the integrity verification function for the application installed in step S410, the operating system of the user terminal for the requested application checks whether the corresponding application has the trusted APP, that is, the verification information. This can be done by checking the folder where the validation information is located in the application (for example, the asset folder) when installing the Trusted APP. If the verification information does not exist, step S480 is performed.

If the verification information exists, the operating system of the user terminal verifies the reliability of the certification authority that issued the verification information in step S420. As an example of a method of verifying reliability, it is possible to previously manage information of a reliable certification authority with a DB, and to confirm whether the verification information is issued by one of the managed certification authorities. If the certification authority verification fails, step S480 is performed.

If verification information issued by a trusted certification authority exists, the verification information content is decrypted in step S430 to check the contents of the verification information. The decryption method uses a public key cryptosystem of the certification authority. Public key cryptography is a type of cryptosystem that allows users who do not share a private key in advance to communicate securely.

It is confirmed in step S440 whether the developer information included in the verification information is identical to the developer information used in the application signature. If the two pieces of information are not the same, step S480 is performed.

If the two pieces of information on the developer are identical in step S450, the operating system of the user terminal generates integrity information for the corresponding application. At this time, the operating system generates integrity information according to the protocol of the certification authority confirmed in step S420. That is, a hash value for each component of the application, which is created by the certification authority and included in the verification information, can be generated. Alternatively, you can generate hash values for specific files, including files such as MANIFEST.SF and CERT.SF.

In step S460, it is determined whether the information generated by the operating system of the user terminal matches information included in the verification information. If the two pieces of information do not match, step S480 is performed.

If the two pieces of information coincide with each other, a step S470 is performed to notify the user that the application is defective.

In step S480, the integrity verification is terminated, and the user is informed of the verification failure information, thereby allowing the user to decide whether to continue installing the application. At this time, together with the integrity error information, the risk of application installation can be notified.

When the Trusted APP is installed in an operating system system of an existing user terminal to which the present invention is not applied, the enclosed verification information is treated as an internal resource and is ignored and the app can be installed / operated according to the installation method of the existing application .

Also, when a general application is installed in the user terminal operating system system proposed in the present invention, the integrity verification is terminated as verification information does not exist, the fact is notified to the user, and installation and operation can be performed according to the user's will.

Since the signature information managed by the operating system of the user terminal includes only the signature information of the developer in the case of the trusted APP, there is no restriction on the application change such as application update and mutual interoperation between applications created by the same developer .

The embodiments of the present invention have been described above. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the disclosed embodiments should be considered in an illustrative rather than a restrictive sense. The scope of the present invention is defined by the appended claims rather than by the foregoing description, and all differences within the scope of equivalents thereof should be construed as being included in the present invention.

Claims

A step of the developer who wants to protect the integrity of the application receives the security certificate of the application from the certification authority;
Adding the verification information to an application as a resource and distributing the verification information through an existing application store;
Checking whether the verification information exists in the application in response to a verification request of an application installed in the terminal;
Verifying the certification authority that issued the verification information if the verification information exists;
Determining whether the developer information included in the verification information and the developer information used in the application signature are identical if the certification authority is verified; And
Determining whether the information generated by the operating system in the user terminal matches the information included in the verification information if the determination result is identical;
The application integrity verification method comprising: