GB2446173A

GB2446173A - Key management for secure data backup

Info

Publication number: GB2446173A
Application number: GB0701686A
Authority: GB
Inventors: Shiraz Billimoria; John William Drew
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2007-01-30
Filing date: 2007-01-30
Publication date: 2008-08-06
Also published as: GB0701686D0

Abstract

Data received by a data transfer device for backup is encrypted using an encryption key 36, 37 and is stored on a removable data storage item along with an encrypted copy of the decryption key 38 necessary to decrypt the data. The decryption key may be encrypted using a public key generated by a trusted third party (TTP). When a user wishes to access the backup data the encrypted decryption key is provided to the trusted third party for decryption. The trusted third party verifies the user, decrypts the encrypted decryption key using the corresponding private key of the public key and provides the user with the decryption key (fig. 5). The decryption key is then used to decrypt the encrypted backup data. The data transfer device may be a tape drive (fig. 2) and the removable data storage item may be a tape cartridge. The encrypted data may be stored in a format selected from one of the generations of LTO and DSS/DAT formats.

Description

DATA TRANSFER DEVICE AND KEY MANAGEMENT METHOD

FIELD OF THE INVENTION

The present invention relates to a data transfer device for transferring data to a data storage item, wherein data are encrypted by the data transfer device during transfer. The present invention also relates to a method of managing the keys necessary to decrypt the data stored on the data storage item.

BACKGROUND OF THE INVENTION

Data backup is a valuable tool in safeguarding important data. Data are generally backed-up onto removable data storage items, such as tape cartridges or optical discs, such that the backup data may be stored at a different geographical location to the primary data.

By storing important data onto removable data storage items, security issues become a consideration. For example, owing to its relatively small size, a tape cartridge storing large amounts of commercially sensitive data might easily be stolen.

Many backup software packages provide the option of encrypting data prior to backup. A drawback with this approach, however, is that the same software package must be used in order to retrieve and decrypt the backup data.

Accordingly, backup data cannot be recovered using other legitimate systems where the backup software is not provided. Additionally, software encryption consumes valuable computer resources.

When storing large amounts of data, it is preferable that different encryption keys are used to encrypt different portions of data. This then minimises the chances of data being recovered by unauthorised parties through the use of a mathematical or brute-force attack on the encrypted data. Additionally, should a decryption key unfortunately become known, the use of different encryption keys ensures that not all data are compromised. When different encryption keys are used to encrypt data, it is vital that adequate key management procedures are put in place to ensure that data can be subsequently recovered.

Nevertheless, there are inherent risks associated with known key management schemes. In particular, the key necessary to decrypt a particular portion of data may become lost and consequently the data cannot be recovered. This is particularly true of key management schemes in which a large number of encryption keys are used to encrypt data.

SUMMARY OF THE INVENTION

In a first aspect, the present invention provides a data transfer device for transferring data to a removable data storage item, the data transfer device being operable to: receive data to be stored to the removable data storage item; encrypt the data using an encryption key, the encrypted data requiring a decryption key for decryption; store the encrypted data to the removable data storage item; and store an encrypted copy of the decryption key to the removable data storage item.

Where the data transfer device encrypts the data to be stored using symmetric encryption, the encryption key and decryption key are, of course, one and the same. Indeed, it is to be understood that reference herein to a decryption key should be understood to be an encryption key for symmetric encryption.

Advantageously, the decryption key is encrypted using an encryption key different to that used to encrypt the data to be stored.

Preferably, the data transfer device is operable to receive the encryption key and the decryption key, and to encrypt the decryption key using an asymmetric encryption algorithm to create the encrypted copy of the decryption key. Where the data transfer device encrypts the data to be stored using symmetric encryption, the data transfer device receives only an encryption key and encrypts the encryption key to create the encrypted copy of the decryption key.

Advantageously, the data transfer device is operable to receive a public key and to encrypt the decryption key using a public-private encryption algorithm that employs the public key to create the encrypted copy of the decryption key.

Conveniently, the data transfer device is operable to receive the encryption key and the encrypted copy of the decryption key.

Preferably, the data transfer device is operable to store the encrypted data as one or more data blocks, and to store the encrypted copy of the decryption key as part of at least one of the data blocks.

More preferably, each data block comprises a data region and an information table, and the encrypted data is stored in the data regions of the data blocks and the encrypted copy of the decryption key is stored in the information table of at least one of the data blocks.

Advantageously, the removable data storage item comprises a data medium having a user data region and a non-user data region, and the data transfer device is operable to store the encrypted data to the user data region and to store the encrypted copy of the decryption key to the non-user data region.

Conveniently, the removable data storage item includes a data medium and a memory device, and the data transfer device is operable to store the encrypted data to the data medium and to store the encrypted copy of the decryption key to the memory device.

