Forscher des Georgia Institute of Technology berichten über mehrere Schwachstellen im Datenschutz von Tile‑Bluetooth‑Trackern. Die Analyse zeigt: Die Geräte senden identifizierende Informationen in Klarform, nutzen statische MAC‑Adressen und erlauben serverseitige Standortkorrelation ohne Ende‑zu‑Ende‑Verschlüsselung (E2EE). Das senkt die Hürden für Deanonymisierung und die Nachverfolgung von Bewegungsprofilen.
Technische Befunde: BLE‑Broadcasts, Identifikatoren und Servertelemetrie
Die Forscher dekompilierten die Android‑App von Tile und untersuchten den BLE‑Funkverkehr sowie Netzwerkanfragen zwischen einem Tile Mate und einem Google Pixel 3 XL. Dabei fiel auf, dass der Tracker kontinuierlich BLE‑Werbepakete (Advertisements) aussendet, die identifizierende Merkmale und einen persistenten MAC‑Identifier enthalten. Zwar werden einige IDs zeitweise randomisiert, sie kommen jedoch wiederholt zum Einsatz, was Langzeitkorrelation erleichtert.
Auf Infrastrukturseite protokollieren die Tile‑Server laut Studie Standortdaten, MAC‑Adressen und eindeutige IDs ohne E2EE. Damit bleibt der Dienstanbieter technisch in der Lage, Inhalte und Metadaten einzusehen. Ein lokaler Angreifer, der BLE‑Signale passiv mitschneidet, kann einen bestimmten Tracker zuordnen und Bewegungsprofile ableiten.
Anti‑Stalking im Konflikt: „Scan and Secure“ vs. „Diebstahlschutz“
Die Funktion Scan and Secure soll unautorisierte Tracker in der Umgebung aufspüren und für Nutzer sichtbar machen. Parallel bewirbt Tile einen „Diebstahlschutz“, der Tracker gezielt unauffindbar macht. Die Studie beschreibt, dass bei aktivierter Schutzfunktion Serverergebnisse zu konkreten Tags unterdrückt werden, während ein modifiziertes Client‑App‑Verhalten dennoch zuvor beobachtete private IDs anzeigen kann. Dieses Spannungsfeld schafft einen Angriffsraum für Missbrauch.
Systemebene vs. App‑Ansatz: Warum OS‑Integration zählt
Viele Wettbewerber binden Anti‑Stalking‑Mechanismen direkt in die Betriebssysteme ein: Hintergrundscans laufen dauerhaft, und Nutzer erhalten automatische Warnungen zu unerwünschten Trackern. Als Drittanbieter‑App fehlt Tile diese tiefe Integration, was Erkennungs‑„Blind Spots“ erzeugen kann. Apple und Google haben 2024 gemeinsame Systemwarnungen auf Basis der Spezifikation Detecting Unwanted Location Trackers (DULT) etabliert, doch die Tile‑Architektur ist hierbei strukturell im Nachteil.
Rechts- und Risikokontext: Amazon Sidewalk, Transportverschlüsselung und Best Practices
Bereits 2023 sah sich Life360, Eigentümer von Tile, Klagen ausgesetzt, u. a. wegen der Integration in Amazon Sidewalk, die Reichweite und damit potenziell auch Missbrauchsrisiken erhöht. Wichtig ist die Unterscheidung zwischen Transportverschlüsselung (z. B. TLS „auf dem Weg zum Server“) und E2EE: Letztere schließt Serverzugriff auf Inhalte aus. Für hochsensible Standortdaten sind rotierende Identifikatoren, BLE‑Privacy/RPA und E2EE etablierte Minimierungsstrategien (vgl. Bluetooth SIG LE Privacy; NIST‑Leitfäden zu Bluetooth‑Sicherheit).
Reaktion von Life360 und angekündigte Änderungen
Die Forscher meldeten ihre Erkenntnisse im November 2024 an Life360. Laut Bericht gab es zunächst Zustimmung zu den Befunden, der Dialog versandete jedoch, und ein öffentlicher Kanal für verantwortliche Offenlegung sei nicht ersichtlich. Gegenüber The Register bestätigte Life360 die Hinweise und kündigte Verbesserungen an, darunter Verschlüsselung der Datenübertragung und die Umstellung auf rotierende MAC‑Adressen. Technische Details zu Zeitplan, Kryptographie und Identifier‑Rotation wurden nicht veröffentlicht.
Einordnung und Praxisempfehlungen
Die beobachteten Muster – statische MAC‑Adressen, teilrandomisierte und wiederverwendete IDs sowie fehlendes E2EE – erleichtern das linking einzelner Sichtungen über Zeit und Ort. In Kombination mit optionalen Reichweitenverlängerern (z. B. Sidewalk) steigt das Risiko für Stalking‑Szenarien. Systemseitige Warnungen (iOS/Android) mildern das, ersetzen aber keine robuste Protokollgestaltung.
Für Anwender: App und Betriebssystem aktuell halten; auf Systemwarnungen zu „Unbekannten Trackern“ reagieren; Umfeld regelmäßig scannen; Teilnahme an Dritt‑Lokalisierungsnetzwerken bei hohen Datenschutzanforderungen einschränken; bevorzugt Tracker nutzen, die rotierende MAC‑Adressen und ephemere, kryptografisch gebundene IDs einsetzen.
Für Organisationen: Tracker in das Asset‑Register und die Bedrohungsmodelle aufnehmen; Datenflüsse und Speicherfristen von Standortdaten beim Anbieter prüfen; offene Vulnerability‑Disclosure‑Prozesse, Roadmaps zu E2EE und vollständiger Identifier‑Randomisierung einfordern; periodische BLE‑Audits in sensiblen Bereichen (Büros, kritische Infrastruktur) durchführen.
Bluetooth‑Tracker sind nützlich, aber die Privatsphäre steht und fällt mit der Protokollimplementierung. Anbieter, die statische Identifikatoren beibehalten und sich auf reine Transportverschlüsselung beschränken, erhöhen das Deanonymisierungs‑ und Tracking‑Risiko. Prüfen Sie die Architektur und Transparenzpolitik Ihres Anbieters, aktivieren Sie Anti‑Stalking‑Funktionen und fordern Sie nachweisbare Sicherheitsnachweise – inklusive unabhängiger Audits und klar dokumentierter Roadmaps zu E2EE und BLE‑Privacy.
