Beschreibung

Die Erfindung betrifft ein Verfahren zum kryptographisch gesicherten

Beweis der Anwesenheit eines Identity-Tokens im Bereich eines Identity- Sensors sowie einen Identity-Sensor, insbesondere für ein solches Verfahren.

Aus DE 44 40 855 C2, DE 1 0 2005 032 379 A1 , DE 1 0 2006 020 422 A1 , DE 1 0 2009 005 221 A1 , DE 1 0 201 0 01 0 892 111 , EP 1 454 807, EP 2 079 058 A2, EP 2 1 89 598 A1 und WO 2007/087471 A2 sind verschiedene drahtlose Zugangskontrollsysteme, Verfahren zum Betrieb derartiger

Systeme sowie einzelne Elemente solcher Systeme, wie z. B. elektronische Schlüssel, bekannt.

Weitere Informationen zum vorstehend genannten technischen Gebiet sind der Veröffentlichung "Yet Another Secure Distance-Bounding Protocol" zu entnehmen, abrufbar im Internet unter http://eprint.iacr.org/2008/31 9.pdf. In Abschnitt 2 („Related Work") dieser Veröffentlichung wird unter Bezugnah- me auf Figur 1 ein theoretisches Verfahrensmodell beschrieben, welches den bitweisen Austausch zweier Zufallszahlen umfasst. Das Verfahren geht zurück auf eine Veröffentlichung aus dem Jahr 1 993 (vgl. Fu ßnote Nr. 3 zu der genannten Veröffentlichung). Eine praktische Umsetzung des Verfahrens ist nicht bekannt.

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum kryptographisch gesicherten Beweis der Anwesenheit eines Identity-Tokens im Bereich eines Identity-Sensors sowie einen Identity-Sensor für ein solches Verfahren vorzuschlagen, die eine hohe Sicherheit vor Missbrauch gewährleisten, die eine hohe Flexibilität aufweisen und die kostengünstig realisierbar sind. Die Lösung der Aufgabe erfolgt erfindungsgemäß mit den Merkmalen der Ansprüche 1 , 1 0 bzw. 1 4.

Ein erfindungsgemäßes Verfahren zum kryptographisch gesicherten Beweis der Anwesenheit eines Identity-Tokens im Bereich eines Identity-Sensors umfasst den Austausch mindestens einer Zufallszahl R _T eines Identity- Tokens mit einer Zufallszahl R _s eines Identity-Sensors sowie folgende Verfahrensschritte: der Identity-Sensor generiert mindestens eine Zufallszahl R _s und lädt diese auf Vorrat als Bestätigungspaket für eine in Zukunft eingehende zweite Zufallszahl R _T von einem Identity-Token in eine Funkschnittstelle hoch, das Identity-Token generiert eine Zufallszahl R _T und sendet diese an den Identity-Sensor, und der Identity-Sensor quittiert den Empfang der Zufallszahl R _T von dem Identity-Token durch unmittelbares Rücksenden der Zufallszahl R _s in Form eines einzigen Datenpakets.

Unter einer Funkschnittstelle werden insbesondere ein Funkchip, ein Funkmodul oder Funk-Interface, z. B. innerhalb eines Chips, verstanden. Zufallszahlen sollen insbesondere NONCE-Zufallszahlen sein, bei denen es sich auch um Pseudo-Zufallszahlen handeln kann. Als Generierung von Zufallszahlen wird beispielsweise auch die Erzeugung eines Stroms von pseudozufälligen Nummern auf Basis eines Geheimnisses verstanden, die für den Identity-Sensor oder für ein Identity-Token (ähnlich wie eine TAN- Liste) abrufbar gespeichert ist. Wichtig ist dabei, dass kein nachvollziehbarer Zusammenhang zwischen den einzelnen Elementen dieser Liste besteht. Durch die Verwendung und den Austausch von NONCE-Zufallszahlen wird sichergestellt, dass die Kombination von R _S und RT immer einzigartig ist und ein Tracking eines Identity-Tokens durch einen Angreifer, der einen Identity-Sensor durch Aussenden einer immer gleich bleibenden Zufallszahl R _S simuliert, keinen Erfolg haben kann.

Das erfindungsgemäße Verfahren hat den Vorteil, dass die Zufallszahlen R _S und RT innerhalb sehr kurzer Zeit ausgetauscht werden, da die Zufallszahl R _S in Form eines einzigen Datenpakets unmittelbar übermittelt und die Übermittlung bereits vor Erhalt einer Zufallszahl R _T durch entsprechendes Hochladen in eine Funkschnittstelle vorbereitet wird. Die Zufallszahl R _T muss daher nach Erhalt der Zufallszahl R _S nicht erst generiert und hochgeladen, sondern kann direkt und ohne zusätzliche Zeitverzögerung„quittiert" werden. Dadurch kann eine hohe Sicherheit des erfindungsgemäßen

Verfahrens gewährleistet werden. Sogenannte "Man-in-the-middle-Angriffe" können durch die Vorgabe enger Zeitgrenzen wirksam verhindert werden.

