DE212012000065U1 - Ein Token für eine starke Authentisierung mit akustischer Dateneingabe - Google Patents

Ein Token für eine starke Authentisierung mit akustischer Dateneingabe Download PDF

Info

Publication number
DE212012000065U1
DE212012000065U1 DE212012000065U DE212012000065U DE212012000065U1 DE 212012000065 U1 DE212012000065 U1 DE 212012000065U1 DE 212012000065 U DE212012000065 U DE 212012000065U DE 212012000065 U DE212012000065 U DE 212012000065U DE 212012000065 U1 DE212012000065 U1 DE 212012000065U1
Authority
DE
Germany
Prior art keywords
token
data
interface
acoustic
input
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
DE212012000065U
Other languages
English (en)
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.)
Onespan International GmbH
Original Assignee
Vasco Data Security International GmbH
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 Vasco Data Security International GmbH filed Critical Vasco Data Security International GmbH
Publication of DE212012000065U1 publication Critical patent/DE212012000065U1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2153—Using hardware token as a secondary aspect

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Telephonic Communication Services (AREA)
  • Lock And Its Accessories (AREA)
  • Input From Keyboards Or The Like (AREA)

Abstract

Ein Token für eine starke Authentisierung (strong authentication token) für die Erzeugung dynamischer Sicherheitswerte umfassend: eine vertrauenswürdige Schnittstelle für die Benutzerausgabe zur Kommunikation erzeugter dynamischer Sicherheitswerte an einen Benutzer; eine Schnittstelle für die akustische Eingabe für den akustischen Empfang von Eingabedaten, wobei die akustische Schnittstelle ein Mikrofon und eine mit dem Mikrofon verbundene Demodulationsschaltung umfasst, die ein vom Mikrofon empfangenes akustisches Signal demodulieren kann; und eine mit der Demodulationsschaltung verbundene Komponente zur Datenverarbeitung, wobei die Komponente zur Datenverarbeitung im empfangenen akustischen Signal übertragene Eingabedaten wiederherstellen kann, nachdem das akustische Signal von der Demodulationsschaltung demoduliert wurde, die wiederhergestellten Eingabedaten verarbeiten und die dynamischen Sicherheitswerte erzeugen kann.

