EP3443769A1 - Identifizieren eines identitätsträgers - Google Patents

Identifizieren eines identitätsträgers

Info

Publication number
EP3443769A1
EP3443769A1 EP17719806.6A EP17719806A EP3443769A1 EP 3443769 A1 EP3443769 A1 EP 3443769A1 EP 17719806 A EP17719806 A EP 17719806A EP 3443769 A1 EP3443769 A1 EP 3443769A1
Authority
EP
European Patent Office
Prior art keywords
fuzzy
handle
server
hash value
candidate
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP17719806.6A
Other languages
English (en)
French (fr)
Inventor
Udo Schwartz
Kurt Stadler
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient Mobile Security GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient Mobile Security GmbH filed Critical Giesecke and Devrient Mobile Security GmbH
Publication of EP3443769A1 publication Critical patent/EP3443769A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0414—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden during transmission, i.e. party's identity is protected against eavesdropping, e.g. by using temporary identifiers, but is known to the other party or parties involved in the communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Definitions

  • the invention relates to the field of identifying an identity carrier by means of reading out identity data, also referred to simply as ID in the context of the invention, from an identity carrier by an interferogram (detection device) via a contactless interface (radio interface, OTA interface).
  • ID identity data
  • interferogram detection device
  • OTA contactless interface
  • an ID is made up of an identifier, e.g. an RFID tag, to an interrogator, e.g. RFID reader, transmitted and identifies the principal by the transmitted ID.
  • the query is mostly passive, i. the process needs no action of the subject and therefore no explicit consent.
  • the query takes place via an air interface, and is activated as soon as the principal is within the detection distance of the interrogator.
  • a server In connection with the interrogator is a server that receives and evaluates read-out IDs from a large number of interrogators.
  • a service provider In connection with the server is a service provider.
  • This is a system through which a computer-implemented business model, hereinafter referred to as business logic, is realized.
  • the business logic can be any application of an ID system, such as logistics, warehousing, access rights management, etc.
  • Sending the ID from the principal can be done passively (automatically by bringing the principal into the scope of the interrogator) or actively (controlled by the user).
  • the ID is picked up by the interrogator and sent to the server. There, the ID is evaluated.
  • the ID is transmitted in plain text from the principal to the interrogator. As a result, the identification has already been achieved with the reading and subsequent evaluation on the server. The identification is thus very easy and easy to achieve.
  • the ID on the other hand, is readable by anyone. In addition, anyone can track the location of the identity carrier based on the ID read out (tracking).
  • the readability of the ID is in principle a violation of privacy, which may be undesirable.
  • the traceability, ie trackability, the ID may be undesirable.
  • a direct solution to ensure privacy is to put the ID in encrypted form during the day. With such a solution, a key management is required, which means effort. If a tag-individual symmetric key is used, it must be stored in the tag, which means a security risk. If a key derivation method is used, the tag must be able to perform elaborate cryptographic calculations. Tracking individual tags is still possible even with encrypted tag read out of the tag.
  • a secure tracking (tracking) of identities with electronic methods, in particular via the air interface (RFID, OT A) must fulfill two initially contradictory objectives: On the one hand, the identity must be reliably transmitted and reported to the system in the background, on the other hand, it should be an external Attackers will not be able to identify and track the principal. For each query, data must be exchanged between a principal and the system that identifies the identity (interrogator). To prevent tracing means that the exchange of data must be anonymised, so that an attacker who has access to data read from the principal can neither determine the identity itself nor assign data from different query processes to a specific identity.
  • the object of the invention is to specify a method for transmitting identity data (an ID) from an identity carrier (eg RFID tag, mobile phone, smartphone, etc.) to an interrogator in such a way that it is possible for the interrogation system Identifying identity bearers based on the read identity data, while ensuring that an external attacker does not gain access to the identity itself by inspecting the transmitted or transmitted identity data (privacy) and unambiguously associating data from different queries with an identity can (anti-tracking).
  • an ID identity data
  • an identity carrier eg RFID tag, mobile phone, smartphone, etc.
  • the object is achieved by a method for identifying an identity carrier with an ID stored therein according to claim 1.
  • the method comprises the steps of: a) reading the ID from the principal by an interrogator; b) by the interrogator, transmitting the ID to a server comprising a database having a plurality of IDs from a plurality of identity bearers, and identifying the identity bearer based on the read ID.
  • the method is characterized by obscuring the read-out ID.
  • the obfuscation is achieved by the following measures.
  • the identity carrier in addition to the ID, a handle uniquely assigned to the ID is stored.
  • the assigned handle with the ID is stored, so that in the database by means of a handle the assigned ID can be found.
  • the handle is a secondary ID that allows you to avoid using the real ID directly.
  • a hash value is calculated by applying a hashing algorithm to the ID and a random salt.
  • the real ID is irreversibly anonymous and can be read out without risk.
  • a fuzzy ID is calculated by applying a fuzzy algorithm with a predetermined Hamming distance to the handles. The handle is thereby obfuscated, but retains enough reconstructable information about the real handle (not the real ID!) That a subsequent fuzzy search can reestablish the real handle.
  • the method further includes:
  • step a) read-out step, comprising the following substeps:
  • step b) (transfer and evaluation step), in order to determine the real ID via the detour of the handle, with the following sub-steps:
  • the server by means of the fuzzy ID (obfuscated handle), performing a fuzzy search, and as a result of the fuzzy search, determining a plurality of candidate mobile phones which according to the fuzzy search for calculating the fuzzy ID (obfuscated) Handle) could have been used;
  • each determined candidate handle determines the assigned ID (i.e., potential true ID) to determine a corresponding plurality of candidate IDs;
  • Hash value to the respective candidate ID and the salt transferred to the server, to generate a plurality of comparison hash values
  • Hash value with the hash value transmitted to the server as an identity carrier whose ID has been read out in the form of the hash value.
  • the ID in plain text form itself is not included in the message, but only a hash value derived therefrom. Furthermore, a random value is generated for each transmission, which enters the hash and is additionally included in the message.
  • a handle is transferred in the message.
  • the handle is a technical key that uniquely addresses the ID.
  • the handle is permanently stored in the device. During the transfer, the handles are linked with a random "noise" source so that instead of the handle itself, a fuzzy ID with a defined Hamming distance is transmitted.
  • the message is routed to the server via the receiver.
  • the server first evaluates the fuzzy ID and performs a fuzzy search (area scan). Search or Range Query) via a database containing all assigned mobile phones. Since the Hamming distance is a metric (the triangle inequality is met), efficient fuzzy search algorithms can be used. The search will generally result in a number of possible cell phones.
  • the corresponding ID is now determined.
  • the ID of the hash is formed from the message using the salt and compared to the transmitted hash value. Assuming that the hash is collision free, in the second phase exactly one matching ID is determined, which then forms the basis for further processing.
  • the transmitted message can not be assigned to an ID for an attacker. Since only the hash value is transmitted via the ID and the hash function can not be reversed (trapdoor), the hash can not be used to deduce the ID.
  • the handle is transmitted as a fuzzy ID.
  • the handle will be different even with each transmission, so that a trivial tracking is not possible even on the handle.
  • the server can always efficiently determine all matching mobile phones for a fuzzy ID.
  • the size of the value range of the handle and the Hamming distance can be used to set the tracking granularity. This allows fine-tuning between tracking granularity and performance.
  • the salt comprises a random number generated by the identifier.
  • the salt comprises a nonce generated by the interrogator, in particular (also) a random number, which is sent to the principal prior to calculating the hash value by the interrogator.
  • the hamming distance of the fuzzy algorithm is optionally set so that in the fuzzy search at least a predetermined minimum number of candidate phones is set to achieve some obfuscation of the true handle.
  • the number of candidate handies should not be too high.
  • the minimum number of candidate phones should be at least ten, but it can also be increased to several thousand, with an optimal number of candidates depends on various parameters in the system, eg in the range from 10 to 10,000 or, more narrowly, from 50 to 500 candidate phones.
  • FIG. 1 shows a polling system according to an embodiment of the invention
  • FIG. 2 shows a scan (TAG read-out process) in the interrogation system from FIG. 1
  • FIG. 1 shows a polling system according to an embodiment of the invention
  • FIG. 2 shows a scan (TAG read-out process) in the interrogation system from FIG. 1
  • FIG. 1 shows a polling system according to an embodiment of the invention
  • FIG. 2 shows a scan (TAG read-out process) in the interrogation system from FIG. 1
  • 3 shows a table with the Hamming distance t to be selected in order to achieve the number of overlaps s for a given number of mobiles and the handle bit length n.
  • FIG. 1 shows an interrogation system according to an embodiment of the invention, wherein the identity carrier is a transponder or, equivalently, TAG, ie a tag with chip and antenna, e.g. an RFID tag or UHF tag.
  • the identity carrier is a transponder or, equivalently, TAG, ie a tag with chip and antenna, e.g. an RFID tag or UHF tag.
  • Transponder TAG The transponder is owned by the ID carrier (end-users).
  • One possible embodiment is an RFID tag.
  • the transponder can transmit messages via the air interface to the interrogator via its aerial and also receive messages from the interrogator (bidirectional communication).
  • the transponder chip in the embodiment according to the invention comprises a processor, namely the micro-processor, and a memory, namely the tag-storage.
  • the processor on the transponder can process data from the memory as well as from messages.
  • the processor is operated either by a power source on the transponder itself (active) or by the energy from the message transmission (eg radio signal).
  • Tag Storage stores the ID of the transponder, here called UID, and a handle.
  • the TAG storage can store data persistently. In the embodiment on which it is based, only read access is required. It is assumed that the data UID and handle are applied once to the TAG in a provisioning step. The data is available to the TAG's Micro-Processor.
  • the interrogator is a transponder reader. He initiates the TAG interaction. The goal of the interrogator is to perform a scan on the TAG, i. perform a read-out process in which ID and handle are read in a falsified form.
  • the interrogator can communicate with the transponder via the air interface (OTA).
  • OTA air interface
  • the interrogator can both send messages to the transponder and receive messages from the transponder. He can continue to send data to the server. After the interrogator has read out a TAG and the data of the TAG in one
  • the interrogator Message received, the interrogator extends the message with its specific Interrogator attributes and sends the extended message to a server in a "ScanEvent" message.
  • the server has a database in which a large number of transponders store pairs of related IDs and cell phones. When the server receives a message from an interrogator, its goal is to determine to which transponder the message belongs. The cell phones may change over time. If so, the database must be updated.
  • the server receives the ScanEvent notification for the scan event and determines the UID in the manner described below. He then signals the scan event with an "event" message to the associated service provider SP.
  • SP The SP (service provider) is a server operated by the service provider. It is the task of this server to execute the action corresponding to the scan event at the level of the business process.
  • UID The ID of a transponder (TAG) is a fixed and generally unchangeable number.
  • the handle is a freely selectable secondary identity of the transponder, which can be redefined again and again, in order to differentiate from the specified actual ID, in particular if required, e.g. as if necessary again and again newly generated random number. Only a subset of all possible cell phones is actually allocated for transponders. Due to the subset of the actually awarded mobile phones in relation to the total amount of constructionally possible mobile phones, the degree of filling used later is defined.
  • SelectQ sent by the interrogator to the TAG to start a scan.
  • SHA () hash value calculation.
  • FuzzyID Calculation of a fuzzy ID FUZZY.
  • ScanEventQ Command used by the interrogator to inform the server about the event of reading the tag and to forward data that the interrogator has read from the tag to the server, possibly together with other data added by the interrogator.
  • Lookup () Command used by the server to perform a search on itself to find an entry in the database.
  • EventQ Command used by the server to inform the service provider of an event that has occurred.
  • RangeQuery Fuzzy search in the ID / Handle database of the server, which searches for a range of several entries.
  • Fig. 2 shows a scan, i. Query pass in the query system of Fig. 1.
  • the flow of the scan includes the following steps.
  • the interrogator generates a nonce.
  • the generation can be done on the basis of a random number generator
  • the interrogator sends a select signal to the transponder.
  • the select signal initiates the scan (query run). If a nonce was generated by the interrogator, the nonce is also sent with the Select () signal and transferred to the transponder.
  • the salt is optionally generated on the transponder (e.g., by a random number generator).
  • the nonce received from the interrogator is used directly as salt.
  • a salt generated by the transponder and the nonce transferred from the interrogator to the transponder are used together as salt.
  • the transponder generates a fuzzy ID FUZZY from the handle. For this a maximum of h random bits are inverted.
  • the transponder sends the salt, the hash code SHA and the fuzzy ID FUZZY to the interrogator.
  • the interrogator communicates the tag read out event with a "ScanEvent ()" message to the server.
  • the interrogator has specific attributes configured (eg a location information "location" of the interrogator, and a service provider identity SPID of a service provider who operates the Interrogator) .
  • the interrogator also determines a timestamp "date”.
  • the interrogator completes the message received from the TAG with interrogator-specific attributes and the timestamp.
  • the interrogator forwards the data received from the transponder to the server.
  • the server executes a "range" query over the handle database.
  • a range query does not just look for a single record, i. Entry, in a database, but determines all records that lie in an interval by a search value.
  • the result of the RangeQuery query is a plurality of phones that are in the polled interval.
  • the server determines the associated UID. This is possible because there is a clear assignment between handle and UID.
  • the server calculates the hash value for each UID from the range query, as calculated by the transponder itself, using the salt from the notification from the interrogator. If the hash value calculated in this way equals the hash value from the message, the correct UID is found.
  • the server sends a message to the SP server and reports the scan event.
  • the SP can now use the information about the identified ID in the Business Logic.
  • the range query has the fuzzy ID FUZZY as the search value.
  • the length of the search interval is the maximum Hamming distance h (the max Hamming distance is a system-wide constant). Since the Hanroiing distance one etrik is satisfied (the triangle inequality is met) are the prerequisite for an efficient range query.
  • the server can determine the IDs in logarithmic time.
  • the handle is introduced, although there is a one-to-one relationship between the handle and the UID.
  • the UID can not be used directly because the UID should never appear in the transmitted data.
  • an optimal distribution of the values for the range query is to be achieved. It should also be ensured that there are always enough values in the Hamming distance to each handle. This is usually ensured only by a value assigned by the system for the handle.
  • the desired protection against a tracking attack requires a careful and coordinated selection of the value range of the handle and the maximum Hamming distance t.
  • Handies x or y are then block codes of bit length n and in their entirety form a set: C £ A n of possible handies x, y.
  • a sphere K of radius t related to the Hamming distance d and a given handle x is defined as follows:
  • K t ⁇ ) ly ec: d (x, y ⁇ t ⁇
  • d (x, y) should denote the Hamming distance of two mobile phones x, y to each other and t the maximum permissible Hamming distance t for the ball K.
  • Kt (x) is a subset of A n .
  • the power of Kt (x) is calculated as follows:
  • the maximum Hamming distance t and the range of values of the phones x (or y) lying in this sphere K should be chosen such that for any x eC there exists a set Y £ C with the following property:
  • V y EY K t ⁇ x) n K t (y) * 0
  • the number of mobile phones x, y must be greater than the sphere barrier (Hamming barrier)
  • the ball packing barrier ICI for a given bit length n and maximum Hamming distance t is calculated as follows:
  • the uncertainty for the decoder increases as more block codewords (phones) x are defined, the larger the maximum Hamming distance t is and the smaller the bit length n is chosen.
  • the table in FIG. 3 represents an estimate of this relationship.
  • the overlap set S of balls K for phones ce C with respect to a sphere K (x) is assumed to be a special handle x, defined as follows:
  • the table in FIG. 3 shows in the table fields in the right-hand part of the table the maximum Hamming distance t which would have to be selected in order to achieve a given overlap (uncertainty s).
  • C ball packing barrier
  • Table 3 is read as follows:
  • the second column shows the number
  • the third column shows the filling level f (Fill%) and thus the defined handsies as a relative size in relation to the total number of possible block codes (the formula returns values in the range 0..1, the table shows the corresponding percentage values):
  • the degree of filling f is thus the ratio between the possible phones in the code space to the actually defined phones. For example, with a bit length n of 8 bits and 25 defined phones, the fill level f is about 10%.
  • a sphere Kt indicates the amount of block codes C possible for a handle with the selected Hamming distance t. If the sum of the power of all Kt for all defined handsies exceeds the code range (2 n ) by the sf ache, this is a sufficient condition for at least s overlaps for each defined handle, ie
  • n, c result from the line (as indicated in columns 1 and 2), the parameter s results from the respective column (see header).
  • the values in the table (cells) are the minimum Hamming distance t determined by the above formula.
  • bit length 8 section is for informational purposes only, but has no practical meaning.
  • the generation algorithm can ensure that that there is a sufficient ambiguity for almost all phones by new phones as long as possible from the balls Kt existing handies are selected.
  • the proof of the protection of the identity ID is trivial, it is given by the fact that never the identity itself, but only the hash value is transferred. An attacker would have to reverse the hash function to determine the actual identity. Given a suitable hash function, we assume that this is not possible efficiently. In addition, a successful attack on the hash function would only compromise a single ID, but the system itself would remain secure.
  • the method according to the invention protects against tracking as follows:
  • the hash value is protected with a random "salt.” This means that for each query, a new random value “salt” is formed and placed in the hash.
  • a tracking attack can also be done via the handle.
  • the handle is transferred as fuzzy ID. That means the handles will also be different in the data of different queries.
  • the attacker can calculate the Hamming distance of two different fuzzy handles. However, the attacker can only be sure that two mobiles belong to different identities (because the Hamming distance is too large).
  • Two mobile phones x, ye A n which are close to each other (small Hamming distance d (x, y)), can always belong to different identities.
  • the Hamming distance should be chosen so that always Overlaps are possible, but the server can easily dissolve because of the knowledge of the assigned Handies.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

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. Verschieiern 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-Handies 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