Die Wartezeit eines Identity-Tokens auf eine (Antwort-)Zufallszahl R _s ist bevorzugt auf 300 Mikrosekunden (με), weiter bevorzugt auf 250 με und besonders bevorzugt auf 1 με begrenzt, d. h. das Identity-Token soll einge- hende Zufallszahlen R _s nur dann berücksichtigen, wenn die Übermittlung der Zufallszahl R _s innerhalb der oben genannten Zeit(en) für das Identity- Token erkennbar begonnen hat. In einer weiter bevorzugten Ausführungsform berücksichtigt das Identity-Token eingehende Zufallszahlen R _s nur dann, wenn die Übermittlung der Zufallszahl R _s innerhalb der oben genann- ten Zeit(en) bzw. des vorgegebenen Zeitfensters für das Identity-Token bereits abgeschlossen ist. Dies verhindert "Man-in-the-Middle-Angriffe" über gängige Funknetzwerkstrukturen, da übliche Latenzzeiten in diesem aufgrund komplexer Protokolle in der Regel höher sind. Ein weiterer Vorteil der vorstehend beschriebenen Ausführungsform liegt darin, dass„Man-in-the- Middle-Angriffe" sehr einfach und kostengünstig durch Verwendung eines einzelnen, vorgegebenen Zeitfensters verhindert werden. Nur Zufallszahlen Rs _, deren Übermittlung innerhalb des Zeitfensters beginnen bzw. die bereits vollständig übermittelt wurden, werden berücksichtigt, alle anderen Zufallszahlen werden verworfen.

Das erfindungsgemäße Verfahren ermöglicht es, dass die Berücksichtigung von Zufallszahlen R _s durch das Identity-Token unabhängig von einer

Zeitmessung durch Beschränkung auf ein festes Zeitfenster erfolgen kann, insbesondere unabhängig von einer aus dem Stand der Technik bekannten aktiven und individuellen Zeitmessung. Der Stromverbrauch des erfindungsgemäßen Verfahrens kann damit signifikant reduziert werden, da die technische Realisierung eines festen Zeitfensters technisch wesentlich einfacher realisierbar ist als die Messung einer Antwortzeit.

Obwohl sich Funkwellen innerhalb von 250 με ca. 75 Kilometer weit ausbreiten, ist die kurze Latenz ein wirkungsvolles Hindernis für Angreifer, da die technische Komplexität der Weiterleitung der Daten über ein weitreichendes Protokoll eine sehr hohe technische Hürde darstellt, hohe Kosten verursacht und deshalb unpraktikabel ist. Bei einer maximalen Wartezeit von einer Mikrosekunde wird eine räumliche Beschränkung auf etwa 300 Meter erzielt.

Vorzugsweise wird auch die Zufallszahl R _T in Form eines einzigen Datenpaktes übermittelt, was die insgesamt benötigte Zeit für den Austausch der Zufallszahlen R _s und RT weiter reduziert. Die Zufallszahlen R _s und RT können ohne Verschlüsselung und/oder

Signatur ausgetauscht werden, so dass die Austauschzeit sich ungefähr auf die benötigte Zeit für die physikalische Übertragung beschränken lässt.

Das erfindungsgemäße Verfahren wird vorzugsweise mit Hilfe eines Identi- ty-Sensors realisiert, der zum wiederholbaren Übertragen mindestens einer dem Identity-Sensor eindeutig zugeordneten Identity-Sensor-I D an eine Vielzahl von Identity-Token ausgebildet ist und ferner eine Funkschnittstelle zum Empfang von durch Identity-Token generierten Zufallszahlen R _T umfasst. Unter einer I D wird im Rahmen der vorliegenden Anmeldung eine Kennung oder eine Kombination von ein oder mehreren Merkmalen, z. B. Nummern oder Schlüsseln, verstanden, die innerhalb ihres Wirkbereichs eindeutig ist. I Ds werden vorzugsweise bereits bei der Herstellung des jeweiligen Elements vergeben. Der erfindungsgemäße Identity-Sensor umfasst eine Vorrichtung zur Datenflusssteuerung, die es ermöglicht, mindestens eine dem Identity-Sensor zugeordnete Zufallszahl R _s in eine Funkschnittstelle hochzuladen, um diese unmittelbar auf den Empfang einer Zufallszahl R _T von einem Identity-Token in Form eines einzigen Datenpa- kets zu quittieren. Eine Vorrichtung zur Datenflusssteuerung ermöglicht es, mit anderen Worten ausgedrückt, eingehende Datenpakete automatisiert zu bestätigen und dabei zuvor abgelegte bzw. in eine Funkschnittstelle hochgeladene Informationen der Bestätigung "beizufügen". Derartige Vorrichtungen sind nur aus anderen technischen Gebieten und für andere Einsatz- zwecke bekannt. Beispielsweise kommen solche Vorrichtungen bei batteriebetriebenen Drahtlosgeräten (z. B. Funk-Tastaturen) zum Einsatz, die mit meist netzstromversorgten Basisstationen kommunizieren. Bei derartigen Vorrichtungen "wacht" das Drahtlosgerät in regelmäßigen Abständen "auf", sendet ein Datenpaket an die Basisstation, und diese sendet im Falle von abgelegten bzw. hochgeladenen Daten dieselben an das Drahtlosgerät zurück. Das Drahtlosgerät muss aus diesem Grund nur für sehr kurze Zeit nach dem Absenden des Datenpakets empfangsbereit sein und kann dadurch sehr energieeffizient arbeiten (geringer Batterieverbrauch). Auch eine Synchronisierung zwischen dem Drahtlosgerät und Basisstation ist in diesem Fall nicht erforderlich. Durch eine Übertragung und wie in den Ansprüchen beschriebene Anwendung und Konfigurierung der vorstehend beschriebenen Technik auf einen erfindungsgemäßen Identity-Sensor lässt sich ein solcher kostengünstig herstellen und energieeffizient betreiben, insbesondere auch unter Verwendung bereits bekannter technischer Ele- mente. Hierauf wird im Zusammenhang mit dem Ausführungsbeispiel noch im Detail eingegangen. Als Funkschnittstelle kommen bevorzugt solche zum Einsatz, die mit einer Frequenz von mindestens 2,4 GHz betrieben werden und weiter bevorzugt solche, die Datenübertragungsraten von mindestens 2 Mbit/s ermöglichen. So lassen sich die Kommunikationszyklen sehr kurz halten, wodurch das Risiko für "Man-in-the-middle-Angriffe" reduziert wird. Das Senden mit Frequenzen von 2,4 GHz oder höher hat den weiteren Vorteil, dass die Durchdringung von Objekten (wie z. B. Häusern etc.) schwieriger und energieaufwändiger ist und dies den räumlichen "Angriffsbereich" eines erfindungsgemäßen Systems in den meisten Fällen beschränkt.

