Specification for Find Hub Network Accessory

v1.3

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

Hinweis :Wenn Sie Ihren Standort-Tag oder Ihr nicht hörbares Gerät in das Zubehör für das „Mein Gerät finden“-Netzwerk einbinden möchten, füllen Sie ein Antragsformular für „Mein Gerät finden“-Geräte aus. Wenn Sie Unterstützung für „Mein Gerät finden“ für Over-Ear-Kopfhörer oder TWS-Kopfhörer hinzufügen möchten, füllen Sie stattdessen das Formular für Gerätevorschläge für „Schnelles Pairing“ aus.

GATT-Spezifikation

Dem Dienst „Schnelles Pairing“ sollte ein zusätzliches generisches Attribut (GATT) mit der folgenden Semantik hinzugefügt werden:

Charakteristik des Dienstes „Schnelles Pairing“	Verschlüsselt	Berechtigungen	UUID
Beacon-Aktionen	Nein	Lesen, Schreiben und Benachrichtigen	FE2C1238-8366-4814-8EB0-01DE32100BEA

Tabelle 1:Schnelles Pairing-Dienstmerkmale für FHN.

Authentifizierung

Die für diese Erweiterung erforderlichen Vorgänge werden als Schreibvorgang ausgeführt, der durch einen Challenge-Response-Mechanismus gesichert ist. Bevor eine Operation ausgeführt wird, muss der Seeker einen Lesevorgang für das Merkmal in Tabelle 1 ausführen. Das Ergebnis ist ein Puffer im folgenden Format:

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

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

Der Seeker berechnet dann einen Einmal-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 weist der Suchende Kenntnisse von einem oder mehreren der folgenden Schlüssel nach:

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

• Schlüssel des Inhaberkontos: Der Anbieter wählt einen der vorhandenen Kontoschlüssel als Schlüssel des Inhaberkontos aus, wenn ein Nutzer zum ersten Mal auf das Merkmal „Beacon Actions“ zugreift. Der ausgewählte Schlüssel des Inhaberkontos kann erst geändert werden, wenn der Anbieter auf die Werkseinstellungen zurückgesetzt wird. Der Anbieter darf den Schlüssel des Inhaberkontos nicht entfernen, wenn die kostenlosen Kontoschlüssel-Slots aufgebraucht sind.

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

  • Anbieter, die FHN-Unterstützung nach der Kopplung erhalten (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 Firmware-Update verwendet wird, um den Bereitstellungsstatus aus dem Beacon-Aktionsmerkmal zu lesen, sofern der Nutzer, der das Update durchgeführt hat, der aktuelle Inhaber des Anbieters ist.

• Temporärer Identitätsschlüssel (Ephemeral Identity Key, EIK): Ein 32‑Byte-Schlüssel, der vom Suchenden während der FHN-Bereitstellung zufällig ausgewählt wird. Mit diesem Schlüssel werden kryptografische Schlüssel abgeleitet, die für die Ende-zu-Ende-Verschlüsselung von Standortberichten verwendet werden. Der Seeker gibt sie niemals an das Backend weiter.

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

• Schlüssel für das Klingeln: Definiert als SHA256(ephemeral identity key || 0x02), gekürzt auf die ersten 8 Byte. Der Schlüssel wird im Backend gespeichert und kann vom Suchenden nur zum Klingeln des Geräts verwendet werden.

• Schlüssel zum Schutz vor unerwünschtem Tracking: Definiert als SHA256(ephemeral identity key || 0x03), auf die ersten 8 Bytes gekürzt. Der Schlüssel wird im Backend gespeichert und kann vom Suchenden nur zum Aktivieren des Schutzmodus vor unerwünschtem Tracking verwendet werden.

Vorgänge

Das Format der in das Merkmal geschriebenen Daten ist in den Tabellen 2 bis 5 angegeben. Jede der Operationen wird später in diesem Abschnitt genauer beschrieben.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x00: Beacon-Parameter lesen 0x01: Bereitstellungsstatus lesen 0x02: Kurzlebigen Identitätsschlüssel festlegen 0x03: Sitzungsspezifischen Identitätsschlüssel löschen
1	uint8	Datenlänge	variiert
2–9	Byte-Array	Einmaliger Authentifizierungsschlüssel	Die ersten 8 Bytes 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 <0	Zusätzliche Daten	0x00: Nicht zutreffend 0x01: n/a 0x02: 32 Byte, die den sitzungsspezifischen Identitätsschlüssel enthalten, der mit dem Kontoschlüssel AES-ECB-128-verschlüsselt ist. Wenn der Anbieter bereits einen temporären Identitätsschlüssel festgelegt hat, senden Sie auch die ersten 8 Bytes 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 Bereitstellung von Beacons

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

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

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x05: Ring 0x06: Ruftonstatus lesen
1	uint8	Datenlänge	variiert
2–9	Byte-Array	Einmaliger Authentifizierungsschlüssel	Die ersten 8 Bytes 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 Klingelstatus, die Klingeldauer und die Klingellautstärke angeben. 0x06: n/a

Tabelle 4:Klingelanfrage

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x07: Modus „Schutz vor unerwünschten Trackern“ aktivieren 0x08: Unerwünschten Tracking-Schutzmodus deaktivieren
1	uint8	Datenlänge	variiert
2–9	Byte-Array	Einmaliger Authentifizierungsschlüssel	Die ersten 8 Bytes 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 Steuerungsflags (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, wie in Tabelle 6 aufgeführt.

Benachrichtigungen mit einer anderen Daten-ID als 0x05: Ring state change (0x05: Änderung des Klingelstatus) sollten vor Abschluss der Schreibtransaktion gesendet werden, die die Benachrichtigung auslöst, d. h. bevor eine Antwort-PDU für die Schreibanfrage gesendet wird.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID <0	0x00: Beacon-Parameter lesen 0x01: Bereitstellungsstatus lesen 0x02: Kurzlebigen Identitätsschlüssel festlegen 0x03: Sitzungsspezifischen Identitätsschlüssel löschen 0x04: Flüchtigen Identitätsschlüssel mit Nutzereinwilligung lesen 0x05: Änderung des Klingelstatus 0x06: Ruftonstatus lesen 0x07: Modus „Schutz vor unerwünschten Trackern“ aktivieren 0x08: Unerwünschten Tracking-Schutzmodus deaktivieren
1	uint8	Datenlänge	variiert
2–9	Byte-Array	Authentifizierung	Detailliert nach Vorgang
10 – var <0x0	Byte-Array <0	Zusätzliche Daten	0x00: 8 Bytes, die die Sendeleistung, den Taktwert, die Verschlüsselungsmethode und die Klingelfunktionen 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 temporären ID (20 oder 32 Byte), falls zutreffend 0x04: 32 Byte, die den sitzungsspezifischen Identitätsschlüssel darstellen, AES-ECB-128-verschlüsselt mit dem Kontoschlüssel 0x05: 4 Bytes, die den neuen Status und den Trigger für die Änderung angeben 0x06: 3 Bytes, die die Komponenten angeben, die aktiv klingeln, und die Anzahl der verbleibenden Dekasekunden für das Klingeln Andere Daten-IDs verwenden leere zusätzliche Daten

Tabelle 6:Antwort des Beacon-Dienstes.

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

Code	Beschreibung	Hinweise
0x80	Nicht authentifiziert	Wird als Antwort auf eine Schreibanfrage zurückgegeben, wenn die Authentifizierung fehlschlägt (einschließlich des Falls, in dem eine alte Nonce verwendet wurde).
0x81	Ungültiger Wert	Wird zurückgegeben, wenn ein ungültiger Wert angegeben wird oder die empfangenen Daten eine unerwartete Anzahl von Byte haben.
0x82	Keine Nutzereinwilligung	Wird als Antwort auf eine Schreibanfrage mit der Daten-ID 0x04: Read ephemeral identity key with user consent (Temporären Identitätsschlüssel mit Nutzereinwilligung lesen) zurückgegeben, wenn sich das Gerät nicht im Kopplungsmodus befindet.

Tabelle 7:GATT-Fehlercodes.

Parameter des Beacons lesen

Der Seeker kann den Provider 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 0x00 besteht. Der Anbieter prüft, ob der bereitgestellte Einmal-Authentifizierungsschlüssel mit einem der auf dem Gerät gespeicherten Kontoschlüssel übereinstimmt.

Wenn die Bestätigung fehlschlägt, gibt der Anbieter einen Fehler zurück, der besagt, dass die Authentifizierung nicht möglich ist.

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, die bei 0 m empfangen wird (ein Wert im Bereich [–100, 20]). Wird als Ganzzahl mit Vorzeichen mit einer Auflösung von 1 dBm dargestellt.
1–4	uint32	Taktwert	Der aktuelle Taktwert in Sekunden (Big-Endian).
5	uint8	Kurvenauswahl	Die für die Verschlüsselung verwendete elliptische Kurve: 0x00 (Standard): SECP160R1 0x01: SECP256R1 (erfordert erweiterte Werbung)
6	uint8	Komponenten	Anzahl der Komponenten, die klingeln können: 0x00: Gibt an, dass das Gerät nicht klingeln kann. 0x01: Gibt an, dass nur eine einzelne Komponente klingeln kann. 0x02: Gibt an, dass zwei Komponenten, der linke und der rechte Kopfhörer, unabhängig voneinander klingeln können. 0x03: Gibt an, dass drei Komponenten (linker und rechter Kopfhörer sowie das Case) unabhängig voneinander klingeln können.
7	uint8	Klingelfunktionen	Die unterstützten Optionen sind: 0x00: Die Auswahl der Klingeltonlautstärke ist nicht verfügbar. 0x01: Auswahl der Klingeltonlautstärke verfügbar. Falls festgelegt, muss der Anbieter drei Lautstärkepegel akzeptieren und verarbeiten, wie unter Anrufvorgang beschrieben.
8–15	Byte-Array	Abstand	Null-Padding für die AES-Verschlüsselung.

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

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

Bereitstellungsstatus des Beacons lesen

Der Seeker kann den Provider 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 bereitgestellte Einmal-Authentifizierungsschlüssel mit einem der auf dem Gerät gespeicherten Kontoschlüssel übereinstimmt.

Wenn die Überprüfung fehlschlägt, gibt der Anbieter einen Fehler zurück, der besagt, dass die Authentifizierung fehlgeschlagen ist.

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

Oktett	Datentyp	Beschreibung	Wert
0	uint8	ProvisioningState	Eine Bitmaske mit den folgenden Werten: Bit 1 (0x01): Wird festgelegt, wenn ein temporärer Identitätsschlüssel für das Gerät festgelegt ist. Bit 2 (0x02): Wird festgelegt, wenn der bereitgestellte Einmal-Authentifizierungsschlüssel mit dem Schlüssel des Inhaberkontos übereinstimmt.
1–20 oder 32	Byte-Array	Aktuelle temporäre Kennung	20 oder 32 Byte (je nach verwendeter Verschlüsselungsmethode), die die aktuelle temporäre ID angeben, die vom Beacon beworben 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.

Temporären Identitätsschlüssel festlegen

Um einen nicht bereitgestellten Anbieter als FHN-Beacon bereitzustellen oder den temporären Identitätsschlüssel eines bereits bereitgestellten Anbieters zu ändern, führt der Seeker 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 Einmal-Authentifizierungsschlüssel stimmt mit dem Schlüssel des Inhaberkontos überein.
• Wenn ein Hash eines sitzungsspezifischen Identitätsschlüssels bereitgestellt wurde, stimmt der gehashte sitzungsspezifische Identitätsschlüssel mit dem aktuellen sitzungsspezifischen Identitätsschlüssel überein.
• Wenn kein Hash eines temporären Identitätsschlüssels angegeben wurde, prüfen Sie, ob der Anbieter nicht bereits als FHN-Beacon bereitgestellt wurde.

Wenn die Überprüfung fehlschlägt, gibt der Anbieter einen Fehler zurück, der besagt, dass die Authentifizierung fehlgeschlagen ist.

Bei Erfolg wird der temporäre Identitätsschlüssel durch AES-ECB-128-Entschlüsselung mit dem übereinstimmenden Kontoschlüssel wiederhergestellt. Der Schlüssel sollte auf dem Gerät gespeichert werden. Ab diesem Zeitpunkt sollte der Anbieter FHN-Frames bewerben. Der neue temporäre Identitätsschlüssel wird sofort nach Beendigung 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.

Kurzlebigen Identitätsschlüssel löschen

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

• Der angegebene Einmal-Authentifizierungsschlü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 FHN-Beacon bereitgestellt wird oder die Überprüfung fehlschlägt, wird ein nicht authentifizierter Fehler zurückgegeben.

Bei Erfolg vergisst der Anbieter den Schlüssel und beendet die Übertragung von FHN-Frames. Der Anbieter benachrichtigt mit einer Antwort aus Tabelle 6 mit der Daten-ID 0x03. Das Authentifizierungssegment ist als die ersten 8 Bytes von HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) definiert.

Temporären 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 Tracker 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 der Nutzereinwilligung entspricht).

