Posts Tagged ‘Talks’

The final 30c3 schedule is going to be late, we know… however, please stay tuned, as it’s still work in progress, and we can promise the Fahrplan will be awesome!

We’d like to tell you about some of the security highlights at 30c3. There are three major groups of interest this year:

Cryptography

Hardware & Embedded Device Security

Software & Protocol Reverse Engineering

First, let’s start with a cryptography highlight: Nadia Heninger, Tanja Lange and Daniel J. Bernstein will be presenting “This Year in Crypto”. They will cover stuff that was broken before and continues to be broken again and again. The talk will also cover the coming Cryptopocalyps, backdoors in cryptographic implementations and the authors’ worries and concerns in regard to crypto in general. It’s worth mentioning that they initially recommended that their talk should be part of the Art & Beauty Track, since crypto is beautiful (and finessing crypto is an art).

Another cryptographic highlight this year is a lecture by Dmitry Khovratovich who’s going to talk about White-Box Cryptography. He’s going to explain the differences between White-Box & Public-Key Cryptography and obfuscation. This will include an overview of the white-box crypto concept along with the most common applications and proposed designs.

The Hardware & Embedded Security track will also feature several noteworthy lectures this year. Due to the outstanding quality of the submissions, it’s difficult to mention just a handful of talks. However, we’d like to highlight the following ones:

Console Hacking 2013 – It’s the year of the Wii U. This talk will cover improvements made in the architecture over previous console generations. Still, its security system was completely bypassed, and the authors will show how the Wii U was broken in less than 31 days. You’ll be able to reproduce all of the presented attacks at home – if you bring basic knowledge of embedded systems and CPU architectures.

Staying on the topic of Embedded Security and Embedded Privacy, Martin Herfurt will be presenting his research on Hybrid broadband broadcast TV (HbbTV). This is the new de-facto standard, which is currently being rolled out around the world. This new standard raises several security and privacy concerns. Martin will cover the emerging standard and how to deal with those security & privacy concerns.

Dr. Peter Laackmann will be covering the last 25 years of smartcard hacking (in German). This will be a rather entertaining talk with many crazy IC analysis techniques that you don’t want to miss – even if you’re not that much into technical details of chip-card hacking (or German).

As already mentioned, there is a substantial number of excellent hardware-security related talks this year. To keep the blog post short, here are just a few more that deserve to be mentioned:

Dmitry Nedospasov will be presenting his approaches on physical attacks of ICs’ backsides,

Adrian Dabrowski is going to introduce you to the RFID Treehouse of Horror, and how to hack city-wide access control systems.

Though it’s difficult to categorize the remaining submissions, they include Software and Protocol Reverse Engineering as well as any remaining software security related topics.

Jan Schejbal and his colleagues reverse engineered one of the implementations of the CHIASMUS cipher, designed by the BSI (Bundesamt für Sicherheit in der Informationstechnik). This work will not only reveal insights on the non-public CHIASMUS-cipher, but also uncover serious implementation issues in the “official” GSTOOL. The implementation issues allow an attacker to crack files that have been encrypted with GSTOOL with very little effort.

Also worth mentioning: Collin Mulliner’s “Dynamic Dalvik instrumentation of Android Applications and the Android framework” as well as Andreas “Bogk’s Bug Class Genocide”. Ilja van Sprundel will try to debunk the greatness of a well known open-source project: the X11 or X.org code.

tldr:Congress is made by you! Please add your workshop. A “workshop” is just something, that happens at a special time and place, but not in one of the big halls.

As you may have read in the blogpost on assemblies this congress will be even more community driven than it used to be. One step towards this is allowing you to hold your own sessions on whatever topic you think is important. We kindly ask you to prepare “workshops”.

That does not mean, that it has to be something with hands-on and making – sure it could be! But workshops can also be a gathering of a project group or discussing a special topic. They can be contests or games, activies outside of the building or even small talks, a follow-up-discussion on one of the “big talks” or any other topic that happened rencently – or something completely different that you think deserves a place at the congress!

For workshops we will have four fixed places, and maybe some more dynamic space at your assembly. The rooms are:
* workshop 12, with 60 square meters
* workshop 13, with 78 square meters
* workshop 14, with 60 square meters
* and the speaker’s corner, that is an open space close to hall 1 and the main foyer.

You know someone who could tell us interesting things at the congress? You recently read an article and thought “It would be great to hear that person speak at the congress”? But you are not sure if he/she/it knows about it? Then just tell them!

There are many ways to do that, the easiest one would be sending an email like this:

“Hey [name], I like your [article /talk/project/something] and I would love to see you at the 29th Chaos Communication Congress. You can find the Call for Participation here: [link]. If you need any help with the submission form I would be happy to assist you. Be aware that the submission deadline is September 30th!”

