Patent Description:
Various abbreviations that appear in the specification and/or in the drawing figures are defined as follows:.

D-Bus was designed to allow communication between system-level processes (such as printer and hardware driver services) and normal user processes. D-bus uses a fast, binary message-passing protocol, which is suitable for same-machine communication due to its low latency and low overhead. Its specification is currently defined by the freedesktop. org project, and is available to all parties. Communication in general happens through a central server application, called the "bus" (hence the name), but direct application-to-application communication is also possible. When communicating on a bus, applications can query which other applications and services are available, as well as activate one on demand. D-Bus buses are used when many-to-many communication is desired. In order to achieve that, a central server is launched before any applications can connect to the bus: this server is responsible for keeping track of the applications that are connected and for properly routing messages from their source to their destination. In addition, D-Bus defines two well-known buses, called the system bus and the session bus. These buses are special in the sense that they have well-defined semantics: some services are defined to be found in one or both of these buses. For example, an application wishing to query the list of hardware devices attached to a computer will likely communicate to a service available on the system bus, while a service providing for the opening of a web browser will likely be found. On the system bus, one can also expect to find restrictions on what services each application is allowed to offer.

Therefore, unless otherwise indicated herein, what is described in the foregoing is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.

Prior art solutions are disclosed in <CIT> and <NPL>.

In an exemplary aspect of the invention, there is a method as defined by appended claim <NUM>.

In an exemplary aspect of the invention, there is an apparatus as defined by appended claim <NUM>.

The foregoing and other aspects of embodiments of this invention are made more evident in the following Detailed Description, when read in conjunction with the attached Drawing Figures, wherein:.

Examples of a method, apparatus, and computer program for providing techniques of resource access control to a software application are disclosed. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention. It is apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the embodiments of the invention.

Access control in Linux is based on a multi-user model. POSIX capabilities are not fully exploited.

A need exists for process level access control, especially one that would require minimal changes to the current model while providing flexibility and granularity. There are some existing and currently available security extensions, but for various reasons they do not fulfill the foregoing criteria.

The exemplary embodiments of this invention apply and extend aspects of UNIX AC to fulfill the foregoing criteria, and employ a multi-user model to provide application level AC.

The exemplary embodiments of this invention adhere to a "principle of least privileges" of access control, where an application should be able to access only a limited set of resources actually needed by that application. Certain resources may be considered to be protected resources such as, but not limited to, cellular communication functionality and location/mapping functionality. An application must declare those resources that it needs. The declaration of needed resources may be in the form of a manifest file.

It is noted that in the preferred embodiments there are no security APIs by default.

<FIG> shows a device <NUM> that uses Linux and that conceptually contains a user mode <NUM> and a kernel mode <NUM> according to one embodiment. One or more applications are loaded from a (trusted) source <NUM>.

A given SW (e.g., a user application) obtains its rights based on its source code and the manifest file. This entails creation, during the software development phase, of the manifest file to specify the resources needed by the SW, and placing the SW and associated manifest file into a suitable repository or source. <FIG> shows the (trusted) source <NUM> containing one or more applications (App<NUM>, App<NUM>. AppN) according to one embodiment. It can be assumed that there are quality assurance checks associated with the source <NUM>. A security policy file is accessible in one embodiment only for an installer 12A that forms a part of the user mode <NUM>, and in another embodiment the security policy file itself is readable by installers not yet in the user mode. Also included is a device policy 12B, which would be used to identify and verify trusted source(s) <NUM>, a D-Bus daemon 12C and a D-Bus policy 12D. In accordance with an aspect of the exemplary embodiments of this invention the D-Bus daemon includes D-Bus extensions 12E. The kernel mode <NUM> includes, further in accordance with an aspect of the exemplary embodiments of this invention, a resource possession list 14A and a process credentials assigner 14B. Also included are a Linux kernel reference monitor 14C and a file's AC lists 14D.

<FIG> shows the foregoing components in somewhat greater detail, and provides an overview of the principle of least privileges enforcement according to one embodiment.

As was mentioned above, an important goal of the security architecture is an enforcement of the "principle of least privilege". As an aid to explanation, a most common abstraction for representing a computer system is dividing it into objects and subjects. Subject is an active entity, which represents a system's user or system process in the computer system. By a subject, one may denote a process in the system, meaning that the access control is process-based. Object is a passive entity, which represents a file, a system resource or even a subject. The latter means that, for example, an executable file is an object of a computer system, but when it starts to execute it becomes a subject of this system. The term resource is used to denote objects in the system.

