Suchen

Wie lassen sich RAIN-RFID-Tags für Retail-Anwendungen sichern?

Mechanismen für Sicherheit und Datenschutz

30. Juni7 Min. Lesezeit
Danny HaakDanny Haak
Artikel

Wenn RAIN-RFID-Tags eingesetzt werden, um Prozesse zu verbessern, soll nicht plötzlich eine große Anzahl von Tags nicht mehr funktionieren. Dieses Szenario ist nicht undenkbar, wenn die Tags nicht richtig geschützt wurden. Da Schutzmechanismen standardmäßig nicht aktiviert sind, kann jeder mit einem RFID-Reader den Inhalt dieser Tags verändern oder sie sogar deaktivieren.

Das Risiko dafür ist natürlich relativ gering, die Auswirkungen wären jedoch gravierend. Der Wareneingang im Distributionszentrum würde aufgrund vieler „fehlender Artikel“ scheitern, Bestandszählungen im Store wären ungenau und der Checkout-Prozess würde sich verlangsamen, weil auf Barcodes zurückgegriffen werden müsste. Dies zu verhindern ist daher äußerst wichtig. Die RFID-Standards (GS1 EPC Gen2v2) bieten dafür entsprechende Möglichkeiten. Es gibt verschiedene Mechanismen, um Änderungen an programmierten RFID-Tags zu verhindern.

Es vollständig unmöglich zu machen, etwas an RFID-Tags zu ändern, steht jedoch im direkten Konflikt mit wichtigen Datenschutzfunktionen für Verbraucher: Die Möglichkeit, einen Tag zu deaktivieren, oder subtiler: die Lesereichweite zu reduzieren oder die eindeutige Nummer in einem Tag auszublenden, sind entscheidende Funktionen. Deshalb braucht es eine gute Balance zwischen Sicherheit und Datenschutz.

Dieser Blog erläutert die Sicherheits- und Datenschutzfunktionen von RAIN RFID sowie Best Practices für deren Einsatz.

Mechanismen für Sicherheit: Sperren und Passwörter

Es gibt zwei eng miteinander verbundene Mechanismen zur Sicherung von Tags:

  1. Passwörter: Für bestimmte Aktionen wird ein Passwort benötigt
  2. Sperren: Definiert, was mit und ohne Passwort möglich ist

RAIN-RFID-Tags haben zwei Passwörter:

  1. Access-Passwort: wird verwendet, um das Lesen und Schreiben bestimmter Speicherbereiche im Chip zu ermöglichen oder zu verhindern
  2. Kill-Passwort: wird verwendet, um das Deaktivieren des Chips zu ermöglichen oder zu verhindern

Nicht alle Chips verfügen über Passwörter, da dies laut Standard nicht verpflichtend ist. Ein Beispiel: Der Impinj Monza R6 hat weder Access- noch Kill-Passwort. Das bedeutet, dass der Chip nicht deaktiviert und nicht per Passwort gegen Schreiben geschützt werden kann. Der Monza R6-P und R6-A verfügen hingegen über Kill- und Access-Passwörter. Der Lock-Befehl ist im Standard verpflichtend.

Mit dem „Lock“-Befehl lässt sich das Verhalten des Chips in Bezug auf Passwörter definieren. Passwörter lediglich zu schreiben, bewirkt noch nichts. Sie müssen durch das „Sperren“ von Tags aktiviert werden.

Bei Verwendung des Lock-Befehls gibt es vier mögliche Konfigurationen:

  1. Der Speicher kann geschrieben werden, auch ohne Access-Passwort
  2. Der Speicher kann geschrieben werden, wenn das Access-Passwort angegeben wird
  3. Der Speicher kann nie wieder beschrieben werden, auch nicht mit Access-Passwort
  4. Der Speicher kann immer geschrieben werden, und diese Einstellung kann nie wieder geändert oder mit einem Passwort geschützt werden

Die Konfiguration kann für jeden Speicherbereich definiert werden: EPC-Speicher, in dem Produktinformationen und Seriennummer gespeichert sind, Kill-Passwort, Access-Passwort usw. Wenn das Passwort schreibgeschützt ist, ist es natürlich auch lesegeschützt. Andernfalls könnte jeder das Passwort leicht abrufen. Der EPC-Speicher kann nicht mit Passwörtern und Sperren gegen Lesen geschützt werden.