In einer praktischen Ausführungsform des erfindungsgemäßen Verfahrens ermitteln sowohl der Identity-Sensor als auch das Identity-Token auf der Grundlage eines Identity-Combipass-Keys sowie der ausgetauschten Zufallszahlen R _s und R _T unabhängig voneinander jeweils eine Identity- Response, die miteinander verglichen werden, um eine Berechtigung zu überprüfen. Der Identity-Combipass-Key kann dabei beispielsweise sowohl in dem Identity-Token als auch in dem Identity-Sensor gespeichert sein, so dass für die Ermittlung einer Identity-Response lediglich der oben beschriebene Austausch der Zufallszahlen erfolgen muss.

Seitens des Identity-Tokens wird der Identity-Combipass-Key vorzugsweise aus einer dem Identity-Sensor eindeutig zugeordneten Identity-Sensor-I D und einem dem Identity-Token zugeordneten und in diesem gespeicherten Identity-Token-Key durch einen Transformationsprozess (z. B. per Ver- Schlüsselung oder per kryptographischer Signierung) abgeleitet. Dazu überträgt der Identity-Sensor eine dem Identity-Sensor eindeutig zugeordnete Identity-Sensor-I D an das Identity-Token, so dass dieses zusammen mit einem in dem Identity-Token gespeicherten Identity-Token-Key durch einen Transformationsprozess den Identity-Combipass-Key bilden kann. Dies hat den Vorteil, dass der im Identity-Token gespeicherte Identity- Token-Key selbst weder übertragen noch in nachvollziehbarer Art und Weise verwendet werden muss. Der Identity-Combipass-Key ist daher für Dritte, die die zwischen dem Identity-Sensor und dem Identity-Token übertragenen Informationen abhören, nicht ermittelbar.

In einer weiteren praktischen Ausführungsform werden dem Identity-Sensor eine Vielzahl von entsprechenden Identity-Token zugeordneten Identity- Combipass-Keys zur Verfügung gestellt (insbesondere je ein Identity- Combipass-Key zu jedem Identity-Token, das eine Berechtigung zur Kommunikation mit dem entsprechenden Identity-Sensor haben soll). Der Identity-Sensor ermittelt gemäß dieser Ausführungsform so lange jeweils eine Identity-Response für zur Verfügung stehende Identity-Combipass- Keys unter Berücksichtigung der Zufallszahlen R _s und RT, bis eine ermittelte Identity-Response mit der von dem Identity-Token ermittelten Identity- Response übereinstimmt oder bis alle zur Verfügung stehenden Identity- Combipass-Keys verwendet wurden. Wird eine übereinstimmende Identity- Response ermittelt, wird das Verfahren beendet und eine Berechtigung erteilt. Wird keine übereinstimmende Identity-Response ermittelt, ist das Verfahren beendet, und es wird keine Berechtigung erteilt.

Da seitens eines Identity-Sensors üblicherweise eine Netzstromversorgung vorliegt (im Gegensatz zu den Identity-Tokens, die üblicherweise über eine Batterie mit Strom versorgt werden) und die Rechenleistung dementsprechend häufig höher ist als die Rechenleistung der Identity-Tokens (die zugunsten eines geringen Stromverbrauchs und einer langen Dauerbereitschaft geringer gewählt wird), kann das Verfahren weiter verbessert wer- den, wenn mit Hilfe des Identity-Sensors unmittelbar nach Kenntnis der beiden Zufallszahlen R _s und R _T sämtliche Identity-Responses für alle dem Identity-Sensor zur Verfügung stehenden Identity-Combipass-Keys ermittelt und diese in einer Vergleichstabelle zwischengespeichert werden. In diesem Fall kann nach Berechnung der Identity-Response seitens des Identity-Tokens durch einen einfachen Vergleich der ermittelten Identity- Response mit den Werten der Vergleichstabelle eine Überprüfung der Identity-Responses erfolgen und die Zeit der Überprüfung weiter verkürzt werden. Wenn die Zeit für die Berechnung aller Identity-Responses seitens des Identity-Sensors grö ßer ist als die Zeit, die ein Identity-Token für die

Berechnung der Identity-Response benötigt (z. B. weil die Zahl der einem Identity-Sensor zugeordneten Identity-Combipass-Keys sehr hoch ist), kann es vorteilhaft sein, die Identity-Combipass-Keys nach Nutzungshäufigkeit oder nach einer anderen Prioritätsrangfolge zu speichern. So kann vorgegeben werden, bei welchen Identity-Token ein erfindungsgemäßes System besonders schnell reagiert.

