proprietary MiFARE [in]security finally falling

At a presentation entitled "Mifare - Little security, despite obscurity" at the 24C3, Henryk Ploetz and Karsten Nohl presented about their revelations of the proprietary Philips MiFARE classic RFID system.

As everyone in the IT industry suspected, the level of security provided by such a cheap, low-gate and completely undisclosed system is in fact very limited.

I'm particularly proud that this security research is exactly what Milosch and me originally wanted to enable by creating the OpenPCD and OpenPICC project. We wanted to put easier accessible and open, documented tools for low-level access to 13.56MHz RFID systems.

With a bit of luck, at some point in 2008, it should once again become clear that security by obscurity doesn't work. This lesson seems to be well-understood in the Internet world, but apparently has little penetration into the RFID sphere so far. There are still many proprietary systems whose security relies solely on the secrecy. Once a single person reveals that secret, the system is broken.

I can only hardly imagine the amount of economic damage imposed by the perpetrators of such systems. There are a couple of hundred million MiFARE classic tags on this planet, particularly in public transport ticketing and access control. The vendors of such systems should be blamed for their false claims. And anyone who bought it should be blamed for their blind belief in the claims of profit-oriented corporations without any independent validation or verification.

Dependency of essential Linux bluetooth features on dbus

Apparently I'm not the only one with outspoken criticism of the BlueZ dependencies on dbus.

I do not want to debate the merits of a message bus system on any system (desktop or non-desktop) and neither do I want to start a debate on how efficient dbus is trying to solve that problem.

However, what I'm fundamentally opposed to is when basic interaction in a network or between a computing device and its peripherals depends on extensive userspace dependencies. Now you might argue that ipsec needs a userspace keying daemon, that routing protocols need a routing daemon, and 802.1x or WPA need a userspace daemon, too. This is not the point. There are very valid technical reasons for doing so, and nobody really proposes that such things should move into the kernel. Also, none of the above-mentioned programs have requirements on other userspace components aside from glibc or maybe some netlink specific library.

Bluetooth however now requires dbus. At least it is almost impossible to do without. I have tried for neverending hours and didn't make it work. Others apparently have similar problems.

If people want to [d]bus-enable their kernel-related tools, let them do it. But please make it optional and don't depend on it. This is just not how things are done in the Linux kernel world until now, and I don't think there has been any debate on whether we really want such a paradigm change yet..

Personal reflection on the 24th annual Chaos Communication Congress

It's great to be at 24C3, the 24th incarnation of the Chaos Computer Clubs annual congress in Berlin.

In fact, this is my 10th anniversary at this congress, i.e. the first one I visited was 15C3. I ended up at 15C3 as somewhat of a coincidence by just following a fellow Linux hacker from the Linux User Group Nuernberg to whom I've since lost all contact.

What's actually worth mentioning is that this is the first CCC congress that I visit as a pure guest. I have no lecture, and I am not actively involved with any of the things I have been involved before, such as the video recording/streaming team or the Sputnik RFID location system.

Interestingly, I felt the first day much more tiring than usually, despite having slept more than in any of the previous years. Apparently the lack of constant adrenaline caused by last-minute-problem-solving has its impact..

The congress is a lot of fun, I've been talking to many old friends, colleagues and fellow hackers from all over the world, involved in all of the projects and/or companies that I've remotely had any contact throughout that ten year time period.

It's a very nice feeling. I doubt there is any other event or occasion where I would feel more at home than at this annual congress. This is my culture. This is where I belong. Here are people who understand, or rather: understood.

HTC TyTN II / Kaiser doesn't look like a GPL violation!

There have been numerous rumors floating around the net that the HTC TyTN II (aka Kaiser) might be a GPL violation due to a number of strings in the firmware image referring to Linux and vmlinux.

I've done some analysis on this subject, and posted my preliminary results in this posting to lkml earlier today.

So as indicated, I do not see any reason to believe there is a GPL violation with regard to the Linux kernel in the MSM7200 modem side as used in the abovementioned device.

So please stop those rumors now. I'm obviously not opposed to people being watchful and report/investigate potential GPL violations. But before you call it an actual violation, please rather make sure that you have some evidence!

Final cleanup of OpenMoko Neo1973 kernel patches

I'm doing one final review+cleanup iteration for the OpenMoko Neo1973 GTA01 related kernel patches before pushing them for review later tonight or at some point tomorrow.

The cleanups are mostly dead code removal, avoiding compile-time warnings as well as cosmetic cleanups such as adding MODULE_DESCRIPTION to all modules, and using consistent naming for files and driver names.