Preferably, the data transfer device is operable to: receive a request to retrieve the encrypted copy of the decryption key from the removable data storage item; retrieve the encrypted copy of the decryption key from the removable data storage item; and output the encrypted copy of the decryption key.

Advantageously, the data transfer device is suitable for transferring data from the removable data storage item, the data transfer device being operable to: retrieve encrypted data from the removable data storage item; decrypt the encrypted data using the decryption key; and output the decrypted data.

Conveniently, the data transfer device is operable to store the encrypted data in a format selected from one of the generations of LTO and DDS/DAT formats.

Preferably, the data transfer device is a tape drive and the removable data storage item is a tape cartridge.

In a second aspect, the present invention provides a data transfer device for transferring data to a removable data storage item, the data transfer device comprising: means for receiving data to be stored to the removable data storage item; means for encrypting the data using an encryption key, the encrypted data requiring a decryption key for decryption; means for storing the encrypted data to the removable data storage item; and means for storing an encrypted copy of the decryption key to the removable data storage item.

Preferably, the data transfer device comprises means for receiving the encryption key and the decryption key, and means for encrypting the decryption key using an asymmetric encryption algorithm to create the encrypted copy of the decryption key.

Advantageously, the data transfer device comprises means for receiving a public key, and the means for encrypting the decryption key uses a public-private encryption algorithm that employs the public key.

In a third aspect, the present invention provides a method of storing data comprising: encrypting data using an encryption key, the encrypted data requiring a decryption key for decryption; storing the encrypted data to a data storage item as one or more data blocks; and storing an encrypted copy of the decryption key to the data storage item as part of at least one of the data blocks.

Preferably, each data block comprises a data region and an information table, and the encrypted data is stored in the data regions of the data blocks and the encrypted copy of the decryption key is stored in the information table of at least one of the data blocks.

Advantageously, the method comprises: encrypting the decryption key using a public-private encryption algorithm that employs a public key to create the encrypted copy of the decryption key; encrypting further data using a further encryption key, the encrypted further data requiring a further decryption key for decryption, the further decryption key differing from the decryption key; encrypting the further decryption key using the public key; storing the encrypted further data to the data storage item as one or more further data blocks; and storing the encrypted copy of the further decryption key to the data storage item as part of at least one of the further data blocks.

Advantageously, the data storage item is a tape cartridge.

In a fourth aspect, the present invention provides a method of key management comprising: generating a public key and a private key of a public-private key pair; generating an encryption key and a corresponding decryption key, the encryption key being used to encrypt data; asymmetrically encrypting the decryption key using the public key; and storing the encrypted decryption key along with data encrypted using the encryption key.

Preferably, data encrypted using the encryption key are stored as one or more data blocks, and the encrypted decryption key is stored as part of at least one of the data blocks.

Advantageously, each data block comprises a data region and an information table, and data encrypted using the encryption key is stored in the data regions of the data blocks and the encrypted decryption key is stored in the information table of at least one of the data blocks.

Conveniently, the method comprises: generating a further encryption key and a corresponding further decryption key, the further decryption key differing from the decryption key; asymmetrically encrypting the further decryption key using the public key; and storing the encrypted further decryption key along with data encrypted using the further encryption key.

Preferably, a user generates the encryption key and the decryption key; a third party generates the public key and the private key; the third party stores the private key and provides the user with the public key; the user asymmetrically encrypts the decryption key using the public key; and the user stores the encrypted decryption key along with data encrypted using the encryption key.

Advantageously, the user retrieves the encrypted decryption key from storage; the user provides the third party with the encrypted decryption key; the third party verifies that the user is authorised to use the decryption key; the third party decrypts the encrypted decryption key using the private key in the event that the user is authorised to use the decryption key; and the third party provides the user with the decryption key.

The terms user' and third party', as employed in the preceding paragraphs and in the claims, should be understood to encompass devices operated or owned by the user and third party, e.g. a computer or data transfer device.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the present invention may be more readily understood, embodiments thereof will now be described, by way of example, with reference to the accompanying drawings, in which: Figure 1 illustrates a key management arrangement embodying the present invention; Figure 2 is a schematic block diagram of a tape drive employed in the arrangement of Figure 1 and embodying the present invention; Figure 3 illustrates a record at various stages of formatting by the tape drive of Figure 2; Figure 4 illustrates a first part of a method of key management embodying the present invention; Figure 5 illustrates a second part of a method of key management embodying the present invention.

DETAILED DESCRIPTION

The arrangement 1 of Figure 1 comprises a server computer 2, a client computer 3 and a tape drive 4.

The server computer 2 is operated by a trusted third party or other escrow agent and stores a database of registered users. For each registered user, the database stores information that can be used to verify the identity of the user (e.g. username, password, other personal information, etc.) and a private key that is particular to the user. The private key is one part of public-private key pair for use in public-private encryption.

