Patent Description:
Modern computing devices are used for a wide variety of purposes, many of which involve data that is private, proprietary or sensitive to the user or to other entities. For example, devices such as smart phones are often used to store financial data such as account numbers, payment credentials, biometric data such as fingerprints, PINs and passwords. In addition, computing devices commonly store encryption keys and the like, for example, for secure communication and document storage or for playback of copy-protected media. Such data is valuable to users and to other entities such as software developers, enterprises, financial institutions and media owners and publishers.

Protection of sensitive data (in particular, against unauthorized access to such data) is important. Allowing for fast and convenient access to data for legitimate purposes by both users and software developers is also important for providing a broad feature set of devices.

It is becoming increasingly common for devices to be used in multiple modes. For example, computing devices may be used in portable or handheld modes and in desktop modes. Different sets of functionality and different user interfaces may be desired in each mode. In addition, users may use a single device for both personal and professional purposes. Enterprises may wish to segregate data from personal data of employees, and employees may likewise wish to maintain separation for privacy reasons. <CIT> discloses an electronic device including a plurality of execution environments for providing an electronic payment function. <CIT> discloses an on-demand disposable virtual work system designed to eliminate most internet-enabled compromises of computer system security. <CIT> discloses a multi-level security system to satisfy the need for MLS systems with high availability capabilities.

Embodiments not falling within the scope of the claims are exemplary. An example computing device comprises: a processor configured to provide: a first operating system with access to a first memory; and a second operating system with access to a second memory and hosting a plurality of containers providing separate execution environments, each of said plurality of containers having secure computing resources; a software module executable within said second operating system for receiving access requests from applications in said first operating system and selectively passing said requests to said secure computing resources based on container access rules.

In some embodiments, the first operating system hosts a plurality of containers providing separate execution environments, each said container of said first operating system corresponding to a container of said second operating system.

In some embodiments, the container access rules comprise a concordance between said containers of said first operating system and said containers of said second operating system.

In some embodiments, the computing device comprises a software module executable in said first operating system for generating access requests each including a value identifying a container from which the access request originated.

In some embodiments, the access rules depend on said value identifying a container from which the access request originated.

In some embodiments, the secure computing resources may comprise trusted applications in said containers of said second operating system.

In some embodiments, first and second containers of said second operating system have respective instances of a trusted application.

In some embodiments, the access requests comprise requests for return of secure data.

In some embodiments, the access requests comprise requests to perform operations using said secure computing resources.

In some embodiments, the first operating system defines a rich execution environment and said second operating system defines a trusted execution environment, each as defined by the Global Platform TEE system architecture.

Computing devices disclosed herein may include the above features in any combination.

An example method of access control occurs on a computing device comprising a first operating system and a second operating system hosting a plurality of containers providing separate execution environments and each having secure computing resources. The method comprises: sending a request from a first software module in said first operating system to said second operating system, said request directed to a secure computing resource in a targeted one of said containers; in a second software module in said second operating system: receiving said request; evaluating said request according to access rules for said one of said containers; and selectively passing said request to said secure computing resource based on said access rules.

In some embodiments, the first operating system hosts a plurality of containers providing separate execution environments, and said request is sent from one of said containers of said first operating system.

In some embodiments, the method comprises, in said first software module, receiving said request from an application in one of said containers of said first operating system, and passing said request to said second operating system with a value identifying said one of said containers.

In some embodiments, the evaluating said request comprises checking an identifier of said targeted container against a list of containers hosted at said second operating system.

In some embodiments, the evaluating said request comprises checking a concordance between said containers of said first operating system and said containers of said second operating system.

In some embodiments, the evaluating said request comprises checking an identifier of said secure resources against a list of resources in said targeted container.

In some embodiments, the secure computing resources comprise trusted applications in said containers of said second operating system.

Methods disclosed herein may include the above features in any combination.

An example computer-readable medium has instructions thereon for execution by a processor, said instructions comprising: a first software module for sending a request from a first software module in a first operating system to a second operating system, said request directed to a secure computing resource in a container hosted by the second operating system; a second software module for execution in said second operating system, for: receiving said request; evaluating said request according to access rules for said container; and selectively passing said request to said secure computing resource based on said access rules.

In the figures, which depict example embodiments:.

<FIG> is a schematic diagram of an example computing device <NUM>. Computing device <NUM> may be, for example, a smart phone, tablet computer, personal computer such as a notebook computer, wearable computing device or the like.

As will be described in further detail, computing device <NUM> has hardware and software resources divided into multiple execution environments. One execution environment has elevated access restrictions and is used for secure storage and processing of some computing resources, which may be referred to as secure computing resources.

Computing device <NUM> includes a processor <NUM>, memory <NUM>, storage <NUM>, one or more input/output (I/O) devices <NUM>, and at least one network interface <NUM>. Components of computing device <NUM> are formed in one or more semiconductor chips, mounted to a printed circuit board for communication between components. In some embodiments, multiple components, e.g. processor <NUM> and network interface <NUM> are incorporated in a single semiconductor chip, referred to as a system-on-chip. In other embodiments, each component is a discrete chip.

Processor <NUM> is any suitable type of processor, such as a processor implementing an ARM or x86 instruction set.

Memory <NUM> is any suitable type of random-access memory accessible by processor <NUM>. Memory <NUM> includes a secure memory <NUM>. In some embodiments, secure memory <NUM> is a discrete physical module. In other embodiments, memory <NUM> is segmented to define secure memory within the same physical module as other memory. In some embodiments, secure memory <NUM> occupies a range of memory addresses within the address space of memory <NUM>. In some embodiments, secure memory <NUM> is accessible by processor <NUM> within a different memory space.

