WO2011085101A1

WO2011085101A1 - Network encryption

Info

Publication number: WO2011085101A1
Application number: PCT/US2011/020375
Authority: WO
Inventors: W. Anthony Mason; Daniel E. Brooks
Original assignee: Osr Open Systems Resources, Inc.
Priority date: 2010-01-08
Filing date: 2011-01-06
Publication date: 2011-07-14

Abstract

Various embodiments are directed to systems and methods for managing secure files in the context of a key distribution server and a client device in electronic communication with one another via a secure connection. The key distribution server may receive from the client device an encrypted file key associated with a first file. The key distribution server may determine whether the client device is authorized to access the file key considering a logical network location of the client device. Conditioned upon the client device being authorized to access the file key, the key distribution server may decrypt the file key; and transmit a decrypted version of the file key to the client device via the secure connection.

Description

TITLE

NETWORK ENCRYPTION

PRIORITY CLAIM

The present application claims, under 35 U.S.C. § 119(e), the benefit of U.S. Provisional Patent Application Serial No. 61/293,382 filed on January 8, 2010, which is incorporated herein by reference in its entirety. BACKGROUND

In enterprise and other applications where high levels of data security are desired, data security policies often come into conflict with productivity. Many of even the most sophisticated data encryption methods can be trivially circumvented by users who are motivated by a need to increase productivity. For example, many encryption methods are implemented based on user identity. Each user of the encrypted data may have a password or hardware device such as a (Universal Serial Bus) USB key. In order to read or write to encrypted data, each user must produce their password and/or hardware unit. Often it is a burden, and a drag on productivity, for users to remember their password and/or their hardware unit. Accordingly, passwords are often written down and posted near a computer device, allowing the encryption to be defeated by any user of the computer device. Likewise, many hardware security units, such as USB keys, are left in or near computer devices, thus defeating encryption with respect to anyone who picks up the security device.

A similar problem arises in the context of removable media, such as removable hard drives and USB pen drives. Often, it may be desirable to use removable media devices such as these and others to legitimately move data within a secure network. Removable media, however, are often prohibited in secure network environments due to the ease with which they can be used to remove potentially sensitive data from the secure networks. The productivity benefits of using removable media often provide motivation for network users to use prohibited removable media. This can lead to the loss of secure data. In one celebrated example, a New Zealand man purchased a used APPLE IPOD containing confidential United States military information at a thrift shop in Oklahoma. See Geoff Duncan, "Man Buys Used iPod with U.S. Troop Data," Digital Trends, January 27 , 1089, http://news.digitaltrendsxom^^

troop-data, last accessed on January 8, 2010.

FIGURES

Various embodiments of the present invention are described here by way of example in conjunction with the following figures, wherein:

Figure 1 illustrates one embodiment of a secure network comprising a key distribution center (KDC).

Figure 2 illustrates one embodiment of a client device in communication with the KDC of Figure 1 , where the KDC is utilizing an asymmetric key encryption algorithm.

Figure 3 illustrates one embodiment of a process flow for opening an encrypted file from a client device, such as the client device of Figure 2, operating on a secure network, such as the secure network of Figure 1.

Figure 4 illustrates one embodiment of a process flow for encrypting a data file where the KDC of Figure 1 utilizes an asymmetric key encryption algorithm, as illustrated in Figure 2.

Figure 5 illustrates one embodiment of a process flow 500 for encrypting a file without contacting the KDC.

Figure 6 illustrates an alternative embodiment of the client device and KDC where the KDC implements a symmetric key encryption algorithm.

Figure 7 illustrates one embodiment of a process flow for encrypting a data file where the KDC utilizes a symmetric key encryption algorithm, as illustrated in Figure 6.

Figure 8 illustrates a logical diagram of one embodiment of a data container including an encrypted file and an encrypted file key.

Figure 9 illustrates a logical diagram of one embodiment of a data container including encrypted file blocks and encrypted file key blocks organized within the data container according to a log- structured file system. DESCRIPTION

As used herein, the term "file" or "data file" may refer to a grouping of logically related data. A "file" may be defined from the perspective of an application. For example, a file may include word processing file, or a spreadsheet file. As used herein, the term "data container" may refer to a collection of data stored as a related unit by a file system. For example, a "data container" may comprise a file, as well as various metadata describing the file including, for example, an encryption key as described herein. Logical data containers may be mapped to physical locations at a data storage by a file system such as NTFS, FAT32, etc.

Various embodiments of the present invention are directed to systems and methods for managing secure access to data files in a network setting according to the logical network location of the requesting entity. Because most secure networks already include functionality for authenticating client devices and users of client devices, implementing the encryption may not require any additional affirmative steps from the user. For example, a user who wishes to access secure data files may be required to authenticate him or herself to a client device having an acceptable logical network location and allow the client device to authenticate itself on the network. It may not be necessary for the user to enter a separate encryption password. Because access to the secure data files is based on a given network location, it may be possible to utilize removable data storage devices. These devices may be accessible from a client device having the proper network location. Once removed from the network, however, data files on the removable data storage devices may be unreadable.