Der Suchende muss den Wiederherstellungsschlüssel im Backend speichern, um den Klartextschlüssel wiederherstellen zu können. Er speichert jedoch nicht den EIK selbst.

Um die EIK zu lesen, führt der Seeker einen Schreibvorgang für das Merkmal aus, der aus einer Anfrage aus Tabelle 3 mit der Daten-ID 0x04 besteht. Der Provider prüft Folgendes:

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

Wenn die Überprüfung fehlschlägt, gibt der Anbieter einen Fehler zurück, der besagt, dass die Authentifizierung fehlgeschlagen ist.

Wenn sich das Gerät nicht im Kopplungsmodus befindet, gibt der Anbieter einen Fehler vom Typ „No User Consent“ 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 Seeker kann den Provider 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 Zehntelsekunden. Darf nicht null und nicht länger als 10 Minuten sein. Der Anbieter verwendet diesen Wert, um zu bestimmen, wie lange es klingeln soll, bevor das Gerät stumm geschaltet wird. Das Zeitlimit überschreibt das bereits aktive Zeitlimit, wenn eine Komponente des Geräts bereits klingelt. Wenn ring operation 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 hängt von der Implementierung ab.

Nach Erhalt des Antrags überprüft der Anbieter Folgendes:

• Der angegebene Einmal-Authentifizierungsschlüssel stimmt mit dem Ringschlüssel überein.
• Der angeforderte Status entspricht den Komponenten, die klingeln können.

Wenn der Anbieter nicht als FHN-Beacon bereitgestellt wird oder die Überprüfung fehlschlägt, wird ein nicht authentifizierter Fehler zurückgegeben. Wenn der Anbieter jedoch einen unerwünschten Tracking-Schutz aktiviert hat und die Anfrage, die den unerwünschten Tracking-Schutz ausgelöst hat, das Flag „Authentifizierung überspringen“ aktiviert hatte, sollte der Anbieter diese Prüfung überspringen. Die Authentifizierungsdaten müssen weiterhin vom Suchenden angegeben 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, wie in Tabelle 6 beschrieben. 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 zulässigen Bereichs) 0x02: Beendet (Zeitüberschreitung) 0x03: Beendet (durch Drücken der Taste) 0x04: Beendet (GATT-Anfrage)
1	uint8	Klingelkomponenten	Eine Bitmaske der Komponenten, die aktiv klingeln, wie in der Anfrage definiert.
2–3	uint16	Zeitlimit	Die verbleibende Zeit für das Klingeln in Zehntelsekunden. Wenn das Gerät aufgehört hat zu klingeln, 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 Klingelstatus befindet, wenn eine Anfrage zum Klingeln oder zum Beenden des Klingelns empfangen wird, sollte der Bereitsteller eine Benachrichtigung mit dem Klingelstatus oder entweder 0x00: Started oder 0x04: Stopped (GATT-Anfrage) senden. Mit dieser Anfrage werden die Parameter des vorhandenen Status überschrieben, sodass die Klingeldauer verlängert werden kann.

