Hearing of German Constitutional Court on voting machines

Today was a public hearing of the German Constitutional Court (Bundesverfassungsgericht) on the subject of the use of voting machines in elections of the German parliament.

I've been anticipating this for quite some time. The plaintiff, Dr. Ulrich Wiesner, has been investigating the subject for a long time, just like the CCC has been doing a lot of theoretical analysis as well as practical hands-on hacking of the respective voting machines (actually, rather, Voting computers).

As most readers of my blog will be well aware, voting using electronic devices, or even more so computers driven by actual software, raises an almost unlimited number of concerns. Both software and hardware manipulations could have tremendous effects on the final result, no regular citizen or even most IT security experts can actually observe the counting of votes and guarantee the correctness of the results.

The hearing of the constitutional court was for clarification of further questions of the judges to both the plaintiff, the defendant (the German parliament and Ministry of Interior) as well as three independent expert witnesses. While the CCC has earlier been asked by the court to provide an expert study, it was not officially invited to be questioned at this hearing.

Nonetheless, three senior members of the Berlin CCC (me included) were present in the audience and following the hearing with great anticipation. It was my first 'live' experience at the constitutional court, and I have to say I am no less than impressed. Intellectual discourse on a very high level. The judges were asking very thoughtful and precise questions, were asking for explanations without mercy ;)

I think the legal representation of the plaintiffs (including a senior legal scholar) was excellent. Good arguments, very eloquent. The various defendants (ranging from representatives of parliament, ministry of interior, the government agency in charge of certifying the voting machines (PTB), as well as the senior election official of the state of Hessen) were making much less impressive performance.

And at the end of the day, I still cannot get why about every consumer electronics device, from mobile phone to digital TV receiver to game console has about one lightyear more security architecture than the machines that are used to count the votes. No hardware-crypto engine, no encrypted JTAG, no signed bootloader and software (plus automatic mask-rom based signature verification). Plus officials in the public administration who think the trade secrets of the vendor of the machine is more important than the public interest..

I think the judges very well got that point. You could literally see their disbelief in situations like when it was outlined to them that only the vote-counting machine has to get type approval, but not the PC + software that is used to program the particular election into the vote-counting machine, neither the software used to read out the memory modules and summarize the votes of multiple voting machines. So not even those insufficient small amount of testing and certification that exists does extend to the entire system, rather just to the input unit.

We'll probably have to wait for some more months (at least weeks) to see the result. I definitely remain very optimistic that the constitutional court will prevent the worst problems of the current situation. I don't think they will completely close the door for voting machines, but at least raise the bar for any such future system very high in order to achieve a level of transparency and trustworthiness similar to that of the traditional paper ballot vote.

To me, for a long time, the constitutional court is the single remaining still functional and trustworthy entity in the Federal Republic of Germany. It is the last bit of hope against the constant battle of the government administration[s] against civil liberties, post-9-11-security, surveillance/intelligence particular in 'new' technology.

Some more S3C24xx NAND speed observations

I've now moved on to other topics, but I still want to mention some of my thoughts on the still quite poor NAND performance on the GTA02 (and generally, the S3C24xx).

It seems like we are down to a point where the CPU is 100% busy reading from NAND, which is odd. Why would reading from a mass storage device make the CPU so busy? Well, because Samsung "forgot" to add DMA support to all of their integrated NAND controllers, from the old 2410 through the 2440, 2442, 2443 and up to the shiny new 6410, all the NAND controllers don't support DMA. In fact, they don't even have a FIFO or some kind of internal buffer for the received data. This is really weird, considering the facts that

• every other peripheral (SD/MMC, SPI, UART, ...) can use DMA
• Samsung as provider of both NAND flash and SoC should be experts in providing good flash performance
• I cannot see any strong architectural limitation. The data is read into a register. The register should be replaced with a FIFO, and a DMA can regularly read from that register or FIFO and put it somewhere else into memory. It's not any different from e.g. SPI or UART DMA.

