Gerade hat sich im Chat von @nbildhauer die Frage gestellt, ob es eigentlich gute AirTag-Alternativen gibt, die nicht komplett proprietär sind und so. Daraufhin wurde dann etwas herum gechattet und dann wollten viele wissen, wie das eigentlich funktionert. Vielleicht planen wir hierzu mal einen Experimentier-Tag oder ähnliches, um uns das mal anzuschauen. Was denkt ihr?
2 „Gefällt mir“
Klingt ganz interessant, ein weiteres Ziel wäre z.b. den „Tracker“ möglichst kompakt zubauen, und energiesparend. Würde gerne mitmachen.
Ich hab so einen SmartTag auch an meinem Roller und der wurde mir gestern geklaut. Dann hab ich das heute Nachmittag nach der Schule bemerkt und bin da mal mit dem @nik hingefahren. Dann hab ich da in dem SmartThings-App auf “In der Nähe suchen” geklickt und wir sind herum gelaufen. Irgendwann hat dann mein Handy den Tag erkannt, aber er war noch zu weit weg um die Verbindung zu bekommen, also haben wir mit Triangulation herausgefunden, in welchem Haus sich der Roller befindet und daraufhin die Polizei gerufen.
1 „Gefällt mir“
Wie funktionieren SAMSUNG SmartTags?
@pinguin und ich haben heute Nachmittag reverse-engineered, wie SAMSUNG SmartTags funktionieren. Dabei haben wir sowohl ein SmartTag untersucht, als auch generelle Überlegungen angestellt, wie ein Offline-Finding-Netzwerk funktioniert.
Tatsächlich haben wir zuerst unser eigenes Offline-Finding-System gestaltet und überlegt, wie wir das bauen würden, und danach herausgefunden, dass die SmartTags im Wesentlichen genau so funktionieren (nur mit ein paar kleineren Schwächen, die unser neues System von vornherein nicht haben wird) ;).
Was ist ein Offline-Finding-Netzwerk?
Ein Offline-Finding-Netzwerk ist ein System, mit dem sich Dinge, die selber keine Verbindung zum Internet haben, wiederfinden lassen. Das ist auch die wichtigste Eigenschaft der SmartTags und auch der Apple AirTags: Diese Tags reden selber nie aktiv mit irgendeinem Server.
Damit das gut funktioniert, benötigt das Netzwerk so genannter Helper Devices, also Helfer-Geräte, die die Kommunikation zwischen den Tags und einem Server übernehmen
Herausforderungen
Die folgenden Herausforderungen haben wir für so ein System identifiziert:
- Ein Tag muss einem Besitzer eindeutig zuzuordnen sein
- Die Zuordnung darf nur für den Besitzer möglich sein
- Ein Beobachter, z.B. jemand, der versucht, ein Tag zu verfolgen, darf es nicht über längere Zeit identifizieren können
- Das Tag muss oft mit einem Helper Device kommunizieren können
- Das Tag muss sehr wenig Energie benötigen, damit es mit einer kleinen Energiequelle lange hält
Wie das bei SAMSUNG SmartTags funktioniert
Die SmartTags
Die SmartTags sind kleine BLE-Geräte (Bluetooth Low Energy). Im normalen Betrieb, d.h. wenn man sie schon registriert hat, senden sie einfach dauerhaft ein so genanntes LE Meta Advertisement. Dieses Advertisement ist ein kleines Datenpaket, das, codiert, folgende Informationen enthält (leicht vereinfachte Erklärung):
- Eine Kennung, die das Gerät als SAMSUNG SmartTag ausweist
- Die aktuelle Uhrzeit, gerundet auf eine Viertelstunde
- Den Zustand des Tags (Akkustand und ob es gerade mit dem Handy seines Besitzers verbunden ist)
- Eine von 1000 verschiedenen IDs, die alle diesem Tag zugeordnet sind
- Eine Signatur mit einem Schlüssel von SAMSUNG
So sieht ein solches Advertisement aus, wenn man es mit btmon mitliest
Bluetooth HCI Event - LE Meta
Event Code: LE Meta (0x3e)
Parameter Total Length: 57
Sub Event: LE Extended Advertising Report (0x0d)
Num Reports: 1
Event Type: 0x0013, Connectable, Scannable, Legacy, Data Status: Complete
.... .... .... ...1 = Connectable: True
.... .... .... ..1. = Scannable: True
.... .... .... .0.. = Directed: False
.... .... .... 0... = Scan Response: False
.... .... ...1 .... = Legacy: True
.... .... .00. .... = Data Status: Complete (0x0)
0000 0000 0... .... = Reserved: 0x000
Peer Address Type: Random Device Address (0x01)
BD_ADDR: 5a:45:72:46:d8:2d (5a:45:72:46:d8:2d)
Primary PHY: LE 1M (0x01)
Secondary PHY: No packets on the secondary advertising channel (0x00)
Advertising SID: 0xff (not available)
TX Power: 127 dBm (not available)
RSSI: -73 dBm
Periodic Advertising Interval: 0x0000 (no periodic advertising)
Direct Address Type: Public Device Address (0x00)
Direct BD_ADDR: 00:00:00_00:00:00 (00:00:00:00:00:00)
Data Length: 31
Advertising Data
Flags
Length: 2
Type: Flags (0x01)
000. .... = Reserved: 0x0
...0 .... = Simultaneous LE and BR/EDR to Same Device Capable (Host): false (0x0)
.... 0... = Simultaneous LE and BR/EDR to Same Device Capable (Controller): false (0x0)
.... .1.. = BR/EDR Not Supported: true (0x1)
.... ..0. = LE General Discoverable Mode: false (0x0)
.... ...0 = LE Limited Discoverable Mode: false (0x0)
16-bit Service Class UUIDs (incomplete)
Length: 3
Type: 16-bit Service Class UUIDs (incomplete) (0x02)
UUID 16: Samsung Electronics Co., Ltd. (0xfd5a)
Service Data - 16 bit UUID
Length: 23
Type: Service Data - 16 bit UUID (0x16)
UUID 16: Samsung Electronics Co., Ltd. (0xfd5a)
Service Data: 15b5c6017cfc736d9fee56adb20000008b95225e
Hier ein paar Erläuterungen zum Inhalt:
- Die Uhrzeit ist wichtig, da sich dadurch die Signatur alle 15 Minuten ändert. So kann es keine so genannten Replay-Attacken geben, d.h. jemand liest ein Advertisement mit und nutzt es dann später, um eine Fake-Position ins Netzwerk zu senden
- Der Status, ob das Tag gerade mit dem Besitzer-Handy verbunden ist, ist wichtig, da man sich so davor schützen kann, Tags untergeschoben zu bekommen – das funktioniert so, dass das Handy beobachtet, ob ein Tag längere Zeit in der Nähe ist, aber eben nicht mit dem Handy des Besitzers verbunden. So weiß man dann, dass ein Tag ohne seinen Besitzer in der Nähe ist
- Jedes Tag hat 1000 verschiedene IDs, von denen es sich alle 15 Minuten eine neue aussucht. Wenn alle 1000 durch sind, fängt es vorne wieder an. Das heißt, nach 10 Tagen und 10 Stunden kann man theoretisch ein einmal gesehenes Tag wiederfinden, auch, wenn man nicht der Besitzer ist.
- Nochmal ganz wichtig: Das Tag selber kennt seinen Aufenthaltsort nicht!
Die IDs des Tags und die Uhrzeit bekommt es bei der Registrierung mit Hilfe des SmartThings-Apps vom SAMSUNG-Server. Diesen Prozess klammern wir hier jetzt erstmal aus.
Die Helper-Devices
Jedes SAMSUNG-Gerät, das die SmartThings-App hat, wird zum Teil des Netzwerks. Vermutlich sind das alle SAMSUNG-Handys mit Original-Firmware, aber z.B. auch SAMSUNG Smart-TVs.
Diese Geräte scannen dauerhaft nach den Advertisements von SmartTags. Wird ein Advertisement empfangen, wird es, zusammen mit dem Standort des Handys, an einen SAMSUNG-Servers geschickt.
Erst an dieser Stelle wird die Position bekannt – SAMSUNG erfährt, dass ein Handy das Tag gesehen hat, und wo es dieses gesehen hat. Außerdem werden noch einige Informationen über die Signalstärke zum Tag mitgesendet. Das hilft, den Standort genauer zu bestimmen, falls mehrere Helper Devices es gleichzeitig gesehen haben (Trilateration).
Nahbereichs-Ortung
Ist man mit seinem Handy in der Nähe eines eigenen SmartTags, so dass es im BLE-Empfangsbereich ist, kann man selber orten oder zumindet die ungefähre Entfernung bestimmen. Hierzu wird wieder die Signalstärke herangezogen.
Zentraler Server
Das zentrale Backend von SAMSUNG sammelt die von den Helper-Devices gemeldeten Advertisements, zusammen mit den Geo-Positionen der Helper Devices.
Wenn man als Besitzer ein Tag registriert, dann handeln die SAMSUNG-Server mittels des SmartThings-Apps auf dem Handy einen kryptografischen Schlüssel mit dem Tag aus. Mit Hilfe dieses Schlüssels werden die 1000 IDs generiert, und man kann später die gemeldeten Advertisements vom Server abfragen.
Schwachstellen des SAMSUNG-Systems
SAMSUNG hat im Wesentlichen ein solides System umgesetzt. Zumindest ist es für Fremde kaum möglich, Rückschlüsse auf den Besitzer eines Tags zu erhalten oder anderen Schaden zu verursachen. Weiteres dazu gibt es in einem Paper Privacy Analysis of Samsung’s Crowd-Sourced Bluetooth Location Tracking System.
Die hauptsächliche Schwachstelle ist, dass SAMSUNG eine uneingeschränkte Vertrauensstellung hat. Durch die Art und Weise, wie die IDs der Tags generiert werden und wie die Registrierung funktioniert, sind alle Tags serverseitig dem SAMSUNG-Konto des Besitzers zugeordnet. SAMSUNG-Mitarbeiter mit entsprechendem Zugriff sowie Angreifer, die möglicherweise die Datenbanken von SAMSUNG angreifen, können also die Positionen aller Tags aller SAMSUNG-Kunden abgreifen.
1 „Gefällt mir“
Apple AirTags
Apple AirTags funktionieren grundlegend nach dem gleichen Prinzip, allerdings mit einer signifikanten Verbesserung, und einer signifikanten Schwachstelle.
Ende-zu-Ende-Verschlüsselung
Die Meldung von Advertisements an Apple-Server funktioniert grundlegend anders. Bei der Registrierung eines Tags wird ein asymmetrisches Schlüsselpaar erzeugt (Public Key und Private Key). Der Public Key wird auf das Tag übertragen, der Private Key bleibt auf dem iPhone oder Mac des Beistzers.
Das Tag sendet im Advertisement nun ständig seinen Public Key. Sobald ein Apple-Gerät (Helper Device) ein Advertisement empfängt, benutzt es den Public Key des Tags, um damit seine eigene Position zu verschlüsseln und an die Apple-Server zu senden.
Alle, die eine Apple-ID haben, können alle Informationen aller gesehen Tags von den Apple-Servern herunterladen. Doch die Informationen daraus kann man nur entschlüsseln, wenn man der Besitzer des Tags ist und deshalb den Private Key hat.
Apple hat also selber keine Möglichkeit, selber an die Daten zu kommen und weiß nicht, wo die Tags sind und wem sie gehóren.
Statisches Advertisement
Daraus ergibt sich jedoch ein Nachteil: Die AirTags senden dauerhaft immer dasselbe Advertisement (zur Erinnerung: Bei den SAMSUNG SmartTags ändert sich das Advertisement alle 15 Minuten). Dadurch ist es möglich, ein einmal gesehenes AirTag zu verfolgen und immer wieder zu erkennen.
Ob Apple dagegen Maßnahmen ergriffen hat, weiß ich noch nicht.
Mehr Informationen zu AirTags und dem FindMy-Netzwerk von Apple gibt es bei OpenHaystack, einer Open-Source-Firmware und -App, mit der man das Apple-FindMy-Netzwerk mit eigenen Tags benutzen kann.
Um selber solche Tags zu beobachten, kann man auf einem Linux-System wie folgt vorgehen:
- Bluetooth-Monitor zum Schreiben in eine Datei starten:
sudo btmon -w bt.cap
Damit werden ab sofort alle Bluetooth-Frames, die der eigene Bluetooth-Adapter sieht, in die Dateibt.cap geloggt - Einen Scan nach Bluetooth-Low-Energy-Geräten starten:
$ bluetoothctl
menu scan
transport le
back
scan on
- Das nun eine Weile laufen lassen. Entweder in der Ausgabe des Scans, oder z.B. mit dem Android-App AirGuard nebenbei die MAC-Adresse des Tags, da man beobachten will, herausfinden
- Wenn man genug gesammelt hat, bluetoothctl und btmon beenden (Strg-C / Strg-D).
- Die Datei
bt.capmit Wireshark öffnen. Dann kann man mit dem Filterbthci_evt.bd_addr == 5a:45:72:46:d8:2dnach der MAC-Adresse des Tags suchen und sich die LE-Advertisements ansehen.
Ich hätte eine Idee für die SpotNuts:
- Der erste Schritt wäre das Koppeln mit dem Handy, wenn das SpotNut in der Nähe ist. Dafür könnte man z.B. einen Knopf am ESP anbringen. Dabei generiert der ESP eine zufällige, lange Nummer bzw Zeichenfolge, die ID, die anschließend mit dem Handy getauscht und gespeichert wird. In evtl einer App dafür kann man dem dann einen Namen geben, z.B “Fahrrad”.
- Nun wartet der ESP auf ein “Suchen”-Signal, am besten über LoRaWan. Das bedeutet, dass man explizit in der App “suchen” klicken muss. Dabei witd dann die ID, die beim Koppeln festgelegt wurde, mitgeschickt. Das wird dann per LoRaWan gesendet, und der ESP erhält es im besten Fall dann auch.
- Nun schickt der ESP - auch über LoRaWan seine Position zurück, oder besser gesagt die LoRaWan oder Wlan-APs in der Nähe. So kann man mit dem Handy in die Nähe kommen.
- Wenn man nah genug ist, schickt man vom Handy aus ein Signal an den SpotNut zur genauen Ortung. Der ESP schaltet jetzt z.B. BT ein und kann somit genau(er) geortet werden.
Könnte das funktionieren? Ein Vorteil daran wäre, dass kein Server benötigt wird und es somit dezentral ist. Außerdem würde es nicht immer eim Signal senden, sondern nur im “Notfall” und somit viel Strom sparen.
Naja, ansich finde ich ich die Idee garnicht so schlecht.
Aber:
- Das mit dem “Suchen”-Signal würde das Offline-Finding-Netzwerk überflüssig machen. Klar, wenn man Dinge nur im eigenen Umkreis verliert geht das, aber sonst nicht
- Bei TTN (LoRaWan-Provider) kann man pro Tag halt nur 30s Uptime haben, das würde damit halt vermutlich kollidieren.
- Handys haben ja kein LoRaWan
c’t deckt auf: Keylogger nutzt Apples Ortungsnetz “Wo ist?”
Mein aktueller Entwurf unseres Servers ist dagegen immun, da wir das Abrufen von Nachrichten für einen Public Key nur erlauben, wenn der Client eine Signatur mit dem passenden Private Key mitliefert. Man kann also keine Keys forgen.
Themen-Pate