Storage <NUM> may be, for example, one or more modules of NAND flash memory of suitable capacity, or may be one or more hard drives or other persistent computer storage device. Storage <NUM> includes a secure storage <NUM>. In some embodiments, secure storage <NUM> resides on a device shared with other storage <NUM>. In other embodiments, secure storage <NUM> resides on a discrete hard drive, flash storage module or the like.

I/O devices <NUM> include, for example, user interface devices such as a screen, such as a capacitive or other touch-sensitive screen capable of displaying rendered images as output and receiving input in the form of touches. In some embodiments, I/O devices <NUM> additionally or alternatively includes one or more of speakers, microphones, sensors such as accelerometers and global positioning system (GPS) receivers, keypads or the like. In some embodiments, I/O devices <NUM> include ports for connecting computing device <NUM> to other computing devices. In an example, I/O devices <NUM> include a universal serial bus (USB) controller for connection to peripherals or to host computing devices.

Network interface <NUM> is capable of connecting computing device <NUM> to one or more communication networks. In some embodiments, network interface <NUM> includes one or more wireless radios, such as Wi-Fi or cellular (e.g. GPRS, GSM, EDGE, CDMA, LTE or the like).

Computing device <NUM> operates under control of software programs. Computer-readable instructions are stored in storage <NUM> or secure storage <NUM>, and executed by processor <NUM> in memory <NUM> or secure memory <NUM>.

<FIG> is a schematic block diagram showing organization of software at computing device <NUM>. As depicted, computing device <NUM> has two separate executing environments provided by operating systems <NUM>-<NUM>, <NUM>-<NUM> (individually and collectively, operating systems <NUM>). Operating system <NUM>-<NUM> has access to resources in memory <NUM> and storage <NUM> (<FIG>) and operating system <NUM>-<NUM> has access to secure memory <NUM> and secure storage <NUM>. In the depicted embodiment, processor <NUM> is configured with logic for maintaining separation between the executing environments provided by operating systems <NUM>-<NUM>, <NUM>-<NUM>. In an example, processor <NUM> includes one or more ARM Cortex-A ™ cores and includes TrustZone™ technology with secure monitor logic for switching between executing environments. Other implementations are possible. As noted, secure memory <NUM> may be located in a separate physical memory module from memory <NUM>. Alternatively or additionally, secure memory <NUM> may be accessible in a different address space or in a different address range. Likewise, secure storage <NUM> may be located in a separate physical memory device or in a different partition or sector of storage <NUM>.

In an example, operating system <NUM>-<NUM> is a rich operating system capable of providing multiple discrete execution environments in containers <NUM>. As depicted, two containers <NUM>-<NUM> and <NUM>-<NUM> are present within operating system <NUM>-<NUM>. However, any number of containers <NUM> may be present.

Each container <NUM> corresponds to an instance of an operating system, which may be a virtualized operating system hosted within operating system <NUM>-<NUM>. A kernel <NUM>-<NUM> of operating system <NUM>-<NUM> provides software within each container with access to hardware of computing device <NUM>. The operating systems within containers <NUM> may be operating systems of the same or similar type as operating system <NUM>-<NUM>. In an example embodiment, operating system <NUM>-<NUM> is a version of Linux and the operating systems in containers <NUM>-<NUM>, <NUM>-<NUM> are versions of Android or other Linux-based operating systems. In other embodiments, one or more of operating system <NUM>-<NUM> and the operating systems in containers <NUM>-<NUM>, <NUM>-<NUM> are other types of operating systems, such as Microsoft Windows or Apple OS X or iOS. Operating system <NUM>-<NUM> may include a translation or emulation layer.

Containers <NUM>-<NUM>, <NUM>-<NUM> provide separated execution environments. In an example, container <NUM>-<NUM> hosts an operating system for personal use and container <NUM>-<NUM> hosts an operating system for professional use.

Each container <NUM> hosts one or more client applications <NUM>. Client applications <NUM> are installable by users, for example, by execution of application packages. Application packages may be retrieved from software repositories or stores, such as the Google Play Store for Android applications, the Apple App Store for iOS applications, the Windows store for Windows applications, and various repositories for applications on distributions of Linux-based operating systems. Alternatively, applications may be obtained and installed from other sources.

Application packages, particularly those distributed through software stores or repositories, typically adhere to standardized formats. Application packages can contain, among others, human or computer-readable code, compiled binaries, application resources such as databases, and metadata identifying properties such as the application name, publisher, compatible file types and the like. For example, Android applications distributed through the Google Play Store are provided in compressed, digitally-signed. apk packages, which include a unique application ID, e.g. "com.

Containers <NUM>-<NUM>, <NUM>-<NUM> segregate their respective client applications <NUM> from one another. That is, client applications <NUM> in container <NUM>-<NUM> cannot directly access data associated with container <NUM>-<NUM> and vice-versa. Thus, for example, data associated with an email client application <NUM> in container <NUM>-<NUM> cannot be accessed by any application in container <NUM>-<NUM>.

Operating system <NUM>-<NUM> hosts one or more trusted applications <NUM>. Trusted applications <NUM> are installed in secure storage <NUM>. Operating system <NUM>-<NUM> is configured so that trusted applications <NUM> cannot be installed by users without providing credentials for elevated permissions. In an example, secure storage <NUM> is not writable by end users. Rather, secure storage <NUM> can be modified only by system-level processes or applications, e.g. as part of updates issued by the manufacturer of computing device <NUM>, or by certain specific digitally signed application packages. Trusted applications <NUM> are therefore "trusted" in the sense that the installation process ensures that they are verified as legitimate applications from authorized sources.

