Spezifikationen für „Mein Gerät finden“-Netzwerkzubehör

v1.3

Die FMDN-Zubehörspezifikation (Find My Device Network) definiert einen Ende-zu-Ende-verschlüsselten Ansatz für das Tracking von Beaconing-Geräten für Bluetooth Low Energy (BLE). Auf dieser Seite wird FMDN als Erweiterung der Spezifikation für schnelles Pairing beschrieben. Anbieter sollten diese Erweiterung aktivieren, wenn sie Geräte haben, die mit FMDN kompatibel sind und bereit sind, die Standortverfolgung für diese Geräte zu aktivieren.

GATT-Spezifikation

Dem Dienst für schnelles Pairing sollte ein zusätzliches generisches Attribut (GATT) mit der folgenden Semantik hinzugefügt werden:

Merkmal „Schnelles Pairing“ Verschlüsselt Berechtigungen UUID
Beacon-Aktionen Nein Lesen, schreiben und benachrichtigen FE2C1238-8366-4814-8EB0-01DE32100BEA

Tabelle 1:Merkmale des FMDN für schnelles Pairing

Authentifizierung

Die von dieser Erweiterung erforderlichen Vorgänge werden als Schreibvorgang ausgeführt und durch einen Abfragemechanismus gesichert. Vor dem Ausführen eines Vorgangs wird erwartet, dass der suchende Nutzer einen Lesevorgang aus der Eigenschaft in Tabelle 1 ausführt, was zu einem Puffer im folgenden Format führt:

Oktett Datentyp Beschreibung Wert
0 uint8 Protokoll-Hauptversionsnummer 0x01
1–8 Byte-Array Einmalige zufällige Nonce variiert

Jeder Lesevorgang sollte zu einer anderen Nonce führen und eine einzelne Nonce sollte nur für einen einzelnen Vorgang gültig sein. Die Nonce muss auch dann ungültig gemacht werden, wenn der Vorgang fehlgeschlagen ist.

Der Suchende berechnet dann einen einmaligen Authentifizierungsschlüssel, der in einer nachfolgenden Schreibanfrage verwendet wird. Der Authentifizierungsschlüssel wird wie in den Tabellen 2 bis 5 beschrieben berechnet. Abhängig vom angeforderten Vorgang weist der Seeker einen oder mehrere der folgenden Schlüssel nach:

Operations

Das Format der Daten, die in das Merkmal geschrieben werden, ist in den Tabellen 2 bis 5 angegeben. Jeder Vorgang wird später in diesem Abschnitt ausführlicher erläutert.

Oktett Datentyp Beschreibung Wert
0 uint8 Daten-ID
  • 0x00: Beacon-Parameter lesen
  • 0x01: Bereitstellungsstatus lesen
  • 0x02: Sitzungsspezifischen Identitätsschlüssel festlegen
  • 0x03: Kurzlebigen Identitätsschlüssel löschen
1 uint8 Datenlänge variiert
2–9 Byte-Array Einmaliger Authentifizierungsschlüssel Die ersten 8 Byte von HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var Byte-Array Zusätzliche Daten
  • 0x00: –
  • 0x01: –
  • 0x02: 32 Byte, die der sitzungsspezifische Identitätsschlüssel sind und AES-ECB-128 mit dem Kontoschlüssel verschlüsselt ist. Wenn der Anbieter bereits einen sitzungsspezifischen Identitätsschlüssel festgelegt hat, senden Sie auch die ersten 8 Byte von SHA256(current ephemeral identity key || the last nonce read from the characteristic)
  • 0x03: Die ersten 8 Byte von SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tabelle 2:Anfrage zur Beacon-Bereitstellung

Oktett Datentyp Beschreibung Wert
0 uint8 Daten-ID 0x04: Kurzlebigen Identitätsschlüssel mit Nutzereinwilligung lesen
1 uint8 Datenlänge 0x08
2–9 Byte-Array Einmaliger Authentifizierungsschlüssel Die ersten 8 Byte von HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length)

Tabelle 3:Anfrage zur Wiederherstellung des Beacon-Bereitstellungsschlüssels

Oktett Datentyp Beschreibung Wert
0 uint8 Daten-ID
  • 0x05: Ring
  • 0x06: Klingeltonstatus lesen
