Merkmale

Schnelles Pairing

Der Fast Pair-Anbieter muss den folgenden GATT-Dienst haben.

Dienst UUID
Schnelles Pairing 0xFE2C

Dieser Dienst muss die folgenden Merkmale aufweisen.

Charakteristik des Dienstes „Schnelles Pairing“ Verschlüsselt Berechtigungen UUID
Modell-ID Nein Lesen FE2C1233-8366-4814-8EB0-01DE32100BEA
Schlüsselbasierte Kopplung Nein Schreiben und benachrichtigen FE2C1234-8366-4814-8EB0-01DE32100BEA
Passkey Nein Schreiben und benachrichtigen FE2C1235-8366-4814-8EB0-01DE32100BEA
Kontoschlüssel Nein Schreiben FE2C1236-8366-4814-8EB0-01DE32100BEA

Geräteinformationsdienst

Der Fast Pair-Anbieter sollte auch den Dienst für Geräteinformationen unterstützen.

Dienst UUID
Geräteinformationsdienst 0x180A

Der Schnelles Pairing Seeker verwendet die folgenden Merkmale.

Name Verschlüsselt Berechtigungen UUID
Firmware-Version Nein Lesen 0x2A26

Merkmal: Modell-ID

So kann der Seeker die Modell‑ID bei Bedarf lesen, auch wenn das Gerät nicht im auffindbaren Modus beworben wird. Es sollten immer die folgenden Daten zurückgegeben werden:

Oktett Datentyp Beschreibung Wert
0–2 uint24 Modell-ID variiert

Merkmal: Schlüsselbasiertes Pairing

Dieses Merkmal steuert das schlüsselbasierte Kopplungsverfahren. Bei diesem Verfahren wird ein gewisses Maß an Vertrauen aufgebaut, indem überprüft wird, ob sowohl der Seeker als auch der Provider im Besitz eines vorinstallierten Schlüssels sind. Der Schlüssel ist in jedem Fall unterschiedlich:

  • Fall 1: Der vorinstallierte Schlüssel basiert auf dem öffentlichen/privaten Schlüsselpaar zur Fälschungssicherheit und dem eigenen öffentlichen/privaten Schlüsselpaar des Seeker, das sich bei jedem Pairing-Versuch ändert.

    • Der Anbieter befindet sich im Kopplungsmodus.
    • Der Suchende prüft, ob der Anbieter den privaten Schlüssel zur Anti-Spoofing-Funktion besitzt.

    Beachten Sie, dass der Anbieter im Kopplungsmodus natürlich auch auf die übliche Weise gekoppelt werden kann, z. B. mit einem Gerät, das die schlüsselbasierte Kopplung von Fast Pair nicht unterstützt.

  • Fall 2: Der vorinstallierte Schlüssel ist einer der Kontoschlüssel.

    • Der Anbieter befindet sich normalerweise nicht im Kopplungsmodus. Das ist jedoch keine Voraussetzung. Der Anbieter sollte die Verwendung eines Kontoschlüssels auch im Pairing-Modus unterstützen.
    • Der Suchende und der Anbieter bestätigen jeweils, dass der andere den Kontoschlüssel besitzt.

Da sich beide Fälle nur darin unterscheiden, welcher vorinstallierte Schlüssel verwendet wird, werden sie in Verfahren zusammengefasst.

Datenformat

Hier finden Sie eine Anleitung zur Verwendung der einzelnen Formate.

Oktett Datentyp Beschreibung Wert Erforderlich?
0–15 uint128 Verschlüsselte Anfrage variiert Obligatorisch
16–79 Öffentlicher Schlüssel variiert Optional

Tabelle 1.1:Verschlüsselte Anfrage, die vom Seeker in das Merkmal geschrieben wird.

Oktett Datentyp Beschreibung Wert Erforderlich?
0 uint8 Mitteilungsart 0x00 = Schlüsselbasierte Anfrage zur Kopplung Obligatorisch
1 uint8 Flags
  • Bit 0 (MSB): veraltet und wird von Seeker ignoriert.
  • Bit 1: 1, wenn der Seeker anfordert, dass der Provider die Kopplung initiiert, und diese Anfrage die BR/EDR-Adresse des Seekers enthält. Andernfalls 0.
  • Bit 2: 1, wenn der Suchende verlangt, dass der Anbieter den vorhandenen Namen angibt. Andernfalls 0.
  • Bit 3: 1, wenn dies für das nachträgliche Schreiben des Kontoschlüssels gilt. Andernfalls 0.
  • Die Bits 4 bis 7 sind für die zukünftige Verwendung reserviert und müssen ignoriert werden.
 variiert Obligatorisch