Alternativ kann die Zeit vom Austausch der Zufallszahlen R _s und RT bis zur Entscheidung über eine Berechtigung (Freigabe oder Ablehnung) innerhalb eines vorgegebenen Zeitfensters bewusst zufällig gewählt werden, um zu verhindern, dass durch die Überwachung der Antwortzeiten Rückschlüsse auf die Identität bestimmter Identity-Token gezogen werden können. Diese Option ist nicht erforderlich, wenn sichergestellt ist, dass die Antwortzeit unabhängig von der Zahl der von einem Identity-Sensor verwalteten Identity-Combipass-Keys stets gleich lang ist (beispielsweise weil die Rechenzeit seitens des Identity-Sensors auch bei einer sehr gro ßen Zahl zu verwalten- der Identity-Combipass-Keys sehr viel geringer ist als die Rechenzeit seitens des Identity-Tokens).

Die Identity-Combipass-Keys werden seitens des Identity-Sensors vorzugsweise nicht direkt in diesem gespeichert, um zu vermeiden, dass diese zusammen dem Identity-Sensor„entwendet" und ausgelesen werden können. Es ist daher bevorzugt, wenn die Identity-Combipass-Keys mit einem Datenspeicher verknüpft und aus diesem Datenspeicher abrufbar sind. Ein solcher Datenspeicher kann beispielsweise in einem mit einem Identity-Sensor verbundenen Gateway oder in einer mit dem Identity-Sensor verbundenen Infrastruktur angeordnet sein. Solche Elemente können an einem vom Identity-Sensor entfernten und insbesondere abgesicherten und geheimen Ort positioniert sein. Unter Gateways werden in diesem Zusammenhang insbesondere Vorrichtungen verstanden, die mit mehreren Identity-Sensoren verbunden sind und eine Verbindung zu einem Netzwerk herstellen, beispielsweise zu einem Mobilfunknetz, einem lokalen Netzwerk oder mit dem Internet. Durch die Verwendung von Gateways können die Betriebskosten des erfindungsgemäßen Verfahrens gesenkt werden, insbesondere wenn sehr viele Identity- Sensoren Bestandteil eines Systems sind und die Kosten für die direkte Anbindung jedes Identity-Sensors höher sind als die Kosten für die Anbin- dung eines Identity-Sensors an ein Gateway. Vorzugsweise befinden sich mindestens zwei Gateways im Empfangsbereich jedes Identity-Sensors, um die Ausfallsicherheit des Systems zu erhöhen.

Unter einer Infrastruktur wird insbesondere ein Server oder ein Serververbund verstanden, der als zentrales Element eines Systems aus einer Vielzahl von Identity-Sensoren Rechenleistung und Datenspeicher an einem beliebigen, in der Regel von den Identity-Sensoren entfernten Ort zur Verfügung stellt.

In einer weiteren praktischen Ausführungsform des erfindungsgemäßen Verfahrens wird von dem Identity-Token eine Identity-Token-I D an den

Identity-Sensor übertragen und der dem Identity-Token zugeordnete Identi- ty-Combipass-Key von dem Identity-Sensor auf Grundlage der Identity- Token-I D ermittelt. Dies hat den Vorteil, dass seitens des Identity-Sensors nur eine Identity-Response ermittelt werden muss. Die Zeit zur Durchfüh- rung des Verfahrens wird damit weiter reduziert.

Anstelle der Identity-Token-I D als Synonym für die Identity-Token-I D kann auch eine zufällige Transaktionsnummer (TAN) übertragen und der Identity- Combipass-Key von dem Identity-Sensor auf Grundlage dieser zufälligen Transaktionsnummer (TAN) ermittelt werden. In diesem Fall muss der Identity-Sensor Zugriff auf eine Tabelle haben, in welcher jeder Transaktionsnummer eine Identity-Token-I D zugeordnet ist. Die Verwendung von Transaktionsnummern hat den Vorteil, dass die Identity-Token-I D selbst nicht übertragen werden muss und dadurch "Mithörer" keine Kenntnis von der Identity-Token-I D erlangen können. Eine solche Tabelle kann wiederum entweder direkt in dem Identity-Sensor oder in einem mit dem Identity- Sensor verbundenen Gateway oder der Infrastruktur gespeichert sein. Auf die bereits beschriebenen jeweiligen Vorteile wird hiermit noch einmal verwiesen.

Die Sicherheit eines erfindungsgemäßen Verfahrens kann weiter erhöht werden, wenn die erstmalige Übertragung einer Identity-Token-I D oder ei- ner Transaktionsnummer (TAN) an einen Identity-Sensor nur erfolgt, nachdem diese Übertragung von einem Benutzer des Identity-Tokens freigegeben wurde. Diese Ausführungsform hat insbesondere Vorteile bei der erstmaligen Autorisierung (pairing). Zur Freigabe können an dem Identity- Token Mittel zur manuellen Freigabe der Übertragung der Identity-Token-I D vorgesehen sein, beispielsweise ein Schalter. In diesem Fall kann der Nutzer eines Identity-Tokens durch Betätigung eines solchen Schalters aktiv entscheiden, ob und falls ja, wann er die Identity-Token-I D (oder ein Synonym hierfür) zur Übertragung freigeben möchte. Vorteile entstehen in diesem Fall insbesondere im Zusammenhang mit Anmeldeverfahren, bei denen nur der Nutzer des Identity-Tokens die autorisierende Person ist (automatische Bestätigung seitens des Identity-Sensors). Wenn beispielsweise in einem Kaufhaus mit mehreren installierten Identity-Sensoren die Möglichkeit angeboten werden, dass Nutzer eines Identity-Tokens ihre Identity-Token-I D zur Erfassung deren Anwesenheit an diversen Orten freigeben, kann der durch Betätigung des Schalters eines Identity-Tokens eine entsprechende Freigabe aktiv erteilen.

