Method and system for protecting data

The present invention is directed to a method and system for protecting data. In accordance with a particular embodiment of the present invention a new file is created. Key information is retrieved for the file from a keyserver. The key information includes, a key, a key identifier, and encryption algorithm information. The file is encrypted using the encryption algorithm. The key identifier is stored in a data repository. The data repository relates the key identifier to the encrypted file.

TECHNICAL FIELD

The present disclosure relates generally to computer security, and more particularly to a method and system for protecting data.

BACKGROUND

Computer security has become increasingly more important, particularly in order to protect against data loss. Lost or stolen computers may result in compromised personal and private data of individuals or organizations. Because of the critical and potentially devastating loss of this highly sensitive data, these losses could expose individuals and organizations to a wide range of liability, fraud, and identify theft.

SUMMARY

In accordance with the present invention, the disadvantages and problems associated with previous techniques for protecting data may be reduced or eliminated.

In accordance with a particular embodiment or the present disclosure, a method for protecting data includes creating a new file. The method also includes retrieving key information for the file from a keyserver. The key information includes a key, a key identifier, and encryption algorithm information. The method further includes encrypting the file using the encryption algorithm. The method further includes storing the key identifier in a data repository. The data repository relates the key identifier to the encrypted file.

Technical advantages of particular embodiments of the present disclosure include a system and method for protecting data that provides protection against lost or stolen computers. For example, files on a laptop may be encrypted using keys stored on an organization's network. Thus, if the laptop is lost or stolen, the files would not be accessible outside the organization's network.

Further technical advantages of particular embodiments of the present disclosure include a system and method for protecting data that may encrypt a key exchange session. For example, a thief may install a network sniffer at an organization, and acquire the keys for a laptop or desktop from the organization. Using encrypted key exchange sessions would prevent the thief from acquiring the keys.

DESCRIPTION OF EXAMPLE EMBODIMENTS

With the advent of mobile computing, protecting data has become increasingly important. For example, data may be compromised if an employee of an organization takes data home on a laptop, and the laptop is inadvertently lost or stolen. Lost or stolen computers may create serious liability for the organization. Thus, there is a strong demand for products that allow organizations to control access to data on computers once the computers leave the organization's network.

In accordance with the teachings of the present disclosure, when a file is created on a client, such as a laptop, the file may be automatically encrypted using a key retrieved from a keyserver on the network. When the client is shut down or idle for a period of time, the key is lost. When the client is started, the client retrieves the key again from the keyserver, and may then decrypt the files. If the client is not on a network that can access the keyserver, the key cannot be obtained, and the files may not be accessed. Thus, the method provides data protection for lost or stolen computers. Additional details of example embodiments of the present disclosure are described in detail below.

FIG. 1is a block diagram illustrating a system10for protecting data, according to the teachings of the present disclosure. System10generally includes one or more clients12storing one or more files14, a network16, and a keyserver20. According to the embodiment, when a file14is created at client12, client12may retrieve key information from keyserver20. The key information may comprise any suitable information for encrypting file14, such as encryption algorithm information, a key, and a key ID. Once client12obtains the key, client12creates file14and stores the key and file information in a data repository, such as a database, that relates files to their respective keys.

Subsequently, when file14is accessed, client12may access the data repository to determine if file14is encrypted. If not, file14may be accessed. If file14is identified as encrypted, client12may suspend the access request to file14and attempt to retrieve the key associated with the file14from keyserver20. If client12cannot retrieve the key, access to file14is denied.

Client12may refer to any suitable device operable store files14. Client12may include, for example, a personal digital assistant, a computer such as a laptop, a cellular telephone, a mobile handset, or any other device operable to store file14. Client12may include any operating system such as MS-DOS, PC-DOS, MAC-OS, WINDOWS, UNIX, OpenVMS, or other appropriate operating systems, including future operating systems.

File14may refer to any suitable data stored at client12. For example, file14may be word processing file. File14may also include other data, such as a database, spreadsheet, text file, or any other suitable file.

Network16may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. Network16may comprise all or a portion of a public switched telephone network (PSTN), a public or private data network, a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a local, regional, or global communication or computer network such as the Internet, a wireline or wireless network, an enterprise intranet, other suitable communication link, or any combination of the preceding.

Network16may utilize protocols and technologies to transmit information. Example protocols and technologies include those described by the Institute of Electrical and Electronics Engineers, Inc. (IEEE) 802.xx standards such as 802.11, 802.16, or WiMAX standards, the International Telecommunications Union (ITU-T) standards, the European Telecommunications Standards Institute (ETSI) standards, Internet Engineering Task Force (IETF) standards, the third generation partnerships project (3GPP) standards, or other standards.

Keyserver20may refer to any suitable device operable to process requests from client12. Examples of keyserver20may include a host computer, workstation, web server, file server, a personal computer such as a laptop, or any other device operable to process requests from client12. Keyserver20may include any operating system such as MS-DOS, PC-DOS, MAC-OS, WINDOWS, UNIX, OpenVMS, or other appropriate operating systems, including future operating systems. Additional details of example embodiments of the disclosure are described in greater detail below in conjunction with portions ofFIG. 2andFIG. 3.

FIG. 2is a block diagram illustrating an example client12and an example keyserver20of the system ofFIG. 1, according to one embodiment of the present disclosure. In the illustrated embodiment, keyserver20includes key information50and client12includes a processor24, a memory device26, a communication interface28, an output device30, an input device32, and a storage device34. Storage device34includes file14and an encryption manager40.

Encryption manager40may refer to any suitable logic embodied in computer-readable media, and when executed, that is operable to protect data, such as file14, using key information50from keyserver20. In the illustrated embodiment of the disclosure, encryption manager40resides in storage device34. In other embodiments of the disclosure, encryption manager40may reside in memory device26, or any other suitable device operable to store and facilitate retrieval of data and instructions.

According to one embodiment of the disclosure, encryption manager40may be operable to encrypt file14when file14is created. For example, when file14is created, encryption manager40may retrieve key information50from keyserver20. Key information50may include, for example, encryption algorithm information, a key, and a key ID. Once encryption manager40obtains key information50, encryption manager40allows file14to be created, encrypts file14using the key obtained from key information50, and stores information identifying the key and file14in a data repository, such as a database on storage device34.

Encryption manager40may be operable to decrypt file14when it is accessed. For example, when file14is accessed, encryption manager40may access the data repository to determine if file14is encrypted. If file14is not encrypted, file14may be accessed without being decrypted by encryption manager40. If file14is identified as encrypted, encryption manager40may suspend the access request to file14and attempt to retrieve key information50associated with the file14from keyserver20. If encryption manager40cannot retrieve key information50for file14, access to file14is denied by encryption manager40, or any other suitable logic operable to prevent access to file14.

If encryption manager40retrieves key information50, encryption manager40may decrypt file14using the key. In one embodiment, if file14is subsequently modified, encryption manager40may encrypt the modified file14using the same key. In other embodiments, encryption manager40may retrieve a new key to encrypt the modified file14.

As described above, encryption manager40may store key information50and file14information in a data repository, such as a database, that relates files14to their respective keys. For example, encryption manager40may store a new entry in the data repository when file14is created. An entry in the data repository may include, for example, a file path for file14and a key ID for the key. As another example, encryption manager40may remove an entry in the data repository when file14is deleted. As yet another example, encryption manager40may update an entry if file14is renamed. In one embodiment, the data repository may be stored on storage device34. In other embodiments, the data repository may reside in memory device26, or any other suitable device operable to store and facilitate retrieval of data and instructions.

According to one embodiment of the disclosure, encryption manager40may access multiple keyservers20and may retrieve a different encryption algorithm for each file14. For example, in one embodiment, when file14is created at client12, encryption manager40may request default key information50from keyserver20. In another embodiment, if client12is configured to use multiple keyservers20, encryption manager40may request key information50from a random keyserver20, and the random keyserver20may use a new encryption algorithm.

