DE60124893T2

DE60124893T2 - Sicherheitsmodul für ein Kontenverwaltungssystem

Info

Publication number: DE60124893T2
Application number: DE60124893T
Authority: DE
Inventors: Gerrit Bleumer; Clemens Heinrich
Original assignee: Francotyp Postalia GmbH
Current assignee: Francotyp Postalia GmbH
Priority date: 2001-07-16
Filing date: 2001-07-16
Publication date: 2007-06-21
Anticipated expiration: 2021-07-17
Also published as: EP1278168B1; DE60124893D1; US20030028790A1; ATE347154T1; EP1278168A1

Description

Die Erfindung betrifft ein Sicherheitsmodul für ein Hostgerät eines Kontenverwaltungssystems, ein Hostgerät zum Austausch von elektronischen Gütern, Dienstleistungen, Daten und/oder Geldmitteln mit anderen Hostgeräten eines Kontenverwaltungssystems und ein Kontenverwaltungssystem. Ferner betrifft die Erfindung ein Verfahren zum Austausch von elektronischen Gütern, Dienstleistungen, Daten und/oder Geldmitteln zwischen Hostgeräten eines Kontenverwaltungssystems, insbesondere einem Endkundenhostgerät, einem Gatewayhostgerät und einem Bankhostgerät, und ein Computerprogrammprodukt.
Traditionell verwalten Finanzinstitute Kundenkonten innerhalb ihrer eigenen Organisationen. Integrität und Vertraulichkeit der Kundenkonten werden durch eine Bandbreite von organisatorischen, administrativen und elektronischen Maßnahmen ebenso wie durch einen legalen Rahmen von Verpflichtungen und Versicherungen geschützt. Um Finanzdaten zwischen Finanzorganisationen zu bewegen, sind geschlossene Finanznetze in Verwendung, die ausreichend gegen Zugriff aus der Nicht-Finanzwelt geschützt sind.
In einem elektronischen Bezahlsystem werden elektronischen Güter, Dienstleistungen, Daten und/oder Geldmittel zwischen verschiedenen Hostgeräten ausgetauscht. Eine elektronische Zahlung findet statt, wenn ein Zahler Güter oder Dienstleistungen von einem Bezahlten erwirbt und dafür mit Geld in elektronischer Form bezahlt, wobei Zahler und Bezahlter auf verschiedene Weisen miteinander agieren können, um die Zahlung durchzuführen. Elektronische Zahlungen erfordern eine Betreuungskette, die die Bank des Zahlers über den Zahler und den Bezahlten mit der Bank des Bezahlten verbindet. Als ein Ergebnis einer elektronischen Zahlung wird reales Geld von der Bank des Zahlers zur Bank des Bezahlten übertragen. Es gibt verschiedene Geschäftsmodelle, in die die elektronische Zahlung eingebettet ist, wie das Vorauszahl-(pre-paid), das Nachzahl-(pay-later) oder das Sofortzahl-(pay-now) Geschäftsmodell.
Andere Geschäftsmodelle der elektronischen Zahlung schließen die Zahlung per Kreditkarte, per elektronischem Scheck, per elektronischem Bargeld und gestufte elektronische Zahlung ein. Viele Dienste werden nicht zu dem Zeitpunkt bezahlt, an dem die bestellt werden. Gründe dafür, nicht zum Bestellzeitpunkt zu zahlen, sind:

– dass eine Zeitverzögerung zwischen dem Bestellen und dem Erbringen der Dienstleistung besteht. Manchmal ist zum Bestellzeitpunkt nicht einmal bestimmt, wann die Dienstleistung erbracht wird, oder der Zahler möchte flexibel darin bleiben, wann die bestellte Dienstleistung genutzt wird. Wenn solche Dienstleistungen vorausbezahlt werden, erhält der Zahler üblicherweise eine Art von Ticket, Gutschein, Briefmarke, Reisescheck, usw. Wenn solche Dienstleistungen später bezahlt werden, erhält der Zahler üblicherweise eine Rechnung vom Bezahlten.
– dass eine Dienstleistung sehr oft genutzt wird. Üblicherweise ist zum Bestellzeitpunkt nicht klar, wie oft (wie lang, wann, usw.) die Dienstleistung genutzt werden wird. Wenn solche Dienstleistungen vorausbezahlt sind, erhält der Zahler üblicherweise eine Art von Sammelticket, z.B. eine Dauerkarte. Wenn solche Dienstleistungen später bezahlt werden, z.B. Telefon- oder Versorgungsnutzung, erhält der Zahler üblicherweise eine Rechnung vom Bezahlten.
– das Modell des späteren Zahlens kann mit traditionellen Mitteln der Zahlung umgesetzt werden, wie dem Inrechnungstellen an den Kunden. Die vorliegende Erfindung bezieht sich insbesondere auf gestufte elektronische Vorauszahlungen, i.e. in mehreren Stufen ausgeführte Vorauszahlungen. Wenn der Zahler eine Dienstleistung bestellt, zahlt er für sie und erhält ein Ticket, einen Gutschein, eine Briefmarke, einen Reisescheck, usw. (Stufe eins). Wenn er tatsächlich die Erbringung der Dienstleistung einfordert, gibt er das jeweilige Ticket, den Gutschein, usw. aus (Stufe zwei). Es können mehr Stufen bestehen, wenn zusätzliche Überantwortungspunkte vor Erbringung der Dienstleistungen existieren.

Die Verbindung zwischen dem Zahler und seiner Bank wird üblicherweise durch ein Zahlergateway errichtet, das elektronisches Geld speichert und es von einem Bankkonto des Zahlers zu dem Hostgerät des Zahlers (Endkundenhostgerät) weiterleitet. Auf ähnliche Weise wird die Verbindung zwischen dem Bezahlten und seiner Bank durch ein Bezahltengateway errichtet, das elektronisches Geld oder ein Äquivalent wie eine Zahlungsermächtigung für Kreditkartenzahlungen speichert und es von Hostgerät des Bezahlten zurück zu seinem Bankkonto weiterleitet. Nahezu alle heutigen Zahler- und Bezahltengateways werden von einer Bank oder einem Kreditkartenunternehmen betrieben. Als solche sind die Zahler- und Bezahltengateways mit einem sicheren Finanznetz verbunden und sie werden in einer „freundlichen Umgebung" betrieben – zumindest aus Sicht der Finanzindustrie. Um neue elektronische Dienstleistungen schnell einzuführen, sollten dritte Unternehmer in die Lage versetzt werden, ihre eigenen Zahler- und Bezahltengateways zu entwickeln und einzusetzen, die auf ihre besondere Art der elektronischen Dienstleistung und ihr Geschäftsmodell angepasst werden. In den meisten Fällen müssen von Dritten betriebene Zahler- und Bezahltengateways durch irgend eine Finanzinstitution, mögliche Regulierer der besonderen erbrachten Dienstleistung und/oder durch Steuerbehörden zertifiziert oder bestätigt werden.
Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Sicherheitsmodul für ein Hostgerät eines Kontenverwaltungssystems bereitzustellen, das dritten Unternehmern erlaubt, elektronische Dienstleistungen und Zahler- und Bezahltengateways einzuführen, um ihren Kunden Gebühren für diese Dienstleistungen zu berechnen und das ein hohes Maß an Manipulationssicherheit und Vertraulichkeit aller Kundenkontos garantiert. Eine andere Aufgabe der Erfindung ist es, ein Gatewayhostgerät und ein Kontenverwaltungssystem mit solchen Merkmalen bereitzustellen.
Diese Aufgaben werden durch ein Sicherheitsmodul wie in Anspruch 1 beansprucht gelöst.
Diese Aufgabe werden weiterhin durch ein Hostgerät wie in Anspruch 12 beansprucht gelöst mit:
Schnittstellen zum Verbinden an andere Hostgeräte eines Kontenverwaltungssystems, insbesondere an Endkundenhostgeräte und Bankhostgeräte,
einer Datenbankeinheit zum Speichern von Kontendaten eines Kundenkontos, und
einem Sicherheitsgerät wie oben definiert.
Dieses Hostgerät ist vorzugsweise als Gatewayhostgerät realisiert und kann ebenso eine Einrichtung, bevorzugt eine Softwarekomponente, aufweisen, die die Integrität und Vollständigkeit aller Rechungsprüfungs- und Transaktionsdaten sicherstellt.
Zudem werden diese Aufgaben durch ein Kontenverwaltungssystem wie in Anspruch 14 beansprucht gelöst, mit:
einem Endkundenhostgerät,
einen Bankhostgerät, und
einem Hostgerät gemäß Anspruch 12, das an das Endkundenhostgerät und das Bankhostgerät zum Austausch von elektronischen Gütern, Dienstleistungen, Daten und/oder Geldmitteln zwischen den Hostgeräten verbunden ist.
Das Kontenverwaltungssystem entsprechend der Erfindung, das im Folgenden als „ultrasicheres Kontenverwaltungssystem" bezeichnet wird, wird von Gatewayhosts, die in einer „feindlichen Umgebung" betrieben werden und an sichere Endpunkte über ungesicherte Netze verbunden ist, einem Bankhost und einem sicheren Endkundenhost wie einer elektronischen Brieftasche angewendet. Die Kernkomponente des ultrasicheren Kontenverwaltungssystems ist das Hardwaresicherheitsmodul, das

– die Zahlungsprotokollspeicher beherbergt, die zur Bedienung beider Endpunkte verwendet werden,
– eine starke Integrität aller Kundenkonten garantiert,
– optional die Integrität und Vollständigkeit aller Rechnungsprüfungs- und/oder Transaktionsdaten und eine starke Vertraulichkeit aller Kundenkonten garantiert, und
– sichere Rückabwicklungsmechanismen für den Fall eines abgebrochenen Geldmitteltransfers sichert.