Each trusted application <NUM> has access to secure data. For at least some functions, client applications <NUM> rely on such data. Client applications are therefore able to send requests to trusted applications <NUM>, e.g. for secure data to be returned, or for operations to be performed using secure data.

Sharing of information between trusted applications <NUM> and client applications <NUM> is based on rules defining requirements for secure computing resources, such as access to trusted applications <NUM> or data stored by trusted applications <NUM>, to be shared with a client application <NUM>.

Because client applications <NUM> are user-installable, they might not be subject to the same degree of verification prior to installation as trusted applications <NUM>. Accordingly, it is possible for client applications <NUM> to be installed that are malicious, coded without proper protection of secure data, or associated with entities that are not authorized to access secure data. The term "trust model" refers to protective measures that are taken to guard against access except by authorized applications and users.

Client applications <NUM> in both of containers <NUM>-<NUM> and <NUM>-<NUM> may require access to secure data for some functions. Accordingly, client applications <NUM> in both containers are provided with the ability to request access to data associated with trusted applications <NUM> or to request performance of operations by trusted applications <NUM>. However, just as software in containers <NUM>-<NUM> and <NUM>-<NUM> cannot access one another's data, it may likewise be desired to prevent access by software in container <NUM>-<NUM> to secure data and operations for container <NUM>-<NUM> and vice-versa. For example, it may be desired to prevent access to enterprise communication data by personal applications, and to prevent access to personal payment data by enterprise applications.

In order to prevent leakage of personal data to enterprise applications and vice-versa, computing device <NUM> is configured so that access to trusted applications <NUM> and their secure data is controlled based on container and client application.

<FIG> depicts an example mechanism for permitting controlled access to secure data, for example, exchanging or sharing data between client applications <NUM> and trusted applications <NUM>. As shown, personal-use container <NUM>-<NUM> hosts a client application <NUM>-<NUM> for financial payments and professional use container <NUM>-<NUM> hosts a client application <NUM>-<NUM> for encrypted access to enterprise resources, such as email, documents or the like. Client application <NUM>-<NUM> has associated payment credential information stored by a trusted application <NUM>-<NUM> in operating system <NUM>-<NUM>, namely a credential storage utility. Client application <NUM>-<NUM> has associated encryption/decryption key information stored by a trusted application <NUM>-<NUM> in operating system <NUM>-<NUM>, namely an encryption/decryption utility. Trusted application <NUM>-<NUM> has access to a data structure (e.g. a database) of financial account information or credentials. Trusted application <NUM>-<NUM> has access to a data structure (e.g. a database) of encryption keys for encrypting and decrypting data such as communications and documents.

Each of trusted application <NUM>-<NUM> and trusted application <NUM>-<NUM> is configured to receive requests from client applications <NUM> in containers <NUM>. Trusted applications <NUM>-<NUM>, <NUM>-<NUM> are further configured to perform permissions checks in response to receiving such requests. The security checks are configured in view of the type of information stored by each trusted application <NUM>. Specifically, in some embodiments, trusted application <NUM>-<NUM> stores credentials belonging to multiple users and associated with a specific client application <NUM> in container <NUM>-<NUM>. In order to confirm that a request for credentials is authorized, trusted application <NUM>-<NUM> is configured to check the name of the requesting application and the user id of the user making the request. Accordingly, in order to make a request intended for trusted application <NUM>-<NUM>, client application <NUM>-<NUM> is configured to construct a message <NUM> containing its application ID, "com. app1", the user ID of the active user and one or more parameters defining the request. In contrast, trusted application <NUM>-<NUM> stores encryption keys associated with specific content, rather than any particular user. Accordingly, to confirm that a request is authorized, trusted application <NUM>-<NUM> might check only the application ID of the client application making the request. Therefore, in order to request secure data from trusted application <NUM>-<NUM>, client application <NUM>-<NUM> constructs a message <NUM> containing its application ID, "com.

Unfortunately, access management by individual trusted applications in this manner has disadvantages. For example, each trusted application <NUM> needs to be configured to receive some credentials from client applications <NUM>. The credentials required by any given trusted application <NUM>, or the format in which they are required, may vary. Accordingly, developers of client applications <NUM> would need to customize client applications <NUM> in view of the configuration of each trusted application <NUM>. Moreover, changes to any trusted application <NUM> would need to be reflected in any client applications <NUM> requiring access to the trusted application's data.

In addition, each trusted application <NUM> might need to maintain an up-to-date record of all authorized client applications <NUM>, e.g. based on application names or IDs. Maintaining such records may be burdensome. Application names and application IDs are publicly accessible - for example, such information can be extracted from some types of application packages and could therefore be forged by malicious client applications <NUM>, making secure data vulnerable to unauthorized access. Moreover, trusted applications <NUM> cannot control access based on containers <NUM> unless they are explicitly made aware of containers <NUM>. Such a configuration may be difficult to implement by developers of trusted applications <NUM> because the arrangement of containers <NUM> varies from device to device. Conversely, controlling access based only on client applications <NUM> invites problems of data leakage. For example, a trusted application <NUM> may not be able to differentiate between duplicate instances of a specific client application <NUM> in containers <NUM>-<NUM>, <NUM>-<NUM>.

Data leakage is also possible between trusted applications <NUM> stored on secure storage <NUM> and operating in secure memory <NUM>. For example, leakage can occur between applications in the same storage and memory space.

<FIG> depicts an embodiment in which operating system <NUM>-<NUM> has secure containers <NUM>-<NUM>, <NUM>-<NUM> (individually and collectively, secure containers <NUM>). Each container hosts an instance of an operating system. Operating systems in secure containers <NUM> are secure operating systems, configured to utilize secure execution technology provided by processor <NUM>.