The third commonly used abstraction is an access type: an operation that a subject can perform on an object. The concrete meaning of access type depends on the computer system. For the file server it can be an ability to read an object (file), to write it, to execute and so forth. For database systems access type can be an ability to insert a new record into a table, to search for data in the database and so forth.

The principle of least privilege may thus be defined as "every subject must be able to access only such objects that are necessary to its legitimate purpose".

Turning now to <FIG>, the installer 12A may be considered as the "entrance door" for new applications, application updates, device policy updates and key updates.

The software sources ranking and resources usage policy (SSRRU policy) is embodied in the device policy block 12B of <FIG>. The SSRRU policy defines the possible known sources of SW for the device <NUM>, their hierarchy, and allowed resources for each of them. For example, the SSRRU policy may specify that there are two known sources: Source1 and Source2, where Source1 is considered to be more trusted than Source2; and SW from Source1 is allowed to use any possible resources, while SW from Source2 may only use Resource1 and Resource2. Initially, the SSRRU policy may be defined by a manufacturer of the device or an operator, if, for example, a device is intended to be distributed via special promotions. For example, an operator may sell a device to an end-user for a small price, but in one embodiment the user is expected to use only a set of SW sources defined by the manufacturer/operator while in another embodiment the user is allowed to use only the manufacturer's/operator's set of SW sources which may be e.g., a SW repository. This policy can be later changed by an authorized policy update. If there are no restrictions enabled on the device, a user can add new sources of SW and assign a list of allowed resources to them. However, the user cannot change the hierarchy of device predefined sources; and cannot grant some sensitive resource(s) to new sources of SW.

The D-Bus is an inter-processor communication (IPC) system for software applications to communicate with each other. D-Bus allows programs to register and offer services to others, and it also allows access control rights to be defined for these services. Access control rights for each D-Bus service can be declared in the D-Bus policy file 12D. Thus, it is possible to define which subject (process) is allowed to access a particular D-Bus service.

The D-Bus reference monitor is a part of the D-Bus daemon 12C, and makes access control decisions based on D-Bus policy, process credentials and the service requested. For example, Process1 wants to send a message to a Service1. The D-Bus reference monitor will check in the D-Bus policy 12D if Process1 is allowed to send a message to Service1. Depending on the policy in place the message will be sent or declined. The D-Bus reference monitor is extended, in accordance with an aspect of this invention, to include the extensions 12E.

The kernel mode <NUM> components include object's access control list 14D. The access control list (ACL) associates with each object in a computer system a list of the system's subjects (which have at least one access right to the object in question). The ACL is typically stored with the object. For the file system AC it may be preferred to use an existing Unix ACL, which can specify access types for owner, owner's group and others. The access types are "read", "write" and "execute".

The kernel mode <NUM> also includes the process credentials assigner 14B which, in accordance with an aspect of this invention, is enabled to modify process credentials at the moment when a process starts to execute.

The Linux kernel reference monitor 14C is a distributed entity which makes an AC decision based on process credentials and an object's ACLs. <FIG>, described below, provide additional details concerning the Linux kernel reference monitor functionality, according to one embodiment.

The resource possession list 14A defines which resources are allowed to be accessed by a process in the system. The list contains a mapping between application identifiers and allowed resources for each such application.

An application identifier fulfills the following requirements: it should be impossible to forge; it should be unique (identify an application uniquely); and it should remain the same for application updates, between boot-ups, for different instances of the same application, and after application restart. The application identifier may be represented by a triplet:<MAT> where SourceID is a unique identifier of an application source. While it should be tight with a key, which is used by this source, it shouldn't directly depend on the key (as the key may be changed due to key compromising). The example may be a current domain name of a repository (for example: Nokia, Maemo), or a unique identifier derived from a key certificate. PackageName is a package name without a version number. AppName is defined by a developer, in case there are a number of applications within the same binary package, and these applications need different access rights. The AppName is defined within the Aegis manifest file. In case there is no such definition, all applications within the same package get the same application identity of a form: AppID = {SourceID, PackageName, none}.

