WO2013137616A1

WO2013137616A1 - Method and apparatus for evaluating required permissions for application

Info

Publication number: WO2013137616A1
Application number: PCT/KR2013/001969
Authority: WO
Inventors: Ji-Soon Park; Jin-Yung Kim; Yong-ho YOON; Jun-Bum Shin; Kwang-keun YI
Original assignee: Samsung Electronics Co., Ltd.; Seoul National University R&Db Foundation
Priority date: 2012-03-12
Filing date: 2013-03-12
Publication date: 2013-09-19
Also published as: KR101900047B1; KR20130116409A

Abstract

A method and apparatus for evaluating required permissions for an application of a smart device. There are disclosed a method, an apparatus, and a computer-readable recording medium for acquiring a source code from the application, generating a function list including at least one function included in the source code, and determining permissions required for the function list when the application is executed in the smart device.

Description

METHOD AND APPARATUS FOR EVALUATING REQUIRED PERMISSIONS FOR APPLICATION

The present invention relates to a method and apparatus for evaluating required permissions for an application of a smart device, and more particularly, to a method of evaluating required permissions for an application to be executed in a smart phone, through a static analysis without directly executing the application.

The use of smart devices, such as smart phones, tablet Personal Computers (PCs), smart TVs, and electronic readers (e.g., a kindle fire), has become popular. Accordingly, the kinds and number of applications used in smart devices is rapidly increasing. These applications use resources, such as location information of a user (or device), to provide a more convenient and useful service than a usual one.

For an application to access device resources, such as location information, the application needs access permission. In general, applications for smart devices may be largely classified to operate on three platforms: Android of Google, iOS of Apple, and Windows of Microsoft. Hereinafter, an application operating on an Android platform will be described as an example.

FIG. 1 is a conceptual diagram illustrating an operation of an application on an Android platform. Referring to FIG. 1, the application on the Android platform operates on a Dalvik virtual machine. In general, a single application is identified using a single user Identification (ID) and operates in a single Sandbox. That is, two or more different applications cannot be theoretically executed on a single Sandbox unless a task for sharing user IDs thereof to be the same is performed.

Basically, an application executed in a corresponding Sandbox process with no permissions cannot access a system or resources. However, when permissions are properly declared through a manifest file of the application, the application can access resources.

That is, an application identified with a user ID 12345 is executed in a first Sandbox 110, and an application identified with a user ID 54321 is executed in a second Sandbox 120. The applications can access resources of which permissions are requested by their corresponding manifest files, respectively.

FIG. 2 illustrates a structure of an application 210, and a portion of a manifest file included in the application 210. Referring to FIG. 2, the application 210 includes a source code file “resources.arcs” and additional information such as “AndroidManifest.xml”. The file “resources.arcs” includes source codes of the application 210, and the file “AndroidManifest.xml” includes additional information such as permission information and active process information. A file “classes.dex” is a file that is format-transformed to byte codes by which class files can operate on a Dalvik virtual machine. A “res” folder includes resources files that are not compiled, and a “META-INF” folder includes signature information of the application 210.

The manifest file may include various kinds of information, such as Android version information, source code start position information, and permission information. In <uses-permission> items, permissions to be used in the application 210 are requested. That is, the application 210 can use the permissions requested in the manifest file or access resources based on the permissions. The application 210 in FIG. 2 requests for (declares) an Internet access permission and an external storage write permission in the manifest file, so the application 210 can access the Internet and write data in an external storage device.

FIG. 3 illustrates an operation of installing and executing an application 310 in a smart device 320. Referring to FIG. 3, the application 310 (e.g., Android application) consists of a source code and additional information including a manifest file, and when the application 310 is installed, the smart device 320 displays permissions requested by the application 310 by referring to the additional information and allows a user to confirm the permissions. After installation, the application 310 requests the smart device 320 for resources required for execution of the application 310 in operation 332, and the smart device 320 determines in operation 334 whether an access permission to the resources is requested (declared) through the manifest file. If the access permission is requested (declared), the application 310 is allowed to access the resources, and if the access permission is not requested (declared), the application 310 is not allowed to access the resources in operation 336.

A developer must explicitly request for required permissions for an application one-by-one for the application to operate according to intent. If the application tries to perform a task without a corresponding permission, the task is rejected by a system, so the application may perform an operation that is not intended by the developer, cause an error, be terminated, or cause the system to go down. Thus, the developer must request for all required permissions for the application without omission.

