Das Home Banking Computer Interface (HBCI) ist für Bankgeschäfte im Internet die ideale Basis: Sicher, standardisiert und multibankfähig deckt es alle wichtigen Geschäftsvorfälle ab. Dieser Beitrag erklärt Aufbau und Abläufe sowie die Sicherheitsmechanismen.

Über das Home Banking Computer Interface (HBCI) verbindet sich der eigene PC durch das Internet mit einem Bankserver. Viele Kreditinstitute bieten Onlinebanking über dieses standardisierte Protokoll an; mit Hilfe fertiger Bibliotheken lässt sich HBCI recht einfach in eigene Programme einbinden.

Zu den wichtigsten unterstützten Geschäftsvorfällen gehören Überweisungen jeder Art (terminiert, vorbereitet, auch Eilüberweisung), Lastschriften und Daueraufträge. Der Bankkunde kann alle Transaktionen auch in einem Sammelauftrag anstoßen. Weitere Funktionen sind Kontoinformationen (etwa Kontoauszug oder Umsatzanzeige) sowie Termineinlagen, Wertpapiergeschäfte, Zahlungsverkehr ins Ausland, Kartenbestellung, Kartensperre, Reisescheckbestellung und Geldkartentransaktionen.

Die erste Version wurde Ende 1996 im Auftrag des ZKA (Zentraler Kreditausschuss) in Deutschland erstellt und laufend um neue Arten von Bankaufträgen ergänzt. Inzwischen ist HBCI bei Version 3.0 angelangt und trägt nun den Namen Fin TS (Financial Transaction Services).

Bankserver, Kundensystem und Sicherheitsmedium

An einem typischen HBCI-Szenario sind drei Instanzen beteiligt (siehe Abbildung 1): Bankserver, Kundensystem und Sicherheitsmedium. Der Bankserver kommuniziert mit dem Kundensystem, also dem PC, auf dem der Benutzer die Aufträge erstellt und verwaltet. Die Daten, die sich beide Systeme zusenden, sind in den meisten Fällen verschlüsselt und digital signiert.

Das Kundensystem nutzt dazu ein Sicherheitsmedium, das die kryptographischen Berechnungen durchführt und die Schlüssel sicher speichert. HBCI legt fest, welche Arten von Sicherheitsmedien zugelassen sind und wie sie mit dem Kundensystem kommunizieren. Drei Medien sind derzeit spezifiziert:

• Softwaremodul mit Diskette
• Chipkarte
• PIN/TAN-Verfahren

Die einfachste Variante ist ein Software-Sicherheitsmodul, das die Schlüssel auf einer Diskette speichert, die der Bankkunde sicher aufbewahren muss. Diese Lösung ist nicht besonders zuverlässig. Ihr Vorteil ist, dass der Benutzer keine zusätzliche Sicherheitshardware installieren muss und dass das Softwaremodul komplexere kryptographische Operationen durchführen kann als eine typische Chipkarte.

Chipkarten sind dennoch die bessere Technik. Sie speichern die Schlüssel und führen die Krypto-Berechnungen selbst aus, die Schlüssel verlassen die Chipkarte in keinem Fall. Mittlerweile sind einfache Chipkartenleser recht preiswert (siehe Artikel in diesem Heft), die meisten Banken versorgen ihre Kunden daher mit einem HBCI-Kit inklusive Leser.

Neu: PIN und TAN statt Chipkarte oder Diskette

Neu in der aktuellen HBCI-Version ist das Sicherheitsverfahren PIN/TAN. Obwohl weit verbreitet und bekannt, war es in den ersten HBCI-Versionen nicht enthalten. Es gilt als umständlich und nicht ausreichend sicher. Dass HBCI mit PIN/TAN nun doch standardisiert wurde, liegt an den Eigenschaften mobiler Geräte: Deren CPU ist für ein Software-Kryptomodul meist zu langsam und für einen Chipkartenleser ist kein Platz vorhanden. Dennoch sollen die Bankkunden auch mit dem Handy HBCI-Geschäfte abwickeln können.

