leider habe ich diesen Vortrag verpasst. Ist denn in absehbarer Zeit ein vergleichbarer Vortrag geplant?

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 )

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.

Dazu eine Frage: Bestehen Plaene, den hash (d.h. das mapping von der flickercode-challenge zum signatur/hash-string) fuer HHD 1.4 ebenfalls zu reversen? (bitte, bitte? Ich habe nicht das equipment dafuer und wohne auch nicht in Frankfurt)

Specs zum Flickercode fuer hhd 1.4 gibt es (noch?) hier:
https://github.com/willuhn/hbci4java/blob/master/doc/tan_hhd_uc_v14.pdf