Application lifecycle operation queueing

A trusted execution environment on an enterprise-enabled computing device allows invocation of a suite of secure applications (apps) on a computing device in an enterprise without hindering external or non-enterprise apps from running on in the same memory space on the same enterprise computing device. An application wrapper provides an operation queue for storing application lifecycle operations while the trusted execution environment is enabled, and the environment is secured. The application defers lifecycle operation to ensure that all security measures are in place before it is allowed to execute. The operation queue receives entries corresponding to the application lifecycle events, and suspends process execution of the lifecycle operations until the secure environment is ready for the operation queued events to be executed.

BACKGROUND

Computer security, particularly to safeguard the proprietary and sensitive data of corporations and other enterprises, has become increasingly scrutinized as more and more data travels electronically over public access networks. An enterprise or other organization, however, with many employees or members presents a particular vulnerability, as any user may be leveraged to obtain access. Further, such enterprises may employ a common set of applications on computing devices of each individual user. It is problematic to mandate and enforce exclusive corporate usage of these personal devices; as a practical matter, little control can be exercised over a machine in a user/employee's possession. Additional applications and activities undertaken by users can interfere with and/or compromise enterprise activities on the computing device due to common execution environments shared by the enterprise apps and user supplied apps, resulting in a vulnerability that rests upon the integrity of extraneous apps loaded by the user, particularly when both types of applications are launched by a common operating system in the same memory space.

SUMMARY

A trusted execution environment on an enterprise-enabled computing device, whether owned by the enterprise or the user/employee, hereinafter called an “enterprise computing device”, allows invocation of a suite of secure enterprise applications (apps) on a device without hindering external or non-enterprise apps from running on the same enterprise computing device. Each of the enterprise computing devices executes the suite of secure enterprise apps, which interact with each other in a trusted manner such that outside apps or network connections are prevented from accessing the enterprise apps. The enterprise computing device, however, also executes non-enterprise applications which operate independently of the enterprise apps in the same address space, and which can communicate with other non-enterprise apps, and using the same unmodified operating system as the enterprise apps on the enterprise computing device. The trusted execution environment therefore restricts interprocess communication only between the set of enterprise apps and non-enterprise apps, and also permits unimpeded operation of other apps under the same OTS (off the shelf) operating system, thereby providing a trusted or secure execution environment for the enterprise (trusted) apps.

The “lifecycle operations” are the operations performed by the app that require the trusted execution environment to be in place. Following application launch, any lifecycle operations which the application invokes are placed in the operation queue to await proper execution conditions as defined by the execution environment configuration. The lifecycle operations include those that occur as the app is starting, in response to app events (e.g. app created, app loaded), however may be any operation or function by the app that requires the trusted execution environment. For example, any operation during which the app could execute a system call that could expose data outside the secure environment may be considered. The execution conditions typically pertain to ensuring the trusted execution environment, such as access to a secure key store, secure interprocess communication channels, VPN or IP (Internet Protocol) operations, and/or access to particular ranges of IP addresses.

Configurations herein are based, in part, on the observation that application execution environments employ an infrastructure of support operations for maintaining security and privacy of various applications in the execution environment. Unfortunately, conventional approaches to partitioning or safeguarding individual applications suffer from the shortcoming that required infrastructure operations may not commence effective performance before application startup, giving rise to a time window or race condition where certain applications could elude the infrastructure protections provided for maintaining the trusted execution environment. For example, applications may have the ability to communicate with other applications via an IPC (Interprocess Communication) mechanism or network connections before those connections have been secured. The trusted execution environment and related apps and processes provide the infrastructure to monitor and oversee such communications, but effective oversight depends on the execution environment being viable to scrutinize communication traffic prior to application startup, otherwise the applications enjoy a brief interval of unscrutinized communication. Accordingly, configurations herein substantially overcome the shortcomings of conventional approaches by providing an operation queue for storing the lifecycle operations, and deferring execution of the lifecycle operations until completion of the execution conditions that define the trusted execution environment, typically meaning that the infrastructure operations have completed. The operation queue receives entries corresponding to the lifecycle operations, and the system suspends process execution of the lifecycle operations until the trusted execution environment is established.

In further detail, in the trusted execution environment for designating a group of trusted applications for exclusive interprocess communication, a disclosed method for installing an application includes identifying a lifecycle operation for an application, in which the lifecycle operation requires application execution in the trusted execution environment. The wrapper determines, for the lifecycle operation, execution conditions for initiation of the lifecycle operation, and defers execution of the lifecycle operation, or optionally the entire application, such that the delay is based on satisfaction of the execution conditions. For example, a lifecycle operation might involve executing operations that occur upon app first launch. Because this operation could send a message to another app, it must be prevented from doing so until the execution environment is considered “trusted” by establishing appropriate safeguards.

