Schneier on Tweakers.net on (In)Secure USB Storage
Thomas Ptacek | April 22nd, 2007 | Filed Under: Defenses, Uncategorized
If you read our blog you already read this story, but, Bruce Schneier wrote an editorial in Wired about how the security market converges to snake oil just as the used car market converges to lemons, using the Tweakers.net takedown of the “Secustick” as an example.
Long story short: a “secure USB stick” with “the ability to destroy itself once an incorrect password has been entered” checks a password stored in cleartext on the stick in software, with debugging symbols present, to authorize access to unencrypted files.
And so, from the Tweakers article, a nit:
Checking the password and unlocking the files are two separate processes. […] The most secure sticks execute both encryption and unlocking on the chip. A somewhat less secure method consists in comparing an encrypted password that resides in the controller with one that is stored on the pc. […] Less secure still is storing it in the stick’s memory, since that can lead to the password being read from the chip. The Secustick is another step lower on the ladder: the processes of checking the password and unlocking the stick are executed entirely on the pc
What year is this? None of these rungs on the “security ladder” are secure; there’s A Right Way to solve this problem, which is, expand a passphrase into a block encryption key using a slow adaptive hash.
The passphrase is stored nowhere, the encryption/decryption can occur anywhere (after all, if you’re taking input from the keyboard, who cares?), and no amount of messing with the code wins you access to the data, which is encrypted under the passphrase rather than guarded by the passphrase.
The Tweakers article is great, and this is one of the rare non-technical Schneier articles that I actually found insightful, but there’s a lesson being hidden here. If your “secure USB stick” uses something other than PGP to encrypt data at rest, you should assume it’s busted. You don’t need to wait for the 6-page Tweakers.net takedown.
[Edit: 4/24]
Ok, I shouldn’t use the words “A Right Way” without knowing The Right Way. Read the comments.
Someone Else
April 23rd, 2007 11:00 amApple Mac gets pwned at CanSecWest
UPDATE 21/04/07 19.33GMT. The Matasano website has been amended to add the following: Apparently the
sargon
April 23rd, 2007 4:55 pmMaybe I am misreading your solution. Are you saying that you want to encrypt data on your USB stick with a password a la PKCS 5? Unless your password is very long with sufficient entropy you are going to be vulnerable to brute force. Hashes are fast to compute and I don’t know if a “slow adaptive hash” is slow enough.
Andrew
April 23rd, 2007 11:11 pmThe creation of data encrypting keys from a passphrase should be avoided. It is common for these types systems to assume that the encrypted data is as good as destroyed when the key is deleted - and as Sargon stated, a passphrase just does not give you enough entropy for that. At best, you’ll be losing effective key bit strength.
The passphase should be used to generate a KEK that encrypts the main key (which should be randomly generated with a NIST SP 800-22 compliant PRNG). Ideally, this (encrypted) key will be stored in the internal RAM of the USB processor, and not externally accessible.
Then, when you want to erase the data, just delete that key.
As for if it doesn’t use “…PGP to encrypt data at rest, you should assume it’s busted” - there are a number of good commercial and freeware encryption utilities that are secure - Truecrypt being a good (freeware) example.
Thomas Ptacek
April 23rd, 2007 11:29 pmIMO, the only thing the KEK buys you is convenience, but I grant that it is convenient.
As for entropy: an adaptive Blowfish hash of an arbitrarily long passphrase generates totally random key material, and the point of an adaptive hash is to allow the computation to take as much time as the defender wants it to.
How does Truecrypt improve on PGP?
Andrew
April 24th, 2007 3:38 amIf the enciphered main key is stored in the internal memory of the controlling micro-processor of the USB stick, it provides significantly more security. Deciphering of the USB key contents would require extraction of this key - if the actual data encipherment key were generated from the passphrase, it would still be possible to exhaust the passphrase to gain the key value.
For the second point, you appear to be confusing entropy with randomness. The two are not identical. A hash function cannot generate entropy, regardless of how many iterations are performed. As an english passphrase is commonly regarded to have around 2 - 3 bits of entropy for each character, so to gain the full bit strength of a 256 bit key you need a passphrase of around 85 - 128 characters.
With keys, both randomness and entropy are important.
Whether or not Truecrypt improves on PGP is not the issue in point (although cost is at least one area where it does - PGP disk is only included in the payware version). The mere existence of a viable alternative to PGP invalidates the statement: “If your “secure USB stick” uses something other than PGP to encrypt data at rest, you should assume it’s busted.”
Bill
April 24th, 2007 12:17 pmDoes anyone have a link that has a good primer on password entropy? I’ve stumbled through some Google results, but didn’t find anything particularly accessible to a non-cryptresearcher.
Thomas Ptacek
April 24th, 2007 12:36 pmYou want this tool:
http://www.fourmilab.ch/random/
Very, very much.
Just compile it and feed it strings and get a feel for what entropy means. Normal text has low entropy; it’s not “dense”, so you need a lot of it to build up a pool of key material.
Nate hand-held me through this stuff last night (hence the brief correction to the blog post) and said, “remember, entropy is only maintained, not reduced”. If you start from low-entropy data (an inherent risk of passphrases), you wind up with low-entropy keys.
So the security win with KEK’s is that you’re generating a random key, which is guaranteed to be high-entropy.
Shawn F
April 24th, 2007 1:54 pm>> “remember, entropy is only maintained, not reduced”.
Don’t you mean “not increased”?
It’s tempting to want to construct password based encryption mechanism like this because you don’t have to store the key. But then you end up only partially solving two problems rather than totally solving one. Here encryption can be used to ensure that data stored offline on your USB stick remains confidential. If you leave the device on the train, you know it’s safe. If you use a password based key you know its safe only until someone really tries to get at it.
Generally you have to store your key someplace and then you try and find a good way of controlling access to that key.
Companies are starting to come out with USB form factor secure ICs (i.e. smart card chips). If someone built, and maybe they already do, a USB memory stick with an integrated secure IC where the IC stored all the keys and performed all encryption/decryption that would be cool. Of course then you would have the problem of creating a trusted channel to enter your password/PIN.
Thomas Ptacek
April 24th, 2007 2:00 pmYou’re right. I should be more careful before I type today.
Thomas Ptacek
April 24th, 2007 2:03 pmMy bias against the KEK scheme — and I should say, this is something I’m totally not authoritative on — is that I’ve dealt with a couple of schemes now where the KEK is just stored alongside the data. That’s just passphrase-based encryption with an extra step.
bob
April 25th, 2007 10:20 am@sargon
PKCS5 uses many rounds of a hash to make the key derivation as slow as you want. This compensates for the lack of entropy in the passphrase.
Robert Ransom
April 25th, 2007 10:48 am> … the KEK is just stored alongside the data.
That’s probably the data encryption key (DEK?).
> That’s just passphrase-based encryption with an extra step.
As Andrew stated, a passphrase-based key can always be guessed - to make all data encrypted under such a key unrecoverable, it is necessary to physically destroy all of the ciphertext. This is a good reason to use a passphrase-based KEK to encrypt a separate DEK stored in the control chip on a secure storage device, as it is somewhat easier to reliably destroy a 320-bit encrypted DEK in the control chip than to destroy all data on a separate 1-GB flash chip. (The 320-bit size for the DEK assumes that the device uses AES-256 for data encryption and AES Key Wrap for key encryption, which produces a 64-bit message integrity check value.)
If you want real security, the security-critical data should be stored in RAM so that the attacker does not need to helpfully provide electrical power for the purpose of destroying the data. Serious attackers will not cooperate with such a scheme. The amount of security-critical data needs to be limited if it is to be stored in RAM, so a DEK-based scheme is also necessary here.
sargon
April 25th, 2007 3:18 pm@bob
Yes I know. However the salt is really what is, “compensating for the lack of entropy”. The iterations make dictionary attacks harder.
Although I have not looked at PKCS#5 in some time I recall that it specifies block ciphers and not hashes. Also I don’t know if you can, “make key derivation as slow as you want.”
I think the point has been made but I want to just reiterate that a password is NOT the same as a good randomly generated cryptographic key (e.g. for AES). I have seen this type of idea in a number of presentations from people who should know better (i.e. security researchers).
One would think that common sense would dictate here; if cryptographers can’t solve the problem of having to store a key *someplace* in clear text, how can you believe *your* solution of encrypting data with a password is somehow new and special.
PBE can add to the security of a system, but its important to know its limits and issues. What would be interesting is seeing some time/computing power analysis of brute forcing a well designed PBE mechanism with a strong password.
Matt Green
April 26th, 2007 12:05 pmThere’s some interesting new work on using CAPTCHAs (or other human-in-the-loop puzzles) to slow down dictionary attacks on offline storage. Essentially, the password-based key derivation function is replaced with one in which the human has to solve puzzles. This is a minor inconvenience for the legitimate user, but a major trouble for a user trying to run a dictionary attack. Far from practical, but an interesting new direction.
http://eprint.iacr.org/2006/276
Leave a reply