2–7 uint48 Entweder:
  • Aktuelle BLE-Adresse des Anbieters
  • Öffentliche Adresse des Anbieters
 variiert Obligatorisch
8–13 uint48 Adresse des Antragstellers (BR/EDR) variiert Nur präsentieren, wenn Bit 1 oder 3 der Flags festgelegt ist
n – 15 Zufälliger Wert (Salt) variiert Obligatorisch

Tabelle 1.2.1:Rohanfrage (Typ 0x00). Entschlüsselt aus der verschlüsselten Anfrage in Tabelle 1.1.

Oktett Datentyp Beschreibung Wert Erforderlich?
0 uint8 Mitteilungsart 0x10 = Aktionsanfrage Obligatorisch
1 uint8 Flags
  • Bit 0 (MSB): 1, wenn es sich um eine Geräteaktion handelt, andernfalls 0.
  • Bit 1: 1, wenn danach Additional Data characteristic (Zusätzliche Datencharakteristik) folgt, andernfalls 0.
  • Die Bits 2 bis 7 sind für die zukünftige Verwendung reserviert und müssen ignoriert werden.
 variiert Obligatorisch
2–7 uint48 Entweder:
  • Aktuelle BLE-Adresse des Anbieters
  • Öffentliche Adresse des Anbieters
 variiert Obligatorisch
8 uint8 Nachricht an die Gruppe schicken variiert Erforderlich, wenn Flag-Bit 0 festgelegt ist
9 uint8 Nachrichtencode variiert Erforderlich, wenn Flag-Bit 0 festgelegt ist
10 uint8 Abhängig von Flags:
  • Bit 0 ist gesetzt: Zusätzliche Datenlänge, weniger als 6
  • Bit 1 ist festgelegt: Daten-ID
 variiert Erforderlich, wenn Bit 0 oder 1 für Flags festgelegt ist
11 – n Zusätzliche Daten variiert Optional
n – 15 Zufälliger Wert (Salt) variiert Obligatorisch

Tabelle 1.2.2:Rohanfrage (Typ 0x10). Entschlüsselt aus der verschlüsselten Anfrage in Tabelle 1.1.

Oktett Datentyp Beschreibung Wert
0 uint8 Mitteilungsart 0x01 = Antwort auf schlüsselbasierte Kopplung
1–6 uint48 Öffentliche Adresse des Anbieters (BR/EDR) variiert
7–15 Zufälliger Wert (Salt) variiert

Tabelle 1.3:Rohantwort. Verschlüsselt, um die verschlüsselte Antwort in Tabelle 1.4 zu erstellen.

Oktett Datentyp Beschreibung Wert
0–15 uint128 Verschlüsselte Antwort variiert

Tabelle 1.4:Verschlüsselte Antwort, die vom Anbieter über eine Benachrichtigung an den Suchenden gesendet wird.

Merkmal: Passkey

Diese Eigenschaft wird während des schlüsselbasierten Pairing verwendet.

Oktett Datentyp Beschreibung Wert
0–15 uint128 Verschlüsselter Passkey-Block variiert

Tabelle 2.1:Verschlüsselter Passkey-Block. Weitere Informationen finden Sie unter Schlüsselbasierte Kopplung.

Oktett Datentyp Beschreibung Wert
0 uint8 Mitteilungsart Eines der folgenden Elemente:
  • 0x02 = Passkey des Suchenden
  • 0x03 = Passkey des Anbieters
1–3 unit32 6‑stelliger Passkey variiert
4–15 Zufälliger Wert (Salt) variiert

Tabelle 2.2:Rohblock für Passkeys. Entschlüsselte Version von Tabelle 2.1.

Merkmal: Kontoschlüssel

Nach dem Koppeln schreibt der Fast Pair-Seeker einen Kontoschlüssel in den Fast Pair-Provider.

Oktett Datentyp Beschreibung Wert
0–15 uint128 Kontoschlüssel (verschlüsselt) variiert

