Die Erfindung betrifft das Gebiet des Identifizierens eines Identitätsträgers mittels Auslesens von Identitätsdaten, im Zusammenhang mit der Erfindung auch einfach als ID bezeichnet, aus einem Identitätsträger durch einen Inter- rogator (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 erzie- len. 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üsselma- nagement 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, OT A) 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. Tra- cking 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 An- griffe 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 Interrogato- ren 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 übertra- gen, 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 Abfra- gen 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 Identi- tä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 anony- misiert 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 auf efunden werden kann.

Das Verfahren umfasst weiter:

den Schritt a) (Ausleseschritt), umfassend folgende Teilschritte:

- Auslesen der ID in Form des Hashwertes zusammen (= irreversibel ano- nymisierte 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-Handies, 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 Kandida- ten-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 Handies 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 Handies 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 pas- sende 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 er- forderlich.

• Die übertragene Nachricht ist für einen Angreifer nicht einer ID zu- ordenbar. 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 Handies 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 Handies hat, wird somit nur eine ständig variierende Gruppe von IDs tracken können.

Umgekehrt kann der Server ausgehend von der Kenntnis der vergebenen Handies immer effizient alle passenden Handies 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 festge- legt, dass bei der Fuzzy-Suche mindestens eine vorbestimmte Mindestzahl von Kandidaten-Handies festgelegt wird, um eine gewisse Verschleierung der wahren Handle zu erreichen. Andererseits darf die Anzahl der Kandidaten-Handies nicht zu hoch sein. Steigt die Anzahl Kandidaten-Handies, gibt es auch zunehmend Kandidaten-Handies, 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-Handies soll mindestens zehn sein, kann aber auch bis auf mehrere tausend gesteigert werden, mit einer optima- len Kandidaten- Anzahl abhängig von diversen Parametern im System, z.B. in Bereich von 10 bis 10000 oder, enger von 50 bis 500 Kandidaten-Handies.

Kurzbeschreibung der Figuren

Ausführungsbeispiele werden anhand der Figuren dargelegt, worin zeigen: Fig. 1 ein Abfragesystem gemäß einer Ausführungsform der Erfindung; Fig. 2 einen Scan (TAG- Auslesevorgang) im Abfragesystem aus Fig. 1;

Fig. 3 eine Tabelle mit dem zu wählenden Hamming- Abstand t, um die Anzahl von Überschneidungen s bei gegebener Anzahl von Handies und der Handle-Bitlänge n zu erreichen.

Detaillierte Beschreibung

Fig. 1 zeigt ein Abfragesystem gemäß einer Ausführungsform der Erfindung, wobei als Identitätsträger ein Transponder oder, gleichbedeutend, TAG vor- gesehen 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 Fig. 1 dargestellten Komponenten.

Transponder TAG: Der Transponder ist im Besitz des ID-Trägers (end- users). 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 Handies 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 Handies 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 Allge- meinen 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 Handies ist tatsächlich für Transponder vergeben. Durch die Teilmenge der tatsächlich vergebenen Handies in Relation zur Gesamtmenge der konstruktiv möglichen Handies ist der später noch verwendete Füllgrad definiert.

Teilweise sind in den Figuren an das Englische angelehnte Kommandos an- gegeben, die als nicht übersetzbar angesehen werden. Insbesondere werden folgende Kommandos verwendet.

SelectQ: vom Interrogator an das TAG gesendet, um einen Scan, zu starten.

SHA(): Hashwert-Berechnung.

FuzzyID(): Berechnung einer Fuzzy-ID FUZZY.

ReplyQ: Antwortnachricht vom TAG an den Interrogator.

ScanEventQ: 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.

EventQ: 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.

Fig. 2 zeigt einen Scan, d.h. Abfragedurchlauf im Abfragesystem aus Fig. 1. Der Ablauf des Scan umfasst die folgenden Schrittel.0-2.5.

1.0 GenerateQ: nonce [Nonce-Erzeugung = optionaler Schritt]

Der Interrogator erzeugt eine Nonce. Die Generierung kann auf Basis eines Zufallszahlengenerators erfolgen

1.1 Select(nonce) [ oder SelectQ ]

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 Transpon- der ü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 Inter- rogator betreibt). Ferner ermittelt der Interrogator einen Zeitstempel„Da- tetime". 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 Handies, die in dem abgefragten Intervall liegen.

