Patent Description:
An electronic device includes various types of device resources. For example, device resources may include at least one camera module, at least one sensor module, at least one speaker module, at least one microphone module, and/or at least one display module. An electronic device as described above may be implemented, by using at least one device resource, in a type of a comprehensive multimedia device (player) providing various functions, such as taking a photo or video, reproducing a music or video file, executing a game, receiving a broadcast, and supporting wireless Internet.

The following prior art publications are related to secure access to a resource of an electronic device:.

Generally, an electronic device may manage authority of access to device resources on a framework through a database. However, the database can be easily accessed or forged (falsified) by malicious use (e.g. rooting, framework changing, etc.) of the electronic device. Accordingly, there occurs a problem in that a device resource of the electronic device may be used in a malicious situation, such as when the electronic device is lost or stolen.

Therefore, various aspects are to provide a method and a device for preventing forgery (or falsification) of a database (e.g. an input/output database of a device resource) related to a device resource of an electronic device, and preventing malicious use of a device resource of the electronic device. Such aspects have been defined in the appended claims.

According to various embodiments, in a region in which a hypervisor (EL2), a secure EL2, or a virtual machine manager (VMM) are executed, authority of an application to access at least one device resource may be determined to prevent forgery (or falsification) of a configured authority related to the device resource of an electronic device, and prevent malicious use of the device resource of the electronic device.

Hereinafter, various embodiments will be described in detail with reference to the accompanying drawings. In addition, in describing the embodiments, a detailed description of known relevant functions or configurations incorporated herein will be omitted when it may make the subject matter of the disclosure unclear. The terms as described below are defined in consideration of the functions in the disclosure, and the meaning of the terms may vary according to the intention of a user or operator, convention, or the like. Therefore, the definitions of the terms should be made based on the contents throughout the specification.

<FIG> is a block diagram illustrating an electronic device <NUM> in a network environment <NUM> according to an embodiment.

According to an embodiment, the auxiliary processor <NUM> (e.g., an ISP or a CP) may be implemented as part of another component (e.g., the camera module <NUM> or the communication module <NUM>) functionally related to the auxiliary processor <NUM>.

According to an embodiment, the camera module <NUM> may include one or more lenses, image sensors, ISPs, or flashes.

The communication module <NUM> may include one or more communication processors that are operable independently from the processor <NUM> (e.g., the AP) and supports a direct (e.g., wired) communication or a wireless communication. The wireless communication module <NUM> may identify and authenticate the electronic device <NUM> in a communication network, such as the first network <NUM> or the second network <NUM>, using subscriber information (e.g., international mobile subscriber identity (IMSI)) stored in the SIM <NUM>.

<FIG> is a block diagram <NUM> illustrating an example of a program <NUM> according to various embodiments. According to an embodiment, the program <NUM> may include an operating system <NUM> for controlling at least one resource of the electronic device <NUM>, middleware <NUM>, or an application <NUM> that are executable in the operating system <NUM>. The operating system <NUM> may include, for example, Android™, iOS™, Windows™, Symbian™, Tizen™, or Bada™. At least a part of the program <NUM> may be, for example, preloaded on the electronic device <NUM> upon manufacture, or downloaded or updated from an external electronic device (for example, the electronic device <NUM> or <NUM>, or the server <NUM>) when used by a user.

The operating system <NUM> may control management (e.g. allocation or deallocation) of at least one system resource (e.g. a process, a memory, or a power source) of the electronic device <NUM>. The operating system <NUM> may additionally or alternatively include at least one driver program for operating another hardware device (e.g. a device resource) of the electronic device <NUM>, for example, an input device <NUM>, a sound output device <NUM>, a display device <NUM>, an audio module <NUM>, a sensor module <NUM>, an interface <NUM>, a haptic module <NUM>, a camera module <NUM>, a power management module <NUM>, a battery <NUM>, a communication module <NUM>, a SIM <NUM>, or an antenna module <NUM>.

The middleware <NUM> may provide various functions to the application <NUM> so that the application <NUM> uses a function or information provided from at least one resource of the electronic device <NUM>. The middleware <NUM> includes, for example, an application manager <NUM>, a window manager <NUM>, a multimedia manager <NUM>, a resource manager <NUM>, a power manager <NUM>, a database manager <NUM>, a package manager <NUM>, a connectivity manager <NUM>, a notification manager <NUM>, a location manager <NUM>, a graphics manager <NUM>, a security manager <NUM>, a telephony manager <NUM>, or a voice recognition manager <NUM>.