A network implementing the description herein may comprise at least one server and one or more client devices. The at least one server may implement authentication functionality for securely authenticating the client devices and a key distribution center (KDC) for managing access to the secure data files. Storage of the secure data files may be distributed to one or more storage devices accessible to the client devices {e.g. , local hard drives, removable disks, etc.). At the storage devices, the data files may be encrypted with a file key according to a symmetric key encryption algorithm. In addition, the data files at the storage devices may be associated with an encrypted version of the file key. For example, the encrypted version of the file key may be stored with the encrypted data file in a single data container. The encrypted file key may be decrypted only by a key at the KDC. The file key may be encrypted according to a symmetric and/or an asymmetric algorithm administered by the KDC.

When a client device attempts to access an encrypted data file, it may retrieve the associated encrypted file key and transmit it to the KDC. The KDC may verify the identity of the client device and determine whether the client device is authorized to access the data file considering a logical network location and/or an access level of the client device. For example, client devices may be located on a network or sub-network with other client devices having a similar level of access. According to various embodiments, different KDC's may comprise keys granting different levels of access. Each KDC may be logically positioned on and/or assigned to service a network, or portion thereof, with client devices having access levels corresponding to that of the KDC. In some embodiments, different logical network locations may comprise multiple KDC's, which different KDC's corresponding to different access levels.

It will be appreciated that, as a condition to joining the network, the client device will have been authenticated to the authentication functionality and assigned a logical network location. Conditioned upon the client device being authorized to access the data file, the KDC may decrypt the file key and transmit the un-encrypted file key to the client device via a secure connection. The client device may then utilize the un-encrypted file key to decrypt the data file and, for example, to also encrypt further writes to the file. According to various embodiments, the un-encrypted file key may be stored only in volatile memory of the client device.

Figure 1 illustrates one embodiment of a secure electronic data transfer network 100. The network 100 may comprise various components including a key distribution center or KDC 102, an authentication server 104, and various client devices 108. The client devices 108 may include any suitable device capable of storing data and communicating on the network 100 including, for example, desktop computers, portable computers (e.g., laptops, netbooks, etc.), and mobile devices (e.g. , mobile phones, palmtop computers, personal digital assistants, etc.). The client devices 108 and servers 102, 104 may communicate on the network 100 according to any suitable network configuration and/or protocol. For example, the devices and servers may be in communication with one another via a private Local Area Network (LAN) 106. In some embodiments, one or more network components may physically communicate on the network 100 utilizing a Wide Area Network (WAN) 114 such as the Internet. For example, a secure Virtual Private Network (VPN) and/or KERB EROS connection may be formed to allow authorized devices on the WAN 114 to communicate on the network 100. Wired and/or wireless communication may be facilitated. For example, one or more of the client devices 108 may communicate wirelessly via a wireless access point 116 in communication with the LAN 106, as shown, and or the WAN 114. Any suitable network organization scheme may be used. For example, according to various embodiments, the various client devices 108 and other devices on the network 100 may be organized into one or more sub-networks or subnets. The network, or subnet, on which a client device 108 is logically positioned may be determined from its network address. Also, according to various embodiments, the network 100 may comprise more than one KDC 102. For example, in some embodiments, each KDC 102 may be assigned to service one or more subnets. KDC's 102 servicing different subnets may be duplicates of one another, or may be unique. For example, each subnet may have a distinct KDC 102. In this way, encrypted data may be compartmentalized, reducing the number of client devices 108 having unnecessary access. Also, in some embodiments, different KDC's 102 may be assigned to handle data having different levels of security (e.g. , confidential, secret, top secret, etc.). Different KDC's 102 may comprise keys necessary to access different levels of secured data. According to various embodiments, the organization of the KDC's 102 may be hierarchical. For example, a KDC 102 handling data having a higher security level may comprise keys necessary to access the higher security level data, as well as keys necessary to access data having less restrictive security levels.

The authentication server 104 may authenticate client devices 108 on the network 100. The authentication server 104 may comprise a stand alone computer device, or may be implemented as software executed by a network switch or other hardware component of the network 100. The authentication server 104 may authenticate the client devices 108 according to any known method. For example, the authentication may be based on a password, a hardware token, etc. In

embodiments where the network 100 comprises subnets, multiple authentication servers 104 may be present (e.g. , each subnet may have its own authentication server 104).

Figure 2 illustrates one embodiment of a client device 108 in communication with the KDC

102 where the KDC 102 is utilizing an asymmetric key encryption algorithm. The client device 108 may be any suitable type of client including, for example, a desktop computer, a portable computer or a mobile device. Although only one client device 108 is shown in Figure 2, it will be appreciated than each client device 108 on the network 100 may have a similar functional relationship with the KDC 102. The client device 108 may execute an operating system 202 and at least one application 204. The application 204 may be any application that uses data storage including, for example, a word processing application, a spreadsheet application, an e-mail application, etc. The operating system 202 may facilitate communications between the application and one or more data storage devices 206, 208, 210. Random Access Memory (RAM) 219 may be in communication with the various other components of the client device 108, for example, via the operating system 202.

The data storage devices 206, 208, 210 may include any suitable data storage devices that are part of, or are in communication with the client device 108. Example data storage devices may include a local data storage 206 (e.g. , a hard disk drive or other local storage), removable data storage 208 (e.g. , a USB flash or pen drive, an external hard drive, etc.) and network data storage 210 (e.g., a database such as database 113, cloud storage, etc.). Each data storage device 206, 208, 210 may have one or more associated file systems 212. A file system 212 may map logical information describing stored data to the physical location(s) of the stored data on the data storages 206, 208, 210. Non-limiting examples of file systems that may be used include, File Allocation Table 16 (FAT 16), File Allocation Table 32 (FAT32), NTFS, High Performance File System (HPFS), or any UNIX or Linux file system. According to some embodiments, a single data storage 206, 208, 210 may have more than one file system (e.g. , on different partitions). Also, it will be appreciated that it is may not be necessary for each data storage 206, 208, 210 to have the same file system 212. For example, many machines running current versions of the MICROSOFT