In the current mainline Linux driver for S3C2440 NAND, we busy-wait (poll) for completion of the read request. This is of course sub-optimal. I implemented a version that uses the Read/Busy line IRQ and a 'struct complation' based mechanism and to my big surprise the CPU usage and throughput was identical. It seems like that NAND flash in the GTA02 is fast enough to max out the CPU.

So probably all that can be done is to optimize the actual code that is executed during the NAND read. It might be worth implementing some small hand-optimized assembly implementation as standalone code (not using the existing driver) to see how far the hardware can actually go.

Isn't it sad that you use Samsungs SoC and Samsungs NAND (packaged together in one component as multi-chip-package by Samsung) and still get less than 50% of the performance of the NAND chip, according to the data sheets :(

Some more GSM Abis experiments

It's been quite some time since I last mentioned Abis in this blog. Recently, I've again found some time to experiment with Abis. The last two days I was working on porting some proof-of-concept code of a fellow hacker from windows to Linux.

I now also have manufactured all the cables and adapters I need, plus installed a Windows 98 box in order to operate the Wandel+Goltermann MA-10 protocol analyzer that somehow made his way to my lab. The MA-10 can act both a a high-impedance passive sniffer on top of the E1 link (using the Abis Monitor software), or it can actually emulate the BSC by using a terminated E1 Rx+Tx interface and the AbisSim software.

I don't want to talk too much about things that haven't been implemented yet. But in the next weeks, I'll be diving all the way into mISDN and see what needs to be done to make it talk the specific Q.921 dialect that Abis uses.

Stay tuned. I'm working towards a first release at the 25C3 congress in late December.

Android and its perceived 'openness' :(

As many other people have been blogging and news sites have been reporting: The Android source code has been released. This is definitely good news. However, freedom-loving people already discover in blog posts that there's a remote kill switch by which Google can disable an already installed application and that some features are reserved to vendor-signed applications.

To me, those things are not a big surprise. As soon as you try to get in bed with the big operators, they will require this level of control. Android is not set out to be a truly open source mobile phone platform, but it's set out to be a sandbox environment for applications.

And even with all the android code out there, I bet almost (if not all) actual devices shipping with Android and manufactured by the big handset makers will have some kind of DRM scheme for the actual code: A bootloader that verifies that you did not modify the kernel, a kernel that ensures you do not run your own native applications.

Thus, Android so far was little more to me than yet-another-J2ME. Some sandbox virtual machine environment where people can write UI apps for. In other words: Nothing that gets me excited at all. I want a openness where I can touch and twist the bootloader, kernel, drivers, system-level software - and among other things, UI applications.

I actually think it's a bit of an insult if people think of Motorola's EZX or MAGX (and now Android) phones as "Linux phones". Because all the freedoms of Linux (writing native applications against native Linux APIs that Linux developers know and love, being able to do Linux [kernel] development) are stripped.

In the end, to what good is Linux in those devices? Definitely not to any benefit of the user. It's to the benefit of the handset maker, who can skip a pretty expensive Windows Mobile licensing fee. Oh and, yes, they get better memory management than on Symbian ;)

That's the brave new world. It makes me sick.

Luckily, it's 50 B.C. and the Romans occupy all of Gaul, except for one small village that has been able to avoid the invaders.

Openmoko GTA02 NAND performance improvements

On Sunday night, after returning from a weekend trip to Hamburg, I sat down and looked at the NAND and S3C2442B data sheet to figure out the actual timing performance. Interestingly, the NAND timings were much more verbose and detailed (and had different names) than the timings described in the NAND controller section of the S3C24xx manual - and both are from Samsung ;)

Anyway, it seems like the current timing settings for the various stages (reading u-boot by the stepping stone mechanism, reading the kernel by u-boot as well as actual mtd-based access inside the Linux kernels) were extremely suboptimal. They're basically standard timings designed to work with most NAND flashes out there, ignoring the fact that GTA02 uses one specific flash with very good (fast) timings, at least according to the data sheet. There should also be no PCB / routing related issues such as capacitive overload preventing higher speeds, since the NAND flash die is stacked onto the CPU die in one package, and the NAND controller signals are not routed on the PCB anywhere.

