این صفحه به‌وسیله ‏Cloud Translation API‏ ترجمه شده است.

مشخصات لوازم جانبی شبکه هاب را پیدا کنید، مشخصات لوازم جانبی شبکه هاب را پیدا کنید، مشخصات لوازم جانبی شبکه هاب را پیدا کنید، مشخصات لوازم جانبی شبکه هاب را پیدا کنید

نسخه ۱.۳

مشخصات لوازم جانبی شبکه Find Hub (FHN) یک رویکرد رمزگذاری سرتاسری را برای ردیابی دستگاه‌های بلوتوث کم‌مصرف (BLE) که از طریق سیگنال‌های رادیویی ارسال می‌شوند، تعریف می‌کند. این صفحه FHN را به عنوان افزونه‌ای برای مشخصات Fast Pair توصیف می‌کند. ارائه‌دهندگان خدمات اینترنتی در صورت داشتن دستگاه‌هایی که با FHN سازگار هستند و مایل به فعال کردن ردیابی موقعیت مکانی برای آن دستگاه‌ها هستند، باید این افزونه را فعال کنند.

مشخصات گات

یک ویژگی عمومی اضافی (GATT) باید با معانی زیر به سرویس Fast Pair اضافه شود:

ویژگی سرویس جفت‌سازی سریع	رمزگذاری شده	مجوزها	شناسه کاربری
اقدامات بیکن	خیر	بخوانید، بنویسید و اطلاع دهید	`FE2C1238-8366-4814-8EB0-01DE32100BEA`

جدول 1: ویژگی‌های سرویس جفت‌سازی سریع برای FHN

احراز هویت

عملیات مورد نیاز این افزونه به عنوان یک عملیات نوشتن انجام می‌شود که توسط یک مکانیسم چالش-پاسخ ایمن شده است. قبل از انجام هر عملیاتی، انتظار می‌رود جستجوگر یک عملیات خواندن از مشخصه جدول ۱ انجام دهد که منجر به ایجاد یک بافر با فرمت زیر می‌شود:

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شماره نسخه اصلی پروتکل	0x01
۱ - ۸	آرایه بایتی	نانس تصادفی یک‌بار مصرف	متغیر است

هر عملیات خواندن باید منجر به یک nonce متفاوت شود و یک nonce واحد باید فقط برای یک عملیات واحد معتبر باشد. nonce باید حتی اگر عملیات با شکست مواجه شود، نامعتبر شود.

سپس جستجوگر یک کلید احراز هویت یکبار مصرف را محاسبه می‌کند تا در درخواست نوشتن بعدی استفاده شود. کلید احراز هویت همانطور که در جداول ۲ تا ۵ توضیح داده شده است محاسبه می‌شود. بسته به عملیاتی که درخواست می‌شود، جستجوگر از یک یا چند کلید زیر مطلع است:

کلید حساب : کلید حساب 16 بایتی Fast Pair، همانطور که در مشخصات Fast Pair تعریف شده است.
کلید حساب مالک : ارائه‌دهنده، اولین باری که یک جستجوگر به ویژگی اقدامات Beacon دسترسی پیدا می‌کند، یکی از کلیدهای حساب مالک موجود را به عنوان کلید حساب مالک انتخاب می‌کند. کلید حساب مالک انتخاب شده تا زمانی که ارائه‌دهنده به تنظیمات کارخانه بازنشانی نشود، قابل تغییر نیست. ارائه‌دهنده نباید کلید حساب مالک را در صورت اتمام اسلات‌های کلید حساب آزاد، حذف کند.
- ارائه‌دهندگانی که از قبل از FHN هنگام جفت شدن برای اولین بار پشتیبانی می‌کنند (یا پس از تنظیم مجدد کارخانه از آن پشتیبانی می‌کنند)، اولین کلید حساب را انتخاب می‌کنند، زیرا این تنها کلید حساب موجود است وقتی که جستجوگر در حین جفت شدن، وضعیت تأمین را می‌خواند.
- ارائه‌دهندگانی که پس از جفت شدن (برای مثال، از طریق به‌روزرسانی میان‌افزار) پشتیبانی FHN را دریافت می‌کنند، می‌توانند هر کلید حساب موجودی را انتخاب کنند. منطقی است که اولین کلید حساب را که برای خواندن وضعیت تأمین از اقدامات چراغ راهنما که پس از به‌روزرسانی میان‌افزار مشخص می‌شوند، انتخاب شود، با فرض اینکه کاربری که به‌روزرسانی را انجام داده، مالک فعلی ارائه‌دهنده است.
کلید هویت موقت (EIK) : یک کلید ۳۲ بایتی که به صورت تصادفی توسط جستجوگر هنگام انجام فرآیند تأمین FHN انتخاب می‌شود. این کلید برای استخراج کلیدهای رمزنگاری که برای گزارش‌های مکانی رمزگذاری سرتاسری استفاده می‌شوند، استفاده می‌شود. جستجوگر هرگز آن را برای پشتیبان فاش نمی‌کند.
کلید بازیابی : به صورت SHA256(ephemeral identity key || 0x01) تعریف شده و به ۸ بایت اول کوتاه شده است. این کلید در backend ذخیره می‌شود و جستجوگر می‌تواند از آن برای بازیابی EIK استفاده کند، مشروط بر اینکه کاربر با فشار دادن دکمه‌ای روی دستگاه رضایت خود را اعلام کند.
کلید حلقه : به صورت SHA256(ephemeral identity key || 0x02) تعریف شده و به 8 بایت اول کوتاه شده است. این کلید در backend ذخیره می‌شود و جستجوگر فقط می‌تواند از آن برای زنگ زدن به دستگاه استفاده کند.
کلید محافظت در برابر ردیابی ناخواسته : به صورت SHA256(ephemeral identity key || 0x03) تعریف شده و به 8 بایت اول کوتاه شده است. این کلید در backend ذخیره می‌شود و جستجوگر فقط می‌تواند از آن برای فعال کردن حالت محافظت در برابر ردیابی ناخواسته استفاده کند.

عملیات

قالب داده‌های نوشته شده برای مشخصه در جداول ۲ تا ۵ آمده است. هر یک از عملیات‌ها بعداً در این بخش با جزئیات بیشتری مورد بحث قرار خواهند گرفت.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x00: خواندن پارامترهای بیکن 0x01: وضعیت آماده‌سازی را بخوانید 0x02: تنظیم کلید هویت موقت 0x03: پاک کردن کلید هویت موقت
۱	uint8	طول داده	متغیر است
۲ - ۹	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول `HMAC-SHA256(account key, protocol major version number \|\| the last nonce read from the characteristic \|\| data ID \|\| data length \|\| additional data)`
10 - متغیر	آرایه بایتی	داده‌های اضافی	0x00: ناموجود 0x01: ناموجود 0x02: 32 بایت که کلید هویت موقت هستند، AES-ECB-128 که با کلید حساب رمزگذاری شده است. اگر ارائه دهنده از قبل مجموعه کلید هویت موقت دارد، 8 بایت اول `SHA256(current ephemeral identity key \|\| the last nonce read from the characteristic)` نیز ارسال کنید. 0x03: هشت بایت اول `SHA256(ephemeral identity key \|\| the last nonce read from the characteristic)`

