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

v1.3

Die Zubehörspezifikation für das „Mein Gerät finden“-Netzwerk (FMDN) definiert einen Ende-zu-Ende-verschlüsselten Ansatz zum Tracking von Bluetooth Low Energy-Geräten (BLE), die Beacons senden. Auf dieser Seite wird FMDN als Erweiterung der Fast Pair-Spezifikation beschrieben. Anbieter sollten diese Erweiterung aktivieren, wenn sie Geräte haben, die mit FMDN kompatibel sind, und das Standort-Tracking für diese Geräte aktivieren möchten.

GATT-Spezifikation

Dem Fast Pair-Dienst sollte ein zusätzliches GATT-Attribut (Generic Attributes) mit der folgenden Semantik hinzugefügt werden:

Fast Pair-Diensteigenschaft Verschlüsselt Berechtigungen UUID
Beacon-Aktionen Nein Lesen, schreiben und benachrichtigen FE2C1238-8366-4814-8EB0-01DE32100BEA

Tabelle 1:Eigenschaften des schnellen Pairing-Dienstes für FMDN

Authentifizierung

Die von dieser Erweiterung erforderlichen Vorgänge werden als Schreibvorgang ausgeführt und durch einen Abfrage-Antwortmechanismus gesichert. Bevor ein Vorgang ausgeführt wird, muss der Sucher einen Lesevorgang von der Eigenschaft in Tabelle 1 ausführen. Dies führt zu einem Puffer im folgenden Format:

Oktett Datentyp Beschreibung Wert
0 uint8 Hauptversionsnummer des Protokolls 0x01
1–8 Byte-Array Einmaliger zufälliger Nonce variiert

Jeder Lesevorgang sollte zu einem anderen Nonce führen und ein einzelner Nonce sollte nur für einen einzelnen Vorgang gültig sein. Der Nonce muss auch dann ungültig gemacht werden, wenn der Vorgang fehlgeschlagen ist.

Der Seeker 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. Je nach angefordertem Vorgang muss der Suchende nachweisen, dass er einen oder mehrere der folgenden Schlüssel kennt:

Vorgänge

Das Format der Daten, die in das Attribut geschrieben werden, ist in den Tabellen 2 bis 5 angegeben. Die einzelnen Vorgänge werden weiter unten in diesem Abschnitt ausführlicher beschrieben.

Oktett Datentyp Beschreibung Wert
0 uint8 Daten-ID
  • 0x00: Beacon-Parameter lesen
  • 0x01: Bereitstellungsstatus lesen
  • 0x02: Schlüssel für die sitzungsspezifische Identität festlegen
  • 0x03: Klarer sitzungsspezifischer Identitätsschlüssel
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, der sitzungsspezifische Identitätsschlüssel, AES-ECB-128-verschlüsselt mit dem Kontoschlüssel. 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: Schlüssel für sitzungsspezifische Identität 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 zum Wiederherstellen des Schlüssels für die Beacon-Bereitstellung

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 Klingellautstärke angeben.
  • 0x06: –

Tabelle 4:Anrufanfrage

