DE102016004426A1

DE102016004426A1 - Identifizieren eines Identitätsträgers

Info

Publication number: DE102016004426A1
Application number: DE102016004426.8A
Authority: DE
Inventors: Udo Schwartz; Kurt Stadler
Original assignee: Giesecke and Devrient Mobile Security GmbH
Current assignee: Giesecke and Devrient Mobile Security GmbH
Priority date: 2016-04-12
Filing date: 2016-04-12
Publication date: 2017-10-12
Also published as: WO2017178114A9; WO2017178114A1; EP3443769A1

Abstract

Die Erfindung schafft ein Verfahren zum Identifizieren eines Identitätsträgers (TAG) mit einer darin abgespeicherten ID, umfassend die Schritte: a) Auslesen der ID aus dem Identitätsträger (TAG) durch einen Interrogator; b) durch den Interrogator, Übertragen der ID an einen Server, der eine Datenbank mit einer Mehrzahl von IDs von einer Mehrzahl von Identitätsträgern umfasst, und Identifizieren des Identitätsträgers (TAG) anhand der ausgelesenen ID; und ist gekennzeichnet durch folgende Merkmale. Verschleiern der ausgelesenen ID durch folgende Maßnahmen. Die ID wird nur als mit einem Salt berechneter Hashwert ausgelesen. In der Datenbank des Servers ist zu jeder ID, der eine Handle zugeordnet ist, der zugeordneten Handle mit der ID abgespeichert. Die Handle wird als Fuzzy-ID ausgelesen, die durch Anwenden eines Fuzzy-Algorithmus mit einem vorbestimmten Hamming-Abstand (t) auf die Handle erzeugt ist. Beim Server wird mittels der Fuzzy-ID eine Fuzzy-Suche durchgeführt, die eine Mehrzahl von Kandidaten-Handles liefert. Zu jeder Kandidaten-Handle wird die zugeordnete ID ermittelt. Für die hierdurch festgelegten Kandidaten-IDs wird je ein Vergleichs-Hashwert berechnet, durch Anwenden des Hash-Algorithmus auf die Kandidaten-ID und den übertragenen Salt, um eine Mehrzahl von Vergleichs-Hashwerten zu erzeugen. Die Vergleichs-Hashwerte werden mit dem an den Server übertragenen Hashwert verglichen. Derjenige Identitätsträger, für dessen ID der Vergleichs-Hashwert mit dem an den Server übertragenen Hashwert übereinstimmt, ist identifiziert.

Description