1 uint8 Datenlänge variiert
2–9 Byte-Array Einmaliger Authentifizierungsschlüssel Die ersten 8 Byte von HMAC-SHA256(ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var Byte-Array Zusätzliche Daten
  • 0x05: 4 Byte, die den Klingeltonstatus, die Klingeldauer und die Lautstärke des Klingeltons angeben.
  • 0x06: –

Tabelle 4:Klingeln lassen

Oktett Datentyp Beschreibung Wert
0 uint8 Daten-ID
  • 0x07: Unerwünschten Schutzmodus für Tracking aktivieren
  • 0x08: Unerwünschten Schutzmodus für Tracking deaktivieren
1 uint8 Datenlänge variiert
2–9 Byte-Array Einmaliger Authentifizierungsschlüssel Die ersten 8 Byte von HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var Byte-Array Zusätzliche Daten
  • 0x07: 1 Byte der Steuer-Flags (optional)
  • 0x08: Die ersten 8 Byte von SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tabelle 5:Anfrage zum Schutz vor unerwünschtem Tracking

Erfolgreiche Schreibvorgänge lösen Benachrichtigungen aus (siehe Tabelle 6).

Benachrichtigungen mit einer anderen Daten-ID als 0x05: Ring state change (Ringstatusänderung) sollten gesendet werden, bevor die Schreibtransaktion abgeschlossen ist, die die Benachrichtigung auslöst, also bevor eine Antwort-PDU für die Schreibanfrage gesendet wird.

Oktett Datentyp Beschreibung Wert
0 uint8 Daten-ID
  • 0x00: Beacon-Parameter lesen
  • 0x01: Bereitstellungsstatus lesen
  • 0x02: Sitzungsspezifischen Identitätsschlüssel festlegen
  • 0x03: Kurzlebigen Identitätsschlüssel löschen
  • 0x04: Kurzlebigen Identitätsschlüssel mit Nutzereinwilligung lesen
  • 0x05: Änderung des Klingeltonstatus
  • 0x06: Klingeltonstatus lesen
  • 0x07: Unerwünschten Schutzmodus für Tracking aktivieren
  • 0x08: Unerwünschten Schutzmodus für Tracking deaktivieren
1 uint8 Datenlänge variiert
2–9 Byte-Array Authentifizierung Details pro Vorgang
10 - var Byte-Array Zusätzliche Daten
  • 0x00: 8 Byte, die die Übertragungsleistung, den Taktwert, die Verschlüsselungsmethode und die Klingelfunktionen angeben, AES-ECB-128 mit dem Kontoschlüssel verschlüsselt (mit Nullauffüllung)
  • 0x01: 1 Byte, das den Bereitstellungsstatus angibt, gefolgt von der aktuellen sitzungsspezifischen ID (20 oder 32 Byte), falls zutreffend
  • 0x04: 32 Byte als sitzungsspezifischer Identitätsschlüssel, AES-ECB-128, verschlüsselt mit dem Kontoschlüssel
  • 0x05: 4 Byte, die den neuen Status angeben und die Änderung auslösen
  • 0x06: 3 Byte, die die aktiven Komponenten und die Anzahl der verbleibenden Dezisekunden für das Klingeln angeben
  • Bei anderen Daten-IDs werden keine zusätzlichen Daten verwendet

Tabelle 6:Antwort des Beacon-Dienstes

In Tabelle 7 sind die möglichen GATT-Fehlercodes aufgeführt, die von den Vorgängen zurückgegeben werden.

Code Beschreibung Hinweise
0x80 Nicht authentifiziert Wird als Antwort auf eine Schreibanfrage zurückgegeben, wenn die Authentifizierung fehlschlägt (auch wenn eine alte Nonce verwendet wurde).
0x81 Ungültiger Wert Wird zurückgegeben, wenn ein ungültiger Wert angegeben wird oder die empfangenen Daten eine unerwartete Anzahl von Byte haben.
0x82 Keine Nutzereinwilligung Wird als Antwort auf eine Schreibanfrage mit der Daten-ID 0x04: Read flüchtigen Identitätsschlüssel mit Nutzereinwilligung zurückgegeben, wenn sich das Gerät nicht im Kopplungsmodus befindet.

Tabelle 7:GATT-Fehlercodes

Beacon-Parameter lesen

Der Suchende kann beim Anbieter die Parameter des Beacons abfragen, indem er einen Schreibvorgang für die Eigenschaft ausführt, die aus einer Anfrage aus Tabelle 2 mit der Daten-ID 0x00 besteht. Der Anbieter überprüft, ob der bereitgestellte Schlüssel zur einmaligen Authentifizierung mit einem der auf dem Gerät gespeicherten Kontoschlüssel übereinstimmt.

Wenn die Überprüfung fehlschlägt, gibt der Anbieter den Fehler „Nicht authentifiziert“ zurück.

Bei Erfolg benachrichtigt der Anbieter mit einer Antwort aus Tabelle 6 mit der Daten-ID 0x00. Der Anbieter erstellt das Datensegment so:

Oktett Datentyp Beschreibung Wert
0 uint8 Kalibrierte Stromversorgung Die kalibrierte Leistung bei 0 m (ein Wert im Bereich [-100, 20]). Wird als vorzeichenbehaftete Ganzzahl mit einer Auflösung von 1 dBm dargestellt.
1–4 uint32 Uhrzeitwert Der aktuelle Taktwert in Sekunden (Big-Endian).
5 uint8 Kurvenauswahl Die elliptische Kurve, die für die Verschlüsselung verwendet wird:
  • 0x00 (Standard): SECP160R1
  • 0x01: SECP256R1 (erweiterte Werbung erforderlich)
6 uint8 Komponenten Anzahl der Komponenten, die klingeln können:
  • 0x00: Zeigt an, dass das Gerät nicht klingeln kann.
  • 0x01: Gibt an, dass nur eine einzelne Komponente klingeln kann.
  • 0x02: Gibt an, dass zwei Komponenten, der linke und der rechte Kopfhörer, unabhängig voneinander klingeln können.
  • 0x03: Gibt an, dass drei Komponenten – linker und rechter Kopfhörer und das Lade-Case – unabhängig voneinander klingeln können.
7 uint8 Klingeln lassen Folgende Optionen werden unterstützt:
  • 0x00: Keine Auswahl der Klingellautstärke.
  • 0x01: Auswahl der Klingellautstärke verfügbar. Wenn dies festgelegt ist, muss der Anbieter drei Lautstärkestufen akzeptieren und verarbeiten, wie unter Klingeln lassen angegeben.
8–15 Byte-Array Abstand Kein Padding für AES-Verschlüsselung.

Die Daten sollten AES-ECB-128-verschlüsselt mit dem Kontoschlüssel sein, der zur Authentifizierung der Anfrage verwendet wird.

Das Authentifizierungssegment ist als die ersten 8 Byte von HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01) definiert.

Bereitstellungsstatus des Beacons lesen

Der Suchende kann beim Anbieter den Bereitstellungsstatus des Beacons abfragen, indem er einen Schreibvorgang für die Eigenschaft ausführt, die aus einer Anfrage aus Tabelle 2 mit der Daten-ID 0x01 besteht. Der Anbieter überprüft, ob der bereitgestellte einmalige Authentifizierungsschlüssel mit einem der auf dem Gerät gespeicherten Kontoschlüssel übereinstimmt.

Wenn die Überprüfung fehlschlägt, gibt der Anbieter einen nicht authentifizierten Fehler zurück.

Bei Erfolg benachrichtigt der Anbieter mit einer Antwort aus Tabelle 6 mit der Daten-ID 0x01. Der Anbieter erstellt das Datensegment so:

Oktett Datentyp Beschreibung Wert
0 uint8 ProvisioningState Eine Bitmaske mit den folgenden Werten:
  • Bit 1 (0x01): Wird festgelegt, wenn für das Gerät ein sitzungsspezifischer Identitätsschlüssel festgelegt ist.
  • Bit 2 (0 x 02): Wird festgelegt, wenn der angegebene Schlüssel zur einmaligen Authentifizierung mit dem Schlüssel des Inhaberkontos übereinstimmt.
1–20 oder 32 Byte-Array Aktuelle sitzungsspezifische ID 20 oder 32 Byte (je nach verwendeter Verschlüsselungsmethode), die die aktuelle vom Beacon angebotene sitzungsspezifische ID angibt, sofern eine für das Gerät festgelegt ist.

Das Authentifizierungssegment ist als die ersten 8 Byte von HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) definiert.

Sitzungsspezifische Identitätsschlüssel festlegen

