Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.
Prosedur Sambungan Cepat
Prosedur
Daripada segera memanggil salah satu prosedur ikatan BR/EDR atau BLE normal, Pencari Kerja akan mengaktifkan Notifikasi pada karakteristik Pasangan Berbasis Kunci, lalu menulis data ke dalamnya dalam Tabel 1.1.
Saat menangani permintaan tulis dari Pencari Sambungan Cepat, Penyedia Sambungan Cepat harus melakukan hal berikut:
Jika kolom Kunci Publik opsional ada:
Jika perangkat tidak dalam mode penyambungan, abaikan tombol tulis dan keluar.
Jika tidak:
Gunakan Kunci Publik yang diterima (titik 64 byte pada kurva eliptis secp256r1), Kunci Pribadi Anti-Spoofing yang telah diinstal sebelumnya - juga secp256r1, dan algoritma Elliptic-Curve Diffie-Hellman untuk menghasilkan kunci AES 256-bit.
Gunakan SHA-256 untuk melakukan hashing pada kunci AES 256-bit.
Ambil 128 bit pertama dari hasilnya. Ini adalah Kunci AES Anti-Spoofing, yang digunakan pada langkah berikutnya.
Coba dekripsi nilai dengan menggunakan AES-128. Karena nilainya adalah blok AES 16 byte tunggal, maka mode cipher IV atau multi-blok tidak diperlukan.
Tombol yang akan digunakan:
Jika Kunci AES Anti-Spoofing dibuat di langkah 1, gunakan kunci tersebut.
Atau, coba setiap kunci di Daftar Kunci Akun yang dipertahankan.
Jika kunci berhasil mendekripsi nilai, memecah, dan melanjutkan ke langkah berikutnya.
Nilai berhasil didekripsi jika output cocok dengan format dalam Tabel 1.2.1 atau Tabel 1.2.2 - (yaitu, jika berisi alamat BLE saat ini dari Penyedia Sambungan Cepat, atau alamat publik Penyedia Sambungan Cepat).
CATATAN: Di akhir paket ada salt yang terpasang. Jika memungkinkan, salt ini harus dilacak, dan jika Penyedia menerima permintaan yang berisi salt yang telah digunakan, permintaan tersebut harus diabaikan untuk mencegah serangan replay.
Sebagai alternatif pelacakan salt, jika operasi tulis menyertakan alamat pribadi Penyedia, cara lain untuk mencegah serangan replay adalah dengan meneruskan waktu rotasi alamat pribadi yang dapat diselesaikan berikutnya, sehingga rotasi terjadi sebelum penulisan Penyambungan berbasis Kunci berikutnya akan diterima.
Jika tidak ada kunci yang berhasil mendekripsi nilai, abaikan penulisan dan keluar.
Catat jumlah kegagalan ini. Saat jumlah kegagalan mencapai 10, gagalkan semua permintaan baru dengan segera. Reset jumlah kegagalan setelah 5 menit, setelah dinyalakan, atau setelah berhasil.
Jika tidak, simpan kunci yang berhasil sebagai K. Tandai K ini sebagai dapat digunakan untuk mendekripsi Kunci Sandi dan penulisan Nama yang dipersonalisasi yang diterima di link LE ini, tetapi bukan penulisan lain atau penulisan apa pun di link lainnya. Mulai timer untuk menghapus K setelah 10 detik jika penyambungan belum dimulai. Hapus juga K jika link LE ini terputus.
Hasilkan Respons Mentah 16 byte yang ditunjukkan pada Tabel 1.3, dengan menggabungkan jenis dan alamat BR/EDR Penyedia, lalu mengisi sisa paket dengan blok byte acak (yaitu, salt).
Enkripsi Respons Mentah dengan K untuk menghasilkan Respons Terenkripsi 16 byte yang ditampilkan dalam Tabel 1.4. Kirimkan hal ini melalui notifikasi tentang karakteristik Penyambungan Berbasis Kunci.
Baca tanda permintaan:
Jika byte Tanda Permintaan memiliki bit 2 yang ditetapkan ke 1, beri tahu Karakteristik Data Tambahan dengan nama yang dipersonalisasi.
Jika byte Tanda Permintaan memiliki bit 1 yang ditetapkan ke 1:
Hal ini menunjukkan bahwa Pencari Kerja meminta Penyedia untuk memulai ikatan ke alamat BR/EDR Pencari, yang terdapat dalam byte 8-13.
Kirim permintaan penyambungan ke alamat BR/EDR Pencari Kerja. Permintaan penyambungan harus seperti yang dijelaskan di bawah (langkah "Selama penyambungan").
Alasan diperlukan: Meminta Penyedia memulai mengatasi masalah di beberapa perangkat.
Jika byte Tanda Permintaan memiliki bit 1 yang ditetapkan ke 0:
Tunggu hingga 10 detik untuk permintaan penyambungan. Jika tidak ada yang diterima, keluar.
Perhatikan bahwa ini mungkin merupakan permintaan BR/EDR, dari alamat yang berbeda (alamat publik Pencari Kerja, bukan alamat pribadi yang dapat diselesaikan). Selama penyambungan, kami akan memverifikasi ulang bahwa perangkat yang meminta ada K.
Selama penyambungan:
Saat paket permintaan/respons penyambungan diterima dari Pencari Kerja: Jika Kemampuan Perangkat dalam permintaan adalah NoInput/NoOutput, lakukan penyambungan akhir untuk menghindari penggunaan metode penyambungan Just Works.
Untuk paket permintaan/respons penyambungan yang dikirim oleh Penyedia: Tetapkan kolom Device Capabilities ke Display/YesNo dan tetapkan Persyaratan Authentication ke MITM Protection required. Tindakan ini akan memicu metode penyambungan Perbandingan Numerik (juga dikenal sebagai Konfirmasi Kunci Sandi di Android). Kami mengandalkan hal ini untuk mengonfirmasi bahwa perangkat yang meminta sebenarnya adalah Pencari Sambungan Cepat, dan bahwa tidak ada man-in-the-middle. Lihat contoh.
Alasan diperlukan: Metode penyambungan Out-of-Band akan lebih cocok, tetapi platform tidak menampilkannya di semua versi Android yang diinginkan.
Jika konfirmasi kunci sandi diperlukan, tunggu hingga 10 detik untuk penulisan ke karakteristik Kunci sandi.
Biasanya, dengan metode penyambungan ini, pengguna akan mengonfirmasi bahwa kunci sandi yang ditampilkan di setiap layar perangkat sama. Sebagai gantinya, hanya untuk penyambungan ini, kami mentransfernya melalui BLE, yang dienkripsi dengan pre-shared key tepercaya.
Perhatikan bahwa pendekatan ini tidak boleh dilakukan untuk perangkat yang memiliki layar atau keyboard karena cara ini membuat sedikit kompromi pada perlindungan MITM. Sambungan Cepat saat ini belum mendukung jenis perangkat tersebut karena hal ini.
Jika timer 10 detik berakhir tanpa menulis kunci sandi, hapus K.
Jika nilai ditulis ke karakteristik Kunci Sandi, ini adalah Blok Kunci Sandi Terenkripsi. Dekripsi dengan K untuk menghasilkan Blok Kunci Sandi Mentah, dengan format yang ditampilkan dalam Karakteristik: Kunci Sandi>Tabel 2.2 - (jenis = Kunci Sandi Pencari).
Jika dekripsi gagal, abaikan penulisan dan hapus K.
Jika tidak, Blok Kunci Sandi Mentah akan berisi kunci sandi 6 digit PSeeker, yang merupakan kunci sandi yang diharapkan oleh Pencari Kerja.
Bandingkan PSeeker dengan kunci sandi yang diharapkan, PProvider.
Jika nilainya sama, balas "ya" untuk konfirmasi.
Jika tidak, balas "tidak" pada konfirmasi, yang menyebabkan kegagalan penyambungan.
Terlepas dari apakah penyambungan gagal, buat Blok Kunci Sandi Mentah lainnya, dengan format yang ditunjukkan dalam Karakteristik: Kunci Sandi>Tabel 2.2, yang berisi kunci sandi yang diharapkan, PProvider.
Pastikan blok memiliki jenis yang benar (Kunci Sandi Penyedia; lihat tabel). CATATAN: Jangan gunakan ulang salt dari Blok Kunci Sandi yang diterima dari Pencari Kerja. Buat nilai acak baru.
Enkripsi Blok Kunci Sandi Mentah dengan K, dan kirim Blok Kunci Sandi terenkripsi yang dihasilkan melalui pemberitahuan tentang karakteristik Kunci Sandi.
Jika Pencari menerima dan mendekripsi kunci sandi yang benar P, Pencari Kerja juga akan membalas "ya" pada konfirmasi, dan penyambungan akan berhasil.
Jika penyambungan berhasil, tandai K sebagai dapat digunakan untuk mendekripsi Kunci Akun yang ditulis di link LE ini, tetapi tidak untuk penulisan Kunci Sandi berikutnya atau penulisan apa pun di link lainnya. Mulai timer untuk menghapus K setelah 10 detik. Hapus juga K setelah setiap upaya untuk menulis Kunci Akun dan, seperti pada langkah 4, jika koneksi LE terputus.
Jika penyambungan gagal, hapus K.
Alihkan kolom kemampuan perangkat kembali ke kemampuan I/O default dan Persyaratan Authentication ke default sehingga penyambungan baru dapat berlanjut seperti yang diharapkan.
Perhatikan bahwa untuk Penyedia yang tidak memerlukan ikatan, Pencari Kerja tidak mengirimkan permintaan penyambungan ke Penyedia. Langkah 8 - langkah 17 akan dilewati. Selain itu, "K" digunakan dalam karakteristik Kunci Akun.
Contoh
Contoh 1: Upaya penyambungan yang berhasil (tidak ada man-in-the-middle).Contoh 2: Upaya penyambungan yang gagal, dengan man-in-the-middle.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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\nProcedure **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\nExamples ***Example 1:** Successful pairing attempt\n(no man-in-the-middle).* ***Example 2:** Failed pairing attempt, with a\nman-in-the-middle.*"]]