Oktett Datentyp Beschreibung Wert
0 uint8 Daten-ID
  • 0x07: Modus zum Schutz vor unerwünschtem Tracking aktivieren
  • 0x08: Modus zum Schutz vor unerwünschtem 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 mit Steuerflags (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, die in Tabelle 6 aufgeführt sind.

Benachrichtigungen mit einer anderen Daten-ID als 0x05: Ringstatusänderung sollten gesendet werden, bevor die Schreibtransaktion, die die Benachrichtigung auslöst, abgeschlossen ist, d. h. 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: Schlüssel für die sitzungsspezifische Identität festlegen
  • 0x03: Klarer sitzungsspezifischer Identitätsschlüssel
  • 0x04: Schlüssel für sitzungsspezifische Identität mit Nutzereinwilligung lesen
  • 0x05: Statusänderung des Rings
  • 0x06: Klingeltonstatus lesen
  • 0x07: Modus zum Schutz vor unerwünschtem Tracking aktivieren
  • 0x08: Modus zum Schutz vor unerwünschtem Tracking deaktivieren
1 uint8 Datenlänge variiert
2–9 Byte-Array Authentifizierung Detaillierte Informationen zu einzelnen Vorgängen
10 – var Byte-Array Zusätzliche Daten
  • 0x00: 8 Byte, die die Übertragungsleistung, den Taktwert, die Verschlüsselungsmethode und die Klingeltonfunktionen angeben, AES-ECB-128-verschlüsselt mit dem Kontoschlüssel (mit Nullen aufgefüllt)
  • 0x01: 1 Byte, das den Bereitstellungsstatus angibt, gefolgt von der aktuellen sitzungsspezifischen ID (20 oder 32 Byte)
  • 0x04: 32 Byte, der sitzungsspezifische Identitätsschlüssel, AES-ECB-128-verschlüsselt mit dem Kontoschlüssel
  • 0x05: 4 Byte, die den neuen Status und den Trigger für die Änderung angeben
  • 0x06: 3 Byte, die die Komponenten angeben, die gerade klingeln, und die Anzahl der verbleibenden Dezisekunden für das Klingeln
  • Für andere 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 in einer Antwort auf eine Schreibanfrage zurückgegeben, wenn die Authentifizierung fehlschlägt (einschließlich des Falls, dass ein altes 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 enthalten.
0x82 Keine Nutzereinwilligung Wird in Antwort auf eine Schreibanfrage mit der Daten-ID 0x04: Schlüssel für sitzungsspezifische Identität mit Nutzereinwilligung lesen zurückgegeben, wenn sich das Gerät nicht im Kopplungsmodus befindet.

Tabelle 7:GATT-Fehlercodes

Parameter des Beacons lesen

Der Sucher kann den Anbieter nach den Parametern des Beacons fragen, indem er einen Schreibvorgang für das Merkmal ausführt, der aus einer Anfrage aus Tabelle 2 mit der Daten-ID 0x0 besteht. Der Anbieter prüft, ob der bereitgestellte Einmalauthentifizierungsschlü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 0x00. Der Anbieter erstellt das Datensegment so:

Oktett Datentyp Beschreibung Wert
0 uint8 Kalibrierte Leistung Die kalibrierte Leistung, wie sie in 0 m empfangen wurde (ein Wert im Bereich [−100, 20]). Wird als vorzeichenbehaftete Ganzzahl mit einer Auflösung von 1 dBm dargestellt.
1–4 uint32 Taktwert Der aktuelle Taktwert in Sekunden (Big-Endian-Format).
5 uint8 Kurvenauswahl Die für die Verschlüsselung verwendete elliptische Kurve:
  • 0x00 (Standard): SECP160R1
  • 0x01: SECP256R1 (erfordert erweiterte Anzeigen)
6 uint8 Komponenten Anzahl der klingelnden Komponenten:
  • 0x00: Gibt an, dass das Gerät nicht klingeln kann.
  • 0x01: Gibt an, dass nur eine einzige Komponente klingeln kann.
  • 0x02: Gibt an, dass zwei Komponenten, der linke und der rechte In-Ear-Kopfhörer, unabhängig voneinander klingeln können.
  • 0x03: Gibt an, dass drei Komponenten – linker und rechter In-Ear-Kopfhörer und das Case – unabhängig voneinander klingeln können.
7 uint8 Klingelfunktionen Folgende Optionen werden unterstützt:
  • 0x00: Die Auswahl der Klingeltonlautstärke ist nicht verfügbar.
  • 0x01: Lautstärke der Klingel kann ausgewählt werden. Wenn diese Option festgelegt ist, muss der Anbieter drei Lautstärkestufen akzeptieren und verarbeiten, wie unter Gongvorgang angegeben.
8–15 Byte-Array Abstand Null-Padding für die AES-Verschlüsselung.

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

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 Sucher kann den Anbieter nach dem Bereitstellungsstatus des Beacons fragen, indem er einen Schreibvorgang für das Merkmal ausführt, der aus einer Anfrage aus Tabelle 2 mit der Daten-ID 0x01 besteht. Der Anbieter prüft, ob der angegebene 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): Ist gesetzt, wenn für das Gerät ein sitzungsspezifischer Identitätsschlüssel festgelegt ist.
  • Bit 2 (0x02): Ist gesetzt, wenn der angegebene Einmalauthentifizierungsschlüssel mit dem Schlüssel des Inhaberkontos übereinstimmt.
1–20 oder 32 Byte-Array Aktuelle sitzungsspezifische Kennung 20 oder 32 Byte (je nach verwendeter Verschlüsselungsmethode), die die aktuelle sitzungsspezifische ID angeben, die vom Beacon gesendet wird, 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.

Schlüssel für sitzungsspezifische Identität festlegen

Wenn ein nicht bereitgestellter Anbieter als FMDN-Beacon bereitgestellt oder der Schlüssel für die sitzungsspezifische Identität eines bereits bereitgestellten Anbieters geändert werden soll, führt der Sucher einen Schreibvorgang für das Merkmal aus, der aus einer Anfrage aus Tabelle 2 mit der Daten-ID 0x02 besteht. Der Anbieter bestätigt, dass:

  • Der angegebene Einmalauthentifizierungsschlüssel 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, prüfen Sie, ob der Anbieter 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 mit AES-ECB-128 wiederhergestellt, indem er mit dem übereinstimmenden Kontoschlüssel entschlüsselt wird. Der Schlüssel sollte auf dem Gerät gespeichert werden und ab diesem Zeitpunkt sollte der Anbieter FMDN-Frames ankündigen. Der neue sitzungsspezifische Identitätsschlüssel wird sofort nach dem Beenden der BLE-Verbindung wirksam. 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.

Schlüssel für die sitzungsspezifische Identität löschen

Um den Beacon-Teil des Anbieters zu entprovisionieren, führt der Sucher einen Schreibvorgang für das Merkmal aus, der aus einer Anfrage aus Tabelle 2 mit der Daten-ID 0x03 besteht. Der Anbieter bestätigt, dass:

  • Der angegebene Einmalauthentifizierungsschlüssel 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 ist oder die Überprüfung fehlschlägt, wird ein nicht authentifizierter Fehler zurückgegeben.

Bei Erfolg vergisst der Anbieter den Schlüssel und hört auf, FMDN-Frames zu senden. 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.

Schlüssel für die sitzungsspezifische Identität mit Nutzereinwilligung lesen

Diese Option ist nur zum Wiederherstellen eines verlorenen Schlüssels verfügbar, da der Schlüssel nur lokal vom Sucher 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 Sucher muss den Wiederherstellungsschlüssel im Backend speichern, um den Klartextschlüssel wiederherstellen zu können. Der EIK selbst wird jedoch nicht gespeichert.

Um die EIK zu lesen, führt der Sucher einen Schreibvorgang für das Merkmal aus, der aus einer Anfrage aus Tabelle 3 mit der Daten-ID 0x04 besteht. Der Anbieter bestätigt, dass:

  • 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.

Bei Erfolg 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 Sucher kann den Dienstanbieter 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): Links klingeln lassen
  • Bit 3 (0x04): Ringgehäuse
  • 0xFF: Alle Komponenten klingeln lassen
  • 0x00: Klingeln beenden