WINDOWS operating system use the NTFS file system, while USB flash or pen drives typically utilize a FAT32 file system.

In a typical client device 108, data storage related requests from the application 204 are handled by the operating system 202 and forwarded by the operating system 202 to the various data storages 206, 208, 210 according to their respective file systems 212. In the embodiment shown in Figure 2, an encryption layer 218 is executed by the client device 108 between the operating system 202 and the respective data storages 206, 208, 210. The encryption layer 218 may implement file encryption in a manner that is transparent to the application 204 and may require minimal modification to the operating system 202. In this way, users of the application 204 may not need to possess a separate encryption password or hardware security device in order to access the data storage 206. They need only gain access to the client device 108 and have privileges allowing them to authenticate the client device 108 on the network 100.

The client device 108 and the KDC 102 may be in communication with one another via a secure connection 224. The secure connection 224 may be established according to any suitable method. For example, the client 108 may have a public and private key pair (not shown) that, in conjunction with the public 224 and private 220 key pair of the KDC 102, may allow the KDC 102 and the client device 108 to communicate according to a standard public key infrastructure method. Also, for example, secure connection protocols, such as KERBEROS and/or Virtual Private Network (VPN), may be used to establish the secure connection 224.

The KDC 102, shown in Figure 2, may possess a private key 220 and a public key 222. The private key 220 may be stored at a location accessible to the KDC 102. The KDC's private key 220 may not be accessible by any other devices or applications on the network 100. The KDC 102 may additionally comprise a public key 222. The public key 222 may be publicly available and shared with other components and applications on the network 100. The public key 222 may be used to encrypt data. Once the data is encrypted with the public key 222, is may be decrypted only by the KDC's private key 220. In this way, a client device 108 may be able to encrypt messages (e.g. , with the public key 222) that may only be read by the KDC 102 (e.g. , with the private key 220).

According to various embodiments, data files may be stored on the various data storages 206, 208, 210 in encrypted form. The encrypted data files may have been encrypted with a file key according to a symmetric key encryption algorithm. The symmetric key encryption algorithm may be any suitable algorithm with any suitable key size. For example, the Advanced Encryption Standard (AES) may be used. The file key may be stored, in encrypted form, in a way that is associated with the file. The file key may be encrypted according to an encryption algorithm administered by the KDC 102 (e.g. , an asymmetric encryption algorithm where the KDC 102 holds the private key 220). The file key may be encrypted with a public key of the KDC 102.

The encrypted file and the encrypted file key may be associated with one another according to any suitable method. According to various embodiments, the encrypted file key and the encrypted file may be associated with one another according to a method that transparently binds the two together. This may allow the encrypted file to be transferred from one data storage to another without loss of the encrypted file key. For example, the data file and the file key may be stored in a common data container which may, in turn, be stored according to a file system 212 at one or more of the data storage devices 206, 208, 210. When the NTFS file system is used, this may be implemented using a feature referred to as alternate data streams, where a single data container comprises multiple associated data streams. According to various embodiments, the encrypted file may be stored in a first data stream, while the encrypted data key may be stored in a second data stream. Also, for example, the encryption layer 218 may implement functionality to transparently store a data file and an associated encrypted file key within a data container that is organized by one of the file systems 212, 214, 216 even when not all of the file systems 212, 214, 216 support data streams or a similar feature. In various embodiments, the encryption layer 218 may store the encrypted data file and the encrypted file key within a data container according to a log-structured file system implemented within the data container (e.g. , by the encryption layer 218). The data container may then be stored to one or more of the data storage devices 206, 208, 210.

Figure 3 illustrates one embodiment of a process flow 300 for opening an encrypted file from a client device 108 operating on a secure network, such as the secure network 100. An application 204 executing on the client 108 may generate a file open request (step 302). The file open request may be directed to the operating system 202, which may handle the file open request according to any suitable method. The operating system 202 may, in turn, direct the file open request to the appropriate data storage 206, 208, 210. The encryption layer 218 may be positioned between the operating system 202 and the data storage 206, 208, 210 to intercept the file open request. The encryption layer 218 may retrieve the encrypted file key associated with the file (step 304). For example, the encryption layer 218 may cause the client device 108 to retrieve from the appropriate data storage device 206, 208, 210 a data container including the encrypted file and the encrypted file key. The encryption layer 218 may then cause the client device 108 to send the encrypted file key to the KDC 102 (step 306) via the secure connection 224. In addition to the encrypted file key, the client device 108 may also send to the KDC 102 information identifying a logical network position of the client device 108 such as, for example, an IP address of the client device 108, etc.

After receiving the encrypted file key, the KDC 102 may verify the logical network status of the client 108 (step 308) and determine whether the client is authorized to access the file (step 310). For example, the KDC 102 may determine whether an IP address of the client device 108 indicates that it has been properly authenticated on the network. According to various

