Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: encryption

26C3: Cryptographically Secure ? (lightning talk)

Cryptographically Secure ?
Cracking FIPS-Certified USB Flash Drives
Lightning talk – PoC – Matthias Deeg

Demo is performed using a SanDisk Cruzer Enterprise (FIPS Edition), however is possible on other devices.

  • Small mistakes often have a big impact, especially when it comes to complex devices.

USB FDU – (USB Flash Drive Unlocker)

The demo PoC tool was able to unlock the device (make it so that any arbitrary password works) within a few seconds. A number of vendors have already patched this issue and provided updates for their devices (see Links below).

Currently the PoC isn’t publicly available.

Links :

Advertisements

Upcoming DECT Talk

For those of you that follow my insane ramblings no a regular basis might just remember some posts I’ve made about DECT interception. As part of my ongoing interest in this area I’ve been keeping an eye on the dedected.org site and the researchers responsible for reversing parts of the DECT standard. Although not much has moved since the December 2008 software release and initial research, RalfPhilipp Weinmann (University of Luxembourg) will be making a presentation at the upcoming EUSecWest 2009 in London (27/28 May). The talk, entitled Efficient UAK Recovery attacks against DECT”, seems to hint at possible advances to the project. The UAK (User Authentication Key) is a 128bit key used in the pairing process to Authenticate the PP (Portable Part). Although this isn’t the point we’ve all been waiting for (an attack on DECT Standard Cipher), it does represent the next step forward and could open the door to easier Man in the Middle type attacks. It could also allow attackers to connect to internal DECT systems and route calls through internal call switches. Great for free calls, social engineering, or maybe gaining access to restricted services (modems on listening on internal extensions, voicemail systems, etc..). At the moment this is all speculation however. It’s a pity I can’t be at EUSecWest (I’m already doing too many conferences this year). However I’ll be keeping an eye on the slides as soon as they’re made public.

At present the dedected.org team have released software that allows for capturing unencrypted DECT telephone calls only. This doesn’t mean that encrypted calls can’t be captured, it simply means that they cannot currently be decoded into anything that makes sense. There is the chance the previously captured encrypted calls could be attacked and decoded in the future.

That not withstanding, I doubt that the dedected.org team will be releasing anything new to decode encrypted traffic in the short term. At this stage they’ve already exposed the weaknesses in DECT, and without a solution to the issue, releasing a tool that captures and decodes encrypted traffic would only put individuals and companies using encrypted DECT in danger. That’s not to say their won’t be something in the mid to long term.

To prevent exposure, companies should start looking (if they’ve not already started) at alternative options to DECT telephones and headsets. VoIP seems like a viable alternative if it’s implemented over VPN or other secure channels. Only time will tell if this is the direction that people head however.

Truecrypt rushes out version 6

It seems like the guys behind Truecrypt managed to sneak out version 6 without many people noticing. I’ve not had a chance to look at the new version, but hope that they’ve made some improvements on it from version 5. A lot of people were disappointed with some of the changes made to Truecrypt between version 4 and 5. There were speed issues and a lot of Linux distributions stuck with the 4.3 release (i.e. Backtrack). Although personally I found version 5 to be suitable for my needs, I was a little disappointed in the lack of command line for windows. This gave me no end of problems when I wanted to script a password guesser and found my example Truecrypt volume (encrypted on version 5 naturally) fails every time when using the version 4.3 under Linux. The error message is suitably vague, saying the password is wrong or it is not a Truecrypt volume. I understand the need for vague responses in order to give deny-ability to the user, but still, it wasted a lot of computer cycles before I figured that one out. My fault for not reading the fine manual (RTFM).

Version 6 apparently deals with some of the speed issues by adding support for multiple CPU cores. Which is a fine addition if it works across Windows and Linux versions. I’ve not seen any mention of support for Smart Cards or tokens as encryption keys, but it’s something I’ve been hoping for in Truecrypt for a while now. That as well as a full disk encryption option that works for Linux as well as Windows systems. Hopefully I’ll have time to play with it soon and see what if anything it can provide over and above version 4.3 or 5.1