Gebiet der Erfindung
Die Erfindung betrifft das Gebiet des Identifizieren eines Identitätsträgers mittels Auslesen von Identitätsdaten, im Zusammenhang mit der Erfindung auch einfach als ID bezeichnet, aus einem Identitätsträger durch einen Interrogator (Erfassungsgerät) über eine Kontaktlosschnittstelle (Funkschnittstelle, OTA-Schnittstelle).
Stand der Technik
In existierenden ID-Systemen wird eine ID aus einem Identitätsträger, z. B. einem RFID-Tag, an einen Interrogator, z. B. RFID-Lesegerät, übertragen und der Identitätsträger anhand der übertragenen ID identifiziert. Die Abfrage ist meist passiv, d. h. der Vorgang Bedarf keiner Aktion des Subjekts und damit auch keiner expliziten Zustimmung. Zudem erfolgt die Abfrage über eine Luftschnittstelle, und wird aktiviert, sobald sich der Identitätsträger innerhalb der Erfassungsdistanz des Interrogators befindet.
In Verbindung mit dem Interrogator steht ein Server, der ausgelesene IDs von einer Vielzahl von Interrogatoren entgegennimmt und auswertet.
In Verbindung mit dem Server steht ein Service-Provider. Dieser ist ein System, durch das ein computerimplementiertes Geschäftsmodell, nachfolgend als Business Logic bezeichnet, verwirklicht ist. Die Business Logic kann ein beliebiger Anwendungsfall eines ID-Systems sein, beispielsweise Logistik, Lagerhaltung, Zugriffsrechteverwaltung etc..
Das Senden der ID vom Identitätsträger kann passiv (automatisch, indem der Identitätsträger in den Erfassungsbereich des Interrogators kommt) oder aktiv (gesteuert durch den User) erfolgen. Die ID wird vom Interrogator aufgenommen und an den Server geleitet. Dort wird die ID ausgewertet.
Bei einem einfachen Ausleseverfahren wird die ID in Klartext aus dem Identitätsträger heraus an den Interrogator übertragen. Hierdurch ist mit dem Auslesen und anschließenden Auswerten am Server die Identifizierung bereits erreicht. Die Identifizierung ist somit sehr leicht und einfach zu erzielen. Die ID ist andererseits für jedermann mitlesbar. Zudem kann jedermann anhand der ausgelesenen ID den Aufenthaltsort des Identitätsträgers mitverfolgen (Tracking).
Die Mitlesbarkeit der ID stellt prinzipiell eine Verletzung der Privatsphäre dar, die unter Umständen unerwünscht ist. Auch die Mitverfolgbarkeit, also Trackbarkeit, der ID kann unerwünscht sein.
Eine direkte Lösung, um die Privatsphäre zu sichern, ist, die ID in verschlüsselter Form im Tag abzulegen. Bei einer solchen Lösung ist ein Schlüsselmanagement erforderlich, was Aufwand bedeutet. Wird ein Tag-individueller symmetrischer Schlüssel verwendet, muss dieser im Tag abgelegt sein, was ein Sicherheitsrisiko bedeutet. Wird ein Schlüsselableitungsverfahren verwendet, muss das Tag aufwändige kryptographische Berechnungen durchführen können. Tracking einzelner Tags ist auch bei verschlüsselt aus dem Tag ausgelesener ID immer noch möglich.
Ein gegen Tracking gesichertes Auslesen (Scan) von Identitäten mit elektronischen Verfahren insbesondere über die Luftschnittstelle (RFID, OTA) muss zwei zunächst widersprüchliche Ziele Erfüllen: Einerseits muss die Identität zuverlässig übertragen und an das System im Hintergrund gemeldet werden, andererseits soll es einem externen Angreifer nicht möglich sein, den Identitätsträger zu identifizieren und zu verfolgen.
Bei jeder Abfrage müssen Daten zwischen einem Identitätsträger und dem System, das die Identität feststellt (Interrogator) ausgetauscht werden. Tracking zu verhindern bedeutet, dass der Datenaustausch anonymisiert werden muss, sodass ein Angreifer, der Zugriff auf aus dem Identitätsträger ausgelesene Daten hat, weder die Identität selbst feststellen kann, noch Daten aus verschiedenen Abfrage-Vorgängen einer bestimmten Identität zuordnen kann.
Sicherheitsrelevant sind somit zusammenfassend zwei grundsätzliche Angriffe möglich: Zum einen wird die Privatsphäre des Subjekts beeinträchtigt, da ein Angreifer die Identität abfragen kann, ohne dass das Subjekt davon Kenntnis erhält oder seine Zustimmung geben muss. Zum zweiten kann ein Angreifer ein Subjekt über die Registrierung an verschiedenen Interrogatoren verfolgen (Tracking).
Aufgabe der Erfindung
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren anzugeben, um Identitätsdaten (eine ID) aus einem Identitätsträger (z. B. RFID Tag, Mobiltelefon, Smartphone etc.) derart verschleiert an einen Interrogator zu übertragen, dass es dem Abfragesystem möglich ist, den Identitätsträger anhand der ausgelesenen Identitätsdaten zu identifizieren, und das gleichzeitig sicherstellt, dass ein externer Angreifer durch Inspektion der übertragenen oder in Übertragung befindlichen Identitätsdaten keinen Zugriff auf die Identität selbst erhält (Schutz der Privatsphäre) und Daten von verschiedenen Abfragen nicht eindeutig einer Identität zuordnen kann (Anti-Tracking).
Zusammenfassung der Erfindung
Die Aufgabe wird gelöst durch ein Verfahren zum Identifizieren eines Identitätsträgers mit einer darin abgespeicherten ID nach Anspruch 1.
Das Verfahren umfasst die Schritte: a) Auslesen der ID aus dem Identitätsträger durch einen Interrogator; b) durch den Interrogator, Übertragen der ID an einen Server, der eine Datenbank mit einer Mehrzahl von IDs von einer Mehrzahl von Identitätsträgern umfasst, und Identifizieren des Identitätsträgers anhand der ausgelesenen ID. Das Verfahren ist gekennzeichnet durch das Verschleiern der ausgelesenen ID. Das Verschleiern wird durch folgende Maßnahmen erreicht. Im Identitätsträger wird, zusätzlich zur ID, eine der ID eindeutig zugeordnete Handle gespeichert. In der Datenbank des Servers wird, zu jeder ID, der eine Handle zugeordnet ist, der zugeordnete Handle mit der ID abgespeichert, so dass in der Datenbank anhand einer Handle die zugeordnete ID auffindbar ist. Die Handle ist eine Zweit-ID, die es erlaubt, die direkte Verwendung der echten ID zu vermeiden. Weiter wird ein Hashwert durch Anwenden eines Hash-Algorithmus auf die ID und einen zufälligen Salt berechnet. Hierdurch ist die echte ID irreversibel anonymisiert und kann gefahrlos ausgelesen werden. Zudem wird eine Fuzzy-ID durch Anwenden eines Fuzzy-Algorithmus mit einem vorbestimmten Hamming-Abstand auf die Handle berechnet. Die Handle ist hierdurch verschleiert, behält aber genug rekonstruierbare Information über die echte Handle (nicht über die echte ID!), dass durch eine nachfolgende Fuzzy-Suche die echte Handle wieder aufgefunden werden kann.
Das Verfahren umfasst weiter:

