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 BLE-Geräten (Bluetooth Low Energy), die Signale senden. Auf dieser Seite wird FHN als Erweiterung der Spezifikation für Schnelles Pairing beschrieben. Anbieter sollten diese Erweiterung aktivieren, wenn sie Geräte haben, die mit FHN kompatibel sind, und bereit sind, die Standortverfolgung für diese Geräte zu aktivieren.

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 für 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 einem anderen Nonce führen und ein einzelnes 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 über einen oder mehrere der folgenden Schlüssel nach:

• Kontoschlüssel: Der 16‑Byte-Kontoschlüssel für Schnelles Pairing, 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 erhalten, nachdem sie bereits gekoppelt wurden (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 zum Lesen des Bereitstellungsstatus aus dem Beacon-Aktionsmerkmal verwendet wird, 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 Byte. 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.

• Ringschlüssel: Definiert als SHA256(ephemeral identity key || 0x02), gekürzt auf die ersten 8 Byte. Der Schlüssel wird im Backend gespeichert und der Suchende kann ihn nur verwenden, um das Gerät klingeln zu lassen.

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

Vorgänge

Das Format der Daten, die in das Merkmal geschrieben werden, ist in den Tabellen 2 bis 5 angegeben. Die einzelnen Vorgänge werden 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	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 Schlüssels für die Beacon-Bereitstellung.

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: Nicht zutreffend

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:Antrag auf Schutz vor unerwünschten Bluetooth-Trackern

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	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	Byte-Array	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: Auswahl der Klingeltonlautstärke nicht verfügbar. 0x01: Auswahl der Klingeltonlautstärke verfügbar. Wenn festgelegt, muss der Anbieter drei Lautstärkepegel akzeptieren und verarbeiten, wie unter Klingelvorgang 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	Bereitstellungsstatus	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 durch, 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 sitzungsspezifische 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 und der Anbieter sollte ab diesem Zeitpunkt FHN-Frames bewerben. Der neue temporäre Identitätsschlüssel wird sofort nach Beendigung der BLE-Verbindung wirksam. Der Bereitsteller 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 Auslieferung von FHN-Frames. Der Anbieter benachrichtigt mit einer Antwort aus Tabelle 6 mit der Daten-ID 0x03. Das Authentifizierungssegment ist als die ersten 8 Byte von HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) definiert.

Temporären Identitätsschlüssel mit Nutzereinwilligung lesen

Diese Option ist nur verfügbar, um einen verlorenen Schlüssel wiederherzustellen, da der Schlüssel nur lokal vom Suchenden 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 einer 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 den 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 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 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	Zeitüberschreitung	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 zum Überspringen der Authentifizierung per Klingeln 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	Zeitüberschreitung	Die verbleibende Klingelzeit 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 Beenden des Klingelns empfangen wird, sollte der Anbieter eine Benachrichtigung mit dem Klingelstatus oder entweder 0x00: Started (GATT-Anfrage) 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 :Bei Anbietern, die eine Erkennung auf dem Kopf unterstützen, sollte geprüft werden, ob sich das Gerät auf dem Kopf befindet, bevor es mit maximaler Lautstärke klingelt. Wenn die Trageerkennung nicht unterstützt wird oder nicht zuverlässig ist, erhöhe die Lautstärke schrittweise, damit der Nutzer Zeit hat, das Klingeln zu beenden oder die Kopfhörer herauszunehmen.

Hinweis :Der Anbieter 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, weil sich der Client zu weit vom Gerät entfernt hat. 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 aus, der aus einer Anfrage aus Tabelle 4 mit der Daten-ID 0x06 besteht. Der Anbieter prüft, ob der bereitgestellte Einmal-Authentifizierungsschlüssel mit dem Ringschlü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	Zeitüberschreitung	Die verbleibende Klingelzeit 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ünschten Trackern soll es jedem Client ermöglichen, missbräuchliche Geräte ohne Serverkommunikation zu identifizieren. Standardmäßig sollte der Anbieter alle Kennungen rotieren, wie unter ID-Rotation beschrieben. Der Dienst „Mein Gerät finden“ kann eine unerwünschte 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 Schutzmodus 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 „Schutz vor unerwünschten Trackern“

Der Anbieter erstellt das Datensegment so:

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Steuerungsflags	0x01: Authentifizierung durch Anrufen überspringen. Wenn diese Einstellung 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 Beacon die Häufigkeit der Rotation privater MAC-Adressen auf einmal pro 24 Stunden reduzieren. Die beworbene temporäre Kennung sollte wie gewohnt rotiert werden. Der Frame-Typ sollte auf 0x41 festgelegt sein. Der Status wird auch im Abschnitt gehashte Flags angezeigt.

Beim Deaktivieren des Modus „Schutz vor unerwünschtem Tracking“

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 Modus zum Schutz vor unerwünschtem Tracking deaktiviert ist, sollte das Beacon die MAC-Adresse wieder in normalem Tempo rotieren lassen, synchronisiert mit der Rotation der temporären Kennung. Der Frame-Typ 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.

Genaue Ortung

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