Alternativ oder in Ergänzung zu dem vorstehenden beschriebenen Verfahren kann nach erstmaliger Übertragung einer Identity-Token-I D oder einer Transaktionsnummer (TAN) von einem Identity-Token an einen Identity- Sensor der Identity-Sensor den zu dieser Identity-Token-I D gehörigen Identity-Combipass-Key von einer Infrastruktur anfordern und die Übermittlung des Identity-Combipass-Keys erst und nur dann erfolgen, wenn diese Übermittlung von einem Betreiber eines Identity-Sensors autorisiert wurde. Bei dieser Ausführungsform kann eine Autorisierung (auch) durch den Betreiber eines Identity-Sensors erfolgen (manuelle Freigabe seitens des Identity-Sensors). Hat der Nutzer einer Identity-Tokens zuvor durch Betäti- gung eines Schalters seine Identity-Token-I D erstmalig an den Identity- Sensor übertragen, erspart er dem Betreiber eines Identity-Sensors die manuelle Eingabe der Identity-Token-I D. Die Übertragung kann dann zu einer Anfrage bei dem Betreiber des Identity-Sensors führen, ob er ein Token mit einer bestimmten Identity-Token-I D freigeben möchte, die mit einfacher Bestätigung oder Ablehnung beantwortet werden kann.

Die beiden zuletzt beschriebenen Verfahrensvarianten eignen sich sehr gut für die Übermittlung ergänzender Informationen, insbesondere an die Nutzer von Identity-Tokens. Beispielsweise können vor oder nach der manuellen Freigabe durch den Betreiber eines Identity-Sensors bzw. den Nutzer eines Identity-Tokens Nutzungsbedingungen, Datenschutzbestimmungen oder sonstige Hinweise übermittelt werden.

In einer besonders bevorzugten Ausführungsform eines erfindungsgemäßen Identity-Sensors umfasst dieser eine Verifizierungseinheit oder ist mit einer Verifizierungseinheit verknüpft, mittels welcher eine Identität, eine Anwesenheit und/oder eine Berechtigung von Identity-Token feststellbar ist. Als Verifizierungseinheit wird jede Funktionseinheit angesehen, die dazu geeignet ist, die von einem Identity-Token ermittelte Identity-Response mit der von einem Identity-Sensor ermittelten Identity-Response zu vergleichen und im Falle einer Übereinstimmung eine Identität bzw. eine Anwesenheit zu bestätigen und/oder eine Berechtigung zu erteilen.

Es ist weiter bevorzugt, wenn die Verifizierungseinheit eines erfindungsge- mäßen Identity-Sensors eine Verknüpfung zu einem Datenspeicher aufweist, in welchem Identity-Combipass-Keys hinterlegbar sind. Ein derartiger Datenspeicher kann entweder Bestandteil des Identity-Sensors selbst sein oder in einem Gateway oder einer Infrastruktur angeordnet sein. In derarti- gen Datenspeichern können Verknüpfungen von Identity-Combipass-Keys zu Identity-Token-I Ds der dazugehörigen Identity-Token sicher abgelegt und verfügbar gemacht werden. Dies hat den Vorteil, dass die Identity- Combipass-Keys selbst nicht übertragen werden müssen.

In einer weiter bevorzugten Ausführungsform eines erfindungsgemäßen Identity-Sensors weist dieser eine Verknüpfung zu einer Verwaltungseinheit auf, mittels welcher Identity-Combipass-Keys aktivierbar und deaktivierbar sind und/oder mittels welcher neue Identity-Token-Keys an Identity-Token übermittelbar sind. Diese Ausführungsform ermöglicht es, Betreibern von Identity-Sensoren Berechtigungen von Nutzern von Identity-Tokens selbständig und unabhängig von einer existierenden Datenverbindung durch Aktivieren bzw. Deaktivieren der entsprechenden Identity-Combipass-Keys zu verwalten. Ferner kann ein auf einem Identity-Token gespeicherter Schlüssel (Identity-Token-Key), beispielsweise nach einem Missbrauchsfall, geändert werden, indem ein neuer Identity-Token-Key generiert und von einem Identity-Sensor an das entsprechende Identity-Token übertragen wird. Eine aktive Handlung des Identity-Token-Nutzers ist dafür nicht erforderlich. Der Nutzer kann optional über den Wechsel des Identity- Token-Keys informiert werden.

Ein erfindungsgemäßer Identity-Sensor ist vorzugsweise Teil eines Systems, das eine Infrastruktur umfasst, die als Kommunikationsmittel des mindestens einen Identity-Sensors dient und ferner mindestens eine

Schnittstelle zur manuellen Konfiguration des Identity-Sensors aufweist. Ein derartiger Sensor kann beispielsweise über ein lokales Netzwerk, ein

Mobilfunknetzwerk, das Internet etc. , konfiguriert werden, wobei die Infrastruktur vorzugsweise als sicheres Speichermedium für kritische Informationen genutzt werden kann.

Auf die Möglichkeit und die damit verbundenen Vorteile, in einem erfindungsgemäßen System mehrere Identity-Sensoren über ein oder mehrere Gateways miteinander zu koppeln und über die Gateways mit der Infrastruk- tur zu verbinden, wurde im Zusammenhang mit dem erfindungsgemäßen Verfahren bereits hingewiesen.

In einer weiteren praktischen Ausführungsform des erfindungsgemäßen Verfahrens, die mit allen vorstehend beschriebenen Ausführungsformen kombinierbar ist, wird die Gültigkeitsdauer der Zufallszahlen R _s und R _T zeitlich beschränkt, insbesondere auf weniger als 300 ms ab Eingang der Zufallszahl R _T beim Identity-Sensor, bevorzugt auf weniger als 200 ms ab Eingang der Zufallszahl R _T beim Identity-Sensor und besonders bevorzugt auf weniger als 1 50 ms ab Eingang der Zufallszahl R _T beim Identity-Sensor.

