Posture-based data protection

One embodiment of the present invention provides a system that facilitates access to encrypted data on a computing device based on a security-posture of the computing device. During operation, the system assesses the security-posture of the computing device upon which the encrypted data is stored. If the assessed security-posture meets specified criteria, the system provides the computing device with a key which enables the computing device to access the encrypted data.

BACKGROUND

1. Field of the Invention

The present invention generally relates to the field of computer security. More specifically, the present invention relates to a method and an apparatus that restricts access to data on a computing device based on a posture assessment of the computing device.

2. Related Art

Corporations deal with an ever-increasing amount of sensitive customer data, such as health records, bank account numbers, government identifiers, and financial records. Accidental or malicious leakage of this data can expose a company to damaging publicity, consumer lawsuits, and punitive governmental action. Unfortunately, many employees, who often are not trained in information technology and security issues, often make mistakes that can lead to the leakage of private customer data. For example, in 2006, the unencrypted personal information of almost 200,000 Hewlett-Packard employees was endangered when a laptop was stolen from the financial services company Fidelity. Another troubling example can be seen by the wealth of unencrypted information that is accidentally shared via file-sharing programs by users unaware of the extent of this sharing.

To deal with this problem, a number of companies have been attempting to develop tools that transparently protect sensitive data to minimize the risk of information leakage from accidents or casual theft. For example, in the Virtual Private Networking (VPN) space, companies have been developing systems that restrict a client's ability to access a VPN based on a “posture assessment” (PA) of the client machine. (This technique is also referred to as “network admission control” (NAC), “device verification” (DV), and “trusted network connect” (TNC).)

The PA technique operates generally as follows. Before allowing a client to connect to a network (either over a VPN or via a direct connection), the state of the client is assessed to determine whether it might be a threat to the network. If so, it may be prevented from connecting to the VPN; or, it may be connected to a quarantine network which it can use to patch itself before being allowed to connect to the VPN with full access. Existing PA implementations vary in what is assessed at each endpoint—from a simple determination of whether a client is currently running firewall and up-to-date antivirus software, to detection of the client's level of service packs and software updates, to fine-grained analysis of the versions of all of the software installed on the machine.

Although existing PA and NAC techniques can protect networks from unauthorized accesses, they do nothing to protect sensitive data after it is retrieved from the network. Note that changes in the security-posture of a client can compromise sensitive data on the client. For example, if malicious code, such as a virus, is inadvertently loaded onto the client, the malicious code may be able to access the sensitive data. This problem can be alleviated by ensuring that sensitive data is never stored on the client, and must always be accessed from a secure server. However, this requires the client to be connected to the network whenever the client needs to access sensitive data, which may not be practical for laptops or other portable computing devices, or for clients with unreliable network connections.

Hence, what is needed is a method and an apparatus that protects sensitive data on a client machine.

SUMMARY

One embodiment of the present invention provides a system that facilitates access to encrypted data on a computing device based on a security-posture of the computing device. During operation, the system assesses the security-posture of the computing device upon which the encrypted data is stored. If the assessed security-posture meets specified criteria, the system provides the computing device with a key which enables the computing device to access the encrypted data.

In a variation on this embodiment, assessing the security posture of the computing device involves determining one or more of the following: whether unverified executable code has been loaded onto the computing device; whether an unverified file has been loaded onto the computing device; whether a virus scan has been recently performed on the computing device; whether a virus scanner for the computing device has been recently updated; whether recent patches have been applied to an operating system for the computing device; whether the computing device is running an up-to-date firewall; or whether the computing device is or has been connected to an insecure network.

In a variation on this embodiment, assessing the security-posture of the computing device involves using a posture-assessment server which interacts with the computing device to assess the security-posture of the computing device.

In a variation on this embodiment, providing the computing device with the key involves using a key-management server which interacts with the computing device to provide the key.

In a further variation, the system caches the key locally on the computing device so the computing device can access the encrypted data when the computing device is unable to communicate with the key-management server. After the key is cached, the system monitors activity on the computing device. If the activity causes the security-posture of the computing device to no longer meet the specified criteria, the system erases the locally cached copy of the key so that computing device cannot access the encrypted data without interacting with the key-management server again.