Um einen nicht bereitgestellten Anbieter als FMDN-Beacon bereitzustellen oder den sitzungsspezifischen Identitätsschlüssel eines bereits bereitgestellten Anbieters zu ändern, führt der Seeker einen Schreibvorgang für die Eigenschaft aus, die aus einer Anfrage aus Tabelle 2 mit der Daten-ID 0x02 besteht. Der Dienstleister überprüft Folgendes:

  • Der angegebene Schlüssel für die einmalige Authentifizierung stimmt mit dem Schlüssel des Inhaberkontos überein.
  • Wenn ein Hash eines sitzungsspezifischen Identitätsschlüssels angegeben wurde, stimmt der gehashte sitzungsspezifische Identitätsschlüssel mit dem aktuellen sitzungsspezifischen Identitätsschlüssel überein.
  • Wenn kein Hash eines sitzungsspezifischen Identitätsschlüssels angegeben wurde, überprüfe, ob der Anbieter nicht bereits als FMDN-Beacon bereitgestellt wurde.

Wenn die Überprüfung fehlschlägt, gibt der Anbieter einen nicht authentifizierten Fehler zurück.

Bei Erfolg wird der sitzungsspezifische Identitätsschlüssel von AES-ECB-128 wiederhergestellt, der ihn mit dem übereinstimmenden Kontoschlüssel entschlüsselt. Der Schlüssel sollte auf dem Gerät bestehen bleiben und der Anbieter sollte ab diesem Zeitpunkt FMDN-Frames bewerben. Der neue sitzungsspezifische Identitätsschlüssel tritt sofort nach Beendigung der BLE-Verbindung in Kraft. Der Anbieter benachrichtigt mit einer Antwort aus Tabelle 6 mit der Daten-ID 0x02.

Das Authentifizierungssegment ist als die ersten 8 Byte von HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) definiert.

Sitzungsspezifische Identitätsschlüssel löschen

Zum Aufheben der Bereitstellung des Beacon-Teils des Anbieters führt der Suchende einen Schreibvorgang für die Eigenschaft aus, der aus einer Anfrage aus Tabelle 2 mit der Daten-ID 0x03 besteht. Der Dienstleister überprüft Folgendes:

  • Der angegebene Schlüssel für die einmalige Authentifizierung stimmt mit dem Schlüssel des Inhaberkontos überein.
  • Der gehashte sitzungsspezifische Identitätsschlüssel stimmt mit dem aktuellen sitzungsspezifischen Identitätsschlüssel überein.

Wenn der Anbieter nicht als FMDN-Beacon bereitgestellt wird oder die Verifizierung fehlschlägt, gibt er einen nicht authentifizierten Fehler zurück.

Im Erfolgsfall vergisst der Anbieter den Schlüssel und stellt die Werbung für FMDN-Frames ein. Der Anbieter benachrichtigt mit einer Antwort aus Tabelle 6 mit der Daten-ID 0x03. Das Authentifizierungssegment ist als die ersten 8 Byte von HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) definiert.

Sitzungsspezifischen Identitätsschlüssel mit Nutzereinwilligung lesen

Diese Option ist nur zum Wiederherstellen eines verlorenen Schlüssels verfügbar, da der Schlüssel nur lokal vom Seeker gespeichert wird. Daher ist diese Funktion nur verfügbar, wenn sich das Gerät im Kopplungsmodus befindet oder für eine begrenzte Zeit, nachdem eine physische Taste auf dem Gerät gedrückt wurde (was eine Nutzereinwilligung darstellt).

Der Suchende muss den Wiederherstellungsschlüssel auf dem Back-End speichern, um den Klartextschlüssel wiederherstellen zu können, er speichert jedoch nicht den EIK selbst.

Zum Lesen des EIK führt der Seeker einen Schreibvorgang für die Eigenschaft aus, der aus einer Anfrage aus Tabelle 3 mit der Daten-ID 0x04 besteht. Der Anbieter überprüft Folgendes:

  • Der gehashte Wiederherstellungsschlüssel stimmt mit dem erwarteten Wiederherstellungsschlüssel überein.
  • Das Gerät befindet sich im EIK-Wiederherstellungsmodus.

Wenn die Überprüfung fehlschlägt, gibt der Anbieter einen nicht authentifizierten Fehler zurück.

Wenn sich das Gerät nicht im Kopplungsmodus befindet, gibt der Anbieter den Fehler „Keine Nutzereinwilligung“ zurück.

Im Erfolgsfall benachrichtigt der Anbieter mit einer Antwort aus Tabelle 6 mit der Daten-ID 0x04.

Das Authentifizierungssegment ist als die ersten 8 Byte von HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) definiert.

Klingeln lassen

Der Suchende kann den Anbieter bitten, einen Ton abzuspielen, indem er einen Schreibvorgang für das Merkmal ausführt, der aus einer Anfrage aus Tabelle 4 mit der Daten-ID 0x05 besteht. Der Anbieter erstellt das Datensegment so:

Oktett Datentyp Beschreibung Wert
0 uint8 Klingeln lassen Eine Bitmaske mit den folgenden Werten:
  • Bit 1 (0x01): Rechts klingeln lassen
  • Bit 2 (0x02): Linksring
  • Bit 3 (0x04): Ring Case
  • 0xFF: Alle Komponenten klingeln lassen
  • 0x00: Klingeln beenden
1–2 uint16 Zeitlimit Das Zeitlimit in Dezise. Darf nicht null sein und nicht größer als 10 Minuten sein.
Der Anbieter legt anhand dieses Werts fest, wie lange er klingeln soll, bevor er sich selbst stummschaltet. Das Zeitlimit überschreibt das Zeitlimit, wenn eine Komponente des Geräts bereits klingelt.

Wenn der Wert für Ringvorgang auf 0 x 00 gesetzt ist, wird das Zeitlimit ignoriert.
3 uint8 Volumen
  • 0 x 00: Standard
  • 0x01: Niedrig
  • 0x02: Mittel
  • 0x03: Hoch
Die genaue Bedeutung dieser Werte hängt von der Implementierung ab.

Nach Erhalt der Anfrage überprüft der Anbieter Folgendes:

  • Der angegebene Schlüssel zur einmaligen Authentifizierung stimmt mit dem Ringschlüssel überein.
  • Der angeforderte Status stimmt mit den Komponenten überein, die klingeln können.

Wenn der Anbieter nicht als FMDN-Beacon bereitgestellt wird oder die Verifizierung fehlschlägt, gibt er einen nicht authentifizierten Fehler zurück. Wenn der Anbieter jedoch den Schutz vor unerwünschtem Tracking aktiviert und bei der auslösenden Anfrage zum Schutz vor unerwünschtem Tracking das Flag für die Authentifizierung beim Überspringen des Klingelns aktiviert war, sollte er diese Prüfung überspringen. Die Authentifizierungsdaten werden weiterhin vom Suchenden erwartet, können jedoch auf einen beliebigen Wert gesetzt werden.