The client computer 3 is in communication with the server computer 2 over a network such as the internet. The client computer 3 is also in communication with the tape drive 4, which may be connected directly to the client computer 3 or connected to the client computer 3 via a network. The client computer 3 is operated by a user and stores backup data that are to be archived onto tape using the tape drive 4.

As illustrated in Figure 2, the tape drive 4 comprises a controller 5, a firmware memory 6, a drive interface 7, a record manager 8, a CRC recorder 9, a data compressor 10, a data encryptor 11, a data packer 12, a memory buffer 13, a data formatter 14, a digital signal processor 15, write 16 and read 17 pre -amplifiers, and magneto-resistive heads 18. With the exception of the data encryptor 11 and the contents of the firmware memory 6, the components of the tape drive 4 are identical to those employed in conventional linear-tape-open (LTO) tape drives.

The firmware memory 6 is non-volatile and stores firmware instructions 27 and a public key 28 of a public-private key pair. As noted above, and described in further detail below, the corresponding private key is stored in escrow by the server computer 2 of the trusted third party.

The controller 5 comprises a microprocessor, which executes the firmware instructions 27 to control the operation of the tape drive 1.

The drive interface 7 controls the exchange of data between the tape drive 4 and the client computer 3. Control signals (e.g. write and read commands) received from the client computer 3 by the interface 7 are delivered to the controller 6, which, in response, controls the operation of the tape drive 4.

Data received from the client computer 3 typically arrives in high speed bursts and the drive interface 7 includes a burst memory 21 for temporarily storing data received from the client computer 3.

When backup data are to be written to tape, the record manager 5 retrieves the data from the burst memory 21 and appends record boundaries. The CRC recorder 9 then appends a cyclic redundancy check (CRC) to each record.

Each of the protected records is then compressed by the data compressor 10 using LTO scheme-I (ALDC) compression. The integrity of the compressed records is then verified by the data compressor 10, after which the compressed records are delivered to the data encryptor II.

The data encryptor 11 comprises a data padder 22, an encryption engine 23, a key memory 24, a CRC recorder 25 and a data compressor 26. The CRC recorder 25 and data compressor 26 of the data encryptor II shall be referred to hereafter as the encrypt CRC recorder 25 and encrypt data compressor 26 so as to distinguish them from the other CRC recorder 9 and data compressor 10.

As described below, the data encryptor 11 employs block encryption, each block having 128 bits. The data padder 22 therefore appends an end-of-record (EOR) codeword to each compressed record and pads each compressed record with redundant data (e.g. with zeros) such that each compressed record is an integral number of 128 bits.

The encryption engine 23 employs a Galois Counter Mode (GCM) encryption algorithm to encrypt each padded, compressed record. The key memory 24 -10 -may be volatile or non-volatile, depending on the intended applications of the tape drive 4, and stores a 256-bit encryption key that is used by the encryption engine 23. Other keys such as a 128 or a 192 bit key may also be used.

Each write command issued by the client computer 3 is accompanied by a copy of the encryption key that is to be used to encrypt the data. The controller 5, in response to receiving the write command, stores the accompanying encryption key in the key memory 24 for use by the encryption engine 23. Alternatively, rather than an encryption key being sent with each write command, the client computer 3 may instead issue a special SET_KEY command, which includes a copy of the encryption key to be used. The controller 5, in response to the SET_KEY command, then stores the accompanying encryption key to the key memory 24.

The encryption engine 23 divides each padded, compressed record into blocks of 128 bits. Each block is then encrypted using the encryption key held in key memory 24 and a counter value.

After data encryption, the encryption engine 23 appends an initialisation vector to the beginning of the blocks of ciphertext and an authentication tag to the end of the blocks of ciphertext to create a pseudo-record. The initialisation vector is the counter value for the first block of ciphertext of the pseudo-record, whilst the authentication tag is generated in accordance with the GCM specification and comprises a form of checksum data generated over the data of a record.

The tag may also be generated over any additional authenticated data (AAD) which may or may not be prefixed to each record. The tag, AAD and prefixing AAD are all concepts enshrined in the GCM and IEEEI6I9.1 standards.

The pseudo-record, comprising the initialisation vector, blocks of ciphertext and authentication tag, is delivered to the encrypt CRC recorder 25, which appends a CRC to the pseudo-record to create a protected pseudo-record. The -11 -protected pseudo-record is then delivered to the encrypt data compressor 26, which compresses the protected pseudo-record using LTO scheme-2 (no-compress) compression. Owing to encryption, the pseudo-record comprises random data and therefore the pseudo-record is incompressible. It is for this reason that scheme-2 compression is employed. Although no compression is actually achieved, the compressed pseudo-record consists of LTO codewords (e.g. compression, scheme and reset codewords). Consequently, the compressed pseudo-record is LTO compliant.