جدول ۲: درخواست تأمین Beacon.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x04: خواندن کلید هویت موقت با رضایت کاربر
۱	uint8	طول داده	0x08
۲ - ۹	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول `HMAC-SHA256(recovery key, protocol major version number \|\| the last nonce read from the characteristic \|\| data ID \|\| data length)`

جدول ۳: درخواست بازیابی کلید تأمین Beacon.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x05: حلقه 0x06: خواندن وضعیت زنگ خوردن
۱	uint8	طول داده	متغیر است
۲ - ۹	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول `HMAC-SHA256(ring key, protocol major version number \|\| the last nonce read from the characteristic \|\| data ID \|\| data length \|\| additional data)`
10 - متغیر	آرایه بایتی	داده‌های اضافی	‎0x05: 4 بایت که وضعیت زنگ، مدت زمان زنگ و میزان صدای زنگ را نشان می‌دهد. 0x06: ناموجود

جدول ۴: درخواست زنگ.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x07: حالت محافظت در برابر ردیابی ناخواسته را فعال کنید 0x08: حالت محافظت از ردیابی ناخواسته را غیرفعال کنید
۱	uint8	طول داده	متغیر است
۲ - ۹	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول `HMAC-SHA256(unwanted tracking protection key, protocol major version number \|\| the last nonce read from the characteristic \|\| data ID \|\| data length \|\| additional data)`
10 - متغیر	آرایه بایتی	داده‌های اضافی	‎0x07: 1 بایت پرچم‌های کنترلی (اختیاری)‎ 0x08: 8 بایت اول `SHA256(ephemeral identity key \|\| the last nonce read from the characteristic)`

جدول ۵: درخواست حفاظت در برابر ردیابی ناخواسته.

اعلان‌های مربوط به نوشتن موفقیت‌آمیز، همانطور که در جدول 6 ذکر شده است، فعال می‌شوند.

اعلان‌هایی با شناسه داده غیر از 0x05: تغییر وضعیت حلقه باید قبل از تکمیل تراکنش نوشتن که باعث ایجاد اعلان می‌شود، ارسال شود، یعنی قبل از ارسال PDU پاسخ برای درخواست نوشتن.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x00: خواندن پارامترهای بیکن 0x01: وضعیت آماده‌سازی را بخوانید 0x02: تنظیم کلید هویت موقت 0x03: پاک کردن کلید هویت موقت 0x04: خواندن کلید هویت موقت با رضایت کاربر 0x05: تغییر وضعیت حلقه 0x06: خواندن وضعیت زنگ خوردن 0x07: حالت محافظت در برابر ردیابی ناخواسته را فعال کنید 0x08: حالت محافظت از ردیابی ناخواسته را غیرفعال کنید
۱	uint8	طول داده	متغیر است
۲ - ۹	آرایه بایتی	احراز هویت	جزئیات در هر عملیات
10 - متغیر	آرایه بایتی	داده‌های اضافی	0x00: 8 بایت که نشان‌دهنده قدرت انتقال، مقدار کلاک، روش رمزگذاری و قابلیت‌های زنگ زدن است، رمزگذاری شده با AES-ECB-128 با کلید حساب (صفر پر شده) 0x01: 1 بایت که وضعیت تأمین را نشان می‌دهد و در صورت لزوم، شناسه موقت فعلی (20 یا 32 بایت) به دنبال آن می‌آید. 0x04: 32 بایت که کلید هویت موقت هستند، AES-ECB-128 رمزگذاری شده با کلید حساب ‎0x05: 4 بایت که نشان‌دهنده وضعیت جدید و تریگر برای تغییر است ‎0x06: 3 بایت که نشان‌دهنده اجزای فعال در حال زنگ زدن و تعداد دسی‌ثانیه‌های باقی‌مانده برای زنگ زدن است سایر شناسه‌های داده از داده‌های اضافی خالی استفاده می‌کنند

جدول 6: پاسخ سرویس بیکن.

جدول 7 کدهای خطای GATT احتمالی که توسط عملیات برگردانده می‌شوند را فهرست می‌کند.

کد	توضیحات	یادداشت‌ها
0x80	احراز هویت نشده	در پاسخ به درخواست نوشتن، زمانی که احراز هویت با شکست مواجه می‌شود (از جمله موردی که از یک nonce قدیمی استفاده شده است)، بازگردانده می‌شود.
0x81	مقدار نامعتبر	زمانی که مقدار نامعتبری ارائه شود یا داده‌های دریافتی تعداد بایت‌های غیرمنتظره‌ای داشته باشند، بازگردانده می‌شود.
0x82	بدون رضایت کاربر	در پاسخ به درخواست نوشتن با شناسه داده 0x04 برگردانده شد: کلید هویت موقت را با رضایت کاربر بخوانید وقتی دستگاه در حالت جفت شدن نیست.

جدول 7: کدهای خطای GATT.

پارامتر بیکن را بخوانید

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

اگر تأیید ناموفق باشد، ارائه‌دهنده خطای عدم احراز هویت را برمی‌گرداند.

در صورت موفقیت، ارائه‌دهنده با پاسخی از جدول ۶ با شناسه داده 0x00 اطلاع می‌دهد. ارائه‌دهنده بخش داده را به شرح زیر می‌سازد:

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	توان کالیبره شده	توان کالیبره شده دریافتی در فاصله 0 متر (مقداری در محدوده [-100، 20]). به صورت یک عدد صحیح علامت‌دار با وضوح 1 dBm نمایش داده می‌شود.
۱ - ۴	واحد۳۲	مقدار ساعت	مقدار ساعت فعلی بر حسب ثانیه (big endian).
۵	uint8	انتخاب منحنی	منحنی بیضوی مورد استفاده برای رمزگذاری: 0x00 (پیش‌فرض): SECP160R1 0x01: SECP256R1 (نیاز به تبلیغات گسترده دارد)
۶	uint8	قطعات	تعداد اجزایی که قادر به زنگ زدن هستند: 0x00: نشان می‌دهد که دستگاه قادر به زنگ زدن نیست. 0x01: نشان می‌دهد که فقط یک قطعه قادر به زنگ زدن است. 0x02: نشان می‌دهد که دو جزء، جوانه‌های چپ و راست، قادر به زنگ زدن مستقل هستند. 0x03: نشان می‌دهد که سه جزء، هدفون‌های چپ و راست و قاب، قادر به زنگ زدن مستقل هستند.
۷	uint8	قابلیت‌های زنگ زدن	گزینه‌های پشتیبانی‌شده عبارتند از: 0x00: انتخاب میزان صدای زنگ در دسترس نیست. 0x01: انتخاب میزان صدای زنگ در دسترس است. در صورت تنظیم، ارائه دهنده باید 3 سطح صدا را همانطور که در عملیات زنگ زدن نشان داده شده است، بپذیرد و مدیریت کند.
۸-۱۵	آرایه بایتی	بالشتک	صفر لایه گذاری برای رمزگذاری AES.

داده‌ها باید با استفاده از کلید حساب کاربری که برای تأیید اعتبار درخواست استفاده شده است، به صورت AES-ECB-128 رمزگذاری شوند.

