Monthly Archives: April 2008

Sicherheitslücken beim Studentenausweis der OvGU

2 Replies

Die Studenten der Otto-von-Guericke-Universität Magdeburg bekommen einen Studentenausweis mit RFID-Chip. Das ist schon seit einigen Jahren so und eigentlich sehr praktisch. Ähnlich wie bei der Geldkarte kann man Geld auf die Karte laden. Damit kann man in der Mensa und den Cafeterien des Studentenwerks sein Essen bezahlen, in der Bibliothek kopieren und sich an speziellen Automaten zurückmelden. Die drucken dann auch das neue Gültigkeitsdatum auf die Karte, so dass man bei den Magdeburger Verkehrsbetrieben stets einen gültigen Fahrausweis hat. Zusätzlich ist noch ein Strichcode vorn drauf, damit dient der Studentenausweis auch als Nutzerausweis der Bibliothek. Das System kommt von der Firma Intercard.

Vor einigen Monaten fiel mir auf, dass im Foyer der Mensa zwei kleine Automaten aufgestellt wurden, die den aktuellen Ladebetrag der Karte anzeigen. Diese Automaten sind im Gegensatz zu den Lesegeräten an den Kassen der Mensa sozusagen autark, nur ein Stromkabel ist angeschlossen. Der logische Schluss: der Geldbetrag ist direkt auf der Karte gespeichert. Die naheliegende Vermutung: wenn es gelänge, den RFID-Chip entsprechend zu manipulieren, ließe sich Guthaben erschleichen. Da ich kein gewiefter Hacker bin, blieb es bei einer Nachfrage beim Studentenwerk, wo man mir einerseits bestätigte, dass der Betrag tatsächlich auf der Karte gespeichert ist und andererseits versicherte, dass das System sicher sei und ich mich bei weiteren Fragen an den Hersteller wenden solle – habe ich nicht gemacht. Das ganze passierte wie gesagt im letzten Jahr.

Vor einigen Wochen nun erschien in der c’t 8/08 ein Artikel mit dem Titel »Chiptease – Verschlüsselungssystem eines führenden Bezahlkartensystems geknackt«. Das ganze las sich zunächst wie der jährliche Aprilscherz der Redaktion. Doch weit gefehlt, der eigentliche Aprilscherz war richtig absurd und relativ leicht zu enttarnen, dies hier hatte Hand und Fuß. Die Autoren hatten den RFID-Chip freigelegt und dann Layer für Layer abgeschliffen und abfotografiert, um aus der Halbleiterstruktur auf die Funktionsweise und damit die verwendete Verschlüsselungstechnik schließen zu können.

Eine kurze Recherche ergab, dass der untersuchte und millionenfach verbreitete Chip vom Typ »Mifare Classic« auch von Intercard eingesetzt wird. Die c’t verweist in ihrem Artikel auf eine Untersuchung des niederländischen OV-Chipkaart-Systems. Die Stellungnahme, die Intercard am 7.4.2008 veröffentlicht hat, liest sich recht interessant:

Zur Verschlüsselung der Systemdaten und -informationen wird der geheim gehaltene sogenannte CRYPTO1 Chiffrieralgorithmus eingesetzt, welcher nur mit speziellen NXP Bausteinen umgesetzt und verarbeitet werden kann. Diese Bausteine sind auch in den Mifare Lesemodulen eingebaut. Die Schlüssellänge beträgt 48 Bit, daraus ergeben sich über 280 Billionen Kombinationsmöglichkeiten.

Punkt 1: Security by Obscurity. Die erfolgreiche Kryptoanalyse hat wieder einmal gezeigt, dass dieses Konzept auf äußerst wackeligen Füßen steht. Punkt 2: Schlüssellänge. Mag das Mitte der 90er noch Stand der Technik gewesen sein, in »Kleiner Passwortgenerator in Perl« haben wir letztens erst Schlüssellängen diskutiert und 48 bit sind heutzutage lächerlich wenig. Intercard schreibt völlig zurecht:

Fazit
Die einfache Struktur der aufgedeckten Rechenregel, voraussagbare Zufallszahlen sowie
Zusammenhänge zwischen Karten-ID und Schlüssel lassen einen erfolgreichen Angriff auf
die Karte gewissermaßen recht einfach erscheinen.
Die Aussage “Verschlüsselungsalgorithmus Mifare Classic nachvollzogen” muss also
im Grundsatz als korrekt bewertet werden !