Wenn der Fast Pair-Anbieter eine Schreibanfrage erhält, muss er Folgendes tun:

  1. Entschlüsseln Sie den Kontoschlüssel mit dem gemeinsamen Secret, das in Schritt 4 der Anleitung generiert wurde.
    • Für Anbieter, die eine Verpflichtung erfordern (häufig):
      • Prüfen Sie vor dem Entschlüsseln, ob das Gemeinsame Secret zum Entschlüsseln der Passkey-Anfrage aus Schritt 12 verwendet wurde. Wenn dieser Schritt mit diesem Secret nicht bestanden wurde, ignoriere diesen Schreibvorgang und beende den Vorgang.
    • An diesem Punkt wird das gemeinsame Secret (K im Verfahren) für diese Kopplung nicht mehr verwendet. Alle Anfragen, die mit diesem Schlüssel verschlüsselt eingehen, ohne dass das Verfahren neu gestartet wurde, sollten abgelehnt werden.
  2. Prüfen Sie, ob der entschlüsselte Wert mit 0x04 oder 0xFF beginnt. Wenn nicht, ignoriere diesen Schreibvorgang und beende den Vorgang.
    • Wenn der Wert 0x04 ist:
      • Prüfen Sie, ob in der gespeicherten Account Key list (Liste der Kontoschlüssel) Platz für den neuen Wert ist.
      • Wenn nicht, löschen Sie den Wert, der am längsten nicht verwendet wurde, aus der Liste.
      • Fügen Sie der Liste den neuen Wert hinzu.
    • Wenn der Wert 0xFF ist:
      • Betrachte dies als temporäre Kopplungssitzung und führe keine Aktion aus.
      • Das kann beim Ablauf Kontoschlüssel rückwirkend schreiben passieren.
      • Speichern Sie den Schlüssel nicht und verwenden Sie ihn nicht in der Liste der Kontoschlüssel, für die Verschlüsselung oder für MAC-Berechnungen.
      • Das Entfernen von Anleihen wird durch ein funktionsspezifisches Ereignis oder einen Timeout ausgelöst. Für die LE-Audio-Freigabe wird dringend empfohlen, die BLE-Verbindung und den Link-Schlüssel 10 Minuten nach dem Trennen der temporären Sitzung zu entfernen.

Die Kontoschlüssel in der Liste werden während der schlüsselbasierten Kopplung verwendet.

Merkmal: Firmware-Version

So kann der Seeker die Firmware-Version des Bereitstellers bei Bedarf lesen. Es sollten immer die folgenden Daten zurückgegeben werden:

Oktett Datentyp Beschreibung Wert
0 – var utf8s Firmware-Revisionscode variiert

Sie sollte in einem einzelnen UTF8-String eingeschlossen werden, auch wenn es mehr als eine Firmware gibt (z. B. drei Firmwares für den linken Kopfhörer, den rechten Kopfhörer und das Case). Der Anbieter kann auch die spezifischen Strings für Sonderfälle zurückgeben:

  1. status-updating: Der Bereitsteller wird gerade auf eine neue Firmware aktualisiert. Alternativ kann der Anbieter die Version der bereitgestellten Firmware zurückgeben.

  2. status-abnormal: wenn sich der Anbieter in einem ungewöhnlichen Zustand befindet. Das Gerät hat beispielsweise nicht richtig funktioniert, weil das Firmware-Update fehlgeschlagen ist. Dieser Wert bewirkt, dass dem Nutzer eine Meldung angezeigt wird, dass der Seeker jetzt aktualisiert werden muss.

Der Anbieter sollte den Zugriff auf das Merkmal „Firmware-Revision“ einschränken, um das Tracking von Geräten zu verhindern. Vorgeschlagene Einschränkungen:

  • Gekoppelte Geräte sollten jederzeit Zugriff haben.
  • Jedes Gerät sollte Zugriff haben, wenn der Anbieter gefunden werden kann.

Merkmal: Zusätzliche Daten

Dieser Dienst muss die folgende Eigenschaft haben.

Charakteristik des Dienstes „Schnelles Pairing“ Verschlüsselt Berechtigungen UUID
Daten Nein Schreiben und benachrichtigen FE2C1237-8366-4814-8EB0-01DE32100BEA
Altes Merkmal des Dienstes „Schnelles Pairing“ (wird am 01.01.2021 eingestellt) Verschlüsselt Berechtigungen UUID
Daten Nein Schreiben und benachrichtigen 0x1237

