Re: disks with hardware FDE
Arshad Noor <[EMAIL PROTECTED]> writes: >Perry E. Metzger wrote: >> There are now a number of drives on the market advertising AES based >> FDE in hardware, and a number of laptops available on the market that >> claim to support them. >> [...] > >There is a debate going on on that list about the value of >encrypting data at the disk-drive layer vs. encrypting at the >application layer - I believe the latter is a more strategic >solution - and the voices from the Crypto forum would be >welcome on these issues. One thing about drive-based encryption is that we're been proised this since about 2000 or 2001, and it's always just another year or two away for various reasons: standardisation, host controller support, OS support, phase of the moon, ... . The current reason seems to be FIPS 140: the turnaround time for a FIPS 140 eval is significantly longer than the mean lifetime of any particular hardware/firmware config, and the cost of the constant re-evals doesn't help much either. So drive-based FDE is currently awaiting the loading of a compliment of small FIPS 140-soaked paper napkins. Until then there will be a short delay. Please return to your seats. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: disks with hardware FDE
On Tue, 8 Jul 2008, Perry E. Metzger wrote: | >> Has anyone had any real-world experience with these yet? Are there | >> standards for how they get the keys from the BIOS or OS? (I'm | >> interested in how they deal with zeroization on sleep and such.) | > | > Most manufacturer (will) implement the TCG Storage Specification: | > https://www.trustedcomputinggroup.org/groups/storage/ | > | >> Lastly, anyone have any idea of whether the manufacturers are doing | >> the encryption correctly or not? | > | > I know that Seagate Secure does not use XTS mode, but something CBC | > based. | | Where do they get their IVs from? I have no idea what they actually *do*, but the obvious way to get an IV is to use the encryption of the block number. Guaranteed known to whoever needs to decrypt the disk block, and unique for each disk block. (Using the disk block number itself as the IV is actually reasonably safe, too, though it seems a bit too structured - one can imagine files which have a leading count or even a copy of the disk block number in each disk block leading to an initial zero input to the encryption.) (I think one of Phil Rogoway's papers suggest this kind of approach for a "safe" CBC API: Given an existing CBC API that takes an IP as input, instead build one that takes no explicit IP, but (a) maintains an internal counter; (b) prepends the current counter value to the supplied input and increments the counter; (c) supplies the underlying API with an IP of 0. The modified API can't be abused by accidentally re-using an IP.) | In general, I feel like the only way to really verify that these | things are being done correctly is to be able (in software) to read | the ciphertext and verify that it is encrypted with the right key in | the right mode. The small amount I've heard about the design leads me | to worry that this is not actually possible. Somehow we still haven't learned the lesson that the security can only come from (a) published, vetted algorithms and modes; (b) a way to check that the alleged algorithm is what the "black box" actually implements. Of course, for all you know it implements the algorithm while hiding a copy of the key away somewhere "just in case" But that's a whole other problem. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: disks with hardware FDE
Dries Schellekens <[EMAIL PROTECTED]> writes: > Perry E. Metzger wrote: > >> Has anyone had any real-world experience with these yet? Are there >> standards for how they get the keys from the BIOS or OS? (I'm >> interested in how they deal with zeroization on sleep and such.) > > Most manufacturer (will) implement the TCG Storage Specification: > https://www.trustedcomputinggroup.org/groups/storage/ > >> Lastly, anyone have any idea of whether the manufacturers are doing >> the encryption correctly or not? > > I know that Seagate Secure does not use XTS mode, but something CBC based. Where do they get their IVs from? In general, I feel like the only way to really verify that these things are being done correctly is to be able (in software) to read the ciphertext and verify that it is encrypted with the right key in the right mode. The small amount I've heard about the design leads me to worry that this is not actually possible. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: disks with hardware FDE
Perry E. Metzger wrote: There are now a number of drives on the market advertising AES based FDE in hardware, and a number of laptops available on the market that claim to support them. Has anyone had any real-world experience with these yet? Are there standards for how they get the keys from the BIOS or OS? (I'm interested in how they deal with zeroization on sleep and such.) Lastly, anyone have any idea of whether the manufacturers are doing the encryption correctly or not? Perry, I have copied the IEEE 1619.3 Working Group where disk-drive manufacturers are working on some of these KM issues. There is a debate going on on that list about the value of encrypting data at the disk-drive layer vs. encrypting at the application layer - I believe the latter is a more strategic solution - and the voices from the Crypto forum would be welcome on these issues. I will let the FDE vendors respond to you so you can forward as appropriate. Thanks. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