The application manager <NUM> may manage, for example, a life cycle of the application <NUM>. The window manager <NUM> may manage, for example, at least one GUI resource used in a screen. The multimedia manager <NUM> may, for example, identify one or more formats required for reproducing media files, and encode or decode a corresponding media file among the media files by using a codec matching a corresponding format selected among the formats. The resource manager <NUM> may manage, for example, a source code of the application <NUM>, or a memory space of the memory <NUM>. The power manager <NUM> may, for example, manage the capacity, temperature, or power of the battery <NUM>, and determine or provide relevant information required for an operation of the electronic device <NUM> by using corresponding information among the capacity, temperature, or power. According to an embodiment, the power manager <NUM> may be linked to a basic input/output system (BIOS) of the electronic device <NUM>.

The database manager <NUM> may, for example, generate, search for, or change a database to be used by the application <NUM>. The package manager <NUM> may manage, for example, installation or update of an application distributed in a package file form. The connectivity manager <NUM> may manage, for example, wireless connection or direct connection between the electronic device <NUM> and an external electronic device. The notification manager <NUM> may provide, for example, a function for notifying a user of occurrence of a designated event (e.g. an incoming call, a message, or an alarm). The location manager <NUM> may manage, for example, location information of the electronic device <NUM>. The graphics manager <NUM> may manage, for example, at least one graphic effect to be provided to a user, or a relevant user interface.

The security manager <NUM> may provide, for example, system security or user authentication. The telephony manager <NUM> may manage, for example, a voice call function or a video call function provided by the electronic device <NUM>. The voice recognition manager <NUM> may, for example, transmit voice data of a user to the server <NUM>, and receive, from the server <NUM>, an instruction corresponding to a function to be performed in the electronic device <NUM>, based on at least a part of the voice data, or character data converted based on at least a part of the voice data. According to an embodiment, the middleware <NUM> may dynamically remove a part of existing elements or add new elements. According to an embodiment, at least a part of the middleware <NUM> may be included in the operating system <NUM> as a part thereof, or may be implemented as separate software different from the operating system <NUM>.

The application <NUM> may include an application related to home <NUM>, dialer <NUM>, SMS/MMS <NUM>, instant message (IM) <NUM>, browser <NUM>, camera <NUM>, alarm <NUM>, contacts <NUM>, voice recognition <NUM>, e-mail <NUM>, calendar <NUM>, media player <NUM>, album <NUM>, clock <NUM>, health <NUM> (for example, measuring biometric information such as exercise quantity or blood sugar), or environment information <NUM> (for example, measuring of atmospheric pressure, humidity, or temperature information). According to an embodiment, the application <NUM> may further include an information exchange application for supporting information exchange between the electronic device <NUM> and an external electronic device. The information exchange application may include, for example, a notification relay application configured to transfer designated information (e.g. a call, a message, or an alarm) to an external electronic device, or a device management application configured to manage an external electronic device. The notification relay application may, for example, transfer, to an external electronic device, notification information corresponding to a designated event (e.g. mail reception) that has occurred in another application (e.g. the email application <NUM>) of the electronic device <NUM>. Additionally or alternatively, the notification relay application may receive notification information from an external electronic device, and provide the notification information to a user of the electronic device <NUM>.

The device management application may control, for example, power (e.g. turning-on or turning-off) or a function (e.g. the brightness, resolution, or focus of the display device <NUM> or the camera module <NUM>) of an external electronic device communicating with the electronic device <NUM>, or a part (e.g. the display device <NUM> or the camera module <NUM>) of the elements of the external electronic device. The device management application may additionally or alternatively support installation, removal, or update of an application operating in an external electronic device.

According to various embodiments, the program <NUM> described above may include an additional element <NUM> for managing access to a device resource, as illustrated. The additional element <NUM> may include a hypervisor <NUM>, a hyper (HYP) module <NUM>, an operating system (OS) module <NUM>, and an authority management manager <NUM>.

According to an embodiment, the authority management manager <NUM> may access input/output of at least one device resource in response to a request of at least one application <NUM> and the operating system <NUM>. According to an embodiment, the operating system module <NUM> may support information exchange between the authority management manager <NUM> and the HYP module <NUM>. For example, if the operating system module <NUM> detects change of an access restriction authority configuration of a device resource, the change being made by the authority management manager <NUM>, the operating system module may provide access restriction authority configuration information relating to the device resource to the HYP module <NUM>. In addition, the operating system module <NUM> may obtain a result of access authority restriction configuration performed by the HYP module <NUM>, and provide the obtained restriction configuration result to the authority management manager <NUM>.