Die möglichen Gefahren sind klar. Da aber die Karte an der Uni hier, soweit ich weiß, nicht als Zugangskarte sondern nur als elektronische Geldbörse dient, ist dieser Punkt für mich am interessantesten. Im Hintergrund des Bezahlsystems wird ein sogenanntes Clearingsystem benutzt. Das bedeutet, dass sämtliche Transaktionen an Aufladeautomaten und Kassen geloggt und ausgewertet werden. Bei Unstimmigkeiten, die bei manipulierten oder geklonten Karten logischerweise auftreten, können die entsprechenden Karten anhand ihrer Seriennummer gesperrt werden. Insofern mache ich mir um meine Karte erstmal keine großen Sorgen, würde aber dennoch empfehlen keine allzu großen Beträge aufzuladen.

Nach einer Bestätigung der Schwächen des Kartensystems vom 19.3.2008 schreibt heise letzte Woche übrigens in »Aus für RFID-System Mifare Classic?«, dass auch das Nachfolgesystem Mifare Plus anfällig ist. Mehr und ausführliche Information zum Thema sowie den Vortrag zum Thema auf dem 24C3 findet man auf der Homepage von Karsten Nohl.

Eins noch, Intercard hatte in dem oben verlinkten PDF noch folgendes angekündigt:

Weitere Vorgehensweise
InterCard wird für seine Kunden sehr zeitnah (ca. 4 – 6 Wochen) eine Migrationsstrategie auf
eine neue Kartentechnologie ausarbeiten und vorstellen.

Wer da nähere Informationen in Bezug auf die OvGU hat, kann die gern an mich weiterleiten.

LIRC für eisfair – eine Episode voller Rückschläge

3 Replies

Wie man auf Pack-Eis sehen kann, betreue ich das Paket »LIRC« für Eisfair. Wie bei climm und GnuPG bin ich 2005 aus persönlicher Notwendigkeit heraus in diese Rolle gerutscht. Mein Heimserver war damals für das Abspielen meiner Musik verantwortlich und eine Infrarotfernbedienung ist da Gold wert. Wie so oft im OpenSource-Bereich brachte ich das Paket auf einen Stand, der meinen Anforderungen genügte und beließ es bei einer längeren Liste mit Ideen und ToDos, die im Prinzip seit 2005 auf ihre Umsetzung warten – andere Dinge waren halt wichtiger.

Nun wurde kürzlich ein neues Kernel-Paket für eisfair-1 veröffentlicht: ein gepatchter 2.4.35. Wir haben im Testteam lange getestet bis er im März der Öffentlichkeit zum Fraß vorgeworfen wurde. Ein neuer Kernel bedeutet aber auch, dass LIRC neu übersetzt werden muss, da es seine Treiber selbst mitbringt und Kernelmodule nunmal zur Kernelversion passen müssen. Es gab auch schon die eine oder andere Anfrage in der Newsgroup und ich beschäftige mich seit ein paar Tagen mit einer neuen Version des Pakets.

Zunächst steht das Kompilieren an. Ich konnte LIRC 0.8.2 für die eisfair-Kernel 2.4.26-1 und 2.4.35-wt1 jeweils in den Versionen mit und ohne Unterstützung für SMP übersetzen – für 2.4.26 mit der alten Build-Umgebung mit gcc 2.95.3 und für den 2.4.35 mit der zukünftigen Build-Umgebung mit gcc 3.4.6, die zur Zeit vom Testteam getestet wird. Das Übersetzen von LIRC artet schnell in Arbeit aus, weil es mit einem Lauf aus ./configure, make und make install nicht getan ist. Das muss für jede Kernel-Version und jeden gewünschten Treiber einzeln gemacht werden, es sei denn, man kompiliert gleich alle Treiber. Tut man dies nicht, ist noch mindestens ein Lauf mit der Option --with-driver=userspace nötig, damit LIRC auch in der Lage ist mit verschiedenen Treibern gestartet zu werden und nicht nur mit dem, für den es kompiliert wurden, wie z.B. serial.