In the currently considered architecture a resource is a virtual object which represents some functionality. It can be a file on the filesystem, a D-Bus service and so on. Resources are described using resource token strings. For example: "Location", "Network-Costly", etc. There is a special service in the system which defines for each sensitive system resource a resource token which should protect this resource. For example, consider a "Network-Costly" resource token. It represents access to all communication channels which may incur costs to a user. The real system objects that are protected by this resource are filesystem objects (such as network configuration files), the possibility to execute "Connect" and "Bind" commands.

An initial set of protected resources may include a small set of predefined resources (such as access to user's data, location information, network services and so forth). Moreover, each application has a possibility to define a new resource which the application itself provides. In this case it is important to ensure that there are no conflicts in the resource's namespace which may be done, for example, by an authority that certifies SW.

<FIG> and <FIG> show an exemplary interaction between these various components for the case of a new application installation.

In <FIG>, an application arrives at the installer 12A (the arrow labeled <NUM>). The installer 12A checks the device policy 12B for information concerning the source <NUM> from which the application arrived (the arrow labeled <NUM>). The installer 12A modifies the resource possession list 14A accordingly for the application (the arrow labeled <NUM>). The installer 12A also accordingly modifies the D-Bus policy 12D.

Describing the installation process now in further detail in <FIG>, upon a new application installation (e.g., request by a user in 3A) the installer 14A at 3B checks the software sources ranking and resources usage policy in the SSRRU policy 12B to determine if the source <NUM> is known, and what kind of resources are allowed for SW from this source. At 3C the installer 12A extracts the resource declarations from the package, and makes an intersection of the extracted resource declarations and the set of resources obtained from the SSRRU policy 12B. The package is then installed. Some user-related resources, such as an ability to read user data, network communication and so forth may also be granted by a user. After successful installation, at 3D the installer 12A modifies the resource possession list 14A by adding a new rule for the new package, where the set of allowed resources is an intersection of package-requested resources and the set of resources defined by the SSRRU 12B for the source <NUM> of the SW. The process of forming a result set of allowed resources is depicted in <FIG>. At 3F the installer 12A also modifies the D-Bus policy 12D if the new application defines a new D-Bus service.

<FIG>, <FIG>, <FIG> and <FIG> show the interaction of the components at application run time according to one embodiment of the invention. Considering <FIG> first, the process credentials assigner 14B obtains the allowed set of resources from the resource possession list 14A (arrow labeled <NUM>), and (arrow labeled <NUM>) the process credentials assigner 14B modifies the process' credentials 14B' (process task structure). At 3a the Linux reference monitor 14C makes an AC decision based on the process's credentials 14B' and the file system AC lists 14D. At 3b the D-Bus daemon 12C makes an AC decision based on the process credentials 14B' and D-Bus policy 12D. The application calls the library to obtain process credentials, and makes a decision based on the process credentials 14B' and its own policy.

Reference is now made to <FIG> for a more detailed description of the operations performed when the application starts to execute, according to one embodiment. The run-time access control can be done at different levels, depending on the action that application attempts to perform (for example, file access or sending a D-Bus message), and the actual level of delegation of the AC decision. The latter means that the application can rely on the operating system or the D-Bus to protect the resource it provides, or may provide its own protection.

<FIG> shows a MSC for the non-limiting case of filesystem access, when the access to a file is constrained by its file permissions. In this example the access rights check is delegated to the Linux kernel reference monitor 14C. When a process starts to execute a sys_execve kernel function is called. This function is enhanced so that it calls (at 6A) the process credentials assigner 14B, which makes a look-up in the resource possession list 14A and assigns corresponding process credentials to the process (6B). This is done by modifying the task kernel structure (at 6C the process credentials assigner 14B modifies the application's credentials according to the set of allowed resources). Control is then transferred to the application and the application executes at 6D. When a process wants to access a system object (in <FIG> it is a file on a filesystem <NUM>), the Linux kernel reference monitor 14C obtains its credentials, ACLs of an object (for the filesystem object, in this case the file's permissions <NUM>) and, based on this information, makes an access control decision (6E). In Linux this is done inside system calls, for example inside a sys_open call for the case shown in the <FIG>. The interactions labeled 6F generally show the operation for the case where the access control is allowed or denied.

Reference is now made to <FIG>, which is the MSC run-time in a case of D-Bus access control. For the case of IPC, which is done over the D-Bus, the access control decision is made by the D-Bus reference monitor (D-Bus daemon 12C), which takes into account process credentials, the service that the process wants to access and the D-Bus policy. There are two applications in <FIG>, according to one embodiment: a D-Bus client 20A and a D-Bus server 20B. The D-Bus client 20A is started in the same manner as the application described in <FIG> (generally shown as 7A). The D-Bus server is assumed to be started in the same way as well (and this is omitted from <FIG>). After a successful start the D-Bus client 20A attempts to connect to the D-Bus via the D-Bus daemon 12C (7B). At 7C the D-Bus daemon 12C obtains the D-Bus client credentials (either from its process task structure or in a simple case, it uses a static mapping from the system configuration file) and the D-Bus policy rules from D-Bus policy file 12D. Based on the obtained information the D-Bus daemon 12C creates a memory representation of the policy for the client 20A (D-Bus connection policy 12D shown at 7D). When the D-Bus client 20A sends a message to the D-Bus server 20B (7E), it first sends it to the D-Bus daemon 12C. The D-Bus daemon 12C checks the connection policy 12D and makes an access control decision based on it (7F). As a result, the message is ether passed to its intended receiver (to the D-Bus server 20B in this case) or the D-Bus client 20A receives an error message (7F).

Whereas <FIG> shows the policy 12D as separate from the daemon 12C, in an embodiment the policy is not a physically separate component but is a part of the running D-Bus daemon hosting the ruleset that is allowed. So for example a client wanting to connect to the server using the D-Bus means that the client makes a socket connection to the D-Bus daemon, which makes the access control decision based on the <NUM>) credentials assigned to the client, <NUM>) D-Bus policy, and if the access is approved, the D-Bus daemon makes a socket connection to the server.