Wenn der Anbieter eine physische Taste hat (oder die Berührungserkennung aktiviert ist), sollte durch Drücken dieser Taste die Klingelfunktion beendet werden, wenn sie aktiv ist.

Hinweis:Wenn der Anbieter eine Funktion zur Erkennung des Tragens auf dem Kopf anbietet, sollte er prüfen, ob das Gerät getragen wird, bevor es mit maximaler Lautstärke klingelt. Wenn die Funktion zur Erkennung des Tragens auf dem Kopf nicht unterstützt wird oder nicht zuverlässig ist, sollte die Lautstärke schrittweise erhöht werden, damit der Nutzer Zeit hat, das Klingeln zu beenden oder die Kopfhörer abzunehmen.

Hinweis:Der Anbieter sollte unabhängig vom Verbindungsstatus des Suchenden, der das Klingeln angefordert hat, weiter klingeln. So wird verhindert, dass das Gerät aufhört zu klingeln, weil die Verbindung verloren geht, da sich der Client zu weit vom Gerät entfernt. Dann kann das Gerät nicht gefunden werden, weil es aufgehört hat zu klingeln und zu weit vom Client entfernt ist, als dass dieser das Klingeln noch einmal anfordern könnte.

Klingelstatus des Beacons abrufen

Um den Klingelstatus des Beacons abzurufen, führt der Seeker einen Schreibvorgang für das Merkmal durch, der aus einer Anfrage aus Tabelle 4 mit der Daten-ID 0x06 besteht. Der Provider prüft, ob der bereitgestellte Einmal-Authentifizierungsschlüssel mit dem Klingelschlüssel übereinstimmt.

Wenn der Anbieter nicht als FHN-Beacon bereitgestellt wird oder die Bestätigung fehlschlägt, gibt der Anbieter einen Fehler zurück, der besagt, dass keine Authentifizierung erfolgt ist.

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 aktiv klingeln, wie in der Klingelanfrage definiert.
1–2	uint16	Zeitlimit	Die verbleibende Zeit für das Klingeln in Zehntelsekunden. 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 „Schutz vor unerwünschtem Tracking“

Der Schutzmodus vor unerwünschtem Tracking soll es jedem Client ermöglichen, missbräuchliche Geräte ohne Serverkommunikation zu identifizieren. Standardmäßig sollte der Anbieter alle Kennungen wie unter ID-Rotation beschrieben rotieren. Der Dienst „Mein Gerät finden“ kann eine Anfrage zur Aktivierung des Schutzes vor unerwünschten Trackern über das „Mein Gerät finden“-Netzwerk weiterleiten. Dadurch veranlasst der Dienst den Anbieter, vorübergehend eine feste MAC-Adresse zu verwenden, sodass Clients das Gerät erkennen und den Nutzer vor möglichen unerwünschten Tracking-Aktivitäten warnen können.

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

Beim Aktivieren des Modus zum Schutz vor unerwünschtem Tracking

Der Anbieter erstellt das Datensegment so:

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Steuerungsflags <	0x01: Authentifizierung durch Klingeln überspringen. Wenn diese Option festgelegt ist, werden Klingelanfragen im Modus „Schutz vor unerwünschtem Tracking“ nicht authentifiziert. Wenn kein Flag gesetzt ist (das Byte besteht nur aus Nullen), kann der Datenabschnitt ganz weggelassen und ein leerer Datenabschnitt gesendet werden. Die Flags sind nur bis zur Deaktivierung des unerwünschten Tracking-Schutzmodus aktiv.

Der Anbieter prüft, ob der bereitgestellte Einmal-Authentifizierungsschlüssel mit dem Schlüssel für den Schutz vor unerwünschtem Tracking übereinstimmt. Wenn der Anbieter nicht als FHN-Beacon bereitgestellt wird oder die Überprüfung fehlschlägt, wird ein Fehler zurückgegeben, der angibt, dass keine Authentifizierung erfolgt ist.

Wenn der unerwünschte Tracking-Schutzmodus aktiviert ist, sollte die Häufigkeit der Rotation der privaten MAC-Adresse des Beacons auf einmal pro 24 Stunden reduziert werden. Die beworbene temporäre Kennung sollte wie gewohnt rotieren. Der Frametyp sollte auf 0x41 festgelegt werden. Der Status wird auch im Abschnitt gehashte Flags angezeigt.

Wenn Sie den Schutz vor unerwünschten Trackern deaktivieren

Der Anbieter bestätigt, dass:

• Der bereitgestellte Einmal-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 FHN-Beacon bereitgestellt wird oder die Überprüfung fehlschlägt, gibt der Anbieter einen Fehler zurück, der besagt, dass keine Authentifizierung erfolgt ist.

Wenn der Schutz vor unerwünschtem Tracking deaktiviert wird, sollte das Beacon die MAC-Adresse wieder in normalem Tempo rotieren lassen, synchronisiert mit der Rotation der temporären Kennung. Der Frametyp sollte wieder auf 0x40 festgelegt werden. Der Status wird auch im Abschnitt gehashte 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.

Präzise Ortung

In diesem Abschnitt werden der Ablauf und die zusätzlichen Vorgänge beschrieben, die für die Suche nach Präzision erforderlich sind. Hier gelten dieselben Regeln für GATT-Merkmale und Authentifizierung wie im Abschnitt zur GATT-Spezifikation definiert. Die präzise Ortung ist optional.

Die Art der präzisen Ortung hängt von den auf den Geräten, die an der präzisen Ortung beteiligt sind, unterstützten Technologien zur Entfernungsmessung ab. Unterstützte Technologien für die Entfernungsmessung finden Sie in der Spezifikation Ranging: Out-of-band message sequence and payload. In späteren Abschnitten wird erläutert, welche Art von Präzisionssuche basierend auf der verwendeten Entfernungsmessungstechnologie erwartet werden kann.

Ablauf der präzisen Ortung

In diesem Abschnitt wird der FHNA-Nachrichtenfluss für die Funktion „Präzises Finden“ beschrieben. Abbildung 1 zeigt den Fluss der Nachrichten und in den Absätzen wird jede Nachricht genauer erläutert.

Abbildung 1: Typischer Ablauf von Nachrichten bei der Suche mit hoher Genauigkeit

Das Initiatorgerät ist das Gerät, auf dem die App „Mein Gerät finden“ installiert ist und auf dem die Funktion „Präziser Standort“ aktiviert wurde. Das Initiatorgerät ist das Gerät, mit dem versucht wird, das andere Gerät zu finden.

Das Responder-Gerät ist das Gerät, das vom Initiator-Gerät gesucht wird.

Das Initiatorgerät sendet eine Nachricht vom Typ „Ranging Capability Request“ an das Respondergerät. Darin werden die Ranging-Technologien aufgeführt, über die das Initiatorgerät vom Respondergerät informiert werden möchte. Das Respondergerät antwortet mit der Benachrichtigung vom Typ „Ranging Capability Response“, die Informationen darüber enthält, welche Ranging-Technologien unterstützt werden und welche Funktionen sie haben. Das Respondergerät enthält nur Informationen, die vom Initiator angefordert wurden. Die Liste der Funktionen wird nach der Priorität der Ranging-Technologie sortiert, die das Respondergerät bevorzugt. Die erste in der Liste hat die höchste Priorität.