Die Art der genauen Ortung hängt von den auf den Geräten, die an der genauen 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 genauen Ortung

In diesem Abschnitt wird der FHNA-Nachrichtenfluss für die Genaue Ortung beschrieben. Abbildung 1 zeigt den Fluss der Nachrichten und in den Absätzen wird jede Nachricht genauer erläutert.

Abb. 1: Typischer Ablauf von Nachrichten bei der genauen Ortung

Das Initiatorgerät ist das Gerät, auf dem die App „Mein Gerät finden“ installiert ist und auf dem die Funktion „Genaue Ortung“ aktiviert wurde. Der Initiator ist das Gerät, das versucht, 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“ (Anfrage zur Reichweitenbestimmung) an das Respondergerät. Darin werden die Technologien zur Reichweitenbestimmung aufgeführt, über die das Initiatorgerät vom Respondergerät informiert werden möchte. Das Responder-Gerät antwortet mit der Benachrichtigung „Ranging Capability Response“ (Antwort auf Anfrage zur Reichweitenbestimmung), die Informationen dazu enthält, welche Technologien zur Reichweitenbestimmung unterstützt werden und welche Funktionen sie bieten. Der Antwortende gibt nur Informationen an, die vom Initiator angefordert wurden. Die Liste der Funktionen wird nach der Priorität der Ortungstechnologie sortiert, die das Responder-Gerät bevorzugt. Die erste Funktion in der Liste hat die höchste Priorität.

Das Initiatorgerät sendet dann eine Nachricht zur Konfiguration der Entfernungsmessung, in der die Konfiguration für jede Entfernungsmessungstechnologie definiert wird, mit der es die Entfernung messen möchte. Nach dem Empfang dieser Nachricht muss das Responder-Gerät mit der Entfernungsmessung für die entsprechenden Technologien anhand der bereitgestellten Konfigurationen beginnen. Das Antwortgerät sendet eine Benachrichtigung zur Reichweitenkonfiguration zurück, die die Ergebnisse dazu enthält, ob die einzelnen Reichweitentechnologien erfolgreich gestartet wurden. Bei einigen Technologien zur Entfernungsmessung muss die Messung sowohl auf dem Initiator- als auch auf dem Responder-Gerät gestartet werden, damit die Entfernungsmessung erfolgreich ist. Bei anderen Technologien ist es nur erforderlich, dass die Messung auf dem Initiator-Gerät gestartet wird. Das Responder-Gerät muss jedoch mit einem Erfolgsergebnis antworten. Weitere Informationen zum Verhalten bestimmter Ranging-Technologien finden Sie in den folgenden Abschnitten.

Sobald das Initiatorgerät bereit ist, die Sitzung zur Genaue Ortung zu beenden, sendet es eine „Stop Ranging“-Nachricht an das Respondergerät, in der angegeben wird, welche Technologien zur Entfernungsmessung beendet werden müssen. Das Responder-Gerät antwortet mit einer Benachrichtigung vom Typ „Stop Ranging Response“ (Antwort auf „Stop Ranging“), die angibt, dass die Entfernungsmessung mit den angeforderten Technologien erfolgreich beendet wurde.

Wenn die BLE GATT-Kommunikation des FHNA-Kanals während einer Sitzung zur genauen Suche unterbrochen wird, aber einige der Ranging-Technologien weiterhin funktionieren, implementiert das Responder-Gerät einen Zeitlimitmechanismus, um sicherzustellen, dass es nicht unbegrenzt sucht. 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 Responder-Gerät muss beispielsweise mehrere Anfragen für die Ranging-Funktion hintereinander oder sogar einen direkten Ranging-Konfigurationsvorgang ohne die vorherige Funktionsanfrage verarbeiten können.

Vorgänge für die genaue Ortung

Tabelle 8 enthält die in diesem Dokument definierten FHNA-Vorgänge, die für die Genaue Ortung erforderlich sind. In jedem Unterabschnitt wird die FHNA-Nachricht für die einzelnen Vorgänge definiert. Der Inhalt des Felds Zusätzliche Daten bezieht sich auf die Spezifikation Ranging: Out-of-band message sequence and payload.

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 Anfrage zur Ranging-Funktion	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 Reichweitenmessung mit den angeforderten Reichweitenmesstechnologien 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 genaue Ortung.

Vorgang „Ranging Capability Request“

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

