Highlights of the Real World Cryptography 2014 workshop, day #2

The 2014 edition of the Real World Cryptography workshop was held last week in New York, hosted by the City College of New York. Here are some personal highlights of day #2 (I have not included a summary of all talks, and do not pay an equal amount of attention to all talks). Day #1 (which was much more interesting in my opinion) can be found here. Day #3 is here.

Tuesday, January 14

Session 5 was dedicated to Opacity (a smart card dedicated protocol for key agreement based on Diffie-Hellman). I didn't hear anything of interest to me here.

Session 6

In this session, Tom Shrimpton (Portland State University) described Format-Transforming Encryption and how it can be used to circumvent censorship.

Many Deep Packet Inspection systems (including China's Great Firewall) appear to use regular expressions to determine which protocol is used for a particular connection. This is used to detect whether, for example, encryption is used to hide the contents of the communication, or to detect whether say FTP is tunnelled over an SMTP connection, say. To fool such systems, you have to create traffic that looks like the protocol expected (and passed) by the DPI filter, while it actually encapsulates encrypted traffic using a different protocol.

This is what Format-Transforming Encryption does. It has three inputs: a plaintext, a key, and a regular expression that describes (a subset of) the messages of a particular protocol. It encrypts the plaintext with the key (using authenticated encryption), and then uses the resulting ciphertext as an index in the language of messages generated by the regexp. This message (which looks innocent to the DPI system) is sent to the receiver that recovers the index given the message, and decrypts the result with its key. They tested the result on China's Great Firewall and managed to stay undetected browsing Facebook and using Twitter for a few months (until they stopped the experiment).

For certain DPI systems, the level of success depends on the regular expression used. Ideally you use the same regexp as the DPI system itself uses for detection. Interestingly enough, the only commercial DPI system they tested (they gave no name...) passed all traffic independently of the regexp used. They initially thought they misconfigured something ;-)

Session 7: Cryptographic Implementation

Dave Anderson (Seagate) talked about the architecture of self-encrypting hard drives.

These drives contain an ASIC that always encrypt data written to the drive, given a data encryption key (DEK) that never leaves the drive. The DEK is stored on an otherwise inaccessible part of the drive itself, encrypted against an authentication key (AK) that must be sent to the drive when it is powered up. The disc also contains some pre-boot image that will ask the user for this AK.

The drive contains a random number generator that uses signals derived from the media in the drive. Multiple DEKs are possible, for different sections of the drive. Additional functions are possible, for example setting up a secure channel with the hard drive directly from outside.

Interesting piece of information: Seagate produces 10 hard drives per second.

He was met with quite some scepticism during the Q&A. There is a hidden key embedded in the device for additional security. Dave didn't want to tell what that was used for. He insisted there were no backdoors but added "If I were you I wouldn't believe me either" which resulted in quite a bit of laughter (for a change; most of the time people were perhaps a bit too serious during the workshop).

Someone suggested that it would be useful to have raw read access to the blocks to verify that the encryption is indeed done correctly (although you'd need to have the key for that as well). Seagate does not provide this raw access.

Session 8: short presentations

I skipped this session.