Project

General

Profile

Kryptographische Details für HBCI/FinTS

FinTS ist der neue Name für HBCI, HBCI ist aber der bekanntere Name, daher wird im folgenden der Begriff HBCI verwendet.

Das Protokoll für HBCI beschreibt Aufbau und Inhalt verschiedener Nachrichten, die Aufträge des Kunden und die Antwort der Banken definiert. Solche Nachrichten müssen kryptographisch abgesichert werden, dabei wird folgender Zweck verfolgt:

  • die Nachricht soll abhörsicher sein
  • beide Kommunikationspartner müssen sicher sein, mit wem sie kommunizieren (damit z.B. die Bank nur berechtigte Aufträge ausführt)
Zur Absicherung werden unterschiedliche kryptographische Verfahren verwendet, diese teilen sich grundsätzlich in zwei Gruppen auf:
  • PIN-TAN-Verfahren
  • echtes HBCI

PIN-TAN

Hier werden die erst einmal unverschlüsselten Nachrichten über HTTPS (also mit SSL gesichertes HTTP) übertragen. Dabei stellt SSL die Authentizität der Nachrichten sicher (also wer kommuniziert mit wem) und die Nachrichten werden mittels SSL verschlüsselt.

Hierbei hängt die Sicherheit ganz entscheidend davon ab, welche SSL-Verfahren zum Einsatz kommen. Beim Aufbau einer SSL-Nachricht tauschen sich Server und Kundensoftware über die unterstützten Verfahren aus und einigen sich dann auf ein Verfahren.

Leider bieten manche Server aus heutiger Sicht unsichere Verfahren an, das ist in AqBanking dann an den Warnmeldungen erkennbar.

"Echtes" HBCI

Beim echten HBCI werden Verschlüsselung und Signaturen auf HBCI-Ebene erledigt (nicht von SSL).

Für alle echten HBCI-Verfahren gilt bisher, dass die Nachrichten mit einem zufällig und für jede Nachricht neu erzeugten Schlüssel die Nachrichten verschlüsselt werden. Dieser Nachrichten-Schlüssel wird dann seinerseits verschlüsselt, wobei dann in der Regel Schlüsseldateien oder Chipkarten zum Einsatz kommen.

Der verschlüsselte Nachrichten-Schlüssel wird dann in der damit verschlüsselten Nachricht mitgesendet. Der Empfänger entschlüsselt dann diesen Nachrichtenschlüssel und kann damit die verschlüsselte Nachricht dekodieren.

Ausserdem werden Nachrichten in der Regel vom Benutzer signiert, d.h. die Kundensoftware erzeugt einen Hash der Nachricht und dieser wird mittels Schlüsseldatei oder Chipkarte signiert.

Bei allen Banken signiert der Benutzer seine Nachrichten, so dass die Bank sicherstellen kann, dass die Aufträge tatsächlich vom Kunden stammen. Leider signieren aber nur wenige Banken ihre Antworten, so dass der Kunde hier eigentlich nicht sicher sein kann, ob Antworten wirklich von der Bank kommen. Ein schönes Beispiel für die Asymmetrie der Beziehung zwischen Bankkunde und Bank...

Grundsätzlich unterscheidet man die in den folgenden Kapiteln vorgestellten Verfahren.

DDV

DDV steht für DES-DES-Verfahren. Das heisst, die Nachricht selbst wird mit dem 3-Key-DES-Verfahren verschlüsselt, und auch der Nachrichtenschlüssel wird mit dem 3-Key-DES-Verfahren verschlüsselt. Dies ist eines der ersten Verfahren, welches es in zwei Versionen gibt (DDV-0 und DDV-1), diese unterscheiden sich allerdings nur in einzelnen Details.
Heute wird nur noch DDV-1 verwendet, und auch das nur noch von wenigen Banken, hauptsächlich Sparkassen.

RDH

RDH steht für RSA-DES-Hybridverfahren. Damit wird die Nachricht weiterhin mit dem 3-Key-DES-Verfahren verschlüsselt, der Nachrichten-Schlüssel aber wird mit dem RSA-Verfahren verschlüsselt. Es gibt inzwischen zahlreiche Untergruppieren dieses Verfahrens (RDH1-10), die sich jeweils in kleinen Details und in der Schlüssellänge unterscheiden. RDH-1 war das erste Verfahren, es wird aber aufgrund der geringen und heute nicht mehr sicheren Schlüssellänge nicht mehr verwendet. Verwendet werden meist RDH2 und RDH10.
Dieses Verfahren kann Schlüsseldateien oder Chipkarten verwenden.

RAH

RAH steht für RSA-AES-Hybridverfahren. Hier wird die Nachricht mit AES-256 verschlüsselt, der Nachrichtenschlüssel dann mit RSA. Auch hier sind Varianten möglich (zur Zeit hauptsächlich nur RAH-10).
Dieses Verfahren kann Schlüsseldateien oder Chipkarten verwenden.