2.3 Lookup(handle): UID

Für jede Handle der Mehrzahl von Handies 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 Hamming- Abstand h (der max Hamming Abstand ist eine systemweite Konstante). Da der Hanroiing Abstand eine etrik 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 nicht 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. Handies x oder y sind dann Blockcodes mit der Bitlänge n und bilden in ihrer Gesamtheit eine Menge: C £ A ⁿ möglicher Handies 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 { ) = ly e c : d(x, y < t }

Dabei soll d(x, y) den Hamming Abstand zweier Handies x, y zueinander bezeichnen und t den für die Kugel K maximal zulässigen Hamming Ab- stand t.

Kt(x) ist eine Teilmenge von A ⁿ . Die Mächtigkeit von Kt(x) errechnet sich wie folgt:

Der maximale Hamming Abstand t und der Wertebereich der Handies x (bzw. y), die in dieser Kugel K liegen, soll so gewählt werden, dass es für jedes beliebige x eC eine Menge Y £C gibt mit der folgenden Eigenschaft:

V y E Y : K _t {x) n K _t (y) * 0

Das heißt mit anderen Worten, die Anzahl der Handies x, y muss größer als die Kugelpackungsschranke (Hamming-Schranke) | C | sein. Die Kugelpackungsschranke I C I bei gegebener Bitlänge n und maximalem Hamming- Abstand t berechnet sich wie folgt:

Wenn die Anzahl der Handies x, y unterhalb der Kugelpackungsschranke

I C I liegt, kann der Angreifer eine mitgehörte Handle dekodieren und einem originalen Handle zuordnen, wenn er Kenntnis aller Handies 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 (Handies) x definiert sind, je größer der maximale Hamming Abstand t ist und je kleiner die Bitlänge n gewählt wird.

Die Tabelle in Fig. 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 Handies c e C in Bezug auf eine Kugel K(x) um ein spezielles Handle x angenommen, die wie folgt definiert ist:

s _t (x = {c e c : K _t {c) n K _t (x 0 }

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 / Handies c angenommen werden:

s _t = min|5 _t (c) |

Die Tabelle in Fig. 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 Fig. 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 Handies 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 Handies

• Die dritte Spalte zeigt den Füllgrad f (Fill %) und damit die definierten Handies 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):

, ici Der Füllgrad f ist somit das Verhältnis zwischen den möglichen Handies im Code-Raum zu den tatsächlich definierten Handies. Zum Beispiel, bei einer Bitlänge n von 8 Bit und 25 definierten Handies 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 Kt:

Mit anderen Worten: Eine Kugel Kt 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 Kt für alle definierten Handies den Code- Bereich (2 ⁿ ) um das s-f ache ü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 Handies C technische Identifier sind, die durch das System generiert werden, kann durch den Generierungsalgorithmus sichergestellt werden, dass es für fast alle Handies eine ausreichende Mehrdeutigkeit besteht, indem neue Handies solange wie möglich aus den Kugeln Kt bestehender Handies 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 Handies zu verschiedenen Identitäten gehören (weil der Hamming Abstand zu groß ist).

Zwei Handies x, y e 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 Handies 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:

Ά 1 0 1

Mögliches Handle, mit Hamming Abstand t = 3 vom Fuzzy-Handle und Hamming Abstand t = 6 zum tatsächlichen Handle:

0 1 3

Als Spezialfall sei angemerkt, dass selbst zwei gleiche von einem Angreifer beobachtete Fuzzy-Handle- Werte somit zu unterschiedlichen Identitäten gehören können.