According to an embodiment, the hypervisor <NUM> may be in a region which the operating system <NUM> and at least one application <NUM> is unable to access. For example, the hypervisor <NUM> or the HYP module <NUM> operating in a region of the hypervisor <NUM> may manage at least one virtual machine. Alternatively or additionally, according to various embodiments, the hypervisor <NUM> or the HYP module <NUM> may manage authority of access to a device resource. For example, the hypervisor <NUM> or the HYP module <NUM> may determine whether a device resource to be accessed by the operating system <NUM> or at least one application <NUM> is a restricted resource, and may provide a determination result to the operating system module <NUM>.

The electronic devices are not limited to those described above.

A method according to an embodiment of the disclosure may be included and provided in a computer program product.

<FIG> is a diagram <NUM> illustrating an architecture of the processor <NUM> according to various embodiments.

Referring to <FIG> the processor <NUM> may operate in multiple exception levels. The exception levels may be related to process authority levels processed by the processor <NUM>. For example, the exception levels may include EL0, EL1, EL2, and EL3, and more authority may be assigned to a high number exception level (e.g. EL3), compared to a low number exception level (EL0). As illustrated in <FIG>, at least one application <NUM> may be executed at EL0 <NUM>, and at least one operating system <NUM> may be executed at EL1 <NUM>. In addition, a hypervisor <NUM> may be executed at EL2 <NUM>. The at least one application <NUM>, the at least one operating system <NUM>, and the hypervisor <NUM> may be operated in a first region <NUM> called a non-secure state. In addition, the processor <NUM> may support a second region <NUM> called a secure state, which is separated from the first region <NUM> to prevent access by processes executed in the first region <NUM>. Accordingly, a secure application (app) <NUM>, a secure operating system (OS) <NUM>, a trusted firmware <NUM>, and a secure monitor <NUM> may be executed in the second region <NUM>.

As described above, the processor <NUM> may provide the first region <NUM> and the second region <NUM>. However, this is merely an example, and embodiments are not limited thereto. For example, the processor <NUM> may provide only the first region <NUM>, or the second region <NUM>.

According to an embodiment, the hypervisor <NUM> described above may manage at least one virtual machine. Alternatively or additionally, the hypervisor <NUM> may manage authority of access to a device resource. For example, the hypervisor <NUM> may manage an authority policy of a device resource at EL2 <NUM> which the operating system <NUM> and at least one application <NUM> are unable to access. The authority policy may be data defining a device resource restricted from being (or allowed to be) accessed by the operating system <NUM> and the at least one application <NUM>. In addition, the hypervisor <NUM> is able to configure the processor <NUM> to determine whether at least one application <NUM> and/or the operating system <NUM> has authority to access at least one device resource. For example, the hypervisor <NUM> is able to configure the processor <NUM> to: if an access to a device resource by at least one application <NUM> and/or the operating system <NUM> is detected, determine, based on a configured authority policy, whether the device resource to be accessed by the at least one application <NUM> and/or the operating system <NUM> is a restricted resource. For example, if the device resource is determined to be a restricted-access resource, the hypervisor <NUM> may receive information notifying of an access restriction from the processor <NUM>, and notify of the information.

According to an embodiment, an electronic device may include a memory; and a processor, wherein the processor is configured to execute at least one operating system executed in a first region allowing an operation based on a first authority; execute at least one application executed in a second region allowing an operation based on a second authority; and configure authority of access to at least one device resource in response to detection of access to the at least one device resource by the at least one application by using an authority determination module executed in a third region allowing an operation based on a third authority. The authority determination module may include a hypervisor.

The third authority may include an authority higher than the first authority.

The third region allowing an operation based on the third authority may include a region in which at least one of a hypervisor, a secure region, or a virtual machine manager (VMM) is executed.

The processor may be configured to store an authority policy defining a device resource restricted from being accessed by the at least one application, in the third region allowing an operation based on the third authority.

The processor may be configured to obtain the authority policy in the electronic device or from an external device.

The processor may be configured to provide the authority policy through a non-secure region of the processor to a non-secure region allowing an operation based on the third authority.

The processor may be configured to provide the authority policy through a secure region of the processor to a secure region allowing an operation based on the third authority.

The processor may be configured to provide the authority policy through a secure region of the processor to a non-secure region allowing an operation based on the third authority.

