Re: Seagate announces hardware FDE for laptop and desktop machines
Ivan Krsti? wrote: On Sep 6, 2007, at 6:14 PM, Jacob Appelbaum wrote: other known good implementations of AES128 (CBC? I'm not sure...). Plain AES-CBC is not a great choice for FDE. You can do whatever you'd like to the bits of a given block at the cost of garbling the previous block, which makes binaries a plausible target. Given the size of modern OSes, it might even be an easy one. That's not the threat model; the main use of FDE is to protect the data in a lost/stolen laptop. FWIW, a couple of days ago I got yet another of those letters where a former employer is informing me that they lost my personal data; this time it was AT&T telling me that a laptop with employee benefits on it got stolen. /ji - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
| Date: Thu, 6 Sep 2007 16:00:03 -0600 | From: Chris Kuethe <[EMAIL PROTECTED]> | To: Jacob Appelbaum <[EMAIL PROTECTED]> | Cc: Cryptography | Subject: Re: Seagate announces hardware FDE for laptop and desktop machines | | On 9/6/07, Jacob Appelbaum <[EMAIL PROTECTED]> wrote: | > Seagate recently announced a 1TB drive for desktop systems and a 250GB | > laptop drive. What's of interest is that it appears to use a system | > called DriveTrust for Full Disk Encryption. It's apparently AES-128. | | Yes, but will it work on my UltraSparc? How about my PPC powermac? Or | maybe my OpenBSD laptop? First off, it depends on how the thing is implemented. Since the entire drive is apparently encrypted, and you have to enter a password just to boot from it, some of the support is in an extended BIOS or some very early boot code, which is "below" any OS you might actually have on the disk. Once you get past that, though, it depends on what they provide. If the boot-time password gets stored in the disk firmware and controls all encryption and decryption for the "session", the OS would neither know nor care. If the drivers have to get involved, or you *want* them involved (e.g., because you want to use the disk hardware to do encryp- tion with different sets of keys you assign to different files, partitions, whatever the thing can support) then ... ask for something reasonable: That the interface to the mechanism is published so that someone can write the appropriate drivers. | What's that - I have to use some opaque mechanism to key my drive? Pass. Ah, yes, it's all a conspiracy to make you run Windows. Grow up. *If* the drive vendor keeps the mechanism secret, you have cause for complaint. But can you name a drive vendor who's done anything like that in years? What possible motivation could they have? (In fact, I believe Seagate has said they will publish the specs.) | And how do I know that the drive didn't just store a copy of my | encryption key in NVRAM somewhere which can be retrieved by reading | some magic sequence of negative sectors? And what about a zillion | other paranoid but reasonable concerns? You don't. The general issue of how you can come to trust a piece of cryptographic hardware has been discussed here before, and no one has been able to suggest a way to do it. Guess what: Seagate makes the same point. As one of the two remaining drive vendors who are actually US-based (I forget who the other is), they've pointed out to Congress that it might not be such a good thing if DoD's and Homeland's and the FBI's secure disks were all based on chips and firmware developed overseas (and particularly in China). They bring this up purely for patriotic reasons, of course. If Congress sees fit to provide a bit of protection, well, that's a national policy issue, not Seagate's doing :-) Of course, most of the world's countries will be faced choosing secure devices developed and built in one of 3 or 4 countries, at least the two largest of which have very well developed organizations to, err, develop information in the national interest. Who are you willing to trust? How much are you willing to pay to avoid trusting someone you would rather not trust? Personally, if I were *that* concerned, I'd use an encrypted file system on top of an FDE system, at least for the stuff I considered really sensitive. -- Jerry | CK | | -- | GDB has a 'break' feature; why doesn't it have 'fix' too? | | - | The Cryptography Mailing List | Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] | | - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
On Sep 6, 2007, at 6:14 PM, Jacob Appelbaum wrote: other known good implementations of AES128 (CBC? I'm not sure...). Plain AES-CBC is not a great choice for FDE. You can do whatever you'd like to the bits of a given block at the cost of garbling the previous block, which makes binaries a plausible target. Given the size of modern OSes, it might even be an easy one. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: In all the talk of super computers there is not...
This is an interesting analysis, and the right way to proceed, I think, when dealing with passphrases that contain sequences of natural language words. I I think the 2.5 bits per word estimate, however, is a massive leap. The problem is that, when it comes to word sequences, the perplexity of each contiguous word is much higher than for each contiguous letter in the same text. That is, there are many more possible symbols that can follow the current one. You identified several alternatives that have the "had a" prefix, and they are are fairly likely. Given the "had a" bigram, it might be the case the the conditional entropy of the following token is fairly small, compared to the general entropy of English unigrams. If "had a little" isn't right, though, the number of possible words that might come next is massive. I think the proper way to continue with this analysis would be to look into the research that has been done on n-gram language models. I think you'll find that even the best models will never get the conditional entropy of an arbitrary word down to 2.5 bits. That would mean that basically had the next word narrowed down to less than 8 choices! This may occur in some very common combinations, but in general the conditional entropy will be much higher. In addition, the phrase-initial word will always have a fairly high perplexity, because the only thing to condition the distribution over possible words for this case on is the fact that it is phrase-initial. That being said, it seems like the idea that the passprases are much less secure than traditional character-lever analysis would suggest is spot on. Google recently published DVDs with their counts of the frequencies of all n-grams up to 5-grams in their web corpus (http://googleresearch.blogspot.com/2006/08/all-our-n-gram-are-belong-to-you.html) Armed with that data and enough resources, one could build a language model that would make passphrase guessing much more principled and could reduce the amount of conditional entropy in a passphrase significantly. In fact, for passphrases up to 5 words in length, the entire phrase is probably already in the Google data, it's just a matter of having the resources to be able to get through them all. --dan > Leichter, Jerry wrote: >> > | A couple of questions. How did you come up with the ~2.5 bits per >> > | word? Would a longer word have more bits? >> > He misapplied an incorrect estimate! :-) The usual estimate - going >> > back to Shannon's original papers on information theory, actually - is >> > that natural English text has about 2.5 (I think it's usually given as >> > 2.4) bits of entropy per *character*. There are several problems >> here: >> > >> >- The major one is that the estimate should be for *characters*, >> >not *words*. So the number of bits of entropy in >> >a 55-character phrase is about 137 (132, if you use >> >2.4 bits/character), not 30. > > > I think in weird ways. :-) The rationale behind it follows: > > I assume that the passphrase is in syntactically correct English. So, > number of possible combinations is reduced by the great amount. Also, I > want to reduce the number of combinations, so I focus on the most > probable sentences. > > It seems ideal to use some stochastic grammar to describe this problem. > This type of grammar can be used to produce: > > 1) probabilities for the sentences so: > a) total count (state space) can be reduced by threshold > b) sentences could be sorted by probability > 2) estimate of shannon entropy (which allows me to estimate bits per > sentence or per word and possibly to craft more effective algorithm to > walk through the space) > > At this point I did a little test for one phrase and played with it a > little. I wanted to know, how likely is that using stochastic grammar > description, someone can infer that passphrase. I asked google for > aproximate count on phrases (results sorted by count): > > "had a look" 210 > "had a car" 591000 > "had a little lamb" 59 > "had a drink" 562000 > "mary had a little lamb" 522000 > "had a fight" 466000 > mary had a little fleece white snow 322000 //not a phrase > "had a president" 80200 > "had a snow" 42400 > "had a lamb" 27300 > > and also: > > "I have been there" 947000 > "to rescue" 219 > > "had" 1.2E9 > "is" 3.68E9 > "the" 5E9 > "a" 7.2E9 > >>From this I assumed that google indexes about 5*109 pages. It can bee > seen clearly, that "had a little lamb" is common phrase (relatively, > between similar phrases). It can be also seen, that the whole rhyme has > about an half count of phrase "had a little lamb". > > At this point I decided not to continue further and assumed, that this > passphrase has very low information content, so I used value of about > 2.5bits/word (which don't seem unreasonable when looking at the numbers > above). I didn't calculated the actual value, it can be higher or lower. >
Re: In all the talk of super computers there is not...
Leichter, Jerry wrote: > > | A couple of questions. How did you come up with the ~2.5 bits per > > | word? Would a longer word have more bits? > > He misapplied an incorrect estimate! :-) The usual estimate - going > > back to Shannon's original papers on information theory, actually - is > > that natural English text has about 2.5 (I think it's usually given as > > 2.4) bits of entropy per *character*. There are several problems here: > > > > - The major one is that the estimate should be for *characters*, > > not *words*. So the number of bits of entropy in > > a 55-character phrase is about 137 (132, if you use > > 2.4 bits/character), not 30. I think in weird ways. :-) The rationale behind it follows: I assume that the passphrase is in syntactically correct English. So, number of possible combinations is reduced by the great amount. Also, I want to reduce the number of combinations, so I focus on the most probable sentences. It seems ideal to use some stochastic grammar to describe this problem. This type of grammar can be used to produce: 1) probabilities for the sentences so: a) total count (state space) can be reduced by threshold b) sentences could be sorted by probability 2) estimate of shannon entropy (which allows me to estimate bits per sentence or per word and possibly to craft more effective algorithm to walk through the space) At this point I did a little test for one phrase and played with it a little. I wanted to know, how likely is that using stochastic grammar description, someone can infer that passphrase. I asked google for aproximate count on phrases (results sorted by count): "had a look" 210 "had a car" 591000 "had a little lamb" 59 "had a drink" 562000 "mary had a little lamb" 522000 "had a fight" 466000 mary had a little fleece white snow 322000 //not a phrase "had a president" 80200 "had a snow" 42400 "had a lamb" 27300 and also: "I have been there" 947000 "to rescue" 219 "had" 1.2E9 "is" 3.68E9 "the" 5E9 "a" 7.2E9 >From this I assumed that google indexes about 5*109 pages. It can bee seen clearly, that "had a little lamb" is common phrase (relatively, between similar phrases). It can be also seen, that the whole rhyme has about an half count of phrase "had a little lamb". At this point I decided not to continue further and assumed, that this passphrase has very low information content, so I used value of about 2.5bits/word (which don't seem unreasonable when looking at the numbers above). I didn't calculated the actual value, it can be higher or lower. If the passphrase is "The car looked at me with a telescope.", I would estimate it higher (unusual combination of words). Thinking about that original passphrase at character level shannon way is incorrect. It overestimates information in that sentence. Word level is better, but still not good enough. Information content is overestimated by many, especially for political speeches. ;-) -- Martin Tomasek - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
Jacob Appelbaum <[EMAIL PROTECTED]> writes: > Seagate recently announced a 1TB drive for desktop systems and a 250GB > laptop drive. What's of interest is that it appears to use a system > called DriveTrust for Full Disk Encryption. It's apparently AES-128. > > The detail lacking press release is here: > http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=seagate-unveils-new-giants&vgnextoid=6bb0e0e1f0494110VgnVCM10f5ee0a0aRCRD > > The relevant excerpt of it appears to be: > "The Barracuda FDE (full disc encryption) hard drive is the world?s > first 3.5-inch desktop PC drive with native encryption to prevent > unauthorized access to data on lost or stolen hard drives or systems. > Using AES encryption, a government-grade security protocol and the > strongest that is commercially available, The Barracuda FDE hard drive > delivers endpoint security for powered-down systems. Logging back on > requires a pre-boot user password that can be buttressed with other > layers of authentication such as smart cards and biometrics." > > > I found this somewhat relevant paper (though it seriously lacks > important details) on DriveTrust: > http://www.seagate.com/docs/pdf/whitepaper/TP564_DriveTrust_Oct06.pdf > > Has anyone read relevant details for this system? It seems like > something quite useful but I'm not sure that I trust something I can't > review... Hitachi's white paper is available from: http://www.hitachigst.com/tech/techlib.nsf/techdocs/74D8260832F2F75E862572D7004AE077/$file/bulk_encryption_white_paper.pdf (Btw, it contains something as rare as a reasonable threat analysis! At least compared to other advertising materials...) After having acquired the 1TB device, and didn't find any support for this feature, I re-read some information: The interesting part is the final sentence of the white paper: Hitachi will be offering the Bulk Data Encryption option on all new 2.5-inch hard disk drive models launched in 2007, including both the 7200 RPM and 5400 RPM product lines. At the request of the customer, ^^ this option can be enabled or not, at the factory, without any impact on the drive?s storage capacity, features or performance. I wonder how easily it would be to request this for a normal customer. I gave up when my supplier said they didn't offer this configuration. I would be interested to know which key-derivation function they are using, I'm assuming the key is derived from a password, and which AES mode and IV etc. Knowing that may enable you to verify that data is really stored encrypted: buy two devices, set up one to use disk encryption, and swap the logic boards and then read data from the supposedly encrypted disk. As for finding out if they accidentally also write down the AES key on some hidden part of the disk, that may be more difficult... /Simon - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: World's most powerful supercomputer goes online
Another potential use for the Storm worm... I can't imagine this would be why it's being assembled since there's no money in it, but consider the prospect of x million machines cycling from idle to full load once a minute. If the power swing in doing this is (for example) 100 watts per PC then even at 1M machines that's switching a 100 megawatt load in and out of circuit, which could cause some fun in power distribution systems. You could easily double (or more) this load by putting the PC and monitor to sleep and then running it up to full load and back down again. Obviously it's highly unlikely that that's what the Storm botherders are planning to do with it, apart from the lack of financial motive you'd need to carefully synchronise the timing, and the PCs would be distributed all over the world rather than affecting one grid. Probably the most you'd get is localised problems, overloading, maybe a few fires from wiring. OTOH the shock effect of someone being able to do this worldwide would be something to behold. Talk about a "light blue touch paper and stand clear". (If they *do* do this with Storm, remember that you read it here first :-). A much simpler attack if all you want to do is cause panic would be to just brick the machines and watch the fun when 1M+ RMAs hit the service channels. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
Chris Kuethe wrote: > On 9/6/07, Jacob Appelbaum <[EMAIL PROTECTED]> wrote: >> Seagate recently announced a 1TB drive for desktop systems and a 250GB >> laptop drive. What's of interest is that it appears to use a system >> called DriveTrust for Full Disk Encryption. It's apparently AES-128. > > Yes, but will it work on my UltraSparc? How about my PPC powermac? Or > maybe my OpenBSD laptop? > It seems the the answer would be yes for the laptop at the very least. > What's that - I have to use some opaque mechanism to key my drive? Pass. > It appears to use a firmware implementation. To quote their pdf I linked to before [0]: "DriveTrust technology implements on the drive a cryptographic service provider that provides encryption, hashing, secure storage, decryption, digital signature and random-number generating functions" Though I think that unless they're providing their full firmware code, it's not to be trusted. Though it should be possible to examine the on disk bits with other known good implementations of AES128 (CBC? I'm not sure...). > And how do I know that the drive didn't just store a copy of my > encryption key in NVRAM somewhere which can be retrieved by reading > some magic sequence of negative sectors? And what about a zillion > other paranoid but reasonable concerns? > All the more reason to investigate it. I wonder if they'll provide their firmware if a big enough client were to request it. They also claim to be about open standards: "An open standard is being developed within the Trusted Computing Group." Perhaps one of the Seagate developers is on this list? If not, I think they probably should be... -jacob [0] http://www.seagate.com/docs/pdf/whitepaper/TP564_DriveTrust_Oct06.pdf - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Seagate announces hardware FDE for laptop and desktop machines
On 9/6/07, Jacob Appelbaum <[EMAIL PROTECTED]> wrote: > Seagate recently announced a 1TB drive for desktop systems and a 250GB > laptop drive. What's of interest is that it appears to use a system > called DriveTrust for Full Disk Encryption. It's apparently AES-128. Yes, but will it work on my UltraSparc? How about my PPC powermac? Or maybe my OpenBSD laptop? What's that - I have to use some opaque mechanism to key my drive? Pass. And how do I know that the drive didn't just store a copy of my encryption key in NVRAM somewhere which can be retrieved by reading some magic sequence of negative sectors? And what about a zillion other paranoid but reasonable concerns? CK -- GDB has a 'break' feature; why doesn't it have 'fix' too? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