Diese Integritäts-, Authentisierungs- und Vertraulichkeitsmerkmale sind auch dann garantiert, wenn der Gatewayhost in einer äußerst feindlichen Umgebung betrieben wird, in der der Superuser des Betriebssystems und der Administrator des Datenbankverwaltungssystems miteinander zusammenarbeiten und eine fortgeschrittene Attacke auf die Kundenkontendatenbank des Gatewayhosts ausführen. In des Begriffen des ISO-OSI-Modells bedeutet eine ultrasichere Kontenverwaltung Kontenintegrität und optionale Kontenvertraulichkeit ebenso wie Mitteilungsauthentisierung und optionale Mitteilungsvertraulichkeit auf der Anwendungsebene (End-to-End-Sicherheit).
Das ultrasichere Kontenverwaltungssystem entsprechend der Erfindung basiert auf der Manipulationssicherheit des von dem Gatewayhostgerät verwendeten Hardwaresicherheitsmoduls. Daher ist der Großteil der in einem herkömmlichen Kontenverwaltungssystems nötigen Risikoanalyse auf eine geeignete Einschätzung des Hardwaresicherheitsmoduls reduziert. Da Hartwaresicherheitsmodule wahrscheinlich um Größenordnungen weniger komplex sind als der komplette Gatewayhost einschließlich Hardware, Software, Verfahren, Standortsicherheit, Personalsicherheit, usw., kann es wahrscheinlich deutlich günstiger und schneller als bei einem traditionellen Kontenverwaltungssystem erreicht werden, ein ultrasicheres Kontenverwaltungssystem durch Bankinstitutionen, Regulierungsbehörden und/oder Steuerbehörden bestätigt zu bekommen.
Entsprechend der Erfindung werden Prüfkodes für Kundenkonten des Hostgerätes in einem Verzeichnismodul des Sicherheitsmoduls gespeichert. Derartige Prüfkodes werden unter Verwendung von Kontendaten des entsprechenden Kundenkontos erzeugt. Wenn das Sicherheitsmodul und/oder das Hostgerät einschließlich des Sicherheitsmoduls aufgefordert werden, Kontendaten eines Kundenkontos zu bearbeiten, beispielsweise Kundenkontendaten zu lesen oder zu aktualisieren oder den Kontowert zu ändern, werden solche Prüfkodes zur Verifizierung des Kundenkontos verwendet, d.h. zum Prüfen, ob die in dem Hostgerät gespeicherten Kontendaten verändert wurden, nachdem sie das letzte Mal von dem Kontenverwaltungssystem gelesen oder aktualisiert wurden. Nur wenn diese Verifikation erfolgreich ist, wird das ultrasichere Kontenverwaltungssystem eine Anfrage zu den Kundenkontodaten verarbeiten. Andernfalls wird eine Rückgewinnungsphase eingeleitet, die den derzeitigen Zustand der Kundenkontendaten unter Berücksichtigung einer Anzahl von Belegen wie Backup-Bändern analysiert. Es ist daher möglich, im Fall von Datenbankverfälschungen oder Systemausfällen während Transaktionen derartige Probleme zu identifizieren und den vorherigen Stand der Kundenkontendaten wiederherzustellen.
Das von der vorliegenden Erfindung vorgeschlagene ultrasichere Kontenverwaltungssystem erlaubt es daher, Finanzdaten und Kundenkonten im Höchstmaß auf Anwendungsebene zu schützen. Als solches nimmt das ultrasichere Kontenverwaltungssystem deutlich weniger Gebrauch von organisatorischen und administrativen Sicherheitsmaßnahmen vor, stattdessen baut es technische und kryptographische Sicherheitsmaßnahmen direkt in die Datenbank und die Netzsysteme ein, die die Kontendaten handhaben. Die Vorteile des ultrasicheren Kontenverwaltungssystems sind zweifältig: nicht dagewesene Ausmaße an Robustheit gegen Insider-Betrug innerhalb der Bankindustrie und der Finanzinstitute und ein sicherer Weg, die Kundenkontenverwaltung an Unternehmen auszugliedern, die einen zusätzlichen Wert für den Endkunden beisteuern können, allerdings nicht mit den dedizierten Finanznetzen verbunden sind.
Bevorzugte Ausführungsformen der Erfindung sind in den abhängigen Ansprüche enthalten. Vorzugsweise wird der Prüfkode für ein Kundenkonto durch das Verwaltungsmodul des Sicherheitsmoduls unter Verwendung der Kontonummer, des Kundennamens und des Kontowerts des Kundenkontos erzeugt. Solche Kundenkontendaten sind in einer entsprechenden Datenbank in dem Hostgerät gespeichert, in dem das Sicherheitsmodul enthalten ist. Während solche Kundenkontendaten manipuliert werden können, ist theoretisch der Prüfkode nur in dem Sicherheitsmodul gespeichert und nicht von außerhalb zugänglich, d.h. der Prüfkode kann nicht manipuliert werden, beispielsweise für geänderte Daten neu berechnet werden. Das vorgeschlagene Verfahren zum Erzeugen der Prüfkodes ist ein einfaches und schnelles Verfahren. Im Allgemeinen können die Prüfkodes auch unter Verwendung anderer oder weiteren Daten des Kundenkontos erzeugt werden.
In Abhängigkeit von der Anwendung kann es ausreichend sein, einen einfachen Hash-Kode als Prüfkode zu verwenden. Es ist jedoch beinahe ebenso effizient, einen Message-Authentication-Kode zu erzeugen, der sicherer sein wird. Zusätzlich vermeidet das Verwenden eines Message-Authentication-Kodes das zusätzliche Risiko böswilliger Individualsoftware innerhalb des Sicherheitsmoduls, die das Verzeichnismodul manipulieren und korrekte Hash-Kodes für die manipulierten Daten erzeugen könnte, um die Manipulation zu verdecken.
Falls das Verzeichnismodul von anderen Funktionseinheiten außer dem Sicherheitsmodul inspiziert und verifiziert werden sollte, ist alternativ der Mechanismus der digitalen Signatur der am meisten geeignete. In diesem Fall können alle potentiell verifizierenden Funktionseinheiten den Verifizierungsschlüssel teilen, ohne den Unterzeichnungsschlüssel des Kontenverwaltungssystem einem Risiko auszusetzen.
Entsprechend einer anderen bevorzugten Ausführungsform weist das Sicherheitsmodul Verschlüsselungs- und Entschlüsselungsmittel auf. Alle zwischen dem Sicherheitsmodul und einem Hostgerät ausgetauschten Daten sind daher verschlüsselt, um den Schutzgrad gegen jedwede Manipulation weiter zu erhöhen. Der interne Verschlüsselungsschlüssel kann in einem flüchtigen Speicher wie einem RAM-Gerät gespeichert werden, das auf Null gesetzt werden kann, falls jemand eine Manipulation an den Verschlüsselungs- und Entschlüsselungsmitteln des Sicherheitsmoduls versuchen sollte.
Um ein mechanisches Mittel zum Schutz vorzusehen, ist das Sicherheitsmodul bevorzugt in einer manipulationssicheren oder auf Manipulationen reagierenden Hardware innerhalb des Hostgerätes eingekapselt.
Da die Anzahl an von einem Hostgerät gehandhabten Kundenkonten sehr groß sein kann, kann das Sicherheitsmodul auch in eine Anzahl von Sicherheitsuntermodulen aufgeteilt sein, die jedes eine Untergruppe der Prüfkodes für eine Untergruppe der Kundenkonten speichern, wie dies entsprechend einer anderen bevorzugten Ausführungsform vorgeschlagen ist.
Eine bevorzugte Anwendung des entsprechend der Erfindung vorgeschlagenen Sicherheitsmoduls ist die Implementierung in einem Gatewayhostgerät, das an andere Hostgeräte eines Kontenverwaltungssystems zum Austauschen von elektronischen Gütern, Dienstleitungen, Daten und/oder Geldmitteln angeschlossen ist, insbesondere an Endkundenhostgeräte und Bankhostgeräte. Das in das Gatewayhostgerät eingebettete oder daran angebrachte Hardwaresicherheitsmodul ist sicher, da es als einem Standard entsprechend von einer unabhängigen Organisation zertifiziert angenommen wird. Im Gegensatz dazu wird die Netzverbindung zwischen dem Gatewayhostgerät und dem Bankhostgerät ebenso wie die zwischen dem Gatewayhostgerät und dem Endkundenhostgerät als unsicher und unzuverlässig angenommen, da angenommen wird, das Gatewayhostgerät wird von einem Dritten betrieben, der keinen Zugang zu einem Finanznetz hat.
In einer bestimmten Anwendung sind die Endkundenhostgeräte Frankiermaschinen und das Gatewayhostgerät wird von einem Porto-Provider bereitgestellt. In einer anderen Ausfüh rungsform ist das Gatewayhostgerät derart eingerichtet, dass es auf sichere Weise eine oder mehrer Steuer- oder Zollbehörden über die durchgeführten Transfers an Geldmitteln oder Gütern benachrichtigt. Die Benachrichtigungsstrategie folgt den einschlägigen Gesetzen und gesetzlichen Bestimmungen. Die Benachrichtigungsmitteilungen sind auf dieselbe Weise wie die Kommunikation zwischen dem Gatewayhostgerät und dem Bankhostgerät end-to-end gesichert.
Das Sicherheitsmodul kann zudem Geldmitteltransfermodule zum Austausch von Geldmitteln zwischen einem Konto eines Endkunden bei dem Gatewayhostgerät und seinem Konto bei einem Bankhostgerät und/oder Endkundenhostgerät aufweisen. Auf diese Weise werden alle zum Austauschen von Geldmitteln nötigen Dienste von dem Sicherheitsmodul geleistet. Vorzugsweise werden solche Module als Softwarekomponenten der Softwarearchitektur des Sicherheitsmoduls implementiert.
Um einen hohen Grad an Sicherheit gegen Manipulation sicherzustellen, sind interagierende Protokollspeicher und sicherheitskritische Anwendungssteuerung innerhalb des Sicherheitsmoduls entsprechend einer weiteren bevorzugten Ausführungsform eingekapselt.
Die Erfindung bezieht sich ferner auf ein Verfahren zum Austausch von elektronischen Gütern, Dienstleistungen, Daten und/oder Geldmitteln zwischen Hostgeräten eines Kontenverwaltungssystems, mit den Schritten:
Anfrage bei einem Hostgerät, Kontendaten eines in dem Hostgerät gespeicherten Kundenkontos zu verarbeiten,
Erzeugen eines Prüfkodes durch ein Verwaltungsmodul eines Sicherheitsgeräts des Hostgeräts unter Benutzung von Kontodaten des Kundenkontos, und
Verifizieren des Kundenkontos unter Verwendung des Prüfkodes, bevor die Kontodaten des Kundenkontos verarbeitet werden.
Im Falle eines angefragten Geldmitteltransfers von einem Endkundenhostgerät an ein Gatewayhostgerät wird das Guthaben des Endkunden bei dem Endkundenhostgerät verringert, bevor das Guthaben des Endkunden bei dem Gatewayhostgerät erhöht wird. In ähnlicher Weise wird im Falle eines angefragten Geldmitteltransfers von einem Gatewayhostgerät an ein Endkundenhostgerät das Guthaben des Endkunden bei dem Gatewayhostgerät verringert, bevor das Guthaben des Endkunden bei dem Endkundenhostgerät erhöht wird. Ferner sind die Schritte des Protokolls zum Geldmitteltransfer derart vorgesehen, dass die Summe der Guthaben in dem Endkundenhostgerät und dem Gatewayhostgerät vor dem Beginn und nach der Beendigung der Protokollausführung gleich sind. Vorzugsweise stimmt zu jedem Zwischenzustand des Protokolls die Summe der Guthaben in dem Endkundenhostgerät und dem Gatewayhostgerät mit der Summe der Guthaben in dem Endkundenhostgerät und dem Gatewayhostgerät zu dem Beginn des Protokolls überein. Ein solcher Zwischenzustand könnte vom Endkunden dazu missbraucht werden, die Transaktion gezielt zu unterbrechen, um sein oder ihr Gesamtguthaben zu erhöhen.
Die Erfindung bezieht sich ferner auf ein Computerprogrammprodukt wie in Anspruch 19 beansprucht mit Programmkodemitteln zum Veranlassen eines Computers, das oben beschriebene Verfahren durchzuführen.
Es ist zu bemerken, dass das Hostgerät wie in Anspruch 12 beansprucht, das Kontenverwaltungssystem wie in Anspruch 14 beansprucht, das Verfahren wie in Anspruch 15 beansprucht und das Computerprogrammprodukt wie in Anspruch 19 beansprucht weiter entwickelt werden und weitere Ausführungsformen haben können, die identisch oder ähnlichen zu den Ausführungsformen des Sicherheitsmoduls sind, wie sie oben beschrieben und in den von Anspruch 1 abhängigen Ansprüchen beansprucht sind.
Die Erfindung wird nun detaillierter mit Bezug auf die Zeichnungen erläutert, bei denen
1 die Betreuungskette für ein bekanntes elektronisches Bezahlsystem zeigt,
2A–2C unterschiedliche Anwendungen eines Kontenverwaltungssystems entsprechend der Erfindung zeigen,
3 ein Blockdiagramm eines Kontenverwaltungssystem entsprechend der Erfindung zeigt,
4 ein Blockdiagramm eines Endkundenhostgerätes zeigt,
5 ein Blockdiagramm eines Gatewayhostgerätes zeigt,
6 ein Blockdiagramm eines Bankhostgerätes zeigt,
7 einen Überblick über ein Geldmitteltransferprotokoll zeigt,
8A–8C ein detailliertes Geldmitteltransferprotokoll zeigen,
9 eine drahtlose Zahlung mittels eines WAP-Mobiltelefons zeigt,
10 eine Erweiterung zu einer gestuften elektronischen Zahlung illustriert,
11 eine Anwendung eines Kundenbindungssystems zeigt, und
12 den Verkauf von elektronischen Tickets für öffentlichen Verkehr und Individualverkehr zeigt.
In 1 ist ein elektronisches Zahlungssystem in einer breiten Perspektive gezeigt. Eine elektronische Zahlung liegt vor, wenn einer Zahler 3 Güter oder Dienstleistungen von einem Bezahlten 4 (oder Händler) erwirbt und für diese mit Geld in elektronischer Form zahlt, d.h. mit elektronischem Geld. Zahler 3 und Bezahlter 4 können in vielfältiger Weise zum Ausführen der Zahlung interagieren. Der Bezahlte 4 kann ein Verkaufsort-Terminal (POS), ein zentrale WWW-Storefront oder eine verteilte Storefront vorsehen, wobei bei Zahlung die Ausrüstung des Zahlers die gewünschten Güter oder Dienstleistungen direkt beim Zahler ausgibt, beispielsweise Pay-TV-Dekoder.
Elektronische Zahlungen erfordern eine Betreuungskette, die die Bank 1 des Zahlers (Ausgeber) über den Zahler 3 und den Bezahlten 4 mit der Bank 6 des Bezahlten (Erwerber) verbindet. Insgesamt sind sechs logische Verbindungen in dieser Betreuungskette der elektronischen Zahlungen (siehe untenstehende Liste) und ein bereitstehender Schlichter vorhanden, der dazu autorisiert und fähig ist, Streitigkeiten bezüglich elektronischer Zahlungen zu lösen.
Das in 1 gezeigte elektronische Zahlungssystem umfasst die folgenden Elemente:

– Ausgeber 1: typischerweise eine Bank, die elektronisches Geld bereitstellt, das für Zahlungen verwendet werden kann. Der Ausgeber 1 stellt elektronisches Geld im Austausch gegen reales Geld bereit.
– Zahlergateway 2: entweder eine Bank oder ein Dritter mit der technischen Infrastruktur, elektronisches Geld beispielsweise über das Internet bereitzustellen.
– Zahler 3: jedwedes Individuum oder Unternehmen, das Güter oder Dienstleistungen gegen elektronisches Geld erwerben möchte.
– Bezahlter 4 (Händler): jedwedes Individuum oder Unternehmen, das Güter oder Dienstleistungen für elektronisches Geld verkauft.
– Bezahltengateway 5: entweder eine Bank oder ein Dritter mit der technischen Infrastruktur, Beträge an elektronischen Zahlungen von Bezahlten 4 entgegenzunehmen und zu bestätigen, die diese Beträge auf ihre Bankkonten einzahlen möchten.
– Erwerber 6: typischerweise eine Bank, die elektronisches Geld oder Äquivalente zur Einzahlung auf Bankkonten der Kunden akzeptiert.
– Schlichter: eine Bank oder ein Dritter, die dazu autorisiert und fähig ist, Streitigkeiten bezüglich elektronischer Zahlungen zu schlichten.

