27C3: We come in peace (2010)

We Came in Peace: Event Recordings Available!

It’s only been a few days since the close of the 27c3, but much of the conference is ready to download. Credit goes in no small part to the FEM, who did a really tremendous job during the conference and continue their hard work getting Official Releases of the talks ready to go.

If you enjoyed the streams and the recordings of the talks, consider supporting their efforts to purchase updated equipment to improve the image quality and transmission path for future events.

Did you really love certain events? Weren’t so excited about others? Let us know! You can leave feedback via the Fahrplan. Find the events you’d like to leave your thoughts on and click on the green “Give Feedback” link in the lower right hand corner. We use this information to plan future events, so your input is essential.

Thanks again for a great Congress and we’ll see you at the camp!

Crypto Talk at 27C3: New Key Recovery Attacks on RC4/WEP, Day 4, 17:15, Saal 2

The RC4 Stream Cipher could be the most common stream cipher used on the Internet. RC4 is the only Stream Cipher which is standardized for the SSL/TLS protocol, it is also used for WEP and WPA protected wireless networks. Initially, RC4 was designed to be a closed source commercial product, with the core algorithm kept secret. In 1994, the source code for RC4 was posted on the internet and the algorithm could be analyzed.

The first attack on RC4 was published by Fluhrer, Mantin, and Shamir in 2001. The attack is very effective, but can only be used against certain keys starting with a special sequence of bytes, (for example 3, 255…). This worked perfectly well against WEP, which generates a per packet key using a random initialization vector IV, and a static secret key K. K is kept secret and shared among all nodes in the network. IV is public, and transmitted with every packet in clear. The per packet is key simply the IV concatenated with K (IV | K). We would also say, that there is a correlation between the output of RC4 and a part of the key, if certain conditions apply (the per packet key starts with 3, 255 for example). Many more of these correlations where found later and implemented in a WEP attack tool by a person under the pseudonym KoreK, which made key recovery on WEP protected networks much faster.

The next level of WEP breaking tools was published in 2007, when a new correlation was used against WEP. This correlation had been previously been found by Jenkins and Klein independently, but was never used against WEP so far. The correlation was much weaker than the correlations used in previous attack, but needed effectively no additional conditions, so that nearly every packet could be used to assist key recovery.

Looking at all those previous WEP attacks, one logical idea would be to automate the search for correlations in the RC4 output, which can be used in key recovery attacks. This is exactly the approach taken by Martin Vuagnoux:

In this paper, we present several weaknesses in the stream cipher RC4. First, we present a technique to automatically reveal linear correlations in the PRGA of RC4.

With this method, 48 new exploitable correlations have been discovered. Then we bind these new biases in the PRGA with known KSA weaknesses to provide practical key recovery attacks. Henceforth, we apply a similar technique on RC4 as a black box, i.e. the secret key words as input and the keystream words as output. Our objective is to exhaustively find linear correlations between these elements. Thanks to this technique, 9 new exploitable correlations have been revealed. Finally, we exploit these weaknesses on RC4 to some practical examples, such as the WEP protocol. We show that these correlations lead to a key recovery attack on WEP with only 9,800 encrypted packets (less than 20 seconds), instead of 24,200 for the best previous attack.

One could ask, why one should still try to improve attacks on RC4/WEP. WEP ca be broken in less than a minute nowadays. The successor protocol to WEP, namely WPA TKIP still uses the RC4 cipher in a very similar mode as WEP does. An improvement on WEP attacks could also help us in breaking WPA. Attacking RC4 in SSL/TLS would also be very interesting: Using RC4 in SSL/TLS is very efficient, because it doesn’t need any padding compared to a block cipher and needs less bandwidth than SSL/TLS using a block cipher does. A good attack on RC4 could render SSL/TLS connections insecure.

Personally, I am very interested in this talk, because I worked on attacking WEP in my diploma thesis and the last generation of WEP attacking tools was one of the results of my diploma thesis. The new attack present here will definitely outperform the last generation of WEP attacks and supersedes my results.

See the talk, Day 4, 17:15, Saal 2

Autor: Erik Tews

Hackcenter project: i3

i3 is a tiling window manager, that means it configures your windows to use the whole available screen space. It was written from scratch with focus on clear and well-documented code. Additionally, a lot of documentation like the User’s Guide or a Hacking Howto is available. i3 is fast, easy to use and configure, features full unicode and decent multi-monitor support.

Two of the core developers are traditionally attending the Chaos Communication Congress and are in the hackcenter (the 4-person table in the middle of the hackcenter, watch out for the i3 poster), ready to answer your questions, hack on bugs and cool features and receive club mate along to a nice conversation! :-)

If you already are an i3 user, take a look at our preview release of the next major version and/or ask us for a demo in the hackcenter. Enjoy the 27C3!

Crypto Talk at 27C3: FrozenCache – Mitigating cold-boot attacks for Full-Disk-Encryption software, Day 3, 23:00, Saal 2

Cold BootsAs a general attack against encryption software on a computer, the cold boot attack was presented at 25C3. To encrypt data on a PC, many programs store the encryption key in RAM. The key is usually derived from a password or loaded from the hard disk where it is protected by a password too. The key resists as least as long as the encryption operation take in RAM. For many applications like Full-Disk-Encryption or Email Signatures, it is convenient to keep the key permanently in RAM, once it has been loaded, so that the user doesn’t need to enter his password again and again.

To protect the key from unauthorized access, computers are locked when the legitimate user is away or the computer has been switched to power-saving-mode. To gain access again, the user needs to type a password or needs to identify himself using a fingerprint reader or any other kind of biometric authorization device. Of course, the key is still in RAM for the whole time.

