DE202013007661U1

DE202013007661U1 - Ein Token für eine starke Authentisierung mit akustischer Dateneingabe über mehrere Trägerfrequenzen

Info

Publication number: DE202013007661U1
Application number: DE202013007661U
Authority: DE
Original assignee: Vasco Data Security International GmbH
Current assignee: Onespan International GmbH
Priority date: 2012-08-30
Filing date: 2013-08-29
Publication date: 2013-10-14
Anticipated expiration: 2023-08-30
Also published as: US9184915B2; US20140068272A1

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 mindestens ein Mikrofon und eine mit dem mindestens einen Mikrofon verbundene Demodulationsschaltung umfasst, die ein vom Mikrofon empfangenes akustisches Signal demodulieren kann; und eine mit der Demodulationsschaltung verbundene oder in dieser enthaltene 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, wobei die Demodulationsschaltung modulierte Träger auf mindestens zwei verschiedenen Trägerfrequenzen demodulieren kann.

Description

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 authentifizieren, Transaktionen zu signieren und eine verschlüsselte Kommunikation einzurichten.
Zur Gewährleistung der Sicherheit muss sichergestellt werden, dass der private Schlüssel eines Benutzers 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 (z. B. geheime kryptografische Schlüssel) 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 NachrichtenAuthentisierungscode (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 Client-Computergeräte (z. B. Tablet-PC, Smartphone, ...) 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 Resonanzen bei der mechanischen Kombination von Lautsprecher und Lautsprecheraufnahme des PCs (oder ähnlichen Computergeräts) besteht, wodurch Verzerrungen im Frequenzgang des Audioausgabesystems am Client-Computergerät auftreten können. Eine weitere Ursache für Übertragungsfehler können Reflexionen (z. B. an den Wänden des Raums, in dem die Übertragung stattfindet) der Tonsignale darstellen, die mit erheblicher Verzögerung am Empfänger des Token ankommen. Dadurch können akustische Signale mehrfach empfangen werden. Ein Mehrfachempfang des akustischen Signals kann auch dann auftreten, wenn dasselbe akustische Signal von mehr als einem Lautsprecher des ausgebenden PCs (oder ähnlichen Computergeräts) ausgegeben wird. Die von verschiedenen Lautsprechern ausgegebenen akustischen Signale können je nach räumlicher Anordnung, in der die Lautsprecher und das Empfangsgerät zueinander positioniert sind, mit einer mehr oder weniger starken Verzögerung vom Empfangsgerät empfangen werden. Wenn die am Empfänger auftretende Verzögerung zwischen den verschiedenen, über verschiedene Pfade empfangenen Signalen mehr oder weniger der halben Periodendauer der Trägerfrequenz entspricht und/oder die verschiedenen akustischen Signale mit einer ähnlichen Stärke empfangen werden, kann am Empfänger eine destruktive Interferenz auftreten. Dabei ist es unerheblich, ob diese verschiedenen Signale verschiedene Reflexionen der ursprünglich von den Lautsprechern des Ausgabegeräts ausgegebenen Signale oder mehrere Instanzen des von verschiedenen Lautsprechern ausgegebenen Signals oder eine Kombination dieser beiden Varianten sind. Hierdurch kann die Stärke des zu demodulierenden Nutzsignals so niedrig sein, dass das Signal nicht mehr zuverlässig erkannt oder demoduliert werden kann, bzw. das Signal-Rausch-Verhältnis kann so niedrig werden, dass die Anzahl der Übertragungsfehler einen zu hohen Wert erreicht.
Ob eine destruktive Interferenz auftritt oder nicht, hängt von der räumlichen Position ab, in der sich der Empfänger zu den verschiedenen Quellen des akustischen Signals (z. B. mehrere Lautsprecher oder Reflexionspunkte) befindet. Grundsätzlich kann damit bei einer bestimmten Anordnung des ausgebenden Computergeräts des Benutzers in bestimmten Zonen oder Bereichen eines Raums eine destruktive Interferenz auftreten, in anderen dagegen nicht. Wenn sich also das empfangende Token in einer Zone mit destruktiver Interferenz befindet, kann das Problem deshalb möglicherweise ganz einfach dadurch behoben werden, dass das empfangende Token aus dieser Zone mit destruktiver Interferenz entfernt wird. Eine effektive Umsetzung dieser Lösung ist aber aus unterschiedlichen Gründen nicht immer möglich. Erstens muss der Benutzer überhaupt erst einmal erkennen, dass vielleicht ein Empfangsproblem vorliegt, das sich durch einen Positionswechsel des Token beheben lässt (generell kann nicht davon ausgegangen werden, dass der Durchschnittsbenutzer mit dem Konzept der destruktiven Interferenz akustischer Signale vertraut ist). Zweitens kann es in der Praxis schwierig bis unmöglich sein, dem Benutzer klare Anweisungen zur Vorgehensweise zu erteilen. Dies liegt zum einen daran, dass die Anwendung, mit der der Benutzer interagiert, die exakte Geometrie des Raums und die räumliche Anordnung des empfangenden Token, der Lautsprecher des Computergeräts des Benutzers und aller möglichen Reflexionsquellen nicht kennt. Daher kann nicht berechnet werden, in welchen Zonen des Raums keine destruktive Interferenz auftritt. Zum anderen verfügt das Token in vielen Ausführungsarten über keine praktische Möglichkeit zur Rückführung von Signalen an die Anwendung (in einem typischen Fall unterstützt die akustische Schnittstelle des Token die Signalübertragung nur in eine Richtung).
Drittens bleibt der Positionswechsel des empfangenden Token wirkungslos, wenn die Übertragungsprobleme durch Resonanzen im Ausgabesystem verursacht werden.
Bei einer alternativen Lösung könnte das empfangende Token mehrere empfangende Mikrofone beinhalten, die in ausreichendem Abstand zueinander positioniert sind, sodass nach vernünftigem Ermessen davon ausgegangen werden kann, dass sich mindestens eines der Mikrofone in einem nicht von destruktiver Interferenz betroffenen Bereich befindet. Diese Lösung ist jedoch möglicherweise nicht immer annehmbar, weil hierbei wahrscheinlich sowohl die Kosten als auch die Größe des empfangenden Token zunehmen und/oder der Bedienkomfort eingeschränkt ist. Mit dieser Lösung werden Übertragungsprobleme aufgrund von Resonanzen im Ausgabesystem möglicherweise ebenfalls nicht beseitigt.
Es ist eine weitere Erkenntnis der Erfinder, dass es nicht nur von der räumlichen Anordnung abhängt (aus der sich wiederum die Unterschiede in der Pfadlänge ergeben, die ihrerseits zusammen mit der vorgegebenen Schallgeschwindigkeit die Unterschiede in der Ankunftszeit und damit die in Sekunden angegebene Verzögerung bestimmt), sondern auch von der Wellenlänge der Trägerfrequenz, ob die relative Verzögerung der verschiedenen empfangenen Kopien des akustischen Signals mehr oder weniger halb so groß ist wie die Periodendauer der Trägerfrequenz. Ob eine bestimmte Verzögerung mehr oder weniger halb so groß ist wie die Periodendauer der Trägerfrequenz, hängt also vom Verhältnis zwischen der Verzögerung und der Periodendauer der Trägerfrequenz und damit von der Frequenz des Trägers ab. Die destruktive Interferenz kann folglich in einer bestimmten räumlichen Konstellation bei einigen Trägerfrequenzen auftreten, bei anderen Trägerfrequenzen in exakt derselben räumlichen Konstellation dagegen nicht.
Auch die Resonanzen im Audioausgabesystem des Client-Computergeräts sind in der Regel frequenzabhängig.
Eine auf dieser Erkenntnis beruhende Lösung zur Vermeidung oder Behebung der Probleme durch destruktive Interferenz und/oder Resonanzen kann einfach in der Auswahl einer anderen Trägerfrequenz bestehen. Die erfolgreiche Umsetzung dieser Lösung kann dadurch erschwert werden, dass das Auftreten einer destruktiven Interferenz wie weiter oben beschrieben von der räumlichen Anordnung abhängt, die bei jedem Benutzer unterschiedlich sein kann und dem System, das das akustische Signal ausgibt, möglicherweise nicht bekannt ist. Da die Anwendung und das empfangende Token die räumliche Konstellation in der Regel nicht kennen, wissen die Anwendung und das Token normalerweise nicht bereits vorab, welche Trägerfrequenzen zu einer destruktiven Interferenz führen und welche nicht. Es ist außerdem möglich, dass der Benutzer unterschiedliche Computergeräte verwendet. Ob Resonanzen auftreten und bei welchen Frequenzen dies der Fall ist, kann deshalb je nach Fall variieren.
Eine weitere Einschränkung ergibt sich dadurch, dass die für den Empfang von Eingabedaten vom Client-Computergerät eines Benutzers ausgelegten Token für eine starke Authentisierung bei vielen Ausführungsarten keine Daten an das Client-Computergerät eines Benutzers senden können. Selbst wenn das Token dazu in der Lage wäre, digitale Daten mit Rückmeldungen an das Client-Computergerät zu senden, ist in keinem Fall gewährleistet, dass ein bestimmtes Client-Computergerät generell die vom Token gesendeten digitalen Daten empfangen kann. Es ist beispielsweise durchaus möglich, dass die Lautsprecher des Client-Computergeräts betriebsbereit und aktiviert sind, das Client-Computergerät aber dagegen über kein betriebsbereites und aktiviertes Mikrofon verfügt, auf das die Anwendung zugreifen kann. Mit anderen Worten: Die digitale Datenkommunikation zwischen dem Client-Computergerät eines Benutzers und dem Token für eine starke Authentisierung des Benutzers verläuft bei vielen Ausführungsarten ausschließlich in eine Richtung. Das Token für eine starke Authentisierung auf der Empfangsseite verfügt über keinen Rückführungskanal zur Benachrichtigung des sendenden Computergeräts über die tatsächlichen Empfangsbedingungen (z. B. ob und in welcher Qualität das Signal empfangen wird). Es ist daher nicht möglich, bestehende Kommunikationstechniken mit irgendeiner Form der Kommunikationsparameterverhandlung einzusetzen. Da beispielsweise das empfangende Token das sendende Computergerät nicht über den Erfolg oder das Fehlschlagen des Signalempfangs benachrichtigen kann, könnte kein Kommunikationsschema verwendet werden, bei dem der Empfänger den Sender über die Qualität oder den Erfolg der Übertragung für irgendeine verwendete Trägerfrequenz benachrichtigt und bei dem der Sender seine Verwendung oder Auswahl bestimmter Trägerfrequenzen anhand dieser Informationen anpasst.
Eine Lösung, die sich auf die Erkenntnis der Erfinder hinsichtlich der Frequenzabhängigkeit von Übertragungsproblemen stützt, mit der diese Einschränkung durch einen fehlenden Rückführungskanal beseitigt werden kann, beinhaltet die redundante akustische Ausgabe derselben Daten über mehrere (mindestens zwei) Trägerfrequenzen.
Bei einigen Ausführungsarten wird das Signal für die Datenübertragung an das empfangende Token redundant in der Zeitdomäne übertragen. Dies bedeutet, dass das Signal mit denselben Eingabedaten mehr als einmal nacheinander auf verschiedenen Trägerfrequenzen wiederholt wird.
Bei anderen Ausführungsarten erfolgt die Redundanz in der Frequenzdomäne. Das Signal mit denselben Eingabedaten wird also gleichzeitig auf mehreren Trägerfrequenzen ausgegeben.
Diese vollständig redundante Übertragung der Eingabedaten erscheint vielleicht als ineffiziente Bandbreitennutzung (weil die Erhöhung der Bandbreite durch die Verwendung mehrerer Trägerfrequenzen nicht zur Erhöhung der Baud-Rate verwendet wird). Sie reduziert jedoch erheblich die Anfälligkeit der Lösung für frequenzabhängige Übertragungsfehler und ermöglicht gleichzeitig einfache und kosteneffektive Ausführungen.
Für die Modulation der verschiedenen Trägerfrequenzen ist der Einsatz verschiedener digitaler Modulationsverfahren möglich. Bei einigen Ausführungsarten kann die Amplitudenumtastung eingesetzt werden. Bei anderen Ausführungsarten kann eine Form der Phasenumtastung eingesetzt werden. Bei weiteren anderen Ausführungsarten kann die Quadraturamplitudenmodulation (QAM) eingesetzt werden. Bei noch anderen Ausführungsarten können weitere andere Modulationsverfahren eingesetzt werden. Bei einigen Ausführungsarten kann dasselbe Modulationsverfahren für alle Trägerfrequenzen eingesetzt werden. Bei anderen Ausführungsarten können verschiedene Modulationsverfahren für verschiedene Trägerfrequenzen eingesetzt werden. Bei einigen Ausführungsarten kann die binäre Phasenumtastung für alle Trägerfrequenzen eingesetzt werden.
Bei einigen Ausführungsarten kann differenzieller Code eingesetzt werden.
Bei einigen Ausführungsarten können Datencodierungsverfahren eingesetzt werden, die eine Fehlererkennung und/oder Fehlerkorrektur durch das empfangende Token ermöglichen.
Auswahl der Trägerfrequenzen und Symbolraten.
Bei einigen Ausführungsarten werden Trägerfrequenzen im akustisch wahrnehmbaren Frequenzbereich ausgewählt. Dies bringt mindestens folgende Vorteile mit sich. Erstens können herkömmliche Lautsprecher der meisten Client-Computergeräte Tonsignalfrequenzen in einem großen Teil des akustisch wahrnehmbaren Frequenzbereichs ausgeben. Zweitens ist das ausgegebene akustische Signal dadurch für den Benutzer wahrnehmbar. Dadurch kann er Übertragungsprobleme, bei denen kein akustisch wahrnehmbares Signal ausgegeben wird (z. B., weil die Lautsprecher am Client-Computergerät des Benutzers ausgeschaltet wurden oder aus einem anderen Grund nicht betriebsbereit sind), sehr einfach feststellen. Bei einigen Ausführungsarten werden Trägerfrequenzen im Bereich von 50 bis 15.000 Hz ausgewählt. Bei einigen Ausführungsarten werden hohe Trägerfrequenzen ausgewählt, um hohe Baud-Raten zu erreichen. Bei einigen Ausführungsarten werden Trägerfrequenzen über 1.000 Hz ausgewählt, um Frequenzen unter 1.000 Hz zu vermeiden, da dort in der Regel die meisten Frequenzbereiche der menschlichen Stimme konzentriert sind. Bei einigen Ausführungsarten werden Frequenzen von 300 bis 500 Hz ausgewählt, weil der zuverlässige untere Bereich typischer akustischer Sender (d. h. Lautsprecher) von Client-Computergeräten ungefähr von 300 bis 500 Hz reicht. Bei einigen Ausführungsarten werden keine sehr hohen Trägerfrequenzen ausgewählt, um unerwünschte Geräusche zu vermeiden. Bei einigen Ausführungsarten werden keine sehr hohen Trägerfrequenzen ausgewählt, um keine zu hohen Anforderungen an die empfangende Hardware zu stellen. Bei einigen Ausführungsarten werden Trägerfrequenzen im konservativeren Bereich von 1.000 bis 3.000 Hz ausgewählt.
Bei einigen Ausführungsarten werden die Trägerfrequenzen so ausgewählt, dass die Überlappung in der spektralen Leistungsdichte der verschiedenen Träger minimiert wird. Bei einigen Ausführungsarten werden die Trägerfrequenzen so ausgewählt, dass sich die Hauptkeulen der Frequenzspektren für die jeweiligen Trägerfrequenzen nicht überlappen. Bei einigen Ausführungsarten werden die Trägerfrequenzen so ausgewählt, dass die ersten Minima (d. h. die am nächsten an den jeweiligen Trägerfrequenzen liegenden Minima) der spektralen Leistungsdichte von zwei benachbarten modulierten Trägerfrequenzen übereinstimmen.
Bei einigen Ausführungsarten werden nur zwei Trägerfrequenzen verwendet, um das Übersprechen zwischen verschiedenen Trägerfrequenzen zu minimieren.
Bei einigen Ausführungsarten sind die Perioden der verschiedenen Trägerfrequenzen ganzzahlige Vielfache der Periodendauer einer gemeinsamen Abtastfrequenz. Bei einigen Ausführungsarten kann diese gemeinsame Abtastfrequenz eine Standardabtastfrequenz sein, die mit einem Standardaudioformat verbunden ist. Beispielsweise kann die gemeinsame Abtastfrequenz 8.000 Hz, 11.025 Hz, 22.050 Hz oder 44.100 Hz betragen. Bei anderen Ausführungsarten ist das Verhältnis zwischen mindestens einer der Trägerfrequenzen und der Abtastfrequenz für die Erzeugung eines oder mehrerer digitaler Signale, die in ein oder mehrere akustische Signale umgewandelt werden sollen, kein ganzzahliger Wert. Bei einigen Ausführungsarten wird eine Abtastfrequenz ausgewählt, die mindestens doppelt so hoch ist wie die höchste Frequenz im zu erzeugenden Signal. Bei einigen Ausführungsarten wird eine Abtastfrequenz ausgewählt, die mindestens doppelt so hoch ist wie die höchste Trägerfrequenz zuzüglich der Baud-Rate.
Bei einigen Ausführungsarten sind die für die verschiedenen modulierten Trägerfrequenzen verwendeten Symbollängen ganzzahlige Vielfache der Periodendauer einer gemeinsamen Abtastfrequenz. Bei einigen Ausführungsarten sind die Symbollängen, die als die Anzahl an Perioden der jeweiligen Trägerfrequenzen angegeben sind, für alle Trägerfrequenzen identisch. Dadurch ergibt sich ein Unterschied bei den in Echtzeit angegebenen Symbollängen und damit bei der Symbolrate für die verschiedenen Trägerfrequenzen. Aber das Verhältnis zwischen Trägerfrequenz und Symbolrate wird konstant gehalten, und dies kann einfachere Ausführungen auf der Empfangsseite ermöglichen.
Bei einigen Ausführungsarten wird bei Trägerfrequenzen, die aus einer gemeinsamen Abtastfrequenz abgeleitet sind, für die Abtastfrequenz ein hoher Wert ausgewählt, um die Präzision der digitalisierten Signale zu erhöhen. Bei anderen Ausführungsarten wird bei Trägerfrequenzen, die aus einer gemeinsamen Abtastfrequenz abgeleitet sind, für die Abtastfrequenz ein niedriger Wert ausgewählt, um die (optionale) digitale Filterung zu vereinfachen und/oder die Größe der erzeugten Audiodateien zu reduzieren. Niedrigere Abtastfrequenzen können die Berechnungen bei der digitalen Filterung möglicherweise beschleunigen. Wenn beispielsweise FIR-Filter (Filter mit endlicher Impulsantwort) verwendet werden, kann die Anzahl der Taps im Filter bei niedrigeren Abtastfrequenzen geringer sein. Niedrigere Abtastfrequenzen und die damit verbundenen kleineren Audiodateien können die Anforderungen an Client-Computersysteme (z. B. in Bezug auf den Festplattenzugriff) senken und das Risiko von Diskontinuitäten oder anderen Fehlern bei der Tonerzeugung reduzieren, die beispielsweise dadurch verursacht werden können, dass die Festplatte eines Client-Computersystems Blöcke von Audiodateidaten mit zu hoher Latenz zurückgibt.
Bei einer beispielhaften Ausführungsart werden zwei Trägerfrequenzen verwendet. Für beide Trägerfrequenzen ist zum einen das Verhältnis zwischen der Trägerfrequenz und der Symbolrate identisch (beispielsweise kann bei beiden Trägerfrequenzen ein Symbol 8 Perioden der Trägerfrequenz benötigen). Zum anderen ist das Verhältnis zwischen den Symbolraten für alle Trägerfrequenzen und einer gemeinsamen Abtastfrequenz ein ganzzahliger Wert (beispielsweise kann die gemeinsame Abtastfrequenz 11.025 Hz und das Verhältnis zwischen der Symbolrate und der gemeinsamen Abtastfrequenz 76 für die niedrige Trägerfrequenz von 1.160,53 Hz bzw. 59 für die hohe Trägerfrequenz von 1.494,92 Hz sein).
Bei einigen Ausführungsarten sind die in Sekunden angegebenen Symbollängen für mehr als eine Trägerfrequenz identisch.
Bei einigen Ausführungsarten werden zwei Trägerfrequenzen vorteilhaft ausgewählt, sodass (mehr oder weniger) die folgende mathematische Gleichung gilt: F_niedrig + F_niedrig/L_Symbol ~ F_hoch – F_hoch/L_Symbol, wobei F_niedrig, F_hoch und L_Symbol stehen für: die niedrige Trägerfrequenz, die hohe Trägerfrequenz bzw. die Anzahl an Perioden der Trägerfrequenz, die zur Übertragung eines einzelnen Symbols verwendet werden. Diese Gleichung hat folgende Entsprechung: F_niedrig = F_hoch·(L_symbol – 1)/(L_Symbol + 1). Es wird davon ausgegangen, dass die Anzahl an Perioden der Trägerfrequenz für die Übertragung eines einzelnen Symbols L_Symbol bei beiden Trägerfrequenzen identisch ist. Dementsprechend ist die Baud-Rate auf der niedrigen Trägerfrequenz geringer als auf der hohen Trägerfrequenz. Wenn beispielsweise eine hohe Trägerfrequenz von 1.500 Hz und eine Symbollänge von 8 Perioden ausgewählt wird, kann die niedrige Trägerfrequenz als (7/9)·1.500 Hz = 1.167 Hz berechnet werden.
Bei einigen Ausführungsarten werden mehr als zwei Trägerfrequenzen verwendet. Bei einigen Ausführungsarten kann anhand der obigen Formel für jedes Paar benachbarter Trägerfrequenzen der Abstand zwischen den Trägerfrequenzen ermittelt werden. Die Trägerfrequenzen werden demnach so ausgewählt, dass die Gleichung F_i·(L_Symbol + 1)/(L_Symbol – 1) = F_i+1 (mehr oder weniger) gilt, wobei der Index i von 1 bis N – 1 reicht. Dabei stehen N für die Gesamtanzahl der Trägerfrequenzen und F_i für die i. Trägerfrequenz (F₀ steht für die niedrigste Trägerfrequenz, und F_N steht für die höchste der N Trägerfrequenzen). Wenn beispielsweise bei drei Trägerfrequenzen als niedrigste Trägerfrequenz 1.167 Hz und eine Symbollänge von 8 Perioden der Trägerwelle ausgewählt werden, kann eine mittlere Trägerfrequenz von (etwa) (9/7)·1.167 Hz = 1.500 Hz und eine hohe Trägerfrequenz von (etwa) (9/7)·1.500 Hz = 1.929 Hz ausgewählt werden.
Bei einigen Ausführungsarten wird ein Modulationsverfahren (wie die Phasenumtastung) verwendet, für das die spektrale Leistungsdichte der modulierten Trägerfrequenzen durch die Funktion [sinc²((f – f_c)·(L_Symbol/f_c)) + sinc²((f – f_c)·(L_Symbol f_c))] beschrieben wird (wobei sinc die normalisierte Sinc-Funktion ist, also sin(Pi·x)/(Pi·x), und f ist die Frequenz und f_c ist die Trägerfrequenz). Diese Funktion hat Nullen bei jeder Frequenz, deren Abstand zur Trägerfrequenz ein ganzzahliges Vielfaches der Symbolrate ist. Wenn die Trägerfrequenzen gemäß den oben angegebenen Formeln ausgewählt werden (also F_niedrig = F_hoch·(L_Symbol – 1)/(L_Symbol + 1) und/oder F_i·(L_Symbol + 1)/(L_Symbol – 1) = F_i+1), stimmen die ersten Minima bei den Funktionen für die spektrale Leistungsdichte benachbarter modulierter Trägerfrequenzen überein.
Filterung
Bei einigen Ausführungsarten können die aus der Modulation der Trägerfrequenzen hervorgehenden Signale vor der Ausgabe gefiltert werden, um die Nebenkeulen außerhalb der Hauptkeulen für die jeweiligen Trägerfrequenzen in der Frequenzdomäne zu unterdrücken. Dies reduziert das Übersprechen zwischen den Signalen der verschiedenen modulierten Trägerfrequenzen. Bei einigen Ausführungsarten kann beispielsweise ein Basisbandsignal mit einer Kopie der zu übertragenden Daten gefiltert werden, bevor ein Träger mit dem Basisbandsignal moduliert wird. Bei einigen Ausführungsarten kann diese Filterung vor dem Mischen einen RRC-Filter (Root Raised Cosine) oder SRRC-Filter (Square Root Raised Cosine) beinhalten. Bei einigen Ausführungsarten kann der modulierte Träger gefiltert werden. Bei einigen Ausführungsarten kann beispielsweise das digitale Signal, das durch das Mischen eines Trägers mit einem (optional vorgefilterten) Basisbandsignal entsteht, mit einem Bandbreitenfilter gefiltert werden. Eine Vorfilterung der Signale vor deren Ausgabe als Tonsignale kann somit den Vorteil haben, dass die Kanalbandbreite und die Intersymbolinterferenz reduziert und das Signal-Rausch-Verhältnis des ausgegebenen akustischen Signals verbessert werden und das akustische Signal vom Benutzer als weniger störend empfunden wird (trotz Verwendung derselben Lautstärke ist das gefilterte Signal weniger stark, hört sich also leiser an, weil die Niederfrequenzkomponente unterdrückt wird und damit z. B. störende Klickgeräusche jedes Mal beseitigt werden, wenn bei einer Phasenänderung Signale per Phasenumtastung moduliert werden).
Bei einigen Ausführungsarten ist die Stärke der Signale (vor der physischen akustischen Ausgabe) auf den verschiedenen modulierten Trägerfrequenzen gleich oder ähnlich. Bei anderen Ausführungsarten ist die Stärke des Signals auf mindestens einer modulierten Trägerfrequenz niedriger als die Stärke des Signals auf mindestens einer anderen Trägerfrequenz. Ein Vorteil der Verwendung einer niedrigeren Stärke auf einer Trägerfrequenz besteht darin, dass diese Trägerfrequenz weniger Interferenzen für die anderen Trägerfrequenzen verursacht. Bei einigen Ausführungsarten ist die Stärke des Signals auf mindestens einer modulierten Trägerfrequenz so eingestellt, dass sie einerseits niedriger als die Stärke des Signals auf mindestens einer anderen Trägerfrequenz ist. Andererseits ist sie immer noch stark genug, um vom empfangenden Token empfangen werden zu können, wenn die vom Token empfangene Stärke der zweiten Trägerfrequenz z. B. durch Resonanzen im ausgebenden Lautsprecher oder aufgrund einer destruktiven Interferenz wegen Mehrfachempfangs unterdrückt ist. Bei einigen Ausführungsarten werden beispielsweise Zwei Trägerfrequenzen gleichzeitig verwendet und die Stärke der ersten modulierten Trägerfrequenz liegt 6 dB unter der Stärke der anderen modulierten Trägerfrequenz. Bei einigen Ausführungsarten wird die Verteilung der Stärke für die verschiedenen Signale auf den verschiedenen modulierten Trägerfrequenzen Zeitabhängig verändert. Bei einigen Ausführungsarten werden beispielsweise zwei Trägerfrequenzen gleichzeitig verwendet und das Ausgabesystem wechselt kontinuierlich zwischen Perioden, in denen die Stärke der ersten modulierten Trägerfrequenz 6 dB unter der Stärke der anderen modulierten Trägerfrequenz liegt, und Perioden, in denen genau die umgekehrte Situation vorliegt (die Zweite Trägerfrequenz ist 6 dB schwächer als die erste Trägerfrequenz). Bei einigen Ausführungsarten werden als Längen dieser Perioden ganzzahlige Vielfache der Nachrichtenlängen auf den verschiedenen modulierten Trägerfrequenzen ausgewählt.
Bei einigen Ausführungsarten können die Signale der verschiedenen modulierten Trägerfrequenzen gemischt werden, bevor das gemischte Signal über einen oder mehrere Lautsprecher akustisch ausgegeben wird. Bei einigen Ausführungsarten wird für die Ausgabe des gemischten akustischen Signals nur ein Lautsprecher des ausgebenden Client-Computergeräts verwendet. Bei anderen Ausführungsarten werden für die Ausgabe des gemischten akustischen Signals alle verfügbaren Lautsprecher des ausgebenden Client-Computergeräts verwendet.
Bei einigen Ausführungsarten werden die verschiedenen modulierten Trägerfrequenzsignale vor der akustischen Ausgabe nicht gemischt. Bei einigen Ausführungsarten können mindestens einige der verschiedenen modulierten Trägerfrequenzsignale akustisch über separate Lautsprecher ausgegeben werden. Bei einigen Ausführungsarten können beispielsweise zwei Trägerfrequenzen verwendet werden und das niedrige Trägerfrequenzsignal kann über einen Lautsprecher ausgegeben werden, während das hohe Trägerfrequenzsignal über einen anderen Lautsprecher ausgegeben wird.
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 einigen Ausführungsarten beinhaltet das Übertragungssystem für das Senden von Eingabedaten an ein Token ein Client-Computergerät, mit dem der Benutzer interagiert (z. B. Zugriff auf eine internetbasierte Anwendung). Das Client-Computergerät kann folgende Komponenten beinhalten: Verarbeitungskomponenten (wie einen Mikroprozessor) für die Datenverarbeitung und/oder Ausführung von Software, Speicherkomponenten (wie eine Festplatte) für die Speicherung von Daten und/oder Software, Benutzeroberflächenkomponenten (wie eine Anzeige, eine Tastatur und/oder eine Maus) für die Interaktion mit dem Benutzer (dies kann das Bereitstellen von Ausgaben an den Benutzer und das Empfangen von Eingaben vom Benutzer beinhalten) sowie Kommunikationskomponenten (wie eine Netzwerkschnittstelle, z. B. eine Ethernet-Karte) für die Interaktion beispielsweise mit einem Webserver über ein Computernetzwerk (wie das Internet). Bei einigen Ausführungsarten kann das Client-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 Client-Computergerät des Benutzers mit einem oder mehreren Lautsprechern ausgestattet, die Tonsignale im akustisch wahrnehmbaren Frequenzbereich ausgeben können. Bei einer bestimmten Ausführungsart geben ein oder mehrere Lautsprecher am Client-Computergerät des Benutzers die von einer auf dem PC ausgeführten Softwareanwendung erzeugten Tonsignale aus. Bei einer Ausführungsart beinhaltet die auf dem Client-Computergerät des Benutzers ausgeführte Softwareanwendung einen Browser, auf dem ein in eine Webseite integriertes Applet oder Plug-In ausgeführt werden kann. Bei einer Ausführungsart beinhaltet das Applet eine Flash-Anwendung. Bei einigen Ausführungsarten kann die Webseite eine Audiodatei mit einer digitalen Kopie des akustischen Signals mit den Eingabedaten für das Token beinhalten. Bei einigen Ausführungsarten kann die Audiodatei eine WAVE- oder WAV-Datei (Waveform Audio File Format) beinhalten. 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 Übertragungssystem für das Senden von Eingabedaten an ein Token auch einen Servercomputer. Der Servercomputer kann folgende Komponenten beinhalten: Verarbeitungskomponenten (wie einen oder mehrere Mikroprozessoren) für die Datenverarbeitung und/oder Ausführung von Software, Speicherkomponenten (wie eine oder mehrere Festplatten) für die Speicherung von Daten (z. B. in einer Datenbank) und/oder Software sowie Kommunikationskomponenten (wie eine oder mehrere Netzwerkschnittstellen, z. B. eine Ethernet-Karte) für die Interaktion beispielsweise mit einem Client-Computergerät über ein Computernetzwerk (wie das Internet). Bei einigen Ausführungsarten kann der Servercomputer einen Webserver beinhalten. Bei einigen Ausführungsarten kann der Servercomputer über ein Computernetzwerk wie das Internet mithilfe von Computerkommunikationsprotokollen wie TCP/IP (Transmission Control Protocol/Internet Protocol), SSL/TLS (Secure Sockets Layer/Transport Layer Security) oder HTTP (Hypertext Transfer Protocol) Daten mit einem Client-Computergerät austauschen. Bei einigen Ausführungsarten stellt der Servercomputer dem Client-Computergerät eine oder mehrere Webseiten zur Verfügung, auf denen sich Daten zur Übertragung an das Authentisierungstoken befinden. Bei einigen Ausführungsarten können die Webseiten (eine oder mehrere) eine Audiodatei mit einer digitalen Kopie des akustischen Signals mit den Eingabedaten für das Token beinhalten. Bei einigen Ausführungsarten kann die Audiodatei beispielsweise eine WAVE- oder WAV-Datei (Waveform Audio File Format) beinhalten.
Bei einigen Ausführungsarten beinhaltet das Token eine akustische Schnittstelle mit mindestens einem Mikrofon und einer 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 ein oder mehrere digitale Signale umwandelt. Bei einer Ausführungsart ist die Demodulationsschaltung mit einem Element zur Datenverarbeitung verbunden, das die in dem digitalen Signal bzw. den digitalen Signalen codierten Eingabedaten extrahieren und verarbeiten kann.
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 Trägerfrequenz (abzüglich einer bestimmten Spanne) und oberhalb der höchsten Trägerfrequenz (zuzüglich einer bestimmten Spanne) unterdrückt. Bei einigen Ausführungsarten beinhaltet das Token für jede Trägerfrequenz einen auf die jeweilige Trägerfrequenz ausgerichteten Bandbreitenfilter. Bei einigen Ausführungsarten beinhaltet das Token einen Bandbreitenfilter, der auf eine ausgewählte Trägerfrequenz eingestellt und ausgerichtet werden kann.
Bei einigen Ausführungsarten kann das Token jeweils immer nur eine Trägerfrequenz demodulieren. Für das Token kann eine anfängliche Trägerfrequenz ausgewählt werden. Wenn das Token über die ausgewählte Trägerfrequenz erfolgreich Eingabedaten empfangen kann, setzt das Token die Demodulation der ausgewählten Trägerfrequenz fort. Das Token kann einige Kriterien für den Wechsel auf eine andere Trägerfrequenz anwenden. Einige dieser Kriterien können sich auf die Stärke des empfangenen Signals in einem Frequenzband um die ausgewählte Trägerfrequenz beziehen (absolut oder in Bezug auf die Stärke in einem anderem Frequenzband, z. B. einem Frequenzband um eine andere Trägerfrequenz). Das Token kann beispielsweise die Trägerfrequenz mit der größten Stärke in einem bestimmten Frequenzband um diese Trägerfrequenz auswählen. Einige Kriterien für den Wechsel auf eine andere Trägerfrequenz können sich auf die empfundene Fehlerrate im demodulierten Signal richten. Das Token kann beispielsweise eine andere Trägerfrequenz auswählen, wenn die augenscheinliche Fehlerrate nach einer bestimmten Zeit einen bestimmten Schwellenwert überschreitet.
Bei einigen Ausführungsarten kann das Token mehrere Trägerfrequenzen parallel demodulieren. Bei einigen Ausführungsarten kann das Token aus den verschiedenen demodulierten Trägerfrequenzen einen Datenstrom zur weiteren Verarbeitung auswählen. Bei einigen Ausführungsarten wendet das Token bestimmte Kriterien für die Auswahl des Datenstroms zur weiteren Verarbeitung aus den verschiedenen Trägerfrequenzen an, die parallel demoduliert werden. Diese Kriterien können sich auf bestimmte Eigenschaften der empfangenen Trägerfrequenzsignale wie die Stärke in einem Frequenzband um eine Trägerfrequenz richten, oder auf die empfundene Fehlerrate in den jeweiligen Datenströmen. Bei einigen Ausführungsarten werden die verschiedenen Datenströme zur weiteren Verarbeitung in einem einzigen Datenstrom zusammengefasst. Bei einer Ausführungsart können beispielsweise mehr als zwei Trägerfrequenzen verwendet werden, auf denen die Daten redundant synchron ausgegeben werden (Verwendung derselben Baud-Rate), und die verschiedenen erzeugten Datenströme werden einfach über einen Redundanzmechanismus zusammengefasst. Der Symbolwert, der in einem bestimmten Zeitraum in den verschiedenen Datenströmen für die verschiedenen zu demodulierenden Trägerfrequenzen am häufigsten vorkommt, wird hierbei als Symbolwert für den erzeugten Datenstrom zur weiteren Verarbeitung zurückgehalten.
Bei einigen Ausführungsarten ist die Anzahl der verschiedenen Trägerfrequenzen, die das Token parallel demodulieren kann, geringer als die Gesamtanzahl an Trägerfrequenzen, die auf der Sendeseite verwendet werden. Bei einigen Ausführungsarten kann das Token von Zeit zu Zeit die parallel demodulierten Trägerfrequenzen ändern. Bei einigen Ausführungsarten kann das Token von Zeit zu Zeit eine oder mehrere der parallel demodulierten Trägerfrequenzen hinzufügen, entfernen oder ersetzen. Das Token kann verschiedene Auswahlkriterien anwenden, um zu entscheiden, wann und welche der parallel demodulierten Trägerfrequenzen hinzugefügt, entfernt oder ersetzt werden. Diese Kriterien können sich auf bestimmte Eigenschaften der Trägerfrequenzsignale wie die Stärke in einem Frequenzband um eine Trägerfrequenz richten, oder auf die empfundenen Fehlerraten in den jeweiligen Datenströmen der demodulierten Trägerfrequenzen.
Bei einigen Ausführungsarten beinhaltet das Token eine Kombination aus Hardware und Software zur Durchführung der Signalverarbeitung entsprechend der Beschreibung in einigen der vorstehenden Absätze. Bei einigen Ausführungsarten erfolgt die Signalverarbeitung (außer der Analog-Digital-Wandlung) ganz oder teilweise über Software, die auf einem oder mehreren Mikroprozessoren ausgeführt wird. Bei einigen Ausführungsarten beinhaltet das Token Hardware und/oder Software für die digitale Signalverarbeitung, sodass die Signalverarbeitung vollständig oder teilweise entsprechend der Beschreibung in einigen der vorstehenden Absätze durchgeführt werden kann.
Bei einigen Ausführungsarten kann das Token neben der Schnittstelle für die akustische Eingabe über zusätzliche Dateneingabemechanismen für den Empfang von Eingabedaten verfügen. Diese 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. Bei einigen Ausführungsarten kann die Schnittstelle für die Benutzereingabe über einen Touchscreen verfügen. Bei einigen Ausführungsarten kann die Schnittstelle für die Benutzereingabe eine Bildschirmtastatur beinhalten, also ein Bild einer Tastatur mit Navigation per Tastatur oder Touchscreen. 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. Herbei 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 NachrichtenAuthentisierungscode (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.
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 oder HMAC 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 nach der Verifizierung der PIN die Speicherorte, an denen eine derartige PIN temporär gespeichert wurde, 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 in dem Folgenden: Ein Token für eine starke Authentisierung mit einer akustischen Schnittstelle und einer Demodulationsschaltung, bei dem das Token mehrere akustische Signale empfangen kann, die verschiedene Trägerfrequenzen verwenden und dieselben an das Token zu übertragenden Daten übertragen, wobei diese Daten redundant ausgegeben werden (gleichzeitig oder nacheinander), unterstützt bei einigen Ausführungsarten der Erfindung die robuste und zuverlässige Demodulation akustischer Signale selbst bei Vorliegen von Störgeräuschen, Resonanzen bei den ausgebenden Lautsprechern und einem Mehrfachempfang aufgrund von Reflexionen.
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 ein Authentisierungstoken anhand eines Aspekts der Erfindung.
zeigt schematisch eine andere Ausführungsart 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 anhand eines Aspekts der Erfindung eine Methode für den sicheren Benutzerzugriff auf eine Remoteanwendung.
zeigt ein System für die Übertragung von Eingabedaten an ein Authentisierungstoken mit einer Schnittstelle für die akustische Eingabe anhand eines Aspekts der Erfindung.
zeigt eine Methode für die Übertragung von Eingabedaten an ein Authentisierungstoken mit einer Schnittstelle für die akustische Eingabe anhand eines Aspekts der Erfindung.
zeigt eine Methode für ein Authentisierungstoken (mit einer Schnittstelle für die akustische Eingabe, um Daten akustisch empfangen zu können).
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 Daten, die Konfigurationsdaten enthalten können, und/oder die Speicherung von 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.

Die Komponente zur Datenverarbeitung (150) kann mit der akustischen Schnittstelle (110), der Schnittstelle für die manuelle Dateneingabe durch den Benutzer (120) und/oder der Schnittstelle für die optische Dateneingabe (140) verbunden sein, um Daten zu empfangen. Die Komponente zur Datenverarbeitung (150) kann mit einer vertrauenswürdigen Ausgabeschnittstelle (130) verbunden sein, um Informationen an den Benutzer zu übertragen. Die Komponente zur Datenverarbeitung (150) kann mit der Komponente zur Datenspeicherung (160) verbunden sein, diese beinhalten oder Teil derselben Komponente sein und sie kann möglicherweise Daten aus der Komponente zur Datenspeicherung (160) lesen und/oder in diese schreiben. Die Komponente zur Datenverarbeitung (150) kann mit der Uhr (170) verbunden sein, diese beinhalten oder Teil derselben Komponente sein und sie kann möglicherweise einen Zeitwert von der Uhr (170) abrufen.
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 einigen Ausführungsarten beinhaltet die akustische Schnittstelle (110) ein Mikrofon und eine Demodulationsschaltung. Bei einigen Ausführungsarten kann die akustische Schnittstelle (110) mehr als ein Mikrofon beinhalten.
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).

Die Komponente zur Datenverarbeitung (151) kann mit der akustischen Schnittstelle (111), der Schnittstelle für die manuelle Dateneingabe durch den Benutzer (121) und/oder der Schnittstelle für die optische Dateneingabe (141) verbunden sein, um Daten zu empfangen. Die Komponente zur Datenverarbeitung (151) kann mit einer vertrauenswürdigen Ausgabeschnittstelle (131) verbunden sein, um Informationen an den Benutzer zu übertragen. Die Komponente zur Datenverarbeitung (151) kann mit der Komponente zur Datenspeicherung (161) verbunden sein, diese beinhalten oder Teil derselben Komponente sein und sie kann möglicherweise Daten aus der Komponente zur Datenspeicherung (161) lesen und/oder in diese schreiben. Die Komponente zur Datenverarbeitung (151) kann mit der Uhr (171) verbunden sein, diese beinhalten oder Teil derselben Komponente sein und sie kann möglicherweise einen Zeitwert von der Uhr (171) abrufen.
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 einigen Ausführungsarten beinhaltet die akustische Schnittstelle (111) ein Mikrofon und eine Demodulationsschaltung. Bei einigen Ausführungsarten kann die akustische Schnittstelle (110) mehr als ein Mikrofon beinhalten.
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).
Bei einigen Ausführungsarten beinhaltet ein Authentisierungstoken (100/101) eine akustische Schnittstelle (110/111) mit einer Demodulationsschaltung, über die zwei oder mehrere modulierte Träger gleichzeitig demoduliert werden können. Die Demodulationsschaltung kann beispielsweise eine Vielzahl von Demodulationsschaltungen beinhalten, die jeweils einen modulierten Träger auf einer bestimmten Trägerfrequenz demodulieren können. Bei einigen Ausführungsarten stellt die Demodulationsschaltung einer Komponente zur Datenverarbeitung (150/151) des Authentisierungstoken (100/101) zwei oder mehrere demodulierte Datenströme zur weiteren Verarbeitung bereit.
Bei einigen Ausführungsarten beinhaltet ein Authentisierungstoken (100/101) eine akustische Schnittstelle (110/111) mit einer Demodulationsschaltung, die jeweils immer nur einen einzigen Träger demodulieren kann. Bei einigen Ausführungsarten kann die Demodulationsschaltung auf eine Vielzahl verschiedener Trägerfrequenzen eingestellt werden. Bei einigen Ausführungsarten versucht das Authentisierungstoken (100/101) immer höchstens einen modulierten Träger zu empfangen und zu demodulieren. Bei einigen Ausführungsarten kann das Authentisierungstoken für den zu demodulierenden Träger eine Trägerfrequenz aus einer Vielzahl möglicher Trägerfrequenzen auswählen. Bei einigen Ausführungsarten wählt das Authentisierungstoken im Empfangsmodus eine Trägerfrequenz aus einer Vielzahl möglicher Trägerfrequenzen aus und versucht, zum Nachrichtenempfang einen modulierten Träger auf der ausgewählten Trägerfrequenz zu empfangen und zu demodulieren. Bei einigen Ausführungsarten wählt das Authentisierungstoken möglicherweise zu einem bestimmten Zeitpunkt eine andere Trägerfrequenz als die ursprünglich ausgewählte Frequenz aus und versucht, einen modulierten Träger auf der neu ausgewählten Trägerfrequenz zu empfangen und zu demodulieren. Bei einigen Ausführungsarten erfolgt dieser Vorgang möglicherweise als Reaktion auf die Erfüllung bestimmter Bedingungen. Diese Bedingungen können beispielsweise darin bestehen, dass ein modulierter Träger auf der ausgewählten Trägerfrequenz nicht innerhalb eines bestimmten Zeitraums empfangen und demoduliert werden konnte, dass in einem Frequenzband für die ausgewählte Trägerfrequenz eine nicht ausreichende Stärke erkannt wurde oder dass eine bestimmte Sequenz oder ein bestimmtes Teil des Signals nicht innerhalb eines bestimmten Zeitraums erkannt werden konnte. Eine bestimmte Sequenz oder ein bestimmtes Teil des Signals dieser Art kann beispielsweise eine bestimmte Abfolge von Symbolen, eine bestimmte Wellenform oder ein Teil des Signals mit dem unmodulierten Träger sein. Bei einigen Ausführungsarten werden diese Bedingungen fortlaufend überprüft. Bei anderen Ausführungsarten werden diese Bedingungen nur von Zeit zu Zeit überprüft.
Bei einigen Ausführungsarten ist die Ausgangsträgerfrequenz, die vom Authentisierungstoken beim Wechsel in den Empfangsmodus verwendet wird, ein konstanter Parameter. Bei einigen Ausführungsarten ist die Ausgangsträgerfrequenz, die vom Authentisierungstoken beim Wechsel in den Empfangsmodus verwendet wird, die zuletzt erfolgreich verwendete Trägerfrequenz. Bei einigen Ausführungsarten kann das Authentisierungstoken Leistungskennzahlen für die verschiedenen möglichen Trägerfrequenzen speichern und die Ausgangsfrequenz auf der Grundlage dieser gespeicherten Leistungskennzahlen auswählen. Bei einigen Ausführungsarten basieren diese gespeicherten Leistungskennzahlen auf früheren Leistungswerten. Eine Grundlage kann beispielsweise der relative Erfolgsquotient der verschiedenen möglichen Frequenzen bei kürzlich erfolgten Versuchen des Datenempfangs sein. Bei einigen Ausführungsarten basiert die Ausgangsfrequenz, die das Authentisierungstoken bei Auswahl des Empfangsmodus zu verwenden versucht, auf dynamischen Prüfungen. Bei einigen Ausführungsarten können diese Prüfungen das Messen der Signalstärke in Frequenzbändern für jede der möglichen Trägerfrequenzen umfassen. Bei einigen Ausführungsarten wird die Trägerfrequenz, bei der in einem zugehörigen Frequenzband die höchste Stärke gemessen wird, als die Ausgangsträgerfrequenz ausgewählt.
Bei vielen Ausführungsarten ist das Authentisierungstoken (100/101) ein relativ kleines und leichtes Gerät. Bei vielen Ausführungsarten kann es sich um ein tragbares Handgerät handeln. Es kann beispielsweise weniger als 10 cm lang, weniger als 2 cm tief und weniger als 7 cm breit sein. Das Authentisierungstoken (100/101) kann beispielsweise weniger als 100 g wiegen.
Bei vielen Ausführungsarten beinhaltet das Authentisierungstoken (100/101) ein eigenes Netzteil. Es kann beispielsweise eine oder mehrere Batterien beinhalten. Bei einigen Ausführungsarten können die Batterien herausgenommen werden.
zeigt schematisch eine Demodulationsschaltung (300) anhand eines Aspekts der Erfindung.
Die Demodulationsschaltung (300) kann beispielsweise dafür verwendet werden, um per binärer Phasenumtastung modulierte akustische Signale zu demodulieren.
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 in alle Mischerkomponenten (340 und 341) eingespeist. Die Phasenregelschleife (330) wird auf eine ausgewählte Trägerfrequenz eingestellt und erzeugt zwei Referenzsignale. Eines der Referenzsignale (331) hat dieselbe Frequenz und Phase wie die Trägerfrequenz. Dieses Referenzsignal (331) wird für die Mischerkomponente (340) bereitgestellt, die das Referenzsignal (331) mit dem per Bandbreitenfilter gefilterten Eingabesignal mischt. Die Mischerkomponente (340) gibt die niedrigen Frequenzanteile aus, die vom Tiefpassfilter (350) gefiltert werden. Dieser entfernt die Doppelfrequenzkomponenten aus der Ausgabe der Mischerkomponente (350). Dadurch beinhaltet die Ausgabe des Tiefpassfilters (350) ein Basisbandsignal mit Eingabedaten, die mithilfe eines Digital-Analog-Wandlers (nicht abgebildet) in ein digitales Signal umgewandelt und in eine Komponente zur Datenverarbeitung eingespeist werden können. Das andere Referenzsignal (332) hat dieselbe Frequenz wie die Trägerfrequenz, ist jedoch um 90 Grad phasenverschoben. Dieses Referenzsignal (332) wird für die Mischerkomponente (341) bereitgestellt, die das Referenzsignal (332) mit dem per Bandbreitenfilter gefilterten Eingabesignal mischt. Die Mischerkomponente (341) gibt die niedrigen Frequenzanteile aus, die vom Tiefpassfilter (351) gefiltert werden. Der Tiefpassfilter (351) gibt die Verschiebung der Phasenregelschleife aus.
Bei einigen Ausführungsarten beinhaltet der Vorverstärker (320) einen Bandbreitenfilter. 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) und/oder des Tiefpassfilters (351) mehr oder weniger der angenommenen Baud-Rate des Eingabesignals. Bei einigen bestimmten Ausführungsarten ist die Grenzfrequenz des Tiefpassfilters (350) und/oder des Tiefpassfilters (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 um die ausgewählte Trägerfrequenz. Sie arbeitet auf einer mehr oder weniger festen ausgewählten Trägerfrequenz, und es sind nur sehr geringe Abweichungen möglich, um eine Phasenangleichung an diese ausgewählte Trägerfrequenz sicherzustellen.
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 kann ein Authentisierungstoken anhand eines Aspekts der Erfindung eine Demodulationsschaltung (300) beinhalten, über die mehr als eine Trägerfrequenz moduliert werden kann. Bei einigen Ausführungsarten kann die Demodulationsschaltung (300) auf verschiedene Trägerfrequenzen eingestellt werden. Bei einigen Ausführungsarten beinhaltet ein Authentisierungstoken eine separate Demodulationsschaltung (300) für jede einzelne Trägerfrequenz. Bei einigen Ausführungsarten können die Demodulationsschaltungen (300) eng auf eine einzige feste Trägerfrequenz eingestellt werden.
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, um z. B. auf eine Remote-Anwendung zuzugreifen (z. B. über das Internet). 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 einigen Ausführungsarten kann dieser Schritt umfassen, dass der Benutzer transaktionsbezogene Daten für die Remote-Anwendung bereitstellt.
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 einigen Ausführungsarten werden möglicherweise alle oder ein Teil der Eingabedaten vom Computergerät des Benutzers zusammengesetzt. Bei einigen Ausführungsarten beispielsweise stellt der Benutzer transaktionsbezogene Daten für das Computergerät des Benutzers bei Schritt 505 bereit. Das Computergerät des Benutzers kann dann einerseits diese transaktionsbezogenen Daten an den Anwendungsserver weiterleiten und andererseits die Eingabedaten zusammensetzen, die aus den transaktionsbezogenen Daten bestehen oder diese beinhalten können.
Bei Schritt 525 kann das Computergerät des Benutzers ein moduliertes akustisches Signal ausgeben, das die Eingabedaten verschlüsselt. Der Schritt der Verschlüsselung eines akustischen Signals mit den Eingabedaten kann (teilweise) über den Anwendungsserver und/oder (teilweise) über das Computergerät des Benutzers erfolgen. Bei einigen Ausführungsarten beispielsweise kann der Anwendungsserver die Eingabedaten zusammensetzen und ein digitalisiertes akustisches Signal verschlüsseln. Der Anwendungsserver kann das digitalisierte akustische Signal an das Computergerät senden (z. B. in Form einer Audiodatei wie einer WAV-Datei) und das Computergerät kann dieses digitalisierte akustische Signal auf seinen Lautsprechern wiedergeben. Bei anderen Ausführungsarten kann das Computergerät des Benutzers die Eingabedaten wie oben beschrieben erhalten (z. B. über den Anwendungsserver oder vom Benutzer), ein digitalisiertes akustisches Signal mit diesen Eingabedaten verschlüsseln und dieses digitalisierte akustische Signal dann auf seinen Lautsprechern wiedergeben.
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.
zeigt ein System (600) für die Übertragung von Daten an ein Authentisierungstoken (100/101) mit einer Schnittstelle für die akustische Eingabe (110/111). Das System (600) beinhaltet ein Computergerät des Benutzers (610). Das System kann auch ein Servercomputersystem (650) beinhalten.
Das Computergerät des Benutzers (610) kann folgende Komponenten beinhalten: eine Komponente zur Datenverarbeitung (wie einen Mikroprozessor) (620), eine oder mehrere Komponenten zur Datenspeicherung (625), möglicherweise mit RAM und/oder einer oder mehreren Festplatten, eine Kommunikationsschnittstelle (wie eine Ethernet-Karte) (630) für die Kommunikation mit einem Servercomputersystem (650) über ein Computernetzwerk (wie das Internet) (690), eine Benutzeroberfläche (635) für den Empfang von Informationen von und die Ausgabe von Informationen an einen Benutzer (wie eine Anzeige, Tastatur und/oder Maus) und eine Schnittstelle für die akustische Ausgabe (640) zur Ausgabe von Tonsignalen im akustisch wahrnehmbaren Frequenzbereich. Die Schnittstelle für die akustische Ausgabe (640) kann eine oder mehrere Soundkarten (641), einen oder mehrere Digital-Analog-Wandler, einen oder mehrere Verstärker und einen oder mehrere Lautsprecher (645) beinhalten. Das Computergerät des Benutzers (610) kann eine Software-Anwendung zur Soundwiedergabe (wie Windows Media Player oder RealPlayer) für die Wiedergabe von Audiodateien beinhalten. Das Computergerät des Benutzers (610) kann beispielsweise einen PC, einen Laptop, ein Smartphone, einen PDA (Personal Digital Assistant) oder einen Tablet-Computer beinhalten.
Das Servercomputersystem (650) kann folgende Komponenten beinhalten: eine oder mehrere Komponenten zur Datenverarbeitung (wie einen oder mehrere Mikroprozessoren) (660), eine oder mehrere Kommunikationsschnittstellen (wie eine Ethernet-Karte) (670) für die Kommunikation mit einem oder mehreren Computergeräten des Benutzers (610) über ein Computernetzwerk (wie das Internet) (690), eine oder mehrere Komponenten zur Datenspeicherung (680), möglicherweise mit RAM und/oder einer oder mehreren Festplatten und/oder einer oder mehreren Datenbanken.
zeigt eine Methode (700) für die Übertragung von Eingabedaten an ein Authentisierungstoken (100/101) mit einer Schnittstelle für die akustische Eingabe (110/111). 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 710 werden Eingabedaten für die Übertragung an das Authentisierungstoken (100/101) empfangen. Dieser Schritt kann beispielsweise das Empfangen eines Anforderungswerts (möglicherweise ein zufälliger Wert) und/oder transaktionsbezogener Daten (möglicherweise vom Benutzer bereitgestellt) umfassen. Bei einigen Ausführungsarten können die Eingabedaten andere Arten von Daten wie Konfigurationsdaten für das Token beinhalten. Bei einigen Ausführungsarten können die Eingabedaten Serveranmeldeinformationen beinhalten (wie ein dynamisches Kennwort oder eine Signatur für alle oder einen Teil der Eingabedaten), das für die Authentisierung des Servers oder des Erstellers der Eingabedaten beim Token oder für den Schutz der Integrität und/oder Vertraulichkeit aller oder eines Teils der Eingabedaten verwendet wird.
Bei Schritt 720 wird eine Bitfolge zusammengesetzt, mit der die Eingabedaten verschlüsselt werden. Dieser Schritt kann Folgendes umfassen: das Formatieren der Eingabedaten, das Hinzufügen von Tags, die Eingabe der Eingabedaten in Datenfeldstrukturen, das Verketten von Daten oder Datenfeldern, das Hinzufügen von Padding-Bits oder -Byte, kryptografische Vorgänge wie das Verschlüsseln, Hashing und/oder Signieren, das Hinzufügen von Codes für die Fehlererkennung und/oder Fehlerkorrektur, das Bitstopfen oder ähnliche Vorgänge.
Bei Schritt 730 kann die Bitfolge in eine Symbolkette umgewandelt werden. Bei einigen Ausführungsarten werden nur zwei Symbole verwendet. Bei anderen Ausführungsarten werden mehr als zwei Symbole verwendet.
Bei Schritt 740 wird die Symbolkette in ein oder mehrere digitalisierte akustische Signale umgewandelt. Bei einigen Ausführungsarten werden die digitalisierten akustischen Signale (eines oder mehrere) in ein Standardformat für Audiodateien wie das WAVE- oder WAV-Dateiformat (Waveform Audio File Format) formatiert. Bei einigen Ausführungsarten können andere Audiodateiformate wie MP3 verwendet werden. Dieser Schritt kann eine Reihe von Teilschritten umfassen.
Bei einigen Ausführungsarten können diese Teilschritte das Erstellen (741) eines oder mehrerer digitaler Basisbandsignale umfassen. Bei einigen Ausführungsarten repräsentiert jedes digitale Basisbandsignal dieselbe Symbolkette. Bei einigen Ausführungsarten werden mehrere Basisbandsignale erstellt. Dabei werden zur Erstellung der verschiedenen Basisbandsignale Symbolketten verwendet, die die Eingabedaten auf verschiedene Weise oder in unterschiedlichen Formaten verschlüsseln. Bei einigen Ausführungsarten wird zur Erstellung der digitalen Basisbandsignale (eines oder mehrere) eine Standardabtastfrequenz wie 8.000 Hz, 11.025 Hz, 22.050 Hz oder 44.100 Hz verwendet.
Bei einigen Ausführungsarten können diese Teilschritte (optional) eine digitale Vorfilterung (742) von mindestens einigen der digitalen Basisbandsignale (eines oder mehrere) umfassen. Bei einigen Ausführungsarten kann diese Vorfilterung einen RRC-Filter (Root Raised Cosine) oder SRRC-Filter (Square Root Raised Cosine) beinhalten.
Bei einigen Ausführungsarten umfassen diese Teilschritte die Modulation (743) von mindestens zwei Trägern mit verschiedenen Trägerfrequenzen mit den digitalen Basisbandsignalen. Diese Trägerfrequenzen können wie in den vorstehenden Absätzen beschrieben ausgewählt worden sein. Die Träger können wie in den vorstehenden Absätzen beschrieben moduliert sein. Bei einigen Ausführungsarten werden die Träger per binärer Phasenumtastung moduliert.
Bei einigen Ausführungsarten haben alle modulierten Träger dieselbe Baud-Rate. Bei einigen Ausführungsarten besteht ein festes Verhältnis zwischen der Baud-Rate und der Trägerfrequenz für mindestens zwei der Träger. Bei einigen Ausführungsarten besteht ein festes Verhältnis zwischen der Baud-Rate und der Trägerfrequenz für alle Träger. Bei anderen Ausführungsarten ist die Baud-Rate für mindestens zwei der Träger identisch. Bei einigen Ausführungsarten ist die Baud-Rate für alle Träger identisch.
Bei einigen Ausführungsarten wird dasselbe Basisbandsignal für die Modulation von mindestens zwei Trägern verwendet. Bei einigen Ausführungsarten wird dasselbe Basisbandsignal für die Modulation aller Träger verwendet. Bei einigen Ausführungsarten wird für jeden Träger ein anderes modulierendes Basisbandsignal verwendet.
Bei einigen Ausführungsarten umfassen diese Teilschritte die Filterung (744) eines oder mehrerer der modulierten Träger. Bei einigen Ausführungsarten kann diese Filterung der modulierten Träger das Anwenden eines Bandbreitenfilters umfassen. Bei einigen Ausführungsarten kann der Bandbreitenfilter auf die Trägerfrequenz des modulierten Trägers ausgerichtet sein. Bei einigen Ausführungsarten kann der Bandbreitenfilter einen FIR-Filter (Filter mit endlicher Impulsantwort) beinhalten. Bei einigen Ausführungsarten kann der Bandbreitenfilter so eingestellt sein, dass die Stärke in den Nebenkeulen des Frequenzspektrums des modulierten Trägers unterdrückt wird.
Bei einigen anderen Ausführungsarten kann der Schritt 740 (Umwandlung der Symbolkette in ein oder mehrere Signale) den Teilschritt des Austauschs (749) von Symbolen oder Symbolabfolgen durch Sequenzen von Abtastwerten umfassen, die aus einer Tabelle mit verschiedenen Sequenzen von Abtastwerten abhängig von dem zu ersetzenden Symbol oder der zu ersetzenden Symbolabfolge abgerufen werden. Bei einigen Ausführungsarten kann dieser Teilschritt beispielsweise die Teilschritte 741 und 742 ersetzen. Bei anderen Ausführungsarten kann dieser Teilschritt beispielsweise die Teilschritte 741, 742 und 743 ersetzen. Bei weiteren anderen Ausführungsarten kann dieser Teilschritt beispielsweise die Teilschritte 741, 742, 743 und 744 ersetzen.
Bei einigen Ausführungsarten werden mindestens zwei modulierte Träger, die möglicherweise per Bandbreitenfilter gefiltert wurden, in ein einziges digitalisiertes Signal gemischt (750). Bei einigen Ausführungsarten werden alle modulierten Träger, die möglicherweise per Bandbreitenfilter gefiltert wurden, in ein einziges digitalisiertes Signal gemischt. Bei anderen Ausführungsarten werden mindestens zwei modulierte Träger als separate digitalisierte Signale beibehalten.
Bei einigen Ausführungsarten werden die erzeugten digitalisierten Signale (eines oder mehrere), die jeweils einen oder mehrere modulierte Träger beinhalten, in ein analoges Signal umgewandelt und als Tonsignal ausgegeben (760). Bei einigen Ausführungsarten werden mindestens zwei modulierte Träger separat nacheinander als Tonsignal ausgegeben. Bei einigen Ausführungsarten werden mindestens zwei modulierte Träger gleichzeitig, aber separat über verschiedene Lautsprecher als Tonsignal ausgegeben (645). Bei einigen Ausführungsarten werden mindestens zwei modulierte Träger gemischt und gleichzeitig zusammen über denselben Lautsprecher als Tonsignal ausgegeben (645).
Bei einigen Ausführungsarten haben alle modulierten Träger dieselbe Stärke. Bei einigen Ausführungsarten ist mindestens ein modulierter Träger stärker als mindestens ein anderer modulierter Träger. Bei einigen Ausführungsarten beträgt der Stärkeunterschied 6 dB.
Bei einigen Ausführungsarten beinhaltet das Computergerät des Benutzers (610) eine Soundkarte (641) und einen oder mehrere Lautsprecher (645), die mit der Soundkarte (641) verbunden sind. Das Computergerät des Benutzers (610) überträgt die Abtastwerte der digitalisierten Signale (eines oder mehrere) an die Soundkarte (641), damit sie über die Lautsprecher (einer oder mehrere) (645) ausgegeben werden. Bei einigen Ausführungsarten werden die Abtastwerte der digitalisierten Signale (eines oder mehrere) direkt in die Soundkarte (641) eingespeist. Bei anderen Ausführungsarten wird ein Audiozwischenformat (z. B. eine WAVE-Datei) verwendet, das die Abtastwerte und einen Header enthält.
Bei einigen Ausführungsarten ist für die Ausgabe der digitalisierten Signale eine feste Anzahl von Wiederholungen vorgegeben. Bei einigen Ausführungsarten wird die Ausgabe der digitalisierten Signale unendlich wiederholt. Bei einigen Ausführungsarten wird die Ausgabe der digitalisierten Signale wiederholt, bis die Benachrichtigung erteilt oder empfangen wird, dass das Authentisierungstoken (100/101) die übertragenen Daten korrekt empfangen hat. Bei einigen Ausführungsarten beispielsweise wiederholt das Computergerät des Benutzers (610) die Ausgabe der digitalisierten Signale, bis der Benutzer den Vorgang abbricht oder dem Computergerät des Benutzers (610) ein dynamisches Kennwort oder eine Signatur bereitstellt, die vom Authentisierungstoken (100/101) als Antwort auf die übertragenen Daten erzeugt wurden. Bei einigen Ausführungsarten wiederholt das Computergerät des Benutzers (610) die Ausgabe der digitalisierten Signale, bis die Benachrichtigung erteilt oder empfangen wird, dass für die Übertragung der Daten an das Authentisierungstoken (100/101) eine andere Methode verwendet werden muss. Bei einigen Ausführungsarten beispielsweise kann der Benutzer das Computergerät des Benutzers (610) darüber benachrichtigen, dass die Daten nicht akustisch, sondern optisch übertragen werden müssen oder dass der Benutzer die Daten manuell in das Authentisierungstoken (100/101) eingeben möchte.
Bei einigen Ausführungsarten werden einige der Schritte zur Übertragung von Eingabedaten an ein Authentisierungstoken (100/101) mit einer Schnittstelle für die akustische Eingabe (110/111) über das Computergerät des Benutzers (610) durchgeführt. Bei einigen Ausführungsarten werden einige der Schritte zur Übertragung von Eingabedaten an ein Authentisierungstoken (100/101) mit einer Schnittstelle für die akustische Eingabe (110/111) über einen Server (650) durchgeführt, der mit dem Computergerät des Benutzers (610) über ein Computernetzwerk wie das Internet kommuniziert. Bei einigen Ausführungsarten werden alle Schritte über das Computergerät des Benutzers (610) durchgeführt. Bei einigen Ausführungsarten werden einige Schritte über einen Server (650) und andere Schritte über das Computergerät des Benutzers (610) durchgeführt. Bei einigen Ausführungsarten beispielsweise empfängt ein Server (650) die Eingabedaten und sendet diese z. B. über das Internet eingebettet in eine Webseite an das Computergerät des Benutzers (610). Das Computergerät des Benutzers (610) empfängt die Eingabedaten, führt alle nachfolgenden Schritte durch, um ein digitales Signal zu erhalten, das die Eingabedaten über mehrere modulierte Träger verschlüsselt, und gibt diese modulierten Träger als Tonsignale für den Empfang am Authentisierungstoken (100/101) aus. Bei anderen Ausführungsarten empfängt ein Server (650) die Eingabedaten, erzeugt ein oder mehrere digitalisierte Signale mit mindestens zwei modulierten Trägern, die die Eingabedaten verschlüsseln, und sendet die digitalisierten Signale (eines oder mehrere) z. B. über das Internet eingebettet in eine Webseite und/oder im Format einer Audiodatei an das Computergerät des Benutzers (610). Das Computergerät des Benutzers (610) empfängt die digitalisierten Signale (eines oder mehrere) und gibt diese als Tonsignale für den Empfang am Authentisierungstoken (100/101) aus.
zeigt eine Methode (800) für ein Authentisierungstoken (100/101) mit einer Schnittstelle für die akustische Eingabe (110/111), um Daten akustisch empfangen zu können. 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 810 kann das Authentisierungstoken (100/101) in den Empfangsmodus wechseln und eine Ausgangsträgerfrequenz auswählen. Dieser Schritt kann Aktionen umfassen, die in einigen der vorstehenden Absätze beschrieben sind. Bei einigen Ausführungsarten ist die Ausgangsträgerfrequenz ein konstanter Parameter. Bei einigen Ausführungsarten wird die Ausgangsträgerfrequenz auf der Grundlage dynamischer Prüfungen ausgewählt, die das Messen der relativen Stärke in Frequenzbändern für alle der ausgewählten Trägerfrequenzen und z. B. die Auswahl der stärksten Frequenz umfassen können. Bei einigen Ausführungsarten kann die Auswahl der Trägerfrequenz ein Schätzen des Signal-Rausch-Verhältnisses und z. B. das Auswählen der Trägerfrequenz mit dem niedrigsten Signal-Rausch-Verhältnis umfassen. Bei einigen Ausführungsarten wird die Trägerfrequenz auf der Grundlage früherer Leistungswerte für die verschiedenen ausgewählten Frequenzen ausgewählt. Bei einigen Ausführungsarten ist die Ausgangsträgerfrequenz die letzte erfolgreich verwendete Trägerfrequenz.
Bei Schritt 820 kann das Authentisierungstoken (100/101) versuchen, einen modulierten Träger mit der aktuell ausgewählten Trägerfrequenz zu empfangen und zu demodulieren. Dieser Schritt kann Aktionen umfassen, die in einigen der vorstehenden Absätze beschrieben sind. Bei einigen Ausführungsarten kann dieser Schritt das Einstellen einer Demodulationsschaltung auf die aktuell ausgewählte Trägerfrequenz umfassen. Bei einigen Ausführungsarten kann dieser Schritt das Einstellen einer Phasenregelschleife auf die aktuell ausgewählte Trägerfrequenz umfassen. Bei einigen Ausführungsarten kann dieser Schritt das Einstellen eines Filters auf die aktuell ausgewählte Trägerfrequenz umfassen. Bei einigen Ausführungsarten kann dieser Schritt das Mischen oder Vielfachschalten des empfangenen Signals mit einem erzeugten Träger der aktuell ausgewählten Trägerfrequenz umfassen.
Bei Schritt 830 kann das Authentisierungstoken (100/101) prüfen, ob die demodulierten Daten einen vollständigen Satz korrekt empfangener Eingabedaten beinhalten. Wenn dies der Fall ist, kann das Token (100/101) den Empfangsmodus beenden (860). Andernfalls kann das Token (100/101) mit den verschiedenen Schritten der Empfangsmethode fortfahren. Dieser Schritt kann parallel zu anderen Schritten wie Schritt 820 und/oder Schritt 840 durchgeführt werden. Bei einigen Ausführungsarten kann dieser Schritt das Verifizieren eines Codes für die Fehlererkennung umfassen. Bei einigen Ausführungsarten kann dieser Schritt das Verifizieren der Menge empfangener Daten umfassen.
Bei Schritt 840 kann das Authentisierungstoken (100/101) bestimmte Bedingungen prüfen und auf der Grundlage der Ergebnisse dieser Bedingungsprüfungen entscheiden, ob die aktuell ausgewählte Trägerfrequenz weiterhin verwendet oder ob stattdessen eine andere Trägerfrequenz ausgewählt werden soll. Bei einigen Ausführungsarten kann dieser Schritt parallel zu anderen Schritten wie Schritt 820 und/oder Schritt 830 durchgeführt werden. Bei einigen Ausführungsarten kann dieser Schritt umfassen, dass die Zeit, die seit der Auswahl der aktuell ausgewählten Trägerfrequenz abgelaufen ist, mit einem bestimmten Schwellenwert verglichen wird. Bei einigen Ausführungsarten kann dieser Schritt das Verifizieren der Stärke in einem Frequenzband für die ausgewählte Trägerfrequenz umfassen. Bei einigen Ausführungsarten kann dieser Schritt das Verifizieren einer Messung der Fehlerrate der empfangenen Daten oder einer Schätzung des Signal-Rausch-Verhältnisses umfassen.
Bei Schritt 850 kann das Authentisierungstoken (100/101) eine alternative Trägerfrequenz auswählen und zu Schritt 820 zurückkehren, um zu versuchen, einen modulierten Träger mit der neu ausgewählten alternativen Trägerfrequenz zu empfangen und zu demodulieren. Dieser Schritt kann Aktionen umfassen, die in einigen der vorstehenden Absätze beschrieben sind. Bei einigen Ausführungsarten beispielsweise wird die alternative Trägerfrequenz auf der Grundlage dynamischer Prüfungen ausgewählt, die das Messen der relativen Stärke in Frequenzbändern für alle der ausgewählten Trägerfrequenzen und z. B. die Auswahl der stärksten Frequenz umfassen können. Bei einigen Ausführungsarten kann die Auswahl der alternativen Trägerfrequenz ein Schätzen des Signal-Rausch-Verhältnisses und z. B. das Auswählen der Trägerfrequenz mit dem niedrigsten Signal-Rausch-Verhältnis umfassen. Bei einigen Ausführungsarten kann die Auswahl einer neuen Trägerfrequenz das Berücksichtigen früherer Leistungswerte für die verschiedenen ausgewählten Frequenzen umfassen. Bei einigen Ausführungsarten kann die Auswahl einer neuen Trägerfrequenz das Ausschließen von Trägerfrequenzen umfassen, bei denen bereits ein Versuch fehlgeschlagen ist. Bei einigen Ausführungsarten werden die Trägerfrequenzen für die Auswahl gewichtet. Dabei erhalten Trägerfrequenzen, bei denen bereits ein Versuch fehlgeschlagen ist, eine relativ niedrige Gewichtung, und Trägerfrequenzen, bei denen noch kein Versuch durchgeführt wurde oder bei denen ein Versuch erfolgreich war, eine relativ hohe Gewichtung. Trägerfrequenzen mit relativ hoher Gewichtung werden gegenüber Trägerfrequenzen mit relativ niedriger Gewichtung bevorzugt ausgewählt, und Trägerfrequenzen mit relativ niedriger Gewichtung können auch von der Auswahl ausgeschlossen werden. Bei einigen Ausführungsarten durchläuft das Authentisierungstoken eine Liste möglicher Trägerfrequenzen. Bei einigen Ausführungsarten ist die Reihenfolge der unterstützten Trägerfrequenzen in dieser Liste ein konstanter Parameter des Token.
Bei einer typischen Ausführungsart befindet sich das Authentisierungstoken (100/101) in räumlicher Nähe zu den Lautsprechern (einer oder mehrere) (645) des Computergeräts des Benutzers (610), die das Tonsignal mit den Eingabedaten, die redundant auf mindestens zwei Trägerfrequenzen verschlüsselt wurden, akustisch ausgeben. Die Luft zwischen den Lautsprechern (einer oder mehrere) (645) des Computergeräts des Benutzers (610) und die Mikrofone (eines oder mehrere) (110/111) des Authentisierungstoken (100/101) dienen als Übertragungsmedium. Bei vielen Ausführungsarten haben die Mikrofone (eines oder mehrere) (110/111) eine schwache relative Richtungsempfindlichkeit. Daher sind die exakte Ausrichtung und Position des Authentisierungstoken (100/101) gegenüber der Ausrichtung und Position der Lautsprecher (einer oder mehrere) (645) des Computergeräts des Benutzers (610) in der Regel für den erfolgreichen Empfang der Daten nicht entscheidend. Bei vielen Ausführungsarten kann das Authentisierungstoken (100/101) in einem Abstand zu den Lautsprechern (einer oder mehrere) (645) des Computergeräts des Benutzers (610) gehalten werden, der von wenigen Zentimetern zu mehreren Metern reicht.
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 [0009]
EP 1211841 [0009]
EP 1788509 [0009]
US 5136644 [0009]

Claims

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 mindestens ein Mikrofon und eine mit dem mindestens einen Mikrofon verbundene Demodulationsschaltung umfasst, die ein vom Mikrofon empfangenes akustisches Signal demodulieren kann; und eine mit der Demodulationsschaltung verbundene oder in dieser enthaltene 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, wobei die Demodulationsschaltung modulierte Träger auf mindestens zwei verschiedenen Trägerfrequenzen demodulieren kann.
Das Token gemäß Anspruch 1, dadurch gekennzeichnet, dass die Demodulationsschaltung gleichzeitig mindestens zwei modulierte Träger mit verschiedenen Trägerfrequenzen demodulieren kann.
Das Token gemäß Anspruch 1, dadurch gekennzeichnet, dass die Demodulationsschaltung vom Token auf eine ausgewählte Trägerfrequenz eingestellt werden kann, und wobei die besagte ausgewählte Trägerfrequenz vom Token aus allen von mindestens zwei verschiedenen möglichen Trägerfrequenzen ausgewählt werden kann.
Das Token gemäß Anspruch 3, das für die besagte ausgewählte Trägerfrequenz einen anderen Wert als die aktuell ausgewählte Trägerfrequenz auswählen kann, wenn bestimmte Bedingungen erfüllt sind.
Das Token gemäß Anspruch 4, dadurch gekennzeichnet, dass die besagten Bedingungen beinhalten, dass das Token die besagten Eingabedaten innerhalb eines vorgegebenen Zeitraums nicht erfolgreich empfangen hat.
Das Token gemäß Anspruch 3, dadurch gekennzeichnet, dass der Ausgangswert für die besagte ausgewählte Trägerfrequenz ein konstanter Parameter des Token ist.
Das Token gemäß Anspruch 3, dadurch gekennzeichnet, dass der Ausgangswert für die besagte ausgewählte Trägerfrequenz, die beim Wechsel des Token in den Empfangsmodus ausgewählt wird, die letzte erfolgreich verwendete Trägerfrequenz ist.
Das Token gemäß Anspruch 4, das die besagte ausgewählte Trägerfrequenz auswählen kann, indem eine vorgegebene Liste möglicher Frequenzen durchlaufen wird.
Das Token gemäß Anspruch 8, dadurch gekennzeichnet, dass die Reihenfolge der besagten Liste ein konstanter Parameter des Token ist.
Das Token gemäß Anspruch 4, das die besagte ausgewählte Trägerfrequenz aus einer Liste möglicher Trägerfrequenzen auswählen kann, indem frühere Leistungswerte für die möglichen Trägerfrequenzen berücksichtigt werden.
Das Token gemäß Anspruch 4, das die besagte ausgewählte Trägerfrequenz auswählen kann, indem die Messwerte von Kennzahlen für mindestens einige der besagten möglichen Trägerfrequenzen berücksichtigt werden.
Das Token gemäß Anspruch 4, das die besagte ausgewählte Trägerfrequenz auswählen kann, indem die Signalstärke in Frequenzbändern für mindestens einige der besagten möglichen Trägerfrequenzen berücksichtigt wird.
Das Token gemäß Anspruch 4, das die besagte ausgewählte Trägerfrequenz auswählen kann, indem Schätzungen oder Messungen der Fehlerrate für mindestens einige der besagten möglichen Trägerfrequenzen berücksichtigt werden.
Das Token gemäß Anspruch 4, das die besagte ausgewählte Trägerfrequenz auswählen kann, indem Schätzungen oder Messungen des Signal-Rausch-Verhältnisses für mindestens einige der besagten möglichen Trägerfrequenzen berücksichtigt werden.
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.
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.
Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die kryptografische Kombination die Ausführung eines symmetrischen kryptografischen Algorithmus beinhaltet.
Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die dynamische Variable einen Zeitwert beinhaltet.
Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die dynamische Variable einen Zählerwert beinhaltet.
Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die dynamische Variable einen Anforderungswert beinhaltet.
Das Token gemäß Anspruch 16, dadurch gekennzeichnet, dass die dynamische Variable einen Wert für Transaktionsdaten beinhaltet.
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.
Das Token gemäß Anspruch 22, dadurch gekennzeichnet, dass der Navigationsmechanismus mindestens eine Navigationstaste und der Bestätigungsmechanismus mindestens eine Bestätigungstaste beinhaltet.
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 „OK”-Taste besteht.
Das Token gemäß Anspruch 22, dadurch gekennzeichnet, dass der Navigationsmechanismus ein Scrollrad beinhaltet.
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.
Das Token gemäß Anspruch 26, bei dem das entfernbare zweite Sicherheitsgerät eine Smartcard beinhaltet.
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.
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.
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.
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.
Das Token gemäß Anspruch 1, das außerdem eine Schnittstelle für die optische Eingabe beinhaltet.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Das Token gemäß Anspruch 1, dadurch gekennzeichnet, dass die Eingabedaten Serveranmeldeinformationen beinhalten, und gemäß Anspruch 1, dadurch gekennzeichnet, dass das Token bei der Verarbeitung außerdem die besagten Serveranmeldeinformationen verifizieren kann.
Das Token gemäß Anspruch 43, dadurch gekennzeichnet, dass die besagte Erzeugung der dynamischen Sicherheitswerte von der erfolgreichen Verifizierung der besagten Serveranmeldeinformationen abhängt.
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.
Das Token gemäß Anspruch 1, das außerdem eine Schnittstelle für die Benutzereingabe zur Erfassung der Benutzereingabe beinhaltet und weiterhin für Folgendes ausgelegt ist: Bereitstellung von mindestens einigen der Eingabedaten für den Benutzer über die vertrauenswürdige Schnittstelle für die Benutzerausgabe, Erfassung der Genehmigung des Benutzers für die bereitgestellten Eingabedaten über die Schnittstelle für die Benutzereingabe, Erzeugung einer kryptografischen Signatur für die genehmigten Eingabedaten über die Komponente zur Datenverarbeitung und Kommunikation der erzeugten kryptografischen Signatur an den Benutzer über die vertrauenswürdige Schnittstelle für die Benutzerausgabe.