The disclosed approach is expected to operate on a personal, portable computing device such as a smartphone, tablet or laptop, responsive to installed applications, including a memory for installing and executing applications, in which the applications include processor instructions, and a processor for interpreting and executing the processor instructions. The device includes at least one lifecycle operation of an application, in which the lifecycle operation requires application execution in the trusted execution environment, and installation instructions for determining, for the lifecycle operation, execution conditions for initiation of the lifecycle operation.

The computing device further includes a graphical user interface (GUI) on the device, such that the GUI is configured to invoke the application for launch once installed by the above sequence. Upon invocation, the device determines, for each of the lifecycle operations, if each of the execution conditions have been satisfied, and defers invocation of the lifecycle operations until operations corresponding to the execution conditions have completed. While complete application execution could be curtailed, the lifecycle operations represent those that potentially compromise security, and thus only these need be queued pending establishment of the trusted execution environment. Other internal operations of the app are permitted to execute. In this manner, the device ensures proper operation of the enterprise apps by ensuring that the trusted execution environment provided for the lifecycle operations is in force prior to permitting their execution.

DETAILED DESCRIPTION

Depicted below is an example of an enterprise having a plurality of portable computing devices, as might be used by employees of the enterprise, each exhibiting a secure execution environment. Examples of communication between apps in the secure execution environment depict particular features, however should not be taken to limit approaches of the invention as claimed herein. Various organizational settings may elect computing devices having a secure execution environment in a stationary, mobile, portable, handheld or other physical configuration.

The applications, or apps, as described represent an executable entity launched in the memory space of a computing device. The computing devices have an operating system such as Android™, IOS (iPhone® Operating System), WINDOWS®, Linux or other suitable platform, however it should be emphasized that the techniques disclosed herein are independent of the native OS (Operating System) and do not impose or require changes to the underlying OS of the computing device. The disclosed approach also employs applications in an unmodified (i.e. vendor supplied) form, such that loaded apps do not require a specialized version for compatibility with the disclosed approach.

The disclosed approach allows an application to intercept and defer normal application operation until proper infrastructure conditions are met, e.g. security measures are established and executing on the device. The interception and deferring of these operations resides entirely in the application. Configurations herein employ application wrapping such as that disclosed in the co-pending application discussed in further detail below. On application startup, the app commences to execute lifecycle operations. Each lifecycle operation is intercepted before its code runs and conditions are checked to determine whether or not the operation is allowed to run. If conditions are not yet met, the lifecycle operation is placed on an operation queue to be run at a later time. To make sure that state is properly maintained, the operation and all parameters passed to it are stored in the operation queue.

This method of lifecycle operation blocking allows the application to effectively pause the state of the lifecycle operations until the conditions are met. The code required to set up the necessary conditions in the infrastructure of the trusted execution environment is allowed to run while the particular operations that update the application's state are deferred. Lifecycle operations may be distinguished from internal operations not requiring a trusted execution environment by a status flag or similar structure that is examined by the app to determine whether to execute or queue an lifecycle operation. Alternative approaches may be employed. For example, all operations may be queued, or operations may be grouped to classify the lifecycle operations as emanating from a particular source file or memory area, or bearing a certain flag parameter.

When all conditions are met, an event is fired to start processing the lifecycle operation queue. Each entry in the operation queue is processed one by one in order, passing along saved parameters to bring the application back up to an expected state. From this point following execution of the queued lifecycle operations, the application and its operations behave normally. It should be emphasized that various mechanisms may be employed to designate the operations for queueing and for concluding an appropriate point to release the queue.

An example configuration depicted herein provides an environment for secure applications to communicate with each other in the presence of other insecure apps. This is implemented within the applications themselves, and therefore does not rely on the operating system to provide a special trusted container. Individual processes in the trusted execution environment are wrapped to provide interception of system calls which affect communication and invocation of other processes. In the discussion and figures that follow, the graphical representation of the applications (apps) are depicted as a circular entity and the wrapper as a larger concentric entity around the app, and code segments depicted as boxes within the concentric entities. The representation is not intended to restrict particular implementations but rather to illustrate one possible manner in which the software may be architected. A typical arrangement incorporates logic elements as code represented by dynamic linked libraries (DLLs), as discussed in detail in co-pending U.S. patent application Ser. No. 14/208,068, filed Mar. 13, 2014, entitled “MODIFICATION OF COMPILED APPLICATIONS AND APPLICATION MANAGEMENT USING RETRIEVABLE POLICIES,” incorporated herein by reference. Other arrangements of code and memory of the apps and operations discussed herein may be performed, depending on the relevant operating system and compiling and/or interpreting facilities.