Identifizieren eines Identitätsträgers Gebiet der Erfindung
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 £ An 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:
Kt{ ) = 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 An. 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 : Kt{x) n Kt(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:
st(x = {c e c : Kt{c) n Kt(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:
st = min|5t(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 (2n) 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 An, 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.

Claims

P a t e n t a n s p r ü c h e
1. 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- Handies, die gemäß der Fuzzy-Suche zum Berechnen der Fuzzy-ID verwen- det 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.
2. Verfahren nach Anspruch 1, wobei der Salt eine durch den Identifikator erzeugte Zufallszahl umfasst.
3. Verfahren nach Anspruch 1 oder 2, wobei der Salt eine durch den Interro- gator erzeugte Nonce, insbesondere eine Zufallszahl, umfasst, die vor Berechnen des Hashwerts durch den Interrogator an den Identitätsträger (TAG) gesendet wird.
4. 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-Handies festgelegt wird.
5. Verfahren nach Anspruch 4, wobei die Mindestzahl von Kandidaten- Handies im Bereich von zehn bis mehrere tausend liegt, weiter vorzugsweise im Bereich 10 bis 10000, weiter vorzugsweise im Bereich von 50 bis 500.
EP17719806.6A 2016-04-12 2017-04-11 Identifizieren eines identitätsträgers Withdrawn EP3443769A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102016004426.8A DE102016004426A1 (de) 2016-04-12 2016-04-12 Identifizieren eines Identitätsträgers
PCT/EP2017/000474 WO2017178114A1 (de) 2016-04-12 2017-04-11 Identifizieren eines identitätsträgers

Publications (1)

Publication Number Publication Date
EP3443769A1 true EP3443769A1 (de) 2019-02-20

Family

ID=58638821

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17719806.6A Withdrawn EP3443769A1 (de) 2016-04-12 2017-04-11 Identifizieren eines identitätsträgers

Country Status (3)

Country Link
EP (1) EP3443769A1 (de)
DE (1) DE102016004426A1 (de)
WO (1) WO2017178114A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113836569B (zh) * 2020-06-08 2024-08-02 中国移动通信有限公司研究院 数据查询方法及相关设备
US11755373B2 (en) 2020-10-07 2023-09-12 Oracle International Corporation Computation and storage of object identity hash values

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090267747A1 (en) * 2003-03-31 2009-10-29 Rivest Ronald L Security and Data Collision Systems and Related Techniques for Use With Radio Frequency Identification Systems
US20070133807A1 (en) * 2005-12-12 2007-06-14 Electronics And Telecommunications Research Institute Tag authentication apparatus and method for radio frequency identification system
US7809747B2 (en) * 2006-10-23 2010-10-05 Donald Martin Monro Fuzzy database matching
US8368517B2 (en) * 2008-08-22 2013-02-05 Hong Kong R&D Centre for Logistics and Supply Chain Management Enabling Technologies Limited RFID privacy-preserving authentication system and method
US8359480B2 (en) * 2008-12-19 2013-01-22 University Of Washington Scalable RFID systems: a privacy preserving protocol with constant-time identification

Also Published As

Publication number Publication date
DE102016004426A1 (de) 2017-10-12
WO2017178114A1 (de) 2017-10-19
WO2017178114A9 (de) 2017-12-07

Similar Documents

Publication Publication Date Title
DE102007016467B3 (de) Transponder mit Zugriffsschutz und Verfahren zum Zugriff auf den Transponder
DE102006030767B4 (de) Verfahren, Transponder und System zum sicheren Datenaustausch
EP1742166B1 (de) Verfahren zur Zugriffssteuerung auf einen Transponder
EP1630757B1 (de) Verfahren und System, um verlorene oder gestohlene Gegenstände zu finden
DE102006032129A1 (de) Skalierbares Verfahren zur Zugriffssteuerung
DE102013224104A1 (de) Chip mit selbstechtheitsnachweis
DE202015009157U1 (de) Systeme zur Erzeugung und Verwendung von flüchtigen Kennungen und Message Intergrity Codes
DE112011100182T5 (de) Transaktionsprüfung für Datensicherheitsvorrichtungen
WO2017178114A1 (de) Identifizieren eines identitätsträgers
EP1735760B1 (de) Datenschutzgerechtes radio frequency identification (rfid)-system durch besitzerkontrollierte rfid-tag funktionalität
EP4381684A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
DE112015002032B4 (de) Vorrichtung und Verfahren zur Verteilung von Regeleigentum unter Vorrichtungen in einem System
DE112018003823T5 (de) Verfahren und vorrichtung zur schätzung einer etikett-lage mittels radiofrequenzidentifizierung (rfid)
EP2590357A1 (de) Verfahren und System zur Identifizierung eines RFID-Tags durch ein Lesegerät
DE102011054637A1 (de) Verfahren zum Konfigurieren eines elektromechanischen Schlosses
DE112021005552T5 (de) Mehrfaktorauthentifizierung von einheiten des internets der dinge
EP2127294B1 (de) Authentisierung portabler Datenträger
EP1571591B1 (de) Verwendung eines RFID-Tags um mit einem Mobilgerät auf eine Hypertext-Seite zuzugreifen
WO2017032452A1 (de) Transaktionssystem
WO2008095664A2 (de) Verfahren zum wenigstens temporären freischalten einer bidirektionalen kommunikation und transponder
EP3348040B1 (de) Verfahren zur erstellung einer datenbank mit einem mobilgerät und einem identifikationsparameter
EP3234853A1 (de) Verfahren und vorrichtung zum sicheren speichern von daten und zum zugreifen auf diese daten
DE102008046812A1 (de) Verfahren zur Kennzeichnung mehrerer Bauteile, Gruppe von Bauteilen, Behälter zur Durchführung des Verfahrens und Wälzlager mit einem Transponder und einer Speichereinrichtung
DE102016107673A1 (de) Verfahren zur Nutzung eines Proxy-Servers für den Datenaustausch
DE102013014187A1 (de) Verfahren und Vorrichtung zur Übertragung einer Information

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20181112

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20191111

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20200414

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 12/02 20090101ALI20200330BHEP

Ipc: H04W 12/00 20090101AFI20200330BHEP

Ipc: H04W 12/06 20090101ALI20200330BHEP

Ipc: H04L 29/06 20060101ALI20200330BHEP

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200825