For completeness, <FIG> shows a case where an application makes access control decision by itself. For example, assume that a certain application (application server <NUM>) provides a database <NUM> for other applications. The database <NUM> is stored in a file system, and only the application server <NUM> can access this file. This can be done, for example, by specifying the permissions of the file in a conventional UNIX way (for example, by setting the file to be readable and writable only by the owner). In order to make an access control decision, the application server <NUM> needs to have a reliable way of obtaining the credentials of another application (application client <NUM>) that wants to access the database <NUM>. This is accommodated by providing a credentials library (libcred) <NUM>, which provides the ability for the application client <NUM> to obtain the needed information from the application server <NUM>. In <FIG> it is assumed that the application client is launched as described previously (shown at 8A). At 8B the application client <NUM> makes a read request for database information from the application server <NUM>. At 8C the application server <NUM> accesses the library <NUM> to obtain the credentials of the application client <NUM>, and makes a decision of whether to grant access to the database <NUM>. *D indicates the actions for the case where access is granted or access is denied.

<FIG> is a logic flow diagram that illustrates various hardware enables and a boot process (operation of a boot loaded), according to one embodiment of the invention. <FIG> assumes a presence of a TrEE (for example the presence of an ARM® Trust Zone) with two main keys: a root public key, and a root device specific key. In 9A the boot ROM integrity is checked. If the integrity is not verified a reset operation occurs (9B) and processing is halted. If the boot ROM integrity is verified the loader integrity is checked (9C). If the integrity is verified a signed SW image is assumed to be present (9D) and can be executed. If the integrity is not verified a check is made at 9E to determine if the device <NUM> is SIM locked (or, more descriptively, to determine if there is a policy in place to prevent access to certain non-approved applications). If this is the case the reset branch is taken (9F), and a requested application is not loaded/executed. If the device <NUM> is not SIM locked, then in accordance with the exemplary embodiments of this invention certain security functionality is restricted (<NUM>). The restriction of the security functionality is implemented by the TrEE and can include disabling certain DRM keys, and preventing content from a previous mode from being decrypted. The unsigned SW image is then loaded and executed (<NUM>) without any restriction on what the SW image can do once it is executed. The only restrictions on the device are those posed by the restricted security functionality provided by the TrEE.

