CONTEXT BASED SWITCHING TO A SECURE OPERATING SYSTEM ENVIRONMENT

Abstract

Generally, this disclosure provides devices, systems, methods and computer readable media for context based switching to a secure OS environment including cloud based data synchronization and filtration. The device may include a storage controller to provide access to the secure OS stored in an initially provisioned state; a context determination module to monitor web site access, classify a transaction between the device and the website and identify a match between the web site and a list of web sites associated with secure OS operation or a match between the transaction classification and a list of transaction types associated with secure OS operation; and an OS switching module to switch from a main OS to the secure OS in response to the identified match. The switch may include updating state data associated with the secure OS, the state data received from a secure cloud-based data synchronization server.

Description

FIELD

The present disclosure relates to context based switching to a secure operating system environment, and more particularly, to context based switching to a secure operating system environment with cloud based data synchronization and filtration.

BACKGROUND

Computing platforms and their associated operating system (OS) are vulnerable to attacks by malware, viruses and other types of malicious software that may attempt to compromise a user's sensitive or confidential data, possibly for financial gain or other illegal purposes. For example, malware may log keystrokes or capture screen images and transmit this information to a remote attacker without the user's knowledge.

Some existing approaches to deal with this problem focus on malware prevention, for example, by scanning downloaded data and programs to detect the presence of malware and block their entry to the system before they can do harm. Scanning software, however, generally requires frequent updates and can only detect older known threats, leaving systems vulnerable in an evolving threat environment.

Other approaches involve sandbox techniques, such as, for example the use of virtual machines to contain software execution that may be infected with malware. Virtual machines typically slow down execution speed, however, which may result in unacceptable system performance. Virtual machine security may also be breached, for example, if the malware can execute before the virtual machine manager is launched.

Still other approaches rely on user diligence, in conforming to security protocols and procedures. This typically imposes an inconvenience on the user and often results in lapses on the part of the user which may result in security breaches.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of embodiments of the claimed subject matter will become apparent as the following Detailed Description proceeds, and upon reference to the Drawings, wherein like numerals depict like parts, and in which:

FIG. 1 illustrates a top level system diagram of one example embodiment consistent with the present disclosure;

FIG. 2 illustrates a block diagram of one example embodiment consistent with the present disclosure;

FIG. 3 illustrates a block diagram of another example embodiment consistent with the present disclosure;

FIG. 4 illustrates a block diagram of another example embodiment consistent with the present disclosure;

FIG. 5 illustrates a flowchart of operations of one example embodiment consistent with the present disclosure;

FIG. 6 illustrates a flowchart of operations of another example embodiment consistent with the present disclosure; and

FIG. 7 illustrates a flowchart of operations of another example embodiment consistent with the present disclosure.

Although the following Detailed Description will proceed with reference being made to illustrative embodiments, many alternatives, modifications, and variations thereof will be apparent to those skilled in the art.

DETAILED DESCRIPTION

Generally, this disclosure provides devices, systems, methods and computer readable media for context based switching from a main OS to a secure OS environment, the switch including cloud based data synchronization and filtration. Web site access may be monitored to determine if a “high value” transaction (e.g., a financial or other sensitive transaction) is being attempted or if the web site is on a list of filtered or white-listed web sites. In response to such a determination, an OS switch may be performed wherein the main OS is suspended and a copy of the secure OS, for example a read-only copy, is retrieved from secure storage and loaded as the new working copy of the OS. The retrieved secure OS may be in a “clean” state, for example, as initially provisioned from the manufacturer or provider or in any known/trusted state. The state of the working copy of the secure OS may then be updated from this clean state to a state associated with more recent activity. The state update may be based on state data received from a secure cloud-based data synchronization server.

When the transaction with the web site is completed, the new current state (e.g., reflecting the state of the secure OS working copy after completion of the transaction) may be re-synchronized with (e.g., stored back to) the secure cloud-based data synchronization server and a switch may be performed back to the main OS.

FIG. 1 illustrates a top level system diagram 100 of one example embodiment consistent with the present disclosure. A computing system or platform 104 is shown to include a main OS 106, a secure OS 108 and a context-based OS switching module 110. The platform 104 may be any type of computing system, such as, for example, a desktop workstation, a laptop, a tablet, a smart phone, or any other device that includes an operating system.

