Writing and reading encrypted data using time-based encryption keys

In one aspect, a method to manage encrypted data includes configuring a first portion of a storage medium to store encrypted data. The encrypted data is encrypted using a time-based encryption key. The method also includes configuring a second portion of the storage medium to include metadata identifying the time-based encryption key and storing the time-based encryption key in a location other than the storage medium.

BACKGROUND

Data is generally encrypted to prevent access by unauthorized individuals. Typically, the data is encrypted using a key. In order for the encrypted data to be read, it must be unencrypted using the key. Thus, for example, if a laptop is stolen, data stored on its hard drive cannot be accessed by a perpetrator unless the key is used. To delete encrypted data typically all of the data is rewritten with 1s and 0s, which is typically repeated a number of times.

SUMMARY

In one aspect, a method to manage encrypted data includes configuring a first portion of a storage medium to store encrypted data. The encrypted data is encrypted using a time-based encryption key. The method also includes configuring a second portion of the storage medium to include metadata identifying the time-based encryption key and storing the time-based encryption key in a location other than the storage medium.

In another aspect, an article includes a machine-readable medium that stores executable instructions to manage encrypted data. The instructions cause a machine to configure a first portion of a storage medium to store encrypted data. The encrypted data is encrypted using a time-based encryption key. The machine-readable medium further includes instructions that cause the machine to configure a second portion of the storage medium to include metadata identifying the time-based encryption key and to store the time-based encryption key in a location other than the storage medium. The location is at least one of a cache and a server. The storage medium includes one of a logical unit, a disk drive and a track storage.

In a further aspect, an apparatus, to manage encrypted data, includes circuitry to configure a first portion of a storage medium to store encrypted data. The encrypted data is encrypted using a time-based encryption key. The apparatus also includes circuitry to configure a second portion of the storage medium to include metadata identifying the time-based encryption key; and to store the time-based encryption key in a location other than the storage medium. The location is at least one of a cache and a server. The storage medium includes one of a logical unit, a disk drive and a track storage.

DETAILED DESCRIPTION

Described herein is an approach to encrypt data that will allow easier maintenance of encrypted data. For example, data may be deleted by simply deleting an encryption key rather than deleting the actually data. While the data described herein is described with a logical unit (LUN), the techniques described herein may be used with file system storage or track storage.

Referring toFIG. 1an encryption storage system10includes a key server20(e.g., a RSA® Key Manager (RKM)) that stores encryption keys22, a computer30, a requestor40and an encrypted logical unit (LUN) (50). The requestor40may be an application, a user or a system that requests access to encrypted data, to encrypt data, delete encrypted data, control access to encrypted data and so forth. In one example, the encryption LUN50encrypts/decrypts data. The LUN50accesses the key server20to retrieve the encryption key (e.g., one of the keys22) for encrypting/decrypting the data.

As used herein, the encryption keys22are time-based encryption keys and are useable to encrypt and/or decrypt for a predetermined time period. For example, after the predetermined amount of time a new key is used to encrypt data. In one particular example, a new encryption key is used each week to encrypt data. In one example, the time-based encryption keys are updated based on a policy.

Referring toFIG. 2A, the encrypted LUN50includes data blocks (e.g., data block0(52a), data block1(52b), data block2(52c) and data block3(52d)). Each data block includes a first portion and a second portion. For example, data block0(52a) includes a first portion54aand a second portion58a; data block1(52b) includes a first portion54band a second portion58b; data block2(52c) includes a first portion54cand a second portion58c; and data block3(52d) includes a first portion54dand a second portion58d.

The first portion54a-54dis configured to store encrypted data and the second portion is configured to store an ID of a key (key ID) used to encrypt the data in the first portion. For example, encryption key1is identified as key ID1. It is important to emphasize that the actual key to encrypt the data in the data block is stored elsewhere. For example, the keys22are stored on the server20. In one example, data block0(52a) includes encrypted data W in the first portion54aand a key ID1in the second portion58a; data block1(52b) includes encrypted data X in the first portion54band a key ID2in the second portion58b; data block2(52c) includes encrypted data Y in the first portion54cand a key ID2in the second portion58c; and data block3(52d) includes encrypted data Z in the first portion54dand a key ID3in the second portion58d.

Referring toFIG. 2B, in one example, the data in data block0(52a) is updated with encrypted data W′ in the first portion54a. In one example, the old key, key1, is expired and no longer useable. In other examples, the old key, key1, is not expired (e.g., the key1may be valid to read encrypted data), but it is not the newest key. The encrypted data W′ is encrypted with a new key, for example, key4. The ID of key4, Key ID4, is stored in the second portion58aof data block0(52a) to identify the key that encrypted the data in data block0(52a).

In one example, the Key IDs may be stored immediately after the data itself is stored. For instance, in a storage system (e.g., the LUN50) where each sector has 520 bytes instead of 512 bytes per sector, the key ID can be stored in some of the last 8 bytes of the sector. In other examples, the key ID may be stored in a special area of the LUN.

Referring toFIG. 3, one example of a process to store encrypted data is a process100. A policy is received (102). For example, a policy may be a write policy. In particular, the write policy may require that encryption keys are updated on a periodic basis.

New data is received to be encrypted (108). The data is encrypted (112) using the appropriate key and stored (114). For example, data W is encrypted using key1and stored in the first portion54aof data block0(52a) (FIG. 2A).

