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 Fast Pair-Spezifikation 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.

GATT-Spezifikation

Dem Fast Pair-Dienst 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:Fast Pair-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. Vor jeder Operation muss der Seeker einen Lesevorgang für das Merkmal in Tabelle 1 ausführen, was zu einem Puffer im folgenden Format führt:

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

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 werden soll. 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:

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 Variabel
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: Nicht zutreffend
  • 0x02: 32 Byte, die den sitzungsspezifischen Identitätsschlüssel darstellen, AES-ECB-128-verschlüsselt mit dem Kontoschlüssel. 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 Einwilligung des Nutzers 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 zum Abrufen des Schlüssels für die Beacon-Bereitstellung.

Oktett Datentyp Beschreibung Wert
0 uint8 Daten-ID
  • 0x05: Klingelton
  • 0x06: Ruftonstatus lesen
1 uint8 Datenlänge Variabel
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 Variabel
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
  • 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 Einwilligung des Nutzers 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 Variabel
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 Zehntelsekunden 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 Einwilligung des Nutzers 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 Ü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 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 Zero-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.

Status der Bereitstellung 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

Wenn ein nicht bereitgestellter Anbieter als FHN-Beacon bereitgestellt oder der temporäre Identitätsschlüssel eines bereits bereitgestellten Anbieters geändert werden soll, 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 Dienstleister 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 ab diesem Zeitpunkt sollte der Anbieter mit der Übertragung von FHN-Frames beginnen. 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 Dienstleister 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 Werbung für 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 Sucher gespeichert wird. Daher ist diese Funktion nur verfügbar, wenn sich das Gerät im Kopplungsmodus befindet oder für eine begrenzte Zeit, nachdem eine physische Taste auf dem Gerät gedrückt wurde (was einer Einwilligung des Nutzers entspricht).

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

Ring-Vorgang

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 Ring-Vorgang 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 festzulegen, wie lange es klingeln soll, bevor der Ton stummgeschaltet 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 angegeben. 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 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 zum Beenden des Klingelns empfangen wird, sollte der Anbieter 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.

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 nicht authentifizierten Fehler zurück.

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

Oktett Datentyp Beschreibung Wert
0 uint8 Klingelkomponenten Die Komponenten, die aktiv klingeln, wie in der Klingelanfrage definiert.
1–2 uint16 Zeitlimit 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 wie unter ID-Rotation beschrieben rotieren. 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, damit Clients das Gerät erkennen und den Nutzer vor möglichen unerwünschten Tracking-Aktivitäten warnen können.

Um den unerwünschten Tracking-Schutzmodus 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 nicht authentifizierter Fehler zurückgegeben.

Wenn der unerwünschte Tracking-Schutzmodus aktiviert ist, sollte die Häufigkeit der Rotation privater MAC-Adressen auf einmal pro 24 Stunden reduziert werden. 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.

Wenn Sie den Schutz vor unerwünschtem Tracking deaktivieren

Der Dienstleister bestätigt, dass:

  • Der bereitgestellte Einmal-Authentifizierungsschlüssel stimmt mit dem Schutzschlüssel für unerwünschtes 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 Bestätigung fehlschlägt, gibt der Anbieter einen nicht authentifizierten Fehler zurück.

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

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-Advertisements und ein FHN-Advertisement senden.

Die durchgeführte Bluetooth-Sendeleistung für FHN-Anzeigen sollte auf mindestens 0 dBm eingestellt sein.

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.

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 20‑Byte-Einmalkennung
28 Gehashte Flags

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

In Tabelle 9 sind die Byte-Offsets und Werte für eine 256-Bit-Kurve aufgeführt.

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 9: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-Zeitcounter 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-Zeitcounter im 32-Bit-Big-Endian-Format. Die K niedrigsten Bits werden gelöscht.

Tabelle 10:Erstellung einer pseudozufälligen Zahl.

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 im Folgenden 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, einen Punkt auf der Kurve, der den verwendeten öffentlichen Schlüssel darstellt. Der Beacon bewirbt Rx als temporäre Kennung, die der x-Koordinate von R entspricht.

Gehashte Flags

Das Feld „Hashed Flags“ wird so berechnet (die Bits werden vom höchstwertigen zum niedrigstwertigen Bit 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: Akkustand sehr niedrig (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 Akkuladestandsanzeige 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

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 Bit 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. Dazu berechnet das Clientgerät des Inhabers Rx-Werte für Beacon-Zeit-Zählerwerte für die jüngste Vergangenheit und die nahe Zukunft.
  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 Ortungs-Tags, die keine Kopplung verwenden.

Die Fast Pair-Ankündigung, die FHN-Ankündigung und die entsprechenden BLE-Adressen sollten gleichzeitig rotiert werden. Die Rotation sollte durchschnittlich 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

Die Auflösung 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 festzustellen, 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 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 Fast Pair-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 auffindbare Fast Pair-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 es zu einer erheblichen Zeitabweichung gekommen ist.
  • Wenn Sie nicht auffindbare Fast Pair-Frames bewerben, sollten keine UI-Hinweise aktiviert sein.
  • Erkennbare Fast Pair-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 Bluetooth Classic

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 für FHN bereitgestellt, wenn er mit dem Seeker gekoppelt wird, sondern erst einige Zeit danach. In diesem Fall hat der Anbieter möglicherweise keine aktuelle BLE-MAC-Adresse, die zum Herstellen einer GATT-Verbindung erforderlich ist. Der Anbieter muss mindestens eine der folgenden Möglichkeiten unterstützen, damit der 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 Fast Pair-Nachrichtenstream über klassisches Bluetooth bereitstellen.
    Diese Methode eignet sich für Anbieter, die keine Fast Pair-Frames bewerben, während sie über Bluetooth mit dem Seeker verbunden sind.

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

Fast Pair-Nachrichtenstream

Der Anbieter kann den Fast Pair-Nachrichtenstream implementieren und ihn verwenden, um den Sucher ü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 RFCOMM-Kanal des Nachrichtenstreams 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 Liste der Bluetooth-Geräte gehen, 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 Variabel
Variable Byte-Array Versionsstring Variabel

Tabelle 11:Ereignis mit 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 Variabel

Tabelle 12: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 13: Ereignis „Geräteinformationen“ – 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 Eigentümers, 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 „Hub suchen“ muss aktiviert sein.
  • Das Gerät muss den Dienst und das Merkmal „Accessory Non-Owner“ implementieren, die in der Implementierungsversion der DULT-Spezifikation definiert sind, einschließlich der Vorgänge Accessory Information und Non-owner controls.
  • Während des 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-Opcode:
    • 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. 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 Identifikationsmodus 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 Anleitungen zum Aktivieren dieses Modus müssen Google als Voraussetzung für die Zertifizierung und mindestens 10 Tage vor einer Aktualisierung oder Änderung der Anleitung 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 Summer 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.
  • Locator-Tags 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 zur Verfügung gestellt werden. Außerdem muss sie mindestens 10 Tage vor einem Update oder einer Änderung der Anleitung erfolgen.
    • 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 immer nur ein Protokoll verwendet werden. Es darf nicht mehr als 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 die Absicht 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 Seeker 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 Find Hub-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ünschten Trackern“ ü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 Modus „Schutz 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.