Homebanking Computer Interface
Matthias Kunzelmann
Inhaltsverzeichnis
1. Einleitung
2. Nachrichtenaufbau
2.1. Nachrichtenelemente
2.1.1. Nachricht
2.1.2. Segmentfolge
2.1.3. Segment
2.1.4. Datenelementgruppe
2.1.5. Datenelement
2.2. Syntax
3. Bankparameterdaten (BPD) und
Userparameterdaten (UPD)
3.1. Bankparameterdaten
3.2. Userparameterdaten
4. Dialogspezifikation
4.1. Begrifflichkeiten
4.2. Dialogabfolge
4.3 Dialog
4.3.1 Dialoginitalisierung
4.3.1.1. Kundennachricht
4.3.1.2. Kreditinstitutsnachricht
4.3.2. Dialogbeendigung
4.4. Verbindungsabbruch
4.5. Statusprotokoll
5. Sicherheit
5.1. Elektronische Signatur
5.2. Verschlüsselung
5.2.1. Chiffrierung des Nachrichtenschlüssels mit DES bei DDV
5.2.2. Chiffrierung des Nachrichtenschlüssels mit RSA bei RDH
5.3. Signatur und Verschlüsselung
6. Geschäftsvorfälle
7. Fazit
Glossar
Abbildungen
Literatur
Unter Homebanking wird die Geschäftsabwicklung von Bankgeschäften über
einen PC oder andere intelligente Endgeräte (z.B.: Komfort- oder
Mobiltelefone) verstanden. So ist auch eine Abgrenzung zum
Telefonbanking möglich, das oft nur zum Informationsabruf genutzt wird
und bei dem das Kommunikationsmedium die Sprache ist.
Zur Zeit wird Homebanking zum größten Teil auf der Basis von T-Online
(ehemals BTX) betrieben. Die auf diesen Grundlagen basierenden
Homebankingsysteme sind meist unkomfortabel und nicht multibankfähig,
so daß jede Anwendung einer neuen Installation bedarf. Das derzeit
gängigste Verfahren ist das PIN/TAN-Verfahren, bei dem sich der Kunde
durch eine persönliche Identifikationsnummer (PIN) authentifiziert und
für jede Kontobewegung eine Transaktionsnummer (TAN) eingeben muß, die
ihm als Liste auf dem Postweg zugestellt wird.
Es ist ersichtlich, daß es zur Zeit im Bereich des Homebankings keinen
Standard gibt. Dies ist einer der Gründe, daß HBCI als eine
multibankfähige, plattformunabhängige und komfortable Lösung vom ZKA entwickelt und vorangetrieben
wird. HBCI stellt bis jetzt nur eine nationale Lösung dar. Sie soll
zwar als europäischer Standard vorgeschlagen werden, doch weltweit
gibt es noch einige andere Ansätze, einen komfortablen,
multibankfähigen Homebankingstandard zu schaffen. Diese Ansätze, wie
z.B. IFX (Interactive Financial Exchange), OFX (Open Financial Exchange) und SET (Secure Electronic Transaction) sind meist auf
den nordamerikanischen Markt zugeschnitten und können deshalb nicht
eins zu eins nach Europa übertragen werden.
Ziel dieser Arbeit ist es, HBCI in der Version 2.1 in seinen
Grundzügen darzustellen. Einer besonderen Betrachtung unterliegt die
informatische Seite dieser Schnittstelle. Aus diesem Grund wird auch
besonders ausführlich auf die Kapitel Dialogspezifikation und
Sicherheit eingegangen.
Für das weitere Verständnis der Thematik ist es von großer Bedeutung,
den Aufbau einer Nachricht aus verschiedenen Typen von untergeordneten
Bausteinen im HBCI- Dialog verstanden zu haben.
In diesem Abschnitt soll nur der Aufbau einer Nachricht erörtert
werden. Die Semantik der einzelnen Nachrichten wird in späteren
Kapiteln jeweils im Dialogzusammenhang dargestellt.
Der HBCI-Dialog zwischen dem Kunden und einem Kreditinstitut wird
durch das abwechselnde Senden von Nachrichten geführt. Eine Nachricht
ist die größte syntaktische Einheit unter HBCI. Diese besteht immer
aus einem Nachrichtenkopf, einer Reihe von Segmentfolgen und einem
Nachrichtenabschluß, wobei erst- und letztgenannter selbst auch
Segmentfolgen sind.
Die Segmentfolge beschreibt eine logisch, nicht jedoch zwingend
syntaktisch, zusammenhängende Menge von Segmenten, die nur gemeinsam
auftreten dürfen.
Ein Segment besteht aus Datenelementen und aus
Datenelementgruppen. Die Datenelementgruppe Segmentkopf steht zu
Anfang eines jeden Elements. Das Ende eines Elements wird durch das
Segmentabschlußzeichen " ' " angezeigt.
Eine beliebige Anzahl von zusammengehörenden Informationen, die
jeweils in Gruppendatenelementen abgelegt werden, bilden zusammen die
syntaktische Einheit einer Datenelementgruppe.
Zusammen mit den Gruppendatenelementen bilden die Datenelemente die
kleinsten syntaktischen Informationseinheiten unter HBCI.
Wird eine Nachricht oder ein Nachrichtenelement genauer spezifiziert,
so werden für die einzelnen untergeordneten Nachrichtenelemente, aus
denen sie oder es zusammengesetzt ist, deren Namen, Format, Länge,
Status und deren Anzahl sowie eventuell auftretende Restriktionen
festgelegt. Die Formatangabe bestimmt, ob z.B. Ziffern, Text oder
alphanumerische Zeichen in ein Datenelement oder Gruppendatenelement
aufgenommen werden dürfen. Für größere Nachrichtenelemente können auch
vordefinierte Formate angegeben werden. Beim Status wird
unterschieden, ob das jeweilige Nachrichtenelement belegt werden muß
(M) oder nicht (K für "kann"). Restriktionen können in verschiedenen
Arten auftreten und sind von dem jeweiligen Typ des
Nachrichtenelements abhängig, auf den sie sich beziehen.
Es wird die Trennzeichensyntax von EDIFACT verwendet, die sich neben diesem
auch in anderen Systemen bewährt hat.
Datenelemente und Datenelementgruppen werden durch "+" voneinander
getrennt. Gruppendatenelemente werden durch ":" getrennt. Zwischen
Segmenten in einer Segmentfolge befindet sich kein Trennzeichen, da
diese durch das Segmentabschlußzeichen voneinander getrennt
werden. Befindet sich in einem Datenelemtent oder einer
Datenelementgruppe ein Syntaxzeichen, so wird dieses durch ein
vorangestelltes Fragezeichen "entwertet". Elemente eines Segments, die
nicht belegt werden müssen, können, wenn noch weitere Elemente folgen,
ausgelassen werden, bzw., wenn sie sich am Ende des Segment befinden,
wegfallen.
| Nr. | Name | Typ |
Format | Länge | Status | Anzahl |
Restriktionen |
| 1 | Kontobezeichnung | DE | an |
..35 | M | 1 | |
| 2 | Kontosaldo | DEG | sdo |
# | M | 1 | |
| 3 | Beschreibung | DE | an |
..35 | M | 1 | |
| GIROKONTO+C:1000,:19960701+Beschreibung |
Mit den BPD können institutsseitig die Kundensysteme automatisch für
die einzelnen Kreditinstitute konfiguriert und dynamisch an die
Vorgaben der jeweiligen Kreditinstitute angepasst werden. Kommt es zu
einer Änderung der BPD durch das Kreditinstitut, so werden die
aktualisierten BPD dem Kundensystem bei der nächsten
Dialoginitialisierung übertragen. Ein intelligentes Kundenprodukt kann
überprüfen, ob die zu sendenden Nachrichten den neuen BPD genügen, und
falls dies der Fall ist, die Nachricht wie geplant übermitteln. Steht
eine solche Intelligenz nicht zur Verfügung, muß das Kundensystem nach
Erhalt von aktualisierten BPD den laufenden Dialog beenden, die
anstehenden Aufträge prüfen, gegebenenfalls entsprechend anpassen und
dann erneut einen Dialog aufbauen.
Die BPD enthalten allgemeine Informationen über Bankparameter wie
Kreditinstitutsbezeichnung und Kreditinstitutskennung, unterstützte
Sprachen und HBCI-Versionen, Anzahl von verschiedenen
Geschäftsvorfällen je Nachricht und maximale Größe der Nachricht,
sowie die aktuelle Versionsnummer der BPD. Des weiteren enthalten sie
Informationen über die bankseitig unterstützen Sicherheits- und
Komprimierungsverfahren, sowie über die minimale Anzahl von Signaturen
in Abhängigkeit des jeweiligen Geschäftsvorfalls.
Mit Hilfe der BPD ist es möglich, bestimmte Fehler bereits auf der
Kundenseite zu erkennen. So kann z.B. festgestellt werden, wenn der
freie Text einer Überweisung zu lang ist. Dies führt zum einen zu
einer Verringerung des Aufwands auf der Institutsseite, zum anderen
werden die Dialoge verkürzt, da der fehlerhafte Auftrag den Kunden
nicht verlässt, das Kreditinstitut dem Kunden beim nächsten
Dialogaufbau keine Fehlermeldung und der Kunde denselben Auftrag nicht
noch einmal in korrigierter Form schicken muß. Dies befreit die
Kreditinstitute jedoch nicht davon, jede Nachricht auf ihre
Korrektheit zu prüfen, da auf Schnittstellenebene nicht sichergestellt
werden kann, daß das Kundenprodukt die BPD richtig auswertet.
In Abgrenzung zu den UPD enthalten die BPD nur für das jeweilige
Kreditinstitut spezifische Daten, so dass eine Änderung von BPD eher
selten vorkommt.
Die UPD werden kreditinstitutsseitig benutzerbezogen generiert und
gehalten. Sie werden zur automatisierten und dynamischen Konfiguration
von Kundensystemen benutzt. Im Unterschied zu den BPD enthalten sie
nur kunden- und kontospezifische Informationen, weshalb auch häufiger
Änderungen nötig werden. Die aktualisierten UPD werden bei der
Dialoginitialisierung übertragen und im Gegensatz zu den BPD auf jeden
Fall sofort verwendet. Dennoch muss das Kreditinstitut jede Nachricht
auf deren Korrektheit überprüfen, da auf Schnittstellenebene nicht
sichergestellt werden kann, dass die UPD richtig ausgewertet wurden.
Die UPD enthalten in erster Linie Informationen über Benutzerkennung
und Kontoinformation.
Während eines HBCI-Dialogs tritt man aus Sicht des Banksystems in zwei verschiedenen
Funktionen in Erscheinung, zum einen als Benutzer und zum anderen als Kunde.
Der Benutzer ist eine natürliche Person, die dem Kreditinstitut gegenüber als
Kontoinhaber oder Kontoberechtigter gegenübertritt. Er identifiziert sich durch eine
Benutzerkennung, deren Vergabe Aufgabe des Kreditinstitutes ist und die
institutsweit eindeutig sein muss.
Der Kunde ist in diesem Fall nicht nur als Kunde im gewöhnlichen
Sprachgebrauch zu verstehen, sondern auch als institutsindividuelle
Abgrenzung der Rolle eines Benutzers, die er gegenüber einem
Kreditinstitut wahrnimmt. Es kann also unterschieden werden, ob ein
Benutzer als Privatperson auf sein eigenes Konto zugreift, oder ob er
z.B. als Bevollmächtigter einer Firma auftritt. Es ist dem
Kreditinstitut freigestellt, ob es jedem Benutzer für seine jeweilige
Rolle verschiedene Benutzerkennungen gibt. Ist dies nicht der Fall, so
erhält ein Benutzer für seine Rollen jeweils eine eigene Kunden-ID,
bzw. im Fall, daß er nur eine Kunden-ID hat, wird seine Rolle im
nachgelagerten operativen System festgelegt.
Ein Dialog geht stets von einem Kunden aus und wird mit einer
Dialoginitialisierungsnachricht begonnen. Darauf folgt vom Institut
eine Antwort auf die Dialoginitialisierung. Nun kann der Kunde eine
Nachricht schicken und wartet dann wieder, bis er eine Antwort vom
Institut erhalten hat. Dies wiederholt sich, bis der Kunde den Dialog
beenden will. Dazu wartet das Kundenprodukt die letzte
Antwortnachricht des Kreditinstituts ab und sendet dann eine
Dialogendenachricht. Wenn diese vom Kreditinstitut durch eine
Antwortnachricht quittiert wurde, kann der Dialog beendet werden. Auf
eine Kundennachricht folgt immer eine Kreditinstitutsnachricht, es sei
denn, ein Fehler im Dialog tritt auf oder die Verbindung wird
physikalisch getrennt.
Abb.1: Beispiel für eine Verbindung mit zwei
Dialogfolgen.
Prinzipiell ist jeder Dialog von Beginn an zu verschlüsseln. Die
einzigen Ausnahmen, auf die im Rahmen dieser Arbeit nicht weiter
eingegangen werden soll, bilden der anonyme Zugang, die erstmalige
Anforderung der öffentlichen Schlüssel des Kreditinstitutes, die
Schlüsselsperrung durch den Kunden sowie die Anforderung eines
Kommunikationszugangs. Während eines Dialogs darf nur ein
Verschlüsselungsverfahren benutzt werden. Wählt der Benutzer in der
Dialoginitialisierungsnachricht aufgrund von veralteten oder
unbekannten BPD ein Verfahren, das die Bank nicht unterstützt, so
bekommt der Kunde eine entsprechende Rückmeldung und der Dialog wird
beendet. Das Kundenprodukt wird diese Rückmeldung nicht entschlüsseln
können, da es das vom Institut gewählte Verfahren nicht
unterstützt. Es wird der Nachricht entnehmen, dass es ein von der Bank
nicht zugelassenes Verfahren benutzt und sich über den anonymen
unverschlüsselten Zugang die aktuellen BPD beschaffen. Diesen kann es
dann entnehmen, welche Verschlüsselungsverfahren das Kreditinstitut
unterstützt.
Zu den Aufgaben der Dialoginitialisierung, die aus Kunden- und
Kreditinstitutsnachricht besteht, gehört die Prüfung, ob der
Kommunikationspartner ein sendebrechtigter Kunde ist und ob die UPD,
BPD und der öffentliche Schlüssel des Kreditinstitutes aktuell sind;
falls dies nicht der Fall ist, folgt deren Aktualisierung. Des
weiteren wird eine Dialog-ID, auf die man sich in späteren Nachrichten
beziehen kann, festgelegt. Es werden vorbereitete Informationen für
die kunden- und kreditinstitutsseitge Verarbeitung übermittelt und es
erfolgt die Übertragung von Kreditinstitutsmeldungen.
Die Dialoginitialisierungsnachricht kann entweder von dem Benutzer,
der sich im Rahmen der Dialoginitialisierung angemeldet hat, oder von
einem Benutzer, der für die nachfolgenden Auftraggeberkonten
bevollmächtigt ist, signiert werden.
Die Nachricht, mit der die Dialoginitialisierung begonnen wird, ist
die Kundennachricht. Sie besteht wie alle Nachrichten aus
Nachrichtenkopf und Nachrichtenabschluss, und wie alle
signaturpflichtigen Nachrichten aus Signaturkopf und
Signaturabschluss. Diese vier Elemente werden im weiteren Verlaufe
dieser Arbeit nicht bei jeder noch zu erläuternden Nachricht
genannt. Zusätzlich besteht die Kundennachricht aus den Segmenten
Identifikation, Verarbeitungsvorbereitung und 'Anforderung eines
öffentlichen Schlüssels'. Das Identifikationssegment beinhaltet die
Kreditinstitutskennung des Instituts, zu dem der Kunde Zugang haben
möchte, sowie die Kunden-ID. Zusätzlich steht in dem Segment eine
Kundensystem-ID und der Kundensystemstatus, wobei dieser im Falle der
Anwendung des DES-DES-Verfahrens (DDV) gleich null und im falle der
Anwendund des RSA-DES-Hybridverfahrenes (RDH) gleich eins ist. Er gibt
an, ob die Kundensystem-ID benötigt wird, was nur beim RDH-Verfahren
der Fall ist. Im Segment "Verarbeitungsvorbereitung" werden die
Versionsnummern von BPD und UPD eingestellt, sowie die Dialogsprache,
die Produktbezeichnung und die Produktversion. Dabei dienen die
letzten beiden Datenelemente dazu, dem Kreditinstitut die Möglichkeit
zu geben, einzelne Kundensysteme gezielt zu unterstützten. Das Segment
'Anforderung eines öffentlichen Schlüssels' ist nur im Fall von
asymmetrischen Verschlüsselungs- und Signaturverfahren zu belegen. In
diesem Fall sind die jüngsten dem Kundensystem bekannten öffentlichen
Chiffrier- und Signaturschlüssel des Kreditinstituts
einzustellen. Damit hat dann das Kreditinstitut die Möglichkeit, dem
Kunden die aktuellen Schlüssel zuzusenden, falls ihm veraltete
vorliegen.
Auf die Kundennachricht folgt, bevor der Kunde seine erste
Auftragsnachricht schicken kann, die Kreditinstitutsnachricht. Die
Kreditinstitutsnachricht beinhaltet neben Rückmeldungen zur
Gesamtnachricht und zu Segmenten die BPD und UPD, falls diese beim
Kundensystem in einer veralteten Version vorliegen. Zur Zeit müssen
die BPD und UPD jeweils stets komplett übertragen werden, d.h. das
Auslassen einzelner aktueller Segmente wird erst in späteren
HBCI-Versionen möglich sein. Zusätzlich enthält die
Kreditinstitutsnachricht noch die öffentlichen Schlüssel des
Kreditinstituts, wenn das RDH-Verfahren angewendet wird und diese
angefordert wurden. Die Schlüssel sind noch nicht verifiziert. Dies
geschieht entweder dadurch, dass die
Dialoginitialisierungs-Antwortnachricht signiert wird, oder es muss
auf alternativem Weg ein neuer Hashwert übermittelt werden. Im Segment
'Kreditinstitutsmeldungen' kann im Moment nur Freitext eingestellt
werden. Bei späteren HBCI-Versionen soll es auch möglich sein,
formatierte Meldungen oder Grafiken an den Kunden
weiterzuleiten. Diese werden dem Kunden noch während des laufenden
Dialogs zur Verfügung gestellt. Es werden in diesem Segment sowohl
allgemeine Kreditinstitutsdaten wie z.B. Konditionen, als auch
kundenspezifische Daten übermittelt.
Jeder Dialog ist mit je einer Dialogendenachricht vom Kundenprodukt
und vom Kreditinstitutssystem zu beenden. Diese Nachrichten haben zwei
Aufgaben. Zum einen teilt das Kundensystem dem Kreditinstitut mit,
dass vom Kunden keine weiteren Auftragsnachrichten folgen, zum anderen
bestätigt das Kundensystem implizit den Empfang der letzten
Antwortnachricht vom Kreditinstitut. Auf die Dialogendenachricht vom
Kundensystem folgt die des Kreditinstitutes, und damit ist der Dialog
beendet, und die Leitung wird unterbrochen oder ein neuer Dialog
begonnen. Sendet der Kunde keine Dialogendenachricht, so wird die
Leitung institutsseitig nach einer transportmedienabhängigen Zeit
automatisch unterbrochen.
Im Unterschied zu einigen anderen Homebankingsystemen kommt es bei
HBCI zu keinem kreditinstitutsseitigen Verbindungsabbruch aufgrund von
fehlerhaften Nachrichten, auch nicht, wenn schon während der
Nachrichtenübertragung ein Fehler entdeckt wird.
Wird die Leitung unbeabsichtigt unterbrochen, so sind aus
Kreditinstitutssicht vier verschiedene Fälle zu behandeln.
- Die Leitung wird während der Dialoginitialisierungsnachricht
des Kunden unterbrochen.
Der Kunde kann vom Kreditinstitut
nicht identifiziert werden und es wird keine weitere Legitimation
erteilt. Das Kreditinstitut nimmt keine Handlung vor.
- Es kommt zu einem Abbruch der Verbindung, nachdem die
Dialoginitialisierung abgelaufen ist, jedoch bevor der Kunde seine
erste Auftragsnachricht schicken kann.
Der Kunde wird vom
Kreditinstitut identifiziert, und es wird eine Legitimation erteilt.
Das Kreditinstitut erwartet eine Auftragsnachricht und bricht den
Dialog aufgrund einer Überschreitung der transportmedienspezifischen
Zeit ohne weitere Nachricht ab.
- Die Leitung wird während der Übertragung einer
Auftragsnachricht unterbrochen.
Das Kreditinstitut ignoriert
die Nachricht, bei der es zum Leitungsabbruch gekommen ist.
- Der Abbruch findet nach der Übertragung der Auftragsnachricht
an das Kreditinstitut statt, also bevor oder während dieses seine
Antwortnachricht sendet.
Das Kreditinstitut hat die
Auftragsnachricht vollständig erhalten und führt diese aus.
Abb.2: Beispiel für einen Verbindungsabbruch wie
im Fall 3 beschrieben.
Nach einem Verbindungsabbruch muß der Dialog wieder aufgenommen und
neu synchronisiert werden. Dies geschieht anhand der Signatur-ID und
der Nachrichtennummer (s. Abb. xxx) und sei hier nur der
Vollständigkeit halber erwähnt. Für den Kunden ist es von größerem
Interesse, ob sein Auftrag nach einem Verbindungsabbruch von der Bank
ausgeführt wurde oder nicht. Dies wird ihm durch das Statusprotokoll
mitgeteilt.
Grundsätzlich erzeugt jedes als Geschäftsvorfall gekennzeichnete
Segment einen Eintrag in das Statusprotokoll. In dieses werden
dieselben Meldungen eingetragen, wie sie dem Kundensystem in
Rückmeldungen zu Aufträgen in Kreditinstitutsnachrichten mitgeteilt
werden. Das Statusprotokoll enthält die jeweils letzten für ein
Kundensystem bestimmten Rückmeldungen in Bezug auf einen Auftrag, die
den Stand der Bearbeitung beschreiben. Somit ist zu jedem Zeitpunkt
für den Kunden der genaue Stand der Verarbeitung seiner Aufträge
ersichtlich.
Das Kundenprodukt sollte über ein Journal verfügen, in das alle
Statusmeldungen chronologisch eingetragen werden. Somit ist auch zu
einem späteren Zeitpunkt die Rückverfolgung von Aufträgen
sichergestellt.
Das Statusprotokoll gibt dem Kunden also, unabhängig davon ob die
Leitung unterbrochen oder der Dialog ordnungsgemäß beendet wurde, die
Möglichkeit, den genauen Status eines jeden noch nicht vollständig
abgewickelten Auftrags abzufragen. Dies ist insbesondere deshalb von
Interesse, da bei den meisten Aufträgen im Regelfall nur der Empfang
online bestätigt wird, die Verarbeitung selbst jedoch offline
geschieht.
Die Frage, wie genau der Kunde über den Bearbeitungsstatus seiner
Aufträge informiert werden soll, ist unter HBCI nicht festgeschrieben
und obliegt dem jeweiligen Kreditinstitut.
Die Statusprotokolle müssen mindestens bis zwei Buchungstage nach dem
nächsten Dialog, in dem ihr Inhalt dem Kunden in der
Kreditinstitutsantwort während der Dialoginitialisierung mitgeteilt
wurde, aufbewahrt werden, maximal jedoch sechs Monate. Dadurch kann
sichergestellt werden, daß dem Kunden keine Statusmeldung verloren
geht, gleichzeitig kann das vom Kreditinstitut vorzuhaltende
Datenvolumen auf ein akzeptables Maß reduziert werden.
Der zweite große Vorteil von HBCI, der diesen Standard zum Marktführer
machen soll, ist neben der Multibankfähigkeit der verwendete
zeitgemäße Sicherheitsmechanismus. Dieser soll vor Mißbrauch im
Bereich des Homebankings schützen.
Im Rahmen von HBCI kommen zwei Sicherheitslösungen zum Einsatz :
- das symmetrische DES-Verschlüsselungsverfahren, das auf Chipkarten basiert
- das asymmetrische RSA-Verschlüsselungsverfahren
DES wird im DDV (DES-DES-Verfahren) verwendet, RSA im RDH (RSA-DES-
Hybridverfahren). Beim DDV wird der MAC (Message Authentication Code)
zur Signatur verwendet und der Nachrichtenschlüssel mittels
2-Key-Triple-DES verschlüsselt. Der Message Authentication Code ist
das Ergebnis einer Einweg Hashfunktion und wird u.a. aus dem
Nachrichteninhalt berechnet. Er dient dazu, festzustellen, ob die
damit signierte Nachricht verändert wurde. RDH signiert mit RSA-EU und
chiffriert den Nachrichtenschlüssel mit dem RSA-Verfahren. Für die
Zukunft wird für alle Systeme eine auf dem RSA-Verfahren basierende
Chipkartenlösung angestrebt.
Die elektronische Signatur wird in drei Schritten gebildet, wobei der
erste für beide Verfahren identisch ist, die letzten beiden sich bei
DDV und RDH unterscheiden.
Diese drei Schritte sind:
- die Bildung des Hashwerts,
- die Formatierung des Hashwerts auf eine vorgegebene Länge und
- die Berechnung der elektronischen Signatur über den Hashwert.
Auf die beiden Signaturverfahren wird an dieser Stelle nicht weiter
eingegangen. Die verwendeten, grundlegenden Verfahren werden jedoch
auch bei der Verschlüsselung benötigt, auf die im folgenden Abschnitt
näher eingegangen wird.
Bei der Chiffrierung wird für jede Nachricht ein eigener Schlüssel
generiert. Die Nachricht selbst wird immer mit dem 2-Key-Triple-DES
Algorithmus gemäß ANSI X3.92 verschlüsselt. Der verwendete
Nachrichtenschlüssel wird in Abhängigkeit vom verwendeten Verfahren im
2-Key-Triple-DES (DDV) oder RSA (RDH) verschlüsselt. Um nun eine
Nachricht verschlüsseln zu können, wird zur Generierung eines
Nachrichtenschlüssels eine Zufallszahl erzeugt, für die ungerade
Parität sichergestellt werden muß. Bei dem Schlüssel ist darauf zu
achten, daß kein schwacher oder halbschwacher Schlüssel (entsprechend
dem DFÜ-Abkommen) gewählt wird.
Mit diesem Nachrichtenschlüssel wird die Nachricht nun mittels
2-Key-Triple-DES im CBC (cipher block chaining) Modus gemäß ISO 10116
(ANSI X3.106) verschlüsselt.
Es ist zu beachten, daß das Kundensystem immer die Routine Encrypt und
das Kreditinstitut immer die Routine Decrypt verwendet.
Die Verschlüsselung der Nachricht soll anhand der drei folgenden
Abbildungen veranschaulicht werden.
Abb.3: Funktionsweise des 2-Key-Triple-DES
Verfahrens im CBC-Mode.
Abb.4: Funktionsweise der 2-Key-Triple-DES
Verschlüsselung.
Abb.5: Funktionsweise der 2-Key-Tripe-DES
Entschlüsselung.
Die Verschlüsselung des Nachrichtenschlüssels erfolgt nun für DDV und
RDH auf unterschiedliche Weise.
Der Nachrichtenschlüssel, mit dem die Daten chiffriert wurden, wird
nun mittels des individuellen Chiffrierschlüssels des Kunden
verschlüsselt. Dieser Chiffrierschlüssel befindet sich auf der
Chipkarte des Kunden. Beim DDV wird als Verschlüsselungsalgorithmus
das 2-Key-Triple-DES Verfahrens im ECB (electronic codebook) Modus
verwendet.
Abb.6: Funktionsweise des 2-Key-Triple-DES
Verfahrens im ECB-Mode.
Der aktuelle Nachrichtenschlüssel, mit dem die Nachricht chiffriert
wurde, wird nun unter Anwendung des RSA-Algorithmus mit dem
öffentlichen Schlüssel des Empfängers chiffriert. Da der
Nachrichtenschlüssel beim 2-Key-Triple-DES Verfahren nur 16 Byte
d.h. 128 Bit lang ist, muß er auf 768 Bit ergänzt werden. So erreicht
er die vorgegebene Moduslänge entsprechend dem DFÜ-Abkommen.
Abb.7: Verschlüsselung des Nachrichtenschlüssels
mit dem RSA Verfahren.
Prinzipiell kann ein Kunde beim DDV zwei Schüssel bzw. beim RDH zwei
Schüsselpaare besitzen. Beim DDV verwendet er einen Schlüssel für die
Signatur von Nachrichten und einen, um den Nachrichtenschlüssel zu
chiffrieren. Beim RDH verwendet er seinen privaten Signaturschlüssel,
um die Nachricht zu signieren, und den öffentlichen Chiffrierschlüssel
des Kreditinstituts, um den Nachrichtensclüssel zu verschlüsseln.
Um eine Nachricht zu verschlüsseln und diese dann verschicken zu
können, muss diese erst einmal generiert werden. Dies geschieht, indem
zuerst die Informationen, die in die Nachricht sollen, im System des
Senders zusammengestellt werden. Nun wird die Nachricht aus den
Informationen, die in die entsprechenden Segmente überführt werden,
aufgebaut, wobei eventuell vorkommende Steuerzeichen entwertet
werden. Darauf wird die Nachricht signiert, wobei der Signaturkopf mit
in die Signatur eingeht. Bei der Notwendigkeit von Mehrfachsignaturen
ist es von Bedeutung, ob in die zweite bzw. dritte Signatur die
jeweils vorhergehende Signatur mit aufgenommen wird, oder ob jeweils
die ursprüngliche Nachricht signiert wird und Signaturkopf und
-abschluß erst dann in die Nachricht eingefügt werden. Von der
aktuellen HBCI-Version wird nur das zweite Verfahren unterstützt. In
späteren Versionen kann an dieser Stelle eine Komprimierung der Daten
erfolgen. Bevor die Nachricht versendet werden kann, wird sie
abschließend verschlüsselt.
Von wirtschaftlicher Bedeutung für den Kunden sind bei HBCI neben der
Multibankfähigkeit die Vielzahl von Geschäftsvorfällen. Diese setzen
sich alle nach der oben beschrieben Syntax zusammen, so daß eine
Erläuterung der einzelnen Vorfälle an dieser Stelle nicht nötig
ist. Da diese jedoch aus Anwendersicht das Herzstück von HBCI
darstellen, sollen die wichtigsten genannt werden.
- Einzelaufträge
- Einzelüberweisungen
- Sonderformen der Überweisung
- Spendenzahlungen
- Überweisung mit prüfzifferngesicherten Zuordungsdaten (BZÜ)
- Terminüberweisungen
- Daueraufträge
- Einzellastschriften
- Sammelaufträge
- Sammelüberweisungen
- Sammellastschriften
- Terminierte Sammelüberweisungen
- Terminierte Lastschriften
Des weiteren können Umsatzinformationen abgefragt und Termineinlagen getätigt
werden. Es ist auch möglich, unter HBCI ein Wertpapierdepot zu verwalten sowie
Zahlungsverkehr mit dem Ausland abzuwickeln und Karten bzw. Schecks zu
bestellen.
Mit der Entwicklung von HBCI ist es gelungen, einen leistungsfähigen
und flexiblen Standard zu schaffen. Des weiteren war es den
Entwicklern möglich, eine Unabhängigkeit von Präsentations- und
Transportdiensten zu erreichen. Im Puncto Betriebssicherheit,
Benutzerfreundlichkeit und Sicherheitskomfort übertrifft HBCI alle
bisher dagewesenen Standards um ein Vielfaches. Neben der bereits
mehrfach erwähnten Multibankfähigkeit führen zusätzliche
Geschäftsvorfälle und Internettauglichkeit zu einer erhöhten
Attraktivität von HBCI gegenüber herkömmlichen Homebankingsystemen.
Daß HBCI, trotz großer Bemühungen seitens des ZKA, noch nicht zum
nationalen Marktführer wurde, liegt unter anderem daran, daß mehrfach
kurz vor der Markteinführung neue Versionen auf den Markt gekommen
sind und somit eine flächendeckende Markteinführung ausblieb.
Folgende Erklärungen sind wörtlich [HBCI] entnommen.
Bei Erscheinen der beiden konkurrierenden Standards OFX und Gold
wurden bereits Pläne geschmiedet, diese zumindest auf hohem Niveau
zusammenzufassen. Dies führte zur Gründung eines Konsortiums unter der
Leitung von BITS (besser bekannt unter Bankers Roundtable), dem außer
den Herstellern Checkfree, IBM, Intuit, Microsoft und Visa auch
zahlreiche namhafte amerikanische und kanadische Banken
angehören. Ziel ist die Definition von gemeinsamen Geschäftsvorfällen,
die dann jeweils ein Mapping in die entsprechende Zielsyntax
erfahren. IFX liegt in einem ersten Draft seit Januar 1999 vor. Man
hofft, noch im ersten Quartal zu einer abgestimmten Version 1.0 zu
kommen.
Weitere Informationen zum Thema gibt es bei: http://www.bitsinfo.org/ifx/index.htm
Die Positionierung von HBCI gegenüber SET ist relativ einfach. Visa
und MasterCard (und beteiligte Firmen, wie z.B. GTE, IBM, Microsoft
und Netscape) spezifizierten SET primär für die allgemeine Abwicklung
von Kreditkartengeschäften. Dies beginnt beim sicheren Bezahlen im
Bereich CyberShopping und endet mit der Verwaltung des
Kreditkartenkontos. Obwohl es hierbei natürlich Überschneidungen geben
kann, ist dem Standard doch anzumerken, daß er auf den amerikanischen
Markt zugeschnitten und somit auf die deutsche Kreditwirtschaft nicht
1:1 übertragbar ist, was sich mit der Spezifikation von SET 2.0 wohl
ändern wird. Die sehr allgemeinen und ausgefeilten
Sicherheitsmechanismen unter Einbeziehung von Zertifizierungsinstanzen
weisen starke Gemeinsamkeiten mit HBCI auf. Als Transportprotokoll
wird auch hier exemplarisch TCP/IP beschrieben.
Weitere Informationen zum Thema gibt es bei: http://www.international.visa.com/fb/main.jsp
Open Financial Exchange - entstanden aus "OFC" von Microsoft und "Open
Exchange" von Intuit - ist ein neuer Homebanking-Standard, der auf
einer HTML-ähnlichen TAG-Language (SGML, ab Version 2.0 XML) basiert
und SSL als Transportsicherheitskomponente verwendet. Für die
Authentifikation wird ein Kennwort verwendet, das über zuvor
ausgetauschte Zufallszahlen sicher verschlüsselt übertragen wird
(Challenge Response Verfahren). Zur Abdeckung der
Transaktionssicherheit kommen heute noch vielfach TANs zum Einsatz,
Kontextsignaturen sind derzeit nicht vorgesehen. OFX ist momentan fest
auf Internet als Transportmedium zugeschnitten. Die definierten
Geschäftsvorfälle orientieren sich momentan (Version 1.6) noch stark
am amerikanischen Markt. Obwohl der Standard als offen gilt, liegt die
Kontrolle bei den Herstellern Microsoft, Intuit und CheckFree.
Weitere Informationen zum Thema gibt es bei: http://www.ofx.net
Alle Abbildungen sind [SPEC] entnommen.
- Abb. 1 entspricht Abb. 7 Kapitel II
- Abb. 2 entspricht Abb. 11 Kapitel III
- Abb. 3 entspricht Abb. 13 Kapitel III
- Abb. 4 entspricht Abb. 14 Kapitel III
- Abb. 5 entspricht Abb. 15 Kapitel III
- Abb. 6 entspricht Abb. 16 Kapitel III
- Abb. 7 entspricht Abb. 17 Kapitel III
|
Letzte Änderung: 2000-03-22 10:46:12
|
![[Universität Karlsruhe]](/images/ico_uni.png)
![[Institut für Technische Informatik]](/images/ico_home.png)
![[E-Mail an Autor]](/images/ico_mail.png)