The applications, or apps, as described represent an executable entity launched in the memory space of a computing device. The computing devices have an operating system such as Android™, IOS (iPhone® Operating System), WINDOWS®, Linux or other suitable platform, however it should be emphasized that the techniques disclosed herein are independent of the native OS and do not impose or require changes to the underlying OS of the computing device. The disclosed approach also employs unmodified applications, such that installed apps do not require a specialized version for compatibility with the disclosed approach.

FIG. 1is a context diagram of an enterprise environment suitable for use with configurations herein. Referring toFIG. 1, in an enterprise setting100such as a corporation or business a particular set or suite of apps for handling proprietary, or corporate sensitive, information. The enterprise provides portable computing devices110-1. . .110-N (110generally) for each employee. The computing devices110may be tablets, laptops, handheld or phone type devices, or may even be more stationary devices such as desktops. Each of the computing devices110executes applications (apps)150-1. . .150-N (150generally), which send messages140-1. . .140-N (140generally) to other apps150on the same or other computing devices110, which may be remotely accessible over a public infrastructure network132such as the Internet. Each of the apps150is generally defined by a process running under the OS, however more complex apps may include more than one process. The operations executed by the app150include lifecycle operations, which require execution in an established infrastructure defined by a trusted execution environment, and internal operations which remain internal to the app. Prior to establishment of the trusted execution environment, lifecycle operations160are deferred and stored in an operation queue pending establishment of a trusted execution environment, such that no secure data leaves the secure app space, and no insecure data is allowed into the secured app space defined by the trusted execution environment.

FIG. 2is an execution environment as inFIG. 1depicting the lifecycle operations160. Referring toFIGS. 1 and 2, an application150-11has one or more lifecycle operations160, which are intended to execute only after certain other operations (i.e. infrastructure operations to establish the trusted execution environment) on which it is dependent are allowed to complete. Generally, the lifecycle operations include operations that require the trusted execution environment. The other operations may be external to the app150, or may be performed by other threads within the same app, to avoid blocking a lifecycle operation waiting for another operation or process that cannot complete in a blocked state. In either case, the lifecycle operation160is paused until the conditions on which it is dependent are satisfied. Blocking the lifecycle operation160may also prevents general app150execution until the lifecycle operations are all completed, as the lifecycle operations160often precede general execution of the app150, such as startup or initialization functions.

In the example configuration, the lifecycle operations160are lifecycle operations executed as a normal aspect of the app. The trusted execution environment includes trusted apps coexisting with untrusted apps in a common address space, typically by modifying the trusted apps using a wrapper, as discussed further below. The trusted execution environment100supports a plurality of applications150. Since IPC communication represents a potential infiltration route to an app150, the deferred invocation of lifecycle operations160in each of the plurality of applications150may prevent interprocess communication and other forms of data input/output of the applications150in the trusted execution environment with other applications in the trusted execution environment.

In the app150, lifecycle operations160are application operations that require adequate security measures to ensure that insecure I/O, including communication with the app, does not occur. For example, the lifecycle operations160may invoke an interprocess communication (IPC) mechanism to exchange information with another process. Blocking a lifecycle operation160until certain conditions are met ensures that proper safeguards and checks are in place to scrutinize and control information exchanged with other processes, and also guards against subtle timing differences, or “race conditions” between other processes and/or threads that could cause a misordering of startup operations. The conditions upon which the lifecycle operation relies are those which provide the proper secure environment in which to perform the lifecycle operations of the application. Such startup conditions, and the ordering thereof, ensure that an appropriate execution environment is in place prior to general app150execution.

In order to ensure that appropriate control is exercised over installed apps for preventing premature execution of the lifecycle events that should be queued, corresponding structures are put in place prior to application execution. In the example configuration, this is performed by the wrapper operation disclosed copending application cited above. Such wrapping occurs prior to app150execution, and preferable prior to or in conjunction with the installation process.

In an example configuration, the application150undergoes a wrapping operation prior to installation to ensure that the lifecycle operations160are designated in the app prior to general app execution. Installations are typically handled by a wrapper149, which is a program that receives an installation package148including the app150′ for installation, as well as other administrative directives for ensuring that administrative details such as program registry updates and start menu designations are handled. During installation, an original execution point (OEP)162of the app is identified and redirected from an interception point167, as shown by arrow161, so that the lifecycle operations160may be completed and verified prior to permitting general execution of the app150-11. Lifecycle operations160.