Also wie gesagt, ich konnte LIRC für die Treiber serial und atiusb kompilieren – das sind die beiden, wo ich selbst Hardware zum Testen habe. Dank VMware waren auch die verschiedenen Kernel kein Problem, ich hab einfach für jeden eine neue virtuelle Maschine angelegt. Die anfängliche Euphorie, dass auch ein LIRC 0.7.1 mit den aus 0.8.2 gebauten Kernelmodulen für 2.4.35 läuft, wich dann der ersten Enttäuschung. Ich hatte zunächst die Version, die mit allen Treibern laufen soll, mit --with-driver=none kompiliert. Das funktionierte logischerweise nicht. Der erste herbe Rückschlag: LIRC 0.8.1, 0.8.2 und 0.8.3pre1 lassen sich mit der neuen eisfair-Buildumgebung und der korrekten Option --with-driver=userspace nicht übersetzen, wie man auf der Mailingliste von LIRC nachlesen kann.

Man kann dort ebenfalls nachlesen, dass ich versucht habe, die neueste Version aus dem CVS zu übersetzen, wo dieser Fehler bereits behoben ist. Leider macht mir da die Buildumgebung einen Strich durch die Rechnung. Das Skript ./configure liegt nicht im CVS, sondern wird mit den autotools (autoconf, automake usw.) erst noch selbst erzeugt. In der Theorie funktioniert das gut, in der Praxis tritt bei mir leider der gleiche Fehler auf, den ich vor einiger Zeit schon hatte, als ich climm aus dem SVN bauen wollte. Es wird ein unbrauchbares Skript erzeugt, dass nur eine wenig hilfreiche Meldung ausgibt. Wenn sich jemand gut mit autoconf auskennt und eine Idee hat, wo da das Problem liegt, möge sie sich dringend bei mir melden! Fazit jedenfalls: LIRC aus CVS ist für mich nicht möglich.

Heute erreichte mich dann über die Mailingsliste von LIRC die überraschende Nachricht, dass gerade die 0.8.3pre2 rausgegeben wurde. Der o.g. Fehler tritt nicht mehr auf, dafür ein neuer. LIRC lässt sich nicht mehr mit dem Treiber serial übersetzen, weil in der entsprechenden Quellcode-Datei eine Header-Datei aus den Kernelquellen nicht gefunden wird. Zumindest wird sie bei den 2.4er Kerneln nicht gefunden. Ein flüchtiger Blick in den Quellbaum eines 2.6er Kernels offenbarte, dass es dort zwei Dateien io.h gibt, eine in /usr/src/linux/include/linux und eine in /usr/src/linux/include/asm – beim 2.4er Kernel gibt es bloß letztere.

Auch dies habe ich auf der Mailingliste von LIRC gemeldet und warte erstmal ab. Es gibt nämlich mehrere Möglichkeiten jetzt:

  • ich warte ab, bis die nächste LIRC-Version veröffentlicht wird, mit der ich alles korrekt übersetzen kann
  • ich baue das allgemeine LIRC und die Treiber für atiusb aus der 0.8.3pre2 und die Treiber für serial aus der 0.8.2
  • ich kann durch wundersame Eingebung oder Hilfe von außen den Fehler in der Buildumgebung finden, so es denn tatsächlich einer in dieser ist, und die aktuelle Version aus dem CVS übersetzen
  • ich gehe in den Versionen soweit zurück, bis ich auf eine stoße, die ich komplett übersetzen kann, das wäre dann wahrscheinlich die 0.8.0
  • ich behebe den Fehler in 0.8.3pre2 selbst und übersetze dann meine modifizierte Version

Ehrlich gesagt, gefällt mir die erste Version bisher am besten, allerdings könnte das unter Umständen noch eine Weile dauern, je nachdem wie schnell die Entwickler von LIRC die nächste Version rausbringen. Module aus verschiedenen Versionen wollte ich eigentlich vermeiden, um mir nicht eine zusätzliche Fehlerquelle aufzureißen. Auch eine alte Version finde ich nicht so cool. Ob wir den potentiellen Fehler in der Buildumgebung schnell finden, ist auch ungewiss, bleibt also im Grunde noch die letzte Möglichkeit: ich stöber durch den C-Code und beheb den Fehler selbst – dazu hab ich keine Lust…

Falls sich also jemand fragt, warum die neue Version des LIRC-Pakets für eisfair so lange braucht, ich weise sämtliche Schuld von mir und schiebe es auf höhere Gewalt!

Flexibles Issue Tracking mit roundup

Leave a reply

