Americas

  • United States

Asia

Oceania

roger_grimes
Columnist

TCG sets the drive encryption standard

Analysis
Mar 06, 20095 mins
Data and Information SecuritySecurity

Trusted Computing Group's Opal spec for interoperable, self-encrypting drives isn't complete, but it's a great start

If you’re not already a huge fan of the Trusted Computing Group, you should be. It is one of the few groups coming up with open-standard, long-term, real security solutions. Anything it does has my full support. If you’ve heard of the Trusted Platform Module (TPM), the cryptographic chip that is built into many motherboards and used by vendors all over the world, you’ve seen what the group can do.

The latest handiwork of the TCG, by way of the Storage Device Working Group, is a full drive encryption standard called Opal. The 81-page specification — full of new storage device logical specs, protocols, and data structures — might even put a system engineer to sleep, but I will try to distill some of the essential points.

[ Your laptop data isn’t safe. Follow InfoWorld’s encryption-based data-protection plan, which can safeguard your most at-risk PCs. ]

Opal defines standards (formatting, bit values, and commands) for creating and managing interoperable self-encrypting drives. It is supported by multiple hard drive vendors, and the basic components are put on the drive during manufacturing.

The standard is very bare bones. Although AES 128- and 256-bit keys must be supported as a minimum, vendors can also incorporate their own crypto algorithms. The standard is more about how and where particular values must be placed on the drive and what basic commands must be supported. A sample command is REVERT, which instructs the drive to return its crypto settings back to the original factory state. REVERT is clearly useful for quickly repurposing the drive. It and other commands can come from the hard drive’s built-in data array controller card or from external software.

Self-encrypting drives support multiple master and user-level “passwords” (such as authentication keys). Depending on the hard drive implementation, a drive can have multiple partitions, and each partition can have its own authentication key. Keys are device- or partition-based and protected by user-based authentication keys.

Opal benefits

There are many benefits of TCG’s Opal. It’s OS independent. It does not require a BIOS update to use. It can be used in conjunction with the TPM chip. Opal is not susceptible to known DMA or memory freeze attacks. The pre-boot code is read-only and protected by the drive manufacturer. The Opal standard was even reviewed and approved by the NSA.

I haven’t been able to find out any performance-based claims, but in general there is a high likelihood that hardware-based crypto at the drive level can provide competitive performance.

Any storage device that claims to be Opal SSC (Security Subsystem Class) compliant follows this standard, including drives from Seagate, Fujitsu, and Hitachi. There are already several drives out on the market, including Seagate/Maxtor’s 160GB USB BlackArmor drive priced as low as $60.

Critical reviews

So if this new hard drive encryption standard is so great, why would anyone want to deploy another vendor’s crypto? Will there still be a market for TrueCrypt, BitLocker, and so on?

It may be hard to believe, but there are critics out there.

First, and most important, most of the important details of implementing Opal are left up to each vendor and software manager. Using AES is a strong no-brainer, but most failed crypto implementations failed because of how the vendor implemented the “strong” crypto. An NSA-approved standard carries no assurance that the standard will be successfully implemented in practice. I could not get any specific details (such as key placement) from any of the hardware vendors from my initial tries. A crypto implementation not thoroughly reviewed is always slightly less trustworthy than one reviewed in the open by many experts.

A second important point is that key management is not defined, but left to the implementer to determine. It’s good that the standard doesn’t lock a manufacturer or software management vendor into a particular key management scheme. But it’s bad that key management isn’t required or even discussed. Where are the keys stored? How can they be extracted (either legitimately or not so legitimately)? These questions need answers before someone should rely on a vendor’s crypto product.

Low-cost vendors might skip on good key management, and without good key management the user is surely to suffer. On a good note, some of the software vendors (including Wave Systems) are pretty open about their key management policies.

Other points of criticism concern how the Opal standard does not include USB thumb drives, backup tapes, or optical drives. To me, personally, these are minor points to the two larger issues above. If you’re interested in seeing more discussion on the topic, check out Bruce Schneier’s blog entry on the subject.

I’m a big fan of the Trusted Computing Group, and I trust whatever comes out of the not-for-profit industry standards organization. Opal is just one part of TCG’s overall vision for a truly trustworthy computing device. The encryption storage device spec may not be broad enough or perfect, but it’s a step in the right direction. At the same time, I encourage users to thoroughly understand the key management aspects before implementing any crypto product.

Other storage-related TCG standards:

roger_grimes
Columnist

Roger A. Grimes is a contributing editor. Roger holds more than 40 computer certifications and has authored ten books on computer security. He has been fighting malware and malicious hackers since 1987, beginning with disassembling early DOS viruses. He specializes in protecting host computers from hackers and malware, and consults to companies from the Fortune 100 to small businesses. A frequent industry speaker and educator, Roger currently works for KnowBe4 as the Data-Driven Defense Evangelist and is the author of Cryptography Apocalypse.

More from this author