Bevor Sie in diese Eigenschaft schreiben oder sie benachrichtigen, muss ein Handshake über die Eigenschaft FE2C1234-8366-4814-8EB0-01DE32100BEA erfolgen, um ein gemeinsames Secret zu erhalten. AES-CTR wird verwendet, um Daten zu verschlüsseln, die über dieses Merkmal übertragen werden. Der Algorithmus ist unten definiert. Dieser Modus ist sicherer für Daten, die über einen einzelnen 16‑Byte-Block hinausgehen. HMAC-SHA256 wird verwendet, um die Datenintegrität zu gewährleisten. Dies wird unten ebenfalls definiert.

Oktett Beschreibung Wert
0–7 Die ersten 8 Byte von HMAC-SHA256. variiert
8–15 Nonce, die von der AES-CTR-Verschlüsselung verwendet wird. variiert
16 – var Verschlüsselte Daten variiert

Tabelle 3.1:Datenpaket, das vom Anbieter über eine Benachrichtigung an den Suchenden gesendet wird oder vom Suchenden über einen Schreibvorgang an den Anbieter gesendet wird.

Oktett Datentyp Beschreibung Wert
0 – var byte array Daten variiert. Decodieren Sie den Wert gemäß der Daten-ID von Tabelle 1.2.2:
  • 0x01(personalisierter Name): utf8s

Tabelle 3.2:Rohdaten. Entschlüsselt aus den verschlüsselten Daten in Tabelle 3.1.

Wenn eine Benachrichtigung angefordert wird (z.B. personalisierter Name über Bit 2 in Tabelle 1.2.1), muss der Fast Pair-Anbieter Folgendes tun:

  1. Generieren Sie kryptografisch zufällige 8 Byte für die Nonce.

  2. Verschlüsseln Sie die Daten mit AES-CTR, wobei jeder 16‑Byte-Block mit

    encryptedBlock[i] = clearBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))

    Bitte wo?

    1. Der AES-Schlüssel ist das gemeinsame Secret aus Schritt 4 der Anleitung.
    2. clearBlock[i] ist ein 16‑Byte-Block, der mit data[i * 16] beginnt. Der letzte Block kann weniger als 16 Byte umfassen.

  3. Führen Sie „concat(encryptedBlock[0], encryptedBlock[1],…)“ aus, um die verschlüsselten Daten zu erstellen.

  4. HMAC-SHA256 generieren

    sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, encrypted_data)))))

    Bitte wo?

    1. K wird durch concat(shared_secret, 48-byte ZEROs) generiert. Das shared_secret stammt aus Schritt 4 des Verfahrens.
    2. opad ist ein 64-Byte-Outer-Padding, das aus wiederholten Bytes mit dem Wert 0x5C besteht.
    3. ipad ist ein 64-Byte-Inner-Padding, das aus wiederholten Bytes mit dem Wert 0x36 besteht.

  5. Nimm die ersten 8 Byte des HMAC-SHA256 als Präfix des Datenpakets.

Wenn der Fast Pair-Anbieter eine Schreibanfrage erhält, muss er Folgendes tun:

  1. Prüfen Sie die Integrität der Daten, indem Sie die ersten 8 Byte von HMAC-SHA256 untersuchen.

  2. Entschlüsseln Sie die verschlüsselten Daten mit AES-CTR, wobei jeder Block mit

    clearBlock[i] = encryptedBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))

    Bitte wo?

    1. encryptedBlock[i] ist ein 16‑Byte-Block, der mit encrypted_data[i * 16] beginnt. Der letzte Block kann weniger als 16 Bytes umfassen.
    2. Der AES-Schlüssel wird aus dem Handshake generiert oder identifiziert, z.B.
      1. Im Namensfluss 1 stammt er von ECDH und wird für diese Kopplung nicht noch einmal verwendet. Alle Anfragen, die mit diesem Schlüssel verschlüsselt eingehen, ohne dass das Verfahren neu gestartet wurde, sollten abgelehnt werden.
      2. Im Benennungsablauf 2 ist es der Kontoschlüssel.

  3. Führen Sie „concat(clearBlock[0], clearBlock[1],…)“ aus, um die Rohdaten zu erstellen.