Das Initiatorgerät sendet dann eine Nachricht zur Reichweitenkonfiguration, in der die Konfiguration für jede Reichweitentechnologie definiert wird, mit der es die Reichweite bestimmen möchte. Nach dem Empfang dieser Nachricht muss das Respondergerät die Reichweite für die entsprechenden Technologien mit den bereitgestellten Konfigurationen bestimmen. Das Respondergerät sendet eine Antwortbenachrichtigung zur Reichweitenkonfiguration zurück, die die Ergebnisse enthält, ob jede einzelne Reichweitentechnologie erfolgreich gestartet wurde. Einige Reichweitentechnologien müssen sowohl auf dem Initiator- als auch auf dem Respondergerät gestartet werden, damit die Reichweitenbestimmung erfolgreich ist. Bei anderen ist es nur erforderlich, dass sie auf dem Initiatorgerät gestartet werden. Das Respondergerät muss jedoch mit einem Erfolgsergebnis für solche Technologien antworten. Weitere Informationen zum Verhalten bestimmter Reichweitentechnologien finden Sie in den folgenden Abschnitten.

Sobald das Initiatorgerät bereit ist, die Suche mit hoher Genauigkeit zu beenden, sendet es eine „Stop Ranging“-Nachricht an das Respondergerät, in der angegeben wird, welche Technologien für die Entfernungsmessung beendet werden müssen. Das Responder-Gerät antwortet mit einer „StopRangingResponse“-Benachrichtigung, die angibt, dass die Entfernungsmessung mit den angeforderten Technologien erfolgreich beendet wurde.

Wenn die BLE GATT-Kommunikation des FHNA-Kanals während einer Precision Finding-Sitzung unterbrochen wird, aber einige der Ranging-Technologien weiterhin funktionieren, implementiert das Responder-Gerät einen Zeitlimitmechanismus, um sicherzustellen, dass es nicht unbegrenzt Ranging-Anfragen sendet. Die Details hängen vom jeweiligen Anwendungsfall ab.

Das Antwortgerät darf nicht davon ausgehen, dass die Reihenfolge der Vorgänge immer gleich ist. Das Antwortgerät muss beispielsweise mehrere aufeinanderfolgende Vorgänge für Anfragen zur Reichweitenbestimmung oder sogar einen direkten Vorgang zur Reichweitenkonfiguration ohne die vorherige Anfrage zur Reichweitenbestimmung verarbeiten können.

Vorgänge für die präzise Ortung

Tabelle 8 zeigt die in diesem Dokument definierten FHNA-Vorgänge, die für die Funktion „Präzise Suche“ erforderlich sind. In den einzelnen Unterabschnitten wird die FHNA-Nachricht für jeden Vorgang definiert. Der Inhalt des Felds Zusätzliche Daten bezieht sich auf die Spezifikation Ranging: Out-of-band message sequence and payload (Entfernungsmessung: Out-of-band-Nachrichtensequenz und Nutzlast).

Vorgang	Daten-ID	Beschreibung
Anfrage zur Entfernungsbestimmung	0x0A	Der Vorgang für die Funktionsanfrage, der vom Initiatorgerät an das Respondergerät gesendet wird. Die Dateninhalte dieses Vorgangs enthalten alle Ortungstechnologien, die der Initiator vom Responder-Gerät wissen möchte.
Antwort auf die Funktion „Entfernungsmessung“	0x0A	Dies ist die Benachrichtigungsantwort auf den Vorgang „Ranging Capability Request“. Sie enthält Informationen zu den Funktionen für jede unterstützte Ranging-Technologie, die vom Initiator angefordert wurden.
Konfiguration der Entfernungsmessung	0x0B	Der Vorgang „Ranging Configuration“ (Konfiguration für die Entfernungsmessung) enthält die Konfigurationen für die Technologien zur Entfernungsmessung, mit denen das Initiatorgerät die Entfernungsmessung mit dem Respondergerät starten möchte.
Antwort auf die Konfiguration der Entfernungsmessung	0x0B	Dies ist die Benachrichtigungsantwort auf den Vorgang „Ranging Configuration“. Sie enthält Daten dazu, ob das Responder-Gerät basierend auf der bereitgestellten Konfiguration erfolgreich mit der Entfernungsmessung mit den angeforderten Entfernungsmessungstechnologien begonnen hat.
RFU	0x0C	Der Vorgang mit dieser Daten-ID wird nicht verwendet und ist für die zukünftige Verwendung reserviert.
Entfernungsmessung beenden	0x0D	Der vom Initiatorgerät gesendete Vorgang „Stop Ranging“ enthält Informationen dazu, mit welchen Ranging-Technologien das Respondergerät das Ranging beenden muss.
Entfernungsmessung beenden	0x0D	Dies ist die Benachrichtigungsantwort auf den Vorgang „Stop Ranging“. Sie enthält Daten dazu, ob der Stoppvorgang für eine bestimmte Ortungstechnologie erfolgreich war oder nicht.

Tabelle 8:Vorgänge für die präzise Suche.

Vorgang „Ranging Capability Request“

In Tabelle 9 wird die Nachricht „Ranging Capability Request“ definiert.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x0A – Vorgang für die Anfrage der Reichweitenfunktion
1	uint8	Datenlänge	variiert
2	Byte-Array	Einmaliger Authentifizierungsschlüssel	Die ersten 8 Bytes von HMAC-SHA256(Kontoschlüssel, Hauptversionsnummer des Protokolls || die letzte Nonce, die aus dem Merkmal gelesen wurde || Daten-ID || Datenlänge || Zusätzliche Daten).
10	Byte-Array	Zusätzliche Daten	Nachricht vom Typ Ranging Capability Request gemäß der Spezifikation Ranging: Out-of-band message sequence and payload (sowohl Header als auch Nutzlast)

Tabelle 9:Anfrage zur Entfernungsbestimmung.

Vorgang „Antwort auf Reichweitenermittlung“

In Tabelle 10 wird die Antwortnachricht für die Entfernungsbestimmung definiert.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x0A: Antwort zur Reichweitenfunktion
1	uint8	Datenlänge	variiert
2	Byte-Array	Einmaliger Authentifizierungsschlüssel	Die ersten 8 Bytes von HMAC-SHA256(Kontoschlüssel, Hauptversionsnummer des Protokolls || zuletzt aus dem Merkmal gelesener Nonce || Daten-ID || Datenlänge || Zusätzliche Daten || 0x01).
10	Byte-Array	Zusätzliche Daten	Nachricht Ranging Capability Response gemäß der Spezifikation Ranging: Out-of-band message sequence and payload (sowohl Header als auch Nutzlast)

Tabelle 10:Antwort zur Entfernungsbestimmung.

Vorgang zur Konfiguration der Entfernungsmessung

In Tabelle 11 wird die Nachricht zur Konfiguration der Entfernungsmessung definiert.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x0B – Ranging-Konfiguration festlegen
1	uint8	Datenlänge	variiert
2	Byte-Array	Einmaliger Authentifizierungsschlüssel	Die ersten 8 Bytes von HMAC-SHA256(Kontoschlüssel, Hauptversionsnummer des Protokolls || die letzte Nonce, die aus dem Merkmal gelesen wurde || Daten-ID || Datenlänge || Zusätzliche Daten).
10	Byte-Array	Zusätzliche Daten	Nachricht Ranging Configuration (Konfiguration für die Entfernungsmessung) gemäß der Spezifikation Ranging: Out-of-band message sequence and payload (sowohl Header als auch Nutzlast)

Tabelle 11:Konfiguration der Entfernungsmessung.

Vorgang für die Antwort auf die Bereichskonfiguration

In Tabelle 12 wird die Antwortnachricht für die Bereichskonfiguration definiert.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x0B – Antwort auf „Ranging-Konfiguration festlegen“
1	uint8	Datenlänge	variiert
2	Byte-Array	Einmaliger Authentifizierungsschlüssel	Die ersten 8 Bytes von HMAC-SHA256(Kontoschlüssel, Hauptversionsnummer des Protokolls || zuletzt aus dem Merkmal gelesener Nonce || Daten-ID || Datenlänge || Zusätzliche Daten || 0x01).
10	Byte-Array	Zusätzliche Daten	Nachricht vom Typ Ranging Configuration Response gemäß der Spezifikation Ranging: Out-of-band message sequence and payload (sowohl Header als auch Nutzlast)