بخش احراز هویت به عنوان ۸ بایت اول HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01) تعریف می‌شود.

وضعیت آماده‌سازی بیکن را بخوانید

جستجوگر می‌تواند با انجام یک عملیات نوشتن در مشخصه شامل درخواستی از جدول ۲ با شناسه داده 0x01، از ارائه‌دهنده در مورد وضعیت تأمین بیکن پرس‌وجو کند. ارائه‌دهنده تأیید می‌کند که کلید احراز هویت یک‌بار مصرف ارائه شده با هر یک از کلیدهای حساب ذخیره شده در دستگاه مطابقت دارد.

اگر تأیید ناموفق باشد، ارائه دهنده خطای عدم احراز هویت را برمی‌گرداند.

در صورت موفقیت، ارائه‌دهنده با پاسخی از جدول ۶ با شناسه داده 0x01 اطلاع می‌دهد. ارائه‌دهنده بخش داده را به شرح زیر می‌سازد:

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	وضعیت تأمین	یک ماسک بیتی با مقادیر زیر: بیت ۱ (0x01): تنظیم می‌کند که آیا یک کلید هویت موقت برای دستگاه تنظیم شده است یا خیر. بیت ۲ (0x02): تنظیم می‌کند که آیا کلید احراز هویت یک‌بار مصرف ارائه شده با کلید حساب مالک مطابقت دارد یا خیر.
۱ - ۲۰ یا ۳۲	آرایه بایتی	شناسه موقت فعلی	۲۰ یا ۳۲ بایت (بسته به روش رمزگذاری مورد استفاده) که نشان‌دهنده‌ی شناسه‌ی موقت فعلی اعلام‌شده توسط بیکن است، البته اگر برای دستگاه تنظیم شده باشد.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	عملیات حلقه‌ای	یک ماسک بیتی با مقادیر زیر: بیت ۱ (۰x۰۱): به راست بچرخان بیت ۲ (۰x۰۲): حلقه به چپ بیت ۳ (0x04): محفظه حلقه 0xFF: حلقه زدن همه اجزا 0x00: زنگ زدن را متوقف کنید
۱ - ۲	واحد۱۶	تایم اوت	زمان انتظار بر حسب دسی‌ثانیه. نباید صفر باشد و نباید بیشتر از معادل ۱۰ دقیقه باشد. ارائه دهنده از این مقدار برای تعیین مدت زمانی که باید قبل از بی‌صدا شدن خودش زنگ بخورد استفاده می‌کند. اگر هر یک از اجزای دستگاه در حال زنگ خوردن باشد، این زمان از قبل فعال است. اگر عملیات حلقه روی 0x00 تنظیم شود، زمان انقضا نادیده گرفته می‌شود.
۳	uint8	حجم	0x00: پیش‌فرض 0x01: پایین 0x02: متوسط 0x03: بالا معنای دقیق این مقادیر به پیاده‌سازی بستگی دارد.

پس از دریافت درخواست، ارائه دهنده تأیید می‌کند که:

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

اگر ارائه‌دهنده به دلیل وجود یک چراغ FHN یا عدم موفقیت در تأیید، تأمین نشده باشد، خطای عدم احراز هویت را برمی‌گرداند. با این حال، اگر ارائه‌دهنده محافظت ردیابی ناخواسته را فعال کرده باشد و درخواست محافظت ردیابی ناخواسته‌ای که فعال شده باشد، پرچم احراز هویت رد زنگ را روشن کرده باشد، ارائه‌دهنده باید از آن بررسی صرف نظر کند. انتظار می‌رود داده‌های احراز هویت همچنان توسط جستجوگر ارائه شود، اما می‌تواند روی یک مقدار دلخواه تنظیم شود.

هنگام شروع یا پایان زنگ زدن، یک اعلان مطابق جدول 6 با شناسه داده 0x05 ارسال می‌شود. محتوای اعلان به شرح زیر تعریف می‌شود:

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	حالت زنگ زدن	0x00: شروع شد 0x01: شروع یا توقف ناموفق بود (تمام اجزای درخواستی خارج از محدوده هستند) 0x02: متوقف شد (تایم اوت شد) 0x03: متوقف شد (فشار دکمه) 0x04: متوقف شد (درخواست GATT)
۱	uint8	اجزای زنگ	یک ماسک بیتی از اجزایی که به طور فعال در حال زنگ زدن هستند، همانطور که در درخواست تعریف شده است.
۲ - ۳	واحد۱۶	تایم اوت	زمان باقی مانده برای زنگ خوردن دستگاه بر حسب دسی‌ثانیه. اگر دستگاه زنگ خوردن را متوقف کرده باشد، باید مقدار 0x0000 برگردانده شود.

بخش احراز هویت به عنوان ۸ بایت اول HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01) تعریف می‌شود.

اگر دستگاه در حالت زنگ درخواستی باشد، زمانی که درخواست زنگ خوردن یا توقف زنگ خوردن دریافت می‌شود، ارائه‌دهنده باید اعلانی با وضعیت زنگ خوردن یا به ترتیب 0x00: شروع شده یا 0x04: متوقف شده (درخواست GATT) ارسال کند. این درخواست پارامترهای وضعیت موجود را لغو می‌کند، به طوری که مدت زمان زنگ خوردن قابل تمدید است.

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

وضعیت زنگ زدن چراغ راهنما را دریافت کنید

برای دریافت وضعیت زنگ خوردن بیکن، جستجوگر یک عملیات نوشتن روی مشخصه انجام می‌دهد که شامل درخواستی از جدول ۴ با شناسه داده ۰x۰۶ است. ارائه‌دهنده تأیید می‌کند که کلید احراز هویت یک‌بار مصرف ارائه شده با کلید زنگ مطابقت دارد.

اگر ارائه‌دهنده به عنوان یک FHN beacon تأمین نشده باشد یا اگر تأیید ناموفق باشد، ارائه‌دهنده خطای عدم احراز هویت را برمی‌گرداند.

در صورت موفقیت، ارائه‌دهنده با پاسخی از جدول ۶ با شناسه داده ۰x۰۶ اطلاع می‌دهد. ارائه‌دهنده بخش داده را به شرح زیر می‌سازد:

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	اجزای زنگ	اجزا به طور فعال در حال زنگ زدن هستند، همانطور که در درخواست زنگ زدن تعریف شده است.
۱ - ۲	واحد۱۶	تایم اوت	زمان باقی مانده برای زنگ خوردن دستگاه بر حسب دسی‌ثانیه. توجه داشته باشید که اگر دستگاه زنگ نخورد، باید مقدار 0x0000 برگردانده شود.

بخش احراز هویت به عنوان ۸ بایت اول HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) تعریف می‌شود.

حالت محافظت در برابر ردیابی ناخواسته

حالت محافظت در برابر ردیابی ناخواسته به گونه‌ای طراحی شده است که به هر کلاینتی اجازه می‌دهد دستگاه‌های سوءاستفاده‌گر را بدون ارتباط با سرور شناسایی کند. به طور پیش‌فرض، ارائه‌دهنده باید تمام شناسه‌ها را همانطور که در چرخش شناسه توضیح داده شده است، بچرخاند. سرویس Find Hub می‌تواند درخواست فعال‌سازی حالت محافظت در برابر ردیابی ناخواسته را از طریق شبکه Find Hub ارسال کند. با انجام این کار، این سرویس باعث می‌شود که ارائه‌دهنده به طور موقت از یک آدرس MAC ثابت استفاده کند و به کلاینت‌ها اجازه می‌دهد دستگاه را شناسایی کرده و کاربر را از ردیابی ناخواسته احتمالی مطلع کنند.