den Schritt a) (Ausleseschritt), umfassend folgende Teilschritte:
– Auslesen der ID in Form des Hashwertes zusammen (= irreversibel anonymisierte ID) mit dem bei der Hashwert-Berechnung verwendeten Salt;
– Auslesen der berechneten Fuzzy-ID (= lediglich verschleierte Handle); und
den Schritt b) (Übertragungs- und Auswerteschritt), um über den Umweg der Handle schließlich die echte ID zu ermitteln, mit folgenden Teilschritten:
– um das Übertragen der ID zu bewirken, Übertragen des Hashwerts und des Salt an den Server;
– beim Server, mittels der Fuzzy-ID (verschleierte Handle), Durchführen einer Fuzzy-Suche, und als Ergebnis der Fuzzy-Suche, Festlegen einer Mehrzahl von Kandidaten-Handles, die gemäß der Fuzzy-Suche zum Berechnen der Fuzzy-ID (verschleierten Handle) verwendet worden sein könnten;
– zu jeder ermittelten Kandidaten-Handle, ermitteln der zugeordneten ID (d. h. potentiellen echten ID), um eine entsprechende Mehrzahl von Kandidaten-IDs festzulegen;
– für jede festgelegte Kandidaten-ID, Berechnen eines Vergleichs-Hashwerts durch Anwenden desselben Hash-Algorithmus wie beim Berechnen des Hashwerts, auf die jeweilige Kandidaten-ID und den an den Server übertragenen Salt, um eine Mehrzahl von Vergleichs-Hashwerten zu erzeugen;
– Vergleichen der Mehrzahl von Vergleichs-Hashwerten mit dem an den Server übertragenen Hashwert;
– Identifizieren desjenigen Identitätsträgers, für dessen ID der Vergleichs-Hashwert mit dem an den Server übertragenen Hashwert übereinstimmt, als Identitätsträger, dessen ID – in Form des Hashwert – ausgelesen wurde.

Gemäß der Erfindung wird die ID in Klartext-Form selbst nicht in der Nachricht aufgenommen, sondern nur ein davon abgeleiteter Hash-Wert. Ferner wird für jede Übertragung ein Zufallswert generiert, der in den Hash eingeht und zusätzlich in die Nachricht aufgenommen wird.
Zusätzlich wird in der Nachricht eine Handle übertragen. Die Handle ist ein technischer Schlüssel, der die ID eindeutig adressiert. Die Handle ist im Device fest gespeichert. Bei der Übertragung wird die Handle mit einer zufälligen „Noise” Quelle verknüpft, sodass anstatt der Handle selbst eine Fuzzy ID mit einem fest definierten Hamming Abstand übertragen wird.
Die Nachricht wird über den Empfänger an den Server geleitet. Der Server wertet zunächst die Fuzzy-ID aus und führt einen Fuzzy Suche (Bereichs-Suche oder Range Query) über eine Datenbank aus, die alle vergebenen Handles enthält. Da der Hamming-Abstand eine Metrik darstellt (die Dreiecks-Ungleichung ist erfüllt) können effiziente Fuzzy-Suchalgorithmen eingesetzt werden. Die Suche wird im Allgemeinen eine Anzahl von möglichen Handles ergeben.
Für jedes Suchergebnis wird nun die zugehörige ID ermittelt. Von der ID wird der Hash unter Verwendung des Salt aus der Nachricht gebildet und mit dem übertragenen Hash Wert verglichen. Unter der Voraussetzung dass der Hash kollisionsfrei ist wird in der zweiten Phase somit genau eine passende ID ermittelt, die dann die Grundlage für die weitere Verarbeitung ist.
Die Vorteile des Verfahrens sind:

• Es werden keine kryptologischen Verfahren verwendet; damit sind auch keine Schlüssel und keine Verfahren zur Schlüssel-Verteilung erforderlich.
• Die übertragene Nachricht ist für einen Angreifer nicht einer ID zuordenbar. Da nur der Hash Wert über die ID übertragen wird und die Hash-Funktion nicht umkehrbar ist (Trapdoor), kann aus dem Hash nicht auf die ID rückgeschlossen werden.
• Da ein zufälliger Salt verwendet wird, wird der Hash für die gleiche ID bei jedem Sendevorgang anders sein, sodass über den Hash auch kein Tracking erforderlich ist.
• Die Handle wird als Fuzzy-ID übertragen. Somit wird die Handle auch bei jeder Übertragung anders sein, sodass ein triviales Tracking auch über die Handle nicht möglich ist.
• Alle Handles einer ID haben jedoch einen definierten Hamming Abstand zueinander. Dies könnte ein Angreifer ausnutzen, um Tracking zu erreichen. Das Verfahren geht jedoch davon aus, dass der Hamming Abstand so groß gewählt wird, dass immer eine ausreichende Anzahl von IDs durch die Handle plus den Hamming Bereich möglich sind. Der Angreifer, der keine Kenntnis über die Menge der vergebenen Handles hat, wird somit nur eine ständig variierende Gruppe von IDs tracken können.
• Umgekehrt kann der Server ausgehend von der Kenntnis der vergebenen Handles immer effizient alle passenden Handles zu einer Fuzzy-ID ermitteln.
• Durch die Größe des Wertebereichs der Handle und den Hamming Abstand kann die Tracking Granularität eingestellt werden. Damit sind feine Abstimmungen zwischen Tracking-Granularität und Performance möglich.