The wrapper149applies the wrapper code to the app150which performs scrutiny of lifecycle operations. Events pertaining to the lifecycle operation160are intercepted or “hooked” by the wrapper, either when the wrapper code is applied or during app invocation/execution. The wrapper code (180,FIG. 3below) includes the instructions and logic that identify the lifecycle events and enqueue them for subsequent execution at an appropriate time. The events have no knowledge that they are wrapped, they are just experiencing normal invocation. The wrapper149applies the wrapper code such that, based on the events, the wrapper code180queues events triggering lifecycle operations160as needed until the secure environment is set up. Once the secure environment is there, the events are fired, and occasionally omitted or skipped, as discussed below, if their execution is now moot or redundant. Following completion of the queued lifecycle operations160after the operation queue is drained, control is returned to the original execution point.162, as shown by arrow163, for general process execution in a state similar to the app as if the queued operations had executed without being queued or as would have occurred in an unwrapped app.

During invocation of the lifecycle operations160, general process execution, such as receiving a message140from another process150-12via an IPC mechanism170, is prevented. The point of this is to prevent the app from taking actions before those actions are secured. IPC communications are employed as an example of a secured lifecycle operation that requires the queueing to ensure that execution occurs in a trusted environment. However, the goal is to prevent any form of I/O or other potentially compromising activity, which includes IPC but also simple file read/write and also network access. Network access is not typically between wrapped apps on different devices, it is between wrapped apps and any server on the Internet or on a private network.

Once the lifecycle operations160have completed according to the preconditions, general execution of the app150-11may occur, such as sending a communication to another process, processing an incoming message, and other actions. This ensures that before the app150accesses files, network, etc. that the environment for doing so is secured. It should be noted that the lifecycle operations affect process communication in both directions. The app is blocked from both sending and receiving any data until all of the lifecycle operations are complete, at which point the intercepted messages will be received and sent in order as part of the operation queue. Further, while the lifecycle operations160are generally categorized as those which exchange data outside of the app150, any operation in the app may be queued pending a trusted execution environment, and each app150maintains a set of execution conditions defining what is deemed sufficient to release the operation queue for permitting the lifecycle operations to execute.

FIG. 3shows an operation queue corresponding to an application150as inFIG. 1. In an example configuration, the deferred lifecycle operations (160-1,160-2) are stored in an operation queue170for maintaining an invocation of each lifecycle operation until the required preconditions (conditions) are met. The operation queue170stores entries172-1. . .172-N (172generally) corresponding to each lifecycle operation150. Each entry172includes the name171of a lifecycle operation160, a parameter list174and a condition set176(conditions) for invocation. During launch, the execution environment100redirects launch from the redirection point167to a program or code sequence defined as wrapper code180in the wrapper152. The wrapper code identifies the lifecycle operations152-1. . .152-2(152generally) and the operation queue170for deferring the lifecycle operations. It should be noted that the queued lifecycle operations need not be limited to those occurring at startup, but rather they represent normal process (“lifecycle”) processing which was merely deferred until the execution environment was “safe” (i.e. trusted). Upon satisfaction of the conditions176, the entries172are pulled from the operation queue170and the corresponding lifecycle operations160executed with the parameter list174stored in the entry172.

In a particular configuration, when all of the conditions are finally met, an event triggers to commence app processing of the queued operations by pulling the lifecycle operations from the operation queue. When executing the queued lifecycle operations, it is ensured that expected conditions for that operation are met. If the conditions for the operation are no longer relevant, processing skips over that queued operation if it is no longer applicable in the execution context. Situations may arise where the queued operations have become obsolete and/or redundant, and execution of that operation might unfavorably alter the state of the execution environment instead of properly restoring the state to what the application expects, i.e. proper, robust security measures being in place.

FIGS. 4aand 4bshow a flowchart of the operation of the operation queue ofFIG. 3. Referring toFIGS. 2-4b, in the trusted execution environment100for separating a group of trusted applications160for exclusive interprocess communication, the disclosed method for installing an application includes, at step400, identifying a lifecycle operation160for an application, the lifecycle operation, or dependency operation (due to dependency on the trusted execution environment) resulting from application execution in the trusted execution environment. The execution environment100identifies an installation package148including the application150′ for installation, in which the installation package148includes installation directives and executable instructions having the OEP162, as depicted at step401. This includes, identifying the original entry point162to the application150, as depicted at step402, and reassigning the original entry point162based on the installation package148, as shown at step403. The wrapper149directs the reassigned entry point for examining and executing the lifecycle operations150, as shown by arrow161and depicted at step404.

