Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Schnelles Pairing
Vorgehensweise
Anstatt sofort eines der normalen BR/EDR- oder BLE-Bonding-Verfahren aufzurufen, aktiviert der Seeker zuerst Benachrichtigungen für die schlüsselbasierte Kopplungseigenschaft und schreibt dann die Daten aus Tabelle 1.1 in diese.
Wenn ein Anbieter für schnelles Pairing eine Schreibanfrage verarbeitet, führt er folgende Schritte aus:
Wenn das optionale Feld „Öffentlicher Schlüssel“ vorhanden ist:
Wenn sich das Gerät nicht im Kopplungsmodus befindet, ignorieren Sie das Schreiben und Beenden.
Andernfalls gehen Sie so vor:
Verwenden Sie den empfangenen öffentlichen Schlüssel (einen 64-Byte-Punkt auf der Elliptische-Kurven-Kurve secp256r1), den vorinstallierten Anti-Spoofing-privaten Schlüssel (auch secp256r1) und den Elliptic-Curve-Diffie-Hellman-Algorithmus, um einen 256-Bit-AES-Schlüssel zu generieren.
Verwenden Sie SHA-256, um den 256-Bit-AES-Schlüssel zu hashen.
Nehmen Sie die ersten 128 Bit des Ergebnisses. Der AES-Schlüssel „Anti-Spoofing“,
der im nächsten Schritt verwendet wird.
Versuchen Sie, den Wert mit AES-128 zu entschlüsseln. Da der Wert ein einzelner 16-Byte-AES-Block ist, ist kein IV- oder Multi-Block-Chiffremodus erforderlich.
Welchen Schlüssel Sie verwenden sollten:
Wenn in Schritt 1 ein Anti-Spoofing-AES-Schlüssel generiert wurde, verwenden Sie diesen Schlüssel.
Versuchen Sie andernfalls alle Schlüssel in der beibehaltenen Kontoschlüsselliste.
Wenn ein Schlüssel den Wert erfolgreich entschlüsselt hat, brechen Sie den Vorgang ab und fahren Sie mit dem nächsten Schritt fort.
Der Wert wird erfolgreich entschlüsselt, wenn die Ausgabe dem Format in Tabelle 1.2.1 oder Tabelle 1.2.2 entspricht, d. h. wenn sie entweder die aktuelle BLE-Adresse des Anbieters für schnelles Pairing oder die öffentliche Adresse des Anbieters für schnelles Pairing enthält.
HINWEIS: Am Ende des Pakets befindet sich ein Salt. Wenn möglich, sollten diese Salts erfasst werden. Wenn der Anbieter eine Anfrage mit einem bereits verwendeten Salt erhält, sollte die Anfrage ignoriert werden, um Replay-Angriffe zu verhindern.
Wenn der Schreibvorgang die private Adresse des Anbieters enthält, können Sie als Alternative zum Nachverfolgen von Salts auch Replay-Angriffe verhindern, indem Sie den Zeitpunkt der nächsten lösbaren privaten Adressrotation so verschieben, dass der nächste Schreibvorgang auf Basis eines schlüsselbasierten Paars akzeptiert wird.
Wenn der Wert mit keinem Schlüssel entschlüsselt werden konnte, ignoriere den Schreibvorgang und den Exit.
Erfassen Sie die Anzahl dieser Fehler. Wenn die Fehleranzahl 10 erreicht, schlagen alle neuen Anfragen sofort fehl. Setzen Sie die Fehleranzahl nach 5 Minuten, nach dem Einschalten oder nach einem Erfolg zurück.
Andernfalls speichern Sie den erfolgreichen Schlüssel als K. Markieren Sie dieses K als zum Entschlüsseln von Passkey- und personalisierten Namen nutzbaren Schreibvorgängen, die unter diesem LE-Link empfangen werden, aber nicht für andere Schreib- oder Schreibvorgänge auf anderen Links. Wenn die Kopplung noch nicht gestartet wurde, starten Sie einen Timer, um K nach 10 Sekunden zu verwerfen. Verwerfen Sie auch K, wenn diese LE-Verbindung getrennt wird.
Erstellen Sie die in Tabelle 1.3 gezeigte Rohantwort mit 16 Byte. Verketten Sie dazu den Typ und die BR/EDR-Adresse des Anbieters und füllen Sie den Rest des Pakets mit einem Block zufälliger Byte (also einem Salt) aus.
Verschlüsseln Sie die Rohantwort mit K, um die in Tabelle 1.4 gezeigte verschlüsselte 16-Byte-Antwort zu generieren. Senden Sie dies über eine Benachrichtigung zum Merkmal der schlüsselbasierten Kopplung.
Lesen Sie das Anfrage-Flag:
Wenn für das Byte für die Flags der Anfrage Bit 2 auf 1 gesetzt ist, benachrichtigen Sie das Merkmal für zusätzliche Daten mit einem personalisierten Namen.
Wenn im Byte für die Flags der Anfrage Bit 1 auf 1 gesetzt ist:
Dies weist darauf hin, dass der Suchende den Anbieter anfordert, die Verbindung zur BR/EDR-Adresse des Suchenden zu initiieren, die in Byte 8–13 vorhanden ist.
Sende eine Kopplungsanfrage an die BR/EDR-Adresse des Suchers. Die Kopplungsanfrage muss wie unten beschrieben aussehen (Schritt „Während der Kopplung“).
Grund: Wenn der Anbieter die Initiierung des Anbieters initiiert, kann ein Problem auf einigen Geräten umgangen werden.
Wenn im Byte für die Flags der Anfrage Bit 1 auf 0 gesetzt ist:
Warten Sie bis zu 10 Sekunden auf eine Kopplungsanfrage. Wird keiner empfangen, wird beendet.
Beachten Sie, dass dies eine BR/EDR-Anfrage von einer anderen Adresse sein kann (die öffentliche Adresse des Suchenden anstelle seiner auflösbaren privaten Adresse).
Während der Kopplung wird noch einmal überprüft, ob sich das anfordernde Gerät im Besitz von K befindet.
Während der Kopplung:
Wenn der Sucher ein Kopplungsanfrage/Antwort-Paket erhält, gilt Folgendes: Wenn die Gerätefunktionen in der Anfrage "NoInput/NoOutput" lauten, beenden Sie die Kopplung. So vermeiden Sie die Verwendung der Just Works-Kopplungsmethode.
Für das vom Anbieter gesendete Anfrage-/Antwortpaket für die Kopplung: Setze das Feld „Gerätefunktionen“ auf Display/YesNo und setze „Authentifizierungsanforderungen“ auf MITM Protection required. Dadurch wird die Kopplungsmethode des numerischen Vergleichs ausgelöst (unter Android auch als Passkey-Bestätigung bezeichnet).
Wir verlassen uns auf diese Information, um zu bestätigen, dass es sich bei dem anfordernden Gerät tatsächlich um das schnelle Pairing handelt und es keinen Man-in-the-Middle gibt. Beispiele
Grund: Die Out-of-Band-Kopplungsmethode wäre besser geeignet, wird aber von der Plattform nicht für alle gewünschten Android-Versionen angezeigt.
Wenn der Passkey bestätigt werden muss, warten Sie bis zu 10 Sekunden, bis das Passkey-Merkmal geschrieben wurde.
Normalerweise bestätigt der Nutzer bei dieser Kopplungsmethode, dass die auf dem Bildschirm jedes Geräts angezeigten Passkeys identisch sind. Stattdessen übertragen wir sie nur für diese Kopplung über BLE, verschlüsselt mit dem vertrauenswürdigen vorinstallierten Schlüssel.
Dieser Ansatz sollte nicht für Geräte mit einem Bildschirm oder einer Tastatur gewählt werden, da dadurch der MITM-Schutz geringfügig beeinträchtigt wird.
Die Funktion „Schnelles Pairing“ unterstützt diese Gerätetypen daher derzeit nicht.
Wenn der 10-Sekunden-Timer abläuft, ohne dass ein Passkey geschrieben wird, verwerfen Sie K.
Wenn ein Wert in die Passkey-Eigenschaft geschrieben wird, ist dies der verschlüsselte Passkey-Block. Entschlüsseln Sie sie mit K, um einen unbearbeiteten Passkey-Block mit dem Format zu erhalten, das in Merkmal: Passkey>Tabelle 2.2 (Typ = Passkey des Suchenden) gezeigt wird.
Wenn die Entschlüsselung fehlschlägt, ignorieren Sie den Schreibvorgang und verwerfen Sie K.
Andernfalls enthält der unformatierte Passkey-Block einen sechsstelligen Passkey-PSeeker. Dies ist der Passkey, den der Seeker erwartet.
Vergleichen Sie PSeeker mit unserem eigenen erwarteten Passkey PProvider.
Wenn die Werte gleich sind, antworten Sie auf die Bestätigung mit „Ja“.
Andernfalls antworten Sie mit „Nein“ auf die Bestätigung und führen zu einem Fehler beim Koppeln.
Unabhängig davon, ob die Kopplung fehlgeschlagen ist, erstellen Sie einen weiteren Roh-Passkey-Block mit dem Format, das in Merkmal: Passkey>Tabelle 2.2 gezeigt wird und unseren eigenen erwarteten Passkey PProvider enthält.
Achten Sie darauf, dass der Block den richtigen Typ hat (Passkey des Anbieters; siehe Tabelle).
HINWEIS: Verwende nicht den Salt aus dem Passkey-Block, den du vom Sucher erhalten hast. Erzeugen Sie einen neuen Zufallswert.
Verschlüsseln Sie den unbearbeiteten Passkey-Block mit K und senden Sie den resultierenden verschlüsselten Passkey-Block über eine Benachrichtigung für die Passkey-Eigenschaft.
Wenn der Suchende den richtigen Passkey P empfängt und entschlüsselt, antwortet er ebenfalls mit „Ja“ auf die Bestätigung und die Kopplung ist erfolgreich.
Wenn die Kopplung erfolgreich ist, markieren Sie K als verwendbar zum Entschlüsseln von Kontoschlüsselschreibvorgängen in diesem LE-Link, aber nicht für nachfolgende Passkey-Schreibvorgänge oder Schreibvorgänge auf anderen Links. Starten Sie einen Timer, um K nach 10 Sekunden zu verwerfen. Verwerfen Sie außerdem K nach jedem Versuch, einen Kontoschlüssel zu schreiben, und wie in Schritt 4 beschrieben, wenn die LE-Verbindung getrennt wird.
Wenn die Kopplung fehlschlägt, verwerfen Sie K.
Setzen Sie das Feld für Gerätefunktionen auf die Standardeinstellungen für E/A-Funktionen und Authentifizierungsanforderungen zurück, damit neue Kopplungen wie erwartet fortgesetzt werden.
Beachten Sie, dass bei Anbietern, die kein Binden benötigen, der Suchende keine Kopplungsanfrage an den Anbieter sendet, d. h. Schritt 8 – Schritt 17 wird übersprungen. Außerdem wird für das Kontoschlüsselmerkmal "K" verwendet.
Beispiele
Beispiel 1: Erfolgreicher Kopplungsversuch (kein Man-in-the-Middle).Beispiel 2: Fehlgeschlagener Kopplungsversuch mit Man-in-the-Middle.
[null,null,["Zuletzt aktualisiert: 2025-08-13 (UTC)."],[[["\u003cp\u003eFast Pair utilizes BLE for initial key exchange and then triggers BR/EDR pairing for secure connection.\u003c/p\u003e\n"],["\u003cp\u003eThe Provider verifies the Seeker's authenticity using encryption, a shared secret, and a numeric comparison pairing method.\u003c/p\u003e\n"],["\u003cp\u003eAccount Keys are exchanged securely after successful pairing to enable seamless future connections.\u003c/p\u003e\n"],["\u003cp\u003eThe process includes anti-spoofing measures like public key cryptography and salt tracking to enhance security.\u003c/p\u003e\n"],["\u003cp\u003eThe Provider initiates the BR/EDR pairing to address compatibility issues with certain devices.\u003c/p\u003e\n"]]],[],null,["Fast Pair Procedure\n-------------------\n\n### Procedure\n\n| **Note:** Google recommends implementing the [Cryptographic Test Cases](/nearby/fast-pair/specifications/appendix/cryptotestcases \"Link to the Cryptographic Test Cases.\") to ease verification of these requirements.\n\nInstead of immediately invoking any of the normal BR/EDR or BLE bonding\nprocedures, the Seeker first enables Notifications on the Key-based Pairing\ncharacteristic, and then writes the data in [Table 1.1](/nearby/fast-pair/specifications/characteristics#table1.1 \"table 1.1\") to it.\n\nWhen handling a write request from a Fast Pair Seeker, the Fast Pair Provider\nshall do the following:\n\n1. If the optional Public Key field **is present** :\n 1. If the device is not in pairing mode, ignore the write and exit.\n 2. Otherwise:\n 1. Use the received Public Key (a 64-byte point on the secp256r1 elliptic curve), the pre-installed [Anti-Spoofing Private Key](/nearby/fast-pair/specifications/configuration#antispoofing \"Anti-Spoofing\") - also secp256r1, and the Elliptic-Curve Diffie-Hellman algorithm to generate a 256-bit AES key.\n 2. Use SHA-256 to hash the 256-bit AES key.\n 3. Take the first 128 bits of the result. This is the Anti-Spoofing AES Key, used in the next step.\n2. Using AES-128, attempt to decrypt the value. Since the value is a single\n 16-byte AES block, no IV or multi-block cipher mode is necessary.\n\n 1. Which key to use:\n 1. If an Anti-Spoofing AES Key was generated in step 1, use that key.\n 2. Otherwise, try each key in the persisted Account Key List.\n 2. If a key successfully decrypts the value, break, and continue to the next step.\n 3. The value is decrypted successfully if the output matches the format in\n [Table 1.2.1](/nearby/fast-pair/specifications/characteristics#table1.2.1 \"table 1.2.1\") or [Table 1.2.2](/nearby/fast-pair/specifications/characteristics#table1.2.2 \"table 1.2.2\") - (that is, if it\n contains either the Fast Pair Provider's current BLE address, or the Fast\n Pair Provider's public address).\n\n NOTE: At the end of the packet there is a salt attached. When\n possible, these salts should be tracked, and if the Provider receives a\n request containing an already used salt, the request should be ignored to\n prevent replay attacks.\n 4. As an alternative to tracking salts, if the write includes the Provider's\n private address, another way to prevent replay attacks is to bring\n forward the time of the next resolvable private address rotation so that\n the rotation occurs before the next Key-based Pairing write will be\n accepted.\n\n3. If no key could successfully decrypt the value, ignore the write and exit.\n\n 1. Keep a count of these failures. **When the failure count hits 10, fail\n all new requests immediately. Reset the failure count after 5 minutes,\n after power on, or after a success.**\n4. Otherwise, save the successful key as *K* . Mark this *K* as usable for\n decrypting Passkey and Personalized name writes received on this LE link, but\n not other writes nor any writes on any other link. Start a timer to discard\n *K* after 10 seconds if pairing has not been started. Also discard *K* if\n this LE link disconnects.\n\n5. Produce the 16-byte Raw Response shown in [Table 1.3](/nearby/fast-pair/specifications/characteristics#table1.3 \"table 1.3\"), by\n concatenating the type and the Provider's BR/EDR address, and then filling\n the remainder of the packet with a block of random bytes (that is, a salt).\n\n6. Encrypt the Raw Response with K to produce the 16-byte Encrypted Response\n shown in [Table 1.4](/nearby/fast-pair/specifications/characteristics#table1.4 \"table 1.4\"). Send this via a notify on the Key-based Pairing\n characteristic.\n\n7. Read the request flag:\n\n 1. **If the Request's Flags byte has bit 2 set to 1** , notify [Additional Data characteristic](/nearby/fast-pair/specifications/characteristics#AdditionalData \"Characteristic - Additional Data\") with personalized name.\n 2. **If the Request's Flags byte has bit 1 set to 1:**\n 1. This indicates that the Seeker is requesting the Provider to initiate bonding to the Seeker's BR/EDR address, which is present in bytes 8-13.\n 2. Send a pairing request to the Seeker's BR/EDR address. The pairing request must be as described below (\"During pairing\" step).\n 3. Reason this is needed: Having the Provider initiate works around an issue on some devices.\n 3. **If the Request's Flags byte has bit 1 set to 0:**\n 1. Wait up to 10 seconds for a pairing request. If none is received, exit.\n 2. Note that this might be a BR/EDR request, from a different address (the Seeker's public address, instead of its resolvable private address). We will re-verify during pairing that the requesting device is in possession of *K*.\n8. During pairing:\n\n 1. When a **pairing request/response packet** is received from the Seeker: If the Device Capabilities in the request are NoInput/NoOutput, end pairing, to avoid using the Just Works pairing method.\n 2. For the pairing request/response packet sent by the Provider: Set the Device Capabilities field to **Display/YesNo** and set Authentication Requirements to **MITM Protection Required** . This triggers the Numeric Comparison pairing method (also known as [Passkey Confirmation](https://developer.android.com/reference/android/bluetooth/BluetoothDevice.html#PAIRING_VARIANT_PASSKEY_CONFIRMATION) on Android). We rely on this to confirm that the requesting device is in fact the Fast Pair Seeker, and that there is no man-in-the-middle. See [examples](#ProcedureExamples).\n 3. Reason this is needed: The Out-of-Band pairing method would be a better fit, but the platform does not expose it on all desired versions of Android.\n9. When **confirmation of the passkey is needed** , wait up to 10 seconds for a\n write to the [Passkey characteristic](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\").\n\n 1. Normally, with this pairing method, the user would confirm that the passkeys displayed on each device's screen are identical. Instead, only for this pairing, we transfer them over BLE, encrypted with the trusted pre-shared key.\n 2. Note that this approach should not be taken for devices that have a screen or a keyboard as it makes a slight compromise on MITM protection. Fast Pair currently does not support those device types yet because of this.\n 3. If the 10 second timer expires without a passkey being written, then discard *K*.\n10. When a **value is written to the Passkey characteristic** , this is the\n Encrypted Passkey Block. Decrypt it with K to yield a Raw Passkey Block, with\n format shown in [Characteristic: Passkey](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\") *\\\u003e* [Table 2.2](/nearby/fast-pair/specifications/characteristics#table2.2 \"table 2.2\") - (type =\n Seeker's Passkey).\n\n11. If decryption fails, ignore the write and discard *K*.\n\n12. Otherwise, the Raw Passkey Block contains a 6-digit passkey\n *P~Seeker~*, which is the passkey that the Seeker expects.\n\n13. Compare *P~Seeker~* with our own expected passkey,\n *P~Provider~*.\n\n 1. If the values are equal, reply \"yes\" to the confirmation.\n 2. Otherwise, reply \"no\" to the confirmation, causing pairing to fail.\n14. Regardless of whether pairing failed, produce another Raw Passkey Block, with\n format shown in [Characteristic: Passkey](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\") *\\\u003e* [Table 2.2](/nearby/fast-pair/specifications/characteristics#table2.2 \"table 2.2\"),\n containing our own expected passkey, *P~Provider~*.\n\n 1. Ensure the block has the correct type (Provider's Passkey; see table). NOTE: Do not reuse the salt from the Passkey Block received from the Seeker. Generate a new random value.\n15. Encrypt the Raw Passkey Block with *K*, and send the resulting Encrypted\n Passkey Block via a notify on the Passkey characteristic.\n\n16. If the Seeker receives and decrypts the correct passkey *P*, the Seeker will\n also reply \"yes\" to the confirmation, and pairing will succeed.\n\n 1. If the pairing succeeds, then mark *K* as usable for decrypting Account Key writes on this LE link, but not for any subsequent Passkey writes nor any writes on any other link. Start a timer to discard *K* after 10 seconds. Also discard *K* following any attempt to write an Account Key and, as per step 4, if the LE link disconnects.\n 2. If the pairing fails, discard *K*.\n17. Switch the device capabilities field back to default I/O capabilities and\n Authentication Requirements to default so that new\n pairings continue as expected.\n\nNote that for Providers that don't require bonding, the Seeker does not send a\npairing request to the Provider, that is step 8 - step 17 are skipped. Also,\n\"K\" is used in [Account Key characteristic](/nearby/fast-pair/specifications/characteristics#AccountKey \"Account Key\").\n\n##### Examples\n\n***Example 1:** Successful pairing attempt\n(no man-in-the-middle).* ***Example 2:** Failed pairing attempt, with a\nman-in-the-middle.*"]]