The compressed encrypted pseudo-record is then delivered to the data packer 12, which appends an EOR codeword to the compressed pseudo-record and packs sequential compressed pseudo-records together to form a compressed data stream, which is then written to the memory buffer 13.

Figure 3 illustrates a record received from the client computer 3 at various stages of formatting by the tape drive 4. Figure 3(a) illustrates the record as received by the tape drive 4, which may be of any size. Figure 3(b) illustrates the record after processing by the CRC recorder 8, and Figure 3(c) illustrates the protected record after compression by the data compressor 9. Figure 3(d) illustrates the compressed record after formatting by the data padder 22.

Figure 3(e) illustrates the pseudo-record created after encryption. Figure 3(1) illustrates the pseudo-record after processing by the encrypt CRC recorder 25, and Figure 3(e) illustrates the protected pseudo-record after compression by the encrypt data compressor 26 and the data packer 12. LTO format specifies also that records must be padded to a 32 bit boundary hence the potential use of a 4-byte pad appended to the end of the pseudo-record.

In response to receiving a new encryption key (e.g. as part of a write command or SET_KEY command), the controller 5 encrypts the encryption key using the public key 28 stored in the firmware memory 6. Unlike the data encryptor 11, which employs symmetric encryption implemented in hardware, the controller 5 -12 -encrypts the encryption key using a public-private encryption algorithm (or other asymmetric encryption algorithm) implemented in software, i.e. by means of the firmware instructions 27. Of course, the public-private encryption algorithm could equally be implemented as hardware. The asymmetrically encrypted encryption key is then stored to the memory buffer 13 or some other memory location within the tape drive 4, e.g. the firmware memory 7.

As in conventional LTO tape drives, the controller 5 divides or partitions the compressed data stream stored in the memory buffer 13 into data chunks of a predetermined size (e.g. 403884 bytes for LTOI/LTO2 and 1616940 for LTO3/LTO4). The controller 5 then creates and appends a data set information table (DSIT) to each data chunk to create a data set.

When creating each DSIT, the controller 5 stores the encrypted copy of the encryption key at a location within the DSIT that is reserved for manufacturer use. In the LTO1, LTO2, LTO3 and LTO4 formats, the DSIT comprises 468 bytes, of which the first 228 bytes are reserved for manufacturer use.

Consequently, each data set that is stored to tape includes not only encrypted data but also an encrypted copy of the key necessary to decrypt the encrypted data. As is described below, by storing an encrypted copy of the encryption key to tape along with the encrypted data, the encryption key can be subsequently recovered in order to decrypt the encrypted data. This has significant advantages in managing the keys used to encrypt and decrypt data.

Each data set is then delivered to the data formatter 14, which ECC-encodes the data set, randomises the ECC-encoded data to remove long sequences, and RLL encodes the randomised data. The RLL-encoded data are then processed by the digital signal processor 15 and delivered, via the write pre-amplifier 16, to write head elements 18 which write the data set to a magnetic tape. -13-

The read process is basically the reverse of the write process. In response to a request to retrieve a particular record, the tape drive 4 first locates the relevant data set or group of data sets. The data set is then read from the tape by read head elements 19 which generate an analogue signal. The analogue signal is then amplified by the read pre-amplifier 17 and processed by the digital signal processor 15 to generate a digital data stream. The digital data stream is then RLL-decoded, unscrambled and ECC-decoded by the data formatter 14 to create the data set.

The chunk of data corresponding to the data region of the data set is then delivered to the data packer 12, which unpacks the chunk of data to create one or more compressed pseudo-records. The location of each compressed pseudo-record is determined by the EOR codewords previously appended by the data packer 12 during data storage. Each compressed pseudo-record is then decompressed by means of the encrypt data compressor 26. The CRC appended to each pseudo-record is discarded by the encrypt data compressor 26 and the resulting pseudo-records are delivered to the encryption engine 23, which then decrypts the pseudo-records. The encryption engine 23 uses the encryption key stored in key memory 24 and the initialization vector stored at the beginning of each pseudo-record to decrypt the pseudo-records and generate in response padded, compressed records.

The padded, compressed records are then delivered to the data compressor 10, which decompresses the records. Owing to the presence of the EOR codeword, the data compressor 10 ignores any padding to the compressed records. The controller 5 then reads each of the retrieved records in turn until the requested record is identified, whereupon it is delivered to the client computer 3 via the drive interface 4.

As with the write command, each read command issued by the client computer 3 is accompanied by an encryption key, which is then stored in key memory 24 and used by the encryption engine 23 to decrypt the encrypted data.

-14 -Alternatively, the client computer 3 may issue a SET_KEY command, which includes the encryption key to be used for both encryption and decryption.