Oktett	Datentyp	Beschreibung	Wert
0	uint8	Daten-ID	0x0A – Ranging Capability Request-Vorgang
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 (Anfrage zur Entfernungsbestimmung), wie in der Spezifikation Ranging: Out-of-band message sequence and payload (Entfernungsbestimmung: Out-of-band-Nachrichtensequenz und ‑Nutzlast) definiert (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 auf die Anfrage zur Ranging-Funktion
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 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 (sowohl Header als auch Nutzlast), wie in der Spezifikation Ranging: Out-of-band message sequence and payload definiert

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 – Ranging Stop Response
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 genauer 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.

Spezifikationen der Ortungstechnologie für die genaue Ortung

Dieser Abschnitt enthält detailspezifische Informationen zur Technologie.

Besonderheiten von Ultrabreitband (UWB)

UWB-spezifische Details

Genaue Ortung

Bei Sitzungen zur genauen 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 UWB zum Starten einer UWB-Entfernungsmessungssitzung benötigt. Einige Parameter werden durch die ausgewählte Konfigurations-ID implizit ausgewählt.

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

UWB-Initiator und ‑Responder

Im Anwendungsfall „Genaue Ortung“ ist das Gerät, das in diesem Dokument als Initiatorgerät bezeichnet wird, der UWB-Responder und das Gerät, das in diesem Dokument als Respondergerät bezeichnet wird, 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 Akkukapazität.

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 + 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 Preamble-Index bestimmt.
• Sicherheitstyp der Sitzung: P-STS

Besonderheiten von BLE Channel Sounding (CS)

BLE CS-spezifische Details.

Genaue Ortung

Bei Sitzungen zur genauen Ortung, bei denen CS als Ortungstechnologie verwendet wird, werden nur Entfernungsmessungen durchgeführt. Die Richtung wird derzeit nicht angegeben.

Erforderliche Verbindung zwischen Geräten

Sitzungen zur genauen 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 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 starten, indem es den Bluetooth-Stack aufruft. Der Rest der Initialisierung auf der Responder-Seite 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.

Genaue Ortung

Bei Sitzungen zur genauen 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.

Genaue 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 muss der Anbieter FHN-Frames mindestens alle 2 Sekunden bewerben. Wenn Fast Pair-Frames beworben werden, sollte der Anbieter die FHN-Frames in die regulären Fast Pair-Anzeigen einfügen. Der Anbieter sollte beispielsweise alle zwei Sekunden sieben Fast Pair- und eine FHN-Ankündigung senden.

Die durchgeführte Bluetooth-Sendeleistung für FHN-Anzeigen 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 Geräte scannen und melden, die Werbung schalten. Dadurch wird die Größe des Netzwerks reduziert.

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-Einmal-ID
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: Das Gerät hat einen 32-Bit-Zeitzähler in Sekunden.

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 jetzt auf das endliche Feld Fp projiziert, indem r = r' mod n berechnet wird. Berechnen Sie schließlich R = r * G. Das ist ein Punkt auf der Kurve, der den verwendeten öffentlichen Schlüssel darstellt. Der Beacon bewirbt Rx als temporäre Kennung. Das ist 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 wird 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 für „r“ sollte 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 zum 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 Seeker implementiert diese, nicht der Provider.

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 des Rotationszeitraums 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 sein.

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

Das Auflösen der temporären Kennung ist stark an ihren Taktwert zum Zeitpunkt der Anzeige gebunden. Daher ist es wichtig, dass der Anbieter seinen Taktwert 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 dass der Anbieter beim Booten den NVM prüft, um zu sehen, ob ein Wert vorhanden ist, mit dem er initialisiert werden kann. Resolver für die temporäre Kennung würden die Auflösung über einen Zeitraum implementieren, der sowohl einen angemessenen Taktversatz als auch diese Art der Wiederherstellung nach 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 Uhrzeitsynchronisierung 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 auf nicht authentifizierte Weise offenlegen, z.B. Namen oder IDs.

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 für FHN bereitgestellt, wenn er mit dem Suchenden gekoppelt wird, 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 Suchende seine BLE-Adresse abrufen kann, während er bereits gekoppelt ist:

• Der Anbieter kann regelmäßig die Fast Pair-Kontodaten 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.
  Diese Methode eignet sich für Anbieter, die keine Schnelles Pairing-Frames bewerben, während sie über Bluetooth mit dem Seeker verbunden sind.

Wenn beide Ansätze unterstützt werden, erhöht sich die Wahrscheinlichkeit, dass der Nutzer das Gerät für 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 verbundener Seeker den Nutzer darüber informieren und anbieten, das Gerät bereitzustellen. 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	FHN-Bereitstellungsstatus	0x00, wenn nicht bereitgestellt; 0x01, wenn von einem Konto bereitgestellt
5 - 10	Byte-Array	Die aktuelle BLE-MAC-Adresse des Geräts	variiert

Tabelle 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 eine teurere und weniger zuverlässige Verbindung für diesen Zweck.

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 sowie 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 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 von 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 8-Byte-Anforderung zu erfüllen. Beispiel: Die Modell-ID 0xFFFFFF wird 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 Identifikationsmodus durch den Nutzer eine gültige Antwort zurückgeben. Für die Aktivierung des Identifikationsmodus 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 beenden 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 Partner sollte den Prozess und die Verteilung von OTA-Updates über seinen eigenen Workflow für mobile Apps oder Web-Apps verwalten.

„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 das Merkmal Firmware-Revision eingeschränkt werden. Der Suchende liest zuerst den Bereitstellungsstatus und stellt dann einen Authentifizierungsschlüssel bereit, wie in dieser Spezifikation definiert. Erst danach wird die Firmware-Version gelesen. Das 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 für die Wiederherstellung nach einem Stromausfall in Locator-Tags 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.