One technical effect of this boot process is to control what gets booted and how, and allowing the bootup of the application's own kernels in a normally closed platform by removing threats that in the past have made it insecure to use applications having their own kernels. This is enabled in an embodiment by making the decision to boot an unknown kernel conditional on the policy and status information, which in the example embodiment the status information is the SIM-lock information. This conditional boot can be overridden by using an operator unlock code, which in an embodiment may be automatically overridden after passage of a preset period of time (e.g., <NUM> years). Note that disabling certain functionality while booting is not the same as 'secure booting' in which there is no boot whatsoever if the signature fails. It is a 'trusted boot' in which the boot does take place, though restricted because of the information e.g., the TrEE which in e.g., a remote attestation case leads to blocking (such as for example blocking network access to a VPN framework).

<FIG> shows the operation of integrity protection using a validator function <NUM> further in accordance with the exemplary embodiments of this invention. The validator function <NUM> ensures the integrity of the executable components (e.g., binaries and libraries) at run time, and in response to offline attacks. The validator function <NUM> can be a module of the kernel <NUM>, and it operates to calculate a cryptographic hash of a file (e.g., by using SHA-<NUM>). Reference hashes are stored in protected storage <NUM>, and are used to bind an application identity (pathname) to an executable file. When a new application is presented, the validator function <NUM> calculates the reference hash of the application, signs it using a validator private key, and stores it in the storage <NUM>. Before the application is run the signed reference hash is retrieved from the storage <NUM>, the validator function <NUM> calculates the hash of the application binary <NUM> and compares the result to the reference hash retrieved from the protected storage <NUM>. If an integrity protection violation is detected (e.g., the component has been modified) then some action is executed. This action depends on an integrity protection policy <NUM> of the device. Typically loading of the modified component is prevented, but there are also other options available such as stripping all additional privileges from the process, or more simply just logging the violation. If the hashes match the application is authorized for execution, otherwise the application may be denied execution.

This approach is superior to the traditional approach to OS integrity protection, where the entire firmware image is signed and the entire image is verified during boot. However, a firmware image contains both read-only and writable files, and the firmware image is updated by installing new packages as opposed to installing a new image. For at least these reasons the load-time integrity protection approach is preferred. As opposed to verifying the entire firmware image once, only those components that will be executed are verified during code loading. The verification status of the object is cached so that files need be verified only once after each boot. Any file modification attempts are detectable by using Linux security module hooks (LSM).

One technical effect of the integrity protection framework is that it creates a basis for building a trusted environment, where the entity/company responsible for the behavior of its consumer electronics can make any guarantees about the availability of services that a device/hardware is to deliver (e.g., emergency phone calls). A simple digital signature protection framework is not as dynamic, is not flexible, and provides no connection to the access control policies. The integrity protection framework disclosed herein (e.g., the Aegis validator) stores, for each binary, hashes with source identifiers that can be mapped to the rights a particular source has. In an embodiment the integrity protection framework can also use a local digital signature with secure extension environment secret keys to sign the storage of reference hashes.

Referring also to <FIG>, the validator <NUM> kernel module hooks all application and shared library load attempts. A file object <NUM> is identified by an inode structure. The inode number is used as a key to the hash store (<NUM> in <FIG>) to request a reference hash value of the inode. The validator <NUM> recalculates the hash value and, if there is a match, the inode number is stored in the verification cache <NUM>. If the calculated hash value does not match the next action depends on the integrity protection policy <NUM>. The hash store <NUM> is initialized in system boot using reference hashlist file, which contains pathname - cryptographic hash pairs. Pathname - cryptographic hash pairs are translated into inode - cryptographic hash pairs. The original store is integrity protected using either RSA signature (initial file) or a locally signed HMAC mechanism (local updates). There may be only one reference hashlist file, although this may be extended to have one reference hashlist file per filesystem, and tie the loading of the hashlist file to a filesystem mount event.

<FIG> shows the operation of privacy protection using the protected storage <NUM> shown in <FIG>, according to one embodiment. The embodiment ensures the integrity of data and configuration files (stored in the protected storage <NUM>) after installation. Additional features include data encryption within the protected storage <NUM>, and the use of private, shared and global or externally signed storages. There is an interface to the TrEE, which is used to sign/verify, encrypt/decrypt the data. Access to a protected storage is defined by an application identifier or application group.

One technical effect of the policy protection framework is that it enables the access control decision to be dynamically bound from any application to any interface in the device. This creates a robust and attack resistant platform where the 'least privileges' principle occurs, e.g., where applications can access only what they need. For example, DRM may be accomplished by creating a resource token termed "DRM" and granting that token only to selected applications coming from the operator's SW repository. Services possessing DRM confidential information (e.g., secret content keys) will only communicate applications having that "DRM" resource token.