Das erfindungsgemäße System hat den Vorteil, dass es nur geringe Systemressourcen benötigen und sehr flexibel nutzbar ist. Insbesondere kann ein Identity-Token für beliebig viele Identity-Sensoren freigegeben werden, ohne dass dazu das Identity-Token verändert werden muss, auf dem

Identity-Token zusätzliche Applikationen installiert werden müssen oder die Sicherheit des Systems reduziert wird. Mit anderen Worten ausgedrückt, kann ein Identity-Token eines erfindungsgemäßen Systems für beliebig viele Identity-Sensoren genutzt werden, ohne dass die Sicherheit dadurch beeinträchtigt wird. Es muss lediglich sichergestellt werden, dass jede Identity-Sensor-I D nur ein Mal vergeben wird.

Weitere praktische Ausführungsformen und Einzelheiten der Erfindung sind nachfolgend im Zusammenhang mit der Zeichnung beschrieben. Es zeigt:

Fig. 1 ein Ablaufdiagramm eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens.

In Figur 1 ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens wiedergegeben. In dem durch die gestrichelte Linie 1 04 eingefassten linken Bereich 1 00 von Figur 1 sind Verfahrensschritte dargestellt, die auf einem Identity-Sensor ablaufen. In dem durch die gestrichelte Linie 1 06 eingefassten rechten Bereich 1 02 sind Verfahrensschritte dargestellt, die auf einem Identity-Token ablaufen. Bei dem Identity-Token kann es sich beispielsweise um einen RFI D-Transponder (RFI D-Tag) handeln, das als Zugangsberechtigungselement für eine Tür eingesetzt wird. Bei dem Identity-Sensor kann es sich beispielsweise um ein Lesegerät für den RFI D-Transponder handeln.

In dem Identity-Token ist ein Identity-Token-Key 1 08 gespeichert. Der Identity-Sensor sendet in regelmäßigen Abständen eine ihm eindeutig zugeordnete Identity-Sensor-I D 1 1 0 aus, die von dem Identity-Token empfangen wird, sobald es sich in Reichweite des von dem Identity-Sensor ausgesandten Signals befindet. Der Prozess des Empfangens der Identity- Sensor-I D durch das Identity-Token ist in Figur 1 durch das Feld 1 1 2 im rechten Bereich 1 02 visualisiert. Durch einen Transformationsprozess 1 1 4, insbesondere durch einen Verschlüsselungsprozess und/oder eine krypto- graphische Signatur, wird auf der Grundlage des Identity-Token-Keys und der Identity-Sensor-I D ein sogenannter Identity-Combipass-Key 1 1 6 generiert, der für jedes Identity-Token in Abhängigkeit des eindeutig zugeordneten Identity-Token-Keys eindeutig festgelegt ist. In dem gezeigten Ausführungsbeispiel hat der Identity-Sensor unabhängig von dem Identity-Token Zugriff auf alle Identity-Combipass-Keys 1 1 8a, 1 1 8b, 1 1 8c, die denjenigen Identity-Token zugeordnet sind, welche für den Identity-Sensor eine Zugangsberechtigung haben sollen. Der Zugriff auf die Identity-Combipass-Keys 1 1 8a, 1 1 8b, 1 1 8c kann direkt erfolgen, wenn diese in dem Identity-Sensor gespeichert sind oder indirekt, wenn die Identity- Combipass-Keys 1 1 8a, 1 1 8b, 1 1 8c in einem nicht dargestellten Gateway oder einer nicht dargestellte Infrastruktur gespeichert sind, die entfernt von dem Identity-Sensor angeordnet sein können, aber auf welche der Identity- Sensor über eine Datenverbindung Zugriff hat.

Eine von dem Identity-Token generierte Zufallszahl R _T 1 20 wird von dem Identity-Token an den Identity-Sensor übermittelt und dort als R _T 1 22 zur Weiterverarbeitung gespeichert. Daraufhin quittiert der Identity-Sensor den Erhalt der Zufallszahl R _T durch unmittelbares Rücksenden einer Zufallszahl R _s 1 24 die zur Weiterverarbeitung als R _s 1 26 in dem Identity-Token gespeichert wird. Die Zufallszahl R _s ist bereits vor Erhalt der Zufallszahl R _T von dem Identity-Sensor generiert und auf Vorrat als Bestätigungspaket in eine nicht dargestellte Funkschnittstelle des Identity-Sensors geladen worden. Der Austausch der Zufallszahlen R _s und R _T läuft daher innerhalb sehr kurzer Zeit ab.

Basierend auf den beiden Zufallszahlen R _s und RT wird seitens des Identi- ty-Tokens eine festgelegte Verknüpfung 1 28 vorgenommen, die einen resultierenden Wert R _CO mbi ergibt. Seitens des Identity-Sensors wird die gleiche Verknüpfung 1 30 unabhängig davon vorgenommen, so dass auch dort der Wert R _CO mbi ermittelt wird. Seitens des Identity-Tokens wird in einem letzten Schritt basierend auf dem Wert Rcombi und dem Identity-Combipass-Key eine Identity-Response 1 32 gebildet. Diese wird anschließend an den Identity-Sensor übermittelt.