Wenn das Klingeln beginnt oder endet, wird eine Benachrichtigung gesendet, wie in Tabelle 6 mit der Daten-ID 0x05 angegeben. Der Inhalt der Benachrichtigung ist so definiert:

Oktett Datentyp Beschreibung Wert
0 uint8 Klingeltonstatus
  • 0x00: Gestartet
  • 0x01: Starten oder Beenden nicht möglich (alle angeforderten Komponenten liegen außerhalb des zulässigen Bereichs)
  • 0x02: Angehalten (Zeitüberschreitung)
  • 0x03: Angehalten (Tastenbetätigung)
  • 0x04: Angehalten (GATT-Anfrage)
1 uint8 Klingelnde Komponenten Eine Bitmaske der Komponenten, die aktiv klingeln, wie in der Anfrage definiert.
2–3 uint16 Zeitlimit Die verbleibende Zeit für das Klingeln in Dezisekunden. Wenn das Gerät nicht mehr klingelt, sollte „0x0000“ zurückgegeben werden.

Das Authentifizierungssegment ist als die ersten 8 Byte von HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01) definiert.

Wenn sich das Gerät bei einer Anfrage zum Klingeln oder Beenden des Klingelns bereits im angeforderten Status befindet, sollte der Anbieter eine Benachrichtigung mit einem Klingeltonstatus oder entweder „0x00: Gestartet“ oder „0x04: Gestoppt“ (GATT-Anfrage) senden. Diese Anfrage überschreibt die Parameter des vorhandenen Status, sodass die Klingeldauer verlängert werden kann.

Wenn der Dienstleister eine physische Taste hat (oder Touch Sense aktiviert ist), sollte diese Taste das Klingeln beenden, wenn sie gedrückt wird, während das Klingeln aktiv ist.

Klingelstatus des Beacon abrufen

Um den Klingeltonstatus des Beacons abzurufen, führt der Seeker einen Schreibvorgang für die Eigenschaft durch, der aus einer Anfrage aus Tabelle 4 mit der Daten-ID 0x06 besteht. Der Anbieter überprüft, ob der bereitgestellte einmalige Authentifizierungsschlüssel mit dem Ringschlüssel übereinstimmt.

Wenn der Anbieter nicht als FMDN-Beacon bereitgestellt wird oder die Überprüfung fehlschlägt, gibt er einen Fehler für einen nicht authentifizierten Dienst zurück.

Bei Erfolg benachrichtigt der Anbieter mit einer Antwort aus Tabelle 6 mit der Daten-ID 0x06. Der Anbieter erstellt das Datensegment so:

Oktett Datentyp Beschreibung Wert
0 uint8 Klingelnde Komponenten Die Komponenten, die aktiv klingeln, wie in der Klingeltonanfrage definiert.
1–2 uint16 Zeitlimit Die verbleibende Zeit für das Klingeln in Dezisekunden. Wenn das Gerät nicht klingelt, sollte „0x0000“ zurückgegeben werden.

Das Authentifizierungssegment ist als die ersten 8 Byte von HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) definiert.

Unerwünschter Schutzmodus für Tracking

Der Schutzmodus für unerwünschtes Tracking soll es allen Clients ermöglichen, missbräuchliche Geräte ohne Serverkommunikation zu identifizieren. Der Anbieter sollte standardmäßig alle Kennungen rotieren, wie unter ID-Rotation beschrieben. „Mein Gerät finden“ kann eine Anfrage zur Aktivierung des Modus zum Schutz vor unerwünschtem Tracking über das „Mein Gerät finden“-Netzwerk weiterleiten. Dadurch verwendet der Dienst vorübergehend eine feste MAC-Adresse, damit Clients das Gerät erkennen und Nutzer vor möglicherweise unerwünschtem Tracking warnen können.

Um den unerwünschten Tracking-Schutzmodus des Beacons zu aktivieren oder zu deaktivieren, führt der Seeker einen Schreibvorgang für die Eigenschaft aus, der aus einer Anfrage aus Tabelle 5 mit der Daten-ID 0x07 bzw. 0x08 besteht.

Wenn der Schutzmodus für unerwünschtes Tracking aktiviert wird

Der Anbieter erstellt das Datensegment so:

Oktett Datentyp Beschreibung Wert
0 uint8 Kontrollflags
  • 0x01: Authentifizierung mit Klingeln wird übersprungen. Wenn diese Option aktiviert ist, werden klingelnde Anfragen im Schutzmodus für unerwünschtes Tracking nicht authentifiziert.
Wenn kein Flag festgelegt wird (das Byte besteht nur aus Nullen), kann der Datenabschnitt vollständig weggelassen und ein leerer Datenabschnitt gesendet werden.
Die Flags sind nur so lange aktiv, bis der unerwünschte Tracking-Schutzmodus deaktiviert wird.

Der Anbieter überprüft, ob der bereitgestellte einmalige Authentifizierungsschlüssel mit dem unerwünschten Tracking-Schutzschlüssel übereinstimmt. Wenn der Anbieter nicht als FMDN-Beacon bereitgestellt wird oder die Überprüfung fehlschlägt, gibt er einen nicht authentifizierten Fehler zurück.

Wenn der Schutzmodus für unerwünschtes Tracking aktiviert ist, sollte das Beacon die Häufigkeit der MAC-Adressrotation auf einmal alle 24 Stunden reduzieren. Die beworbene sitzungsspezifische ID sollte wie gewohnt rotieren. Der Frame-Typ sollte auf 0 x 41 festgelegt sein. Der Status wird auch im Bereich Hash-Flags widergespiegelt.

Wenn der Schutzmodus für unerwünschtes Tracking deaktiviert wird

Der Dienstleister überprüft Folgendes:

  • Der angegebene Schlüssel zur einmaligen Authentifizierung stimmt mit dem unerwünschten Schutzschlüssel für das Tracking überein.
  • Der gehashte sitzungsspezifische Identitätsschlüssel stimmt mit dem aktuellen sitzungsspezifischen Identitätsschlüssel überein.

Wenn der Anbieter nicht als FMDN-Beacon bereitgestellt wird oder die Überprüfung fehlschlägt, gibt der Anbieter einen Fehler zurück, der nicht authentifiziert ist.

Wenn der Schutzmodus für unerwünschtes Tracking deaktiviert ist, sollte das Beacon die MAC-Adresse wieder normal mit der Rotation sitzungsspezifischer Kennungen synchronisieren. Der Frame-Typ sollte wieder auf 0x40 zurückgesetzt werden. Der Status wird auch im Abschnitt Hash-Flags widergespiegelt.

Bei Erfolg benachrichtigt der Anbieter mit einer Antwort aus Tabelle 6 mit der Daten-ID 0x07 oder 0x08.

Das Authentifizierungssegment ist als die ersten 8 Byte von HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) definiert.

Beworbene Frames

Nach der Bereitstellung wird erwartet, dass der Anbieter mindestens einmal alle 2 Sekunden FMDN-Frames anbietet. Wenn Frames für schnelles Pairing beworben werden, sollte der Anbieter die FMDN-Frames innerhalb des regulären Advertising für schnelles Pairing verschachteln. Beispielsweise sollte der Anbieter alle zwei Sekunden sieben Fast-Pair-Werbung und ein FMDN-Werbung anbieten.

Der FMDN-Frame enthält einen öffentlichen Schlüssel, mit dem Standortberichte von einem unterstützenden Client verschlüsselt werden, der zum Crowdsourcing-Netzwerk beiträgt. Es sind zwei Arten von Schlüsseln mit elliptischen Kurven verfügbar: ein 160-Bit-Schlüssel für ältere BLE 4-Frames oder ein 256-Bit-Schlüssel, der BLE 5 mit erweiterten Werbefunktionen erfordert. Die Implementierung des Anbieters bestimmt, welche Kurve verwendet wird.

Ein FMDN-Frame ist wie folgt aufgebaut.

Oktett Wert Beschreibung
0 0x02 Länge
1 0x01 Wert des Flags-Datentyps
2 0x06 Daten zu Flags
3 0x18 oder 0x19 Länge
4 0x16 Wert des Dienstdatentyps
5 0xAA 16-Bit-Dienst-UUID
6 0xFE ...
7 0x40 oder 0x41 FMDN-Frametyp mit Anzeige des Schutzmodus für unerwünschtes Tracking
8...27 Sitzungsspezifische 20-Byte-Kennung
28 Gehashte Flags

Tabelle 8:FMDN-Frame, der eine 160-Bit-Kurve unterstützt

Tabelle 9 zeigt die Byte-Offsets und -Werte für eine 256-Bit-Kurve.

Oktett Wert Beschreibung
0 0x02 Länge
1 0x01 Wert des Flags-Datentyps
2 0x06 Daten zu Flags
3 0x24 oder 0x25 Länge
4 0x16 Wert des Dienstdatentyps
5 0xAA 16-Bit-Dienst-UUID
6 0xFE ...
7 0x40 oder 0x41 FMDN-Frametyp mit Anzeige des Schutzmodus für unerwünschtes Tracking
8–39 Sitzungsspezifische 32-Byte-Kennung
40 Gehashte Flags

Tabelle 9:FMDN-Frame, der eine 256-Bit-Kurve unterstützt

Berechnung von flüchtigen Kennungen (EID)

Eine Zufallsauswahl wird von AES-ECB-256 generiert, das die folgende Datenstruktur mit dem sitzungsspezifischen Identitätsschlüssel verschlüsselt:

Oktett Field Beschreibung
0–10 Abstand Wert = 0xFF
11 K Exponent des Rotationszeitraums
12–15 TS[0]...TS[3] Beacon-Zeitzähler im 32-Bit-Big-Endian-Format. Die k-niedrigsten Bits werden gelöscht.
16–26 Abstand Wert = 0x00
27 K Exponent des Rotationszeitraums
28–31 TS[0]...TS[3] Beacon-Zeitzähler im 32-Bit-Big-Endian-Format. Die k-niedrigsten Bits werden gelöscht.

Tabelle 10:Konstruktion einer Pseudozufallszahl

Das Ergebnis dieser Berechnung ist eine 256-Bit-Zahl mit der Bezeichnung r'.

Für die restliche Berechnung werden SECP160R1 oder SECP256R1 für kryptografische Vorgänge mit elliptischer Kurve verwendet. Kurvendefinitionen finden Sie in SEC 2: Empfohlene Domainparameter für elliptische Kurven, in denen als Nächstes Fp, n und G definiert werden.

r' wird jetzt durch Berechnung von r = r' mod n auf das endliche Feld Fp projiziert. Berechnen Sie abschließend R = r * G. Dies ist ein Punkt auf der Kurve, der den verwendeten öffentlichen Schlüssel darstellt. Das Beacon bietet Rx als sitzungsspezifische Kennung an, bei der es sich um die x-Koordinate von R handelt.

Gehashte Flags

Das Feld der Hash-Flags wird wie folgt berechnet (Bits werden von der höchsten bis zur niedrigsten Signifikanz referenziert):

  • Bits 0–4: Reserviert (auf Nullen gesetzt).
  • Die Bits 5 bis 6 geben den Akkustand des Geräts so an:
    • 00: Anzeige des Akkustands wird nicht unterstützt
    • 01: Normaler Akkustand
    • 10: Akkustand niedrig
    • 11: Sehr niedriger Akkustand (der Akku muss bald ausgetauscht werden)
  • Wenn sich das Beacon im unerwünschten Tracking-Schutzmodus befindet, wird Bit 7 auf 1 gesetzt, andernfalls ist Bit 7 festgelegt.

Um den endgültigen Wert dieses Byte zu erzeugen, wird es mit dem niedrigstwertigen Byte SHA256(r) multipliziert.

Beachten Sie, dass r an der Größe der Kurve ausgerichtet sein muss. Fügen Sie Nullen als höchstwertige Bits hinzu, wenn die Darstellung kürzer als 160 oder 256 Bit ist, oder die wichtigsten Bits werden abgeschnitten, wenn sie größer als 160 oder 256 Bit ist.

Wenn das Beacon die Anzeige des Akkustands nicht unterstützt und sich nicht im unerwünschten Tracking-Schutzmodus befindet, darf dieses Byte vollständig aus der Anzeige entfernt werden.

Verschlüsselung mit EID

Zum Verschlüsseln einer Nachricht m würde ein Sichter, der Rx aus dem Beacon gelesen hat, Folgendes tun:

  1. Wählen Sie eine Zufallszahl s in Fp aus, wie im Abschnitt EID-Berechnung definiert.
  2. S = s * G berechnen.
  3. Berechnen Sie R = (Rx, Ry) durch Substitution in der Kurvengleichung und wählen Sie einen beliebigen Ry-Wert aus den möglichen Ergebnissen aus.
  4. Berechnet den 256-Bit-AES-Schlüssel k = HKDF-SHA256((s * R)x), wobei (s * R)x die x-Koordinate des Kurvenmultiplikationsergebnisses ist. Salt ist nicht angegeben.
  5. Lass URx und LRx die oberen bzw. unteren 80 Bit von Rx im Big-Endian-Format sein. Definieren Sie auf ähnliche Weise USx und LSx für S.
  6. nonce = LRx || LSx berechnen.
  7. (m’, tag) = AES-EAX-256-ENC(k, nonce, m) berechnen.
  8. Senden Sie (URx, Sx, m’, tag) an den Inhaber, möglicherweise über einen nicht vertrauenswürdigen Remote-Dienst.

Entschlüsselung von mit EID verschlüsselten Werten

Der Client des Eigentümers, der über den EIK und den Exponenten des Rotationszeitraums verfügt, entschlüsselt die Nachricht wie folgt:

  1. Mit URx wird der Wert des Beacon-Zeitzählers ermittelt, auf dem URx basiert. Dazu kann der Client des Inhabers Rx-Werte für Beacon-Zeitzählerwerte aus der jüngsten und der nahen Zukunft berechnen.
  2. Unter Berücksichtigung des Werts des Beacon-Zeitzählers, auf dem URx basiert, wird der erwartete Wert von r berechnet, wie im Abschnitt EID-Berechnung definiert.
  3. Berechne R = r * G und prüfe die Übereinstimmung mit dem vom Sucher bereitgestellten Wert URx.
  4. Berechnen Sie S = (Sx, Sy) durch Substitution in der Kurvengleichung und wählen Sie einen beliebigen Sy-Wert aus den möglichen Ergebnissen aus.
  5. k = HKDF-SHA256((r * S)x) berechnen, wobei (r * S)x die x-Koordinate des Kurvenmultiplikationsergebnisses ist.
  6. nonce = LRx || LSx berechnen.
  7. m = AES-EAX-256-DEC(k, nonce, m’, tag) berechnen.

ID-Rotation

Für Werbung für FMDN-Frames muss eine auflösbare (RPA) oder nicht auflösbare (NRPA) BLE-Adresse verwendet werden. RPA ist für LE Audio-Geräte (LEA) erforderlich und wird für andere Geräte empfohlen, mit Ausnahme von Locator-Tags, die kein Bonding verwenden.

Fast-Pair-Werbung, FMDN-Werbung und die entsprechenden BLE-Adressen sollten gleichzeitig rotieren. Die Rotation sollte im Durchschnitt alle 1.024 Sekunden erfolgen. Der genaue Punkt, ab dem das Beacon die neue ID bewirbt, muss innerhalb des Zeitfensters zufällig ausgewählt werden.

Der empfohlene Ansatz zur Randomisierung der Rotationszeit besteht darin, sie auf die nächste erwartete Rotationszeit (wenn keine Randomisierung angewendet wurde) plus einen positiven zufälligen Zeitfaktor im Bereich von 1 bis 204 Sekunden festzulegen.

Wenn sich das Gerät im unerwünschten Tracking-Schutzmodus befindet, sollte die BLE-Adresse des FMDN-Werbung korrigiert werden, aber die RPA für nicht erkennbare Werbung (z. B. schnelles Pairing) muss sich weiterhin drehen. Für die verschiedenen Protokolle können unterschiedliche Adressen verwendet werden.

Wiederherstellung nach Stromausfall

Das Auflösen der sitzungsspezifischen ID ist zum Zeitpunkt der Anzeige eng an den Taktwert gebunden. Daher ist es wichtig, dass der Provider bei einem Stromausfall seinen Uhrwert wiederherstellen kann. Es wird empfohlen, dass der Anbieter seinen aktuellen Taktwert mindestens einmal pro Tag in den nichtflüchtigen Speicher schreibt und beim Start die NVM prüft, ob ein Wert für die Initialisierung vorhanden ist. Resolver der sitzungsspezifischen Kennung implementieren die Auflösung über ein Zeitfenster, das ausreicht, um sowohl eine angemessene Taktabweichung als auch diese Art der Wiederherstellung nach Stromausfall zu ermöglichen.

Anbieter sollten dennoch alles daran setzen, die Zeitverschiebungen zu minimieren, da das Zeitfenster für die Problemlösung begrenzt ist. Es sollte mindestens eine zusätzliche Methode zur Taktsynchronisierung implementiert werden (Anzeigen von nicht auffindbaren Fast-Pair-Frames oder Implementierung des Nachrichtenstreams).

Implementierungsrichtlinien für „Schnelles Pairing“

In diesem Abschnitt werden besondere Aspekte der Implementierung des schnellen Pairings bei Anbietern beschrieben, die FMDN unterstützen.

Spezifische Richtlinien für Ortungs-Tags

  • Wenn der Anbieter gekoppelt wurde, die FMDN aber nicht innerhalb von 5 Minuten bereitgestellt wurde (oder wenn ein OTA-Update durchgeführt wurde, während das Gerät gekoppelt, aber nicht über die FMDN bereitgestellt wurde), sollte der Anbieter seine Werkseinstellungen zurücksetzen und die gespeicherten Kontoschlüssel löschen.
  • Nach dem Koppeln des Anbieters sollte er seine MAC-Adresse erst dann ändern, wenn der FMDN bereitgestellt wurde oder 5 Minuten vergangen sind.
  • Wenn der sitzungsspezifische Identitätsschlüssel vom Gerät gelöscht wird, sollte das Gerät auf die Werkseinstellungen zurückgesetzt und die gespeicherten Kontoschlüssel gelöscht werden.
  • Der Anbieter sollte normale Bluetooth-Kopplungsversuche ablehnen und nur die Kopplung über „Schnelles Pairing“ akzeptieren.
  • Der Anbieter muss einen Mechanismus implementieren, mit dem Nutzer die Werbung vorübergehend einstellen können, ohne das Gerät auf die Werkseinstellungen zurückzusetzen (z. B. durch Drücken einer Kombination von Schaltflächen).
  • Nach einem Stromausfall sollte das Gerät bis zum nächsten Aufruf der Lese-Beacon-Parameter nicht auffindbare Fast-Pair-Frames anbieten. Dadurch kann der Seeker das Gerät erkennen und die Uhr synchronisieren, auch wenn eine erhebliche Taktabweichung aufgetreten ist.
  • Wenn Sie nicht auffindbare Frames für schnelles Pairing bewerben, sollten keine UI-Anzeigen aktiviert werden.
  • Sichtbare Frames für schnelles Pairing sollten nicht beworben werden, solange der Anbieter für FMDN bereitgestellt ist.
  • Der Anbieter darf Informationen zur Identifizierung nicht ohne Authentifizierung preisgeben (z.B. Namen oder Kennzeichnungen).