Secure containers <NUM>-<NUM>, <NUM>-<NUM> and their respective trusted applications are stored in different sections of secure storage <NUM> and operate in different sections of secure memory <NUM>. In some embodiments, the separate sections are defined by different address ranges or different address spaces. In other embodiments, the sections of secure storage <NUM> and secure memory <NUM> are defined by discrete storage devices.

Secure containers <NUM>-<NUM>, <NUM>-<NUM> segregate their respective trusted applications <NUM>. Secure container <NUM>-<NUM> hosts a first set of trusted applications <NUM> and secure container <NUM>-<NUM> hosts a second set of trusted applications <NUM>.

Individual secure containers <NUM> correspond to individual containers <NUM>. That is, each secure container <NUM> contains secure data and trusted applications <NUM> for use by client applications of a counterpart container <NUM>. For example, in the depicted embodiment, secure container <NUM>-<NUM> and its trusted applications <NUM> correspond to personal use container <NUM>-<NUM> and its client applications <NUM>. Secure container <NUM>-<NUM> and its trusted applications <NUM> correspond to professional use container <NUM>-<NUM> and its client applications <NUM>. As described in further detail hereinafter, client applications <NUM> within a particular container <NUM> are only able to access trusted applications <NUM> in the corresponding secure container <NUM>.

One or both of operating systems <NUM>-<NUM>, <NUM>-<NUM> maintains a data structure <NUM> defining concordance between containers <NUM> and corresponding secure containers <NUM>. <FIG> depicts an example data structure <NUM>. In some embodiments, the concordance defined by data structure <NUM> is also used as a set of access rules for accessing secure computing resources in containers <NUM>.

In the embodiment of <FIG>, control of access to secure data is managed by discrete software modules within operating systems <NUM>-<NUM>, <NUM>-<NUM>, rather than individual trusted applications <NUM>. Such components allow for standardization of functions for requesting secure data and for enforcing access rules. In addition, such components allow for access credentials to be created and maintained internally at computing device <NUM>, such that access control need not rely on publicly-available and easily forged information.

In particular, operating system <NUM>-<NUM> further includes an access control library <NUM> such as an application programming interface (API), which provides a set of functions for receiving requests from client applications <NUM> in containers <NUM> for accessing secure data from trusted applications <NUM> or for performance of operations by trusted applications <NUM> using secure data. Client applications <NUM> can invoke functions provided by access control library <NUM> by constructing requests including parameters such as an identifier of a trusted application <NUM>, an identifier of a function to be performed by the trusted application <NUM>, and other parameters required for authorization or for performance of the function by trusted application <NUM>.

Access control driver <NUM> and secure access manager <NUM> have access to data structures <NUM>, <NUM> (<FIG>, <FIG>) cataloguing the client applications <NUM> installed within containers in operating system <NUM>-<NUM> and trusted applications <NUM> installed within containers in operating system <NUM>-<NUM>. Data structures <NUM>, <NUM> may be maintained by access control driver <NUM> and secure access manager <NUM>, respectively. Alternatively, data structures <NUM>, <NUM> may be maintained by other components of operating systems <NUM>-<NUM>, <NUM>-<NUM>, respectively.

<FIG> depict an example data structure <NUM> cataloguing client applications <NUM>. As shown in <FIG>, data structure <NUM> contains a container table <NUM> with entries corresponding to each container <NUM> hosted at operating system <NUM>-<NUM>. The entries have pointers <NUM> identifying application tables <NUM>. Each application table <NUM> contains a list of client applications <NUM> in a particular container <NUM> and parameters associated with each client application <NUM>. As depicted, container table <NUM> has entries for M containers <NUM>-<NUM> through <NUM>-M. Each container has a corresponding application table <NUM>. Container <NUM>-<NUM> has N client applications <NUM>-<NUM> through <NUM>-N. Container <NUM>-<NUM> has P client applications <NUM>-i through <NUM>-P. Container <NUM>-M has Q client applications <NUM>-<NUM> through <NUM>-Q.

<FIG> depicts an example client application table <NUM>. As shown, client application table <NUM> contains an application name field <NUM>, one or more access credential fields <NUM>, and a container ID field <NUM>. Application name field <NUM> contains values identifying each application. As shown in <FIG>, field <NUM>-<NUM> contains identifier "com. app1" corresponding to client application <NUM>-<NUM> and field <NUM>-<NUM> contains identifier "com. app2" corresponding to client application <NUM>-<NUM>. In the depicted embodiment, access credential fields <NUM> include an application access key field <NUM>, and an application group ID field <NUM>. However, additional types of access credentials may be used.

Application access key field <NUM> contains, for each client application <NUM>, a unique identifying value assigned to the client application <NUM> upon installation. For example, a unique secure access key may be sequentially assigned or derived from the client application name, e.g. using a time-based function, at the time of installation. As depicted, field <NUM>-<NUM> contains secure access key C0001 associated with client application <NUM>-<NUM> and field <NUM>-<NUM> contains secure access key C0002 associated with client application <NUM>-<NUM>. In some embodiments, creation of a secure access key for an application within a container <NUM>-<NUM> is prompted by a message sent from software in container <NUM>-<NUM> to operating system <NUM>-<NUM>.