However, it is not easy for the developer to perceive all required permissions for an application when the developer develops the application. In many cases, for convenience of development, the developer may excessively request for even permissions that are not required to execute an application, or may develop an application where all required permissions are requested and delete permissions determined as not required thereafter. Furthermore, even though the developer correctly perceives required permissions for an application, it is troublesome to declare the required permissions in a manifest file one-by-one.

In addition, on an Android platform, required permissions for an application are displayed on a screen of a device at an installation stage of the application, and a user checks the displayed required permissions. However, an increase in applications requesting for excessive permissions frequently causes users to habitually accept or confirm requested permissions without carefully checking a permission list displayed on a screen. In addition, since there are many cases where a permission list displayed on a screen does not match with permissions for an application to actually access, it is difficult for a user to correctly perceive what permissions the application actually uses. These problems may cause a malfunction of a smart device due to a malignant application or an outflow of sensitive information by an application.

In addition, to correctly perceive permissions used by an application, an application must be tested at the development stage while repeating compiling or execution (runtime) of the application.

It is not easy for the developer to perceive all required permissions for an application when the developer develops the application.

The present invention provides a method and apparatus for automatically evaluating and informing of required permissions for an application through a static analysis of the application.

The above and other features and advantages of the present invention will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings in which:

FIG. 1 is a conceptual diagram illustrating an operation of an application on an Android platform;

FIG. 2A illustrates a structure of an application, and FIG. 2B illustrates a portion of a manifest file;

FIG. 3 illustrates an operation of installing and executing an application in a smart device;

FIG. 4 is a block diagram of an apparatus for evaluating required permissions for an application, according to an embodiment of the present invention;

FIG. 5 is a conceptual diagram illustrating a process of a permission evaluating unit according to an embodiment of the present invention;

FIG. 6 is a conceptual diagram illustrating an inclusion relationship among permissions according to an embodiment of the present invention;

FIG. 7 is a flowchart illustrating a method of evaluating required permissions for an application, according to an embodiment of the present invention;

FIG. 8 is a block diagram of a server for statically evaluating required permissions for an application, according to an embodiment of the present invention;

FIG. 9 is a flowchart illustrating a method of statically evaluating required permissions for an application in a server, according to another embodiment of the present invention;

FIG. 10 is a block diagram of a smart device according to an embodiment of the present invention;

FIG. 11 is an example of evaluating permissions actually used by an application installed in a smart device, according to another embodiment of the present invention; and

FIG. 12 is a flowchart illustrating a method of evaluating permissions for an application installed in a smart device, according to another embodiment of the present invention.

According to an aspect of the present invention, there is provided a method of evaluating required permissions for an application executed in a device, the method including: acquiring a source code from the application; generating a function list including at least one function included in the source code; and determining permissions required for the function list when the application is executed in the device.

The method may further include: further acquiring additional information including previously requested permission information; and comparing the previously requested permission information with the determined permissions and outputting the comparison result.

The additional information may further include start location information of the source code, and the function list may include functions determined to be executable based on a control flow of the source code from the start location.

The function list may be a function list obtained by filtering functions determined not to be called when the application is executed by determining a condition included in each of the functions or a function list obtained by filtering functions determined not to be called by a virtual call when the application is executed by determining a type of each of the functions, from among the functions determined to be executable.

The previously requested permission information may be included in a manifest file, and if the previously requested permission information does not match with the determined permissions, the method may further include generating an updated manifest file based on the determined permissions.

According to another aspect of the present invention, there is provided an apparatus for evaluating required permissions for an application executed in a device, the apparatus including: an application acquisition unit for acquiring a source code from the application; a control flow analysis unit for generating a function list including at least one function included in the source code; and a permission evaluating unit for determining permissions required for the function list when the application is executed in the device.

According to another aspect of the present invention, there is provided a method of evaluating required permissions for an application in a server, the method including: receiving the application from a developer device; acquiring a source code of the application and additional information including previously requested permission information from the application; generating a function list including at least one function included in the source code; determining permissions required for the function list when the application is executed; and comparing the previously requested permission information with the determined permissions, registering the application in the server if the previously requested permission information matches with the determined permissions, and transmitting the comparison result to the developer device if the previously requested permission information does not match with the determined permissions.

