DE60029379T2 - Verfahren und Gerät, die einem Rechnerbenutzer erlauben, vor der Eingabe von privilegierten Informationen ein System zu authentifizieren - Google Patents

Verfahren und Gerät, die einem Rechnerbenutzer erlauben, vor der Eingabe von privilegierten Informationen ein System zu authentifizieren Download PDF

Info

Publication number
DE60029379T2
DE60029379T2 DE60029379T DE60029379T DE60029379T2 DE 60029379 T2 DE60029379 T2 DE 60029379T2 DE 60029379 T DE60029379 T DE 60029379T DE 60029379 T DE60029379 T DE 60029379T DE 60029379 T2 DE60029379 T2 DE 60029379T2
Authority
DE
Germany
Prior art keywords
host
user
authentic
client
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60029379T
Other languages
English (en)
Other versions
DE60029379D1 (de
Inventor
Charles Sunnyvale Merriam
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Application granted granted Critical
Publication of DE60029379D1 publication Critical patent/DE60029379D1/de
Publication of DE60029379T2 publication Critical patent/DE60029379T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Description

  • Hintergrund
  • Die Erfindung bezieht sich allgemein auf gesicherte Systeme, und insbesondere auf ein Verfahren und eine Vorrichtung, um einem Benutzer zu ermöglichen, ein System zu authentisieren, bevor er dem System irgendwelche benutzerprivilegierten Informationen zur Verfügung stellt.
  • In jedem gesicherten System ist eines der Probleme, das vom größten Interesse ist, das der Parteiauthentisierung. Das heißt, wie können die Parteien wissen, dass die andere Partei derjenige oder dasjenige ist, was sie zu sein beansprucht? Durch die starke Zunahme des elektronischen Handels in den letzten Jahren wurde das Problem an die vorderste Front gebracht. In Reaktion auf dieses Problem wurden unzählige mögliche Lösungen entwickelt.
  • Eine mögliche Lösung umfasst die Verwendung einer persönlichen Identifikationsnummer (PIN). In einem einfachen PIN-basierten System liefert der Benutzer immer dann, wenn er eine Transaktion mit einem Host-System, wie z. B. einem Geldautomaten (ATM, Automatic Teller Machine) durchführt, dem Host-System ein bestimmtes physikalisches Zeichen (Token), wie z. B. eine ATM-Karte, die den Benutzer für den Host identifiziert. Dieses Zeichen enthält typischerweise einige spezifische Informationen den Benutzer betreffend, wie z. B. dem Namen des Benutzers, die Kontonummer des Benutzers, den Typ des Kontos und dergleichen. Zusätzlich zum Zeichen liefert der Benutzer ferner dem Host (in Reaktion auf eine Aufforderung) eine geheime PIN, die vorher zwischen dem Benutzer und der den Host kontrollie renden Einrichtung (wie z. B. einer Bank) vereinbart worden ist. Auf der Grundlage der auf dem Zeichen gespeicherten Informationen und der vom Benutzer bereitgestellten PIN bestimmt der Host, ob er mit einem autorisierten Benutzer umgeht. Vermutlich werden nur der Benutzer oder vom Benutzer autorisierte Leute Kenntnis von der PIN haben, so dass dann, wenn die richtige PIN dem Host zur Verfügung gestellt wird, der Host begründet überzeugt ist, dass er mit einem ordnungsgemäßen Benutzer umgeht. Auf diese Weise authentisiert der Host den Benutzer.
  • Eine alternative und höherentwickelte Lösung umfasst die Verwendung eines aktiven Zeichens. Ein aktives Zeichen, hier auch als Client bezeichnet, unterscheidet sich von dem obenerwähnten Zeichen dadurch, dass es eine eigene Verarbeitungsfähigkeit aufweist. Da der Client seine eigene Verarbeitungsfähigkeit aufweist, kann er mit dem Host in einer höherentwickelten Weise umgehen, die dem System eine zusätzliche Sicherheitsschicht hinzufügt. Im vorliegenden Zusammenhang kann ein Client irgendetwas sein, das eine Verarbeitungsfähigkeit aufweist, einschließlich, jedoch nicht hierauf beschränkt, einer Chipkarte und eines Personalcomputers.
  • In einem Client-Host-System findet eine typische Transaktion in folgender Weise statt. Zuerst leitet der Benutzer eine Interaktion zwischen dem Client und dem Host ein. Dies kann z. B. durch Einführen einer Chipkarte in ein Host-System geschehen. Anschließend ist es Sache des Clients und des Hosts, einander zu authentisieren. Dies wird typischerweise mittels eines Zweiwege-Aufforderung-Antwort-Protokolls erreicht, wobei der Client eine Aufforderung zum Host sendet und eine Antwort empfängt, und der Host eine Aufforderung zum Client sendet und eine Antwort empfängt. Die weitere Interaktion zwischen dem zwei Komponenten findet nur dann statt, wenn beide Einheiten angemessene Antworten auf ihre jeweiligen Aufforderungen empfangen, um somit einander zu authentisieren. Anschließend authentisiert der Host den Benutzer durch Fragen des Benutzers nach einer PIN. Nur wenn die vom Benutzer eingegebene PIN richtig ist, wird der Host die Durchführung einer Transaktion erlauben. Auf diese Weise werden alle Parteien, die an der Transaktion beteiligt sind (Host, aktives Zeichen und Benutzer), authentisiert.
  • Zusätzlich zu den eben beschriebenen Authentisierungsschemen sind derzeit andere Schemen bekannt und verfügbar, die die grundsätzlichen Authentisierungsfähigkeiten modifizieren/verbessern. Für die meisten ist ein Großteil dieser Schemen in der gleichen Art wie die obenbeschriebenen Schemen.
  • Eine Beobachtung, die bezüglich der derzeit verfügbaren Lösungen gemacht werden kann, ist, dass sie hauptsächlich auf zwei spezifischen Aspekten des Authentisierungsproblems konzentriert sind: (1) dem Host-System ermöglichen, den Benutzer zu authentisieren; und (2) dem Client und dem Host ermöglichen, einander zu authentisieren. Auf diesen Gebieten sind die aktuellen Lösungen für den größten Teil angemessen. Ein Aspekt jedoch, der von allen aktuell verfügbaren Lösungen schmerzhaft vermisst wird, ist die Möglichkeit für den Benutzer, das Host-System zu authentisieren. Bei den obigen Schemen ist zu beachten, dass der Benutzer seine PIN in Reaktion auf eine Aufforderung vom Host eingibt. Zu dem Zeitpunkt, zu dem der Benutzer die PIN eingibt, hat der Benutzer keine Gewissheit, dass der Host authentisch ist. Im Grunde weis der Benutzer, er könnte seine PIN in einen betrügerischen Host eingeben. Derzeit muss der Benutzer annehmen oder darauf vertrauen, dass der Host ein authentischer Host ist. Unglücklicherweise ist dieses Vertrauen manchmal fehl am Platz, was den Benutzer veranlasst, seine PIN in einen betrügerischen Host einzugeben, wodurch ermöglicht wird, dass die PIN gestohlen wird.
  • Eine Anordnung, die verwendet worden ist, um eine PIN von einem Benutzer zu stehlen, ist die Folgende. Ein Täter baut einen gefälschten Host und platziert diesen an einem ähnlichen Ort, wie z. B. nahe einer Bank oder eines Lebensmittelladens. Der gefälschte Host erscheint und agiert in allen oberflächlichen Belangen ähnlich einem authentischen Host. Wenn ein Benutzer sein Zeichen (entweder aktiv oder inaktiv) in den gefälschten Host einführt, führt der Host eine von zwei Aktionen aus: (1) wenn möglich, liest er das Zeichen, um daraus die Identifikationsinformationen bezüglich des Benutzers zu extrahieren; oder (2) er nimmt einfach das Zeichen entgegen. Anschließend fragt der gefälschte Host den Benutzer nach seiner PIN. Sobald der Benutzer seine PIN eingibt, hat der gefälschte Host seine Aufgabe erfüllt, die darin besteht, die PIN des Benutzers zu stehlen. Ein wichtiger Punkt, der hierbei zu beachten ist, ist, dass der Zweck des gefälschten Host darin besteht, die PIN zu stehlen, und nicht sofort eine Transaktion durchzuführen. Da der Host nicht versucht, eine Transaktion auszuführen, muss er letztendlich nicht mit dem Zeichen interagieren. Als Ergebnis bleibt die Host-Authentisierungsfähigkeit, die aktive Zeichen bieten, nutzlos. Die obige Anordnung kann verwendet werden, um PINs sowohl in PIN-basierten Systemen als auch in Client-Host-Systemen zu stehlen.
  • Sobald die PIN gestohlen worden ist, können verschiedene Szenarien entstehen. Erstens, der gefälschte Host kann das Zeichen einfach einbehalten. Zu einem bestimmten späteren Zeitpunkt kann der Täter das Zeichen aus dem gefälschten Host gewinnen und dieses zusammen mit der PIN verwenden, um eine Vielfalt von Transaktionen auf Kosten des Benutzers durchzuführen. Alternativ kann der gefälschte Host dann, wenn er fähig ist, Benutzeridentifikationsinformationen aus dem Zeichen zu extrahieren, das Zeichen dem Benutzer mit der Nachricht zurückgeben, dass eine Transaktion zu diesem Zeitpunkt nicht durchgeführt werden kann. Ausgerüstet mit der Identifikationsinformation und der PIN kann der Täter immer noch eine breite Vielfalt von Transaktionen durchführen, selbst bei Abwesenheit des physikalischen Zeichens. Der Vorteil für den Täter, dem Benutzer das Zeichen zurückzugeben, besteht darin, dass der Benutzer sehr wahrscheinlich nicht einmal den Verdacht hat, dass seine PIN gestohlen worden ist. Wenn dies zutrifft, hat der Täter eine sehr lange Zeitspanne zur Verfügung (wahrscheinlich bis zum nächsten Kontoauszug des Benutzers, während der er betrügerische Transaktionen durchführen kann. Als eine weitere Möglichkeit kann der Benutzer, sobald die PIN nachgeprüft worden ist, überfallen und seines physikalischen Zeichens beraubt werden. In jedem dieser Szenarien erleidet der Benutzer einen bestimmten Schaden. Im günstigsten Fall ist es ein bestimmtes Maß an Unbequemlichkeit. Im ungünstigsten Fall kann es ein signifikanter finanzieller und/oder physikalischer Schaden sein.
  • Wie die obige Diskussion zeigt, kann die Unfähigkeit eines Benutzers, ein Host-System zu authentisieren, zu großen Fallgruben für den Benutzer führen. Die derzeitigen Authentisierungsschemen bieten keine angemessene Lösung für dieses Problem.
  • Das Dokument WO 99/12308 offenbart ein System für die Durchführung geregelter Transaktionen mit einem Netzwerk, das für eine Vielzahl von Kommunikationsendgeräten allgemein zugänglich ist.
  • Überblick über die Erfindung
  • Es wird ein Verfahren geschaffen, dass mittels eines Clients implementiert wird, um einen Benutzer zu ermöglichen, einen Host zu authentisieren, wie in Anspruch 1 ausgeführt ist, sowie ein Client für die Interaktion mit einem Host, wie in Anspruch 4 ausgeführt ist. Ferner werden ein Verfahren, dass mittels eines Hosts implementiert wird, um einem Benutzer zu ermöglichen, einen Host zu authentisieren, wie in Anspruch 6 ausgeführt ist, sowie ein Host geschaffen, der einem Benutzer ermöglicht, den Host zu authentisieren, wie in Anspruch 8 ausgeführt ist.
  • Um die Nachteile des Standes der Technik zu beseitigen, schafft die vorliegende Erfindung eine Einrichtung, die einem Benutzer ermöglicht, ein System zu authentisieren. Diese Authentisierung wird durchgeführt, bevor der Benutzer irgendwelche benutzerprivilegierten Informationen in das System eingibt, so dass ein Diebstahl benutzerprivilegierter Informationen durch ein betrügerisches System verhindert wird. Der Ausdruck benutzerprivilegierte Informationen, wie er hier verwendet wird, bezieht sich allgemein auf irgendwelche Informationen, die von einem System verwendet werden, um einen Benutzer zu authentisieren, einschließlich, jedoch nicht hierauf beschränkt, einer PIN oder eines Verschlüsselungsschlüssels.
  • Die vorliegende Erfindung kann in irgendeinem Typ von System implementiert sein, einschließlich eines host-basierten Systems und eines Client-Host-Systems. In einem host-basierten System leitet der Benutzer eine Interaktion mit einem Host ein durch Bereitstellen bestimmter Benutzeridentifikationsinformationen für den Host. Diese Informationen können den Namen des Benutzers, eine Kontonummer und dergleichen enthalten, enthalten jedoch keine benutzerprivilegierten Informationen. In Reaktion hierauf verwendet der Host die Benutzeridentifikationsinformationen, um eine eindeutige Nachricht wiederzugewinnen, die dem Benutzer zugeordnet ist. In einer Ausführungsform ist diese eindeutige Nachricht eine geheime Nachricht, die vorher zwischen dem Benutzer und dem Host vereinbart worden ist. Die Nachricht kann eine Textnachricht, ein Geräusch, eine graphische Anzeige oder irgendetwas sein, das unverwechselbar ist. Sobald die eindeutige Nachricht beschafft worden ist, wird sie vom Host zusammen mit einer Aufforderung für bestimmte benutzerprivilegierte Informationen zum Benutzer gesendet.
  • Nur wenn die vom Host gesendete Nachricht die gleiche ist wie diejenige, die vom Benutzer erwartet wird, wird der Benutzer die geforderten benutzerprivilegierten Informationen bereitstellen. Vermutlich wird nur ein authentischer Host die eindeutige Nachricht kennen oder darauf Zugriff haben; somit sind gefälschte Host-Systeme nicht fähig, die richtige Nachricht zu senden. Wenn die richtige Nachricht nicht zum Benutzer gesendet wird, liefert der Benutzer nicht die benutzerprivilegierten Informationen an den Host. Auf diese Weise wird einem Benutzer ermöglicht, einen Host zu authentisieren, um somit einen Diebstahl benutzerprivilegierter Informationen durch einen betrügerischen Host zu verhindern.
  • Mit einer bestimmten Modifikation kann dieses gleiche Ergebnis in einem Client-Host-System erreicht werden. Genauer, wenn ein Benutzer eine Interaktion zwischen einem Client und einem Host einleitet, führt der Client eine Authentisierungsprüfung für den Host durch. Diese Authentisierungsprüfung kann unter Verwendung irgendeiner bekannten Authentisierungstechnik durchgeführt werden, einschließlich, jedoch nicht hierauf beschränkt, eines Aufforderung/Antwort-Protokolls. Wenn der Client feststellt, dass der Host ein authentischer Host ist, sendet der Client eine eindeutige Nachricht, die dem Benutzer signalisiert, dass der Host authentisch ist. In einer Ausführungsform wird die Nachricht auf dem Client gespeichert und ist eine geheime Nachricht, die im voraus zwischen dem Benutzer und dem Client vereinbart worden ist. Die eindeutige Nachricht kann eine Textnachricht, ein Geräusch, eine graphische Anzeige oder irgendeine Information sein, die unverwechselbar ist. Es ist zu beachten, dass in einem Client-Host-System der Client die eindeutige Nachricht sendet. Wenn ein Benutzer die eindeutige Nachricht empfängt, kann der Benutzer sicher sein, dass: (1) der Client mit dem Host interagiert hat; und (2) der Host ein authentischer Host ist. Wenn somit der Host anschließend den Benutzer nach bestimmten benutzerprivilegierten Informationen fragt, kann der Benutzer sicher sein, dass der Host ein authentischer Host ist und dass die benutzerprivilegierten Informationen sicher eingegeben werden können. Auf diese Weise ermöglicht die vorliegende Erfindung einem Benutzer, einen Host zu authentisieren, um somit einen betrügerischen Host daran zu hindern, benutzerprivilegierte Informationen von einem Benutzer zu erhalten.
  • Kurzbeschreibung der Zeichnungen
  • 1 ist ein Blockdiagramm eines Client-Host-Systems, in dem die vorliegende Erfindung implementiert sein kann.
  • 2 ist ein Flussdiagramm, das die Client-Host-Methodik der vorliegenden Erfindung zeigt.
  • 3 ist ein Blockdiagramm eines host-basierten Systems, in dem die vorliegende Erfindung implementiert sein kann.
  • 4 ist ein Flussdiagramm, das die host-basierte Methodik der vorliegenden Erfindung zeigt.
  • 5 ist ein Blockdiagramm eines allgemeinen Systems, in dem die vorliegende Erfindung implementiert sein kann.
  • Genaue Beschreibung der Ausführungsform(en)
  • In 1 ist ein System 100 gezeigt, in welchem die vorliegende Erfindung implementiert sein kann, wobei das System 100 einen Host 112 und einen Client 110 für die Interaktion mit dem Host 112 umfasst. Der Ausdruck Client bezieht sich hier allgemein auf irgendein System, eine Vorrichtung oder eine Maschine, die ihre eigene logische Verarbeitungsfähigkeit hat. Im System der 1 ist die allgemeine Voraussetzung, das nicht bekannt ist, ob der Host 112 ein authentischer Host ist. Wenn der Host 112 ein gefälschter Host ist, kann er irgendeine einer Anzahl von verschiedenen Konfigurationen annehmen. Da die Konfigurationen des Hosts 112 nicht vorhergesagt werden können, und da es für den größten Teil irrelevant ist, ist der Host 112 in 1 einfach als leerer Kasten dargestellt.
  • Im System 100 ist es der Client 110, der hauptsächlich für die Ausführung des Verfahrens der vorliegenden Erfindung verantwortlich ist. Der Client 110 umfasst einen Hauptbus 120 und mehrere Komponenten, die mit dem Hauptbus 120 verbunden sind, einschließlich eines Prozessors 122 und eines Speichers 124. Der Speicher 124, der die Form irgendeines Speichermediums annehmen kann, einschließlich, jedoch nicht hierauf beschränkt, magnetischer Medien, optischer Medien und nicht flüchtigen Speichers, hat einen Satz von Authentisierungsanweisungen 132, einen oder mehrere Sätze von Daten 134 und eine oder mehrere eindeutige Nachrichten 136 gespeichert. Die Authentisierungsanweisungen 132 werden vom Prozessor 122 ausgeführt, um das Authentisierungsverfahren der vorliegenden Erfindung auszuführen. Die Daten 134, die solche Informationen wie Verschlüsselungsschlüssel und dergleichen enthalten können, werden vom Prozessor 122 im Verlauf der Ausführung der Authentisierungsanweisungen 132 verwendet, wobei die eindeutigen Nachrichten 136, wie im Folgenden beschrieben wird, vom Prozessor 122 verwendet werden, um dem Benutzer anzuzeigen, dass der Client 110 mit dem Host 112 interagiert hat, und dass der Host ein authentischer Host ist. In einer Ausführungsform sind die eindeutigen Nachrichten geheime Nachrichten, die dem Client 110 vom Benutzer zur Verfügung gestellt werden, bevor der Client 110 mit dem Host 112 interagiert. Die eindeutigen Nachrichten 136 können irgendeine Form annehmen, einschließlich, jedoch nicht hierauf beschränkt, einer Textnachricht, einer Audionachricht oder eines Geräusches, oder einer graphischen Anzeige einer bestimmten Art. Zum Beispiel kann die Nachricht eine spezielle Textphrase ("Wie geht es den Kindern?") sein, ein Abschnitt eines Lieblingsliedes des Benutzers, ein spezielles Symbol oder ein Bild mit einer bestimmten Bedeutung für den Benutzer. Für die Zwecke der vorliegenden Erfindung können irgendwelche Informationen, die für den Benutzer unverwechselbar sind, und die normalerweise von einem betrügerischen Host nicht gekannt oder erraten werden können, als eindeutige Nachrichten verwendet werden.
  • Der Client umfasst ferner einen Arbeitsspeicher 125 und einen Schnittstellenanschluss 126, die beide mit dem Hauptbus 120 verbunden sind. Der Arbeitsspeicher 125 wird vom Prozessor 122 verwendet, um die Befehlsaus führung und die Datenmanipulation zu erleichtern, während der Schnittstellenanschluss 126 vom Prozessor 122 verwendet wird, um mit dem Host 112 zu kommunizieren. In der gezeigten Ausführungsform nimmt der Client 110 die Form einer mit Software betriebenen Vorrichtung an; d. h., der Client 110 leitet seine Funktionalität vom Prozessor 122 ab, der einen Satz an Software- oder Programmanweisungen 132 ausführt. Obwohl dies eine vorteilhafte Ausführungsform ist, ist zu beachten, dass, falls gewünscht, die Funktionalität der vorliegenden Erfindung unter Verwendung von Hardwarelogikkomponenten erreicht werden kann. Diese Modifikation fällt in den Umfang der vorliegenden Erfindung.
  • Der Client 110 kann optional ferner ein oder mehrere Ausgabevorrichtungen 128 umfassen, die mit dem Hauptbus 120 gekoppelt sind, sowie ein oder mehrere Benutzereingabevorrichtungen 130, die mit dem Hauptbus 120 gekoppelt sind. Die Ausgabevorrichtungen 128 können irgendeine Anzahl von Vorrichtungen enthalten, die dafür ausgelegt sind, Informationen zum Benutzer zu befördern, einschließlich, jedoch nicht hierauf beschränkt, einer visuellen Anzeige, eines Audiosystems (z. B. Klangkarte und Lautsprecher) und eines Druckers. Die Eingabevorrichtungen 130 können irgendeine Anzahl von Vorrichtungen enthalten, die dafür ausgelegt sind, einem Benutzer zu ermöglichen, eine Eingabe für den Client 110 bereitzustellen, einschließlich, jedoch nicht hierauf beschränkt, einer Tastatur, einer Maus, eines elektronischen Stifts und einer Tafel, und eines berührungsempfindlichen Bildschirms. Ob diese Vorrichtungen 128, 130 als Teil des Clients 110 enthalten sind, hängt von der besonderen Client-Host-Anordnung ab. Genauer, wenn der Host 112 ein Verkaufsstellen-Endgerät (POS-Endgerät) oder eine Lesevorrichtung ist und der Client eine Chipkarte ist, dann wäre es der Host 120, der die Eingabe- und Ausgabevorrichtung aufweisen würde. Wenn andererseits der Client 110 ein Personalcomputer ist und der Host 112 ein mit dem Client 110 über eine Kommunikationsleitung gekoppelter Server ist (wobei in diesem Fall der Schnittstellenanschluss 126 ein Modem wäre), dann würde der Client 110 wahrscheinlich die Eingabe- und Ausgabevorrichtungen 130, 128 enthalten. Dies sind nur zwei mögliche Client-Host-Konfigurationen. Andere Anordnungen können ebenfalls innerhalb des Umfangs der vorliegenden Erfindung implementiert werden.
  • Im Folgenden wird mit Bezug auf das Flussdiagramm, das in 2 gezeigt ist, und das Systemdiagramm der 1 die Methodik der vorliegenden Erfindung beschrieben. Ein Benutzer beginnt eine Transaktion durch Einleiten (204) einer Interaktion zwischen dem Client 110 und dem Host 120. In einem Chipkarten-POS-Endgerät-Typ einer Anordnung wird dies bewerkstelligt, indem einfach die Chipkarte in das POS-Endgerät eingeführt wird. In einer Client-Server-Anordnung wird dies bewerkstelligt durch Einrichten einer Verbindung zwischen dem Personalcomputer und dem Server unter Verwendung eines Modems 126. Sobald die Interaktion eingeleitet ist, führt der Prozessor 122 die Authentisierungsanweisungen 132 aus, die im Speicher 124 gespeichert sind, um die Methodik der vorliegenden Erfindung auszuführen. Unter der Steuerung der Anweisungen 132 interagiert (208) der Prozessor 122 mit dem Host 112, um zu bestimmen, ob der Host ein authentischer Host. Diese Bestimmung kann unter Verwendung irgendeiner bekannten Authentisierungsmethodik durchgeführt werden. In einer Ausführungsform wird der Schritt 208 mittels eines Aufforderung/Antwort-Protokolls unter Verwendung einer Öffentlich/Privat-Schlüssel-Verschlüsselung durchgeführt.
  • Genauer nimmt der Prozessor 122 einen Satz von Informationen (wie z. B. eine vom Prozessor 122 erzeugte Zufallszahl) und verschlüsselt diese unter Verwendung eines öffentlichen Schlüssels eines authentischen Hosts, um eine verschlüsselte Nachricht abzuleiten. In einer Ausführungsform ist dieser öffentliche Schlüssel im voraus zwischen dem Client und dem authentischen Host vereinbart worden und als Teil der Daten 134 im Speicher 124 gespeichert. Sobald die verschlüsselte Nachricht hergeleitet worden ist, wird sie über den Schnittstellenanschluss 126 als Aufforderung zum Host 112 gesendet. Der Prozessor 122 wartet anschließend auf eine Antwort.
  • In Reaktion auf die Aufforderung würde der authentische Host die Nachricht unter Verwendung eines privaten Schlüssels, der vom Client dem verwendeten öffentlichen Schlüssel zugeordnet wird, entschlüsseln. Das Ergebnis dieser Operation wäre die ursprüngliche Information (d. h. die Zufallszahl), die vom Prozessor 122 gesendet worden ist. Es ist zu beachten, dass nur ein authentischer Host diesen privaten Schlüssel haben würde; daher würde nur ein authentischer Host fähig sein, die Aufforderungsnachricht in geeigneter Weise zu entschlüsseln. Sobald die ursprüngliche Information hergeleitet worden ist, würde ein authentischer Host die Information erneut verschlüsseln, diesmal unter Verwendung eines öffentlichen Schlüssels des Clients, um eine zweite verschlüsselte Nachricht herzuleiten. Der öffentliche Schlüssel des Clients ist ein Schlüssel, der im voraus zwischen dem Client 110 und dem authentischen Host vereinbart worden ist. Sobald die zweite verschlüsselte Nachricht hergeleitet worden ist, wird sie über den Schnittstellenanschluss 126 als Antwort zum Client 110 gesendet.
  • Sobald die Antwort empfangen worden ist, testet der Prozessor 122 die Antwort durch Entschlüsseln derselben unter Verwendung eines privaten Schlüssels, der vom authentischen Host dem verwendeten öffentlichen Schlüssel des Clients zugeordnet wird. Dieser private Schlüssel ist als Teil der Daten 134 im Speicher 124 gespeichert und ist nur dem Client 110 bekannt. Wenn der Host 112 ein authentischer Host ist, ist das Ergebnis dieses Entschlüsselungsprozesses die ursprüngliche Information, die vom Prozessor 122 gesendet worden ist. Wenn das Ergebnis nicht die ursprüngliche Information ist, die vom Prozessor 122 gesendet worden ist, oder wenn keine Antwort empfangen wird, weiß der Prozessor 122, dass der Host 112 kein authentischer Host ist. Auf diese Weise bestimmt (212) der Prozessor 122 und somit der Client 110, ob der Host 112 ein authentischer Host. Wenn der Host 112 ein authentischer Host ist, wird er höchstwahrscheinlich auch versuchen, den Client 110 zu authentisieren. Diese Authentisierung kann unter Verwendung der gleichen Aufforderung/Antwort-Methodik wie oben beschrieben ausgeführt werden.
  • Wenn der Prozessor 122 feststellt, dass der Host 112 kein authentischer Host ist, stoppt (216) der Prozessor 122 alle weitere Interaktion mit dem Host 112. Wenn andererseits der Prozessor 122 feststellt, dass der Host 112 ein authentischer Host, sendet (220) der Prozessor 122 ein oder mehrere der eindeutigen Nachrichten 136, die im Speicher 124 gespeichert sind, zum Benutzer, um dem Benutzer anzuzeigen, dass: (1) der Client 110 mit dem Host 112 interagiert hat; und (2) der Client 110 festgestellt hat, dass der Host 112 ein authentischer Host ist. In der Chipkarte-POS-Konfiguration sendet der Prozessor 122 die eindeutige Nachricht zum Host 112 für die Ausgabe an den Benutzer unter Verwendung einer der Ausgabevorrichtungen des Hosts 112. In der Client-Server-Konfiguration sendet der Prozessor 122 die eindeutige Nachricht zu einer seiner eigenen Ausgabevorrichtungen 128, um die Nachricht dem Benutzer zu übermitteln.
  • Anschließend sieht der Benutzer durch (224), welche Nachricht als Ergebnis der Client-Host-Interaktion zurückgegeben worden ist. Wenn die Rückgabenachricht eine der eindeutige Nachrichten ist, die vom Benutzer erwartet werden, kann der Benutzer sicher sein, dass der Client mit dem Host 112 interagiert hat und dass der Host ein authentischer Host ist; somit kann der Benutzer sicher dem Host 112 die benutzerprivilegierten Informationen bereitstellen (236), die vom Host 112 angefordert werden. Der Ausdruck benutzerprivilegierte Information, wie er hier verwendet wird, bezieht sich allgemein auf irgendwelche Informationen, die von einem authentischen Host verwendet werden, um einen Benutzer zu authentisieren. Benutzerprivilegierte Informationen sind geheime Informationen, die nur einem authentischen Host, einem authentischen Benutzer und autorisierten Vertretern des authentischen Benutzers bekannt sind, und können irgendein Typ von Information sein, die eine PIN oder einen Verschlüsselungsschlüssel enthält, ist jedoch nicht hierauf beschränkt. Sobald die benutzerprivilegierten Informationen einem authentischen Host zur Verfügung gestellt worden sind, werden sie vom authentischen Host verwendet, um einen Benutzer zu authentisieren. Wenn der Benutzer authentisiert ist, wird anschließend erlaubt, eine Transaktion durchzuführen.
  • Wenn andererseits der Benutzer feststellt (228), dass die Rückgabenachricht keine der eindeutigen Nachrichten ist, die vom Benutzer erwartet werden, weis der Benutzer anschließend, dass entweder der Client nicht geeignet mit dem Host 112 interagiert hat, oder dass der Host kein authentischer Host ist. In jedem Fall stoppt (232) der Benutzer alle weitere Interaktion mit dem Host 112. Hierbei ist zu beachten, dass im Gegensatz zum Stand der Technik die vorliegende Erfindung nicht erlaubt, den Authentisierungsprozess zwischen dem Client 110 und dem Host 112 zu umgehen oder zu ignorieren. Wenn der Authentisierungsprozess nicht ausgeführt wird, sendet der Prozessor 122 keine der eindeutigen Nachrichten 136. Wenn der Prozessor 122 keine der eindeutigen Nachrichten sendet, besteht keine Möglichkeit für den betrügerischen Host, zu wissen, welche Nachricht zum Benutzer zu senden ist. Als Ergebnis ist der betrügerische Host nicht fähig, die richtige eindeutige Nachricht zum Benutzer zu senden. Wenn nicht die richtige Nachricht gesendet wird, wird der Benutzer dem Host keine benutzerprivilegierten Informationen zur Verfügung stellen. Auf diese Weise verhindert die vorliegende Erfindung den Diebstahl benutzerprivilegierter Informationen durch einen betrügerischen Host.
  • Als eine Verbesserung der vorliegenden Erfindung ist es möglich, die eindeutige Nachricht, die vom Prozessor 122 gesendet wird, auf dem aktuellen Wert eines oder mehrerer Parameter beruhen zu lassen. Zum Beispiel kann der Prozessor 122 bei der Bestimmung, welche eindeutige Nachricht zu senden ist, die Größe der Transaktion prüfen, die der Benutzer zu verarbeiten versucht. Wenn die Größe kleiner als 1.000 Dollar ist, kann der Prozessor 122 die eindeutige Nachricht "Lass uns eine Transaktion durchführen" senden. Wenn andererseits die Größe über 1.000 Dollar liegt, kann der Prozessor 122 die eindeutige Nachricht "Großzügiger Spender!" senden. Durch Variieren der eindeutigen Nachrichten wird eine zusätzliche Schutzschicht bereitgestellt, da selbst dann, wenn ein betrügerischer Host fähig ist, die eindeutige Nachricht für Transaktionen mit geringerer Größe wiederzugeben, Transaktionen mit größerer Größe weiterhin geschützt sind. Die Größe der Transaktion ist nur einer der möglichen Parameter, die der Prozessor 122 prüfen kann. Andere Parameter können ebenfalls innerhalb des Umfangs der vorliegenden Erfindung geprüft werden.
  • Bisher wurde die Erfindung hinsichtlich eines Client-Host-Systems beschrieben. Es ist jedoch zu beachten, dass die Erfindung auch in einem host-basierten System implementiert werden kann. Der Ausdruck host-basiertes System, wie er hier verwendet wird, bezieht sich auf irgendein System, in welchem die Authentisierungsmethodik der vorliegenden Erfindung mittels eines Hosts statt eines Clients implementiert ist. Ein Blockdiagramm eines solchen Systems ist in 3 gezeigt.
  • Wie in 5 gezeigt ist, umfasst der Host 302 eines host-basierten Systems 300 einen Hauptbus 303 und mehrere Komponenten, die mit dem Hauptbus 303 gekoppelt sind, einschließlich eines Prozessors 304, eines Arbeitsspeichers 308 und eines Speichers 306. Der Speicher 306 kann die Form irgendeines Speichermediums annehmen, einschließlich, jedoch nicht hierauf beschränkt, magnetischer Medien, optischer Medien und eines nichtflüchtigen Speichers, und hat einen Satz von Authentisierungsanweisungen 310 gespeichert. Diese Authentisierungsanweisungen 310 werden vom Prozessor 304 ausgeführt, um die Authentisierungsmethodik der vorliegenden Erfindung auszuführen. Der Arbeitsspeicher 308 wird vom Prozessor 304 verwendet, um die Befehlsausführung und die Datenmanipulation zu erleichtern. In der gezeigten Ausführungsform nimmt der Host 302 die Form mittels Software betriebenen Vorrichtung an; d. h. der Host 302 leitet seine Funktionalität aus dem Prozessor 304 her, der einen Satz von Software- oder Programmanweisungen 310 ausführt. Obwohl dies eine vorteilhafte Ausführungsform ist, ist zu beachten, dass, falls gewünscht, die Funktionalität der vorliegenden Erfindung unter Verwendung von Hardwarelogikkomponenten erreicht werden kann. Diese Modifikation liegt innerhalb des Umfangs der vorliegenden Erfindung.
  • Der Speicher 306 enthält ferner eine Datenbank 312 für benutzerprivilegierte Informationen und eine Datenbank 314 für eindeutige Nachrichten. Die Datenbank für benutzerprivilegierte Informationen 312 enthält Informationen, die vom Prozessor 304 verwendet werden, um Benutzer zu authentisieren. Die Datenbank 312 kann Informationen enthalten, wie z. B. PINs und Verschlüsselungsschlüssel, die mit benutzerprivilegierten Informationen verglichen werden, die von Benutzern eingegeben werden, wie weiter unten beschrieben wird, um zu überprüfen, dass die Benutzer authentische Benutzer sind. Die Datenbank 314 für eindeutige Nachrichten enthält Nachrichten, die vom Prozessor 304 verwendet werden, um den Benutzern zu signalisieren, dass der Host 302 ein authentischer Host ist. In einer Ausführungsform sind die eindeutigen Nachrichten geheime Nachrichten, die dem Host 302 von den Benutzern zur Verfügung gestellt werden, bevor die Benutzer mit dem Host 302 interagieren. Die eindeutige Nachrichten können irgendeine Form annehmen, einschließlich jedoch nicht hierauf beschränkt, einer Textnachricht, einer Audionachricht oder eines Geräusches, oder einer graphischen Anzeige einer bestimmten Art. Für die Zwecke der vorliegenden Erfindung kann irgendetwas als eindeutige Nachricht verwendet werden, dass für die Benutzer unverwechselbar ist und normalerweise von einem betrügerischen Host nicht gekannt oder erraten werden kann.
  • Der Host 304 kann optional ferner einen Kommunikationsanschluss 316, einen Schnittstellenanschluss 318, Ausgabevorrichtungen 320 und Eingabevorrichtungen 322 umfassen, die alle mit dem Hauptbus 303 gekoppelt sind. Ob diese Komponenten als Teil des Hosts 302 enthalten sind, hängt von der spezifischen Ausführungsform ab, die der Host annimmt (weiter unten beschrieben). Der Kommunikationsanschluss 316 ermöglicht dem Host 302, über ein Netzwerk mit einem nachgestellten System 330 zu kommunizieren. Das nachgestellte System 330 und der Host 302 können interagieren, um irgendeine gewünschte Funktion auszuführen. Die Funktionalität zwischen den zwei Komponenten kann frei aufgeteilt werden, wobei bei Bedarf die Funktionalität des nachgestellten Systems 330 vollständig in den Host 302 eingebettet werden kann. Der Kommunikationsanschluss 316 erlaubt ferner dem Host 302, mit unechten Endgeräten 340 und Clients 350 zu kommunizieren.
  • Der Schnittstellenanschluss 318 erlaubt dem Host 302, mit Zeichen zu kommunizieren. Diese Zeichen, wie z. B. ATM-Karten, werden von Benutzern verwendet, um dem Host 302 Benutzeridentifikationsinformationen zur Verfügung zu stellen, und allgemein, um mit dem Host 302 zu interagieren.
  • Die Ausgabevorrichtungen 320 können irgendeine einer Anzahl von Vorrichtungen enthalten, die dafür ausgelegt sind, Informationen den Benutzern zu übermitteln, einschließlich, jedoch nicht hierauf beschränkt, eine visuelle Anzeige, ein Audiosystem (z. B. Klangkarte und Lautsprecher) und einen Drucker. Die Eingabevorrichtungen 322 können irgendeine einer Anzahl von Vorrichtungen enthalten, die dafür ausgelegt sind, Benutzern zu erlauben, Eingaben in den Client 110 zu machen, einschließlich, jedoch nicht hierauf beschränkt, einer Tastatur, einer Maus, eines elektronischen Stifts und eines Tabletts, und eines berührungsempfindlichen Bildschirms.
  • Gemäß der vorliegenden Erfindung kann der Host 302 in einer Vielfalt unterschiedlicher Formen implementiert werden. Zum Beispiel kann der Host 302 die Form eines POS-Endgerätes (z. B. eines Geldautomaten) annehmen, das mit inaktiven Zeichen interagiert. In dieser Form würde der Host 302 den Schnittstellenanschluss 318, die Ausgabevorrichtungen 320, die Eingabevorrichtungen 322 und wahrscheinlich den Kommunikationsan schluss 316 enthalten. Der Host 302 kann ferner die Form eines Großrechners annehmen, der mit mehreren unechten Endgeräten 340 gekoppelt ist. In dieser Implementierung würde der Host 302 den Kommunikationsanschluss 316 enthalten, jedoch nicht den Schnittstellenanschluss 318 oder die Ausgabevorrichtungen 320 und die Eingabevorrichtungen 322. Außerdem kann der Host 302 auch die Form eines Servers annehmen, der mit einer Mehrzahl von Clients 350 gekoppelt ist. In dieser Form würde der Host 302 den Kommunikationsanschluss 316 enthalten, jedoch nicht den Schnittstellenanschluss 318 oder die Ausgabevorrichtungen 320 oder die Eingabevorrichtungen 322. Der Host 302 kann diese und viele andere Formen annehmen. Tatsächlich kann der Host 302 als Authentisierungsmechanismus in irgendeinem System implementiert sein, an dem sich der Benutzer unter Verwendung benutzerprivilegierter Informationen anmelden oder registrieren muss.
  • Mit Bezug auf das in 4 gezeigte Flussdiagramm und das Systemdiagramm der 3 wird im Folgenden die Operation des Hosts 302 beschrieben. Unter Leitung der Authentisierungsanweisungen 310, die im Speicher 306 gespeichert sind, implementiert der Prozessor 304 des Hosts 302 die Methodik der vorliegenden Erfindung. Der Prozessor 304 beginnt mit dem Authentisierungsprozess durch Senden (404) einer Anfrage an den Benutzer nach bestimmten Benutzeridentifikationsinformationen. Diese Informationen können den Namen des Benutzers, die Kontonummer des Benutzers, die Anmeldung des Benutzers und dergleichen enthalten, enthalten jedoch keine benutzerprivilegierten Informationen. Als Antwort liefert (408) der Benutzer die Benutzeridentifikationsinformationen an den Host 302.
  • Sobald die Benutzeridentifikationsinformationen empfangen worden sind, verwendet der Prozessor 304 die Identifikationsinformationen, um aus der Datenbank 314 für die eindeutigen Nachrichten eine oder mehrere eindeutige Nachrichten, die dem identifizierten Benutzer zugeordnet sind, zu beschaffen (402). Die eindeutige Nachricht ist eine geheime Nachricht, die im voraus vom Benutzer dem Host 302 zur Verfügung gestellt worden ist. Jeder Benutzer besitzt eine oder mehrere kundenspezifische eindeutige Nachrichten, die ihm zugeordnet sind. Der Prozessor 304 sendet (416) anschließend die eindeutige Nachricht zum Benutzer zusammen mit einer Anfrage nach bestimmten benutzerprivilegierten Informationen, wie z. B. einem Passwort, einer PIN oder einem Verschlüsselungsschlüssel.
  • Vor der Bereitstellung der vom Host 302 angeforderten benutzerprivilegierten Informationen sieht der Benutzer die Nachricht durch (420), die vom Host in Reaktion auf die Benutzeridentifikationsinformation zurückgegeben worden ist. Wenn der Benutzer feststellt (424), dass die Rückgabenachricht die vom Benutzer erwartete eindeutige Nachricht ist, stellt der Benutzer anschließend (432) dem Host 302 die angeforderten benutzerprivilegierten Informationen zur Verfügung.
  • Wenn andererseits die Rückgabenachricht nicht die vom Benutzer erwartete eindeutige Nachricht ist, weiß der Benutzer anschließend, dass der Host 302 kein authentischer Host ist. In einem solchen Fall stoppt der Benutzer (428) alle weitere Interaktion mit dem Host 302 und stellt dem Host keine benutzerprivilegierten Informationen zur Verfügung. Auf diese Weise ermöglicht die vorliegende Erfindung dem Benutzer, den Host 302 zu authentisieren, bevor er irgendwelche benutzerprivilegierten Informationen liefert. Dies trägt dazu bei, sicherzustellen, dass die benutzerprivilegierten Informationen nicht einem betrügerischen Host zur Verfügung gestellt werden.
  • Wenn der Host 302 ein authentischer Host ist und der Benutzer einen Satz von benutzerprivilegierten Informationen zur Verfügung stellt, überprüft (436) anschließend der Prozessor 304 die vom Benutzer bereitgestellten Informationen im Vergleich mit den Informationen, die in der Datenbank 302 für benutzerprivilegierte Informationen, die im Speicher 306 gespeichert ist, gespeichert sind. Wenn die zwei Sätze von Informationen übereinstimmen, weiß der Host 302 anschließend, dass der Benutzer ein authentischer Benutzer ist. In einem solchen Fall wird der Host 302 die Interaktion mit dem Benutzer fortsetzen.
  • Bisher wurde die Erfindung im Zusammenhang mit einem Client-Host-System und einem host-basierten System beschrieben. Obwohl die vorliegende Erfindung vorteilhaft in solchen Systemkonfigurationen implementiert werden kann, ist zu beachten, dass die Erfindung nicht hierauf beschränkt ist. Vielmehr kann sie allgemein auf irgendeinen Systemtyp angewendet werden.
  • 5 zeigt ein allgemeines Gesamtsystem 500, in welchem die vorliegende Erfindung implementiert werden kann, wobei das System 500 eine Benutzerschnittstelle 502 zum Empfangen von Eingaben und Bereitstellen von Ausgaben von/für einen Benutzer, eine vertrauenswürdige Komponente 504 und ein oder mehr andere Komponenten 508 umfasst. Im System 500 ist die vertrauenswürdige Komponente 504 die Komponente, die für die Implementierung der Methodik der vorliegenden Erfindung verantwortlich ist. Der Zweck der vertrauenswürdigen Komponente 504 besteht darin, den Benutzer Sicherheit zu geben, dass das Gesamtsystem authentisch ist. Das heißt, wenn der Benutzer feststellen kann, dass die vertrauenswürdige Komponente im System 500 vorhanden ist, weiß der Benutzer, dass das System authentisch ist.
  • Im System 500 kann die vertrauenswürdige Komponente 504 in irgendeiner Form und in irgendeinem Teil des Systems implementiert sein. Das heißt, sie kann als Softwaremodul oder als Hardwarekomponente (z. B. ein zweckbestimmter Chip) implementiert sein. Sie kann als Teil eines Clients, eines Hosts oder irgendeiner anderen Komponente implementiert sein. Zum Beispiel war in der vorher beschriebenen Client-Host-Implementierung (1) die vertrauenswürdige Komponente 504 als Teil des Clients 110 implementiert. Im obenbeschriebenen host-basierten System (3) war die vertrauenswürdige Komponente 504 als Teil des Hosts 302 implementiert. Falls gewünscht, kann die vertrauenswürdige Komponente 504 als Teil irgendeiner anderen Komponente implementiert sein. Die genaue Implementierung der vertrauenswürdigen Komponente 504 ist nicht von Bedeutung. Wichtig ist, dass die vertrauenswürdige Komponente 504 dem Benutzer eine gewisse Sicherheit bietet, dass das System 500 authentisch ist, bevor der Benutzer irgendwelche benutzerprivilegierten Informationen dem System 500 zur Verfügung stellt.
  • Bei der Erreichung dieses Ziels arbeitet die vertrauenswürdige Komponente 504 wie folgt. Sie empfängt zuerst über die Benutzerschnittstelle 502 einen Satz vom Benutzeridentifikationsinformationen. Diese Informationen können den Namen des Benutzers, die Kontonummer des Benutzers, die Anmeldung des Benutzers und dergleichen enthalten, enthalten jedoch keine benutzer privilegierten Informationen. Die vertrauenswürdige Komponente 504 verwendet anschließend die Identifikationsinformationen, um aus einem Speicher 506 ein oder mehrere eindeutige Nachrichten wiederzugewinnen, die dem identifizierten Benutzer zugeordnet sind. Die eindeutige Nachricht ist eine geheime Nachricht, die nur eine authentische vertrauenswürdige Komponente 504 kennen würde. Vor dem Senden der eindeutigen Nachricht zurück zum Benutzer führt die vertrauenswürdige Komponente 504 irgendwelche Überprüfungen durch, die notwendig sind, um die Benutzerschnittstelle 502 und die anderen Komponenten 508 des Systems 500 zu authentisieren. Anschließend sendet die vertrauenswürdige Komponente 504 die eindeutige Nachricht zum Benutzer über die Benutzerschnittstelle 502, um den Benutzer Sicherheit zu geben, dass das System 500 authentisch ist. Wenn die eindeutige Nachricht diejenige ist, die vom Benutzer erwartet wird, weiß der Benutzer anschließend, dass die vertrauenswürdige Komponente 504 sich im System 500 befindet und daher das System 500 authentisch ist. Als Ergebnis weiß der Benutzer, dass er dem System 500 sicher die benutzerprivilegierten Informationen zur Verfügung stellen kann. Wenn andererseits die Rückgabenachricht nicht die vom Benutzer erwartete eindeutige Nachricht ist, weiß der Benutzer anschließend, dass das System 500 kein authentisches System ist. In einem solchen Fall stoppt der Benutzer alle weitere Interaktion mit dem System 500. Auf diese Weise ermöglicht die vorliegende Erfindung dem Benutzer, das System 500 zu authentisieren, bevor er dem System 500 irgendwelche benutzerprivilegierten Informationen zur Verfügung stellt. Dies verhindert wiederum, dass benutzerprivilegierte Informationen betrügerischen Systemen zur Verfügung gestellt werden.
  • An diesem Punkt ist zu beachten, dass, obwohl die Erfindung mit Bezug auf spezifische Ausführungsformen beschrieben worden ist, die Erfindung nicht als derart eingeschränkt zu betrachten ist. Verschiedene Modifikationen können von Fachleuten mit dem Nutzen dieser Offenbarung vorgenommen werden, ohne vom Erfindungsgedanken der Erfindung abzuweichen. Die Erfindung soll daher durch spezifischen Ausführungsformen, die zur Erläuterung derselben verwendet worden sind, nicht eingeschränkt werden, sondern nur durch den Umfang der beigefügten Ansprüche.

Claims (9)

  1. Verfahren, das von einem Client (110) implementiert wird, um einem Benutzer zu ermöglichen, einen Host (112) zu authentisieren, umfassend: Interagieren (208) mit dem Host (112), um zu bestimmen, ob der Host (112) ein authentischer Host (112) ist; und in Reaktion auf eine Feststellung, dass der Host (112) ein authentischer Host (112) ist, Senden (220) einer eindeutigen Nachricht, die dem Benutzer anzeigt, dass der Client (110) mit dem Host (112) interagiert hat und dass der Host (112) ein authentischer Host (112) ist, wobei die eindeutige Nachricht eine geheime Nachricht ist, die dem Host (112) nicht bekannt ist und die vom Benutzer dem Client (110) im Voraus zur Verfügung gestellt wurde; dadurch gekennzeichnet, dass der Schritt des Sendens einer eindeutigen Nachricht umfasst: Bestimmen des aktuellen Wertes eines Parameters oder mehrerer Parameter; Auswählen einer von mehreren eindeutigen Nachrichten auf der Grundlage des aktuellen Wertes des einen Parameters oder der mehreren Parameter; und Senden der ausgewählten eindeutigen Nachricht an den Benutzer, um dem Benutzer anzuzeigen, dass der Client (110) mit dem Host (112) interagiert hat und dass der Host (112) ein authentischer Host (112) ist.
  2. Verfahren nach Anspruch 1, wobei die eindeutige Nachricht an den Host (112) gesendet wird, um sie mittels des Hosts (112) dem Benutzer anzuzeigen.
  3. Verfahren nach Anspruch 1, wobei das Interagieren mit dem Host (112) umfasst: Senden einer Aufforderung an den Host (112); Empfangen einer Antwort auf die Aufforderung vom Host (112); und Bestimmen auf der Grundlage der Antwort, ob der Host (112) ein authentischer Host (112) ist.
  4. Client (110) für das Interagieren mit einem Host (112), wobei der Client (110) einem Benutzer ermöglicht, den Host (112) zu authentisieren, wobei der Client (110) umfasst: einen Speicher zum Speichern einer eindeutigen Nachricht; eine Einrichtung zum Interagieren mit dem Host, um zu bestimmen, ob der Host (112) ein authentischer Host ist; und eine Einrichtung zum Senden der eindeutigen Nachricht an den Benutzer in Reaktion auf eine Feststellung, dass der Host (112) ein authentischer Host (112) ist, um den Benutzer anzuzeigen, dass der Client (110) mit dem Host (112) interagiert hat und dass der Host (112) ein authentischer Host ist, wobei die eindeutige Nachricht eine geheime Nachricht ist, die dem Host (112) nicht bekannt ist und vom Benutzer im Voraus dem Client (110) zur Verfügung gestellt wurde; dadurch gekennzeichnet, dass der Speicher mehrere eindeutige Nachrichten speichert, wobei die Einrichtung zum Senden umfasst: eine Einrichtung zum Bestimmen des aktuellen Wertes eines Parameters oder mehrerer Parameter; eine Einrichtung zum Auswählen einer der mehreren eindeutigen Nachrichten, die im Speicher gespeichert sind, auf der Grundlage des aktuellen Wertes des einen Parameters oder der mehreren Parameter; und eine Einrichtung zum Senden der ausgewählten eindeutigen Nachricht an den Benutzer, um dem Benutzer anzuzeigen, dass der Client (110) mit dem Host (112) interagiert hat und dass der Host (112) ein authentischer Host ist.
  5. Client (110) nach Anspruch 4, wobei die Einrichtung zum Interagieren mit dem Host (112) umfasst: eine Einrichtung zum Senden einer Aufforderung an den Host (112); eine Einrichtung zum Empfangen einer Antwort auf die Aufforderung vom Host (112); und eine Einrichtung, um auf der Grundlage der Antwort zu bestimmen, ob der Host (112) ein authentischer Host (112) ist.
  6. Verfahren, dass von einem Host (112) implementiert wird, um einem Benutzer zu ermöglichen, zu überprüfen, dass der Host (112) ein authentischer Host (112) ist, umfassend: Empfangen eines Satzes von Benutzeridentifikationsinformationen vom Benutzer; Abrufen einer dem Benutzer zugeordneten eindeutigen Nachricht auf der Grundlage der Benutzeridentifikationsinformationen, wobei die eindeutige Nachricht eine geheime Nachricht ist, die nur ein authentischer Host (112) kennen würde; und Senden der eindeutigen Nachricht an den Benutzer, um dem Benutzer zu ermöglichen, zu überprüfen, dass der Host (112) ein authentischer Host (112) ist, wobei die eindeutige Nachricht eine geheime Nachricht ist, die dem Host (112) vom Benutzer im Voraus zur Verfügung gestellt worden ist; dadurch gekennzeichnet, dass der Schritt des Sendens einer eindeutigen Nachricht umfasst: Bestimmen des aktuellen Wertes eines Parameters oder mehrerer Parameter; Auswählen einer von mehreren eindeutigen Nachrichten auf der Grundlage des aktuellen Wertes des einen Parameters oder der mehreren Parameter; und Senden der ausgewählten eindeutigen Nachricht an den Benutzer, um dem Benutzer anzuzeigen, dass der Client (110) mit dem Host (112) interagiert hat und dass der Host (112) ein authentischer Host (112) ist.
  7. Verfahren nach Anspruch 6, ferner umfassend: Empfangen eines Satzes von benutzerprivilegierten Informationen vom Benutzer, wobei der Benutzer die benutzerprivilegierten Informationen nur bereitstellt, nachdem der Benutzer überprüft hat, dass der Host (112) ein authentischer Host (112) ist; und Bestimmen auf der Grundlage der benutzerprivilegierten Informationen, ob der Benutzer ein authentischer Benutzer ist.
  8. Host (112), der einem Benutzer ermöglicht, die Authentizität des Hosts (112) zu überprüfen, umfassend: einen Speicher zum Speichern einer eindeutigen Nachricht, die dem Benutzer zugeordnet ist; eine Einrichtung zum Empfangen eines Satzes von Benutzeridentifikationsinformationen vom Benutzer; eine Einrichtung zum Abrufen der dem Benutzer zugeordneten eindeutigen Nachricht auf der Grundlage der Benutzeridentifikationsinformationen, wobei die eindeutige Nachricht eine geheime Nachricht ist, die nur ein authentischer Host (112) kennen würde; und eine Einrichtung zum Senden der eindeutigen Nachricht an den Benutzer, um dem Benutzer zu ermöglichen, zu überprüfen, dass der Host (112) ein authentischer Host (112) ist, wobei die eindeutige Nachricht eine geheime Nachricht ist, die dem Host (112) im Voraus vom Benutzer zur Verfügung gestellt worden ist; dadurch gekennzeichnet, dass der Speicher mehrere eindeutige Nachrichten speichert, wobei die Einrichtung zum Senden umfasst: eine Einrichtung zum Bestimmen des aktuellen Wertes eines Parameters oder mehrerer Parameter; eine Einrichtung zum Auswählen einer der mehreren eindeutigen Nachrichten, die im Speicher gespeichert sind, auf der Grundlage des aktuellen Wertes des einen Parameters oder der mehreren Parameter; und eine Einrichtung zum Senden der ausgewählten eindeutigen Nachricht an den Benutzer, um dem Benutzer anzuzeigen, dass der Client (110) mit dem Host (112) interagiert hat und dass der Host (112) ein authentischer Host ist.
  9. Host (112) nach Anspruch 8, ferner umfassend: eine Einrichtung zum Empfangen eines Satzes von benutzerprivilegierten Informationen vom Benutzer, wobei der Benutzer die benutzerprivilegierten Informationen nur eingibt, nachdem der Benutzer überprüft hat, dass der Host (112) ein authentischer Host (112) ist; und eine Einrichtung zum Bestimmen auf der Grundlage der benutzerprivilegierten Informationen, ob der Benutzer ein authentischer Benutzer ist.
DE60029379T 1999-04-20 2000-04-17 Verfahren und Gerät, die einem Rechnerbenutzer erlauben, vor der Eingabe von privilegierten Informationen ein System zu authentifizieren Expired - Lifetime DE60029379T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US29451899A 1999-04-20 1999-04-20
US294518 2002-11-13

Publications (2)

Publication Number Publication Date
DE60029379D1 DE60029379D1 (de) 2006-08-31
DE60029379T2 true DE60029379T2 (de) 2007-07-19

Family

ID=23133784

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60029379T Expired - Lifetime DE60029379T2 (de) 1999-04-20 2000-04-17 Verfahren und Gerät, die einem Rechnerbenutzer erlauben, vor der Eingabe von privilegierten Informationen ein System zu authentifizieren

Country Status (3)

Country Link
EP (1) EP1046976B1 (de)
DE (1) DE60029379T2 (de)
IL (1) IL135475A (de)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020066039A1 (en) * 2000-11-30 2002-05-30 Dent Paul W. Anti-spoofing password protection
US7562222B2 (en) 2002-05-10 2009-07-14 Rsa Security Inc. System and method for authenticating entities to users
US7730321B2 (en) 2003-05-09 2010-06-01 Emc Corporation System and method for authentication of users and communications received from computer systems
US7966492B1 (en) 2002-05-10 2011-06-21 Emc Corporation System and method for allowing an e-mail message recipient to authenticate the message
DE102004004552A1 (de) * 2004-01-29 2005-08-18 Giesecke & Devrient Gmbh System mit wenigstens einem Computer und wenigstens einem tragbaren Datenträger
WO2006028488A2 (en) 2004-02-04 2006-03-16 Passmark Security, Inc. Authentication of users and computer systems
WO2006062838A1 (en) * 2004-12-04 2006-06-15 Indiana University Research And Technology Corporation Anti-phising logon authentication object oriented system and method
KR100654039B1 (ko) * 2005-11-14 2006-12-05 에스케이 텔레콤주식회사 무선 인터넷에서 서비스 서버의 인증방법 및 이를 이용한결제방법
US8825728B2 (en) * 2006-06-15 2014-09-02 Microsoft Corporation Entering confidential information on an untrusted machine
US20080172750A1 (en) * 2007-01-16 2008-07-17 Keithley Craig J Self validation of user authentication requests
EP2003590A1 (de) * 2007-06-11 2008-12-17 Richard Mervyn Gardner Integrierte Systeme zur gleichzeitigen, gegenseitigen Authentifizierung von Datenbank und Benutzer
DE102007052826A1 (de) 2007-11-06 2009-05-07 Giesecke & Devrient Gmbh Daten verarbeitende Vorrichtung und Verfahren zum Betreiben einer Daten verarbeitenden Vorrichtung
DE102008046339A1 (de) * 2008-09-09 2010-03-11 Giesecke & Devrient Gmbh Freigabe von Transaktionsdaten
US8701165B2 (en) 2009-06-03 2014-04-15 Microsoft Corporation Credentials phishing prevention protocol

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5665952A (en) * 1993-09-07 1997-09-09 Ziarno; Witold A. Method of streamlining the acknowledgement of a multiplicity of contribution or gift commitments made at a plurality of remote locations to distinct fund-raising organizations and gift recipients and system therefor
US6178510B1 (en) * 1997-09-04 2001-01-23 Gtech Rhode Island Corporation Technique for secure network transactions

Also Published As

Publication number Publication date
EP1046976A2 (de) 2000-10-25
EP1046976A3 (de) 2004-07-14
DE60029379D1 (de) 2006-08-31
IL135475A0 (en) 2001-05-20
EP1046976B1 (de) 2006-07-19
IL135475A (en) 2004-09-27

Similar Documents

Publication Publication Date Title
DE602004012996T2 (de) Verfahren und vorrichtung zum authentifizieren von benutzern und websites
DE69521156T2 (de) Verfahren zum Authentisieren eines Schalterterminals in einem System zur Durchführung von Überweisungen
DE69829642T2 (de) Authentifizierungssystem mit chipkarte
DE69435079T2 (de) Chipkarte für eine Vielzahl von Dienstleistungsanbietern und für entfernte Aufstellung derselben
DE60121517T2 (de) Verfahren zur Erzeugung eines Anmeldungszertifikats aus einem fremden PKI-System unter Verwendung eines bestehenden starken PKI-Authentifizierungssystems
DE69727519T2 (de) Datennetzwerk mit Stimmkontrollmitteln
DE60211841T2 (de) Vorrichtung zur Aktualisierung und zum Entzug der Gültigkeit einer Marke in einer Infrastruktur mit öffentlichen Schlüsseln
DE69830993T2 (de) Elektronische transaktion und chipkarte für eine elektronische transaktion
EP1358533B1 (de) Verfahren, anordnung und sicherheitsmedium zur authentifizierung eines benutzers
DE69929267T2 (de) Vorrichtung zur entfernten Authentifikation
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
EP2332313B1 (de) Verfahren zur speicherung von daten, computerprogrammprodukt, id-token und computersystem
DE69814406T2 (de) Tragbare elektronische vorrichtung für systeme zur gesicherten kommunikation und verfahren zur initialisierung der parameter
DE69019037T2 (de) Mehrebenen-Sicherheitsvorrichtung und -verfahren mit persönlichem Schlüssel.
DE60029379T2 (de) Verfahren und Gerät, die einem Rechnerbenutzer erlauben, vor der Eingabe von privilegierten Informationen ein System zu authentifizieren
EP1777907B1 (de) Vorrichtungen und Verfahren zum Durchführen von kryptographischen Operationen in einem Server-Client-Rechnernetzwerksystem
DE10125954B4 (de) Sichere Datenübertragung von ungesicherten Eingabeumgebungen
DE19947986A1 (de) System und Verfahren zum Herunterladen von Anwendungsteilen auf eine Chipkarte
EP0970447B1 (de) Netzwerkunterstütztes chipkarten-transaktionsverfahren
WO2008113521A2 (de) Verfahren zur erzeugung bestätigter transaktionsdaten und vorrichtung dazu
DE10233297A1 (de) Vorrichtung zur digitalen Signatur eines elektronischen Dokuments
DE60008795T2 (de) Informatikvorrichtung zur anwendung von akkredtierungsdaten auf eine software oder auf einen dienst
DE69330743T2 (de) Verfahren zur Beurkundung einer Informationseinheit durch eine andere
DE112018006031B4 (de) Authentifizieren einer zahlungskarte
DE10124427A1 (de) System und Verfahren für einen sicheren Vergleich eines gemeinsamen Geheimnisses von Kommunikationsgeräten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition