Ein BLE-Tag ist nur so vertrauenswürdig, wie du beweisen kannst, dass es echt ist. Wenn irgendein billiges Board mit derselben MAC und Payload antwortet, bricht dein Asset-Tracking, Zutritt oder Payment zusammen. Dieser Artikel zeigt, wie ein BLE-Tag Klonen und Spoofing widersteht: Challenge-Response, PUF-Schlüssel, rotierende Identitäten und Attestation.

Warum Klonen funktioniert

Ein BLE-Tag sendet eine Identität. Ein Nachmacher, der dieselbe Werbung abspielt oder mit demselben statischen Schlüssel antwortet, ist für einen naiven Leser nicht unterscheidbar. Die Verteidigung ist kryptografisch: das Tag muss Besitz eines Geheimnisses beweisen, das es nicht preisgeben kann.

Challenge-Response mit ECDH

Ein Leser gibt einen Zufalls-Nonce aus und das BLE-Tag muss eine Signatur darüber zurückgeben:

resp = Sign(sk, nonce || reader_id)

Der private Schlüssel sk verlässt niemals das Secure Element. Ein Klon ohne sk kann kein gültiges resp erzeugen und wird abgewiesen. Nutze ECDSA P-256 oder Ed25519; kombiniere es mit ECDH, damit der Sitzungsschlüssel ephemer und forward-secret ist.

PUF: ein Schlüssel, den man nicht lesen oder kopieren kann

Eine physically unclonable function leitet einen eindeutigen Schlüssel aus Silizium-Variationen ab. Der PUF-Schlüssel des BLE-Tags liegt nie im Flash, also liefert selbst ein Dump des Chips nichts. Jedes Gerät bekommt einen anderen Schlüssel ohne enroll-Datenbank zum Brechen.

Rotierende Identitäten und Anti-Replay

Statische Advertisements werden trivial aufgezeichnet und abgespielt. Rotiere die beworbene rotierende ID in kurzem Intervall:

ID_i = Truncate(HMAC(k, T_i), n)

wobei T_i ein Zeitfenster ist. Ein Leser validiert gegen das aktuelle und vorige Fenster. Ein abgefangenes Advertisement ist Minuten später wertlos. Kombiniere es mit einem monoton steigenden Zähler, um Replay zu töten.

Attestation und Flottenvertrauen

Für eine verwaltete Flotte sollte das BLE-Tag Firmware und Identität attestieren. Ein signierter Attestation-Blob, geprüft gegen eine im Leser eingebrannte Root, beweist, dass die Einheit unmanipulierte Firmware läuft — blockiert sowohl Klone als auch gerootete Geräte.

Reichweiten- und Relay-Angriffe

Krypto stoppt kein Relay: ein Angreifer verlängert die Reichweite mit zwei Proxys, sodass ein Tag „neben“ dem Leser erscheint. Mildern mit Distance-Bounding (Round-Trip-Zeit-Checks) und Bindung der Transaktion an ein kurzes physisches Nähe-Fenster.

Praktische Checkliste

  • Schlüssel im Secure Element oder PUF, nie im Klartext-Flash.
  • Challenge-Response nutzen, nie statische Shared Secrets.
  • Beworbene IDs kurz rotieren mit Anti-Replay-Zählern.
  • Firmware gegen eingewurzelte Trust-Chain attestieren.
  • Distance-Bounding wo Relay eine reale Drohe ist.

Ein gut verteidigtes BLE-Tag macht Klonen wirtschaftlich sinnlos: der Angreifer braucht das Silizium, nicht nur die Bytes.