Some initial experiments based on the calculations show that the performance can be easily improved by 41% over the stock GTA02 NAND performance. However, the actual speed (6.59MBytes/sec) is still much lower than the theoretical maximum read performance of 15.64MBytes/sec. It seems there is more room for improvement inside the MTD layer of the Linux kernel.

It's again quite amazing how much room there is for improvement in GTA02 performance, both power consumption wise (see my recent post about framebuffer blanking), as well as actual data throughput. Those are really low-hanging fruits, and it's very surprising that nobody working for Openmoko or in the Openmoko community has been able to spend some time to look into those...

About the new format / structure of FOSS.in

There has been quite some discussion on various places on the net about the recently-announced change of the FOSS.in conference format. Instead of lots of talks/presentations, there is an emphasis on workshops and similar more interactive and collaborative types of events.

I have been speaking to a number of developers who have been to FOSS.in before and who have been putting in proposals for FOSS.in/2008, too. They all think it is a very courageous step: going from a successful, working 'traditional conference' scheme with presentations, sufficient sponsors to cover travel expenses of foreign speakers, etc. to a very different, much more developer-community oriented event.

I also think it is a courageous experiment. I have not yet heard of any event similar to this before. Sure, there are project days and developer meetings or miniconfs or whatever you might call them. But not to the extent as, at least to my perception, FOSS.in is planning right now.

In any case, it depends on what your target is. 'typical' Linux conferences are basically focussing on either one (or multiple) of the following:

• Spread the word about Linux/FOSS, to generate more adoption
• Provide updates on development progress to various people in the community as well both individual and professional users

However, if you emphasize on the actual FOSS development, then I think it is quite legitimate to go for a event format that FOSS.in is heading to right now.

It is exactly FOSS.in who can try such a change, since it is a true community event without any commercial interest and without affiliation to particular companies.

And after all, who wants to see the same kind of event happening each and every year, with the same kind of people talking? Wouldn't that be boring after some time? Especially if there are a number of other events doing more or less the same?

In any case, personally I'm planning to do a FOSS.in WorkOut on a USRP+gnuradio based GSM scanner project. India is the perfect place on earth to get this done, since the government mandates A5/0 (no encryption) and thus all the packets can be captured and each and every bit implemented as wireshark plugin.

FOSS.in 2008 CfP is out

I have just received news that the FOSS.in 2008 Call for Participation has been released. This is good news, although I think it is quite late, as every year...

I'm definitely looking forward to FOSS.in, like every year. There's such a huge potential in India, so many software developers. If only some more could be convinced to _effectively_ work on FOSS and contribute their work back to the community, it would be a great gain.

All details about mifare crypto1 algorithm and protocol disclosed

Henryk Ploetz has released his thesis on mifare protocol and cryptographic weaknesses, which is to the best of my knowledge the most complete publicly available documentation about the mifare CRYPTO1 system.

Congratulation to him and his peers (starbug, Karsten Nohl and others) on this great work. I still hope I could have played a more active role in the security research on mifare. But it's good to see that as imperfect as they are, OpenPCD and OpenPICC fulfill their duty as toolkit to enable security research on RFID.

Significant power savings during framebuffer blanking

As I've posted today to openmoko-kernel, there have been some quite significant power savings during the "backlight off but still not suspended yet" operational mode of the GTA02. The power savings are in the order of 49%, which is really massive, particularly for applications that run in the background while the screen is blanked, like typical mp3/ogg player applications.

It is sad to me that something like this is found long after the GTA02 has actually shipped. It seems like there are still fairly low-hanging fruit around to do some significant power saving.

Since all the measurements can be done on the device itself, using the built-in high precision coulomb counter of the battery, everyone is able to do the measurements without any special equipment. It also means that power management related issues can be tested automatically.