Typically, the main OS 106 may perform the majority of the work associated with a user's session on the platform 104, while operations of the secure OS working copy 108 may be limited to those situations for which security is desired. In some embodiments the main OS 106 and the secure OS 108 may initially be the same, for example at the time of provisioning. Over time, however, the main OS may change through interaction with external entities such as, for example, internet transactions with web sites, some of which may be malicious, while the secure OS is maintained in a clean or initial state as will be explained in greater detail below. The context-based OS switching module 110 may be configured to switch between the main OS 106 and the secure OS 108 based on the context associated with website access and transactions, as will also be explained in greater detail below. In some embodiments, the switching may be accomplished in conjunction with synchronization of state data, for example associated with a previous invocation of the secure OS 108, between the platform 104 and a secure cloud-based data synchronization server 102.

FIG. 2 illustrates a block diagram 200 of one example embodiment consistent with the present disclosure. Platform 104 is shown, in greater detail, to illustrate that main OS 106 may be exist as a stored copy 206 and that secure OS 108 may also exist as a stored copy (e.g., a read-only copy) 208. During run-time, working copy 216 of the main OS and/or working copy 218 of the secure OS may be loaded and executed. Working copies 216 and 218 are drawn with dashed lines in FIG. 2 to indicate that they are created at run-time. Platform 104 may also include storage controller 204 and a trusted execution environment (TEE) 210, which, along with secure OS agent 202, may be components of the context based OS switching module 110 of FIG. 1. Storage controller 204 may be configured to maintain and access the stored copies of the main OS 206 and the read-only secure OS 208. In some embodiments, the storage controller 204 may store these copies in a solid-state memory device to facilitate more rapid switching between the working copy of the main OS 216 and the stored read only copy of secure OS 208, as well as switching back between the working copy of the secure OS 218 and the stored main OS 206. The stored secure OS 208 may be stored in a “clean” state, for example, as initially provisioned from the manufacturer or provider and may be stored as a read-only copy (or stored using any other suitable security mechanism) to prevent modifications and possible corruption or compromise. The TEE 210 may be configured to provide encryption and authentication services associated with communication between the platform 104 and the secure cloud-based data synchronization server 102, as will be explained in greater detail below.

The main OS working copy 216 may include a secure OS agent 202. The secure OS agent 202 may further include context determination module 212 and OS switching module 214. Context determination module 212 may be configured to perform context determination by monitoring access to websites that are included in a filtered list of websites that are associated with secure OS operations. This filtered list of websites, or white list, may contain websites for which secure OS operations are preferred, because, for example, confidential or sensitive data may be available. Additionally, in some embodiments, the secure OS may be limited to accessing only those websites included in the white list to further limit the possibility of a security compromise that could result from access to malicious websites. Context determination module 212 may further be configured to monitor transactions between platform 104 and these websites to determine if the transaction is a high value transaction, for example, a funds transfer or payment type transaction. High-value transactions may also include activities such as viewing documents containing data of a confidential, private, or otherwise sensitive nature. Such a high value transaction may also be associated with secure OS operations.

OS switching module 214 may be configured to switch operating systems from main OS working copy 216 to secure OS working copy 218, in response to a determination, by module 212, that secure OS operations are required. The switch may be performed by suspending the main OS working copy 216, accessing the read-only stored copy of secure OS 208 through storage controller 204, and loading and executing it as the new secure OS working copy 218.

Since the stored copy of secure OS 208 is stored in a clean or known trusted state, such as, for example, an initially provisioned state, state data may be needed for the freshly invoked working copy of secure OS 218 to update the context to a more recent operational state. The state data may be associated with a previous execution of the secure OS working copy 218 and may be obtained from the secure cloud-based data synchronization server 102. This may allow for a seamless or smooth transition from the main OS working copy 216 to the secure OS working copy 218. In some embodiments, state data may include, for example, cookies, passwords, etc., associated with one or more previous sessions or transactions performed by the secure OS working copy 218.

Because the secure OS working copy 218 is launched from a clean state, updated with state data from a secure server over an encrypted communication link, and restricted to access of web sites that are on a filtered white list (e.g., trusted), a relatively high degree of confidence may be achieved with respect to the security of this system.

When secure operations have been completed, the updated or most recent state data associated with the secure OS working copy 218 may be transmitted back to the secure cloud-based data synchronization server 102, in an encrypted or otherwise secure manner, to be employed in connection with future invocations of the secure OS. The OS may then be switched back from secure OS working copy 218 to main OS working copy 216, for example by suspending the secure OS working copy 218 and re-loading and executing the main OS stored copy 206 through storage controller 204.

FIG. 3 illustrates a block diagram 300 of another example embodiment consistent with the present disclosure. Trusted execution environment (TEE) 210 is shown to include platform identity module 302, cloud authentication module 304, and encryption key storage and management module 306. Platform identity module 302 may be configured to identify and authenticate the platform 104 to the cloud server 102. Platform identity module 302 may use anonymous ID, such as, for example Enhanced Privacy ID (EPID), for trust establishment with the cloud server. Cloud authentication module 304 may be configured to authenticate the cloud server 102 to the platform. Cloud authentication module 304 may identify the cloud server using certified keys provided to the cloud by a trusted third-party. Encryption key storage and management module 306 may be configured to store and manage the encryption keys that are used to encrypt session data, state data and/or any other communication between the platform 104 and the cloud server 102. Encryption may increase assurance that data created on the platform 104 is bound to the platform (e.g., not accessible beyond the platform).

The TEE 210 provides security and isolation from other host entities that are outside the secure OS, such as, for example, the main OS and non-trusted applications. The isolation may prevent external entities from exercising control over the secure OS. In some embodiments, the TEE 210 may comprise separate physical hardware, for example an integrated circuit (IC) that is separate from an IC associated with the platform 104. In some embodiments, the TEE 210 may comprise a separate controller or processor within an IC that is shared with the platform 104. In some embodiments, the TEE 210 may comprise a separate domain within a controller or processor that is shared with the platform 104. Various techniques may be employed to securely isolate the TEE 210 including situations where hardware is being shared between the TEE 210 and the platform 104. These techniques may include privileged execution modes associated with the processor and access protection mechanisms associated with memory.

FIG. 4 illustrates a block diagram 400 of another example embodiment consistent with the present disclosure. Secure cloud-based data synchronization server 102 is shown to include file sharing module 402, state data sharing module 404, malware and privacy filtering module 406, platform binding module 408, OS patch manager 410 and encryption module 412. File sharing module 402 and state data sharing module 404 may be configured to securely store data, for example state or other context data, associated with the operation of the secure OS working copy 218 on platform 104, and in particular, data associated with transitions between the main OS working copy 216 and the secure OS working copy 218. Malware and privacy filtering module 406 may be configured to filter out malware and any other malicious software that may attempt to compromise the data or files stored on the cloud server 102.

Platform binding module 408 may be configured to exchange identification information and encryption keys with platform 104 to identify and authenticate the platform and bind that platform to the cloud server.

OS patch manager 410 may be configured to securely provide patches, updates and/or any other fixes (e.g., bug fixes) to the stored copy of secure OS 208 on platform 104. The stored copy of secure OS 208 may generally be considered a “clean” copy (e.g., an originally provisioned copy) that may, in some embodiments, be stored in read-only memory to provide protection against unauthorized and potentially malicious modifications. There may, however, be occasions when authorized updates to the stored copy of secure OS 208 are appropriate. OS patch manager may therefore be configured, possibly in combination with TEE 210 and/or storage controller 204, to circumvent read-only or other restrictions to the stored copy of secure OS 208 so that these updates may be applied.

Communications between cloud server 102 and platform 104 are secured by encryption module 412 which employs the encryption keys as discussed above.

FIG. 5 illustrates a flowchart of operations 500 of one example embodiment consistent with the present disclosure. At operation 510, a user accesses a website. At operation 520, a determination is made as to whether a high-value transaction is being conducted or a white listed website is being accessed. If the determination is negative, the main OS working copy, which was loaded and executed at run-time from a stored copy, continues execution at operation 530. If the determination is positive, the main OS working copy is suspended at operation 540. At operation 550, a switch is performed to a secure OS by loading and executing a working copy of the secure OS from a read-only stored copy of the secure OS. At operation 560, filtered state data, which may be associated with the context of a previous invocation of the secure OS, is fetched employing cloud server state data synchronization. At operation 570, the transaction with the website is performed. At operation 580, current state data associated with the working copy of the secure OS is synchronized with the cloud server. At operation 590, a switch is performed back to the main OS working copy.

FIG. 6 illustrates a flowchart of operations 600 of another example embodiment consistent with the present disclosure. An operation 610, an initial boot of the working copy of the secure OS is performed. At operation 620, the platform TEE uses anonymous ID, such as, for example Enhanced Privacy ID (EPID), for trust establishment with the cloud server. At operation 630, the platform TEE identifies the cloud server using certified keys provided to the cloud by a trusted third-party. At operation 640, the platform TEE exchanges cryptographic keys with the cloud server for use in future communications.

FIG. 7 illustrates a flowchart of operations 700 of another example embodiment consistent with the present disclosure. The operations provide a method for context based switching to a secure OS environment. At operation 710, web site access is monitored. At operation 720, transactions with the web site are classified. At operation 730, a switching event is identified. The switching event includes a match between the web site and a list of web sites associated with secure OS operation, and/or a match between the transaction classification and a list of transaction types associated with the secure OS operation. At operation 740, a switch is made from a main OS to the secure OS in response to the switching event. The secure OS is loaded from storage in an initially provisioned or clean state. At operation 750, state data associated with the secure OS is updated. The state data is received from a secure cloud-based data synchronization server.

Embodiments of the methods described herein may be implemented in a system that includes one or more storage mediums having stored thereon, individually or in combination, instructions that when executed by one or more processors perform the methods. Here, the processor may include, for example, a system CPU (e.g., core processor) and/or programmable circuitry. Thus, it is intended that operations according to the methods described herein may be distributed across a plurality of physical devices, such as processing structures at several different physical locations. Also, it is intended that the method operations may be performed individually or in a subcombination, as would be understood by one skilled in the art. Thus, not all of the operations of each of the flow charts need to be performed, and the present disclosure expressly intends that all subcombinations of such operations are enabled as would be understood by one of ordinary skill in the art.

The storage medium may include any type of tangible medium, for example, any type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), digital versatile disks (DVDs) and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic and static RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), flash memories, magnetic or optical cards, or any type of media suitable for storing electronic instructions.

“Circuitry”, as used in any embodiment herein, may include, for example, singly or in any combination, hardwired circuitry, programmable circuitry, state machine circuitry, and/or firmware that stores instructions executed by programmable circuitry. An app may be embodied as code or instructions which may be executed on programmable circuitry such as a host processor or other programmable circuitry. A module, as used in any embodiment herein, may be embodied as circuitry. The circuitry may be embodied as an integrated circuit, such as an integrated circuit chip.

Thus, the present disclosure provides devices, systems, methods and computer readable media for context based switching to a secure OS environment including cloud based data synchronization and filtration. The following examples pertain to further embodiments.

The device may include a storage controller configured to provide read-only access to the secure OS, the secure OS stored in an initially provisioned state. The device of this example may also include a context determination module configured to monitor web site access and to classify a transaction between the device and the website. The context determination module of this example device may further be configured to identify a switching event. The device of this example may further include an OS switching module configured to switch from a main OS to the secure OS in response to the switching event, and the switch to the secure OS includes: loading the secure OS from the storage controller and updating state data associated with the secure OS, the state data received from a secure cloud-based data synchronization server.

Another example device includes the forgoing components and the switching event is a match between the web site and a list of web sites associated with secure OS operation, and/or the switching event is a match between the transaction classification and a list of transaction types associated with secure OS operation.

Another example device includes the forgoing components and the OS switching module is further configured to save the state data associated with the secure OS to the secure cloud-based data synchronization server, and to switch from the secure OS back to the main OS.

