Eigenschaften

Schnelles Pairing

Der Anbieter für schnelles Pairing bietet den folgenden GATT-Dienst an.

Dienst UUID
Schnelles Pairing 0xFE2C

Dieser Dienst muss die folgenden Merkmale haben.

Merkmal „Schnelles Pairing“ Verschlüsselt Berechtigungen UUID
Modell-ID Nein Lesen FE2C1233-8366-4814-8EB0-01DE32100BEA
Schlüsselbasiertes Pairing 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 Anbieter für schnelles Pairing sollte auch den Geräteinformationsdienst unterstützen.

Dienst UUID
Geräteinformationsdienst 0x180A

Für die Funktion „Schnelles Pairing“ werden die folgenden Eigenschaften verwendet.

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

Merkmal: Modell-ID

Diese Eigenschaft ermöglicht es dem Seeker, die Modell-ID bei Bedarf zu lesen, auch wenn das Gerät nicht im Erkennungsmodus beworben wird. Es sollten immer die folgenden Daten zurückgegeben werden:

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

Merkmal: schlüsselbasierte Kopplung

Diese Eigenschaft steuert das schlüsselbasierte Kopplungsverfahren. Bei diesem Verfahren wird ein gewisses Maß an Vertrauen geschaffen, indem überprüft wird, ob der Suchende und der Anbieter beide 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 Anti-Spoofing-Schlüsselpaar und dem öffentlichen/privaten Schlüsselpaar des Suchenden, das sich bei jedem Kopplungsversuch ändert.

    • Der Anbieter befindet sich im Kopplungsmodus.
    • Der Suchende überprüft, ob der Provider im Besitz des privaten Schlüssels gegen Spoofing ist.

    Im Kopplungsmodus kann der Anbieter natürlich auch auf die übliche Weise gekoppelt werden, z. B. um ein Gerät zu koppeln, das die schlüsselbasierte Kopplung durch schnelles Pairing 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 Kopplungsmodus unterstützen.)
    • Der Suchende und der Anbieter überprüfen beide, ob die jeweils andere Person im Besitz des Kontoschlüssels ist.

Da beide Fälle äußerst ähnlich sind, mit Ausnahme des vorinstallierten Schlüssels, werden sie in einem Verfahren kombiniert.

Datenformat

Informationen zur Verwendung der einzelnen Formate finden Sie hier.

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

Tabelle 1.1:Verschlüsselte Anfrage, geschrieben in das Merkmal des Seekers.

Oktett Datentyp Beschreibung Wert Obligatorisch?
0 uint8 Nachrichtentyp 0x00 = schlüsselbasierte Kopplungsanfrage Obligatorisch
1 uint8 Markierungen
  • Bit 0 (MSB): Von Seeker verworfen und ignoriert.
  • Bit 1: 1, wenn der Suchende anfordert, dass der Dienstleister die Bindung initiieren soll, und diese Anfrage die BR/EDR-Adresse des Suchenden enthält. Andernfalls 0.
  • Bit 2: 1, wenn der Suchende verlangt, dass der Dienstleister den bestehenden Namen in Kenntnis setzt. Andernfalls 0.
  • Bit 3: 1, wenn dies für das rückwirkende Schreiben des Kontoschlüssels vorgesehen ist. 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 Sie haben folgende Möglichkeiten:
  • Aktuelle BLE-Adresse des Anbieters
  • Öffentliche Adresse des Dienstleisters
 variiert Obligatorisch
8–13 uint48 BR/EDR-Adresse des Suchenden variiert Nur vorhanden, wenn Flags Bit 1 oder 3 festgelegt sind
n – 15 Zufallswert (Salt) variiert Obligatorisch

Tabelle 1.2.1:Raw-Anfrage (Typ 0x00). die aus der verschlüsselten Anfrage in Tabelle 1.1 entschlüsselt wurden.

Oktett Datentyp Beschreibung Wert Obligatorisch?
0 uint8 Nachrichtentyp 0x10 = Aktionsanfrage Obligatorisch
1 uint8 Markierungen
  • Bit 0 (MSB): 1, wenn es sich um eine Geräteaktion handelt, andernfalls 0.
  • Bit 1: 1, wenn Merkmal für zusätzliche Daten folgt, sonst 0.
  • Bit 2 bis 7 sind für die zukünftige Verwendung reserviert und müssen ignoriert werden.
 variiert Obligatorisch