Als ein Ergebnis der elektronischen Zahlung wird reales Geld von Ausgeber 1 zum Erweber 6 bewegt. Eine Interaktion zwischen Mitgliedern der Betreuungskette ist die elektronische Zahlung selbst. Die letzte Interaktion ist eine Abwicklung zwischen dem Ausgeber 1 und dem Erwerber 6 über ein Finanznetz. Welche weiteren Schritte nötig sind und was während der abschließenden Abwicklung vorgeht, hängt sehr vom jeweiligen Geschäftsmodell ab, in das die elektronische Zahlung eingebettet ist.

Eine wichtige Einordnung für Geschäftsmodelle für elektronische Zahlung ergibt sich daraus, wann im Bezug auf das Abschließen der elektronischen Zahlung durch den Zahler der Ausgeber 1 den Zahler 3 belastet:

– Vorausbezahlt (pre-paid):	Der Ausgeber 1 belastet den Zahler 3 vor dem Bereitstellen von elektronischem Geld im Gegenzug und daher bevor die elektronische Zahlungen beginnen kann, geschweige denn beendet wird. Dies ist ein bargeldähnliches Geschäftsmodell. Ein typisches Beispiel ist electronic cash.
– Nachzahlen (pay-later):	Der Zahler 3 kann eine elektronische Zahlung ausführen und lediglich danach belastet der Ausgeber 1 den Zahler 3 mit dem entsprechenden Betrag, beispielsweise wenn die Zahlung zwischen dem Ausgeber 1 und dem Erwerber 6 abgewickelt ist. Dies ist ein kontenbasiertes Geschäftsmodell. Typische Beispiele sind Zahlungen per Kreditkarte, Debitkarte oder electronic check.
– Sofortzahlen (pay-now):	Ein Spezialfall des Nachzahl-Modells liegt vor, wenn der Ausgeber 1 den Zahler 3 schon kurz nach Beendigen der elektronischen Zahlung belastet. Ein typisches Beispiel sind Zahlungen per Debitkarte.

Die primäre Aufgabe des Zahlergateways 2 besteht darin, elektronisches Geld zu speichern und von einem Bankkonto eines Zahlers bei dem Ausgeber 1 zum Gerät des Zahlers 3 (Endkundengerät) weiterzuleiten. Entsprechend ist die primäre Aufgabe des Bezahltengateways 5, elektronisches Geld oder ein Äquivalent (wie Zahlungsermächtigungen für Kreditkartenzahlungen) zu speichern und von der Infrastruktur des Bezahlten zurück zum Erwerber 6 zu übermitteln.
Ein Zahlergateway 2 verbindet drahtgebunden oder drahtlos Zahlergeräte 3 mit dem geschäftlichen Bankkontensystem beim Ausgeber 1. Dabei kann das Zahlergateway 2 in verschiedener Weise einen Wert zu den Bankkonten des Kunden bei dem Ausgeber 1 hinzufügen, indem:

(1) eine flexiblere Kontenverwaltung und ein breiterer Kontenzugang ermöglicht wird, als dies der Ausgeber 1 tut.
(2) geringere Transaktionsgebühren angeboten werden, als dies der Ausgeber 1 tut.
(3) ein Einbinden mit innovativen Diensten stattfindet, die von Endkundengeräten 3 wie elektronischen Vielzweck-Brieftaschen, Mobiltelefonen, Organizer usw. unterstützt werden. Die Endkundengeräte 3 können über den Provider des Zahlergateways 2 oder ein Dritter verfügbar sein.
(4) die Sicherheit der innovativen Dienste und damit deren Akzeptanz durch Finanzinstitute, Händler und potentielle Regler solcher Dienstleistungen erhöht wird.

Diese Merkmale sind von besonderem Interesse, wenn Zahlergateways 2 von Unternehmern betrieben werden sollen, insbesondere nicht von Banken oder anderen Institutionen, die mit den Finanznetzen verbunden sind. Solche Unternehmer können Internetdienstprovider (ISPs) sein, die Inhalte-Anbieter oder Drahtlos-Anwendungsdienstanbieter (ASPs) werden wollen. Solche Unternehmer stehen vor einer wichtigen Sicherheitsfrage, da weder das Zahlergateway 2 noch seine Verbindung zum Bankhost sicher ist.
Ein Bezahltengateway 5 verbindet die Bezahlteninfrastruktur mit dem geschäftlichen Bankkontensystem bei dem Erwerber 6. Dabei kann das Bezahltengateway 5 in verschiedener Weise einen Wert zu den Bankkonten des Bezahlten bei dem Erwerber 6 hinzufügen, beispielsweise indem:

(1) eine flexiblere Kontenverwaltung und ein flexiblerer Kontenzugang ermöglicht wird, als dies der Erwerber 6 kann.
(2) geringere Transaktionsgebühren angeboten werden, als dies der Erwerber 6 tut.
(3) ein Einbinden mit innovativen Diensten stattfindet, die von Händlergeräten 4 und Infrastrukturen wie Verkaufsautomaten oder Geldautomaten usw. unterstützt werden, die auf Mobiltelefone reagieren. Die Händlergeräte 4 können über den Provider des Bezahltengateways 5 oder ein Dritter verfügbar sein.
(4) die Sicherheit der innovativen Dienste und damit deren Akzeptanz durch Finanzinstitute, Zahler, potentielle Regler solcher Dienstleistungen oder Steuerbehörden erhöht wird.

Diese Merkmale sind von besonderem Interesse, wenn Bezahltengateways 5 von Unternehmern betrieben werden sollen, insbesondere nicht von Banken oder anderen Institutionen, die mit den Finanznetzen verbunden sind. Solcher Unternehmer können Internetdienstprovider (ISPs) sein, die Inhalte-Anbieter mit einer Option zur elektronischen Rechnungszah lung oder Drahtlos-Anwendungsdienstanbieter (ASPs) werden wollen. Solche Unternehmer stehen vor einer wichtigen Sicherheitsfrage, da weder das Bezahltengateway 5 noch seine Verbindung zum Bankhost sicher ist.
Es gibt eine Anzahl von Anwendungen, für die Konsumenten unter Verwendung von Endkundenhost verschiedener Formfaktoren vorauszahlen können:

– Elektronische Brieftasche: Der Endkundenhost ist dazu in der Lage, online an eine Händlereinrichtung zu verbinden, um in ein Zahlungsprotokoll einzutreten.
– Aufladeeinrichtung: Der Endkundenhost kann dazu verwendet werden, die Telefonkarten des Endkunden oder andere Cash-Cards mittels spezieller Aufladeausrüstung wieder aufzuladen.
– Drucker für sichere Dokumente: Der Endkundenhost verbindet an oder ist ein normaler PC mit einem Desktopdrucker. Der Endkundenhost kann verschiedene Arten sicherer Dokumente ausdrucken, wie Geldanweisungen, Barschecks, Reiseschecks, Rabattschecks, Darlehensschecks, Tickets für Fluglinien, Züge, Schiffsreisen oder andere Beförderungsmittel, Gebühren-Pässe, Tickets für Veranstaltungen wie Konzerte, Theater, Oper, Football, Baseball, usw., Einzelhandelsmarken, Jagdscheine, Angelscheine, Führerscheine, Mietwagengutscheine, Lebensmittelgutscheine, Geschenkgutscheine, usw.
– Pay-TV-Dekoder: Der Endkundenhost verbindet an einen TV-Empfänger oder einen Satellitenempfänger oder wird in diesen eingesteckt. Für jeden Teil dekodierter Daten wird ein kleiner Betrag vom Guthaben des Endkunden abgezogen.

Jedes Vorauszahl-Geschäftsmodell (einschließlich des gestuften Zahlungsmodells) sollte die folgenden Sicherheitsanforderungen erfüllen:

– Verfügbarkeit: der Zahler 3 sollte alle Dienstleistungen in der ausgehandelten Qualität erhalten, wenn er zuvor dafür bezahlt hat.
– Integrität (Zahler 3): der Zahler 3 sollte keine Dienstleistungen erhalten, für die er nicht zuvor bezahlt hat. Dies wird von dem Bezahlten 4, dem Ausgeber 1, dem Erwerber 6 und im Fall regulierter Dienstleistungen wie der Postauslieferung ebenso von den Regulierungsbehörden gefordert. Im Fall einer gestuften Zahlung schließt diese Anforderung ein, dass der Zahler 3 keine Tickets für Dienstleistungen erhalten kann, für die er nicht im Voraus bezahlt hat.
– Integrität (Bezahlter 4): der Bezahlte 4 sollte keine Einzahlungen auf sein Konto bei dem Bezahltengateway 5 oder bei dem Erwerber 6 für Güter oder Dienstleistungen ausführen können, die er nicht bereitgestellt hat. Insbesondere sollte es für den Be zahlten 6 nicht möglich sein, dieselbe Zahlung zweimal auf sein Bankkonto einzuzahlen.