Application group field <NUM> contains, for at least some client applications <NUM>, one or more values defining groups to which the client applications <NUM> belong. Application groups can include, for example, applications installed by a particular user, applications from a particular developer or publisher, functional groupings (e.g. banking applications, encryption/decryption tools, media applications), or any other suitable grouping. Group values can be assigned based on metadata in application packages, instructions from the user, rules in operating system <NUM>-<NUM> or access control driver <NUM>, or the like. As shown, client application <NUM>-<NUM> belongs to group "<NUM>" and client application <NUM>-<NUM> belongs to group "<NUM>". In the depicted example, group "<NUM>" corresponds to a set of applications using a common encryption/decryption utility, provided by trusted application <NUM>-<NUM>. Applications belonging to the group may include, for example, email, messaging and document storage applications associated with the same enterprise. In the depicted example, each of client applications <NUM>-<NUM>, <NUM>-<NUM> belongs to one group. However, it is possible for some applications to belong to multiple groups and for other applications to belong to no groups.

Container ID field <NUM> contains an identifier of the container <NUM> in which the client application <NUM> is installed.

A record is added to data structure <NUM> for each client application <NUM> upon installation of the client application <NUM>. That is, a record is added to the relevant application table <NUM> in data structure <NUM>. Likewise upon creation of a new container <NUM>, a new pointer <NUM> and application table <NUM> are added to data structure <NUM>.

<FIG> depict an example data structure <NUM> maintained by secure access manager <NUM> cataloguing trusted applications <NUM> and containing bindings of trusted applications <NUM> with access credentials of authorized client applications <NUM>. As shown in <FIG>, data structure <NUM> contains a container table <NUM> with entries corresponding to each secure container <NUM> hosted at operating system <NUM>-<NUM>. The entries have pointers <NUM> identifying trusted application tables <NUM>. Each trusted application table <NUM> contains a list of trusted applications <NUM> in a particular secure container <NUM> and parameters defining access requirements for each trusted application <NUM>. As depicted, secure container table <NUM> has entries for M secure containers <NUM>-<NUM> through <NUM>-M. Each container has a corresponding application table <NUM>. Secure container <NUM>-<NUM> has N trusted applications <NUM>-<NUM> through <NUM>-N. Secure container <NUM>-<NUM> has P trusted applications <NUM>-i through <NUM>-P. Secure container <NUM>-M has Q trusted applications <NUM>-<NUM> through <NUM>-Q.

<FIG> depicts an example trusted application table <NUM>. Trusted application table <NUM> includes a trusted application field <NUM> containing application ID values for each trusted application <NUM>. As depicted, trusted application field <NUM>-<NUM> contains a value, com. accountstore, which identifies the trusted application <NUM>-<NUM> responsible for maintaining payment and account credentials. Trusted application field <NUM>-<NUM> contains a value, com. encryptionkeys, which identifies the trusted application <NUM>-<NUM> responsible for maintaining an encryption/decryption utility. Trusted application table <NUM> further includes a required credentials field <NUM> containing credential values or combinations of credential values required for accessing the trusted application. As shown, field <NUM>-<NUM> contains an expression specifying that both a user ID of "user1" and an application access key of "C0001" (corresponding to client application <NUM>-<NUM>) are required to access trusted application <NUM>-<NUM>. Field <NUM>-<NUM> contains an expression specifying that a group value of "<NUM>" is required to access trusted application <NUM>-<NUM>. Thus, client applications <NUM> identified as belonging to that group are authorized. Referring again to <FIG>, application group field <NUM>-<NUM> contains value "<NUM>", indicating that client application <NUM>-<NUM> belongs to the authorized group for trusted application <NUM>-<NUM>. Application group field <NUM>-<NUM> contains value "<NUM>", indicating that client application <NUM>-<NUM> does not belong to the authorized group for trusted application <NUM>-<NUM>.

In some cases, it may be possible to access a trusted application <NUM> with multiple credentials or multiple combinations of credentials. For example, more than one user may be authorized to access a particular trusted application <NUM>, in which case credentials associated with any authorized user may be sufficient to gain access to the trusted application <NUM>. In such cases, the possible combinations could be entered as delimited values in a single field. For example, a field could contain multiple delimited user ID values. Alternatively, each combination could be entered in a discrete field.

Trusted application table <NUM> further includes a secure container field <NUM>, holding an identifier of the trusted container <NUM> in which each application is installed.

Data structures <NUM>, <NUM> may be database tables, e.g. relational database tables. However, other structures are possible, as will be apparent to skilled persons from the present disclosure. For example, each of data structures <NUM>, <NUM> could be implemented as a single table. In such embodiments, the container <NUM>, <NUM> in which each application is installed may be identified by an entry in container field <NUM> or secure container field <NUM>, rather than in a separate table.

Data structure <NUM> is stored in secure storage <NUM> and therefore can only be modified by secure access manager <NUM> or other components of operating system <NUM>-<NUM>. In some embodiments, secure access manager <NUM> is configured to modify data structure <NUM> only based on system-level instructions or instructions from specific digitally-signed application packages. Without limitation, updates to data structure <NUM> can occur: on installation of client applications <NUM> or trusted applications <NUM>; as part of system-level software updates issued, for example by the manufacturer of computing device <NUM>; uninstallation of applications; or resetting computing device <NUM>.

In some embodiments, access control driver <NUM> (<FIG>) further maintains a record of parameters used to authorize access to each trusted application <NUM>. In the depicted example, access control driver records that trusted application <NUM>-<NUM> can use the application access key and active user ID to authorize a request and that trusted application <NUM>-<NUM> uses only the application access key. In such embodiments, access control driver <NUM> constructs messages intended for particular trusted applications <NUM> based on the parameters required to authorize the message. Alternatively, access control driver <NUM> can include all available parameters with all messages intended for trusted applications <NUM>.