Ohne weitere Geräte müssten die Kunden lange TAN-Listen mitführen – das wäre unpraktisch und unsicher. Um diesen Schwachpunkt zu vermeiden, gibt es Pläne für eine chipkartenbasierte Lösung: Der Benutzer wird künftig einen TAN-Generator in Form eines Schlüsselanhängers erhalten, der mit Hilfe der HBCI-Chipkarte jederzeit gültige TANs erzeugt. Das kombiniert die besten Eigenschaften beider Verfahren: Zu Hause am PC nutzt der Kunde die Chipkarte direkt für HBCI-Banking, unterwegs verwendet er den TAN-Generator zusammen mit derselben Chipkarte.

Abbildung 1: In einer HBCI-Transaktion kommuniziert das Kundensystem mit dem Bankserver. Für Sicherheitsaufgaben greift es auf spezielle Medien zu.

Aufbau einer HBCI-Nachricht

Das HBCI-Protokoll überträgt die Bankaufträge als Textnachrichten im international normierten Zeichensatz ISO 8859. Meist kommt ein sprachspezifisches Subset des Codesets Latin-1 zum Einsatz. Definiert sind derzeit Subsets für Deutsch, Englisch und Französisch, weitere lassen sich nach Bedarf hinzufügen. Alle Felder einer Nachricht, die keine binären Daten enthalten, sind in diesem Zeichensatz kodiert.

Abbildung 2 zeigt den prinzipiellen Aufbau einer HBCI- Nachricht. Das Da-tenelement (DE) ist die kleinste syntaktische Einheit. Meist beschreibt es ein einzelnes Element eines Auftrags, zum Beispiel eine Kontonummer oder eine Bankleitzahl. Ein Datenelement besitzt keinen Header, um die Nachricht kompakt zu halten. Seine Bedeutung lässt sich daher nur aus der Position innerhalb der Nachricht bestimmen.

Logisch zusammengehörende DEs fasst das Protokoll zu Datenelementgruppen (DEG) zusammen, jedes darin enthaltene DE heißt Gruppendatenelement (GDE). Die Bedeutung eines DEGs ist ebenfalls durch seine Position gegeben.

Abbildung 2: Eine HBCI-Nachricht besteht aus Segmenten, die jeweils mehrere Datenelemente und Datenelementgruppen aufnehmen können. In einer Datenelementgruppe (DEG) befinden sich Gruppendatenelemente (GDE).

Datenelemente, Gruppen und Segmente

DEs und DEGs, die logisch zusammengehören, fasst HBCI zu Segmenten zusammen (SEG). Ein Segment beschreibt einen kompletten Geschäftsvorfall, zum Beispiel eine Überweisung. Jedes Segment beginnt mit einen Segmentkopf, darauf folgen mehrere DEs und DEGs. Der Kopf ist auch nur eine DEG, er enthält aber die eindeutige Segmentkennung. Die Kennung sagt dem Empfänger, was das Segment bedeutet. Er weiß damit auch, welche DEs und DEGs im Segment enthalten sind, ihre Reihenfolge ist für jede Kennung exakt festgelegt.

Eine vollständige HBCI-Nachricht beginnt mit einem Nachrichtenkopf, gefolgt von mehreren Segmenten, und endet mit einem Nachrichtenabschluss. Nachrichtenkopf und -abschluss sind selbst Segmente. HBCI nutzt für administrative Zwecke noch weitere Segmente, etwa Signaturkopf und Signaturabschluss.

Das passende Trennzeichen: Punkt, Komma oder Strich

Die einzelnen Felder einer Nachricht sind durch spezielle Zeichen getrennt. Damit bleibt das Protokoll recht einfach und flexibel. Es überträgt immer nur so viele Zeichen wie nötig – HBCI verzichtet auf Zusatzinformationen wie Name und Länge eines Feldes, da der Empfänger sie aus der Definition des jeweiligen Segments bereits kennt. Optionale Elemente befinden sich immer am Ende der Datenstrukturen, der Absender kann sie weglassen, falls sie leer sind.