Tabelle 12:Antwort zur Konfiguration von Reichweite

Entfernungsmessung beenden

In Tabelle 13 wird die Nachricht „Stop Ranging“ definiert.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x0D – Ranging Stop
1	uint8	Datenlänge	variiert
2	Byte-Array	Einmaliger Authentifizierungsschlüssel	Die ersten 8 Byte von HMAC-SHA256(Kontoschlüssel, Hauptversionsnummer des Protokolls || die letzte Nonce, die aus dem Merkmal gelesen wurde || Daten-ID || Datenlänge).
10	Byte-Array	Zusätzliche Daten	Nachricht Stop Ranging gemäß der Spezifikation Ranging: Out-of-band message sequence and payload (sowohl Header als auch Nutzlast)

Tabelle 13:Stop Ranging (Entfernungsmessung beenden)

Vorgang „Ranging Response“ beenden

In Tabelle 14 wird die Nachricht „Stop Ranging Response“ definiert.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x0D: Antwort auf Ranging-Stopp
1	uint8	Datenlänge	variiert
2	Byte-Array	Einmaliger Authentifizierungsschlüssel	Die ersten 8 Bytes von HMAC-SHA256(Kontoschlüssel, Hauptversionsnummer des Protokolls || zuletzt aus dem Merkmal gelesener Nonce || Daten-ID || Datenlänge || Zusätzliche Daten || 0x01).
10	Byte-Array	Zusätzliche Daten	Nachricht Stop Ranging Response gemäß der Spezifikation Ranging: Out-of-band message sequence and payload (sowohl Header als auch Nutzlast)

Tabelle 14:Antwort auf „Stop Ranging“

Schutz vor unerwünschtem Tracking mit präziser Ortung

Wenn der Schutz vor unerwünschtem Tracking aktiviert ist (siehe Abschnitt „Schutz vor unerwünschtem Tracking“), gilt für das Überspringen von Authentifizierungsprüfungen für Klingeln-Nachrichten derselbe Ablauf wie für alle in diesem Dokument definierten Nachrichten für die genaue Suche für Geräte, die diese Funktion unterstützen möchten.

Spezifische Informationen zur Ortungstechnologie für die präzise Ortung

Dieser Abschnitt enthält detailspezifische Informationen zur Technologie.

Besonderheiten von Ultrabreitband (UWB)

UWB-spezifische Details

Präzise Ortung

Bei Sitzungen zur präzisen Ortung, bei denen UWB als Ortungstechnologie verwendet wird, werden sowohl Entfernungs- als auch Richtungsinformationen angezeigt. Das Intervall für die Entfernungsmessung muss mindestens 240 ms betragen. Für eine optimale Führung werden 96 ms empfohlen.

Konfigurations-IDs

Die Out-of-Band-Konfigurationsdaten, die für UWB ausgetauscht werden, enthalten nicht alle verfügbaren konfigurierbaren Parameter, die für UWB erforderlich sind, um eine UWB-Entfernungsmessung zu starten. Einige Parameter werden implizit durch die ausgewählte Konfigurations-ID ausgewählt.

Jede Konfigurations-ID ist eine Reihe vordefinierter UWB-Konfigurationsparameter, die öffentlich dokumentiert sind. Für den Anwendungsfall „Präzises Auffinden“ muss das Responder-Gerät Konfigurations-ID 6 und optional Konfigurations-ID 3 unterstützen.

UWB-Initiator und ‑Responder

Für den Anwendungsfall „Präzise Suche“ ist das in diesem Dokument als Initiatorgerät bezeichnete Gerät der UWB-Responder und das in diesem Dokument als Respondergerät bezeichnete Gerät der UWB-Initiator. Das liegt daran, dass das UWB-Initiatorgerät weniger Strom verbraucht als das UWB-Respondergerät. In den meisten Fällen ist das Respondergerät ein Peripheriegerät mit begrenzter Akkulaufzeit.

Das bedeutet, dass das Responder-Gerät in der Nachricht „Ranging Capability Response“ angeben muss, dass es die Rolle des UWB-Initiators unterstützt.

Andere UWB-bezogene Parameter

• Channel 9 muss unterstützt werden
• Für eine optimale Führung wird ein Bereichsintervall von 96 ms empfohlen. Andernfalls müssen 240 ms unterstützt werden.
• Für eine längere Akkulaufzeit wird eine Slot-Dauer von 1 ms empfohlen. 2 ms werden aber auch unterstützt.
• Der UWB-Chip muss mindestens FIRA v1.2- und P-STS-kompatibel sein.
• BPRF ist obligatorisch, HPRF wird empfohlen, ist aber optional. Der unterstützte oder ausgewählte Modus wird durch den unterstützten oder ausgewählten Präambelindex bestimmt.
• Sitzungssicherheitstyp: P-STS

Besonderheiten von BLE Channel Sounding (CS)

BLE CS-spezifische Details.

Präzise Ortung

Bei Sitzungen zur präzisen Ortung, bei denen CS als Entfernungstechnologie verwendet wird, werden nur Entfernungsmessungen durchgeführt. Die Richtung wird derzeit nicht angegeben.

Erforderliche Verbindung zwischen Geräten

Sitzungen zur präzisen Ortung mit Channel Sounding funktionieren nicht, wenn Geräte nicht gekoppelt sind. Es muss eine bestehende Verbindung zwischen dem Initiator- und dem Antwortgerät vorhanden sein. Diese Spezifikation bietet keine Möglichkeit, eine Verbindung zwischen den Geräten herzustellen. Stattdessen muss der Entwickler des Anwendungsfalls diese Verbindung zwischen den Geräten herstellen.

Erforderliche Maßnahmen von der Antwortseite für den Kundenservice

Im Gegensatz zu UWB, wo beide Geräte die UWB-APIs zum Starten und Beenden der Entfernungsmessung explizit aufrufen müssen, muss bei CS nur das Initiatorgerät die CS-Entfernungsmessung durch Aufrufen des Bluetooth-Stacks starten. Die restliche Initialisierung auf der Responderseite erfolgt In-Band über Bluetooth (BT). Das bedeutet, dass die Responder-Seite beim Empfang der Nachricht „Ranging Configuration“ oder „Stop Ranging“ für CS nichts tun muss, wenn BT aktiviert ist, außer mit der Benachrichtigung „Ranging Configuration Response“ zu antworten. Das Antwortgerät könnte diese Nachrichten als Trigger verwenden, um die Benutzeroberfläche zu aktualisieren, wenn ein Bildschirm vorhanden ist. Unabhängig davon, ob ein Bildschirm vorhanden ist, könnte es für visuelles Feedback zum Gerätestatus verwendet werden, z. B. durch Blinken der Geräte-LEDs.

WLAN-NAN-RTT

Details zu Wi-Fi NAN RTT.

Präzise Ortung

Bei Sitzungen zur präzisen Ortung, bei denen Wi‑Fi NAN RTT als Ortungstechnologie verwendet wird, werden nur Entfernungsmessungen durchgeführt. Die Richtung wird derzeit nicht angegeben.

BLE RSSI

BLE RSSI-spezifische Details.

Präzise Ortung

Bei Sitzungen zur genauen Suche, bei denen nur BLE RSSI als Ortungstechnologie verwendet wird, können weder die Entfernungs- noch die Richtungsinformationen abgerufen werden, da BLE RSSI keine genaue Ortungstechnologie ist. Stattdessen wird dem Nutzer angezeigt, dass sich das Gerät in der Nähe oder weit entfernt befindet.

