-
Die
Erfindung betrifft ein Datenkommunikationssystem, ein Datenkommunikationsverfahren,
sowie Vorrichtungen zur Verwendung in einem Datenkommunikationssystem.
-
Im
Stand der Technik sind Datenkommunikationssysteme, insbesondere
Internet-Bankanwendungs-Datenkommunikationssysteme bekannt, bei denen
sich ein Nutzer an seinem Rechner mittels Eingabe entsprechender
Kennungen (z.B. seiner Konto-, und seiner PIN-Nummer) bei einem Zentralrechner, z.B.
einer Bank, authentifizieren, und – nach Eingabe einer entsprechenden,
weiteren Kennung, z.B. einer TAN-Nummer – entsprechende Transaktionen
(Überweisungen,
Umbuchungen, Wertpapier-Käufe
oder Verkäufe,
etc.) durchführen
kann.
-
Die
TAN-Nummern werden dem Nutzer i.d.R. in Papierform zugesendet, was
mit einem relativ hohen Aufwand verbunden ist.
-
Alternative
Internet-Bankanwendungs-Datenkommunikationssysteme, z.B. entsprechende, chipkartenbasierte
HBCI-Systeme, SMS-basierte Internet-Bankanwendungs-Datenkommunikationssysteme,
etc. haben sich am Markt nicht oder nur wenig durchsetzen können, da
sie z.B. mit hohen Investitionskosten verbunden sind und meist relativ
wenig Bedienungskomfort bieten usw.
-
Die
Erfindung hat zur Aufgabe, ein neuartiges Datenkommunikationssystem,
ein neuartiges Datenkommunikationsverfahren, sowie neuartige Vorrichtungen
zur Verwendung in einem Datenkommunikationssystem zur Verfügung zu
stellen. Sie erreicht dieses und weitere Ziele durch die Gegenstände der
Hauptansprüche.
Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
-
Beansprucht
wird ein Datenkommunikationssystem, mit mindestens einem ersten
Endgerät,
mindestens einem weiteren, mobilen Endgerät und mindestens einer zentralen
Rechnereinheit. Selbstverständlich
ist damit auch ein System gemeint, welches mehrere erste bzw. weitere,
mobile Endgerät und/oder
mehrere zentralen Rechnereinheit umfasst.
-
Das
erste Endgerät
ist insbesondere eine Rechner-Einrichtung, z. B. ein PC, Laptop,
Organizer (Palm, Blackberry etc.), Mobilfunktelefon etc., kann also
stationär
oder mobil eingerichtet sein. Das weitere Endgerät ist typischerweise mobil,
z. B. ein Laptop, Organizer, Mobilfunktelefon. Die zentrale Rechnereinheit
kann beispielsweise ein Server oder ein Rechnernetz sein. Die zentrale
Rechnereinheit sendet eine von ihr erzeugte erste Kennung an das
erste Endgerät.
-
Diese
erste Kennung beinhaltet vorteilhafterweise mindestens eine die
zentrale Rechnereinheit identifizierende Zentralrechner-Kennung,
z. B. eine Serversignatur, und eine Auftragsquersumme. Die Zentralrechner-Kennung
beinhaltet vorteilhafterweise eine Gerätekennung des weiteren, mobilen
Endgerätes
(z. B. ein IMEI) oder alternativ eine dem jeweiligen Nutzer zugeordnete
Benutzerkennung, und einen Transaktionszähler (z. B. einen ATC) oder
einen Zufallswert. Die Auftragsquersumme repräsentiert vorteilhafterweise
eine zwischen erstem Endgerät
und der zentralen Rechnereinheit bestehende Auftragssitzung, günstigerweise
inklusive eines Zeitstempels. Diese Auftragssitzung kann z. B. eine Banküberweisung,
eine Bestellung, eine Angebotsabgabe etc. beinhalten.
-
Das
weitere, mobile Endgerät
ist so ausgestaltet und eingerichtet, dass es nach Eingabe der ersten
Kennung diese zur Authentifizierung der zentralen Rechnereinheit
verwendet. Dies geschieht geschickterweise dadurch, dass nach Eingabe
der ersten Kennung aus dieser die Zentralrechner-Kennung extrahiert
und mit einer im weiteren, mobile Endgerät erzeugten bzw. gespeicherten
Zentralrechner-Kennung vergleicht und dieser Vergleich zur Authentifizierung
der zentralen Rechnereinheit verwendet wird. Die im weiteren, mobilen
Endgerät
vorhandene Zentralrechner-Kennung kann auch verschlüsselt bzw.
mit anderen Daten verschränkt
gespeichert sein. Es ist auch möglich,
dass die im weiteren, mobilen Endgerät (indirekt) vorhandene Zentralrechner-Kennung
erst berechnet werden muss; es ist dann vorteilhaft, wenn dies mittels
der gleichen Logik geschehen kann, mit der der Zentralrechner seine Kennungen
erzeugt. Die Autentifizierung entspricht also meist der Herleitung
und daraufhin einem Vergleich zweier Kennungen, nämlich dem
Vergleich einer Server-Kennung mit einer Authentifizierungs-Kennung.
Dabei sind die zu vergleichenden Kennungen vorteilhafterweise identisch,
es sind aber auch Vergleiche zwischen nicht-identischen Kennungen
möglich,
wobei hier ein anderes Kriterium zur Authentifizierung vorhanden
ist.
-
Weiterhin
wird beansprucht ein Datenkommunikationssystem der beschriebenen
Art, bei welchem durch das weitere, mobile Endgerät aus der ersten
Kennung eine weitere, zweite Kennung, insbesondere eine TAN-Nummer,
erzeugbar ist. Typischerweise wird nach Eingabe der ersten Kennung die
MTan-Kennung, die der am ersten Endgerät einzugebenden TAN-Nummer
entspricht, erzeugt, vorteilhafterweise dadurch, dass sie aus der
in der ersten Kennung enthaltenen, und dann durch das weitere, mobile
Endgerät
extrahierten Auftragskennung erzeugt wird.
-
Weiterhin
ist das beanspruchte System so ausgestaltet und eingerichtet, dass
nach Eingabe der zweiten Kennung, insbesondere einer MTan-Nummer,
in das erste Endgerät
diese an die zentrale Rechnereinheit übertragen wird. Für eine Banküberweisung
könnte
dieser Vorgang darin bestehen, dass eine vom Mobilfunktelefon ausgegebene
MTan-Nummer in das zur Eingabe der TAN-Nummer vorgesehene Feld einer
sicheren Internetseite eingegeben und dann per Internetverbindung
o. ä. an
einer Bankrechner gesendet wird. Bei der Eingabe der TAN-Nummer wird vorteilhafterweise
vor der Nummer ein Präfix eingegeben,
der es dem Bankrechner erlaubt, zwischen MTan-Nummern und klassischen
TAN-Nummern (von einer Papierliste) zu unterscheiden. Damit ist
gewährleistet,
dass beide TAN-Nummerverfahren wahlfrei durch den Kunden genutzt
werden können.
-
Vorteilhafterweise
ist die zentrale Rechnereinheit so ausgestaltet und eingerichtet,
dass die übertragene
zweite Kennung von der zentralen Rechnereinheit zur Authentifizierung
verwendet wird.
-
Selbstverständlich weiden
auch die einzelnen, entsprechend zur Verwendung ausgestalteten Komponenten
des Datenkommunikationssystems beansprucht, nämlich u. a. das erste Endgerät, das weitere,
mobile Endgerät
und/oder die zentrale Rechnereinheit.
-
Auch
beansprucht werden Datenkommunikationsverfahren, insbesondere zur
Verwendung bei einem oben beschriebenen Datenkommunikationssystem.
-
Auch
beansprucht wird eine Initialisierung des Verfahrens sowohl für bekannte
Nutzer als auch für
neue, bisher nicht registrierte Nutzer.
-
Die
Erfindung wird nun anhand eines Ausführungsbeispiels sowie der beigefügten Zeichnung näher erläutert. Die
Zeichnung zeigt:
-
1 ein
mobiles Endgerät
eines Datenkommunikationssystems gemäß eines Ausführungsbeispiels
der vorliegenden Erfindung, bei einem ersten Endgerät-Zustand;
-
2 ein
beim Datenkommunikationssystem verwendbarer Rechner, bei einem ersten
Zustand des Rechners;
-
3 das
in 1 gezeigte mobile Endgerät, bei einem zweiten Endgerät-Zustand;
-
4 das
in 1 und 3 gezeigte mobile Endgerät, bei einem
dritten Endgerät-Zustand;
-
5 der
in 2 gezeigte Rechner bei einem zweiten Zustand;
und
-
6 ein
Flußdiagramm
zur Veranschaulichung von bei dem Datenkommunikationssystem zur Auftragsbearbeitung
durchgeführten
Verfahrensschritten, einschließlich
der Erzeugung einer mobilen Tan-Kennung.
-
Im
folgenden wird die Funktionsweise eines Datenkommunikationssystems
und eines Datenkommunikationsverfahrens gemäß einem Ausführungsbeispiels
der Erfindung, insbesondere eines Internet-Bankanwendungs-Datenkommunikationssystems
mit MTG (MTG = Mobile TAN Generation (Mobile TAN Erzeugung)), und
eines MTG-Verfahrens exemplarisch dargestellt.
-
1.1 Initialisierung eines
bekannten Nutzers
-
Es
wird unterstellt, dass der Nutzer der Internet-Bankanwendung der
Anwendung bzw. – genauer – einer
zentralen Rechnereinheit wie einem Anwendungs-Zentralrechner bzw.
einem Anwendungs-Zentral-Rechennetz einer das Datenkommunikationssystem
betreibenden Bank bekannt ist, und sich an einem – z.B. in 2 gezeigten – Rechner 2 z.B.
mittels Benutzerkennung (z. B. Kontonummer) und geheimem Kennwort
(z. B. PIN) anmeldet. Bei dem Rechner 2 kann es sich um
einen tragbaren oder stationären
Rechner handeln, der eine Anzeige-Einrichtung 2a, und eine
Rechen-Einrichtung 2b aufweist, und sich z.B. zuhause beim
Nutzer, oder z.B. an dessen Arbeitsplatz befinden kann, und – z.B. über das Internet – mit dem
Anwendungs-Zentralrechner bzw. dem Anwendungs-Zentral-Rechennetz
kommunizieren kann.
-
Die
Kommunikation zwischen einem am Rechner 2 laufenden Nutzer-Browser
und der zentralen Rechnereinheit (Zentralrechner) ist zum Beispiel SSL-verschlüsselt. Nach
der Anmeldung des Nutzers wird eine logische Sitzung (Session) aufgebaut.
Meldet sich der Nutzer ab oder ist er eine bestimmte Zeit untätig (timeout),
wird die Session beendet und die zugehörigen Sitzungsdaten werden
gelöscht.
-
Einem
Nutzer, der seine Aufträge
bislang durch die Eingabe einer Transaktionsnummer signiert hat,
wird in einem Menü das
MTG-Verfahren angeboten. Um dieses Verfahren zu nutzen initialisiert der
Nutzer dieses. Dazu wird er in diesem Anwendungsbeispiel aufgefordert,
den Gerätetyp
(z.B. Siemens M55, Nokia 6600, o.ä.), die Mobilfunknummer und
gegebenenfalls die Hardwarekennung seines mobilen Endgerätes (z.B.
den International Mobile Equipment Identifier (IMEI), oder eine
beliebige andere, das mobile Endgerät individuell kennzeichnende
Kennung („Hardware-Kennung") anzugeben. Die Richtigkeit
dieser Angaben bestätigt
und signiert er mittels einer herkömmlichen TAN (die TAN-Autorisierung steht
hier beispielhaft für
bereits eingeführte Verfahren;
chipkartenbasierte Verfahren, sowie Mechanismen mit einer Super-PIN,
etc. sind ebenfalls vorstellbar). Durch die Eingabe der o.g. Werte
identifiziert sich der Nutzer gegenüber der Anwendung.
-
Um
das MTG-Verfahren einsetzen zu können,
erweitert der Nutzer die Software eines in 1 gezeigten,
weiteren, mobilen Endgeräts 1,
z. B. eines Mobiltelefons oder Organizers oder auch eines Laptops.
Die Software – hier
z. B.: eine spezielle Java-Anwendung (J2ME MIDlet) – wird z.
B. vom Betreiber des Datenkommunikationssystems bereitgestellt,
und kann über
z. B. eine WAP-Anwendung heruntergeladen und im JAM (Java-Application-Manager) des mobilen
Endgerätes 1 installiert
werden (Over-the-Air-Installation; OTA). Das MTG-Verfahren setzt
hier den OTA-Push-Mechanismus ein, um das MIDlet auf dem mobilen
Endgerät 1 des
Nutzers zu installieren. Neben Java kann, in einer auf die jeweilige
Sprachumgebung (z. B. .Net) angepassten Art und Weise, auch eine
andere Sprache zur Erweiterung der Software des weitern, mobilen
Endgeräts, eingesetzt
werden. Das für
Java anzuwendende Verfahren läuft
in diesem Ausführungsbeispiel
wie folgt ab:
Hat der Nutzer sich – ggf. nach Eingabe eines Passworts – am o.g.
Anwendungs-Zentralrechner
registriert, erzeugt dieser eine SMS. Die SMS wird an die eingetragene,
dem Endgerät 1 zugeordnete
Mobilfunknummer des Nutzers gesandt; und enthält enthält einen Link auf eine URL
(Internet-Adresse). Wenn der Nutzer nun mit seinem mobilen Endgerät 1 diese
URL im Internet aufruft, wird ihm das MIDlet (also die erforderliche
Software für
das Handy) in der für seinen
Gerätetyp
passenden Variante automatisch über
das Mobilfunknetz auf sein Endgerät 1, insbesondere
Mobiltelefon geladen, und mittels JAM installiert.
-
Nach
Abschluss der Installation meldet der JAM (über einen eigenen http-Request)
an den Anwendungs-Zentralrechner eine „Erfolgsmeldung". Der Anwendungs-Zentralrechner
erzeugt daraufhin für
den Nutzer entweder einen individuellen MTG-Initialwert MTGI, und
sendet diesen wiederum via SMS an das mobile Endgerät 1 des
Nutzers oder eine spezifische MTG-Benutzerkennung ("MTGB"), die auf dem Postwege
an die Adresse des Benutzers in papierform gesendet wird.
-
Diesen
MTG-Initialwert MTGI muss der Nutzer beim ersten Start des MTG-MIDlets,
vorzugsweise zusätzlich
zu einem Anwendungspasswort bzw. Freischaltcode, erfassen, d.h.,
wie in 1 gezeigt, über
die o.g. Java-Anwendung in das Endgerät 1 eingeben. Er wird
nun im Datenspeicher der Java-Anwendung auf dem Endgerät 1 des
Endkunden (RMS) verschlüsselt
gespeichert und korrespondiert ab sofort mit dem im o.g. Anwendungs-Zentralrechner gespeicherten
Wert. Ab diesem Zeitpunkt kennen das Endgerät 1 des Nutzers und
die Zentralrechner-Anwendung die IMEI des Nutzers und den Initialwert; sie
besitzen also ein gemeinsames „Geheimnis".
-
Wird
eine MTG-Benutzerkennung MTGB an den Kunden gesendet, erfasst der
Kunde nach Erhalt die MTGB in der Java-Anwendung auf dem Endgerät 1.
Die MTGB ersetzt in diesem Fall die Funktion der IMEI. Der Versand
und die Eingabe eines MTGI bleibt davon unberührt.
-
Damit
ist die Einrichtung und Initialisierung des MTG abgeschlossen; es
kann nun zur Signierung von Transaktionen verwendet werden.
-
Der
MTG-Initialwert MTGI bildet ab jetzt die Grundlage zur späteren Bildung
eines Signaturzählers
(Application Transaction Counter – ATC) und dient außerdem zur
Re-Synchronisation
zwischen dem MTG-MIDlet und der Zentralrechner-Anwendung. Alternativ
ist auch die Verwendung eines Zufallswertes als variabler Faktor
anstatt MTGI möglich.
-
1.2 Initialisierung eines
neuen, bisher nicht registrierten Anwenders
-
Neu-Nutzer,
die noch nicht über
eine PIN/TAN-Liste oder ein Chipkartenverfahren verfügen, erhalten
beim Vertragsabschluß mit
dem Betreiber des Datenkommunikationssystems eine PIN und eine Super-PIN
ausgehändigt.
Die PIN dient wie in den bestehenden Verfahren zur Identifikation
des Nutzers für
sein Konto; die Super-PIN
ersetzt die im oben beschriebenen Verfahren eingesetzte erste TAN,
mit der die Anwendung intiialisiert wird.
-
Datenkommunikationssystem-Betreiber,
die beide Verfahren dauerhaft parallel betreiben wollen, können auch
Neu-Nutzer regelmäßig mit
PIN und TAN ausstatten.
-
Sobald
ein Nutzer über
PIN und Super-PIN oder PIN und TAN verfügt, kann er sich, wie zuvor
beschrieben, bei der MTG-Anwendung registrieren und sie so ohne
weitere Unterstützung
durch den Datenkommunikationssystem-Betreiber einsetzen.
-
1.3 Nutzung der Internet-Bankanwendung
-
Sobald
der Nutzer sich für
die Anwendung freigeschaltet hat und das MTG-MIDlet installiert
wurde, kann er diese nutzen, um einzelne Aufträge zu signieren.
-
Beispiel Überweisung:
-
Der
Nutzer meldet sich bei der Anwendung, insbesondere dem o.g. Zentralrechner
des Datenkommunikationssystem-Betreibers an (siehe Punkt 1.1, oben),
und erfasst daraufhin im Kontext der E-Banking-Anwendung eine Überweisung
im Internet-Browser auf seinem Rechner 2, und sendet die Daten
an den o.g. Zentralrechner.
-
Bildung der Auftragsquersumme:
-
Der
Zentralrechner überprüft die Richtigkeit der
eingegeben Auftragsdaten hinsichtlich der banküblichen Plausibilitäten (Limit,
Bankleitzahl, Kontonummer, usw.) und fordert gegebenenfalls zur
Korrektur auf. Sobald die eigentlichen Auftragsdaten fachlich fehlerfrei
sind, bildet die Zentralrechner-Anwendung aus den Auftragsdaten
und der Session-Kennung – vorzugsweise
inklusive eines Zeitstempels – die
der Webserver bzw. Zentralrechner dem Nutzer zuordnet, eine Quersumme
(zum Beispiel einen MD5 Hash-Wert). Dies ist die Auftragsquersumme
Q.
-
Erzeugung einer Zentralrechner-Signatur:
-
Die
Zentralrechner-Signatur SigZ wird errechnet aus der gespeicherten
Hardwarekennung des Nutzers (IMEI) oder der MTG-Benutzerkennnung MTGB
und dem kundenspezifischen Signaturzähler ATC oder einem Zufallswert.
-
Die
Hardware-Kennung oder MTGB des Nutzers (hier: IMEI) ist dem Zentralrechner
seit der Registrierung des Nutzers bekannt. Für den ATC (Application Transaction
Counter) – Signaturzähler wird
auf Basis der IMEI oder MTGB nach einem festgelegten Algorithmus
eine Prüfziffer
errechnet. Um den Wert dieser Prüfziffer
wird der Signaturzähler
ATC nunmehr pro Signiervorgang erhöht. Anfangsbasis für die Erhöhung ist
der ursprüngliche
MTG-Initialwert MTGI des Nutzers.
-
Hardware-Kennung
oder MTGB und Signaturzähler
ATC werden miteinander verknüpft.
Daraufhin wird über
diesen Wert ein Hash-Wert gebildet, der als Zentralrechner-Signatur
SigZ dient.
-
Auftragsbestätigungsseite
mit Auftrags-Signatur anzeigen
-
Auftragsquersumme
Q und Zentralrechner-Signatur SigZ werden dem Nutzer auf einer Auftragsbestätigungsseite
angezeigt. Beide Werte zusammen ergeben z. B. eine zehnstellige
Ziffernfolge, die so genannte Auftragssignatur bzw. Auftragssignatur-Kennung
SigA. Wie aus 2 hervorgeht, ist dabei für den Anwender
nicht erkennbar, welche Bedeutung die einzelnen Elemente dieser
Ziffernfolge haben und wie diese miteinander verknüpft wurden.
-
Ablesen und Eingeben der
Auftragssignatur SigA in der Java Anwendung auf dem Endgerät des Nutzers:
-
Der
Nutzer startet auf seinem mobilen Endgerät 1 das MTG-MIDlet
und wird dort, wie in 3 gezeigt ist, zur Eingabe der
Auftrags-Signatur aufgefordert. Er schließt die Eingabe mit der Betätigung des
Buttons „MTan-Erzeugen" ab.
-
Prüfung der Zentralrechner-Signatur
durch das MTG-MIDlet:
-
Das
MTG-MIDet prüft
nun, ob die eingegebene Zentralrechner-Signatur SigZ authentisch
ist. Hierzu extrahiert das Programm die Zentralrechner-Signatur
SigZ aus der eingegebenen Auftragssignatur-Kennung SigA. Daraufhin
nutzt das MIDlet dieselbe Logik, die der Zentralrechner zur Erzeugung seiner
Signatur angewendet hat, um ebenfalls eine Zentralrechner-Signatur
SigZ2 herzuleiten und vergleicht die beiden Datenelemente SigZ,
SigZ2 miteinander:
Das Programm liest aus seinem Datenbestand
den letzten Signaturzähler
ATC (bei der ersten Anwendung ist dieser „NULL" und wird daher durch den MTG-Initialwert
MTGI ersetzt. Das MIDlet liest im nächsten Schritt seine eigene
Hardware-Kennung (z. B. über
den Befehl System.getProperty(„phone.IMEI")) oder die MTG-Benutzerkennung
MTGB aus den RMS aus. Aus der gelesenen Hareware-Kennung oder der
MTGB wird der Wert zur Erhöhung
des ATC wiederum abgeleitet. Der letzte Signaturzähler ATC
wird um den Erhöhungswert
erhöht. Mit
diesem neu erzeugten Signaturzähler
ATC und der Hardware-Kennung wird der Schlüssel gebildet, der wiederum
Grundlage zur Errechnung eines Hash-Wertes ist. Die durch das MIDlet
erzeugte Zentralrechner-Signatur SigZ2 wird nun mit der eingegebenen Zentralrechner-Signatur
SigZ verglichen. Stimmen beide Werte überein, speichert das Programm
den neuen ATC-Wert in seinem Datenspeicher.
-
Sollte
die Prüfung
nicht erfolgreich sein, wird das MIDlet den Signaturzähler ATC
in einer Schleife z.B. dreimal (oder mehr oder weniger häufig) um
den Erhöhungswert
verringern und jeweils mit dem so erzeugten Signaturzähler ATC
prüfen,
ob die Signaturen übereinstimmen.
Bei einer Übereinstimmung
wird der gefundene Signaturzähler
ATC im Datenspeicher abgelegt.
-
Dieses
Verfahren ist vorteilhaft, da es möglich ist, dass der Nutzer
zwar eine MTan erfolgreich erzeugt hat, daraufhin aber die Auftragsbestätigung am
Zentralrechner abbricht. In diesem Fall hat das MTG-MIDlet den Signaturzähler ATC
bereits erhöht und
gespeichert, während
auf dem Zentralrechner der Signaturzähler ATC noch nicht abgelegt
wurde (Speicherung auf dem Zentralrechner erfolgt erst nach geprüfter MTan-Eingabe).
In diesem Fall sind die ATC-Werte zwangsläufig nicht mehr synchron. Durch
die schrittweise Reduzierung des Signaturzählers ATC im Endgerät 1 wird
dem Zentralrechner eine Resynchronisierung angeboten.
-
Sperren und Entsperren
des MTG-MIDlets (Erneutes Setzen des MTG-Initialwertes)
-
Durch
die beschriebene Prüfung
kann das MTG-MIDlet ermitteln, ob es sich bei der eingegebenen Auftragssignatur-Kennung
SigA um eine authentische Signatur der Zentralrechner-Anwendung
handelt. Nach dreimaliger Falscheingabe einer Auftrags-Signatur
muss davon ausgegangen werden, dass es sich nicht mehr um eine versehentliches „Ent"-Synchronisierung handelt, sondern dass
jemand versucht, das MTG missbräuchlich
einzusetzen. In diesem Fall wird das MTG-MIDlet automatisch gesperrt
und kann nur durch erneutes Setzen des MTG-Initialwertes durch den
Nutzer wieder entsperrt werden.
-
Zum
Entsperren muss der Nutzer den MTG-Initialwert MTGI in der Zentralrechner-Anwendung erneut
anfordern (Bestätigung
mit TAN oder Super-PIN). Der Initialwert MTGI wird dem Nutzer erneut
per SMS zugesandt. Server und MIDlet beginnen wieder gemeinsam mit
dem Zählerstand
NULL.
-
Erzeugen einer
MTan aus der Auftragsquersumme
-
Wurde
die Zentralrechner-Signatur SigZ als korrekt erkannt, erzeugt das
MTG-MIDlet im nächsten
Schritt seinerseits eine Signatur (MTan) über die eingegebene Auftragsquersumme
Q (diese wird aus der Auftrags-Signatur SigA extrahiert). Hierzu
nutzt das Programm den bereits bei der Prüfung der Zentralrechner-Signatur
SigZ ermittelten ATC-Wert. Die Auftragsquersumme Q wird mittels
Signaturzählers ATC
und Hardware-Kennung oder MTG-Benutzerkennung signiert und die erzeugte
MTan wird – wie
in 4 gezeigt ist – auf dem Bildschirm des Endgeräts 1 angezeigt.
-
Eingabe der
MTan durch den Nutzer in der Auftragsbestätigungsseite am Zentralrechner
-
Der
Nutzer liest die MTan vom Bildschirm seines mobilen Endgerätes 1 ab
und gibt sie – wie
in 5 gezeigt ist – in der Auftragsbestätigungsseite der
E-Banking-Anwendung im dafür
vorgesehenen Eingabefeld, gegebenenfalls unter Verwendung eines
Präfix,
ein. Dieser Vorgang entspricht der herkömmlichen TAN-Eingabe. Optional
kann eine Quittung über
Aufträge
direkt an das mobile Endgerät,
z. B. das Mobiltelefon, versandt werden, vorzugsweise als SMS oder
MMS oder ähnlichem.
-
Prüfung der
MTan durch den Zentralrechner
-
Die
Zentralrechneranwendung nimmt die TAN entgegen und prüft sie.
Hierzu errechnet der Zentralrechner mithilfe des aktuellen ATC (welcher mit
dem ATC des MTG synchron sein muss) und unter Verwendung der Hardwarekennung
(IMEI) oder MTG-Benutzerkennung MTGB des Nutzers (die ihm bei der
Anmeldung bekannt gemacht wurde) die nächste gültige MTan aus der Auftragsquersumme
Q und vergleicht sie mit dem Eingabewert.
-
Stimmen
die Werte überein,
akzeptiert der Server bzw. Zentralrechner die Eingabe und speichert
die Zählerwerte
seinerseits. Danach wird der zugehörige Auftrag zur Verarbeitung
freigegeben.
-
Stellt
der Zentralrechner jedoch eine Abweichung fest, fordert er den Nutzer
erneut zur Eingabe auf, da ein Eingabefehler vorliegen muss. Kommt
es hier dreimal hintereinander zu einer Fehleingabe, so wird der
zugehörige
Nutzer gegenüber
der E-Banking-Anwendung gesperrt. Eine Entsperrung kann nun nur
noch dadurch erfolgen, dass der Nutzer seine Benutzerkennung, seine
PIN und eine gültige
Tan (aus dem konventionellen Bestand) oder eine Super-PIN eingibt.