Spezifische Richtlinien für klassische Bluetooth-Geräte

In diesem Abschnitt werden besondere Aspekte klassischer Bluetooth-Geräte beschrieben, die FMDN unterstützen.

FMDN-Bereitstellung bereits gekoppelter Geräte

Der Anbieter ist bei der Kopplung mit dem Seeker nicht immer für FMDN bereitgestellt. In diesem Fall hat der Anbieter möglicherweise keine aktuelle BLE-MAC-Adresse, die zum Herstellen einer GATT-Verbindung erforderlich ist. Der Anbieter muss mindestens eine der folgenden Möglichkeiten unterstützen, damit der Seeker seine BLE-Adresse erhält, während er bereits gekoppelt ist:

  • Der Anbieter kann regelmäßig die Kontodaten für schnelles Pairing anbieten, mit denen der Suchende seine BLE-Adresse über einen BLE-Scan finden kann.
    Dieser Ansatz eignet sich für Anbieter, die den Nachrichtenstream nicht implementieren.
  • Der Anbieter kann diese Daten über den Nachrichtenstream des schnellen Pairings über klassisches Bluetooth bereitstellen.
    Dieser Ansatz eignet sich für Anbieter, die „Schnelles Pairing“ nicht bewerben, während sie über Bluetooth mit dem Seeker verbunden sind.

Wenn beide Ansätze unterstützt werden, erhöht sich die Wahrscheinlichkeit, dass der Nutzer das Gerät für FMDN bereitstellen kann.

Nachrichtenstream durch schnelles Pairing

Der Anbieter kann den Nachrichtenstream für schnelles Pairing implementieren und den Suchenden über Geräteinformationen informieren. Durch das Implementieren des Nachrichtenstreams werden bestimmte Funktionen aktiviert, wie in diesem Abschnitt beschrieben.

Der Anbieter sollte jedes Mal, wenn der RFCOMM-Kanal des Nachrichtenstreams eingerichtet wird, Geräteinformationsnachrichten senden.

Firmwareversion (Geräteinformationscode 0x09) und Tracking-Funktion

Wenn ein Firmware-Update FMDN-Unterstützung zum Anbieter hinzufügt, kann ein verbundener Seeker den Nutzer darüber benachrichtigen und anbieten, ihn bereitzustellen. Andernfalls muss der Nutzer manuell die Bluetooth-Geräteliste aufrufen, um die FMDN-Bereitstellung zu starten.

Dazu sollte der Anbieter die Eigenschaft „Firmwareversion“ (Code 0x09) verwenden, um einen Stringwert zu melden, der die Firmwareversion darstellt. Darüber hinaus sollte der Anbieter das Protokoll unterstützen, mit dem der Seeker über Funktionsänderungen aufgrund von Firmware-Updates informiert wird.

Oktett Datentyp Beschreibung Wert
0 uint8 Ereignis „Geräteinformationen“ 0x03
1 uint8 Firmwareversion 0x09
2–3 uint16 Zusätzliche Datenlänge variiert
var Byte-Array Versionsstring variiert

Tabelle 11:Ereignis „Geräteinformationen“: aktualisierte Firmwareversion.

Wenn der Anbieter eine Anfrage zur Aktualisierung der Funktion (0x0601) erhält, sollte er wie in Tabelle 12 gezeigt reagieren, wenn er die Unterstützung für das FMDN-Tracking aktiviert hat.

Oktett Datentyp Beschreibung Wert
0 uint8 Synchronisierungsereignis für Gerätefunktion 0x06
1 uint8 FMDN-Tracking 0x03
2–3 uint16 Zusätzliche Datenlänge 0x0007
4 uint8 FMDN-Bereitstellungsstatus 0x00, wenn nicht bereitgestellt; 0x01, wenn von einem Konto bereitgestellt
5 - 10 Byte-Array Die aktuelle BLE-MAC-Adresse des Geräts variiert

Tabelle 12:Synchronisierungsereignis mit Gerätefunktion: Tracking-Funktion hinzugefügt

Aktuelle sitzungsspezifische ID (Geräteinformationscode 0x0B)

Der Anbieter kann die aktuelle sitzungsspezifische Kennung (Code 0x0B) verwenden, um die aktuelle EID und den Uhrwert zu melden, wenn der Anbieter für den FMDN bereitgestellt wird, um den Seeker bei einer Zeitabweichung zu synchronisieren (z. B. aufgrund eines entladenen Akkus). Andernfalls initiiert der Seeker zu diesem Zweck eine teurere und weniger zuverlässige Verbindung.

Oktett Datentyp Beschreibung Wert
0 uint8 Ereignis „Geräteinformationen“ 0x03
1 uint8 Aktuelle sitzungsspezifische ID 0 × 0 Mrd.
2–3 uint16 Zusätzliche Datenlänge 0x0018 oder 0x0024
4–7 Byte-Array Uhrzeitwert Beispiel: 0x13F9EA80
8–19 oder 31 Byte-Array Aktuelle EID Beispiel: 0x1122334455667788990011223344556677889900

Tabelle 13:Ereignis „Geräteinformationen: Synchronisierung der Uhr“.

Auf Werkseinstellungen zurücksetzen

Bei Geräten, die das Zurücksetzen auf die Werkseinstellungen unterstützen: Wenn das Zurücksetzen auf die Werkseinstellungen durchgeführt wird, muss der Dienstleister das Beaconing beenden und den sitzungsspezifischen Identitätsschlüssel sowie alle gespeicherten Kontoschlüssel, einschließlich des Kontoschlüssels des Inhabers, löschen.

Nach dem Zurücksetzen auf die Werkseinstellungen (entweder manuell oder programmatisch) sollte der Anbieter nicht sofort Werbung für „Schnelles Pairing“ schalten, um zu verhindern, dass der Kopplungsablauf direkt nach dem Löschen des Geräts durch den Nutzer beginnt.

Schutz vor unerwünschtem Tracking

Zertifizierte FMDN-Geräte müssen auch die Anforderungen der Implementierungsversion der plattformübergreifenden Spezifikation für die Erkennung unerwünschter Standort-Tracker (DULT) erfüllen.