Tabelle 1 zeigt die Trennzeichen und ihre Bedeutung. Ein Segment ist damit wie folgt aufgebaut:

Segmentkopf+DE1+GDE2:GDE3:GDE4+DE5+++DE8'

Es beginnt mit dem Segmentkopf, das erste Inhaltselement ist das Datenelement DE1. Es folgt eine Datenelementgruppe mit GDE2, GDE3 und GDE4, anschließend folgt DE5 (nicht mehr in der Gruppe enthalten).

Die Datenelemente DE6 und DE7 haben in diesem Beispiel keinen Inhalt, der Absender lässt sie daher leer. Die Trennzeichen sind jedoch geblieben, sodass der Empfänger das nächste DE richtig zuordnen kann. Nach dem letzten Datenelement (DE8) folgt noch das Segmentende-Zeichen »\’«. Die Spezifikation dieses Segments könnte zehn Datenelemente vorsehen, wobei im Beispiel die beiden letzten nicht gebraucht und daher weggelassen wurden: Nach DE8 folgt unmittelbar das Segmentende. E

Dieser prinzipielle Aufbau lässt sich anhand einer Einzelüberweisung gut nachvollziehen:

HKUEB:4:5+1234567::280:10020030+
9876543::280:40050060+Hans Mustermann++
500,:EUR+51+000+Flugticket:und Mietwagen'

Der Segmentkopf lautet »HKUEB:4:5«. Er enthält die Kennung des Segments, die Segmentnummer sowie eine Versionsangabe. Die Bankverbindung des Auftraggebers »1234567::280:10020030« besteht aus der Kontonummer, einem Unterkontomerkmal (hier leer), dem Ländercode und der Kreditinstitutskennung (also der Bankleitzahl).

Die gleichen Elemente finden sich in der Bankverbindung des Empfängers »9876543::280:40050060«, darauf folgen sein Name »Hans Mustermann«, der Betrag und die Währung »500,:EUR« sowie der Textschlüssel »51« und dessen Ergänzung »000«. Der Textschlüssel bezeichnet die gewünschte Zahlungsart. Den Abschluss bildet dann die zweizeilige Angabe des Verwendungszwecks: »Flugticket:und Mietwagen«.

Falls ein Trennzeichen innerhalb eines Datenelements vorkommen soll, muss der Absender dessen Sonderrolle neutralisieren. Dazu setzt er das Freigabezeichen »?« unmittelbar vor das ungewollte Trennzeichen. Lautet der Verwendungszweck einer Überweisung »Kosten für Hotel + Mietwagen«, dann sendet HBCI folgendes DE:

...+Kosten für Hotel ?+ Mietwagen+...

Binäre Daten

Neben reinem Text überträgt das HBCI-Protokoll auch binäre Daten, und zwar Byte-weise. Ein DE mit binärem Inhalt beginnt mit dem Zeichen »@«, darauf folgen die Länge der Daten in Byte, dann ein weiteres Binärdatenzeichen »@« und schließlich die Daten selbst. Bei einem 10-Byte-Datenblock würde das wie folgt aussehen:

...+@10@Binärdaten+...

Das Kommunikationsmedium muss dafür alle Bytes unverfälscht übertragen. Bei HBCI über TCP/IP ist das gegeben, andere Kanäle könnten aber Probleme bereiten. Kritisch sind häufig Steuerzeichen, insbesondere das Null-Byte.

Eine HBCI-Nachricht darf mehrere Segmente enthalten. Da jedes Segment einen kompletten Bankauftrag beschreibt, kann der Kunde mehrere Aufträge auf einmal an einen Bankserver übermitteln. HBCI erlaubt auch verschiedene Auftragsarten pro Nachricht. Damit ergibt sich der logische Nachrichtenaufbau in Abbildung 3.

Abbildung 3: Eine einzelne HBCI-Nachricht kann mehrere Aufträge zusammenfassen, auch die Art der Aufträge darf sich unterscheiden.