2–7 uint48 Sie haben folgende Möglichkeiten:
  • Aktuelle BLE-Adresse des Anbieters
  • Öffentliche Adresse des Dienstleisters
 variiert Obligatorisch
8 uint8 Nachrichtengruppe variiert Obligatorisch, wenn Flags Bit 0 gesetzt ist
9 uint8 Nachrichtencode variiert Obligatorisch, wenn Flags Bit 0 gesetzt ist
10 uint8 Von Flags abhängig:
  • Bit 0 ist festgelegt: Zusätzliche Datenlänge, kleiner als 6
  • Bit 1 ist festgelegt: Daten-ID
 variiert Obligatorisch, wenn Flag Bit 0 oder 1 gesetzt ist
11 – n Zusätzliche Daten variiert Optional
n – 15 Zufallswert (Salt) variiert Obligatorisch

Tabelle 1.2.2:Raw-Anfrage (Typ 0x10). die aus der verschlüsselten Anfrage in Tabelle 1.1 entschlüsselt wurden.

Oktett Datentyp Beschreibung Wert
0 uint8 Nachrichtentyp 0x01 = schlüsselbasierte Kopplungsantwort
1–6 uint48 Öffentliche Adresse des Anbieters (BR/EDR) variiert
7–15 Zufallswert (Salt) variiert

Tabelle 1.3:Rohantwort. Die Verschlüsselung erfolgt, um die verschlüsselte Antwort in Tabelle 1.4 zu erzeugen.

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 beim schlüsselbasierten Pairing-Verfahren 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 „Verfahren zur schlüsselbasierten Kopplung“.

Oktett Datentyp Beschreibung Wert
0 uint8 Nachrichtentyp Eine der folgenden Optionen:
  • 0x02 = Passkey des Suchenden
  • 0x03 = Passkey des Anbieters
1–3 unit32 6-stelliger Passkey variiert
4–15 Zufallswert (Salt) variiert

Tabelle 2.2:Roh-Passkey-Block. Entschlüsselte Version von Tabelle 2.1

Merkmal: Kontoschlüssel

Nach dem Koppeln schreibt der Suchende für schnelles Pairing einen Kontoschlüssel an den Anbieter für schnelles Pairing.

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

Beim Erhalt einer Schreibanforderung geht der Anbieter für schnelles Pairing so vor:

  1. Entschlüsseln Sie den Kontoschlüssel mit dem gemeinsamen Secret, das in Schritt 4 des Verfahrens generiert wurde.
    • Für Anbieter, die Bindung erfordern (üblich):
      • Prüfen Sie vor der Entschlüsselung, ob das gemeinsame Secret zum Entschlüsseln der Passkey-Anfrage aus Schritt 12 verwendet wurde. Wenn dieser Schritt mit diesem Secret nicht bestanden wurde, ignorieren Sie diesen Schreibvorgang und beenden Sie den Vorgang.
    • An dieser Stelle wird das gemeinsame Secret (K im Verfahren) nicht noch einmal für diese Kopplung verwendet. Alle Anfragen, die mit diesem Schlüssel verschlüsselt eingehen, ohne das Verfahren neu zu starten, sollten abgelehnt werden.
  2. Prüfen Sie, ob der entschlüsselte Wert mit 0x04 beginnt. Ist dies nicht der Fall, ignorieren Sie diesen Schreibvorgang und beenden Sie den Vorgang.
  3. Prüfen Sie, ob in der beibehaltenen Kontoschlüsselliste Platz für den neuen Wert vorhanden ist.
  4. Ist dies nicht der Fall, löschen Sie den am wenigsten verwendeten Wert aus der Liste.
  5. Fügen Sie der Liste den neuen Wert hinzu.

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

Eigenschaft: Firmware-Version

Diese Eigenschaft ermöglicht es dem Seeker, die Firmwareversion des Anbieters bei Bedarf zu lesen. Es sollten immer die folgenden Daten zurückgegeben werden:

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