Another example device includes the forgoing components and the state data includes cookies and/or passwords.

Another example device includes the forgoing components and further includes a TEE configured to provide encryption and authentication services associated with communication between the device and the secure cloud-based data synchronization server.

Another example device includes the forgoing components and the list of web sites associated with secure OS operation includes an ERM web site.

Another example device includes the forgoing components and the list of transaction types associated with secure OS operation includes a fund transfer or payment transaction.

Another example device includes the forgoing components and the storage controller is further configured to enable patch updates to the secure OS, the patch updates provided by the secure cloud-based data synchronization server.

Another example device includes the forgoing components and the secure cloud-based data synchronization server is configured to provide malware filtering of the state data.

According to another aspect there is provided a method. The method may include monitoring web site access. The method of this example may also include classifying transactions with the web site. The method of this example may further include identifying a switching event, and the switching event includes a match between the web site and a list of web sites associated with secure OS operation, and/or a match between the transaction classification and a list of transaction types associated with the secure OS operation. The method of this example may further include switching from a main OS to the secure OS in response to the switching event, and the secure OS is loaded from storage in an initially provisioned state. The method of this example may further include updating state data associated with the secure OS, the state data is received from a secure cloud-based data synchronization server.

Another example method includes the forgoing operations and further includes saving the state data associated with the secure OS to the secure cloud-based data synchronization server, and switching from the secure OS back to the main OS.

Another example method includes the forgoing operations and the state data includes cookies and/or passwords.

Another example method includes the forgoing operations and further includes providing a TEE to store and manage encryption keys.

Another example method includes the forgoing operations and further includes identifying, authenticating and communicating with the secure cloud-based data synchronization server using the encryption keys.

Another example method includes the forgoing operations and the web site associated with secure OS operation is an ERM web site.

Another example method includes the forgoing operations and the transaction type associated with secure OS operation is a fund transfer or payment transaction.

Another example method includes the forgoing operations and further includes applying patch updates to the secure OS, the patch updates provided by the secure cloud-based data synchronization server.

Another example method includes the forgoing operations and further includes malware filtering of the state data.

According to another aspect there is provided a system. The system may include a means for monitoring web site access. The system of this example may also include a means for classifying transactions with the web site. The system of this example may further include a means for identifying a switching event, and the switching event includes a match between the web site and a list of web sites associated with secure OS operation, and/or a match between the transaction classification and a list of transaction types associated with the secure OS operation. The system of this example may further include a means for switching from a main OS to the secure OS in response to the switching event, and the secure OS is loaded from storage in an initially provisioned state. The system of this example may further include a means for updating state data associated with the secure OS, the state data is received from a secure cloud-based data synchronization server.

Another example system includes the forgoing components and further includes a means for saving the state data associated with the secure OS to the secure cloud-based data synchronization server, and a means for switching from the secure OS back to the main OS.

Another example system includes the forgoing components and the state data includes cookies and/or passwords.

Another example system includes the forgoing components and further includes means for providing a TEE to store and means to manage encryption keys.

Another example system includes the forgoing components and further includes means for identifying, authenticating and communicating with the secure cloud-based data synchronization server using the encryption keys.

Another example system includes the forgoing components and the web site associated with secure OS operation is an ERM web site.

Another example system includes the forgoing components and the transaction type associated with secure OS operation is a fund transfer or payment transaction.

Another example system includes the forgoing components and further includes means for applying patch updates to the secure OS, the patch updates provided by the secure cloud-based data synchronization server.

Another example system includes the forgoing components and further includes means for malware filtering of the state data.

According to another aspect there is provided at least one computer-readable storage medium having instructions stored thereon which when executed by a processor, cause the processor to perform the operations of the method as described in any of the examples above.

According to another aspect there is provided an apparatus including means to perform a method as described in any of the examples above.

The terms and expressions which have been employed herein are used as terms of description and not of limitation, and there is no intention, in the use of such terms and expressions, of excluding any equivalents of the features shown and described (or portions thereof), and it is recognized that various modifications are possible within the scope of the claims. Accordingly, the claims are intended to cover all such equivalents. Various features, aspects, and embodiments have been described herein. The features, aspects, and embodiments are susceptible to combination with one another as well as to variation and modification, as will be understood by those having skill in the art. The present disclosure should, therefore, be considered to encompass such combinations, variations, and modifications.