Der HBCI-Dialog

Bevor das Kundensystem HBCI-Nachrichten zum Bankserver übermittelt, muss es einen HBCI-Dialog starten (Abbildung 4). Während des Dialogs übertragen die Systeme ihre HBCI-Nachrichten synchron. Auf jede Nachricht folgt eine (genau definierte) Antwortnachricht; erst wenn er diese Antwort empfangen hat, darf der Client eine neue Nachricht senden. Das Kundensystem startet den Dialog mit einer Initialisierungsnachricht und beendet ihn mit einer Dialogende-Nachricht.

Ein HBCI-Dialog bezieht sich immer auf einen einzelnen Benutzer. Falls dieser mehrere Konten bei einer Bank besitzt, kann er innerhalb des Dialogs Aufträge für jedes der Konten erteilen. Innerhalb einer physikalischen Verbindung können auch mehrere Benutzer mit der Bank kommunizieren, sie führen ihre Dialoge dann nacheinander durch.

Abbildung 4: Innerhalb eines HBCI-Dialogs (hellblau) kann das Kundensystem mehrere Aufträge (grün) an das Banksystem senden.

Vorzeitiger Abbruch

Normalerweise beendet das Kundensystem den Dialog. Falls das Kreditinstitut die Sitzung vorzeitig schließen möchte, etwa weil die Kundenauthentifizierung fehlgeschlagen ist, sendet es einen Abbruch-Code, der die Sitzung sofort als geschlossen deklariert. Das Kundensystem muss dann keine Dialogende-Nachricht mehr senden.

Der Dialog schafft eine sichere Übertragungsumgebung für die HBCI-Nachrichten. Während der Initialisierung authentifiziert sich der Kunde erst gegenüber seinem Sicherheitsmedium, danach findet eine gegenseitige Authentifizierung zwischen Kunde und Bank statt. Dabei vereinbaren sie einige Kommunikationsparameter, etwa die Dialogsprache oder die kryptographischen Schlüssel und Algorithmen. Die wichtigsten Segmente der Dialog-Initialisierungsnachricht und der Antwort sind in Tabelle 2 zu sehen.

Charakter einer Bank

Zwei Parametersätze definieren die Fähigkeiten beider Seiten. Die User-Parameterdaten (UPD) beschreiben die Eigenschaften des Benutzers, die Bank-Parameterdaten (BPD) jene der Bank (Tabelle 3). Beide Sätze werden von der Bank generiert und am Kundensystem gespeichert. Bei der Dialoginitialisierung wählt das Kundensystem ein Verschlüsselungs- und ein Signaturverfahren und legt weitere Kommunikationsparameter fest. Falls die Bank bei der Dialoginitialisierung veraltete Parameterdaten feststellt (anhand der Versionsnummer), antwortet sie mit einer aktuellen Version, sodass das Kundensystem immer den aktuellen Stand kennt.

Die BPD beschreiben allgemeine Charakteristika des Bankinstituts. Anhand dieser Daten passt das Kundensystem seine Oberfläche an: Falls die Bank bei Überweisungen nur zwei Zeilen Verwendungszweck erlaubt, zeigt die Software auch nur zwei Zeilen an.

Nach der Dialoginitialisierung beginnt der Client mit dem Senden der Auftragsnachrichten. Die Antworten des Banksystems zeigen ihm, ob jeder Auftrag korrekt ausgeführt wurde. Im Falle eines Fehlers sind die Rückmeldecodes ziemlich genau. Ein Fehlercode bezieht sich entweder auf die ganze Nachricht, auf ein Segment oder auf ein Datenelement. So kann das Kundensystem den Benutzer ausführlich informieren und passende Hilfe anbieten. War zum Beispiel eine BLZ fehlerhaft, so könnte das Kundensystem automatisch eine Liste gültiger Bankleitzahlen anbieten.

Wenn während des Dialogs viel Zeit zwischen zwei Nachrichten verstreicht, dann könnte ein Timeout des Banksystems den Dialog vorzeitig abbrechen. Um das zu vermeiden, sieht HBCI die Life-Indikator-Nachrichten vor, die das Kundensystem periodisch an den Bankserver sendet.

