Evaluating options for tape encryption

Posted on July 10, 2008

RssImageAltText

By George Hall

-- Given that the pressures to encrypt data at-rest are continuing to mount, and the IEEE Secure Storage Working Group is nearly finished establishing standards for disk/tape encryption and key management, it is time to revisit some operational considerations associated with planning and policy development for tape encryption.

As of December 2007, the IEEE Storage Working Group completed its work on disk and tape encryption standards (IEEE 1619.1 and IEEE 1619.2). The only standard remaining unsettled is key management (IEEE 1619.3). The standards themselves are important, but not nearly as important as how storage vendors implement the standards and how they will impact storage architectures.

One of the most important questions that storage managers may have to consider is the interoperability (or lack of interoperability) among different vendors' encryption solutions. A variety of tape drive and library vendors offer encryption at the drive level, and storage application vendors are also delivering software-based encryption. However, it is unlikely that the various encryption solutions will be interoperable.

There are a number of reasons for this. For one, there is no settled standard for which version of the 256-bit Advanced Encryption Standard (AES256) should be used on drives and other devices. Some versions may not even pass some aspects of FIPS certification (if that is important to an enterprise), although they do meet the IEEE and NIST standards. Some vendors use AES256-GCM and some use AES256-CCM. The following NIST-approved modes are available for AES256 block cipher encryption:

  • CCM-128-AES-256: Counter mode encryption with cipher block chaining message authentication code;
  • GCM-128-AES-256: Galois/Counter mode (counter mode encryption with 128-bit finite field message authentication code);
  • CBC-AES-256-HMAC-SHA: Cipher block chaining mode for encryption with key-hash message authentication code using secure hashing algorithm; and
  • XTS-AES-256-HMAC-SHA: XTS encryption with key-hash message authentication code using secure hashing algorithm.

They comply with the standard as long as a vendor adheres to one of these modes, but different vendors' implementations will not necessarily interoperate.

If you are looking to develop a common encryption standard today across more than one tape subsystem, backup application or drive type in a heterogeneous vendor environment, it probably won't be possible with drive-based encryption.

In the tape world, we will continue to see advances in device-based encryption for both proprietary drive types as well as standards-based drives. For instance, all future LTO generations include device-level encryption options. However, unless you replace your existing tape subsystems with a single vendor's drive-level encryption devices, you will still be operating in a heterogeneous environment. Even within a single vendor's drive environment, re-keying a failed drive may not be straightforward. This is especially true from the perspective of common encryption and key management.

Even within a single vendor's drive line, there is no guarantee that the specific drives that you buy today will be available in five to ten years to replace broken drives and thereby allow the restoration of saved and encrypted data, especially if the media increases in bit-error rates over time.

Another consideration is interoperability within classes of devices or applications. The standards will address some degree of encryption interoperability, as well as some forward and backward compatibility at the drive level, for tape, but will device interoperability ever cross vendors' product lines? Possibly, but it hasn't happened yet and it probably won't happen soon because there is little incentive for drive vendors to push for complete interoperability until the market demands it.

As a result, enterprises may not be able to migrate their encrypted tape workflow and storage operations to take advantage of other vendors' offerings. This is more than likely to be the case with different vendors' solutions for device-level encryption and application-level encryption for some time to come. Transparent portability of encrypted data and keys may not be achieved. Vendors will conform to one of the accepted standards, but which one is unclear, and they will likely add extensions to their encryption solutions to ensure some proprietary control over their installed base.

Key management
The single weakest link in storage encryption standards today is the still unsettled questions surrounding key management. Encryption key management is arguably the most important question with which storage administrators must wrestle. Without effective, extensible, interoperable and reliable key management, data-protection systems, processes, procedures, and policies for encrypting and decrypting data can become a nightmare.

There will eventually be some interoperability among vendors' key management systems. However, that does not exist today and, despite an emerging IEEE standard (1619.3), the ways that each vendor achieves IEEE compliance will probably be different. This is likely because it would preserve proprietary aspects of a vendor's products.

Today, the major drive-based encryption vendors' key management systems are early implementations that may not be fully secure and robust. And there is no interoperability between vendors' key management systems, either within classes of devices or across vendors. Some vendors' key management systems are simple Java applications that are not secure without other technologies to protect and manage keys. The methods that different tape vendors use to replicate keys for disaster recovery, and how they save, store, move, secure, share, destroy, and re-key keys are different and not interoperable. In fact, the drive vendor community has not determined how the entire key lifecycle will be addressed. This is one reason that the IEEE standard for key management is taking longer to resolve than the device-level standards did. Key management is a workflow management issue that, to be effective, must be able to support security policy across the enterprise, as opposed to what most key management is today: a drive- or application-specific system that operates in isolation from other vendors' solutions.