Seitens des Identity-Sensors werden auf der Grundlage des eindeutigen Wertes R _CO mbi und der bekannten Identity-Combipass-Keys 1 1 8a, 1 1 8b, 1 1 8c entsprechende Identity-Responses 1 34a, 1 34b, 1 34 c gebildet. Diese werden im Rahmen eines Vergleichs 1 36 mit der von dem Identity-Token ermittelten Identity-Response 1 32 verglichen. Stimmt eine Identity- Response 1 34a, 1 34b, 1 34c des Identity-Sensors mit der Identity-Response 1 32 des Identity-Tokens überein, gilt der Beweis der Anwesen heit des

Identity-Tokens als erbracht und erfolgt eine Freigabe bzw. ein Zugriffsberechtigung. Wenn Identity-Sensor und Identity-Token Teil eines Zugangsberechtigungssystems für Türen sind, wird in diesem Fall beispielsweise eine Tür von dem Identity-Sensor freigegeben. Zur weiteren Veranschaulichung des in Figur 1 beschriebenen Ablaufs sind nachstehend ein konkretes Programmierbeispiel mit entsprechenden

Beispielwerten für die einzelnen Parameter wiedergegeben. Verfahrensschritte, die auf dem Identity-Token ablaufen, sind nachfolgend mit dem Buchstaben T abgekürzt (z. B. T1 , T2, T3 etc.). Verfahrensschritte, die auf dem Identity-Sensor ablaufen, sind mit dem Buchstaben S abgekürzt (z. B. S1 , S2, S3 etc.). An den Beispielwerten ist erkennbar, dass die Verknüpfung von R _T (im Beispiel als R1 angegeben) und von R _s (im Beispiel als R2 angegeben) durch einfaches Aneinanderreihen erfolgt ist. Es sind jeweils drei Beispiele entsprechender Verfahrensabläufe für zwei verschiedene Türen dargestellt. Die Erfindung ist nicht auf das beschriebene Ausführungsbeispiel beschränkt, sondern sie kann im Rahmen der Ansprüche und unter Berücksichtigung der Kenntnisse des zuständigen Fachmanns variiert werden. Insbesondere wird darauf verwiesen, dass sämtliche in Verbindung mit dem erfindungsgemäßen Verfahren beschriebenen Merkmale auch auf den erfindungsgemäßen Identity-Sensor und das erfindungsgemäße System übertragbar sind. Das gleiche gilt für die Übertragung von Merkmalen, die nur in Verbindung mit dem erfindungsgemäßen Identity-Sensor oder dem erfindungsgemäßen System beschrieben sind.

Proqrammierbeispiel :

<?php

// use 128 bit ÄES (RIJNDÄEL) encryption in this example

define( ' KEY_SIZE_BYTES', 128/8) ;

5 define ( ' ENCRYPTION_ALGORITHM', MCRYPT_RIJNDAEL_ 128) function RandomKey()

{

return openssl_random_pseudo_bytes (KEY_SIZE_BYTES);

}

function RandomNumber ( )

{

return openssl_random_pseudo_bytes (KEY_SIZE_BYTES/2);

}

function EncryptData WithKey ($data, $key)

{

return mcrypt_encrypt (

ENCRYPTION_ALGORITHM,

$key,

$data.

MCRYPT_MODE_ECB) ;

}

function Show ($message, $data) echo str_pad($message,45, '. '). ':

'.trim(chunk_split (strtoupper (bin2hex($data)),4, '-'), '-')■ "\n ";

}

// **** Code (Part A) on Identity-token **** // 71. random key for Identity-Token assigned during token production $identity_token_key = pack

(Ή ^* ', Ό 123456789ABCDEF0123456789ABCDEF') ; ; Show ('TL Identity-Token-Key' ,$identity_token_key) ;

// T2. Identity-Sensor-ID, received via 2.4GHz during as wake-up Signal for token

$identity_sensor_ID = pack('H ^* ', '12345678') ;