Also, embodiments of the policy protection framework use dynamic mappings that are created in the installation time from an abstract declaration in the application package. In an embodiment the host device itself creates and maintains a locally unique mapping from resource tokens to user identifiers UIDs and group identifiers GIDs. Creating such new tokens on the fly when installing new SW is not seen in the prior art, nor is binding them to the source of the applications. Additionally, in an embodiment a limited-access-service can be created without support from the device operator/manufacturer.

<FIG> presents a non-limiting example of a security policy file, according to one embodiment. <FIG> shows a non-limiting AC control example showing a manifest file for a server and for a client (the latter giving permission for a token server), according to one embodiment. <FIG>, <FIG> and <FIG> provide a non-limiting example for the D-Bus server 20B and D-Bus client 20A (e.g., refer again to <FIG>), specifically a manifest file for the D-Bus server 20B, a manifest file for the D-Bus client 20A, and a D-Bus configuration file, respectively, according to one embodiment of the invention. The references to "Aegis" in these Figures, and elsewhere in the description, may be read as being descriptive of a name of the overall security architecture provided by the exemplary embodiments of this invention.

<FIG> illustrates an exemplary device <NUM> in both plan view (left) and sectional view (right), and the invention may be embodied in one or some combination of the illustrated function-specific components. In <FIG> the device <NUM> has a graphical display interface <NUM> and a user interface <NUM> illustrated as a keypad but understood as also encompassing touch-screen technology at the graphical display interface <NUM> and voice-recognition technology received at the microphone <NUM>. A power actuator <NUM> controls the device being turned on and off by the user. The exemplary device <NUM> may have a camera <NUM> which is shown as being forward facing (e.g., for video calls) but may alternatively or additionally be rearward facing (e.g., for capturing images and video for local storage). The camera <NUM> is controlled by a shutter actuator <NUM> and optionally by a zoom actuator <NUM>.

Within the sectional view of <FIG> are seen multiple transmit/receive antennas <NUM> that are typically used for cellular communication. The antennas <NUM> may be multi-band antennas. A power chip <NUM> controls power amplification on the channels being transmitted and/or across the antennas that transmit simultaneously where spatial diversity is used, and amplifies the received signals. The power chip <NUM> outputs the amplified received signal to the radio-frequency (RF) chip <NUM> which demodulates and downconverts the signal for baseband processing. The baseband (BB) chip <NUM> detects the signal which is then converted to a bit-stream and finally decoded. Similar processing occurs in reverse for signals generated in the device <NUM> and transmitted from it.

Signals going to and from the camera <NUM> pass through an image/video processor <NUM> which encodes and decodes the various image frames. A separate audio processor <NUM> may also be present controlling signals to and from the speakers <NUM> and the microphone <NUM>. The graphical display interface <NUM> is refreshed from a frame memory <NUM> as controlled by a user interface chip <NUM> which may process signals to and from the display interface <NUM> and/or additionally process user inputs from the keypad <NUM> and elsewhere.

Certain embodiments of the device <NUM> may also include one or more secondary radios such as a wireless local area network radio WLAN <NUM> and a Bluetooth® radio <NUM>, which may incorporate an antenna on-chip or be coupled to an off-chip antenna.

Throughout the apparatus are various memories such as random access memory RAM <NUM>, read only memory ROM <NUM>, and in some embodiments there may be removable memory such as the illustrated memory card <NUM>. Various programs 110C are stored in one or more of the memories. The programs 110C include software that is configured to operate, in cooperation with at least one of the data processors, in accordance with the various embodiments of this invention that were described above. The programs 110C are assumed to include a suitable operating system, such as Linux, and are configured to implement the user mode <NUM> and the kernel mode <NUM> functionalities described above. The various applications may be downloaded from the source <NUM> via wireless communication, or downloaded via a wire to the device <NUM>.

All of these components within the device <NUM> are normally powered by a portable power supply such as a battery <NUM>.

The aforesaid processors <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, if embodied as separate entities in the device <NUM>, may operate in a slave relationship to the main processor 110A which may then be in a master relationship to them. Any or all of these various processors of <FIG> access one or more of the various memories, which may be on-chip with the processor or separate from the processor.