1–2 uint16 Zeitlimit Das Zeitlimit in Dezisekunden. Der Wert darf nicht null sein und darf nicht länger als 10 Minuten sein.
Anhand dieses Werts bestimmt der Anbieter, wie lange das Klingeln dauern soll, bevor das Gerät stummgeschaltet wird. Die Zeitüberschreitung überschreibt die bereits gültige Zeitüberschreitung, wenn eine Komponente des Geräts bereits klingelt.

Wenn Ringvorgang auf 0x00 gesetzt ist, wird das Zeitlimit ignoriert.
3 uint8 Lautstärke
  • 0x00: Standard
  • 0x01: Niedrig
  • 0x02: Mittel
  • 0x03: Hoch
Die genaue Bedeutung dieser Werte ist von der Implementierung abhängig.

Nach Erhalt des Antrags prüft der Anbieter Folgendes:

  • Der angegebene Einmalauthentifizierungsschlüssel 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 ist oder die Überprüfung fehlschlägt, wird ein nicht authentifizierter Fehler zurückgegeben. Wenn der Anbieter jedoch den Schutz vor unerwünschtem Tracking aktiviert hat und für die auslösende Anfrage zum Schutz vor unerwünschtem Tracking das Flag „Authentifizierung über Klingeln überspringen“ aktiviert war, sollte der Anbieter diese Prüfung überspringen. Die Authentifizierungsdaten müssen weiterhin vom Suchenden bereitgestellt werden, können aber auf einen beliebigen Wert festgelegt werden.

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

Oktett Datentyp Beschreibung Wert
0 uint8 Klingelstatus
  • 0x00: Gestartet
  • 0x01: Starten oder Beenden fehlgeschlagen (alle angeforderten Komponenten liegen außerhalb des Bereichs)
  • 0x02: Angehalten (Zeitüberschreitung)
  • 0x03: Angehalten (Taste gedrückt)
  • 0x04: Angehalten (GATT-Anfrage)
1 uint8 Klingelkomponenten Eine Bitmaske der Komponenten, die in der Anfrage definiert sind und gerade klingeln.
2–3 uint16 Zeitlimit Die verbleibende Klingelzeit 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 bereits im angeforderten Klingeltonstatus befindet, wenn eine Anfrage zum Klingeln oder zum Beenden des Klingelns empfangen wird, sollte der Anbieter eine Benachrichtigung mit dem Klingeltonstatus oder 0x00: Started oder 0x04: Stopped (GATT-Anfrage) senden. Mit dieser Anfrage werden die Parameter des vorhandenen Status überschrieben, damit die Klingeldauer verlängert werden kann.

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

Klingelstatus des Beacons abrufen

Um den Klingelstatus des Beacons abzurufen, führt der Sucher einen Schreibvorgang für das Merkmal aus, der aus einer Anfrage aus Tabelle 4 mit der Daten-ID 0x06 besteht. Der Anbieter prüft, ob der angegebene Einmalauthentifizierungsschlüssel mit dem Ringschlüssel übereinstimmt.

Wenn der Anbieter nicht als FMDN-Beacon bereitgestellt ist oder 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 0x06. Der Anbieter erstellt das Datensegment so:

Oktett Datentyp Beschreibung Wert
0 uint8 Klingelkomponenten Die Komponenten, die laut Klingeltonanfrage aktiv klingeln.
1–2 uint16 Zeitlimit Die verbleibende Klingelzeit 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.

Modus zum Schutz vor unerwünschtem Tracking

Mit dem Modus zum Schutz vor unerwünschtem Tracking können alle Clients Geräte erkennen, die missbräuchlich verwendet werden und keine Serverkommunikation haben. Standardmäßig sollte der Anbieter alle IDs wie unter ID-Rotation beschrieben rotieren. Der Dienst „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 veranlasst der Dienst den Anbieter, vorübergehend eine feste MAC-Adresse zu verwenden, damit Clients das Gerät erkennen und den Nutzer vor möglichem unerwünschten Tracking warnen können.