The processor may be configured to determine access authority of the at least one application, based on the configured authority of access to the at least one device resource; and if the configured authority is determined to be an authority by which access to the at least one device resource is restricted, provide information indicating restriction of access to the at least one device resource.

The processor may be configured to obtain a designated first authority policy during a boot-on operation, and after the boot-on operation is complete, obtain a second authority policy. For example, the first authority policy may be stored in the electronic device. In addition, the second authority policy may be obtained from the outside of the electronic device.

<FIG> is a flowchart <NUM> for determining authority of access to a device resource in the electronic device <NUM> according to an embodiment. In an embodiment described below, operations may be sequentially performed, but the disclosure is not limited to the sequential operations. For example, the sequences of operations may be changed, and at least two operations may be performed in parallel.

Referring to <FIG>, the electronic device <NUM> (or the processor <NUM>) may execute at least one operating system in step <NUM>. The processor <NUM> may process at least one operating system to be executed in a region allowing an operation based on a first authority. For example, the region allowing an operation based on the first authority may correspond to an exception level (e.g. EL1 <NUM>) to which more authority has been assigned compared to a low number exception level (EL0 <NUM>).

The processor <NUM> may execute at least one application in step <NUM>. The processor <NUM> may process execution of at least one application executed in a region allowing an operation based on a second authority. For example, the region allowing an operation based on the second authority may correspond to an exception level (EL0) to which less authority has been assigned compared to the region allowing an operation based on the first authority.

The processor <NUM> may determine authority of the at least one application to access a device resource, in step <NUM>. In a state where a restriction on access to a device resource by at least one application is configured, access to the device resource is restricted in view of hardware, and the processor <NUM> may be requested to determine authority of access to the device resource by using an authority determination module executed in a region allowing an operation based on a third authority. For example, the region allowing an operation based on the third authority may be a region in which a hypervisor, a virtual machine, and a secure EL2 are executed. For example, the region allowing an operation based on the third authority may correspond to an exception level (EL2 <NUM>) to which more authority has been assigned compared to the region allowing an operation based on the first authority. In addition, the authority determination module may include a hypervisor.

<FIG> is a flowchart <NUM> for determining authority of access to a device resource in an electronic device according to an embodiment. In an embodiment described below, operations may be sequentially performed, but the disclosure is not limited to the sequential operations. For example, the sequences of operations may be changed, and at least two operations may be performed in parallel.

Referring to <FIG>, the electronic device <NUM> (or. the processor <NUM>) may receive a request for determining authority of access to a device resource from an authority determination module executed in a region (e.g. EL2 <NUM>) allowing an operation based on a third authority, in step <NUM>. For example, the region allowing an operation based on the third authority may correspond to an exception level to which more authority has been assigned compared to the region (e.g. EL1 <NUM>) allowing an operation based on the first authority, as described above. In addition, the authority determination module may include a hypervisor <NUM>. The authority determination module may be configured to configure authority of access to a device resource. For example, the authority determination module may provide a configured access authority to the processor <NUM> to request determination of authority of access to a device resource.

The processor <NUM> may execute at least one operating system in step <NUM>. The processor <NUM> may process at least one operating system to be executed in a region allowing an operation based on a first authority. For example, the region allowing an operation based on the first authority may correspond to an exception level to which more authority than that of a region (e.g. EL0 <NUM>) allowing an operation based on a second authority has been assigned.

The processor <NUM> may execute at least one application in step <NUM>. The processor <NUM> may process execution of at least one application executed in a region allowing an operation based on a second authority. For example, the region allowing an operation based on the second authority may correspond to an exception level to which less authority has been assigned compared to the region allowing an operation based on the first authority.

The processor <NUM> may determine authority of the executed at least one application to access the device resource, in step <NUM>. The processor <NUM> may determine the access authority of at least one application accessing particular hardware, based on an access authority received from the authority determination module.

The processor <NUM> may perform processing such that a restriction on access to the device resource by the at least one application is configured, in step <NUM>. In response to detection of access, by at least one application, to a device resource for which an access restriction is configured, the processor <NUM> may perform processing such that a restriction on access to the device resource is configured. In addition, the processor <NUM> may notify an authority management module that the access restriction is configured. For example, in a state where a restriction on access to a device resource by at least one application is configured, access to the device resource is restricted in view of hardware, and the authority management module executed in the region allowing an operation based on the third authority may be notified of information informing that access to the device resource is restricted.