Note that the various chips (e.g., <NUM>, <NUM>, <NUM>, etc.) that were described above may be combined into a fewer number than described and, in a most compact case, may all be embodied physically within a single chip.

The various embodiments of the device <NUM> can include, but are not limited to, cellular phones, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions. Note that is some embodiments the device <NUM> may not include wireless communication capabilities, or at least may not include cellular radio communication capabilities.

Based on the foregoing it should be apparent that the exemplary embodiments of this invention provide a method, apparatus and computer program product(s) to provide an enhanced security architecture for a user device.

In accordance with first exemplary embodiments of this invention, and referring to <FIG>, a method comprises receiving from a source a package comprising a binary file representing an application software and an associated resource declaration indicating resources required by the software application (Block 16A). The method further comprises extracting the resource declarations from the package (Block 16B), and forming an intersection of the extracted resource declarations and a set of allowable resources, for the source of the package, obtained from a software sources ranking and resources usage policy (Block 16C). The method further comprises granting the application software resources based on the result of the formed intersection (Block 16D), installing the application software (Block 16E), and storing an indication of the granted resources in a resource possession list (Block 16F).

In accordance with further exemplary embodiments of this invention, and referring to <FIG>, a method comprises (at Block 17A) initiating an application software execution by calling a process credentials assigner to make a look-up in the resource possession list for the software application, (Block 17B) assigning corresponding process credentials according to a set of allowed resources for the software application; (Block 17C) transferring control to the software application and (in Block 17D), in response to a request by the application software to access a system object, making an access control decision based on assigned process credentials and an access control list associated with the system object.

In accordance with further exemplary embodiments of this invention, and referring to <FIG>, a method comprises (at Block 18A) calculating a cryptographic hash of an executable and, at Block 18B, signing the cryptographic hash and storing a resulting reference signed cryptographic hash in a protected storage. The method further comprises, prior to executing the executable, calculating the cryptographic hash of the executable (Block 18C), and comparing a result to the reference cryptographic hash retrieved from the protected storage (Block 18D). If an integrity protection violation is detected, the method further comprises taking some action depending on an integrity protection policy (Block 18E).

The various blocks shown in <FIG>, <FIG> and <FIG> may be viewed as method steps, and/or as operations that result from operation of computer program code, and/or as a plurality of coupled logic circuit elements constructed to carry out the associated function(s).

In accordance with an exemplary aspect of the invention there is at least a method, apparatus, and executable computer program to perform actions comprising comprising receiving, at a device, from a source a package comprising a binary file representing an application software and an associated resource declaration indicating resources required by the application software, extracting the resource declaration from the package, forming an intersection of the extracted resource declaration and a set of allowable resources, for the source of the package, obtained from a software sources ranking and resources usage policy, granting the application software resources based on the result of the formed intersection, installing the application software, and storing an indication of the granted resources in a resource possession list.

Further, in accordance with the paragraph above, the resource possession list defines which resources are allowed to be accessed by the application software, and wherein the resource possession list comprises a mapping between an application identifier of the application software and the allowed resources.

In addition, in accordance with the paragraph above, the application identifier uniquely identifies an application, and wherein the application identifier remains unchanged at least between bootups, for different instances of a same application, and after an application restart.

Wherein, in accordance with the two paragraphs above, the application identifier is represented by AppID = {SourceID, PackageName, AppName}, wherein the SourceID is a unique identifier of an application source, wherein the PackageName is a package name without a version number, and wherein the AppName is defined by an application developer.

Further, in accordance with any of the paragraphs above, there is storing, for the binary file, a cryptographic hash with source identifiers of the binary file that are mapped to rights of the source, wherein a storage of the cryptographic hash is signed using a local digital signature with secret key.

In addition, in accordance with any of the paragraphs above, there is modifying a bus policy file for the application software, wherein the bus policy file provides access control rights for the application software to communicate with other resources.

Additionally, in accordance with any of the paragraphs above, there is initiating an execution of the application software comprising accessing the resource possession list, assigning corresponding process credentials according to allowed resources for the application software defined in the resource possession list, transferring control to the application software, and executing the application software.

Further, in accordance with the paragraph above, there is, in response to a request by the application software to access a system object, determining access control of the application software based on the assigned process credentials and an access control list associated with the system object.

Further, in accordance with any of the paragraphs above, there is creating a resource token, and granting the resource token to only selected application software coming from a software repository associated with at least one operator of the device.