Das HBCI-Statusprotokoll

Falls während eines HBCI-Dialogs die Verbindung abbricht, weiß der Benutzer ohne zusätzliche Vorkehrungen nicht, ob die Bank seine Nachricht empfangen hat. Er könnte den Auftrag wiederholen und hoffen, dass die Bank ihn nicht doppelt ausführt, falls er schon beim ersten Mal richtig angekommen ist. HBCI löst dieses Problem elegant per Dialoginitialisierung mit Synchronisation.

Bei der Synchronisation erhält jede Nachricht eine fortlaufende Nummer, die die Bank in ihren Antwortnachrichten zurückschickt. Damit kann das Kundensystem nach einem Verbindungsabbruch ermitteln, ob die Bank den letzten Auftrag erhalten hat: Es öffnet eine neue Verbindung und fordert während der Dialoginitialisierung eine Synchronisation an, die Bank antwortet mit der Nummer des letzten ihr bekannten Auftrags.

Mit dem Statusprotokoll fragt der Benutzer die Bank, wie weit sie seine Aufträge schon abgewickelt hat. Die Bank kann Aufträge synchron oder asynchron ausführen: Einen synchronen Auftrag muss sie vollständig ausführen, bevor sie antwortet. Die Antwort enthält dann auch das Ergebnis. Im asynchronen Fall gibt der Benutzer seine Aufträge an das Kreditinstitut und erhält als Antwort nur “Auftrag entgegengenommen”. Er kann dann später per Statusprotokoll den Erfolg seiner Aufträge erfahren, etwa am nächsten Tag prüfen, ob die Bank alle Wertpapiergeschäfte abgeschlossen hat.

Sicherheitsmechanismen

HBCI überträgt im Allgemeinen alle Nachrichten verschlüsselt, die einzige Ausnahme ist der anonyme Zugang. Bei anonymen Klienten beantwortet die Bank nur besondere Aufträge, etwa Informationen über die Kreditvergabe. Die meisten Aufträge sind verschlüsselt und zusätzlich digital signiert, damit die Bank ihre Herkunft eindeutig bestimmen kann. Eine digitale Signatur in den Antworten der Bank ist optional.

Die Sicherheitsklasse jeder Auftragsart zeigt, ob eine digitale Signatur nötig ist:

• 0: Kein Sicherheitsdienst notwendig
• 1: Authentifikation erforderlich
• 2 bis 4: Nichtabstreitbarkeit

Die Bank-Parameterdaten enthalten unter anderem die Sicherheitsklasse jeder Auftragsart. Für Klasse-0-Aufträge muss keine rechtsverbindliche Willenserklärung des Benutzers vorliegen, bei den Klassen 1 bis 4 ist eine digitale Signatur nötig. Durch die Authentifikation kann die Bank den Ursprung der Nachricht eindeutig bestimmen, die Nichtabstreitbarkeit verhindert zusätzlich, dass der Benutzer nachträglich die Erstellung des Auftrags leugnet.

Nichtabstreitbarkeit ist die strengere Variante, HBCI verwendet dazu Signaturen mit einer höheren Sicherheitsstufe (vor allem längere Schlüssel) und einen separaten Schlüsselsatz. Für die Klassen 2 bis 4 gelten die Regelungen des Signaturgesetzes, die Signaturen haben also vor Gericht Beweiskraft.

Der Kunde besitzt einen Signaturschlüssel und einen separaten Verschlüsselungsschlüssel. Die Bank kann auch einen dritten Schlüssel für digitale Signaturen verlangen, den muss er dann für Aufträge der Sicherheitsklassen 2 bis 4 verwenden.

Digital signiert