Some vendors use asymmetrical keys, while others use symmetrical keys. Some vendors write key data to the media, and others do not. With respect to tape, there is no guarantee that forward- or backward-compatibility will span vendors' drives and/or key management systems over time. Given the diversity of products on the market, it is unlikely that in the near future -- even with a set standard -- that the vendor community will adhere to a single, interoperable application to manage encryption keys.

So far we have focused on device- and application-based encryption and key management systems. There are two other mechanisms available today for encrypting data written to tape.

Backup applications
One option is to use the facilities within an existing backup application to encrypt, and optionally compress, data. However, unless you are using the latest encryption software modules you may not be using AES256 encryption, which is the latest IEEE and NIST standard. AES256 encryption is far more resource efficient and secure than its predecessors—DES and TripleDES. AES256 has not yet been hacked either. Let's assume you are running the latest release from your backup software vendor and that you have compression and encryption turned on. Let's also assume you are able to accomplish all of the necessary jobs you have scheduled within the time limits of your backup windows today. What happens when your data volume grows?

The answer is that your tape operations workflow will change. In most enterprises today, storage operations and data protection are never in a static state. One question is, "At what rate will my data-protection requirements grow and change?" An equally important question is, "How can I set policies for a moving target?" The options to address data growth over time are straightforward. You can

A) Extend the size of the backup window;
B) Reduce the numbers of devices that are backed up and protected;
C) Add more drives;
D) Add more backup servers and software; and
E) Improve the efficiency of your workflow with an overarching encryption and key management capability.

The vast majority of IT shops typically go for options C and D because they are easy (although not inexpensive) and do not impact data-protection workflow requirements over time. Only one of the five options (E) takes into account strong key management systems and the ability to build and manage centralized and secure key management operations regardless of underlying drive or server issues. Option E improves workflow efficiency with comprehensive encryption and key management. Less than 35% of archival data is encrypted today because without the ability to build a common encryption management policy, any policy becomes dated and useless almost as soon as it is implemented.

Encryption appliances
With an extensible and secure way to implement encryption policies across the entire tape storage environment, more enterprises would feel comfortable using encryption. Data-protection policies would be commonly applicable, evenly implemented across the enterprise, and supported for all devices in a heterogeneous storage environment without consideration of the underlying drive technology. This removes the issue of which drives have encryption and which ones don't. It gives storage administrators flexibility and freedom to migrate jobs based upon device availability and workflow needs rather than specific encryption features of a storage partition. Most importantly, however, storage administrators should seek a robust and common key management system that allows them to set and enforce a common tape encryption policy across the entire enterprise. If you lose encryption keys with AES256 encryption you have just committed digital data shredding -- intentionally or not -- and without assurances that administrators will always be able to decrypt data, no one will want to take a chance if they do not have to. That's one reason why adoption of encryption is so low today.

The goal is to free your storage operations from the need to choose one drive vendor over another, or one server-based application over another, and to ensure interoperation of the key management system with all of your devices. This can be accomplished with an encryption appliance that sits transparently in the data path, with wire-speed performance and strong key management that is independent of drive type, backup application, servers, or operating systems.

Since encryption appliances sit in the data path, they should transparently support meshed, redundant, high-availability SAN fabrics. Encryption appliances also allow you to securely move keys around and use them on any drive for both encryption and restoration.

Additionally, by using an external tape encryption appliance you can increase the number of vendors in your tape environment by eliminating concerns about specific implementation differences between vendors. You can also leverage common FIPS-compliant key management for an operating environment that includes a variety of tape drives.

In summary, we have described three ways to implement tape encryption in the enterprise: drive-based encryption, applications and backup programs, and appliance-based encryption. We have discussed the policy, workflow and long-term considerations that storage administrators should consider. By reviewing the options you will have more information for consideration as you move toward tape encryption.

George Hall is a senior partner and forensics expert with RidgeLLC, a storage security and computer forensic support services business. He can be reached at ghall (at) ridgellc.com.

Originally published on .

Comment and Contribute
(Maximum characters: 1200). You have
characters left.

InfoStor Article Categories:

SAN - Storage Area Network   Disk Arrays
NAS - Network Attached Storage   Storage Blogs
Storage Management   Archived Issues
Backup and Recovery   Data Storage Archives