Tapkey gegen Bluetooth-Relay-Angriffe

Relay Angriffe betreffen Tapkey nicht

In den letzten Jahren wurden verschiedene Arten von Angriffen auf Bluetooth-fähige Schließmechanismen demonstriert. Erst kürzlich wurde eine neuartige Relay-Attacke aufgezeigt, welche das Öffnen und Bedienen von Tesla Autos ermöglicht. Wir von Tapkey werden oft von unseren Kunden gefragt, ob auch Tapkey von dieser Art von Angriffen auf den Bluetooth-Technologiestandard betroffen ist. Die kurze Antwort: Ist es nicht und war es nie. Hier ist der Grund.

Zuerst etwas Hintergrund. Die Mehrheit der nachgewiesenen Angriffe lässt sich in zwei Kategorien unterteilen, auf die näher eingegangen wird:

Angriffe auf die im Bluetooth-Standard integrierten Sicherheitsprotokolle
Relay-Angriffe

Angriffe auf die integrierten Sicherheitsprotokolle

Bluetooth verfügt über integrierte Sicherheitsprotokolle, welche im Standard spezifiziert sind und welche eine sichere Kopplung und Kommunikation zwischen Bluetooth-fähigen Geräten ermöglichen sollen. Sicherheitsforscher haben Schwachstellen in diesen Protokollen identifiziert, welche insbesondere das Kopplungsverfahren betreffen. Es wurde gezeigt, dass diese Anfälligkeiten für Abhörversuche aufweisen beziehungsweise es Angreifern sogar möglich sein könnte, die Kontrolle über betroffene Geräte zu übernehmen.

Tapkey ist von solchen Schwachstellen nicht betroffen, da die Sicherheitsprotokolle, welche bei Tapkey zum Einsatz kommen, außerhalb des Bluetooth Standards definiert wurden und zusätzlich zu den Protokollen des Standards ablaufen. Das bedeutet, dass Tapkey sich nicht auf die Sicherheit der Bluetooth-eigenen Kryptografie verlässt, sondern stattdessen alle erforderlichen Verschlüsselungen in zusätzlichen Protokollen implementiert, die alle unabhängig vom Bluetooth-Standard sind. Einer der Gründe dafür ist, dass die in den Standard integrierten Protokolle nicht für Cloud-basierte Operationen mit vielen Teilnehmern entwickelt wurden, welche aber die Natur von Tapkey-fähigen Geräten sind.

Relay-Angriffe

Die Kommunikation über Bluetooth ist in der Regel auf einen Bereich von wenigen Metern beschränkt. Bluetooth-Geräte haben einige Möglichkeiten, die tatsächliche Entfernung zwischen Teilnehmern abzuschätzen, wie die Messung der Signalstärke oder Triangulation, um nur zwei zu nennen. Das Problem dabei ist, dass sie nicht zuverlässig sind. Einerseits sind sie relativ ungenau, viel wichtiger ist aber, dass ein Kommunikationspartner entweder die Entfernung des anderen abschätzen oder aber seine Identität verifizieren kann, nicht aber nicht beides zusammen. So kann eine Partei entweder wissen, wo sich die andere Partei befindet, aber nicht sicher sein, ob sie wirklich diejenige ist, für die sie sich ausgibt. Oder die Partei kann die Identität der zweiten Partei überprüfen, sich aber nicht sicher sein, ob sie sich auch tatsächlich in der Nähe befindet. Die relevanteste Methode, um die Entfernung zwischen mobilen Geräten zuverlässig und sicher zu messen, wäre die Messung von Signallaufzeiten in Kombination mit etwas Kryptografie (d. h. die Messung der Zeit, die es dauert, bis ein Signal von einer ersten Partei (dem Mobiltelefon) gesendet und von der anderen Partei (dem Schloss/Auto) empfangen wird, sodann die andere Partei bestimmte kryptografische Operationen durchführt und das Ergebnis an die erste Partei zurückgesendet wird). Diese Technologie erfordert jedoch Unterstützung auf sehr niedrigen Ebenen des Protokoll-Stacks und ist im Bluetooth-Standard weder vorhanden noch kann sie in die heutige verbreitete Hardware sinnvoll nachgerüstet werden.

Nun, warum ist das ein Problem?

Einige Produkte bieten das Entsperren über einen Hands-free Modus (auch “Keyless Entry”, “Keyloess Go”, etc. genannt). Dabei handelt es sich um einen Modus bei dem es ausreicht, einen Schlüssel (oder in unserem Fall ein mobiles Gerät) in die Nähe eines Schlosses (oder eines Autos) zu bringen, um es zu bedienen. Es ist keine zusätzliche Interaktion zwischen dem Eigentümer des Schlüssels und dem Schlüssel (Mobilgerät) selbst erforderlich. Dies wird normalerweise so implementiert, dass die auf dem Mobilgerät ausgeführte App die Entfernung zu benachbarten Schließgeräten überwacht, und einen Befehl zum Öffnen sendet, falls es zu einer Annäherung unter eine bestimmte Distanz kommt. Doch mangels Unterstützung durch den Bluetooth-Standard können weder die mobile App noch das Schließgerät sicher sein, dass es sich bei demjenigen Kommunikationspartner, welcher sich in unmittelbarer Nähe befindet, auch wirklich um jenen handelt, für den er sich ausgibt. Dies ermöglicht einem Paar von Angreifern die Ausführung folgenden (vereinfachten) Verfahrens:

Eine Person (nennen wir sie Alice) hat ein mobiles Gerät mit einem Schlüssel für das Auto einer anderen Person (nennen wir sie Bob).
Angreiferin 1 (nennen wir sie Mallory) bringt ihr Mobilgerät mit einer selbst programmierten, bösartigen App in die Nähe von Alices Telefon.
Mallorys Telefon gibt vor, Bobs Auto zu sein, indem es die Advertising-Daten des Autos repliziert.
Alices Telefon kann nur sehen, dass Bobs Auto in der Nähe zu sein scheint, aber nicht seine Identität verifizieren. Alices Schlüsselring-App verfügt über einen integrierten Hands-free Modus, sodass sie dennoch einen legitimen Entsperrbefehl an Mallorys Telefon sendet (weil sie davon ausgeht, dass es sich um Bobs Auto handelt).
Mallorys Telefon empfängt den Schlüssel und leitet ihn an das mobile Gerät des zweiten Angreifers (nennen wir ihn Malcolm) weiter.
Malcolm hat sein Telefon bereits in die Nähe von Bobs Auto gebracht, und ebenfalls eine bösartige, selbst programmierte App auf seinem Telefon laufen. Diese leitet den Schlüssel an Bobs Auto weiter und gibt dabei vor, Alices Telefon zu sein.
Bobs Auto verifiziert den Schlüssel, was erfolgreich ist, da es Alices legitimer Schlüssel ist. Bobs Auto stellt auch fest, dass das Telefon, welches Alices Schlüssel sendet, tatsächlich Alices Mobiltelefon zu sein scheint. Aufgrund der in diesem Artikel diskutierten Einschränkungen kann Bobs Auto dies jedoch nicht mit zuverlässig überprüfen.
Bobs Auto wird geöffnet.

Dieser Angriff ermöglicht es Mallory und Malcolm, Bobs Auto zu öffnen, obwohl Alice nicht in der Nähe ist. Vielleicht ist sie sogar in einem anderen Land.

Lässt sich das Hands-free Öffnen mit heutigen Smartphones und nur auf Basis von Bluetooth überhaupt sicher realisieren? „Meines Wissens nicht.“ spricht Co-CEO & CTO Markus Minichmayr.

Bedeutet dies, dass die Verwendung von Bluetooth für den physischen Zugriff unsicher ist? Nein. Es bedeutet nur, dass die sichere Implementierung des Hands-free Modus nicht möglich zu sein scheint, wenn er ausschließlich auf Bluetooth-Technologie basiert.

Warum ist Tapkey nicht betroffen?

Die Tapkey App implementiert schlicht und einfach keinen Hands-free Modus. Tapkey rät auch allen Drittanbietern, welche das Tapkey Mobile SDK in ihre Apps integrieren, dringend davon ab, dies zu tun. Beim Entsperren über die Tapkey App per Bluetooth wird der Vorgang immer vom Benutzer selbst initiiert und beinhaltet immer die Interaktion über eine Benutzeroberfläche. So kann ein Angreifer die Tapkey App nicht von sich aus veranlassen, einen Befehl abzusetzen. Darüber hinaus zeigt die Benutzeroberfläche beim Öffnungsvorgang immer den Namen des zu öffnenden Schlosses an und fordert den Benutzer auf, den Entriegelungsvorgang durch eine physische Interaktion zu bestätigen. Da Nutzer die App in der Regel nur dann zum Öffnen einer Tür veranlassen, wenn sie sich in unmittelbarer Nähe befinden, sind Relays in den meisten Fällen kein relevanter Angriffsvektor.

Übrigens gibt es Alternativen zum Hands-free Modus, die es ermöglichen, sowohl eine großartige Benutzererfahrung zu bieten, als auch die besprochenen Sicherheitsprobleme zu vermeiden. Die Tapkey App für iOS enthält beispielsweise ein nettes Widget für den Heute-Bildschirm von iOS, mit welchem Benutzer schnell auf ihre Schlösser in der Nähe zugreifen können. Mit der Tapkey App für Android kann NFC zum Entsperren verwendet werden, wodurch der Zugriff durch einfaches Antippen eines Schlosses mit einem entsperrten Android-Telefon ermöglicht wird. In beiden Fällen ist natürlich trotzdem die besprochene Sicherheitsmechanismen aktiv, sodass diese vermieden werden, während dennoch eine großartige User Experience geboten wird.