Posts Tagged ‘AES’

It is all about key management

January 7th, 2010

I’ve written in the past about how when encryption fails, key management is usually to blame. You may have seen the news that SySS has figured out how to simultaneously crack open FIPS 140-2 level 2 USB drives from Kinston, SanDisk and Verbatim. If you have not heard about this yet, read on. The crack would be comical if it was not so scary easy.

All the USB drives in question use 256 bit AES to secure the partition. They also use hardware to perform the encryption process. The flaw is in the front end software that performs the authentication. SySS found that when a successful password was entered, a numeric string was sent to the drive to encrypt/decrypt the data. So far, so good. The flaw is that the exact same numeric string is used by all the drives, regardless of password.  In other words, it appears that the same key is always being used to protect every single drive. Create a little software magic to send that string to any of the above mentioned drives, and you will gain access to the data. No knowledge of the password is required, nor is brute forcing. Just send the magick string and “POOF!” the drive is open.
This reminds me of the hack a European group found with a military grade USB drive a few years back. What they figured out is that a successful password triggered a specific pin combination. Trigger the pin with a battery and you have access to the drive.
Of course this creates big problems for the end user community. The marketing material on the drives looks good. They are using the right algorithm, meeting the right NIST spec, and yet the drives are just short of useless. How do you know which drives are actually safe? For me, it goes back to a comment an old mentor once made to me, “bleeding edge and cryptography don’t mix”. Guess the only way to know for sure is to let others vet it for a few years first.

AES is becoming very close to broken

July 30th, 2009

In earlier posts I discussed what’s wrong with WPA and why its always a bad idea to base a standard around a single method of encryption, even AES. Bruce Schneier posted to his blog today regarding a new attack against AES. In short, the paper he references identifies how to dramatically reduce the number of guesses required to retrieve a key. While its not practical today for a basement hack to perform the attack, its still nasty stuff.

The attack in question is what is referred to as a related key attack. This requires the attacker to have some level of knowledge of the plain text secured by multiple related keys. In other words, we need to already know a bit of what is being protected and where to look for it.

This is a serious problem when you are talking about VPNs or wireless, because we are using it to secure IP traffic. IP uses some pretty consistent values:

  • Byte 0 contains the IP version (usually 4) and the size of the IP header (usually 20 bytes)
  • Byte 1 contains the type of service field (usually not used so set to 0)
  • Bytes 2 & 3 contain the total length field (a consistent value for traffic like ARP packets if you know the OS)
  • Byte 8 contains the TTL (a consistent value on a per OS basis)
  • Bytes 12-15 contain the source IP address (a consistent value for each specific system)

And that’s just the IP header…

So when we protect traffic on the wire, related key attacks can be particularly evil because there are many repetitive values to work with.

So what should you do? I’ll fall back on the same advice I gave in those earlier posts I referenced above. Make sure you have more options than just a single encryption algorithm, just in case things get a whole lot worse.