Proseminar Homebanking

Transkript

1 Proseminar Homebanking Vortragsthema HBCI 1. Einführung Was ist HBCI? Î Home Banking Computer Interface Es handelt sich bei HBCI um einen vom ZKA (Zentraler Kreditausschuss der deutschen Kreditwirtschaft) verabschiedeten Standard. Die aktuelle Version dieses Standards ist die Versionsnummer 2.2. Dieser Standard wurde geschaffen um Homebanking noch sicherer und komfortabler zu machen. Weiterhin ist durch die Verfügungsstellung dieses Standards eine Multibankingfähigkeit angestrebt um durch die Verwendung eines Kundensystems mit mehreren Bank-/ Kreditinstituten kommunizieren zu können. Es wird durch die Verwendung moderner kryptographischer Funktionen in Verbindung mit Chipkarten nun auch eine sichere Kommunikation in offenen Netzen wie dem Internet gewährleistet. Durch seine Flexibilität soll HBCI der zukünftige Homebanking Standard für die deutschen Kreditinstitute werden. Die Ausgangssituation für die Entstehung von HBCI: Homebanking wurde bisher hauptsächlich auf Basis von T-Online BTX betrieben. Viele der andere Homebanking-Lösungen, wie z.b. AOL Homebanking, bauen auf BTX auf und betreiben im Prinzip nur eine Art Face-Lifting. T-Online, die zwei verschiedenen Homebanking-Verfahren: 1. Screen-Dialog (CEPT) Online-Dialog auf Basis von BTX-Seiten, Auflösung von 25x40 Zeichen eingesetzte Geräte verfügen über keine eigene Intelligenz PIN/TAN Verfahren als Sicherungskonzept (PIN zur Identifikation und möglicher Anzeige von Kontoständen und Umsatzdaten TAN zusätzlich bei Transaktionen) 2. ZKA-Maske ebenfalls Nutzung von BTX, jedoch keine vom Bediener nutzbare Dialogmaske mehr, reine Datenschnittstelle Daten werden als Nettodaten übertragen, Kommunikation wird durch ein einheitliches Datenformat vereinfacht ebenfalls Sicherungsverfahren PIN/TAN schlechte Definition dieses Standards, unterschiedliche Interpretationen/Umsetzungen machen eine Normierung zunichte und bewirken das Gegenteil der Absicht Beide Verfahren haben ein Problem in ihrer Betriebssicherheit. Wenn bei der Übertragung einer Transaktion ein Verbindungsabbruch auftritt, kann der Status dieses Auftrags erst auf dem Kontoauszug geprüft werden. Eine Online-Überprüfung besteht nicht. 1

2 Abb. Screen-Dialog (CEPT) Abb. ZKA-Maske Zusammenfassung: Î Es gibt keinen richtigen Standard und das Sicherungskonzept durch PIN/TAN ist zu aufwendig (Erzeugung und Überwachung). Es besteht der Bedarf an der Zeit angepassten, intelligenten Kundensystemen welche über einen Standard die Kompatibilität und damit Multibankingfähigkeit gewährleisten. folgende Anforderungen werden an den Homebankingstandard gestellt: flexible, leistungsfähige und von Präsentationsdiensten unabhängige Datenschnittstelle Datenschnittstelle muss unabhängig vom Transportnetz sein um auch auf alternativen Netzen einsetzbar zu sein, wobei die Transportschicht jedoch genau spezifiziert sein muss, um multibankfähige Kundensystem mit gleicher Zugangscharakteristik herstellen zu können Sicherheitsfunktionen sollen den Betrieb in unsicheren Netzen ermöglichen und den Bedienkomfort erhöhen Multibankfähigkeit um Konten bei verschiedenen Geldinstituten gleichermassen verwalten zu können Idealer Weise herstellerunabhängig um bei mobilen Endgeräten auf keine Kompatibilitätsschwierigkeiten zu stossen (z.b. Terminal in einem Hotel, Bahnhof oder ähnlichem) es sollen neue Geschäftsarten erschliesbar sein, die über das bisherige Überweisen und Kontostandabfragen hinausgehen (z.b. Wertpapiergeschäfte) und so mit eine grössere Attraktivität mit sich bringen der Standard soll sich nahtlos in der Welt der Bank-Selbstbedienung integrieren lassen und somit eine gleichbleibende Funktionalität über alle Endgeräte und Kreditinstitute bei der Erstellung und Wartung von Anwendungen gewährleisten 2