The method may further include updating the additional information based on the determined permissions if the previously requested permission information does not match with the determined permissions.

According to another aspect of the present invention, there is provided a server for evaluating required permissions for an application, the server including: an application receiver for receiving the application from a developer device; an application acquisition unit for acquiring a source code of the application and additional information including previously requested permission information from the application; a control flow analysis unit for generating a function list including at least one function included in the source code; a permission evaluating unit for determining permissions required for the function list when the application is executed; and an application registering unit for registering the application in the server, wherein the permission evaluating unit transmits a comparison result to the developer device if the previously requested permission information does not match with the determined permissions, and the application registering unit registers the application in the server if the previously requested permission information matches with the determined permissions.

According to another aspect of the present invention, there is provided a method of evaluating required permissions for an application in a smart device, the method including: calling at least one application installed in the smart device; allowing a user to select at least one application from among the called at least one application; acquiring a source code of each application and additional information including previously requested permission information from the selected at least one application; generating a function list including at least one function included in the source code; determining permissions required for the function list when the application is executed; and comparing the previously requested permission information with the determined permissions and displaying the comparison result on a screen of the smart device.

The method may further include transmitting the comparison result to a developer device or an application providing server.

According to another aspect of the present invention, there is provided a smart device for evaluating required permissions for an application, the smart device including: an application calling unit for calling at least one application installed in the smart device and allowing a user to select at least one application from among the called at least one application; an application acquisition unit for acquiring a source code of each application and additional information including previously requested permission information from the selected at least one application; a control flow analysis unit for generating a function list including at least one function included in the source code; a permission evaluating unit for determining permissions required for the function list when the application is executed and comparing the previously requested permission information with the determined permissions; and a display unit for displaying the comparison result on a screen of the smart device.

The smart device may further include a transmitter for transmitting the comparison result to a developer device or an application providing server.

According to another aspect of the present invention, there is provided a computer-readable recording medium storing a computer-readable program for executing the methods.

This application claims the benefit of Korean Patent Application No. 10-2012-0025228, filed on March 12, 2012, in the Korean Intellectual Property Office, the disclosure of which is incorporated herein in its entirety by reference.

As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items. Expressions such as “at least one of,” when preceding a list of elements, modify the entire list of elements and do not modify the individual elements of the list.

The present invention will now be described more fully with reference to the accompanying drawings, in which exemplary embodiments of the invention are shown.

FIG. 4 is a block diagram of an apparatus 400 for evaluating required permissions for an application, according to an embodiment of the present invention. Referring to FIG. 4, the apparatus 400 includes an application acquisition unit 410, a control flow analysis unit 420, and a permission evaluating unit 430.

In general, an application is provided in a package form including a program source code of the application and additional information of the application, which includes signature information, authentication information, and permission information. The application acquisition unit 410 may extract a source code and additionally acquire additional information from an application. In a case of the Android platform-based application 210 shown in FIG. 2, the source code may include “resources.arsc”, and the additional information may include folders, such as “META-INF”, and the “AndroidManifest .xml” file in which components of the application 210 and an input configuration required for the application 210 are registered.

The apparatus 400 may read an application installed in a smart device (not shown) from a storage space of the smart device. In addition, the apparatus 400 may receive an application from an external server connected via a wired/wireless network. In this case, the apparatus 400 may further include an application receiver (not shown). In addition, one of ordinary skill in the art understands that the apparatus 400 can evaluate required permissions for an application for a smart device by receiving the application from a developer device even though the developer device is not a smart device.

The application acquisition unit 410 may transform a source code of an acquired application to an assembly code suitable for a platform on which the application is executed. Alternatively, the application acquisition unit 410 may extract a source code transformed to a proper assembly code from the application. In a case of an Android platform, the application acquisition unit 410 may acquire a source code of an application in a byte code form of a Dalvik virtual machine.

The control flow analysis unit 420 may analyze the source code or the assembly code of the application (hereinafter, for convenience of description, referred to as the source code). The source code includes a plurality of functions and/or instructions (hereinafter, referred to as the functions), and each of the functions may call a library function of a virtual machine or a device. Some library functions may need specific permissions.