Um den Modus zum Schutz vor unerwünschtem Tracking des Beacons zu aktivieren oder zu deaktivieren, führt der Sucher einen Schreibvorgang für das Attribut aus, der aus einer Anfrage aus Tabelle 5 mit der Daten-ID 0x07 bzw. 0x08 besteht.

Wenn Sie den Modus zum Schutz vor unerwünschtem Tracking aktivieren

Der Anbieter erstellt das Datensegment so:

Oktett Datentyp Beschreibung Wert
0 uint8 Steuerflags
  • 0x01: Authentifizierung beim Klingeln überspringen. Wenn diese Einstellung aktiviert ist, werden Klingelanfragen im Modus zum Schutz vor unerwünschtem Tracking nicht authentifiziert.
Wenn kein Flag gesetzt wird (das Byte besteht nur aus Nullen), ist es zulässig, den Datenabschnitt vollständig zu erlassen und einen leeren Datenabschnitt zu senden.
Die Flags sind nur wirksam, bis der Modus zum Schutz vor unerwünschtem Tracking deaktiviert wird.

Der Anbieter prüft, ob der angegebene Einmalauthentifizierungsschlüssel mit dem Schlüssel für den Schutz vor unerwünschtem Tracking übereinstimmt. Wenn der Anbieter nicht als FMDN-Beacon bereitgestellt ist oder die Überprüfung fehlschlägt, wird ein nicht authentifizierter Fehler zurückgegeben.

Wenn der Modus zum Schutz vor unerwünschtem Tracking aktiviert ist, sollte das Beacon die Rotationsfrequenz der MAC-Privatadresse auf einmal pro 24 Stunden reduzieren. Die beworbene sitzungsspezifische Kennung sollte wie gewohnt rotieren. Der Frame-Typ sollte auf 0x41 festgelegt sein. Der Status wird auch im Abschnitt Hash-Flags angezeigt.

Wenn der Schutz vor unerwünschtem Tracking deaktiviert wird

Der Anbieter bestätigt, dass:

  • Der angegebene einmalige Authentifizierungsschlüssel stimmt mit dem Schlüssel für den Schutz vor unerwünschtem 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 ist oder die Überprüfung fehlschlägt, gibt der Anbieter einen nicht authentifizierten Fehler zurück.

Wenn der Modus zum Schutz vor unerwünschtem Tracking deaktiviert ist, sollte das Beacon die MAC-Adresse wieder mit normaler Geschwindigkeit rotieren, synchronisiert mit der Rotation der sitzungsspezifischen IDs. Der Frametyp sollte wieder auf 0x40 gesetzt werden. Der Status wird auch im Abschnitt Hash-Flags angezeigt.

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 muss der Anbieter mindestens alle zwei Sekunden FMDN-Frames ankündigen. Wenn Fast Pair-Frames beworben werden, sollte der Anbieter die FMDN-Frames in die regulären Fast Pair-Anzeigen einfügen. Beispielsweise sollte der Anbieter alle zwei Sekunden sieben Fast Pair-Anzeigen und eine FMDN-Anzeige senden.

Die übertragene Bluetooth-Sendeleistung für FMDN-Anzeigen sollte mindestens 0 dBm betragen.

Der FMDN-Frame enthält einen öffentlichen Schlüssel, mit dem Standortberichte von allen unterstützenden Clients verschlüsselt werden, die zum Crowdsourcing-Netzwerk beitragen. Es sind zwei Arten von elliptischen Kurvenschlüsseln verfügbar: ein 160-Bit-Schlüssel, der zu älteren BLE 4-Frames passt, oder ein 256-Bit-Schlüssel, der BLE 5 mit erweiterten Werbefunktionen erfordert. Welche Kurve verwendet wird, hängt von der Implementierung des Anbieters ab.

Ein FMDN-Frame ist so aufgebaut:

Oktett Wert Beschreibung
0 0x02 Länge
1 0x01 Wert des Datentyps „Flags“
2 0x06 Flags-Daten
3 0x18 oder 0x19 Länge
4 0x16 Wert für den Datentyp der Dienstdaten
5 0xAA 16-Bit-Dienst-UUID
6 0xFE …
7 0x40 oder 0x41 FMDN-Frametyp mit Angabe des Modus für den Schutz vor unerwünschtem Tracking
8..27 20-Byte-sitzungsspezifische Kennung
28 Hash-Flags

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

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

Oktett Wert Beschreibung
0 0x02 Länge
1 0x01 Wert des Datentyps „Flags“
2 0x06 Flags-Daten
3 0x24 oder 0x25 Länge
4 0x16 Wert für den Datentyp der Dienstdaten
5 0xAA 16-Bit-Dienst-UUID
6 0xFE …
7 0x40 oder 0x41 FMDN-Frametyp mit Angabe des Modus für den Schutz vor unerwünschtem Tracking
8.39 32-Byte-sitzungsspezifische Kennung
40 Hash-Flags

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