Wahlweise umfasst der Salt eine durch den Identifikator erzeugte Zufallszahl. Wahlweise – alternativ oder zusätzlich zur vom Identifikator erzeugten Zufallszahl, umfasst der Salt eine durch den Interrogator erzeugte Nonce, insbesondere (ebenfalls) eine Zufallszahl, die vor Berechnen des Hashwerts durch den Interrogator an den Identitätsträger gesendet wird.
Der Hamming-Abstand des Fuzzy-Algorithmus wird wahlweise so festgelegt, dass bei der Fuzzy-Suche mindestens eine vorbestimmte Mindestzahl von Kandidaten-Handles festgelegt wird, um eine gewisse Verschleierung der wahren Handle zu erreichen. Andererseits darf die Anzahl der Kandidaten-Handles nicht zu hoch sein. Steigt die Anzahl Kandidaten-Handles, gibt es auch zunehmend Kandidaten-Handles, die auf mehrere unterschiedliche echte IDs zurückführen. Ein Rückschluss von einem Kandidaten-Handle auf eine eindeutige ID kann somit zunehmend erschwert oder sogar unmöglich werden. Die Mindestzahl Kandidaten-Handles soll mindestens zehn sein, kann aber auch bis auf mehrere tausend gesteigert werden, mit einer optimalen Kandidaten-Anzahl abhängig von diversen Parametern im System, z. B. in Bereich von 10 bis 10000 oder, enger von 50 bis 500 Kandidaten-Handles.
Kurzbeschreibung der Figuren
Ausführungsbeispiele werden anhand der Figuren dargelegt, worin zeigen:
1 ein Abfragesystem gemäß einer Ausführungsform der Erfindung;
2 einen Scan (TAG-Auslesevorgang) im Abfragesystem aus 1;
3 eine Tabelle mit dem zu wählenden Hamming-Abstand t, um die Anzahl von Überschneidungen s bei gegebener Anzahl von Handles und der Handle-Bitlänge n zu erreichen.
Detaillierte Beschreibung
1 zeigt ein Abfragesystem gemäß einer Ausführungsform der Erfindung, wobei als Identitätsträger ein Transponder oder, gleichbedeutend, TAG vorgesehen ist, also ein Funketikett mit Chip und Antenne, z. B. ein RFID-Tag oder UHF-Tag. Die Lösung wird realisiert durch das Zusammenwirken der folgenden in 1 dargestellten Komponenten.
Transponder = TAG: Der Transponder ist im Besitz des ID-Trägers (endusers). Eine mögliche Ausführungsform ist ein RFID-Tag. Der Transponder kann mittels seiner Antenne Nachrichten über die Luftschnittstelle an den Interrogator senden und auch Nachrichten vom Interrogator empfangen (bidirektionale Kommunikation). Der Transponder-Chip in der erfindungsgemäßen Ausführung umfasst einen Prozessor, nämlich den Micro-Prozessor, und einen Speicher, nämlich den Tag-Storage.
Micro-Processor: Der Prozessor auf dem Transponder kann Daten vom Speicher sowie aus Nachrichten verarbeiten. Der Prozessor wird entweder durch eine Stromquelle auf dem Transponder selbst (aktiv) oder durch die Energie aus der Nachrichten-Übertragung (z. B. Funksignal) betrieben.
Tag-Storage: Im Tag-Storage (Tag-Speicher) sind die ID des Transponders, hier als UID bezeichnet, und eine Handle gespeichert. Das TAG-Storage kann Daten persistent speichern. In der hier zugrunde liegenden Ausführung ist nur lesender Zugriff verlangt. Es wird davon ausgegangen, dass die Daten UID und Handle einmalig in einem Provisionierungsschritt auf das TAG aufgebracht werden. Die Daten stehen dem Micro-Processor des TAG lesend zur Verfügung.
Interrogator: Der Interrogator ist ein Transponder-Lesegerät. Er initiiert die TAG Interaktion. Ziel des Interrogators ist es, am TAG einen Scan, d. h. einen Auslesevorgang durchzuführen, bei dem ID und Handle in verfälschter Form ausgelesen werden. Der Interrogator kann über die Luftschnittstelle (OTA) mit dem Transponder kommunizieren. Der Interrogator kann sowohl Nachrichten an den Transponder senden als auch Nachrichten vom Transponder empfangen. Der kann weiter Daten an den Server senden. Nachdem der Interrogator ein TAG ausgelesen hat und die Daten des TAG in einer Nachricht empfangen hat, erweitert der Interrogator die Nachricht mit seine spezifischen Interrogator-Attributen und sendet die erweiterte Nachricht an einen Server in einer „ScanEvent”-Nachricht.
Server: Der Server hat eine Datenbank, in der zu einer Vielzahl von Transpondern Paare von zusammengehörigen IDs und Handles gespeichert sind. Empfängt der Server von einem Interrogator eine Nachricht, ist es sein Ziel, zu ermitteln, zu welchem Transponder die Nachricht gehört. Die Handles können sich in Lauf der Zeit ändern. Ist dies der Fall, muss die Datenbank jeweils aktualisiert werden. Der Server empfängt die ScanEvent-Notifikation zum Scan-Ereignis und ermittelt in der unten beschriebenen Weise die UID. Danach signalisiert er das Scan-Ereignis mit einer „Event”-Nachricht an den zugeordneten Service Provider SP.
SP: Der SP (Service Provider) ist ein Server der vom Dienst-Anbieter betrieben wird. Es ist die Aufgabe dieses Servers die dem Scan-Ereignis entsprechenden Aktion auf der Ebene des Business Prozesses auszuführen.
UID: Die ID eines Transponders (TAGs) ist eine festgelegte und im Allgemeinen unveränderbare Zahl.
Handle: Die Handle ist eine frei wählbare Zweit-Identität des Transponders, die um Unterschied zur festgelegten eigentlichen ID also insbesondere bei Bedarf immer wieder neu festgelegt werden kann, z. B. als bei Bedarf immer wieder neu generierte Zufallszahl. Nur eine Teilmenge aller möglichen Handles ist tatsächlich für Transponder vergeben. Durch die Teilmenge der tatsächlich vergebenen Handles in Relation zur Gesamtmenge der konstruktiv möglichen Handles ist der später noch verwendete Füllgrad definiert.
Teilweise sind in den Figuren an das Englische angelehnte Kommandos angegeben, die als nicht übersetzbar angesehen werden. Insbesondere werden folgende Kommandos verwendet.
Select(): vom Interrogator an das TAG gesendet, um einen Scan, zu starten.
SHA(): Hashwert-Berechnung.
FuzzyID(): Berechnung einer Fuzzy-ID FUZZY.
Reply(): Antwortnachricht vom TAG an den Interrogator.
ScanEvent(): Kommando, mit dem der Interrogator den Server über das Ereignis eines Auslesens des TAGs informiert und Daten, die der Interrogator aus dem TAG ausgelesen hat, an den Server weiterleitet, ggf. zusammen mit weiteren Daten, die der Interrogator hinzufügt.
Lookup(): Kommando, mit dem der Server bei sich selbst eine Suchabfrage durchführt, um einen Eintrag in der Datenbank zu finden.
Event(): Kommando, mit dem der Server den Service Provider über ein aufgetretenes Ereignis informiert.
RangeQuery(): Fuzzy-Suche in der ID/Handle-Datenbank des Servers, bei der nach einem Bereich („Range”) von mehreren Einträgen gesucht wird.
2 zeigt einen Scan, d. h. Abfragedurchlauf im Abfragesystem aus 1. Der Ablauf des Scan umfasst die folgenden Schritte 1.0–2.5.
1.0 Generate(): nonce [None-Erzeugung = optionaler Schritt]
Der Interrogator erzeugt eine Nonce. Die Generierung kann auf Basis eines Zufallszahlengenerators erfolgen
1.1 Select(nonce) [oder Select()]
Der Interrogator sendet ein Select Signal an den Transponder. Mit dem Select Signal wird der Scan (Abfragedurchlauf) eingeleitet. Falls vom Interrogator eine Nonce erzeugt wurde, wird die Nonce mit dem Select() Signal mit übersendet und an den Transponder übergeben.
1.2 SHA(salt, UID): SHA [oder SHA(salt,nonce,UID) oder SHA(nonce,UID)]
Der Transponder berechnet über. die UID und einen Salt einen Hashwert. Der Salt wird wahlweise auf dem Transponder generiert (z. B. durch einen Zufallszahlengenerator). Alternativ wird die vom Interrogator empfangene Nonce direkt als Salt verwendet. Alternativ werden als Salt ein vom Transponder generierter eigener Salt und die vom Interrogator an den Transponder übertragene Nonce zusammen als Salt verwendet.
1.3 Fuzzy(Handle, h): FUZZY
Der Transponder erzeugt eine Fuzzy-ID FUZZY aus der Handle. Dazu werden maximal h zufällige Bits der Handle invertiert.
2.0 Reply(salt, SHA, FUZZY)
Der Transponder sendet den Salt, den Hash-Code SHA und die Fuzzy-ID FUZZY an den Interrogator.
2.1 ScanEvent(location, datetime, SPID, salt, SHA, FUZZY)
Der Interrogator teilt mit einer „ScanEvent()” Nachricht an den Server das TAG-Auslese-Ereignis mit. Der Interrogator ist mit spezifischen Attributen konfiguriert (z. B. einer Ortsinformation „location” des Interrogators, und einer Service Provider-Identität SPID eines Service-Providers, der den Interrogator betreibt). Ferner ermittelt der Interrogator einen Zeitstempel „Datetime”. Der Interrogator vervollständigt die vom TAG erhaltene Nachricht mit Interrogator-spezifischen Attributen und dem Zeitstempel. Der Interrogator gibt die vom Transponder empfangenen Daten weiter an den Server.
2.2 RangeQuery(FUZZY, h): List<handle>
Der Server führt eine ”Range”-Query über die Handle-Datenbank aus. Eine Range-Query sucht nicht nur nach einem einzelnen Record, d. h. Eintrag, in einer Datenbank, sondern ermittelt alle Records, die in einem Intervall um einen Suchwert liegen. Das Ergebnis der RangeQuery Abfrage ist eine Mehrzahl von Handles, die in dem abgefragten Intervall liegen.
2.3 Lookup(handle): UID
Für jede Handle der Mehrzahl von Handles aus der Range-Query ermittelt der Server die zugehörige UID. Dies ist möglich da eine eindeutige Zuordnung zwischen Handle und UID besteht.
2.4 SHA(salt, UID): hash
Der Server berechnet für jede UID aus der Range-Query den Hash-Wert nach, wie ihn der Transponder selbst berechnet hat, unter Benutzung des Salt aus der Notifikation vom Interrogator. Wenn der so errechnete Hash-Wert gleich dem Hash-Wert aus der Nachricht ist, ist die richtige UID gefunden.
2.5 Event(location, datetime, SPID, UID)
Der Server sendet eine Nachricht an den SP-Server und meldet das Scan Event. Der SP kann nun die Information über die identifizierte ID in der Business Logic anwenden.
Die Range-Query hat als Suchwert die Fuzzy-ID FUZZY. Die Länge des Such-Intervalls ist der maximale Harnming-Abstand h (der max Hamming Abstand ist eine systemweite Konstante). Da der Hamming Abstand eine Metrik ist (die Dreiecksungleichung ist erfüllt) sind die Voraussetzung für eine effiziente Range-Query erfüllt. Der Server kann die IDs in logarithmischer Zeit ermitteln.
Die Handle ist eingeführt, obwohl eine eins-zu-eins Beziehung zwischen der Handle und der UID besteht. Die UID kann reicht direkt verwendet werden, da die UID nie in den übertragenen Daten erscheinen soll. Zudem soll auch eine optimale Verteilung der Werte für die Range-Query erreicht werden. Außerdem soll erreicht werden, dass immer ausreichend viele Werte im Hamming Abstand zu jeder Handle liegen. Dies ist in der Regel nur durch einen durch das System vergebenen Wert für die Handle sichergestellt.
Zusammenfassend werden vom Interrogator zum Transponder folgenden Daten übertragen:

• Nonce (zufälliger Wert)

Vom Transponder zum Interrogator werden die folgenden Daten gesendet:

• Salt (zufällig gewählter Wert)
• Hash über UID (mit Salt)
• Fuzzy-Handle (von tatsächlicher Handle abgeleitet, mit max h bits umgeschaltet)

Die angestrebte Absicherung gegen einen Tracking-Angriff erfordert eine sorgfältige und abgestimmte Auswahl des Wertebereichs des Handle und des maximalen Hamming Abstandes t.
Im Folgenden gehen wir von einem binären Alphabet A = {0, 1} aus. Handles x oder y sind dann Blockcodes mit der Bitlänge n und bilden in ihrer Gesamtheit eine Menge: C ⊆ Aⁿ möglicher Handles x, y.
Eine Kugel K vom Radius t bezogen auf den Hamming Abstand d und einen bestimmten Handle x sei definiert wie folgt: K_t(x) = {y ∊ C:d(x, y) ≤ t)
Dabei soll d(x, y) den Hamming Abstand zweier Handles x, y zueinander bezeichnen und t den für die Kugel K maximal zulässigen Hamming Abstand t.
K_t(x) ist eine Teilmenge von Aⁿ. Die Mächtigkeit von K_t(x) errechnet sich wie folgt:
Der maximale Hamming Abstand t und der Wertebereich der Handles x (bzw. y), die in dieser Kugel K liegen, soll so gewählt werden, dass es für jedes beliebige x ∊ C eine Menge Y ⊆ C gibt mit der folgenden Eigenschaft: ∀ y ∊ Y:K_t(x) ∩ K_t(y) ≠ ∅
Das heißt mit anderen Worten, die Anzahl der Handles x, y muss größer als die Kugelpackungsschranke (Hamming-Schranke) |C| sein. Die Kugelpackungsschranke |C| bei gegebener Bitlänge n und maximalem Hamming-Abstand t berechnet sich wie folgt:
Wenn die Anzahl der Handles x, y unterhalb der Kugelpackungsschranke C liegt, kann der Angreifer eine mitgehörte Handle dekodieren und einem originalen Handle zuordnen, wenn er Kenntnis aller Handles hätte (was in der Praxis allerdings nicht der Fall ist).
Die Unsicherheit für den Dekodierer (den Angreifer) erhöht sich, je mehr Blockcodewörter (Handles) × definiert sind, je größer der maximale Hamming Abstand t ist und je kleiner die Bitlänge n gewählt wird.
Die Tabelle in 3 stellt eine Abschätzung dieses Zusammenhangs dar.
Als Grundlage für das Maß für die Unsicherheit des Dekodierers (Angreifers) ist die Überschneidungsmenge S von Kugeln K für Handles c ∊ C in Bezug auf eine Kugel K(x) um ein spezielles Handle x angenommen, die wie folgt definiert ist: S_t(x) = {c ∈ C: K_t(c) ∩ K_t(x) ≠ ∅}
Als eigentliches Maß für Unsicherheit selbst bzw. die Güte der Privacy-Protection soll die minimale Mächtigkeit von S für alle gültigen Code-Wörter/Handles c angenommen werden:
Die Tabelle in 3 zeigt in den Tabellenfeldern im rechten Teil der Tabelle die maximale Hamming-Distanz t, die gewählt werden müsste, um eine vorgegebene Überschneidung (Unsicherheit s) zu erreichen. In Analogie zur Berechnung der Kugelpackungsschranke |C| wird für die Berechnung die Überbelegung des verfügbaren Code-Raums durch die Kugeln K herangezogen. Die Tabelle 3 ist wie folgt zu lesen:

• Die Kopfzeile im rechten Teil der Tabelle gibt die geforderte Überschneidung s bzw. die Unsicherheit an, mit exemplarischen Überschneidungs-Werten s = 1, 5, 10, 20, 100, 500, 1000 und 2000
• Die erste Spalte zeigt die Länge n des Blockcodes (Bit-Länge), d. h. des Handles x, mit Bit-Länge-Werten n = 8, 16, 24, 32, 48 und 64
• Die zweite Spalte zeigt die Anzahl |C| der gültigen Code-Wörter; dies entspricht der Anzahl |C| der verwendeten Handles
• Die dritte Spalte zeigt den Füllgrad f (Fill %) und damit die definierten Handles als relative Größe in Bezug auf die Gesamtzahl der möglichen Block-Codes (die Formel liefert Werte im Bereich 0...1, die Tabelle zeigt die entsprechenden Prozentwerte):
Der Füllgrad f ist somit das Verhältnis zwischen den möglichen Handles im Code-Raum zu den tatsächlich definierten Handles. Zum Beispiel, bei einer Bitlänge n von 8 Bit und 25 definierten Handles ist der Füllgrad f ca. 10%.
• Die restlichen Spalten zeigen den Hamming-Abstand t, der gewählt werden müsste, um die in der Kopfzeile gegebene Unsicherheit s = 1, 5, 10, ... bzw. 2000 zu erreichen