<FIG> is a flowchart <NUM> for configuring an authority policy in the electronic device <NUM> according to an embodiment. In addition, <FIG> is a diagram <NUM> illustrating an additional policy authority according to an embodiment. The steps in <FIG> described below may correspond to various embodiments of step <NUM> in <FIG>. In addition, in an embodiment below, operations may be sequentially performed, but the disclosure is not limited to the sequential operations. For example, the sequences of operations may be changed, and at least two operations may be performed in parallel.

Referring to <FIG>, according to various embodiments, the electronic device <NUM> (or the processor <NUM>) may perform a boot-on operation in step <NUM>. The processor <NUM> may perform a boot-on operation in response to reception of an input indicating the boot-on operation. For example, the input indicating the boot-on operation may include a power key input. As another example, the input indicating the boot-on operation may be related to a power supply to the electronic device <NUM>.

The processor <NUM> may obtain a designated authority policy in step <NUM>. The authority policy may be data defining a device resource restricted from being (or allowed to be) accessed by the operating system <NUM> and/or at least one application <NUM>, as described above. For example, the authority policy may be encrypted and stored in a predesignated storage space (e.g. a storage space having a predetermined level of security level). For example, the authority policy may be obtained by a framework module operating in a region allowing an operation based on a first authority, as described below with reference to <FIG> and <FIG>.

The processor <NUM> may configure a resource authority, based on the obtained authority policy, in step <NUM>. The processor <NUM> may configure a resource authority by storing the obtained authority policy in a region (e.g. EL2) allowing an operation based on a third authority, as described below with reference to <FIG> and <FIG>. In addition, the processor <NUM> may perform a resource authority operation before the boot-on operation is complete.

The processor <NUM> may determine whether an additional authority policy is obtained, in step <NUM>. The additional authority policy may be obtained in a state where the boot-on operation has been complete. For example, the additional authority policy may be received through an external electronic device (e.g. the electronic device <NUM>, the electronic device <NUM>, or the server <NUM>). The processor <NUM> may obtain an additional authority policy defining at least one device resource restricted or allowed based on a user's input. As illustrated in <FIG>, a user may select a target (e.g. a control target) for which access to a device resource is controlled, through an external electronic device (as indicated by reference numeral <NUM>). The user may select at least one device resource, access to which is restricted or allowed, among the device resources of the selected control target (as indicated by reference numeral <NUM>). For example, the user may control access to all sensors among the device resources. In addition, the user may control access to a part of the sensors among the device resources. For example, the additional authority policy may be defined by a user who lost the electronic device <NUM>. As another example, the additional authority policy may be defined by an external company (e.g. a financial institution) for claiming (or securing) ownership of the electronic device <NUM>.

The processor <NUM> may execute at least one operating system if the additional authority policy is not obtained. For example, the processor <NUM> may perform an operation related to step <NUM> in <FIG>.

If the additional authority policy is obtained, the processor <NUM> may update the resource authority, based on the additional authority policy, in step <NUM>. The processor <NUM> may update the resource authority by updating the policy authority stored in the region allowing an operation based on the third authority, based on the obtained additional policy authority. In addition, after updating the resource authority, the processor <NUM> may execute at least one operating system. For example, the processor <NUM> may perform an operation related to step <NUM> in <FIG>.

<FIG> is a flowchart <NUM> for configuring a resource authority in the electronic device <NUM> according to an embodiment. In addition, <FIG> is a diagram <NUM> illustrating a procedure of providing an authority policy to a region allowing an operation based on a third authority according to an embodiment, <FIG> is a diagram <NUM> illustrating a procedure of providing an authority policy to a region allowing an operation based on a third authority according to an embodiment, and <FIG> is a diagram <NUM> illustrating a procedure of providing an authority policy to a region allowing an operation based on a third authority according to an embodiment. The steps in <FIG> described below may correspond to various embodiments of step <NUM> in <FIG>. In addition, in an embodiment below, operations may be sequentially performed, but the disclosure is not limited to the sequential operations. For example, the sequences of operations may be changed, and at least two operations may be performed in parallel.

Referring to <FIG>, the electronic device <NUM> (or the processor <NUM>) may provide a designated authority policy to a region allowing an operation based on a third authority, in step <NUM>. For example, an authority policy may be obtained by a framework module operating in a region (e.g. EL0) allowing an operation based on a first authority, and the processor <NUM> may provide the obtained authority policy to a region (e.g. EL2) allowing an operation based on a third authority. For example, the authority policy may be provided through a region (e.g. EL1) allowing an operation based on a second authority to a region (e.g. EL2) allowing an operation based on a third authority.