In some embodiments, at least some client applications <NUM> are installed in containers <NUM> concurrently with installation of their corresponding trusted applications <NUM> in secure containers <NUM>. Data structures <NUM>, <NUM> are updated accordingly upon installation. For example, in some embodiments, a client application <NUM>-<NUM> for encrypted communication and a trusted application <NUM>-<NUM> for encryption/decryption are contained in the same application package. Upon execution of the application package by a user, both of client application <NUM>-<NUM> and trusted application <NUM>-<NUM> are installed. Operating system <NUM>-<NUM> or a component thereof sends an instruction to operating system <NUM>-<NUM> identifying the container <NUM> in which the client application <NUM> is installed. Operating system <NUM>-<NUM> then identifies the corresponding container in which to install the trusted application <NUM>. Access control driver <NUM> assigns an application access key to the client application <NUM>-<NUM> and provides instructions to secure access manager <NUM> to add a record to data structure <NUM> linking trusted application <NUM>-<NUM> with the assigned secure access key, so that client application is authorized to access secure data from trusted application <NUM>-<NUM>.

<FIG> depicts an example method <NUM> of installing a trusted application <NUM>. At block <NUM>, operating system <NUM>-<NUM> receives a message from operating system <NUM>-<NUM> indicating that a trusted application <NUM> is to be installed. The message identifies a container <NUM> in which a corresponding client application <NUM> is installed. At block <NUM>, operating system <NUM>-<NUM> identifies a secure container <NUM> in which the trusted application is to be installed. The secure container <NUM> is identified by looking up the container identified at block <NUM> in data structure <NUM>.

At block <NUM>, the trusted application <NUM> is installed in the identified secure container <NUM>.

At block <NUM>, secure access manager <NUM> creates an entry in data structure <NUM> identifying the trusted application <NUM>, its access requirements and container information.

Alternatively or additionally, trusted applications <NUM> can be pre-installed in respective secure containers <NUM>, e.g. by the manufacturer of computing device <NUM>. In such cases, an application package containing a client application <NUM> which requires access to the trusted application <NUM> also contains instructions for updating data structure <NUM> to grant access rights to the client application <NUM>. Access control driver <NUM> processes the instructions and validates the application package as being authorized to modify data structure <NUM>, and passes the modification instructions to secure access manager <NUM>.

<FIG> are flow charts showing a method <NUM> of managing access to secure data, performed at computing device <NUM>. <FIG> is a schematic diagram showing example messages exchanged among components of computing device <NUM> in the method of <FIG>.

At block <NUM>, client application <NUM>-<NUM> requests access to secure data. In particular, the client application <NUM> calls a function provided by access control library <NUM> for sending requests to trusted applications <NUM>. The client application <NUM> constructs a message <NUM> (<FIG>) containing an identifier of the trusted application <NUM> for which the request is intended, and parameters defining the request, as indicated by message <NUM> in <FIG>.

The request may be a read request, i.e. a request for secure data to be returned. In such cases, the parameters included in message <NUM> define the data required. For example, a user of computing device <NUM> enters an input instructing client application <NUM>-<NUM> to present the user's credit card credentials at a point of sale. Client application <NUM>-<NUM> constructs a message <NUM> including request parameters such as (READ, CARD1), indicating that the request is a read request and that CARD1 is the data to be retrieved.

Alternatively, the request may be a write request i.e. a request to store data in secure storage <NUM>. For example, a user of computing device <NUM> enters an account number into client application <NUM>-<NUM> for storage, in which case client application <NUM>-<NUM> constructs a message including request parameters such as (WRITE, [account type], [account no. ]), indicating that the request is a write request and defining the type of account and number to be saved.

Alternatively, the request may be a request for performance of an operation by a trusted application <NUM>, such as encryption or decryption of data. For example, secure communication client application <NUM>-<NUM> constructs a request intended for trusted application <NUM>-<NUM>. The request may be a request for data to be decrypted or encrypted, in which case, the request includes or otherwise identifies the data, or it may be a request to retrieve an encryption key.

The message constructed by the client application <NUM> is passed from the container <NUM>, in which the client application <NUM> is installed, to access control driver <NUM> of operating system <NUM>-<NUM>.

At block <NUM>, access control driver <NUM> identifies the container <NUM> from which request <NUM> was received and looks up the corresponding secure container <NUM> in data structure <NUM> (<FIG>) at operating system <NUM>-<NUM>. Access control driver <NUM> further determines the types of access parameters required for accessing the relevant trusted application <NUM> and looks up those access parameters associated with the client application <NUM> from which the request originated. For example, as noted, trusted application <NUM>-<NUM>, housing payment credentials, requires an application access key to confirm that the requesting client application <NUM> is authorized and a user ID to confirm that the active user is authorized to access the requested account data. Some access parameters, e.g. application access keys, are retrieved by reading data structure <NUM>. Additional access parameters, e.g. user ID, can be provided by operating system <NUM>-<NUM> or the requesting client application <NUM>. Access control driver <NUM> forms a request <NUM> (<FIG>) including an identifier of the container <NUM> from which the request originated, an identifier of the corresponding secure container <NUM>, an identifier for the relevant trusted application <NUM>, the appropriate access parameters identified by access control driver <NUM>, and the request parameters received from client application <NUM>.

At block <NUM>, request <NUM> is passed to operating system <NUM>-<NUM> via processor <NUM>. Specifically, as shown in <FIG>, a message <NUM> is passed to secure access manager <NUM> identifying the container <NUM> from which the request originated and the relevant trusted application <NUM>-<NUM> and containing the parameters defining the data or operation requested and the access parameter, namely secure access key <NUM>-<NUM>.

