Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Encryption Security IT

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.
This discussion has been archived. No new comments can be posted.

Cracking a Crypto Hard Drive Case

Comments Filter:
  • 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.
  • by corsec67 ( 627446 ) on Tuesday February 19, 2008 @02:52AM (#22472110) Homepage Journal
    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.
  • by blackwing0013 ( 680833 ) on Tuesday February 19, 2008 @03:00AM (#22472156)
    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.
  • Manufacturer link. (Score:3, Informative)

    by palegray.net ( 1195047 ) <philip DOT paradis AT palegray DOT net> on Tuesday February 19, 2008 @03:03AM (#22472174) Homepage Journal
    Here's a link to the manufacturer's website [easy-nova.de]. Why don't we all ask them what they were thinking?
  • Take a look at this publication [google.com] on an open source cryptographic coprocessor. Sorry about the PDF format.
  • by kiltyj ( 936758 ) <[moc.liamg] [ta] [jytlik]> on Tuesday February 19, 2008 @03:28AM (#22472280)
    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.
  • by Woek ( 161635 ) on Tuesday February 19, 2008 @03:48AM (#22472354)
    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.
  • by pipatron ( 966506 ) <pipatron@gmail.com> on Tuesday February 19, 2008 @04:41AM (#22472542) Homepage

    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.

  • by this great guy ( 922511 ) on Tuesday February 19, 2008 @05:58AM (#22472864)

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

    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.

  • by Viol8 ( 599362 ) on Tuesday February 19, 2008 @08:46AM (#22473624) Homepage
    "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.
  • by msauve ( 701917 ) on Tuesday February 19, 2008 @08:47AM (#22473638)
    although they perhaps didn't do due diligence.

    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

    The IN7206 merely uses AES encryption when saving the RFID chip's ID in the controller's flash memory. The company explained that actual data encryption is based on a proprietary algorithm. The company claims the IM7206 only offers basic protection and is designed for "general purpose" users.
    Cheap Chinese Crap.
  • by Teun ( 17872 ) on Tuesday February 19, 2008 @09:04AM (#22473706)
    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.
  • by ThinkingInBinary ( 899485 ) <<thinkinginbinary> <at> <gmail.com>> on Tuesday February 19, 2008 @10:08AM (#22474248) Homepage

    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.

  • by mxs ( 42717 ) on Tuesday February 19, 2008 @10:56AM (#22474806)
    From the horse's mouth, actually : http://www.microsoft.com/technet/archive/security/news/efs.mspx?mfr=true [microsoft.com]

    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 /possible/ to make EFS reasonably secure.
  • by Anonymous Coward on Tuesday February 19, 2008 @12:00PM (#22475502)
    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.
  • by SirTalon42 ( 751509 ) on Tuesday February 19, 2008 @12:30PM (#22475864)
    Trust Crypt uses a kernel module (entirely software solution). It isn't a USB device.
  • by TechyImmigrant ( 175943 ) * on Tuesday February 19, 2008 @01:47PM (#22477082) Homepage Journal
    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.

  • by goodtrick ( 1201109 ) on Tuesday February 19, 2008 @05:04PM (#22480104)
    just FYI http://mareichelt.de/pub/texts.cryptoloop.php?alt_styles=2 [mareichelt.de] talks about the shortcomings of the original cryptoloop. AFAIK, truecrypt, loop-aes and the new dm-crypt/LUKS solves these issues.
  • by lgw ( 121541 ) on Tuesday February 19, 2008 @05:45PM (#22480618) Journal
    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.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...