Es gibt weitere Anforderungen, insbesondere zur Vertraulichkeit und zum Datenschutz, die eingefordert werden können oder auch nicht.
Nahezu alle heutigen Zahler- und Bezahltengateways 2, 5 werden durch eine Bank oder ein Kreditkartenunternehmen betrieben. Als solche sind die Zahler- und Bezahltengateways 2, 5 mit einem sicheren Finanznetz verbunden und sie werden in einer freundlichen Umgebung betrieben – zumindest aus Sicht der Finanzindustrie. Um neue elektronische Dienstleistungen schnell einzuführen, sollten dritte Unternehmer in die Lage versetzt werden, ihre eigenen Zahler- und Bezahltengateways 2, 5 zu entwickeln und einzusetzen, die auf ihre besondere Art der elektronischen Dienstleistung und ihr Geschäftsmodell angepasst werden. In den meisten Fällen müssen von Dritten betriebene Zahler- und Bezahltengateways 2, 5 durch irgendeine Finanzinstitution, mögliche Regulierer der besonderen erbrachten Dienstleistung und/oder durch Steuerbehörden zertifiziert oder bestätigt werden. Ultrasichere Kontenverwaltung ist eine technologische Vorraussetzung für Unternehmer, die elektronische Dienstleistungen und Zahler- oder Bezahltengateways 2, 5 einführen, um ihren Kunden für diese Dienstleistungen Gebühren zu berechnen.
Die ultrasichere Kontenverwaltung sollte von Gatewayhosts angewandt werden, die in feindlichen Umgebungen betrieben werden und zwei sichere Endpunkte über unsichere Netze verbinden; die Bank des Ausgebers und einen sicheren Endkundenhost wie eine elektronische Brieftasche. Die Kernkomponente der ultrasicheren Kontenverwaltung ist ein Hardwaresicherheitsmodul, das die Zahlungsprotokollspeicher beherbergt, die zur Bedienung beider Endpunkte verwendet werden, das eine starke Integrität aller Kundenkonten garantiert, das optional eine starke Vertraulichkeit aller Kundenkonten garantiert, und das sichere Rückabwicklungsmechanismen für den Fall eines abgebrochenen Geldmitteltransfers sichert. Diese Integritäts-, Authentisierungs- und Vertraulichkeitsmerkmale sind auch dann garantiert, wenn der Gatewayhost in einer äußerst feindlichen Umgebung betrieben wird, in der der Superuser des Betriebssystems und der Administrator des Datenbankverwaltungssystems miteinander zusammenarbeiten und eine fortgeschrittene Attacke auf die Kundenkontendatenbank des Gatewayhosts ausführen.
In den Begriffen des ISO-OSI-Modells bedeutet eine ultrasichere Kontenverwaltung Kontenintegrität und optionale Kontenvertraulichkeit ebenso wie Mitteilungsauthentisierung und optionale Mitteilungsvertraulichkeit in der Anwendungsebene. Das ultrasichere Kontenverwaltungssystem basiert auf der Manipulationssicherheit des von dem Gatewayhostgerät verwendeten Hardwaresicherheitsmoduls. Auf diese Weise ist der Großteil der in einem herkömmlichen Kontenverwaltungssystems nötigen Risikoanalyse auf eine geeignete Einschätzung des Hardwaresicherheitsmoduls reduziert. Da Hartwaresicherheitsmodule wahrscheinlich um Größenordnungen weniger komplex sind als der komplette Gatewayhost (Hardware, Software, Verfahren, Standortsicherheit, Personalsicherheit, usw.), kann es wahrscheinlich deutlich günstiger und schneller als bei einem traditionellen Kontenverwaltungssystem erreicht werden, ein ultrasicheres Kontenverwaltungssystem durch Bankinstitutionen, Regulierungsbehörden und/oder Steuerbehörden bestätigt zu bekommen.
Die 2A–2C zeigen verschiedene Anwendungen eines elektronischen Zahlungssystems in einem Offline-Vorauszahl-Geschäftsmodell. In 2A ist ein ultrasicheres Kontenverwaltungssystem am Zahlergateway 2 realisiert, das es mit dem Bankhostgerät 1 des Ausgebers einerseits und andererseits mit dem Endkundengerät 3 des Zahlers verbindet. In einem Online-Vorauszahl-Geschäftsmodell kann derselbe Vorschlag verwendet werden, um Online-Zahlungstransaktionen zu sichern, wobei das Zahlergateway 2 einerseits mit dem Bankhostgerät 1 des Ausgebers und andererseits mit dem Bezahlten 4 verbunden ist, wie in 2B gezeigt. Vieles vom gesagten in diesem Abschnitt gilt analog für das in 2C gezeigte Bezahltengateway 5 und seine Verbindungen mit dem Bankhostgerät 6 des Erwerbers einerseits und dem Bezahlten 4 andererseits.
Der Aufbau eines ultrasicheren Kontenverwaltungssystems wird in 3 dargestellt. Der Bankhost 50 stellt jedwedes Bankkontendatenzentrum dar, typischerweise ein Mainframe-basiertes System. Der Gatewayhost 30 ist ein Datenzentrum bei einem Drittanbieter, der elektronische Güter oder Dienstleistungen seinen Kunden anbietet. Der Gatewayhost 30 verbindet mittels beliebiger Kommunikationsmittel 8, die der Bankhost 50 unterstützt, an dem Bankhost 50, typischerweise mittels einer Frame-relay-Verbindung oder einer Telefonstandleitung. Der Endkundenhost 10 ist ein Computer oder EDV-Gerät des Endkunden. Es verbindet an den Gatewayhost 30 über ein Kommunikationsmittel 7, dessen Verwendung für den Endkunden bequem ist, typischerweise über eine Telefonleitung oder eine drahtlose Internet-Verbindung.
Der Bankhost 50 stellt alle Standardfunktionalitäten des Bankwesens zur Verfügung, insbesondere die Funktionalität des Geldmitteltransfers mit anderen Bankhosts. Der Gatewayhost 30 weist zwei Zahlungsschnittstellen auf: eine Vorderschnittstelle zum Verbinden mit dem Endkundenhost 10 und einer Hinterschnittstelle zum Verbindung mit dem Bankhost 50. Die Vorderschnittstelle erlaubt, elektronisches Geld zum Endkundenhost 10 zu transferieren, und nimmt Rücküberweisungen von ihm an. Ein oder mehrere Online- oder Offline-Protokolle zur elektronischen Zahlung können unterstützt werden. Die Hinterschnittstelle erlaubt, elektronisches Geld von dem Bankhost 50 zu erhalten und Rücküberweisungen zurück zum Bankhost 50 durchzuführen. Der Gatewayhost 30 unterstützt alle existierenden – üblicherweise Mainframe-basierten – zwischenbanklichen (B2B) Zahlungsprotokolle wie den elektronischen Zahlungsverkehr. Andere Beispiele schließen den Banking Internet Payment Standard (BIPS) des Financial Services Technology Consortium (FSTC) und Open Financial Exchange (OFX) von CheckFree, Intuit und Mircosoft ein.
Der Gatewayhost 30 weist ein Datenbanksystem auf, das dazu in der Lage ist, alle Konten aller Endkunden zu verwalten, die an den Gatewayhost 30 mittels ihrer Endkundengeräte verbinden.
Im Prinzip hat jeder Provider in eine elektronischen Zahlungsinfrastruktur eine andere Ansicht darüber, welche Systemkomponenten, Verfahren und Mitarbeiter sicher sein sollten oder nicht. Der folgende Vorschlag übernimmt den Standpunkt der Bankindustrie und in einem gewissen Ausmaß den von Regierungsbehörden wie den Steuer- oder Regulierungsbehörden. Dieses Bankwesensicherheitsmodell wird im folgenden skizziert. Ultrasichere Kontenverwaltung ist eine Ausgangstechnologie, die das Bankwesensicherheitsmodell übernimmt und die dabei hilft, Infrastrukturen zur elektronischen Zahlung schneller durch die Bankindustrie bestätigt zu bekommen.
Bankhosts 50 sind komplett sicher und dies gilt auch für die sie verbindenden Finanznetze.
Der Gatewayhost 30 ist unsicher mit Ausnahme eines in ihn eingebetteten oder an ihn angeschlossenen Hardwaresicherheitsmoduls. Dieses Hardwaresicherheitsmodul kann ein interner PCI-Krypto-Coprozessor, z.B. von IBM, oder eine externer Krypto-Coprozessor, z.B. von Encipher oder Chrysalis, usw. sein. Es wird angenommen, dass das Hardwaresicherheitsmodul entsprechend FIPS 140-1/2, Common Criteria oder einem anderen Standard von einem unabhängigen, akkreditieren Labor zertifiziert ist.
Der Zweck des Verwendens eines Hardwaresicherheitsmoduls innerhalb des Gatewayhosts 30 liegt darin, Angriffe auch von wissenden und fortgeschrittenen Angreifern aus dem Innenbereich zu vereiteln, wie dem UNIX-Superuser oder einem Datenbanksystemadministrator. Die Netzverbindung 8 zwischen dem Gatewayhost 30 und dem Bankhost 50 wird als unsicher und unzuverlässig angenommen, da angenommen wird, dass der Gatewayhost 30 von einem Dritten betrieben wird, der keinen Zugang zu einem Finanznetz hat.
Der Endkundenhost 10 ist unsicher mit Ausnahme eines in ihn eingebetteten Hardwaresicherheitsmoduls. Dieses Hardwaresicherheitsmodul kann ein interner Krypto-Prozessor wie der i-Button von Dallas Semiconductors, eine Smartcard oder jedwedes handelsübliche oder eigene Gerät sein, das klein und leistungsstark genug ist, die Annehmlichkeitsanforderungen der Endkunden und die Sicherheitsanforderungen der jeweiligen Institutionen des Bankwesens und der Regierungsbehörden zu erfüllen. Es wird angenommen, dass das Hardwaresicherheitsmodul entsprechend FIPS 140-1/2, Common Criteria oder einem anderen Standard von einem unabhängigen, akkreditieren Labor zertifiziert ist.
Der Zweck des Verwendens eines Hardwaresicherheitsmoduls innerhalb des Endkundenhosts liegt darin, Angriffe auch von kenntnisreichen und fortgeschrittenen Benutzern zu vereiteln, die gewillt sind, Geld für das Knacken eines Endkundengeräts aufzubringen, um danach freie Dienste zu erhalten. Die Verbindung 7 zwischen dem Endkundenhost 10 und dem Gatewayhost 30 ist unsicher, da sie über ein öffentliches Netz erfolgt, wie das Internet, ein drahtloses oder ein Telefonnetz.
Die oben beschriebenen Sicherheitsanforderungen legen einem ultrasichern Kontenverwaltungssystem, das von dem Gatewayhost 30 betrieben wird, die folgenden Kommunikationssicherheitsanforderungen auf.
Geldmittel dürfen unter keinen Umständen verloren gehen. Wenn die Kommunikationsleitung zwischen dem Bankhost 50 und dem Gatewayhost 30 oder zwischen dem Gatewayhost 30 und dem Endkundenhost 10 unterbrochen wird, müssen die Zahlungsprotokolle sicherstellen, dass jede Transaktion sicher zu ihrem anfänglichen Statuts rückabgewickelt wird und alle Geldmittel da verbleiben, wo sie zuvor waren. Wenn das Datenbankverwaltungssystem zusammenbricht, müssen ausreichend robuste Backup-Mechanismen vorhanden sein, um den vorherigen Status der Datenbank präzise wiederherzustellen.
Das Kontenverwaltungssystem muss eine End-to-End-Authentifizierung von dem Bankhost 50 direkt durchgehend zum Hardwaresicherheitsmodul des Endkundengeräts 10 und umgekehrt für Rücküberweisungen sicherstellen. Diese Anforderung impliziert einen Schutz gegen Wiederholungen, was einen Weg darstellt, missbräuchlich jemanden unautorisierten als einen autorisierten Benutzer darzustellen.
Geldmittel dürfen nicht manipuliert werden. Das Kontenverwaltungssystem muss sicherstellen, dass Endkunden niemals mehr Geldmittel erhalten, als das was sie auf ihrem Bankkonto beim Bankhost 50 haben. Es ist klar, dass der Endkundenhost 10 alles von dem Gatewayhost 30 heruntergeladenen Geldmittel innerhalb des Hardwaresicherheitsmoduls des Endkundenhosts speichern muss. Entsprechend muss der Gatewayhost 30 seine Kontendatenbank mittels seines Hardwaresicherheitsmoduls in einer solchen Weise schützen, dass es unmöglich sein muss, Geldmittel in einer unerkennbaren Weise zu manipulieren, selbst wenn der Datenbanksystemadministrator, der Netzadministrator und der Betriebssystemadministrator des Gatewayhosts 30 in einem fortgeschrittenen Angriff zusammenspielen.
Die Architektur des Endkundenhosts 10 ist in 4 gezeigt. Der Endkundenhost 10 weist ein Hardwaresicherheitsmodul 15 auf. Der Endkundenhost 10 kann drei Arten den Schnittstellen besitzen:

– eine Benutzerschnittstelle 11, z.B. eine textbasierte, graphische oder sprachbasierte Benutzerschnittstelle. Es kann ebenso eine Kabelschnittstelle zu einem anderen Gerät des Endbenutzers sein, das eine bequemere oder vielseitigere Benutzerschnittstelle aufweist.
– eine Uplink-Schnittstelle 12, die an eine Downlink-Schnittstelle des Gatewayhost 30 verbindet. Es kann eine TCP/IP-Verbindung über Ethernet oder Modem X.25 oder über einen drahtlosen Kanal sein.
– eine Erfüllungsschnittstelle 13, die die angeforderte Dienstleistung für den Endkunden bereitstellt. Es kann eine standardisierte serielle, USB- oder Parallelport-Verbindung zu einer Druckeinrichtung zum Ausdrucken von e-Tickets oder elektronischen Briefmarken sein. Es kann eine USB- oder FireWire-Schnittstelle zum Dekodieren und Entschlüsseln von Audio- oder Videostreams sein. Es kann eine Infrarot-Schnittstelle zum Verbinden an Verkaufspunkt-Terminals oder Geldautomaten sein. Es kann eine drahtlose Schnittstelle zum Verbinden mit Verkaufsautomaten usw. sein.

Das Hardwaresicherheitsmodul 15 kann drei analoge Arten von Schnittstellen aufweisen:

– eine Anwendungsebenenschnittstelle 16, die an die Benutzerschnittstelle 11 des Endkundenhost 10 oder eine auf dem Gatewayhost 30 laufende Hostanwendung 14 verbindet.
– eine Transportebenenkommunikationsschnittstelle 17, die an eine Downlink-Schnittstelle des Gatewayhosts 30 verbindet. Über diese Schnittstelle können Geldmittel über den Gatewayhost mit einem Konto bei einer realen Bank ausgetauscht werden.
– eine Erfüllungsschnittstelle 18, die an die Erfüllungsschnittstelle 13 des Endkundenhosts 10 verbindet. Über diese Schnittstelle stellt das Hardwaresicherheitsmodul über ein Erfüllungsdienstmodul 23 elektronische Güter oder Dienstleistungen gegen in dem Endkundenhost 10 gespeicherte Geldmittel zur Verfügung.

Die Softwarearchitektur des Hardwaresicherheitsmoduls 15 umfasst wenigstens vier Softwarekomponenten:

– Das Kundengeldmittelverwaltungssystem 20 ist ein Anwendungssoftwaremodul, das alle Eingaben von und alle Ausgaben zu der Endkundenbenutzerschnittstelle verarbeitet. Es hält zudem Endkundengeldmittel innerhalb sicherer Speicherregister nach, die von den Echtzeitbetriebssystem 22 bereitgestellt werden. Um diese Aufgaben zu handhaben, benutzt es ein bestimmtes B2C-Geldmitteltransfermodul 21 und es kann zusätzliche Softwarekomponenten 19 nutzen, wie ein Modul zum Sichern der Integrität und Vollständigkeit aller Rechnungsprüfungs- und Transaktionsdaten.
– Das B2C-Geldmitteltransfermodul 21 stellt alle Dienste bereit, die zum Herunterladen von Geldmitteln von einem Bankkonto eines Endkunden in das Hardwaresicherheitsmodul 15 oder zum Hochladen zurück in das Bankkonto an Endkunden benötigt werden.
– Zusätzliche Softwarekomponenten 19 stellen zusätzliche E-Produkte oder E-Dienstleistungen zur Verfügung, wie das Erstellen von elektronischen Tickets, elektronischer Geldanweisungen, elektronischer Reiseschecks, elektronischer Briefmarken, GPS-Positionsfinder, Video- oder Audioentschlüsselungseinrichtungen, elektronische Verkaufsortzahlung, usw.
– Das Echtzeitbetriebssystem (RTOS) 22 leistet grundlegende Dienste wie:
– allgemeine und kryptographische Rechenleistung, die optional durch spezielle kryptographische Coprozessoren beschleunigt ist,
– kryptographische Boot-Loader, die sicherstellen, dass nur korrekt signierte ausführbare Programme oder DLLs ausgeführt werden,
– Verwaltung des Flash-Memory und des flüchtigen Speichers,
– Echtzeituhr.

Etwaige Software-Treiber für zusätzliche Sensoren oder Aktoren, die die zusätzlichen Softwarekomponenten benötigen könnten, z.B. GPS-Empfänger, USB, FireWire, Geldautomat, usw.
Die Architektur des Gatewayhosts 30 ist in 4 dargestellt. Der Gatewayhost 30 umfasst eine Benutzerschnittstelle, allgemeine Rechenmittel, beständige Speichermittel 34 für, unter anderem, eine Kontendatenbank, ein Datenbankverwaltungssystem (DBMS) 31, ein Hardwaresicherheitsmodul 35 und zwei Arten von Schnittstellen:

– eine Uplink-Schnittstelle 32, die an den Bankhost 50 verbindet und
– eine Downlink-Schnittstelle 33, die an die Uplink-Schnittstelle 12 des Endkundenhosts 10 verbindet.

Das Hardwaresicherheitsmodul 35 hat vier Arten von Schnittstellen:

– eine Anwendungsebenenschnittstelle 36, über die das Hardwaresicherheitsmodul Zugang zu dem/den Datenbankverwaltungssystem(en) 31 des Gatewayhosts 30 hat, beispielsweise um Anwendungsdaten oder seinen Log-Stream auszugeben;
– eine Anwendungsebenenschnittstelle 39, über die der Betreiber. des Gatewayhosts 30 das Hardwaresicherheitsmodul 35 warten kann;
– eine Transportebenen-Uplink-Schnittstelle 37, die an die Uplink-Schnittstelle 32 des Gatewayhosts 30 verbindet. Über diese Schnittstelle können Geldmittel mit einem Konto beim Bankhost 50 ausgetauscht werden;
– eine Transportebenen-Downlink-Schnittstelle 38, die an die Downlink-Schnittstelle 33 des Gatewayhosts 30 verbindet.

Die Softwarearchitektur des Hardwaresicherheitsmoduls 35 umfasst wenigstens die folgenden fünf Softwarekomponenten:

– Das Ultrasichere Kontenverwaltungssystem (USAMS) 40 ist ein Anwendungssoftwaremodul, das alle Eingaben von und alle Ausgaben zu dem Gatewayhost 30 verarbeitet. Es bedient zudem Anfragen, die entweder über ein B2C-Geldmitteltransfermodul 41 oder ein B2B-Geldmitteltransfermodul 43 hereinkommen. Um diese Anfragen zu handhaben, benutzt es ein bestimmtes Verzeichnisverwaltungsmodul 42 und es kann zusätzliche Dienste des darunterliegenden Echtzeitbetriebssystems 44 des Hardwaresicherheitsmoduls 35 nutzen. Zusätzlich sichert es die Integrität und Vollständigkeit aller Rechnungsprüfungs- und Transaktionsdaten.
– Das B2B-Geldmitteltransfermodul 41 stellt alle Dienste bereit, die zum Austauschen von Geldmitteln zwischen einem Konto eines Endkunden beim Gatewayhost 30 und seinem Konto beim Bankhost 50 nötig sind.
– Der Verzeichnisverwalter 42 stellt zusätzliche Dienste bereit, die zur Sicherstellung der Integrität der beim Gatewayhost 30 außerhalb seines Hardwaresicherheitsmoduls 35 nachgehaltenen Daten benötigt werden. Zusätzlich kann der Verzeichnisverwalter 42 eine starke Vertraulichkeit der externen Kundenkontendatenbank sichern.
– Das B2C-Geldmitteltransfermodul 43 stellt alle Dienste bereit, die zum Austauschen von Geldmitteln zwischen einem Konto eines Endkunden beim Gatewayhost 30 und dem Endkundenhost 10 nötig sind.
– Das Echtzeitbetriebssystem (RTOS) 44 leistet grundlegende Dienste wie:
– allgemeine und kryptographische Rechenleistung, die optional durch spezielle kryptographische Coprozessoren beschleunigt ist,
– kryptographische Boot-Loader, die sicherstellen, dass nur korrekt signierte ausführbare Programme oder DLLs ausgeführt werden,
– Verwaltung des Flash-Memory und des flüchtigen Speichers,
– Echtzeituhr.

Das Hardwaresicherheitsmodul 35 des Gatewayhosts 30 umfasst ein ultrasicheres Kontenverwaltungssystem (40), das große Kundenkontendatenbanken so verwalten kann, dass die Integrität und/oder Vertraulichkeit aller Kundenkonten strikt sichergestellt ist:

(1) auch gegen den fortgeschrittensten und privilegiertesten Angreifer aus dem inneren Bereich wie einem Zusammenspiel des Administrators des DBMS und dem Superuser des darunterliegenden Betriebssystems des Gatewayhosts 30. Es ist zu bemerken, dass ein Datenbankadministrator Lese- und Schreibzugriff auf alle Kundenkonten hat und dass ein Superuser des Betriebssystems die Macht hat, sogar den DBMS-Kernel zu patchen.
(2) obwohl sich das Datenbankverwaltungssystem (DBMS) und die Festplatten, auf denen die Datenbanken liegen, in einer feindlichen Umgebung wie dem Gatewayhost 30 oder bei einem entfernten Datenzentrum eines Subunternehmers oder sogar verteilt über eine Anzahl von Hosts im Internet befinden können.

Das Konzept der ultrasicheren Kontenverwaltung wird am Beispiel einer sehr einfachen Datenbank erläutert. Das ultrasichere Kontenverwaltungssystem 40 führt die Kundenkontendatenbank (CAD) unter Verwendung des DBMS außerhalb des Hardwaresicherheitsmoduls 35, da die Kundendatenbank möglicherweise größer ist, als das was das Hardwaresicherheitsmodul aufnehmen kann. Zu der externen Kundenkontendatenbank führt das ultrasichere Kontenverwaltungssystem 40 ein internes Integritätsaufrechterhaltungsverzeichnis (IMD) unter Verwendung des Verzeichnisverwaltungsmoduls innerhalb des Hardwaresicherheitsmoduls 35. Das Integritätsaufrecherhaltungsverzeichnis ist eine Tabelle mit einer Zeile für jedes Kundenkonto der externen Kundenkontendatenbank und zwei Spalten. Die erste Spalte nimmt eine Kontonummer auf, die zweite einen Integritätsprüfkode (ICC). Das interne Integritätsaufrecherhaltungsverzeichnis spiegelt die externe Kundenkontendatenbank zeilenweise wieder, d.h. für jede Zeile der Kundenkontennummer in der externen Kundenkontendatenbank gibt es eine Zeile in dem internen Integritätsaufrecherhaltungsverzeichnis.
In der Praxis besteht die externe Kundenkontendatenbank aus einer Tabelle mit drei Spalten und möglicherweise Tausenden an Zeilen. Jede Zeile enthält ein Kundenkonto. Die erste Spalte nimmt die Kundenkontonummer auf, die zweite Spalte nimmt eine Kunden-ID auf und die dritte Spalte nimmt einen Kontowert auf, wie die zu Beispielzwecken in der folgenden Tabelle gezeigt ist:
Es ist entscheidend, dass das Integritätsaufrechterhaltungsverzeichnis im geschützten Speicher innerhalb des Hardwaresicherheitsmoduls gehalten wird. Man bedenke die folgende schwache Realisierung der Kundenkontenverwaltung 40, bei der das Integritätsaufrecherhaltungsverzeichnis stattdessen in der externen Kundenkontendatenbank gehalten wird. Beispielsweise könnte die externe Kundenkontendatenbank mit einer zusätzlichen Spalte ergänzt werden, die den ICC des jeweiligen Kundenkontos aufnimmt. Ein Angreifer aus dem Innenbereich wie der DBMS-Administrator 42 kann zwar keine gültigen ICCs für beliebige Kontodaten erzeugen, er könnte allerdings vorherige Zustände einschließlich gültiger ICCs in die Kundenkontendatenbank „zurückspielen", vorzugsweise Zustände mit höheren Kontowerten als der tatsächliche Kontowert. Die „Rückspiel"-Attacke würde unerkannt bleiben, da die schwache Realisierung der Kundenkontenverwaltung 40 keine Möglichkeit aufweist, festzustellen, ob die Daten für ein Konto die richtigen sind.
Immer wenn das ultrasichere Kontenverwaltungssystem 40 das Kundenkonto n (erstes Feld) aktualisiert,

(1) schreibt es den neuen Kundennamen <KundenName_n> in das zweite Feld der Zeile und den neuen Kontowert <KontoWert_n> in das dritte Feld derselben Zeile.
(2) Als nächstes berechnet es den entsprechenden Integritätsprüfkode <ICC_n> aus der Kontonummer, dem Kundennamen und dem Kontowert. Der Integritätsprüfkode kann ein Hash-Wert, MAC oder eine digitale Signatur sein.
(3) Schließlich schreibt es den Integritätsprüfkode <ICC_n> in das zweite Feld des Kontos des Integritätsaufrechterhaltungsverzeichnisses.

Inner wenn das ultrasichere Kontenverwaltungssystem 40 das Kundenkonto n (erstes Feld) aus der externen Kundenkontendatenbank liest,

(1) liest es <KundenName_n> aus dem zweiten Feld, <KontoWert_n> aus dem dritten Feld und <ICC_n> aus dem vierten Feld.
(2) Vor dem Verarbeiten dieser Daten, überprüft das Kontenverwaltungssystem, ob ICC_n HMAC (n|<KundenName_n>|<KontoWert_n>).
(3) Wenn diese Prüfung negativ ausfällt, wurden <KundenName_n> oder <KontoWert_n> oder beides geändert, nachdem sie das letzte Mal vom Kontenverwaltungssystem aktualisiert wurden. In diesem Fall startet das Kontenverwaltungssystem eine Rückgewinnungsprozedur, die den derzeitigen Zustand der Kundenkontendatenbank unter Berücksichtigung einer Anzahl von Belegen wie Backup-Bändern, Buchungsbelegen der Kundenkontendatenbank und des Integritätsaufrechterhaltungsverzeichnisses analysiert.
(4) Nur wenn in Prüfung in Schritt (2) erfolgreich ist, wird das ultrasichere Kontenverwaltungssystem eine Anfrage zu den Kundenkontendaten verarbeiten.