embodiments, access to certain files may be limited to client devices 108 authenticated on particular subnets. The KDC 102 may, accordingly, verify that the client device 108 is

authenticated on a subnet that is authorized to open the file corresponding to the encrypted file key. In this way, different subnets of the network 100 may be created having different levels of access to encrypted data files. In various embodiments, a KDC's 102 may require authentication in addition to the network status of the client 108. For example, in embodiments with multiple KDC's 102 handling different levels of secured data, those KDC's 102 handling higher levels of secured data may require additional levels of authentication {e.g., passwords, USB keys, etc.).

In some embodiments, factors other than a client device's logical network location may be considered to determine whether the client device 108 is authorized to access an encrypted data file. Examples of such additional criteria including, for example, a unique hardware identifier of the client device 108 and/or its network adapter {e.g. , a Media Access Control (MAC) address). Also, the additional criteria may include a state of the client device 108 as indicated, for example, by an indication of the applications installed on the client device; a list of executable images loaded at the client device 108, a checksum of the executables running on the client device 108, a checksum of the executables stored at a memory and/or one of the data storages 206, 208, 210 of the client device 108, other users logged-into the client device 108, drivers loaded on the client device 108, modules loaded to the client device 108, etc. For example, in high security implementations, it may be desirable to ensure that the client device 108 is running and/or has installed only authorized applications 204. For example, unauthorized mal-ware, such as spy programs or other applications, may be used to intercept unencrypted versions of the file key and allow nefarious access to data. Accordingly, clients 108 {e.g. , via encryption layers 218) may include with file open requests checksums indicating a current state of the memory 219 (showing applications 204 executing) and/or a current state of one or more of the data storages 206, 208, 210 (showing applications 204 installed). If the KDC 102 receives an indication that the client 108 is executing any unauthorized application, or if an unauthorized application is installed on the client 108, the KDC 102 may determine that the client 108 is not authorized to access the file.

Conditioned upon the client device 108 being authorized to access the data file, the KDC 102 may decrypt the encrypted file key utilizing the private key 220 of the KDC 102. The now- decrypted file key may be transmitted back to the client device 108 via the secure connection 224 (step 312). The client device 108 (e.g. , via the encryption layer 218) may use the file key to decrypt the file (step 314), which may be returned to the application 204 in response to the original file open request. According to various embodiments, the encryption layer 218 may be configured to ensure that the decrypted file key is only be stored only in RAM 219 and/or the various registers of the processor or processors of the client device 108 (not shown) and not on any of the data storage devices 206, 208, 210. In this way, when the client device 108 is shut down, the unencrypted file key may be lost, requiring a new query to the KDC 102 upon start-up. This may prevent the client device 108 from accessing encrypted files off-line based on file keys obtained while the client device 108 is on the network 100.

In some embodiments, the client 108 (e.g. , via the encryption layer 218) may be configured to purge the decrypted file key form RAM 219 and all processor registers in events where the client device 108 may be compromised. For example, the encryption layer 218 may perform a purge upon any or all of the following events: a shut-down or power down; a loss of connectivity to the network 100; a transition to a stand-by mode; and a system crash. The preceding list is not intended to be exhaustive. It will be appreciated that the described purges may take place upon the detection of other events that may compromise the client device 108. This may limit the risk of the decrypted file key being exposed.

According to various embodiments, the encryption layer 218 may also be configured to prevent the data file from being completely or partially stored on any of the data storages 206, 208, 210 unencrypted or in the clear. Because the data file is encrypted with the file key according to a symmetric algorithm, the file key may be capable of both decrypting the data file and encrypting any new data blocks that are added to the data file by the application 204. When the application 204 initiates a write request, the encryption layer 218 may utilize the unencrypted file key to encrypt the data blocks included in the write request and then incorporate the new data blocks into the encrypted version of the file on the appropriate data storage 206, 208, 210.

Figure 4 illustrates one embodiment of a process flow 400 for encrypting a data file where the KDC 102 utilizes an asymmetric key encryption algorithm, as illustrated in Figure 2.

According to the process flow 400, file keys for each file encrypted by client devices 108 utilizing the KDC 102 may be generated by the KDC 102. This may allow the KDC 102 to maintain records of encrypted data file including various information about the files (e.g. , at a key database 118). For example, the KDC 102 may, for each file, store identifying information regarding the client device 108 that originally requested that the data file be encrypted, a logical network location or subnet from which the file originated, etc. This information may be used to determine whether a given client device 108 is authorized to decrypt the data file. For example, the subnets authorized to decrypt a given file may be determined based on the subnet of the encrypting client device 108.