Berechnung der sitzungsspezifischen Kennung (EID)

Ein Zufallszahlengenerator wird durch AES-ECB-256 generiert, indem die folgende Datenstruktur mit dem sitzungsspezifischen Identitätsschlüssel verschlüsselt wird:

Oktett Feld Beschreibung
0–10 Abstand Wert = 0xFF
11 K Exponent für den Rotationszeitraum
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 für den Rotationszeitraum
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, die mit r' bezeichnet wird.

Für den Rest der Berechnung werden SECP160R1 oder SECP256R1 für kryptografische Operationen mit elliptischen Kurven verwendet. Siehe Kurvendefinitionen in Abschnitt 2: Empfohlene Parameter für elliptische Kurvendomänen, in denen Fp, n und G definiert werden, auf die im Folgenden verwiesen wird.

r' wird jetzt durch Berechnung von r = r' mod n auf das endliche Feld Fp projiziert. Berechnen Sie abschließend R = r * G, einen Punkt auf der Kurve, der den verwendeten öffentlichen Schlüssel darstellt. Der Beacon sendet Rx, die x-Koordinate von R, als sitzungsspezifische Kennung.

Gehashte Flags

Das Feld „Hash-Flags“ wird so berechnet (Bits werden vom höchstwertigen zum niedrigstwertigen Bit referenziert):

  • Bits 0–4: Reserviert (auf Null gesetzt).
  • Die Bits 5 und 6 geben den Akkustand des Geräts an:
    • 00: Akkustandanzeige wird nicht unterstützt
    • 01: Normaler Akkustand
    • 10: Niedriger Akkustand
    • 11: Akkustand sehr niedrig (Akku bald wechseln)
  • Bit 7 ist auf „1“ gesetzt, wenn sich das Beacon im Modus zum Schutz vor unerwünschtem Tracking befindet, andernfalls auf „0“.

Um den endgültigen Wert dieses Bytes zu erhalten, wird es mit dem niedrigstwertigen Byte von SHA256(r) verwürfelt.

Beachten Sie, dass „r“ an die Größe der Kurve angepasst werden sollte. Fügen Sie Nullen als höchstwertige Bits hinzu, wenn die Darstellung kürzer als 160 oder 256 Bit ist. Die höchstwertigen Bits sollten gekürzt werden, wenn die Darstellung länger als 160 oder 256 Bit ist.

Wenn das Beacon keine Akkustandsanzeige unterstützt und sich nicht im Modus zum Schutz vor unerwünschtem Tracking befindet, darf dieses Byte aus der Werbung vollständig weggelassen werden.

Verschlüsselung mit EID