The control flow analysis unit 420 may basically extract the functions included in the source code and generate a list of the extracted functions. In addition, the control flow analysis unit 420 may generate a function list by filtering functions not to be called or executed when the application is executed from among the functions included in the source code. The filtering operation includes control flow analysis, internal state tracking for excluding a dead code, and function type analysis for responding to a virtual call.

Through the control flow analysis, an execution order of the functions forming the source code may be perceived, and it may be perceived whether each function is actually called when the application is executed. In addition, the control flow analysis unit 420 may perceive a start point of the source code of the application by using the additional information such as a manifest file and may analyze an execution order of functions reachable from the start point and whether the functions reachable from the start point are called.

In addition, since it is difficult to correctly perceive functions called when the application is executed without executing the application, the control flow analysis unit 420 subsumes all actual execution results through a static analysis to analyze whether the functions included in the source code are actually called. In this case, to increase the accuracy and efficiency of the analysis, the control flow analysis unit 420 may perform both call path tracking and internal state tracking. That is, although the control flow analysis checks an execution order and all possible paths in executing a single program, since a program source generally includes a conditional jump or a loop syntax, such as goto, if-else, case, switch, for, or while, when a value that a variable may have is traced in a case of a conditional jump, functions that are not actually executed or called exist. These functions may be excluded from an analysis scope. For example, for a source code including functions of transmitting address book information in a case of condition 1, updating the address book information in a case of condition 2, and initializing the address book information in a case of condition 3, when a control flow of the source code is analyzed, if it is determined through internal state tracking that a part for calling the function of condition 3 cannot be actually executed although it is determined that the functions of conditions 1, 2, and 3 are executable, the control flow analysis unit 420 may ignore this dead code and analyze only codes of conditions 1 and 2 as actual call functions.

In addition, the source code may include a function to be called, which is determined when the application is executed. For example, when child classes B, C, and D, which have inherited class A having Method M, decide on Method M, which one function of B.M(), C.M(), D.M() is a function to which a Method called A.M() from among codes is transcribed is determined in the execution of the application. The control flow analysis unit 420 may also perform the function type analysis including function inheritance relationship tracking and function type transform tracking to respond to such a virtual call. In the above example, if it is assumed that the Method called A.M() is transcribed to B.M(), the control flow analysis unit 420 may perform the control flow analysis by excluding the functions of C.M() and D.M() from functions to be actually called.

The permission evaluating unit 430 may analyze library functions that are called by functions that the application actually reaches based on the analysis result of the control flow analysis unit 420. In addition, the permission evaluating unit 430 may output required permissions for libraries needing specific permissions from among the library functions. The permission evaluating unit 430 will be described in detail with reference to FIG. 5 below.

FIG. 5 is a conceptual diagram illustrating a process of the permission evaluating unit 430 according to an embodiment of the present invention. Referring to FIG. 5, the control flow analysis unit 420 analyzes actually reaching functions 520 from among all functions 510 included in an application and provide the actually reaching functions 520 to the permission evaluating unit 430. In FIG. 5, although Functions 04, 06, and 09 are included in a source code of the application, Functions 04, 06, and 09 correspond to functions that are not actually executed or called.

The permission evaluating unit 430 may evaluate library functions 530 called by the actually reaching functions 520 and corresponding permissions 540. In FIG. 5, library functions Library A to Library F corresponding to Functions 01 to 03, 05, 07, and 08 are analyzed. Then, permissions requested by the functions remaining by excluding Library D that does not request for a specific permission from Library A to Library F are evaluated. According to a permission evaluating result of the application illustrated in FIG. 5, permissions of CALL_PHONE, CAMERA, INTERNET, READ_LOGS, and SEND_SMS are used. However, although permissions of DIAGNOSTIC and REBOOT are set in the source code, the permissions of DIAGNOSTIC and REBOOT are not used in actual execution of the application.

Although it is described with reference to FIG. 5 that all the functions 510 included in the source code of the application, the actually reaching functions 520 in a control flow analysis, the library functions 530, and the permissions 540 have a one-to-one relationship, only for convenience of description, one of ordinary skill in the art understands that a many-to-one or one-to-many relationship between functions and functions or functions and permissions is possible.

