سرویس جفت سریع گوگل - مشخصات

weixin_45840033于 2019-11-05 15:32:21 发布 1216 收藏 7

分类专栏：#Bluetooth#Google#Audio 文章标签： Google Bluetooth BLE Google Fast Pair Audio 原文链接：https://developers. google. com/nearby/fast-pair/spec 1 篇文章 0 订阅

معرفی

سرویس جفت سریع Google (GFPS) از بلوتوث کم انرژی (BLE) برای کشف دستگاه های بلوتوث نزدیک بدون استفاده از باتری قابل توجه تلفن استفاده می کند و سناریوهای «جادویی» را براساس نزدیکی دستگاه فعال می کند. هدف GFPS در ابتدا تسهیل جفت سازی دستگاه های سینک صوتی برای اولین بار، مانند بلندگوها، هدفون ها و کیت های خودرو، با کمترین تعامل کاربر مورد نیاز است. جفت شدن و اتصال مجدد بعدی بر اساس مجاورت یکپارچه خواهد بود.

وابستگی های پروفایل

این نمایه به نمایه توزیع صوتی پیشرفته (A2DP) یا نمایه هندزفری (HFP) نیاز دارد. اجرای سرویس GFPS با مشخصات هسته بلوتوث نسخه 4. 2 یا جدیدتر سازگار است.

سفارش هشتگانه

هر جا که یک فیلد از چندین بایت تشکیل شده باشد، ترتیب بایت ها به صورت big-endian است، یعنی ترتیب بایت های شبکه (هشت بایت مهم ترین تا اکتت کم اهمیت). توجه داشته باشید که در حالی که این استاندارد برای بایت های منتقل شده از طریق شبکه است، با ترتیب بایت برای فیلدهای چند بایتی در مشخصات بلوتوث SIG متفاوت است (به عنوان مثال، یک UUID سرویس در یک تبلیغات بسیار کم است).

پیکربندی

نقش ها

نمایه دو نقش را تعریف می کند: جستجوگر جفت سریع و ارائه دهنده جفت سریع. Seeker معمولاً یک تلفن است که به دنبال یک دستگاه صوتی برای جفت شدن با آن است. ارائه دهنده یک دستگاه صوتی است که حضور و آمادگی خود را برای جفت شدن (به عنوان مثال یک جفت هدفون قابل شناسایی) تبلیغ می کند. جفت جستجوگر سریع باید از نقش مرکزی GAP استفاده کند. ارائه دهنده جفت سریع باید از نقش محیطی GAP استفاده کند. علاوه بر این، ارائه دهنده جفت سریع باید یک نمایه بلوتوث مرتبط مانند نمایه توزیع صوتی پیشرفته (A2DP) یا نمایه هندزفری (HFP) را پیاده سازی کند. هر دو نقش جستجوگر جفت سریع و ارائه دهنده جفت سریع باید از روش های اتصال کلاسیک بلوتوث BR/EDR پشتیبانی کنند.

کشف دستگاه

برای تسهیل کشف دستگاه، ارائه دهنده جفت سریع باید باری را تبلیغ کند که نشان دهنده پشتیبانی از سرویس جفت سریع Google است (با داده هایی که در زیر توضیح داده شده است). جستجوگر جفت سریع باید به صورت دوره ای قاب های تبلیغاتی ارائه دهنده جفت سریع را اسکن کرده و مشاهده کند و در صورت علاقه اقدام کند.

ارائه دهنده جفت سریع

ثبت نام مدل

تمام مدل های ارائه دهنده قبل از کار با جفت سریع باید در Google ثبت شوند. پس از ثبت نام ، گوگل یک شناسه مدل و جفت کلید عمومی/خصوصی ضد پخش را توزیع می کند. اطلاعات ارائه شده در هنگام ثبت نام در پیشنهاد جفت شدن ارائه شده به کاربر استفاده می شود و ممکن است در سایر UX استفاده شود. برای اطلاعات در مورد ثبت نام دستگاه و دریافت شناسه مدل مربوطه و کلیدهای ضد پاشیدن ، به مستندات دستگاههای مجاور مراجعه کنید.

انتقال قدرت

• این دستگاه شامل نوع داده سطح قدرت TX ، همانجا ، 1. 5 پوند در تبلیغات خود است.

در طول ثبت مدل ارائه شده است