Referring back to Figure 4, the client device 108 (e.g. , via the encryption layer 218) may direct a request to encrypt a data file to the KDC 102. This may occur when an application 204 executing on the client device generates a new data file, or encounters an existing file to be encrypted. According to various embodiments, the encryption request may include various information about the file including, for example, an indication of which logical network positions are authorized to decrypt the file (e.g., a list of IP addresses, a list of subnets, a list of MAC addresses, etc.). The KDC 102 may receive the request to encrypt (step 402). In response to the request to encrypt, the KDC 102 may generate a file key (step 404). The length of the file key (e.g. , in bits) may depend on the particular symmetric key encryption algorithm being used. The file key itself may be generated according any suitable method. For example, the KDC 102 may implement a random and/or pseudo-random number generator for generating the file key. The KDC 102 may transmit the file key to the client device 108 via the secure connection 224 (step 406). The client device 108 may use the file key to encrypt the data file (step 408). As described above, the client device 108 (e.g. , via the encryption layer 218) may be configured to store the unencrypted file key only in volatile storage, such as RAM 219. According to various embodiments, the client device 108 may be configured to purge the unencrypted file key from RAM 219 upon the occurrence of predetermined events that could compromise the integrity of the client device 108 including, for example, a shut-down, a loss of network connectivity, a machine administrator or other user with elevated privileges logging-on to the device 108 (this may prevent an unauthorized party from reading the unencrypted file key from RAM 219), and hibernation or standby of the device 108 (e.g. , this may prevent the unencrypted keys from RAM 219 from being written to a less-transitory data storage).

The file key may be encrypted with the KDC's public key 224 (step 410). Because the KDC's public key 224 is accessible to both the KDC 102 and the client device 108, the file key may be encrypted by either device. For example, when the KDC 102 encrypts the file key it may (e.g. , at step 406) transmit both an encrypted and a clear version of the file key to the client device 108. The client device 108 may store the encrypted file key in association with the encrypted file (step 412). Alternatively, the client device 108 itself may encrypt the file key using the public key 222 of the KDC 102. This may make it unnecessary for the KDC 102 to send the client device 108 an encrypted copy of the file key. When the client device 108 is in possession of both the encrypted file key and the encrypted file, it may, via the encryption layer 218, associate the two and store them at one or more of the data storages 206, 208, 210. As described above, the encrypted file key and the encrypted file may be stored within a single data container organized on the desired data storage 206, 208, 210 according to a file system 212 (e.g. , by the encryption layer 218).

In embodiments where the KDC 102 implements an asymmetric key encryption algorithm, it is possible, and may be desirable, for client devices 108 to generate file keys without contacting the KDC 102. For example, Figure 5 illustrates one embodiment of a process flow 500 for encrypting a file without contacting the KDC 102. First, the client 108 may detect an unencrypted file (step 502). For example, an application 204 may create a new data file to be written to one of the data storages 206, 208, 210. In various embodiments, such a request from an application 204 to create a new file may be intercepted and by the encryption layer 218, which may proceed with the encryption process. Also, for example, an application 204, encryption layer 218 or other system component may detect a file stored at one of the data storages 206, 208, 210 in the clear. Upon detection of an unencrypted file, the client device 108 (e.g. , via the encryption layer 218) may generate a file key. The file key may be generated, for example, with a random or a pseudorandom number generator. According to various embodiments, the unencrypted file key may only be stored at RAM 219 and/or other volatile storage locations and may not be stored at any data storage 206, 208, 210. The data file may be encrypted with the file key (step 506). The client device 108 may, in turn, encrypt the file key with the public key of the KDC 102 (step 508). The encrypted data file and encrypted file key may then be stored to the desired data storage 206, 208, 210 in association with one another (e.g. by the encryption layer 218). For example, the data file and data key may be stored in a common data container positioned at the desired data storage 206, 208, 210 according to the local file system 212. Although the file may be encrypted without interaction with the KDC 102, it may be necessary to contact the KDC 102 in order to decrypt the data file with the KDC's 102 private key.