3 2. Aufbau (Syntax) Zeichensatz Als Zeichensatz verwendet HBCI den ISO-Zeichensatz Das jeweilige Codeset für diesen Zeichensatz kann definiert werden und innerhalb dieses Codesets (z.b. latin ) ist es noch möglich ein nationales HBCI-spezifisches Subset (z.b. deutsch, englisch oder französisch) zu wählen. Der definierte Zeichensatz gilt für alle Textformate, jedoch nicht für binäre oder transparente Daten. Binäre Daten sind jegliche Arten von Programmen, Multimediadaten oder ähnliches. Als transparent Daten gelten HBCI-Fremdformate, die hauptsächlich aus der Kreditwirtschaft stammen. Binäre und transparente Daten benötigen alle 8-Bit eines Bytes, sollte dies nicht gegeben sein (z.b. - Dienste), kommen Filter zum Einsatz. HBCI ist nicht textorientiert und nicht an einen speziellen Präsentationstyp gebunden. Trennzeichensyntax HBCI verwendet zur Darstellung der Daten eine Trennzeichensyntax. Diese Trennzeichensyntax zeichnet sich durch Flexibilität und Minimierung des Datenvolumens aus, spezifische Daten wie Feldlänge oder Feldname sind durch die Reihenfolge definiert und müssen so nicht mit übertragen werden. Eine zusätzliche Verringerung des Datenvolumens wird durch eine logische Komprimierung erzielt, optionale Datenelemente stehen am Ende der Datenstruktur und können auch problemlos weggelassen werden. + Datenelement Ende : Gruppendatenelement Ende Segment Ende? Freigabezeichen (bei Steuerzeichen im Kennzeichen für binäre Daten Syntaktische Einheiten Die HBCI-Trennzeichensyntax lässt sich in 3 verschiedene, logische Ebenen unterteilen: 1. Datenelemente (DE) Diese entsprechen den einzelnen Feldern eines Segmentes. Die einfachste Form eines DE kann z.b. eine Bankleitzahl sein. Es ist jedoch möglich, dass sich hinter dem DE ein gesamtes, transparent eingestelltes Fremdformat verbirgt. 2. Datenelementgruppen (DEG) Diese bestehen aus logisch zusammengehörenden Datenelementen Die darin enthaltenen Elemente werde dann als Gruppendatenelemente (GD) bezeichnet. 3. Segmente Alle logisch zusammengehörigen Datenelemente und Gruppendatenelemente werde zu einem HBCI-Segment zusammengefasst. Im bankfachlichem Sinne stellt ein Segment in der Regel einen Geschäftsfall dar (z.b. Einzelüberweisung). Im Gegensatz zu den beiden vorangegangen Ebenen wird ein Segment zusätzlich durch einen Header beschrieben, dem Segmentkopf. Der Segmentkopf enthält vor allem die Segmentkennung, welche Informationen über den Inhalt der enthaltenen Datenelemente und Datengruppenelemente enthält. 3

4 Abb. Segmentaufbau Beispiel anhand einer Einzelüberweisung: (1) (2) (3) HKUEB:4: ::280: ::280: (4) (5) (6) (7) (8) (9) MEIER FRANZ++100,:DEM RE-NR.1234:KD-NR.9876 Zusammensetzung: Nr. Name Typ 1 Segmentkopf DEG 2 Kontoverbindung Auftraggeber DEG 3 Kontoverbindung Empfänger DEG 4 Name Empfänger 1 DE 5 Name Empfänger 2 DE 6 Betrag DEG 7 Textschlüssel DE 8 Textschlüsselergänzung DE 9 Verwendungszweck DEG 10 Ausführungsdatum DE 11 Auftragsidentifikation DE (1) Segmentkopf (DEG) Segmentkennung Segmentnummer Segmentversion (2+3) Kontoverbindung (DEG) Konto-/Depotnummer Länderkennzeichen (z.b. Deutschland=280, USA=840) Kreditinstitutecode (4) Name Empfänger1 (DE) max. 27Zeichen (6) Betrag (DEG) Wert Währung (z.b. DEM) (7) Textschlüssel (DE) 2 Ziffern (z.b. 51=Überweisungsgutschrift, 54=Vermögenswirksame Leistungen) (8) Textschlüsselergänzung (DE) 3 Ziffern (z.b. 107=10% Sparzulage für 1997) (9) Verwendungszweck n* max. 27 Zeichen ( n hängt von den Bankparameterdaten ab, in diesem Fall 2) 4

5 Nachrichtenaufbau Ein Segment bildet nur den bankfachlichen Teil eines Geschäftsvorfalles. Die Kommunikation zwischen dem Kunden und dem Kreditinstitut erfolgt bei HBCI über Nachrichten. Je Nachricht sind mehrere Segmente möglich, z.b. 2 Einzelüberweisungen und 1 Saldoabfrage. Die Nachrichten setzen sich aus einer vorgegebenen Abfolge zusammen und sehen im allgemeinen wie folgt aus: Abb. Nachrichtenaufbau Alle Nachrichten enthalten je einen Nachrichtenkopf und ein Nachrichtenabschlussegment. Im Nachrichtenkopf befinden sich administrative Informationen, z.b. Nachrichtennummer. Im Nachrichtenabschluss befindet sich eine Referenz auf den Nachrichtenkopf. Der Chiffrierkopf enthält Verschlüsselungsangaben. Im Signaturkopf befinden sich Informationen zur Beschreibung der anzuwendenden Sicherheitsverfahren und eine eindeutige Referenznummer als Doppeleinreichungskontrolle beim Kreditinstitut. Der Signaturabschluss enthält die elektronische Signatur der gesamten Nachricht. 5

6 3. Dialogablauf Dialoginitialisierung HBCI-Nachrichten können nur innerhalb eines HBCI-Dialoges gesendet werden. Die HBCI- Nachrichten sind zwar in sich geschlossene Verarbeitungseinheiten, es ist jedoch nicht möglich diese im Rahmen von -Diensten zu verarbeiten. Ein HBCI-Dialog ist wie folgt aufgebaut: Abb. HBCI-Dialog Ein HBCI-Dialog läuft grundsätzlich synchron ab, d.h. dass jede Nachricht vom Kredititinstitut beantwortet werden muss, bevor eine neue Kundennachricht gesendet werden kann. Mit der Dialoginitialisierung erfolgt die gegenseitige Authentifizierung zwischen dem Kunden und dem Kreditinstitut, nur so können die darauf folgenden Auftragsdaten in einer sicheren Umgebung durchgeführt werden. Es erfolgt ebenfalls ein Vergleich der Verschlüsselungs- und Komprimierungsverfahren, so wie ein Abgleich der Bank-Parameterdaten (BPD) und der User- Parameterdaten (UPD). Gegebenenfalls werden bei der Initialisierung neue Versionen für BPD und UPD übertragen oder auch die Versionen für die öffentlichen Schlüssel des Kreditinstitutes. Es besteht der Spezialfall, wo ein anonymer Zugang über eine Bankleitzahl als Einstieg ermöglicht wird. Mit Hilfe dieses anonymen Zugangs ist es möglich, dass Angebot des Kreditinstitutes kennenzulernen oder nicht signaturpflichtige Anfragen zu senden, z.b. abrufen der Börsenkurse. Nach erfolgreicher Initialisierung und Abarbeitung aller Nachrichten, wird der Dialog durch das Senden einer Dialogsbeendigungsnachricht abgeschlossen. Diese Beendigungsnachricht stellt sicher, dass alle vorherigen Daten korrekt und komplett übertragen wurden. Rückmeldecodes Bei der Übertragung von Kreditinstitutionsnachrichten werden stets standardisierte Rückmeldecodes mit übertragen, welche auf der Basis der Informationen im Nachrichten- und Segmentkopf ein fehlerhaftes Datenelement genauestens identifizieren und das Kundensystem entsprechend intelligent reagieren lassen können. Beispielsweise kann das Kundensystem nach der Eingabe einer falschen Bankleitzahl (Fehlercode-Nr. 9210) dem Benutzer eine Bankleitzahlensuche anbieten um damit den Auftrag richtigzustellen. 6

7 Statusprotokoll In HBCI gibt es zwei Möglichkeiten, um sich nach dem Status der bereits versendeten Nachrichten zu informieren. Bei herkömmlichen Verfahren war dies nicht möglich und es konnte nach einem Leitungsabbruch nur durch erneutes absenden, unter Verwendung der gleichen TAN, geprüft werden, ob der Auftrag noch übertragen wurde. 1. Dialoginitialisierung mit Synchronisation Durch das einfügen eines Synchronisationssegments in die Dialoginitialisierungsnachricht, wird in der Kreditinstitutsnachricht die Nummer der zuletzt verarbeiteten Nachricht zurückgeliefert. 2. Statusprotokoll In einem speziellen Segment vom Typ Statusprotokoll wird dem Kunden der Status aller Aufträge der zuletzt gesendeten HBCI-Nachricht in Form von Rückmeldecodes mitgeteilt. Der Vorteil eines Statusprotokoll ist, dass stets, auch bei normaler Verarbeitung ohne Fehlersituation, der Kunde über den Fortschritt seiner Aufträge informiert werden kann, z.b. Auftrag angenommen oder Auftrag ausgeführt. Es sind verschiedene Statusmeldungen möglich und diese können je nach Kreditinstitut durchaus verschieden sein. Synchrone / Asynchrone Verarbeitung Durch die Verwendung von Statusprotokollen ergibt sich die Möglichkeit verschiedener Implementierungsmöglichkeiten. Synchrone Verarbeitung: Die Auftragsdaten werden an den Kreditinstitutsrechner gesendet und interpretiert. Die einzelnen Aufträge werden sofort an die nachgeschalteten Buchungssystem weitergeleitet und danach eine Antwort an den Kunden gesendet. Dieses System ist nach wie vor notwendig um z.b. Informationen, wie Umsatz- oder Saldeninformationen abrufen zu können. Der Nachteil dieser Verarbeitungsmethode besteht darin, dass während der gesamten Verbindung eine Leitungsverbindung stehen muss. Asynchrone Verarbeitung: Bei dieser Verarbeitungsweise erhält der Kunde nur eine Bestätigung über den Erhalt der Nachricht, deren Status er sich später über eine Statusprotokollabfrage anzeigen lassen kann. Der grosse Vorteil dieser Methode ist, die Verarbeitung im Kreditinstitutsrechner kann Off-Line erfolgen. 7

8 4. Parameterdaten in HBCI Allgemeines zu HBCI-Parameterdaten Aufgrund der unterschiedlichen Verarbeitungssysteme bei den Kreditinstituten, stösst man bei der Implementierung von multibankfähigen Kundensystemen auf Probleme. Eines dieser Probleme kann z.b. die Anzahl der zu verarbeiteten Verwendungszweckzeilen bei einer Überweisung sein, je nach Kreditinstitut werden meist nur 1 bis ca. 3 Zeilen interpretiert. Aufgabe der Parametersteuerung ist es diese Unterschiede zu beseitigen, so dass es dem Kunden ermöglicht wird eine für alle seine Bankverbindungen gleichartige Verhaltenslogik erkennbar zu machen. Das Kundensystem muss in der Lage sein diese Parametersteuerung umzusetzen. Solche Verarbeitungsrestriktionen sind in den Bankparameterdaten (BPD) verankert. Es gibt jedoch auch kundenspezifische Unterschiede. Bei der Dialoginitialisierung erfolgt der Zugang durch eine, durchaus jeweils unterschiedliche, Benutzerkennung, welche speziell das Sicherheitsmedium des Kunden identifiziert. Um die, dem jeweils dem zugeordneten Konto erlaubten Auftragsarten dem Kundensystem mitteilen zu können, gibt es die Userparameterdaten (UPD). Es muss beachtet werden, dass BPD und UPD dem Kundensystem nur vorab schon mitteilen, welche Prüfungen institutsseitig zu erwarten sind. Alle Angaben werden parallel bei der Einreichung von Aufträgen im Banksystem nochmals abgeprüft und es ist durchaus möglich, dass vom Kundensystem, auf Basis von BPD/UPD, akzeptierte Aufträge, bankseitig abgelehnt werden. Ein Kriterium dafür kann durchaus das jeweilige Limit des Kunden sein, das vielen Einflüssen unterworfen ist. Aufbau der Bankparameterdaten (BPD) In den Bankparameterdaten wird dem Kundensystem die Infrastruktur des jeweiligen Kreditinstitutes mitgeteilt. Beschreibung der Generellen Rahmenbedingungen in einem allgemeinem Teil, z.b. den exakten Namen des Kreditinstitutes oder auch der von ihm unterstützen Sprachen Im Segment Kommunikationszugang werden die verfügbaren Transportmedien beschrieben. Unter Sicherheits- und Komprimierungsverfahren sind die von der Bank unterstützen Verfahren aufgeführt Die restlichen Segmente enthalten sogenannte Geschäftsvorfallparameter, in den die Restriktionen pro Geschäftsvorfall beschrieben sind. Aufbau der Userparameterdaten (UPD) In den Userparameterdaten erhält das Kundensystem Informationen über das Profil eines Kunden, bzw. des Benutzers. Userparameter allgemein enthalten hauptsächlich die Benuterkennung und Daten zur Versionskontrolle Alle restlichen Segmente enthalten Kontoinformationen, z.b. Kontonummer, Produktbezeichnung, erlaubte Geschäftsfälle oder auch Limits 8

9 5. Sicherheit Ein Hauptziel in HBCI ist die Einbindung neuer Sicherheitsmechanismen und die daran anlehnende sicherheitstechnische Ausgestaltung nach den Anforderungen des Signaturgesetzes, um eine in Zukunft rechtskräftige Abwicklung von Geldgeschäften auf elektronischem Wegen zu ermöglichen. HBCI unterstützt die Methodik von Kontext-Signaturen, was bedeutet, dass die Daten eines Geschäftsfalles in die Signaturbildung mit eingebunden werden. Sicherheits-Verfahren Bei HBCI werden zwei verschiedene Verfahren eingesetzt: MAC-Verfahren (Message Authentication Code) Das MAC-Verfahren ist ein symmetrisches Verfahren, was bedeutet, die Schlüssel, welche zum Signieren und Chiffrieren verwendet werden, müssen beiden Partner bekannt sein und vorher auf einem alternativen Weg ausgetauscht werden, z.b. per Post. Es handelt sich bei diesem gemeinsamen Schlüssel um einen geheimen Schlüssel ( secret key ). Es dürfen nur die beiden Partner diesen Schlüssel kennen, denn die Sicherheit hängt von diesem Schlüssel ab. HBCI verwendet zwei verschieden Schlüsseltypen, zum einen den Signierschlüssel um Nachrichten zu unterschreiben und zum anderen den Chiffrierschlüssel für die Verschlüsselung der Nachricht. Die zur Verschlüsselung verwendeten Funktionen basieren auf dem Triple-DES-Verfahren. Die Umsetzung des MAC-Verfahrens erfolgt durch eine Chipkarte, wobei die geheimen Schlüssel niemals die Karte verlassen. Alle sensitiven kryptographischen Prozesse laufen im Chip ab und sind von aussen nicht zugänglich. Der Einsatz dieses Systems bietet sich vor allem in unbekannten Umgebungen an, wie z.b. einer Hotelhalle. Mit einem Preis von rund 20 ¼ LVW GHU (UZHUE HLQHV.DUWHQOHVHJHUlWHV I U dem Privatgebrauch ebenfalls erschwinglich geworden. Der Einzige Nachteil bei diesem Verfahren ist, dass nicht nachgeprüft werden kann, wer die Chipkarte verwendet hat. Dies wird jedoch durch ein Vertrauensverhältnis zwischen Kunde und Bank aufgehoben. RSA-Verfahren (Rivest-Shamir-Adleman, Namen der Erfinder) Beim asymmetrischen RSA-Verfahren werden jeweils Schlüsselpaare verwendet, die immer aus einem öffentlichem( public key ) und einem privatem Schlüssel ( private key ) bestehen. Der Kunde erzeugt ein Schlüsselpaar und teilt den öffentlichen Schlüssel seinem Kreditinstitut mit. Das Kreditinstitut kann nun seinerseits die elektronische Unterschrift auf Korrektheit prüfen. Der Vorteil dieses Verfahrens ist, dass zum einem die Eindeutigkeit der Herkunft der Unterschrift besteht und zum anderen der Schlüssel öffentlich sein kann, da mit im nur Signaturen geprüft, aber nicht erzeugt werden können. HBCI verwendet zwei verschieden Schlüsseltypen, zum einen den Signierschlüssel um Nachrichten zu unterschreiben und zum anderen den Chiffrierschlüssel für die Verschlüsselung der Nachricht. Die Umsetzung des RSA-Verfahrens erfolgt durch eine Softwarelösung mittels einer Diskette oder Festplatte als Speichermedium. Derzeit wird an einer RSA-Umsetzung gearbeitet, welche schon eingesetzt wird, aber noch nicht multibankfähig ist. Das Ziel aller Verbände ist die Verwendung einer ZKA-einheitlichen RSA- Chipkarte. Authentisierung des Kunden Die Authentisierung, Prüfung des Kunden gegenüber dem Sicherheitssystem erfolgt durch die Eingabe eines Passwortes und der nachfolgenden Ausführung einer Sicherheitsfunktion. Das Passwort wird lokal geprüft und verlässt das Kundensystem nicht. Je nach Sicherheitsverfahren erfolgt die Prüfung in der Chipkarte (MAC), bzw. durch die Software (RSA). 9

10 Gegenseitige Authentisierung Kundensystem Ù Banksystem Bei der gegenseitigen Authentisierung machen sich die beiden Parteien mit einander bekannt. Die Verifizierung erfolgt während der Dialoginitialisierung durch das Signieren der Kunden- Kreditinstitutsnachricht. Wenn die Signatur erfolgreich verifiziert werden kann ist die Prüfung erfolgreich abgeschlossen. Beim RSA-Verfahren erfolgt optional nur eine einseitige Prüfung des Kunden. Nachweis der Auftragsherkunft Es ist wichtig, dass die Herkunft der eingereichten Aufträge eindeutig nachgewiesen werden kann. Dieser Nachweis wird durch die jeweilige elektronische Signatur gewährleistet. Beim MAC-Verfahren besteht die theoretische Möglichkeit der Signatur eines Kundenauftrages durch das Kreditinstitut, dies sollte aber durch das Vertrauensverhältnis beider Seiten ausgeschlossen sein. Integrität elektronische Signatur Die elektronische Signatur soll beweisen, dass die HBCI-Nachricht auf dem Übertragungsweg nicht manipuliert worden ist. Es wird über die gesamte Nachricht wird ein Hash-Wert gebildet, eine Prüfsumme die per MAC-/, bzw. RSA-Verfahren die elektronische Signatur berechnet, welche in das HBCI-Segment Signaturabschluss geschrieben wird. Der Empfänger bildet einen Hash-Wert mit dem selben Algorithmus wie der Versender und überprüft die Signatur mittels geheimen Schlüssel (MAC) oder dem öffentlichem Schlüssen (RSA). Abb. Elektronische Signatur Geheimhaltung Verschlüsselung / Chiffrierung Bei der Verschlüsselung/Chiffrierung wird (im Gegensatz zur elektronischen Signatur) die gesamte Nachricht unlesbar gemacht. Diese Unleserlichkeit ist besonders wichtig bei der Übertragung vertraulicher Daten, wie z.b. Umsatzdaten. Die Verschlüsselung bei HBCI erfolgt generell über das Triple-DES-Verfahren. Aus Sicherheitsgründen wird nicht der eigentliche Chiffrierschlüssel verwendet, sondern ein nachrichtenspezifischer Schlüssel. Dieser Schlüssel wird für jede Nachricht aus einer Zufallszahl gebildet, die mit dem Chiffrierschlüssel (entweder per MAC oder RSA) verschlüsselt und der Nachricht vorangestellt wird. Doppeleinreichungskontrolle Eine Möglichkeit ein krypthographisches System anzugreifen besteht darin, Daten abzuhören und mehrfach einzuspielen. Um dem vorzubeugen könnte eine Art manipulationssicherer Zeitstempel verwendet werden, jedoch ist dieser bei vielen Endgeräten nicht gegeben und die Heranziehung der jeweiligen Systemzeit ist zu unsicher da diese zum einen nicht immer richtig ist und zum anderen leicht manipulierbar ist. 10

11 Um einer Doppeleinreichung vorzubeugen beinhaltet HBCI ein Verfahren, was zum einen Missbrauch ausschliesst und zum anderen kaum Flexibilitätseinbussen aufweist. Es handelt sich bei diesem Verfahren um eine Kombination aus einem Sequenzzählers, welcher parallel auf dem Sicherheitsmedium und im Kreditinstitut geführt wird und einer Liste, welche die bereits eingereichten Sequenzen enthält und Aufzeichnungslücken enthält. Dies ist wichtig, da beim Senden von mehreren Off-Line erfassten Nachrichten nicht gewährleistet werden kann, dass diese Nachrichten in aufsteigender Reihenfolge beim Kreditinstitut ankommen. 6. HBCI-Entwicklung Werkzeuge für den Entwickler Die Kreditwirtschaft hat ein grosses Interesse an der Verbreitung und Umsetzung von HBCI und es werden deshalb für Entwickler kostenlose Werkzeuge bereitgestellt, welche die Umsetzung zum einen erleichtern und zum anderen beschleunigen soll. Es werden neben vorgefertigten Funktionsbibliotheken auch technischer Support und Testmöglichkeiten angeboten. Diese zur Verfügung stehenden Entwicklertools sind für die Implementation von HBCI nicht notwendig, jedoch sehr hilfreich. Entwicklertools: HBCI-API (Application Programming Interface) Die HBCI-API wird vom Bundesverband Deutscher Banken (BdB) in Zusammenarbeit mit dem Bankverlag kostenlos verteil. Diese API beinhaltet neben einem High- und Low-Level Interface für C++ auch die Unterstützung der in HBCI definierten Transportkanäle und RSA als Sicherheitsverfahren. HBCI-Kernel Der HBCI-Kernel ist eine Entwicklung der Sparkassenorganisation zusammen mit dem Genossenschaftsbereich. Es wird der Zugang über TCP/IP und T-Online Unterstützt. Die Homebanking-API steht für C, C++ und JAVA zur Verfügung und als Sicherheitsverfahren wird neben dem RSA auch das MAC-Verfahren mit Chipkarte angeboten. Zukunftsaussichten Mit HBCI ist es endlich gelungen einen Standard zu schaffen, welcher die bestehenden Homebanking-Systeme sicherer, unabhängiger und komfortabler macht. Für die deutsche Kreditwirtschaft ist HBCI die Zukunft in Sachen Sicherheit und Multibankingfähigkeit. Wie die Akzeptanz der Bevölkerung im Bezug auf dieses neue Homebanking-Konzept aussieht bleibt abzuwarten. Mit Sicherheit wird die Akzeptanz im Bereich von Unternehmen grösser und schneller sein, da diese häufig weniger Probleme mit dem Anschaffen und Verwenden neuer Techniken (Chipkartenleser u.ä.) haben und hier wirklich ein Bedarf an einem multibankingfähigen Kundensystem. Im Privatbereich bleibt es abzusehen, ob Nutzer früherer System auf HBCI umsteigen werden und neue Nutzer sich für HBCI entschliessen. Generell muss wohl gesagt werden, dass das Vertrauen in die Sicherheit von HBCI und das Homebanking im Ganzen vorhanden sein muss. Letztendlich bleibt ebenfalls noch abzuwarten, wie die Verbreitung und Akzeptanz von HBCI im internationalen Bereich, speziell auf europäischer Ebene aussieht. HBCI ist ein nationaler Standard und steht der Entwicklung von Systemen/Standards im Ausland gegenüber, welche sich da ebenfalls im Aufbau befinden. 11