In one embodiment, encryption manager40may determine whether it supports a particular encryption algorithm when it requests default key information50. If encryption manager40does not support the algorithm, it may request key information50for its strongest supported encryption algorithm. If keyserver20does not have key information50for that algorithm, keyserver20may return a negative response, which may cause encryption manager40to request the next strongest algorithm. In order to prevent the possibility that encryption manager40and keyserver20have no algorithm in common, encryption manager40and keyserver20may both support a common encryption algorithm, such as a Triple Data Encryption Standard (3DES) algorithm.

According to one embodiment of the disclosure, encryption manager40may cache default key information50for a finite length of time, after which it must request key information50again. Non-default key information50may be cached until client12is shut down or idle for a period of time. In one embodiment, encryption manager40may erase key information from a memory or cache if client12is restarted from a suspended mode. In the embodiment, key information50stored in memory may be encrypted using a hard-coded key (perhaps based on information that will not change during the life of the process), and any key information50erased from memory may be modified before the memory is freed to ensure that key information50cannot be recovered.

In one embodiment, the keys and their associated key IDs may be random. For example, if the key IDs are random, it may be possible to retrieve the associated key from a single keyserver20. In the example, the key ID may be at least 32 bits, so there would need to be two billion keys to have a 50% chance that two keyservers20will have two different keys with the same key ID. Having random key IDs may prevent files14from being corrupted in the event that encryption manager40retrieves an incorrect key for a particular key ID. In other embodiments, keys may be copied between two keyservers20to provide load balancing.

According to one embodiment of the disclosure, encryption manager40and keyserver20may communicate over an encrypted communication session. For example, keyserver20may be configured such that it will only handle encrypted requests. Otherwise, keyserver20may handle encrypted requests only if encryption manager40encrypts the requests. If encryption manager40is configured to encrypt requests, but keyserver20does not require encryption, the communication may be encrypted anyway. If encryption manager40is not configured to encrypt requests, and keyserver20requires encryption, encryption manager40may encrypt requests after receiving an error from keyserver20.

Encryption manager40and keyserver20may communicate using any suitable protocol. For example, communication may occur over User Datagram Protocol (UDP) to maximize the scalability of keyserver20.

In one embodiment, a request from encryption manager40may include one or more components. Any of the following components of the request may be encrypted once key information50is established. For example, the request may include a session ID, which may be used by keyserver20to determine which key to use for an encrypted communication. The request may also include a random request ID. The request ID may be echoed back to encryption manager40in a response so encryption manager40knows which request was responded to from keyserver20. The request ID may be random to prevent another machine from sending spoofed responses.

The request may further include an operation. For example, the operation may include a ‘get key’ operation, but other operations may be used during a key exchange. The request may further include the data size. The data size may include any padding that may be added to the request to satisfy alignment requirements of the encryption algorithm. The request may further include the data associated with the operation. For example, in the case of a ‘get key’ operation, the data may contain the key ID of the key. The request may further include a hash of the entire decrypted request. The hash may be used in encrypted requests to determine if the decryption was performed correctly. Before the key is established, the hash may be ignored.

Similar to requests, responses may have the same format as the requests. The session ID, request ID and operations may match for encryption manager40to accept the response. For example, in the case of a ‘get key’ operation, the response may contain the requested key.

In one embodiment of operation, a key exchange between encryption manager40and keyserver20may be performed as follows. Encryption manager40sends an ‘establish session’ request, passing random data used to calculate the key, and −1 for the session ID to indicate an unencrypted session. Keyserver20generates random data, generates a session ID, and calculates the key. Keyserver20sends the random data back to client, so encryption manager40may generate its key. Encryption manager40may store the session ID for use in future requests.

In one embodiment, once a session has existed for at least 30 minutes, the session may be expired by keyserver20. Keyserver20may record the IP address associated with the session, and if the IP address does not match the session ID, keyserver20may respond with an error. If key information50has not been established for this session, the error response may contain a session ID of −1 and a request ID of −1. Encryption manager40may then respond to this error by re-establishing its session. If encryption manager40does not get a response within the timeout, it may try the request again with a new request ID.

