iBeacon – Sicherheit, Rollende ID’s und einige Gedanken dazu

In den letzten Wochen habe ich mich etwas mehr wieder mit iBeacons bzw. BTLE beschäftigt und den damit zusammenhängenden Geschäftsfällen. Eigentlich ist darüber ja in der gängigen Presse schon alles gesagt worden. Oder nicht? Irgendwie kam es mir vor, als wäre dem Sicherheitsmerkmal zu wenig bzw. dem nicht-existieren der Diskussion darüber Beachtung geschenkt. Eigentlich erstaunlich. Und ich rede hier nicht vom offensichtlichen, dass die Konfiguration der iBeacons mittels Backend, Passworten, Encryption… gesichert werden sollte.

Schauen wir mal…

Ein Beispiel: SBB Mein Bahnhof (HB Zürich)

Die SBB hat mit der App ‘SBB: Mein Bahnhof‘ eine App geschaffen, die es auch Fremden und nicht-Kundigen des Bahnhofs Zürich erlaubt, rasch die Dinge zu finden, die sie benötigen. Sehr gut und spannendes Angebot. #Ilike.

Wie das funktioniert? Das wird rasch klar. Die App fordert einen – auf iOS mindestens – auf, Bluetooth zu aktivieren für eine verbesserte Navigation innerhalb der Banhhofsgebäude. Schaut man mal nach oben an die Decke in den Untergeschossen, fallen einem kleine, weisse (oder goldene…) Kästchen auf, die in einem definierten Abstand von einander aufgehängt wurden. Diese Dinger sind iBeacons. Mit Hilfe dieser interpoliert die App den Standort des App-Nutzers. Das sieht man auch daran, dass der Standort immer leicht schwankt, auch wenn man sich nicht bewegt. Das liegt halt an der Sache der BTLE-Sendemuster. Oder auch daran, dass halt nicht die ganze Sache ausgemessen bzw. kalibriert wurde. Aber das ist ein anderes Thema.

Worum es mir hier geht: mit geeigneten Apps kann ich die Beacons klonen. Das heisst, ich hijacke die Daten UUID, Major, Minor von den umliegenden Beacons, da diese Daten offen sind. Ich aktiviere danach mein iPhone als 1-n Beacons und – Flupp – kann ich Leute an der Nase rumführen. Das ist nur ein witziger Case, wenn die Leute etwas hilflos rumstehen. Das kann aber weitergehen. Man stelle sich genügend kriminelle Energie vor, und schon kann man Leute, die eigentlich zum Mövenpick wollen zu einem anderen Geschäft lotsen.

Sicher – in diesem Case ist es noch nicht schwerwiegend. Aber was passiert, wenn Beacons für Couponing, Loyalty, CheckIn, EntryAccess etc. genutzt werden und diese Beacons in diesen Fällen dann kopiert werden?

Oder Daten dazu verwendet werden, Benutzer auf die falschen Fährten mit eigenen Apps zu führen und dann persönliche Daten auszuspionieren?

Interessante Möglichkeiten – doch wie begegnen wir denen?

iBeacon Sicherheit – Thema mit viel Potential

Die Lösungsansätze die es bereits gibt sind noch nicht so vielfältig – eigentlich gibt es bisher nur eine Möglichkeit, mit verschiedenen Ausprägungen:

Rotation der iBeacon Identifier durch ein Backend getrieben

  • UUID: einige Anbieter rotieren die UUID des iBeacons. Dabei gibt es auch wieder zwei Ausprägungen. Die einen machen dies frei und unlimitiert, die anderen mittels im Backend erfassten Listen. Das Problem dabei: irgendwie muss die Limite von 20 Regionen ausgehebelt werden. Diese 20 Regionen sind im OS der Phones fix eingebaut und haben zum Zweck, Batterie- und auch weitere Ortungseigenschaften zu optimieren. Was passiert aber, wenn ich zu oft rotiere? Mehr Regionen werden genutzt. Was wenn zu wenig? Angreifbarer. Und: wie halte ich viele Beacons synchron?
    Einige Anbieter behaupten, das 20-Regionen-Problem gelöst zu haben. Und das Synchronitätsproblem auch. Das wird wohl einfach mit einem Call in der App jeweils gemacht.
  • Major und/oder Minor: rotieren dieser Elemente verhindert zwar das Regionen-Desaster (sorry) ist aber anderweitig etwas komplexer: potentiell müssen mehrere iBeacons geollt (-sic-) werden und synchron gehalten werden. Auch hier gilt, dass die Daten zwischen App, Beacons und Backend bzw. SDK synchronisiert werden müssen. Und das Rolling-Verhalten die Sicherheit bestimmt. Minor und / oder Major zu rollen hat sicherlich extrem viele Möglichkeiten – jedoch ist auf die Notwendigkeit bzw. Beherrschung zu achten, dass gerade diese Daten oftmals für die Erkennung nur marginalisiert betrachtet werden vom OS – oder eben je nach Strategie.
  • Zusätzliche Daten: einige Hersteller / Anwender / Backend-Anbieter schwören auf die Kombination von iBeacon Daten, Geoplacement und / oder WLAN/ NetworkProvider -Netzstärke, die im Backend hinterlegt wird beim Platzieren. Bei (jedem | periodischen) Aufruf zum Backend wird der Standort bzw. die hinterlegten Daten geprüft und in einem gemittelten Verfahren ein Alarming ausgelöst. Kann indoors funktionieren. Oder auch nicht. Viele Parameter bestimmen die Geolocation (GPS) indoors, ebenso wie die WLAN-Signalstärke bzw. auch die Network-Stärke. Gerade diese kann auch durch den Telco-Provider dynamisch gesteuert werden. Denken wir nur an z.b. Sportstadien etc.

Gibt es weitere Möglichkeiten?

Bin gespannt auf die Reaktionen.