HK40061174B - Mitigation of ransomware in integrated, isolated applications - Google Patents

Description

Suppressing and isolating ransomware in integrated applications

Background Technology

In an isolated computing deployment, applications can be executed in an environment that is partially or completely isolated from the main computing environment of the host machine. This isolation provides additional security to the host environment by restricting and/or preventing applications from accessing its resources. In many cases, applications running in an isolated environment may be untrusted or may be more vulnerable to malicious activity; therefore, from a security perspective, creating an isolation barrier between the application and the host environment becomes increasingly important. In other words, even if malicious code executes in the application's isolated environment, the risk to the host environment can be minimized due to the isolation barrier.

However, to enhance the user experience, certain vulnerabilities may intentionally exist within the isolation barrier, such as allowing applications in the isolated environment to access files in the host environment. While such vulnerabilities in the isolation barrier might improve integration between the isolated and host environments, these seemingly benign attempts to enhance the user experience can create security weaknesses in the host environment. For example, malicious code called ransomware, which could enter the isolated environment, could use encryption keys known only to the attacker to encrypt personal data stored in the host environment. In this scenario, the user is forced to pay a ransom to the attacker to regain access to their data. Therefore, even if applications can be isolated, openings in the isolation barrier can still lead to these and other types of weaknesses.

Summary of the Invention

This summary is provided to present a simplified description of the selection of concepts further described below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

Methods, systems, apparatus, and computer program products are provided for enabling secure access to resources. A token request from an application (e.g., a virtual machine) executing in a first computing environment can be received in a second computing environment (e.g., a host computing environment). The host computing environment can assign a trust level to the received token request, such as a trust level indicating that the first computing environment should not be trusted. The token request, along with the corresponding trust level, can be provided to a token issuer (e.g., on an authorization server), which can verify the identity information in the token and generate an authorization token including a trust indication. The trust indication can indicate, for example, the trust level of the second computing environment. The host computing environment can obtain the authorization token and provide it to the application. When the application executing in the second computing environment transmits the authorization token to a resource manager to access the resource, the resource manager can be configured to perform preventative actions, such as creating a backup of the resource, before granting access.

Other features and advantages of the invention, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It should be noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to those skilled in the art based on the teachings contained herein.

Attached Figure Description

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present application and, together with the description, serve to explain the principles of the embodiments and enable those skilled in the art to make and use the embodiments.

Figure 1 shows a block diagram of a system for providing secure access to resources according to an example embodiment.

Figure 2 shows a flowchart of a method for providing an application with authorization, including a trust indication, according to an example embodiment.

Figure 3 shows a block diagram of a system for providing secure access to network resources according to an example embodiment.

Figure 4 shows a flowchart of a method for generating an authorization token including a trust indication according to an example embodiment.

Figure 5 shows a flowchart of a method for performing preventative actions to protect resources according to an example embodiment.

Figure 6 shows a block diagram of a system for providing secure access to local resources according to an example embodiment.

Figure 7 is a block diagram of an example computing device that can be used to implement the example embodiments.

The features and advantages of the invention will become more apparent from the following detailed description when taken in conjunction with the accompanying drawings, wherein the same reference numerals consistently identify corresponding elements. In the drawings, the same reference numerals generally indicate the same, functionally similar, and/or structurally similar elements. The first appearance of an element in the drawings is indicated by the leftmost numeral(s) of the corresponding reference numeral(s).

Detailed Implementation

I. Introduction

This specification and accompanying drawings disclose one or more embodiments incorporating the features of the present invention. The scope of the invention is not limited to the disclosed embodiments. The disclosed embodiments are merely illustrative of the invention, and modifications to the disclosed embodiments are also covered by the invention. The embodiments of the invention are defined by the appended claims.

References to "an embodiment," "an embodiment," "an exemplary embodiment," etc., in the specification indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may not necessarily include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in conjunction with an exemplary embodiment, whether explicitly described or not, it is asserted that such feature, structure, or characteristic can be implemented in conjunction with other embodiments within the knowledge of those skilled in the art.

In this discussion, unless otherwise specified, adjectives such as “substantially” and “approximately” that modify one or more features of the exemplary embodiments of this disclosure are understood to mean that the condition or feature is defined within the operational tolerances acceptable for the intended application of the embodiment.

Many exemplary embodiments are described below. It should be noted that any section/subsection headings provided herein are not intended to be limiting. Embodiments are described in this document, and embodiments of any type may be included under any section/subsection. Furthermore, embodiments disclosed in any section/subsection may be combined in any way with any other embodiments described in the same and/or different sections/subsections.

II. Example Implementation

In an isolated computing deployment, applications can run in an environment that is partially or completely isolated from the main computing environment of the host machine. This isolation provides additional security to the host environment by restricting and/or preventing applications from accessing its resources. In many cases, applications running in an isolated environment may be untrusted or potentially more vulnerable to malicious activity; therefore, from a security perspective, establishing a barrier between the application and the host environment becomes crucial. In other words, even if malicious code executes in the application's isolated environment, the risk to the host environment can be minimized due to the isolation barrier.

However, to enhance the user experience, certain vulnerabilities may intentionally exist within the isolation barrier, such as allowing applications in the isolated environment to access files in the host environment. While such vulnerabilities in the isolation barrier might improve integration between the isolated and host environments, these seemingly benign attempts to enhance the user experience can create security weaknesses in the host environment. For example, malicious code called ransomware, which could enter the isolated environment, could use encryption keys known only to the attacker to encrypt personal data stored in the host environment. In this scenario, the user is forced to pay a ransom to the attacker to regain access to their data. Therefore, even if applications can be isolated, openings in the isolation barrier can still lead to these and other types of weaknesses.

The embodiments described herein address these and other problems by providing a system for enabling trusted access to resources. In the example system, a first environment that receives a token request from another environment (e.g., an application running on a virtual machine in the first environment) that is at least partially isolated from it can obtain an authorization token that includes a trust indication. The trust indication can indicate the trust level of the environment in which the token request was initiated, which may include untrusted environments that may be vulnerable to malicious activity. When an application attempts to access a trusted resource using an authorization token, the resource provider may take preventative actions.

In this way, resources can be protected from malicious activities or malicious code, such as ransomware or any other type of malware, malicious code, or breaches by unauthorized entities attempting to access user resources (such as data or services). For example, even if an attacker attempts to encrypt user data to collect a ransom, a backup copy of the user resource may be automatically created when the attacker accesses the data based on the trust instructions included in the authorization token. This backup copy of the user resource, which may be stored and/or encrypted in a way inaccessible to the attacker, can be later restored by the user, eliminating the need to pay a ransom to the attacker. Therefore, harm caused by malicious activities in a less trusted computing environment can be reduced or completely prevented.

Access to resources using the secure methods described herein offers numerous advantages, including enhanced security for the network and/or its coupled resources (e.g., computing devices, storage devices, etc.). For example, by providing an authorization token that includes a trust indication, a resource provider (which may be a local resource provider or a network-accessible resource server) that grants access to the resource in response to receiving the authorization token can take one or more preventative actions to protect the resource, such as creating a backup copy of the resource, restricting access (e.g., providing only read-only access instead of read/write access), implementing enhanced authentication procedures (e.g., two-factor authentication), or other preventative actions. Thus, the resource can be protected against malicious activity originating from an environment (perceived as less secure). Furthermore, because the resource provider can receive an authentication token that includes an embedded trust indication, the resource provider can be configured to detect the presence of anomalous network activity (e.g., where a particular application is using such an authorization token to access an unusually large number of resources). Therefore, as described herein, malicious activity occurring on the network and/or within its coupled resources can be contained, mitigated, and/or prevented.