GTA02 will have to wait a bit more. On the one hand, changes that the kernel developers want me to do on PCF50606 will likely appear in the PCF50633 driver, too. On the other hand, the entire Smedia Glamo driver core has not been polished yet.

Playing around with the HTC TyTN II / Kaiser

For reasons that I cannot yet disclose, I have obtained a HTC TyTN II (aka Kaiser). This is my first (and hopefully last) Windows Mobile based device.

So far I've taken the device fully apart, unmounted all the shielding covers and took high-resolution photographs of each and every part of the phone. The resulting information is now that I'm aware of all the major components in the device, and I've started to do some data mining on those components.

As everyone knows, HTC used a Qualcomm MSM7200 based chipset in this device. The MSM integrates both the GSM baseband (DSP+ARM9) as well as the application processor (ARM11) and many other things. What's less known is the further peripheral configuration.

• The Bluetooth and WiFi chips are from Ti (BRF6300 and WL125, respectively).
• The power management unit is a Qualcomm PM7500
• NAND+DRAM are in a multi-chip module (1.8V, 2GBit NAND x8, 1GBbit DRAM x32) from Samsung
• The 3G/GSM RF part consists of Qualcomm's RFR6500 (receive with integrated GPS) and RTR6275 (transmit) as well as AWT6280, AWT6273 and AWT6273 amplifiers
• There furthermore is a CPLD: Xilinx XC2C128 (3000 system gates, 128 macrocells).

For those interested, I'll go through my PCB photographs and will edit and publish them soon.

I am now digging through all the various XDA/WM6 hacker information out there and trying to understand the various tools that can be used for further taking apart the software side. I've already managed to get into the bootloader, which apparently offers a standard USB serial emulation that can be accessed even from a Linux PC.

Unfortunately the MSM7200 is a highly proprietary/closed chipset, and there is very limited public information available. I've already ran into this while evaluating potential hardware for OpenMoko at some point in the past. I became curious about this MSM7xxx chipset family when they were first added to the ARM-Linux machine type registry many months ago.

Anyway, meanwhile Google seems to be doing a lot using this chipset, as they have recently announced the availability of a linux-msm.git tree. The source code should document many things such as GPIO assignments, IRQ's and contain drivers for most of the hardware (on the application processor side).

Now if some of you ask yourselves if I have turned my back on OpenEZX and OpenMoko: No, that's not true. I'm just looking at this for a very peculiar reason. Hopefully I'm able to reveal more soon.

Merging OpenMoko patches with u-boot and kernel mainline trees

Those following the OpenMoko commitlog will have noticed quite a bit of activity in the areas of u-boot and kernel patchset. For u-boot we always tried to track mainline git. For the kernel, there is now a patchset against the current Linus git tree (2.6.24-rc4 should also work) at http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/patches.

I'm intending to do some level of testing after the merge, and then submit the majority of the stuff. For kernel, I don't expect many issues. For u-boot, it will be a quite painful process.

So if you now think this means that I'm back working for OpenMoko, this is wrong. I'm doing this for a personal reason: I merely want to make sure that the code I wrote throughout the last 18 months will not bit rot somewhere but is actively merged into mainline.

Day one of FOSS.in

It was a great first day at FOSS.in 2007. It's been surprisingly quiet at the venue today, compared with the previous incarnations of the event. This is due to the changed structure, in which the first two days are focused "project days" and the main conference only starts on day three.

This does by no means imply that the project days are less important, or that the lower number of people is bad. Quality matters, not quantity. And since the event is about contributions, project days are a very important addition to FOSS.in

I spent most of the day talking to Rusty and James. It has been quite nice and I now have learned about Rustys new exciting CCAN project. As a long-time perl developer (I have leanred Perl before C!), I definitely understand the beauty of something like CPAN. With C however, the hardest issue will be resolving the namespace problem. Unfortunately I am currently not in the mood of adding even more unfinished things to my task list.

incommunicado for a while

It seems like my main mail server, ganesha.gnumonks.org, is facing some severe problems (ext3 corruption on a 3ware hardware RAID-1, i.e. something that clearly should not happen.

As per Murphy's law, this had to happen exactly while I was in-flight on my trip to Bangalore for FOSS.in 2007 :( Had it happened 2 days earlier, i would have actually within physical reach of the machine in question.

Luckily, all my hosted servers have remote consoles and actually even remote access to the BIOS setup. So I'm trying to recover what's to recover. The exim mail spool is on the affected /var partition. The much more important cyrus IMAPD spool is not affected. What a relief.

Still, everyone who tried to contact me: Please expect some delays in email based communication through the next few days. Sorry for the inconvenience.