Beworbene Frames

Nach der Bereitstellung wird vom Anbieter erwartet, dass er FHN-Frames mindestens einmal alle 2 Sekunden bewirbt. Wenn Schnelles Pairing-Frames beworben werden, sollte der Anbieter die FHN-Frames in die regulären Schnelles Pairing-Anzeigen einfügen. Beispielsweise sollte der Anbieter alle 2 Sekunden sieben Schnelles Pairing-Anzeigen und eine FHN-Anzeige schalten.

Die leitungsgebundene Bluetooth-Sendeleistung für FHN-Ankündigungen sollte auf mindestens 0 dBm eingestellt sein.

Hinweis :Es wird empfohlen, die FHN-Frames auch dann zu übertragen, wenn sich das Gerät im Energiesparmodus befindet, da es so leichter gefunden werden kann, falls es verloren geht. Bei einigen Geräten ist es möglicherweise nicht möglich, Werbung zu schalten, wenn das Gerät ausgeschaltet ist, da dies die Akkulaufzeit beeinträchtigen würde. In solchen Fällen wird dringend empfohlen, das Gerät regelmäßig zu aktivieren und für kurze Zeit zu bewerben (z.B. alle 10 Minuten aktivieren und 10 Sekunden lang bewerben).

Der FHN-Frame enthält einen öffentlichen Schlüssel, mit dem Standortberichte von allen unterstützten Clients verschlüsselt werden, die zum Crowdsourcing-Netzwerk beitragen. Es gibt zwei Arten von Elliptic Curve-Schlüsseln: einen 160-Bit-Schlüssel, der in BLE 4-Frames passt, und einen 256-Bit-Schlüssel, für den BLE 5 mit erweiterten Werbefunktionen erforderlich ist. Die Implementierung des Anbieters bestimmt, welche Kurve verwendet wird.

Hinweis :Wenn 256-Bit-Schlüssel verwendet werden, können ältere Smartphones, die BLE 5 nicht unterstützen, keine Werbegeräte scannen und melden. Dadurch wird die Größe des Netzwerks verringert.

Ein FHN-Frame ist so aufgebaut:

Oktett	Wert	Beschreibung
0	0x02	Länge
1	0x01	Wert des Datentyps „Flags“
2	0x06	Flag-Daten
3	0x18 oder 0x19	Länge
4	0x16	Wert des Dienstdatentyps
5	0xAA	16-Bit-Dienst-UUID
6	0xFE	…
7	0x40 oder 0x41	FHN-Frame-Typ mit Angabe des Schutzmodus vor unerwünschtem Tracking
8..27		Temporäre 20‑Byte-Kennung
28		Gehashte Flags

Tabelle 15:FHN-Frame, der eine 160-Bit-Kurve unterstützt.

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

Oktett	Wert	Beschreibung
0	0x02	Länge
1	0x01	Wert des Datentyps „Flags“
2	0x06	Flag-Daten
3	0x24 oder 0x25	Länge
4	0x16	Wert des Dienstdatentyps
5	0xAA	16-Bit-Dienst-UUID
6	0xFE	…
7	0x40 oder 0x41	FHN-Frame-Typ mit Angabe des Schutzmodus vor unerwünschtem Tracking
8..39		32‑Byte-Einmalkennung
40		Gehashte Flags

Tabelle 16:FHN-Frame, der eine 256‑Bit-Kurve unterstützt.

Berechnung der temporären Kennung (Ephemeral ID, EID)

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

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

Tabelle 17:Erstellung einer pseudozufälligen Zahl.

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

Hinweis: Der Exponent für den Rotationszeitraum ist fest und auf 10 festgelegt, 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. Weitere Informationen finden Sie in den Kurvendefinitionen in SEC 2: Recommended Elliptic Curve Domain Parameters, in denen die als Nächstes referenzierten Fp, n und G definiert sind.

r' wird nun auf das endliche Feld Fp projiziert, indem r = r' mod n berechnet wird. Schließlich wird R = r * G berechnet, ein Punkt auf der Kurve, der den verwendeten öffentlichen Schlüssel darstellt. Der Beacon gibt Rx als temporäre Kennung aus, die x-Koordinate von R.

Gehashte Flags

Das Feld mit den gehashten Flags wird so berechnet (die Bits werden vom wichtigsten zum unwichtigsten referenziert):

• Bits 0–4: Reserviert (auf 0 gesetzt).
• Die Bits 5–6 geben den Akkustand des Geräts an:
  • 00: Akkustandanzeige nicht unterstützt
  • 01: Normaler Akkustand
  • 10: Niedriger Akkustand
  • 11: Kritisch niedriger Akkustand (Batterie muss bald ausgetauscht werden)
• Bit 7 ist auf 1 gesetzt, wenn sich der Tracker im Modus „Schutz vor unerwünschtem Tracking“ befindet, andernfalls auf 0.

Um den endgültigen Wert dieses Byte zu erhalten, wird es mit dem niedrigstwertigen Byte von SHA256(r) XOR-verknüpft.

Der Wert „r“ muss an die Größe der Kurve angepasst werden. 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 der Beacon keine Akkustandsanzeige unterstützt und sich nicht im Modus „Schutz vor unerwünschtem Tracking“ befindet, darf dieses Byte vollständig aus der Werbung weggelassen werden.

Verschlüsselung mit EID

Hinweis :Die folgenden Details zur Ver- und Entschlüsselung mit EIDs sind nur zur Vervollständigung der Spezifikation enthalten. Nur der Suchende implementiert diese, nicht der Anbieter.

Um eine Nachricht m zu verschlüsseln, würde ein Sichter (der Rx vom Beacon gelesen hat) Folgendes tun:

1. Wählen Sie eine zufällige Zahl s in Fp aus, wie im Abschnitt EID-Berechnung definiert.
2. Compute S = s * G
3. Berechnen Sie R = (Rx, Ry) durch Einsetzen in die Kurvengleichung und Auswahl eines beliebigen Ry-Werts aus den möglichen Ergebnissen.
4. Berechnen Sie den 256-Bit-AES-Schlüssel k = HKDF-SHA256((s * R)x), wobei (s * R)x die x-Koordinate des Ergebnisses der Kurvenmultiplikation ist. Das Salt wurde nicht angegeben.
5. Seien URx und LRx die oberen bzw. unteren 80 Bits von Rx im Big-Endian-Format. Definieren Sie USx und LSx für S auf ähnliche Weise.
6. Compute nonce = LRx || LSx
7. Compute (m’, tag) = AES-EAX-256-ENC(k, nonce, m)
8. Senden Sie (URx, Sx, m’, tag) an den Inhaber, möglicherweise über einen nicht vertrauenswürdigen Remotedienst.

Entschlüsselung von mit EID verschlüsselten Werten

Der Client des Inhabers, der den EIK und den Exponenten für den Rotationszeitraum besitzt, entschlüsselt die Nachricht so:

1. Ermitteln Sie anhand von URx den Wert des Beacon-Zeitcounters, auf dem URx basiert. Dies kann durch die Berechnung von Rx-Werten für Beacon-Zeit-Zählerwerte für die jüngste Vergangenheit und nahe Zukunft durch den Client des Eigentümers erfolgen.
2. Berechnen Sie anhand des Beacon-Zeitcounterwerts, 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 Person, die das Problem gemeldet hat, angegebenen Wert von URx übereinstimmt.
4. Berechnen Sie S = (Sx, Sy) durch Einsetzen in die Kurvengleichung und Auswahl eines beliebigen Sy-Werts aus den möglichen Ergebnissen.
5. Berechnen Sie k = HKDF-SHA256((r * S)x), wobei (r * S)x die x-Koordinate des Ergebnisses der Kurvenmultiplikation ist.
6. Compute nonce = LRx || LSx
7. Compute m = AES-EAX-256-DEC(k, nonce, m’, tag)

ID-Rotation

