|
HBCI
|
-
|
OFX
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Bankgeschäfte und Bezahltransaktionen
|
|
|
|
|
- vielfach implementiert
- meist deutsche Anbieter,
z.B. Faktum, Brokat, Sparkassen,
aber auch Intuit
- HBCI-Kernel (Sparkassenorganisation)
- HBCI-API (BdB)
|
|
- vielfach implementiert
- viele amerikanische e-Commerce-Anbieter,
natürlich Microsoft, Intuit
|
- 5x in Verwendung
- Raiffeisen-Volksbank eG Mainz
- Volksbank Aachen Süd eG
- Hamburger Sparkasse
- BfG Bank AG
- Dresdner Bank AG:
- seit 16. August 1999
- erste Großbank mit HBCI-Banking
- vorher kein Internetbanking
|
|
- nicht in Verwendung
- nichts gefunden
|
|
HBCI
|
-
|
OFX
|
- Zahlungsverkehr Inland
- Überweisungen
- Lastschriften
- Daueraufträge
- Sammelaufträge
|
|
- Zahlungsverkehr Inland
- Überweisungen
- Lastschriften (als Überweisungen aufs eigene Konto)
- Daueraufträge
- Sammelaufträge (als mehrere Einzelaufträge)
|
|
|
|
- Umsatzinformationen, auch für Kreditkarten
|
- Termineinlagen
- Festgeld, neu, ändern etc.
|
|
|
|
|
|
|
|
|
|
- Zahlungsverkehr Ausland
- Keine Länderangabe möglich
- aber Erläuterung, welche Parameter für welches Land
|
- Bestellungen
- Karten, Schecks, Formulare
|
|
- Bestellungen nur per Mail
|
|
|
|
|
|
|
|
|
|
HBCI
|
-
|
OFX
|
- Trennzeichensyntax
- vermeidet Overhead
- viele transparent eingestellte Formate
(S.W.I.F.T. [Wertpapiere]/ DTAUS)
ermöglichen schnelle Weiterverarbeitung
- EDIFACT ähnliche Trennzeichensyntax
- HBCI ist vollständig spezifiziert,
lässt weniger Realisierungsvarianten zu,
wie ZKA-Dialog
- Komprimierung möglich
|
|
- OFXSGML
- übersichtlicher
- Umsetzung der Daten muss in OFX-Software
des Kreditinstitutes erfolgen
- financial data markup language
- nicht so genaue Definitionen wie HBCI,
lässt daher Unterstandarts zu
|
|
|
|
|
- festgeschriebener Standart /
einige Sprachen definiert
- deutsch, englisch, französisch
- MIME:application/hbci
- PORT 3000
|
|
- lässt Unterstandarts für
verschiedene Länder zu
- MIME:application/x-ofx
- SSL-PORT 443
|
- Annahme: Kundensystem ist unsicher und ungenau
- z.B. Zeitstempel des Kunden nicht relevant
- viele Sicherheitsabfragen schon auf
Kundenseite vorgesehen
- Auf Bankseite wird trotzdem alles nochmal überprüft
- einige Dinge auf Kundenseite nicht überprüfbar (z.B. Limits)
|
|
- Vertrauen in Kundensystem
- z.B. Zeitstempel des Kunden
und des Servers relevant
|
|
|
|
|
|
HBCI
|
-
|
OFX
|
- Text und eingestellte Binärdaten
|
|
|
- signiert und verschlüsselt
- Verschlüsselung mit Triple-DES
Nachrichtenschlüssel
- Für jede Nachricht neuer Nachrichtenschlüssel
- getrennte Chiffrierschlüssel und Signierschlüssel
- Chiffrierschlüssel dienen nur zum verschlüsseln
von Nachrichtenschlüsseln
- Verfahren: RSA (Software) oder MAC (Chipkarte)
- noch keine ZKS-einheitliche RSA-Chipkarte,
ist aber in Vorbereitung
- MAC - Schlüssel verlassen nie Karte die Karte
- MAC - keine Nichtabstreitbarkeit, da auch Bank
Kunden-Nachrichten signieren kann, aufgehoben
durch Vertrauensverhälnis Kunde / Bank
|
|
- SSLv3 (optional) / application-level security (opt.)
- Type I: Passwort und Zufallsdaten vom Server mit
öffentlichem Schlüssel des FI (Financial Institution)
verschlüsselt
- kein Bezug (Hash etc.) zum Rest der Nachricht
- erfordert channel-level-security (SSLv3)
|
- ZKA UN/EDIFACT / X.509
- Zertifikate
|
|
- X.509 v3 / festgelegte CA‘s
- Zertifikate
- CA's noch nicht benannt
|
- verschiedene Übertragungswege,
auch unsichere Netze
- Internet / Online-Dienst:
FIF (BTX), FTP, Telnet
- Elektronische Signaturen und Datenverschlüsselung
auch für unsichere Netze geeignet
- Zertifikate
|
|
- Internet: TCP/IP; HTTP; SSLv3
|
- Online oder Offline
- Statusprotokolltechnik (offline):
Aufträge entgegennehmen und ohne
Leitungsverbindung
zum Kunden weiterverarbeiten
- Online-Status:
Aufträge annehmen und online Status zurückliefern
(dauerhafte Verbindung notwendig)
- Faktum: Programm: Offline schreiben der Aufträge /
Installation nötig
- Faktum: Applet: Online schreiben der Aufträge /
(überall einsetzbar / Kartenleser ?!?)
|
|
|
|
|
|
|