Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Hızlı Eşleme Prosedürü
Prosedür
Arayan, normal BR/EDR veya BLE bağlama prosedürlerinden herhangi birini hemen çağırmak yerine, önce Anahtar Tabanlı Eşleme özelliğinde Bildirimleri etkinleştirir ve daha sonra, Tablo 1.1'deki verileri buna yazar.
Hızlı Eşleme Sağlayıcısı, Hızlı Eşleme Sağlayıcıdan gelen yazma isteğini işlerken aşağıdakileri yapar:
İsteğe bağlı Ortak Anahtar alanı varsa:
Cihaz eşleme modunda değilse yazma ve çıkış işlemlerini yoksayın.
Aksi halde:
256 bit AES anahtarı oluşturmak için alınan Ortak Anahtarı (secp256r1 elips biçimli eğri üzerinde 64 baytlık bir nokta), önceden yüklenmiş Anti-Adres Sahteciliği Özel Anahtarı'nı (ayrıca secp256r1) ve Eliptik Eğri Diffie-Hellman algoritmasını kullanın.
256 bit AES anahtarına karma oluşturma işlemi uygulamak için SHA-256 kullanın.
Sonucun ilk 128 bitini alın. Bu, bir sonraki adımda kullanılacak olan Adres Sahteciliği Önleme AES Anahtarı'dır.
AES-128 kullanarak değerin şifresini çözmeyi deneyin. Değer, tek bir 16 baytlık AES bloğu olduğundan IV veya çok bloklu şifre moduna gerek yoktur.
Hangi anahtar kullanılmalıdır?
1. adımda bir Adres Sahteciliği Önleme AES Anahtarı oluşturulduysa bu anahtarı kullanın.
Aksi takdirde, kalıcı Hesap Anahtarı Listesindeki her anahtarı deneyin.
Bir anahtar değerin şifresini başarıyla çözerse ara verip bir sonraki adıma geçin.
Çıkış, Tablo 1.2.1 veya Tablo 1.2.2'deki biçimle eşleşirse (yani Hızlı Eşleme Sağlayıcısı'nın geçerli BLE adresini veya Hızlı Eşleme Sağlayıcısı'nın genel adresini içeriyorsa) değerin şifresi başarıyla çözülür.
NOT: Paketin sonunda bir takviye işareti vardır. Mümkün olduğunda bu takviye değerler izlenmelidir. Ayrıca Sağlayıcı, halihazırda kullanılmış bir takviye değeri içeren bir istek alırsa tekrar oynatma saldırılarını önlemek için istek yok sayılmalıdır.
Takviye değer hesaplamalarına alternatif olarak, yazma işlemi Sağlayıcı'nın özel adresini içeriyorsa tekrar oynatma saldırılarını önlemenin bir başka yolu da, bir sonraki Anahtar Tabanlı Eşleme yazma işlemi kabul edilmeden önce rotasyonun gerçekleşmesi için bir sonraki çözümlenebilir özel adres rotasyonunun zamanını belirlemektir.
Hiçbir anahtar değerin şifresini başarıyla çözemezse yazma ve çıkış işlemlerini yoksayın.
Bu hataların sayısını tutun. Başarısızlık sayısı 10'a ulaştığında tüm yeni istekler hemen başarısız olur. 5 dakika, cihaz açıldıktan veya başarılı olduktan sonra hata sayısını sıfırlayın.
Aksi takdirde, başarılı anahtarı K olarak kaydedin. Bu K'yi, bu LE bağlantısında alınan geçiş anahtarı ve kişiselleştirilmiş ad yazmalarının şifresini çözmek için kullanılabilir olarak işaretleyin ancak başka bir bağlantıda yazma veya yazma işlemi için kullanmayın. Eşleme başlatılmadıysa 10 saniye sonra K'yi silmek için bir zamanlayıcı başlatın. Bu LE bağlantısının bağlantısı kesilirse K değerini de silin.
Türü ve Sağlayıcının BR/EDR adresini birleştirip paketin geri kalanını rastgele bayt bloku (yani bir takviye) ile doldurarak Tablo 1.3'te gösterilen 16 baytlık Ham Yanıtı oluşturun.
Tablo 1.4'te gösterilen 16 baytlık Şifrelenmiş Yanıtı oluşturmak için Ham Yanıtı K ile şifreleyin. Bunu, Anahtar Tabanlı Eşleme özelliğiyle ilgili bir bildirim aracılığıyla gönderin.
İstek işaretini okuyun:
İsteğin Flags baytının bit 2 değeri 1 olarak ayarlanmışsa kişiselleştirilmiş adla Ek Veri özelliğini bilgilendirin.
İsteğin Flags baytı bit 1, 1 olarak ayarlandıysa:
Bu, Arayan'ın, Sağlayıcı'dan, Arayan'ın, 8-13 arasındaki baytlar cinsinden mevcut BR/EDR adresine bağlanmayı başlatmasını istediğini gösterir.
Arayanın BR/EDR adresine bir eşleme isteği gönderin. Eşleme isteği aşağıda açıklandığı gibi olmalıdır ("Eşleme sırasında" adımı).
Gerekli neden: Sağlayıcının başlatması, bazı cihazlarda geçici olarak çözülebilir.
İsteğin Flags baytı bit 1 değeri 0 olarak ayarlandıysa:
Eşleme isteği için 10 saniyeye kadar bekleyin. Herhangi bir ileti gelmezse çıkış yapın.
Bunun farklı bir adresten (arayanın çözümlenebilir özel adresi yerine genel adresi) gelen bir BR/EDR isteği olabileceğini unutmayın.
Eşleme sırasında, istekte bulunan cihazda K olduğunu yeniden doğrulayacağız.
Eşleme sırasında:
Arayandan bir eşleme isteği/yanıt paketi alındığında:
İstekteki Cihaz Özellikleri NoInput/NoExit ise Just Works eşleme yöntemini kullanmaktan kaçınmak için eşlemeyi sonlandırın.
Sağlayıcı tarafından gönderilen eşleme isteği/yanıt paketi için: Device Capabilities alanını Display/YesNo olarak ayarlayın ve Kimlik Doğrulama Gereksinimleri'ni MITM Koruması Gerekli olarak ayarlayın. Bu, Sayısal Karşılaştırma eşleme yöntemini (Android'de Geçiş Anahtarı Onayı olarak da bilinir) tetikler.
İstekte bulunan cihazın aslında Hızlı Eşleme Arayan olduğunu ve ortadaki adam bulunmadığını onaylamak için buna güveniriz. Örneklere bakın.
Gerekli neden: Bant dışı eşleme yöntemi daha uygun olabilir ancak platform, Android'in istenen tüm sürümlerinde bu yöntemi göstermemektedir.
Geçiş anahtarının onaylanması gerektiğindegeçiş anahtarı özelliğine yazılması için 10 saniye kadar bekleyin.
Normalde bu eşleme yöntemiyle kullanıcı, her cihazın ekranında görüntülenen geçiş anahtarlarının aynı olduğunu onaylar. Bunun yerine, sadece bu eşleme için bunları önceden paylaşılan güvenilir anahtarla şifrelenmiş BDE üzerinden aktarırız.
Bu yaklaşım, MITM korumasından biraz ödün vereceğinden ekran veya klavye bulunan cihazlarda kullanılmamalıdır.
Hızlı Eşleme bu nedenle şu anda bu cihaz türlerini desteklememektedir.
10 saniyelik zamanlayıcının süresi geçiş anahtarı yazılmadan dolarsa K değerini silin.
Geçiş anahtarı özelliğine bir değer yazıldığında bu, Şifrelenmiş Geçiş Anahtarı Bloğu'dur. Ham Geçiş Anahtarı Bloğu oluşturmak için şifrenin şifresini çözün. Ham Geçiş Anahtarı Bloğu elde edilir. Biçim, Karakter: Geçiş Anahtarı>Tablo 2.2 (tür: = Arayanın Geçiş Anahtarı) bölümünde gösterilir.
Şifre çözme başarısız olursa yazma işlemini yoksayın ve K değerini silin.
Aksi takdirde, Ham Geçiş Anahtarı Bloğu, Arayan'ın beklediği geçiş anahtarı olan 6 haneli bir geçiş anahtarı PSeeker içerir.
PSeeker'i kendi beklenen geçiş anahtarımız olan PProvider ile karşılaştırın.
Değerler aynıysa onaya "evet" yanıtını verin.
Aksi takdirde, onaya "hayır" yanıtını verdiğinizde eşleme başarısız olur.
Eşlemenin başarısız olup olmamasından bağımsız olarak, beklenen geçiş anahtarımız olan >'yı içeren başka bir Ham Geçiş Anahtarı Bloğu oluşturun. Bu blok, Özellik: Geçiş Anahtarı>Tablo 2.2'de gösterilen biçimdedir.
Bloğun doğru türde olduğundan emin olun (Sağlayıcı geçiş anahtarı; tabloya bakın).
NOT: Arayandan alınan geçiş anahtarı blokunda bulunan takviyeyi yeniden kullanmayın. Yeni bir rastgele değer oluştur.
Ham Geçiş Anahtarı Bloğu'nu K ile şifreleyin ve sonuç olarak elde edilen Şifreli Geçiş Anahtarı Bloğu'nu geçiş anahtarı özelliğiyle ilgili bir bildirimle gönderin.
Arayan kişi doğru geçiş anahtarı P'yi alır ve bu geçiş anahtarının şifresini çözerse, Arayan kişi de onaya "evet" yanıtını verir ve eşleme başarılı olur.
Eşleme başarılı olursa K'yi bu LE bağlantısındaki Hesap Anahtarı yazmalarının şifresini çözmek için kullanılabilir olarak işaretleyin ancak sonraki geçiş anahtarı yazma işlemleri veya başka bir bağlantıdaki yazma işlemleri için kullanmayın. K'yi 10 saniye sonra silmek için bir zamanlayıcı başlatın. Ayrıca, herhangi bir Hesap Anahtarı yazma girişiminde bulunduktan sonra ve 4. adımda olduğu gibi, LE bağlantısının bağlantısı kesilirse K'yi silin.
Eşleme başarısız olursa K değerini silin.
Yeni eşlemelerin beklendiği gibi devam etmesi için cihaz özellikleri alanını tekrar varsayılan G/Ç özelliklerine ve Kimlik Doğrulama Gereksinimleri'ni varsayılan değerine getirin.
Bağ kurma gerektirmeyen Sağlayıcılar için Arayan'ın, Sağlayıcı'ya eşleme isteği göndermediğini unutmayın. Bu durumda, 8. adım atlanır. Ayrıca "K", Hesap Anahtarı özelliği'nde de kullanılır.
Örnekler
1. Örnek: Başarılı eşleme denemesi (ortadaki adam yok).2. Örnek: Ortadaki adam ile eşleme denemesi başarısız oldu.
[null,null,["Son güncelleme tarihi: 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.*"]]