Of course it would be much nicer if you wrote some more:
You could write some words about the congress: you can use the Wikipedia entry or the older congress pages for copypasta. It will be even nicer if you find your own words. You can also point out that a lot of great people have spoken at the last editions of Chaos Communication Congress, and this would be a good opportunity to be listed on the same page with those people ;)

Please make sure that the speaker does not get the impression that you are from the content team or that you are issuing an official invitation.

You could also write to 29-content@cccv.de and suggest a speaker. Tell us something about him/her and how great it would be to have them! Give us links to talks he/she held and just everything we should know to invite him/her.

As 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:

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.

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.

To 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.

For 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.

The new national id card Neuer Personalausweis (NPA) was one of the biggest IT projects in the German government in the last years. Compared to the old id card, the new id card is a RFID smart card, which can also be used on the internet to prove your identify to a remote party (Ebay, Paypal, or Amazon for example) and to sign binding contracts. For example, you can use the card to buy a new house or car, or open up a bank account or apply for a credit.

When using the card over the internet, the card is connected to a reader, which is connected to a (potentially insecure) PC, which is connected to the internet. To use the card, the user needs to enter his PIN code to prove possession of the card and knowledge of the PIN. If the PIN is entered on an insecure device as the PC, it might be recorded by an attacker and used by him later.

Frank Morgner and Dominik Oepe examined the various attack scenarios on the NPA, which could be possible, depending on the used reader for the NPA:

Personally, I am interested in this talk, because it might show us some nice attack scenarios on the NPA, which are hard to counter, without buying very expensive readers. A lot of low-cost readers have just been distributed by a well known computer magazine in Germany, so that we can assume that a lot of people will be using their NPA with a highly insecure reader.

Many applications, including closed source applications like malware or DRM-enabled multimedia players (you might consider them as malware too) use cryptography. When analyzing these applications, a first step is the identification and localization of the cryptographic building blocks (cryptographic primitives, for example AES, DES, RSA…) in the applications. When these blocks have been localized, the input and output of the cryptographic primitives and the key management can be observed and the application can be analyzed further. Fortunately, many cryptographic algorithms use special constants or have a typical fingerprint and there are only a few different public implementations of the algorithm. This allows us to automate this first, Felix Gröbert will show us how:

Using dynamic binary instrumentation, we record instructions of a program during runtime and create a fine-grained trace. We implement a trace analysis tool, which also provides methods to reconstruct high-level information from a trace, for example control flow graphs or loops, to detect cryptographic algorithms and their parameters.

Because the program is analyzed at runtime, it is immediately known which parts of the code are used at which time, so that they might be correlated with runtime decryption of the code or with network communication.

Inputs and outputs of the primitives as well as the keys are recorded, even if the originate from a remote server or botnet. This allows us to immediately distinguish between long term keys and session keys, if multiple executions of the same program can be recorded.

This is also highly interesting if private keys are included in an obfuscated binary, for example private RSA keys.

Dead or unused code is automatically excluded, so that one can proceed with the main parts of the code first.

If additional code is loaded from a server, it is included in the analysis. This would be hard to impossible using static analysis.

Of course, trace driven analysis has it disadvantages, for example if a malware needs to communicate with a command-and-control server, which has already been taken down or behaves differently on different systems or at different times.

Personally, I am interested in this talk because it might make ease up the analysis of closed source applications using cryptography. Even if the application, the DRM scheme, or the cryptographic primitive has no special weaknesses or bugs, just he recording of every input and output of all cryptographic building blocks in the application might be sufficient to extract a DRM free version of DRM protected digital content. Please also note that even if an application uses only well analyzed cryptographic primitives as AES and RSA, it might still be insecure, if these primitives are used in the wrong way.

The HHA is open to everyone and open the entire congress! Hackers of all ages and skill levels are welcome! Round-the-clock hands on workshops will be led by lots of experienced teachers like Mitch Altman, Jimmie P. Rodgers, fbz, Wim Vandeputte and…you!

Learn to solder, then help teach others! Make cool things with electronics, design and print 3D models on the Makerbot, break RFID, or give your own workshop on the projects you’ve been hacking on this year. Last year there was a Cantenna workshop, a Mikrocopter workshop, and a GSM workshop among many others.

Lots of kits for you to make will be available including Brain Machines, TV-B-Gones, Trippy RGB Waves, Mignonette Games, LEDcubes, LOL shields, Atari Punk Consoles…and there’s always room for yours!

To accommodate all this hardware hacking goodness, the HHA will be twice the size it was during the 26c3, but still conveniently located near the Hackcenter.

Even if you don’t have a ticket to Congress, you can stop by the HHA with a Night Pass good from Midnight to 6 AM. Night passes are only €5 and will be sold shortly before midnight each day of the 27c3.