FIG. 6 is a conceptual diagram illustrating an inclusion relationship among permissions according to an embodiment of the present invention. FIG. 6 shows an inclusion relationship among all permissions 610 previously requested (declared) in additional information, permissions 620 required for functions included in a source code of an application, and permissions 630 determined to be actually necessary in executing the application, which are derived through a control flow analysis and permission evaluation. All the permissions 610 previously requested in the additional information may be permissions requested by a manifest file on an Android platform. FIG. 6 shows that the permissions 610 requested in the additional information include the permissions 620 actually required to execute the application. However, besides a general case where a developer excessively set permissions required to execute an application, a case where a developer wrongly sets permissions required to execute an application by excluding any of them may also exist. In this case, the apparatus 400 may compare the previously requested permissions 610 with a list of the permissions 630 determined to be necessary in executing the application and inform of a comparison result, i.e., not only unnecessarily requested permissions but also permissions that are required to execute the application but excluded from the additional information.

In FIG. 6, although a developer has requested for permissions of CALL_PHONE and CALL_PRIVILEGED in the development of the application, a privileged call function is not used in actual execution of the application. In addition, although the developer has requested for permissions of READ_CALENDAR, READ_CONTACTS, READ_PHONE_STATE, READ_SYNC_STATE, and READ_LOGS, actually used permissions are limited to only the permission of READ_LOGS. In addition, although the developer has requested for permissions of REBOOT and RECEIVE_BOOT_COMPLETED, any of them is not used in actual execution of the application. The permission evaluating unit 430 may output all the evaluation results or only a necessary permission list. In addition, the permission evaluating unit 430 may output a list of permissions to be deleted from the additional information and/or a list of permissions to be added to the additional information. In addition, the permission evaluating unit 430 may update the additional information based on the evaluation results. In addition, the permission evaluating unit 430 may generate and provide a code corresponding to a permission setup part in a form suitable for a platform on which a corresponding application operates.

FIG. 7 is a flowchart illustrating a method of evaluating required permissions for an application, according to an embodiment of the present invention.

Referring to FIG. 7, in operation 710, the application acquisition unit 410 acquires a source code and/or additional information required to analyze an application from the application. In addition, the application acquisition unit 410 may transform the source code of the application to an assembly code suitable for a platform on which the application is executed. In operation 720, the control flow analysis unit 420 generates a function list including at least one function from among functions included in the source code. In addition, the control flow analysis unit 420 may perceive a start point of the application by using the additional information such as a manifest file and analyze an execution order of reachable functions in execution of the application and whether the reachable functions are called by analyzing a control flow from the start point. In addition, the control flow analysis unit 420 may filter functions not to be called through internal state tracking of the source code. In addition, the control flow analysis unit 420 may filter functions not to be transcribed by analyzing functions that are actually transcribed in a virtual call through a function type analysis. In operation 730, permissions actually required to execute the application are evaluated based on the function list generated in operation 720. In addition, the method may further include receiving an application when an application is received from an external server. In addition, to output an evaluation result to a display device, the permission evaluation result of the application may be displayed using a display unit of a device.

According to the current embodiment, required permissions for an application to be executed can be easily perceived through a static analysis of a source code of the application without actually executing the application. Thus, an application developer may prevent an outflow of sensitive information, such as personal information, by developing an application with declaring only positively necessary permissions.

FIG. 8 is a block diagram of a server 800 for statically evaluating required permissions for an application, according to an embodiment of the present invention. Referring to FIG. 8, the server 800 may be an online market place/store. The server 800 includes an application receiver 810, an application acquisition unit 820, a control flow analysis unit 830, a permission evaluating unit 840, and an application registering unit 850. The same description as described above in association with the server 800 will be omitted or roughly made.

The application receiver 810 receives an application 310 from an application developer device 870. The application acquisition unit 820 acquires a source code and additional information of the application 310 from the application 310. The additional information may include previously requested permission information, and the permission information may be included in a manifest file. The control flow analysis unit 830 analyzes functions included in the source code of the application 310 and a control flow of the source code and generates a function list including at least one function from among the functions included in the source code. The permission evaluating unit 840 determines required permissions for the function list and compares the required permissions with the previously requested permission information. As a result of the comparison, if permissions not required to execute the application 310 are included in the additional information, the permission evaluating unit 840 provides the comparison result to the application developer device 870. The application registering unit 850 registers an available application list in a consumer device 880 or registers the application 310 in the market place which is provided by the server 800 if the permissions requested in the additional information matches with a permission list required to actually execute the application 310.