برای فعال یا غیرفعال کردن حالت محافظت در برابر ردیابی ناخواسته‌ی بیکن، جستجوگر یک عملیات نوشتن روی مشخصه انجام می‌دهد که شامل درخواستی از جدول ۵ با شناسه داده‌ی 0x07 یا 0x08 به ترتیب است.

هنگام فعال کردن حالت محافظت در برابر ردیابی ناخواسته

ارائه دهنده، بخش داده را به صورت زیر می‌سازد:

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	پرچم‌های کنترل	0x01: رد شدن از احراز هویت زنگ. در صورت تنظیم، درخواست‌های زنگ در حالت محافظت از ردیابی ناخواسته احراز هویت نمی‌شوند. اگر هیچ پرچمی تنظیم نشده باشد (بایت‌ها همگی صفر باشند)، می‌توان بخش داده را به‌طور کامل حذف کرد و یک بخش داده خالی ارسال کرد. این پرچم‌ها فقط تا زمانی که حالت محافظت در برابر ردیابی ناخواسته غیرفعال شود، فعال هستند.

ارائه‌دهنده تأیید می‌کند که کلید احراز هویت یک‌بارمصرف ارائه‌شده با کلید محافظت ردیابی ناخواسته مطابقت دارد. اگر ارائه‌دهنده به عنوان یک چراغ FHN تأمین نشده باشد یا تأیید با شکست مواجه شود، خطای عدم احراز هویت را برمی‌گرداند.

وقتی حالت محافظت در برابر ردیابی ناخواسته فعال می‌شود، بیکن باید فرکانس چرخش آدرس خصوصی MAC را به یک بار در هر ۲۴ ساعت کاهش دهد. شناسه موقت تبلیغ‌شده باید طبق معمول به چرخش خود ادامه دهد. نوع فریم باید روی 0x41 تنظیم شود. این وضعیت همچنین در بخش پرچم‌های هش‌شده منعکس می‌شود.

هنگام غیرفعال کردن حالت محافظت در برابر ردیابی ناخواسته

ارائه دهنده تأیید می‌کند که:

کلید احراز هویت یک‌بارمصرف ارائه شده با کلید محافظت از ردیابی ناخواسته مطابقت دارد.
کلید هویت موقت هش شده با کلید هویت موقت فعلی مطابقت دارد.

اگر ارائه‌دهنده به دلیل وجود چراغ FHN آماده‌سازی نشده باشد یا تأیید با شکست مواجه شود، ارائه‌دهنده خطای عدم احراز هویت را برمی‌گرداند.

وقتی حالت محافظت در برابر ردیابی ناخواسته غیرفعال می‌شود، بیکن باید دوباره شروع به چرخاندن آدرس MAC با سرعت عادی کند، که با چرخش شناسه زودگذر هماهنگ است. نوع فریم باید به 0x40 برگردانده شود. این وضعیت همچنین در بخش پرچم‌های هش شده منعکس می‌شود.

در صورت موفقیت، ارائه‌دهنده با پاسخی از جدول ۶ با شناسه داده 0x07 یا 0x08 اطلاع می‌دهد.

بخش احراز هویت به عنوان ۸ بایت اول HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) تعریف می‌شود.

دقت در یافتن

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

نوع دقت یابی به نوع فناوری‌های مسافت‌یابی پشتیبانی‌شده در دستگاه‌های درگیر در دقت یابی بستگی دارد. فناوری‌های مسافت‌یابی پشتیبانی‌شده را می‌توان در مشخصات توالی پیام و بار مفید در بخش مسافت‌یابی: خارج از باند یافت. بخش‌های بعدی بررسی می‌کنند که چه نوع تجربه دقت یابی را می‌توان بر اساس فناوری مسافت‌یابی مورد استفاده انتظار داشت.

جریان دقیق یافتن

این بخش به بررسی جریان پیام FHNA برای Precision Finding می‌پردازد. شکل 1 جریان پیام‌ها را نشان می‌دهد و پاراگراف‌ها هر پیام را با جزئیات بیشتری توضیح می‌دهند.

جریان پیام جستجوی دقیق

شکل 1. جریان پیام جستجوی دقیق معمول

دستگاه آغازگر، دستگاهی است که برنامه Find Hub روی آن نصب شده و قابلیت Precision Finding از آنجا فعال شده است. آغازگر، دستگاهی است که سعی در یافتن دستگاه دیگر دارد.

دستگاه پاسخ‌دهنده (Responder) دستگاهی است که سعی دارد توسط دستگاه آغازگر (Initiator) پیدا شود.

دستگاه آغازگر یک پیام درخواست قابلیت ردیابی به دستگاه پاسخ‌دهنده ارسال می‌کند که در آن فهرستی از فناوری‌های ردیابی که علاقه‌مند به کسب اطلاعات در مورد آنها از دستگاه پاسخ‌دهنده است، ارائه می‌شود. دستگاه پاسخ‌دهنده با اعلان پاسخ قابلیت ردیابی پاسخ می‌دهد که حاوی اطلاعاتی در مورد فناوری‌های ردیابی پشتیبانی‌شده و قابلیت‌های آنهاست. پاسخ‌دهنده فقط اطلاعاتی را که آغازگر درخواست کرده است، در بر می‌گیرد. فهرست قابلیت‌ها بر اساس اولویت فناوری ردیابی مورد علاقه دستگاه پاسخ‌دهنده مرتب می‌شود و اولین مورد در لیست بالاترین اولویت را دارد.

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

زمانی که دستگاه آغازگر آماده‌ی توقف جلسه‌ی «یافتن دقیق» شد، یک پیام «توقف اندازه‌گیری» به پاسخ‌دهنده ارسال می‌کند که نشان می‌دهد کدام فناوری‌های اندازه‌گیری باید اندازه‌گیری را متوقف کنند. دستگاه پاسخ‌دهنده با یک اعلان «پاسخ توقف اندازه‌گیری» پاسخ می‌دهد که نشان می‌دهد با موفقیت اندازه‌گیری را با فناوری‌های اندازه‌گیری درخواستی متوقف کرده است.

در مورد قطع شدن کانال ارتباطی FHNA BLE GATT در اواسط جلسه Precision Finding، اما در حالی که برخی از فناوری‌های مسافت‌یابی هنوز در حال مسافت‌یابی هستند، دستگاه پاسخ‌دهنده یک مکانیسم مهلت زمانی را پیاده‌سازی می‌کند تا اطمینان حاصل شود که مسافت‌یابی آن به طور نامحدود ادامه نمی‌یابد. جزئیات به هر مورد استفاده بستگی دارد.