Here, the cold boot attack kicks in. At 25C3, it has been shown that RAM chips (DRAMs) can be easily removed from a running PC, Server or Laptop Computer, and their content can be extracted afterward. Even if the device has just been turned off, the content of the RAM fades only slowly away, depending on the exact type of RAM and its temperature. Even if some bits are recovered incorrectly, the correct encryption key can still be found an corrected, because many cryptographic algorithms use a lot of redundancy in they keys (round-keys for AES for example).

One way to counter the attack could be to store the keys only in the computer cache, instead of RAM. In contrast to the RAM which is a separate device connected to the computers motherboard, the Cache resides on the CPU die, and cannot easily be extracted or read-out. However, caches are hard to control and one needs to make sure that keys are really frozen in the cache and are never written to the RAM:Frozen Cache

Cold boot attacks are a major risk for the protection that Full-Disk-Encryption solutions provide. FrozenCache is a general-purpose solution to this attack for x86 based systems that employs a special CPU cache mode known as “Cache-as-RAM”. Switching the CPU cache into a special mode forces data to held exclusively in the CPU cache and not to be written to the backing RAM locations, thus safeguarding data from being obtained from RAM by means of cold boot attacks.

Personally, I am interested in this talk, because it might be a good solution to use secure full-disk encryption software, without always having to shutdown your computer when you leave it unattended.

See the talk, Day 3, 23:00, Saal 2!

Autor: Erik Tews

Today at 18:30: The concert in Saal 1.


This morning, a concert grand (see photo) was delivered to the stage of Saal one for a special event today: Starting at 18:30 hrs, Corey Cerovsek, Alex Antener and Julien Quentin will be giving a classical concert.

They will be playing pieces from many different composers, including Lennon, Bernstein (Leonard probably; Dan Bernstein can be heard one hour later in the same Saal ;-), Mozart, Liszt and Paganini, to name a few. But there’s more:

In this very concert copyright and public domain issues will be discussed—and a (musical) answer will be given: what would classical music sound like if our modern copyright laws had been in effect two or three centuries ago. Corey, Julien and Alex’s conclusion does not sound very optimistic.

The concert will also be streamed and recorded and available for download for free. However, no recording can substitute the live experience of a good musical performance, so be there, 18:30, Saal 1!

Photo courtesy of alech

Crypto Talk at 27C3: Is the SSLiverse a safe place? Day 2, 16:00, Saal 2

SSL/TLS is the standard when it comes to securing HTTP traffic on the internet. The authenticity of a webserver is usually secured using a X.509 certificate digitally signed by a trusted certification authority (CA). All major webbrowsers come with a list of CAs preinstalled they assume as trustworthy. Every website can be signed by any of these CAs, so no webbrowser would show a warning, if www.dod.gov would be signed by a Chinese certification authority or the Deutsche Telekom.

ObservatoryTo examine the usage of X.509 certificates for SSL/TLS, the EFF installed a SSL Observatory:

The SSL observatory is a project to bring more transparency to SSL Certificate Authorities, and help understand who really controls the web’s cryptographic authentication infrastructure. The Observatory is an Electronic Frontier Foundation (EFF) project that began by surveying port 443 of all public IPv4 space. At Defcon 2010, we reported the initial findings of the SSL Observatory. That included thousands of valid ‘localhost’ certificates, certificates with weak keys, CA certs sharing keys and with suspicious expiration dates, and the fact that there are approximately 650 organizations that can sign a certificate for any domain that will be trusted by modern desktop browsers, including some that you might regard as untrustworthy.

I am looking forward to see some obscure SSL/TLS setups here. For example, SSL/TLS doens’t require the server to present a certificate, connections where no certificate at all are also supported, which only provide security against an passive eavesdropper. Also, the usage of encryption is an optional feature in SSL/TLS, so that both parties may send their traffic in clear, and use SSL/TLS only to prevent unauthorized modification of the data or to prove authenticity of the server. Also, the key in a certificate doesn’t need to be an RSA key, instead some public Diffie-Hellmann parameters or a DSA key might be embedded there too.

Netscape NavigatorFor those of you who would like to know why it is called SSL/TLS: SSL 1.0 was created by Netscape to secure HTTP traffic, but the standard was never released to the public. SSL 2.0 was the first version of SSL released to the public and implemented in the Netscape Browser. SSL 3.0 was the last version of SSL created by Netscape, before the IETF took over development. TLS 1.0 was the first version of SSL released by the IETF, which technically still carriers a version number 3.1 in the protocol header. While there are big differences between SSL 2.0 and SSL 3.0, the differences between SSL 3.0 and TLS 1.0 are only minor. The current version of TLS is version 1.2 (which still carries a version number 3.3 in the protocol header), which contains some security fixes and improvements over TLS 1.0. So we usually say SSL/TLS, when we refer to the SSL or TLS protocol, but not to a particular version of the protocol.

Personally, I am interested in this talk because I conducted a small SSL X.509 survey by myself back in 2007, when I implemented a TLS 1.0 stack in Java for the J2ME plattform. Nowadays, this stack is included in the bouncycastle project, a Java cryptography provider, and can be run on J2ME as well as on J2SE or J2EE.

See the talk at Day2, 16:00 Saal 2!

Autor: Erik Tews

Update on Hash Tags for Peace Missions

To relay a question to the Mission Angels in each talk, use the following Twitter hash tags without dashes:


If you’d like to help, you can sign yourself up for Mission Angel shifts in the Engelsystem. Be sure to check in at the Angel Heaven on the C level for your briefing sheet.