In the current embodiment, if permissions not required to execute the application 310 have been requested in the additional information, the permission evaluating unit 840 may update the permission information included in the additional information of the application 310 and provide the updated application to the application registering unit 850 instead of providing an evaluation result to the application developer device 870.

In addition, one of ordinary skill in the art understands that, when there are permissions that are required to execute an application but not requested in additional information, the permissions can be informed to the application developer device 870 or the additional information can be updated to include the permissions.

FIG. 9 is a flowchart illustrating a method of statically evaluating required permissions for an application in a server, according to another embodiment of the present invention.

Referring to FIG. 9, in operation 910, an application is received from an application developer device. In operation 920, a source code and additional information are acquired from the application. In operation 930, a function list is generated based on a control flow analysis of the source code. In operation 940, permissions required to execute the application are determined, and the required permissions are compared with previously requested permission information included in the additional information. In operation 950, as a result of the comparison, if the permissions required to actually execute the application match with the permissions requested in the additional information, the method proceeds to operation 960. Otherwise, if the permissions required to actually execute the application do not match with the permissions requested in the additional information, the method proceeds to

operation

970 or 980. In operation 960, the application is registered in a market place provided by the server, and the method ends. In operation 970, an evaluation result is transmitted to the application developer device. In operation 980, the additional information is updated to include only permissions required to execute the application based on the evaluation result, and the updated application is registered in the market place provided by the server in operation 960.

According to the current embodiment, even though a developer requests for required permissions in a wide range without requesting for required permissions one-by-one when an application is developed, additional information may be easily updated so that only permissions required to execute the application are requested for in a process of registering the application in a server providing applications, or the server may automatically update the additional information. In addition, an application providing server may also provide a user with an application for which only positively necessary permissions to execute the application are requested, and the user may also rely on the application providing server and download and use the application.

FIG. 10 is a block diagram of a smart device 1000 according to an embodiment of the present invention. In FIG. 10, the smart device 1000 includes an application calling unit 1010, an application acquisition unit 1020, a control flow analysis unit 1030, a permission evaluating unit 1040, and a display unit 1050.

Referring to FIG. 10, the application calling unit 1010 calls at least one application installed in the smart device 1000. The application calling unit 1010 may call all applications installed in the smart device 1000 or call all applications except for applications evaluated that permissions previously requested in additional information match with permissions actually usable by each application.

The application calling unit 1020 acquires a source code and additional information of each of the called at least one application, the control flow analysis unit 1030 generates a function list by analyzing a control flow of the application based on the acquired information, and the permission evaluating unit 1040 determines permissions actually used by the application based on the function list and evaluates whether the permissions actually used by the application with the permissions previously requested in the additional information. The above-described process may be performed for each of all called applications or for only applications selected by a user from among all the called applications. The display unit 1050 displays the evaluation result on a display screen of the smart device 1000.

FIG. 11 is an example of evaluating permissions actually used by an application installed in the smart device 1000, according to another embodiment of the present invention. Referring to FIG. 11, a plurality of applications 1110, such as “KAKAO Talk” and “ChatOn”, are called. If “ChatOn” is selected by a user, an evaluation (verification) result 1120 through a static analysis is displayed. That is, “CAMERA”, “FLASHLIGHT”, and “NFC” are permissions that are not actually used from among permissions declared in additional information. The user may feed the evaluation result 1120 back to a developer or an application providing server or delete the application “ChatOn”.

Although not shown, one of ordinary skill in the art understands that it is also possible to perform a permission evaluation for all called or the plurality of applications 1110, display an evaluation result together with a list of the plurality of applications 1110 and display a detailed evaluation result when a specific application is selected by the user.

FIG. 12 is a flowchart illustrating a method of evaluating permissions for an application installed in the smart device 1000, according to another embodiment of the present invention. Referring to FIG. 12, in operation 1210, at least one application is called by the smart device 1000. In operation 1220, it is allowed for a user to select an application for which permissions are evaluated from among the called at least one application. In operation 1230, a source code and additional information of the selected application are acquired, and in operation 1240, a control flow of the application is analyzed using the source code and the additional information, and a function list is generated. In operation 1250, permissions required to execute the application are evaluated based on the function list, and in operation 1260, an evaluation result is displayed on a display screen of the smart device 1000. In the current embodiment, operations 1230 to 1250 may be repeatedly performed for all applications called in operation 1210 or for one or more selected applications from among the called applications. In addition, the method may further include feeding the evaluation result back to a developer device or an application providing server or deleting an application.