توجه داشته باشید، دستگاه پاسخ‌دهنده نباید فرض کند که ترتیب عملیات همیشه یکسان خواهد بود. به عنوان مثال، دستگاه پاسخ‌دهنده باید بتواند چندین عملیات درخواست قابلیت تعیین محدوده را پشت سر هم انجام دهد، یا حتی یک عملیات پیکربندی تعیین محدوده را مستقیماً بدون درخواست قابلیت قبلی انجام دهد.

عملیات دقیق یابی

جدول ۸ عملیات FHNA تعریف‌شده توسط این سند را که برای یافتن دقیق مورد نیاز هستند، نشان می‌دهد. هر زیربخش، پیام FHNA را برای هر یک از عملیات تعریف می‌کند، در حالی که محتوای فیلد داده‌های اضافی به تعیین محدوده: توالی پیام خارج از باند و مشخصات بار مفید اشاره دارد.

عملیات	شناسه داده	توضیحات
درخواست قابلیت مسافت‌یابی	0x0A	عملیات درخواست قابلیت که توسط دستگاه آغازگر به دستگاه پاسخ‌دهنده ارسال می‌شود. محتوای داده‌های این عملیات، تمام فناوری‌های بردی را که آغازگر می‌خواهد از دستگاه پاسخ‌دهنده در مورد آنها اطلاعات کسب کند، فهرست می‌کند.
قابلیت ردیابی پاسخ	0x0A	این پاسخ اعلان به عملیات درخواست قابلیت مسافت‌یابی است. این شامل اطلاعاتی در مورد قابلیت‌های هر فناوری مسافت‌یابی پشتیبانی‌شده است که توسط آغازگر درخواست شده است.
پیکربندی محدوده	0x0B	عملیات پیکربندی مسافت‌یابی شامل پیکربندی‌هایی برای فناوری‌های مسافت‌یابی است که دستگاه آغازگر می‌خواهد مسافت‌یابی را با دستگاه پاسخ‌دهنده آغاز کند.
پاسخ پیکربندی محدوده	0x0B	این پاسخ اعلان به عملیات پیکربندی مسافت‌یابی است. این شامل داده‌هایی در مورد اینکه آیا دستگاه پاسخ‌دهنده با موفقیت مسافت‌یابی را با فناوری‌های مسافت‌یابی درخواستی بر اساس پیکربندی ارائه شده آغاز کرده است یا خیر، می‌باشد.
آر اف یو	0x0C	عملیاتی که با این شناسه داده انجام می‌شود، استفاده نمی‌شود و برای استفاده‌های بعدی رزرو شده است.
توقف محدوده‌یابی	0x0D	عملیات توقف مسافت‌یابی که توسط دستگاه آغازگر ارسال می‌شود، حاوی اطلاعاتی در مورد فناوری‌های مسافت‌یابی است که دستگاه پاسخ‌دهنده باید مسافت‌یابی را با آنها متوقف کند.
پاسخ توقف محدوده‌یابی	0x0D	این پاسخ اعلان به عملیات توقف مسافت‌یابی است. این شامل داده‌هایی است که آیا عملیات توقف برای فناوری مسافت‌یابی خاص موفقیت‌آمیز بوده است یا خیر.

جدول ۸: عملیات دقیق یافتن.

عملیات درخواست قابلیت مسافت‌یابی

جدول 9 پیام درخواست قابلیت تعیین محدوده را تعریف می‌کند.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x0A - عملیات درخواست قابلیت مسافت‌یابی
۱	uint8	طول داده	متغیر است
۲	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول HMAC-SHA256 (کلید حساب، شماره نسخه اصلی پروتکل \|\| آخرین nonce خوانده شده از مشخصه \|\| شناسه داده \|\| طول داده \|\| داده‌های اضافی).
۱۰	آرایه بایتی	داده‌های اضافی	پیام درخواست قابلیت محدوده‌بندی ، همانطور که در مشخصات دنباله پیام و بار مفید خارج از باند (هم سرآیند و هم بار مفید) تعریف شده است.

جدول ۹: درخواست قابلیت مسافت‌یابی.

قابلیت مسافت‌یابی عملیات واکنش

جدول 10 پیام پاسخ قابلیت مسافت‌یابی را تعریف می‌کند.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x0A: پاسخ قابلیت مسافت‌یابی
۱	uint8	طول داده	متغیر است
۲	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول HMAC-SHA256 (کلید حساب، شماره نسخه اصلی پروتکل \|\| آخرین nonce خوانده شده از مشخصه \|\| شناسه داده \|\| طول داده \|\| داده‌های اضافی \|\| 0x01).
۱۰	آرایه بایتی	داده‌های اضافی	پیام پاسخ قابلیت مسافت‌یابی، همانطور که در مشخصات توالی و بار مفید پیام مسافت‌یابی: خارج از باند (هم سرآیند و هم بار مفید) تعریف شده است.

جدول 10: پاسخ قابلیت مسافت‌یابی.

عملیات پیکربندی محدوده‌بندی

جدول 11 پیام پیکربندی محدوده‌بندی را تعریف می‌کند.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x0B - تنظیم پیکربندی محدوده
۱	uint8	طول داده	متغیر است
۲	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول HMAC-SHA256 (کلید حساب، شماره نسخه اصلی پروتکل \|\| آخرین nonce خوانده شده از مشخصه \|\| شناسه داده \|\| طول داده \|\| داده‌های اضافی).
۱۰	آرایه بایتی	داده‌های اضافی	پیام پیکربندی محدوده‌بندی همانطور که در مشخصات توالی و بار داده پیام محدوده‌بندی: خارج از باند (هم سرآیند و هم بار داده) تعریف شده است

جدول 11: پیکربندی محدوده.

عملیات پاسخ پیکربندی محدوده‌بندی

جدول ۱۲ پیام پاسخ پیکربندی محدوده‌بندی را تعریف می‌کند.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x0B - پاسخ پیکربندی تنظیم محدوده
۱	uint8	طول داده	متغیر است
۲	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول HMAC-SHA256 (کلید حساب، شماره نسخه اصلی پروتکل \|\| آخرین nonce خوانده شده از مشخصه \|\| شناسه داده \|\| طول داده \|\| داده‌های اضافی \|\| 0x01).
۱۰	آرایه بایتی	داده‌های اضافی	پیام پاسخ پیکربندی محدوده‌بندی همانطور که در مشخصات توالی و بار داده پیام محدوده‌بندی: خارج از باند (هم سرآیند و هم بار داده) تعریف شده است.

جدول ۱۲: پاسخ پیکربندی محدوده‌بندی.

عملیات مسافت‌یابی را متوقف کنید

جدول ۱۳ پیام توقف اندازه‌گیری محدوده را تعریف می‌کند.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x0D - توقف مسافت
۱	uint8	طول داده	متغیر است
۲	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول HMAC-SHA256 (کلید حساب، شماره نسخه اصلی پروتکل \|\| آخرین nonce خوانده شده از مشخصه \|\| شناسه داده \|\| طول داده).
۱۰	آرایه بایتی	داده‌های اضافی	پیام توقف محدوده‌یابی، همانطور که در مشخصات توالی و بار داده پیام محدوده‌یابی: خارج از باند (هم سرآیند و هم بار داده) تعریف شده است.

جدول ۱۳: توقف اندازه‌گیری محدوده.

عملیات پاسخ محدوده‌یابی را متوقف کنید