In another variation, the key is specific to a particular encrypted data item, so that the computing device has to interact with the key-management server again to access another encrypted data item.

In a variation on this embodiment, providing the key to the computing device involves obtaining the key from a trusted key storage device.

In a variation on this embodiment, the specified criteria is formulated as a policy which provides selective access to specific encrypted data items based on specific security-postures of the computing device.

DETAILED DESCRIPTION

The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or any device capable of storing data usable by a computer system.

Overview

One embodiment of the present invention provides a new a technique, referred to as “Posture-Based Data Protection” (PBDP), which automatically encrypts sensitive data stored on computing devices, such laptops and other mobile devices. PBDP ensures that access to encrypted documents occurs only when the device is in a known good state, and terminates when safety-violating events occur (such as unauthorized software installation).

Recall from the above discussion that existing VPN and NAC techniques protect a network and network services from unauthorized accesses, thereby allowing only authorized users of verified devices into the “trust domain” of the network and network services. The idea of PBDP is to take this paradigm one step further, to extend this “trust domain” to the device itself. This means that data on the device itself is accessible only after successful posture assessment.

A comparison of the two approaches can be seen inFIGS. 1 and 2. In the existing PA system illustrated inFIG. 1, a PA server102inspects and authorizes computers and network devices106, before they are allowed to access the network and associated network services. In this system, PA server102ensures that only inspected and authorized computers and network devices can enter the “trust domain”105of the network services (inside the dashed line).

In contrast,FIG. 2illustrates a system that also uses a PA server202to protect data on a client machine in accordance with an embodiment of the present invention. The system inFIG. 2similarly uses PA server202to inspect and authorize computers and network devices206before they are allowed to access entities within trust domain205. However, the system also provides a PBDP server208, which selectively enables access to restricted data stored locally on computers and network devices206. In one embodiment of the present invention, PBDP server208is implemented as a key-management server, which manages key that can be used to access encrypted data items located on computers and network devices206. This process is described in more detail below with reference toFIGS. 3-8.

EXAMPLE

To illustrate how PBDP works in practice, consider the following example use case. Alice, an accountant, is issued a company laptop, which she uses throughout the work day. At the end of normal working hours, Alice notices that she is not yet finished processing data about her company's customers. She copies the data that she needs onto her laptop, which she then takes home.

At home, Alice continues processing customer data, opening Excel™ spreadsheets, copying data from Word™ documents, and so on. After a while, Alice decides she would like to connect to the Internet and install Winny, so she can download a popular movie. When she plugs in an Ethernet jack to connect to her local network (or attempts to activate her wireless card), Alice sees a dialog box appear on the laptop's screen, warning her that she has two choices: (1) connect to her home network, but lose access to the company files, or (2) log into work, and keep access to her company's files.

Suppose Alice chooses (1). Her laptop now connects to the local area network. Alice notices that the files she was working with can no longer be edited or saved, and she cannot open any other company files, either. Alice can, however, browse the Web, and possibly even download or install programs such as Winny (depending on corporate policy). Nevertheless, these newly-installed programs cannot access the company data, since the partition on which the company data is stored is now entirely unreadable. Furthermore, her laptop is now flagged as “unsafe”, and when she returns to work the next day (or tries to connect to work from home), her system fails posture-assessment due to the presence of unauthorized software. The company data on the partition continues to remain unreadable until administrators remove the offending software, and the laptop passes posture-assessment again.

Suppose instead that Alice chooses (2). Immediately after connecting to her home network, her laptop establishes a VPN connection to work and proceeds through posture-assessment. Installation of Winny or other offending software is prevented by her corporate network, and through ongoing posture-assessment inspection. While her system continues to remain connected to work (or disconnected entirely from any network), Alice can continue reading, editing, and writing company files.

Variations

