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

Hinweis: Wenn Sie die Spezifikation für „Mein Gerät finden“-Zubehör integrieren möchten, reichen Sie ein Gerätevorschlagsformular ein. Weitere Informationen zu den Integrationsschritten und zur Zertifizierung folgen demnächst.

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 für diese Erweiterung erforderlichen Vorgänge werden als Schreibvorgang ausgeführt, der durch einen Abfragemechanismus gesichert ist. 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:

Octet	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. Abhängig vom angeforderten Vorgang weist der Seeker auf, dass er einen oder mehrere der folgenden Schlüssel kennt:

• Kontoschlüssel: Der 16-Byte-Fast-Pair-Kontoschlüssel, wie in der Fast-Pair-Spezifikation definiert.

• Inhaberkontoschlüssel: Der Anbieter wählt einen der vorhandenen Kontoschlüssel als Inhaberkontoschlüssel aus, wenn ein Sucher zum ersten Mal auf das Attribut „Beacon-Aktionen“ zugreift. Der ausgewählte Schlüssel für das Inhaberkonto kann erst geändert werden, wenn der Anbieter auf die Werkseinstellungen zurückgesetzt wurde. Der Anbieter darf den Inhaberkontoschlüssel nicht entfernen, wenn die kostenlosen Slots für Kontoschlüssel aufgebraucht sind.

  • Anbieter, die FMDN bereits bei der erstmaligen Kopplung unterstützen (oder nach dem Zurücksetzen auf die Werkseinstellungen), wählen den ersten Kontoschlüssel aus, da dies der einzige vorhandene Kontoschlüssel ist, wenn der Sucher den Bereitstellungsstatus während der Kopplung liest.

  • Anbieter, die FMDN-Unterstützung erhalten, nachdem sie bereits gekoppelt sind (z. B. durch ein Firmware-Update), können einen beliebigen vorhandenen Kontoschlüssel auswählen. Es ist sinnvoll, den ersten Kontoschlüssel auszuwählen, der nach dem Firmwareupdate verwendet wird, um den Bereitstellungsstatus aus dem Attribut „Beacon-Aktionen“ zu lesen, vorausgesetzt, der Nutzer, der das Update ausgeführt hat, ist der aktuelle Inhaber des Anbieters.

• Ephemerer Identitätsschlüssel (EIK): Ein 32-Byte-Schlüssel, der vom Sucher bei der Bereitstellung des FMDN zufällig ausgewählt wird. Dieser Schlüssel wird verwendet, um kryptografische Schlüssel abzuleiten, die für die Ende-zu-Ende-Verschlüsselung von Standortberichten verwendet werden. Der Seeker gibt sie dem Back-End nicht weiter.

• Wiederherstellungsschlüssel: Definiert als SHA256(ephemeral identity key || 0x01), auf die ersten 8 Byte gekürzt. Der Schlüssel wird im Backend gespeichert und die Suchperson kann ihn verwenden, um das EIK wiederherzustellen, sofern der Nutzer seine Einwilligung durch Drücken einer Schaltfläche auf dem Gerät erklärt.

• Klingeltonschlüssel: Definiert als SHA256(ephemeral identity key || 0x02), gekürzt auf die ersten 8 Byte. Der Schlüssel wird im Back-End gespeichert und der Seeker kann ihn nur verwenden, um das Gerät anzurufen.

• Schlüssel für den Schutz vor unerwünschtem Tracking: Wird als SHA256(ephemeral identity key || 0x03) definiert und auf die ersten 8 Byte gekürzt. Der Schlüssel wird im Back-End gespeichert und der Seeker kann damit nur den Schutzmodus für unerwünschtes Tracking aktivieren.

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.

Octet	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 für den sitzungsspezifischen Identitätsschlüssel, AES-ECB-128, mit dem Kontoschlüssel verschlüsselt. 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

Octet	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

Octet	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:Klingeltonanfrage.

Octet	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 Kontroll-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, die in Tabelle 6 aufgeführt sind.