Grundlage für die Werte in der Tabelle ist die folgende Berechnung der Überbelegung tab (n, c, s) des verfügbaren Code-Raums durch die Menge aller Kugeln K_t:
Mit anderen Worten: Eine Kugel K_t gibt die für eine Handle mögliche Menge von Block-Codes C mit dem gewählten Hamming Abstand t an. Wenn die Summe der Mächtigkeit aller K_t für alle definierten Handles den Code-Bereich (2ⁿ) um das s-fache übersteigt, ist dies eine hinreichende Bedingung für mindestens s Überschneidungen für jede definierte Handle, d. h.
Die Parameter n, c ergeben sich aus der Zeile (wie in Spalte 1 und 2 angeben), der Parameter s ergibt sich aus der jeweiligen Spalte (siehe Kopfzeile). Die Werte in der Tabelle (Zellen) sind der nach der obigen Formel ermittelte minimale Hamming Abstand t.
Die Sektion mit der Bitlänge 8 hat nur informativen Charakter, aber keine praktische Bedeutung.
Für das Verfahren günstig ist ein ausreichend hoher Hamming-Abstand t und eine dünn besetzte Code-Space (|C| ist klein).
Da die Handles C technische Identifier sind, die durch das System generiert werden, kann durch den Generierungsalgorithmus sichergestellt werden, dass es für fast alle Handles eine ausreichende Mehrdeutigkeit besteht, indem neue Handles solange wie möglich aus den Kugeln K_t bestehender Handles gewählt werden.
Der Nachweis des Schutzes der Identität ID ist trivial, er ist dadurch gegeben, dass nie die Identität selbst, sondern nur der Hash Wert übertragen wird. Ein Angreifer müsste die Hash-Funktion umkehren, um die tatsächliche Identität zu ermitteln. Eine geeignete Hash-Funktion vorausgesetzt gehen wir davon aus, dass dies nicht effizient möglich ist. Zudem würde ein erfolgreicher Angriff auf die Hash-Funktion nur eine einzige ID kompromittieren, das System selbst bliebe aber sicher.
Gegen Tracking schützt das erfindungsgemäße Verfahren wie folgt:
Der Hash-Wert ist mit einem zufälligen „Salt” geschützt. Das bedeutet, dass für jede Abfrage ein neuer Zufallswert „Salt” gebildet und in die Hash-Berechnung einbezogen wird. Der „Salt” ist in den Abfragedaten enthalten. Somit enthalten die Daten von verschiedenen Abfragen unterschiedliche Hash Werte (bis auf den Fall dass tatsächlich der gleiche Salt verwendet wird, was als sehr unwahrscheinlich angesehen werden kann).
Ein Tracking Angriff kann auch über die Handle geführt werden. Die Handle wird aber als Fuzzy-ID übertragen. Das bedeutet, auch die Handle wird in den Daten von verschiedenen Abfragen unterschiedlich sein.
Der Angreifer kann zwar den Hamming Abstand von zwei unterschiedlichen Fuzzy-Handles berechnen. Damit kann der Angreifer aber nur sicher feststellen, dass zwei Handles zu verschiedenen Identitäten gehören (weil der Hamming Abstand zu groß ist).
Zwei Handles x, y ∊ Aⁿ, die nahe beieinander liegen (geringe Hamming-Distanz d(x, y)), können immer zu unterschiedlichen Identitäten gehören. Zum einen sollte der Hamming Abstand so gewählt werden, dass immer Überschneidungen möglich sind, die aber der Server wegen der Kenntnis der vergebenen Handles leicht auflösen kann.
Zum anderen ist der Angreifer im Nachteil, da er nur die Fuzzy-Handles aber nicht den tatsächlichen Handle-Wert kennt. Letztlich bedeutet dies dass der Angreifer mit dem doppelten Hamming Abstand rechnen muss (wegen Kugel-Überschneidung):
Dies kann an dem folgenden Beispiel gezeigt werden (Annahme ist 8 Bit Handle-Länge n, und Hamming-Abstand t = 3):
Tatsächliches Handle:
Fuzzy-Handle, offen für Angreifer:
Mögliches Handle, mit Hamming Abstand t = 3 vom Fuzzy-Handle und Hamming Abstand t = 6 zum tatsächlichen Handle:
Als Spezialfall sei angemerkt, dass selbst zwei gleiche von einem Angreifer beobachtete Fuzzy-Handle-Werte somit zu unterschiedlichen Identitäten gehören können.