The processor <NUM> may provide an authority policy through a first region <NUM> called a non-secure state (or normal world) to a non-secure region allowing an operation based on the third authority, as illustrated in <FIG>. The non-secure region may include a framework module <NUM>, an operating system module <NUM>, and a HYP module <NUM>. For example, the processor <NUM> may provide an authority policy obtained through the framework module <NUM>, to the HYP module <NUM> through the operating system module <NUM>.

For example, the framework module <NUM> may operate at a low number exception level (EL0) to which the least authority has been assigned, and may obtain (or receive) an authority policy from an external electronic device (e.g. the electronic device <NUM>, the electronic device <NUM>, or the server <NUM>). In addition, the framework module <NUM> may provide an authority policy obtained from the external electronic device, to the operating system module. As described above, the operating system module <NUM> may provide an authority policy received from the framework module <NUM>, to the HYP module <NUM> through supporting information exchange between the framework module <NUM> and the HYP module <NUM>. The authority policy may be data defining a device resource restricted from being (or allowed to be) accessed by an operating system and at least one application. The HYP module <NUM> may manage authority of access to a device resource, as described above. For example, the HYP module <NUM> (or a hypervisor) may store an authority policy received from the operating system module <NUM>. In addition, the HYP module <NUM> may determine whether a device resource to be accessed by an operating system or at least one application is a restricted resource, and may provide a determination result to the operating system module <NUM>.

According to another embodiment, the processor <NUM> may provide an authority policy through a second region <NUM> that is called a secure state (or secure world) and is separated from the first region <NUM>, to a secure region allowing an operation based on the third authority, as illustrated in <FIG>. The secure region may include a trusted application <NUM>, a secure operating system module <NUM>, and a secure EL2 <NUM>. For example, the processor <NUM> may store an authority policy obtained through the trusted application <NUM>, in the secure EL2 <NUM> through the secure operating system module <NUM>. For example, the trusted application <NUM>, the secure operating system module <NUM>, and the secure EL2 <NUM> may be similar to the framework module <NUM>, the operating system module <NUM>, and the hypervisor <NUM> which are executed in the first region <NUM>, differing only in that the trusted application, the secure operating system module, and the secure EL2 are executed in the second region <NUM> separated from the first region <NUM>.

According to another embodiment, the processor <NUM> may provide an authority policy through a different second region <NUM> that is called a secure state (or secure world) and is separated from the first region <NUM>, to a non-secure region allowing an operation based on the third authority, as illustrated in <FIG>. The secure region <NUM> may include a trusted application <NUM>, a secure operating system module <NUM>, and a monitor module <NUM>. For example, an authority policy may be obtained by the trusted application <NUM>, and the obtained authority policy may be stored in a non-secure region <NUM> allowing an operation based on the third authority in the first region, as illustrated in <FIG>. The authority policy obtained in the secure region <NUM> (e.g. obtained through the trusted application <NUM> and the secure operating system module <NUM>) may be transferred through the monitor module <NUM> to the non-secure region <NUM>.

The processor <NUM> may decode the authority policy through the region allowing an operation based on the third authority, in step <NUM>. The processor <NUM> may decode an encrypted authority policy by using a hypervisor executed in the region allowing an operation based on the third authority.

The processor <NUM> may store the decoded authority policy in a region allowing an operation based on the third authority, in step <NUM>. The processor <NUM> may store the decoded authority policy in a non-secure region allowing an operation based on the third authority or a secure region allowing an operation based on the third authority.

The processor <NUM> may store the decoded authority policy in a region allowing an operation based on the third authority, to finish a resource authority configuration operation. The processor <NUM> may determine whether an additional authority policy is obtained, after storing the decoded authority policy. For example, the processor <NUM> may perform an operation related to step <NUM> in <FIG>.

<FIG> is a flowchart <NUM> for processing access to a device resource in the electronic device <NUM> according to an embodiment. The steps in <FIG> described below may correspond to various embodiments of step <NUM> in <FIG>. In addition, in an embodiment below, operations may be sequentially performed, but the disclosure is not limited to the sequential operations. For example, the sequences of operations may be changed, and at least two operations may be performed in parallel.

Referring to <FIG>, the electronic device <NUM> (or the processor <NUM>) may determine whether access to a device resource is detected, in step <NUM>. Input/output of a device resource may be managed through a database. The processor <NUM> may determine whether an operating system or at least one application accesses a memory address region corresponding to at least one device resource. However, the determination merely corresponds to an example, and embodiments are not limited thereto. For example, the processor <NUM> may detect that an operating system or at least one application accesses at least one device resource, based on various known methods.