The tape drive 4 is operable to respond to a special READ_KEY command issued by the client computer 3. In response to receiving the READ_KEY command, the tape drive 4 reads the DSIT of each data set recorded on the tape and extracts the encrypted copy of the encryption key. The tape drive 4 then identifies any changes in the encrypted copy of the encryption key and stores, as a tuple, the location (i.e. the absolute position) of any change in key along with a copy of the encrypted encryption key. Following a complete scan of the tape, a set of tuples { {absolute position (record, filemark), encrypted copy of encryption key)1,

. {abso/ute position (record, filemark), encrypted copy of encryption key} } is created by the tape drive and returned to the client computer 3. From this set of tuples, the client computer 3 can identify the encryption key necessary to decrypt a particular record stored on the tape... DTD: In an alternative embodiment, the READ_KEY command may be accompanied by an identification of a data set stored on the tape. In response to receiving the READ_KEY command, the tape drive 4 retrieves the DSIT of the identified data set, extracts the encrypted copy of the encryption key from the DSIT, and returns the encrypted copy of the encryption key to the client computer 3.

As is described below with reference to Figures 4 and 5, should a user lose the encryption key for a particular data set, the encrypted copy of the encryption key can be retrieved by means of the READ_KEY command. The encrypted copy of the encryption key returned to the client computer 3 can then be decrypted in order to recover the encryption key.

The tape drive 4 is additionally operable to respond to a special WRITE_PUBLIC_KEY command issued by the client computer 3. In response to the WRITE_PUBLIC_KEY command, the controller 5 stores the public key -15-that accompanies the command to the firmware memory 6, thereby overwriting the previously stored public key. Consequently, a new or replacement tape drive 4 can be configured to use the same public key as that of an existing or previous tape drive owned by the user.

The tape drive 4 may additionally be operable to delete the public key from the firmware memory 6 in response to a DELETE_PUBLIC_KEY issued by the client computer 3. When no public key is stored in the firmware memory 6, no encrypted copy of an encryption key is created in response to a write command or SET_KEY command. Moreover, no encrypted copy of an encryption key is stored to the DSIT a data set. Nevertheless, the data set continues to comprise encrypted backup data.

In the embodiment of tape drive 4 described above, a copy of the asymmetrically encrypted encryption key is written to the DSIT of each data set.

Alternatively, the encrypted copy of the encryption key may instead be written to the DSIT of only the first of the data sets having data encrypted using the encryption key. Upon a change of encryption key, an encrypted copy of the new encryption key is then written to the DSIT of the first of the data sets having data encrypted using the new encryption key. In a further alternative, a single copy of the encrypted encryption key may be written to a portion of the tape cartridge that is not reserved for user data. For example, the encrypted data may be written to the tape header portion of the tape or to a cartridge memory. In this alternative embodiment, all data stored to the tape cartridge are encrypted using the same encryption key. In order to prevent a tape cartridge storing data encrypted with different keys, the tape drive 4 prevents any change to the encryption key stored in key memory 24 until such time as a new tape cartridge has been inserted, or until the contents of the tape cartridge have been erased.

-16 -Rather than creating an encrypted copy of the encryption key, the tape drive 4 may instead be operable to receive an encrypted copy of the encryption key. In particular, each write command or SET_KEY command may include not only a copy of the encryption key but also an asymmetrically encrypted copy of the encryption key. In response to the write or SET_KEY command, the controller stores the accompanying encrypted copy of the encryption key in the memory buffer 13 or other memory location (e.g. firmware memory 6 or key memory 24) for subsequent use. Whilst the client computer 3 is then responsible for creating the asymmetrically encrypted copy of the encryption key, the resources required to encrypt the encryption key are small in comparison to the resources required to encrypt the backup data, which continues to be performed by the tape drive 4.

Whilst the data encryptor 11 employs a Galois Counter Mode encryptionalgorithm, other encryption algorithms may alternatively be employed, including block cipher, stream cipher, symmetric and asymmetric encryption. Symmetric encryption has advantages over asymmetric encryption owing to its faster speed of encryption. In the case where asymmetric encryption is employed, the key memory 24 stores a decryption key, separate to that of the encryption key, for data decryption. Naturally, where asymmetric encryption is employed, an asymmetrically encrypted copy of the decryption key, rather than the encryption key, is stored to tape along with the encrypted data.

By creating pseudo-records, which are then formatted using conventional LTO formatting, data sets stored to tape by the tape drive 4 can be read back using conventional LTO tape drives, i.e. LTO tape drives not having means to encrypt or decrypt data. In particular, a conventional LTO tape drive is able to read and return pseudo-records to the client computer 3, which can then decrypted using software resident on the client computer 3. The tape drive 4 therefore has the benefit that encrypted data stored to tape can be read back by conventional tape drives and decrypted using software resident on the client computer 3.

-17 -Nevertheless, the creation of LTO-compliant pseudo-records is not regarded as essential and other arrangements in which data are encrypted and stored to tape along with an encrypted copy of the key necessary for decryption may equally be employed.