According to the current embodiment, a user can call an application installed in a smart device of the user and easily perceive what permissions the application can actually use and what resources the application can access. In addition, the problem that the user can check required permissions for an application only when the application is installed and cannot perceive what permissions the application actually uses or what resources the application accesses when the application is executed is solved. In addition, the problem that even permissions unnecessary to execute an application are excessively set can be solved by feeding an evaluation result back to a developer or an application providing server or deleting the application based on the evaluation result.

According to an embodiment of the present invention, required permissions for an application to be executed can be easily perceived through a static analysis of a source code of the application without actually executing the application. Thus, an application developer may prevent an outflow of sensitive information, such as personal information and location information, through an application by developing the application with declaring only positively necessary permissions.

According to another embodiment of the present invention, even though a developer requests for required permissions in a wide range without requesting for required permissions one-by-one when an application is developed, contents to be updated from additional information may be informed so that only permissions required to execute the application are requested for in a process of registering the application in a server providing applications, or the server may automatically update the additional information. In addition, the application providing server may also provide a user with an application for which only positively necessary permissions to execute the application is requested, and the user may also rely on the application providing server and download and use the application.

According to another embodiment of the present invention, a user can call an application installed in a smart device of the user and easily perceive what permissions the application can actually use and what resources the application can access. In addition, the problem that the user can check required permissions for an application only when the application is installed and cannot perceive what permissions the application actually uses or what resources the application accesses when the application is executed is solved. In addition, the problem that even permissions unnecessary to execute an application are excessively set can be solved by feeding an evaluation result back to a developer or an application providing server or deleting the application based on the evaluation result.

One of ordinary skill in the art can analyse that the block diagrams disclosed in the present invention have a form in which circuits for implementing the principles of the present invention are conceptually represented. Similarly, one of ordinary skill in the art recognizes that arbitrary flowcharts, flow diagrams, state transition diagrams, and pseudo codes are substantially represented in a computer-readable recording medium to indicate various processes executable by a computer or processor regardless of whether the computer or processor is explicitly shown. Thus, the embodiments of the present invention can be written as computer programs and can be implemented in general-use digital computers that execute the programs using a computer-readable recording medium. Examples of the computer-readable recording medium include storage media such as magnetic storage media (e.g., ROM, floppy disks, hard disks, etc.) and optical recording media (e.g., CD-ROMs or DVDs).

Functions of the various elements shown in the drawings may be provided through the use of not only hardware capable of executing software in association with proper software but also exclusive hardware. When the functions are provided by a processor, the functions may be provided by a single exclusive processor, a single shared processor, or a plurality of individual processors some of which can be shared. In addition, the explicit use of the term “processor” or “controller” should not be analyzed to exclusively denote hardware capable of executing software and may implicitly include Digital Signal Processor (DSP) hardware, a Read Only Memory (ROM) for storing software, a Random Access Memory (RAM), and a nonvolatile storage device without any limitation.

In the claims of the specification, an element represented as a means for performing a specific function generally includes an arbitrary method of performing the specific function, and such an element may include a set of circuit elements for performing a specific function or an arbitrary form of software including firmware and microcode combined with a circuit suitable to perform software for performing the specific function.

In the specification, ‘an embodiment’ of principles of the present invention and various modifications of this expression indicate that a specific feature, structure, and characteristic associated with the embodiment are included in at least one embodiment of the principles of the present invention. Thus, the expression ‘in an embodiment’ and arbitrary other modified embodiments disclosed over all the specification do not necessarily indicate the same embodiment.

In the specification, the expression ‘at least one of’ in a case of ‘at least one of A and B’ is used to generally include only selection of the first option A, only selection of the second option B, or selection of both the options A and B. As an additional example, a case of ‘at least one of A, B, and C’ may generally include only selection of the first option A, only selection of the second option B, only selection of the third option C, only selection of the first and second options A and B, only selection of the second and third options B and C, or selection of all the three options A, B, and C. Even in a case of listing more items, it will be clearly extended and analyzed by one of ordinary skill in the art.

