Die Kryptologie hinter Apple’s Find My

Anfang Juni bereits hat Apple auf seiner Developer Konferenz das neue Find My vorgestellt, eine Weiterentwicklung von Find My iPhone, die sogar bei ausgeschaltetem Geräten funktionieren soll. Dabei bekommt nicht einmal Apple mit, wo sich das gesuchte Gerät befindet. Statt einem ausgewachsenen iDevice kommt auch ein kleiner Anhänger oder Tracker Tag mit Batterie in Frage; Tile muss sich also warm anziehen.

Kurzversion

  • Apple Find My verwendet ausgeklügelte Kryptographie, um nichts über die Position verlorener iDevices zu erfahren
  • Dabei verlässt sich Apple auf andere iDevice Besitzer, die Position gefundener iDevices automatisch bei Apple melden
  • Es sieht so aus, als ob die Helfer dabei mehr Information über sich an Apple melden als ihnen lieb ist
  • Aber letztlich kann man das erst sagen, wenn die genaue Spezifikation von Find my vorliegt

Detailversion

Wie funktioniert’s?

Wir haben uns gefragt, wie es sein kann, dass man Apple Geräte auffinden kann, ohne, dass Apple davon mitbekommt. Lassen wir zunächst die Kryptographie beiseite, so könnte das Auffinden grob wie folgt funktionieren:

  • Ein (potentiell verlorenes) Gerät L (wie lost) mit Find My sendet regelmäßig ein Signal mit seiner ID
  • Ein anderes Apple Gerät F (wie Finder) mit GPS, welches ein solches Signal empfängt, ermittelt seine eigene Position (und vielleicht noch eine Schätzung woher das Signal kam) und trägt die geschätzte Position des Senders L bei Apple in einer Datenbank unter der ID von L ein
  • Will man das Gerät wiederfinden, so schaut man bei Apple in der Datenbank unter der entsprechenden ID nach und findet dort die letzte Position von L
  • Selbst ausgeschaltet oder im Flugmodus kann das Gerät per Bluetooth ein Signal senden. Wenn das selten passiert, ist der Stromverbrauch in der Größenordnung einer Quarzuhr, so dass eine Batterie oder Kondensatorladung lange reicht.

So implementiert wäre es natürlich eine grobe Verletzung der Privatsphäre, da sich eine einmal beobachtete ID leicht über die Datenbank bei Apple überall verfolgen ließe.

Das vorgestellte Protokoll verhindert genau das und zwar mit Hilfe eines ausgeklügelten Verschlüsselungsverfahrens:

  • Zunächst braucht man mindestens zwei Apple Geräte: L (das Gerät das im Beispiel verloren geht) und H (wie Home; das Gerät, das wir verwenden um das verlorene zu suchen) die gekoppelt werden: Auf L und H wird ein geheimer Schlüssel (im Sinne von Public Key Verschlüsselung) erzeugt und getauscht
  • Aus dem geheimen Schlüssel lassen sich viele gültige öffentliche Schlüssel ableiten, wie man das vielleicht von Kyrpto Wallets kennt
  • Das verlorene Gerät L sendet jetzt nicht seine ID, sondern einen öffentlichen Schlüssel, der zeitabhängig generiert wurde, z.B. jede Minute einen anderen
  • Das Gerät F, welches das Signal empfängt, berechnet nun die Position, verschlüsselt diese mit dem öffentlichen Schlüssel und legt die verschlüsselte Position statt unter der ID unter einem aus dem öffentlich Schlüssel berechneten Hashwert.
  • Apple kennt den geheimen Schlüssel von L nicht und kann auch die Position von F (und L) nicht aus der Datenbank lesen, da sie ja verschlüsselt ist
  • Das gekoppelte Gerät H aber kennt den geheimen Schlüssel von L und kann daher in der Zeit rückwärts mit den möglichen Hashwerten in der Datenbank von Apple Suchen und die verschlüsselten Positionen erhalten und diese Dank privatem Schlüssel auch entschlüsseln und daher erfahren wo sich L befindet.

Was sind die Schwächen des beschriebenen Protokolls?

  • Für den Besitzer von L ist das Protokoll in der Tat recht sicher, das Gerät kann nur aus Bluetooth-Distanz getrackt werden solange es den Schlüssel nicht ändert. Im Extrem verwendet es jeden Schlüssel nur einmal und kann dann auf dieser Ebene gar nicht mehr verfolgt werden. Auf anderer Ebene schon: Sendet das Gerät wie im Beispiel oben aber in einem festen Intervall, ist es wahrscheinlich, dass das Signal aller Geräte nicht Atom-Uhr-genau zur gleichen Zeit kommt (es wäre dann auch schwer zu empfangen), sondern leicht versetzt. Über diesen Versatz könnte man das Gerät wieder auf Bluetooth-Distanz verfolgen. Andere, ähnliche Seitenkanäle sind denkbar und wahrscheinlich.
  • Ein weiteres Risiko für den Besitzer von L ist, dass F nicht ehrlich ist und eine falsche Position sendet. Damit muss (und kann) man wohl leben, da kaum jemand sein iDevice so manipulieren wird.
  • Wenn der Akteur F Zugriff auf L hat und zusätzlich die Datenbankanfragen bei Apple überwacht, so kann man H identifizieren (z.B. über die verwendete IP), wenn H eine Anfrage macht, schliesslich kennt man ja die Hash-Werte die man selbst in die Datenbank geschrieben hat. Ein Verbrecher sollte ein am Tatort zurückgelassenen iDevice also besser nicht suchen.

Deutlich exponierter ist der barmherzige Samariter dem F gehört:

  • Er spendet Energie zur GPS-Bestimmung und Datenvolumen um die Eintragung in der Apple Datenbank vorzunehmen
  • Will jemand F überwachen muss man nur einen Tracker Tag (z.B. am Auto) anbringen und die Position des Tags - also von F - wird für Monate übertragen ohne dass man sich um die Energieversorgung kümmern muss. Der aufwendige Teil wird ja von F übernommen.
  • Denkbar wäre auch einen Tag an einem einsamen Ort zu deponieren. Wenn man eine Positionsmeldung vom Tag bekommt, weiß man das der Ort gerade nicht einsam ist.
  • Richtig problematisch wird es, wenn man Zugriff auf die Kommunikation mit der Apple Datenbank hat (man denke an NSA oder FBI). Dann kann H viele Tags in der Stadt verstreuen und jedes mal, wenn F (identifiziert z.B. über die IP) eine Position meldet, kennt man die Position von F.
  • Ebenso erfährt man über zwei Finder F1 und F2, die einen Eintrag zum gleichen Hashwert in der Datenbank machen wollen, dass beide nahe bei L also auch nahe zueinander sind. Die Auflösung ist hier deutlich besser als nur die Information, dass sich beide in der gleichen Funkzelle befinden. Dies ist das unseres Erachtens das größte Problem, so wie wir das Protokoll verstehen

Letztendlich wird Apple das Protokoll nicht genau so wie oben beschrieben implementieren, so dass man die genau Spezifikation analysieren muss.