جدول ۱۴ پیام پاسخ توقف اندازه‌گیری محدوده را تعریف می‌کند.

هشت‌تایی	نوع داده	توضیحات	ارزش
0	uint8	شناسه داده	0x0D - پاسخ توقف مسافت‌سنجی
۱	uint8	طول داده	متغیر است
۲	آرایه بایتی	کلید احراز هویت یکبار مصرف	۸ بایت اول HMAC-SHA256 (کلید حساب، شماره نسخه اصلی پروتکل \|\| آخرین nonce خوانده شده از مشخصه \|\| شناسه داده \|\| طول داده \|\| داده‌های اضافی \|\| 0x01).
۱۰	آرایه بایتی	داده‌های اضافی	پیام پاسخ Stop Rangeing همانطور که در مشخصات دنباله و بار داده پیام Rangeing: Out-of-band و Payload (هم هدر و هم Payload) تعریف شده است.

جدول ۱۴: پاسخ توقف اندازه‌گیری محدوده.

محافظت در برابر ردیابی ناخواسته با قابلیت جستجوی دقیق

وقتی حالت محافظت در برابر ردیابی ناخواسته فعال می‌شود، همانطور که در بخش محافظت در برابر ردیابی ناخواسته توضیح داده شده است، همان روندی که برای نادیده گرفتن بررسی‌های احراز هویت برای پیام‌های در حال زنگ خوردن اعمال می‌شود، برای همه پیام‌های Precision Finding تعریف شده در این سند برای دستگاه‌هایی که می‌خواهند از این ویژگی پشتیبانی کنند، نیز اعمال می‌شود.

ویژگی‌های فناوری مسافت‌یابی برای یافتن دقیق

این بخش شامل جزئیاتی است که مربوط به فناوری‌های خاص هستند.

مشخصات فوق پهن‌باند (UWB)

جزئیات خاص UWB.

سطح دقت یافته

جلسات جستجوی دقیق با استفاده از UWB به عنوان فناوری مسافت‌یابی می‌توانند انتظار داشته باشند که هم اطلاعات فاصله و هم اطلاعات جهت را مشاهده کنند. فاصله مسافت‌یابی باید حداقل ۲۴۰ میلی‌ثانیه باشد و ۹۶ میلی‌ثانیه برای هدایت بهینه ترجیح داده می‌شود.

شناسه‌های پیکربندی

Out-of-band configuration data exchanged for UWB doesn't contain a full set of available configurable parameters that UWB requires to start an UWB ranging session. Some parameters are implicitly selected by the chosen config Id.

Each config Id is a set of predefined UWB configuration parameters that is publicly documented . For the Precision Finding use case, the responder device must support config Id 6 , and optionally config Id 3 .

UWB Initiator and Responder

For the Precision Finding use case, the device noted as the Initiator device in this document will be the UWB responder, and the device noted as the Responder device in this document will be the UWB initiator. This is because the UWB initiator device consumes less power than UWB responder does, and in most cases the Responder device will be a peripheral with limited battery.

This means that the Responder device needs to indicate that it supports being a UWB initiator role in the Ranging Capability Response message.

Other UWB related parameters

Channel 9 must be supported
For optimal guidance, a 96ms ranging interval is recommended, otherwise 240ms must be supported.
Slot duration of 1ms is recommended for battery savings, but 2ms is also supported.
The UWB chip must be at least FIRA v1.2 + P-STS compliant.
BPRF is mandatory, HPRF is recommended but optional. The supported or selected mode is determined by the supported or selected preamble index.
Session security type: P-STS

BLE Channel Sounding (CS) specifics

BLE CS specific details.

Precision Finding level

Precision Finding sessions using CS as the ranging technology will cause distance only measurements, directionality is not provided at this moment.

Required bond between devices

Precision Finding sessions using Channel Sounding won't work if devices are not bonded. An existing bond between the initiator and the responder device is required. This specification does not provide a way for creating a bond between the devices. Instead, it is up to the developer of the use case to establish this bond between the devices.

Action required by the responder side for CS

Unlike UWB, where both devices are required to call the UWB start ranging and stop ranging API explicitly, for CS, only the initiator device is required to start CS ranging by calling the Bluetooth stack, the rest of the initialization on the responder side happens in-band using Bluetooth (BT). This means that upon receiving the Ranging Configuration message or the Stop Ranging message for CS, the responder side doesn't have to do anything if BT is enabled, other than reply with the Ranging Configuration Response message notification. The responder device could potentially use those messages as a trigger to update the UI where a screen is present, or regardless of having a screen it could be used for visual feedback on the devices state, for example blink the device LEDs.

Wi-Fi NAN RTT

Wi-Fi NAN RTT specific details.

Precision Finding level

Precision Finding sessions using Wi-Fi NAN RTT as the ranging technology will cause distance only measurements, directionality is not provided at this moment.

BLE RSSI

BLE RSSI specific details.

Precision Finding level

Precision Finding sessions using only BLE RSSI as the ranging technology won't be able to get either the distance or the direction information, due to BLE RSSI not being an accurate ranging technology. Instead, the user will see guidance indicating that device is close or device is far.

Advertised frames

After provisioning, the Provider is expected to advertise FHN frames at least once every 2 seconds. If Fast Pair frames are advertised, the Provider should interleave the FHN frames within the regular Fast Pair advertisements. For example, every two seconds, the Provider should advertise seven Fast Pair advertisements and one FHN advertisement.

The conducted Bluetooth transmit power for FHN advertisements should be set to at least 0 dBm.

The FHN frame carries a public key used to encrypt location reports by any supporting client that contributes to the crowdsourcing network. Two types of elliptic curve keys are available: a 160-bit key that fits legacy BLE 4 frames, or 256-bit key that requires BLE 5 with extended advertising capabilities. The Provider's implementation determines which curve is used.

An FHN frame is structured as follows.

Octet	ارزش	توضیحات
0	0x02	طول
۱	0x01	Flags data type value
۲	0x06	Flags data
۳	0x18 or 0x19	طول
۴	0x16	Service data data type value
۵	0xAA	16-bit service UUID
۶	0xFE	...
۷	0x40 or 0x41	FHN frame type with unwanted tracking protection mode indication
8..27		20-byte ephemeral identifier
۲۸		Hashed flags

Table 15: FHN frame supporting a 160-bit curve.

Table 16 shows the byte offsets and values for a 256-bit curve.

Octet	ارزش	توضیحات
0	0x02	طول
۱	0x01	Flags data type value
۲	0x06	Flags data
۳	0x24 or 0x25	طول
۴	0x16	Service data data type value
۵	0xAA	16-bit service UUID
۶	0xFE	...
۷	0x40 or 0x41	FHN frame type with unwanted tracking protection mode indication
8..39		32-byte ephemeral identifier
۴۰		Hashed flags

Table 16: FHN frame supporting a 256-bit curve.

Ephemeral identifier (EID) computation

A random is generated by AES-ECB-256 encrypting the following data structure with the ephemeral identity key:

Octet	میدان	توضیحات
0 - 10	بالشتک	Value = 0xFF
۱۱	ک	Rotation period exponent
12 - 15	TS[0]...TS[3]	Beacon time counter, in 32-bit big-endian format. The K lowest bits are cleared.
16 - 26	بالشتک	Value = 0x00
۲۷	ک	Rotation period exponent
28 - 31	TS[0]...TS[3]	Beacon time counter, in 32-bit big-endian format. The K lowest bits are cleared.

Table 17: Construction of a pseudorandom number.

The result of this computation is a 256-bit number, denoted r' .

For the rest of the calculation, SECP160R1 or SECP256R1 are used for elliptic curve cryptographic operations. See curve definitions in SEC 2: Recommended Elliptic Curve Domain Parameters , which defines Fp , n and G referenced next.

r' is now projected to the finite field Fp by calculating r = r' mod n . Finally, compute R = r * G , which is a point on the curve representing the public key being used. The beacon advertises Rx , which is the x coordinate of R , as its ephemeral identifier.

Hashed flags

The hashed flags field is calculated as follows (bits are referenced from most significant to least significant):

Bits 0-4: Reserved (set to zeros).
Bits 5-6 indicates the battery level for the device as follows:
- 00: Battery level indication unsupported
- 01: Normal battery level
- 10: Low battery level
- 11: Critically low battery level (battery replacement needed soon)
Bit 7 is set to 1 if the beacon is in unwanted tracking protection mode, and 0 otherwise.

To produce the final value of this byte, it is xor-ed with the least significant byte of SHA256(r) .

Note that r should be aligned to the curve's size. Add zeros as most significant bits if its representation is shorter than 160 or 256 bits, or the most significant bits should be truncated if its representation is larger than 160 or 256 bits.

If the beacon doesn't support battery level indication, and isn't in unwanted tracking protection mode, it's allowed to omit this byte entirely from the advertisement.

Encryption with EID

To encrypt a message m , a sighter (having read Rx from the beacon) would do the following:

Choose a random number s in Fp , as defined in the EID computation section.
Compute S = s * G .
Compute R = (Rx, Ry) by substitution in the curve equation and picking an arbitrary Ry value out of the possible results.
Compute the 256-bit AES key k = HKDF-SHA256((s * R)x) where (s * R)x is the x coordinate of the curve multiplication result. Salt isn't specified.
Let URx and LRx be the upper and lower 80-bits of Rx , respectively, in big-endian format. In a similar way, define USx and LSx for S .
Compute nonce = LRx || LSx .
Compute (m', tag) = AES-EAX-256-ENC(k, nonce, m) .
Send (URx, Sx, m', tag) to the owner, possibly through an untrusted remote service.

Decryption of values encrypted with EID

The owner's client, which is in possession of the EIK and the rotation period exponent, decrypts the message as follows:

Given URx , obtain the beacon time counter value on which URx is based. This can be done by the owner's client computing Rx values for beacon time counter values for the recent past and near future.
Given the beacon time counter value on which URx is based, compute the anticipated value of r as defined in the EID computation section.
Compute R = r * G , and verify a match to the value of URx provided by the sighter.
Compute S = (Sx, Sy) by substitution in the curve equation and picking an arbitrary Sy value out of the possible results.
Compute k = HKDF-SHA256((r * S)x) where (r * S)x is the x coordinate of the curve multiplication result.
Compute nonce = LRx || LSx .
Compute m = AES-EAX-256-DEC(k, nonce, m', tag) .

ID rotation

A resolvable (RPA) or non-resolvable (NRPA) BLE address must be used for advertising FHN frames. RPA is required for LE Audio (LEA) devices and is recommended for other devices, with the exception of locator tags that don't use bonding.

Fast Pair advertisement, FHN advertisement and the corresponding BLE address(es) should rotate at the same time. Rotation should happen every 1024 seconds on average. The precise point at which the beacon starts advertising the new identifier must be randomized within the window.

The recommended approach to randomize the rotation time is to set it to the next anticipated rotation time (if no randomization was applied) plus a positive randomized time factor in the range of 1 to 204 seconds.

When the device is in unwanted tracking protection mode, the BLE address of the FHN advertisement should be fixed, but the RPA for FP non-discoverable advertisement (such as Fast Pair) must keep rotating. It's acceptable to use different addresses for the different protocols.

Recovery from power loss

Resolving the ephemeral identifier is strongly tied to its clock value at the time of the advertisement, so it's important that the Provider can recover its clock value if there's a power loss. It is recommend that the Provider writes its current clock value to nonvolatile memory at least once per day, and that at boot time the Provider checks the NVM to see if there's a value present from which to initialize. Resolvers of the ephemeral identifier would implement resolution over a time window sufficient to allow for both reasonable clock drift and this type of power loss recovery.

Providers should still make all efforts to minimize clock drifts, as the resolution time window is limited. At least one additional clock synchronization method should be implemented (advertising non-discoverable Fast Pair frames or implementing the message stream ).

Fast Pair implementation guidelines

This section describes special aspects of the Fast Pair implementation on Providers that support FHN.

Locator tag specific guidelines

If the Provider was paired, but FHN wasn't provisioned within 5 minutes (or if an OTA update was applied while the device is paired but not FHN-provisioned), the Provider should revert to its factory configuration and clear the stored account keys.
After the Provider is paired, it shouldn't change its MAC address until FHN is provisioned or until 5 minutes pass.
If the ephemeral identity key is cleared from the device, the device should perform a factory reset and clear the stored account keys as well.
The Provider should reject normal Bluetooth pairing attempts and accept only Fast Pair pairing.
The Provider must include a mechanism that lets users temporarily stop advertising without factory resetting the device (for example, pressing a combination of buttons).
After a power loss, the device should advertise non-discoverable Fast Pair frames until the next invocation of read beacon parameters . This lets the Seeker detect the device and synchronize the clock even if a significant clock drift occurred.
When advertising non-discoverable Fast Pair frames, UI indications shouldn't be enabled.
Discoverable Fast Pair frames shouldn't be advertised while the Provider is provisioned for FHN.
The Provider shouldn't expose any identifying information information in an unauthenticated manner (eg names or identifiers).

Classic Bluetooth device-specific guidelines

This section describes special aspects of classic Bluetooth devices that support FHN.

FHN provisioning of already paired devices

The Provider isn't always provisioned for FHN when pairing with the Seeker, but a while after that. In that case, the Provider might not have an up-to-date BLE MAC address that's required to establish a GATT connection. The Provider must support at least one of the following ways for the Seeker to get its BLE address while it's already paired:

The Provider can periodically advertise the Fast Pair account data that lets the Seeker find its BLE address through a BLE scan.
This approach suits Providers that don't implement the message stream.
The Provider can provide this data through the Fast Pair message stream over classic Bluetooth.
This approach suits Providers that don't advertise Fast Pair frames while connected to the Seeker over Bluetooth.

Supporting both approaches increases the chances that the user can provision the device for FHN.

Fast Pair message stream

The Provider can implement Fast Pair message stream and use it to notify the Seeker about Device information . Implementing the message stream enables certain features as described in this section.

The Provider should send device information messages once every time the message stream RFCOMM channel is established.

Firmware version (device information code 0x09) and the tracking capability

When a firmware update adds FHN support to the Provider, a connected Seeker can notify the user about that and offer to provision it. Otherwise, the user has to navigate to the Bluetooth device list manually to initiate FHN provisioning.

To allow that, the Provider should use the Firmware version property (code 0x09) to report a string value that represents the firmware version. In addition, the Provider should support the protocol that lets the Seeker know about Capability changes due to firmware updates.

Octet	نوع داده	توضیحات	ارزش
0	uint8	Device information event	0x03
۱	uint8	Firmware version	0x09
۲ - ۳	uint16	Additional data length	متغیر است
متغیر	byte array	Version string	متغیر است

Table 18: Device information event: updated firmware version.

Upon receiving a capability update request (0x0601), if the Provider has enabled support for FHN tracking, it should respond as shown in table 12.

Octet	نوع داده	توضیحات	ارزش
0	uint8	Device capability sync event	0x06
۱	uint8	FHN tracking	0x03
۲ - ۳	uint16	Additional data length	0x0007
۴	uint8	FHN provisioning state	0x00 if unprovisioned; 0x01 if provisioned by any account
5 - 10	byte array	The current BLE MAC address of the device	متغیر است

Table 19: Device capability sync event: added tracking capability.

Current ephemeral identifier (device information code 0x0B)

The Provider can use the current ephemeral identifier (code 0x0B) to report the current EID and clock value when the Provider is provisioned for FHN, to sync the Seeker in case of a clock drift (for example, due to drained battery). Otherwise, the Seeker initiates a more expensive and less reliable connection for this purpose.

Octet	نوع داده	توضیحات	ارزش
0	uint8	Device information event	0x03
۱	uint8	Current ephemeral identifier	0x0B
۲ - ۳	uint16	Additional data length	0x0018 or 0x0024
4 - 7	byte array	Clock value	Example: 0x13F9EA80
8 - 19 or 31	byte array	Current EID	Example: 0x1122334455667788990011223344556677889900

Table 20: Device information event: clock sync.

Factory reset

For devices that support factory reset: if a factory reset is performed, the Provider must stop beaconing and wipe out the ephemeral identity key and all stored account keys, including the owner's account key.

After a factory reset (either manual or programmatic), the Provider shouldn't start advertising Fast Pair right away, to prevent the pairing flow to start immediately after the user deletes the device.

Unwanted tracking prevention

Certified FHN devices must also meet the requirements in the implementation version of the cross-platform specification for Detecting Unwanted Location Trackers (DULT).

Relevant guidelines specific to FHN to be compliant with DULT spec:

Any FHN compatible device must be registered in the Nearby Device Console, and have the "Find Hub" capability activated.
The device must implement the Accessory Non-Owner service and characteristic defined in the implementation version of the DULT spec, including the Accessory Information operations and Non-owner controls .
During the backward compatibility period, as defined in the DULT spec, there are no changes to the advertised frame as defined in this document.
"Unwanted tracking protection mode" defined in this document maps to the "separated state" defined by the DULT spec.
Guidelines for implementing the Accessory Information opcodes:
- Get_Product_Data should return the model ID provided by the console, zero padded to fit the 8-byte requirement. For example, model ID 0xFFFFFF is returned as 0x0000000000FFFFFF.
- Get_Manufacturer_Name and Get_Model_Name should match the values provided in the console.
- Get_Accessory_Category can return the generic "Location Tracker" value if no other category better fits the type of the device.
- Get_Accessory_Capabilities must indicate the support for ringing as well as BLE identifier lookup.
- Get_Network_ID should return Google's identifier (0x02).
Guidelines for implementing the Get_Identifier opcode:
- The operation should only return a valid response for 5 minutes after the user activated the 'identification' mode, which requires a combination of button presses. A visual or audio signal should indicate to the user that the provider entered that mode. The model-specific instructions for activating that mode must be provided to Google as a requirement for certification and at least 10 days prior to any update or modification to the instructions.
- The response is constructed as: the first 10 bytes of current ephemeral identifier, followed by the first 8 bytes of HMAC-SHA256(recovery key, the truncated current ephemeral identifier) .
Guidelines for implementing Identifier over NFC:
- As a URL, use find-my.googleapis.com/lookup .
- As the e parameter, use the same response as constructed for Get_Identifier , hex encoded.
- As the pid parameter, use the same response as constructed for Get_Product_Data , hex encoded.
It is mandatory for the device to include a sound maker and support the ringing function. Per the DULT spec, the sound maker must emit a sound with minimum 60 Phon peak loudness as defined by ISO 532-1:2017.
Guidelines for implementing the Sound_Start opcode:
- The command should trigger ringing in all available components.
- The maximal supported volume should be used.
- The recommended duration for ringing is 12 seconds.
Locator tags must include a mechanism that lets users temporarily stop advertising without factory resetting the device (for example, pressing a combination of buttons).
- The disablement instructions must be documented in a publicly available URL and provided to Google as a requirement for certification and at least 10 days prior to any update or modification to the instructions.
- The URL should support localization. Depending on the client, the language will be provided either as a query param ("hl=en") or using the "accept-language" HTTP header.

Switchable protocol guidelines

Only one protocol should be used at a time. Ensure that no more than one network can operate on the device simultaneously. This requirement is needed to ensure that there is no commingling of sensitive user data between varying protocols.
It is suggested to incorporate a hard reset workflow into the device that allows a user to re-setup a device with a different network.
The process of updating a device to a network should be user friendly and equitable between networks. A user must be able to choose which network they want to use without giving preference to one of the networks. This flow needs to be approved by the Google team.

به‌روزرسانی‌های میان‌افزار

The process and distribution of OTA updates should be managed by the partner using their own Mobile or Web app workflow.

Fast Pair supports delivering notifications to the user, informing of available OTA updates. In order to use this mechanism:

The latest firmware version should be updated in the Nearby Device Console.
A companion App should be set in the Nearby Device Console. It should support the firmware update intent .
Provider should implement the Firmware revision GATT characteristic.

To prevent tracking, access to the Firmware revision characteristic should be restricted. Seeker will first read the provisioning state and provide an authentication key, as defined in this specification, and only then read the firmware revision. This will be done over the same connection. If an attempt is made to read the firmware revision, and the Provider isn't bonded nor an authenticated operation was successfully completed over that same connection, the Provider should return an unauthenticated error.

سازگاری

Find Hub network requires location services and Bluetooth to be turned on. Requires cell service or internet connection. Works on Android 9+ and in certain countries for age-eligible users.

تغییرات

FHN Version	تاریخ	نظر دهید
نسخه ۱		Initial release of the FHN spec for early access.
نسخه ۱.۱	فوریه ۲۰۲۳	Added a cleartext indication of unwanted tracking protection mode. Added an option to skip authentication of ringing requests while in unwanted tracking protection mode.
نسخه ۱.۲	آوریل ۲۰۲۳	Updated the definition of an owner's AK. Added a recommendation for recovering from power loss in locator tags. Added a clarification for MAC address randomization. Added a clarification on MAC address rotation while in unwanted tracking protection mode. Added a guideline on having a way to deactivate a locator tag.
نسخه ۱.۳	دسامبر ۲۰۲۳	Added a clarification on identifying information exposed by locator tags. Added a requirement to implement the unwanted tracking prevention specification. Added guidelines for switchable protocol devices.