We now describe four variations of PBDP in accordance with different embodiments of the present invention. A first variation is a “local-cache variation” of PBDP which protects files in storage by requiring decryption keys for those files to be obtained from a server, which is only allowed after successful posture-assessment. In this variation, the keys are cached locally to improve performance. The second variation is a “server-aided variation,” in which local key caching is not allowed, and decryption can be performed only with the aid of a server. The third variation is a “threshold variation,” in which decryption is possible only with cooperation between a trusted key storage device (such as a smart card) and a server (or key information cached from it). Finally, the fourth variation is a “threshold server-aided variation,” wherein decryption is possible only with cooperation between trusted key storage device (such as a smart card) and a server (which does not allow caching of its keying information). These variations are described in more detail below with reference toFIGS. 3-8.

System for Local-Cache Variation

FIG. 3illustrates an implementation of a PA system which is associated with the local-cache variation of PBDP in accordance with an embodiment of the present invention. This implementation includes a client computer device300. Client300can generally include any node on a network including computational capability and including a mechanism for communicating across the network. More specifically, client300can include, but is not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a personal organizer, a device controller, and a computational engine within an appliance.

Client300contains an application302which accesses data within an encrypted data store306through a decryption agent304. During this process, decryption agent304performs decryption and/or encryption operations as necessary to allow application302to read and/or write data from encrypted data store306. Decryption agent304obtains the necessary decryption and/or encryption keys from key-management client310which is located within client300. Before giving keys to decryption agent304, key-management client310interacts with posture-assessment (PA) client308, which is also located on client300, to ensure that client300has the requisite security posture to obtain the keys.

Key-management client310in turn communicates with a key-management server314, which is located on a remote server. Similarly, PA client308interacts with PA server312, which is also located on a remote server. In one embodiment of the present invention, key-management server314and PA server312are integrated into a single remote server.

FIG. 4presents a flow chart illustrating the local-cache variation of the PA process in accordance with an embodiment of the present invention. The process starts when application302attempts to open/read a file in encrypted data store306(step402). This request is intercepted by decryption agent304(step404).

Next, decryption agent304requests metadata for the file from encrypted data store306(step406). Encrypted data store306then replies with the metadata, which includes a key identifier, an encrypted header and encrypted content (step408)—although the encrypted content need not be exchanged until step434.

Next, decryption agent304forwards the key identifier and the encrypted header to the key-management client310(step410). Key-management client310then sends a request for a PA token to PA client308(step412).

In response to this request, PA client308checks to see if it has obtained a PA token recently. If not, it engages in a PA protocol (P) with PA server312to obtain this token (step414). (Note that the protocol (P) can take place at any point in the process before step414.) If posture-modifying events have occurred since the last time protocol (P) was executed, the PA client308erases its PA token and attempts to obtain a new one via protocol (P). If the PA client308possesses a recently-obtained PA token, it replies to key-management client310with the token. Otherwise, it returns error which aborts the protocol.

At this point, key-management client310checks to see if it already has the key corresponding to the key identifier (called the “corresponding key”) (step416). If so, the process skips to step430. Otherwise, key-management client310sends the PA token and the key identifier to the key-management server314(step418).

Next, key-management server314engages in a protocol with PA server312to verify the authenticity of the PA token (step420). This step can be omitted if the PA token is independently verifiable by key-management server314.

Next, based on the PA token and the key identifier, key-management server314decides whether or not the decryption request is authorized (steps422and424). If not, it returns an error to key-management client310(step426). Otherwise, it returns the corresponding key for the key identifier to key-management client310(step428).

At this point, the key-management client310possesses the corresponding key, which it uses to decrypt the encrypted header to obtain a decrypted header, which it sends to decryption agent304(step430).

Next, decryption agent304extracts a content-decryption key from the decrypted header (step432). Recall that decryption agent304already has the encrypted content associated with the request which it obtained during step408(or obtains it now). Hence, decryption agent304uses the content-decryption key to extract the decrypted content, which it sends to application302(step434).

FIG. 5presents a flow chart illustrating the server-aided variation of the PA process in accordance with an embodiment of the present invention. Note that the system illustrated inFIG. 3also applies to this server-aided variation. The server-aided variation first repeats steps402-414from the flow chart illustrated inFIG. 4. Next, instead of moving to step416, the server aided variation moves to step518, which is described below.

At step518, key-management client310sends the PA token, the key identifier and the encrypted header to the key-management server314(step518).