• سازنده در هنگام ثبت مدل ، قدرت انتقال و مدل دستگاه مورد استفاده برای اندازه گیری آن را فراهم می کند.
• دستگاه باید هنگام استفاده از این گزینه ، قدرت انتقال خود را برای همه پخش ها ثابت نگه دارد تا اندازه گیری مسافت دقیق باشد.

کلیدی

جفت کلید عمومی/خصوصی ضد فریبنده

پس از ثبت نام مدل ، به همراه شناسه مدل ، Google یک کلید خصوصی ضد انفجار 256 بیتی (یک عدد صحیح در [1 ، N-1] در منحنی بیضوی SECP256R1) توزیع می کند. این کلید باید در دستگاه ارائه دهنده ادامه یابد و در حالت ایده آل در داخل یک عنصر امن (SE) ذخیره شود. توجه داشته باشید که یک عنصر امن به شدت توصیه می شود - در صورت عدم وجود یکی ، هیچ تضمینی وجود ندارد که مهاجمان نتوانند نقش ارائه دهنده را فریب دهند ، زیرا کلید خصوصی می تواند نشت کند. این نشت کلیدی احتمال حمله انسان در حملات میانه را باز می کند. بنابراین ، در صورت تشخیص جعل هویت یا سوءاستفاده ، ویژگی های جفت سریع که از این کلید استفاده می کنند ممکن است غیرفعال شوند (برای مثال ، اعلان "شیر به جفت" هنگامی که ارائه دهنده در حالت جفت شدن است).

کلید عمومی مربوط به ضد پاشیدن مربوطه در حال حاضر توسط ارائه دهنده استفاده نمی شود. این توسط Seeker استفاده می شود تا پیام ارسال به ارائه دهنده را رمزگذاری کند (به جفت شدن مبتنی بر کلید مراجعه کنید).

لیست کلید حساب

ارائه دهنده باید فضا را برای ذخیره لیستی از کلیدهای حساب 128 بیتی اختصاص دهد. هر کلید حساب اجازه می دهد تا ارائه دهنده به عنوان متعلق به یک حساب کاربری خاص شناخته شود.

این لیست باید بتواند حداقل پنج کلید را ذخیره کند (یعنی باید حداقل 80 بایت فضای اختصاص داده شده به این لیست وجود داشته باشد). ارائه دهندگان می توانند بیش از این به صورت اختیاری ذخیره کنند ، آنها فقط باید اطمینان حاصل کنند که کلیدها در داخل بسته تبلیغاتی خود قرار می گیرند. تعداد دقیقی که می تواند ذخیره شود بستگی به تعداد بایت رایگان در بسته تبلیغاتی دارد. برای اطلاعات بیشتر در مورد تعیین تعداد بایت هر کلید ، به بخش فیلتر کلید حساب مراجعه کنید. به عنوان مثال ، برای تبلیغ 10 کلید حساب ، باید 15 بایت در بسته موجود باشد.

این لیست در ابتدا خالی است و در صورت ارائه دهنده ارائه دهنده کارخانه (اگر کاربر لیست دستگاه های زوج خود را پاک کند) باید پاک شود. این لیست همانطور که در بخش ویژگی اصلی حساب شرح داده شده است ، جمع شده است.

تبلیغات: در صورت کشف

هنگامی که دستگاه ارائه دهنده BR/EDR قابل کشف است (یعنی در حالت جفت شدن) ، باید داده های شناسه مدل سریع جفت را از طریق BLE تبلیغ کند.

فاصله تبلیغاتی

فاصله بین تبلیغات نباید بزرگتر از 100ms (10 هرتز) باشد. نرخ سریع به سالک اجازه می دهد تا حتی در هنگام اسکن در حالت کم مصرف ، به سرعت ارائه دهنده را پیدا کند.

آدرس بلندی

برای جلوگیری از ردیابی ، تبلیغات BLE باید از آدرس خصوصی قابل حل و مستغلات (RPA) استفاده کند. در حالی که دستگاه به طور فعال تبلیغ می شود ، آدرس باید حداقل هر 15 دقیقه چرخانده شود و هر بار که دولت از تبلیغات به تبلیغات تغییر نمی کند. برای تغییر فاصله تصادفی آدرس باید از یک افست تصادفی استفاده شود.

Payload Payload: داده های شناسه مدل سریع جفت

تبلیغات باید شامل نوع داده داده های سرویس ، همان ، 1. 11 پوند باشد. UUID باید خدمات سریع جفت 0xfe2c باشد. داده های سرویس شامل موارد زیر است:

شناسه مدل

هر مدل ارائه دهنده دارای یک شناسه مدل 24 بیتی است که در هنگام ثبت مدل توسط Google ارائه می شود.

تبلیغات: وقتی قابل کشف نیست

هنگامی که قابل کشف نیست (یعنی در حالت جفت شدن نیست) ، دستگاه ارائه دهنده با استفاده از دستورالعمل های زیر باید داده های حساب جفت سریع را تبلیغ کند.

تبلیغات داده های حساب به جستجوگرها این نزدیکی را می دهد تا تشخیص دهند که یک ارائه دهنده متعلق به حساب خود است و بدون نیاز به مجبور کردن ارائه دهنده به حالت جفت شدن ، باعث می شود که یک دلیل مشترک برای شکایت کاربر باشد. جستجوگران این فرصت را برای کاربران فراهم می کنند تا بتوانند این پخش را در مواردی که منتظر نیستند با ارائه دهنده جفت شوند یا پخش کننده نباشد ، نادیده بگیرند (برای مثال ، اگر قبلاً جفت شده اند). افراد متقاضی همچنین به طور خودکار پخش های بد را به طور خودکار فیلتر می کنند ، مانند زمانی که داده های حساب غلط تنظیم می شوند.

فاصله تبلیغاتی

فاصله بین تبلیغات باید حداکثر 250ms (4Hz) باشد.

آدرس بلندی

برای جلوگیری از ردیابی ، تبلیغات BLE باید از آدرس خصوصی قابل حل و مستغلات (RPA) استفاده کند. در حالی که دستگاه به طور فعال تبلیغ می شود ، آدرس باید حداقل هر 15 دقیقه چرخانده شود و هر بار که دولت از تبلیغات به تبلیغات تغییر نمی کند. برای تغییر فاصله تصادفی آدرس باید از یک افست تصادفی استفاده شود.

Payload Advertising: داده های حساب جفت سریع

تبلیغات باید شامل نوع داده داده های سرویس ، همان ، 1. 11 پوند باشد. UUID باید خدمات سریع جفت 0xfe2c باشد. داده های سرویس شامل موارد زیر است:

داده های کلیدی حساب شامل:

فیلتر کلید حساب

فیلتر کلید حساب تبلیغاتی به یک جستجوگر اجازه می دهد تا قبل از تلاش برای اتصال ، به سرعت بررسی کند که آیا یک ارائه دهنده ممکن است یک کلید حساب خاص (با احتمال مثبت کاذب ، به طور متوسط بسیار کمتر از 0. 5 ٪) داشته باشد. جستجوگر همچنین ممکن است به طور خودکار وصل شود و سعی کند این روش را هنگام پخش یک فیلتر که به طور بالقوه شامل یکی از کلیدهای حساب خود است ، شروع کند ، تا بتواند میزان مثبت کاذب را کاهش دهد.

فیلتر کلید حساب یک فیلتر شکوفه با طول متغیر است که به شرح زیر ساخته شده است:

1. Let n be the number of account keys (n>= 1) در لیست کلید حساب ادامه یافته.
2. بگذارید S ، اندازه فیلتر در بایت ، (1. 2*N + 3) کوتاه شود. به عنوان مثال ، اگر 1 کلید ادامه داشته باشد ، S = 4 بایت.
3. فیلتر F را به عنوان آرایه ای از بایت های S ، هر یک بر 0 تنظیم کنید.
4. برای هر کلید حساب k در لیست کلید حساب مداوم: الف. یک مقدار V تولید کنید ، کجا: i. 16 بایت اول K II است. بایت های باقیمانده نمک هستند (به چرخش مراجعه کنید). ب. Hash V با استفاده از SHA256 ، به دست آوردن مقدار 256 بیتی H. c. H را به هشت عدد صحیح 32 بیتی بدون امضا ، x = تقسیم کنید. د. برای هر XI: من. بگذارید k modulo xi تعداد بیت های موجود در فیلتر باشد ، (S * 8). ii. بایت را در F در شاخص (K / 8) دریافت کنید ، گرد شده است. iiiدر بایت ، بیت را در شاخص (K ٪ 8) تنظیم کنید. IV. به عبارت دیگر:

    