Benachrichtigungen mit einer anderen Daten-ID als 0x05: Ring state change (Änderung des Anrufstatus) sollten gesendet werden, bevor die Schreibtransaktion, die die Benachrichtigung auslöst, abgeschlossen ist, 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: Schlüssel für die sitzungsspezifische Identität festlegen 0x03: Sitzungsspezifischer Identitätsschlüssel löschen 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 für den Bereitstellungsstatus, gefolgt von der aktuellen sitzungsspezifischen ID (20 oder 32 Byte), falls zutreffend 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 leere zusätzliche 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 bei 0 m empfangene kalibrierte Leistung (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	Klingeltonfunktionen	Folgende Optionen werden unterstützt: 0x00: Auswahl der Klingeltonlautstärke nicht verfügbar. 0x01: Auswahl der Klingeltonlautstärke verfügbar. 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 Seeker kann den Bereitstellungsstatus des Beacons beim Anbieter abfragen. Dazu führt er einen Schreibvorgang für das Merkmal aus, das 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 eine 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 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 ID	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 einmalige Authentifizierungsschlüssel stimmt mit dem Kontoschlüssel des Inhabers ü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 wirksam, nachdem die BLE-Verbindung beendet wurde. 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.

Sitzungsspezifischen Identitätsschlüssel 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 überprüft, ob

• 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 Provider den Schlüssel und beendet die Werbung für FMDN-Frames. Der Anbieter benachrichtigt sich 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 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 am Gerät gedrückt wurde (wodurch die Einwilligung des Nutzers bestätigt wird).

Der Seeker muss den Wiederherstellungsschlüssel im Back-End speichern, um den Klartextschlüssel wiederherstellen zu können. Er speichert jedoch nicht den EIK selbst.

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): Ring links Bit 3 (0 x 04): Ring-Case 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. Das Zeitlimit überschreibt die Zeitüberschreitung, die bereits gilt, 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 0 x 03: 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 Anfrage zum Schutz vor unerwünschtem Tracking das Flag „Authentifizierung über Klingeln überspringen“ aktiviert war, sollte er 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 wie folgt definiert:

Octet	Datentyp	Beschreibung	Wert
0	uint8	Klingelstatus	0x00: Gestartet 0x01: Starten oder Beenden fehlgeschlagen (alle angeforderten Komponenten liegen außerhalb des Bereichs) 0x02: Angehalten (timeout) 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 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 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 die Touch Sense-Taste aktiviert ist), sollte diese die Klingeltonfunktion stoppen, wenn sie gedrückt wird, während das Klingeln aktiv ist.

Hinweis: Bei Anbietern, die die Erkennung der Kopfhörernutzung unterstützen, sollten Sie prüfen, ob das Gerät nicht am Kopf getragen wird, bevor es mit maximaler Lautstärke klingelt. Wenn die Erkennung, dass der Nutzer die Kopfhörer aufgesetzt hat, nicht unterstützt oder nicht zuverlässig ist, erhöhen Sie die Lautstärke schrittweise, damit der Nutzer das Klingeln beenden oder die Kopfhörer herausnehmen kann.

Hinweis :Der Dienstleister sollte unabhängig vom Verbindungsstatus des Suchenden, der das Klingeln angefordert hat, weiter klingeln. So wird verhindert, dass das Gerät nicht mehr klingelt, weil die Verbindung unterbrochen wird, wenn sich der Kunde zu weit vom Gerät entfernt. Das Gerät kann dann nicht gefunden werden, weil es aufgehört hat zu klingeln und zu weit vom Client entfernt ist, um das Klingeln noch einmal anzufordern.

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

Schutzmodus für unerwünschtes Tracking