Example embodiments are described below for systems and methods used to securely provide access to resources. For example, FIG1 shows a block diagram of system 100 according to an example embodiment. As shown in FIG1, system 100 includes a computing device 102, an authorization server 108, and a resource server 112 communicatively coupled via a network 120, and a secure resource 116 coupled to the resource server 112. System 100 may include any number of computing devices and/or servers, including those illustrated in FIG1 and one or more other devices not explicitly illustrated. As shown in FIG1, computing device 102 includes a virtual machine 104 hosted therein and an authorization token manager 106. As described in more detail below, authorization token manager 106 may be configured to receive a token request from an application executing on virtual machine 104, obtain an authorization token with a trust indication, and provide the authorization token including the trust indication to the application in virtual machine 104. Authorization server 108 includes a token issuer 110. Resource server 112 includes a resource manager 114. Although FIG1 is described with respect to an application executing on virtual machine 104, this implementation is not intended to be limiting. As described later, other types of partially and/or fully isolated computing environments that token requests can generate are also envisioned. System 100 is further described below.

Network 120 may include one or more of any of a local area network (LAN), a wide area network (WAN), a personal area network (PAN), a combination of communication networks such as the Internet, and/or a virtual network. In an example implementation, computing device 102, authorization server 108, resource server 112, and/or security resource 116 may be communicatively coupled to each other via network 120. In the implementation, any one or more of computing device 102, authorization server 108, resource server 112, and/or security resource 116 may communicate via one or more application programming interfaces (APIs) and/or according to other interfaces and/or technologies. Computing device 102, authorization server 108, resource server 112, and/or security resource 116 may each include at least one network interface capable of communicating with each other. Examples of such wired or wireless network interfaces include IEEE 802.11 Wireless LAN (WLAN) wireless interfaces, Wi-MAX interfaces, Ethernet interfaces, Universal Serial Bus (USB) interfaces, cellular network interfaces, Bluetooth ^™ interfaces, Near Field Communication (NFC) interfaces, etc. Other examples of network interfaces are described elsewhere in this article.

Computing device 102 includes any computing device belonging to one or more users (e.g., individual users, home users, enterprise users, government users, etc.). This computing device may include one or more applications, operating systems, virtual machines, storage devices, etc., which may be executed, hosted, and/or stored within or via one or more other computing devices through network 120. In some examples, computing device 102 may access one or more server devices, such as authentication server 108 and/or resource server 112, to access one or more security resources 116, as described herein. Computing device 102 may include any number of computing devices, including tens, hundreds, thousands, millions, or even more. The computing device 102 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., devices, personal digital assistants (PDAs), laptops, notebook computers, tablet computers (such as Apple iPad ^™ , netbooks, etc.), mobile phones, wearable computing devices, or other types of mobile or stationary computing devices (such as desktop computers or PCs (personal computers)) or servers. The computing device 102 is not limited to a physical machine but can include other types of machines or nodes, such as virtual machines. The computing device 102 can interface with the authorization server 108 and/or resource server 112 via APIs and/or other mechanisms. It should be noted that any number of program interfaces may exist.

Authorization server 108 may include any computing device, server, and/or service for issuing one or more authorization tokens to computing devices of network 120 that request such tokens. As described in more detail below, authorization tokens may include any object (e.g., a dataset) that enables computing devices, computing environments, and/or applications to access resources. For example, an authorization token may be a file or other object that includes one or more of the following: an identifier for the token, an identifier for the associated login session, an identifier for the application requesting access, a user identifier for the user of the application requesting access, and an indication of one or more privileges provided by the authorization token.

In some examples, the authorization server 108 may include an identity service or identity provider configured to verify the identity information of the entity requesting the authorization token, including but not limited to user login credentials (e.g., username and/or password), user aliases, accounts, biometric information, or any other information or credentials that can be used for secure access to resources. Depending on the implementation, the token issuer 110 of the authorization server 108 may generate and issue tokens to be transmitted to the computing device 102. These tokens may also include a trust indication that may indicate the trust level of the environment in which the token is requested and/or is intended to be used to access resources (e.g., secure resource 116). In some instances, the authorization server 108 may be configured to provide access to multiple resources unrelated to and/or not affiliated with the authorization server 108 based on verified identity information. In some other instances, the authorization server 108 and/or resource server 112 may include affiliated entities and/or may be implemented on a single server or a collection of servers.

Resource server 112 may include any one or more computing devices, servers, services, local processes, remote machines, web services, etc., for hosting, managing, and/or providing access to secure resource 116 by users of computing device 102. For example, resource server 112 may include servers located at an organizational site and/or coupled to an organization's local network, remote servers, cloud-based servers (e.g., one or more servers in a distributed manner), or any other device or service that can host, manage, and/or provide access to secure resource 116. Secure resource 116 may include any type of resource coupled to the network, including but not limited to computing or processing resources, software resources (e.g., Software as a Service (SaaS), Platform as a Service (PaaS), etc.), storage resources (e.g., physical storage devices, local storage devices, cloud-based storage devices, hard disk drives, solid-state drives, random access memory (RAM) devices, etc.), databases, etc.