In addition, in accordance with the paragraph above, there is maintaining, on the device, a locally unique mapping between the resource token and identities of the at least one operator of the device, wherein the locally unique mapping enables an access control decision to be dynamically bound from the selected application software to an interface of the device, wherein services processing the resource token will only communicate with applications which have been granted the resource token.

In accordance with the exemplary embodiments of the invention, there is at least a method, apparatus, and an executable computer program for performing calculating, at a device, a cryptographic hash of an executable, signing the cryptographic hash, and storing a resulting reference signed cryptographic hash in a protected storage, prior to executing the executable, calculating the cryptographic hash of the executable, and comparing a result to the reference cryptographic hash retrieved from the protected storage.

Further, in accordance with the paragraph above, if the result and the reference cryptographic hash match, then there is executing the executable.

Further, in accordance with the paragraphs above, if an integrity protection violation is detected, taking an action depending on an integrity protection policy.

In addition, in accordance with the paragraphs above, wherein the action comprises at least one of preventing loading of the executable, stripping additional privileges from the executable, and logging the violation.

In accordance with the exemplary embodiments of the invention, there is at least a method, apparatus, and an executable computer program for performing verifying, during a boot process, an integrity of an application kernel on a device, wherein verifying the integrity comprises verifying an integrity of a boot read only memory of the device, based on a verified boot read only memory, verifying a loader integrity of the device, wherein the loader integrity verification indicates a signed software image for the application kernel is present, and for the case that the loader integrity is not verified, then determining if there is a policy in place to prevent access to the application kernel, wherein if there is no policy in place to prevent access to the application kernel, then restricting a security functionality of the device and booting the device with the restricted functionality.

Further, in accordance with the paragraph above, if the integrity of a boot read only memory is not verified, there is performing a reset operation of the device.

Further, in accordance with the paragraphs above, the restricting comprises at least one of disabling certain digital rights management keys, and preventing certain content from being decrypted, and executing the application kernel with the restricted security functionality.

Additionally, in accordance with the paragraphs above, if the loader integrity is not verified, determining if a subscriber identity module of the device is locked, wherein for the case the subscriber identity module is locked, then performing a reset operation of the device, and wherein for the case that the subscriber identity module is not locked, then restricting a security functionality of the device, wherein the restricting comprises at least one of disabling certain digital rights management keys, and preventing certain content from being decrypted, and executing the application kernel with the restricted security functionality.

While various aspects of the exemplary embodiments of this invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

It should be appreciated that at least some aspects of the exemplary embodiments of the inventions may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this invention may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this invention. Further, it is noted that, in accordance with the exemplary embodiments, the terms application software and software application are non-limiting and can be used interchangeably.

Various modifications and adaptations to the foregoing exemplary embodiments of this invention may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of this invention. For example, the use of these exemplary embodiments is not limited to only one type of operating system, such as Linux. Further, the user devices that may benefit from these exemplary embodiments are not limited to handheld or portable devices, but may include as well desktop computers and workstations, as well as servers and mainframe computers, as non-limiting examples.

It should be noted that the terms "connected," "coupled," or any variant thereof, mean any connection or coupling, either direct or indirect, between two or more elements, and may encompass the presence of one or more intermediate elements between two elements that are "connected" or "coupled" together. The coupling or connection between the elements can be physical, logical, or a combination thereof. As employed herein two elements may be considered to be "connected" or "coupled" together by the use of one or more wires, cables and/or printed electrical connections, as well as by the use of electromagnetic energy, such as electromagnetic energy having wavelengths in the radio frequency region, the microwave region and the optical (both visible and invisible) region, as several non-limiting and non-exhaustive examples.

Claim 1:
A method, comprising:
verifying, during a boot process, an integrity of an application kernel on a device, wherein verifying the integrity comprises verifying an integrity of a boot read only memory of the device; and
based on a verified boot read only memory, verifying a loader integrity of the device, wherein the loader integrity verification indicates a signed software image for the application kernel is present, and wherein for the case that the loader integrity is not verified, the method further comprising:
determining if there is a policy in place to prevent access to the application kernel, and based on determining there is no policy in place, restricting a security functionality of the device, and booting the device with the restricted functionality, or else for the case there is a policy in place, performing a reset operation of the device.