Although embodiments of the tape drive 4 have been described with reference to the LTO format, the present invention is equally applicable to other data formats, particularly those data formats in which data to be stored are received as records. The pseudo-records created by the encryption engine 23 can be formatted as conventional records using alternative tape formats, such as DDS (including DAT 72 and DAT 160), SDLT, DLT and proprietary IBM formats.

Moreover, although embodiments of the present invention has been described with reference to a tape drive 4, it will be appreciated that the present invention is equally applicable to other types of data transfer devices including, but not limited to, optical drives.

Figures 4 and 5 illustrate a method of key management embodying the present invention.

A user first registers 30 with a trusted third party or other escrow agent.

Registration includes providing the trusted third party with user information that can be subsequently used by the trusted third party to verify the identify of the user. In response to receiving 31 the user information, the trusted third party generates 32 a public key and a private key of a public-private key pair. The trusted third party then provides 33 the user with the public key, and stores 34 the private key together the user information.

Following a successful registration, the user receives 35 the public key from the trusted third party. The user then generates 36 an encryption key and a corresponding decryption key. In the case of symmetric encryption (e.g. AES), only an encryption key is generated by the user. The user encrypts 37 backup -18 -data using the encryption key, and encrypts 38 the decryption key (or encryption key in the case of symmetric encryption) with the public key using a public-private encryption algorithm. Finally, the user stores 39 the encrypted backup data together with the encrypted copy of the decryption key.

When the user wishes to retrieve the backup data from storage, the user first retrieves 40 the encrypted decryption key from storage. The user then provides 41 the trusted third party with the encrypted decryption key along with user information that identifies the user. The trusted third party verifies 42 that the user is authorised to use the decryption key by comparing the received user information with those details previously stored at the time of user registration.

If a match is found between the received user information and the information previously stored at registration, the user is verified as being authorised to use the decryption key. The private key, which was stored by the trusted third party along with the user information, is retrieved 43 by the trusted third party. The trusted third party then decrypts 44 the encrypted decryption key using the private key and provides 45 the user with the resulting decryption key.

The user, after providing the trusted third party with a copy of the encrypted decryption key and user information, receives 46 the decryption key from the trusted third party. The user then retrieves 47 the encrypted backup data from storage and decrypts 48 the backup data using the decryption key.

The method of key management illustrated in Figures 4 and 5 may be implemented using the arrangement I illustrated in Figures 1-3. In particular, user registration 30 with the trusted third party may take place online between the server computer 2 of the trusted third party and the client computer 3 of the user. The server computer 2 of the trusted third party is then responsible for the steps 31-34, 42-45 performed by the trusted third party.

-19 -Following a successful registration, the client computer 3 receives 31 the public key from the server computer 2 and delivers the public key to the tape drive 4 as part of the WRITE_PUBLIC_KEY command. The client computer 3 also generates 35 the encryption key and the decryption key, which are delivered to the tape drive 4 as part of a write command or SET_KEY command. The tape drive 4 encrypts 36 the backup data using the received encryption key and encrypts the decryption key using the public key. The tape drive 4 then stores 39 the encrypted backup data and the encrypted decryption key to tape as one or more data sets.

When retrieving backup data, the encrypted copy of the decryption key is retrieved 40 by the client computer 3 by issuing a READ_KEY command to the tape drive 4, which in response retrieves the encrypted copy of the decryption key from tape and returns the encrypted decryption key to the client computer 3. The client computer 3 then provides 41 the server computer 2 of the trusted third party with the encrypted copy of the decryption key and the user information. The client computer 3 subsequently receives 46 the decryption key from the server computer 2 of the trusted third party and delivers the decryption key to the tape drive 4 as part of a read command or SET_KEY command. Finally, the tape drive 4 retrieves 47 the backup data from tape and decrypts 48 the backup data using the decryption key.

With the method of key management embodying the present invention, the encrypted backup data continues to be decrypted by the user; at no time is the encrypted backup data delivered to or decrypted by the trusted third party.

Consequently, there is no danger of the trusted third party having access to the backup data. Moreover, there is no danger of the backup data being intercepted by unauthorised parties, which might otherwise arise if the trusted third party were responsible for decrypting and returning the backup data to the user. Additionally, with this particular key management arrangement, the -20 -private key is at no time distributed by the trusted third party. Consequently, there is no danger of the private key being intercepted by unauthorised parties.

In the embodiment of key management described above, the user is not required to maintain any records of the encryption keys used or the decryption keys necessary to recover the backup data. Instead, the user may rely solely upon the services of the trusted third party to obtain the key necessary to decrypt the data. However, this arrangement may not always be suitable. For example, if the trusted third party makes a charge each time its services are called upon, this particular arrangement might prove to be expensive when backup data are frequently being recovered. Accordingly, the user may store a record of the keys necessary to decrypt the backup data and call upon the services of the trusted third party only in the event that a key is subsequently lost.

