9 Gedanken zu „„Vom Überweisungsauftrag zur TAN““

  3. bruhns

    Der Hash-Algorithmus und die Erzeugung des Application-Cryptograms sind zwar auch interessant, aber eigentlich meine ich die Konstruktion des zu hashenden Strings.

    Der Hintergrund ist der: Ich halte es fuer unwahrscheinlich, dass der Krypto-Algorithmus Schrott ist und bin auch nicht so sehr an den Internals symmetrischer Primitiven interessiert.
    Das Protokoll zur Tan-Erzeugung hingegen stinkt und sieht in HHD 1.3 sehr fragil aus. Der zu hashende String kann nicht wieder geparsed werden, da –aus welchen hirnverbrannten Gruenden auch immer– die Typ und Value-Felder aber nicht die Lenght-Felder mitgehasht werden. Folgendes Beispiel ist einer der Gruende fuer die Fragilitaet:

    Hash-string:
    …\xe1Konto-Nummer\xe1123456789\xe1Betrag\xe10,01\xe1Betrag\xe11000,00\xb6\x00

    Ist nun die Kontonummer komisch und der Betrag 1000 eur oder die Konto-Nummer OK und der Betrag komisch? Jedenfalls haben beide Ueberweisungen dieselbe TAN. Fragil!

    Vielleicht erlaubt dies in HHD 1.4 einen exploit, falls die ZKA weiter so fragile Protokolle gebaut hat. Vielleicht erlaubt dies einen Exploit, wenn man das Zusammenspiel zwischen verschiedenen Protokollversionen und verschiedenen Auftragstypen betrachtet.

  4. schiermi

    Leider bekomme ich die Beispielsequenz 10850120829019984849453939424f464927 aus tan_hhd_uc_v14.pdf nicht eingelesen. Möglicherweise braucht es dafür auch eine neuere Version des Smartcard Betriebsystems SECCOS. Ich erwarte aber nicht, dass es bei der Konstruktion des zu hashenden Strings massive Unterschiede gibt. Die Felder sind jeweils mit 0xe0 (BCD) oder 0xe1 (ASCII) eingeleitet und das letzte mit 0xb6 abschlossen. Diese „Marker“ sind nicht Teil des Zeichenvorrats. Zumindest der TAN-Generator von ReinerSCT erwies sich in dieser Hinsicht „wachsam“. Von dieser Seite her sehe ich es eher schwierig, dem Gerät, der Karte oder dem Benutzer etwas vorzugaukeln.

  5. Sebastian

    Sehr interessant und schön chronologisch dargestellt mit den ganzen notwendigen APDUs, danke 🙂

    Ich habe nun das Vergnügen, dass meine Bank demnächst HHD 1.2 abschaltet, vermutlich erstmal nur zugunsten von 1.32.
    Momentan benutze ich Chipcardmaster und einen internen (Klasse 1)-PC/SC-Leser im Notebook, einfach Copy&Paste, TAN generieren und fertig, war super bequem und man brauchte nicht extra ein Gerät kaufen, das sowieso ständig zwischen zei Wohnungen hin- und her-verschwindet etc…

    Aber nun ist man wohl der Meinung, dass das ganze Verfahren scheinbar „für sogenannte ‚Social-Engineering‘-Angriffe anfällig ist“ (*hust*), und die Bankkunden freuen sich, mal wieder ein neues Gerät kaufen zu dürfen…

    Chipcardmaster scheint nur Version 1.2 zu unterstützen, aber es gibt ja auch noch die Script-Funktion, für so notorische Obsoleszenz-Verweigerer wie mich 😉
    notfalls könnte ich zum Testen auch den HHD1.3.2-Generator von meiner Mutter mitbenutzen, bzw. würde selbst diesen benutzen und wohl oder übel doch noch einen neuen kaufen, der vielleicht auch einfacher zu bedienenen wäre –
    aber bis auf das fehlende Tastenpad scheint sich nicht viel geändert zu haben: keine Displaybeleuchtung, und vermutlich verschwindet die TAN auch gleich wieder nach ein paar Sekunden.. -.- (nicht dass man es nicht schaffen würde, sie rechtzeitig abzulesen – aber allein der Gedanke sich auf eine vorgegebene Reihenfolge (erst zum Eingabefeld scrollen und tippbereit sein, dann TAN generieren) unter dem subjektiv empfundenen Zeitdruck macht das ganze für manche halt doch schon ziemlich stressig 😉 )

    klingt natürlich erstmal nach geringem Energieverbrauch – immerhin läuft das Ding von zwei Knopfzellen…
    Und ReinerSCT gibt ironischerweise auch eine Batterielebensdauer von ca. 15000 TANs an – nunja, meine Mutter hat vielleicht 2-3 Überweisungen im Monat, d.h. wenn man dann nach maximal 100-200 TANs sowieso schon wieder das nächste Gerät kaufen muss, hätte man ihm ja doch ruhig ein paar LEDs spendieren können, auf die paar mA kommts dann auch nicht mehr an…

    Was mich letzlich zu folgendem Gedanken bringt:
    Hätte jemand ernsthaft Lust auf einen kleines AVR-Projekt, so von wegen „Open Source TAN-Generator“, über USB wiederauflad- und alle paar Jahre updatefähig wenns wieder nen neuen Standard gibt (=also schonmal in keinster Weise zertifizierbar =D) !?

    (Die Spezifikation des Flickercodes sieht jedenfalls verlockend simpel aus, einfach den linken Balken auf nen PCINT-Pin und bei jedem Takt einen Nibble in ein Register schieben… nur noch Smartcard und Display ansteuern und paar Berechnungen machen 😉 )

  6. Foo Bar

    Die Seite im Wiki kann ich mit einem neuen Account wohl leider nicht editieren, daher auf diesem Wege:

    Das 0xb6 am Ende des gehashten Strings ist keine Konstante, sondern wohl 0xb0 + Anzahl Felder, das haut jedenfalls bei allen Versuchen, die ich gemacht habe hin (wobei „Anzahl Felder“ der Anzahl an Präfix-Bytes entspricht).

    Außerdem ist das Character-Encoding ungewöhnlich, bzw. wohl im Finanzbereich gar nicht so ungewöhnlich:

    Ä -> 0x5b, Ö -> 0x5c, Ü -> 0x5d, ß -> 0x7e – ibs. das Ü wird für die „Überweisung“ natürlich gebraucht.

    Achja, und die Hashfunktion in dem Beispiel im Wiki ist übrigens einfach SHA1 des übertragenen Strings – das wird aber nicht von allen Karten verwendet, die ich getestet habe.

  7. schiermi

    Danke Foo Bar für die Anmerkungen. Ich habe gerade mal geschaut, welche Encodings zu deinen Funden passen:

    > for c in $(iconv -l); do test „$(iconv -c -f $c -t UTF8 <<<$'\x5b\x5c\x5d\x7e' 2>/dev/null)“ = $’\xc3\x84\xc3\x96\xc3\x9c\xc3\x9f‘ && echo $c; done
    CSISO21GERMAN//
    DE//
    DIN_66003//
    ISO-IR-21//
    ISO646-DE//
    >

    Eine kurze Recherche offenbart DIN-66003 als beliebtes Encoding im Bankenumfeld (HBCI, DTAUS). Ich denke das passt. Dementsprechend habe ich das Wiki angepasst (auch bzgl. „B6“).

  8. potpiejimmy

    Der Artikel ist brilliant – top, wie ihr das alles herausgefunden habt, Respekt. Und danke.

    Kurze Anmerkungen/Ergänzungen:

    Zu HASH:

    Hier steht in der Beschreibung eine „1“ über der 0x31 (vor dem „a S t a r t“) – das müsste aber meiner Meinung nach die Länge der nachfolgenden Daten sein – also quasi Le‘ = (Le-5)
    HASH P1 P2 Le Le‘ a S t a r t -…

    Auch noch interessant: Viele Banken verwenden Masken 8 und 1 für IBAN und Betrag (statt wie im Beispiel 7 und 1 für Kontonummer und Betrag). Der Startcode beginnt dann entsprechend mit 881… statt 871.. In diesem Fall ist es wichtig, dass die Feldbezeichnung „I B A N“ statt „K o n t o n u m m e r“ in die zu hashenden Daten einfließt – wenn auch im Regelfall trotzdem nur die letzten 10 Stellen der IBAN (=quasi Kontonummer) dort eingesetzt werden.

    Zu ATC:

    Gar nicht wirklich erwähnt wird, dass der Application Transaction Counter (ATC) sich mit jeder Berechnung ändert (er wird mit jedem Aufruf von GET PROCESSING OPTIONS automatisch im Chip um 1 erhöht) – das führt dazu, dass immer eine andere TAN herauskommt, selbst bei gleichen Flickercode-Eingangsdaten. Das wiederum führt aber dazu, dass das Banksystem die TAN nur dann erfolgreich abgleichen kann, wenn es den aktuellen ATC der Karte auch kennt – ist dieser „offline“ erhöht worden, bspw. durch Offline-Transaktionen an einem Terminal oder durch sinnloses Herumspielen mit TAN-Generierungen ;), dann sind der ATC im Banksystem und der ATC auf der Karte nicht mehr synchron. Daher gibt es z.B. die Funktion „TAN-Generator synchronisieren“, über die man der Bank den aktuellen ATC der Karte mitteilen kann.

  9. Foo Bar

    Noch eine Erkenntnis: Es gibt Karten, die produzieren 20 bit-TANs, und davon passen natürlich ~ 5% nicht in 6 Dezimalstellen. Mein Reader tut in dem Fall auch nichts schlaueres als man sich so ausdenken könnte: Er probiert es einfach nochmal (wobei er allerdings einen Großteil der Schritte wohl als Optimierung weglässt) in der Hoffnung, dass der nächste ATC-Wert zu einer TAN unterm Limit führt.

Kommentare sind geschlossen.