Relevante Richtlinien speziell für FMDN zur Einhaltung der DULT-Spezifikation:

  • Jedes mit FMDN kompatible Gerät muss in der Konsole für Geräte in der Nähe registriert sein und die Funktion „Mein Gerät finden“ muss aktiviert sein.
  • Das Gerät muss den Nichtinhaberdienst für das Zubehör und die in der Implementierungsversion der DULT-Spezifikation definierte Eigenschaft implementieren, einschließlich der Vorgänge für Zubehörinformationen und Steuerelemente für Nichtinhaber.
  • Während des Zeitraums der Abwärtskompatibilität, wie in der DULT-Spezifikation definiert, gibt es keine Änderungen am beworbenen Frame, wie in diesem Dokument definiert.
  • Der in diesem Dokument definierte „Schutzmodus für unerwünschtes Tracking“ entspricht dem in der DULT-Spezifikation definierten „Separated State“.
  • Richtlinien zur Implementierung der Opcodes für Zubehörinformationen:
    • "Get_Product_Data" sollte die von der Konsole bereitgestellte Modell-ID zurückgeben. Diese muss mit Nullen aufgefüllt sein, um die 8-Byte-Anforderung zu erfüllen. Beispielsweise wird die Modell-ID 0xFFFFFF als 0x0000000000FFFFFF zurückgegeben.
    • Get_Manufacturer_Name und Get_Model_Name sollten mit den in der Konsole angegebenen Werten übereinstimmen.
    • Get_Accessory_Category kann den generischen Wert für „Location Tracker“ zurückgeben, wenn keine andere Kategorie besser zum Gerätetyp passt.
    • Get_Accessory_Capabilities muss angeben, dass Klingeln und BLE-Identifikator-Lookup unterstützt werden.
    • Get_Network_ID sollte die ID von Google (0x02) zurückgeben.
  • Richtlinien zur Implementierung des Opcodes Get_Identifier:
    • Der Vorgang sollte nur 5 Minuten lang eine gültige Antwort zurückgeben, nachdem der Nutzer den Modus „Identifikation“ aktiviert hat. Dafür ist eine Kombination aus Tastenbetätigungen erforderlich. Ein visuelles oder Audiosignal sollte den Nutzer darüber informieren, dass der Anbieter diesen Modus aktiviert hat. Die modellspezifischen Anweisungen zur Aktivierung dieses Modus müssen Google mindestens 10 Tage vor der Aktualisierung oder Änderung der Anleitung als Voraussetzung für die Zertifizierung zur Verfügung gestellt werden.
    • Die Antwort wird so erstellt: die ersten 10 Byte der aktuellen sitzungsspezifischen ID, gefolgt von den ersten 8 Byte von HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
  • Richtlinien zur Implementierung des Opcodes Sound_Start:
    • Der Befehl sollte in allen verfügbaren Komponenten das Klingeln auslösen.
    • Es sollte das maximal unterstützte Volume verwendet werden.
    • Die empfohlene Dauer für das Klingeln beträgt 12 Sekunden.
  • Such-Tags müssen einen Mechanismus enthalten, mit dem Nutzer die Werbung vorübergehend einstellen können, ohne das Gerät auf die Werkseinstellungen zurückzusetzen (z. B. durch Drücken einer Kombination von Schaltflächen).
    • Die Deaktivierungsanleitung muss unter einer öffentlich verfügbaren URL dokumentiert und Google als Voraussetzung für die Zertifizierung und mindestens 10 Tage vor der Aktualisierung oder Änderung der Anleitung zur Verfügung gestellt werden.
    • Die URL sollte lokalisiert werden können. Abhängig vom Client wird die Sprache entweder als Abfrageparameter ("hl=en") oder mithilfe des HTTP-Headers "accept-language" bereitgestellt.

Richtlinien für wechselbare Protokolle

  • Es sollte immer nur ein Protokoll verwendet werden. Achten Sie darauf, dass nicht mehr als ein Netzwerk gleichzeitig auf dem Gerät betrieben werden kann. Diese Anforderung ist erforderlich, um dafür zu sorgen, dass sensible Nutzerdaten nicht zwischen verschiedenen Protokollen vermischt werden.
  • Es wird empfohlen, einen Workflow zum Zurücksetzen auf die Werkseinstellungen in das Gerät einzubinden, mit dem Nutzer ein Gerät mit einem anderen Netzwerk neu einrichten können.
  • Das Aktualisieren eines Geräts auf ein Netzwerk sollte nutzerfreundlich und unter allen Netzwerken gleich sein. Ein Nutzer muss auswählen können, welches Netzwerk er verwenden möchte, ohne eines der Netzwerke zu bevorzugen. Dieser Ablauf muss vom Google-Team genehmigt werden.

Firmware updates

Der Prozess und die Verteilung von OTA-Updates sollte vom Partner mithilfe seines eigenen Workflows für mobile oder Web-Apps verwaltet werden.

Kompatibilität

Für „Mein Gerät finden“ müssen die Standortdienste und Bluetooth aktiviert sein. Es ist eine Mobilfunk- oder Internetverbindung erforderlich. Funktioniert mit Android 9 und höher und in bestimmten Ländern für Nutzer ab einem bestimmten Alter.

Änderungsprotokoll

FMDN-Version Datum Kommentar
v1 Erste Version der FMDN-Spezifikation für den Vorabzugriff.
v1.1 Feb. 2023
  • Es wurde eine Klartextanzeige für den Schutzmodus für unerwünschtes Tracking hinzugefügt.
  • Es wurde eine Option hinzugefügt, mit der die Authentifizierung von klingelnden Anfragen im Schutzmodus für unerwünschtes Tracking übersprungen werden kann.
v1.2 April 2023
  • Die Definition des Alias eines Inhabers wurde aktualisiert.
  • In Locator-Tags wurde eine Empfehlung zur Wiederherstellung nach einem Stromausfall hinzugefügt.
  • Eine Klarstellung für die zufällige Anordnung von MAC-Adressen wurde hinzugefügt.
  • Es wurde eine Klarstellung zur MAC-Adressrotation im Schutzmodus für unerwünschtes Tracking hinzugefügt.
  • Wir haben eine Richtlinie hinzugefügt, die erläutert, wie man ein Tag für die Standortsuche deaktivieren kann.
v1.3 Dez. 2023
  • Wir haben eine Klarstellung zur Identifizierung von Informationen hinzugefügt, die über Locator-Tags offengelegt werden.
  • Es wurde eine Anforderung hinzugefügt, um die Spezifikation zum Schutz vor unerwünschtem Tracking zu implementieren.
  • Richtlinien für Geräte mit wechselbaren Protokolldaten hinzugefügt.