If access to the device resource is not detected, the processor <NUM> may repeatedly perform an operation of determining whether access to the device resource is detected. For example, the processor <NUM> may perform an operation related to step <NUM>. Step <NUM> may occur repeatedly in a normal situation in which the program <NUM> uses a device resource.

If access to the device resource is detected, the processor <NUM> may determine whether the device resource that has been detected to be accessed is a device resource for which access authority is restricted, in step <NUM>. For example, the processor <NUM> may determine whether an event of determining authority of access to the device resource occurs, based on the determination. Step <NUM> may be determined in the processor <NUM> in view of hardware. The access authority determination event may be a designated event of allowing an authority management module to perform a subsequent processing operation when access to the device resource is restricted. The processor <NUM> may determine that an access authority determination event has occurred, in response to detection of access to a device resource for which access authority is restricted. For example, the processor <NUM> may determine that a device resource for which access authority is restricted has been accessed, in response to detection of rooting in which the highest authority is obtained in an operating system running in the electronic device <NUM>. As another example, the processor <NUM> may determine that a device resource for which access authority is restricted has been accessed, in response to obtaining of an additional authority policy defining at least one device resource that is restricted or allowed, from an external electronic device (e.g. the electronic device <NUM>, the electronic device <NUM>, or the server <NUM>). As another example, the processor <NUM> may determine that a device resource for which access authority is restricted has been accessed, in response to detection of installation of a custom binary that is not authenticated. As another example, the processor <NUM> may determine that a device resource for which access authority is restricted has been accessed, in response to detection of entering into a predesignated region (or area, zone) that is not permitted to be accessed.

In a case where a device resource for which access authority is restricted is accessed, if a restriction of authority of access to a corresponding device resource region is previously configured in a region allowing an operation based on a third authority, the processor <NUM> may determine, in view of hardware, whether the resource is a resource for which access authority is restricted, in step <NUM>.

If a device resource detected to be accessed is a device resource for which access authority is restricted, the processor <NUM> may request modules in a different region to perform subsequent processing on the device resource access authority restriction in a region allowing an operation based on the third authority, in step <NUM>. For example, a subsequent processing request may be a notification (permission fault) informing of access to a restricted device resource. As described above, the region allowing an operation based on the third authority is a region in which a hypervisor, a virtual machine, and a secure EL2 are executed, and may correspond to an exception level (EL2 <NUM>) to which more authority has been assigned compared to an exception level (EL0) of a region allowing an operation based on a first authority. In addition, an authority determination module may include a hypervisor.

If the device resource is a device resource for which access authority is not restricted, the processor <NUM> may allow access to the device resource in step <NUM>. The processor <NUM> may perform processing such that a device resource accessed by an operating system or at least one application is executed.

<FIG> is a flowchart <NUM> for processing an access to a device resource in an electronic device according to an embodiment. The steps in <FIG> described below may correspond to various embodiments of step <NUM> in <FIG> or step <NUM> in <FIG>. In addition, in an embodiment below, operations may be sequentially performed, but the disclosure is not limited to the sequential operations. For example, the sequences of operations may be changed, and at least two operations may be performed in parallel.

Referring to <FIG>, the processor <NUM>) may identify whether access to a device resource restricted from being executed is identified, in step <NUM>. The processor <NUM> may determine whether an operating system or at least one application accesses a restricted device resource, by using an authority determination module executed in a region allowing an operation based on a third authority. For example, the authority determination module may identify a restricted device resource, based on a predesignated authority policy.

If access to the restricted device resource is identified, the processor <NUM> may determine that a restriction on access to the device resource is required, in step <NUM>.

If a restriction on access to the device resource is determined to be required, the processor <NUM> may provide a notification informing of access restriction, in step <NUM>. The processor <NUM> may provide the notification informing of access restriction to at least one of a framework module or an operating system module. Accordingly, the processor may perform processing such that a message notifying that execution of the device resource is restricted is output through a display device <NUM> of the electronic device <NUM>. As another example, the processor <NUM> may process execution of the application to be stopped according to the notification. However, the processing merely corresponds to an example, and embodiments are not limited thereto. For example, the notification may be provided in various forms such as an audio form, a vibration form, etc. After providing a notification informing of access restriction, the processor <NUM> may store a record (e.g. log) showing occurrence of an abnormal (or malicious) operation in the electronic device <NUM> (such as in the memory <NUM>) or the outside (e.g. an external electronic device (e.g. the electronic device <NUM>, the electronic device <NUM>, or the server <NUM>)) of the electronic device <NUM>.