For example, secure resource 116 may include a storage device for storing any data that is confidential, critical, private, secure, and/or not intended to be otherwise publicly disclosed (such as personal information, educational information, health information, professional information, organizational or company information, bank or other financial records, legal documents, biographical information such as birth certificates, driver's licenses, passports, etc.). These examples are merely illustrative, and secure resource 116 may include any other type of data (including confidential and non-confidential information) that can be stored on any device, whether local and/or cloud-based storage. In some examples, secure resource 116 may be stored securely, such as through password protection, encryption (e.g., public and private key encryption, symmetric keys, etc.), or any other secure method known to those skilled in the art, such that read/write access can only be granted by the data owner.

In the example embodiment, computing device 102 may include multiple computing environments, including but not limited to a host computing environment (e.g., an environment on which the primary operating system of computing device 102 is running) and one or more other computing environments that may be completely or partially isolated from the host computing environment. For example, such an isolated environment may include virtual machine 104 and/or applications running therein. In the example, virtual machine 104 and/or applications running therein may be restricted from accessing resources outside the isolated environment by isolation mechanisms (e.g., containers managed by the host operating system), without any “loophole” provided in the isolation barrier or authorization token that permits the application running in the isolated environment to access external resources (e.g., stored in the host computing environment and/or stored in another device accessible via network 120).

In the example, when an application in virtual machine 104 requests access to resources outside of virtual machine 104, the application can submit a token request for an appropriate authorization token to authorization token manager 106. Depending on the implementation, authorization token manager 106 can be configured to assign a trust level to the token request. For example, the trust level could indicate that virtual machine 104 and/or the application executing therein is not trusted and/or vulnerable to harm or corruption. Authorization token manager 106 can submit a token request and the assigned trust level to token issuer 110 to obtain an authorization token. Token issuer 110 can verify identity information (e.g., login credentials) and generate an authorization token that includes an embedded trust indication. Token issuer 110 can provide authorization token including the embedded trust indication to authorization token manager 106, which can then provide the authorization token to the requesting application executing in virtual machine 104.

When an application attempts to access an external resource such as secure resource 116 using an authorization token, resource manager 114 can extract a trust indication from the authorization token. Therefore, if the trust indication indicates that the authorization token was issued in an untrusted environment (e.g., potentially vulnerable to various types of malicious activity, such as ransomware attacks), resource manager 114 can perform preventative actions (e.g., creating a backup) to protect secure resource 116 before granting access to the application.

It should be noted and understood that the implementation is not limited to the illustrative arrangement shown in Figure 1. Rather, network 120 may include any number of computing devices and/or servers (including, but not limited to, machines and/or virtual machines) coupled in any manner. For example, although computing device 102 is shown as separate from authorization server 108, resource server 112, and security resource 116, in embodiments, one or more of computing device 102, authorization server 108, resource server 112, and/or security resource (or components thereof) may be located in the same location, remote from each other, may be implemented on a single computing device or virtual machine, or may be implemented or distributed across one or more additional computing devices or virtual machines not explicitly illustrated in Figure 1. An example of an arrangement in which the authorization token manager, token issuer 110, resource manager 114, and security resource 116 may be implemented in a computing device is illustrated in Figure 6, as described in more detail below.

The authorization token manager 106 can operate in various ways to enable secure access to resources. For example, the authorization token manager 106 can operate according to FIG2. FIG2 shows a flowchart 200 of a method for providing authorization, including a trust indication, to an application according to an example embodiment. For illustrative purposes, flowchart 200 and authorization token manager 106 are described below with respect to FIG3.

Figure 3 illustrates a block diagram of a system 300 for providing secure access to network resources according to an example embodiment. As shown in Figure 3, system 300 includes an example implementation of a computing device 102, an authorization server 108, and a resource server 112. The computing device 102 includes a virtual machine 104 and an authorization token manager 106. The virtual machine 104 may include an application 302 executed therein. The authorization token manager 106 may include a trust level allocator 304 and a token requester 306. The authorization server 108 includes a token issuer 110. The token issuer 110 includes an authenticator 314 and a token generator 316. The resource server includes a resource manager 114. The resource manager 114 includes a resource access provider 318 and a resource protector 320. The resource manager 114 may be coupled to a secure resource 116 and a resource snapshot 322. As shown in system 300 of Figure 3, the authorization token manager 106 may transmit a token request 308 and an associated trust level 310 to the token issuer 110. Token issuer 110 can generate an authorization token 312 that includes a trust indication that can be embedded therein. Authorization token manager 106 can provide the authorization token to application 302. Subsequently, when application 302 provides the authorization token to resource manager 114 to access secure resource 116, resource manager 114 can be configured to perform preventative actions to protect secure resource 116 before granting access to such resource. Flowchart 200 and system 300 are described in more detail below.

Flowchart 200 of Figure 2 begins at step 202. In step 202, a token request is received from an application executing in a second computing environment that is at least partially isolated from the first computing environment to access resources. For example, referring to Figure 3, a trust level allocator 304 may be configured to receive a token request 324 from application 302. Virtual machine 104 may include a computing environment that is partially or completely isolated from another computing environment (e.g., a host environment where the primary operating system of computing device 102 may be executing). For example, virtual machine 104 may include an operating system (e.g., of the same or different type as the operating system executing in the host environment) and/or one or more applications executing therein. Virtual machine 104 runs on top of the primary operating system of computing device 102. Application 302 may include any type of application that can execute on virtual machine 104, including but not limited to software packages, web applications, web services, or any other code or binaries that can execute on or within virtual machine 104 or that are installed in or accessed from a remote computing or server. In the example embodiment, virtual machine 104 and/or application 302 may be untrusted due to any number of factors (e.g., may be insecure, vulnerable to execution of malicious code, etc.), including but not limited to the type of application executed by the user of virtual machine 104, remote services or websites accessed by the user that may potentially exploit application 302 and/or virtual machine 104, and/or inherent aspects of virtual machine 104 or application 302 itself (e.g., the operating system running on virtual machine 104 may be considered completely untrusted).

Although Figure 3 depicts computing device 102 as potentially including virtual machines and applications running therein, implementations are not limited to this particular arrangement. For example, an isolated computing environment on computing device 102 may include applications running on computing device 102 (e.g., on the same primary operating system as the host environment), such as in guest, private, or stealth modes, arrangements including one or more fully or partially isolated containerized or sandboxed processes or applications, computing environments of a first central processing unit (CPU) separated from the computing environment of a second CPU (on the same or different circuit boards or motherboards), or applications running in other modes or arrangements where a fully or partially isolated boundary can be established between the executing application and the host computing environment.

In the example, through user interaction or in response to software executing on virtual machine 104, application 302 may attempt to connect to resources outside virtual machine 104, such as secure resource 116. For example, application 302 may attempt to connect to a cloud-based file server remote from virtual machine 104 and/or computing device 102. To access such secure resource 116, application 302 may need to provide an appropriate authorization token to resource manager 114. In the implementation, the token request for such authorization token generated by application 302 can be redirected so that the token request is provided to the host computing environment. For example, referring to Figure 3, the request for authorization token initiated by application 302 can be redirected to trust level allocator 304, indicating that the application is seeking access to certain resources. Trust level allocator 304 can receive such requests through one or more vulnerabilities provided in the isolation barrier implemented between virtual machine 104 and the host computing environment of computing device 102.

The authorization request received by the trust level allocator 304 from the application 302 may include an identifier for accessing the requested resource (e.g., an identifier for security resource 116), an identifier for the requesting application, login credentials for the appropriate authorization entity (e.g., an identifier provider), the type of access requested (e.g., read-only access, read/write access, etc.), the duration for which the token is requested, and any other information that may be associated with the authorization token request and is known to a person skilled in the art.

In step 204, a trust level is assigned to the token request. For example, referring to FIG3, a trust level allocator 304 can be configured to assign a trust level to a token request received by an application 302 executing in virtual machine 104. In some examples, as previously described, virtual machine 104 and/or one or more applications executing therein can be considered untrusted. In such an example, trust level allocator 304 can assign a trust level indicating that the entity requesting the token request (e.g., by identifying that application 302 and/or virtual machine 104) is not trusted. In some other implementations, trust level allocator 304 can assign a trust level that includes a gradation, such as an alphanumeric value, that can indicate the level of trustworthiness of the token request based on a predetermined proportion.

In the example, trust level allocator 304 can allocate trust levels in various ways. For example, trust level allocator 304 can allocate trust levels based on predetermined knowledge about the characteristics of the isolated computing environment (e.g., stored in a database or other data structure), such as the identifiers of virtual machine 104, the operating system running on virtual machine 104, and/or any other application 302 that may be running there. In an illustrative example, trust level allocator 304 can automatically assume that certain types of token requests (or all token requests) originating from the isolated environment are untrusted and therefore assign a reduced trust level to each such token request. In other examples, trust level allocator 304 can assign a reduced trust level to token requests associated with certain applications, operating systems, or virtual machines that may be hosted as part of the isolated environment on computing device 102. In other examples, trust level allocator 304 can assign trust levels to token requests received from application 302 based on on-the-fly determination. Trust levels can be indicated in any form, including numerical values (e.g., in the range of 0 to 10, where "0" means no trust and "10" means the highest trust), text values (e.g., "high", "medium", "low", "none", etc.), alphanumeric values, strings, etc.

In step 206, an authorization token, including a trust indication corresponding to the trust level of the token request, is obtained. For example, referring to FIG3, token requester 306 may obtain authorization token 312 including a trust indication from token issuer 110. Token requester 306 may obtain authorization token 312 in various ways. In the illustrative arrangement shown in FIG3, for example, token requester 306 may be configured to obtain trust level 310 328 from trust level allocator 304. Token requester 306 may send trust level 310 332 and authenticator 314 that sends token request 308 330 to token issuer 110 based on one or more API or network calls. Token request 308 may include information associated with the requested access described previously, such as login credentials, an identifier of the resource to be accessed, the scope of the requested access, etc. Token request 308 may correspond to token request 304 (e.g., for accessing a resource) and associated trust level received by trust level allocator from application 302. For example, if the trust level assignment indicates that virtual machine 104 and/or application 302 are not trusted at a certain trust level, token requester 306 can transmit token request 308 and the assigned trust level 310 to the appropriate token issuance service to obtain a token that enables access to the requested resource.

In implementation, token request 308 may be sent separately from trust level 310 (e.g., in different data packets, sequentially, out of order, etc.). In some other examples, token request 308 and trust level 310 may be sent together (e.g., as part of the same data packet or set of data packets). For example, trust level 310 may be attached to, included in, or otherwise sent with token request 308 as a tag, identifier, mark, flag, claim, metadata, new or revised scope associated with the request, etc. Implementations are not limited to these illustrative examples and may include any other means of transmitting trust level 310 along with token request 308 to a token issuer (e.g., token issuer 110), whereby token request 308 may indicate trust information for the token request (e.g., the trust level of virtual machine 104 and/or application 302).

In the example, token generator 316 can generate authorization token 312, which includes a trust indication indicating the trust level of the environment in which the token can be used. The trust indication can include any suitable format (e.g., numbers, text, strings, etc.) and can be included within, appended to, merged with, or otherwise associated with authorization token 312. For example, the trust indication can similarly include tags, identifiers, marks, flags, claims, metadata, new or revised scopes, etc., which are part of or integrated with authorization token 312. In the example where authorization token 312 is a file, the trust indication can be written into existing fields or as a new entry in the file. By including the trust indication, authorization token 312 is considered "tagged." Therefore, in the implementation, authorization token 312 can include a tag indicating that the requesting entity may be insecure. In the example, token generator 316 can send authorization token 312 including the trust indication to token requester 306 (e.g., via a network).

In step 208, an authorization token including a trust indication is provided to the application executing in the second computing environment. For example, referring to FIG3, a token requester 306 may be configured to provide an authorization token 312 including a trust indication to an application 302 executing on virtual machine 104. In an implementation, the token requester 306 may pass the authorization token 312 to the application 302 without modifying the authorization token. The application 302 can then use the authorization token 312 to access resources, such as secure resource 116 (or resources that may be stored locally on computing device 102). In the example, because the trust indication is included as part of the authorization token 312, the application 302 (or any malicious code that may be executing on virtual machine 104) may not change the received authorization token. In other words, if the authorization token is changed by any activity occurring in a potentially compromised environment (e.g., virtual machine 104), the changed authorization token will not be able to access the resource provider's resources because the changed authorization token cannot be verified between the resource provider and the authorization service (e.g., token issuer 110 and resource manager 114, as shown in the example of FIG3). Therefore, trust instructions can be embedded into the authorization token in a way that cannot be modified, thereby enhancing the integrity of the authorization token.

As will be described in more detail below, when application 302 attempts to access a resource by sending the received authorization token 336 to the appropriate resource provider, the resource provider can be configured to extract (e.g., read or copy) the trust indication from the authorization token and determine whether preventative actions should be performed before granting access to the resource. For example, if resource protector 320 extracts a trust indication indicating that application 302 and/or virtual machine 104 may be insecure, resource protector 320 can be configured to protect the secure resource 116 by creating a backup of the requested resource (e.g., by creating a resource snapshot 322) before granting access to such resource 338. An example flowchart depicting the execution of preventative actions to protect the resource will be described in more detail below relative to Figure 6.

As described above, token issuer 110 can be configured to generate authorization tokens including trust indications in various ways. For example, FIG4 shows a flowchart 400 of a method for generating authorization tokens including trust indications according to an example embodiment. In an implementation, the method of flowchart 400 can be implemented by authenticator 314 and token generator 316. FIG4 continues to be described with reference to FIG3. Based on the following discussion of flowchart 400 and system 300 of FIG3, other structural and operational implementations will be apparent to those skilled in the art.

Flowchart 400 begins at step 402. In step 402, a token request is received, which includes identity information and an indication that the token request was initiated in an application in a second computing environment at least partially isolated from the first computing environment. For example, referring to Figure 3, the authenticator 314 of the authorization server 108 may be configured to receive a token request 308, which includes identity information and a trust level 310 indicating an associated trust level. In this example, the identity information may include one or more of the following: user login credentials (e.g., username and/or password), user alias, account, biometric information, or any other information or credentials that the authenticator 314 can verify to determine whether access to a resource (e.g., secure resource 116) is permitted. As previously described, trust level 310 may include information corresponding to the trust level of the environment in which the token request 308 was initiated. For example, referring to Figure 3, trust level 310 may indicate the trust level associated with the application 302 executing in virtual machine 104. In other examples, trust level 310 may include a flag or other indication indicating that the request was initiated in an environment different from or within the host computing environment. These examples are merely illustrative, and trust level 310 may include any type of information (such as flags, tags, claims, metadata, etc.) that indicates that token request 308 may originate from a potentially untrusted environment.

In step 404, the identity information is verified. For example, referring to Figure 3, authenticator 314 can be configured to verify the identity information received in token request 308 to determine whether the requesting entity is permitted to obtain an authorization token allowing access to the requested resource. Authenticator 314 can verify the identity information in various ways that will be known to those skilled in the art, such as by looking up and comparing the identity information in a database (e.g., a user or account database), or by providing the identity information to another server or service for verification. For example, if verification fails (e.g., an incorrect user credential is received), authenticator 314 can determine that access should not be permitted, and therefore no authorization token will be provided to application 302. In the case of successful verification, authenticator 314 can allow token generator 316 to generate an appropriate authorization token, which can be provided to application 302 to access the requested resource.

In step 406, an authorization token including a trust indication is generated. For example, referring to FIG3, token generator 316 may be configured to generate authorization token 312, which includes a trust indication indicating the trust level of the computing environment in which token request 308 was initiated. In the example, the trust indication may indicate the trust level associated with virtual machine 104 and/or application 302 executed therein, such as by indicating that the computing environment is not trusted. As previously described, the trust indication may be embedded in authorization token 312 and may include any suitable form, including tags, marks, symbols, claims, etc., that may indicate to the resource provider (e.g., resource server 112) that the authorization token may be used by an application in an untrusted computing environment.

In some example implementations, the trust indicator can differ for each received token request. For instance, certain types of isolated environments (e.g., certain applications and/or operating systems running within them that are known to be insecure) may be considered less trustworthy than other applications or operating systems, so the trust indicator for such a less trustworthy application or operating system might indicate a further reduced level of trust. In other examples, the trust indicator may include different types of indicators, such as those for cases where an application might be considered only potentially trustworthy (as opposed to being labeled insecure). In this way, the token generator 316 can tag the authorization token 312 with an appropriate trust indicator that indicates the trust level of the application in an untrusted environment, thereby enabling the resource provider to perform different precautions based on the embedded trust indicator.

Authorization token 312 may include any type of token that enables a computing entity (such as an application, service, etc.) to access a resource. Examples of authorization token 312 include, but are not limited to, web tokens, access tokens, tokens generated according to the Open Authorization (OAuth) standard, Windows NT tokens, etc., that enable access to web or other network-accessible resources. Authorization token 312 may be generated for a specific requesting application or a specific resource, or may include a single token associated with multiple such applications.

In some example embodiments, the token generator 316 may also be configured to store each generated authorization token 312 in a suitable storage device (locally or in one or more cloud-based storage devices). Thus, when application 302 attempts to access a resource by providing authorization token 312 to resource manager 114, resource protector 320 can obtain the authorization token stored at authorization server 108 to verify the authenticity of the token received from application 302 prior to authorizing access to the requested resource. In other instances, the token generator 316 may also be configured to resend previously generated and expired tokens (including trust indications) to token requester 306, such as where token generator 316 previously generated an authorization token corresponding to application 302's access to the same resource.

In step 408, an authorization token, including a trust indication, is provided to the application executing in the second computing environment. For example, referring to FIG3, the token generator 316 may be configured to transmit the authorization token 312 to the token requester 306 for provision to the application 302 (e.g., by passing the authorization token 312 across an isolation boundary) and/or by providing the authorization token 312 directly to the application 302 (e.g., without transmitting the token to the token requester 306 as an intermediary). As described above, the application 302 can use the authorization token 312 to access the requested resource.

As described herein, resource manager 114 can be configured to protect secure resource 116 in response to receiving an authorization token. For example, Figure 5 shows a flowchart of a method for performing preventative actions to protect a resource according to an example embodiment. In an implementation, the method of flowchart 500 can be implemented by resource access provider 318 and resource protector 320. Figure 5 continues to be described with reference to Figure 3. Based on the following discussion of flowchart 500 and system 300 of Figure 3, other structural and operational implementations will be apparent to those skilled in the art.

Flowchart 500 begins at step 502. In step 502, an authorization token is received from an application executing in the computing environment. For example, referring to Figure 3, resource protector 320 may be configured to receive authorization token 312 from application 302 executing in virtual machine 104 via network 120. As described herein, authorization token 312 may also include a trust indicator that indicates the trust level of the environment associated with authorization token 312. Thus, in this example, the trust indicator may indicate the trust level of the computing environment in virtual machine 104 and/or application 302 that may be executing.

However, it should be noted that in some other example embodiments, the authorization token 312 may not include a trust indication, such as when the token request originates from a trusted environment (e.g., from an application running on a primary operating system of a computing device). For example, if a trusted application (or an application running in a trusted environment) requests an authorization token, the generated authorization may not include a trust indication for such an application. Therefore, in some examples, the resource protector 320 may also be configured to determine whether a trust indication is present in the received authorization token.

As previously described, after application 302 obtains authorization token 312, application 302 may attempt to access resources consistent with the scope of the authorized authorization token by interacting with an appropriate resource provider, such as resource server 112. In the example, application 302 may also provide authorization token 312 to resource protector 320 in conjunction with the attempt to access the resource. Resource protector 320 may verify the authenticity of authorization token 312 in a manner similar to that previously described, such as by interacting with authorization server 108 to determine whether the authentication token received from application 302 is valid and/or has not expired.

In step 504, the trust indication is extracted from the authorization token. For example, resource protector 320 can be configured to parse authorization token 312 to extract the trust indication. For example, resource protector 320 can extract such an indication if it is embedded in authorization token 312 as an identifier, tag, flag, claim, metadata, etc. In some implementations, resource protector 320 may also obtain the trust indication from authorization server 108 (e.g., when the authenticity of the received token is verified).

In step 506, preventative actions are determined to be performed to protect the resource. For example, referring to FIG3, the resource protector 320 may be configured to determine preventative actions to be performed to protect the resource in response to receiving an authorization token and extracting a trust indication. For example, if the trust indication indicates that the environment in which the authorization token 312 was received is untrusted, the resource protector 320 may determine one or more preventative actions to be performed to protect the secure resource 116. Preventative actions may include any type of action performed to prevent (e.g., preempt) or mitigate potential malicious alterations to the secure resource 116.

For example, if the extracted trust indication indicates that the computing environment in which the authorization token 312 was received is untrusted, the resource protector 320 can be configured to perform certain actions to prevent user data from being corrupted, damaged, and/or destroyed. In some examples, the resource protector 320 can determine that multiple preventative actions should be performed. In some other instances, the resource protector 320 can determine that preventative actions do not need to be performed, such as when the authentication token is received from a computing environment known to be trusted by the resource server 112. In some other instances, the resource protector 320 can also determine not to perform preventative actions, such as when the resource protector 320 deems application 302 not malicious based on a previous access where the same authorization token was provided to application 302.

In step 508, in response to receiving an authorization token, preventative actions are performed to protect the resource. For example, referring to FIG3, resource protector 320 may be configured to perform one or more preventative actions to protect secure resource 116 in response to receiving authorization token 312 from application 302. In this example, the type (or types) of preventative actions performed to protect secure resource 116 may be based on a combination of factors, including the type of resource being accessed, the scope of access (e.g., read-only access, resource modification, etc.), and/or the trust level that may be indicated by a trust indicator in authorization token 312. For example, if the accessed resource has been identified as sensitive and/or important, resource protector 320 may be configured to perform one or more security measures to protect the resource. In another example, if the extracted trust indicator indicates that the computing environment (e.g., application 302) to which authorization token 312 was received is known to be untrusted, resource protector 320 may perform one or more enhanced security measures to protect secure resource 116.

In one example, resource protector 320 may be configured to automatically create resource snapshot 322 in response to receiving an authorization token 312 indicating that application 302 is not trusted. Resource snapshot 322 may include, for example, a backup copy of secure resource 116 that application 302 cannot access, even with authorization token 312. In some implementations, resource protector 320 may generate resource snapshot 322 of secure resource 116 in various ways, including by creating a snapshot consistent with the entire access scope of authorization token 312 (e.g., copying all user files if authorization token 312 is extended) and/or copying the resource file by file (e.g., copying only the single file that application 302 attempts to access).

While in some examples resource snapshot 322 may be stored locally on secure resource 116, it is anticipated that resource snapshot 322 may also be stored remotely (e.g., on another server) in a manner inaccessible to application 302 and/or any other potentially untrusted application. In some implementations, resource protector 320 may be configured to encrypt (or further encrypt) resource snapshot 322 to further enhance security by preventing unauthorized access in the event of potential damage.

The creation of a backup copy of secure resource 116 is merely an illustrative example of the preventative measures that resource protector 320 can perform to protect resources. In addition to or as an alternative to creating resource snapshot 322, resource protector 320 may perform one or more other measures, including but not limited to granting access with a more limited scope than indicated in authorization token 312 (e.g., read-only access to files already accessed on the storage device, preventing withdrawals from financial institutions, etc.), allowing access only for a specific period of time (e.g., in days, hours, minutes, seconds, etc.) after access may be terminated, completely denying access (e.g., in cases where secure resources may be deemed overly sensitive or important, such as banking or financial information, to allow any potentially untrusted access), and/or requiring one or more additional or alternative authorization procedures.

In some other instances, resource protector 320 may perform enhanced identity authentication in response to receiving an authorization token that includes a trust indication. For example, before authorizing access to secure resource 116, resource protector 320 may require the user of computing device 102 to perform additional authentication procedures or re-perform the same authentication procedures from a trusted environment (e.g., from an application running within a trusted primary operating system), performing multi-factor procedures (e.g., verifying that randomly generated code was transmitted to a mobile device, email account, etc.) to confirm that authentication token 312 was initiated by a legitimate application before authorizing access to the resource.

In some other implementations, resource protector 320 may also be configured to detect anomalous activity via the authentication token described herein. For example, if resource protector 320 is receiving an unusually large number of access requests from application 302 associated with a specific authorization token 312 (e.g., exceeding a threshold or the number of access requests within a certain time period), resource protector 320 may infer that application 302 is engaged in potentially malicious activity that could otherwise be compromised. In such an instance, as an additional precaution, resource protector 320 may determine to stop serving access requests from application 302 as an additional preventative measure.

In some other instances, resource protector 320 may also perform preventative actions on one or more resources unrelated to authorization token 312. For example, if resource protector 320 receives a request from a potentially untrusted computing environment, it may be configured to automatically protect (e.g., by encrypting, locking, moving to a more secure location, etc.) unrelated files, which may have increased sensitivity or importance to further enhance security. In this way, even if some malicious code could compromise secure resource 116, the movement of the malicious code may still be restricted because resource protector 320 can prevent the code from accessing not only resource snapshot 322, but also other data that may exist on the same server or be accessible by the same server.

In step 510, access to the resource is authorized by an application executing in the computing environment. For example, referring to FIG3, resource access provider 318 can be configured to authorize access to secure resource 116 by application 302 executing in the computing environment (i.e., a potentially untrusted environment). In some examples, the type of access authorized by resource access provider 318 can be based on multiple preventative actions performed to protect secure resource 116. For example, if resource protector 320 creates a resource snapshot 322 that is inaccessible to application 302, resource access provider 318 can be granted full read/write access to secure resource 116.

In other examples, if a backup copy is not created, resource access provider 318 can grant application 302 more limited access, such as read-only access, to prevent secure resource 116 from being affected by potential malicious activity. For example, resource access provider 318 can be configured to authorize application 302 to access, based on trust instructions included in a token, existing content in the user's file space and/or generate new content to store in the user's file space, while preventing application 302 from modifying or deleting existing content. In some other implementations, resource access provider 318 can also be configured to tag or label any new content generated by application 302, allowing the application not only to generate new content (each item of which is identified by a tag or label) but also to modify or delete newly generated content based on tagged content items. In yet another implementation, such tags or labels can be automatically cleaned up, for example, after a predetermined period of time or when a full access authorization token (e.g., a token authorized to an application executing in a trusted environment) accesses the tagged content.

Resource access provider 318 can also be configured to allow application 302 to access resource snapshot 322 (instead of secure resource 116, which can remain unprotected by application 302). In either instance, resource protector 320 can be configured to automatically delete the backup copy when it is determined that application 302's access is not malicious and/or when a predetermined time has elapsed. In other instances, such as when resource protector 320 can be notified that application 302 has maliciously altered secure resource 116 (e.g., due to ransomware), resource protector 320 can be configured to restore secure resource 116 from resource snapshot 322. Therefore, even if an untrusted application attempts to inject ransomware to encrypt or otherwise alter a user's files, the backup files can be easily restored, minimizing the harm of such malicious activity.

It should be noted and understood that the arrangement described in Figure 3 is illustrative only, and implementations may include various other types of arrangements, including arrangements where one or more of the following can be implemented locally on computing device 102: authorization token manager 106, token issuer 110, resource manager 114, security resource 116, and resource snapshot 322. For example, Figure 6 shows a block diagram of system 600 for providing secure access to local resources according to an example embodiment. System 600 includes computing device 602. Similar to computing device 102, computing device 602 may include multiple computing environments. For example, computing device 602 may include computing environments in which a desktop primary operating system and/or mobile operating system (e.g., Windows, macOS, iOS, Android) can be executed. Computing device 602 may also include one or more other computing environments described herein, such as an isolated environment that may include virtual machine 104 and applications (e.g., application 302) executed therein.

In the example arrangement of Figure 6, the first computing environment (e.g., a computing environment that can host an isolated environment) may include one or more of the following: an authorization token manager 106, a token issuer 110, a resource manager 114, a security resource 116, and a resource snapshot 322. For example, instead of implementing one or more of these components on one or more network entities, these components may be implemented locally on the computing device 602. For example, the token requester 306 may provide token requests (e.g., requests for NT tokens, etc.) to the authenticator 314, which is configured to manage authorization tokens for local activities on the computing device 602. In some example implementations, the authenticator 314 and/or the token generator 316 may be implemented as part of the computing device 602's primary operating system, file system manager, and/or any other application running thereon, enabling access to data in locally stored (or data in remotely stored that is accessible via local interaction, such as via shortcuts, etc.) to be managed using local authorization tokens. In other words, token generator 316 can be configured to generate and provide authorization tokens to allow applications running on computing device 602 (including any applications that can be hosted in an isolated environment) to access local resources such as security resource 116.

Therefore, when application 302 requests a token and token requester 306 provides token request 308 and assigned trust level 310 to token issuer 110, token generator 316 can generate an authorization token that includes a trust indication indicating trust level 310 in a similar manner to that described previously. The authorization token may include information associated with authorized access, such as user information (e.g., an identifier of a user as an administrator, guest, etc.), permission level (e.g., read-only, read/write access, etc.), identifier of the requested resource, etc. Token requester 306 can provide application 302 with an authorization token including the trust indication (e.g., a marked authorization token), thereby authorizing the application to access local resources that may be available outside virtual machine 104.

Therefore, when application 302 attempts to access or modify resources outside the isolated computing environment (such as secure resource 116), resource access provider 318 can extract a trust indication from the authorization token provided by application 302 and determine that application 302 may not be trusted. In response to receiving an authorization request indicating that application 302 may not be trusted, resource protector 320 may perform one or more preventative actions to protect secure resource 116 in a computing environment including a primary operating system, such as creating a resource snapshot 322 that includes a backup copy of secure resource 116 prior to allowing access to secure resource 116. As previously described, in addition to creating resource snapshot 322 or as an alternative, resource protector 320 may also include any other type of preventative action, including but not limited to allowing limited access to secure resource 116 (e.g., read-only access), preventing secure resource 116 from being encrypted (or further encrypted), requiring enhanced authorization, or any other preventative action that a person skilled in the art would understand.

It is important to note and understand that the isolated environment does not need to include the virtual machine 104 described relative to Figures 3 and 6. For example, application 302 can also include any type of application (e.g., a web browser) running on the host computing environment, which may include partial or complete isolation boundaries. Therefore, even if the isolated environment includes another application that can access resources that are local or remotely stored, the implementation can still enable these resources to be accessed more securely by marking the authorization token used for such access with trust information of the access environment described herein (e.g., by creating backup copies, restricting access, etc.).

III. Examples of Moving and Stationary Device Embodiments

The computing device 102, virtual machine 104, authorization token manager 106, authorization server 108, token issuer 110, resource server 112, resource manager 114, secure resource 116, trust level allocator 304, token requester 306, authenticator 314, token generator 316, resource access provider 318, resource protector 320, resource snapshot 322, flowchart 200, flowchart 400 and/or flowchart 500 can be implemented in hardware or in combination with software and/or firmware, for example, implemented as computer program code/instructions stored in a physical/hardware-based computer-readable storage medium and configured to execute in one or more processors, or implemented as a hardware logic/circuit system (e.g., a circuit consisting of transistors, logic gates, operational amplifiers, one or more application-specific integrated circuits (ASICs), one or more field-programmable gate arrays (FPGAs)). For example, one or more of the following components may be implemented in the SoC: computing device 102, virtual machine 104, authorization token manager 106, authorization server 108, token issuer 110, resource server 112, resource manager 114, secure resource 116, trust level allocator 304, token requester 306, authenticator 314, token generator 316, resource access provider 318, resource protector 320, resource snapshot 322, flowchart 200, flowchart 400, and/or flowchart 500. The SoC may include an integrated circuit chip that includes a processor (e.g., central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or other circuitry, and may optionally execute received program code and/or include embedded firmware to perform functions.

Figure 7 illustrates an exemplary implementation of computing device 700 from which the example embodiments can be implemented. For example, any of the following can be implemented in one or more computing devices: computing device 102, virtual machine 104, authorization token manager 106, authorization server 108, token issuer 110, resource server 112, resource manager 114, security resource 116, trust level allocator 304, token requester 306, authenticator 314, token generator 316, resource access provider 318, resource protector 320, and/or resource snapshot 322, including one or more features and/or alternative features of computing device 700 in embodiments similar to those of a stationary or mobile computer. The description of computing device 700 provided herein is for illustrative purposes and is not intended to be limiting. As known to those skilled in the art, the example embodiments can be implemented in other types of computer systems.

As shown in Figure 7, the computing device 700 includes one or more processors (referred to as processor circuitry 702), system memory 704, and a bus 706 that couples various system components, including system memory 704, to processor circuitry 702. Processor circuitry 702 is an electrical and/or optical circuit implemented as a central processing unit (CPU), microcontroller, microprocessor, and/or other physical hardware processor circuitry in one or more physical hardware circuitry devices and/or integrated circuit devices (semiconductor chip or die). Processor circuitry 702 can execute program code stored in a computer-readable medium, such as program code for operating system 730, application program 732, other programs 734, etc. Bus 706 represents one or more of a variety of bus architectures, including memory buses or memory controllers using any of various bus architectures, peripheral buses, accelerated graphics ports, and processor or local buses. System memory 704 includes read-only memory (ROM) 708 and random access memory (RAM) 710. Basic input/output system 712 (BIOS) is stored in ROM 708.

The computing device 700 also includes one or more of the following drives: a hard disk drive 714 for reading and writing to a hard disk, a disk drive 716 for reading or writing to a removable disk 718, and an optical disk drive 720 (such as a CD-ROM, DVD-ROM, or other optical media) for reading or writing to a removable optical disk 722. The hard disk drive 714, disk drive 716, and optical disk drive 720 are connected to bus 706 via hard disk drive interface 724, disk drive interface 726, and optical disk drive interface 728, respectively. The drives and their associated computer-readable media provide a non-volatile storage device for computer-readable instructions, data structures, program modules, and other data. Although hard disks, removable disks, and removable optical disks are described, other types of hardware-based computer-readable storage media can be used to store data, such as flash memory cards, digital video discs, RAM, ROM, and other hardware storage media.

Multiple program modules may be stored on a hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include an operating system 730, one or more application programs 732, other programs 734, and program data 736. Application programs 732 or other programs 734 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing computing device 102, virtual machine 104, authorization token manager 106, authorization server 108, token issuer 110, resource server 112, resource manager 114, security resource 116, trust level allocator 304, token requester 306, authenticator 314, token generator 316, resource access provider 318, resource protector 320, resource snapshot 322, flowchart 200, flowchart 400, and/or flowchart 500 (including any suitable steps of flowchart 200, 400, or 500) and/or other example embodiments described herein.

Users can type commands and information into the computing device 700 using input devices such as a keyboard 738 and a pointing device 740. Other input devices (not shown) may include a microphone, joystick, game controller, satellite dish, scanner, touchscreen and/or touchpad, voice recognition system for receiving voice input, gesture recognition system for receiving gesture input, etc. These and other input devices are typically connected to the processor circuitry 702 via a serial port interface 742 coupled to bus 706, but may be connected via other interfaces such as a parallel port, game port, or Universal Serial Bus (USB).

Display screen 744 is also connected to bus 706 via an interface such as video adapter 746. Display screen 744 can be external to computing device 700 or incorporated into computing device 700. Display screen 744 can display information and is a user interface for receiving user commands and/or other information (e.g., via touch, finger gestures, virtual keyboard, etc.). In addition to display screen 744, computing device 700 may include other peripheral output devices (not shown), such as speakers and printers.

The computing device 700 is connected to the network 748 (e.g., the Internet) via an adapter or network interface 750, a modem 752, or other components for establishing communication over the network. As shown in FIG7, the modem 752, which may be internal or external, may be connected to the bus 706 via a serial port interface 742, or it may be connected to the bus 706 using another interface type including a parallel interface.

As used herein, the terms “computer program medium,” “computer-readable medium,” and “computer-readable storage medium” are used to refer to physical hardware media, such as a hard disk associated with hard disk drive 714, removable disk 718, removable optical disk 722, other physical hardware media such as RAM, ROM, flash memory cards, digital video disks, zip disks, MEM, nanotechnology-based storage devices, and other types of physical/tangible hardware storage media. Such computer-readable storage media are distinguished from and do not overlap with communication media (excluding communication media). Communication media implement computer-readable instructions, data structures, program modules, or other data in modulated data signals, such as carrier waves. The term “modulated data signal” refers to a signal whose one or more characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, communication media include wireless media (such as acoustic, RF, infrared, and other wireless media) as well as wired media. The example embodiments also relate to such communication media, which are separate from and do not overlap with embodiments relating to computer-readable storage media.

As mentioned above, computer programs and modules (including application program 732 and other programs 734) can be stored on a hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage media. Such computer programs can also be received via network interface 750, serial port interface 742, or any other interface type. When executed or loaded by an application, such computer programs enable computing device 700 to implement the features of the exemplary embodiments described herein. Therefore, such computer programs represent the controller of computing device 700.

The example embodiments also relate to computer program products, including computer code or instructions stored on any computer-readable medium. Such computer program products include hard disk drives, optical disk drives, memory device packages, memory sticks, memory cards, and other types of physical storage hardware.

IV. Example Implementation

This document describes a system for providing an authorization token with a trust indication in a computing device. The system includes: one or more processors; and one or more memory devices storing program code configured to be executed by the one or more processors, the program code including: an authenticator configured to: receive a token request from an authorization token manager of a first computing environment, the token request including identity information and indications that the token request was initiated by an application executing in a second computing environment, the second computing environment being at least partially isolated from the first computing environment; and verify the identity information; and a token generator configured to: generate an authorization token including a trust indication of a trust level of the second computing environment; and transmit the authorization token including the trust indication to the first computing environment.

In one implementation of the aforementioned system, the trust indication includes an indication that the application executing in the second computing environment is not trusted.

In another implementation of the aforementioned system, the second computing environment includes virtual machines hosted in the first computing environment.

In another implementation of the aforementioned system, the authorization token is configured to allow an application running in the second computing environment to access secure resources in the first computing environment.

In another implementation of the aforementioned system, the authorization token is configured to allow an application running in a second computing environment to access secure resources over the network.

In another implementation of the aforementioned system, access to security resources by applications running in the second computing environment includes read-only access to the security resources.

This document discloses a method for supporting secure access to resources. The method includes: receiving a token request from an application running in a second computing environment to access resources, the second computing environment being at least partially isolated from a first computing environment; assigning a trust level to the token request; obtaining an authorization token including a trust indication corresponding to the trust level of the token request; and providing the authorization token including the trust indication to the application running in the second computing environment.

In one implementation of the aforementioned method, obtaining an authorization token includes: transmitting a token request and the assigned trust level to a token issuer; and receiving an authorization token from the token issuer, the authorization token including a trust indication corresponding to the trust level.

In another implementation of the aforementioned method, the trust indication includes an indication that the application executed in the second computing environment is not trusted.

In another implementation of the aforementioned method, the resources are stored in a first computing environment; and the method further includes: receiving an authorization token from an application running in a second computing environment; and in response to receiving the authorization token, performing preventative actions in the first computing environment to protect the resources.

In another implementation of the aforementioned method, the preventative action includes creating a backup of the resource in response to receiving an authorization token.

In another implementation of the aforementioned method, the method further includes: in response to receiving an authorization token, authorizing the first computing environment to have read-only access to the resource.

In another implementation of the aforementioned method, resources are stored in a server configured to perform preventative actions in response to: receiving an authorization token; extracting a trust indication from the authorization token; and determining, based on the extracted trust indication, to perform a preventative action.

In another implementation of the aforementioned method, the second computing environment includes a virtual machine hosted in the first computing environment.

This document describes a system for authorizing access to resources. The system includes: one or more processors; and one or more memory devices storing program code configured to be executed by the one or more processors, the program code including: a resource protector configured to: receive an authorization token from an application executing in a computing environment to access the resource, the authorization token including a trust indication indicating a trust level of the application; perform preventative actions to protect the resource in response to receiving the authorization token including the trust indication; and a resource access provider configured to authorize access to the resource from applications executing in the computing environment.

In one implementation of the aforementioned system, the trust indication includes an indication that the application running in the computing environment is not trusted.

In another implementation of the aforementioned system, the computing environment includes virtual machines hosted in another computing environment.

In another implementation of the aforementioned system, the preventative actions performed by the resource protector include: creating a backup of the resource in response to receiving an authorization token.

In another implementation of the aforementioned system, the resource access provider is configured to grant limited access to resources to applications running in the computing environment in response to receiving an authorization token.

In another implementation of the aforementioned system, the resource protector is configured to perform enhanced identity authentication in response to receiving an authorization token; and the resource access provider is configured to authorize access to the resource in response to performing enhanced identity authentication.

V. Conclusion

While various embodiments of the invention have been described above, it should be understood that they are presented by way of example only and not as limitations. It will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention as defined by the appended claims. Therefore, the breadth and scope of the invention should not be limited by any of the exemplary embodiments described above, but should be defined only by the following claims and their equivalents.

Claims (19)

1. A system for authorizing access to resources, comprising: Processor; and A memory coupled to the processor, the memory including computer-executable instructions, which, when executed by the processor, perform operations including: The token issuer receives a token request from a client device, which includes a virtual machine and an authorization token manager. The token request includes the identity information of the user for the virtual machine and the trust level assigned to the token request by the authorization token manager, wherein: The token request is generated by an application executing on the virtual machine in response to a request from the application to access a secure resource stored outside the client device, and the token request requests an authorization token. The trust level indicates whether the virtual machine is trusted based on its operational characteristics, wherein the operational characteristics include at least one of the following: The identity of the operating system running on the virtual machine; The identity of the application; and The virtual machine provides the token request to the authorization token manager; The token issuer uses its authenticator to verify the identity information, which is configured to verify the identity information for the user, including at least one of the following: user login credentials, user alias, account, or biometric information. The token issuer generates an authorization token for the token, wherein the authorization token for the token is: This includes a trust indicator that indicates the trust level of the virtual machine; and The token request was generated by the virtual machine; and The token issuer transmits an authorization token, which includes the trust indication, to the authorization token manager, wherein the authorization token with the indicated mark is used to determine the application's access to the security resource. 2. The system of claim 1, wherein the trust indication includes an indication that the application executing in the virtual machine is not trusted. 3. The system of claim 1, wherein the token issuer is configured to generate an authorization token with at least one token, the authorization token with at least one token being configured to authorize an application executing in the virtual machine to access one or more security resources of the client device. 4. The system of claim 1, wherein the authorization token of the token enables the application to have read-only access to the secure resource. 5. The system of claim 1, wherein generating the authorization token of the token includes selecting the trust indicator from a plurality of trust indicators. 6. The system of claim 1, wherein generating the authorization token of the token includes embedding the trust indication into the authorization token of the token. 7. A method for authorizing access to a resource, comprising: In the authorization token manager of the host computing device, a token request is received from an application running in a virtual machine within the host computing device. The token request requests access to a security resource stored outside the host computing device, and the token request includes the identity information of the user of the application. Based on the determination that the token request was initiated by the application, the authorization token manager assigns a trust level to the token request. This trust level indicates the trustworthiness of the application or the virtual machine, and is a value based on the operating characteristics of the virtual machine, wherein the operating characteristics describe at least one of the following: The identity of the operating system running in the virtual machine; The identity of the application; The token request and the trust level are provided to the token issuer, which includes an authenticator configured to verify the identity information; The authorization token manager obtains an authorization token from the token issuer, which includes a trust indicator indicating the trust level. The authorization token manager provides the marked authorization token to the virtual machine; The virtual machine provides the marked authorization token to a storage location external to the host computing device, which has access to the secure resource; and The virtual machine receives an access determination, which indicates whether the application is permitted to access the security resource. 8. The method of claim 7, wherein the trust indication indicates that the application is not trusted. 9. The method according to claim 7, wherein the method further comprises: In response to receiving the authorized token marked by the storage location, preventative actions are performed to protect the security resource. 10. The method of claim 9, wherein the preventive action includes creating a backup of the security resource in response to receiving an authorization token for the marked token. 11. The method of claim 9, further comprising: In response to receiving the authorization token marked by the storage location, read-only access to the secure resource is authorized. 12. The method of claim 7, wherein the storage location performs a preventative action in response to: Receive the authorization token of the marked token; Extract the trust indication from the authorization token of the marked token; and Based on the extracted trust indication, it is determined that the preventive action should be performed. 13. A system for authorizing access to a resource, the system comprising: processor; A memory coupled to the processor, the memory including computer-executable instructions, which, when executed by the processor, perform a method, the method comprising: An application running in a virtual machine on a client device receives an authorization token for accessing resources, the system and the resources being located outside the client device, the authorization token being authorized by a token issuer located outside the client device; Extract a trust indicator from the marked authorization token, indicating the trust level of the application, wherein the trust level is a value based on the operating characteristics of the virtual machine; Based on the trust level, preventative actions are performed to protect the resource, and the preventative actions include at least one of the following: Create a backup copy of the resource; or Restrict the scope of access to the resources; and The application is authorized to access the resources based on the preventative action. 14. The system of claim 13, wherein the trust indication includes an indication that the application executing in the virtual machine is not trusted. 15. The system of claim 13, wherein performing the preventative action to protect the resource further comprises performing enhanced authentication in response to receiving an authorization token marked with the token; and The system is configured to authorize access to the resource in response to performing the enhanced authentication. 16. The system of claim 13, wherein the authorization token of the token is generated at least based on an indication that a token request is initiated in the virtual machine, wherein the virtual machine is less trusted than the host computing environment in which it is executed. 17. The system of claim 13, wherein the operational characteristics of the virtual machine include the identity of the application executed in the virtual machine. 18. The system of claim 13, wherein restricting the scope of access to the resource includes limiting the scope of access to the resource to a more limited scope than the access level indicated by the trust level. 19. The system of claim 13, wherein restricting access to the resource includes setting a time period during which the resource is accessible to the application.