I've received a lot of questions about the different tape drives are doing encryption, so I thought I'd get some details and get back to you. This is the first of a few posts on this topic, and it concentrates on Sun's T10000 tape drive. There will also be a post on IBM's TS1120 and their LTO-4 drive.
I had a two-hour conversation with Sun's Jon Hiles today about the T10000. Poor Jon. He thought we were going to have the most basic of conversations, and I wanted a deep dive. To his credit, he didn't complain a bit and actually did quite well, given that he wasn't forewarned the kind of questions he was likely to get. Here's a summary of the details of this drive.
First, the original design (for Generation 1) included a requirement for an "air gap" between the tape drive and the key management server (KMS). Therefore, what seems to be a bit of clunkiness in how this thing works apparently comes from certain entities actually asking that the KMS not be in constant communication with the tape drives — they should be able to run autonomously. Given that, the design makes a bit more sense.
When you buy a T10k, a CSE must visit you to turn on encryption for that drive. Once turned on, that drive will always encrypt everything sent to it — always. Unlike other encrypting tape drives, there is no turning encryption on or off based on bar codes, or anything else. They said they customers who wanted to be able to say that there's no way a backup wasn't encrypted.
When you receive your tape drive(s), a CSE must visit you and enter some information about the drive on a website (known as the Customer Resource Center, or CRC). The CRC gives him a 64 bit key that is checked against the key that is already stored on a chip in the drive. If everything matches, the CSE creates a CD of special information that comes from the drives and gives it to the customer.
Meanwhile, the customer sets up the Key Management Server (KMS), by giving it a passphrase that will be used to authenticate the customer whenever interacting with the KMS. The customer then transfers to the KMS the data on the CD given to him/her by the CSE, and voila! Now we have "enrolled" these drives in the KMS. (The insertion of the CSE in the process ensures that rogue drives are never used.)
The customer then uses the KMS to create one or more keys (randomly created by the KMS), each of which are assigned a "key id," and are assigned to one or more drives. (You can use one key for your entire environment or one key per drive, or some mix thereof.) This information is transferred into a "key token" that is sitting in a "token bay." (Think thumb drive in a USB port, although it's more sophisticated than that.) They token is then taken out of the KMS, physically transferred across the "air gap," and placed into the token bay in the tape library. Each drive is then told (via the internal network inside the tape library) which key they should use to encrypt their data. This key is stored in non-volatile memory on the tape drive.
When a tape is written to, the tape drive writes the key id of the key it used to encrypt the tape. When that tape is later read, the tape drive will read the key id from the tape, and see if they key is already stored in it's memory. If not, it can ask the key token (which would be left in the token bay) for the key associated with the key id it needs to read the tape. If the key token doesn't have the requested key, an alert will be sent, and the system administrator will need to use the key token to transfer the requested key from the key server (which stores all keys every used). Under normal operations, there is no reason the key token shouldn't have all previous keys, since it's capable of storing 60,000 keys. But in the rare case that the key is not there, you can retrieve it from the KMS.
In a DR scenario, you need to transfer a backup of the KMS to your DR KMS and authenticate yourself (and therefore the new KMS) using the passphrase you created earlier. (That passphrase better be stored somewhere other than someone's head!) The tape drives in the DR library would need to be enrolled with that DR KMS via the CSE process described earlier, and then you would have to associate your previously generated keys to the new tape drives in that KMS. (This works because a single can be associated with more than one tape drive.) Once the DR tape drives were enrolled in the DR KMS, you would transfer the keys to the tape drives via a DR key token.
If at some point decide you want to change which key you you want a given drive to use, you generate a new key in the KMS (which also stores the old key) and transfer it again to the tape library via the key token. The drive will store that key as it's new "read/write" key, and store up to 31 previous keys as read-only keys for reading older tapes written with previous keys. (Again, if the tape drive needs a key that is 32+ generations ago, it will request it from the key token, which should have it. If it doesn't have it, then an alert will be created.)
Since the keys are stored in the drive, I asked what would happen if someone stole a drive. Jon said that as soon as power is pulled from the drive, all keys are erased. Therefore, you could not steal a tape drive and take it somewhere else and use it to read backup tapes.
I was able to think of two scenarios where you could beat this system, but they're pretty unlikely.
1. If a black hat could steal some tape drives AND the key token, then they should be able tor read backup tapes. I'm thinking, however, that this would be a very noticeable event, as the tape library would stop working without the key token.
2. If a black hat went to the trouble of purchasing an identical tape library and KMS solely for the purpose of stealing your data, and they had access to an unscrupulous person in your data center that could get them a backup of the KMS, they could mimic a DR scenario and read your tapes. Since the Sun CSE doesn't interact with the KMS, they'd have no idea that's what was going on. (Don't fool yourself into thinking this is an unlikely scenario. Stop thinking hacker and think competitor trying to steal corporate secrets. Corporate Espionage is real.)
I suggest that both of these could be dealt with using strong physical security, and standard separation of duty techniques, such as having the backup person having nothing to do with key management. The person(s) with access to/knowledge of the passphrase shouldn't have access to the backup of the KMS database.
I hope this explanation helped you to better understand how this drive works. Please ask questions via the comment system if you have them.
----- Signature and Disclaimer -----
Written by W. Curtis Preston (@wcpreston). For those of you unfamiliar with my work, I've specialized in backup & recovery since 1993. I've written the O'Reilly books on backup and have worked with a number of native and commercial tools. I am now Chief Technical Evangelist at Druva, the leading provider of cloud-based data protection and data management tools for endpoints, infrastructure, and cloud applications. These posts reflect my own opinion and are not necessarily the opinion of my employer.