Cracking a Crypto Hard Drive Case

juct writes "A label on the box reading 'AES' does not ensure that your data are protected. heise examined a hard drive enclosure with an RFID key that is typical of many similar products. They found that the 128-bit AES hardware encryption claimed in advertisements was in fact a simple XOR encryption that they were able to break easily with a known plaintext attack." The manufacturer of the drive examined has announced that the product is being retooled and will be reintroduced later this year, presumably with actual AES encryption.

Criminal prosecution?

For God's sake, can't the company's executives be charged under a criminal statute? Fraud, anyone? I guess their next product will use advanced ROT13 encryption technology.

Re:Criminal prosecution?

Hey, that's better than ROT26.

Re:Criminal prosecution?

It'll be so good, it'll do ROT13 twice!

Re:Criminal prosecution?

It'll be so good, it'll do ROT13 twice!

Hah! That doesn't compare with DOUBLE-XOR encryption! :D

Re:Criminal prosecution?

Double-ROT-13 is funny
Quadruple-ROT-13 is twice as funny
Sextuple-ROT-13 is thrice as funny, and gets a two bonus points for the 's-e-x' string in it
Octuple-ROT-13 is twice twice as funny, and gets a bonus point for sounding a bit like the word 'octopus', which has 'p-u-s' in it, which sounds a bit like 'pussy', which is a synonym for 'vagina', which is related to 'sex'
Decuple-ROT-13 is twice plus thrice as funny
Duodecuple-ROT-13 is twice thrice as funny

After that it just gets lame.

Re:Criminal prosecution?

It's not fraud if it's still AES. In this case AES stands for the claims which are Advanced Equine Stool.

Re:Criminal prosecution?

For God's sake, can't the company's executives be charged under a criminal statute? Fraud, anyone?

AES was used /somewhere/.

It's /never/ a good idea to rely on cryptographic features when you don't know exactly how they are implemented. A vendor telling you they use AES is completely and utterly worthless, and always has been. It's a nice buzzword people like to use.

It's also NEVER a good idea to use any "crypto developed in-house". Manufacturers love to tell you since they developed it and their development is secret and such that their product is safe and secure, much more secure even since nobody knows how it works.
Cryptologists laugh at those claims, and everybody else should, too. These non-encrypting devices are a good reason as to why they do so.

If you want truly encrypted files and disks, don't rely on cheap external enclosures. TrueCrypt is not hard to use and offers a decent level of protection (forget Windows crypto, it's littered with backdoors unless configured JUST right, which is not an easy task and definitely not default). Under linux, it's decidedly easy to use AES encryption on block devices.

I guess their next product will use advanced ROT13 encryption technology.

For good measure, they'll apply it twice -- after all, twice is better than once.

Re:Criminal prosecution?

This is, of course, also the reason why you should never trust any closed-source products to do anything important. You have absolutely no clue about what it does and how it does it, no matter what it claims to do.

Re:Criminal prosecution?

Hardware crypto, such that key authentication/management is done without any computer interaction, means I don't have to worry about the security of the machine I'm using

Wrong. If the machine you are using is compromised, anyone with access to it can access your data as soon as you unlock it, either with your physical key, or with a password. Doesn't matter if you use software or hardware encryption. If your text editor can read the file on the disk, so can any other program on the computer.

How about a software solution?

Would something like TrueCrypt [truecrypt.org], where you can easily look at the source, be a better solution? At the very least, it could avoid problems like these.

Re:How about a software solution?

Call me back when they have released something based on version 5.0 that "works" with Linux. Right now, the newly released 5.0 series is broken on Linux. It will cause your machine to lockup on most kernel versions used by Linux distros. Apparently, according to the authors of Truecrypt, they require you to upgrade to the latest release of the Linux kernel, which may not be an option for most of us.