Wenn das Passwort nur aus Nullen besteht, kann der Tag nicht deaktiviert werden. Daher muss zuerst ein Kill-Passwort geschrieben werden, das nicht nur aus Nullen besteht, bevor es zum Deaktivieren eines Tags verwendet werden kann.

Das Schreiben der Lock-Konfiguration und der Passwörter erfolgt typischerweise beim Codieren der Tags.

Mechanismen für Datenschutz: Lesereichweite reduzieren und Teile des EPC ausblenden

Die grundlegendste Datenschutzfunktion von RFID-Tags ist der „Kill“-Befehl. Wird dieser Befehl ausgeführt, funktioniert der Tag nie wieder. Für den Verbraucherdatenschutz ist das ideal, erschwert jedoch Prozesse wie automatisiertes Retourenmanagement und würde erfordern, nach einer Rückgabe einen neuen Tag am Produkt anzubringen.

Um dies zu vermeiden, wurden zwei anspruchsvollere Datenschutzmechanismen eingeführt:

  1. Reduzierung der Lesereichweite: dynamische Anpassung der Lesereichweite auf nur wenige Zentimeter statt mehrere Meter
  2. Ausblenden des datenschutzsensiblen Teils des EPC: Produktkennung und/oder Seriennummer werden unlesbar gemacht

Beide Mechanismen sind durch das Access-Passwort geschützt.

Diese Datenschutzfunktionen sind derzeit nur auf den NXP UCODE 8/8m Chips verfügbar. Es wird jedoch erwartet, dass andere Chiphersteller bald folgen.

Aus Sicherheitsgründen wäre es zwar ausreichend, alle Änderungen am Chip zu verhindern, indem alle Speicherbereiche und Passwörter dauerhaft gesperrt werden. Dadurch würden jedoch auch alle Datenschutzfunktionen dauerhaft deaktiviert, was eindeutig unerwünscht ist. Passwörter sind daher der richtige Weg.

Passwörter verwalten

Die Herausforderung besteht natürlich darin, Passwörter zu verwalten. Der naheliegendste Ansatz wäre, ein einziges Passwort zu verwenden, das für alle Tags in einer Organisation gleich ist. Sobald dieses Passwort jedoch bekannt wird, sind alle Tags angreifbar.

Selbst wenn das Passwort nicht bekannt wird, lässt es sich durch Brute Force ermitteln, also durch das Ausprobieren aller Passwörter. Wenn man annimmt, dass ein einzelner Reader etwa 5 Millisekunden benötigt, um ein Passwort zu testen, und es 2 hoch 32, also 4.294.967.296 Möglichkeiten gibt, lässt sich berechnen, dass man maximal 248 Tage benötigt, um das Passwort zu „erraten“. Im Durchschnitt wären es 124 Tage. Da Tags sehr günstig und leicht verfügbar sind, können mehrere Reader parallel eingesetzt werden, um Passwörter zu ermitteln. Mit etwas Aufwand kann ein Passwort innerhalb weniger Tage herausgefunden werden.

Um die Sicherheit deutlich zu erhöhen, braucht es eine Lösung, bei der jedes einzelne Tag ein anderes Passwort hat. Wird ein Passwort kompromittiert, hat dies keine Auswirkungen auf andere Tags. Einfach für jedes Tag ein eigenes Passwort zu vergeben und in einer Datenbank zu speichern, wäre jedoch nicht sehr skalierbar: Jedes Mal, wenn ein Tag deaktiviert oder eine Datenschutzfunktion aktiviert werden soll, wäre eine Client-Server-Kommunikation erforderlich.

Glücklicherweise wurde dieses Problem in ähnlichen Situationen bereits vielfach gelöst. Mit einer kryptografischen Einweg-Hashfunktion lässt sich ein Passwort auf Basis des EPC-Werts und eines Geheimnisses berechnen, also eines weiteren Passworts, das pro Marke eindeutig ist. Eine Einweg-Hashfunktion funktioniert so:

  1. Wenn EPC und Geheimnis bekannt sind, kann das Passwort berechnet werden.
  2. Wenn Passwort und EPC bekannt sind, kann das Geheimnis nicht berechnet werden.

