Follow-up to Hitachi's Announcement of AES-256 Encryption Within a Hard Disk

As many readers noticed, last week Slashdot covered a announcement that Fujitsu is the first to offer 256-bit AES encryption in their MHZ2 CJ Series 320 GB 2.5" hard drives.  As chair of the IEEE P1619 Security in Storage Working Group, I felt an obligation to get more details on exactly what 'AES-256' encryption means. So I clicked on the handy box to submit questions, and got the following responses from Fujitsu:

1. What is the mode of operation for the AES block cipher (e.g., ECB, CBC, CTR, etc)?
===> We don't disclose this.

2. How are the 256-bit AES keys managed?
===> We don't disclose this.

3. Is Fujitsu considering NIST FIPS 140-2 certification for this disk drive (like Seagate is doing)?
===> under consideration.  

I had similar questions about Seagate's Full Disk Encryption (FDE) hard drive, and couldn't get any answers there, either.  According to AES Certificate #587, Seagate is using Electronic Code Book (ECB) for their FDE.  Unfortunately, ECB is a very insecure mode-of-operation, one that I hope NIST eventually withdraws.  To visually see what I mean, take a look at the ECB encryption of Tux the penguin.  The latest rumors I've heard is that Seagate is moving to cipher-block-chaining (CBC) encryption (a much more secure mode-of-operation) for subsequent encrypting hard disks.  Fujitsu will likely take a similar course, although there is expected to be some flexibility in the algorithms.

In contrast, tape drive vendors have been much more open about the details of their tape encryption. According to the LTO-Technology page, LTO uses the AES-GCM mode as specified in IEEE P1619.1 (soon to be published as IEEE Std 1619-2007).  Sun's T10000 uses AES-CCM, both as specified in P1619.1 and in NIST SP 800-38C.  IBM's TS1120 also uses AES-GCM.

So why aren't hard disk vendors disclosing the technical details about their encryption implementation?

Here are my thoughts:

1. Hard disk vendors don't think that the mode of encryption is too important because it is difficult to get direct access to the encrypted data (this would require bypassing the firmware or putting the hard disk on a spin stand)
2. Hard disk vendors are afraid that weaknesses will be found in their encryption mode, whether real or perceived
3. There are no good standards to use for hard disk encryption

While it is true that most users don't understand enough about encryption to even know what a mode-of-operation is, I believe that these details will become increasingly important as buyers become better educated and demand open details about the encryption.  Otherwise there is no way to know whether you've been sold snake oil that doesn't actually provide measurable benefits (for example, weak ECB encryption of the entire hard disk using the otherwise strong AES block cipher).

Concerning standards, this is an example of how the late arrival of IEEE 1619 has caused confusion in the storage encryption industry.  When IEEE 1619 start about 6 years ago, the goal was to create a strong encryption standard suitable for data storage devices.  First came the wide-block EME mode.  This mode fell when Antoine Joux found a vulnerability that sent Shai Halevi and Phil Rogaway back to the drawing board.  Next was the LRW mode.  This fell when Niels Ferguson of Microsoft noted in Crypto 2006 that you can leak the tweak key if encrypted with itself (Microsoft has no control over where the keys are).  About this same time, the Trusted Computing Group wanted to endorse LRW (this was dropped).  About two years ago during the LRW unrest, Mart Somermaa pointed the group to the XEX mode as proposed by Phil Rogaway.  The P1619 group added ciphertext-stealing to this mode and called it XTS-AES.  

The XTS-AES algorithm was approved last December by IEEE as part of IEEE 1619-2007, and is nearly published.  After it is published, IEEE will submit XTS to NIST for consideration as an Approved Mode of Operation for FIPS 140-2.  If NIST accepts XTS, then this will become an excellent mode for hard disk vendors to consider.

Seagate Includes IEEE P1619.3 in an FDE Whitepaper

Seagate recently published a white paper depicting the IEEE 1619.3 key management protocol used in a system containing Seagate Full Disk Encryption (FDE) hard disks. It's an interesting read if you're into the hardware encryption scene.