The wrapper149copies the executable instructions and installation directives to a deferred installation package, such that the deferred installation package is defined by wrapper code153operable to define the operation queue170for one or more lifecycle operations160and to defer execution from the original entry point162pending completion of the plurality of lifecycle operations, as shown at step405. Further, the lifecycle operations may include either startup operations or operations resulting from normal process execution. The intended result is that actions defined by the lifecycle operations do not occur/execute until the execution conditions defining a secure environment are in place. The installation package148also includes the code and DLLs of the application to be installed150′.

During app150installation, the wrapper148determines, for the lifecycle operation, execution conditions for initiation of the lifecycle operation160, as depicted at step406, and inserts a delay into a launch of the application150, such that the delay is based on satisfaction of the execution conditions, as disclosed at step407. The inserted delay (performed above by the operation queue) is responsive to an interception of a launch instruction for the application150, which further includes instructions for returning control to an original execution point or other normal app execution state following completion of the lifecycle operations, as shown by arrow179.

Insertion of the delay, in the example ofFIG. 3, further includes defining an operation queue170configured for storing entries172corresponding to each of a plurality of lifecycle operations160, as depicted at step408. The wrapper148identifies one or more lifecycle operations160-N for inclusion, as disclosed at step409and stores an entry172for each of the identified lifecycle operations160in the operation queue170, as shown at step410. The queued lifecycle operations include parameter lists174, and the operation queue170also stores the parameter lists174corresponding to each of the lifecycle operations160in the entry172along with the conditions176that need to be satisfied for execution of the lifecycle operation160.

The inserted wrapper code153defers launch of the application150until each of the operation queued lifecycle operations160has completed, shown at step411as control is not returned to the OEP162or other execution point until all entries172have been processed off the operation queue170. The inserted delay is a conditional delay, and the wrapper also inserts conditional checks for examining completion of each of the execution conditions176, as depicted at step412. The wrapper149also inserts a branch back to the original execution point162based on satisfaction of the execution conditions176, as disclosed at step413, as after all entries172have been pulled off the operation queue170and the lifecycle operations160stored in those entries executed, the app150may commence.

It should be emphasized that the lifecycle operation is an application action/function/execution that relies on the wrapper to ensure that execution is deferred (queued) until the environment is ready. The operation queued lifecycle operations are the actions that the app wishes to take prior to the environment being ready. For example, the app wants to make a network connection. The wrapper detects that, but sees that the VPN is not available. It operation queues the network operation, and delays execution until the VPN is ready

Following installation of the app150along with the wrapper code153for establishing and checking the lifecycle operations160, an input is received to invoke the application150for launch, as disclosed at step414. The executing app150determines, for each of the lifecycle operations160in the operation queue170, if each of the execution conditions176have been satisfied, as depicted at step415, and defers launch of the application150until the execution conditions176have been satisfied and/or completed, as shown at step416. The execution conditions generally pertain to establishment of the trusted execution environment, such as enablement of IPC mechanisms and launch of a keystore process for managing encryption between the apps150. The wrapper code152redirects the application150to the original entry point to resume normal operation after satisfaction of the execution conditions176and execution of the queued lifecycle operations.

It will be appreciated by those skilled in the art that alternate configurations of the disclosed invention include a multiprogramming or multiprocessing computerized device such as a workstation, handheld or laptop computer or dedicated computing device or the like configured with software and/or circuitry (e.g., a processor as summarized above) to process any or all of the method operations disclosed herein as embodiments of the invention. Still other embodiments of the invention include software programs such as a Java Virtual Machine and/or an operating system that can operate alone or in conjunction with each other with a multiprocessing computerized device to perform the method embodiment steps and operations summarized above and disclosed in detail below. One such embodiment comprises a computer program product that has a computer-readable storage medium including computer program logic encoded thereon that, when performed in a multiprocessing computerized device having a coupling of a memory and a processor, programs the processor to perform the operations disclosed herein as embodiments of the invention to carry out data access requests. Such arrangements of the invention are typically provided as software, code and/or other data (e.g., data structures) arranged or encoded on a non-transitory computer readable storage medium such as an optical medium (e.g., CD-ROM), floppy or hard disk or other medium such as firmware or microcode in one or more ROM, RAM or PROM chips, field programmable gate arrays (FPGAs) or as an Application Specific Integrated Circuit (ASIC). The software or firmware or other such configurations can be installed onto the computerized device (e.g., during operating system execution or during environment installation) to cause the computerized device to perform the techniques explained herein as embodiments of the invention.