Figure 6 illustrates an alternative embodiment of the client device 108 and KDC 102 where the KDC 102 implements a symmetric key encryption algorithm. The KDC 102 has a symmetric key 602 which is not shared with any other components on the network 100. File open requests may be handled in a manner similar to that described above with respect to Figure 3. Instead of decrypting the file key with its private key 220, however, the KDC 102 may decrypt the file key with its symmetric key 602. Figure 7 illustrates one embodiment of a process flow 700 for encrypting a data file where the KDC 102 utilizes a symmetric key encryption algorithm, as illustrated in Figure 6. The client device 108 may direct an encryption request to the KDC 102. A file key may be generated by the client device 108 and/or by the KDC 102. In embodiments where the client device 108 generates the file key, the encryption request may comprise the file key generated by the client device 108. The request may be sent to the KDC 102 via the secure connection 224 (e.g. , if the unencrypted file key is part of the request). The KDC 102 may receive the request (step 702). If necessary, (e.g. , if the client device 108 hasn't already generated a file key), the KDC 102 may generate a file key (704). Regardless of whether the file key was generated by the KDC 102 or the client 108, the KDC 102 may encrypt the file key with its own symmetric key 602 (step 706). The KDC 102 may then transmit encrypted and unencrypted versions of the file key to the client device 108 via the secure connection 224 (step 708). It will be appreciated that in embodiments where the file key is generated by the client device 108, it may not be necessary for the KDC 102 to re-send the unencrypted file key back to the client device 108. With the unencrypted file key, the client device 108 may encrypt the data file (step 710) and store the data file in association with the encrypted file key (step 712), e.g. , as components of a single data container.

Figure 8 illustrates a logical diagram of one embodiment of a data container 802 including an encrypted file 806 and an encrypted file key 804. The data container 802 may be stored on a data storage device 206, 208, 210 according to any suitable file system 212. The encrypted file key 804 and encrypted file 806 may be incorporated into the data container 802 according to any suitable means. For example, the encrypted file 806 and the encrypted file key 804 may be configured as streams or sub-files of the container 802. In a MICROSOFT WINDOWS environment, this concept of including streams or sub-files within a data container may be called a "file system filter driver" or in the NTFS file system, "streams." In a UNFX/Linux environment, it may be called a "layered" or "stackable" file system, and in MICROSOFT DISK OPERATING SYSTEM (MS-DOS), it may be called an INT21 or INT13 driver.

According to various embodiments, the encrypted file 806 and encrypted file key 804 may be organized within a data container 802 according to a log-structured file system implemented within the container 802. In a log-structured file system, data blocks written to a volume may be posted to the logical end of the volume. Write requests to the volume may comprise the appropriate data block or blocks as well as a log entry tying the logical position of the data block or blocks to their physical position on the volume. To read data blocks from a log-structured volume, one may begin at the logical end of the volume and examine each log entry until the physical position of the desired data block or blocks are found. Figure 9 illustrates a logical diagram of one embodiment of a data container 902 including encrypted file blocks 906 and encrypted file key blocks 904 organized within the data container 902 according to a log-structured file system. As illustrated, the data container 902 may be written from left to right. The data container 902, as shown, comprises an encrypted file key block 904 making up all or a portion of the encrypted file key as well as a plurality of encrypted file blocks 906 making up all or a portion of an encrypted file. Log blocks 908 may tie the logical position of each data block 904, 906 to their position within the data container 902. For example, to retrieve a given encrypted file block 906 and/or encrypted file key block 904, the encryption layer 218 may begin at the logical end of the data container 902 and review every log block 908 until finding the first log block 908 referencing the desired block 904, 906.

It will be appreciated that the encryption and storage functionalities described herein may be implemented at any level of the client devices 108. For example, as described above, the encryption layer 218 may handle file open and encryption request, communicate with the KDC 102 and handle encryption and decryption tasks. According to various embodiments, however, the functionality of the encryption layer 218 may be performed by various other hardware and/or software components of the client 108. For example, the functionality of the encryption layer 218 may be performed by an operating system 202, for example, in conjunction with a file system such as NTFS that supports sub-files or streams.

It will be appreciated that the various computer devices described herein (e.g. , client devices 108, servers 104, 102, etc.) may be implemented with any suitable kind of computing hardware. For example, according to various embodiments client devices 108, 110, 112 and/or servers 104, 102 may comprise one or more processors and operatively associated electronic memory. The electronic memory may comprise instructions for execution by the one or more processors. When executed, the instructions may cause the various computer devices to implement the functionality described herein.

It is to be understood that the figures and descriptions of the present invention have been simplified to illustrate elements that are relevant for a clear understanding of the present invention, while eliminating other elements, for purposes of clarity. Those of ordinary skill in the art will recognize that these and other elements may be desirable. However, because such elements are well known in the art and because they do not facilitate a better understanding of the present invention, a discussion of such elements is not provided herein.

In general, it will be apparent to one of ordinary skill in the art that at least some of the embodiments described herein may be implemented in many different embodiments of software, firmware, and/or hardware. The software and firmware code may be executed by a processor or any other similar computing device. The software code or specialized control hardware that may be used to implement embodiments is not limiting. For example, embodiments described herein may be implemented in computer software using any suitable computer software language type, using, for example, conventional or object-oriented techniques. Such software may be stored on any type of suitable computer-readable medium or media, such as, for example, a magnetic or optical storage medium. The operation and behavior of the embodiments may be described without specific reference to specific software code or specialized hardware components. The absence of such specific references is feasible, because it is clearly understood that artisans of ordinary skill would be able to design software and control hardware to implement the embodiments based on the present description with no more than reasonable effort and without undue experimentation.

Moreover, the processes associated with the present embodiments may be executed by programmable equipment, such as computers or computer systems and/or processors. Software that may cause programmable equipment to execute processes may be stored in any storage device, such as, for example, a computer system (nonvolatile) memory, an optical disk, magnetic tape, or magnetic disk. Furthermore, at least some of the processes may be programmed when the computer system is manufactured or stored on various types of computer-readable media.

It can also be appreciated that certain process aspects described herein may be performed using instructions stored on a computer-readable medium or media that direct a computer system to perform the process steps. A computer-readable medium may include, for example, memory devices such as diskettes, compact discs (CDs), digital versatile discs (DVDs), optical disk drives, or hard disk drives. A computer-readable medium may also include memory storage that is physical, virtual, permanent, temporary, semipermanent, and/or semitemporary.

A "computer," "computer system," "computer device," "host," or "processor" may be, for example and without limitation, a processor, microcomputer, minicomputer, server, mainframe, laptop, personal data assistant (PDA), wireless e-mail device, cellular phone, pager, processor, fax machine, scanner, or any other programmable device configured to transmit and/or receive data over a network. Computer systems and computer-based devices disclosed herein may include memory for storing certain software applications used in obtaining, processing, and communicating information. It can be appreciated that such memory may be internal or external with respect to operation of the disclosed embodiments. The memory may also include any means for storing software, including a hard disk, an optical disk, floppy disk, ROM (read only memory), RAM (random access memory), PROM (programmable ROM), EEPROM (electrically erasable PROM) and/or other computer-readable media. In various embodiments disclosed herein, a single component may be replaced by multiple components and multiple components may be replaced by a single component to perform a given function or functions. Except where such substitution would not be operative, such substitution is within the intended scope of the embodiments. Any servers described herein, for example, may be replaced by a "server farm" or other grouping of networked servers (such as server blades) that are located and configured for cooperative functions. It can be appreciated that a server farm may serve to distribute workload between/among individual components of the farm and may expedite computing processes by harnessing the collective and cooperative power of multiple servers. Such server farms may employ load-balancing software that accomplishes tasks such as, for example, tracking demand for processing power from different machines, prioritizing and scheduling tasks based on network demand and/or providing backup contingency in the event of component failure or reduction in operability.

While various embodiments have been described herein, it should be apparent that various modifications, alterations, and adaptations to those embodiments may occur to persons skilled in the art with attainment of at least some of the advantages. The disclosed embodiments are therefore intended to include all such modifications, alterations, and adaptations without departing from the scope of the embodiments as set forth herein.

Claims

CLAIMS We claim:

1. A computer system for managing secure files, the system comprising:

a key distribution server, wherein the key distribution server is in electronic communication with a client device via a secure connection, and wherein the key distribution server comprises:

at least one processor;

a memory circuit operatively associated with the at least one processor and comprising instructions that, when executed by the at least one processor cause the key distribution server to:

receive from the client device an encrypted file key associated with a first file;

determine whether the client device is authorized to access the file key considering a logical network location of the client device;

conditioned upon the client device being authorized to access the file key, decrypt the file key; and

transmit a decrypted version of the file key to the client device via the secure connection.

2. The computer system of claim 1, wherein the encrypted file key is encrypted according to a symmetric key encryption algorithm.

3. The computer system of claim 2, wherein decrypting the file key comprises decrypting the file key with a symmetric key of the key distribution server.

4. The computer system of claim 1, wherein the encrypted file key is encrypted according to an asymmetric key encryption algorithm.

5. The computer system of claim 4, wherein decrypting the file key comprises decrypting the file key with a private key of the key distribution server.

6. The computer system of claim 1, wherein determining whether the client device is authorized to access the file key also comprises considering a state of the client device.

7. The computer system of claim 6, wherein the considering the state of the client device comprises considering at least one factor selected from the group consisting of: an indication of the applications installed on the client device; a list of executable images loaded at the client device, a checksum of the executables running on the client device, a checksum of the executables stored at a memory and/or one of the data storages of the client device, other users logged-into the client device, drivers loaded on the client device, modules loaded to the client device.

8. The computer system of claim 1, wherein determining whether the client device is authorized to access the file key also comprises considering a network address of the client device.

9. The computer system of claim 1, wherein determining whether the client device is authorized to access the file key also comprises considering a hardware identifier associated with the client device.

10. The computer system of claim 1, wherein the secure connection is generated utilizing the KERB EROS protocol.

11. The computer system of claim 1, wherein the memory circuit further comprises instructions that, when executed by the at least one processor cause the key distribution server to: receive a request to encrypt a second file;

encrypt a second file key associated with the second file; and

transmit the encrypted version of the second file key to the client device via the secure connection.

12. The computer system of claim 11, wherein the memory circuit further comprises instructions that, when executed by the at least one processor cause the key distribution server to receive from the client device an unencrypted version of the second file key.

13. The computer system of claim 11, wherein the memory circuit further comprises instructions that, when executed by the at least one processor cause the key distribution server to generate the second file key, and wherein transmitting the encrypted version of the second file key to the client device comprises transmitting an unencrypted version of the second file key to the client device via the secure connection.

14. The computer system of claim 1, further comprising:

a second key distribution server in electronic communication with the client device via a secure connection, wherein the second key distribution server comprises:

at least one processor;

a memory circuit operatively associated with the at least one processor and comprising instructions that, when executed by the at least one processor cause the second key distribution server to:

receive from the client device a second encrypted file key associated with a second file;

determine whether the client device is authorized to access the second file key considering a logical network location of the client device;

conditioned upon the client device being authorized to access the second file key, decrypt the file key; and

transmit a decrypted version of the second file key to the client device via the secure connection, wherein the first file comprises data classified according to a first security level and the second file key comprises data classified according to a second security level.

15. The computer system of claim 1, further comprising:

a second key distribution server in electronic communication with a second client device via a secure connection, wherein the client device and the second client device are at different logical network locations, and wherein the second key distribution server comprises:

at least one processor;

receive from the second client device a second encrypted file key associated with a second file;

determine whether the second client device is authorized to access the second file key considering a logical network location of the client device;

conditioned upon the second client device being authorized to access the second file key, decrypt the file key; and

transmit a decrypted version of the second file key to the second client device via the secure connection, wherein the first file comprises data classified according to a first security level and the second file key comprises data classified according to a second security level.

16. A computer-implemented method for managing secure files, the method comprising: a key distribution server, receiving from the client device an encrypted file key associated with a first file, wherein the key distribution server is in electronic communication with the client device via a secure connection, and wherein the key distribution server comprises at least one processor and a memory circuit operatively associated with the at least one processor;

the key distribution server receiving from the client device an encrypted file key associated with a first file;

the key distribution server determining whether the client device is authorized to access the file key considering a logical network location of the client device;

the key distribution server decrypting the file key; and

the key distribution server transmitting a decrypted version of the file key to the client device via the secure connection.

17. A computer system for managing secure files, the system comprising:

a client device in electronic communication with a key distribution center via a secure connection, and in electronic communication with an electronic data storage, wherein the client device comprises:

at least one processor; and

a memory circuit operatively associated with the at least one processor and comprising instructions that, when executed by the at least one processor cause the key the client device to:

receive a file open request from an application executed by the client device, wherein the file open request specifies a file;

retrieve from the data storage an encrypted copy of the file encrypted with a file key according to a symmetric key encryption algorithm, and an encrypted copy of the file key;

transmit to the key distribution center: the encrypted file key, and an indication of a logical position of the client device on a network;

receive from the key distribution center an unencrypted copy of the file key via the secure connection; and

decrypt the copy of the data file using the unencrypted copy of the file key, wherein the unencrypted copy of the file key is maintained in a volatile portion of the electronic memory.

18. The computer system of claim 17, wherein the electronic memory further comprises instructions that, when executed by the at least one processor, cause the client device to:

receive a write request directed to the file from the application, wherein the write request comprises a data unit;

encrypt the data unit utilizing the unencrypted copy of the file key maintained in a volatile portion of the electronic memory; and

write the encrypted data unit to the data file.

19. The computer system of claim 17, wherein the data storage comprises a plurality of data containers organized on the data storage according to a first file system, wherein one of the plurality of data containers comprises:

a plurality of data units making up the copy of the data file encrypted with the file key; and at least one data unit making up the encrypted copy of the file key, wherein the plurality of data units and the at least one data unit are organized according to a log-structured file system implemented within the file.

20. The computer system of claim 17, wherein the electronic memory further comprises instructions that, when executed by the at least one processor cause the client device to execute: the application;

an operating system; and

an encryption layer logically positioned between the operating system and the data storage, wherein the encryption layer is configured to:

receive the file open request from an application executed by the client device; retrieve from the data storage the encrypted copy of the file and the encrypted copy of the file key;

transmit to the key distribution center via the secure connection: the encrypted file key, and the indication of a network location of the client device;

receive from the key distribution center the unencrypted copy of the file key via the secure connection; and

decrypt the copy of the data file using the unencrypted copy of the file key.

21. The system of claim 17, wherein the transmitting to the key distribution center via the secure connection also comprises transmitting an indication of an application being executed by the client device.

22. The system of claim 21, wherein the transmitting to the key distribution center via the secure connection also comprises transmitting at least one of a checksum of the executable file of the application and a checksum of at least a portion of a random access memory of the client device.

23. The system of claim 17, wherein the transmitting to the key distribution center via the secure connection also comprises transmitting a hardware identifier associated with the client device.

24. The system of claim 17, wherein the memory circuit further comprises instructions that, when executed by the at least one processor cause the key the client device to:

receive an indication of a second file;

request from the key distribution center a second file key to be associated with the second file;

receive from the key distribution center via the secure connection an encrypted version of the second file key and an unencrypted version of the second file key;

encrypt the second file according to a symmetric encryption algorithm using the unencrypted version of the second file key; and

store an encrypted version of the second file and the encrypted version of the second file key in a common data container at the electronic data storage.

25. The system of claim 17, wherein the memory circuit further comprises instructions that, when executed by the at least one processor cause the key the client device to:

receive an indication of a second file;

generate a second file key;

encrypt the second file according to a symmetric encryption algorithm using the second file key;

encrypt the second file key according to an asymmetric encryption algorithm using a public key of the key distribution center; and

26. The system of claim 17, wherein the memory circuit further comprises instructions that, when executed by the at least one processor cause the key the client device to:

receive an indication of a second file;

generate a second file key to be associated with the second file;

transmit an unencrypted version of the second file key to the key distribution center;

receive from the key distribution center an encrypted version of the second file key;

encrypt the second file according to a symmetric encryption algorithm using the

unencrypted version of the second file key; and

27. The system of claim 17, wherein the memory circuit further comprises instructions that, when executed by the at least one processor cause the key the client device to store the unencrypted version of the file key only in a location selected from the group consisting of volatile portions of the memory circuit and registers of the at least one processor.

28. The system of claim 27, wherein the memory circuit further comprises instructions that, when executed by the at least one processor cause the key the client device to purge the volatile portions of the memory circuit and the registers of the at least one processor upon the occurrence of a predetermined event.

29. The system of claim 28, wherein the predetermined event includes at least one of the group consisting of: a shut-down of the client device; a loss of connectivity between the client device and the network; an administrator logging on to the client device; a user with elevated privileged logging on to the client device; the client device entering a hibernation state and the client device entering a standby state.

30. A computer-implemented method for managing secure files, the method comprising: a client device receiving a file open request from an application executed by the client device, wherein the file open request specifies a file, wherein the client device is in electronic communication with a key distribution center via a secure connection, and in electronic

communication with an electronic data storage, and wherein the client device comprises at least one processor; and a memory circuit operatively associated with the at least one processor; the client device retrieving from the data storage an encrypted copy of the file encrypted with a file key according to a symmetric key encryption algorithm, and an encrypted copy of the file key;

the client device transmitting to the key distribution center: the encrypted file key, and an indication of a logical position of the client device on a network;

the client device receiving from the key distribution center an unencrypted copy of the file key via the secure connection; and

the client device decrypting the copy of the data file using the unencrypted copy of the file key, wherein the unencrypted copy of the file key is maintained in a volatile portion of the electronic memory.