Das Problem des Rückgewinnens nach Korrumpierung der Kundenkontendatenbank des Gatewayhosts 30 ist ein Verfügbarkeitsproblem. Als solches kann es nicht mittels kryptographischer Techniken gelöst werden. Es kann nur mittels geeigneter Sicherheitsstrategien und -praktiken gelöst werden. Diese schließen das Training und das Bewusstsein der Beschäftigten, solide Backup-, Protokoll- und Revisionsverfahren, usw. ein. Diese Maßnahmen zusammen helfen dabei, ausreichend Belege zur Rückgewinnung der Kundenkontendatenbank aus einem korrumpierten Zustand zur Verfügung zu stellen. Es ist wichtig zu bemerken, dass das ultrasichere Kontenverwaltungssystem 40 sicherstellt, dass nur intakte Kontendaten verarbeitet werden. Es hilft zudem dabei, festzustellen, welche Konten korrumpiert wurden. Es kann allerdings nicht das Korrumpieren von Konten verhindern, weder infolge eines Unfalls noch durch einen Angreifer. Die ultrasichere Kontenverwaltung verwendet bekannte Rückgewinnungsmechanismen weiter, die ohnehin von einem Datenzentrum vorgehalten werden müssen.
Es wird empfohlen, einen Message-Authentication-Kode als Integritätsprüfung zu verwenden. Beispielsweise ist der ist auf SHA-1 basierende HMAC eine gute Wahl. Obwohl in gewissen Fällen ein einfacher Hash-Wert ausreichend sein mag, ist das Berechnen eines Message-Authentication-Kodes beinahe ebenso recheneffizient und sicherer.
Wenn das Hardwaresicherheitsmodul 35 keine andere Software als das absolute Minimum dessen beinhaltet, was für die Kontenverwaltung 40 und die Unterstützungsmodule 41–44 benötigt wird, ist es ausreichend, einen einfachen Hash-Wert als Integritätsprüfkode zu nutzen, beispielsweise SHA-1. Wenn jedoch zusätzliche Individualsoftware in das Hardwaresicherheitsmodul geladen wird, ist es sicherer, einen Message-Authentication-Kode als Integritätsprüfkode zu nutzen. Dies vermeidet das zusätzliche Risiko böswilliger Individualsoftware innerhalb des Sicherheitsmoduls, die das Integritätsaufrechterhaltungsverzeichnis manipulieren und richtige Hash-Kodes für die manipulierten Daten erzeugen könnte, um die Manipulation zu verdecken.
Falls das Verzeichnismodul von anderen Funktionseinheiten außer dem Sicherheitsmodul 35 des Gatewayhosts 30 inspiziert und verifiziert werden muss oder sollte, ist der Mechanismus der digitalen Signatur der am meisten geeignete. In diesem Fall können alle potentiell verifizierenden Funktionseinheiten den Verifizierungsschlüssel teilen, ohne den Unterzeichnungsschlüssel des Kontenverwaltungssystem 40 einem Risiko auszusetzen.
Das Konzept der ultrasicheren Kontenverwaltung am Gatewayhost 30 basiert auf Hardwaresicherheitsmodulen. Ein Hardwaresicherheitsmodul hat jedoch begrenzte Rechen- und Speicherfähigkeiten und stellt daher einen möglichen Flaschenhals dar. Als Hardwaresicherheitsmodul des Gatewayhosts (30) sollte der kryptographische Coprozessor 4758-002/023 von IBM in Betracht gezogen werden. Dieser Coprozessor stellt eine natürliche Wahl da, da er eine FIPS 140-1 Gesamt-Level 4/3-Zertifikat besitzt und frei programmierbar ist. Er wird mit 4 MB Flash-RAM geliefert, von denen 3 MB von Individualanwendungssoftware genutzt werden können. Der Flash-RAM kann optional verschlüsselt werden. Der interne Verschlüsselungsschlüssel liegt in einem batteriegepufferten RAM, das wirksam genullt wird, falls jemand ein Manipulieren des kryptographischen Coprozessors versucht.
Eine Implementierung des ultrasicheren Kontenverwaltungssystems 40 der oberen Abschnitte benötigt pro Konto 4 Byte für die Kontonummer und 20 Byte (120 Bit) für den Integritätsprüfkode. Das IBM 4758 Modell 002 erreicht eine interne Signierleistung von 71 RSA-Digitalsignaturen (1024 Bit Modulus) pro Sekunde. Um größere Kontendatenbanken zu unterstützen oder eine höhere Transaktionsrate pro Sekunde zu erreichen, müssen zusätzliche kryptographische Coprozessoren verwendet werden.
Das obige ultrasichere Kontenverwaltungssystem 40 skaliert gut, wenn ein statischer Speicherausgleich verwendet wird. Das heißt, dass das Hardwaresicherheitsmodul 35 mit einer Anzahl von eigentlichen Hardwaresicherheitsmodulen realisiert wird, wobei jedes davon die Integrität einer vorbestimmten Untergruppe von Kundenkonten aufrechterhält. Das Integritätsaufrechterhaltungsverzeichnis ist logisch in Teile aufgeteilt, und jeder Teil wird in gesichertem Speicher eines der eigentlichen Hardwaresicherheitsmodule gehalten.
Eingehende Aufträge von Endkunden können auf unterschiedliche Weisen weitergeleitet werden: Eine eingehende Anfrage kann zu dem richtigen eigentlichen Hardwaresicherheitsmodul von der Anwendungssoftware des Gatewayhosts 30 weitergeleitet werden, wenn diese die Identität des Endkunden und seine Kontonummer kennt. Andernfalls kann jede Anfrage an alle eigentlichen Hardwaresicherheitsmodule gesendet werden, was es ihnen überlässt, eine verteilte Entscheidung darüber zu treffen, welches die Anfrage bearbeitet. Die Anfrage wird nur von dem eigentlichen Hardwaresicherheitsmodul bearbeitet, in dessen Bereich an Kundenkonten sie fällt, während alle anderen eigentlichen Hardwaresicherheitsmodule die Anfrage ignorieren.
Um die Schlüsselverwaltung einfach zu halten, sollten alle eigentlichen Hardwaresicherheitsmodule das gleiche Authentisierungsschlüsselpaar in ihrer sicheren Kommunikation mit dem Endkundenhost 10 und dem Bankhost 50 verwenden. Es ist zu bemerken, dass sie weiterhin individuelle Authentisierungsschlüssel zum Erzeugen und Verifizieren ihrer internen Integritätsprüfkodes verwenden können.
Die Architektur des Bankhosts 50 ist in 6 dargestellt. Der Bankhost 50 umfasst ein Bankkontenverwaltungssystem 55, ein Betriebssystem 57, ein Datenbankverwaltungssystem (DBMS) 54 für eine Kontendatenbank 53, ein Softwaremodul 56 für B2B-Geldmitteltransfers, optional andere Softwaremodule 52 und zumindest eine Art von Schnittstelle 51, durch die der Bankhost Geldmittel mit externen Kontenverwaltungssystemen transferieren kann, wobei die Schnittstelle 51 eine Downlink-Schnittstelle ist, die an die Uplink-Schnittstelle 32 des Gatewayhosts 30 verbindet.
Im folgenden wird ein allgemeines Geldmitteltransferprotokoll vorgestellt, das für jedes ultrasichere Kontenverwaltungssystem 40 verwendet werden kann, unabhängig davon, wie es in einer Zahlungsbetreuungskette angewendet wird, wie in den 2A–2C gezeigt. Zur Veranschaulichung des folgenden Protokolls, wird die in 2A gezeigte Anwendung A verwendet.
Die ultrasichere Kontenverwaltung muss zwischen dem Gatewayhost 30 und dem Bankhost 50 einerseits und dem Endkundenhost 10 andererseits einen verlässlichen Geldmitteltransfer sicherstellen. Diese Transfers werden üblicherweise über unzuverlässige Verbindungen wie private Telefonleitungen, drahtlose Telefonverbindungen oder das Internet gehandhabt. Die ultrasichere Kontenverwaltung muss sicherstellen, dass

– Endkundengeldmittel mit dem höchsten Grad an Integrität gehandhabt werden, aber
– Endkunden oder Administratoren des Gatewayhosts 30 nicht gezielt Geldmitteltransfers abbrechen können, um in unautorisierter Weise ihre Geldmittel zu vermehren.

Da Gatewayhosts viele Verbindungen zur gleichen Zeit bedienen können, benötigen sie einen Zwischenspeicher für kritische Daten aller offenen Verbindungen zu allen Zeiten, um abgebrochene Transaktionen korrekt rückabwickeln zu können. Wenn der Gatewayhost viele zusammenfallende Verbindungen erlaubt, können die Speicheranforderungen des Hardwaresicherheitsmoduls des Gatewayhosts bedeutend werden. Ein Protokoll wird vorgestellt, das es dem Hardwaresicherheitsmodul erlaubt, alle offenen Geldmitteltransfers nachzuhal ten und zu kontrollieren, wobei es allerdings die unsicheren Datenbanken des Gatewayhosts nutzt, um die Speicheranforderungen des Hardwaresicherheitsmoduls selbst zu minimieren.
Das folgende Protokoll, das mit Bezug auf die 7 und 8A–8C erläutert wird, handhabt Geldmitteltransfers in jede Richtung zwischen dem Hardwaresicherheitsmodul A des Endkundenhosts 10 und dem Hardwaresicherheitsmodul C des Gatewayhosts. Jeder Geldmitteltransfer wird von A eingeleitet.
Die Protokollstruktur ist in 7 gezeigt. Der Endkundenhost 10 stellt nur die Benutzerschnittstelle für den Endkunden zur Verfügung, nimmt allerdings nicht am eigentlichen Kommunikationsprotokoll teil. Daher zeigt 7 drei Teilnehmer:

– das Hardwaresicherheitsmodul (HSM) A des Endkundenhosts 10,
– den Gatewayhost B einschließlich eines Datenbanksystems und
– das Hardwaresicherheitsmodul (HSM) C des Gatewayhosts B.

Während der ersten Phase (Rechenschritte A1, B1, C1, B2, A2) einigen sich A und C auf eine frische Transaktionsnummer, die ein späteres Wiederholen verhindert. Die zweite Phase (Rechenschritte A2 (fortgesetzt), B3, C2, B4, A3) dient entweder dazu, den angefragten Geldmitteltransfer komplett durchzuführen, oder in dem Fall, dass die letzte Anfrage erfolglos war, den Zustand wiederherzustellen, der vor dem Starten des Protokolls bestand, und die eigentliche Anfrage auszuführen.
Das Hardwaresicherheitsmodul A des Endkundenhost 10 besitzt einen Satz von internen Parametern:

(1) eine eindeutige Kennung ID,
(2) eine eindeutige Kennung der aktuellen Transaktionsnummer TAN_now,
(3) eine eindeutige Kennung der letzten Transaktionsnummer TAN_last, die anfangs auf Null gesetzt ist,
(4) einen Betrag, der das von A gespeicherte Guthaben darstellt,
(5) einen Signierschlüssel sk_ID,
(6) einen öffentlichen Verifizierungsschlüssel vk_C des Hardwaresicherheitsmoduls C des Gatewayhosts 30. Es wird angenommen, dass dieser öffentliche Verifizierungsschlüssel in einer authentischen Art importiert wurde, beispielsweise während der Herstellung des Hardwaresicherheitsmoduls A.

Der Gatewayhost B führt

– eine Kontendatenbank, die einen Betrag für jedes Hardwaresicherheitsmodul A mit eindeutiger Kennung ID enthält,
– eine Antwortdatenbank, die alle Antworten c₂ des Hardwaresicherheitsmoduls von B enthält, die als Antwort auf Geldmitteltransferanfragen jedes Hardwaresicherheitsmoduls A berechnet wurden. Die Antwort auf eine Anfrage mit der Transaktionsnummer TAN wird als c_2,TAN bezeichnet.

Das Hardwaresicherheitsmodul C des Gatewayhosts B weist eine Anzahl von internen Registern auf:

(1) einen TAN-Puffer, der die Paare von IDs und Transaktionsnummern aller TAN-Anfragen enthält, die bisher weder abgelaufen sind noch erfolgreich bearbeitet wurden,
(2) seinen Signierschlüssel sk_C,
(3) ein Verzeichnis der öffentlichen Schlüssel der Verifizierungsschlüssel vk_ID der Hardwaresicherheitsmodule aller registrierter Endkunden. Es wird angenommen, dass dieses Verzeichnis der öffentlichen Schlüssel in geeigneter Weise verwaltet wird, insbesondere dass nur authentisierte öffentliche Schlüssel eingefügt werden. Beispielsweise können Verifizierungsschlüssel entsprechend dem X509-Standard verwaltet werden.