Für das Broadcasting von FHN-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 Ortungstags, die keine Kopplung verwenden.

Die Schnelles Pairing-Ankündigung, die FHN-Ankündigung und die entsprechenden BLE-Adressen sollten gleichzeitig rotiert werden. Die Rotation sollte im Durchschnitt alle 1.024 Sekunden erfolgen. Der genaue Zeitpunkt, zu dem das Beacon den neuen Identifier bewirbt, muss innerhalb des Zeitfensters zufällig ausgewählt werden.

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

Wenn sich das Gerät im Modus „Schutz vor unerwünschtem Tracking“ befindet, sollte die BLE-Adresse der FHN-Ankündigung fest sein. Die RPA für die nicht erkennbare FP-Ankündigung (z. B. „Schnelles Pairing“) muss jedoch weiterhin rotieren. Es ist zulässig, für die verschiedenen Protokolle unterschiedliche Adressen zu verwenden.

Wiederherstellung nach Stromausfall

Die Auflösung des temporären Bezeichners ist stark an seinen Taktwert zum Zeitpunkt der Anzeige gebunden. Daher ist es wichtig, dass der Anbieter seinen Taktwert wiederherstellen kann, wenn es zu einem Stromausfall kommt. Es wird empfohlen, dass der Anbieter seinen aktuellen Taktwert mindestens einmal täglich in den nichtflüchtigen Speicher schreibt und dass er beim Booten den NVM prüft, um festzustellen, ob ein Wert vorhanden ist, mit dem er initialisiert werden kann. Resolver des temporären Bezeichners würden die Auflösung über einen Zeitraum implementieren, der sowohl eine angemessene Taktabweichung als auch diese Art der Wiederherstellung nach einem Stromausfall ermöglicht.

Dienstleister sollten weiterhin alles tun, um Zeitabweichungen zu minimieren, da das Zeitfenster für die Problemlösung begrenzt ist. Es sollte mindestens eine zusätzliche Methode zur Uhrensynchronisierung implementiert werden (Werbung für nicht erkennbare Fast Pair-Frames oder Implementierung des Nachrichtenstreams).

Implementierungsrichtlinien für „Schnelles Pairing“

In diesem Abschnitt werden spezielle Aspekte der Schnelles Pairing-Implementierung bei Anbietern beschrieben, die FHN unterstützen.

Spezifische Richtlinien für Ortungsgeräte

• Wenn der Anbieter gekoppelt wurde, FHN aber nicht innerhalb von 5 Minuten bereitgestellt wurde (oder wenn ein OTA-Update angewendet wurde, während das Gerät gekoppelt, aber nicht für FHN bereitgestellt war), sollte der Anbieter zur Werkseinstellung zurückkehren und die gespeicherten Kontoschlüssel löschen.
• Nachdem der Anbieter gekoppelt wurde, sollte er seine MAC-Adresse erst ändern, wenn FHN bereitgestellt wurde oder 5 Minuten vergangen sind.
• Wenn der sitzungsspezifische Identitätsschlüssel vom Gerät gelöscht wird, sollte das Gerät auf die Werkseinstellungen zurückgesetzt und die gespeicherten Kontoschlüssel ebenfalls gelöscht werden.
• Der Anbieter sollte normale Bluetooth-Kopplungsversuche ablehnen und nur Fast Pair-Kopplungen akzeptieren.
• Der Anbieter muss einen Mechanismus einbauen, 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).
• Nach einem Stromausfall sollte das Gerät nicht sichtbare Schnelles Pairing-Frames senden, bis read beacon parameters das nächste Mal aufgerufen wird. So kann der Seeker das Gerät erkennen und die Uhr synchronisieren, auch wenn eine erhebliche Zeitabweichung aufgetreten ist.
• Wenn Sie nicht auffindbare Fast Pair-Frames bewerben, sollten keine UI-Hinweise aktiviert sein.
• Sichtbare Schnelles Pairing-Frames sollten nicht beworben werden, während der Anbieter für FHN bereitgestellt wird.
• Der Anbieter darf keine identifizierenden Informationen (z.B. Namen oder IDs) auf nicht authentifizierte Weise offenlegen.

Gerätespezifische Richtlinien für Classic Bluetooth

In diesem Abschnitt werden spezielle Aspekte von Classic Bluetooth-Geräten beschrieben, die FHN unterstützen.

FHN-Bereitstellung von bereits gekoppelten Geräten

Der Anbieter wird nicht immer sofort nach dem Koppeln mit dem Tracker für FHN bereitgestellt, sondern erst einige Zeit 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 Tracker seine BLE-Adresse abrufen kann, während er bereits gekoppelt ist:

• Der Anbieter kann regelmäßig die Kontodaten für das schnelle Pairing bewerben, damit der Suchende seine BLE-Adresse über einen BLE-Scan finden kann.
  Dieser Ansatz eignet sich für Anbieter, die den Nachrichtenstream nicht implementieren.
• Der Anbieter kann diese Daten über den Schnelles Pairing-Nachrichtenstream über klassisches Bluetooth bereitstellen.
  Dieses Verfahren eignet sich für Anbieter, die keine Schnelles Pairing-Frames bewerben, während sie über Bluetooth mit dem Seeker verbunden sind.

Wenn Sie beide Ansätze unterstützen, steigt die Wahrscheinlichkeit, dass der Nutzer das Gerät für FHN bereitstellen kann.

Schnelles Pairing-Nachrichtenstream

Der Anbieter kann den Fast Pair-Nachrichtenstream implementieren und verwenden, um den Seeker über Geräteinformationen zu benachrichtigen. Durch die Implementierung des Nachrichtenstreams werden bestimmte Funktionen aktiviert, wie in diesem Abschnitt beschrieben.

Der Anbieter sollte einmalig Geräteinformationsnachrichten senden, wenn der Nachrichtenstream eingerichtet wird.

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

Wenn ein Firmware-Update dem Anbieter FHN-Unterstützung hinzufügt, kann ein verbundenes Seeker-Gerät den Nutzer darüber informieren und anbieten, die Bereitstellung zu starten. Andernfalls muss der Nutzer manuell zur Bluetooth-Geräteliste navigieren, um die FHN-Bereitstellung zu starten.

Dazu sollte der Anbieter die Eigenschaft „Firmwareversion“ (Code 0x09) verwenden, um einen Stringwert zu melden, der die Firmwareversion darstellt. Außerdem sollte der Anbieter das Protokoll unterstützen, über das der Suchende über Änderungen der Funktionen aufgrund von Firmware-Updates informiert wird.

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

Tabelle 18: Geräteinformationen – aktualisierte Firmwareversion.

Wenn der Anbieter eine Anfrage zur Aktualisierung der Funktionen (0x0601) erhält und die Unterstützung für die FHN-Erfassung aktiviert hat, sollte er wie in Tabelle 12 beschrieben antworten.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Synchronisierung von Gerätefunktionen	0x06
1	uint8	FHN-Tracking	0x03
2–3	uint16	Zusätzliche Datenlänge	0x0007
4	uint8	Status der FHN-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 19:Ereignis zur Synchronisierung der Gerätefunktionen: Tracking-Funktion hinzugefügt.

Aktuelle temporäre ID (Geräteinformationscode 0x0B)

Der Anbieter kann die aktuelle temporäre Kennung (Code 0x0B) verwenden, um die aktuelle EID und den aktuellen Taktwert zu melden, wenn der Anbieter für FHN bereitgestellt wird. So kann der Tracker bei einer Taktabweichung (z. B. aufgrund eines leeren Akkus) synchronisiert werden. Andernfalls initiiert der Seeker zu diesem Zweck eine teurere und weniger zuverlässige Verbindung.

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Geräteinformationen	0x03
1	uint8	Aktuelle temporäre 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 20:Geräteinformationen – Ereignis: Uhrsynchronisierung.

Auf Werkseinstellungen zurücksetzen