Das bedeutet: Selbst wenn ein oder mehrere Passwörter per Brute Force ermittelt werden, lassen sich daraus nicht die Passwörter anderer Tags ableiten. Außerdem wird pro Marke nur ein Geheimnis benötigt, das sicher verteilt werden kann. Eine Passwortdatenbank ist nicht erforderlich. Das ist ein sehr skalierbarer, sicherer und zuverlässiger Mechanismus.

Skalierung der Lösung für Multi-Brand-Retailer

Für einen Retailer mit nur einer Marke funktioniert diese Lösung gut. Für Multi-Brand-Retailer, die Produkte unterschiedlicher Herkunft verkaufen, wird es schwieriger. Sie können Marken keine eigene Passwortmanagement-Strategie aufzwingen, da dies in der Supply Chain nicht umsetzbar wäre.

Wir schlagen vor, dass jede Marke das Passwortmanagement wie oben beschrieben implementiert und die Sicherheitsschlüssel an die Retailer verteilt, die ihre Produkte verkaufen. Jede Serie von GS1 Company Prefixes hätte ihr eigenes Geheimnis. Wenn ein Retailer eine Datenschutzfunktion für einen EPC aktivieren möchte, ermittelt er den Company Prefix dieses EPC und nutzt ihn, um das richtige Geheimnis zu erhalten. Damit kann das erforderliche Passwort generiert werden.

Diese Lösung kombiniert die Vorteile eindeutiger Passwörter pro Tag und bleibt zugleich für Marken und Retailer einfach umzusetzen.

Das offensichtliche Risiko dieser Lösung liegt im Management der Markenschlüssel: Wenn ein Retailer versehentlich den Schlüssel einer oder mehrerer Marken offenlegt, entstehen dennoch Probleme. Für die Schlüsselverteilung gibt es Best Practices der Branche, die eingehalten werden sollten.

Wenn eine Marke das Geheimnis nicht an Retailer weitergeben möchte, kann sie alternativ einen API-Service anbieten, bei dem ein Retailer einen EPC übermittelt und im Gegenzug ein Passwort erhält. Das erfordert natürlich Konnektivität, ist aber die sicherste Arbeitsweise.

Fazit: Standardisierung ist notwendig

Zusammengefasst ist es mit einer passenden Konfiguration der Lock-Parameter auf dem Chip und durch das Setzen von Passwörtern möglich, RFID-Chips skalierbar gegen unbefugte Änderungen zu sichern und gleichzeitig Verbraucherdatenschutz zu ermöglichen. All dies ist selbstverständlich standardmäßig in Nedap iD Cloud integriert.

Da diese Lösung nur funktioniert, wenn alle diese Methoden nutzen, empfehlen wir der Branche dringend, diesen Ansatz zu standardisieren. So können alle Retailer und Verbraucher von einer sicheren und datenschutzbewussten Einführung von RAIN RFID profitieren.

Nedap begleitet Ihren Weg

Bei Nedap unterstützen wir globale Retailer dabei, RFID erfolgreich einzuführen und zu skalieren: mit Bestandsgenauigkeit in Echtzeit, besserer Warenverfügbarkeit über alle Kanäle hinweg und intelligenteren Prozessen. So helfen wir Marken, ihre Abläufe weiterzuentwickeln, unabhängig davon, wo sie auf ihrer Reise stehen.

Ähnliche Inhalte

Woolworths wählt Nedap für groß angelegten RFID-Rollout

30. Juni

Inventory Engine

30. Juni

Nedap stellt den i15 Go vor: kompakte Größe, nahtlose Sicherheit

Inventory Engine

Nedap stellt energiesparenden Sleep Mode für EAS-Systeme vor

30. Juni

Inventory Engine

Glossar RFID im Fashion Retail

30. Juni

Loss Prevention
Inventory Engine

30. Juni

Nedap unterstützt HEMAs groß angelegten RFID-Rollout

Inventory Engine

Tillys stärkt mit Nedap seine Omnichannel-Strategie

30. Juni

Inventory Engine