Die folgende Notation wird in den 8A–8C verwendet, die ein Geldmitteltransferprotokoll im Detail erläutern. Die Signierschlüssel sk_ID und sk_C können dazu verwendet werden, digitale Signaturen zu berechnen. Der Signieralgorithmus eines digitalen Signaturmechanismus nimmt als Eingabe einen Signierschlüssel, z.B. sk_ID, und eine Nachricht m und gibt als Ausgabe eine digitale Signatur σ zurück. Der Signieralgorithmus wird folgendermaßen bezeichnet: σ ← sign(skID, m).
Wenn die Nachricht aus mehreren Bitsträngen m₁, m₂, ..., m_n zusammengesetzt ist, wird die gesamte Nachricht mit m = (m₁, m₂, ..., m_n) bezeichnet.
Die Verifizierungsschlüssel vk_ID und vk_C werden zum Verifizieren der digitalen Signaturen des jeweils mit ID und C gekennzeichneten Hardwaresicherheitsmoduls verwendet. Der Verifizierungsalgorithmus nimmt als Eingabe einen Verifizierungsschlüssel, z.B. vk_ID, eine Nachricht m und eine Signatur σ und gibt als Ausgabe einen Booleschen Wert accept. Der Verifizierungsalgorithmus wird folgendermaßen bezeichnet: accept ← verify(vkID, m, σ).
Wenn der Algorithmus WAHR zurückgibt, spricht man davon, dass die Signatur für die Nachricht m bezüglich des Verifizierungsschlüssels vk_ID gültig ist. Andernfalls wird sie als ungültig bezeichnet.
Der Endkunde kann einen Geldmitteltransfer von seinem Konto bei dem Gatewayhost zu seinem Endkundenhost 10 anfragen. Solch ein Herunterladen von Geldmitteln wird mit einem positiven Betrag x in Rechenschritt A2 angegeben. Der Endkunde kann ebenso eine Rücküberweisung von seinem Endkundengerät 10 zurück zu seinem Kundenkonto bei dem Gatewayhost in Auftrag geben. Solch eine Rücküberweisung wird mit einem negativen Betrag x in Rechenschritt A2 angegeben. In jedem Fall darf kein Zwischenzustand des Protokolls auftreten, in dem die Summe der Guthaben in den Hardwaresicherheitsmodulen A und C die Summe ihrer Guthaben zu Beginn des Protokolls übersteigt. Ein solcher Zwischenzustand könnte durch den Endkunden dazu missbraucht werden, die Transaktion gezielt abzubrechen, um sein Gesamtguthaben zu erhöhen. Daher stellt das Protokoll sicher, dass im Fall einer Herunterladeanfrage (x ≥ 0) das Endkundenguthaben zuerst bei dem Hardwaresicherheitsmodul C reduziert wird (siehe Schritt C2.3 in 8C), bevor es bei dem Hardwaresicherheitsmodul A erhöht wird (siehe Schritt A3.3 in 8C). Im Fall einer Hochladeanfrage wird das Guthaben bei dem Hardwaresicherheitsmodul A reduziert (siehe Schritt A2.5 in 8B), bevor das Guthaben des Endkunden bei dem Hardwaresicherheitsmodul C erhöht wird (siehe Schritt C2.3 in 8C).
Das Hardwaresicherheitsmodul A leitet das Protokoll durch Anfragen einer frischen TAN (Schritt A1.1) und deren Senden als Nachricht a₁ an den Gatewayhost B (Schritt A1.2) ein. Der Gatewayhost B empfängt die Nachricht a₁, kopiert sie zu b₁ (Schritt B1.1) und leitet sie unverändert an sein Hardwaresicherheitsmodul C weiter (Schritt B1.2). Das Hardwaresicherheitsmodul C empfängt die Nachricht b₁ und extrahiert daraus ID' (Schritt C1.1). Danach benutzt es einen Hardwarezufallszahlengenerator, um eine 64-Bit Transaktionsnummer TAN ungleich Null zu wählen (Schritt C1.2), gibt das Paar (ID', TAN) in den TAN-Puffer (Schritt C1.3) und sendet die Nachricht c₁ = respondTAN(ID', TAN) zurück zum Gatewayhost B (Schritt C1.4). Der Gatewayhost B empfängt die Nachricht c₁, kopiert sie zu b₂ (Schritt B2.1) und leitet sie unverändert an das Hardwaresicherheitsmodul A weiter (Schritt B2.2).
Das Hardwaresicherheitsmodul A empfängt die Nachricht b₂ und akzeptiert sie, wenn sie innerhalb einer vorgegebenen Frist nach Schritt A1 ankommt und wenn ID' gleich ID ist (Schritt A2.1). Danach aktualisiert es die internen Register TAN_last mit TAN_now (Schritt A2.2) und TAN_now mit TAN (Schritt A2.3), liest den Betrag x vom Endkunden ein (Schritt A2.4) und aktualisiert credit mit credit + x, falls ein Hochladen (x < 0) angefragt wurde (Schritt A2.5). Eine digitale Signatur σ ← sign(sk_A, (ID, TAN_last, TAN_now, x)) wird berechnet (Schritt A2.6) und eine Nachricht a₂ = reqFT(ID, TAN_last, TAN_now, x, σ) wird an den Gatewayhost B gesendet (Schritt A2.7).
Die Frist nach Rechenschritt A1, innerhalb derer die Antwort b₂ akzeptiert werden wird, muss eine Anzahl von Parametern einer gegebenen Systemimplementierung ausgleichen. Ganz allgemein, je kürzer die Frist ist, desto geringer ist das Risiko, angegriffen zu werden. Je länger sie ist, desto toleranter ist das System gegenüber Nachrichtenverspätungen infolge von Netzüberlastungen usw.
Der Gatewayhost B empfängt die Nachricht b₂. Wenn TAN_last gleich Null ist, sendet er die eigentlichen Geldmitteltransferanfrage an das Hardwaresicherheitsmodul C (Schritt B3.1), während er andernfalls damit fortsetzt, die Antwort c₂(TAN_last) in der Antwortdatenbank nachzusehen (Schritt B3.2) und eine Rückabwicklungsanfrage b₃ an sein Hardwaresicherheitsmodul C (Schritt B3.3) sendet.
Das Hardwaresicherheitsmodul C des Gatewayhosts B empfängt die Nachricht b₃ und akzeptiert sie dann und nur dann, wenn sie innerhalb einer bestimmten Frist nach Schritt C1 ankommt und entweder die letzte Transaktion erfolgreich verarbeitet (Schritt C2.1a) oder die letzte Transaktion abgebrochen wurde (Schritt C2.1b). Das Paar (ID, TAN_now) wird aus dem TAN-Puffer gelöscht (Schritt C2.2). Wenn die Nachricht b₃ = reqFT(ID, TAN_last, TAN_now, x, σ) ist, wird das Endkundenguthaben credit_ID mit credit_ID – x aktualisiert (Schritt C2.3). Falls alternativ die Nachricht b₃ = rollback(a₂, c₂(TAN_last)) ist, wobei c₂(TAN_last) = reqFT(ID, TAN_last,0, TAN_last, x₀, σ₀) ist, d.h. falls die Rückabwicklung abgebrochen wurde, wird das Endkundenguthaben credit_ID mit credit_ID – x + x₀ aktualisiert (Schritt C2.4). Danach wird die digitale Signatur σ' = sign(sk_C, (ID, TAN_now, x)) berechnet (Schritt C2.5) und eine Nachricht c₂ = resFT(ID', TAN', x', σ') mit ID' = ID, TAN' = TAN_now und x' = x an den Gatewayhost B gesendet (Schritt C2.6).
Die auf den Rechenschritt C1 folgende Frist, innerhalb derer die Antwort b₃ akzeptiert werden wird, muss wie oben beschrieben eine Anzahl von Parametern einer gegebenen Systemimplementierung ausgleichen. Darüber hinaus muss der TAN-Puffer regelmäßig von TANs geleert werden, auf die keine gültigen Geldmitteltransfers innerhalb der gesetzten Frist folgten.
Der Gatewayhost B empfängt die Antwort c₂ von seinem Hardwaresicherheitsmodul C, speichert sie in seiner Antwortdatenbank (Schritt A3.1), kopiert sie zu Nachricht b₄ (Schritt A3.2) und sendet die Nachricht b₄ an das Hardwaresicherheitsmodul A.
Das Hardwaresicherheitsmodul A des Endkundenhosts 10 empfängt die Nachricht b₄ und akzeptiert sie, wenn sie innerhalb der bestimmten Frist nach Schritt A2 ankommt, wenn die Signatur σ' bezüglich des Verifizierungsschlüssels vk_C für die Nachricht (ID', TAN', x') gültig ist, wenn TAN' gleich TAN ist und wenn x' gleich x ist (Schritt A3.1). Wenn eine dieser Bedingungen nicht gegeben ist, wird die Transaktion abgebrochen und die folgenden Schritte werden übersprungen. Wenn alle Bedingungen erfüllt sind, wird die Transaktion erfolgreich abgeschlossen, indem TAN_now mit Null aktualisiert wird (Schritt A3.2) und credit mit credit + x aktualisiert wird, sofern x eine Herunterladeanfrage anzeigt (x ≥ 0) (Schritt A3.3).
Die auf den Rechenschritt A2 folgende Frist, innerhalb derer die Antwort b₄ akzeptiert werden wird, muss wie oben beschrieben eine Anzahl von Parametern einer gegebenen Systemimplementierung ausgleichen.
9 zeigt eine drahtlose Zahlung per WAP-Mobiltelefon. Das Wireless Application Protocol (WAP) ist ein Standard mittels dessen WAP-Mobiltelefone 63 an einen entfernten Anwendungsserver 62 (RAS) verbinden, um anwendungsbezogene Dienstleistungen anzufordern. Wenn das WAP-Mobiltelefon einen Zahlungsdienst anfordert, verbindet der entfernte Anwendungsserver 62 an den Bezahlten 64, um die beabsichtigten Geldmittel aus dem Konto des Zahlers in das Datenzentrum des Händlers zu transferieren.
Technisch gesehen besteht eine solche Zahlung aus zwei Protokollen:

(1) eine von dem WAP-Mobiltelefon 63 über eine WAP-Session unter Verwendung von WTLS (wireless transport layer security) an den Anwendungsserver 62 übermittelte Zahlungsanfrage und
(2) das Zahlungsprotokoll, das den angefragten Betrag vom Konto des Kunden beim Ausgeber 61 abbucht und ihn über eine HTTPS-Session unter Verwendung von SSL an den jeweiligen Händler 64 transferiert.

Das erste Protokoll autorisiert den entfernten Anwendungsserver 62 im Namen des Zahlers 63 gegenüber de Ausgeber 61 und dem Händler 64 aufzutreten. Der entfernte Anwendungsserver kann als Protokollumsetzer zwischen WAP und HTTPS und anderen Protokollen zwischen dem Ausgeber 61 und dem Zahlergateway 61 gesehen werden. Der Zweck eines Sicherheitsmoduls 67 innerhalb des entfernten Anwendungsservers 62 liegt darin, sicherzustellen, dass diese Protokollumsetzung nicht korrumpiert ist und sich entweder erfolgreich von unterbrochenen Verbindungen wiederherstellt oder alle Teilnehmer in ihre Zustände vor der letzten Zahlungsanfrage zurückversetzt.
In einem genaueren Beispiel richtet der Händler 64 einen Webserver innerhalb von Verkaufsautomaten auf und die Kunden können mit ihren WAP-Mobiltelefonen 63 an diese Verkaufsautomaten verbinden.
Eine andere Anwendung illustriert eine Ausweitung auf eine gestufte elektronische Zahlung in 10, die sich auf das Verbinden von Online-Diensten mit elektronischen Tickets bezieht. Wenn Zahler 73 elektronische Tickets 78 für einen bestimmten Flug mit einer Fluglinie oder Tickets für eine Veranstaltung in einer Oper, einem Kino, Football-Stadion usw. anfordern, ist es wahrscheinlich, dass sie entsprechende Sitzreservierungen usw. vornehmen. Hier bestehen zwei Stufenprozesse:

(1) eine Ticketanfrage wird von dem Zahler 73 an das Zahlergateway 72 übermittelt und
(2) das Zahlergateway 72 bucht den jeweiligen Betrag von dem Konto des Kunden beim Ausgeber 71 ab und gibt eine elektronisches Ticket an den Zahler 73. Zur gleichen Zeit führt das Zahlergateway 72 zudem den Zahler 73 durch ein Reservierungsmenü für die angefragte Veranstaltung.

Es ist wichtig, dass die Transaktion (2) entweder vollständig oder gar nicht durchgeführt wird. Es ist für den Kunden nicht annehmbar, den Preis zu zahlen, aber kein Ticket zu erhalten oder ohne die gewünschte Reservierung abzuschließen. Andererseits wird der Veranstalter oder die Fluglinie kein Ticket auf den Zahler oder keine auf den Namen des Zahlers vorgenommene Reservierung ohne korrekte Zahlung akzeptieren. Der Zweck des Sicherheitsmoduls 77 innerhalb des Zahlergateways 72 liegt darin, sicherzustellen, dass entweder alle Aktionen des Schrittes (2) durchgeführt werden oder keine von ihnen. Zusätzlich wird es alle Anfragen protokollieren und falls möglich eine Wiederherstellung nach unterbrochenen Verbindungen vornehmen oder alle Teilnehmer wieder in den Zustand vor der letzten Anfrage zurückversetzen.
Es ist zu bemerken, dass in diesem Beispiel das Ticket 78 auf verschiedene Weisen realisiert werden kann. Es kann als papierbasiertes Ticket auf einen Aufkleber, einfaches Papier oder gesichertes Wertpapier gedruckt werden. Es kann ebenso vom Zahler 73 in elektronischer Form gehalten werden, z.B. als wiederverwendbare Chipkarte, die in einen Chipkartenleser am Ticketverkaufsstand eingeführt werden kann, oder als Handheld-Gerät, das eine Infrarot- oder Drahtlos-Verbindung zum Ticketverkaufsstand eingehen kann.
Bei dieser Anwendung werden Sicherheitsgeräte 77, 79 im Zahlergateway 72 und im Reservierungsserver 74 eingesetzt. Sie garantieren folgendes:

(1) Zahler 73 werden nur für die Tickets, die sie bestellt haben, und die Reservierungen, die sie vorgenommen haben, belastet.
(2) Veranstaltungsorganisatoren (Bezahlte) erhalten die Geldmittel für jedes verkaufte Ticket und jede gemachte Reservierung.
(3) Alle Bestellungen, Reservierungen und Zahlungen werden durch das Zahlergateway 72 und den Reservierungsserver 74 sicher mitprotokolliert. Im späteren Streitfall kann die Sache durch Analysieren der Protokolleinträge beigelegt werden.
(4) Zusätzlich können die Sicherheitsgeräte 77, 79 garantieren, dass kein Ticket ohne eine korrekte Reservierung verkauft wird.

In 11 wird eine Anwendung eines Kundenbindungssystems gezeigt. Händler verschiedener Sektoren oder Betreiber des öffentlichen oder Individualverkehrs einer geographischen Region schließen sich zusammen, um ein Kundenbindungsprogramm zu führen. Sie richten ein Bezahltengateway 85 ein, um ihre sämtlichen Einnahmen in ihre jeweiligen Bankkonten bei einem oder mehreren Erwerber 86 einzuzahlen. Um die mit jedem Kunden erzielten Einnahmen nachzuhalten, führt das Bezahltengateway 85 Kundenkonten, die immer dann aktualisiert werden, wenn ein Händler seine Einnahme einzahlt. Auf diese Weise können Kunden Boni oder Guthaben vom Erwerb einer breiten Palette von Gütern und Dienstleistungen sammeln.
Bei dieser Anwendung werden Sicherheitsgeräte 87, 88 beim Bezahltengateway 85 und vorzugsweise ebenso im Verkaufortterminal 84 des Bezahlten eingesetzt. Das Sicherheitsgerät 88 beim Bezahltengateway 85 verwaltet in sicherer Weise eine Kundenkontendatenbank, die alle Einnahmen einer Anzahl von Händlern mit einer Anzahl von Kunden wiedergibt. Die Sicherheitsgeräte 87 und 88 garantieren zusammen folgendes:

(1) Die Einnahmen eines jeden Händlers werden schließlich auf das richtige Konto bei der jeweiligen erwerbenden Bank eingezahlt.
(2) Die mit jedem Kunden erzielten Einnahmen werden sicher überwacht und den Kunden werden jeweilige Boni, Guthaben, verringerte Zinsen usw. gewährt.