Er sollte in einen einzigen utf8-String gekapselt werden, auch wenn beim Anbieter mehr als eine Firmware (z. B. drei Firmwares für den linken, rechten Kopfhörer und das Gehäuse) vorhanden ist. In Sonderfällen kann der Provider die spezifischen Strings auch zurückgeben:

  1. status-refresh: Gibt an, ob der Anbieter derzeit auf eine neue Firmware aktualisiert wird. Alternativ könnte der Anbieter die Version der bereitgestellten Firmware zurückgeben.

  2. status-abnormal: Der Anbieter hat einen ungewöhnlichen Status. Zum Beispiel funktioniert es nicht, weil das Firmware-Update fehlgeschlagen ist. Dieser Wert führt dazu, dass der Seeker eine Meldung mit dem Hinweis anzeigt, dass er jetzt aktualisiert werden muss.

Der Anbieter sollte den Zugriff auf die Eigenschaft der Firmwareversion einschränken, um das Geräte-Tracking zu verhindern. Empfohlene Einschränkungen:

  • gebundenen Geräten jederzeit Zugriff
  • Jedes Gerät sollte Zugriff haben, wenn der Anbieter sichtbar ist

Merkmal: Zusätzliche Daten

Diese Dienstleistung weist folgende Merkmale auf.

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

Bevor dieses Merkmal geschrieben oder darüber benachrichtigt wird, muss ein Handshake über die Eigenschaft FE2C1234-8366-4814-8EB0-01DE32100BEA erfolgen, um ein gemeinsames Secret zu haben. AES-CTR wird zum Verschlüsseln von Daten verwendet, die diese Eigenschaft durchlaufen, deren Algorithmus unten definiert ist. Dieser Modus ist sicherer für Daten, die über einen einzelnen 16-Byte-Block hinausgehen. HMAC-SHA256 wird verwendet, um die Datenintegrität sicherzustellen, die ebenfalls unten definiert ist.

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

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

Oktett Datentyp Beschreibung Wert
0 – var byte array Daten variiert, decodieren Sie ihn gemäß der Daten-ID aus Tabelle 1.2.2:
  • 0x01(personalisierter Name): utf8s

Tabelle 3.2:Rohdaten. Aus den verschlüsselten Daten in Tabelle 3.1 entschlüsselt.

Wenn eine Benachrichtigung angefordert wird (z.B. Anforderung eines personalisierten Namens über Bit 2 in Tabelle 1.2.1), wird der Anbieter für schnelles Pairing Folgendes tun:

  1. Generiert kryptografisch zufällige 8 Byte für 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 des Verfahrens.
    2. ClearBlock[i] ist ein 16-Byte-Block, der mit „data“[i * 16] beginnt. Der letzte Block kann kleiner als 16 Byte sein.

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

  4. HMAC-SHA256 generieren durch

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

    Bitte wo?

    1. K wird von concat(shared_secret, 48-Byte ZEROs) generiert, das gemeinsam genutzte_Secret aus Schritt 4 des Verfahrens.
    2. Opad ist ein äußeres Padding von 64 Byte, das aus wiederholten Byte mit dem Wert 0x5C besteht.
    3. ipad hat einen Innenrand von 64 Byte, der aus wiederholten Byte mit dem Wert 0x36 besteht.

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

Beim Erhalt einer Schreibanforderung geht der Anbieter für schnelles Pairing so vor:

  1. Die Integrität der Daten durch Prüfen der ersten 8 Byte von HMAC-SHA256 prüfen

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

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

    Bitte wo?

    1. encryptionBlock[i] ist ein 16-Byte-Blockstart aus verschlüsselten_data[i * 16]. Der letzte Block kann kleiner als 16 Byte sein.
    2. Der AES-Schlüssel wird durch den Handshake generiert oder identifiziert. Beispiel:
      1. in Benennung von Ablauf 1 stammt von ECDH und wird nicht noch einmal für diese Verknüpfung verwendet. Alle Anfragen, die mit diesem Schlüssel verschlüsselt werden und ohne einen Neustart der Prozedur eingehen, sollten abgelehnt werden.
      2. im Benennungsablauf 2 ist es der Kontoschlüssel.

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