Next, key-management server314engages in a protocol with PA server312to verify the authenticity of the PA token (step520). This step can be omitted if the PA token is independently verifiable by key-management server314.

Next, based on the PA token, the key identifier and the encrypted header, the key-management server314decides whether or not the decryption request is authorized (steps522and524). If not, it returns an error to key-management client310(step526). Otherwise, it uses the corresponding key to decrypt the encrypted header and returns the encrypted header to key-management client310(step528).

At this point, key-management client310sends the decrypted header to decryption agent304(step530).

Next, decryption agent304extracts a content-decryption key from the decrypted header (step532). Recall that decryption agent304already has the encrypted content associated with this request which is obtained during step408(or obtains it now). Hence, decryption agent304uses the content-decryption key to extract the decrypted content, which it sends to application302(step534).

System for Threshold Variation

FIG. 6illustrates an implementation of a PA system which is associated with the threshold variation of PBDP in accordance with an embodiment of the present invention. This implementation is the same as the implementation illustrated inFIG. 3, except that a trusted key storage device616(such as a smart card) has been added to the system to securely store keys. Note that this trusted key storage device communicates with key-management client310during the decryption process.

Threshold Variation

FIG. 7presents a flow chart illustrating the threshold variation of the PA process in accordance with an embodiment of the present invention. The threshold variation first repeats steps402-414from the flow chart illustrated inFIG. 4. Next, instead of moving to step416, the threshold variation moves to step716which is described below.

At step716, key-management client310checks to see if it already has a partial key corresponding to the key identifier (step716). If so, the process skips to step730. Otherwise, key-management client310sends the PA token and key identifier to the key-management server314(step718).

Next, key-management server314engages in a protocol with PA server312to verify the authenticity of the PA token (step720). This step can be omitted if the PA token is independently verifiable by key-management server314.

Next, based on the PA token and the key identifier, key-management server314decides whether or not the decryption request is authorized (steps722and724). If not, it returns an error to key-management client310(step726). Otherwise, it returns the partial key for the key identifier to key-management client310(step728).

At this point, the key-management client310possesses the partial key, which it uses to decrypt the encrypted header to obtain a partially-decrypted header (step730).

Key-management client310then sends the key identifier and the partially-decrypted header to trusted key storage device616(step732). Trusted key storage device616uses another partial key (which is only stored locally within trusted key storage device616) to decrypt the partially-decrypted header to produce a decrypted header (step733). Trusted key storage device616then returns the decrypted header to key-management client (step734).

At this point, the key-management client310sends the decrypted header to decryption agent304(step736).

Next, decryption agent304extracts a content-decryption key from the decrypted header (Step738). Recall that decryption agent304already has the encrypted content associated with this request which it obtains during step408(or obtains it now). Hence, decryption agent304uses the content-decryption key to extract the decrypted content, which it sends to application302(step740).

FIG. 8presents a flow chart illustrating the threshold server-aided variation of the PA process in accordance with an embodiment of the present invention. Note that the system illustrated inFIG. 6also applies to this threshold server-aided variation. The process steps for the threshold server-aided variation are the same as the for the server-aided variation illustrated inFIG. 5, except that on the “YES” branch from step524inFIG. 5, instead of moving to step528, the threshold server-aided variation moves to step828which is described below.

At step828, key-management server314uses a partial key associated with the key identifier to decrypt the encrypted header to produce a partially-decrypted header (step828). Next, key-management server314returns this partially-decrypted header to key-management client310.

Key-management client310then sends the key identifier and the partially-decrypted header to trusted key storage device616(step832). Trusted key storage device616uses another partial key (which is only stored locally within trusted key storage device616) to decrypt the partially-decrypted header to produce a decrypted header (step833). Trusted key storage device616then returns the decrypted header to key-management client (step834).

At this point, the key-management client310sends the decrypted header to decryption agent304(step836).

Next, decryption agent304extracts a content-decryption key from the decrypted header (Step838). Recall that decryption agent304already has the encrypted content associated with this request which it obtained during step408(or obtains it now). Hence, decryption agent304uses the content-decryption key to extract the decrypted content, which it sends to application302(step840).