k = xi ٪ (s * 8) f [k/8] = f [k/8] |(1

فیلتر F را به عنوان قسمت Filter Account Key Filter ، در داده های تبلیغاتی قرار دهید. توجه داشته باشید که هیچ "پایان" به این مقدار وجود ندارد ، زیرا بایت کم و بیش قابل توجه وجود ندارد - ترتیب بایت را تغییر ندهید.

چرخش

برای کاهش توانایی ردیابی دستگاه ها با نظارت بر فیلتر کلید حساب ، فیلتر کلید حساب بازسازی می شود ، با نمک جدید ، حداقل هر 15 دقیقه در حالی که دستگاه به طور فعال تبلیغ می شود. با این حال ، توجه داشته باشید که اگر دستگاه از طریق لینک BR/EDR متصل باشد ، آدرس عمومی یک انتهای لینک به شکل کد دسترسی کانال پخش می شود ، بنابراین حریم خصوصی محدود است.

دو گزینه برای نمک وجود دارد:

گزینه نمک A: نمک آدرس BLE با آدرس BLE فعلی ، همچنین به عنوان آدرس خصوصی قابل حل و منطقی (RPA) شناخته می شود. اگر در هنگام چرخش ، پاسخ به تماس در دسترس باشد ، این ساده ترین گزینه است و ترجیح داده می شود.

برای تولید فیلتر کلید حساب:

1. از رده بندی 6 بایت فعلی (به صورت بزرگ ، به Octet Order) به عنوان نمک در مرحله 4 (A) استفاده کنید.
2. در داده های حساب Fast Pair تبلیغ شده ، فیلتر تولید شده را در قسمت Filter Account Key Filter قرار دهید. میدان نمکی اختیاری را درج نکنید.

هربار که درمانگاه می چرخد ، فیلتر کلید حساب را بازسازی کنید. در حالت ایده آل ، اطمینان حاصل کنید که هیچ تبلیغی با استفاده از آدرس جدید و فیلتر کلید حساب قدیمی پخش نمی شود. این کار را می توان با مکث تبلیغات به طور خلاصه انجام داد در حالی که فیلتر کلید حساب بازسازی می شود. با این حال ، همانطور که قبلاً نیز اشاره شد ، محدودیتی برای حریم خصوصی وجود دارد که می تواند با دستگاه های دو حالته با اتصالات فعال BR/EDR حاصل شود.

گزینه نمک B: فیلد نمک در صورت چرخش آدرس BLE از این گزینه استفاده کنید. استفاده از نمک باید کمتر از چرخش با آدرس BLE ایمن تلقی شود، زیرا اگر این دو با سرعت یکسان نچرخند، ردیابی همچنان امکان پذیر است. آدرس BLE همچنین به دلیل طولانی بودن آنتروپی بیشتری را معرفی می کند. در صورت امکان از آدرس BLE استفاده کنید.

برای تولید فیلتر کلید حساب:

1. یک بایت تصادفی S ایجاد کنید.
2. از بایت S به عنوان نمک در مرحله 4(a) استفاده کنید.
3. در داده های حساب جفت سریع تبلیغ شده، فیلتر ایجاد شده را در قسمت فیلتر کلید حساب و S را در قسمت نمک قرار دهید.

از یک تایمر استفاده کنید که هر 15 دقیقه یک بار روشن می شود. هر بار که تایمر فعال می شود، فیلتر کلید حساب را دوباره ایجاد کنید. تایمر به صورت اختیاری می تواند سریعتر شلیک کند، اما نه سریعتر از یک بار در دقیقه.

مشخصه: جفت سازی مبتنی بر کلید

این مشخصه رویه جفت سازی مبتنی بر کلید را کنترل می کند. در این روش، سطح معینی از اعتماد با تأیید اینکه جستجوگر و ارائه دهنده هر دو دارای یک کلید از پیش مشترک هستند، ایجاد می شود. کلید در هر مورد متفاوت است:

• مورد 1: کلید از پیش مشترک بر اساس جفت کلید عمومی/خصوصی ضد جعل و جفت کلید عمومی/خصوصی خود جستجوگر است که برای هر تلاش جفت سازی تغییر می کند.
  • ارائه دهنده در حالت جفت شدن است.
  • جستجوگر تأیید می کند که ارائه دهنده کلید خصوصی ضد جعل را در اختیار دارد.

  توجه داشته باشید که در حالت جفت سازی، البته ممکن است ارائه دهنده به روش معمول جفت شود، به عنوان مثال، برای جفت شدن با دستگاهی که جفت سازی مبتنی بر کلید Fast Pair را پشتیبانی نمی کند.

  • ارائه دهنده معمولاً در حالت جفت شدن نیست.(اما این یک الزام نیست - ارائه دهنده باید از استفاده از کلید حساب حتی در حالت جفت شدن پشتیبانی کند.)
  • جستجوگر و ارائه دهنده هر کدام تأیید می کنند که دیگری کلید حساب را در اختیار دارد.

  از آنجایی که هر دو مورد بسیار شبیه به هم هستند، به جز مواردی که از کلید از پیش مشترک استفاده شده است، آنها در Procedure ترکیب می شوند.

  فرمت داده

  نحوه استفاده از هر قالب را ببینید.

   

  هشتاد	نوع داده	شرح	ارزش	اجباری؟
  0 - 15	uint128	درخواست رمزگذاری شده	متفاوت است	اجباری
  16 - 79	کلید عمومی	متفاوت است	اختیاری

  جدول 1. 1: درخواست رمزگذاری شده، نوشته شده به ویژگی توسط جستجوگر.

   

  هشتاد	نوع داده	شرح	ارزش	اجباری؟
  0	uint8	نوع پیام	0x00 = درخواست جفت شدن مبتنی بر کلید	اجباری
  1	uint8	پرچم ها: 1. بیت 0 (MSB): 1 برای درخواست قابلیت کشف، 0 در غیر این صورت. 2. بیت 1: 1 اگر جستجوگر درخواست کند که ارائه دهنده پیوند را آغاز کند، و این درخواست حاوی آدرس BR/EDR جستجوگر است. 0 در غیر این صورت؛3. بیت های 2 - 7 برای استفاده در آینده رزرو شده اند و باید نادیده گرفته شوند.	متفاوت است	اجباری
  2 - 7	uint48	یکی: 1. آدرس BLE فعلی ارائه دهنده. 2. آدرس عمومی ارائه دهنده	متفاوت است	اجباری
  8 - 13	uint48	آدرس BR/EDR جستجوگر	متفاوت است	تنها در صورتی ارائه شود که بیت پرچم 1 تنظیم شده باشد
  n - 15	مقدار تصادفی (نمک)	متفاوت است	اجباری

  جدول 1. 2: درخواست خام. رمزگشایی از درخواست رمزگذاری شده در جدول 1. 1.

   

  هشتاد	نوع داده	شرح	ارزش
  0	uint8	نوع پیام	0x01 = پاسخ جفت سازی مبتنی بر کلید
  1 - 6	uint48	آدرس عمومی ارائه دهنده (BR/EDR).	متفاوت است
  7 - 15	مقدار تصادفی (نمک)	متفاوت است

  جدول 1. 3: پاسخ خام. برای تولید پاسخ رمزگذاری شده در جدول 1. 4 رمزگذاری شده است.

   

  هشتاد	نوع داده	شرح	ارزش
  0-15	uint128	پاسخ رمزگذاری شده	متفاوت است

  جدول 1. 4: پاسخ رمزگذاری شده، ارسال شده توسط ارائه دهنده برای جستجوگر از طریق یک اعلان.

  روش

  به جای فراخوانی فوری هر یک از رویه های پیوند معمولی BR/EDR یا BLE، جستجوگر ابتدا اعلان های مربوط به ویژگی جفت سازی مبتنی بر کلید را فعال می کند و سپس داده های جدول 1. 1 را روی آن می نویسد.

  هنگام رسیدگی به درخواست نوشتن از طرف جستجوگر جفت سریع، ارائه دهنده جفت سریع باید موارد زیر را انجام دهد:

  1. اگر فیلد کلید عمومی اختیاری وجود داشته باشد: الف. اگر دستگاه در حالت جفت شدن نیست، نوشتن را نادیده بگیرید و خارج شوید. بدر غیر اینصورت من. از کلید عمومی دریافتی (نقطه 64 بایتی در منحنی بیضی secp256r1)، کلید خصوصی از پیش نصب شده Anti-Spoofing (همچنین secp256r1) و الگوریتم Elliptic-Curve Diffie-Hellman برای تولید یک کلید AES 256 بیتی استفاده کنید. iiاز SHA-256 برای هش کردن کلید AES 256 بیتی استفاده کنید. III. 128 بیت اول نتیجه را بگیرید. این کلید AES Anti-Spoofing است که در مرحله بعد استفاده می شود.
  2. با استفاده از AES-128 ، سعی در رمزگشایی ارزش دارید. از آنجا که این مقدار یک بلوک AES 16 بایت است ، هیچ حالت رمزگذاری IV یا چند بلوک لازم نیست. آ. از کدام کلید استفاده می شود: من. اگر یک کلید AES ضد فریبنده در مرحله 1 ایجاد شده است ، از آن کلید استفاده کنید. ii. در غیر این صورت ، هر کلید را در لیست کلید حساب مداوم امتحان کنید. ب. اگر یک کلید با موفقیت ارزش را رمزگشایی کند ، شکسته شود و به مرحله بعدی ادامه دهید. ج. اگر خروجی با فرمت در جدول 1. 2 مطابقت داشته باشد ، این مقدار با موفقیت رمزگشایی می شود (یعنی اگر حاوی آدرس BLE فعلی ارائه دهنده جفت سریع یا آدرس عمومی ارائه دهنده جفت سریع باشد). د. توجه داشته باشید که در انتهای بسته یک نمک وصل شده است. در صورت امکان ، این نمک ها باید ردیابی شوند و در صورت دریافت ارائه دهنده درخواستی که حاوی نمک از قبل استفاده شده باشد ، باید از این درخواست نادیده گرفته شود تا از حملات پخش مجدد جلوگیری شود. ه. به عنوان جایگزینی برای ردیابی نمک ، اگر نوشتن شامل آدرس خصوصی ارائه دهنده باشد ، راه دیگری برای جلوگیری از حملات پخش مجدد این است که زمان چرخش آدرس خصوصی قابل حل بعدی را افزایش دهید تا چرخش قبل از نوشتن جفت مبتنی بر کلید بعدی رخ دهدپذیرفته شده.
  3. اگر هیچ کلید نمی تواند با موفقیت ارزش را رمزگشایی کند ، نوشتن و خروج را نادیده بگیرید. آ. تعداد این شکست ها را حفظ کنید. هنگامی که تعداد شکست به 10 رسید ، بلافاصله تمام درخواست های جدید را شکست دهید. شمارش خرابی را بعد از 5 دقیقه ، بعد از برق یا بعد از موفقیت تنظیم مجدد کنید.
  4. در غیر این صورت ، کلید موفق را به عنوان K. ذخیره کنید. این k را به عنوان قابل استفاده برای رمزگشایی Passkey می نویسد که در این لینک LE دریافت می کند ، اما نه کلید حساب می نویسد و نه در هر لینک دیگری نوشت. در صورت شروع جفت شدن ، یک تایمر را برای دور انداختن K پس از 10 ثانیه شروع کنید (این ممکن است همان تایمر باشد که در مرحله 5 برای فعال کردن قابلیت کشف موقت استفاده می شود). همچنین اگر این پیوند LE قطع شود ، K را دور بیندازید.
  5. اگر بیت پرچم های درخواست رمزگشایی شده درخواست کشف بر روی 1 تنظیم شده است ، برای 10 ثانیه قابل کشف یا تا زمانی که این روند جفت شدن کامل شود ، هر کدام از اول باشد. آ. بر خلاف سایر مواقعی که ارائه دهنده جفت سریع قابل کشف است ، نباید در این مدت داده های شناسه مدل Fast Pair را تبلیغ کند. ب. دلیل این امر مورد نیاز است: نسخه های اندرویدی Nougat و در زیر درخواستی را با مجموعه بیت کشف ارسال می کنند تا در اطراف یک اشکال در سیستم عامل کار کنند که در آن جفت شدن با یک دستگاه بدون کشف اولین دستگاه از بین می رود.
  6. پاسخ خام 16 بایت را که در جدول 1. 3 نشان داده شده است ، با جمع آوری نوع و آدرس BR/EDR ارائه دهنده ، و سپس پر کردن باقیمانده بسته با یک بلوک بایت های تصادفی (یعنی نمک) تولید کنید.
  7. برای تولید پاسخ رمزگذاری شده 16 بایت که در جدول 1. 4 نشان داده شده است ، پاسخ خام را با K رمزگذاری کنید. این را از طریق یک اطلاعیه در مورد ویژگی جفت شدن مبتنی بر کلید ارسال کنید.
  8. اگر پرچم های درخواستی بایت 1 بیت 1 تنظیم شده در 1: a. این نشان می دهد که جستجوگر از ارائه دهنده درخواست می کند تا پیوند را با آدرس BR/EDR جستجوگر ، که در بایت 8-13 وجود دارد ، آغاز کند. ب. درخواست جفت شدن را به آدرس BR/EDR جستجوگر ارسال کنید. درخواست جفت شدن باید همانطور که در زیر شرح داده شده است (مرحله "در طول جفت شدن"). ج. دلیل این امر مورد نیاز است: با شروع ارائه دهنده در مورد مسئله در برخی از دستگاه ها کار می کند.
  9. اگر بایت پرچم های درخواست بیت 1 روی 0 تنظیم شده است: الف. برای درخواست جفت شدن تا 10 ثانیه صبر کنید. اگر هیچ کدام دریافت نشود ، خروج کنید. ب. توجه داشته باشید که این ممکن است یک درخواست BR/EDR باشد ، از یک آدرس متفاوت (آدرس عمومی جستجوگر ، به جای آدرس خصوصی قابل حل آن). ما در حین جفت شدن دوباره تأیید خواهیم کرد که دستگاه درخواست کننده در اختیار K. c است. حتی اگر این یک درخواست جفت شدن BLE باشد ، برای جلوگیری از میانی ، همان رویه باید دنبال شود. پس از جفت شدن بیش از BLE ، دستگاه ها باید از نسل کلیدی متقاطع استفاده کنند تا از BR/EDR جفت شوند.
  10. در طول جفت شدن: الف. هنگامی که یک بسته درخواست/پاسخ جفت شدن از سالک دریافت می شود: اگر قابلیت دستگاه در درخواست Noinput/No Output باشد ، جفت شدن پایان ، برای جلوگیری از استفاده از روش جفت شدن Just Works. ب. برای بسته درخواست/پاسخ جفت ارسال شده توسط ارائه دهنده: قسمت قابلیت های دستگاه را برای نمایش/YesNO تنظیم کرده و الزامات احراز هویت را برای محافظت از MITM مورد نیاز تنظیم کنید. این باعث می شود روش جفت مقایسه عددی (همچنین به عنوان تأیید PassKey در Android شناخته می شود). ما به این موضوع اعتماد می کنیم تا تأیید کنیم که دستگاه درخواست کننده در واقع سالخورده جفت سریع است ، و اینکه هیچ یک از میانه ها وجود ندارد. مثالها را ببینید. ج. دلیل این امر لازم است: روش جفت شدن خارج از باند مناسب تر خواهد بود ، اما این پلتفرم آن را در تمام نسخه های مورد نظر Android در معرض نمایش قرار نمی دهد.
  11. هنگامی که تأیید PassKey لازم است ، تا 10 ثانیه صبر کنید تا یک ویژگی PassKey را بنویسید. آ. به طور معمول ، با این روش جفت شدن ، کاربر تأیید می کند که PassKeys نمایش داده شده در صفحه هر دستگاه یکسان است. درعوض ، فقط برای این جفت شدن ، ما آنها را از طریق BLE منتقل می کنیم ، رمزگذاری شده با کلید از پیش سهم قابل اعتماد. به این ترتیب که این رویکرد نباید برای دستگاه هایی که دارای صفحه نمایش یا صفحه کلید هستند ، استفاده شود زیرا باعث ایجاد سازش جزئی در محافظت از MITM می شود. در حال حاضر جفت سریع به دلیل این امر هنوز از آن نوع دستگاه ها پشتیبانی نمی کند. ج. اگر تایمر 10 ثانیه ای با نوشتن یک پاسگاه منقضی شود ، پس از K.
  12. When a value is written to the Passkey characteristic, this is the Encrypted Passkey Block. Decrypt it with K to yield a Raw Passkey Block, with format shown in Characteristic: Passkey>جدول 2. 2 (نوع = PassKey Seeker).
  13. اگر رمزگشایی از بین رفت ، نوشتن را نادیده بگیرید و K. را دور بیندازید.
  14. در غیر این صورت ، بلوک Passkey Raw شامل یک Passeeker 6 رقمی Passkey است که این پاسکی است که جستجوگر انتظار دارد.
  15. Pseeker را با PassKey مورد انتظار خود ، PPROVIDER مقایسه کنید. آ. اگر مقادیر برابر هستند ، به تأیید "بله" پاسخ دهید. ب. در غیر این صورت ، به تأیید "نه" پاسخ دهید ، و باعث شکست جفت شدن می شود.
  16. Regardless of whether pairing failed, produce another Raw Passkey Block, with format shown in Characteristic: Passkey>جدول 2. 2 ، حاوی PassKey مورد انتظار خود ، PPRVIDER. آ. اطمینان حاصل کنید که این بلوک از نوع صحیح برخوردار است (کلید ارائه دهنده ؛ جدول را ببینید). ب. توجه: از نمك از بلوك گذرگاه دریافت شده از سالك استفاده نکنید. یک مقدار تصادفی جدید ایجاد کنید.
  17. بلوک Passkey Raw را با K رمزگذاری کنید و بلوک PassKey رمزگذاری شده حاصل را از طریق یک اطلاعیه در مورد PassKey مشخص کنید.
  18. اگر سالک Passkey P صحیح را دریافت و رمزگشایی کند ، جستجوگر نیز به تأیید پاسخ می دهد ، و جفت شدن موفق می شود. آ. اگر این جفت شدن موفق شود ، پس از آن برای رمزگشایی کلید حساب کاربری در این لینک LE قابل استفاده است ، اما برای هر پاسکی بعدی نمی نویسد و نه در هر لینک دیگری نوشت. یک تایمر را برای دور انداختن K پس از 10 ثانیه شروع کنید. همچنین K را پس از هرگونه تلاش برای نوشتن یک کلید حساب و ، طبق مرحله 4 ، اگر پیوند LE قطع شود ، دور بیندازید. ب. در صورت عدم موفقیت این جفت ، K. را دور بیندازید.
  19. قسمت قابلیت های دستگاه را به NoInput/NOOUTPUT و الزامات احراز هویت برگردانید تا حفاظت از MITM لازم نباشد تا جفت های جدید مطابق آنچه انتظار می رود ادامه یابد.

  مثال ها Example 1 : Successful pairing attempt (no man-in-the-middle). Example 2 : Failed pairing attempt, with a man-in-the-middle.

  ویژگی: PassKey این ویژگی در طی روش جفت شدن مبتنی بر کلید استفاده می شود.

   

  هشتاد	نوع داده	شرح	ارزش
  0 - 15	uint128	بلوک رمزگذاری شده رمزگذاری شده	متفاوت است

  جدول 2. 1: بلوک رمزگذاری شده رمزگذاری شده. برای استفاده از روش جفت شدن مبتنی بر کلید مراجعه کنید.

   

  هشتاد	نوع داده	شرح	ارزش
  0	uint8	نوع پیام	یکی از: 0x02 = Seeker's PassKey ؛0x03 = PassKey ارائه دهنده ؛
  1 - 3	واحد 32	پاس 6 رقمی	متفاوت است
  4 - 15	مقدار تصادفی (نمک)	متفاوت است

  جدول 2. 2: بلوک PassKey RAW. نسخه رمزگشایی شده جدول 2. 1.

  ویژگی: کلید حساب

  پس از جفت شدن ، Seeker Fast Pair یک کلید حساب را برای ارائه دهنده Fast Pair می نویسد.

   

  هشتاد	نوع داده	شرح	ارزش
  0 - 15	uint128	کلید حساب (رمزگذاری شده)	متفاوت است

  پس از دریافت درخواست نوشتن ، ارائه دهنده سریع جفت باید موارد زیر را انجام دهد:

  1. کلید حساب را با استفاده از راز مشترک تولید شده از مرحله 4 در روش فوق رمزگشایی کنید. آ. قبل از رمزگشایی ، تأیید کنید که از راز مشترک برای رمزگشایی درخواست PassKey از مرحله 12 استفاده شده است. اگر این مرحله با استفاده از این راز گذشت ، این نوشتن را نادیده بگیرید و ترک کنید. ب. در این مرحله ، راز مشترک (K در روش فوق) دوباره برای این جفت شدن استفاده نمی شود. هرگونه درخواست که با این کلید رمزگذاری شده باشد بدون شروع مجدد روش فوق باید رد شود.
  2. تأیید کنید که مقدار رمزگشایی شده با 0x04 شروع می شود. اگر این کار را نکرد ، این نوشتن را نادیده بگیرید و ترک کنید.
  3. بررسی کنید که آیا لیست کلید حساب ادامه یافته فضایی برای مقدار جدید دارد یا خیر.
  4. اگر اینطور نیست ، کمترین مقدار مورد استفاده را از لیست حذف کنید.
  5. مقدار جدید را به لیست اضافه کنید.

  کلیدهای حساب در لیست در هنگام جفت شدن مبتنی بر کلید استفاده می شود.