The white paper mentions using existing key management systems, like IBM's EKM (Enterprise Key Management) system, with storage systems that include Seagate FDE hard disks

The FDE encrypts the hard disk data using an AES-128 encryption key (NIST's Advanced Encryption Standard), and stores the only copy of this encryption key on the hard disk in encrypted form. To decrypt the encryption key, you need an 'authentication key'. The FDE also stores a cryptographic hash of the authentication key, which is used to verify whether the user entered the correct authentication key.

The beauty of this setup is that it is possible to perform a fast secure-erase of the hard disk by simply erasing the encrypted encryption key. Also, if an attacker was able to open the hard disk or compromise the firmware, the only available information is the encrypted encryption key and the hash of the authentication key. Without the authentication key, it is impossible to get any data off the hard disk.

There are a few caveats here, however:

1. In the absence of a key management server, the authentication key is likely a password entered by the user, which makes the strength of the encryption only as strong as the weaker of the entropy of the password (which is typically very low) or the physical security of the hard disk (which is unknown). If someone is able to comprise the firmware of the FDE hard disk to reveal the hashed authentication key or encrypted encryption key, then it becomes possible to launch an off-line dictionary attack against likely passwords, making it possible to decrypt the data.
2. Neither the white paper nor any other source I've seen describes the AES encryption mode used for protecting the data and the encryption key in the FDE. Just using AES-128 is not sufficient to ensure a high-level of security -- you need to use AES in a secure mode of operation. For example, using AES in Electronic Code Book (ECB) mode is notorious for leaking a significant amount of data -- see an example of Tux (the Linux penguin) encrypted using ECB as compared to other modes. I'm not saying that Seagate is using a bad mode of operation -- it's just that we don't know.
3. The white paper mentions P1619.3 even though the standard is still in relatively early stages. On the one hand, I like seeing publicity for P1619.3, but on the other it's hard to say exactly how it will look in the end. It may not be what we expect.
   

Overall, I'm very happy to see encryption enter the hard disk market and to see increased interest in the 1619.3 work. The FDE hard disk is certainly sufficient for most user's security needs. However, for the agencies with high security needs (like the government), the lack of FIPS 140-2 certification and encryption mode disclosure makes it a difficult (if not impossible) purchase. Hopefully after P1619.3 helps create interchangeable key management solutions, we'll see the FDE volumes increase enough to justify improvements like FIPS certification.

Who uses IEEE 1619 and 1619.1?

Last December, IEEE approved the standards two encryption standards (See Press Release):

• IEEE 1619 (specifying the XTS encryption mode, commonly used for disk encryption); and
• IEEE 1619.1 (specifying GCM, CCM, CBC-HMAC, and XTS-HMAC encryption modes, typically for tape) .

Byte and Switch interviewed me in an article discussing this and other related standards.

Currently the IEEE Security in Storage Working Group (SISWG) is investigating the possibility of submitting the IEEE 1619 XTS mode to NIST for consideration as an Approved Mode of Operation for FIPS 140-2 certification. One of the questions asked on the SISWG e-mail reflector was whether there is widespread industry support for these newly approved modes.

From doing some web searching, I've come up with the following list of companies who are claiming compliance to these newly approved standards.

IEEE 1619 (XTS-AES) Support

• True Crypt - Version 5.0 now supports XTS for software disk encryption
• (Update from 2016: TrueCrypt is no longer maintained and has been accumulating security issues so this is no longer recommended.  Please see this list of alternatives instead).
• FreeOTFE - Free On-The-Fly-Encryption
• dmcrypt - Encryption for the Linux 2.6 kernel
• Hifn: "Hifn’s full line of Applied Services Processors as well as its board-level security acceleration products currently support, and are compliant with, the encryption algorithms specified in the IEEE 1619 standards"
• Helion Technology: AES-XTS cores
• Elliptic Semiconductor:
• CLP-33 XTS-AES cipher core
• CLP-35 High Throughput XTS-AES cipher core
• IP Cores: XTS-AES IEEE P1619 Core Families XTS2 and XTS3
• Hightech Global Design & Distribution: Combined AES-GCM-XTS/XEX-CCM IP Core
• JetStream Media Technologies: High Speed XTS/XEX-AES Core
• SafeNet, Inc.: SafeXcel IP AES/GCM/XTS Accelerators

IEEE 1619.1 (GCM, CCM, CBC-HMAC, XTS-HMAC):

• IBM, HP, Quantum, Tandberg's LTO-4 Tape Drive uses IEEE 1619.1 GCM-AES
• IBM's TS1120 Enterprise Tape Drive uses GCM
• Sun's T10000 Enterprise Tape Drive uses 1619.1 CCM
• Many core vendors (basically same list as for 1619)

I expect that these lists will grow considerably after IEEE officially publishes 1619 and 1619.1 in the next couple months. Right now, it's hard to assess compliance because a product cannot technically claim compliance until the standard is published.

If you know of implementations that expect IEEE 1619 or 1619.1 compliance, please post a comment with the vendor and product name, with a link to the appropriate webpage.

TechWorld article on P1619.3

There was an article yesterday in TechWorld about the IEEE P1619.3 standard, and HP and NetApp's (i.e., Decru) involvement in shaping the current state of this standard. See this link:

Security: the protocol is the key by Chris Mellor

While it's good to get lots of press on P1619.3, it's not clear that the article articulated its point very well. Aside from a plethora of misspelling errors, the content seemed somewhat questionable. I've pulled out a quote from the article below, with commentary:

Blair Semple, a security evangelist at NetApp, [s]ays that IEEE has initiatives, meaning working groups, relating to storage security. These are:-

- IEEE 1619.0 relates to disk security,
- IEEE 1619.1 relates to tape security,
- IEEE 1619.2 relates to securing big blocks on disk,
- IEEE 1619.3 relates to key management.

Sempl says that 1619.3 is much earlier along in the standards process than the disk and tape device focussed standards. NetApp sits on all these committees and submitted the API, jointly with HP, from the Decru DataFort's Lifetime Key Management product, the Open Key API, as technology to be used for the 1619.3 protocol. He said the: "spec is approved and is the foundation for 1619.3."

(For the record, P1619 and P1619.1 are both in submission to IEEE, and should be published by early next year. P1619.2 is still a little ways off, and does not have a tight time schedule, yet)

I'm a little confused about the part that says "[NetApp] submitted the API, jointly with HP". The P1619.3/D1 draft was submitted to my knowledge only by NetApp (Decru). If HP had a hand in it, they kept quiet about their part. In fact, HP has kept quite about all their partnerships with key management. All the key management vendors I've talked to think they are HP's secret mistress -- NetApp included.

Another point is the quote that the "spec is approved". The IEEE P1619.3 standard isn't approved until IEEE sponsor ballot completes with an affirmative vote. The draft was approved by the working group, but this is only providing a rough starting point. We expect there to be many changes before it's all done. It may look nothing like OpenKey (i.e., Decru's API for their DataFort key management appliance) -- although it's hard to say because you need a non-disclosure agreement (NDA) to even see OpenKey.

NetApp mentioned that it has several OpenKey partners, including Symantec and Quantum. From my experience, this has been a little bit of a marking-driven statement that hasn't had much engineering work to back it up. Quantum has announced its own QEKM (Quantum Enterprise Key Management), which is a rebranding of IBM's Java-based EKM. Quantum has not announced any products that use OpenKey.

With the general availability of the encrypting LTO-4 (using P1619.1 GCM encryption), the only remaining problem left is universal key management. Several groups are working on this problem, but at this stage, the group with the biggest industry membership is the IEEE P1619.3 group. HP wasn't sure if IEEE is the right place to do this standards work (according to the article), but I haven't seen a better place yet. The standard is still in the early stages of development and needs some more time, but it will get there.