Secondly, even if you were able to make it work the Linux kernel on your machine, the new FUSE-based Truecrypt 5.0 series is only 1/20-1/10 of the speed I get from the 4.x series. From 20-40 MB/s, now I only get 1-5 MB/s.

I am now considering to switch to dmcrypt+luks.

Well, as others have noted

This was a hardware solution. There's reason to want your encryption done in hardware (less CPU load for example).

However more importantly, what good does the source really do you? I mean I can get the Truecrypt source, and I can look at it, but it really isn't going to tell me anything other than that I'm not very good at C++. I'm not a programmer by trade, so I certainly can't trace through all the complicated code that makes up a program like Truecrypt (it even includes assembly).

What's more, even if you are a programmer, it doesn't necessairily do you any good. Cryptography is a pretty specialized field and a pretty complex one. So while you might be able to trace through all the code and see what it does, do you have all the cryptographic knowledge to know if it is doing everything right? Can you tell the different between a properly and improperly applied algorithm? Will you notice a minor bug in assembly where they put a JNA instead of a JNAE? You might conclude everything looks fine, but be wrong simply because you don't understand how it works well enough or because the error is non-obvious.

Now please don't misunderstand, I'm not saying I think Truecrypt is untrustworthy. Far from it, I use and trust it. I am just saying that there is the false warm fuzzy myth about OSS that tends to get thrown around on /. a lot. That the code is open doesn't mean anything because 99.999+% of people can't "easily look at the source" since it won't be meaningful to them. A source audit is only useful if the person doing it is an expert and does a thorough job.

Well, while that certainly can, and does, happen with OSS, it can happen with closed software as well. Being open doesn't make it inherantly secure, and doesn't mean a normal person can tell.

For that matter, to really check crypto software you don't just need a code audit, it is even more important to do a results audit. Basically you take data, you encrypt it, and then you look at the result and see if it is good. You treat the software like a black box because the question isn't "Is it producing the correct result based on the code," the question is "Is it producing the correct result based on the cryptosystem." If I wanted to audit Truecrypt I wouldn't so much be interested in how it did things internally. Heck, even if I was an expert it might easily have a bug I'd miss (since after all other experts had written it and missed said bug). What I'd be interested in is having it do encryption, then comparing the result against controls. Maybe another AES implementation I knew to be good, maybe one I wrote, maybe a bit of a test worked out by pen and paper, maybe just trying to do cryptographic attacks against the ciphertext..

Regardless of the method, what I'd want to do is verify operation, not design. I imagine that's what they did in this case. Drive claims "this is AES encryption" so they do a little compare and contrast and, what do you know, it isn't.

Re:How about a software solution?

I'm aware it's not the same thing :). While I understand the performance benefits of doing the heavy computation with specialized hardware, I'm questioning the wisdom of trusting any embedded encryption platform that isn't easily audited for correct operation. What about devices that actually perform encryption using the algorithms claimed, but the implementation of the crypto routines contains a flaw that isn't easily detected? What do you do about it when your organization has a few of them in production? Closed platforms make me nervous when security really matters.

Re:How about a software solution?

There's another disadvantage to hardware encryption like this product, even if it worked correctly, and why I also favor something like TrueCrypt (which is infact what I use) even if it might make a bit more work for the computer. The maker says "this is our special chip, and here's the source for our firmware for you to inspect"...now, how do you *know* that's really the firmware that's on that chip? Very few of us are in a position where we could take that source and make our own chip. In a situation where I want to be assured of security, I'm going to not only use TrueCrypt, I'm going to compile it myself.

Re:How about a software solution?

I'm going to not only use TrueCrypt, I'm going to compile it myself.

That won't help you. You need to read Reflections of Trusting Trust by Ken Thompson: http://cm.bell-labs.com/who/ken/trust.html [bell-labs.com]

So what happens...

...when you lose the RFID fob?

Does the mfg keep a list of serial #s and RFID keys so they can mail you/thief a replacement?

Re:So what happens...

All the fobs are encoded with the special key: QWERTYUIOP1234567890. Don't worry though, the key is copyrighted internationally and cannot be used without proper authorization. Devilishly ingenious, those wily engineers...

Re:So what happens...

I think this is actually true in some cases. I once worked on some 2.4ghz radios from a certain vendor, and if you forgot the admin password you could expose them to the net and they could "unlock" them (YIKESOMG). They also had a version where you gave them the MAC of the radio and they gave you a special "unlock" password over the phone. Yea. It wasn't even random either, it was an english word iirc. The world of proprietary network gear = ugh. I prefer building them myself using Soekris or similar.

Re:So what happens...

...when you lose the RFID fob?

Glad that you asked. Thank you for being our customer. Please go download http://vendor/recover.exe [vendor]. It will recover your data on your harddrive. This is a feature. Thank you for your business.

Does the mfg keep a list of serial #s and RFID keys so they can mail you/thief a replacement?

Quite honestly the entire concept is flawed. a.) if you loose your key and somebody else can furbish another one, your crypto is broken by default. You cannot trust it to secure anything at all. b.) RFID IDs as keys ? Sure, everybody knows RFIDs can ONLY be read at a distance of several centimeters. Right ? RIGHT ?

The question you should be asking is "If somebody copies my key, can I change the lock ?"

This has to be illegal

This can't possibly be legal. Even the CEO should have an idea if one of their newest product does some highly technical thing which it advertises as a major feature. I don't expect him/her to know how AES works... but he should at least be sure that it is working on the drive. I'm sure his pocket change could hire a contractor to test this.

Trust

The manufacturer of the drive examined has announced that the product is being retooled and will be reintroduced later this year, presumably with actual AES encryption.

Trust is a precious resource that you must cultivate; it's not a boomerang. Never risk throwing it away.

XOR encryption can be good

XOR doesn't immediately mean that it is a crappy form of encryption. One Time Pads [wikipedia.org] can be a very good form of encryption, if the pad is generated correctly and used only once. But, that isn't very useful for encrypting a hard drive. It looks to me like the "encryption" in the box was just a 512 byte key used like a OTP for each sector, which is trivial to break, as the article says.

Stream Ciphers [wikipedia.org] also use XOR, but are much more convenient to use and could very easily be used to encrypt a hard drive.

Re:XOR encryption can be good

Stream Ciphers [wikipedia.org] also use XOR, but are much more convenient to use and could very easily be used to encrypt a hard drive.

The problem is that very few stream ciphers allow you to quickly seek to an arbitrary point in the stream - so unless you just want to read the entire drive sequentially you're SOL.

The only exception I've read about is SEAL [wikipedia.org] but IIRC that's still patented by IBM.

Re:XOR encryption can be good

To enforce parent's point, many (if not all) of the best modes of operation (CCM, etc) for block ciphers like AES use XOR -- it would be silly to think of cryptography without XOR.

It is also true that one can use AES (ignorantly) in a way that allows decryption as described in the article. Using Electronic codebook (ECB) [wikipedia.org], for example, with the same key for each block, would provide no security beyond what would be provided by a reused OTP. Sadly (though obviously insecure), this is still technically using AES as a block cipher -- it's just using an insecure mode of operation. My first thought was that the manufacturers used ECB, or a similar insecure mode of operation (trusting the claim of using AES).

From reading the article, though, it seems the manufacturers even admitted only using AES "when saving the RFID chip's ID in the controller's flash memory" and that "actual data encryption is based on an algorithm developed in-house." Just goes to show that if tried-and-true algorithms / ciphers are available, you should NEVER have to develop your own.

Perfect XOR encryption.

XOR is not an encryption method, it's just a binary operation. It's what you XOR your data with that determines if your encryption is good or not. That's what is the problem in this case.

Indeed. I XOR the data with itself, making sure that it can never, ever be decrypted.