At block <NUM>, secure access manager <NUM> performs a container check. <FIG> shows detailed steps of the container check at block <NUM>. At block <NUM>, secure access manager <NUM> searches container table <NUM> for the secure container <NUM> identified in request <NUM>. If the container does not exist in table <NUM>, the request fails and an error message may be returned.

If the container <NUM> identified in request <NUM> exists in container table <NUM>, at block <NUM>, secure access manager <NUM> checks access rules for that container <NUM>. In the depicted embodiment, the access rules are provided by the concordance defined in data structure <NUM>. That is, secure access manager <NUM> checks data structure <NUM> to verify that the container <NUM> from which the request <NUM> originated corresponds to the secure container <NUM> to which the request <NUM> is directed. If the access rules are not satisfied, the request fails.

If access rules are satisfied, secure access manager <NUM> checks the relevant secure container's trusted application table <NUM> for the trusted application <NUM> identified in request <NUM>. If the trusted application <NUM> does not exist in the table <NUM>, the request fails.

If the trusted application <NUM> is present in the table, secure access manager <NUM>, at block <NUM>, trusted application <NUM> reads the values in application table <NUM> and determines whether the combination of access parameters in message <NUM> appears in a corresponding field <NUM>. If the combination of parameters in message <NUM> matches a combination of parameters in a corresponding field <NUM>, a communications session is created between the client application <NUM> which originated the request and the trusted application <NUM> targeted by the request.

If, as in the depicted example, the received combination of access parameters matches a combination listed in field <NUM> for the trusted application <NUM> identified in message <NUM>, the requesting client application <NUM> is authorized to access the secure computing resource requested (e.g. secure data or trusted application <NUM>). At block <NUM>, secure access manager <NUM> passes a message <NUM> to the trusted application <NUM> containing the parameters defining the request.

If the received combination of access parameters does not match a combination associated with the trusted application <NUM> in application table <NUM>, the request is not authorized. For example, the user or client application <NUM> originating the request may not be authorized to access the secure data or perform the operation requested. If so, the request is rejected, that is, secure access manager <NUM> does not pass the request to the trusted application <NUM>. Optionally, an error message may be returned.

If an authorized request is a write request, trusted application <NUM> writes the received data to secure storage <NUM> (<FIG>). Alternatively, if an authorized request is a read request, trusted application <NUM> retrieves the requested data for returning to client application <NUM> in operating system <NUM>-<NUM>. If an authorized request is for performance of an operation, e.g. encryption or decryption of data, trusted application <NUM> performs the application. <FIG> depicts a method <NUM> of returning secure data from a trusted application <NUM> to a client application <NUM>. <FIG> depicts messages sent among components of computing device <NUM> during method <NUM>.

At block <NUM>, a trusted application <NUM> carries out the request. For example, the trusted application <NUM> obtains the secure data requested by client application <NUM>-<NUM>. In some examples, the trusted application <NUM> retrieves data from secure storage <NUM> and returns the data to client application <NUM>. In other examples, the trusted application <NUM> writes data received in the request. In still other examples, the trusted application <NUM> performs an operation, e.g. uses secure data to derive a response. For example, an encryption key may be retrieved from secure storage <NUM> and used to generate a decrypted value to be returned to a client application <NUM>.

At block <NUM>, trusted application <NUM> generates a response <NUM> (<FIG>) to be returned to the client application <NUM> and sends the response to secure access manager <NUM>. The message is passed to secure access manager <NUM>.

At block <NUM>, secure access manager <NUM> sends a message <NUM> (<FIG>) to including the response contents to operating system <NUM>-<NUM> by way of processor <NUM>. In particular, secure access manager sends message <NUM> to access control driver <NUM>.

At block <NUM>, access control driver <NUM> sends a message <NUM> (<FIG>) including the response contents to the client application <NUM>.

Data security may be strengthened by storing each secure container <NUM> in its own discrete secure storage <NUM> or address space or range thereof, and by providing each secure container <NUM> and its applications <NUM> a discrete secure memory <NUM> or memory space or range thereof. Such configuration guards against unintentional leakage of data from one secure container <NUM> to another, and from one secure container <NUM> to an unauthorized container <NUM>.

In addition, providing containers <NUM> for trusted applications <NUM> allows for the installation of multiple instances of a particular trusted application <NUM>. That is, independent instances of a trusted application <NUM> can be installed in each secure container without creating conflicts or errors in the access control methods and systems described herein. Thus, sets of data, such as personal and enterprise/professional data may be segregated from one another even when the same application is used for both personal and professional purposes.

As will be apparent, operating systems <NUM>-<NUM>, <NUM>-<NUM> (e.g. using access control driver <NUM> and secure access manager <NUM>) handle the identification of containers <NUM> and secure containers <NUM>, track concordance of individual containers <NUM> to secure containers <NUM>, identify communications between operating systems <NUM>-<NUM>, <NUM>-<NUM> as having originated from a particular container, and verify authorization of requests based on the originating containers. No special adaptation need be made to client applications <NUM> or trusted applications <NUM>. Thus, client applications <NUM> and trusted applications <NUM> need not be aware of containerization within computing device <NUM>. Likewise, developers of client applications <NUM> and trusted applications <NUM> need not be aware of containerization.

As described above, data structure <NUM> defines a concordance between containers <NUM> and secure containers <NUM>. The concordance is used as a set of rules for accessing secure computing resources in containers <NUM>. That is, any given secure container <NUM> can be accessed only through requests originating from the corresponding container <NUM>. In other embodiments, access rules may be defined differently. For example, any of the access requirements defined for trusted applications <NUM> in applications table <NUM> (<FIG>) could be used to control access at the secure container level. Such rules may be added to data structure <NUM>.