Description

  • Verweis auf verwandte Anmeldungen
  • Diese Anmeldung bezieht sich auf die beim US-amerikanischen Patentamt am 25. Februar 2011 eingereichte vorläufige Anmeldung mit der Seriennummer 61/446,779 und beansprucht deren Vorteile, wobei der gesamte Inhalt dieser Anmeldung hier durch Bezugnahme eingeschlossen ist.
  • Erfindungsfeld
  • Die Erfindung betrifft Token für eine starke Authentisierung für die Sicherstellung des Remotezugriffs auf Computer und Anwendungen sowie für die Unterstützung von Remotetransaktionen über Computernetzwerke. Insbesondere betrifft die Erfindung Token für eine starke Authentisierung, die akustisch eingegebene Daten empfangen können.
  • Hintergrund der Erfindung
  • Der Remotezugriff auf Computersysteme und Anwendungen spielt eine immer wichtigere Rolle, und die Anzahl und Verschiedenartigkeit der Transaktionen, bei denen der Zugriff dezentral über öffentliche Netzwerke wie das Internet erfolgt, hat dabei erheblich zugenommen. Mit dieser tragenden Rolle geht ein erhöhter Sicherheitsbedarf einher. Es muss sichergestellt werden, dass die von den Remotebenutzern angegebene Identität korrekt ist, dass dezentral durchgeführte Transaktionen von hierzu berechtigten Personen eingeleitet werden und dass Transaktionsdaten vor dem Empfang an einem Anwendungsserver nicht verändert werden.
  • Früher haben sich die Anbieter von Anwendungen auf statische Kennwörter verlassen, um die Sicherheit von Remoteanwendungen zu gewährleisten. In den vergangenen Jahren wurde jedoch deutlich, dass statische Kennwörter nicht ausreichen und eine fortschrittlichere Sicherheitstechnologie erforderlich ist.
  • Eine Möglichkeit zur Beseitigung der Sicherheitsprobleme in Verbindung mit dem Remotezugriff auf Computersysteme und Anwendungen über öffentliche Netzwerke ist die Einrichtung einer Public-Key-Infrastruktur (PKI). Bei der Public-Key-Infrastruktur wird jedem Benutzer sowohl ein öffentlicher als auch ein privater Schlüssel zugewiesen. Dieses Schlüsselpaar ist mit einem (von einer vertrauenswürdigen Zertifizierungsstelle ausgegebenen) Zertifikat verknüpft, das den jeweiligen öffentlichen und privaten Schlüssel an einen bestimmten Benutzer bindet. Mithilfe eines asymmetrischen Kryptosystems kann dieses Schlüsselpaar dazu verwendet werden, den Benutzer zu authentisieren, Transaktionen zu signieren und eine verschlüsselte Kommunikation einzurichten.
  • Zur Gewährleistung der Sicherheit muss sichergestellt werden, dass der private Schlüssel eines Benutzer geheim bleibt und nur dem berechtigten Benutzer, dem dieser Schlüssel zugewiesen wurde, zur Signaturerstellung oder Nachrichtenentschlüsselung zur Verfügung steht. Häufig werden Smartcards oder USB-Geräte (Universal Serial Bus, auch als USB-Schlüssel oder USB-Token bezeichnet) eingesetzt, um den privaten und den öffentlichen Schlüssel und das Zertifikat zu speichern und die kryptografischen Berechnungen in Verbindung mit dem privaten Schlüssel auszuführen.
  • Die Public-Key-Infrastruktur und die Verwendung von Smartcards zur Speicherung der PKI-Schlüssel und -Zertifikate weist jedoch einige Nachteile auf:
    • 1. Der Aufbau einer Public-Key-Infrastruktur ist in der Regel kompliziert, weshalb diese Lösung im Vergleich zu konkurrierenden Sicherheitstechnologien höhere Kosten verursacht.
    • 2. PKI ist grundsätzlich auf Umgebungen und Anwendungen beschränkt, bei denen Clients und Server digital verbunden sind. Dies liegt daran, dass PKI-Kryptogramme und -Signaturen sehr umfangreich sind und nur schwer in eine visuell lesbare Form umgewandelt werden können. Aus diesem Grund ist diese Technologie nicht für das Telefonbanking oder andere Übermittlungskanäle geeignet, bei denen keine digitale Verbindung zwischen dem Speicherort des PKI-Zertifikats und des privaten Schlüssels auf der einen Seite und einem Anwendungsserver auf der anderen Seite hergestellt werden kann.
    • 3. Die bei der PKI verwendeten Smartcards und USB-Token sind nicht mit einem integrierten Netzteil oder einer Benutzeroberfläche ausgestattet. Sie sind deshalb auf ein Verbindungssystem angewiesen, das die Karte mit Strom versorgt und dazu in der Lage ist, Daten auf digitalem Weg mit der Karte auszutauschen und mit dem Benutzer zu interagieren (z. B. Erfassen der Identifikationsnummer (PIN) der Karte und Anzeigen der zu signierenden Daten). USB-Token werden normalerweise an einen USB-Anschluss eines PCs angeschlossen. Dabei wird das USB-Token über den USB-Anschluss mit Strom versorgt und die an den PC angeschlossenen Eingabegeräte stellen Funktionen für die Benutzerinteraktion bereit (Modell mit angeschlossenem USB-Token). PKI-Smartcards werden normalerweise über einen PC betrieben, der mit einem einfachen Smartcardleser ausgestattet ist. Der Leser übernimmt dabei nur die Stromversorgung der Smartcard und ermöglicht die Kommunikation zwischen einer Anwendung auf dem PC und der eingeführten Smartcard. Die Funktionen für die Benutzerinteraktion werden dagegen von den Eingabegeräten bereitgestellt, die an den PC angeschlossen sind. Ein derartiger Leser ohne vertrauenswürdige eigene Benutzeroberfläche wird häufig als transparenter Kartenleser bezeichnet. Bei diesen typischen Nutzungsmodellen ist die Mobilität des Benutzers eingeschränkt, weil die meisten PCs nicht werkseitig mit Smartcardlesern ausgestattet sind und eine Ad-hoc-Treiberinstallation für die Leser von USB-Token zu aufwändig ist Es besteht außerdem ein Sicherheitsproblem, weil sämtliche Benutzerinteraktionen (wie das Genehmigen von Signaturen oder das Erfassen der Karten-PIN) über den grundsätzlich unsicheren PC erfolgen.
  • Ein anderer Ansatz besteht darin, Softwareanwendungen mit Sicherheitsfunktionen auf Mehrzweckgeräten wie Benutzer-PCs oder Mobilgeräten (z. B. Mobiltelefonen oder PDAs) zu installieren. Das Hauptproblem bei dieser Lösung ist die grundsätzlich offene Architektur dieser Mehrzweckgeräte. Diese sind dadurch für alle Arten von Malware wie Viren und Trojaner anfällig, die falsche Nachrichten an den Benutzer senden, Tastatureingaben des Benutzers erfassen, vertrauliche Daten für Sicherheitsanwendungen aus dem Speicher abrufen oder Daten vor der Signierung verändern können. Die Benutzeroberfläche von Mehrzweckgeräten kann aus diesem Grund nicht als vertrauenswürdig eingestuft werden, und es besteht keine sichere Möglichkeit zur Speicherung geheimer Informationen wie PINs und kryptografischer Schlüssel. Bei bekannten Technologien für Mobilgeräte werden außerdem für den Empfang und/oder die Übertragung von Transaktionsdaten drahtlose Abonnentennetzwerke verwendet. Diese Netzwerke bieten eigene Verfahren zur Gewährleistung der Sicherheit und Authentisierung am Endpunkt. Aber es kann nicht davon ausgegangen werden, dass diese aktiv sind, wenn das Internet für sämtliche Übertragungen genutzt wird.
  • Eine alternative Technologie mit Signaturfunktionen für Transaktionen und die Authentisierung bieten Token für eine starke Authentisierung. Mit dieser Lösung werden die bei Mehrzweckgeräten bestehenden Sicherheitseinschränkungen ebenso vermieden wie die Probleme im Hinblick auf Sicherheit, Installation und Anschluss bei Verwendung von PKI-Smartcards und USB-Token. Typische Beispiele für Token für eine starke Authentisierung sind die Produkte der Reihe DIGIPASS®, die von VASCO Data Security Inc. aus Chicago, Illinois, vertrieben werden (siehe Website unter http://www.vasco.com). Token für eine starke Authentisierung sind unabhängige batteriebetriebene Geräte, die Signaturfunktionen für Transaktionen und/oder die Authentisierung bereitstellen. Die Geräte haben in der Regel Taschenformat und sind mit eigener Anzeige und Tastatur ausgestattet. Bei einigen Modellen wird dabei eine komplette Tastatur verwendet. Diese kann aber auch auf eine einzige Taste reduziert sein oder es wird ganz auf eine Tastatur verzichtet. Die Anzeige und die Tastatur eines typischen Token für eine starke Authentisierung können nicht entfernt oder vom Benutzer gewartet werden, ihre Steuerung erfolgt vollständig über das Token und sie sind immun gegen Angriffe durch Malware auf einem Hostcomputer. Im Gegensatz etwa zu PCs, bei denen immer die Möglichkeit besteht, dass Malware wie Viren und Trojaner falsche Nachrichten an den Benutzer senden, Tastatureingaben des Benutzers erfassen, vertrauliche Daten für Sicherheitsanwendungen aus dem Speicher abrufen oder Daten vor der Signierung verändern, gilt die Benutzeroberfläche von Token für eine starke Authentisierung deshalb als vertrauenswürdig. Token für eine starke Authentisierung dienen hauptsächlich zur Erzeugung dynamischer Sicherheitswerte, die auch als Einmalkennwörter (OTPs) oder dynamische Kennwörter bezeichnet werden. Zur Erzeugung dieser Einmalkennwörter wird in der Regel ein geheimer Schlüssel, der für das Token und einen Verifizierungsserver eingerichtet wurde, kryptografisch mit einem dynamischen Wert wie einem Zeitwert, einem Zählerwert, einer Serveranforderung an das Token oder einer Kombination dieser Alternativen verbunden. Einige Token für eine starke Authentisierung können auch anhand von Daten (wie Transaktionsdaten), die als dynamischer Wert oder zusammen mit einem der oben erwähnten dynamischen Werte auf das Token übertragen wurden, einen Sicherheitswert erzeugen. Ein auf diese Weise erzeugter Sicherheitswert wird allgemein als elektronische Signatur oder Nachrichten Authentisierungscode (MAC) bezeichnet und zeigt an, dass die Daten vom Benutzer genehmigt wurden. Es gibt Token für eine starke Authentisierung, die über eine Anzeige und eine Tastatur für die Kommunikation mit einer eingeführten Smartcard verfügen. In diesem Fall erfolgt die Erzeugung der OTPs oder MACs teilweise auf dem Gerät selbst und teilweise über die eingeführte Smartcard.
  • Bei Token für eine starke Authentisierung werden die erforderlichen Daten häufig vom Benutzer manuell über die Tastatur des Token eingegeben. Wenn jedoch mehrere Dutzend Zeichen auf diese Weise eingegeben werden müssen, wird dieser Prozess von den Benutzern oftmals als unpraktisch betrachtet. Ein weiterer Nachteil von Token mit Tastatur zur Unterstützung manueller Dateneingaben besteht darin, dass die Geräte in der Regel wesentlich größer sind. Zur Steigerung des Bedienkomforts wurden Lösungen entwickelt, bei denen die besagten Daten vom Benutzer nicht manuell über eine Tastatur eingegeben werden müssen. Ein Beispiel hierfür sind Token mit technischen Komponenten für den Empfang von Daten, die über einen Out-of-Band-Kanal wie ein Funk- oder Mobilfunknetz gesendet werden (siehe US-Patent Nr. 5,668,876 vom 16. September 1997). Diese Lösungen sind jedoch mit einer höheren Komplexität und zusätzlichen Kosten für die Unterstützung der Technologie des Out-of-Band-Kanals verbunden. Außerdem ist dieses System von der Verfügbarkeit des Out-of-Band-Kanals abhängig, und dessen Nutzung verursacht weitere Kosten. Eine weitere Technologie beruht auf Token, bei denen die Daten über eine optische Schnittstelle eingegeben werden. Der Benutzer hält das Token dazu vor einen Computerbildschirm, auf dem abwechselnde optische Muster angezeigt werden. Beispiele für derartige optische Token sind die Modelle Digipass 700 und Digipass 300 von VASCO Data Security Inc. aus Chicago, Illinois, und die Token gemäß der europäischen Patentbeschreibung Nr. 1211841 vom 5. Juni 2002, der europäischen Patentbeschreibung Nr. 1788509 vom 23. Mai 2007 und dem US-Patent Nr. 5,136,644 vom 4. August 1992.
  • Ein generelles Problem von Token mit optischer Schnittstelle für die Dateneingabe sind die relativ teuren Komponenten, die zur Herstellung geeigneter Schnittstellen für den Empfang hoher Datenraten erforderlich sind. Dies ist Voraussetzung für eine zuverlässige Funktionsweise, denn es müssen Computerbildschirme von sehr unterschiedlicher Qualität und Lichtverhältnisse in verschiedenen Umgebungen unterstützt werden. Hinzu kommen die relativ niedrigen Aktualisierungsraten typischer Computerbildschirme. Eine kostengünstigere Alternative hierzu stellt die Verwendung optischer Schnittstellen mit niedrigen Übertragungsraten dar. Bei diesem Modell wird jedoch entweder die Menge der auf das Token übertragenen Transaktionsdaten stark eingeschränkt oder es müssen sehr lange Übertragungszeiten in Kaufgenommen werden.
  • Es besteht somit das Erfordernis eines alternativen und kosteneffektiven Dateneingabemechanismus für Token für eine starke Authentisierung, über den Daten mit relativ hohen Datenraten zuverlässig und bequem vom Benutzer eingegeben werden können.
  • Darstellung der Erfindung
  • Die vorliegende Erfindung stützt sich auf die Erkenntnis der Erfinder, dass der Benutzerzugriff auf viele durch Token für eine starke Authentisierung geschützte Anwendungen über PCs oder ähnliche Computergeräte erfolgt, die in der Regel Tonsignale im akustisch wahrnehmbaren Frequenzbereich mit einer Bandbreite von etwa 10 Kilohertz erzeugen und ausgeben können, und dass Daten durch eine gesteuerte Tonmodulation mittels dieser Computergeräte mit einer relativ hohen Datenrate an ein Token für eine starke Authentisierung übertragen werden können, das über eine geeignete Technologie für den Empfang und die Demodulation der von den Computergeräten ausgegebenen Tonsignale verfügt. Die vorliegende Erfindung stützt sich zudem auf die Erkenntnis der Erfinder, dass in einer solchen Konstellation (also mit Datenaustausch über Schallwellen im akustisch wahrnehmbaren Frequenzbereich, Datenübertragung über einen Lautsprecher, Datenempfang über ein Mikrofon, der Luft zwischen dem Lautsprecher und dem Mikrofon als Übertragungsmedium, einem gewissen Nachhall des Mediums/Raums und in der Regel einer bestimmten Menge an Störgeräuschen im Raum) eine Hauptursache für Übertragungsfehler in Reflexionen (z. B. an den Wänden des Raums, in dem die Übertragung stattfindet) der Tonsignale besteht, die mit erheblicher Verzögerung am Empfänger des Token ankommen, weshalb akustische Signale mehrfach empfangen werden, und dass die Stärke eines reflektierten Signals normalerweise geringer ist als die eines direkt empfangenen Signals. Störgeräusche können eine weitere wichtige Ursache für Übertragungsfehler darstellen. Es ist eine weitere Erkenntnis der Erfinder, dass die Stärke der Störgeräusche normalerweise stochastisch über eine relativ breite Bandbreite verteilt ist. Die vorliegende Erfindung stützt sich zudem auf die Erkenntnis der Erfinder, dass eine nicht lineare Verzerrung des akustischen Signals, durch die Oberschwingungen bei den im Signal vorhandenen Frequenzen entstehen, im Allgemeinen nicht erheblich zur Stärke der Störgeräusche auf das empfangene Signal beiträgt.
  • Bei einer typischen Ausführungsart werden die Eingabedaten für das Token als modulierte Tonsignale übertragen, die über eine akustische Schnittstelle in das Token eingegeben werden. Bei einer Ausführungsart beinhaltet die akustische Schnittstelle des Token ein Mikrofon und eine Demodulationsschaltung. Das Mikrofon dient zum Empfang akustischer Signale und zu deren Umwandlung in analoge elektrische Signale. Das Mikrofon ist mit einer Demodulationsschaltung verbunden, die die analogen elektrischen Signale in digitale Signale umwandelt. Bei einer Ausführungsart ist die Demodulationsschaltung mit einem Element zur Datenverarbeitung verbunden, das die in den digitalen Signalen codierten Eingabedaten extrahieren und verarbeiten kann.
  • Bei einer Ausführungsart beinhaltet die sendende Einheit ein Computergerät, mit dem der Benutzer interagiert (z. B. Zugriff auf eine internetbasierte Anwendung). Bei einigen Ausführungsarten kann das Computergerät des Benutzers einen PC, einen Tablet-Computer, ein Smartphone oder ein ähnliches Computergerät beinhalten, mit dem der Benutzer interagiert (z. B. Zugriff auf eine internetbasierte Anwendung). Bei einigen Ausführungsarten ist das Computergerät des Benutzers mit Lautsprechern ausgestattet, die Tonsignale im akustisch wahrnehmbaren Frequenzbereich ausgeben können. Bei einer bestimmten Ausführungsart geben die Lautsprecher am Computergerät des Benutzers die von einer auf dem PC ausgeführten Softwareanwendung erzeugten Tonsignale aus. Bei einer Ausführungsart beinhaltet die auf dem Computergerät des Benutzers ausgeführte Softwareanwendung einen Browser, auf dem ein in eine Webseite integriertes Applet oder Plug-In ausgeführt wird. Bei einer Ausführungsart beinhaltet das Applet eine Flash-Anwendung. Bei einigen Ausführungsarten ist die Webseite mit der Anwendung verknüpft, die durch das Token für eine starke Authentisierung geschützt werden soll.
  • Bei einigen Ausführungsarten beinhaltet das empfangende Token ein Mikrofon für den Empfang der akustischen Signale und deren Umwandlung in elektrische Signale. Das Token kann auch eine mit dem Mikrofon verbundene Demodulationsschaltung beinhalten, über die die elektrischen Signale des Mikrofons demoduliert werden.
  • Bei einigen Ausführungsarten werden die Eingabedaten an der sendenden Einheit als digitale Datenkette verschlüsselt. Bei einigen Ausführungsarten wird die digitale Datenkette über ein Modulationsverfahren der Frequenzumtastung als akustisches Signal ausgegeben, wobei alle zur Codierung des akustischen Signals verwendeten Frequenzen (in diesem Text nachfolgend als „Codierungsfrequenz” bezeichnet) ganzzahlige Vielfache einer gemeinsamen Grundfrequenz sind. Auch wenn bei einigen Ausführungsarten die Modulation so ausgelegt ist, dass das fortlaufend ausgegebene akustische Signal nur eine der Codierungsfrequenzen enthält, kann das vom Token empfangene akustische Signal aufgrund von Störgeräuschen, Reflexionen und Verzerrungen gleichzeitig mehrere der Codierungsfrequenzen enthalten. Bei einigen Ausführungsarten ermittelt die Demodulationsschaltung die Stärke aller im Signal vorhandenen Codierungsfrequenzen und vergleicht die relative Stärke der einzelnen Codierungsfrequenzen. Die Codierungsfrequenz mit der höchsten relativen Stärke gilt als die an der sendenden Einheit ausgegebene Codierungsfrequenz.
  • Bei einigen Ausführungsarten sind alle Codierungsfrequenzen ganzzahlige Vielfache einer gemeinsamen Grundfrequenz und die Demodulationsschaltung beinhaltet eine Phasenregelschleife (PRS), die auf die gemeinsame Grundfrequenz der Codierungsfrequenzen eingestellt ist. Bei einigen Ausführungsarten kommt eine schmalbandige PRS zum Einsatz. Durch die Einstellung auf die gemeinsame Grundfrequenz der Codierungsfrequenzen wird die PRS auch mit allen Codierungsfrequenzen selbst synchronisiert.
  • Bei einigen Ausführungsarten beinhaltet die Demodulationsschaltung einen Vorverstärker, der die elektrischen Signale vor der eigentlichen Demodulation selektiv verstärkt. Bei einigen Ausführungsarten beinhaltet der Vorverstärker einen Bandbreitenfilter, der Frequenzen unterhalb der untersten Codierungsfrequenz und oberhalb der höchsten Codierungsfrequenz unterdrückt.
  • Bei einigen Ausführungsarten beinhaltet die Demodulationsschaltung für jede unterstützte Codierungsfrequenz eine Stromerkennungsteilschaltung. Jede Stromerkennungsteilschaltung gibt ein elektrisches Signal aus, dessen Ebene die Stärke des empfangenen akustischen Signals der Codierungsfrequenz anzeigt, die mit dieser Stromerkennungsteilschaltung verbunden ist. Die Stromerkennungsteilschaltungen können an eine Ratiodetektorteilschaltung angeschlossen sein, die die Ausgabeebenen der Stromerkennungsteilschaltungen vergleicht und über ein Signal anzeigt, welche Stromerkennungsteilschaltung die höchste Ausgabeebene aufweist und welche Codierungsfrequenz damit im empfangenen akustischen Signal am stärksten ist. Bei einigen Ausführungsarten werden nur zwei Codierungsfrequenzen verwendet und das Ausgabesignal der Ratiodetektorteilschaltung ist eine Bitsequenz, wobei durch „0” oder 1” angezeigt wird, welche Codierungsfrequenz am stärksten ist. Bei einigen bestimmten Ausführungsarten kann die Ratiodetektorteilschaltung einen Komparator beinhalten, dessen Eingaben die Ausgaben der beiden Stromerkennungsteilschaltungen sind.
  • Bei einigen Ausführungsarten können die Stromerkennungsteilschaltungen einen Demodulator und einen Tiefpassfilter beinhalten. Dabei entspricht die Ausgabe des Demodulators der Eingabe des Tiefpassfilters und jeder Demodulator übernimmt das empfangene Eingabesignal (optional selektiv verstärkt) und ein von der Phasenregelschleife erzeugtes Referenzsignal als Eingabe.
  • Bei einigen Ausführungsarten kann das Token neben der Schnittstelle für die akustische Eingabe weitere Dateneingabemechanismen für den Datenempfang aufweisen. Die besagten zusätzlichen Dateneingabemechanismen können eine Schnittstelle für die manuelle Benutzereingabe beinhalten, über die der Benutzer Daten manuell in das Token eingeben kann. Diese Schnittstelle für die manuelle Benutzereingabe kann einen Tastenblock oder eine Tastatur beinhalten. Des Weiteren können alternative Mechanismen für die manuelle Dateneingabe wie Joysticks, Jog Dials, Trackballs, Scrollräder oder ähnliche Geräte enthalten sein. Die zusätzlichen Eingabeschnittstellen können auch Kommunikationsmechanismen und Protokolle wie persönliche Netzwerke (PANs), USB oder Firewire, optische Anschlüsse oder WPANs (Wireless Personal Area Networks) beinhalten, die Funkverbindungen wie Bluetooth oder Infrarotverbindungen wie IRDA (Infrared Data Association) nutzen.
  • Bei einigen Ausführungsarten hat das Token keinen Tastenblock, was eine sehr kompakte Bauweise ermöglicht. Bei anderen Ausführungsarten verfügt das Token über eine kompakte Schnittstelle für die manuelle Benutzereingabe, über die der Benutzer Daten wie PINs manuell eingeben kann. Die kompakte Schnittstelle für die manuelle Benutzereingabe kann einen Tastenblock mit maximal drei oder vier Tasten, ein Rad für das Scrollen durch verschiedene Optionen (wie eine Liste mit Ziffern) in Verbindung mit maximal zwei Tasten oder auch nur ein Rad für das Scrollen durch verschiedene Optionen beinhalten, wobei das Rad in diesem Fall zudem als Drucktaste zur Bestätigung der aktuell ausgewählten Option dienen kann. Bei einigen Ausführungsarten kann die kompakte Schnittstelle für die manuelle Benutzereingabe aus einem Navigations- und einem Bestätigungsmechanismus bestehen. Hierbei ermöglicht der Navigationsmechanismus dem Benutzer die Navigation in einer Optionsliste und/oder die Auswahl eines Elements aus einer Optionsliste und der Benutzer kann dem Token über den Bestätigungsmechanismus Bestätigungen erteilen. Es können beispielsweise aktuell ausgewählte Elemente wie Optionen oder Daten oder auch Informationen bestätigt werden, die dem Benutzer vom Token angezeigt oder empfohlen werden. Bei einigen Ausführungsarten kann die kompakte Schnittstelle für die manuelle Benutzereingabe auch einen Abbruchmechanismus beinhalten, über den der Benutzer vom Token angezeigte Elemente ablehnen und den Vorgang abbrechen kann. Bei einigen Ausführungsarten beinhaltet der Navigationsmechanismus ein Scrollrad oder Jog Dial. Bei einigen Ausführungsarten kann der Navigationsmechanismus eine, zwei oder mehrere Navigationstasten beinhalten. Bei einigen Ausführungsarten kann der Bestätigungsmechanismus eine „OK”-Taste beinhalten. Bei einigen Ausführungsarten kann der Abbruchmechanismus eine „Cancel”-Taste (Abbrechen) beinhalten. Bei einigen Ausführungsarten können die Dateneingabeelemente des Token aus nur einer Schnittstelle für die akustische Eingabe und einer kompakten Schnittstelle für die manuelle Benutzereingabe bestehen.
  • Bei einer Reihe von Ausführungsarten der Erfindung beinhaltet das Token einen Tastenblock Bei einer Ausführungsart können über diesen Tastenblock mindestens die Dezimalziffern eingegeben werden. Bei einer anderen Ausführungsart ermöglicht der besagte Tastenblock auch die Eingabe von Hexadezimalziffern oder alphanumerischen Zeichen. Bei einigen Ausführungsarten beinhaltet der besagte Tastenblock Kontrolltasten, über die der Benutzer vom Token angezeigte Informationen oder Optionen genehmigen oder ablehnen kann, oder Navigationstasten für das Scrollen durch Menüoptionen oder vom Token angezeigte Informationen. Bei anderen Ausführungsarten ist eine komplette Tastatur vorhanden. Bei einigen Ausführungsarten kann neben der Schnittstelle für die akustische Eingabe sowohl ein Tastenblock als auch eine optische Schnittstelle vorhanden sein. Hierbei kann der Tastenblock als Absicherung dienen, wenn die optische und/oder akustische Eingabe fehlschlägt.
  • Bei einigen Ausführungsarten kann der Benutzer über die Schnittstelle für die manuelle Benutzereingabe Genehmigungen erteilen, z. B. für zu signierende Daten, oder Auswahlen treffen, z. B. ob eine optische oder eine akustische Schnittstelle für den Empfang von Eingabedaten verwendet werden soll. Bei einigen Ausführungsarten kann der Benutzer über die Schnittstelle für die manuelle Benutzereingabe Werte an das Token übermitteln. Hierzu zählen unter anderem zu signierende Transaktionsdaten oder PINs.
  • Bei einigen Ausführungsarten beinhaltet das Token eine Schnittstelle für die Benutzerausgabe, über die das Token Informationen ausgeben oder dem Benutzer anzeigen kann. Bei einigen Ausführungsarten können die an den Benutzer ausgegebenen Informationen Sicherheitswerte wie Einmalkennwörter oder dynamische Kennwörter und/oder Signaturen etwa für transaktionsbezogene Daten beinhalten. Bei einigen Ausführungsarten können die dem Benutzer angezeigten Informationen Daten beinhalten, die vom Token für die vorherige Genehmigung durch den Benutzer signiert werden müssen. Bei einigen Ausführungsarten können dem Benutzer Informationen zu den Daten angezeigt werden, die signiert werden sollen. Dies können Beschreibungen bestimmter Datenelemente oder Informationen zu Transaktionskontexten wie Verweise auf Anwendungseigentümer oder deren Namen sein.
  • Bei einigen Ausführungsarten der Erfindung können die Ausgabeelemente des Token eine Anzeige wie eine Flüssigkristallanzeige (LCD) und/oder eine oder mehrere Leuchtdioden (LEDs) beinhalten, über die z. B. Status oder Bedingungen im Zusammenhang mit der Sicherheit angezeigt werden können. Bei einer Ausführungsart kann das Token auf der Anzeige Texte anzeigen. Bei einer Ausführungsart können die besagten Texte als Zeichenfolge angezeigt werden. Bei einer anderen Ausführungsart kann das Token auf der Anzeige Symbole oder Bildsymbole anzeigen. Bei einer anderen Ausführungsart beinhalten die Ausgabeelemente des Token Elemente für die Audioausgabe wie Lautsprecher, Ohrhörer oder Elemente für den Anschluss solcher Lautsprecher oder Kopfhörer wie 1/8-Zoll- oder Cinch-Audiobuchsen, um Informationen über erzeugte Tonsignale an den Benutzer zu übermitteln. Bei einer Ausführungsart werden die erzeugten Tonsignale als Tonfolgen ausgegeben. Bei einer anderen Ausführungsart bestehen die erzeugten Tonsignale in künstlich erzeugter Sprache. Bei einer anderen Ausführungsart sind die erzeugten Tonsignale Reproduktionen gespeicherter Tonfragmente.
  • Bei einigen Ausführungsarten kann das Token eine vertrauenswürdige Schnittstelle für die Benutzereingabe beinhalten. Bei einigen Ausführungsarten kann hierzu die Eingabeschnittstelle des Token so ausgelegt sein, dass das Token immer zwischen einerseits Daten, die manuell von einem physisch mit dem Token interagierenden Benutzer eingegeben werden, und andererseits Daten, die ohne eine solche manuelle Eingabe an das Token übermittelt werden, unterscheiden kann. Bei einigen Ausführungsarten kann die Schnittstelle für die manuelle Benutzereingabe nicht entfernt oder vom Benutzer gewartet werden, ihre Steuerung erfolgt vollständig über das Token und sie ist immun gegen Angriffe durch Malware auf einem Hostcomputer. Bei einigen Ausführungsarten kann das Token vor unberechtigten Veränderungen an der Tokenfirmware geschützt sein. Bei einigen Ausführungsarten kann die Tokenfirmware auf einem unveränderbaren Speicher wie ROM gespeichert sein. Bei einigen Ausführungsarten unterstützt das Token Firmware-Updates, aber die Firmware kann nur über kryptografisch geschützte und sichere Firmware-Updateprotokolle aktualisiert werden. Bei einigen Ausführungsarten kann das Token mit Mechanismen zum Manipulationsschutz und/oder zur Manipulationserkennung ausgestattet sein. Dies kann Mechanismen beinhalten, die erkennen, wenn das Gehäuse des Token geöffnet wird.
  • Bei einigen Ausführungsarten kann das Token eine vertrauenswürdige Schnittstelle für die Benutzerausgabe beinhalten. Bei einigen Ausführungsarten kann hierzu die Schnittstelle für die Benutzerausgabe des Token so ausgelegt sein, dass das Token vollständig alle Ausgaben steuert, die dem Benutzer vom Token angezeigt werden. Bei einigen Ausführungsarten kann die Schnittstelle für die Benutzerausgabe nicht entfernt oder vom Benutzer gewartet werden, ihre Steuerung erfolgt vollständig über das Token und sie ist immun gegen Angriffe durch Malware auf einem Hostcomputer. Bei einigen Ausführungsarten kann das Token vor unberechtigten Veränderungen an der Tokenfirmware geschützt sein. Bei einigen Ausführungsarten kann die Tokenfirmware auf einem unveränderbaren Speicher wie ROM gespeichert sein. Bei einigen Ausführungsarten unterstützt das Token Firmware-Updates, aber die Firmware kann nur über kryptografisch geschützte und sichere Firmware-Updateprotokolle aktualisiert werden. Bei einigen Ausführungsarten kann das Token mit Mechanismen zum Manipulationsschutz und/oder zur Manipulationserkennung ausgestattet sein. Dies kann Mechanismen beinhalten, die erkennen, wenn das Gehäuse des Token geöffnet wird.
  • Bei einer bestimmten Ausführungsart der Erfindung beinhaltet das Token Elemente zur Datenverarbeitung wie Mikroprozessoren, um kryptografische Vorgänge durchzuführen, und Elemente zur Datenspeicherung wie RAM, ROM oder EEPROM, um einen oder mehrere geheime Werte wie eine oder mehrere PINs oder geheime kryptografische Schlüssel zu speichern. Bei einigen Ausführungsarten ist das Token so ausgelegt, dass das unberechtigte Lesen dieser geheimen Werte verhindert wird. Beispielsweise kann das Token mit Mechanismen zum Manipulationsschutz und/oder zur Manipulationserkennung ausgestattet sein. Dies kann Mechanismen beinhalten, die erkennen, wenn das Gehäuse des Token geöffnet wird.
  • Bei einer Ausführungsart der Erfindung können die Eingabedaten eine Anforderung beinhalten (z. B. eine Zufallszahl oder ein Hash für Transaktionsdaten, die zu Zwecken der Authentisierung/Validierung verarbeitet werden können). Bei einer anderen Ausführungsart der Erfindung beinhalten die Eingabedaten transaktionsbezogene Daten wie Transaktionswerte oder Informationen zum Transaktionskontext. Bei einigen Ausführungsarten können die Informationen zum Transaktionskontext Bezeichnungen der Transaktionsdaten und/oder Informationen zur Bedeutung der transaktionsbezogenen Daten beinhalten. Bei einigen Ausführungsarten beinhalten die Eingabedaten Informationen zum Anwendungsfluss. Bei einigen Ausführungsarten können die Informationen zum Anwendungsfluss Informationen zum Transaktionstyp beinhalten. Bei einigen Ausführungsarten können die Informationen zum Transaktionstyp Anweisungen dazu beinhalten, wie das Token die empfangenen transaktionsbezogenen Daten und/oder den Benutzerinteraktionsfluss bearbeiten soll, z. B. welche Daten dem Benutzer zur Überprüfung und/oder Genehmigung angezeigt werden sollen, ob der Benutzer die Möglichkeit erhalten soll, Daten zu korrigieren oder zusätzliche Daten manuell einzugeben, und/oder welche Nachrichten dem Benutzer angezeigt werden sollen.
  • Bei einigen Ausführungsarten können die Eingabedaten Serveranmeldeinformationen beinhalten, die kryptografisch von einem Server erzeugt wurden. Bei einigen Ausführungsarten erzeugt der Server die Serveranmeldeinformationen über einen symmetrischen kryptografischen und geheimen Schlüssel, der zusammen mit dem Token verwendet wird, oder über ein zweites Sicherheitsgerät, mit dem das Token kommuniziert. Bei einigen Ausführungsarten kann das Token die Serveranmeldeinformationen verifizieren. Bei einigen Ausführungsarten kann das Token die Serveranmeldeinformationen in Verbindung mit einem zweiten Sicherheitsgerät verifizieren. Bei einigen Ausführungsarten erfolgt die Verifizierung der Serveranmeldeinformationen über einen symmetrischen kryptografischen Algorithmus mit einem geheimen Schlüssel, der zusammen mit dem Server verwendet wird. Bei einigen Ausführungsarten beinhalten die Serveranmeldeinformationen ein Einmalkennwort für den Server. Bei einigen Ausführungsarten beinhalten die Serveranmeldeinformationen eine Datensignatur. Bei einigen Ausführungsarten beinhalten die Serveranmeldeinformationen einen Nachrichten Authentisierungscode (MAC). Bei einigen Ausführungsarten beinhalten die Serveranmeldeinformationen verschlüsselte Eingabedaten. Bei einigen Ausführungsarten besteht der Zweck der Serveranmeldeinformationen in der Authentisierung eines Servers oder einer Serveranwendung. Bei einigen Ausführungsarten besteht der Zweck der Serveranmeldeinformationen in der Authentisierung von Eingabedaten, die das Token von einem Server empfangen hat. Bei einigen Ausführungsarten besteht der Zweck der Serveranmeldeinformationen im Schutz der Integrität von Eingabedaten, die das Token von einem Server empfangen hat. Bei einigen Ausführungsarten besteht der Zweck der Serveranmeldeinformationen im Schutz der Vertraulichkeit von Eingabedaten, die das Token von einem Server empfangen hat. Bei einigen Ausführungsarten kann die Erzeugung dynamischer Sicherheitsanmeldeinformationen durch das Token von der erfolgreichen Verifizierung der Serveranmeldeinformationen abhängen.
  • Bei einer bestimmten Ausführungsart sind die Eingabedaten als Binärdatenkette mit einer Bitsequenz verschlüsselt. Die Binärdatenkette wird als akustisches Signal auf zwei Codierungsfrequenzen ausgegeben, wobei eine Codierungsfrequenz doppelt so hoch ist wie die andere.
  • Erzeugung dynamischer Sicherheitswerte.
  • Bei einigen Ausführungsarten kann das Token dynamische Sicherheitswerte erzeugen. Bei einigen Ausführungsarten können die erzeugten dynamischen Sicherheitswerte Einmalkennwörter oder dynamische Kennwörter und/oder Antworten auf Anforderungen und/oder elektronische Signaturen für Transaktionsdaten beinhalten. Bei einigen Ausführungsarten kann das Token dem Benutzer erzeugte dynamische Sicherheitswerte anzeigen. Bei einigen Ausführungsarten wird zur Erzeugung der dynamischen Sicherheitswerte kryptografisch mindestens ein geheimer Wert (wie ein kryptografischer Schlüssel) mit mindestens einem dynamischen Wert (wie einem Zeitwert und/oder einem Zählerwert und/oder einer Anforderung und/oder transaktionsbezogenen Daten) kombiniert. Bei einigen Ausführungsarten beinhaltet die kryptografische Kombination die Ausführung eines kryptografischen Algorithmus. Bei einigen Ausführungsarten kann der kryptografische Algorithmus einen symmetrischen Ver- oder Entschlüsselungsalgorithmus wie DES, 3DES oder AES beinhalten. Bei einigen Ausführungsarten kann der kryptografische Algorithmus einen Hash-Algorithmus oder verschlüsselten Hash-Algorithmus wie SHA-1 beinhalten.
  • Bei einigen Ausführungsarten beinhaltet das Token eine Komponente zur Datenverarbeitung für die Ausführung eines kryptografischen Algorithmus, der vom Token für die Erzeugung dynamischer Sicherheitswerte verwendet wird. Bei einigen Ausführungsarten beinhaltet das Token eine Speicherkomponente für die Speicherung eines oder mehrerer kryptografischer Geheimwerte, die vom Token für die Erzeugung dynamischer Sicherheitswerte verwendet werden. Bei einigen Ausführungsarten sind die gespeicherten kryptografischen Geheimwerte symmetrische Schlüssel, die gemeinsam mit einem Authentisierungsserver verwendet werden. Bei einigen Ausführungsarten werden die gespeicherten kryptografischen Geheimwerte im Token in einem permanenten Speicher gespeichert und für mehrere Erzeugungen dynamischer Sicherheitswerte verwendet. Bei einigen Ausführungsarten werden die gespeicherten kryptografischen Geheimwerte nur für eine Erzeugung eines dynamischen Sicherheitswerts verwendet, und diese Geheimwerte werden bei einigen Ausführungsarten im nicht permanenten Speicher gespeichert und/oder nach der Erzeugung des Sicherheitswerts aktiv aus dem Speicher gelöscht.
  • Bei einigen Ausführungsarten kann das Token mit einem zweiten Sicherheitsgerät kommunizieren, und die dynamischen Sicherheitswerte werden vom Token zusammen mit diesem zweiten Sicherheitsgerät erzeugt. Bei einigen Ausführungsarten ist das Token so ausgelegt, dass es einen Befehl an das zweite Sicherheitsgerät senden, eine Antwort vom zweiten Sicherheitsgerät empfangen und einen dynamischen Sicherheitswert aus dieser Antwort ableiten kann. Bei einigen Ausführungsarten speichert das zweite Sicherheitsgerät einen sicheren Schlüssel und das Token weist das zweite Sicherheitsgerät an, diesen geheimen Schlüssel in einer kryptografischen Berechnung zu verwenden und ein Ergebnis dieser kryptografischen Berechnung an das Token zurückzugeben. Bei einigen Ausführungsarten kombiniert das zweite Sicherheitsgerät den von ihm gespeicherten geheimen Schlüssel kryptografisch mit einem oder mehreren vom Token empfangenen Datenelementen wie Anforderungen oder Transaktionsdaten. Bei einigen Ausführungsarten kombiniert das zweite Sicherheitsgerät den von ihm gespeicherten geheimen Schlüssel kryptografisch mit einem oder mehreren von ihm gespeicherten und intern verwalteten Datenelementen wie einem Zähler. Bei einigen Ausführungsarten leitet das Token aus der Antwort vom zweiten Sicherheitsgerät einen geheimen Schlüssel ab, den es kryptografisch mit einer dynamischen Variable kombiniert, um einen dynamischen Sicherheitswert zu erzeugen. Bei einigen Ausführungsarten kann die dynamische Variable aus einer Dateneingabe (wie einer Anforderung oder einer oder mehreren transaktionsbezogenen Datenelementen) in das Token über die Schnittstelle für die akustische Eingabe des Token abgeleitet werden. Bei einigen Ausführungsarten beinhaltet das zweite Sicherheitsgerät eine Smartcard. Bei einigen Ausführungsarten beinhaltet die Smartcard eine Smartcard für Finanzdienste, die mit dem EMV-Standard (Europay, MasterCard, Visa) kompatibel ist, und das Token kann mit EMV-kompatiblen Smartcards kommunizieren.
  • PIN-Bearbeitung.
  • Bei einigen Ausführungsarten kann das Token eine vom Benutzer bereitgestellte PIN empfangen. Bei einigen Ausführungsarten kann das Token eine vom Benutzer bereitgestellte PIN zur Verifizierung an ein zweites Sicherheitsgerät (wie eine Smartcard) weiterleiten. Bei einigen Ausführungsarten kann das Token sämtliche Kopien in allen Formaten einer derartigen PIN nach der Verifizierung dieser PIN aus seinem Speicher entfernen. Bei einigen Ausführungsarten kann das Token die Speicherorte, an denen eine derartige PIN temporär gespeichert wurde, nach der Verifizierung der PIN aktiv löschen oder überschreiben.
  • Gleichzeitiges Bestehen einer Schnittstelle für die akustische Eingabe und einer Schnittstelle für die optische Eingabe im selben Token.
  • Bei einigen Ausführungsarten gibt die Anwendung auf dem Computergerät des Benutzers (unter anderem PCs, Tablet-Computer oder Smartphones) ein akustisches Signal aus, über das Eingabedaten für den Empfang durch das Token des Benutzers verschlüsselt werden. Bei einigen Ausführungsarten verfügt das Computergerät des Benutzers über eine Anzeige, auf der optisch verschlüsselte Eingabedaten für den Empfang durch das Token des Benutzers angezeigt werden. Die optisch verschlüsselten Daten können beispielsweise in einem blinkenden Muster verschlüsselt werden. Bei einigen Ausführungsarten gibt das Computergerät des Benutzers ein akustisches Signal aus, das Eingabedaten für den Empfang durch das Token des Benutzers verschlüsselt, und es verfügt über eine Anzeige, auf der ein blinkendes Muster angezeigt wird, das ebenfalls Eingabedaten für den Empfang durch das Token des Benutzers verschlüsselt. Bei einigen Ausführungsarten beinhalten die Daten, die das Computergerät des Benutzers akustisch ausgibt, und die Daten, die optisch verschlüsselt werden, im Wesentlichen dieselben Informationen. Bei einigen Ausführungsarten unterscheiden sich die Daten, die das Computergerät des Benutzers akustisch ausgibt, von den Daten, die optisch verschlüsselt werden. Bei einigen Ausführungsarten ergänzen die Daten, die das Computergerät des Benutzers akustisch ausgibt, die Daten, die optisch verschlüsselt werden.
  • Bei einigen Ausführungsarten verfügt das Token sowohl über eine Schnittstelle für die akustische Eingabe als auch über eine Schnittstelle für die optische Eingabe und es kann optional auch mit einer Schnittstelle für die manuelle Benutzereingabe ausgestattet sein.
  • Bei einigen Ausführungsarten kann das Token vom Benutzer eine Anweisung dazu erhalten, ob das Token Eingabedaten über die Schnittstelle für die optische Eingabe oder über die Schnittstelle für die akustische Eingabe empfangen soll. Bei einigen Ausführungsarten kann das Token nach der Anweisung des Benutzers zur Verwendung der Schnittstelle für die optische Eingabe die Schnittstelle für die optische Eingabe aktivieren und die Schnittstelle für die akustische Eingabe deaktivieren. Bei einigen Ausführungsarten kann das Token nach der Anweisung des Benutzers zur Verwendung der Schnittstelle für die akustische Eingabe die Schnittstelle für die akustische Eingabe aktivieren und die Schnittstelle für die optische Eingabe deaktivieren.
  • Bei einigen Ausführungsarten können die Schnittstelle für die akustische Eingabe und die Schnittstelle für die optische Eingabe gleichzeitig aktiviert sein. Bei einigen Ausführungsarten sind standardmäßig sowohl die Schnittstelle für die akustische Eingabe als auch die Schnittstelle für die optische Eingabe aktiviert. Bei einigen Ausführungsarten kann das Token Daten gleichzeitig über die Schnittstelle für die akustische Eingabe und die Schnittstelle für die optische Eingabe empfangen, wenn die Schnittstelle für die akustische Eingabe und die Schnittstelle für die optische Eingabe beide gleichzeitig aktiviert sind. Bei einigen Ausführungsarten kann das Token die Daten, die es über die Schnittstelle für die optische Eingabe empfangen hat, mit den Daten, die es über die Schnittstelle für die akustische Eingabe empfangen hat, assemblieren oder kombinieren. Beispiel: Wenn eine Nachricht für den Empfang durch das Token aus mehreren Datenblöcken besteht, kann das Token einige Datenblöcke der Nachricht über die Schnittstelle für die optische Eingabe und andere Datenblöcke der Nachricht über die Schnittstelle für die akustische Eingabe empfangen und das Token kann diese Datenblöcke kombinieren, um die vollständige Nachricht zu assemblieren. Dies kann zum Beispiel der Fall sein, wenn das Computergerät des Benutzers dieselbe Nachricht über die Schnittstelle für die optische Eingabe und die Schnittstelle für die akustische Eingabe sendet, aufgrund von Übertragungsfehlern sowohl im optischen als auch im akustischen Kanal aber einige Datenblöcke möglicherweise nicht korrekt über die Schnittstelle für die optische Eingabe und andere Datenblöcke nicht korrekt über die Schnittstelle für die akustische Eingabe empfangen wurden. Bei einigen Ausführungsarten kann das Token Daten gleichzeitig über die Schnittstelle für die akustische Eingabe und die Schnittstelle für die optische Eingabe empfangen und es wird davon ausgegangen, dass dieselbe Nachricht sowohl über die Schnittstelle für die akustische Eingabe als auch über die Schnittstelle für die optische Eingabe gesendet wird. Bei einigen Ausführungsarten kann das Token Daten gleichzeitig über die Schnittstelle für die akustische Eingabe und die Schnittstelle für die optische Eingabe empfangen und der Nachrichtenempfang wird als erfolgreich eingestuft, sobald eine Nachricht entweder über die Schnittstelle für die akustische Eingabe oder über die Schnittstelle für die optische Eingabe empfangen wurde.
  • Bei einigen Ausführungsarten kann das Token eine der Schnittstellen für die akustische oder die optische Eingabe für den Datenempfang auswählen, ohne eine diesbezügliche Anweisung des Benutzers zu empfangen.
  • Bei einigen Ausführungsarten verfügt das Token über einen Mechanismus zur Auswahl der Eingabeschnittstelle, über den eine der Schnittstellen für die akustische oder die optische Eingabe ausgewählt werden kann. Bei einigen Ausführungsarten kann der Mechanismus zur Auswahl der Eingabeschnittstelle über eine Komponente zur Datenverarbeitung wie einen Mikroprozessor oder eine logische Schaltung umgesetzt werden.
  • Bei einigen Ausführungsarten entscheidet der Mechanismus zur Auswahl der Eingabeschnittstelle anhand von heuristischen Regeln auf der Grundlage bestimmter Eigenschaften der über die Schnittstelle für die akustische Eingabe und die Schnittstelle für die optische Eingabe empfangenen Signale, welche Eingabeschnittstelle für den Datenempfang bevorzugt wird. Bei einigen Ausführungsarten analysiert das Token die Signale der Schnittstelle für die akustische Eingabe und der Schnittstelle für die optische Eingabe gleichzeitig und entscheidet je nach Analyseergebnis, ob die Signale der Schnittstelle für die akustische Eingabe oder der Schnittstelle für die optische Eingabe weiterverarbeitet werden müssen, um Daten demodulieren und die Nachricht empfangen zu können. Bei einigen Ausführungsarten werden im Rahmen dieser Analyse der Energie- und/oder der Frequenzinhalt der optischen und/oder akustischen Signale analysiert. Bei einigen Ausführungsarten wird im Rahmen dieser Analyse die Energie in einem bestimmten Frequenzbereich des empfangenen Signals mit einem Referenzwert verglichen.
  • Bei einigen Ausführungsarten kann das Token auf folgende Weise eine der Schnittstellen für die akustische oder die optische Eingabe für den Datenempfang auswählen. Zunächst versucht das Token eine bestimmte Zeit lang (z. B. eine Sekunde oder sogar weniger als eine Sekunde), mindestens einige Daten über eine der Schnittstellen für die akustische oder die optische Eingabe zu empfangen. Wenn dieser Vorgang erfolgreich ist, wählt das Token diese Eingabeschnittstelle aus und empfängt weitere Daten über die ausgewählte Eingabeschnittstelle. Wenn der Vorgang fehlschlägt, wiederholt das Token den Auswahlprozess bei der anderen Eingabeschnittstelle. Dieser Auswahlprozess kann so lange fortgesetzt werden, bis das Token über eine der Eingabeschnittstellen erfolgreich Daten empfängt.
  • Bei einigen Ausführungsarten erkennt das Token Übertragungsprobleme beim Datenempfang über die ausgewählte Eingabeschnittstelle. Bei einigen Ausführungsarten kann das Token bei Übertragungsproblemen bei der ausgewählten Eingabeschnittstelle zur Phase der Schnittstellenauswahl zurückkehren. Bei einigen Ausführungsarten kann die Entscheidung zur Rückkehr in die Phase der Schnittstellenauswahl von vordefinierten Kriterien abhängen. Bei einigen Ausführungsarten können für diese vordefinierten Kriterien Eigenschaften der erkannten Übertragungsfehler berücksichtigt werden. Bei einigen Ausführungsarten kann das Token beispielsweise entscheiden, in die Phase der Schnittstellenauswahl zurückzukehren, wenn ein vordefinierter Schwellenwert für die Anzahl der Übertragungsfehler per Zeiteinheit überschritten wurde.
  • In Übereinstimmung mit einem Aspekt der vorliegenden Erfindung erzeugt ein Token für eine starke Authentisierung dynamische Sicherheitswerte, indem es ein akustisches Signal von einem dezentralen Computersystem am Authentisierungstoken empfängt, die Eingabedaten durch Demodulation des akustischen Signals erhält und den dynamischen Sicherheitswert am Authentisierungstoken erzeugt, wobei hierzu Eingabedaten vom akustischen Signal wiederhergestellt und die wiederhergestellten Eingabedaten verarbeitet werden. Das Authentisierungstoken kann eine Kommunikationsschnittstelle für die Kommunikation mit einem entfernbaren Sicherheitsgerät beinhalten, und der Erzeugungsschritt kann die Erzeugung des dynamischen Sicherheitswerts durch das Authentisierungstoken zusammen mit dem entfernbaren Sicherheitsgerät beinhalten. Diese Methode kann zusätzlich den Empfang eines optischen Signals mit weiteren Eingabedaten beinhalten, und der Erzeugungsschritt kann die Kombination der wiederhergestellten Eingabedaten mit den weiteren Eingabedaten beinhalten.
  • Ein anderer Aspekt der Erfindung beinhaltet eine Methode für den Benutzerzugriff auf eine serverbasierte Remoteanwendung über ein Computergerät, das mit dem Anwendungsserver z. B. über das Internet kommuniziert. Die Methode kann folgende Schritte beinhalten.
    • – Bereitstellen eines Authentisierungstoken mit einer Schnittstelle für die akustische Eingabe für den Benutzer. Bei dem Authentisierungstoken kann es sich dabei um eines der in den vorstehenden Absätzen beschriebenen Authentisierungstoken handeln. Bei einigen Ausführungsarten wird dem Benutzer auch ein zweites Sicherheitsgerät wie eine Smartcard zur Verfügung gestellt, das zusammen mit dem Authentisierungstoken zur Erzeugung eines dynamischen Sicherheitswerts verwendet wird.
    • – Assemblieren der Eingabedaten für die Eingabe in das besagte Authentisierungstoken. Diese Eingabedaten können z. B. Anforderungen, transaktionsbezogene Daten oder Informationen zum Transaktionskontext beinhalten. Bei einigen Ausführungsarten können die Eingabedaten Serveranmeldeinformationen beinhalten. Um die Serveranmeldeinformationen zu erhalten, kann der Server optional zunächst Serveranmeldeinformationen erzeugen. Der Server kann die Serveranmeldeinformationen über einen geheimen Schlüssel und einen kryptografischen Algorithmus erzeugen. Bei dem kryptografischen Algorithmus kann es sich um einen symmetrischen kryptografischen Algorithmus handeln. Bei einigen Ausführungsarten kann der geheime Schlüssel für die Erzeugung der Serveranmeldeinformationen zusammen mit dem Authentisierungstoken des Benutzers verwendet werden.
    • – Senden der Eingabedaten an das Computergerät des Benutzers. Auf dem Computergerät des Benutzers kann eine Computeranwendung wie ein Webbrowser ausgeführt werden. Die Eingabedaten können in eine oder mehrere Webseiten eingebettet sein, auf die die serverbasierte Anwendung über den Browser des Computergeräts zugreift.
    • – Ausgeben (am Computergerät des Benutzers) einer modulierten akustischen Signalverschlüsselung für die Eingabedaten, die vom Authentisierungstoken empfangen und demoduliert werden, um die Eingabedaten wiederherzustellen. Das Authentisierungstoken kann wie in den vorstehenden Absätzen beschrieben das akustische Signal empfangen und demodulieren und die Eingabedaten aus dem demodulierten akustischen Signal wiederherstellen. Bei einigen Ausführungsarten kann am Computergerät des Benutzers auch ein optisches Signal ausgegeben werden. Bei einigen Ausführungsarten kann das optische Signal Daten mit allen oder mit einem Teil der Eingabedaten verschlüsseln.
    • – Empfangen (vom Benutzer) eines dynamischen Sicherheitswerts, der vom Authentisierungstoken erzeugt wurde. Das Authentisierungstoken kann den dynamischen Sicherheitswert wie in den vorstehenden Absätzen beschrieben erzeugen. Bei einigen Ausführungsarten kann das Authentisierungstoken eine Kommunikationsschnittstelle für die Kommunikation mit einem entfernbaren zweiten Sicherheitsgerät beinhalten und das Authentisierungstoken erzeugt den dynamischen Sicherheitswert zusammen mit dem entfernbaren zweiten Sicherheitsgerät. Bei einigen Ausführungsarten verarbeitet das Authentisierungstoken die Eingabedaten, um einen dynamischen Sicherheitswert zu erzeugen. Bei einigen Ausführungsarten wird der dynamische Sicherheitswert durch die kryptografische Kombination einer dynamischen Variable mit einem geheimen Schlüssel erzeugt. Bei einigen Ausführungsarten beinhaltet die kryptografische Kombination die Verwendung eines symmetrischen kryptografischen Algorithmus. Bei einigen Ausführungsarten beinhaltet die dynamische Variable eine Anforderung. Bei einigen Ausführungsarten beinhaltet die dynamische Variable transaktionsbezogene Daten. Bei einigen Ausführungsarten beinhaltet die dynamische Variable einen Zeitwert. Bei einigen Ausführungsarten beinhaltet die dynamische Variable einen Zähler. Bei einigen Ausführungsarten beinhaltet die dynamische Variable ein Datenelement aus den von der serverbasierten Anwendung empfangenen Eingabedaten. Bei einigen Ausführungsarten wird der dynamische Sicherheitswert über einen Schlüssel erzeugt, der zusammen mit der serverbasierten Anwendung verwendet wird. Bei einigen Ausführungsarten beinhalten die Eingabedaten Serveranmeldeinformationen und das Authentisierungstoken verifiziert die Serveranmeldeinformationen vor der Erzeugung des dynamischen Sicherheitswerts. Bei einigen Ausführungsarten verwendet das Authentisierungstoken einen symmetrischen kryptografischen Algorithmus mit einem geheimen Schlüssel, der zusammen mit dem Anwendungsserver zur Verifizierung der Serveranmeldeinformationen verwendet wird. Bei einigen Ausführungsarten erzeugt das Authentisierungstoken den dynamischen Sicherheitswert unter der Voraussetzung, dass die Verifizierung der Serveranmeldeinformationen erfolgreich war. Bei einigen Ausführungsarten beinhaltet das Authentisierungstoken eine sichere Schnittstelle für die Benutzerausgabe, über die es den dynamischen Sicherheitswert an den Benutzer ausgibt. Bei einigen Ausführungsarten empfängt der Benutzer den dynamischen Sicherheitswert und gibt diesen auf einer Webseite für die serverbasierte Anwendung ein.
    • – Verifizieren des empfangenen dynamischen Sicherheitswerts. Der Anwendungsserver kann den empfangenen dynamischen Sicherheitswert über einen kryptografischen Algorithmus verifizieren. Bei einigen Ausführungsarten kombiniert der Anwendungsserver kryptografisch eine dynamische Referenzvariable mit einem geheimen Referenzschlüssel, um den empfangenen dynamischen Sicherheitswert zu verifizieren. Bei einigen Ausführungsarten erzeugt der Anwendungsserver einen Referenzsicherheitswert und vergleicht diesen mit dem empfangenen dynamischen Sicherheitswert. Bei einigen Ausführungsarten berechnet der Anwendungsserver den Referenzsicherheitswert durch die kryptografische Kombination einer dynamischen Referenzvariable mit einem geheimen Referenzschlüssel. Bei einigen Ausführungsarten beinhaltet die kryptografische Kombination die Ausführung eines symmetrischen kryptografischen Algorithmus. Bei einigen Ausführungsarten kommt ein geheimer Schlüssel zum Einsatz, den der Anwendungsserver zusammen mit dem Authentisierungstoken oder mit einem entfernbaren zweiten Sicherheitsgerät verwendet, mit dem zusammen das Authentisierungstoken den dynamischen Sicherheitswert erzeugt hat.
    • – Durchführen geeigneter Aktionen je nach dem Ergebnis der Verifizierung des dynamischen Sicherheitswerts. Bei einigen Ausführungsarten kann dies beinhalten, dass dem Benutzer bei erfolgreicher Verifizierung der Zugriff auf die serverbasierte Anwendung erteilt wird und dass der Zugriff verweigert wird, wenn die Verifizierung nicht erfolgreich war. Bei einigen Ausführungsarten kann dies beinhalten, dass bei erfolgreicher Verifizierung eine vom Benutzer angeforderte Transaktion durchgeführt wird und dass die Transaktion nicht durchgeführt wird, wenn die Verifizierung nicht erfolgreich war.
  • Bei einigen Ausführungsarten kann der Anwendungsserver einen oder mehrere Servercomputer beinhalten, auf denen eine oder mehrere Softwareanwendungen ausgeführt werden. Bei einigen Ausführungsarten kann der Anwendungsserver einen oder mehrere Webserver beinhalten. Bei einigen Ausführungsarten kann der Anwendungsserver eine oder mehrere Datenbanken für die Datenspeicherung beinhalten. Bei einigen Ausführungsarten kann der Anwendungsserver benutzerbezogene Daten verwenden und/oder speichern. Bei einigen Ausführungsarten kann der Anwendungsserver Informationen zum Authentisierungstoken verwenden und/oder speichern. Bei einigen Ausführungsarten beinhalten die Daten zum Benutzer oder zum Authentisierungstoken einen oder mehrere geheime Schlüssel. Bei einigen Ausführungsarten können einer oder mehrere dieser geheimen Schlüssel zusammen mit dem Authentisierungstoken des Benutzers oder mit einem entfernbaren zweiten Sicherheitsgerät verwendet werden, mit dem zusammen das Authentisierungstoken den dynamischen Sicherheitswert erzeugt hat.
  • Vorteilhafte Auswirkungen
  • Ein wichtiger Vorteil der vorliegenden Erfindung besteht darin, dass ein Token für eine starke Authentisierung, der mit einer akustischen Schnittstelle ausgestattet ist und eine relativ geringe Anzahl an kostengünstigen Komponenten enthält, Eingabedaten mit einer deutlich höheren Datenrate empfangen kann als ein Token für eine starke Authentisierung, der mit einer optischen Schnittstelle mit vergleichbaren Kosten ausgestattet ist.
  • Ein weiterer Vorteil der vorliegenden Erfindung besteht darin, dass ein Token für eine starke Authentisierung mit einer akustischen Schnittstelle, aber ohne Tastenblock (oder mit einem Tastenblock mit nur wenigen Tasten) im Vergleich zu einem Token mit einem Tastenblock, der zumindest über alle Zifferntasten verfügt, wesentlich kompakter ist, aber dennoch Dateneingaben auf für den Benutzer bequeme Weise empfangen kann.
  • Ein weiterer klarer Vorteil der vorliegenden Erfindung besteht darin, dass ein Token für eine starke Authentisierung mit einer akustischen Schnittstelle und einer Demodulationsschaltung bei einigen Ausführungsarten der Erfindung die robuste und zuverlässige Demodulation akustischer Signale selbst bei Vorliegen von Störgeräuschen und einem Mehrfachempfang aufgrund von Reflexionen unterstützt.
  • Kurzbeschreibung der Zeichnungen
  • Die vorstehend angegebenen sowie weitere Merkmale und Vorteile der Erfindung werden anhand der folgenden spezielleren Beschreibung einer Ausführungsart der Erfindung und der zugehörigen Zeichnungen deutlich.
  • zeigt eine typische Ausführung der Erfindung.
  • zeigt schematisch eine andere typische Ausführung der Erfindung.
  • zeigt schematisch eine Demodulationsschaltung anhand eines Aspekts der Erfindung.
  • veranschaulicht in einem Flussdiagramm eine Methode der starken Authentisierung für die Verwendung mit einem Authentisierungstoken anhand eines Aspekts der vorliegenden Erfindung.
  • veranschaulicht in einem Flussdiagramm eine Methode für den sicheren Benutzerzugriff auf eine Remoteanwendung.
  • Detaillierte Beschreibung
  • Einige Ausführungen der vorliegenden Erfindung werden nachfolgend dargestellt. Es werden zwar spezielle Ausführungen dargestellt, dies erfolgt jedoch nur zu Zwecken der Veranschaulichung. Eine Person mit Fachwissen wird erkennen, dass andere Komponenten und Ausstattungen verwendet werden können, ohne vom Wesen und Umfang der Erfindung abzuweichen.
  • zeigt eine typische Ausführung der Erfindung bestehend aus einem Token (100) für die Erzeugung von Sicherheitswerten wie Einmalkennwörtern zur Authentisierung von Benutzern oder von Transaktionssignaturen zur Anzeige der Genehmigung einer Transaktion durch den Benutzer. Hierzu gehört Folgendes:
    • • eine akustische Schnittstelle (110) für den Empfang akustischer Signale, die Eingabedaten für das Token übertragen;
    • • eine vertrauenswürdige Ausgabeschnittstelle (130) wie eine Anzeige oder eine Schnittstelle für die Audioausgabe für die Kommunikation von Informationen wie den besagten Sicherheitswerten oder von zu genehmigenden Transaktionsdaten an den Benutzer;
    • • (optional) eine oder mehrere zusätzliche Schnittstellen für die Dateneingabe wie eine Schnittstelle für die manuelle Dateneingabe durch den Benutzer (120), die z. B. einen Tastenblock und/oder eine Schnittstelle für die optische Dateneingabe (140) mit z. B. einem oder mehreren lichtempfindlichen Elementen wie einer Gruppe lichtempfindlicher Elemente beinhaltet, um Eingabedaten (unter anderem Anforderungen und/oder Transaktionsdaten) zu empfangen und/oder die Genehmigung des Benutzers von Transaktionsdaten zu erfassen;
    • • eine Komponente zur Datenverarbeitung (150) wie einen Mikroprozessor, einen Controller, ein FPGA (Field Programmable Gate Array) oder eine anwendungsspezifische integrierte Schaltung (ASIC), geeignet für kryptografische Vorgänge, für die Erzeugung von Sicherheitswerten (wie dynamischen Kennwörtern und/oder elektronischen Signaturen) und/oder für die Verifizierung von Serveranmeldeinformationen mithilfe von geheimen Werten, die zusammen mit einem Server verwendet werden;
    • • eine Komponente zur Datenspeicherung (160) wie ROM, EEPROM oder batteriegepufferter RAM für die Speicherung von Konfigurationsdaten und/oder geheimen Werten, die einen Zugriffscode für das Token (z. B. eine PIN) und/oder geheime Werte beinhalten können, die zusammen mit einem Server verwendet werden und zur Erzeugung von Sicherheitswerten und/oder zur Verifizierung von Serveranmeldeinformationen dienen;
    • • eine Uhr (170) für die Bereitstellung eines Zeitwerts, der zur Verifizierung von Serveranmeldeinformationen oder Erzeugung von Sicherheitswerten verwendet werden kann.
  • Bei einigen Ausführungsarten kann der Tastenblock (120) weniger Tasten beinhalten als in dargestellt sind. Bei einigen Ausführungsarten kann der Tastenblock (120) mehr Tasten beinhalten als in dargestellt sind.
  • Bei einer Ausführungsart beinhaltet die akustische Schnittstelle (110) ein Mikrofon und eine Demodulationsschaltung.
  • Bei einigen Ausführungsarten beinhaltet die Komponente zur Datenverarbeitung (150) einen Mechanismus zur Auswahl der Eingabeschnittstelle, über den für den Empfang von Eingabedaten entweder die Schnittstelle für die optische Eingabe (140) oder die Schnittstelle für die akustische Eingabe (110) ausgewählt werden kann.
  • zeigt schematisch eine andere typische Ausführung der Erfindung bestehend aus einem ersten Sicherheitsgerät (101) für die Erzeugung von Sicherheitswerten wie Einmalkennwörtern zur Authentisierung von Benutzern oder von Transaktionssignaturen zur Anzeige der Genehmigung einer Transaktion durch den Benutzer und für die Kommunikation mit einem entfernbaren zweiten Sicherheitsgerät (102) wie einer Smartcard, auf das beispielsweise bestimmte kryptografische Vorgänge übertragen werden können. Hierzu gehört Folgendes:
    • • eine akustische Schnittstelle (111) für den Empfang akustischer Signale, die Eingabedaten übertragen;
    • • eine vertrauenswürdige Ausgabeschnittstelle (131) wie eine Anzeige oder eine Schnittstelle für die Audioausgabe für die Kommunikation von Informationen wie den besagten Sicherheitswerten oder von zu genehmigenden Transaktionsdaten an den Benutzer;
    • • (optional) zusätzliche Schnittstellen für die Dateneingabe wie eine Schnittstelle für die manuelle Dateneingabe durch den Benutzer (121), die z. B. einen Tastenblock und/oder eine Schnittstelle für die optische Dateneingabe (141) mit z. B. einem oder mehreren lichtempfindlichen Elementen wie einer Gruppe lichtempfindlicher Elemente beinhaltet, um Eingabedaten (unter anderem Anforderungen und/oder Transaktionsdaten) zu empfangen und/oder die Genehmigung des Benutzers von Transaktionsdaten zu erfassen;
    • • eine Komponente zur Datenverarbeitung (151) wie einen Mikroprozessor, einen Controller, ein FPGA (Field Programmable Gate Array) oder eine anwendungsspezifische integrierte Schaltung (ASIC), möglicherweise geeignet für kryptografische Vorgänge, für die Erzeugung von Sicherheitswerten (wie dynamischen Kennwörtern und/oder elektronischen Signaturen) und/oder für die Verifizierung von Serveranmeldeinformationen möglicherweise mithilfe von geheimen Werten, die zusammen mit einem Server verwendet werden, und zur Erzeugung und/oder Verifizierung, die möglicherweise zusammen mit dem entfernbaren Sicherheitsgerät durchgeführt wird;
    • • eine Komponente zur Datenspeicherung (161) wie ROM, EEPROM oder batteriegepufferter RAM z. B. für die Speicherung von Konfigurationsdaten und/oder geheimen Werten, die geheime Werte beinhalten können, die zusammen mit einem Server verwendet werden und zur Erzeugung von Sicherheitswerten und/oder Verifizierung von Serveranmeldeinformationen dienen;
    • • eine Schnittstelle (181) z. B. mit einem Smartcardanschluss (182) für die Interaktion mit einem entfernbaren Sicherheitsgerät (102).
  • Bei einigen Ausführungsarten kann der Tastenblock (121) weniger Tasten beinhalten als in dargestellt sind. Bei einigen Ausführungsarten kann der Tastenblock (121) mehr Tasten beinhalten als in dargestellt sind.
  • Bei einer Ausführungsart beinhaltet die akustische Schnittstelle (111) ein Mikrofon und eine Demodulationsschaltung.
  • Bei einigen Ausführungsarten beinhaltet die Komponente zur Datenverarbeitung (151) einen Mechanismus zur Auswahl der Eingabeschnittstelle, über den für den Empfang von Eingabedaten entweder die Schnittstelle für die optische Eingabe (141) oder die Schnittstelle für die akustische Eingabe (111) ausgewählt werden kann.
  • Bei einigen Ausführungsarten beinhaltet die Schnittstelle (181) eine Schnittstelle für die Datenkommunikation, die zum Austausch von Daten mit dem entfernbaren Sicherheitsgerät dient. Bei einigen Ausführungsarten ist das entfernbare Sicherheitsgerät (102) eine Smartcard und die Schnittstelle für die Datenkommunikation beinhaltet einen Smartcardleser für den Austausch von Smartcardbefehlen und -antworten mit der Smartcard. Bei einigen Ausführungsarten kann das entfernbare Sicherheitsgerät (102) ein Kryptogramm erzeugen und die Schnittstelle für die Datenkommunikation (181) des ersten Sicherheitsgeräts (101) kann einen Befehl an das zweite Sicherheitsgerät (102) senden, um ein Kryptogramm zu erzeugen und vom zweiten Sicherheitsgerät (102) das zur Antwort auf diesen Befehl erzeugte Kryptogramm zu erhalten. Bei einigen Ausführungsarten erzeugt das zweite Sicherheitsgerät (102) das Kryptogramm über einen symmetrischen kryptografischen Algorithmus und einen geheimen Schlüssel. Bei einigen Ausführungsarten verwendet das erste Sicherheitsgerät (101) bei der Erzeugung der Sicherheitswerte ein vom zweiten Sicherheitsgerät (102) erhaltenes Kryptogramm. Bei einigen Ausführungsarten beinhaltet die Erzeugung eines Sicherheitswerts durch das erste Sicherheitsgerät (101) die Auswahl von Bits aus Daten, die vom zweiten Sicherheitsgerät (102) erhalten wurden. Bei einigen Ausführungsarten beinhaltet die Auswahl von Bits aus Daten, die vom zweiten Sicherheitsgerät (102) erhalten wurden, die Auswahl von Bits aus einem Kryptogramm, das vom zweiten Sicherheitsgerät (102) erzeugt und vom ersten Sicherheitsgerät (101) erhalten wurde. Bei einigen Ausführungsarten kann die Komponente zur Datenverarbeitung (151) bei der Erzeugung von Sicherheitswerten kryptografische Vorgänge durchführen, wobei die kryptografischen Vorgänge einen kryptografischen Schlüssel beinhalten, der aus Daten abgeleitet ist, die vom zweiten Sicherheitsgerät (102) erzeugt und vom ersten Sicherheitsgerät (101) erhalten wurden. Bei einigen Ausführungsarten beinhalten diese kryptografischen Vorgänge die Erzeugung eines NachrichtenAuthentisierungscodes (Message Authentication Code, MAC) durch die Eingabe von Transaktionsdaten in das erste Sicherheitsgerät (101).
  • Bei einigen Ausführungsarten kann das erste Sicherheitsgerät (101) mit einer Smartcard (102) kommunizieren; einen Smartcardbefehl an die Smartcard (102) senden, mit dem die Smartcard (102) angewiesen wird, über einen symmetrischen kryptografischen Algorithmus mit einem geheimen Schlüssel, der auf der Smartcard (102) gespeichert ist, und einem auf der Smartcard (102) gespeicherten und verwalteten Zähler ein Kryptogramm zu erzeugen; das von der Smartcard (102) erzeugte Kryptogramm von der Smartcard (102) empfangen; einen symmetrischen Schlüssel aus dem empfangenen Kryptogramm ableiten; mithilfe des abgeleiteten symmetrischen Schlüssels über eine Reihe von transaktionsbezogenen Daten einen MAC erzeugen; den MAC in einen dynamischen Sicherheitswert umwandeln und dem Benutzer diesen dynamischen Sicherheitswert über die Ausgabeschnittstelle (131) anzeigen. Bei einigen Ausführungsarten empfängt das erste Sicherheitsgerät (101) aus der Reihe von transaktionsbezogenen Daten mindestens ein Element über die Schnittstelle für die akustische Eingabe (111).
  • zeigt schematisch eine Demodulationsschaltung (300) anhand eines Aspekts der Erfindung.
  • Bei einer Ausführungsart ist ein Eingabeknoten (310) der Demodulationsschaltung (300) mit einem Mikrofon verbunden, das ein akustisches Signal empfängt. Optional beinhaltet die Demodulationsschaltung (300) einen Vorverstärker (320), der das Eingabesignal am Eingabeknoten (310) selektiv verstärkt. Das optional selektiv verstärkte Eingabesignal wird auf der einen Seite in die Phasenregelschleife (330) und auf der anderen Seite in alle Demodulatoren (340 und 341) eingespeist. Die Phasenregelschleife (330) ist auf eine Grundfrequenz eingestellt und erzeugt eine Reihe von Referenzsignalen. Jedes Referenzsignal hat eine bestimmte Frequenz, bei der es sich um ein exakt ganzzahliges Vielfaches der Grundfrequenz handelt, auf die die Phasenregelschleife (330) synchronisiert ist. Die Frequenzen der Referenzsignale entsprechen den Codierungsfrequenzen, bei denen davon ausgegangen wird, dass sie für die Modulation des akustischen Eingabesignals verwendet wurden. Die Phasenregelschleife (330) übermittelt an jeden Demodulator (340 und 341) eines dieser Referenzsignale. Jeder Demodulator (340, 341) kombiniert das Eingabesignal mit dem Referenzsignal, das er von der Phasenregelschleife (330) empfängt, und gibt ein Signal mit einer Niederfrequenzkomponente aus, das die Stärke des Eingabesignals auf der Frequenz des Referenzsignals anzeigt, das der Demodulator (340, 341) von der Phasenregelschleife (330) empfängt. Die Ausgabesignale jedes Demodulators (340, 341) werden von einem Tiefpassfilter (350, 351) gefiltert, und die Ausgabe jedes Tiefpassfilters (350, 351) wird in einen Ratiodetektor (360) eingespeist, der die Signale des Tiefpassfilters (350, 351) vergleicht und an der Ausgabeklemme (370) ein digitales Signal ausgibt, das anzeigt, bei welcher Codierungsfrequenz das Eingabesignal am stärksten ist. Da ein direkt empfangenes Signal im Allgemeinen stärker als ein reflektiertes (und verzögertes) Signal ist, werden Verzögerungen des Eingabesignals aufgrund von Reflexionen effizient unterdrückt. In sind nur jeweils zwei Demodulatoren und zugehörige Tiefpassfilter dargestellt. Selbstverständlich kann bei einigen Ausführungsarten die Anzahl der Demodulatoren und zugehörigen Tiefpassfilter und damit die Anzahl der Codierungsfrequenzen größer sein.
  • Bei einigen Ausführungsarten ist eine Komponente zur Datenverarbeitung mit der Ausgabeklemme (370) der Demodulationsschaltung (300) verbunden, um das digitale Ausgabesignal weiterzuverarbeiten und die Eingabedaten wiederherzustellen und zu verarbeiten. Bei einigen Ausführungsarten kann die Komponente zur Datenverarbeitung einen Mikroprozessor, einen Mikrocontroller, ein FPGA (Field Programmable Gate Array) oder eine anwendungsspezifische integrierte Schaltung (ASIC) beinhalten.
  • Bei einigen Ausführungsarten beinhaltet der Vorverstärker (320) einen Bandbreitenfilter, der Frequenzen unterhalb der untersten Codierungsfrequenz und oberhalb der höchsten Codierungsfrequenz unterdrückt. Da die Stärke des Eingabesignals auf Frequenzen außerhalb dieses Bereichs nur auf Störgeräuschen beruhen kann, trägt dies zur Beseitigung von Störgeräuschen bei. Bei einigen Ausführungsarten beinhaltet der Vorverstärker (320) eine Funktion zur automatischen Verstärkungsregelung.
  • Bei einigen Ausführungsarten entspricht die Grenzfrequenz des Tiefpassfilters (350, 351) mehr oder weniger der angenommenen Baud-Rate des Eingabesignals. Bei einigen bestimmten Ausführungsarten ist die Grenzfrequenz des Tiefpassfilters (350, 351) weniger als doppelt so hoch wie die angenommene Baud-Rate des Eingabesignals.
  • Bei einigen Ausführungsarten hat die Phasenregelschleife (330) einen sehr kleinen Fangbereich. Sie arbeitet auf einer mehr oder weniger festen Grundfrequenz, und es sind nur sehr geringe Abweichungen möglich, um eine Phasenangleichung an diese Grundfrequenz sicherzustellen. Es ist zu beachten, dass die Phasenregelschleife (330) auch eine Angleichung an ganzzahlige Vielfache der Grundfrequenz vornehmen kann.
  • Bei einigen Ausführungsarten beinhaltet die Phasenregelschleife eine digitale Phasenregelschleife. Bei einigen Ausführungsarten beinhaltet die Phasenregelschleife einen numerisch gesteuerten Oszillator.
  • Bei einigen Ausführungsarten beinhalten die Demodulatoren einen Synchrondemodulator für die Amplitudenmodulation (AM). Bei einigen Ausführungsarten beinhalten die Demodulatoren einen Produktdetektor. Bei einigen Ausführungsarten multipliziert jeder Demodulator effektiv das Eingabesignal mit dem von der Phasenregelschleife (330) empfangenen Referenzsignal auf der Frequenz fx. Ihr Ausgabesignal verfügt deshalb über eine Niederfrequenzkomponente (f_low = fx – fx = DC) und eine Hochfrequenzkomponente (f_high = fx + fx = 2·fx). Die Hochfrequenz wird über den mit diesem Demodulator verbundenen Tiefpassfilter entfernt oder zumindest abgeschwächt. Die meisten Störgeräusche im empfangenen Eingabesignal werden deshalb über diesen Tiefpassfilter minimiert. Bei einigen Ausführungsarten können die Demodulatoren einen Inverter beinhalten. Bei einigen Ausführungsarten können die Demodulatoren zwei Mischstufen beinhalten.
  • Bei einigen Ausführungsarten entspricht die niedrigste Codierungsfrequenz der Grundfrequenz.
  • Bei anderen Ausführungsarten gibt es zwei Codierungsfrequenzen.
  • Bei weiteren anderen Ausführungsarten sind die Codierungsfrequenzen ganzzahlige Vielfache der niedrigsten Codierungsfrequenz.
  • veranschaulicht in dem Flussdiagramm 400 Schritte zur Verwendung mit einem Token für eine starke Authentisierung (100/101), um starke Sicherheitswerte zu erzeugen. Auch wenn die Schritte des Flussdiagramms 400 nachfolgend in Bezug auf das Gerät aus den bis beschrieben werden, erkennt eine Person mit Fachwissen anhand der Beschreibung in diesem Dokument, dass die Methode auch mit anderen Geräten durchgeführt werden kann, ohne vom Umfang der vorliegenden Erfindung abzuweichen.
  • Bei Block 402 wird ein akustisches Signal mit Eingabedaten von einem dezentralen Computersystem empfangen. Das akustische Signal kann an einem Authentisierungstoken 100/101 von einem Computersystem wie einem PC, einem Tablet-Computer oder einem Smartphone oder von einem anderen Computer/Verarbeitungsgerät empfangen werden, mit dem der Benutzer interagiert. Bei dem Authentisierungstoken (100/101) kann es sich dabei um eines der in den vorstehenden Absätzen beschriebenen Authentisierungstoken mit einer Schnittstelle für die akustische Eingabe (111) handeln. Die Eingabedaten können Daten beinhalten, die zur Authentisierung/Validierung verwendet werden, wie Anforderungen, Transaktionsdaten oder Serveranmeldeinformationen.
  • Bei Block 404 werden Eingabedaten durch die Demodulation des akustischen Signals erhalten. Das akustische Signal kann über eine Demodulationsschaltung 300 demoduliert werden.
  • Bei Block 404 werden die dynamischen Sicherheitswerte erzeugt. Die dynamischen Sicherheitswerte können wie in einem der vorstehenden Absätze beschrieben am Authentisierungstoken (100/101) erzeugt werden. Der dynamische Sicherheitswert kann am Authentisierungstoken 100/101 erzeugt werden, indem Eingabedaten vom demodulierten akustischen Signal wiederhergestellt und die wiederhergestellten Eingabedaten mit der Komponente zur Datenverarbeitung 150/151 verarbeitet werden. Das Authentisierungstoken 100/101 kann eine Kommunikationsschnittstelle (182) für die Kommunikation mit einem entfernbaren Sicherheitsgerät (102) wie einer Smartcard beinhalten, und der Erzeugungsschritt kann die Erzeugung des dynamischen Sicherheitswerts durch das Authentisierungstoken (100/101) zusammen mit dem entfernbaren Sicherheitsgerät (102) beinhalten. Die Authentisierungsmethode kann zusätzlich den Empfang eines optischen Signals mit weiteren Eingabedaten beinhalten, und der Erzeugungsschritt kann die Kombination der wiederhergestellten Eingabedaten mit den weiteren Eingabedaten beinhalten.
  • zeigt verschiedene Schritte einer Methode (500) anhand eines Aspekts der Erfindung für den sicheren Benutzerzugriff auf eine Remoteanwendung. Bei einigen Ausführungsarten können einige Schritte in einer anderen Reihenfolge als hier beschrieben ausgeführt werden. Bei einigen Ausführungsarten können einige Schritte entfallen. Bei einigen Ausführungsarten können zusätzliche Schritte durchgeführt werden.
  • Bei Schritt 501 wird dem Benutzer ein Authentisierungstoken mit einer Schnittstelle für die akustische Eingabe (wie eines der Authentisierungstoken (100/101), die in einem der vorstehenden Absätze beschrieben sind) zur Verfügung gestellt. Beim (optionalen) Schritt 502 wird dem Benutzer auch ein entfernbares zweites Sicherheitsgerät (102) wie eine Smartcard (dies kann eine mit dem EMV-Standard kompatible Karte für Finanzdienste sein) zur Verfügung gestellt, und dieses kann z. B. zusammen mit dem Authentisierungstoken (100/101) verwendet werden (in diesem Fall kann das Authentisierungstoken (100/101) eine Kommunikationsschnittstelle für die Kommunikation mit dem zweiten Sicherheitsgerät (102) beinhalten).
  • Bei Schritt 505 greift der Benutzer über ein Computergerät (wie einen PC, einen Tablet-Computer oder ein Smartphone) auf die Remoteanwendung (auf einem Anwendungsserver) zu, z. B. über ein Kommunikationsnetzwerk, das z. B. ein (Computer-)Netzwerk wie das Internet oder ein (Mobil-)Telefonnetz beinhalten kann, und es wird beispielsweise ein auf dem Computergerät ausgeführter Webbrowser verwendet.
  • Bei Schritt 510 werden Eingabedaten von einer Anwendung oder einem Anwendungsserver assembliert. Die Eingabedaten können z. B. Anforderungen, transaktionsbezogene Daten, Informationen zum Transaktionskontext oder Serveranmeldeinformationen beinhalten. Beim (optionalen) Teilschritt 511 werden die Serveranmeldeinformationen von der Anwendung oder vom Anwendungsserver erzeugt.
  • Bei Schritt 520 sendet die Anwendung oder der Anwendungsserver die Eingabedaten (z. B. eingebettet in eine oder mehrere Webseiten) an das Computergerät des Benutzers, mit dem der Benutzer z. B. über das Internet auf die Remoteanwendung zugreift.
  • Bei Schritt 525 kann das Computergerät des Benutzers ein moduliertes akustisches Signal ausgeben, das die Eingabedaten verschlüsselt. Beim (optionalen) Schritt 526 kann das Computergerät des Benutzers ein optisches Signal ausgeben, das Daten verschlüsselt. Bei einigen Ausführungsarten beinhalten die im optischen Signal verschlüsselten Daten alle oder einen Teil der im akustischen Signal verschlüsselten Daten.
  • Bei Schritt 530 empfängt das Authentisierungstoken (100/101) das akustische und/oder das optische Signal und stellt die im akustischen und/oder optischen Signal verschlüsselten Daten wieder her.
  • Bei Schritt 535 erzeugt das Authentisierungstoken (100/101) einen dynamischen Sicherheitswert. Das Authentisierungstoken (100/101) kann den dynamischen Sicherheitswert wie in einem der vorstehenden Absätze beschrieben erzeugen. Bei einigen Ausführungsarten kann das Authentisierungstoken (100/101) aus dem akustischen und/oder dem optischen Signal wiederhergestellte Daten verwenden, um den dynamischen Sicherheitswert zu erzeugen. Bei Schritt 536 verifiziert das Authentisierungstoken (100/101) Serveranmeldeinformationen, die in den aus dem akustischen und/oder dem optischen Signal wiederhergestellten Daten enthalten sind. Bei einigen Ausführungsarten kann die Erzeugung des dynamischen Sicherheitswerts von der erfolgreichen Verifizierung der Serveranmeldeinformationen abhängen. Bei Schritt 537 gibt das Authentisierungstoken (100/101) den erzeugten dynamischen Sicherheitswert an den Benutzer aus.
  • Bei Schritt 540 sendet der Benutzer den erzeugten dynamischen Sicherheitswert an die Anwendung oder den Anwendungsserver. Dies erfolgt z. B. durch die Eingabe der Ziffern, aus denen sich der dynamische Sicherheitswert zusammensetzt, in ein Formularfeld auf einer Webseite der Anwendung.
  • Bei Schritt 550 empfängt die Anwendung oder der Anwendungsserver den dynamischen Sicherheitswert. Bei Schritt 551 verifiziert die Anwendung oder der Anwendungsserver den empfangenen dynamischen Sicherheitswert. Diese Verifizierung kann wie in einem der vorstehenden Absätze beschrieben erfolgen.
  • Bei Schritt 560 führt die Anwendung oder der Anwendungsserver je nach dem Ergebnis der Verifizierung des empfangenen dynamischen Sicherheitswerts wie in einigen der vorstehenden Absätze beschrieben geeignete Aktionen durch.
  • Es wurde eine Reihe von Ausführungen beschrieben. Dennoch versteht es sich, dass verschiedene Änderungen vorgenommen werden können. Zum Beispiel können Elemente aus einer oder mehreren Ausführungen kombiniert, gelöscht, geändert oder ergänzt werden, um weitere Ausführungen zu bilden. Dementsprechend liegen weitere Ausführungen innerhalb des Umfangs der beigefügten Ansprüche. Auch wenn ein bestimmtes Merkmal der vorliegenden Erfindung nur in Bezug auf eine der verschiedenen Ausführungen dargestellt wurde, kann dieses Merkmal außerdem auch mit einem oder mehreren anderen Merkmalen der anderen Ausführungen kombiniert werden, wenn dies erwünscht und für eine bestimmte oder spezielle Anwendung vorteilhaft ist. Vorstehend wurden zwar verschiedene Ausführungsarten der vorliegenden Erfindung beschrieben. Diese Darstellung ist jedoch nur beispielhaft und nicht abschließend. Zwar ist es insbesondere nicht möglich, alle denkbaren Kombinationen von Komponenten oder Methoden zum Zwecke der Beschreibung des Anmeldungsgegenstands darzustellen. Jedoch kann eine Person mit durchschnittlichem Fachwissen erkennen, dass viele weitere Kombinationen und Umsetzungen der vorliegenden Erfindung möglich sind. Die Breite und der Umfang der vorliegenden Erfindung dürfen deshalb nicht auf eine der vorstehend beschriebenen beispielhaften Ausführungsarten beschränkt werden, sondern sie sollten nur in Übereinstimmung mit den folgenden Ansprüchen und deren Entsprechungen bestimmt werden.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 5668876 [0010]
    • EP 1211841 [0010]
    • EP 1788509 [0010]
    • US 5136644 [0010]
  • Zitierte Nicht-Patentliteratur
    • http://www.vasco.com [0009]

Claims (45)

  1. Ein Token für eine starke Authentisierung (strong authentication token) für die Erzeugung dynamischer Sicherheitswerte umfassend: eine vertrauenswürdige Schnittstelle für die Benutzerausgabe zur Kommunikation erzeugter dynamischer Sicherheitswerte an einen Benutzer; eine Schnittstelle für die akustische Eingabe für den akustischen Empfang von Eingabedaten, wobei die akustische Schnittstelle ein Mikrofon und eine mit dem Mikrofon verbundene Demodulationsschaltung umfasst, die ein vom Mikrofon empfangenes akustisches Signal demodulieren kann; und eine mit der Demodulationsschaltung verbundene Komponente zur Datenverarbeitung, wobei die Komponente zur Datenverarbeitung im empfangenen akustischen Signal übertragene Eingabedaten wiederherstellen kann, nachdem das akustische Signal von der Demodulationsschaltung demoduliert wurde, die wiederhergestellten Eingabedaten verarbeiten und die dynamischen Sicherheitswerte erzeugen kann.
  2. Das Token gemäß Anspruch 1, dadurch gekennzeichnet, dass das akustische Signal über ein Modulationsverfahren der Frequenzumtastung unter Verwendung einer Vielzahl von Codierungsfrequenzen moduliert wird, um das akustische Signal zu codieren, wobei jede Codierungsfrequenz ein ganzzahliges Vielfaches einer gemeinsamen Grundfrequenz ist.
  3. Das Token gemäß Anspruch 2, dadurch gekennzeichnet, dass die Demodulationsschaltung außerdem die Stärke jeder im empfangenen akustischen Signal vorhandenen Codierungsfrequenz ermitteln und die relative Stärke der einzelnen Codierungsfrequenzen vergleichen kann.
  4. Das Token gemäß Anspruch 2, dadurch gekennzeichnet, dass die Demodulationsschaltung eine auf die gemeinsame Grundfrequenz eingestellte Phasenregelschleife beinhaltet und als Eingabe ein elektrisches Signal entsprechend dem empfangenen akustischen Signal empfängt.
  5. Das Token gemäß Anspruch 2, dadurch gekennzeichnet, dass die Demodulationsschaltung außerdem folgende Komponenten beinhaltet: eine Vielzahl von Stromerkennungsteilschaltungen, jeweils eine für jede Codierungsfrequenz, wobei jede Stromerkennungsteilschaltung ein Ausgabesignal ausgibt, das die Stärke des empfangenen akustischen Signals der Codierungsfrequenz anzeigt, mit der die Stromerkennungsteilschaltung verbunden ist; ein mit den Ausgängen der Stromerkennungsteilschaltungen verbundener Ratiodetektor, der die Ausgabesignale der Stromerkennungsteilschaltungen vergleichen und ein Signal ausgeben kann, das die stärkste Codierungsfrequenz im empfangenen akustischen Signal anzeigt.
  6. Das Token gemäß Anspruch 5, dadurch gekennzeichnet, dass jede Stromerkennungsteilschaltung folgende Komponenten beinhaltet: einen Demodulator, der als Eingabe ein elektrisches Signal entsprechend dem empfangenen akustischen Signal empfängt; und einen mit dem Demodulator verbundenen Tiefpassfilter, der die Ausgabe des mit ihm verbundenen Demodulators filtert.
  7. Das Token gemäß Anspruch 6, das außerdem einen Bandbreitenfilter beinhaltet, der ein elektrisches Signal entsprechend dem empfangenen akustischen Signal filtern kann. Daher kann es mindestens eines der elektrischen Signale entsprechend dem empfangenen akustischen Signal, das in die Phasenregelschleife eingegeben wird, oder die elektrischen Signale entsprechend dem empfangenen akustischen Signal, das in die Demodulatoren eingegeben wird, ausgeben, und außerdem Frequenzen unterhalb der untersten Codierungsfrequenz und oberhalb der höchsten Codierungsfrequenz unterdrücken.
  8. Das Token gemäß Anspruch 6, dadurch gekennzeichnet, dass mindestens ein Tiefpassfilter über eine Grenzfrequenz verfügt, die weniger als doppelt so hoch wie die Baud-Rate des empfangenen akustischen Signals ist.
  9. Das Token gemäß Anspruch 8: dadurch gekennzeichnet, dass die Phasenregelschleife außerdem für jede Codierungsfrequenz ein Referenzsignal erzeugen kann, das mit dieser Codierungsfrequenz verbunden ist, wobei jedes Referenzsignal ein ganzzahliges Vielfaches der Frequenz ist, an die die Phasenregelschleife eine Angleichung vornimmt; und wobei der Multiplikationsfaktor zwischen jedem Referenzsignal und der Frequenz, an die die Phasenregelschleife eine Angleichung vornimmt, dem Multiplikationsfaktor zwischen der Codierungsfrequenz, mit dem das Referenzsignal verbunden ist, und der gemeinsamen Grundfrequenz entspricht; und dadurch gekennzeichnet, dass jeder Demodulator als Eingabe auch das Referenzsignal für die Codierungsfrequenz empfängt, mit der der Demodulator verbunden ist; und dadurch gekennzeichnet, dass jeder Demodulator ein Ausgabesignal mit einer Niederfrequenzkomponente erzeugt, die die Stärke des empfangenen akustischen Signals auf der Frequenz des von der Phasenregelschleife erzeugten Referenzsignals anzeigt, das der Demodulator als Eingabe empfängt.
  10. Das Token gemäß Anspruch 9, dadurch gekennzeichnet, dass der Demodulator einen AM-Synchrondemodulator beinhaltet.
  11. Das Token gemäß Anspruch 9, dadurch gekennzeichnet, dass der Demodulator einen Produktdetektor beinhaltet.
  12. Das Token gemäß Anspruch 9, dadurch gekennzeichnet, dass der Demodulator einen Inverter beinhaltet.
  13. Das Token gemäß Anspruch 9, dadurch gekennzeichnet, dass der Demodulator zwei Mischstufen beinhaltet.
  14. Das Token gemäß Anspruch 9, dadurch gekennzeichnet, dass mindestens ein Demodulator eine Komponente beinhaltet, die das elektrische Signal entsprechend dem empfangenen akustischen Signal, das in den Demodulator eingegeben wird, mit dem von der Phasenregelschleife erzeugten Referenzsignal, das in den Demodulator eingegeben wird, multiplizieren kann.
  15. Das Token gemäß Anspruch 1, das außerdem eine Komponente zur Datenspeicherung für die Speicherung geheimer Werte beinhaltet, die zusammen mit einem Server verwendet werden, und dadurch gekennzeichnet ist, dass die besagte Komponente zur Datenverarbeitung außerdem die besagten Sicherheitswerte unter Verwendung von mindestens einem der besagten geheimen Werte erzeugen kann.
  16. Das Token gemäß Anspruch 15, dadurch gekennzeichnet, dass die Komponente zur Datenverarbeitung außerdem die besagten Sicherheitswerte durch die kryptografische Kombination von mindestens einem der besagten geheimen Werte mit einer dynamischen Variable erzeugen kann.
  17. Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die kryptografische Kombination die Ausführung eines symmetrischen kryptografischen Algorithmus beinhaltet.
  18. Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die dynamische Variable einen Zeitwert beinhaltet.
  19. Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die dynamische Variable einen Zählerwert beinhaltet.
  20. Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die dynamische Variable einen Anforderungswert beinhaltet.
  21. Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die dynamische Variable einen Wert für Transaktionsdaten beinhaltet.
  22. Das Token gemäß Anspruch 1, das außerdem eine kompakte Schnittstelle für die manuelle Benutzereingabe beinhaltet, die wiederum einen Navigations- und einen Bestätigungsmechanismus beinhaltet.
  23. Das Token gemäß Anspruch 22, dadurch gekennzeichnet, dass der Navigationsmechanismus mindestens eine Navigationstaste und der Bestätigungsmechanismus mindestens eine Bestätigungstaste beinhaltet.
  24. Das Token gemäß Anspruch 23, dadurch gekennzeichnet, dass der Navigationsmechanismus aus zwei Navigationstasten besteht und der Bestätigungsmechanismus aus zwei Bestätigungstasten einschließlich einer Taste „OK” besteht.
  25. Das Token gemäß Anspruch 22, dadurch gekennzeichnet, dass der Navigationsmechanismus ein Scrollrad beinhaltet.
  26. Das Token gemäß Anspruch 1, dadurch gekennzeichnet, dass das Token ein erstes Sicherheitsgerät ist, dass das Token außerdem eine Kommunikationsschnittstelle für die Kommunikation mit einem entfernbaren zweiten Sicherheitsgerät beinhaltet und dass das Token die dynamischen Sicherheitswerte zusammen mit dem zweiten Sicherheitsgerät erzeugen kann.
  27. Das Token gemäß Anspruch 26, bei dem das entfernbare zweite Sicherheitsgerät eine Smartcard beinhaltet.
  28. Das Token gemäß Anspruch 26, dadurch gekennzeichnet, dass das Token mindestens einen der dynamischen Sicherheitswerte erzeugen kann, indem ein Befehl an das zweite Sicherheitsgerät gesendet wird, und mindestens einen dynamischen Sicherheitswert aus der Antwort des zweiten Sicherheitsgeräts auf den besagten Befehl ableiten kann.
  29. Das Token gemäß Anspruch 28, dadurch gekennzeichnet, dass das Token eine Anforderung in den besagten Befehl aufnehmen kann und die Antwort des zweiten Sicherheitsgeräts vom zweiten Sicherheitsgerät abhängig von der besagten Anforderung berechnet wird.
  30. Das Token gemäß Anspruch 28, dadurch gekennzeichnet, dass die Antwort des zweiten Sicherheitsgeräts ein Kryptogramm beinhaltet, das vom zweiten Sicherheitsgerät durch die kryptografische Kombination eines vom zweiten Sicherheitsgerät gespeicherten geheimen Werts mit einem vom zweiten Sicherheitsgerät gespeicherten und verwalteten Zählerwert über einen symmetrischen kryptografischen Algorithmus berechnet wird.
  31. Das Token gemäß Anspruch 30, dadurch gekennzeichnet, dass das Token außerdem einen kryptografischen Schlüssel aus der Antwort des zweiten Sicherheitsgeräts ableiten und mindestens einen dynamischen Sicherheitswert durch die kryptografische Kombination des besagten kryptografischen Schlüssels mit mindestens einem Wert für Transaktionsdaten erzeugen kann.
  32. Das Token gemäß Anspruch 1, das außerdem eine Schnittstelle für die optische Eingabe beinhaltet.
  33. Das Token gemäß Anspruch 32, das außerdem einen Mechanismus zur Schnittstellenauswahl beinhaltet, über den entweder die Schnittstelle für die akustische Eingabe oder die Schnittstelle für die optische Eingabe für den Datenempfang ausgewählt werden kann.
  34. Das Token gemäß Anspruch 33, dadurch gekennzeichnet, dass das Token außerdem vom Benutzer eine Anweisung dazu empfangen kann, ob das Token die Schnittstelle für die akustische Eingabe oder die Schnittstelle für die optische Eingabe verwenden soll.
  35. Das Token gemäß Anspruch 33, dadurch gekennzeichnet, dass der Mechanismus zur Schnittstellenauswahl anhand von heuristischen Regeln auf der Grundlage bestimmter Eigenschaften der über die Schnittstelle für die akustische Eingabe und die Schnittstelle für die optische Eingabe empfangenen Signale entscheiden kann, welche Eingabeschnittstelle für den Datenempfang ausgewählt wird.
  36. Das Token gemäß Anspruch 33, dadurch gekennzeichnet, dass das Token einen Auswahlprozess anwenden kann, bei dem in einem ersten Zeitraum versucht wird, mindestens einige Daten über eine der Schnittstellen für die akustische oder die optische Eingabe zu empfangen. Wenn der Versuch des Empfangs von mindestens einigen Daten während des ersten Zeitraums erfolgreich ist, wird die Eingabeschnittstelle des Empfangsversuchs ausgewählt und es werden weitere Daten über die ausgewählte Eingabeschnittstelle empfangen. Wenn hingegen der Versuch des Empfangs von mindestens einigen Daten während des ersten Zeitraums nicht erfolgreich ist, wird der Auswahlprozess über die jeweils andere der Schnittstellen für die akustische oder die optische Eingabe in einem zweiten Zeitraum wiederholt.
  37. Das Token gemäß Anspruch 33, bei dem das Token außerdem Übertragungsfehler in den über die aktuell ausgewählte Schnittstelle empfangenen Daten erkennen kann und dass es zur Auswahl entweder der Schnittstelle für die akustische Eingabe oder die Schnittstelle für die optische Eingabe zurückkehren kann, wenn eines oder mehrere der vordefinierten Kriterien in Bezug auf die erkannten Übertragungsfehler erfüllt sind.
  38. Das Token gemäß Anspruch 32, das gleichzeitig Daten über die Schnittstelle für die akustische Eingabe und die Schnittstelle für die optische Eingabe empfangen kann.
  39. Das Token gemäß Anspruch 32, das außerdem über die Schnittstelle für die optische Eingabe empfangene Daten mit über die Schnittstelle für die akustische Eingabe empfangen Daten kombinieren kann.
  40. Das Token gemäß Anspruch 1, das außerdem eine Schnittstelle für die optische Benutzereingabe und eine Smartcardschnittstelle für die Kommunikation mit einer Smartcard im Format einer Standardkreditkarte beinhaltet. Dabei kann die Komponente zur Datenverarbeitung außerdem Signaturen für Transaktionsdaten erzeugen, indem durch die Eingabe von Transaktionsdaten in das Token über die Schnittstelle für die akustische oder die optische Eingabe ein NachrichtenAuthentisierungscode (MAC) erzeugt wird. Hierbei erzeugt die Komponente zur Datenverarbeitung den MAC unter Verwendung eines symmetrischen kryptografischen Algorithmus mit einem geheimen Schlüssel, der aus einem von der Smartcard erzeugten Kryptogramm abgeleitet ist.
  41. Das Token gemäß Anspruch 40, das außerdem eine Schnittstelle für die manuelle Dateneingabe durch den Benutzer beinhaltet, über die der Benutzer eine Identifikationsnummer (PIN) eingeben kann, und dadurch gekennzeichnet ist, dass das Token außerdem die besagte PIN zur Verifizierung an die Smartcard übertragen kann, bevor die Smartcard das besagte Kryptogramm erzeugt, und alle Kopien der PIN aus dem Speicher löschen kann, nachdem das Token die besagte PIN zur Verifizierung an die Smartcard übertragen hat.
  42. Das Token gemäß Anspruch 41, das außerdem einen Mechanismus zur Schnittstellenauswahl beinhaltet, über den entweder die Schnittstelle für die akustische Eingabe oder die Schnittstelle für die optische Eingabe für den Datenempfang ausgewählt werden kann.
  43. Das Token gemäß Anspruch 1, dadurch gekennzeichnet, dass die Eingabedaten Serveranmeldeinformationen beinhalten, und gemäß Anspruch 20, dadurch gekennzeichnet, dass das Token bei der Verarbeitung außerdem die besagten Serveranmeldeinformationen verifizieren kann.
  44. Das Token gemäß Anspruch 43, dadurch gekennzeichnet, dass die besagte Erzeugung der dynamischen Sicherheitswerte von der erfolgreichen Verifizierung der besagten Serveranmeldeinformationen abhängt.
  45. Das Token gemäß Anspruch 43, das außerdem eine Komponente zur Datenspeicherung für die Speicherung geheimer Werte beinhaltet, die zusammen mit einem Server verwendet werden, und dadurch gekennzeichnet ist, dass die besagte Komponente zur Datenverarbeitung außerdem die besagten Serveranmeldeinformationen unter Verwendung von mindestens einem der besagten geheimen Werte und einem symmetrischen kryptografischen Algorithmus erzeugen kann.
DE212012000065U 2011-02-25 2012-02-22 Ein Token für eine starke Authentisierung mit akustischer Dateneingabe Expired - Lifetime DE212012000065U1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201161446779P 2011-02-25 2011-02-25
US61/446,779 2011-02-25
PCT/US2012/026077 WO2012116045A1 (en) 2011-02-25 2012-02-22 A strong authentication token with acoustic data input

Publications (1)

Publication Number Publication Date
DE212012000065U1 true DE212012000065U1 (de) 2013-09-27

Family

ID=45876894

Family Applications (1)

Application Number Title Priority Date Filing Date
DE212012000065U Expired - Lifetime DE212012000065U1 (de) 2011-02-25 2012-02-22 Ein Token für eine starke Authentisierung mit akustischer Dateneingabe

Country Status (4)

Country Link
US (1) US8930702B2 (de)
CN (1) CN204965434U (de)
DE (1) DE212012000065U1 (de)
WO (1) WO2012116045A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3276909A1 (de) 2016-07-29 2018-01-31 Giesecke+Devrient Mobile Security GmbH Authentisierungsanordnung

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8738919B2 (en) * 2007-04-20 2014-05-27 Stmicroelectronics S.A. Control of the integrity of a memory external to a microprocessor
US9449319B1 (en) * 2008-06-30 2016-09-20 Amazon Technologies, Inc. Conducting transactions with dynamic passwords
US9836737B2 (en) * 2010-11-19 2017-12-05 Mastercard International Incorporated Method and system for distribution of advertisements to mobile devices prompted by aural sound stimulus
US9098865B2 (en) * 2011-04-07 2015-08-04 Facebook, Inc. Ultrasonic near-field communication
US9954578B2 (en) * 2011-09-08 2018-04-24 Yubico Inc. Devices and methods for identification, authentication and signing purposes
CN103379491A (zh) * 2012-04-12 2013-10-30 中兴通讯股份有限公司 用于密码验证的用户终端、密码交易终端、系统和方法
JP2014048414A (ja) * 2012-08-30 2014-03-17 Sony Corp 情報処理装置、情報処理システム、情報処理方法及びプログラム
US10304047B2 (en) 2012-12-07 2019-05-28 Visa International Service Association Token generating component
US9306943B1 (en) * 2013-03-29 2016-04-05 Emc Corporation Access point—authentication server combination
ES2812541T3 (es) * 2013-12-30 2021-03-17 Onespan Int Gmbh Aparato de autenticación con interfaz Bluetooth
US9503476B2 (en) * 2014-01-28 2016-11-22 Vivint, Inc. Anti-takeover systems and methods for network attached peripherals
US9836594B2 (en) 2014-05-19 2017-12-05 Bank Of America Corporation Service channel authentication token
US9306930B2 (en) 2014-05-19 2016-04-05 Bank Of America Corporation Service channel authentication processing hub
US10530767B2 (en) * 2015-03-23 2020-01-07 Telefonaktiebolaget Lm Ericsson (Publ) Methods and user device and authenticator device for authentication of the user device
EP3283951B1 (de) * 2015-04-14 2020-01-29 Capital One Services, LLC System und verfahren für sichere firmware-validierung
CN105553945A (zh) * 2015-12-08 2016-05-04 北京元心科技有限公司 一种在移动终端中加解密数据的方法和装置
WO2017173145A1 (en) * 2016-03-30 2017-10-05 The Privacy Factor, LLC Systems and methods for analyzing, assessing and controlling trust and authentication in applications and devices
GB2552721A (en) * 2016-08-03 2018-02-07 Cirrus Logic Int Semiconductor Ltd Methods and apparatus for authentication in an electronic device
US11030618B1 (en) 2016-09-30 2021-06-08 Winkk, Inc. Authentication and personal data sharing for partner services using out-of-band optical mark recognition
US10402808B1 (en) * 2016-12-02 2019-09-03 Worldpay, Llc Systems and methods for linking high-value tokens using a low-value token
US10404703B1 (en) 2016-12-02 2019-09-03 Worldpay, Llc Systems and methods for third-party interoperability in secure network transactions using tokenized data
KR102458042B1 (ko) 2017-04-14 2022-10-24 삼성전자주식회사 음향 보안 전송
US10432614B2 (en) * 2017-05-16 2019-10-01 Apple Inc. Techniques for verifying user intent and securely configuring computing devices
WO2020018454A1 (en) 2018-07-16 2020-01-23 Islamov Rustam Cryptography operations for secure post-quantum communications
CN108810029B (zh) * 2018-07-23 2021-08-31 宏桥高科技集团有限公司 一种微服务架构服务间鉴权系统及优化方法
US11928193B2 (en) 2019-12-10 2024-03-12 Winkk, Inc. Multi-factor authentication using behavior and machine learning
US11657140B2 (en) 2019-12-10 2023-05-23 Winkk, Inc. Device handoff identification proofing using behavioral analytics
US11936787B2 (en) 2019-12-10 2024-03-19 Winkk, Inc. User identification proofing using a combination of user responses to system turing tests using biometric methods
US11563582B2 (en) * 2019-12-10 2023-01-24 Winkk, Inc. Method and apparatus for optical encryption communication using a multitude of hardware configurations
US11328042B2 (en) 2019-12-10 2022-05-10 Winkk, Inc. Automated transparent login without saved credentials or passwords
US11652815B2 (en) 2019-12-10 2023-05-16 Winkk, Inc. Security platform architecture
US11553337B2 (en) 2019-12-10 2023-01-10 Winkk, Inc. Method and apparatus for encryption key exchange with enhanced security through opti-encryption channel
US11574045B2 (en) 2019-12-10 2023-02-07 Winkk, Inc. Automated ID proofing using a random multitude of real-time behavioral biometric samplings
US11588794B2 (en) 2019-12-10 2023-02-21 Winkk, Inc. Method and apparatus for secure application framework and platform
US11165586B1 (en) * 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11843943B2 (en) 2021-06-04 2023-12-12 Winkk, Inc. Dynamic key exchange for moving target
US11824999B2 (en) 2021-08-13 2023-11-21 Winkk, Inc. Chosen-plaintext secure cryptosystem and authentication

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5136644A (en) 1988-04-21 1992-08-04 Telecash Portable electronic device for use in conjunction with a screen
US5668876A (en) 1994-06-24 1997-09-16 Telefonaktiebolaget Lm Ericsson User authentication method and apparatus
EP1211841A1 (de) 2000-06-23 2002-06-05 Esignus, S.L. Externe signaturvorrichtung für pc mit optischer dateneingabe über den monitor
EP1788509A1 (de) 2005-11-22 2007-05-23 Berner Fachhochschule, Hochschule für Technik und Architektur Verfahren zum Senden einer verschlüsselten Information und Vorrichtung dafür

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3483476D1 (de) * 1984-08-08 1990-11-29 Toshiba Kawasaki Kk Informationsmedium.
US6607136B1 (en) 1998-09-16 2003-08-19 Beepcard Inc. Physical presence digital authentication system
US7533735B2 (en) * 2002-02-15 2009-05-19 Qualcomm Corporation Digital authentication over acoustic channel
US7083090B2 (en) * 2002-08-09 2006-08-01 Patrick Zuili Remote portable and universal smartcard authentication and authorization device

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5136644A (en) 1988-04-21 1992-08-04 Telecash Portable electronic device for use in conjunction with a screen
US5668876A (en) 1994-06-24 1997-09-16 Telefonaktiebolaget Lm Ericsson User authentication method and apparatus
EP1211841A1 (de) 2000-06-23 2002-06-05 Esignus, S.L. Externe signaturvorrichtung für pc mit optischer dateneingabe über den monitor
EP1788509A1 (de) 2005-11-22 2007-05-23 Berner Fachhochschule, Hochschule für Technik und Architektur Verfahren zum Senden einer verschlüsselten Information und Vorrichtung dafür

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
http://www.vasco.com

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3276909A1 (de) 2016-07-29 2018-01-31 Giesecke+Devrient Mobile Security GmbH Authentisierungsanordnung
DE102016009258A1 (de) 2016-07-29 2018-02-01 Giesecke+Devrient Mobile Security Gmbh Authentisierungsanordnung

Also Published As

Publication number Publication date
US8930702B2 (en) 2015-01-06
US20120221859A1 (en) 2012-08-30
WO2012116045A1 (en) 2012-08-30
CN204965434U (zh) 2016-01-13

Similar Documents

Publication Publication Date Title
DE212012000065U1 (de) Ein Token für eine starke Authentisierung mit akustischer Dateneingabe
DE102012219618B4 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
AU2012363099B2 (en) Key management using quasi out of band authentication architecture
DE202013007661U1 (de) Ein Token für eine starke Authentisierung mit akustischer Dateneingabe über mehrere Trägerfrequenzen
DE102011082101B4 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
EP2533172B2 (de) Gesicherter Zugriff auf Daten in einem Gerät
DE60212577T2 (de) Verfahren und vorrichtung zur beglaubigung von daten
DE60200081T2 (de) Sichere Benutzer- und Datenauthenifizierung über ein Kommunikationsnetzwerk
DE60200093T2 (de) Sichere Benutzerauthenifizierung über ein Kommunikationsnetzwerk
DE102013202001B4 (de) Verfahren zum Versehen eines mobilen Endgeräts mit einem Authentisierungszertifikat
US20120066501A1 (en) Multi-factor and multi-channel id authentication and transaction control
EP2962439B1 (de) Lesen eines attributs aus einem id-token
EP3699791A1 (de) Zugangskontrolle mit einem mobilfunkgerät
EP3465513B1 (de) Nutzerauthentifizierung mittels eines id-tokens
EP3767513B1 (de) Verfahren zur sicheren durchführung einer fernsignatur sowie sicherheitssystem
CN115150193A (zh) 一种数据传输中敏感信息加密方法、系统和可读存储介质
EP3882796A1 (de) Nutzerauthentifizierung unter verwendung zweier unabhängiger sicherheitselemente
WO2005055018A1 (de) Verfahren und vorrichtung zur sicherung digitaler daten
DE102021103995A1 (de) Auslesen von Identitätsattributen mit einem entfernte Sicherheitselement
DE102021103993A1 (de) Initialisieren applikationsspezifischer kryptographischer Sicherheitsfunktionen
DE102011110898A1 (de) Verfahren zur Authentifizierung eines Benutzers zum Gewähren eines Zugangs zu Diensten eines Computersystems, sowie zugehöriges Computersystem, Authentifizierungsserver und Kommunikationsgerät mit Authentifizierungsapplikation
KR20140047058A (ko) 클라우드 공인인증 시스템 및 그 제공방법
DE102016215629A1 (de) Kommunikationssystem zur Verwaltung eines Fahrzeugs

Legal Events

Date Code Title Description
R207 Utility model specification

Effective date: 20131121

R150 Utility model maintained after payment of first maintenance fee after three years
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0021200000

Ipc: G06F0021300000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0021200000

Ipc: G06F0021300000

Effective date: 20150303

R150 Utility model maintained after payment of first maintenance fee after three years

Effective date: 20150225

R151 Utility model maintained after payment of second maintenance fee after six years
R158 Lapse of ip right after 8 years