Cracking a Crypto Hard Drive Case 238
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.
Leaves Software Based Encryption Relevant (Score:2, Informative)
XOR encryption can be good (Score:5, Informative)
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:How about a software solution? (Score:5, Informative)
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.
Manufacturer link. (Score:3, Informative)
Re:How about a software solution? (Score:3, Informative)
Re:XOR encryption can be good (Score:5, Informative)
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.
Re:XOR encryption can be good (Score:4, Informative)
Re:Criminal prosecution? (Score:5, Informative)
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.
Encryption with today's processors (Score:3, Informative)
Just to put things in perspective for this specific case, full-speed encryption of the I/O traffic of a 2.5" drive would be pretty cheap with today's processors. I happen to have a dev tree of OpenSSL 0.9.9 on my system, and its AES-128 implementation runs at 160 MByte/s (in 64-bit mode) on my dual-core 2.4 GHz Athlon 64. A typical 2.5" drive like the one cracked by Heise has a sequential I/O transfer rate of 50 Mbyte/s. Therefore encrypting at this rate would only require 16% of my CPU time (31% of a core). Or about 7-9% of CPU time of a $270 quad-core 2.4 GHz Intel Core2 Q6600.
Re:How about a software solution? (Score:3, Informative)
While they're hardware may be faulty an OS should NOT lock up just because its gets unexpected signals/data down a USB cable. Sounds to me like there was a major issue with some or other linux driver.
It's not the company's fault... (Score:5, Informative)
They used a chipset from INNMAX, the IM7206 [innmax.com], believing it provided AES encryption to data. INNMAX's marketing [innmax.com] strongly implies that AES encryption is being used for data on disk.
According to the article, when confronted with this situation, INNMAX's response was Cheap Chinese Crap.
Re:How about a software solution? (Score:5, Informative)
In the mean time I'm quite happy with the new 5.0.
Re:Criminal prosecution? (Score:3, Informative)
His point was not the difference between open- and closed-source software but that, just because people can look at the source of open-source software and look for backdoors does not guarantee that someone will find one, if it exists.
Re:Criminal prosecution? (Score:3, Informative)
It's a very spinny article, of course.
The algorithms uses are, by and large, peer-reviewed ones believed to be implemented securely (i.e. 3DES, AES, etc), so thsoe people you know would probably be right on that front (though I obviously can't check the source code myself; this is not an empty "open source is better than X" proclamation, but rather a cold, hard fact in cryptology : if the source is not there to be examined, you can't be sure that there aren't implementation weaknesses that could be exploited. In this field, this is major; for instance, if by some unthought-of chain of events the cleartext encryption key ever gets swapped to disk, the game is over, no need to break the strong crypto itself
By default, EFS stores a copy of the encryption key for the administrator of the machine (or domain administrator if in a domain). In the latter case the recovery key does not reside on the local machine, in the former case it does. This is default behavior. While it's documented, it really should not be DEFAULT behavior. http://support.microsoft.com/default.aspx?scid=kb;en-us;223316&sd=tech [microsoft.com] lists some best practices you should follow for EFS. The first best practice starts with the words "Teach users to". This is a bad idea, no matter what follows.
As I noted, it's
Re:Linux AES better or not? (Score:1, Informative)
According to documents I have read online, the US Government considers AES-256 "good enough" for "Top Secret" level security. The "devil" can still be in the details of the implementation, though. Beware of flaws where information inadvertantly leaks out or is subject to easy brute force attacks. I agree with the statement that "mathematics cannot be cheated." In any case, beware if you set your password as password
On a final note, the above facts probably only come into play for a determined attacker. In the usual case where a laptop has been lost or may have been stolen- most likely for parts or for a quick buck on turn-around, the thief may attempt to see if other "goodies" are easily accessible on the disk. He will most likely just give up when he sees that a total disk encryption solution is in place. Practice safe procedures for more peace of mind.
Re:How about a software solution? (Score:3, Informative)
Re:Criminal prosecution? (Score:3, Informative)
The disk encryption product being discussed would not pass FIPS-140, yet they claimed the use of AES and implied that this meant it was secure.
The comment "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." carries a lot of truth. A vendor that knows what they are doing will know what to tell another security expert sufficient to convince him of the security of the system or algorithms. This would typically include the key management functions, data encryption functions, data integrity functions and compliance to specifications such as FIPS-140.
Re:Linux AES better or not? (Score:2, Informative)
Re:Criminal prosecution? (Score:4, Informative)
NTFS encryption is secure if properly configured (or at least any weaknesses aren't yet known), but it's totally insecure by default, and this lack of security is not at all obvious.