Bei Geräten, die das 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 temporären Identitätsschlüssel und alle gespeicherten Kontoschlüssel, einschließlich des Kontoschlüssels des Inhabers, löschen.

Nach dem Zurücksetzen auf die Werkseinstellungen (manuell oder programmatisch) sollte der Anbieter nicht sofort mit der Werbung für Fast Pair beginnen, damit der Kopplungsvorgang nicht sofort nach dem Löschen des Geräts durch den Nutzer gestartet wird.

Schutz vor unerwünschtem Tracking

Zertifizierte FHN-Geräte müssen auch die Anforderungen in der Implementierungsversion der plattformübergreifenden Spezifikation für Unerwünschte Tracker erkennen (Detecting Unwanted Location Trackers, DULT) erfüllen.

Relevante Richtlinien speziell für FHN, um der DULT-Spezifikation zu entsprechen:

• Alle mit FHN 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 in der Implementierungsversion der DULT-Spezifikation definierten Dienst und das Merkmal „Accessory Non-Owner“ implementieren, einschließlich der Vorgänge Accessory Information und Non-owner controls.
• Während des Zeitraums der Abwärtskompatibilität, wie in der DULT-Spezifikation definiert, gibt es keine Änderungen am beworbenen Frame, wie in diesem Dokument definiert.
• Der in diesem Dokument definierte „Schutzmodus vor unerwünschtem Tracking“ entspricht dem in der DULT-Spezifikation definierten „getrennten Status“.
• Richtlinien für die Implementierung der Accessory Information-Opcodes:
  • Get_Product_Data sollte die von der Konsole bereitgestellte Modell-ID zurückgeben, die mit Nullen aufgefüllt wird, um die Anforderung von 8 Byte zu erfüllen. Die Modell-ID 0xFFFFFF wird beispielsweise als 0x0000000000FFFFFF zurückgegeben.
  • „Get_Manufacturer_Name“ und „Get_Model_Name“ sollten mit den in der Console angegebenen Werten übereinstimmen.
  • „Get_Accessory_Category“ kann den generischen Wert „Location 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 BLE-ID-Suche angeben.
  • Get_Network_ID sollte die Kennung von Google (0x02) zurückgeben.
• Richtlinien für die Implementierung des Opcode Get_Identifier:
  • Der Vorgang sollte nur 5 Minuten lang nach der Aktivierung des Identifizierungsmodus durch den Nutzer eine gültige Antwort zurückgeben. Für die Aktivierung ist eine Kombination aus Tastendrücken erforderlich. Ein visuelles oder akustisches Signal sollte dem Nutzer anzeigen, dass der Anbieter in diesen Modus gewechselt ist. Die modellspezifischen Anweisungen zum Aktivieren dieses Modus müssen Google als Voraussetzung für die Zertifizierung und mindestens 10 Tage vor einer Aktualisierung oder Änderung der Anweisungen zur Verfügung gestellt werden.
  • Die Antwort wird so erstellt: die ersten 10 Byte der aktuellen temporären Kennung, gefolgt von den ersten 8 Byte von HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
• Richtlinien für die Implementierung von Kennungen über NFC:
  • Verwenden Sie find-my.googleapis.com/lookup als URL.
  • Verwenden Sie als e-Parameter dieselbe Antwort, die für Get_Identifier erstellt wurde, hexadezimal codiert.
  • Verwenden Sie als pid-Parameter dieselbe Antwort wie für Get_Product_Data, hexadezimal codiert.
• Das Gerät muss einen Soundgenerator enthalten und die Klingelfunktion unterstützen. Gemäß der DULT-Spezifikation muss der Soundgenerator einen Ton mit einer Spitzenlautstärke von mindestens 60 Phon gemäß ISO 532-1:2017 ausgeben.
• Richtlinien für die Implementierung des Opcode Sound_Start:
  • Der Befehl sollte das Klingeln auf allen verfügbaren Komponenten auslösen.
  • Das maximal unterstützte Volumen sollte verwendet werden.
  • Die empfohlene Dauer für das Klingeln beträgt 12 Sekunden.
• Ortungstags 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 Deaktivierungsanleitung muss unter einer öffentlich verfügbaren URL dokumentiert und Google als Voraussetzung für die Zertifizierung mindestens 10 Tage vor einer 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=en“) oder über den HTTP-Header „accept-language“ angegeben.

Richtlinien für wechselbare Protokolle

• Es sollte jeweils nur ein Protokoll verwendet werden. Es darf nur ein Netzwerk gleichzeitig auf dem Gerät aktiv sein. Diese Anforderung ist erforderlich, um sicherzustellen, dass sensible Nutzerdaten nicht zwischen verschiedenen Protokollen vermischt werden.
• Es wird empfohlen, einen Hard-Reset-Ablauf in das Gerät zu integrieren, der es einem Nutzer ermöglicht, ein Gerät mit einem anderen Netzwerk neu einzurichten.
• Das Aktualisieren eines Geräts auf ein Netzwerk sollte nutzerfreundlich und für alle Netzwerke gleich sein. Nutzer müssen in der Lage sein, das gewünschte Netzwerk auszuwählen, ohne dass eines der Netzwerke bevorzugt wird. Dieser Ablauf muss vom Google-Team genehmigt werden.

Firmware-Updates

Der Prozess und die Verteilung von OTA-Updates sollten vom Partner über seinen eigenen Workflow für mobile Apps oder Web-Apps verwaltet werden.

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

• Die aktuelle Firmware-Version sollte in der Nearby Device Console aktualisiert werden.
• In der Nearby Device Console muss eine Companion-App festgelegt werden. Sie sollte den Intent für Firmware-Updates unterstützen.
• Der Anbieter sollte das GATT-Merkmal Firmware-Revision implementieren.

Um Tracking zu verhindern, sollte der Zugriff auf die Eigenschaft Firmware-Revision eingeschränkt werden. Der Seeker liest zuerst den Bereitstellungsstatus und stellt einen Authentifizierungsschlüssel bereit, wie in dieser Spezifikation definiert. Erst dann wird die Firmware-Revision gelesen. Dies erfolgt über dieselbe Verbindung. Wenn versucht wird, die Firmware-Revision zu lesen, und der Anbieter weder gebunden ist noch ein authentifizierter Vorgang über dieselbe Verbindung erfolgreich abgeschlossen wurde, sollte der Anbieter einen nicht authentifizierten Fehler zurückgeben.

Kompatibilität

Für das „Mein Gerät finden“-Netzwerk müssen die Standortdienste und Bluetooth aktiviert sein. Es ist eine Mobilfunk- oder Internetverbindung erforderlich. Verfügbar unter Android 9 und höher in bestimmten Ländern für Nutzer, die das Mindestalter erreicht haben.

Änderungsprotokoll

FHN-Version	Datum	Kommentar
v1		Erste Version der FHN-Spezifikation für den Vorabzugriff.
v1.1	Feb. 2023	Es wurde ein Hinweis im Klartext zum Schutzmodus vor unerwünschtem Tracking hinzugefügt. Es wurde eine Option hinzugefügt, mit der die Authentifizierung von Klingelanfragen im Modus „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 bei Ortungstags hinzugefügt. Eine Klarstellung zur MAC-Adressen-Randomisierung wurde hinzugefügt. Es wurde eine Klarstellung zur MAC-Adressrotation im Schutzmodus vor unerwünschtem Tracking hinzugefügt. Es wurde eine Richtlinie zum Deaktivieren von Tracker-Tags hinzugefügt.
v1.3	Dezember 2023	Es wurde eine Klarstellung zum Identifizieren von Informationen hinzugefügt, die durch Locator-Tags offengelegt werden. Es wurde eine Anforderung hinzugefügt, die Spezifikation zur Verhinderung unerwünschten Trackings zu implementieren. Es wurden Richtlinien für Geräte mit umschaltbarem Protokoll hinzugefügt.