Claims

1. One or more non-transitory computer-readable storage devices having instructions stored thereon which, when executed by at least one processor, result in operations for context-based switching to a secure operating system (OS), the operations comprising: identify a switching event, wherein the switching event corresponds to an indication of a possible security compromise of a main OS; andswitch from the main OS to the secure OS responsive to identifying the switching event, wherein the secure OS is executing in a trusted execution environment (TEE) isolated from the main OS.

2. The one or more non-transitory computer-readable storage devices of claim 1, wherein the instructions resulting in the operation identify a switching event, wherein the switching event corresponds to an indication of a possible security compromise of a main operating system (OS), when executed by the at least one processor, result in further operations comprising: identify one or more secure operations to be executed, wherein execution of the one or more secure operations in the main OS corresponds to an indication of a possible security compromise of the main OS.

3. The one or more non-transitory computer-readable storage devices of claim 2, wherein the instructions resulting in the operation identify one or more secure operations to be executed, when executed by the at least one processor, result in further operations comprising: monitor access to a web site;compare the web site to a list of web sites; andidentify one or more secure operations to be executed based, at least in part, on a result of the comparison.

4. The one or more non-transitory computer-readable storage devices of claim 2, having additional instructions stored thereon which, when executed by the at least one processor, result in further operations comprising: execute the secure operations in the secure OS.

5. The one or more non-transitory computer-readable storage devices of claim 4, further comprising additional instructions which, when executed by the at least one processor, result in additional operations comprising: switch from the secure OS to the main OS.

6. The one or more non-transitory computer-readable storage devices of claim 1, wherein the TEE is isolated from the main OS via memory access protection.

7. The one or more non-transitory computer-readable storage devices of claim 1, wherein the secure OS is accessed via read-only memory.

8. A device for context-based switching to a secure operating system (OS), the device comprising: context determination circuitry to identify a switching event, wherein the switching event corresponds to an indication of a possible security compromise of a main OS; andOS switching circuitry to switch from the main OS to the secure OS responsive to identification of the switching event, wherein the secure OS is executing in a trusted execution environment (TEE) isolated from the main OS.

9. The device of claim 8, wherein the context determination circuitry to identify a switching event, wherein the switching event corresponds to an indication of a possible security compromise of a main OS comprises: context determination circuitry to identify one or more secure operations to be executed, wherein execution of the one or more secure operations in the main OS corresponds to an indication of a possible security compromise of the main OS.

10. The device of claim 9, further comprising a processor to execute the one or more secure operations in the secure OS.

11. The device of claim 10, wherein the OS switching circuitry is to switch from the secure OS to the main OS responsive to the one or secure operations being executed.

12. The device of claim 8, wherein the TEE is isolated from the main OS via memory access protection.

13. The device of claim 8, wherein the secure OS is stored in read-only memory.

14. The device of claim 8, wherein the device comprises one of a smart phone, a tablet computer, a laptop computer, or a desktop computer.

15. A method for context-based switching to a secure operating system (OS), the method comprising: identifying a switching event, wherein the switching event corresponds to an indication of a possible security compromise of a main OS; andswitching from the main OS to the secure OS responsive to identifying the switching event, wherein the secure OS is executing in a trusted execution environment (TEE) isolated from the main OS.

16. The method of claim 15, wherein identifying a switching event, wherein the switching event corresponds to an indication of a possible security compromise of a main OS comprises: identifying one or more secure operations to be executed, wherein execution of the one or more secure operations in the main OS corresponds to an indication of a possible security compromise of the main OS.

17. The method of claim 16, further comprising executing the secure operations in the secure OS.

18. The method of claim 17, further comprising switching from the secure OS to the main OS responsive executing the secure operations in the secure OS.

19. The method of claim 15, wherein the TEE is isolated from the main OS via memory access protection.

20. The method of claim 15, wherein the secure OS is accessible via read-only memory.