Bevor er sie verschlüsselt, signiert der Absender seine Nachricht (Abbildung 5, Mitte), wobei er sie um zwei Segmente erweitert: Signaturkopf und Signaturabschluss. Der Kopf enthält Informationen über den verwendeten Signaturalgorithmus sowie das Zertifikat des Signierers. Im Signaturabschluss ist die digitale Signatur zu finden. Manche Aufträge erfordern mehrfache Signaturen, etwa wenn das Einverständnis mehrerer Kontoinhaber vorliegen muss. In diesem Fall stehen die Signaturköpfe nacheinander in der Nachricht, dann folgen die signierten Daten und am Ende mehrere Signaturabschlüsse.

Abbildung 5: Der Absender muss die Auftragselemente seiner HBCI-Nachricht (links) zunächst signieren (Mitte) und danach verschlüsseln (rechts).

Komprimiert und verschlüsselt

Die signierte Nachricht wird dann vom Absender komprimiert und verschlüsselt, inklusive aller Signaturköpfe und Signaturabschlüsse. Dazu fügt er einen Verschlüsselungskopf ein (Abbildung 5, rechts), der Informationen über den verwendeten Verschlüsselungs- und Komprimierungsalgorithmus enthält. Für jede Nachricht setzt das Kundensystem einen neuen Schlüssel ein, den es aus einer Zufallszahl und dem Verschlüsselungsschlüssel des Benutzers berechnet. Diesen Nachrichtenschlüssel verschlüsselt es mit dem Kundenschlüssel und hängt ihn an die Nachricht. Die Gegenstelle entschlüsselt erst den Nachrichtenschlüssel und dann – mit dessen Hilfe – die Nachricht.

HBCI verwendet für die Krypto-Operationen zwei Verfahren: Die asymmetrische Variante basiert auf RSA, die symmetrische auf DES. Der Kasten “DES, MAC, RSA und Hash” erklärt einige Grundlagen.

Das richtige Verfahren: DDV oder RDH?

Das symmetrische Verfahren nennt sich DDV (DES-DES-Verfahren). Der Absender signiert seine Nachrichten hier mit einem DES-basierten MAC, obwohl sich symmetrische Verfahren eigentlich nicht für digitale Signaturen eignen. Die Verschlüsselung der Daten findet mit 2-Key-Triple-DES im CBC-Modus statt. Das Kundensystem muss den MAC selbst berechnen, für die Verschlüsselung ist die Chipkarte zuständig – die EC-Karte mit Chip ist hierfür zugelassen.

Das asymmetrische Verfahren lautet RDH (RSA-DES-Hybridverfahren). Es benutzt RSA für digitale Signaturen und ebenfalls 2-Key-Triple-DES im CBC-Modus zum Verschlüsseln. Der Bankkunde führt die Signatur und die Verschlüsselung entweder per Softwaremodul mit Diskette als Schlüsselspeicher durch oder besser mit einer signaturfähigen Chipkarte. Bislang war es erlaubt, proprietäre Chipkarten für RDH einzusetzen. Heute gibt es die ZKA-Chipkarte, die auch für HBCI geeignet ist und standardmäßig zum Einsatz kommt.

01 // API-Objekt erstellen:
02 HBCI::API *myapi=new HBCI::API();
03 
04 // Konfigurationsdatei laden:
05 myapi->loadEnvironment("HbciConfigFile");
06 
07 // Auftragsobjekt erstellen:
08 HBCI::OutboxJobGetAccounts job1(MyCustomerObject);
09 
10 // Auftragsobjekt in Bearbeitungsliste eintragen:
11 myapi->addJob(job1.cast<OutboxJob>());
12 
13 // Hier weitere Auftragsobjekte instanziieren
14 // und zur Bearbeitungsliste hinzufügen.
15 
16 // Bearbeitungsliste ausführen:
17 Error e=myapi->executeQueue();
18 
19 // Sind Fehler aufgetreten?
20 if(e.isOK()==false) {
21     // Benutzer informieren:
22     cout << e.errorString();
23     // Aufräumen und Terminieren...
24 }
25 
26 // Geänderte Informationen speichern:
27 myapi->saveEnvironment("HbciConfigFile");

Passende Parameter für DDV und RDH