I would love to see somebody working on software that switches certain hardware on (and off) again or cycles through various differnent power states of every hardware unit an then reads the power consumption. The resulting readings can then be manually checked if they're consistent with expectations based on the hardware design. Furthermore, this program could be used for regression testing against new uboot/kernel/OS releases in order to ensure we don't get into power consumption regressions.

Actually working on Openmoko again

It's an interesting feeling to spend some days working full-time on Openmoko again. Swisscom was stating a number of high-priority bugs (for them) which I tried to resolve.

The first two are u-boot related, namely: get GSM passthrough working again, and fix USB DFU Upload on GTA02. Those two should be doing quite fine now.

I've also been investigating possible ways to optimize CPU usage of frameworkd, although it is not yet clear which of the possible solutions should be implemented in the end

Right now I'm working on some power management related issues, mostly glamo/backlight/LCM related, as well as re-investigating the hardware-ECC work by Zecke.

However, after a significant break from _using_ the Openmoko devices and the software available for them for a number of months, I have to say that the overall experience was really disappointing.

• Whatever Openmoko builds as their daily builds available on downloads.openmoko.org is the most unintuitive UI that I've ever seen (is that ASU?). After some attempts, I gave up. unusable for me.
• FSO images can be installed, but are incredibly slow
• Documentation in either openmoko wiki or FSO wiki is horribly outdated
• It's _really_ hard to get devirginator running since lowlevel_foo and others are not available on downloads.openmoko.org, but devirginator insists on downloading them from a website rather than copying them from a local directory
• there's a neverending fragmentation
• core aspects of the system level have not been addressed, like replacing sysvinit with something like upstart, some serious boot speed optimizations and various power management related bits
• Nobody has yet had the time and resources to investigate a thorough, flexible and performant storage and API subsystem for contact + related data

All this makes me really sad and gets me back to the point where I feel like when I left OpenMoko, Inc. last year: Too many insurmountable problems, and very few that can be addressed in a way that they are solved once and forever. Everyone runs their own personal little pet system, magic scripts, revision control system, overlay files, images, etc. Still too many people think OE is a tool to develop+crosscompile application programs.

In Switzerland again. Feeling like in a Bollywood movie

I'm back to Switzerland for some Swisscom related work. Right now I'm sitting in the Intercity train between Zurich and Bern. And believe it or not: Half of the car is occupied by (loud) Hindi speaking Indian tourists ;)

It really feels like I'm in a Bollywood movie. Indians in Switzerland. And not only in Switzerland, but in the Train. Couldn't be any more cliche ;)

Drona - what a disappointment

In Berlin there are not many chances to watch a Bollywood movie in an actual cinema. Those few movies that they show, I usually try to watch, at least if I'm in town. So far they've always made a great selection and picked only blockbuster movies that actually were any good.

Since I haven't been staying up-to-date with the latest Bollywood releases (mostly due to time constraints and lack of access to Indian DVD's in Taiwan), I didn't even check about the background of the latest movie they've started to show here: Drona.

After watching the first five to ten minutes of the film, it became already clear to me that I should have done better and check beforehand. Never seen such a trashy movie before. What a disappointment.

Blinkenlights is back (stereoscope)

Some of you might remember the famous blinkenlights installations of the CCC in Berlin at Alexanderplatz some years back. Basically they used a matrix of windows on a building for a low-resolution display to play pong and display all kinds of animations and text.

After a long break, they're back, even bigger with blinkenlights stereoscope, a massive installation spanning 960 windows of Toronto City Hall. The entire backend technology has been re-implemented based on OpenBeacon , specifically the WMCU and the WDIM units.

Netfilter Developer Workshop 2008 in Paris

I'm currently at the netfilter workshop 2008 in Paris, France.

It's always sort-of a mixed experience for me. Obviously it's great to spend some time with all the great hackers who work on various aspects of netfilter/iptables (and now finally also its successor that is so-far called nftables). On the other hand, it's been about three years since I last actively contributed code to netfilter, which makes me sad. I'm still excited about it and have many ideas that I'd love to implement. But where to find the time for it?