The ID of the key is stored. For example, if the data W is encrypted using key1and stored in the first portion54aof data block0(52a) then the ID of the key, key ID1, is stored in the second portion58aof data block0(52a) (FIG. 2A).

If there are additional writes (i.e., data to be encrypted and stored) it is determined if there is a change in policy (124). If there is not a change in policy, then processing blocks108,112,116and122are repeated. If there is a change in policy, a new policy is received (102) and processing blocks108,112,116and122are repeated using the new policy.

Referring toFIG. 4, one example of a process to read encrypted data is a process200. A request is received to read encrypted data (212). The key ID associated with the key used to encrypt the data is determined (218) and used to decrypt the data so it may be read. For example, if a request to read data block1(52b) of LUN50is received, then it is determined that the key ID is key ID1so that key1is used to decrypt data W (seeFIG. 2A). In one example, the encryption key is requested from the key server20.

In another example, the storage system10may cache keys in a cache (e.g., in a key cache540(FIG. 6)) so it will not have to access the key server20on every IO, but periodically. The storage system10will access the key server to get a new key policy, and if a key was erased the storage system10will erase it from the cache. In one example, the storage system10stores encryption keys in the cache in a volatile memory (e.g., volatile memory524(FIG. 6)).

Because of the time-based nature of updating the keys, some keys may be valid but not the newest key and some keys are so old that there are invalid. For example, there are at least three types of encryption keys used to read encrypted data. One type is a latest (e.g., newest, current) type key available. With the latest type key, the encrypted data is decrypted using the latest key and provided, for example, to the user when the user requests a read. Another type key is a valid but older type key (e.g., the key is valid for reading encrypted data but is older than allowed by a policy and is no longer used for encrypting new data). In this case, data is encrypted with the new key instead and stored but the unencrypted data is still provided, for example, to the user. A still further type key is an invalid type key. The invalid type key is a key that has been erased from the server22or has expired. In this case, using an invalid key will result in the read request failing, since storage cannot decrypt the data.

Process300will determine if the encryption key is invalid (224). If the key is invalid, the read request will fail (226).

If the key is not invalid, then process300will read and decrypt the data (227). Process300determines if the key needs updating based on a refresh policy (228). For example, even though keys used to encrypt data are updated once a week, in reading encrypted data, the refresh policy may require that keys used to read encrypted data be refreshed (updated) to the newest key only once a month. If the key does not need updating (refreshing), then the data is provided (262), for example, as a read IO.

If the key is not the newest key, for example, the encryption key is outdated based on a policy (e.g., keys older than a month are updated), then the key is updated on a read request based on the policy, the data is decrypted using the old key then re-encrypted with the latest encryption key (e.g., a newer encryption key than an outdated encryption key) (234), the new encrypted data is stored back to the LUN50(244) and the key ID is updated to reference the new encryption key (254). In one example, processing blocks234,244and245are performed before acknowledging the read (262).

Referring toFIG. 5, one example of a process to delete encrypted data is a process300. A request is received to delete encrypted data (302). The keys IDs associated with the encrypted data are determined (308). Keys associated with the key IDs are deleted (312).

For example, a request will be to erase all data older then a specific time. In one particular example, a regulation (e.g., a retention policy) may require deletion of all data older then 7 years so that process300will erase all older keys. The encryption keys are deleted from the key server20, and on a periodic update the storage system will erase their keys from the memory. If a user had access to an old encryption key, when the data that used the old encryption key is changed to use a newer encryption key the user will not be able to read the newer data even if the user takes the physical spindles out of the storage system.

While a LUN is described herein other data storage environments may be used. For example, a file system may be used wherein a metadata file that includes a key ID of the key used to encrypt the data may be stored together with the encrypted data file. In one particular example, a portable storage drive includes an encrypted data file and another file includes the key ID. In another example, a track storage system may be used so that for each track or a number of tracks that includes data encrypted by an encryption key another track stores the key ID identifying the encryption key used to encrypt the data. In a further example, like in an EMC® SYMMETRIX® Storage system for example, the minimum encryption portion may be a track of 64 KB, so that each track will have a key ID attached to it, and the key ID may be kept in a cache.

Referring toFIG. 6, an example of the computer30is a computer30′. The computer30′ includes a processor522, a volatile memory524, a non-volatile memory528(e.g., hard disk) and a user interface (UI)528(e.g., a mouse, a keyboard, a display, touch screen and so forth). The non-volatile memory524stores computer instructions534, an operating system536and data538. The volatile memory includes the key cache540to store a copy of encryption keys located on the server20. In one example, the computer instructions534are executed by the processor522out of volatile memory524to perform all or part of the processes described herein (e.g., processes100,200,300,400,500).

The processes described herein (e.g., processes100,200,300,400,500) are not limited to use with the hardware and software ofFIG. 6; they may find applicability in any computing or processing environment and with any type of machine or set of machines that is capable of running a computer program. The processes described herein may be implemented in hardware, software, or a combination of the two. The processes described herein may be implemented in computer programs executed on programmable computers/machines that each includes a processor, a storage medium or other article of manufacture that is readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and one or more output devices. Program code may be applied to data entered using an input device to perform any of the processes described herein and to generate output information.

The processes described herein are not limited to the specific embodiments described. For example, the processes100,200,300,400and500are not limited to the specific processing order ofFIGS. 3 to 5, respectively. Rather, any of the processing blocks ofFIGS. 3 to 5may be re-ordered, combined or removed, performed in parallel or in serial, as necessary, to achieve the results set forth above.