<FIG> depicts an embodiment with client applications <NUM> installed directly in operating system <NUM>-<NUM>, rather than within containers <NUM>. The client applications <NUM> in operating system <NUM>-<NUM> include a first group A and a second group B. Group A is, for example, a set of personal applications such as payment. Group B is, for example, a set of enterprise applications such as encrypted communication applications. Secure container <NUM>-<NUM> contains a trusted application <NUM>-<NUM> through which payment credentials can be accessed. Secure container <NUM>-<NUM> contains a trusted application <NUM>-<NUM> with secure communication resources such as encryption/decryption keys. In the embodiment of <FIG>, rules for accessing containers <NUM>-<NUM>, <NUM>-<NUM> and secure computing resources therein are based on application groups. Application tables <NUM> include values identifying groups to which applications belong. Data structure <NUM> (<FIG>) includes values identifying groups authorized to access secure containers <NUM>. Access control driver <NUM> is configured to construct requests including group identifiers. Secure access manager <NUM> is configured to pass the requests to the targeted secure container <NUM> if the relevant group is authorized based on the rules defined by data structure <NUM>.

Rules for accessing secure containers <NUM> may be based on any suitable combination of the criteria described above. For example, <FIG> depicts an embodiment with two containers <NUM>-<NUM>', <NUM>-<NUM>' in operating system <NUM>-<NUM>. Client applications <NUM> are installed within each of containers <NUM>-<NUM>' and <NUM>-<NUM>'. A subset of client applications <NUM> in container <NUM>-<NUM>' belong to a group C. In the embodiment of <FIG>, data structure <NUM> defines a concordance between containers <NUM>, <NUM> and further contains values defining groups authorized to access particular containers <NUM>.

As will be apparent, container access rules based on other combinations of criteria are possible.

As described with reference to the embodiments of <FIG>, control of access to trusted applications <NUM> and to secure data stored by trusted applications <NUM> is centrally managed by secure access manager <NUM> in concert with and using information provided by access control library <NUM> and access control driver <NUM>. Access control measures need not be implemented by either of client applications <NUM> or trusted applications <NUM>. Rather, client applications <NUM>, trusted applications <NUM> can simply define the desired access controls, e.g. using metadata in application packages, and rely on access control library <NUM>, access control driver <NUM> and secure access manager <NUM> to implement such controls. Access control library <NUM>, access control driver <NUM> and secure access manager <NUM> reflect the desired access rules in data structures <NUM>, <NUM>.

Centralized implementation of access control in this manner allows for standardization of access controls among client applications <NUM>, trusted applications <NUM>. For example, code to limit access to specific client applications or users is implemented in access control driver <NUM> and secure access manager <NUM>, and client applications <NUM>, trusted applications <NUM> can simply rely on the access control driver <NUM> and secure access manager <NUM> for such functions. Thus, vulnerabilities associated with incorrect implementations by individual applications can be avoided. Moreover, in the event of a security vulnerability being identified, the vulnerability can be addressed for all applications by updating one or more of access control library <NUM>, access control driver <NUM> or security access manager <NUM>. In contrast, if access controls were implemented by individual client applications <NUM> or trusted applications <NUM>, addressing vulnerabilities could require updating every application.

Handling of access control functions by operating system components, e.g. access control library <NUM>, access control driver <NUM> and secure access manager <NUM>, also eases development of client applications <NUM> and trusted applications <NUM>, as developers of individual applications need not implement custom access controls in each application. Ease of development may tend to encourage the development of applications that utilize secure memory <NUM> and secure storage <NUM> and therefore may contribute to the expansion of capabilities of computing devices such as computing device <NUM>.

As described above with reference to <FIG>, each request generated by a client application <NUM> includes an identification of the trusted application <NUM> for which the request is intended. Client applications <NUM> are aware of trusted applications <NUM> with which they are designed to interact. That is, client applications <NUM> are programmed to rely on trusted applications <NUM> for some data or for performance of some operations, and to form requests identifying those trusted applications and including the relevant parameters. In other embodiments, access control library <NUM> may provide multiple functions, specific to types of data available from trusted applications <NUM> and types of operations that can be performed by trusted applications <NUM>. In such embodiments, access control library <NUM> further maintains a concordance between each function and the respective trusted application, and defines the parameters required for each function, each as part of an API. Thus, client applications <NUM> can be configured to rely on functions provided by access control library <NUM> and need not explicitly identify trusted applications <NUM>.

In some embodiments, components and features of the systems and methods disclosed herein can be implemented according to Global Platform Trusted Execution Environment (TEE) specifications, accessible on the internet at www. globalplatform. org/specificationsdevice. For example, in some embodiments, mobile computing device <NUM> is compliant with Global Platform TEE System Architecture v1. <NUM> and operating system <NUM>-<NUM> is compliant with the trusted execution environment specifications defined therein. Moreover, in some embodiments, operating systems <NUM>-<NUM>, <NUM>-<NUM> and computing device <NUM> implement Global Platform TEE API specifications such as TEE Client API Specification v1. <NUM> and TEE Internal Core API Specification v1. <NUM> and communication between operating system <NUM>-<NUM> and operating system <NUM>-<NUM> occurs according to such specifications.

The scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed, that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.

Claim 1:
A computing device, comprising:
a processor configured to provide:
a first operating system with access to a first memory; and
a second operating system with access to a second memory and hosting a plurality of containers providing separate execution environments, each of said plurality of containers having secure computing resources; and
a software module executable within said second operating system for receiving access requests from applications in said first operating system and selectively passing said requests to said secure computing resources based on container access rules;
wherein said secure computing resources comprise trusted applications in said containers of said second operating system; and
wherein first and second containers of said second operating system have respective instances of a trusted application.