تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
إجراء الإقران السريع
إجراء
وبدلاً من استدعاء أي من إجراءات ربط BR/EDR أو BLE العادية، يبدأ "الباحث" أولاً بتفعيل الإشعارات بشأن خاصية الإقران المستنِد إلى المفتاح، ثم يكتب البيانات في الجدول 1.1 إليها.
عند التعامل مع طلب كتابة من باحث عن ميزة "الإقران السريع"، على موفّر خدمة "الإقران السريع" تنفيذ ما يلي:
إذا كان حقل المفتاح العام الاختياري موجودًا:
إذا لم يكن الجهاز في وضع الإقران، تجاهل الكتابة والخروج
وفي حال عدم حدوث ذلك:
استخدِم المفتاح العام الذي تم استلامه (نقطة 64 بايت على منحنى secp256r1 البيضاوي) والمفتاح الخاص لمكافحة الانتحال المثبَّت مسبقًا - أيضًا secp256r1 وخوارزمية Elliptic-Curve Diffie- Hellman لإنشاء مفتاح AES بحجم 256 بت.
استخدِم خوارزمية SHA-256 لتجزئة مفتاح AES بـ 256 بت.
خذ أول 128 بت من النتيجة. إنّه مفتاح Anti-Spoofing AES
الذي يتم استخدامه في الخطوة التالية.
جرِّب استخدام AES-128 لفك تشفير القيمة. وبما أن القيمة هي كتلة AES واحدة من 16 بايت، لا يلزم وضع وضع IV أو التشفير المتعدد الكتل.
المفتاح الذي تريد استخدامه:
إذا تم إنشاء مفتاح AES لمكافحة الانتحال في الخطوة 1، استخدِم هذا المفتاح.
ويمكنك بدلاً من ذلك تجربة كل مفتاح في قائمة مفاتيح الحساب الدائمة.
إذا نجح أحد المفاتيح في فك تشفير القيمة، يمكنك قطعه والمتابعة إلى الخطوة التالية.
يتم فك تشفير القيمة بنجاح إذا تطابُق الإخراج مع التنسيق في
الجدول 1.2.1 أو الجدول 1.2.2 - (أي إذا كان
يحتوي على عنوان BLE الحالي لموفّر ميزة "الإقران السريع" أو العنوان العلني لموفّر ميزة "الإقران السريع").
ملاحظة: يحتوي نهاية الحزمة على محتوى ملح مرتبط. ويجب تتبُّع هذه القيم العشوائية متى أمكن، وإذا تلقّى مقدّم الخدمة طلبًا يحتوي على قيمة عشوائية مستخدَمة من قبل، يجب تجاهل الطلب لمنع هجمات إعادة التشغيل.
وكبديل لتتبُّع القيم العشوائية، إذا كانت الكتابة تتضمّن العنوان الخاص
لموفّر الخدمة، هناك طريقة أخرى لمنع هجمات إعادة التشغيل تتمثل في استرجاع وقت
تغيير العنوان الخاص التالي القابل للحلّ كي
يحدث التغيير قبل قبول كتابة "الإقران المستند إلى المفتاح" التالية.
إذا لم يتمكّن أي مفتاح من فك تشفير القيمة، تجاهل الكتابة والخروج.
احرص على عدّ حالات الإخفاق هذه. عندما يبلغ عدد الإخفاق 10، فشل جميع الطلبات الجديدة على الفور. يمكنك إعادة ضبط عدد الأخطاء بعد 5 دقائق
أو بعد تشغيل الجهاز أو بعد نجاحه.
بخلاف ذلك، احفظ المفتاح الناجح باسم K. ضَع علامة على K تشير إلى أنّها قابلة للاستخدام لفك تشفير مفتاح المرور وكتابة الاسم المخصّص التي يتم تلقّيها على رابط LE هذا، وليس عمليات الكتابة الأخرى أو أي رسائل على أي رابط آخر. ابدأ موقّتًا لتجاهل
K بعد 10 ثوانٍ إذا لم تبدأ عملية الإقران. تجاهل أيضًا K في حال
قطع اتصال رابط LE هذا.
أنتج استجابة نموذجية بحجم 16 بايت والموضّحة في الجدول 1.3 من خلال ربط النوع وعنوان BR/EDR لموفّر المحتوى، ثم ملء باقي الحزمة بكتلة من وحدات البايت العشوائية (أي القيمة العشوائية).
عليك تشفير الاستجابة الأولية باستخدام K لإنتاج استجابة مشفّرة بحجم 16 بايت والموضّحة في الجدول 1.4. يمكنك إرسال هذا الإشعار من خلال إشعار حول خاصية الإقران المستند إلى المفتاح.
يشير ذلك إلى أنّ مقدِّم الطلب يطلب من مقدّم الخدمة بدء الربط بعنوان BR/EDR الخاص بمقدِّم الطلب، والذي يمكن العثور عليه بالبايت
8 إلى 13.
أرسِل طلب إقران إلى عنوان BR/EDR الخاص بالمقدِّم. يجب أن يكون طلب الإقران
كما هو موضّح أدناه (خطوة "أثناء الإقران").
سبب الحاجة إلى ذلك: مساعدة مقدِّم الخدمة في بدء العمل لحل مشكلة في بعض الأجهزة.
إذا كان بايت علامات الطلب مضبوطًا على 0:
انتظِر مدة تصل إلى 10 ثوانٍ لتلقّي طلب إقران. إذا لم يتم تلقي أي
شيء، فاخرج.
يُرجى العِلم أنّ هذا الطلب قد يكون طلبًا لـ BR/EDR، ويكون من عنوان مختلف
(العنوان العام للباحث، بدلاً من عنوانه الخاص الذي يمكن حلّه).
أثناء عملية الإقران، سنتحقق مرة أخرى من أنّ الجهاز المطلوب
حوزته K.
أثناء الإقران:
عند تلقّي حزمة طلب/استجابة للإقران من Seeker:
إذا كانت إمكانات الجهاز في الطلب هي NoInput/Noالإخراج، عليك إنهاء الإقران،
لتجنّب استخدام طريقة الإقران في Just Works.
بالنسبة إلى حزمة طلب/الاستجابة التي يرسلها الموفر: اضبط حقل "إمكانات الجهاز" على Display/YesNo واضبُط متطلبات المصادقة على MITM Protected Protection (حماية MITM). يؤدي ذلك إلى تفعيل طريقة الإقران باستخدام ميزة Numeric Comparison (المعروفة أيضًا باسم تأكيد مفتاح المرور) على Android.
ونعتمد على ذلك للتأكد من أنّ الجهاز الذي يطلب نقل البيانات هو في الحقيقة أداة البحث عن ميزة
الإقران السريع، وأنّه ليس هناك وسيط. يمكنك الاطّلاع على أمثلة.
سبب الحاجة إلى ذلك: قد تكون طريقة الإقران "خارج الإطار" أكثر ملاءمةً، إلا أنّ النظام الأساسي لا يعرضها على جميع إصدارات Android المطلوبة.
عندما يجب تأكيد مفتاح المرور، انتظِر لمدة تصل إلى 10 ثوانٍ لتتم كتابة سمة مفتاح المرور.
عادةً، باستخدام طريقة الإقران هذه، يؤكد المستخدم أن
مفاتيح المرور المعروضة على شاشة كل جهاز متطابقة. بدلاً من ذلك، في عملية الإقران هذه فقط، سننقلها عبر تقنية BLE على شكل مفاتيح مشفّرة باستخدام المفتاح المشترك الموثوق به والمشترَك مسبقًا.
تجدر الإشارة إلى أنّه يجب عدم اتّباع هذا الأسلوب في الأجهزة المزوّدة بشاشة أو لوحة مفاتيح لأنّه قد يشكِّل خطرًا طفيفًا على حماية MITM.
لا تتوافق ميزة "الإقران السريع" حاليًا مع أنواع الأجهزة هذه بسبب ذلك.
إذا انتهت صلاحية موقّت مدته 10 ثوانٍ بدون كتابة مفتاح مرور،
عليك تجاهل K.
عند كتابة قيمة لسمة مفتاح المرور، تكون هذه القيمة هي
حظر مفتاح المرور المشفّر. فك تشفيره باستخدام K للحصول على كتلة مفتاح مرور أوّلية، مع عرض التنسيق في Feature: Passkey>الجدول 2.2 - (type =
Seeker's Passkey).
في حال تعذَّر فك التشفير، يمكنك تجاهل الكتابة وتجاهل K.
في الحالات الأخرى، تحتوي مجموعة مفاتيح المرور Raw على مفتاح مرور مكوّن من 6 أرقام هو PSeeker، وهو مفتاح المرور الذي يتوقعه الباحث.
قارن PSeeker بمفتاح المرور المتوقع التابع لنا،
PProvider.
إذا كانت القيمتان متساويتان، عليك الردّ بـ "نعم" على التأكيد.
وإلا، فيمكنك الرد بـ "لا" على التأكيد، مما يؤدي إلى إخفاق الإقران.
بغض النظر عمَّا إذا تعذّر الإقران، أنشئ كتلة مفتاح مرور Raw أخرى تتضمّن التنسيق المعروض في Feature: مفتاح المرور>الجدول 2.2،
الذي يحتوي على مفتاح المرور الخاص بنا المتوقَّع، وهو PProvider.
تأكد من أن المجموعة لها النوع الصحيح (مفتاح مرور الموفر، راجع الجدول).
ملاحظة: يجب عدم إعادة استخدام القيمة العشوائية المضافة إلى مجموعة مفاتيح المرور التي تلقّيتها من الباحث. إنشاء قيمة عشوائية جديدة.
تشفير مجموعة مفتاح المرور الأولية باستخدام K، وإرسال رمز مفتاح المرور المشفَّر الناتج عن ذلك من خلال إشعار خاص بسمة مفتاح المرور
إذا تلقّى المستخدم مفتاح المرور الصحيح P وفك تشفيره، يردّ
أيضًا على التأكيد بـ "نعم" وبالتالي سيتم الإقران.
إذا نجح الإقران، ضَع علامة على K تشير إلى أنّه قابل للاستخدام لفك تشفير مفتاح الحساب
الذي تتم كتابته على رابط LE هذا، وليس لأي عمليات كتابة لاحقة لمفتاح مرور أو أي عمليات كتابة على أي رابط آخر. ابدأ مؤقّتًا لتجاهل K بعد 10 ثوانٍ. وعليك أيضًا تجاهل K بعد أي محاولة لكتابة مفتاح حساب،
ووفقًا للخطوة 4، إذا انقطع اتصال الرابط LE.
إذا تعذَّر الإقران، يمكنك تجاهل K.
عليك إعادة ضبط حقل إمكانات الجهاز على إمكانات وحدات الإدخال والإخراج التلقائية
و"متطلبات المصادقة" على الوضع التلقائي حتى تتم متابعة عمليات الإقران الجديدة على النحو المتوقَّع.
تجدر الإشارة إلى أنّه بالنسبة إلى مقدّمي الخدمات الذين لا يشترطون الربط، لا يرسل الباحث
طلب الإقران إلى مقدّم الخدمة، إذ يتم تخطّي الخطوة 8 - الخطوة 17. ويتم أيضًا استخدام "K" في سمة مفتاح الحساب.
أمثلة
المثال 1: محاولة إقران ناجحة
(بدون تدخّل الوسيط).المثال 2: تعذّرت محاولة الإقران مع
الوسيط.
تاريخ التعديل الأخير: 2025-08-13 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-13 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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.*"]]