Beide Verfahren lassen sich unterschiedlich parametrisieren. Um die Multibankfähigkeit zu garantieren, sind ein Parametersatz für DDV und vier für RDH standardisiert. HBCI-Clients müssen nicht zwingend alle Sätze implementieren, das Kundensystem wählt die Parameter aus. Eine Übersicht dieser Sicherheitsprofile zeigt Tabelle 4. In den Sicherheitsprofilen spiegelt sich auch die Entwicklung von HBCI: DDV-1, RDH-1 und RDH-2 sind die älteren Profile, RDH-3 und 4 die heute üblichen.

Für DDV ist eine einfache symmetrische Chipkarte nötig. Die EC-Karten mit Chip sind dafür ausreichend und folglich für DDV zugelassen, der Benutzer benötigt keine zusätzliche HBCI-Karte. Allerdings ist die Verwendung von MAC zum digitalen Signieren problematisch: Die Bank könnte jede Signatur, die vom Benutzer stammt, auch selbst erzeugen – Bank und Kunde benutzen denselben Schlüssel. Ein gewisses Vertrauensverhältnis zwischen beiden vorausgesetzt, ist dieses Problem nicht gravierend.

RDH-1 und 2 verwenden RSA mit 768-Bit-Schlüssel, mehr konnten die ersten signaturfähigen Chipkarten nicht verarbeiten. Da solche Karten teuer waren, ist im HBCI-Standard auch die Softwarelösung zugelassen. Signaturfähige Chipkarten sind mittlerweile wesentlich billiger, sodass HBCI 3.0 das Sicherheitsprofil RDH-3 als verpflichtend für Kundenprodukte und Banken spezifiziert. Alle anderen RDH-Profile sind optional für Kundenprodukte.

Bewertung

Die Sicherheitsmechanismen von HBCI sind gut genug, um bewusst auf zusätzliche Sicherheitsmechanismen, die das Kommunikationsmedium eventuell anbietet, zu verzichten. Im Falle von TCP/IP ist daher keine SSL-Verschlüsselung erforderlich. Der Standard verbietet es zwar nicht, ein zusätzlich gesicherter Kommunikationskanal gilt jedoch als überflüssig.

Das RDH-3-Verfahren bietet sehr gute Sicherheitseigenschaften. RSA-Schlüssel mit 2048 Bit werden heute als sehr sicher angesehen, längere Schlüssel könnten die derzeit verfügbaren Chipkarten auch nicht verarbeiten. Die Verschlüsselung der Nachrichten ist ebenfalls ausreichend. Es gibt zwar neuere Algorithmen als Triple-DES, es ist jedoch weit verbreitet und bewährt. Außerdem unterstützt fast jede Chipkarte DES, aber kaum eine beherrscht neuere Algorithmen wie etwa AES.

Neu für HBCI ist das PIN/TAN-Sicherheitsverfahren, das in Version 3.0 standardisiert wurde. Die Spezifikation enthält zusätzliche Segmente, um die TANs des Benutzers und die entsprechenden Zusatzinformationen zu übertragen. Dieses Verfahren benutzt keine digitalen Signaturen, es ersetzt in gewisser Weise die Signatur durch eine TAN.

Fazit

HBCI ist ein sehr vielseitiges Protokoll, das in der vorliegenden Version praktisch alle Bankaufträge unterstützt und mit sehr guten Sicherheitseigenschaften ausgestattet ist. Mit fertigen Bibliotheken und Modulen (siehe Kasten “HBCI-Bibliotheken”) können die Entwickler HBCI-Funktionalität sehr einfach in ihre Finanzsoftware einbinden. Auch komplette HBCI-Systeme sind damit realisierbar, die sich leicht in existierende Infrastrukturen integrieren lassen.

Da mittlerweile auch die Spezifikation der signaturfähigen ZKA-Chipkarte fertig gestellt ist, sind die Rahmenbedingungen für HBCI günstig. Seit der Einführung im Jahr 1996 wird HBCI zunehmend benutzt und unterstützt. (fjl)