[Update: 2012 habe ich mir Tickets erneut angesehen.]
Pünktlich zu Ostern wird es endlich Zeit, mal zu zeigen, was sich denn in den Barcodes der Onlinetickets der Bahn alles an Informationen findet und daraus abzuleiten, wie wohl deren System funktioniert.
Ganz dumm haben sie sich dabei nicht angestellt, sondern – und das war der unerwartete Teil – mal ausnahmsweise alles richtig gemacht: Die Ticketdaten werden zlib-komprimiert, dieser Blob dann DSA signiert und das alles mit dem „Aztec“ Matrixcode auf’s Ticket gebracht. Die mobilen Endgeräte prüfen (hoffentlich) die Signatur und speichern einen Kontrolldatensatz, der später mit der Datenbank abgeglichen wird, sodass sie zumindest erkennen, wenn stornierte Tickets oder das selbe Ticket mehrfach genutzt wurden (Quelle).
Letztendlich scheinen die mobilen Kontrollgeräte der vermutlich einzig verwundbare Punkt. Käme man an die Firmware ließen sich sicherlich Wege finden, diese trotz falscher Signatur von einem echten Onlineticket zu überzeugen. Ansatzpunkte wären beispielsweise Carrier-IDs die dem Gerät unbekannt sind, fehlerhafte ASN.1-codierte Signaturen oder gar Pufferüberläufe durch zu lange Payloads (Dank zlib-Kompression passt ja einiges in den Barcode).
Weitere Ressourcen:
- Wikipedia: Diskussion:Online-Ticket dokumentiert die Ergebnisse des Reverse-Engineerings und die Bedeutungen der einzelnen Felder
- onlineticket.py ist ein proof-of-concept python-Modul, das einen Parser implementiert um den Inhalt von Onlineticket-Dumps auszulesen
- BCTester: Software um den Aztec-Code zu dekodieren
- Die Slides der Präsentation auf dem Easterhegg 2010 sind auch verfügbar (svg+javascript im Firefox getestet)