With the above-described methods of key management, the public-private key pair is generated 32 by the trusted third party and the private key is stored only by the trusted third party. In an alternative embodiment, the public-private key pair may instead be generated 32 by the user, and the user alone stores the private key. This then obviates the need for a trusted third party. The user would not then be required to maintain any records of the decryption keys necessary to recover the backup data. Instead, the user need only securely retain the private key. Should the user wish to retrieve data from tape, the relevant encrypted copy of the encryption key is retrieved from tape and decrypted using the private key. The now decrypted encryption key is delivered to the tape drive 4 (e.g. as part of a read data command or as part of a SET_KEY command) and used to decrypt the requested data. Since only a copy of the private key need be securely retained, key management is greatly simplified, whilst the ability to encrypt data using different encryption keys ensures that data security is not compromised.

-21 -In a further alternative, the encryption key and the encrypted copy of the decryption key may be generated by the trusted third party in response to a key request from the user. In response to the key request, the trusted third party generates an encryption key and encrypts the encryption key using a key that is specific to the user, e.g. created at the time of user registration. The user-specific key is then used to encrypt all encryption keys for that user. The encryption key and encrypted copy of the decryption key received from the trusted third party may then be delivered to the tape drive 4 as part of a write command or SET_KEY command. In the event that a user needs to decrypt data, the encrypted copy of the decryption key is retrieved from tape using the READ_KEY command and delivered to the trusted third party. After user verification, the trusted third party decrypts the encrypted copy of the decryption key using the user-specific key and returns the decrypted copy of the decryption key to the user. Since the trusted third party does not distribute a public key, the decryption keys may be encrypted using a symmetric or an asymmetric encryption algorithm.

In the arrangement I described above, the tape drive 4 is initially shipped to the user without any keys. In particular, the contents of the firmware memory 6 and the key memory 24 of the tape drive 4 are initially empty. In response to user registration, the server computer 2 generates 32 the public-private key pair, and provides 33 the client computer 3 with a copy of the public key 28.

The client computer 3 then delivers the public key 28 to the tape drive 4 using the WRITE_PUBLIC_KEY command. In an alternative arrangement, the trusted third party may provide the user with a tape drive 4 having the public key 28 already written to the firmware memory 6. In this alternative arrangement, the option to overwrite or delete the public key 28 using the WRITE_PUBLIC_KEY or DELETE_PUBLIC_KEY commands may be removed such that management of the public and private keys is left solely to the trusted third party.

-22 -With the method and arrangement of the present invention, the encryption and decryption of backup data is moved from the client computer to the data transfer device. By storing an encrypted copy of the key necessary for decryption along with the encrypted backup data, key management is greatly s simplified without jeopardising data security. In particular, different encryption keys may be used to encrypt the backup data, whilst only a single key need be securely retained to ultimately decrypt the backup data. In order to further improve data security, the single key may be stored in escrow by a trusted third party. In the event that backup data need to be retrieved, only the encrypted copy of the key is delivered to the trusted third party, which in turn decrypts and returns the key necessary for decryption. Consequently, neither the backup data nor the important single key is transmitted between the trusted third party and the user. There is therefore no danger of important data being intercepted by unauthorised parties.

When used in this specification and claims, the terms "comprises" and "comprising" and variations thereof mean that the specified features, steps or integers are included. The terms are not to be interpreted to exclude the presence of other features, steps or components.

The features disclosed in the foregoing description, or the following claims, or the accompanying drawings, expressed in their specific forms or in terms of a means for performing the disclosed function, or a method or process for attaining the disclosed result, as appropriate, may, separately, or in any combination of such features, be utilised for realising the invention in diverse forms thereof.

Claims

-23 -

What is claimed is: s 1. A data transfer device for transferring data to a removable data storage item, the data transfer device being operable to: receive data to be stored; encrypt the data using an encryption key, the encrypted data requiring a decryption key for decryption; store the encrypted data to the removable data storage item; and store an encrypted copy of the decryption key to the removable data storage item.
2. A data transfer device according to claim 1, wherein the data transfer device is operable to receive the encryption key and the decryption key, and to encrypt the decryption key using an asymmetric encryption algorithm to create the encrypted copy of the decryption key.
3. A data transfer device according to claim 2, wherein the data transfer device is operable to receive a public key and to encrypt the decryption key using a public-private encryption algorithm that employs the public key to create the encrypted copy of the decryption key.
4. A data transfer device according to claim 1, wherein the data transfer device is operable to receive the encryption key and the encrypted copy of the decryption key.
5. A data transfer device according to any preceding claim, wherein the data transfer device is operable to store the encrypted data as one or more data blocks, and to store the encrypted copy of the decryption key as part of at least one of the data blocks.