Um eine Nachricht m zu verschlüsseln, geht ein Beobachter, der Rx vom Beacon gelesen hat, so vor:

  1. Wählen Sie eine zufällige Zahl s in Fp aus, wie im Abschnitt EID-Berechnung definiert.
  2. Berechnen Sie S = s * G.
  3. Berechnen Sie R = (Rx, Ry), indem Sie die Kurvengleichung einsetzen und einen beliebigen Ry-Wert aus den möglichen Ergebnissen auswählen.
  4. Berechnen Sie den 256‑Bit-AES-Schlüssel k = HKDF-SHA256((s * R)x), wobei (s * R)x die x-Koordinate des Kurvenmultiplikationsergebnisses ist. Das Salt ist nicht angegeben.
  5. Angenommen, URx und LRx sind die oberen und unteren 80 Bit von Rx im Big-Endian-Format. Definieren Sie auf ähnliche Weise USx und LSx für S.
  6. Berechnen Sie nonce = LRx || LSx.
  7. Berechnen Sie (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
  8. (URx, Sx, m’, tag) an den Eigentümer senden, möglicherweise über einen nicht vertrauenswürdigen Remotedienst.

Entschlüsselung von mit EID verschlüsselten Werten

Der Client des Eigentümers, der die EIK und den Exponenten für die Rotationsperiode hat, entschlüsselt die Nachricht so:

  1. Ermitteln Sie anhand von URx den Wert des Beacon-Zeitzählers, auf dem URx basiert. Dazu kann der Kunde des Eigentümers Rx-Werte für Beacon-Zeitzählerwerte für die jüngere Vergangenheit und die nahe Zukunft berechnen.
  2. Berechnen Sie anhand des Beacon-Zeitzählerwerts, auf dem URx basiert, den erwarteten Wert von r, wie im Abschnitt EID-Berechnung definiert.
  3. Berechnen Sie R = r * G und prüfen Sie, ob der Wert mit dem von der Sichtungssoftware angegebenen Wert für URx übereinstimmt.
  4. Berechnen Sie S = (Sx, Sy), indem Sie die Kurvengleichung einsetzen und einen beliebigen Sy-Wert aus den möglichen Ergebnissen auswählen.
  5. Berechnen Sie k = HKDF-SHA256((r * S)x), wobei (r * S)x die x-Koordinate des Kurvenmultiplikationsergebnisses ist.
  6. Berechnen Sie nonce = LRx || LSx.
  7. Berechnen Sie m = AES-EAX-256-DEC(k, nonce, m’, tag).

ID-Rotation

Für die 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, bei denen keine Kopplung verwendet wird.

Fast Pair-Anzeigen, FMDN-Anzeigen und die entsprechenden BLE-Adressen sollten gleichzeitig rotieren. Die Rotation sollte durchschnittlich alle 1.024 Sekunden erfolgen. Der genaue Zeitpunkt, zu dem der Beacon mit der Ausstrahlung der neuen Kennung beginnt, muss innerhalb des Zeitfensters zufällig festgelegt werden.

Wir empfehlen, die Zufallsrotationszeit auf die nächste erwartete Rotationszeit (falls keine Zufallsmix-Funktion verwendet wurde) plus einen positiven, zufälligen Zeitfaktor im Bereich von 1 bis 204 Sekunden festzulegen.

Wenn sich das Gerät im Modus zum Schutz vor unerwünschtem Tracking befindet, sollte die BLE-Adresse der FMDN-Anzeigen unveränderlich sein. Die RPA für nicht auffindbare FP-Anzeigen (z. B. „Schnelles Pairing“) muss jedoch weiter rotieren. Es ist zulässig, für die verschiedenen Protokolle unterschiedliche Adressen zu verwenden.

Wiederherstellung nach einem Stromausfall

Die Auflösung der sitzungsspezifischen Kennung ist stark mit ihrem Zeitwert zum Zeitpunkt der Werbung verknüpft. Daher ist es wichtig, dass der Anbieter seinen Zeitwert bei einem Stromausfall wiederherstellen kann. Es wird empfohlen, dass der Anbieter seinen aktuellen Taktwert mindestens einmal täglich in den nichtflüchtigen Speicher schreibt und beim Starten prüft, ob ein Wert vorhanden ist, der initialisiert werden kann. Resolver der sitzungsspezifischen Kennung implementieren die Auflösung über ein Zeitfenster, das sowohl eine angemessene Uhrenabweichung als auch diese Art der Wiederherstellung nach einem Stromausfall zulässt.

Anbieter sollten jedoch alles tun, um Zeitabweichungen zu minimieren, da das Zeitfenster für die Behebung begrenzt ist. Es sollte mindestens eine zusätzliche Methode zur Uhrensynchronisierung implementiert werden (Anzeigen von nicht auffindbaren Fast Pair-Frames oder Implementierung des Nachrichtenstreams).

Leitlinien für die Implementierung von „Schnelles Pairing“

In diesem Abschnitt werden spezielle Aspekte der Fast Pair-Implementierung bei Anbietern beschrieben, die FMDN unterstützen.

Richtlinien für Locator-Tags

  • Wenn der Anbieter gekoppelt wurde, die FMDN-Bereitstellung aber nicht innerhalb von 5 Minuten erfolgte (oder wenn ein Over-the-air-Update angewendet wurde, während das Gerät gekoppelt, aber nicht für FMDN bereitgestellt wurde), sollte der Anbieter zur Werkseinstellung zurückkehren und die gespeicherten Kontoschlüssel löschen.
  • Nachdem der Anbieter gekoppelt wurde, sollte er seine MAC-Adresse nicht ändern, bis 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 auch 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 bereitstellen, mit dem Nutzer Werbung vorübergehend deaktivieren können, ohne das Gerät auf die Werkseinstellungen zurücksetzen zu müssen (z. B. durch Drücken einer Tastenkombination).
  • Nach einem Stromausfall sollte das Gerät bis zur nächsten Aufrufung von read beacon parameters nicht auffindbare Fast Pair-Frames senden. So kann der Sucher das Gerät erkennen und die Uhr synchronisieren, auch wenn eine erhebliche Abweichung aufgetreten ist.
  • Wenn Sie nicht auffindbare Fast Pair-Frames bewerben, sollten keine UI-Hinweise aktiviert sein.
  • Sichtbare Fast Pair-Frames sollten nicht beworben werden, während der Anbieter für FMDN bereitgestellt wird.
  • Der Anbieter darf keine identifizierenden Informationen (z.B. Namen oder Kennungen) auf nicht authentifizierte Weise offenlegen.

Gerätespezifische Richtlinien für Bluetooth Classic

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

FMDN-Bereitstellung bereits gekoppelter Geräte

Der Anbieter ist nicht immer für FMDN eingerichtet, wenn er mit dem Sucher gekoppelt wird, sondern erst einige Zeit danach. 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 Sucher seine BLE-Adresse abrufen kann, während er bereits gekoppelt ist:

  • Der Anbieter kann regelmäßig die Fast Pair-Kontodaten veröffentlichen, mit denen der Sucher 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 Fast Pair-Nachrichtenstream über klassisches Bluetooth bereitstellen.
    Dieser Ansatz eignet sich für Anbieter, die keine Fast Pair-Frames angeben, während sie über Bluetooth mit dem Sucher 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.

Fast Pair-Nachrichtenstream

Der Anbieter kann den Fast Pair-Nachrichtenstream implementieren und damit den Sucher über Geräteinformationen informieren. Durch die Implementierung des Nachrichtenstreams werden bestimmte Funktionen aktiviert, die in diesem Abschnitt beschrieben werden.

Der Anbieter sollte jedes Mal, wenn der RFCOMM-Kanal für den Nachrichtenstream hergestellt wird, Nachrichten mit Geräteinformationen senden.

Firmwareversion (Geräteinformationen-Code 0x09) und die Tracking-Funktion

Wenn ein Firmwareupdate dem Anbieter FMDN-Unterstützung hinzufügt, kann ein verbundener Sucher den Nutzer darüber informieren und ihm anbieten, die Funktion zu aktivieren. Andernfalls muss der Nutzer manuell zur Bluetooth-Geräteliste wechseln, um die FMDN-Bereitstellung zu starten.

Dazu muss der Anbieter die Eigenschaft „Firmwareversion“ (Code 0x09) verwenden, um einen Stringwert für die Firmwareversion anzugeben. Außerdem sollte der Anbieter das Protokoll unterstützen, über das der Sucher über Änderungen der Funktionen aufgrund von Firmwareupdates informiert wird.

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

Tabelle 11:Ereignis „Geräteinformationen“: Aktualisierte Firmwareversion

Wenn der Anbieter den Support für das FMDN-Tracking aktiviert hat, sollte er bei Erhalt einer Anfrage zum Aktualisieren der Funktionen (0x0601) wie in Tabelle 12 beschrieben antworten.

Oktett Datentyp Beschreibung Wert
0 uint8 Ereignis „Gerätefunktionssynchronisierung“ 0x06
1 uint8 FMDN-Tracking 0x03
2–3 uint16 Zusätzliche Datenlänge 0x0007
4 uint8 Status der FMDN-Bereitstellung 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:Ereignis zur Gerätefunktionssynchronisierung: Tracking-Funktion hinzugefügt

Aktuelle Sitzungs-ID (Geräteinformationen-Code 0x0B)

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

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

Tabelle 13:Ereignis „Geräteinformationen: Uhrsynchronisierung“

Auf Werkseinstellungen zurücksetzen

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

Nach einem Zurücksetzen auf die Werkseinstellungen (manuell oder programmatisch) sollte der Anbieter nicht sofort mit der Werbung für Fast Pairing beginnen, um zu verhindern, dass der Kopplungsvorgang sofort nach dem Löschen des Geräts gestartet wird.

Schutz vor unerwünschtem Tracking

Zertifizierte FMDN-Geräte müssen außerdem die Anforderungen in der Implementierungsversion der plattformübergreifenden Spezifikation für die Erkennung unerwünschter Standort-Tracker (Detecting Unwanted Location Trackers, DULT) erfüllen.

Relevante Richtlinien speziell für FMDN, die der DULT-Spezifikation entsprechen:

  • Alle FMDN-kompatiblen Geräte müssen in der Nearby Device Console registriert sein und die Funktion „Mein Gerät finden“ muss aktiviert sein.
  • Das Gerät muss den Dienst und die Eigenschaft „Accessory Non-Owner“ implementieren, die in der Implementierungsversion der DULT-Spezifikation definiert sind, einschließlich der Vorgänge Accessory Information und Non-Owner Controls.
  • Während des in der DULT-Spezifikation definierten Zeitraums der Abwärtskompatibilität gibt es keine Änderungen am in diesem Dokument definierten beworbenen Frame.
  • Der in diesem Dokument definierte „Schutzmodus für unerwünschtes Tracking“ entspricht dem in der DULT-Spezifikation definierten „getrennten Zustand“.
  • Richtlinien für die Implementierung der Opcodes für Zubehörinformationen:
    • „Get_Product_Data“ sollte die von der Konsole bereitgestellte Modell-ID zurückgeben, die auf 8 Byte aufgefüllt ist. Die Modell-ID 0xFFFFFF wird beispielsweise als 0x0000000000FFFFFF zurückgegeben.
    • „Get_Manufacturer_Name“ und „Get_Model_Name“ müssen mit den in der Konsole angegebenen Werten übereinstimmen.
    • „Get_Accessory_Category“ kann den generischen Wert „Standort-Tracker“ zurückgeben, wenn keine andere Kategorie besser zum Gerätetyp passt.
    • „Get_Accessory_Capabilities“ muss die Unterstützung für das Klingeln sowie die Suche nach BLE-IDs angeben.
    • „Get_Network_ID“ sollte die Kennung von Google (0x02) zurückgeben.
  • Richtlinien für die Implementierung des Get_Identifier-Opcodes:
    • Der Vorgang sollte nur 5 Minuten lang nach der Aktivierung des Identifikationsmodus eine gültige Antwort zurückgeben. Für diesen Modus ist eine Kombination von Tastendrücken erforderlich. Ein visuelles oder akustisches Signal sollte dem Nutzer anzeigen, dass der Anbieter diesen Modus aktiviert hat. Die modellspezifischen Anweisungen zum Aktivieren dieses Modus müssen Google als Voraussetzung für die Zertifizierung und mindestens 10 Tage vor jeder Aktualisierung oder Änderung der Anleitung zur Verfügung gestellt werden.
    • Die Antwort besteht aus den ersten 10 Byte der aktuellen sitzungsspezifischen Kennung, gefolgt von den ersten 8 Byte von HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
  • Richtlinien für die Implementierung von IDs über NFC:
    • Verwenden Sie als URL find-my.googleapis.com/lookup.
    • Verwende als Parameter e dieselbe Antwort wie für Get_Identifier, hexadezimal codiert.
    • Verwende als Parameter pid dieselbe Antwort wie für Get_Product_Data, hexadezimal codiert.
  • Das Gerät muss einen Tongeber haben und die Klingelfunktion unterstützen. Gemäß der DULT-Spezifikation muss der Schallgeber einen Ton mit einer Spitzenlautstärke von mindestens 60 Phon gemäß ISO 532-1:2017 ausgeben.
  • Richtlinien für die Implementierung des Sound_Start-Opcodes:
    • Der Befehl sollte das Klingeln auf allen verfügbaren Komponenten auslösen.
    • Es sollte das maximal unterstützte Volumen verwendet werden.
    • Die empfohlene Dauer für das Klingeln beträgt 12 Sekunden.
  • Locator-Tags müssen einen Mechanismus enthalten, mit dem Nutzer die Werbung vorübergehend deaktivieren können, ohne das Gerät auf die Werkseinstellungen zurückzusetzen (z. B. durch Drücken einer Tastenkombination).
    • Die Anleitung zur Deaktivierung muss unter einer öffentlich zugänglichen URL dokumentiert und Google als Zertifizierungsanforderung mindestens 10 Tage vor jeder Aktualisierung oder Änderung der Anleitung zur Verfügung gestellt werden.
    • Die URL muss die Lokalisierung unterstützen. Je nach Client wird die Sprache entweder als Suchparameter („hl=de“) oder mit dem HTTP-Header „accept-language“ angegeben.

Richtlinien für umschaltbare Protokolle

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

Firmware updates

Der Prozess und die Verteilung von Over-the-air-Updates sollten vom Partner mit seinem eigenen Workflow für mobile oder Web-Apps verwaltet werden.

„Schnelles Pairing“ unterstützt die Zustellung von Benachrichtigungen an den Nutzer, in denen er über verfügbare Over-the-air-Updates informiert wird. So verwenden Sie diesen Mechanismus:

  • Die neueste Firmwareversion sollte in der Nearby Device Console aktualisiert werden.
  • In der Console für Geräte in der Nähe sollte eine Companion App festgelegt sein. Sie sollte die Intention „Firmware-Update“ unterstützen.
  • Der Anbieter muss die GATT-Eigenschaft Firmware-Revision implementieren.

Um das Tracking zu verhindern, sollte der Zugriff auf die Eigenschaft Firmware-Version eingeschränkt werden. Der Seeker liest zuerst den Bereitstellungsstatus und gibt einen in dieser Spezifikation definierten Authentifizierungsschlüssel an und liest erst dann die Firmwareversion. Dies geschieht über dieselbe Verbindung. Wenn versucht wird, die Firmwareversion zu lesen, der Anbieter aber nicht verbunden ist und über dieselbe Verbindung kein authentifizierter Vorgang erfolgreich abgeschlossen wurde, sollte der Anbieter einen nicht authentifizierten Fehler zurückgeben.

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 in bestimmten Ländern für Nutzer ab einem bestimmten Alter.

Änderungsprotokoll

FMDN-Version Datum Kommentar
v1 Erste Version der FMDN-Spezifikation für Early Access.
v1.1 Feb. 2023
  • Der Modus zum Schutz vor unerwünschtem Tracking wurde im Klartext gekennzeichnet.
  • Es wurde eine Option hinzugefügt, mit der die Authentifizierung von Anrufanfragen im Modus zum Schutz vor unerwünschtem Tracking übersprungen werden kann.
v1.2 Apr. 2023
  • Die Definition der AK eines Inhabers wurde aktualisiert.
  • Es wurde eine Empfehlung zur Wiederherstellung nach einem Stromausfall in Locator-Tags hinzugefügt.
  • Es wurde eine Klarstellung zur Zufallsgenerierung von MAC-Adressen hinzugefügt.
  • Es wurde eine Klarstellung zur MAC-Adressrotation im Modus zum Schutz vor unerwünschtem Tracking hinzugefügt.
  • Es wurde eine Richtlinie zur Deaktivierung eines Locator-Tags hinzugefügt.
v1.3 Dez. 2023
  • Es wurde eine Klarstellung zur Identifizierung von Informationen hinzugefügt, die durch Standort-Tags offengelegt werden.
  • Es wurde eine Anforderung zur Implementierung der Spezifikation zur Verhinderung von unerwünschtem Tracking hinzugefügt.
  • Es wurden Richtlinien für umschaltbare Protokollgeräte hinzugefügt.