Slashdot Mirror
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.
Yet another reason to encrypt your entire hard-drive with Linux in addition to hardware based encryption. Wish I knew enough to tell if it was working, though. Sure without the keys my hard-drives seems unreadable, but I am not a crypto expert.
"Where have all the good people gone?" - Jack Johnson
XOR doesn't immediately mean that it is a crappy form of encryption. One Time Pads 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 also use XOR, but are much more convenient to use and could very easily be used to encrypt a hard drive.
If I have nothing to hide, don't search me
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.
Here's a link to the manufacturer's website. Why don't we all ask them what they were thinking?
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
Take a look at this publication on an open source cryptographic coprocessor. Sorry about the PDF format.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
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.
c++;
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.
"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."
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.
They used a chipset from INNMAX, the IM7206, believing it provided AES encryption to data. INNMAX's marketing strongly implies that AES encryption is being used for data on disk.
According to the article, when confronted with this situation, INNMAX's response wasCheap Chinese Crap.
"National Security is the chief cause of national insecurity." - Celine's First Law
Nothing stops you from using version 4.3. Even when you think you need a GUI, there are several available.
In the mean time I'm quite happy with the new 5.0.
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
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.
ttuttle is a rankmaniac
From the horse's mouth, actually : http://www.microsoft.com/technet/archive/security/news/efs.mspx?mfr=true
...)
/possible/ to make EFS reasonably secure.
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 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
Encrypted devices (a hard drive, in your case) have gone through several generations in the Linux kernel. The device mapper facility is the latest incarnation and (presumably) the one which should be used to avoid known pitfalls. This next generation replaces cryptoloop. Device mapper can be setup for backward compatibility with cryptoloop, but most security experts recommend sacrificing backward compatibility in the name of better security. For example, the luks-cryptsetup program will do various forms of hashing on a initial passphrase, and also setup the device to perform better hashing using the so-called "initialization vector." As far as I can tell, the problems with the previous design have to do with dictionary attacks which assume a predictable hashing function. The problem was never with the specific encryption algorithm which the user had elected to use (aes, serpent, twofish, etc.)
;)
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.
Trust Crypt uses a kernel module (entirely software solution). It isn't a USB device.
You are mistaking AES for FIPS-140.
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.
Evil people are out to get you.
just FYI http://mareichelt.de/pub/texts.cryptoloop.php?alt_styles=2 talks about the shortcomings of the original cryptoloop. AFAIK, truecrypt, loop-aes and the new dm-crypt/LUKS solves these issues.
NTFS encryption allows encrypted files to be decrypted by either the owner or a designated "recovery account". This makes good sense in a business setting, and is not per se a bad design. However, the default recovery account on a system that doesn't belong to a domain is the local Administrator account. This was a horrible design mistake because all local Administrator accounts are equilavent in Windows - you can move the hard drive to any system where you know the local Administrator password and "recover" the encrypted files.
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.
Socialism: a lie told by totalitarians and believed by fools.