27c3 wrap-up

31.12.2010 17:01

The 27th Chaos Communication Congress ended yesterday in Berlin. This year I flew there with a small group of fellow hackers from Kiberpipa. As I'm writing this we're waiting for our airplane to land in Klagenfurt, having yet again successfully survived the dangerous conditions on the congress network and -22°C on the streets of Berlin.

Berliner Congress Center during 27C3

It was busier than usual so I didn't manage to blog about day to day happenings like on my previous visits. However this doesn't mean that I wasn't doing and learning anything interesting there. On the contrary, compared to the previous years there was much more talking, coding, lock-picking (no soldering though) and less sleeping. I have a backlog things I would like to write about and most likely there will be a trickle of blog posts about them in the near future (depending on the backlog of things waiting for me at home and/or office) as I gradually convert my notes to something presentable. I'm pretty sure you got up-to-the minute reports of the most earth-shattering revelations through other channels.

As it is usual for the last few years the Berliner Congress Center was packed to the top. I guess the amount of congestion in the halls, saals and on the various wired and wireless (GSM, DECT and 802.11ab) networks was about comparable to 25C3 and I heard it was less crowded as 26C3 (I skipped the congress last year, so I can't say first hand). If not by that, the new ticket pre-order certainly had a noticeable effect on the waiting time to get the wrist-band entry permit. I don't think we waited longer than 5 minutes even though we were in the queue just 30 minutes before the keynote, most probably at the peak of the in-rush. Despite that the pre-order system was lovingly named pre-fail due to all the problems it had (not that I noticed thanks to lowk3y who got the tickets without the rest of us having to care about the 5 minute window in which the tickets were sold-out).

The organizers seem to be increasingly conscious of all the safety measures necessary on an event this size (around 3000 people or hundred percent capacity of the BCC). Saals were closed off when they were filled to capacity, special procedures were in place during the breaks so people were moved efficiently in and out of the rooms. I also keep wondering if the distinct lack of power sockets this year had something to do with keeping to the electrical safety codes.

Nick Farr at the 27C3 closing events.

In general the motto "we come in peace" came true. The closing event was quite unusual in that there were hardly any reports from the Network Operations Center about such and such attacks taking place from the congress networks or angry mails coming to the abuse email address. A paranoid person my say they were left out since the frequency of loud cheers in early morning hours was still quite high in the Hack Center. Or perhaps people took to their hearts the message from Rop Gonggrijp's keynote address who hoped most attendees have reached the level of ethical maturity where they see such actions as unacceptable.

Concerning the talks, here is a random selection of the few most memorable from the top of my head: ACTA (Jérémie Zimmermann of LQDN) and data retention in Europe was quite well covered, the latter even with a workshop. Talks about GSM and mobile technologies, from smart phone OSes to baseband processing probably had the most impact - topped by the Karsten Nohl's live demonstration of GSM voice eavesdropping. Plenty of hardware topics, from RFID to printable electronics (hacked 21 EUR printer that prints PCB masks in hot wax) and MOS 6502 reverse engineering (Michael Steil of pagetable.com). I guess you could also put the Lepht Anonym's Cybernetics for the masses talk in the hardware bag. Or is that wetware? Crypto covered new attacks on RC4/WEP, chip and PIN systems (go see Steven Murdoch's talk if you think modern smartcards are resistant to abuse). From the general security point of view there's the PDF is the new flash argument from Julia Wolf and Microsoft's adventures in analyzing Stuxnet. Last but not least, Annalee Newitz' view on the future of journalism was also very interesting.

So, to wrap it up: had a wonderful time, attended more than my usual share of talks from the society track, met a lot of people and observed that the lack of sleep and amount of social interaction are positively correlated.

Posted by Tomaž | Categories: Life | Comments »

Scary exercise

26.12.2010 21:19

Try this on a computer you use often:

# export HISTFILE=/dev/null
# grep secret /dev/sda /dev/sdb
Binary file /dev/sda matches
Binary file /dev/sdb matches

Substitute secret for a secret password that should never be stored in clear text in any persistent storage. For instance your system account password, disk encryption key, GPG private key passphrase, etc. Note that entering your secrets on the command line like that has dangers beyond Bash history logging, so it's only safe to do this experiment with a password that you just changed.

If grep returns no hits, great. Your secret is safe from this particular attack. In my case however the fun part was in finding out why exactly the password that supposedly never leaves volatile RAM appeared in clear on all of the computer's hard drives (and the machine in question doesn't even have swap enabled).

Posted by Tomaž | Categories: Code | Comments »

dm-crypt on Eee PC 901

19.12.2010 20:23

After making sure my data wouldn't be more vulnerable to disk failure I decided to use dm-crypt to encrypt the partition holding my home directory on Eee PC 901.

I'm leaving the root partition unencrypted for now and I only encrypted the second, 16 GB built-in SSD drive that I mount as my home directory. It's LUKS formatted using default settings (128-bit AES). I'm using pam-mount to mount the drive at login-time.

Setting this up following examples in README.Debian in libpam-mount package was mostly painless. The only problem I encountered was the fact that libpam-mount is slightly broken in Debian Lenny and required the following small fix to the mount.crypt utility to be actually able to mount encrypted drives:

--- libpam-mount-0.44.orig/scripts/mount.crypt	2010-12-18 19:30:27.000000000 +0100
+++ libpam-mount-0.44/scripts/mount.crypt	2010-12-18 17:21:16.000000000 +0100
@@ -57,7 +57,7 @@
 		exit 0;
 		;;
 	(-o)
-		OPTIONS="$2";
+		OPTIONS="${2/# /}";
 		shift 2;
 		;;
 	(--)

The GNOME Desktop behaves a bit weird with this setup and I now have two icons for the encrypted partition on my Desktop. Annoying, but not a show-stopper. Also at one point I saw it automatically mount an USB key that had a LUKS password identical to my system password without a password prompt, but later on that stopped working. I'm not quite sure what happened.

Finally, here are some timings of common operations before and after I encrypted the home partition:

Operationbeforeafter
Boot (power on button to GDM prompt)24 s24 s
Login (enter key on GDM prompt to icons appearing on the desktop)5 s8 s
Firefox 3.5.15 fresh start after boot5 s6 s

Login takes a little longer. That is expected, as pam-mount takes a while to mount the partition and run fsck on it after password entry. That was previously done on boot and probably in parallel with some other process as boot time stayed the same.

Kernel compile timings:

$ time CONCURRENCY_LEVEL=2 fakeroot make-kpkg kernel_image

# before
real	112m43.709s
user	154m26.811s
sys	10m33.868s

# after
real	125m56.766s
user	153m23.283s
sys	10m16.099s

The difference in wall-clock time is around 10% - noticeable, but not really significant. What is puzzling here is that user and system times stayed approximately the same - I would expect the CPU time spent on encryption to be added to system time row.

Posted by Tomaž | Categories: Code | Comments »

Resistance of dm-crypt to corruption

11.12.2010 23:15

Recently I've been thinking about using dm-crypt to encrypt partitions on my computers. As mulaz writes, portable devices like flash drives and laptops are getting physically smaller and logically larger. The former makes them easier to lose or get stolen while the latter increases the possibility that they contain something valuable. I've been using LUKS to format my USB flash drives for a while now. I've been pleasantly surprised that the GNOME desktop will recognize, prompt for password and mount them automatically.

Two years ago Phoronix found out that disk encryption on contemporary hardware has negligible effect on performance. On the other hand EeePC 901 didn't fare that well (also, I wonder what the impact on battery life is?). In 2010 the overhead of encryption should be even smaller.

One thing I've been wondering about is how an encrypted volume behaves when data on the storage device gets corrupted (bad block, odd cosmic particle, etc.) Is it all-or-nothing like file compression, where you loose the entire file if only a part of it gets corrupted? Encryption is done in blocks so in theory only the blocks touched by corruption on the device level should be affected after decryption.

To test that theory I made two 2 GB files with ext3 filesystem on them and mounted them via the loopback device. One was encrypted with dm-crypt (default settings) and the other was left unencrypted. Then I copied some random data to them and ran the following script. It incrementally zeros 64 kB blocks at random locations on the block device and compares file contents with the original. It stops at the first sign of trouble.

#!/bin/bash

set -e

SIZE=2147483648
BLOCK=$(($SIZE/32768))
FILE="encrypted_damaged"
#FILE="plaintext_damaged"

N=0
while true; do
	OFFSET="$RANDOM"

	echo "Writing $BLOCK bytes at $OFFSET to $FILE" >> log
	tail -n1 log

	dd if=/dev/zero of="$FILE" bs="$BLOCK" count=1 seek="$OFFSET" conv=notrunc

	losetup /dev/loop0 "$FILE"
	cryptsetup --key-file=password create test /dev/loop0 
	mount /dev/mapper/test /mnt
	#mount /dev/loop0 /mnt

	diff --brief /mnt/linux-2.6.34.7.tar.bz2 linux-2.6.34.7.tar.bz2
	diff --brief -r /mnt/linux-2.6.34.7 linux-2.6.34.7

	#umount /dev/loop0
	umount /dev/mapper/test
	cryptsetup remove test
	losetup -d /dev/loop0

	N=$(($N+1))
done

As expected, both plain and encrypted volumes behaved in the same way. In most cases corruption only caused file contents to silently change. When it touched filesystem structures a fsck was necessary, but the success rate on plain and encrypted volumes was pretty much similar. From what I've seen encrypted volumes don't seem to be any more vulnerable to corruption than otherwise.

Of course, this is only anecdotal evidence: I only did a couple of runs to convince myself that my understanding of how dm-crypt should behave is correct. Also note that plain dm-crypt volumes used here are different from LUKS formatted volumes - those have a header that holds some vital parameters for the encryption algorithm and from what I heard once that header is lost you can say goodbye to your data.

Posted by Tomaž | Categories: Code | Comments »

Slow turn-on

08.12.2010 22:05

Continuing on the topic of thyristors, here's an interesting graph I just measured:

SCR anode-cathode voltage versus current

This is path anode-cathode voltage and current make on the I(U) graph during a single commutation cycle. The blue part of the plot is during the switch-on and the red part is during switch-off. Each dot represents a sample (sampling period was 10 μs)

Interesting thing to note here is that this graph shows the slow turn-on. Ideally the blue line should not deviate too much from the red one. The slowly rising line on the right means a considerable current flows through the device while there's still a large voltage drop on it, causing increased heat dissipation. This happens because after the gate pulse not all surface of the junction gets turned on at the same moment.

The second useful thing this graph shows is the magnitude of the voltage drop of the two PN junctions (around 1 V, quite low actually) and the equivalent series resistance (around 80 mΩ). These two components help determine the safe operating area of the device: the dissipated power on the constant voltage part depends on the average current value while the resistive part is sensitive to the RMS value.

Posted by Tomaž | Categories: Analog | Comments »

xmllint and DTD caching

03.12.2010 20:10

Back in 2008 W3C published a blog post complaining about the hundred million requests their servers get per day for HTML Document Type Definitions and other files you usually find referenced at the top of valid web pages. The main point of the post was that these files should be cached, not continuously retrieved by various validation tools from their site, since they never change. I'm sure these two years have added another order of magnitude to their web statistics.

Anyway, some days ago I wanted to validate a large number of XHTML+RDFa documents and I wrote a simple shell script that ran xmllint on each of them. It ran much slowly than I anticipated and in the end I found out that xmllint will request a fresh copy of 38 DTD files for each document it validates. It does that even if you specify multiple documents on the command line. If the most authoritative XML validation tool I know behaves in such a blatant disregard of HTTP caching standards I can see how W3C manages to use hundreds of Mb/s of bandwidth.

The bright side is that there is a standard for specifying local copies of external XML entities. It's called XML Catalog and xmllint honors it.

On Debian systems there's a w3c-dtd-xhtml package that will install a local copy of W3C DTDs. However it only covers XHTML 1.0 and 1.1, it's on the brink of being orphaned and its XML cataloging system is so complicated that after an hour I did not find a way to supplement it with the XHTML+RDFa DTDs.

In the end I found a simpler way:

First make a local copy of required DTDs. Running xmllint on a sample file while using tcpdump and some grepping to capture GET requests on W3C's servers got me the list of files required. A recursive wget did the rest. In the case of XHTML+RDFa that meant mirroring the content of http://www.w3.org/Markup and http://www.w3.org/TR/ruby (don't ask) to a local directory.

Then create a catalog.xml with the following:

<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS/DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
	<rewriteSystem systemIdStartString="http://www.w3.org/MarkUp" rewritePrefix="file:///path_to_MarkUp/" />
	<rewriteSystem systemIdStartString="http://www.w3.org/TR/ruby" rewritePrefix="file:///path_to_TR/ruby/" />
	<nextCatalog catalog="/etc/xml/catalog.xml" />
</catalog>

This simple XML catalog simply redirects requests for resources under the given URL prefixes to the mirror on the local filesystem. It also points any unknown requests to the system's XML catalog file.

Using this setup, the xmllint can be used with the following command line:

$ XML_CATALOG_FILES=catalog.xml xmllint --valid --noout --nonet file_to_validate.xml

--nonet flag is there so that xmllint throws an error if there's still something it needs to fetch over the internet.

Needless to say, this manual procedure is unreasonably time consuming when all you want is make sure a bunch files are valid. It starts to make sense when a local DTD copy reduces the run time from days to minutes. Plus you get the warm feeling you're not breaking the internet. However I think there's no excuse that such a broadly used tool as xmllint doesn't have some kind of a cache built-in, even if it's only for the time of running a single xmllint instance.

Posted by Tomaž | Categories: Code | Comments »