Der Schutzmodus für unerwünschtes Tracking soll jedem Client die Identifizierung missbräuchlicher Geräte ohne Serverkommunikation ermöglichen. Standardmäßig sollte der Anbieter alle IDs rotieren, wie unter ID-Rotation beschrieben. 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 verwendet der Dienst vorübergehend eine feste MAC-Adresse, sodass Clients das Gerät erkennen und den Nutzer vor möglichem unerwünschtem Tracking warnen können.

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

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 Schutzmodus für unerwünschtes 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 Schutzmodus für unerwünschtes Tracking aktiviert ist, sollte das Beacon die Häufigkeit der Rotation der MAC-Adresse der privaten Adresse auf einmal pro 24 Stunden reduzieren. Die beworbene sitzungsspezifische Kennung sollte wie gewohnt rotieren. Der Frame-Typ sollte auf 0x41 eingestellt sein. Der Status wird auch im Abschnitt Hash-Flags angezeigt.

Wenn der Schutz vor unerwünschtem Tracking deaktiviert wird

Der Anbieter überprüft, ob

• 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 Bereich Hash-Flags angegeben.

Bei Erfolg benachrichtigt der Anbieter eine 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 Frames für schnelles Pairing beworben werden, sollte der Anbieter die FMDN-Frames mit den regulären Anzeigen für schnelles Pairing verschachteln. Beispielsweise sollte der Anbieter alle zwei Sekunden sieben Fast Pair-Anzeigen und eine FMDN-Anzeige senden.

Hinweis :Es wird empfohlen, die FMDN-Frames auch dann zu senden, wenn sich das Gerät im Energiesparmodus befindet, da das Gerät so bei Verlust gefunden werden kann. Bei einigen Geräten kann keine Werbung geschaltet werden, wenn das Gerät aufgrund der Auswirkungen auf die Akkulaufzeit ausgeschaltet ist. In solchen Fällen wird dringend empfohlen, das Gerät regelmäßig zu aktivieren und für einen kurzen Zeitraum Werbung zu schalten (z.B. alle 10 Minuten für 10 Sekunden).

Der FMDN-Frame enthält einen öffentlichen Schlüssel, mit dem Standortberichte von jedem unterstützenden Client verschlüsselt werden, der zum Crowdsourcing-Netzwerk beiträgt. 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.

Hinweis: Wenn Sie 256-Bit-Schlüssel verwenden, können ältere Smartphones, die BLE 5 nicht unterstützen, keine Geräte suchen und keine Berichte zu Werbegeräten erstellen. Dadurch wird die Größe des Netzwerks verringert.

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		Sitzungsspezifische 20-Byte-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.

Octet	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:

Octet	Feld	Beschreibung
0–10	Abstand	Wert = 0xFF
11	K	Rotationszeitraumexponent
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	Rotationszeitraumexponent
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.

Hinweis: Es wird davon ausgegangen, dass das Gerät einen 32‑Bit-Zeitzähler in Sekunden hat.

Hinweis: Der Exponent für die Rotationsdauer ist festgelegt und auf 10 gesetzt, was 1.024 Sekunden entspricht.

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) verschlüsselt.

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. Andernfalls sollten die höchstwertigen Bits abgeschnitten werden, wenn die Darstellung länger als 160 oder 256 Bit ist.

Wenn das Beacon die Anzeige des Akkustands nicht unterstützt und sich nicht im Schutzmodus für unerwünschtes Tracking befindet, kann dieses Byte in der Anzeige weggelassen werden.

Verschlüsselung mit EID

Hinweis: Die folgenden Details zur Verschlüsselung und Entschlüsselung mit EIDs sind nur zur Vollständigkeit der Spezifikation enthalten. Diese werden nur vom Suchenden implementiert, nicht vom Anbieter.

Zum Verschlüsseln einer m-Nachricht würde ein Sighter, der Rx vom Beacon gelesen hat, so vorgehen:

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. 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 im Besitz der EIK und des Rotationszeitraumsexponents ist, 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

Zum Bewerben von FMDN-Frames muss eine auflösbare (RPA) oder nicht auflösbare BLE-Adresse (NRPA) 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 keine Kopplung verwenden.

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, ab dem das Beacon die neue ID bewirbt, muss innerhalb des Zeitfensters zufällig ausgewählt 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 würden die Auflösung über ein Zeitfenster implementieren, das ausreichend ist, um sowohl eine angemessene Uhrabweichung als auch diese Art der Wiederherstellung bei einem Stromausfall zu ermöglichen.

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

