2010 IEEE Key Management Summit

Maybe I'm something of a glutton for punishment, but we're going to run another installment of the successful IEEE Key Managment Summit (KMS). The focus of KMS is on the challenges of securely managing cryptographic keys that are used to encrypt data. Last year, we held the first KMS 2008 with the 2008 MSST (Mass Storage Systems and Technologies) symposium (slides and mp3 recordings are still available for download). We had 75 attendees, which was an excellent turnout for a technical and highly-focused event.  Results from surveys also showed that the attendees were happy with the event.

The next Key Management Summit (KMS2010) is scheduled for May 4-5, 2010 in Incline Village at Lake Tahoe, NV.  It's a beautiful venue in the picturesque mountains near Reno, and the prices are quite reasonable compared to Baltimore last year and San Diego the year before.

Already, the program committee has found excellent speakers for about half of the slots.  We're still looking for more proposals and the deadline for submitting proposals is December 31, 2009.  So far, we have two proposals from NIST, one from the NSA, several from standards organizations that are involved with key management (IETF, OASIS, IEEE to name a few), leading banks, and others.  If you'd like to submit a proposal, please send an brief abstract to chair@keymanagementsummit.org for consideration by the program committee.

I'm excited that we'll be able to put together an even better program than last year, and hope to see you there!

TrueCrypt Releases version 6.0

On July 4th, 2008, the TrueCrypt Foundation released TrueCrypt version 6.0. TrueCrypt is a very popular open-source disk encryption tool that is currently based on the XTS-AES encryption mode that the IEEE P1619 Task Group developed and standardized in December 2007. As the chair of the IEEE Security in Storage Working Group (SISWG) -- the group that oversaw the development of XTS -- I'm very pleased to see the continued adoption of XTS in the industry.

On a related note, NIST is currently considering XTS as an Approved Mode of Operation for protecting U.S. government confidential data under FIPS 140-2. If NIST accepts XTS, this will be a huge boon to TrueCrypt and similar tools that use XTS. If you use TrueCrypt or other tools that use XTS, please send NIST a comment (before Sept 2008).

For a limited time, you can pick up a free copy of XTS from IEEE. After September, you'll have to buy it from the IEEE store. See the P1619 homepage for instructions and other information.

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.

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.