-24 -
6. A data transfer device according to claim 5, wherein each data block comprises a data region and an information table, and the encrypted data is stored in the data regions of the data blocks and the encrypted copy of the decryption key Is stored in the information table of at least one of the data blocks.
7. A data transfer device according to any one of claims 1 to 4, wherein the removable data storage item comprises a data medium having a user data region and a non-user data region, and the data transfer device is operable to io store the encrypted data to the user data region and to store the encrypted copy of the decryption key to the non-user data region.
8. A data transfer device according to any one of claims 1 to 4, wherein the removable data storage item includes a data medium and a memory device, and the data transfer device is operable to store the encrypted data to the data medium and to store the encrypted copy of the decryption key to the memory device.
9. A data transfer device according to any preceding claim, wherein the data transfer device is operable to: receive a request to retrieve the encrypted copy of the decryption key from the removable data storage item; retrieve the encrypted copy of the decryption key from the removable data storage item; and output the encrypted copy of the decryption key.
10. A data transfer device according to any preceding claim, wherein the data transfer device is suitable for transferring data from the removable data storage item, the data transfer device being operable to: retrieve encrypted data from the removable data storage item; decrypt the encrypted data using the decryption key; and output the decrypted data.
11 A data transfer device according to any preceding claim, wherein the data transfer device is operable to store the encrypted data in a format selected from one of the generations of LTO and DDS/DAT formats.
12. A data transfer device according to any preceding claim, wherein the data transfer device is a tape drive and the removable data storage item is a tape cartridge.
13. A data transfer device for transferring data to a removable data storage item, the data transfer device comprising: means for receiving data to be stored; means for encrypting the data using an encryption key, the encrypted data requiring a decryption key for decryption; means for storing the encrypted data to the removable data storage item; and means for storing an encrypted copy of the decryption key to the removable data storage item.
14. A data transfer device according to claim 13, wherein the data transfer device comprises means for receiving the encryption key and the decryption key, and means for encrypting the decryption key using an asymmetric encryption algorithm to create the encrypted copy of the decryption key.
15. A data transfer device according to claim 14, wherein the data transfer device comprises means for receiving a public key, and the means for encrypting the decryption key uses a public-private encryption algorithm that employs the public key.
16. A method of storing data comprising: encrypting data using an encryption key, the encrypted data requiring a decryption key for decryption; -26 -storing the encrypted data to a data storage item as one or more data blocks; and storing an encrypted copy of the decryption key to the data storage item as part of at least one of the data blocks.
17. A method according to claim 16, wherein each data block comprises a data region and an information table, and the encrypted data is stored in the data regions of the data blocks and the encrypted copy of the decryption key is stored in the information table of at least one of the data blocks.
18. A method according to claim 16 or 17, wherein the method comprises: encrypting the decryption key using a public-private encryption algorithm that employs a public key to create the encrypted copy of the decryption key; encrypting further data using a further encryption key, the encrypted further data requiring a further decryption key for decryption, the further decryption key differing from the decryption key; encrypting the further decryption key using the public key; storing the encrypted further data to the data storage item as one or more further data blocks; and storing the encrypted copy of the further decryption key to the data storage item as part of at least one of the further data blocks.
19. A method according to any one of claims 16 to 18, wherein the data storage item is a tape cartridge.
20. A method of key management comprising: generating a public key and a private key of a public-private key pair; generating an encryption key and a corresponding decryption key, the encryption key being used to encrypt data; asymmetrically encrypting the decryption key using the public key; and storing the encrypted decryption key along with data encrypted using the encryption key.

-27 -
21. A method according to claim 20, wherein data encrypted using the encryption key are stored as one or more data blocks, and the encrypted decryption key is stored as part of at least one of the data blocks.
22. A method according to claim 21, wherein each data block comprises a data region and an information table, and data encrypted using the encryption key is stored in the data regions of the data blocks and the encrypted decryption key is stored in the information table of at least one of the data io blocks.
23. A method according to any one of claims 20 to 22, wherein the method comprises: generating a further encryption key and a corresponding further decryption key, the further decryption key differing from the decryption key; asymmetrically encrypting the further decryption key using the public key; and storing the encrypted further decryption key along with data encrypted using the further encryption key.
24. A method according to any one of claims 20 to 23, wherein: a user generates the encryption key and the decryption key; a third party generates the public key and the private key; the third party stores the private key and provides the user with the public key, the user asymmetrically encrypts the decryption key using the public key; and the user stores the encrypted decryption key along with data encrypted using the encryption key.
25. A method according to claim 24, wherein: the user retrieves the encrypted decryption key from storage; -28-the user provides the third party with the encrypted decryption key; the third party verifies that the user is authorised to use the decryption key; the third party decrypts the encrypted decryption key using the private key in the event that the user is authorised to use the decryption key; and the third party provides the user with the decryption key.