If access to the restricted device resource is not identified, the processor <NUM> may determine that access to a device resource is allowed, in step <NUM>.

If access to a device resource is determined to be allowed, the processor <NUM> may perform processing such that the device resource accessed by the operating system or the at least one application is executed, in step <NUM>.

<FIG> is a diagram <NUM> illustrating an operation of accessing a device resource in a general electronic device. In addition, <FIG> is a diagram <NUM> illustrating an operation of accessing a device resource in the electronic device <NUM> according to an embodiment.

Referring to <FIG>, the electronic device may execute at least one application, for example, a camera application <NUM>, based on a designated input. In response to execution of the camera application <NUM>, at least one camera driver program <NUM> (e.g. a camera driver of an operating system) for operating at least one device resource (e.g. a camera module) may be executed in a memory region. In addition, the camera driver <NUM> may access a register <NUM> related to input/output of the camera module, to process the camera module to be operated. The register <NUM> of the device resource can be easily accessed by an application, and thus there may occur a problem in that the device resource of the electronic device may be used in a malicious situation. For example, there may occur a problem in that a user who finds a lost electronic device uses or attempts to use a device resource.

However, the electronic device <NUM> determines authority of an application to access at least one device resource, in a region in which at least one of a hypervisor (EL2), a secure EL2, or a virtual machine manager (VMM) is executed. Therefore, the electronic device can prevent forgery (or falsification) of a database related to the device resource of the electronic device, and prevent malicious or unauthorized use of the device resource of the electronic device.

Specifically, referring to <FIG>, if the camera driver <NUM> is detected to access the register <NUM> related to input/output of a device resource, for example, the camera module, the processor <NUM> determines authority of an application to access the device resource, the authority being configured in a hypervisor <NUM>. Therefore, the device resource of the electronic device <NUM> can be prevented from being used maliciously.

According to an embodiment, an operation method of an electronic device may include executing at least one operating system executed in a first region allowing an operation based on a first authority; executing at least one application executed in a second region allowing an operation based on a second authority; and configuring authority of access to at least one device resource in response to detection of access to the at least one device resource by the at least one application by using an authority determination module executed in a third region allowing an operation based on a third authority. The authority determination module may include a hypervisor.

The third region allowing an operation based on the third authority may include a region in which at least one of a hypervisor, a secure EL2, or a virtual machine manager (VMM) is executed.

The method of the electronic device may further include storing an authority policy defining a device resource restricted from being accessed by the at least one application, in the third region allowing an operation based on the third authority.

The method of the electronic device may further include obtaining the authority policy in the electronic device or from an external device.

The authority policy may be provided through a non-secure region of a processor to a non-secure region allowing an operation based on the third authority.

The authority policy may be provided through a secure region of a processor to a secure region allowing an operation based on the third authority.

The authority policy may be provided through a secure region of a processor to a non-secure region allowing an operation based on the third authority.

The method of the electronic device may further include determining access authority of the at least one application, based on the configured authority of access to the at least one device resource, and if the configured authority is determined to be an authority by which access to the at least one device resource is restricted, providing information indicating restriction of access to the at least one device resource.

Obtaining the authority policy may include obtaining a designated first authority policy during a boot-on operation and after the boot-on operation is complete, obtaining a second authority policy. The first policy authority policy may be stored in the electronic device, and the second authority policy may be obtained from the outside of the electronic device.

Claim 1:
An electronic device (<NUM>) comprising:
a memory (<NUM>); and
a processor (<NUM>) configured to:
execute (<NUM>) at least one operating system executed in a first region (<NUM>) of the processor (<NUM>) allowing an operation based on a first authority;
execute (<NUM>) at least one application executed in a second region (<NUM>) of the processor (<NUM>) allowing an operation based on a second authority; and
in response to detection of access to at least one device resource by the at least one application, configure (<NUM>) authority of access to the at least one device resource by using an authority determination module executed in a third region (<NUM>) of the processor (<NUM>) allowing an operation based on a third authority;
the electronic device (<NUM>) wherein
the processor (<NUM>) is further configured to:
store an authority policy defining a device resource restricted from being accessed by the at least one application, in the third region (<NUM>) allowing an operation based on the third authority; and
provide the authority policy through a secure region of the processor (<NUM>) to a non-secure region of the processor (<NUM>) allowing an operation based on the third authority.