Fuer den Einsatz in der Firma suche ich derzeit ein Bug- und Issue-Tracking-System. Nicht ausschliesslich fuer unsere Engineeringabteilung, sondern auch fuer die Jungs vom Service, die die Hilfeschreie entgegennehmen, wenn der Kunde (fliegendes Personal, und damit extrem ungeduldig) ausnahmsweise mal nicht von der Runway wegkommt.

Eins ist klar: Es muss Open-Source sein. Zum einen will ich nicht erst eine ellenlange Begruendung fuer die Finanzbuchhaltung schreiben, warum sie bitte schoen n+1 Euro fuer eine Software ausgeben sollen, deren Nutzen fuer die Firma sie ohnehin (wieder mal) nicht korrekt quantifizieren koennen. Zum anderen will ich nicht erst mit m+1 Vertrieblern von irgendwelchen Softwarebuden quatschen, die mir ihre “Marktfuehrer”-Loesung aufschwatzen wollen. Aber noch viel wichtiger: Ich will schnell mal eben was aendern koennen, wenn das Tagesgeschaeft es notwendig macht!

Also dann, Wikipedia ist mein Freund, und auf in die taktische Aufklaerung auf dem Softwarefeld: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems listet einen ganzen Wald von Optionen auf. Neben dem eierlegenden Wollmilchborstenviehmoloch “Bugzilla” existieren viele nette kleinere Systeme, die zwar nicht so dick auftragen, die dafuer aber umso schneller und wartbarer sind und fuer deren man Evaluierung man nicht erst im RDBMS herumfuhrwerken muss (bravo!). Web- und Email-Frontends sind anscheinend per stiller Konvention ohnehin ueberall dabei (wobei ich das Email-Frontend derzeit ueberhaupt nicht brauch’).

Besonderen Gefallen habe ich an Roundup gefunden, der ist nicht nur sehr flink, sondern vor allem sehr vielseitig. Eine der Uebersetzungen von Roundup aus dem Englischen ist “Razzia”, und dem Namen macht das kleine Softwarepaket alle Ehre: Neben PostgreSQL und MySQL kann Roundup auch mit sqlite umgehen, das macht das Testen sehr bequem; es bringt seinen eigenen Webserver mit, fuehlt sich aber im mod_python-erweiterten Apache2 genauso daheim; es laesst sich als Bugtracker, Trouble-Ticket-System, ToDo-Liste, persoenliche Zeiterfassung und sogar als Kaffeemaschine konfigurieren. Okay, die Kaffeemaschine ist jetzt gelogen, aber ich wette, lange dauert’s nicht mehr, dann gibt’s auch das! Nettes Feature: Pro Eintrag in die Issue Liste wird eine kleine Mailingliste angelegt, so dass alle Beteiligten/Interessenten ohne viel Aufwand verfolgen koennen, wie sich ein Problem seiner Loesung naehert.

Am besten gefaellt mir bei der Arbeit mit Roundup die Dokumentation, die mit Beispielen nicht geizt, wie man unkompliziert Erweiterungen am Datenbankschema und an den Eingabemasken und Ansichten vornehmen kann: http://roundup.sourceforge.net/doc-1.0/customizing.html. Die Beispiele wirken allesamt wie direkt aus der Praxis entnommen und geben selbst einem Python-Laien wie mir in kuerzester Zeit das Gefuehl, die Dinge wirklich in der Hand zu haben. Innerhalb eines Tages ist es mir gelungen, einen Protoypen zu basteln, in den wir exemplarisch mal ein paar der Bugs der letzten Wochen eingetragen haben. Der Tag Arbeit schliesst eine Customization der CSS-Stylesheets auf unsere Firmen-CI genauso mit ein, wie das Erstellen von automatisierten Reports ueber den Lebenszyklus von Kundenanfragen und Fehlermeldungen fuer die Geschaeftsleitung. Und demnaechst wird auch die Serviceabteilung angebunden, kann ja nicht laenger als einen Tag dauern. ;-)

Fazit: Ich frage mich, warum ich mir ueberhaupt andere Systeme angeschaut und nicht stattdessen gleich Roundup genommen habe. Hier finde ich alles, was ich brauche, um meinen Job zu erledigen, ohne viel Zeit von den Hauptaufgaben abzuzwacken. Ich wuenschte, es waer immer so einfach! Und ich komme von meinem Vorurteilen ueber Python weg, der Produktivitaetsgewinn macht die infantile Syntax locker wieder wett. ;-)