According to one embodiment of the disclosure, encryption manager40may be operable to provide a user interface. For example, it is possible that a user may demand that he be able to access his data while away from the network, and still desire the data protection. To provide this capability, encryption manager40may be operable to copy key information50of the appropriate keyserver20onto a portable storage medium, such as a Compact Disc (CD). However, this may increase the probability of data being compromised so appropriate measures to secure the CD may be appropriate.

According to one embodiment of the disclosure, the encryption/decryption of files14may be Federal Information Processing Standards (FIPS) compliant. For example, to perform encryption/decryption of the files, encryption manager40may use a file named ‘fips.sys,’ which is a driver provided by Microsoft that provides several different encryption algorithms to support FIPS compliant cryptography. Additional details of the other components of client12are described below.

Processor24may refer to any suitable device operable to execute instructions and manipulate data to perform operations for client12. Processor24may include, for example, any type of central processing unit (CPU).

Memory device26may refer to any suitable device operable to store and facilitate retrieval of data, and may comprise Random Access Memory (RAM), Read Only Memory (ROM), a magnetic drive, a disk drive, a Compact Disk (CD) drive, a Digital Video Disk (DVD) drive, removable media storage, any other suitable data storage medium, or a combination of any of the preceding.

Communication interface28may refer to any suitable device operable to receive input from keyserver20, send output to keyserver20, perform suitable processing of the input or output or both, communicate to other devices, or any combination of the preceding. Communication interface28may include appropriate hardware (e.g. modem, network interface card, etc.) and software, including protocol conversion and data processing capabilities, to communicate through a LAN, WAN, or other communication system that allows client12to communicate to other devices. Communication interface28may include one or more ports, conversion software, or both.

Output device30may refer to any suitable device operable for displaying information to a user. Output device30may include, for example, a video display, a printer, a plotter, or other suitable output device.

Input device32may refer to any suitable device operable to input, select, and/or manipulate various data and information. Input device32may include, for example, a keyboard, mouse, graphics tablet, joystick, light pen, microphone, scanner, or other suitable input device.

Storage device34may refer to any suitable device operable for storing data and instructions. Storage device34may include, for example, a magnetic disk, flash memory, or optical disk, or other suitable data storage device.

FIG. 3is a flow diagram illustrating a method100for protecting data, according to one embodiment of the present disclosure. The method begins at step102where a client retrieves key information for a file. For example, the client may retrieve a key from a keyserver for a file that is new or recently modified. The key information may also include a key ID and encryption algorithm information. Next, at step104, the file is encrypted using the encryption algorithm associated with the key.

At step106, the client stores the key ID in a data repository, such as a database, that relates the file to its respective keys. An entry in the data repository may include, for example, a file path for a file and a key ID for the key.

The client may receive a request to access the file at step108. For example, the client may be shut down or idle for a period of time, and the key is lost. Method100proceeds to step110to retrieve the key from the keyserver based on the key ID stored in the data repository. If the client receives an error at step112, indicating a problem with accessing the key, method100proceeds to step114where access is prevented for the file. Otherwise, if the keyserver returns the key at step112, method100proceeds to step116where the file is decrypted and access is allowed for the file.

Thus, the method described herein improves current methods to protect data. Data files of new or updated files on a client are encrypted with a key retrieved from a keyserver on a network. If the client is shut down or idle for a period of time, the key is lost. For subsequent requests to access the encrypted file, the client retrieves the key from the keyserver and decrypts the file. If the client is not on a network that can access the keyserver, the client cannot retrieve the key, and access to the file is denied. Thus, the method provides protection against lost or stolen computers, such as laptops.

Numerous other changes, substitutions, variations, alterations and modifications may be ascertained by those skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations and modifications as falling within the spirit and scope of the appended claims. Moreover, the present disclosure is not intended to be limited in any way by any statement in the specification that is not otherwise reflected in the claims.