Show (Ύ2. Identity-Sensor-ID' , $identity_sensor_ID) ;

// T3. encrypt ID with Identity-Token-Key to calculate Identity-Sensor // specific Identity-Combipass-Key -> "Key Derivation "

$identity_combipass_key = EncryptData WithKey($identity_sensor_ID, $identity_token_key) ;

Show ( ' T3. Identity-Combipass-Key' , $identity_combipass_key) ;

// T4. create random Number R 1 and transmit to Identity-Sensor

$R1 = RandomNumber ( ) ;

Show ( ' T4. Create Random R 1, send to Sensor ' , $R1) ;

// **** Code (Part B) on Identity-sensor ****

// S 1. create random number R2 and transmit to Identity-Token

$R2 = RandomNumber ( ) ;

Show ( ' S 1. Create Random R2, send to Token ' , $R2) ;

// S2. & T5. - concatenate R 1 and R2 to create Rcombi both on Token and Sensor

$ Rcombi = $R1 . $R2 ;

Show ( ' S2. & T5. Concatenate R 1+R2 into Rcombi ' , $Rcombi) ;

// S3. & T6. - calculate Rreply based on Rcombi and Identity-Combipass-Key

$Rreply = EncryptData WithKey ($Rcombi, $identity_combipass_key) ;Show ( ' S3. & T6. Calculate Rreply, send to Sensor' , $Rreply) ; echo "S4. compare received Rreply with calculated Rreply - open door if equal. \n\n " ;

?>

Beispielwerte:

Example Door 1234-5678:

T1. Identity-Token-Key 0123-4567-89 AB-CDEF-0123-456

7-89AB-CDEF

T2. Identity-Sensor-ID 1234-5678

T3. Identity-Combipass-Key B21 C-9C8C-A 741-844B- 791 D-57F

4-B9B8-51BB

T4. Create Random R 1, send to 24EB-F6F1-0254-A 72B

Sensor

51. Create Random R2, send to E 1 CE- 15F3- 1 B92-C6E8

Token

52. & T5. Concatenate R 1+R2 24EB-F6F1-0254-A 72B-E 1 CE- 15F into Rcombi 3- 1B92-C6E8

53. & T6. Calculate Rreply, send BFCC-04F8-D61 F-9E0E-89E2-7D to Sensor 78-6DC0-AC06

54. compare received Rreply with calculated Rreply - open door if equal

T1. Identity-Token-Key 0123-4567 -89 AB-CDEF-0123-4567-

89AB-CDEF

T2. Identity-Sensor-ID 1234-5678

T3. Identity-Combipass-Key B21 C-9C8C-A 741-844B- 791 D-57F4

-B9B8-51BB

T4. Create Random R 1, send to 5801 - 122D-53BE-C 130

Sensor

51. Create Random R2, send to FCEC-522D-717A-2A9E

Token

52. & T5. Concatenate R 1+R2 5801- 122D-53BE-C 130-FCEC-522D into Rcombi -717A-2A9E 53. & T6. Calculate Rreply, send 82D2-83A 7-D 162-4A60-0696-5EAB to Sensor -4C3F-F152

54. compare received Rreply with calculated Rreply - open door if equal.

T1. Identity-Token-Key 0123-4567-89AB-CDEF-0123-456

7-89AB-CDEF

T2. Identity-Sensor-ID 1234-5678

T3. Identity-Combipass-Key B21 C-9C8C-A 741 -844B-791 D-57

F4-B9B8-51BB

74. Create Random R 1, send to 2BCA-4A6B-762B-CC20

Sensor

51. Create Random R2, send to 9C2B-4950-0D 17-7769

Token

52. & T5. Concatenate R 1+R2 into 2BCA-4A6B-762B-CC20-9C2B-49

R combi 50-0D 17-7769

S3. & T6. Calculate Rreply, send to D 1D8-6083-7CB 1 -2814-D 160-51

Sensor 0C-0C7D- 13C0

S4. compare received Rreply with calculated Rreply - open door if equal.

Example Door 0234-5678:

T1. Identity-Token-Key 0123-4567 -89 AB-CDEF-0123-45

67-89AB-CDEF

T2. Identity-Sensor-ID 0234-5678

T3. Identity-Combipass-Key B07D-B7EF-5419-7557-BC5A-5

D84-42CC-8829

74. Create Random R 1, send to F7A5-C05D-B364-BC84

Sensor

51. Create Random R2, send to B77A-CF32-0A41 -C9A2

Token

52. & T5. Concatenate R 1+R2 into F7A5-C05D-B364-BC84-B77A-C

R combi F32-0A41-C9A2

S3. & T6. Calculate Rreply, send to 53F4-BEF3-DD68-58C4-B337-B

Sensor A0E-F3A3-4EA6

S4. compare received Rreply with calculated Rreply - open door if equal. T1. Identity-Token-Key 0123-4567-89AB-CDEF-0123-45

67-89AB-CDEF

T2. Identity-Sensor-ID 0234-5678

T3. Identity-Combipass-Key B07D-B7EF-5419-7557-BC5A -5D

84-42CC-8829

T4. Create Random R 1, send to 02C6-FC55-4CD9- 1 FEF

Sensor

51. Create Random R2, send to FE97-CDC7-ABAA-8A88

Token

52. & T5. Concatenate R 1+R2 into 02C6-FC55-4CD9- 1 FEF-FE97-C

Rcombi DC7-ABAA-8A88

53. & T6. Calculate Rreply, send to 5485-5 A52-2A5B-071 D-2459- A3 Sensor A3-9756-B767

54. compare received Rreply with calculated Rreply - open door if equal.

T1. Identity-Token-Key 0123-4567 -89 AB-CDEF-0123-456

7-89AB-CDEF

T2. Identity-Sensor-ID 0234-5678

T3. Identity-Combipass-Key B07D-B7EF-5419-7557-BC5A-5D

84-42CC-8829

74. Create Random R 1, send to DCCF-83D5-652D-6F91

Sensor

51. Create Random R2, send to 56EE-44D7-9E12-2DFF

Token

52. & T5. Concatenate R 1+R2 into DCCF-83D5-652D-6F91 -56EE-44

Rcombi D7-9E12-2DFF

S3. & T6. Calculate Rreply, send to B696-5030-8273-E471 -3FC 1 -9B0

Sensor 6-6537-A2A2

S4. compare received Rreply with calculated Rreply - open door if equal. Bezugszeichenliste

100 linker Bereich

102 rechter Bereich

104 gestrichelte Linie

106 gestrichelte Linie

108 Identity-Token-Key

110 Identity-Sensor-ID (gespeichert in Identity-Sensor)

112 Identity-Sensor-ID (empfangen von Identity-Token)

114 Transformationsprozess

116 Identity-Combipass-Key (in Identity-Token gespeichert)

118 Identity-Combipass-Keys (Zugriff über Identity-Sensor)

120 Zufallszahl R _T (von Identity-Token generiert)

122 Zufallszahl R _T (von Identity-Sensor empfangen)

124 Zufallszahl R _s (von Identity-Sensor generiert)

126 Zufallszahl R _s (von Identity-Token empfangen)

128 Verknüpfung der Zufallszahlen R _s und RT durch das Id.-Token

130 Verknüpfung der Zufallszahlen R _s und R _T durch den Id. -Sensor

132 Identity-Response, ermittelt durch Id.-Token

134 Identity-Response, ermittelt durch Id. -Sensor

136 Vergleich

* * * * * * *