Claims

Verfahren zum Identifizieren eines Identitätsträgers (TAG) mit einer darin abgespeicherten ID, umfassend die Schritte: a) Auslesen der ID aus dem Identitätsträger (TAG) durch einen Interrogator; b) durch den Interrogator, Übertragen der ID an einen Server, der eine Datenbank mit einer Mehrzahl von IDs von einer Mehrzahl von Identitätsträgern umfasst, und Identifizieren des Identitätsträgers (TAG) anhand der ausgelesenen ID; gekennzeichnet durch die Merkmale: Verschleiern der ausgelesenen ID durch folgende Maßnahmen: – im Identitätsträger (TAG), Gespeicherthalten oder Abspeichern einer der ID eindeutig zugeordneten Handle; – in der Datenbank des Servers, zu jeder ID, der eine Handle zugeordnet ist, Abspeichern der zugeordneten Handle mit der ID, so dass in der Datenbank anhand einer Handle die zugeordnete ID auffindbar ist; – Berechnen eines Hashwertes durch Anwenden eines Hash-Algorithmus auf die ID und einen zufälligen Salt; – Berechnen einer Fuzzy-ID durch Anwenden eines Fuzzy-Algorithmus mit einem vorbestimmten Hamming-Abstand (t) auf die Handle; und durch das Merkmal, dass Schritt a) umfasst: – Auslesen der ID in Form des Hashwertes zusammen mit dem bei der Hashwert-Berechnung verwendeten Salt; – Auslesen der berechneten Fuzzy-ID; und Schritt b) umfasst: – um das Übertragen der ID zu bewirken, Übertragen des Hashwerts und des Salt an den Server; – beim Server, mittels der Fuzzy-ID, Durchführen einer Fuzzy-Suche, und als Ergebnis der Fuzzy-Suche, Festlegen einer Mehrzahl von Kandidaten-Handles, die gemäß der Fuzzy-Suche zum Berechnen der Fuzzy-ID verwendet worden sein könnten; – zu jeder ermittelten Kandidaten-Handle, ermitteln der zugeordneten ID, um eine entsprechende Mehrzahl von Kandidaten-IDs festzulegen; – für jede festgelegte Kandidaten-ID, Berechnen eines Vergleichs-Hashwerts durch Anwenden desselben Hash-Algorithmus wie beim Berechnen des Hashwerts; auf die jeweilige Kandidaten-ID und den an den Server übertragenen Salt, um eine Mehrzahl von Vergleichs-Hashwerten zu erzeugen; – Vergleichen der Mehrzahl von Vergleichs-Hashwerten mit dem an den Server übertragenen Hashwert; – Identifizieren desjenigen Identitätsträgers, für dessen ID der Vergleichs-Hashwert mit dem an den Server übertragenen Hashwert übereinstimmt.
Verfahren nach Anspruch 1, wobei der Salt eine durch den Identifikator erzeugte Zufallszahl umfasst.
Verfahren nach Anspruch 1 oder 2, wobei der Salt eine durch den Interrogator erzeugte Nonce, insbesondere eine Zufallszahl, umfasst, die vor Berechnen des Hashwerts durch den Interrogator an den Identitätsträger (TAG) gesendet wird.
Verfahren nach einem der Ansprüche 1 bis 3, wobei der Hamming-Abstand (t) des Fuzzy-Algorithmus so festgelegt wird, dass bei der Fuzzy-Suche mindestens eine vorbestimmte Mindestzahl von Kandidaten-Handles festgelegt wird.
Verfahren nach Anspruch 4, wobei die Mindestzahl von Kandidaten-Handles im Bereich von zehn bis mehrere tausend liegt, weiter vorzugsweise im Bereich 10 bis 10000, weiter vorzugsweise im Bereich von 50 bis 500.