Richtlinien für die Implementierung von „Schnelles Pairing“

In diesem Abschnitt werden spezielle Aspekte der Implementierung von „Schnelles Pairing“ bei Anbietern beschrieben, die FMDN unterstützen.

Richtlinien für Locator-Tags

• Wenn der Anbieter gekoppelt, aber FMDN nicht innerhalb von 5 Minuten bereitgestellt wurde (oder wenn ein OTA-Update angewendet wurde, während das Gerät gekoppelt, aber nicht FMDN bereitgestellt wurde), sollte der Anbieter auf die Werkseinstellungen zurücksetzen und die gespeicherten Kontoschlüssel löschen.
• Nachdem der Anbieter gekoppelt ist, sollte er seine MAC-Adresse erst dann ändern, wenn FMDN bereitgestellt wird 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 Funktion „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ückzusetzen (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.
• Frames für schnelles Pairing 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.

Spezifische Richtlinien für klassische Bluetooth-Geräte

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

FMDN-Bereitstellung bereits gekoppelter Geräte

Der Anbieter wird beim Koppeln mit dem Seeker nicht immer für FMDN bereitgestellt, aber eine Weile später. 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 Kontodaten für schnelles Pairing anbieten, damit der Seeker 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 Nachrichtenstream mit schnellem Pairing implementieren und den Seeker über Geräteinformationen informieren. Durch die Implementierung des Nachrichtenstreams können bestimmte Funktionen genutzt werden, 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 Trackingfunktion

Wenn ein Firmwareupdate dem Anbieter FMDN unterstützt, kann ein verbundener Seeker den Nutzer darüber benachrichtigen und anbieten, ihn bereitzustellen. 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 an den Funktionen aufgrund von Firmwareupdates informiert wird.

Octet	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 nach dem Empfang einer Anfrage zur Funktionsaktualisierung (0x0601) die Unterstützung für FMDN-Tracking aktiviert hat, sollte er wie in Tabelle 12 dargestellt antworten.

Octet	Datentyp	Beschreibung	Wert
0	uint8	Ereignis zum Synchronisieren von Gerätefunktionen	0x06
1	uint8	FMDN-Tracking	0x03
2–3	uint16	Zusätzliche Datenlänge	0x0007
4	uint8	Bereitstellungsstatus von FMDN	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 sitzungsspezifische ID (Geräteinformationscode 0x0B)

Der Anbieter kann die aktuelle sitzungsspezifische ID (Code 0x0B) verwenden, um den aktuellen EID- und Uhrwert zu melden, wenn der Anbieter für FMDN bereitgestellt wird, und um den Seeker bei einer Zeitverschiebung (z. B. aufgrund eines zu entladenen 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 zur Einhaltung der DULT-Spezifikation:

• 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 angeben, ob Klingeltöne und die BLE-ID-Suche unterstützt werden.
  • „Get_Network_ID“ sollte die Kennung von Google (0x02) zurückgeben.
• Richtlinien für die Implementierung des Opcodes Get_Identifier:
  • Der Vorgang sollte nur 5 Minuten lang nach der Aktivierung des Identifikationsmodus durch den Nutzer 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 der Kennung über NFC:
  • Verwenden Sie find-my.googleapis.com/lookup als URL.
  • Verwende als Parameter e dieselbe Antwort, die für Get_Identifier erstellt wurde, hexadezimal codiert.
  • Verwende als Parameter pid dieselbe Antwort wie für Get_Product_Data, hexadezimal codiert.
• Richtlinien für die Implementierung des Opcodes Sound_Start:
  • Der Befehl sollte das Klingeln bei 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 sollte 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 wechselbare 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 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 Over-the-air-Updates sollten vom Partner mit seinem eigenen Workflow 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 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 klingelnden Anfragen im Schutzmodus gegen unerwünschtes Tracking übersprungen werden kann.
v1.2	April 2023	Die Definition für das Konto 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 Vermeidung von unerwünschtem Tracking hinzugefügt. Es wurden Richtlinien für umschaltbare Protokollgeräte hinzugefügt.