Im Januar haben wir uns mit der (gänzlich fehlenden) Sicherheit von Legic Prime befasst, einer RFID-Lösung für kontaktlose Smartcards, wie sie z.B. vom Studentenwerk in unserer Mensa eingesetzt werden. Der selbe Chip ist auch auf den Student Cards der TUM, daher kann man mit seinem Studentenausweis in der Mensa essen gehen, was ja eigentlich eine praktische Sache ist.
Leider ganz an uns vorbeigegangen ist eine zum Abschluss unseres Projekts und genau zeitgleich mit meiner Veröffentlichung von Code, der das Beschreiben von Legic-Karten praktisch zum Kinderspiel macht erschienene Mitteilung der Zwischenfirma Automaten Seitz von Anfang Februar, denn Hardware und Karten beziehen TUM und Studentenwerk nicht direkt von der Schweizer Firma Legic. In dieser Mitteilung über die Sicherheitsaspekte von Legic Prime berichten sie recht objektiv über die Probleme der Technik und versuchen das Risiko einzuschätzen.
„[Im] ungünstigsten Fall können […] Karten dupliziert und/oder Dateninhalte verändert werden.” „Unsere Systeme führen mit jeder Einzeltransaktion auch einen Vorgangszähler (VGZ) mit. Wird eine LEGIC prime Karte dupliziert, kann dies über einen Sonderbericht, der nach eklatanten Vorgangszählersprüngen auswertet, festgestellt werden. Es gibt in diesem Fall zwei gleiche Karten, mit gleicher Kartennummer, die in den Start- und Endsalden Auffälligkeiten aufweisen.“
Soweit stimmt das an sich. Manipulationen durch geklonte Karten kann man erkennen und diese dann sperren lassen. Was sie dabei vergessen, ist allerdings, dass man ja viele Karten kopieren könnte (eine Karte sind genau 256 Bytes) und dann sich seine Karte jedes Mal mit einer neuen kopierten Karte bespielt. Jede Karte hat eine 4 Byte lange UID, die nicht veränderbar ist. Darüber hinaus ist auf jeder Karte noch eine Kartennummer aufgedruckt, die auch im Kartenspeicher steht und durchaus veränderbar ist. Nach allem was ich bisher weiß, war das die einzige Nummer, die vom Backendsystem tatsächlich benutzt wird, d.h. dass das Klonen beliebiger Karten problemlos möglich war, anscheinend haben sie jetzt aber zumindest dafür ein Softwareupdate rausgebracht. Das ist dann aber trotzdem total egal, denn wenn man die UID auch nicht auf der geklonten Karte verändern kann, kann man mit entsprechender Hardware (die man zum Ändern der Daten der Karte ohnehin braucht) eine Karte emulieren, bei der sich dann auch die UID verändern ließe.
Der eigentlich lustige Teil kommt erst auf Seite zwei der Erklärung von Automaten Seitz:
Ist eine Datenmanipulation möglich?
Eine Manipulation ist nur mit tieferem Verständnis und genauer Kenntnis
- über den Kartenaufbau (an welchem Byte steht welche Information)
- über Anzahl und Position der Speicherblöcke
- über den Algorithmus der Checksummenbildung
möglich.
Diese aufgeführten Mechanismen sind geschützt. Eine Manipulation ohne diese Kenntnisse, würde also mit hoher Wahrscheinlichkeit nicht ohne Fehler stattfinden. […]
So: 1. stimmt natürlich tatsächlich und wir wissen bis heute nicht, wofür jedes einzelne Byte gut ist. Aber wir wissen zumindest für alle veränderlichen Bytes, was sie bedeuten. Das Vorgehen war denkbar einfach: Wir haben Samples diverse Karten genommen und geschaut, wo sie sich unterscheiden. Oder bei einer Karte geschaut, wo sich diese nach einer Transaktion unterscheidet. So fanden wir sehr schnell, wo der Geldbetrag gespeichert wird und fanden auch den Transaktionszähler auf der Karte. Der Geldbetrag ist ein unsigned short also eine zwei Byte lange vorzeichenlose Zahl, die den Cent-Betrag speichert. Das alles bringt uns natürlich noch nichts, denn wir kennen ja den Algorithmus der Checksummenbildung nicht! Der ist natürlich streng geheim und müsst ihr wissen Automaten Seitz glaubt: um auf den zu kommen müsste man schon Einstein persönlich um Hilfe bitten. (Ihr könnt euch gern selbst probieren: 3,03€: 01 2f Prüfsumme: 2e; 39,00€: 0f 3c Prüfsumme: 33) Nach zweimaligem Hinschauen hatten wir dann den Algorithmus gefunden: er heißt Parität und berechnet sich aus dem XOR der beiden Bytes. Der Transaktionszähler funktioniert nach dem selben Prizip. Oh und zur Sicherheit stehen sowohl der Geldbetrag als auch der Transaktionszähler gleich zweimal auf der Karte!
Es gibt darüber hinaus noch weitere Checksummen auf der Karte und natürlich wussten wir wieder mal nichts über den Algorithmus. Bekannt war jedoch, dass die UID z.B. durch CRC gesichert ist. CRC ist ein Mechanismus, der vor Übertragungsfehlern schützen soll, nicht aber gegen beabsichtigte Manipulationen. Aber das mit Crypto-Sicherheit hat damals bei Legic ohnehin keiner verstanden. Die „Verschlüsselung“ der Kommunikation ist jedenfalls ein Witz. Nun denn: Unsere Vermutung war, dass die anderen Prüfsummen auf der Karte auch CRCs sind. Stimmt auch. Jetzt bedeutet das Wissen, dass die Prüfsumme ein CRC ist, noch nicht sofort, dass man diesen auch fälschen kann, denn ein CRC hat Parameter, die je nach Implementierung variieren. Zum Beispiel wären da das Prüfpolynom, der Initialwert und natürlich die Daten über den der CRC gebildet wird. Da wir ohnehin schon eine ganze Reihe von Kartensamples hatten, war es dann ein leichtes, entsprechende Software zu schreiben, die halt die ganzen Parameter mal ausprobiert, diejenigen streicht, bei denen es bei einer Karte nicht hinhaut und am Ende ausspuckt, was denn die Parameter vermutlich sind.
Die TUM hat noch ihre eigenen Segmente auf der Karte, auch wieder durch einen CRC gesichert, aber immerhin betrachten die Validierungsstationen der TUM auch die UID, d.h. man kann sich nicht einen beliebigen Studiengang auf die Karte drucken lassen in dem man einfach die auf der Karte gespeicherte Matrikelnummer ändert.
Zur Untermalung hab’ ich hier mal den Dump meiner Karte:
00000000 3e 97 34 45 b4 60 ea 9f ff 00 00 00 11 03 27 c0 |>.4E.`……..’.|
00000010 04 c0 83 23 00 00 7e 40 08 40 0a 1c 00 03 51 64 |…#..~@.@….Qd|
00000020 00 XY 17 c9 06 5f 59 06 5f 03 01 01 03 00 00 00 |…..Y.…….|
00000030 00 20 20 00 00 00 00 20 20 00 00 00 00 00 00 00 |. …. …….|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 01 b8 b9 |…………….|
00000050 01 b8 b9 00 00 00 00 02 00 00 02 00 00 00 00 00 |…………….|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
00000070 00 00 00 00 01 01 00 00 00 00 01 01 59 97 34 45 |…………Y.4E|
00000080 e6 b4 0f b4 0f 00 00 00 00 00 00 00 00 00 00 00 |…………….|
00000090 00 00 00 00 16 40 09 40 52 fb 1f 01 01 08 66 1b |…..@.@R…..f.|
000000a0 01 97 01 01 01 03 31 03 10 df 27 40 04 c0 a1 fb |……1…’@….|
000000b0 1f 01 02 00 10 50 09 67 09 00 00 00 02 72 XY ZX |…..P.g…..r..|
000000c0 01 00 40 00 XY ZX YZ 01 00 00 00 00 00 03 00 00 |..@………….|
000000d0 9d 2f c0 04 c0 34 fb 1f 01 03 00 00 00 ff 00 00 |./…4……….|
000000e0 00 ff 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 |…………….|
000000f0 00 ff 00 00 00 00 00 00 00 00 c9 00 00 00 00 00 |…………….|
Kurze Legende und eine Auswahl an Daten, die man dort sieht:
- Gelb sind die Legic-Segment Header mit Prüfsumme. In denen steht u.a. die Länge des Segments und die Zugriffsrechte. Es folgt der Header CRC
- Blau, Grün bzw. Orange sind die eigentlichen Nutzdaten der Segmente (Mensa, TUM1: Gütigkeit, TUM2: Matrikelnummer & Bibliothek, TUM3: TBD / bei allen gleich). Die TUM-Segmente haben wieder jeweils noch nen CRC am Ende.
- Alle kursiv gedruckten Bytes sind auf allen von uns gelesen Karten gleich gewesen. Bytes die unterstrichen sind unterscheiden sich auf manchen Karten, wir haben aber keinen blassen Schimmer, was sie bedeuten. Ansonsten könnt ihr mit der Maus über die Bereich fahren und solltet einen kurzen Beschreibungstext als Tooltip sehen.
- Auf der Karte sind 0x65F cent, also 16,31€ und es wurden 0x1b8 also 440 Transaktionen getätigt.
- Die auch auf der Karte aufgedruckte Kartennummer ist 6400XY (XYZ sind von mir anonymisierte Werte), die CRC Prüfsumme der Nummer steht direkt dahinter.
- Meine Matrikelnummer ist 272XYZX, meine Bibliotheksnummer 04000XYZXYZ und meine Karte ist bis zum 31.03.2010 gültig.
Wir sind natürlich keine Kriminellen, deswegen nutzen wir das Wissen nicht um gratis in der Mensa zu essen oder unser Gehalt durch diskrete Kartenaufwertungen aufzubessern. Aber wohlgemerkt: Es wäre ein Leichtes! Nur auf die gute Moral der Angreifer zu hoffen, wird wohl aber nicht immer aufgehen:
„__Eine massive und akute Bedrohung oder unauffällige Massenmanipulation sehen wir im Moment nicht. Dazu sind zusätzliche Hardware und spezielles, tiefes IT-Know-how notwendig.“
Das mit der Hardware stimmt, das nötige IT-Know-how trau ich jedem versierteren Zweitsemesterstudent an der Uni aber auch zu. Schließlich hatte auch keiner von uns irgendwelche RFID-Erfahrungen. Die eigentliche Schwierigkeit war es daher, das Legic-Protokoll, zu dem trotz des Vortrags auf dem 26C3 noch viele Details unbekannt waren, auf der Hardware zu implementieren, sodass Karten gelesen und beschrieben werden konnten. Nicht weil das Protokoll in irgendeiner Form sicher ist, sondern hauptsächlich wegen abstruser Details, nötigem genauen Timing und ähnlichen Dingen, die einem das Leben ein bisschen schwerer machen.
Ich find’s natürlich cool, dass Legic so ziemlich alles falsch gemacht hat, was man falsch machen kann. Das ist ein prima Beispiel um Leuten zu zeigen: So macht man’s nicht. Und natürlich hat es auch Spaß gemacht, die Sachen rauszubekommen. Meiner Meinung nach ist Automaten Seitz ein bisschen naiv, was die Einschätzung der Bedrohung angeht, aber zumindest haben Studentenwerk und TUM geschnallt, dass die Technologie ausgetauscht werden muss. Ob der Nachfolger dabei die richtige Wahl ist, wird sich wohl noch rausstellen.