Hochschule Bremen Secure Electronic Transaction (SET) und Homebanking Computer Interface (HBCI)
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Hochschule
Bremen
Secure Electronic Transaction (SET)
und
Homebanking Computer Interface (HBCI)
Fach RST-Labor
Gruppe Marco Ochudlo
Matthias Meyer
Semester I8IXSecure Electronic Transaction-Homebanking Computer Interface
1.0 EINLEITUNG 4
2.0 VERSCHLÜSSELUNGSVERFAHREN 4
2.1 SYMMETRISCHE VERSCHLÜSSELUNG (SECRET-KEY-VERFAHREN) 4
2.2 ASYMMETRISCHE VERSCHLÜSSELUNG (PUBLIC-KEY-VERFAHREN) 4
2.3 PRÜFSUMME (MESSAGE DIGEST) 5
2.4 DIGITALE SIGNATUR 6
3.0 SET, SECURE ELECTRONIC TRANSACTION 7
3.1 EINLEITUNG 7
3.2 TYPISCHER BESTELLVORGANG IM INTERNET 7
3.3 TECHNISCHE VORAUSSETZUNGEN 8
3.4 TEILNEHMER 9
3.5 SICHERHEIT 11
3.6 ZERTIFIKATE 12
3.7 ABLAUF 13
4.0 HBCI 25
4.0 AUFBAU DER NACHRICHTENELEMENTE 27
4.1 TRENNUNG DER ELEMENTE 27
4.2 AUFBAU EINER NACHRICHT 28
4.3 BILDUNG EINER NACHRICHT 29
4.4 NACHRICHTENAUFBAU 29
5.0 EINLEITUNG VERSCHLÜSSELUNG HBCI 30
5.1 SCHLÜSSELVERWALTUNG 30
5.2 ZUSAMMENSETZUNG DER SCHLÜSSELNAMEN 31
5.3 ELEKTRONISCHE SIGNATUR BEIM DDV VERFAHREN 31
5.4 ELEKTRONISCHE SIGNATUR BEIM RDH VERFAHREN 33
5.5 ERSTELLEN DES CHIFFRIERSCHLÜSSEL 33
6.0 MIKROPROZESSORKARTEN 39
2Secure Electronic Transaction-Homebanking Computer Interface
6.1 AUFBAU EINER MIKROPROZESSORKARTE 39
6.2 CHIPKARTENBETRIEBSSYSTEME 40
6.3 AUFBAU DER DATEIEN 40
6.4 DATEITYPEN 41
7.0 CHIPKARTENSPEZIFIKATION IM HBCI 42
7.1 DATEIEN IM DF_BANKING_20 VERZEICHNIS 43
7.2 SIGNIEREN EINER NACHRICHT 47
7.3 NACHRICHT CHIFFRIERN 49
QUELLENVERZEICHNIS 51
ABBILDUNGSVERZEICHNIS 53
3Secure Electronic Transaction-Homebanking Computer Interface
1.0 Einleitung
Der Verkauf von Produkten und Dienstleistungen über das Internet wird zunehmend genutzt,
so daß es notwendig geworden ist, sichere Verfahren einzuführen, die das bezahlen sicherer
machen. Hierzu gehören die Verfahren Secure Electronic Transaction (SET) sowie mit dem
deutschen Homebanking Computer Interface (HBCI) Verfahren.
Grundlage beider Verfahren sind Verschlüsselungsverfahren, die an dieser Stelle nur kurz
angesprochen werden.
2.0 Verschlüsselungsverfahren
2.1 Symmetrische Verschlüsselung (Secret-Key-Verfahren)
Diese Methode verwendet nur einen Schlüssel zum Ver- und Entschlüsseln. Es ist daher
notwendig, daß Sender und Empfänger diesen Schlüssel auf sicherem Wege austauschen, um
beide im Besitz dieses Schlüssels zu sein und keinem Dritten Kenntnis des Schlüssels zu
ermöglichen. Es ist bei dieser Methode schwierig, mit einer großen Anzahl von Partnern zu
kommunizieren, da man mit jedem einen eigenen Schlüssel sicher austauschen muß. Wenn es
n Parteien gibt, die untereinander kommunizieren, werden n2 Schlüssel benötigt.
Ein weitverbreiteter Algorithmus dieses Typs ist DES (Data Encryption Standard).
Auf diesem Algorithmus wird in einem späteren Kapitel näher eingegangen.
Da der DES Schlüssel im Jahre 1997 entschlüsselt wurde, mußte der damalige Schlüsselraum
von 256 Bit vergößert werden. Hierzu wurde der Triple DES Algorithmus entwickelt, bei dem
zwei Schlüssel mit jeweils 56 Bit zum Einsatz kommen. Durch diese Maßnahme wurde die
Wahrscheinlichkeit verringert, daß dieses Verschlüsselungsverfahren durch Probieren aller
Möglichkeiten entschlüsselt wird.
Der Triple DES wird als wirkungsvolle Alternative zum DES eingesetzt.
2.2 Asymmetrische Verschlüsselung (Public-Key-Verfahren)
Diese Methode verwendet Schlüsselpaare. Ein Schlüssel dient jeweils zum Verschlüsseln, der
andere zum Entschlüsseln. Die beiden Schlüssel hängen mathematisch derart zusammen, daß
4Secure Electronic Transaction-Homebanking Computer Interface
die Verschlüsselung mit beiden Schlüsseln (siehe digitale Signatur) möglich ist und mit dem
jeweils anderen wieder entschlüsselt werden kann, jedoch die Kenntnis des einen Schlüssels
nicht auf den anderen schließen läßt.
Einer der Schlüssel ist der öffentliche Schlüssel (Public Key), der andere der private Schlüssel
(Private Key). Eine Nachricht schickt man an einen Partner, indem man sie mit dessen
öffentlichen Schlüssel verschlüsselt; nur dieser kann sie mit seinem privaten Schlüssel wieder
lesen. Durch die Hinterlegung des öffentlichen Schlüssels an allgemein zugänglicher Stelle
kann man auf diese Weise einfach mit vielen Partnern verschlüsselt kommunizieren.
Public-Key-Systeme haben zwei wesentliche Nachteile. Erstens sind die Schlüssel im
Vergleich zu konventionellen Kryptosystemen sehr groß. Dies kann sich als
Problem erweisen, wenn sie eingegeben oder übermittelt werden müssen. Zweitens sind die
Ver- und Entschlüsselung bedeutend langsamer. Das erste Problem ist kaum beeinflußbar.
Das zweite Problem wird umgangen, indem solche Systeme hauptsächlich zur
Schlüsselverteilung eingesetzt werden. Ein Vorteil dieser Systeme ist, daß im Gegensatz zu
den Private-Key-Verfahren die Schlüsselzahl linear mit der Anzahl der
Kommunikationsteilnehmer steigt. Pro Teilnehmer wird nur ein Schlüsselpaar benötigt.
Das bekannteste und wichtigste Public-Key-Kryptoverfahren heißt RSA. Seine Sicherheit
beruht auf der Schwierigkeit, sehr große Zahlen zu faktorisieren. Um RSA
einzusetzen, werden zwei große Primzahlen p und q gewählt, die beide wenigstens mehrere
hundert Bit lang sein sollten. Aus diesen beiden Zahlen werden der
private und der öffentliche Schlüssel abgeleitet, wobei das mathematische Verfahren hier
nicht interessieren soll. Es ist kein Verfahren bekannt, den privaten Schlüssel
aus dem öffentlichen Schlüssel abzuleiten, welches ohne die Faktorisierung von pq
auskommt, und die Faktorisierung großer Zahlen gilt als sehr aufwendig.
2.3 Prüfsumme (Message Digest)
Prüfsummen werden durch außerordentlich schwer zu invertierenden Funktionen
(kryptographische Einweg-Algorithmen) erzeugt, man kann also vom Ergebnis nicht auf die
Eingabe schließen. Sie generieren aus einer Zeichenkette einen charakteristischen "Abdruck",
den sogenannten digitalen Fingerabdruck. Die Algorithmen sind so beschaffen, daß eine
Änderung auch nur eines Zeichens massive Änderungen in der Prüfsumme bewirkt.
Außerdem muß es extrem aufwendig sein, eine Nachricht zu erzeugen, die die gleiche
Prüfsumme ergibt, um das Verfahren für sicher halten zu können.
5Secure Electronic Transaction-Homebanking Computer Interface
Prüfsummen haben zwei Haupteinsatzgebiete. Zum einen kann jedes digitale Signatursystem
statt auf die Nachricht selbst auf den Prüfsummen-Wert angewendet werden. Dies ist im
allgemeinen sehr viel billiger, weil die Eingabe für das Signatursystem sehr viel kürzer
ausfällt. Zweitens kann die Integrität eines Dokuments garantiert werden. Dazu wird der
digitale Fingerabdruck einer Nachricht mit dieser übermittelt. Der Empfänger errechnet noch
einmal den Fingerabdruck der Nachricht und vergleicht ihn mit dem Sollwert.
Bekannte Verfahren zum Berechnen einer Prüfsumme sind der Secure Hash- und der MAC-
Algorithmus.
2.4 Digitale Signatur
Die digitale Signatur stellt ein eindeutiges Kennzeichen dafür dar, dass eine bestimmte Person
eine Nachricht akzeptiert oder zumindest gelesen hat.
Kehrt man das Prinzip von RSA um, lassen sich mit RSA auch digitale Signaturen realisieren.
Die mathematische Struktur von RSA erlaubt es, einen Klartext durch Entschlüsselung zu
codieren und durch Verschlüsselung zu decodieren. Um eine Nachricht zu unterschreiben,
entschlüsselt der Urheber die Nachricht mit seinem privaten Schlüssel. Jeder kann die
Echtheit der Nachricht überprüfen, und sie dabei sichtbar machen, indem er sie mit dem
öffentlichen Schlüssel verschlüsselt. Anstelle von RSA kann man aber auch eben so gut
andere asymmetrische Verschlüsselungsverfahren benutzen
Da asymmetrische Verschlüsselung recht langsam ist, ist es sinnvoller, die digitale Signatur
über den Prüfsummenwert einer Nachricht anzuwenden. Soll in diesem Fall die Nachricht
ebenfalls nicht lesbar sein, so kann man z.B. folgender Maßen vorgehen:
Es wird eine Prüfsumme über die Nachricht gebildet, anschließend wird die Nachricht mit
einem symmetrischen Verschlüsselungsverfahren verschlüsselt. Dann werden verschlüsselte
Nachricht mit angehängtem Schlüssel und Prüfsumme digital signiert, und der ganze Block
verschickt.
Der Empfänger entschlüsselt die Signierung, entschlüsselt die Nachricht mit dem
mitgelieferten Schlüssel, erstellt nun selbst eine Prüfsumme von der Nachricht und vergleicht
diese mit der mitgelieferten Prüfsumme.
6Secure Electronic Transaction-Homebanking Computer Interface
3.0 SET, Secure Electronic Transaction
3.1 Einleitung
Im Verlauf der raschen Kommerzialisierung des Internets und der zunehmenden raschen
Verbreitung des eCommerce wurden verschiedene Verfahren entwickelt, um den zugehörigen
Zahlungsverkehr im Internet abwickeln zu können. Sehr häufig bezahlt man im Internet mit
seiner Kreditkarte. Da die Übertragung von Kreditkartennummern über das Internet jedoch
meist unverschlüsselt oder nur unzureichend geschützt vonstatten geht, stellt das für den
Kunden meistens eine große Hemmschwelle dar. Und die ist auch nicht unbegründet. Denn
man hört immer wieder, dass es sehr einfach ist, die relevanten Daten der Kreditkarte auf
ihrem Weg zum Händler abzufangen und zu Missbrauchen.
Aber auch auf der Seite der Händler gibt es Risiken. So kann z.B. eine Person an die Daten
einer fremden Kreditkarte gekommen sein, und mit ihr Waren bei einem Händler bestellt
haben. Nach Auslieferung der Waren, nimmt der wirkliche Kartenbesitzer sein Recht auf
Zahlungsverweigerung in Anspruch, und der Händler hat keine Möglichkeit, den wahren
Auftraggeber zu identifizieren.
Es liegt auf der Hand, dass für eine Imageverbesserung der Zahlung per Internet ein sicheres
Übertragungsverfahren für Kreditkartendaten entwickelt werden muß.
Aus diesem Grund schlossen die Kreditkartenorganisationen VISA und Mastercard ihre
Bemühungen zusammen und entwickelten mit Unterstützung von Firmen, wie IBM, Netscape
und Microsoft die Secure Electronic Transaction, kurz SET.
SET ist eine offene Spezifikation eines Protokolls für die gesicherte Übertragung von
Kreditkartendaten für Zahlungen über das Internet oder andere Computernetzwerke.
Seit Dezember 1997 verwaltet die von Visa und Mastercard gegründete Firma SETCo die
SET Spezifikation und kümmert sich um Weiterentwicklung und Verbreitung.
3.2 Typischer Bestellvorgang im Internet
SET beschränkt sich lediglich auf den Zahlungsvorgang. Dieser wird innerhalb eines
Bestellvorgangs entsprechend integriert.
Ein typischer Bestellvorgang kann folgendermaßen aussehen:
7Secure Electronic Transaction-Homebanking Computer Interface
1. Kartenbesitzer sieht sich Angebot an
2. Kartenbesitzer wählt Ware aus
3. Kartenbesitzer erhält Bestellformular
4. Kartenbesitzer wählt Zahlungsmethode
5. Kartenbesitzer sendet Auftrag und Zahlungsanweisung
6. Händler läßt Kartendaten überprüfen
7. Händler bestätigt Bestellung
8. Händler sendet Ware
9. Händler fordert Bezahlung an
SET soll hier die Bereiche 5, 6, 7 und 9 abdecken, also nur genau die, die den
Zahlungsvorgang ausmachen. Alle anderen Bereiche werden nicht spezifiziert und bleiben in
ihrer Ausgestaltung den Händlern überlassen.
3.3 Technische Voraussetzungen
Um überhaupt SET-Transaktionen durchführen zu können, sind einige Hürden zu meistern.
Als Grundausstattung muß der Kunde einen Rechner, der eine Verbindung zum Internet
aufbauen kann, besitzen, und einen aktuellen Browser installiert haben, um in den Online-
Shops bestellen zu können.
Außerdem muß er in Besitz einer Kreditkarte einer teilnehmenden Bank sein.
Dann muß er sich das sogenannte Wallet von seiner Bank oder im Internet besorgen.
Das Wallet ist eine Software, die den SET-Standard beherrscht und entsprechend mit den
Händlern kommunizieren kann. Die Walletsoftware bietet meist auch Funktionen, um das
eigene Zertifikat zu erstellen und getätigte Bestellungen zu verwalten. Die dazu notwendigen
Informationen bekommt man von seiner Bank.
Dieses Programm muß auf dem eigenen Rechner installiert werden und schließlich
muß er sich mit dessen Bedienung vertraut machen.
Auf Händlerseite muß ein Vertrag mit einer Inkassostelle existieren, die dem Händler erlaubt,
Kreditkartenzahlungen zu akzeptieren und abzurechnen. Auch der Server, also die
Händlersoftware, muß beschafft, installiert und in den Online-Shop integriert werden.
8Secure Electronic Transaction-Homebanking Computer Interface
3.4 Teilnehmer
SET definiert den für eine Zahlung notwendigen Nachrichtenaustausch zwischen
verschiedenen Teilnehmern. Die Teilnehmer des Zahlungssystems sind im einzelnen:
• Karteninhaber
Ein Karteninhaber besitzt eine Kreditkarte und ein zugehöriges Konto einer
kartenausgebenden Bank. Mit dieser Karte kann er am SET-Zahlungsverkehr teilnehmen.
• Kartenausgebende Bank
Diese Bank eröffnet für einen Karteninhaber ein Konto und gibt die dazugehörige
Kreditkarte aus. Die Bank führt die mit der Kreditkarte bestätigten Transaktionen aus. Sie
bestätigt gegenüber anderen die Korrektheit von Kreditkartendaten.
• Händler
Um Kreditkartenzahlungen akzeptieren zu können, muß ein Händler ein Konto bei einer
dem Kreditkartenzahlungsverkehr angeschlossenen Bank besitzen.
• Händlerbank
Die Bank des Händlers ist in das Kreditkartenzahlungssystem eingebunden. Sie kann auf
Anforderung des Händlers Kartendaten bestätigen und Zahlungen ausführen.
• Zahlungsgateway
Ein Zahlungsgateway wird von einer Inkassostelle oder einer dritten Stelle betrieben und
dient als Zwischenstation zwischen Händler und dessen Bank. Es bearbeitet
Zahlungsanweisungen, die vom Händler über offene Netze eingereicht werden und leitet
sie über bankeigene Netze an die entsprechende Inkassostelle weiter. Es ist im SET-
System die einzige Schnittstelle zwischen dem Banknetz und den offenen Netzen.
• Zertifizierungsstelle (Certificate Authority, CA)
Eine CA stellt auf Anforderung anderen Teilnehmer nach Prüfung deren Identität
sogenannte digitale Zertifikate aus, mit denen sie ihre Identität anderen Teilnehmern
gegenüber beweisen können. Dies wird ausführlicher im Kapitel Zertifikate behandelt.
Die Übergabe der Zertifikate an den Bankkunden, bzw. dem Händler sei folgenden
Abbildungen zu entnehmen.
9Secure Electronic Transaction-Homebanking Computer Interface
Abbildung 1: Übergabe eines Zertifikates an einen Händler
Abbildung 2: Übergabe eines Kreditkartenzertifikates an einen Bankkunden
10Secure Electronic Transaction-Homebanking Computer Interface
3.5 Sicherheit
Sicherheit ist der treibende Gedanke der SET-Spezifikation, daher garantiert SET folgende
Anforderungen an die Sicherheit:
• Vertraulichkeit
Nur der vorgesehene Empfänger soll eine Nachricht lesen können. SET verschlüsselt
daher die übertragenen Daten mit asymmetrischen Verschlüsselungsverfahren, so daß
festgelegt werden kann, wer eine Nachricht lesen kann. So kann also beispielsweise nur
die Bank die Kreditkartendaten kennen, nur der Händler erfährt die Details der Bestellung.
Durch die Verschlüsselung werden Übertragung und Aufbewahrung gesichert, auch ein
Einbruch auf dem Server des Händlers führt nicht mehr zum Bekanntwerden der
Kreditkartendaten.
• Integrität
Die Nachricht soll beim Empfänger so ankommen, wie sie der Absender verschickt hat.
Um Betrugsabsichten oder auch Übertragungsfehler zu verhindern bzw. zu entdecken,
arbeitet SET mit digitalen Signaturen.
• Authentizität von Karteninhaber und Händler
Der jeweilige Partner muß als legitimer Teilnehmer des Systems erkannt und seine
Identität gesichert werden. Der Händler wünscht eine Legitimation des Karteninhabers
und die Garantie der Echtheit der Kreditkartendaten, der Kunde wünscht eine
Zusicherung, daß der Händler Kreditkartentransaktionen durchführen darf. SET
ermöglicht dieses durch eine Kombination von Zertifikaten und digitalen Signaturen.
• Verbindlichkeit
Der Ursprung einer Nachricht ist zweifelsfrei feststellbar. Dies wird in SET durch
Zertifikate und Signaturen erreicht.
• Nicht-Wiederholbarkeit
Eine Nachricht soll nicht erneut verschickt werden können, was hier einer doppelten
Bestellung gleichkäme. Dies wird durch eine Kombination von Zertifikaten, Signaturen
und Identifikationsnummern erreicht.
11Secure Electronic Transaction-Homebanking Computer Interface
3.6 Zertifikate
Ein Zertifikat bindet den Namen einer Person oder Institution an deren öffentlichen Schlüssel.
Ein Zertifikat ist eine spezielle Datenstruktur, die Informationen zu einem öffentlichen
Schlüssel und dessen Besitzer beinhaltet sowie einige Verwaltungsinformationen wie z.B. den
Gültigkeitszeitraum, den verwendeten Kryptoalgorithmus etc. Ein Zertifikat ist immer digital
signiert, um seine Echtheit zu bestätigen.
Um sich zu Identifizieren muß jeder zunächst das Zertifikat seines Gegenüber erhalten. Damit
sichergestellt ist, das jeder Teilnehmer wirklich der ist, für den er sich ausgibt, werden bei
SET die Zertifikate von einer dritten vertrauenswürdigen Stelle, einer sogenannten
Zertifizierungsstelle (Certificate Authority CA) oder Trust Center (üblicherweise der eigenen
Bank), ausgegeben. Diese signiert das vorgelegte Zertifikat und garantiert damit, daß sie die
Identität des Besitzers bestätigt hat. Zertifizierungsstellen können ihrerseits wieder ihre
Zertifikate durch übergeordnete Zertifizierungsstellen signieren lassen, bis hin zu einer Root-
Zertifizierungsstelle mit dem Root-Key, von dem alle anderen direkt oder indirekt
authentifiziert sind.
Abbildung 3: Hierarchie der Zertifizierungsstellen, vereinfacht mit geringer Hierarchietiefe
12Secure Electronic Transaction-Homebanking Computer Interface
Ein Teilnehmer wird üblicherweise den Schlüssel seiner eigenen Zertifizierungsstelle
kennen, aber nicht die aller anderen. Kennt er den Wurzelschlüssel, kann er über diesen zu
jedem beliebigen Zertifikat in der Vertrauenshierarchie eine Zertifizierungskette durchlaufen,
indem er ausgehend vom Wurzelschlüssel den Baum bis zum gewünschten Schlüssel
durchläuft und dabei jeweils die Gültigkeit der Signaturen überprüft.
Wenn ein Zertifikat zum Beispiel durch Diebstahl oder Mißbrauch nicht mehr als sicher
angesehen werden kann, ist ein Zertifikatswiderruf möglich. In einer Zertifikatswiderrufsliste
werden die Seriennummern von Zertifikaten abgelegt, die schon vor ihrem Ablaufdatum nicht
mehr gültig sind. Bei einer Prüfung eines Zertifikats muß anhand dieser Liste festgestellt
werden, ob das Zertifikat nicht eventuell ungültig ist.
3.7 Ablauf
Der SET-Standard definiert eine Reihe von Transaktionen, über die die Zahlungen und
Abrechnungen erfolgen. Diese teilen sich auf in solche, die für die Durchführung von
Zahlungen unbedingt notwendig sind und in solche, die Zusatzfunktionen bereitstellen. Die
wichtigen Basisfunktionen werden hier ausführlich vorgestellt, Eine vollständige Darstellung
der Transaktionen findet sich SET-Spezifikationen unter www.setco.org .
Die folgenden Punkte enthalten jeweils eine Grafik die darauffolgend in schriftlicher Form
genauer ergänzt wird. Die Grafik besteht aus drei Spalten. Die erste Spalte beschreibt die
Informationen, die im Besitz des Karteninhabers/Händlers sind (fettgedruckt) und die
Aktionen des Karteninhabers/Händler (kursiv). Die dritte Spalte die Informationen und
Aktionen der Zertifizierungsstelle / Zahlungsgateways. Die zweite Spalte zeigt in welcher
Form die Datensätze über das Internet übertragen werden. Man wird sehen, daß die
Übertragung von relevanten Daten verschlüsselt vonstatten geht und so eine gewisse
Sicherheit gewährleistet wird.
13Secure Electronic Transaction-Homebanking Computer Interface
1. Registrierung des Karteninhabers (Cardholder Registration)
• Karteninhaber müssen sich bei einer Zertifizierungsstelle (CA) registrieren, bevor sie
SET- Nachrichten austauschen können. Um mit der CA kommunizieren zu können,
braucht der Karteninhaber die Zertifikate, die im ersten Schritt bezogen werden.
• Um die Zertifizierungskette nachzuvollziehen, braucht der Karteninhaber den Root Key,
der meist in der Wallet-Software eingebaut ist.
• nach Abschluß dieser Transaktion ist der Karteninhaber im Besitz eines gültigen
Zertifikates.
1 Öffentlicher Rootkey der CA Public-Private-Key Paar der
(öRootKey) CA (öKeyCA, pKeyCA)
Anfrage
Antwort = öffentlicherKey der
2
CA (öKeyCA)
Sign pRootKey(Antwort) +
Zertifikat der CA
3 Vergleichen:Zertifikat der CA (Z-CA)
über Zertifizierungskette
öKeyCA= EnSignöRootKey(Antwort)
Generierung: zufälliger Schlüssel S1
Nachricht = DecS1(Kartennummer)
SignöKeyCA(Nachricht+S1)
EnSignpKeyCA(Nachricht+S1)
4
S1
Kartenummer=EncS1(Nachric
ht)
Bereitstellung: Formular
SignpKeyCA(Formular)+Z-CA
5 Formular=EnSignöKeyCA(Formular)
Ausfüllen: Formular
Erstellen: Key-Paar Karteninhaber
(öKeyKI & pKeyKI)
Generierung: zufälliger Schlüssel S2
Generierung: zufälliger Schlüssel S3
Erzeugung: Zufallszahl Z1
14Secure Electronic Transaction-Homebanking Computer Interface
Nachricht=DecS3(Formular+öKeyKI+
S2)
SignöKeyCA(Nachricht+S3+Z1)
6
EnSignpKeyCA(Nachricht+S3+Z
1)
S3, Z1, Nachricht
Formular, öKeyKI, S2 =
EncS3(Nachricht)
Erzeugung: Zufallszahl Z2
Erstellung: Geheimzahl GZ
aus Z1 und Z2
Generirung: Zertikfikat des
Karteninhabers (Z-KI)
Berechnung der Prüfsumme
um Zertifikat an Karte zu
Binden.
7 Z2, Z-KI =
DecS2(Antwort)+Z2 Antwort=SignpKeyCA(Z-KI)
EncS2[SignöKeyCA(Antwort)]
Erstellung: Geheimzahl GZ aus Z1
und Z2
1. Karteninhaber -> Initiate Request -> Zertifizierungsstelle
•Anfrage nach dem Zertifikat der CA, um im folgenden verschlüsselt kommunizieren
zu können
2. Karteninhaber Zertifizierungsstelle
• Der Karteninhaber vergleicht die Zertifikate über die Zertifizierungskette und
überprüft die Antwort, indem er deren Signatur mit dem öffentlichen
Signaturschlüssel der CA dekodiert und mit einer selbsterstellten Prüfsumme
vergleicht.
• Die eingegebene Kartennummer wird in eine Nachricht eingebettet.
• Die Nachricht wird verschlüsselt mit zufälligem symmetrischen Schlüssel S1
•
Kartennummer und symmetrischer Schlüssel S1 werden mit dem öffentlichen
Schlüssel der CA verschlüsselt und zusammen mit der Nachricht abgeschickt.
4. KarteninhaberSecure Electronic Transaction-Homebanking Computer Interface
• Nach der Entschlüsselung der übertragenen Daten ermittelt die CA die Bank des
Karteninhabers (anhand der ersten Stellen der Kartennummer) und verwendet das
entsprechende Antragsformular.
• Das Formular wird von der CA digital signiert.
• Dies wird zusammen mit dem Zertifikat der CA versendet.
5. Karteninhaber -> Cardholder Certificate Request -> Zertifizierungsstelle
• Der Karteninhaber vergleicht das empfangene Zertifikat anhand der
Zertifizierungskette und überprüft die Signatur des Formulars.
• Der Karteninhaber füllt das Anmeldeformular aus
• Er erstellt ein Public-Private-Key-Paar für die Signatur, erzeugt einen zufälligen
symmetrischen Schlüssel S2 und generiert eine Zufallszahl Z1.
• Das ausgefüllte Formular, der öffentliche Signaturschlüssel des Karteninhabers und
der symmetrische Schlüssel S2 werden mit einem zufälligen, symmetrischen Schlüssel
S3 verschlüsselt.
• Dieser Block, der Schlüssel S3, die Kartennummer, das Ablaufdatum der Karte und
die Zufallszahl Z1 werden dann mit dem öffentlichen Schlüssel der CA verschlüsselt
6. KarteninhaberSecure Electronic Transaction-Homebanking Computer Interface
nicht näher. Es ist jedoch klar, daß diese Daten die Identität des Karteninhabers
gegenüber dem System bestätigen und somit extrem schutzbedürftig sind und von der
Walletsoftware geeignete Maßnahmen gegen das Ausspionieren getroffen werden
müssen.
2. Registrierung des Händlers (Merchant Registration)
• Händler müssen sich bei einer CA registrieren, um SET-Transaktionen anbieten zu
können.
• Der Händler braucht eine Inkassostelle, die seine Zahlungstransaktionen abwickelt.
• Die Zertifikate der CA werden im ersten Schritt bezogen
• Nach Abschluß dieser Transaktion ist der Händler im Besitz eines gültigen Zertifikats.
1 Öffentlicher Rootkey der CA Public-Private-Key Paar der CA
(öRootKey) (öKeyCA, pKeyCA)
Anfrage+ Bekanntgabe der
Inkassostelle
Bereitstellung:
2
Anmeldeformular
Antwort=Anmeldeformular +
Zertifikat der CA (Z-CA)+
SignpRootKey(Antwort) (öKeyCA)
3 öKeyCA, Z-CA, Formular =
EnSignöRootKey(Antwort)
Erstellung: zwei public-private-
Key-Paare (öKeyH1, pKeyH1 &
öKeyH2, pKeyH2)
Ausfüllen: Formular
Generierung: zufälliger Schlüssel
S1
Nachricht=DecS1(öKeyH1+
öKeyH2+ Formular)
SignöKeyCA(Nachricht+S1)
EnSignpKeyCA(Nachricht+S1)
4
öKeyH1, öKeyH2, Formular =
EncS1(Nachricht)
17Secure Electronic Transaction-Homebanking Computer Interface
EncS1(Nachricht)
Generierung: Händlerzertifikat
ZH
SignpKeyCA(Antwort)
5 EnSignöKeyCA(Antwort) Antwort=DecöKeyH1(ZH)
Händlerzertifikat ZH =
EncpKeyH1(Antwort)
1. Händler -> Initiate Request -> Zertifizierungsstelle
• Anfrage nach dem Zertifikat der CA, um im folgenden verschlüsselt kommunizieren
zu können.
• In diesem Schritt gibt der Händler auch seine Inkassostelle bekannt.
2. Händler Zertifizierungsstelle
• Händler vergleicht die Zertifikate und prüft die Signatur des Formulars
• Der Händler erstellt zwei Public-Private-Key-Paare, eins für Signatur und eins für
Verschlüsselung.
• Er füllt das Formular aus mit Name, Adresse und Händler-ID.
• Das ausgefüllte Formular mit den beiden öffentlichen Schlüssel wird mit einem
zufälligen symmetrischen Schlüssel S1 verschlüsselt.
• S1 wird zusammen mit den Kontodaten des Händlers mit dem öffentlichen Schlüssel
der CA verschlüsselt und zusammen mit dem verschlüsselten Formular mit den
Schlüsseln gesendet
4. HändlerSecure Electronic Transaction-Homebanking Computer Interface
3. Kaufgesuch (Purchase Request)
• Diese Transaktion bildet aus Benutzersicht den Hauptbestandteil des Systems.
• Die Daten werden beim Händler aufgeteilt und der Teil mit den Zahlungsdaten in einer
separaten Transaktion vom Händler an das Zahlungsgateway weitergeleitet.
• Die Transaktion wird erst nach der Komplettierung der Bestellung durchgeführt. Zuvor
wurden schon alle Einzelheiten der Bestellung und Zahlung festgelegt.
1 Öffentlicher Schlüssel des Öffentlicher Schlüssel des
Zahlungsgateways öKeyZ, Karteninhabers öKeyKI
öffentlicher Schlüssel des
Händlers öKeyH
Anfrage + Kreditkartenmarke
Kreditkartenmarke
2
Generierung:
Transaktionsnummer TI
SignöKeyKI(TI+Zertifikate)
3 EnSignpKeyKI(TI+Zertifikate)
Generierung: Bestellinformatio OI
Generierung: Zahlungsinformatio
PI
Generierung: dualen Signatur für
OI und PI (Prüfsumme)
Erzeugung: zufälligen Schlüssel
S1
DecS1(PI)
DecöKeyZ(S1)
Nachricht= DecSig(PI)+OI OI+ DecS1(PI)+ DecöKeyZ(S1)+
Prüsumme+ Zertifikat des
19Secure Electronic Transaction-Homebanking Computer Interface
Prüsumme+ Zertifikat des
Karteninhabers Z-KI
OI, DecS1(PI), DecöKeyZ(S1),
4 Z-KI
Vergleich: Z-KI,duale Signatur
SignöKeyKI(Auftragsbestätigung)
5 EnSignpKeyKI(Auftragsbestätigung)
1. Karteninhaber -> Initiate Request -> Händler
•Anfrage nach den Schlüsseln des Zahlungsgateways und des Händlers zusammen mit
einer Angabe über die Kreditkartenmarke
2. Karteninhaber Händler
• Der Karteninhaber vergleicht die Zertifikate.
• Er generiert eine Bestellinformation (Order Information, OI) und eine
Zahlungsinformation (Payment Information, PI). In beiden wird die TI vermerkt, so
daß das Zahlungsgateway sie später miteinander in Verbindung setzen kann.
• Der Karteninhaber generiert eine duale Signatur für OI und PI
• Er erzeugt einen zufälligen symmetrischen Schlüssel S1 und verschlüsselt damit PI.
• S1 wird dann zusammen mit den Karteninformationen mit dem öffentlichen Schlüssel
des Zahlungsgateways verschlüsselt.
•OI und die verschlüsselten PI und S1 werden dann zusammen mit den Prüfsummen
von OI und PI und dem Zertifikat des Karteninhabers an den Händler geschickt.
Durch die Verschlüsselung von PI kann der Händler diese Information nicht mitlesen.
4. KarteninhaberSecure Electronic Transaction-Homebanking Computer Interface
•Er generiert eine Bestätigung des Auftrags, signiert diese und schickt sie an den
Kunden.
5. Der Karteninhaber
• Der Karteninhaber vergleicht das Zertifikat und prüft die Signatur
Die Antwort wird als Bestätigung der Bestellung im Wallet vermerkt.
4. Zahlungsautorisierung (Payment Authorization)
• Während der Behandlung des Kaufgesuches zwischen Kunde und Händler holt der
Händler vom Zahlungsgateway die Bestätigung der Kundendaten und die Autorisation zur
Abbuchung ein.
1 Transaktionnummer TI Öffentlicher Schlüssel des
Händlers öKeyH
Bestellinformation OI
Schlüssel S1 vom Kunden
DecS1(PI), DecöKeyZ(S1) vom
Kunden
Öffentlicher Schlüssel des
Zahlungsgateway öKeyZ
Generiert: Autorisierungswunsch=
TI+ OI+ Betrag
SignpKeyH(Autorisierungswunsch)
Generierung: zufälligen Schlüssel
S2
DecS2[SignpKeyH(Autorisierungs-
wunsch)] +decöKeyZ(S2) +
DecS1(PI) + DecöKeyZ(S1)
EncpKeyZ(S2)
2
EncS2[ EnSignöKeyH
(Autorisierungswunsch)]
Autorisierungswunsch
beinhaltet TI, OI und Betrag
vom Händler
EncpKeyZ(S1)
EncS1(PI)
21Secure Electronic Transaction-Homebanking Computer Interface
PI beinhaltet TI, OI und Betrag
vom Kunden
Vergleich: der Beträge und Tis
Einholen: Zahlungsbestätigung
ZB der Bank
Generierung: zufallige
Schlüssel S3, S4 und
Einzugsmarke mit
Kontoinformationen des
DecS3(ZB)+SignöKeyH(S3) + Kunden
DecöKeyZ[DecS4(Einzugsmarke)
+ S4]
3 EnSignpKeyH(S3)
EncS3(ZB)
DecöKeyZ[DecS4(Einzugsmarke) +
S4] für späteren Einlösevorgang
1. Händler -> Authorization Request -> Zahlungsgateway
• Der Händler generiert einen Autorisierungswunsch mit der Transaktionsnummer aus
der Bestellinformation und dem abzubuchenden Betrag.
• Dieser Autorisierungswunsch mit TI und Betrag wird signiert.
• Der signierte Autorisierungswunsch wird mit einem zufälligen symmetrischen
Schlüssel S2 verschlüsselt
• S2 wird mit dem öffentlichen Schlüssel des Zahlungsgateways verschlüsselt (also mit
dem Schlüssel, den auch schon der Kunde verwendet hat).
• Diese Komponenten werden zusammen mit der Zahlungsinformation, die der Händler
vom Kunden erhalten hat, und den Zertifikaten von Karteninhaber und Händler an das
Zahlungsgateway gesendet.
2. HändlerSecure Electronic Transaction-Homebanking Computer Interface
• Die Zahlungsautorisation wird über bankeigene Netze an die Bank des Kunden
weitergeleitet und die Antwort abgewartet.
• Das Zahlungsgateway generiert eine Bestätigung aus der Antwort der Bank, signiert
und verschlüsselt sie mit einem zufälligen symmetrischen Schlüssel S3 und
verschlüsselt S3 mit dem öffentlichen Schlüssel des Händlers
• Zusätzlich generiert das Zahlungsgateway eine Einzugsmarke, die später bei der
Zahlungsanforderung verwendet wird.
• Diese wird mit einem zufälligen symmetrischen Schlüssel S4 verschlüsselt, dieser
Schlüssel und die Kontoinfomationen des Kunden werden schließlich mit dem
öffentlichen Schlüssel des Zahlungsgateways verschlüsselt, so daß nur das Gateway
diese Informationen wieder lesen kann.
• Diese Komponenten werden zusammen mit dem Zertifikat des Gateways versendet.
3. Der Händler
• Der Händler vergleicht das Zertifikat und prüft die Signatur.
Die Antwort der Bank und die Einzugsmarke werden für den späteren Einlösevorgang
abgelegt. Der Händler kann jetzt das Kaufgesuch mit dem Kunden weiter abarbeiten.
5. Zahlungseinzug (Payment Capture)
• Nachdem der Händler die Bestellung ausgeführt hat, wird er die Zahlung einfordern. Dies
kann durchaus lange nach der Autorisierung der Zahlung geschehen.
• Mit diesem Schritt ist eine Zahlungsbearbeitung üblicherweise abgeschlossen.
1 Generierung: zufälliger Schlüssel
S5
Generierung: endgültige
Zahlungsanforderung ZA mit TI
DecS5(ZA) +DecöKeyZ(S5) +
DecöKeyZ[DecS4(Einzugsmarke
) + S4]
2 EncpKeyZ(S5)
EncS5(ZA)
EncpKeyZ[DecS4(Einzugsmarke) +
S4]
EncS4(Einzugsmarke)
Vergleich: TI von ZA und von
Einzugsmarke
23Secure Electronic Transaction-Homebanking Computer Interface
Zahlung über Bank wird
eingeleitet
Generierung: Bestätigung und
zufälligen Schlüssel S6
DecS6(Bestätigung) +
3 SignöKeyH(S6)
EnSignpKeyH(S6)
EncS6(Bestätigung)
1. Händler -> Capture Request -> Zahlungsgateway
• Der Händler generiert eine Zahlungsanforderung mit dem endgültige Betrag und der
Transaktionsnummer
•
Diese wird signiert und mit einem zufälligen symmetrischen Schlüssel S5 kodiert. S5
wird mit dem öffentlichen Schlüssel des Zahlungsgateways verschlüsselt und
zusammen mit der verschlüsselten Einzugsmarke aus der Zahlungsautorisierung an
das Gateway geschickt
2. HändlerSecure Electronic Transaction-Homebanking Computer Interface
4.0 HBCI
Die Abkürzung HBCI steht für Homebanking Computer Interface und wird das zur Zeit
benutzte Verfahren mit PIN/TAN ablösen. Die Spezifikation des HBCI Standard wird vom
Zentralen Kreditausschuß des Kreditgewerbes (ZKA) festgelegt.
Das PIN/TAN Verfahren wird bereits seit Jahren als unkomfortabel und als
sicherheitstechnisch bedenklich eingestuft, so daß sich die Kreditwirtschaft im Jahre 1997 für
diesen neuen Standard entschieden hat. Auch die zunehmende Verbreitung des Internet und
anderer Kommunikationssysteme führte zu diesem neuen Verfahren. Die Anforderungen der
Kunden sind ebenfalls gestiegen. So werden heute nicht nur einfache Bankgeschäfte getätigt
sondern auch Wertpapiergeschäfte, die zunehmend auch über das Internet abgewickelt
werden.
Dieser neue Standard sollte folgende Kriterien erfüllen:
• Multibankfähigkeit
Hierbei können sowohl die Benutzer und die Softwarehersteller auf eine definierte
Schnittstelle zurückgreifen. Der Kunde hat somit den Vorteil, daß er nur eine Software
benötigt, mit der er seine Geschäfte sowohl bei der Bank A, als auch bei der Bank B
abwickeln kann.
• Transportmedienunabhängigkeit
Das neue Verfahren soll unabhängig sein vom eingesetzten Medium oder Betriebssystem.
• Endgeräteunabhängig
Homebanking wird in Zukunft unabhängig vom Endgerät sein. Es lassen sich dann auch
die Bankgeschäfte über das Handy oder den Fernseher abwickeln.
• Dokumentensicher
Die erteilten Aufträge an die Banken werden durch Einführung einer digitalen Signatur
fälschungssicher.
• Offen gegenüber internationalen Standards
Der Aufbau des HBCI Systems ist so ausgelegt, daß es auch im internationalen
Geldverkehr zum Einsatz kommen könnte. In Aussicht steht die Einführung von HBCI
europaweit.
• Flexibel
HBCI läßt sich über eine Chipkarte oder eine Datei ausführen. Der Kunde hat somit die
Wahl, ob er die Chipkarte benutzt oder aber eine Datei, die Ihm auf Diskette zur
Verfügung gestellt wird.
25Secure Electronic Transaction-Homebanking Computer Interface
Bei beiden Verfahren wird eine PIN (Hashwert bei der Diskette) Eingabe notwendig,
womit sich der Benutzer identifiziert.
Diskette
HBCI
Kunde
Kreditinstitut
Chipkarte
Abbildung 8: Übersicht der Schnittstellenbeziehungen
Zukünftige Anwendungen, wie das Laden der Geldkarte, würden sich dann z.B. am
heimischen PC durchführen lassen. Auch individuelle Beratungen mittels Videosequencen
wären so außerhalb der Öffnungszeiten möglich.
Da das System über eine Schichtenstruktur (OSI) aufgebaut ist, ist es unabhängig vom
zugrunde liegenden Transportmedium. So läßt sich die Verschlüsselung der Daten über eine
Chipkarte durchführen, als auch über eine Datei, die mittels Diskette zur Verfügung gestellt
wird. Die Möglichkeit einer Manipulation sehe ich bei der Diskettenversion eher als gegeben,
da bei der Chipkarte nur verschlüsselt auf die Daten zugegriffen werden kann.
HBCI ist zur Zeit nur als nationaler Standard vorgesehen, soll aber als europäischer Standard
vorgeschlagen werden. Die Verschlüsselung der Informationen wird mit international
anerkannten symmetrischen und asymmetrischen Verfahren durchgeführt. Dies sind
Verschlüsselungsverfahren wie DES, RSA und eine Kombination beider Verfahren, dem
RDH (RSA-DES-Hybridverfahren).
26Secure Electronic Transaction-Homebanking Computer Interface
Zunächst wird es neben der Geldkarte eine eigene Karte für das Homebanking geben. Das
Problem ist zur Zeit die Geldkarte auf Chips zu portieren, die die als sicher geltende RSA
Verschlüsselung unterstützen. Das Ganze muß dann natürlich noch zu einem akzeptablen
Preis zu realisieren sein. Das Ziel, die Geldkarte mit der Homebankingkarte zu vereinigen, ist
für Anwendungen, wie z.B. das Aufladen der Geldkarte über das Internet, Voraussetzung.
4.0 Aufbau der Nachrichtenelemente
Die Erteilung eines Auftrags durch den Kunden an die Bank erfolgt über Nachrichten, die
eine speziellen Aufbau haben. Hierdurch wird sichergestellt, daß jeder erteilte Auftrag durch
eine digitale Signatur unterzeichnet werden muß. Die einzelnen Aufträge werden
anschließend zu einer Nachricht zusammengefaßt. Die komplette Nachricht wird dann
chiffriert an das Bankinstitut gesendet.
4.1 Trennung der Elemente
Der Aufbau der Nachrichtenelemente beim HBCI erfolgt durch mehrere Elemente, die durch
Syntaxzeichen voneinander getrennt werden.
Diese Art der Trennung hat sich bereits auch in anderen Anwendungen bewährt.
Zeichen Bedeutung
+ Datenelement (DE)-Trennzeichen
: Gruppendatenelement (GD)-Trennzeichen
' Segmentende-Zeichen
? Freigabezeichen
@ Binärdatenkennzeichen
Abbildung 9: Übersicht der Trennzeichen
27Secure Electronic Transaction-Homebanking Computer Interface
4.2 Aufbau einer Nachricht
Durch die Verwendung der Trennzeichen, lassen sich drei verschiedene, logische
Hierarchieebenen abbilden:
Nachrichtenkopf Segmentkopf
GD 1
Segment 1 DE 1 (DEG 1)
.
. .
Nachricht
. DEG 2 (DE 2) .
.
.
. .
Segment n . .
.
GD n
Nachrichtenabschluß DE n (DEG n)
Abbildung 10: Nachrichtenaufbau
• Die Nachricht setzt sich aus dem Nachrichtenkopf und dem Nachrichtenabschluß
zusammen. Zwischen diesen beiden Elementen befinden sich die Segmente, die jeweils
einen Geschäftsvorgang definieren.
• Ein Segment setzt sich wiederum aus dem Segmentkopf und dem Segmentende-Zeichen
zusammen. Da ein Segment einen Geschäftsvorgang beschreibt, kann sich eine Nachricht
aus mehreren Segmenten zusammensetzen, die unterschiedliche Geschäftsvorfälle
darstellen.
• Zusammengehörende Daten können zu einer syntaktischen Einheit zusammen gefaßt
werden. Hierzu werden die Datenelementgruppen (DEG) gezählt, die wiederum aus den
Gruppendatenelementen (GD) bestehen und den Datenelementen (DE). Logisch
zusammengehörende Datenelemente (z.B. Bankleitzahl [DE 1] und Kontonummer [DE
2]) bilden eine logische Einheit (GD), weil sie alleine keinen Sinn ergeben.
• Die kleinste Dateneinheit bilden die Datenelemente (DE). Dies können z.B. Bankleitzahl
oder Kontonummer sein.
Segmentkopf+DE+GD:GD+GD:::GD'
Abbildung 11: Beispiel für ein Segment
28Secure Electronic Transaction-Homebanking Computer Interface
4.3 Bildung einer Nachricht
Bis auf einige Ausnahmen werden generell die Kunden- als auch die
Kreditinstitutsnachrichten verschlüsselt.
1. Als erstes werden die Informationen im System des Senders aus Datenelementen
zusammengesetzt, wie zuvor beschrieben. Die Segmente bilden jeweils einen
Geschäftsvorgang und müssen mit einer elektronischen Signatur „unterschrieben“ werden.
2. Für jedes Segment wird eine elektronische Signatur gebildet:
• Erstellung des Signaturkopf
• Berechnung der elektronischen Signatur über das einzelne Segment
• Erstellung des Signaturabschluß
3. Verschlüsselung der Nachricht
Beim Empfänger wird die Nachricht in umgekehrter Reihenfolge entschlüsselt.
4.4 Nachrichtenaufbau
Der Verbindungsaufbau geht stets vom Kunden aus. Hierzu wird die Kundennachricht an das
Kreditinstitut gesendet, worauf mit einer fest definierten Kreditinstitutsnachricht geantwortet
wird. Erst wenn diese Nachricht vollständig auf der Kundenseite empfangen wurde, kann die
erste Auftragsnachricht an das Kreditinstitut gesendet werden. Nach der letzten
Auftragsnachricht sendet der Kunde an das Kreditinstitut eine Dialogendenachricht, um die
Verbindung zu beenden. Erst nach Bestätigung der Dialogendenachricht vom Kreditinstitut
wird der Dialog beendet. Während der Verbindung darf nur eine Seite jeweils senden. Dies
wird dadurch festgelegt, daß erst nach dem Empfang der Nachricht von der Gegenstelle
erneut gesendet werden darf.
29Secure Electronic Transaction-Homebanking Computer Interface
Aufbau der physikalischen Verbindung
Dialoginitialisierung
K
Antwort auf Dialoginitialisierung r
e
Auftragnachricht 1 d
Antwortnachricht i
K
t
u .
. i
n
. n
d
Auftragnachricht n s
e
Antwortnachricht
t
i
t
Dialogendenachricht
u
Antwortnachricht t
Abbau der physikalischen Verbindung
Abbildung 12: Verbindungsaufbau
5.0 Einleitung Verschlüsselung HBCI
Beim HBCI Verfahren werden grundsätzlich zwei Schlüssel zum Chiffrieren und
Dechiffrieren verwendet. Die Schlüssel setzen sich aus dem symmetrischen DES Algorithmus
und dem asymmetrischen RSA Algorithmus zusammen. Die eingesetzten
Verschlüsselungsverfahren werden mit DDV (DES-DES Verfahren) und mit RDH (RSA-
DES-Hybridverfahren) bezeichnet. Angestrebt wird jedoch eine einheitliche Lösung,
basierend auf einer RSA Chipkartenlösung. Diese Lösung läßt sich zur Zeit technisch noch
nicht überall realisieren und wird deshalb noch nicht flächendeckend eingesetzt.
5.1 Schlüsselverwaltung
Die Verwaltung der benutzten Schlüssel ist bei beiden Verfahren gleich zu betrachten. So
verfügen Kunde und Kreditinstitut jeweils über einen Signierschlüssel (DDV), bzw. einem
Signierschlüsselpaar (RDH) und einem Chiffrierschlüssel (DDV), bzw. einem
Chiffrierschlüsselpaar (RDH).
30Secure Electronic Transaction-Homebanking Computer Interface
Der Signierschlüssel wird zum Unterzeichnen von Transaktionen verwendet, während der
Chiffrierschlüssel zum Verschlüsseln von Nachrichten dient.
DDV (RDH)
Signierschlüssel Chiffrierschlüssel
(Signierschlüsselpaar) (Chiffrierschlüsselpaar)
Abbildung 13: Schlüsselverwaltung
5.2 Zusammensetzung der Schlüssel
Die Zusammensetzung der Schlüssel, sowohl im 2-KEY-TRIPLE-DES Verfahren als auch im
RSA Verfahren, setzt sich wie folgt zusammen:
• Ländercode (max. 3 Byte)
• Kreditinstitut (max. 30 Byte, normalerweise Bankleitzahl)
• Benutzerkennung (max. 30 Byte, kann vom Kreditinstitut festgelegt werden z.B.
Kontonummer)
• Schlüsselart (1 Byte, S:Signierschlüssel, V:Chiffrierschlüssel)
• Schlüsselnummer (max. 3 Byte [Zur Identifizierung der jeweiligen Schlüssel])
• Versionsnummer (max. 3 Byte)
5.3 Elektronische Signatur beim DDV Verfahren
Die Bildung der elektronischen Signatur erfolgt in drei Schritten.
1. Als erstes wird mit einer Einweg-Hash-Funktion die Länge der Signatur auf ein fest
definiertes Maß, in unserem Fall 20 Byte, komprimiert. Bei diesem Verfahren werden
Dokumente mit variabler Länge zu einem Wert mit fester Länge berechnet. Hierbei wird
der Inhalt des Dokuments in komprimierter, nicht rückrechenbarer Form dargestellt. Bei
31Secure Electronic Transaction-Homebanking Computer Interface
der Hash Funktion handelt es sich um den RIPEMD-1601 One-Way-Hashfunktion, die
kryptographische Prüfsumme von 160 Bit (20 Byte) Länge erzeugt
2. Im zweiten Schritt wird der 20 Byte lange Hashwert mit Hilfe des Paddingverfahren auf
ein vielfaches von 8 Byte aufgefüllt. Hierzu wird der 20 Byte lange Hashwert auf 24 Byte
aufgefüllt, so daß sich 3 Blöcke zu 8 Byte ergeben. Dieser Schritt ist nötig, da das DES
Verfahren blockorientiert arbeitet.
3.
Initialisierungsvektor
Block 1 XOR Verknüpfung Verschlüsselung
Block 2 XOR Verknüpfung Verschlüsselung
Block 3 XOR Verknüpfung Verschlüsselung
Abbildung 14: Cipher Block Chaining (CBC) Modus
4. Im letzten Schritt erfolgt die Berechnung der elektronischen Signatur. Hierzu wird der
zuvor gepaddete Hashwert in 3 Blöcke der Länge 8 Byte aufgeteilt. Mit Hilfe eines
Initialisierungsvektor wird ein einfacher CBC-MAC über die ersten 2 Blöcke berechnet.
Hierbei wird die linke des Signierschlüssel verwendet. Anschließend erfolgt eine 2-KEY-
TRIPLE-DES Verschlüsselung mit dem Signierschlüssel des Kunden über die XOR
1
Der RIPEMD 160 ist ein Verfahren zur Erzeugung einer 160 Bit langen, kryptographischen Prüfsumme. Bisher
sind noch keine Schwachstellen bekannt geworden.
32Secure Electronic Transaction-Homebanking Computer Interface
Summe des Zwischenergebnisses mit dem letzten Nachrichtenblock. Der Signierschlüssel
muß zuvor im Kreditinstitut hergeleitet werden.
5.4 Elektronische Signatur beim RDH Verfahren
Die Verschlüsselung der elektronischen Signatur beim RDH Verfahren wird anders realisiert
als beim DDV Verfahren. Sie erfolgt aber auch in drei Schritten.
1. Wie beim DDV Verfahren, wird auch beim RDH Verfahren zunächst ein Hashwert
gebildet.
2. Der Hashwert wird für die nachfolgende Signaturbildung als Langzahl interpretiert.
3. Der Hashwert wird mittels RSA signiert.
5.5 Erstellen des Chiffrierschlüssel
Bei der Verschlüsselung der Nachrichten wird für jede Nachricht ein individueller Schlüssel
generiert. Hierzu wird auf der Chipkarte oder mit Hilfe der Datei auf Diskette, eine
individuelle Zufallszahl generiert. Dieser Schlüssel wird dynamisch von dem sendenden
System generiert
Die Verschlüsselung der Daten wird generell mit dem 2-Key-Triple-DES durchgeführt.
Dieses Verfahren wird ebenfalls in drei Schritten durchgeführt, wobei die ersten beiden
Schritte bei beiden Verfahren (DDV und RDH) gleich verläuft.
1. Zunächst wird vom Sender eine Zufallszahl generiert, die als Nachrichtenschlüssel
verwendet wird. Sicherzustellen ist hierbei, daß die Parität ungerade ist und daß es sich
nicht um einen schwachen oder halbschwachen Schlüssel handelt. Da es bei schwachen
bzw. halbschwachen Schlüsseln häufig Wiederholungen der einzelnen Elemente
vorkommen, sollten diese nicht verwendet werden.
Die schwachen Schlüssel des DES-Algorithmus:
X’01 01 01 01 01 01 01 01’
X’FE FE FE FE FE FE FE FE’
X’1F 1F 1F 1F 0E 0E 0E 0E’
X’E0 E0 E0 E0 F1 F1 F1 F1’
33Secure Electronic Transaction-Homebanking Computer Interface
Die halbschwachen Schlüssel des DES-Algorithmus:
X’01 FE 01 FE 01 FE 01 FE’
X’FE 01 FE 01 FE 01 FE 01’
X’1F E0 1F E0 0E F1 0E F1’
X’E0 1F E0 1F F1 0E F1 0E’
X’01 E0 01 E0 01 F1 01 F1’
X’E0 01 E0 01 F1 01 F1 01’
X’1F FE 1F FE 0E FE 0E FE’
X’FE 1F FE 1F FE 0E FE 0E’
X’01 1F 01 1F 01 0E 01 0E’
X’1F 01 1F 01 0E 01 0E 01’
X’E0 FE E0 FE F1 FE F1 FE’
X’FE E0 FE E0 FE F1 FE F1’
34Secure Electronic Transaction-Homebanking Computer Interface
2. Der generierte Schlüssel wird verwendet, um die Daten mittels 2-Key-Triple-DES im
CBC Modus zu verschlüsseln. Der verwendete Initialisierungsvektor wird in einen linken
und einen rechten Schlüssel unterteilt, so daß zwei unterschiedliche Schlüssel für das
2-Key-Triple-DES Verfahren zur Verfügung stehen.
Klartextblock 1 Klartextblock 2 Klartextblock 3
+ + +
DES
DES
DES
Schlüssel 1 Schlüssel 1 Schlüssel 1
verschlüsseln verschlüsseln verschlüsseln
Initialisierungsvektor
DES
DES
DES
Schlüssel 2 Schlüssel 2 Schlüssel 2
entschlüsseln entschlüsseln entschlüsseln
DES
DES
DES
Schlüssel 1 Schlüssel 1 Schlüssel 1
verschlüsseln verschlüsseln verschlüsseln
63 0 63 0 63 0
verschlüsselter Textblock 1 verschlüsselter Textblock 2 verschlüsselter Textblock 3
Schlüssel 1: linke Schlüsselhälfte
Schlüssel 2: rechte Schlüsselhälfte
Abbildung 15: 2-Key-Triple-DES im CBC Modus
3. DDV Verfahren
Der aktuelle Nachrichtenschlüssel wird mit dem 2-Key-Triple-DES, im ECB Modus
verschlüsselt. Hierzu wird der auf der Chipkarte abgelegte Chiffrierschlüssel verwendet.
Beim verwendeten ECB Blockmodus wird der zu verschlüsselnde Text in drei Blöcke
aufgeteilt und mit dem 2-Key-Triple-DES verschlüsselt. Am Ende kommen drei
verschlüsselte Blöcke heraus. Bei dieser Methode der Verschlüsselung ist es für einen
Angreifer leichter, die Nachricht zu entschlüsseln. Das CBC Blockverfahren gilt als
bessere Alternative, da eine XOR Verschlüsselung mit den vorangegangenen Blöcke
durchgeführt wird.
35Secure Electronic Transaction-Homebanking Computer Interface
Klartextblock 1 Klartextblock 2 Klartextblock 3
DES
DES
DES
Schlüssel 1 Schlüssel 1 Schlüssel 1
verschlüsseln verschlüsseln verschlüsseln
DES
DES
DES
Schlüssel 2 Schlüssel 2 Schlüssel 2
entschlüsseln entschlüsseln entschlüsseln
DES
DES
DES
Schlüssel 1 Schlüssel 1 Schlüssel 1
verschlüsseln verschlüsseln verschlüsseln
63 0 63 0 63 0
verschlüsselter Textblock 1 verschlüsselter Textblock 2 verschlüsselter Textblock 3
Schlüssel 1: linke Schlüsselhälfte
Schlüssel 2: rechte Schlüsselhälfte
Abbildung 16: 2-Key-Triple-DES im ECB-Mode
Der komplette Ablauf der Verschlüsselung mit 2-Key-Triple-DES wird dann wie folgt
durchgeführt. Mit dem generierten Nachrichtenschlüssel wird die Nachricht, zu diesem
Zeitpunkt noch im Klartext, mit dem 2-Key-Triple-DES im CBC Modus verschlüsselt.
Der Nachrichtenschlüssel wird mit dem Chiffrierschlüssel der Chipkarte und unter
Verwendung des 2-Key-Triple-DES im ECB Modus chiffriert. Sowohl die chiffrierte
HBCI Nachricht als auch der chiffrierte Nachrichtenschlüssel werden dann verschickt.
36Secure Electronic Transaction-Homebanking Computer Interface
127 0
Zufallszahl HBCI-Nachricht (Klartext)
= Nachrichtenschlüssel
Padding nach ANSI X9.23
Initialisierungsvektor=0
3DES
CBC
Mode
127 0
3DES
ECB
Chiffrierschlüssel
Mode
Kundensystem : Encrypt
Kreditinstitut : Decrypt
127 0
Nachrichtenschlüssel (chiffriert) HBCI-Nachricht (chiffriert)
Abbildung 17: Verschlüsselung bei 2-Key-Triple-DES
Die Entschlüsselung erfolgt in umgekehrter Reihenfolge:
127 0
Nachrichtenschlüssel (chiffriert) HBCI-Nachricht (chiffriert)
Padding nach ANSI X9.23
Initialisierungsvektor=0
127 0
3DES
ECB
Chiffrierschlüssel
Mode
Kundensystem : Encrypt
Kreditinstitut : Decrypt
127 0
Nachrichtenschlüssel
3DES
CBC
Mode
HBCI-Nachricht (Klartext)
Abbildung 18: Entschlüsselung bei 2-Key-Triple-DES
37Secure Electronic Transaction-Homebanking Computer Interface
3. RDH Verfahren
Beim RDH Verfahren wird der Nachrichtenschlüssel mit dem öffentlichen Schlüssel des
Empfängers verschlüsselt. Da die Länge des Nachrichtenschlüssel beim 2-Key-Triple-
DES nur 128 Bit (16 Byte) entspricht, wird sie mit Hilfe des Paddingverfahren auf 768 Bit
ergänzt. Das Paddingverfahren wird notwendig, damit eine Verschlüsselung mit 768 Bit
erfolgt.
127 0
Zufallszahl HBCI-Nachricht (Klartext)
= Nachrichtenschlüssel
Padding nach ANSI X9.23
Initialisierungsvektor=0
767 127 0
00..00 Nachrichtenschlüssel
Padding
3DES
>707 0 CBC
Chiffrierschlüssel* Mode
767 >707 0
RSA
00..00 Chiffrierschlüssel*
Padding * Öffentlicher Chiffrierschlüssel
des Partners
767 0
Nachrichtenschlüssel (chiffriert) HBCI-Nachricht (chiffriert)
Abbildung 19: Verschlüsselung bei RSA (2-Key-Triple-DES)
38Sie können auch lesen