The present invention has been particularly shown and described with reference to exemplary embodiments thereof. All the embodiments and conditional illustrations disclosed in the specification are described with an intention for helping one of ordinary skill in the art to understand the principle and concept of the present invention, and one of ordinary skill in the art understands that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the following claims. The exemplary embodiments should be considered in descriptive sense only and not for purposes of limitation. Therefore, the scope of the present invention is defined not by the detailed description of the present invention but by the appended claims, and all differences within the scope will be construed as being included in the present invention.

Claims

A method of evaluating required permissions for an application executed in a device, the method comprising:

acquiring a source code from the application;

generating a function list including at least one function included in the source code; and

determining permissions required for the function list when the application is executed in the device.
The method of claim 1, wherein the acquiring comprises:

further acquiring additional information including previously requested permission information; and

comparing the previously requested permission information with the determined permissions and outputting the comparison result.
The method of claim 2, wherein the additional information further includes start location information of the source code, and

the function list includes functions determined to be executable based on a control flow of the source code from the start location.
The method of claim 3, wherein the function list is a function list obtained by filtering functions determined not to be called when the application is executed by determining a condition included in each of the functions from among the functions determined to be executable.
The method of claim 3, wherein the function list is a function list obtained by filtering functions determined not to be called by a virtual call when the application is executed by determining a type of each of the functions, from among the functions determined to be executable.
The method of claim 2, wherein the previously requested permission information is included in a manifest file, and

if the previously requested permission information does not match with the determined permissions, the method further comprises generating an updated manifest file based on the determined permissions.
A method of evaluating required permissions for an application in a server, the method comprising:

receiving the application from a developer device;

acquiring a source code of the application and additional information including previously requested permission information from the application;

generating a function list including at least one function included in the source code;

determining permissions required for the function list when the application is executed; and

comparing the previously requested permission information with the determined permissions, registering the application in the server if the previously requested permission information matches with the determined permissions, and transmitting the comparison result to the developer device if the previously requested permission information does not match with the determined permissions.
The method of claim 7, further comprising updating the additional information based on the determined permissions if the previously requested permission information does not match with the determined permissions.
A method of evaluating required permissions for an application in a smart device, the method comprising:

calling at least one application installed in the smart device;

allowing a user to select at least one application from among the called at least one application;

acquiring a source code of each application and additional information including previously requested permission information from the selected at least one application;

generating a function list including at least one function included in the source code;

determining permissions required for the function list when the application is executed; and

comparing the previously requested permission information with the determined permissions and displaying the comparison result on a screen of the smart device.
The method of claim 9, further comprising transmitting the comparison result to a developer device or an application providing server.
An apparatus for evaluating required permissions for an application executed in a device, the apparatus comprising:

an application acquisition unit for acquiring a source code from the application;

a control flow analysis unit for generating a function list including at least one function included in the source code; and

a permission evaluating unit for determining permissions required for the function list when the application is executed in the device.
The apparatus of claim 11, wherein the application acquisition unit further acquires additional information including previously requested permission information, and

the permission evaluating unit compares the previously requested permission information with the determined permissions and outputs the comparison result.
The apparatus of claim 12, wherein the additional information further includes start location information of the source code, and

the function list includes functions determined to be executable based on a control flow of the source code from the start location.
A server for evaluating required permissions for an application, the server comprising:

an application receiver for receiving the application from a developer device;

an application acquisition unit for acquiring a source code of the application and additional information including previously requested permission information from the application;

a control flow analysis unit for generating a function list including at least one function included in the source code;

a permission evaluating unit for determining permissions required for the function list when the application is executed; and

an application registering unit for registering the application in the server,

wherein the permission evaluating unit transmits a comparison result to the developer device if the previously requested permission information does not match with the determined permissions, and

the application registering unit registers the application in the server if the previously requested permission information matches with the determined permissions.
A smart device for evaluating required permissions for an application, the smart device comprising:

an application calling unit for calling at least one application installed in the smart device and allowing a user to select at least one application from among the called at least one application;

an application acquisition unit for acquiring a source code of each application and additional information including previously requested permission information from the selected at least one application;

a control flow analysis unit for generating a function list including at least one function included in the source code;

a permission evaluating unit for determining permissions required for the function list when the application is executed and comparing the previously requested permission information with the determined permissions; and

a display unit for displaying the comparison result on a screen of the smart device.