Ein ultrasicheres Kontenverwaltungssystem kann alle Kundendaten vertraulich halten, auch gegenüber den neugierigen Blicken des Superusers des Betriebssystems, des Datenbankadministrators des Gatewayhosts oder beiden. Ultrasichere Kontenverwaltungssysteme erreichen dieses Merkmal durch das Schreiben von Kontodaten in die externen Datenbank des Gatewayhosts lediglich in verschlüsselter Form. Typischerweise ist das ultrasichere Kontenverwaltungssystem die einzige Einheit, die überhaupt dazu vorgesehen ist, Kontendaten zu entschlüsseln, so dass es angemessen ist, ein symmetrisches Verschlüsselungsschema anzuwenden, z.B. Triple DES oder AES (Rijndal), usw.
Das Konzept der ultrasicheren Kontenverwaltung ist es, interagierende Protokollspeicher und sicherheitskritische Anwendungssteuerung innerhalb eines Hardwaresicherheitsmoduls einzukapseln. Um die begrenzten Hardware-Ressourcen des Hardwaresicherheitsmoduls auszuweiten, können Ressourcen des Gatewayhosts in einer Weise verwendet werden, die End-to-End-Authentisierung und End-to-End-Integrität zwischen zwei Endpunkten sicherstellt, die von dem Gatewayhost verbunden werden.
Es ist klar, dass die Dienstverfügbarkeit nicht allein durch das Hardwaresicherheitsmodul sichergestellt werden kann, wenn es sich auf Ressourcen des Gatewayhosts verlässt. Das Hardwaresicherheitsmodul ist jedoch ein eingebettetes System innerhalb des Gatewayhosts und kann daher ohnehin für sich allein keine Dienstverfügbarkeit garantieren. Es hat beispielsweise keine unabhängigen Kommunikationsmittel in die Welt außerhalb des Gatewayhosts. In diesem Sinn ist ultrasichere Kontenverwaltung das Maximum dessen, was in Bezug auf Sicherheit erwartet werden kann.
Ein ultrasicheres Kontenverwaltungssystem kann eingesetzt werden, um in stärkerem Maß integrierte Dienste zu realisieren, wie sichere Austauschverwaltungssystem, bei denen Händler und Kunden digitale Güter für digitales Geld austauschen. Das ultrasichere Kontenverwaltungssystem kann verwendet werden, um sicherzugehen, dass entweder beide Parteien jeweils das vereinbarte Gut bzw. Geld erhalten oder keiner von beiden überhaupt etwas vom anderen erhält. Hier kann entweder das Zahlergateway oder das Bezahltengateway als ein vertrauenswürdiger Händler dienen, der dafür verantwortlich ist, Austauschtransaktionen sicher rückabzuwickeln, die unterbrochen wurden.
Anwendungen des fairen Austauschs ergeben sich mit dem Aufkommen von Multimediageräten in Kundenhaushalten. Ein Multimediagerät kann ein zweckbestimmtes Gerät wie ein Video- oder DVD-Player sein, oder es kann ein PC sein, auf dem ein MPEG-Dekoder läuft, oder ein Browser für elektronische Bücher, usw. Die Multimediagerätestation des Kunden wird von einem Multimediaprovider versorgt, der mit (dem einen oder den mehreren) Zahlergateways seiner Kunden interagieren kann. Über das Zahlergateway kann der Kunde die Schlüssel erwerben, die einen bestimmten Inhalt aus einem Multimedia-Broadcaststream des Multimedia-Providers freischalten, z.B. pay per view. Der Kunde kann auch einen bestimmten Video- oder Audio-Inhalt bestellen, dafür zahlen und ihn direkt empfangen, z.B. video on demand. Seltene Einkäufe können online getätigt werden. Wenn das Zahlungsmodell häufige Zahlungen von wahrscheinlich geringerem Umfang (Mikro-Zahlungen ähnlich zu Telefoneinheiten) erfordern, können die Kunden offline zahlen. In diesem Fall verwenden sie ihr Multimediagerät zudem als ein sichere Brieftasche, in die sie vom Zahlergateway einen Betrag an Geldmitteln herunterladen können. Die Geldmittel innerhalb des Multimediageräts des Zahlers werden verbraucht, wenn der Zahler einen bestimmten Multimediainhalt freischaltet.
Bei dieser Anwendung werden Sicherheitsgeräte im Zahlergateway und im Server des Multimedia-Providers und optional in dem Multimediagerät des Zahlers verwendet. Die Sicherheitsgeräte garantieren zusammen folgendes:

(1) Zahler werden nur für den Inhalt belastest, den sie empfangen oder gesehen (konsumiert) haben.
(2) Multimedia-Provider (Bezahlte) erhalten die Geldmittel für jedes Stück Inhalt, das geliefert oder gesehen (konsumiert) wurde.
(3) Alle Bestellungen und Lieferungen werden in sicherer Weise durch das Zahlergateway und von dem Multimedia-Provider mitprotokolliert. Streitigkeiten können nach Analysieren der Protokolleinträge beigelegt werden.

Eine weitere Anwendung bezieht sich auf den Verkauf elektronischer Tickets für öffentlichen und Individualverkehr, wie in 12 gezeigt. Im öffentlichen Verkehr möchten Menschen U-Bahnen, Busse oder Züge nutzen, ohne vorherige Reservierungen vorzunehmen. Passagiere können die U-Bahnen, Busse und Züge wechseln und manchmal kann der beste verfügbare Fahrpreis erst nach Abschluss der Reise berechnet werden. In diesem Fall können Passagiere individuelle Tickets für jede Etappe ihrer Reise zahlen und abschließend einen Nachlass erhalten, wenn die gesamte Reise günstiger ist als die Summe ihrer Etappen. Andere Preismodell wie Dauerkarten können ebenfalls unterstützt werden.
Die Passagiere nutzen elektronische Ticketgeräte 93, die entweder (a) Geldmittel von einem Zahlergateway 92 herunterladen oder (b) einen Bezahlten autorisieren können, für den Passagier einen bestimmten Geldmittelbetrag herunterzuladen. Transport-Provider richten Eingangsterminals 94 an allen Punkten ein, an denen Passagiere in U-Bahnen, Busse oder Züge einsteigen können. Wenn ein Passagier ein Eingangsterminal 94 passiert, muss er zunächst ein Ticket erhalten. Um für das Ticket 90 zu zahlen, kann das Ticketgerät 93 entweder (a) Geldmittel vom Zahlergateway 92 im Voraus herunterladen und dann das Eingangsterminal 94 direkt über eine Drahtlos- oder Infrarot-Verbindung bezahlen oder (b) das Eingangsterminal 94 autorisieren, die Geldmittel für das Ticket von dem Konto des Passagiers bei dem Zahlergateway 92 abzubuchen.
Bei dieser Anwendung werden Sicherheitsgeräte 97, 98, 99 im Zahlergateway 92, in den Eingangsterminals 94 des Transport-Providers und optional in den Ticketgeräten 93 des Zahlers verwendet.
Die Sicherheitsgeräte 97, 98, 99 garantieren zusammen folgendes:

(1) Zahler werden nur für Reisen belastet, die sie gemacht haben, und dies nur mit dem geringsten Fahrpreis, zu dem die Reise erhältlich ist.
(2) Provider des öffentlichen und Individualverkehrs (Bezahlte) erhalten die Geldmittel für jede tatsächlich geleistete Etappe.
(3) Alle Ticketbestellungen und -lieferungen und alle tatsächlich gemachten Reisen werden in sicherer Weise von dem Zahlergateway 92 und den Eingangsterminals 94 mitprotokolliert. Streitigkeiten werden nach Analysieren der Protokolleinträge beigelegt.

Wenn verschiedene Transport-Provider ein Netz von Transportdienstleistungen betreiben, können sie zudem ein Kundenbindungssystem wie in 11 einbinden.

Claims

Sicherheitsmodul für ein Hostgerät eines Kontenverwaltungssystems mit: einer Schnittstelle zum Kommunizieren und Austauschen von Daten mit dem Hostgerät, einem Verwaltungsmodul zum Verarbeiten von Daten und Anfragen, einem Verzeichnismodul zum Speichern von kundenkontenspezifischen Prüfkodes für in dem Hostgerät gespeicherten Kundenkonten, einer Kodeerzeugungseinrichtung zum Erzeugen eines Prüfkodes unter Benutzung von Kontendaten eines Kundenkontos, und einer Verifizierungseinrichtung zum Verifizieren des Prüfkodes, um zu prüfen, ob die Kundendaten des entsprechenden Kundenkontos geändert wurden, im Falle einer Anfrage, Kundendaten des Kundenkontos zu verarbeiten.
Sicherheitsmodul gemäß Anspruch 1, wobei der Prüfkode für ein Kundenkonto von dem Verwaltungsmodul unter Benutzung der Kontonummer, des Kundennamen und des Kontowertes des Kundenkontos erzeugt wird.
Sicherheitsmodul gemäß Anspruch 1 oder 2, wobei der Prüfkode ein Hash-Kode, ein Message-Authentication-Kode oder eine digitale Signatur ist.
Sicherheitsmodul gemäß einem der vorstehenden Ansprüche, ferner mit einer Verschlüsselungs- und Entschlüsselungseinrichtung zum Verschlüsseln von Daten vor dem Austausch mit dem Hostgerät und zum Entschlüsseln von von dem Hostgerät empfangenen Daten.
Sicherheitsmodul gemäß einem der vorstehenden Ansprüche, wobei das Sicherheitsmodul in manipulationssicherer oder in auf Manipulationen reagierender Hardware eingekapselt ist.
Sicherheitsmodul gemäß einem der vorstehenden Ansprüche, wobei das Sicherheitsmodul durch eine Anzahl von Sicherheitsuntermodulen implementiert ist, von denen jedes eine Teilmenge von Prüfkodes für eine Teilmenge von Kundenkonten speichert.
Sicherheitsmodul gemäß einem der vorstehenden Ansprüche, wobei das Hostgerät ein mit anderen Hostgeräten des Kontenverwaltungssystems, insbesondere mit Endkundenhostgeräten und Bankhostgeräten, verbundenes Gatewayhostgerät ist, zum Austausch von elektronischen Waren, Dienstleistungen, Daten und/oder Geldmitteln.
Sicherheitsmodul gemäß Anspruch 7, wobei die Endkundenhostgeräte Frankiermaschinen sind und das Gatewayhostgerät von einem Portoprovider bereitgestellt wird.
Sicherheitsmodul gemäß Anspruch 7, wobei das Gatewayhostgerät derart eingerichtet ist, dass es auf sichere Weise eine oder mehrere Steuer- oder Zollbehörden über den Transfer von Geldmitteln oder Waren benachrichtigt.
Sicherheitsmodul gemäß Anspruch 7, ferner mit Geldmitteltransfermodulen zum Austausch von Geldmitteln zwischen einem Konto eines Endkunden an dem Gatewayhostgerät und seinem Konto bei einem Bankhostgerät und/oder einem Endkundenhostgerät.
Sicherheitsmodul gemäß Anspruch 7 oder 10, wobei interagierende Protokollspeicher und eine sicherheitskritische Anwendungssteuerung innerhalb des Sicherheitsmoduls eingekapselt sind.
Hostgerät zum Austausch von elektronischen Gütern, Dienstleistungen, Daten und/oder Geldmitteln zwischen Hostgeräten eines Kundenkontenverwaltungssystems mit: Schnittstellen zum Verbinden an andere Hostgeräte eines Kontenverwaltungssystems, insbesondere an Endkundenhostgeräte und Bankhostgeräte, einer Datenbankeinheit zum Speichern von Kontendaten eines Kundenkontos, und einem Sicherheitsgerät gemäß einem der vorstehenden Ansprüche.
Hostgerät gemäß Anspruch 12, ferner mit einer Einrichtung zum Sicherstellen der Integrität und Vollständigkeit aller Rechnungsprüfungs- und Transaktionsdaten.
Kontenverwaltungssystem mit: einem Endkundenhostgerät, einem Bankhostgerät, und einem Hostgerät gemäß Anspruch 12, das an das Endkundenhostgerät und das Bankhostgerät zum Austausch von elektronischen Gütern, Dienstleistungen, Daten und/oder Geldmitteln zwischen den Hostgeräten verbunden ist.
Verfahren zum Austausch von elektronischen Gütern, Dienstleistungen, Daten und/oder Geldmitteln zwischen Hostgeräten eines Kontenverwaltungssystems, insbesondere eines Endkundenhostgeräts, einem Gatewayhostgerät und einem Bankhostgerät, mit den Schritten: Anfrage bei einem Hostgerät, Kontendaten eines in dem Hostgerät gespeicherten Kundenkontos zu verarbeiten, Erzeugen eines kundenkontospezifischen Prüfkodes durch ein Verwaltungsmodul eines Sicherheitsgeräts des Hostgeräts unter Benutzung von Kontodaten des Kundenkontos, und Verifizieren des Prüfkodes, um zu überprüfen, ob die Kundendaten des Kundenkontos geändert wurden, bevor die Kontodaten des Kundenkontos verarbeitet werden.
Verfahren gemäß Anspruch 15, wobei im Falle eines angefragten Geldmitteltransfers von einem Endkundenhostgerät an ein Gatewayhostgerät das Guthaben des Endkunden bei dem Endkundenhostgerät verringert wird, bevor das Guthaben des Endkunden bei dem Gatewayhostgerät erhöht wird.
Verfahren gemäß Anspruch 15, wobei im Falle eines angefragten Geldmitteltransfers von einem Gatewayhostgerät an ein Endkundenhostgerät das Guthaben des Endkunden bei dem Gatewayhostgerät verringert wird, bevor das Guthaben des Endkunden bei dem Endkundenhostgerät erhöht wird.
Verfahren gemäß einem der Ansprüche 15 bis 17, wobei die Schritte des Protokolls zum Geldmitteltransfer derart vorgesehen sind, dass die Summe der Guthaben in dem Endkundenhostgerät und dem Gatewayhostgerät vor dem Beginn und nach der Beendigung der Protokollausführung gleich sind.
Computerprogrammprodukt mit Programmkodemitteln zum Veranlassen eines Computers, die Schritte des Verfahrens gemäß einem der Ansprüche 15 bis 18 auszuführen.