হাব নেটওয়ার্ক অ্যাক্সেসরি স্পেসিফিকেশন খুঁজুন, হাব নেটওয়ার্ক অ্যাক্সেসরি স্পেসিফিকেশন খুঁজুন, হাব নেটওয়ার্ক অ্যাক্সেসরি স্পেসিফিকেশন খুঁজুন, হাব নেটওয়ার্ক অ্যাক্সেসরি স্পেসিফিকেশন খুঁজুন

v1.3

ফাইন্ড হাব নেটওয়ার্ক (FHN) অ্যাকসেসরি স্পেসিফিকেশনটি বিকনিং ব্লুটুথ লো এনার্জি (BLE) ডিভাইস ট্র্যাক করার জন্য একটি এন্ড-টু-এন্ড এনক্রিপ্টেড পদ্ধতি সংজ্ঞায়িত করে। এই পৃষ্ঠাটি ফাস্ট পেয়ার স্পেসিফিকেশনের একটি এক্সটেনশন হিসেবে FHN-কে বর্ণনা করে। প্রোভাইডারদের এই এক্সটেনশনটি সক্রিয় করা উচিত, যদি তাদের কাছে FHN-এর সাথে সামঞ্জস্যপূর্ণ ডিভাইস থাকে এবং তারা সেই ডিভাইসগুলির জন্য লোকেশন ট্র্যাকিং চালু করতে ইচ্ছুক হন।

গ্যাট স্পেসিফিকেশন

নিম্নলিখিত অর্থসহ ফাস্ট পেয়ার সার্ভিসে একটি অতিরিক্ত জেনেরিক অ্যাট্রিবিউট (GATT) বৈশিষ্ট্য যোগ করা উচিত:

সারণি ১: এফএইচএন-এর ফাস্ট পেয়ার সার্ভিসের বৈশিষ্ট্যসমূহ।

প্রমাণীকরণ

এই এক্সটেনশনের জন্য প্রয়োজনীয় অপারেশনগুলো একটি রাইট অপারেশন হিসেবে সম্পাদিত হয়, যা একটি চ্যালেঞ্জ-রেসপন্স মেকানিজম দ্বারা সুরক্ষিত। যেকোনো অপারেশন সম্পাদন করার আগে, সিকারের কাছ থেকে টেবিল ১-এর ক্যারেক্টারিস্টিক থেকে একটি রিড অপারেশন সম্পাদন করার প্রত্যাশা করা হয়, যার ফলে নিম্নলিখিত ফরম্যাটে একটি বাফার তৈরি হয়:

প্রতিটি রিড অপারেশনের ফলে একটি ভিন্ন ননস তৈরি হবে এবং একটি ননস শুধুমাত্র একটি অপারেশনের জন্যই বৈধ থাকবে। অপারেশনটি ব্যর্থ হলেও ননসটি অবশ্যই বাতিল করতে হবে।

এরপর সিকার পরবর্তী রাইট রিকোয়েস্টে ব্যবহারের জন্য একটি ওয়ান-টাইম অথেন্টিকেশন কী গণনা করে। টেবিল ২ থেকে ৫-এ বর্ণিত পদ্ধতি অনুসারে অথেন্টিকেশন কী-টি গণনা করা হয়। অনুরোধকৃত অপারেশনের উপর নির্ভর করে, সিকার নিম্নলিখিত এক বা একাধিক কী সম্পর্কে তার জ্ঞান প্রমাণ করে:

• অ্যাকাউন্ট কী : ফাস্ট পেয়ার স্পেসিফিকেশনে সংজ্ঞায়িত ১৬-বাইট ফাস্ট পেয়ার অ্যাকাউন্ট কী।

• মালিক অ্যাকাউন্ট কী : যখন কোনো সিকার প্রথমবারের মতো বিকন অ্যাকশনস ক্যারেক্টারিস্টিক অ্যাক্সেস করে, তখন প্রোভাইডার বিদ্যমান অ্যাকাউন্ট কীগুলোর মধ্যে থেকে একটিকে মালিক অ্যাকাউন্ট কী হিসেবে বেছে নেয়। প্রোভাইডারকে ফ্যাক্টরি রিসেট না করা পর্যন্ত নির্বাচিত মালিক অ্যাকাউন্ট কী পরিবর্তন করা যাবে না। প্রোভাইডারের কাছে খালি অ্যাকাউন্ট কী স্লট শেষ হয়ে গেলেও সে মালিক অ্যাকাউন্ট কীটি সরাতে পারবে না ।

  • যেসব প্রোভাইডার প্রথমবার পেয়ার করার সময় (অথবা ফ্যাক্টরি রিসেটের পর পেয়ার করার সময়) আগে থেকেই FHN সাপোর্ট করে, তারা প্রথম অ্যাকাউন্ট কী-টি বেছে নেয়, কারণ পেয়ারিংয়ের সময় সিকার যখন প্রোভিশনিং স্টেট পড়ে, তখন এটিই একমাত্র বিদ্যমান অ্যাকাউন্ট কী থাকে।

  • যেসব প্রোভাইডার ইতিমধ্যে পেয়ার করা থাকার পর FHN সাপোর্ট পায় (উদাহরণস্বরূপ, একটি ফার্মওয়্যার আপডেটের মাধ্যমে), তারা যেকোনো বিদ্যমান অ্যাকাউন্ট কী বেছে নিতে পারে। ফার্মওয়্যার আপডেটের পর বীকন অ্যাকশন ক্যারেক্টারিস্টিক থেকে প্রোভিশনিং স্টেট পড়ার জন্য ব্যবহৃত প্রথম অ্যাকাউন্ট কী-টি বেছে নেওয়াই যুক্তিসঙ্গত, এই শর্তে যে যিনি আপডেটটি করেছেন তিনিই প্রোভাইডারটির বর্তমান মালিক।

• ক্ষণস্থায়ী পরিচয় কী (EIK) : এটি একটি ৩২-বাইটের কী যা সিকার (Seeker) এফএইচএন (FHN) প্রোভিশনিং প্রক্রিয়া সম্পাদনের সময় দৈবচয়নের মাধ্যমে বেছে নেয়। এই কী-টি ক্রিপ্টোগ্রাফিক কী তৈরি করতে ব্যবহৃত হয়, যা লোকেশন রিপোর্ট এন্ড-টু-এন্ড এনক্রিপ্ট করার জন্য ব্যবহৃত হয়। সিকার এটি কখনোই ব্যাকএন্ডের কাছে প্রকাশ করে না।

• রিকভারি কী : SHA256(ephemeral identity key || 0x01) হিসাবে সংজ্ঞায়িত, যা প্রথম ৮ বাইটে সংক্ষিপ্ত করা হয়। কী-টি ব্যাকএন্ডে সংরক্ষিত থাকে এবং ব্যবহারকারী ডিভাইসের একটি বোতাম টিপে সম্মতি প্রকাশ করলে, সিকার এটি ব্যবহার করে EIK পুনরুদ্ধার করতে পারে।

• রিং কী : SHA256(ephemeral identity key || 0x02) হিসেবে সংজ্ঞায়িত, যা প্রথম ৮ বাইটে সংক্ষিপ্ত করা হয়। কী-টি ব্যাকএন্ডে সংরক্ষিত থাকে এবং সিকার এটি শুধুমাত্র ডিভাইসটিতে রিং করার জন্য ব্যবহার করতে পারে।

• অবাঞ্ছিত ট্র্যাকিং সুরক্ষা কী : SHA256(ephemeral identity key || 0x03) হিসাবে সংজ্ঞায়িত, যা প্রথম ৮ বাইটে সংক্ষিপ্ত করা হয়। কী-টি ব্যাকএন্ডে সংরক্ষিত থাকে এবং সিকার এটি শুধুমাত্র অবাঞ্ছিত ট্র্যাকিং সুরক্ষা মোড সক্রিয় করতে ব্যবহার করতে পারে।

অপারেশন

বৈশিষ্ট্যে লেখা ডেটার বিন্যাস সারণি ২ থেকে ৫-এ দেওয়া হয়েছে। এই বিভাগের পরবর্তী অংশে প্রতিটি অপারেশন নিয়ে আরও বিস্তারিত আলোচনা করা হয়েছে।

সারণি ২: বীকন সরবরাহের অনুরোধ।

সারণি ৩: বীকন প্রোভিশনিং কী পুনরুদ্ধারের অনুরোধ।

সারণি ৪: রিং করার অনুরোধ।

সারণি ৫: অনাকাঙ্ক্ষিত ট্র্যাকিং সুরক্ষা অনুরোধ।

সফল রাইটগুলো সারণি ৬-এ তালিকাভুক্ত নোটিফিকেশনগুলো ট্রিগার করে।

0x05 ব্যতীত অন্য ডেটা আইডি সহ নোটিফিকেশন: যে রাইট ট্রানজ্যাকশনটি নোটিফিকেশনটি ট্রিগার করে, সেটি সম্পন্ন হওয়ার আগে, অর্থাৎ রাইট রিকোয়েস্টের জন্য একটি রেসপন্স পিডিইউ পাঠানোর আগে, রিং স্টেট পরিবর্তনের তথ্য পাঠানো উচিত।

সারণি ৬: বীকন পরিষেবার প্রতিক্রিয়া।

সারণি ৭-এ অপারেশনগুলো দ্বারা ফেরত আসা সম্ভাব্য GATT ত্রুটি কোডগুলো তালিকাভুক্ত করা হয়েছে।

সারণি ৭: গ্যাট (GATT) ত্রুটি কোডসমূহ।

বীকনের প্যারামিটারটি পড়ুন

সিকার, ডেটা আইডি 0x00 সহ টেবিল ২ থেকে একটি অনুরোধ সম্বলিত ক্যারেক্টারিস্টিকে একটি রাইট অপারেশন সম্পাদন করে প্রোভাইডারের কাছে বীকনের প্যারামিটারগুলো জানতে চাইতে পারে। প্রোভাইডার যাচাই করে দেখে যে প্রদত্ত ওয়ান-টাইম অথেন্টিকেশন কী-টি ডিভাইসে সংরক্ষিত যেকোনো অ্যাকাউন্ট কী-এর সাথে মেলে কি না।

যাচাইকরণ ব্যর্থ হলে প্রোভাইডার একটি অপ্রমাণিত ত্রুটি ফেরত দেয়।

সফল হলে, প্রোভাইডার টেবিল ৬ থেকে ডেটা আইডি 0x00 সহ একটি প্রতিক্রিয়া পাঠিয়ে অবহিত করে। প্রোভাইডার ডেটা সেগমেন্টটি নিম্নরূপে গঠন করে:

অনুরোধটি প্রমাণীকরণের জন্য ব্যবহৃত অ্যাকাউন্ট কী দিয়ে ডেটা অবশ্যই 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 সহ একটি প্রতিক্রিয়া পাঠিয়ে অবহিত করে। প্রোভাইডার ডেটা সেগমেন্টটি নিম্নরূপে গঠন করে:

প্রমাণীকরণ অংশটি HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) এর প্রথম ৮ বাইট হিসাবে সংজ্ঞায়িত করা হয়।

একটি ক্ষণস্থায়ী পরিচয় কী সেট করুন

একটি অপ্রস্তুত প্রোভাইডারকে FHN বীকন হিসেবে প্রস্তুত করতে, অথবা ইতিমধ্যে প্রস্তুতকৃত প্রোভাইডারের ক্ষণস্থায়ী পরিচয় কী (ephemeral identity key) পরিবর্তন করতে, সিকার (Seeker) ডেটা আইডি 0x02 সহ টেবিল ২ থেকে একটি অনুরোধ সম্বলিত ক্যারেক্টারিস্টিকে একটি রাইট অপারেশন সম্পাদন করে। প্রোভাইডার যাচাই করে যে:

• প্রদত্ত এককালীন প্রমাণীকরণ কী-টি মালিক অ্যাকাউন্টের কী-এর সাথে মিলে যায়।
• যদি কোনো ক্ষণস্থায়ী পরিচয় কী-এর হ্যাশ প্রদান করা হয়ে থাকে, তবে হ্যাশ করা ক্ষণস্থায়ী পরিচয় কী-টি বর্তমান ক্ষণস্থায়ী পরিচয় কী-টির সাথে মিলে যায়।
• যদি কোনো ক্ষণস্থায়ী পরিচয় কী-এর হ্যাশ প্রদান করা না হয়ে থাকে, তবে যাচাই করুন যে প্রোভাইডারটি আগে থেকেই একটি FHN বীকন হিসাবে প্রোভিশন করা ছিল না।

যাচাইকরণ ব্যর্থ হলে, প্রোভাইডার একটি অপ্রমাণিত ত্রুটি ফেরত দেয়।

সফল হলে, মিলে যাওয়া অ্যাকাউন্ট কী ব্যবহার করে AES-ECB-128 পদ্ধতিতে ডিক্রিপ্ট করার মাধ্যমে ক্ষণস্থায়ী পরিচয় কী-টি পুনরুদ্ধার করা হয়। কী-টি ডিভাইসে সংরক্ষণ করা উচিত এবং সেই মুহূর্ত থেকে প্রোভাইডারের FHN ফ্রেম প্রচার করা শুরু করা উচিত। BLE সংযোগ বিচ্ছিন্ন হওয়ার সাথে সাথেই নতুন ক্ষণস্থায়ী পরিচয় কী-টি কার্যকর হয়। প্রোভাইডার টেবিল ৬ থেকে ডেটা আইডি 0x02 সহ একটি প্রতিক্রিয়ার মাধ্যমে অবহিত করে।

প্রমাণীকরণ অংশটি HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) এর প্রথম ৮ বাইট হিসেবে সংজ্ঞায়িত করা হয়।

ক্ষণস্থায়ী পরিচয় কী মুছে ফেলুন

প্রোভাইডারের বীকন অংশটিকে আনপ্রোভিশন করার জন্য, সিকার ক্যারেক্টারিস্টিকটিতে একটি রাইট অপারেশন সম্পাদন করে, যার মধ্যে ডেটা আইডি 0x03 সহ টেবিল 2 থেকে একটি অনুরোধ অন্তর্ভুক্ত থাকে। প্রোভাইডার যাচাই করে যে:

• প্রদত্ত এককালীন প্রমাণীকরণ কী-টি মালিক অ্যাকাউন্টের কী-এর সাথে মিলে যায়।
• হ্যাশ করা ক্ষণস্থায়ী পরিচয় কী-টি বর্তমান ক্ষণস্থায়ী পরিচয় কী-এর সাথে মিলে যায়।

যদি প্রোভাইডারটিকে FHN বীকন হিসেবে প্রোভিশন করা না থাকে অথবা ভেরিফিকেশন ব্যর্থ হয়, তাহলে এটি একটি অপ্রমাণিত ত্রুটি ফেরত দেয়।

সফল হলে, প্রোভাইডার কী-টি ভুলে যায় এবং FHN ফ্রেমের বিজ্ঞাপন দেওয়া বন্ধ করে দেয়। প্রোভাইডার ডেটা আইডি 0x03 সহ টেবিল ৬ থেকে একটি প্রতিক্রিয়ার মাধ্যমে অবহিত করে। অথেনটিকেশন সেগমেন্টটি HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) এর প্রথম ৮ বাইট হিসাবে সংজ্ঞায়িত করা হয়।

ব্যবহারকারীর সম্মতি সাপেক্ষে ক্ষণস্থায়ী পরিচয় কী-টি পড়ুন।

এই বিকল্পটি শুধুমাত্র হারিয়ে যাওয়া কী পুনরুদ্ধার করার জন্য উপলব্ধ, কারণ কী-টি শুধুমাত্র সিকার দ্বারা স্থানীয়ভাবে সংরক্ষিত থাকে। সেই কারণে, এই সুবিধাটি কেবল তখনই উপলব্ধ হয় যখন ডিভাইসটি পেয়ারিং মোডে থাকে অথবা ডিভাইসের কোনো ফিজিক্যাল বাটন চাপার পর একটি সীমিত সময়ের জন্য (যা ব্যবহারকারীর সম্মতি হিসেবে গণ্য হয়)।

ক্লিয়ারটেক্সট কী পুনরুদ্ধার করতে পারার জন্য সিকারকে অবশ্যই ব্যাকএন্ডে রিকভারি কী সংরক্ষণ করতে হবে, কিন্তু এটি EIK নিজে সংরক্ষণ করে না।

EIK পড়ার জন্য, সিকার ক্যারেক্টারিস্টিকটিতে একটি রাইট অপারেশন সম্পাদন করে, যার মধ্যে ডেটা আইডি 0x04 সহ টেবিল 3 থেকে একটি অনুরোধ অন্তর্ভুক্ত থাকে। প্রোভাইডার যাচাই করে যে:

• হ্যাশ করা রিকভারি কী-টি প্রত্যাশিত রিকভারি কী-এর সাথে মিলে গেছে।
• ডিভাইসটি EIK রিকভারি মোডে আছে।

যাচাইকরণ ব্যর্থ হলে, প্রোভাইডার একটি অপ্রমাণিত ত্রুটি ফেরত দেয়।

ডিভাইসটি পেয়ারিং মোডে না থাকলে, প্রোভাইডার 'ব্যবহারকারীর সম্মতি নেই' (No User Consent) ত্রুটি দেখায়।

সফল হলে, প্রোভাইডার টেবিল ৬ থেকে ডেটা আইডি 0x04 সহ একটি প্রতিক্রিয়া পাঠিয়ে অবহিত করে।

প্রমাণীকরণ অংশটি HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) হিসেবে সংজ্ঞায়িত করা হয়।

রিং অপারেশন

অনুসন্ধানকারী, ডেটা আইডি 0x05 সহ টেবিল 4 থেকে একটি অনুরোধ সম্বলিত ক্যারেক্টারিস্টিক-এ একটি রাইট অপারেশন সম্পাদন করে প্রোভাইডারকে একটি শব্দ বাজাতে বলতে পারে। প্রোভাইডার ডেটা সেগমেন্টটি নিম্নরূপে গঠন করে:

অনুরোধটি পাওয়ার পর, প্রদানকারী যাচাই করে যে:

• প্রদত্ত ওয়ান-টাইম অথেনটিকেশন কী-টি রিং কী-এর সাথে মিলে যায়।
• অনুরোধকৃত অবস্থাটি সেই উপাদানগুলোর সাথে মেলে যেগুলো বেজে উঠতে পারে।

যদি প্রোভাইডারটি একটি FHN বীকন হিসাবে প্রোভিশন করা না থাকে অথবা ভেরিফিকেশন ব্যর্থ হয়, তবে এটি একটি অপ্রমাণিত ত্রুটি ফেরত দেয়। তবে, যদি প্রোভাইডারটির অবাঞ্ছিত ট্র্যাকিং সুরক্ষা সক্রিয় থাকে, এবং যে অনুরোধটি অবাঞ্ছিত ট্র্যাকিং সুরক্ষা ট্রিগার করেছিল তাতে 'স্কিপ রিংগিং অথেন্টিকেশন ফ্ল্যাগ' চালু করা থাকে, তাহলে প্রোভাইডারটির সেই চেকটি এড়িয়ে যাওয়া উচিত। সিকারের পক্ষ থেকে অথেন্টিকেশন ডেটা সরবরাহ করার কথা থাকলেও, এটি একটি যথেচ্ছ মানে সেট করা যেতে পারে।

রিং শুরু বা শেষ হলে, টেবিল ৬-এ নির্দেশিত ডেটা আইডি 0x05 সহ একটি নোটিফিকেশন পাঠানো হয়। নোটিফিকেশনটির বিষয়বস্তু নিম্নরূপভাবে সংজ্ঞায়িত করা হয়েছে:

প্রমাণীকরণ অংশটি 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 রিকোয়েস্ট) সহ একটি নোটিফিকেশন পাঠানো। এই অনুরোধটি বিদ্যমান স্টেটের প্যারামিটারগুলোকে ওভাররাইড করে, যার ফলে রিং হওয়ার সময়কাল বাড়ানো যায়।

প্রোভাইডারে যদি কোনো ফিজিক্যাল বাটন থাকে (অথবা টাচ সেন্স চালু থাকে), তাহলে রিং চালু থাকা অবস্থায় সেই বাটনটি চাপলে রিং ফাংশনটি বন্ধ হয়ে যাবে।

বীকনটির রিংগিং অবস্থা জানুন

বীকনের রিংগিং অবস্থা জানার জন্য, সিকার ক্যারেক্টারিস্টিক-এ একটি রাইট অপারেশন সম্পাদন করে, যার মধ্যে ডেটা আইডি 0x06 সহ টেবিল 4 থেকে একটি অনুরোধ অন্তর্ভুক্ত থাকে। প্রোভাইডার যাচাই করে যে প্রদত্ত ওয়ান-টাইম অথেনটিকেশন কী-টি রিং কী-এর সাথে মেলে কিনা।

যদি প্রোভাইডারটিকে FHN বীকন হিসেবে প্রোভিশন করা না থাকে অথবা ভেরিফিকেশন ব্যর্থ হয়, তাহলে প্রোভাইডারটি একটি অপ্রমাণিত ত্রুটি ফেরত দেয়।

সফল হলে, প্রোভাইডার টেবিল ৬ থেকে ডেটা আইডি 0x06 সহ একটি প্রতিক্রিয়া পাঠিয়ে অবহিত করে। প্রোভাইডার ডেটা সেগমেন্টটি নিম্নরূপে গঠন করে:

প্রমাণীকরণ অংশটি HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) হিসেবে সংজ্ঞায়িত করা হয়।

অবাঞ্ছিত ট্র্যাকিং সুরক্ষা মোড

অবাঞ্ছিত ট্র্যাকিং সুরক্ষা মোডের উদ্দেশ্য হলো, সার্ভারের সাথে কোনো যোগাযোগ ছাড়াই যেকোনো ক্লায়েন্টকে ক্ষতিকর ডিভাইস শনাক্ত করার সুযোগ দেওয়া। ডিফল্টরূপে, প্রোভাইডারের উচিত 'আইডি রোটেশন' -এ বর্ণিত পদ্ধতি অনুযায়ী সমস্ত আইডেন্টিফায়ার পরিবর্তন করা। ফাইন্ড হাব সার্ভিসটি ফাইন্ড হাব নেটওয়ার্কের মাধ্যমে অবাঞ্ছিত ট্র্যাকিং সুরক্ষা মোড সক্রিয় করার অনুরোধটি রিলে করতে পারে। এর ফলে, সার্ভিসটি প্রোভাইডারকে সাময়িকভাবে একটি নির্দিষ্ট MAC অ্যাড্রেস ব্যবহার করতে বাধ্য করে, যা ক্লায়েন্টদের ডিভাইসটি শনাক্ত করতে এবং ব্যবহারকারীকে সম্ভাব্য অবাঞ্ছিত ট্র্যাকিং সম্পর্কে সতর্ক করতে সাহায্য করে।

বীকনের অবাঞ্ছিত ট্র্যাকিং সুরক্ষা মোড সক্রিয় বা নিষ্ক্রিয় করতে, সিকার ক্যারেক্টারিস্টিক-এ একটি রাইট অপারেশন সম্পাদন করে, যার মধ্যে যথাক্রমে ডেটা আইডি 0x07 বা 0x08 সহ টেবিল 5 থেকে একটি অনুরোধ অন্তর্ভুক্ত থাকে।

অবাঞ্ছিত ট্র্যাকিং সুরক্ষা মোড সক্রিয় করার সময়

প্রোভাইডার ডেটা সেগমেন্টটি নিম্নরূপে গঠন করে:

প্রোভাইডার যাচাই করে যে প্রদত্ত ওয়ান-টাইম অথেনটিকেশন কী-টি অনাকাঙ্ক্ষিত ট্র্যাকিং প্রোটেকশন কী-এর সাথে মেলে কিনা। যদি প্রোভাইডারটি একটি 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 মেসেজ ফ্লো নিয়ে আলোচনা করা হয়েছে। চিত্র ১-এ মেসেজগুলোর প্রবাহ দেখানো হয়েছে এবং অনুচ্ছেদগুলোতে প্রতিটি মেসেজ আরও বিস্তারিতভাবে ব্যাখ্যা করা হয়েছে।

চিত্র ১। প্রিসিশন ফাইন্ডিং মেসেজ প্রবাহের একটি সাধারণ চিত্র।

ইনিশিয়েটর ডিভাইস হলো সেই ডিভাইস, যেটিতে ফাইন্ড হাব অ্যাপ রয়েছে এবং যেখান থেকে প্রিসিশন ফাইন্ডিং ফিচারটি চালু করা হয়েছিল। ইনিশিয়েটর হলো সেই ডিভাইস যা অন্য ডিভাইসটিকে খুঁজে বের করার চেষ্টা করছে।

রেসপন্ডার ডিভাইস হলো সেই ডিভাইস, যাকে ইনিশিয়েটর ডিভাইস খুঁজে বের করার চেষ্টা করে।

ইনিশিয়েটর ডিভাইসটি রেসপন্ডার ডিভাইসের কাছে একটি রেঞ্জিং ক্যাপাবিলিটি রিকোয়েস্ট মেসেজ পাঠায়, যেখানে এটি রেসপন্ডার ডিভাইসের কাছ থেকে কোন কোন রেঞ্জিং টেকনোলজি সম্পর্কে জানতে আগ্রহী তার একটি তালিকা থাকে। রেসপন্ডার ডিভাইসটি রেঞ্জিং ক্যাপাবিলিটি রেসপন্স নোটিফিকেশনের মাধ্যমে উত্তর দেয়, যাতে কোন কোন রেঞ্জিং টেকনোলজি সমর্থিত এবং সেগুলোর সক্ষমতা কী, সেই সম্পর্কিত তথ্য থাকে। রেসপন্ডার শুধুমাত্র ইনিশিয়েটরের অনুরোধ করা তথ্যই অন্তর্ভুক্ত করবে। সক্ষমতার তালিকাটি রেসপন্ডার ডিভাইসের পছন্দের রেঞ্জিং টেকনোলজির অগ্রাধিকার অনুসারে সাজানো হবে, যেখানে তালিকার প্রথমটির অগ্রাধিকার সর্বোচ্চ।

এরপর ইনিশিয়েটর ডিভাইসটি একটি রেঞ্জিং কনফিগারেশন মেসেজ পাঠাবে, যেখানে এটি প্রতিটি রেঞ্জিং প্রযুক্তির জন্য কনফিগারেশন নির্ধারণ করবে যা দিয়ে এটি রেঞ্জিং করতে চায়। এই মেসেজটি পাওয়ার পর, রেসপন্ডার ডিভাইসটিকে অবশ্যই প্রদত্ত কনফিগারেশন ব্যবহার করে প্রযোজ্য প্রযুক্তিগুলোর জন্য রেঞ্জিং শুরু করতে হবে। রেসপন্ডার ডিভাইসটি একটি রেঞ্জিং কনফিগারেশন রেসপন্স নোটিফিকেশন ফেরত পাঠাবে, যাতে প্রতিটি স্বতন্ত্র রেঞ্জিং প্রযুক্তি সফলভাবে শুরু হয়েছে কিনা তার ফলাফল থাকবে। একটি সফল রেঞ্জিং সেশনের জন্য কিছু রেঞ্জিং প্রযুক্তি ইনিশিয়েটর এবং রেসপন্ডার উভয় ডিভাইসেই শুরু করতে হয়, আবার অন্যগুলোর ক্ষেত্রে শুধুমাত্র ইনিশিয়েটর ডিভাইসে শুরু করাই যথেষ্ট; তবুও, রেসপন্ডার ডিভাইসটিকে অবশ্যই সেইসব প্রযুক্তির জন্য একটি সফলতার ফলাফল দিয়ে উত্তর দিতে হবে। নির্দিষ্ট রেঞ্জিং প্রযুক্তির আচরণ সম্পর্কে আরও বিস্তারিত পরবর্তী বিভাগগুলোতে পাওয়া যাবে।

ইনিশিয়েটর ডিভাইসটি যখন প্রিসিশন ফাইন্ডিং সেশনটি বন্ধ করার জন্য প্রস্তুত হবে, তখন এটি রেসপন্ডারকে একটি 'স্টপ রেঞ্জিং' বার্তা পাঠাবে, যা নির্দেশ করবে কোন কোন রেঞ্জিং প্রযুক্তিকে রেঞ্জিং বন্ধ করতে হবে। রেসপন্ডার ডিভাইসটি একটি 'স্টপ রেঞ্জিং রেসপন্স' নোটিফিকেশনের মাধ্যমে সাড়া দেবে, যা নির্দেশ করবে যে এটি অনুরোধকৃত রেঞ্জিং প্রযুক্তিগুলোর সাথে সফলভাবে রেঞ্জিং বন্ধ করেছে।

প্রিসিশন ফাইন্ডিং সেশনের মাঝপথে FHNA BLE GATT কমিউনিকেশন চ্যানেল বিচ্ছিন্ন হয়ে গেলে, কিন্তু তখনও কিছু রেঞ্জিং প্রযুক্তি চালু থাকা অবস্থায়, রেসপন্ডার ডিভাইসটি একটি টাইমআউট ব্যবস্থা প্রয়োগ করবে যাতে এটি অনির্দিষ্টকালের জন্য রেঞ্জিং চালিয়ে না যায়। এর বিস্তারিত বিবরণ প্রতিটি ব্যবহারের ক্ষেত্রের উপর নির্ভর করবে।

উল্লেখ্য, রেসপন্ডার ডিভাইসটিকে অবশ্যই ধরে নেওয়া উচিত নয় যে অপারেশনগুলোর ক্রম সর্বদা একই থাকবে। উদাহরণস্বরূপ, রেসপন্ডার ডিভাইসটিকে অবশ্যই পরপর একাধিক রেঞ্জিং ক্যাপাবিলিটি রিকোয়েস্ট অপারেশন, অথবা পূর্ববর্তী ক্যাপাবিলিটি রিকোয়েস্ট ছাড়াই সরাসরি একটি রেঞ্জিং কনফিগারেশন অপারেশন পরিচালনা করতে সক্ষম হতে হবে।

নির্ভুলতা অনুসন্ধান অপারেশন

সারণি ৮-এ এই নথি দ্বারা সংজ্ঞায়িত FHNA অপারেশনগুলো দেখানো হয়েছে যা প্রিসিশন ফাইন্ডিং-এর জন্য প্রয়োজন। প্রতিটি উপবিভাগ প্রতিটি অপারেশনের জন্য FHNA বার্তা সংজ্ঞায়িত করে, যেখানে অতিরিক্ত ডেটা ফিল্ডের বিষয়বস্তু রেঞ্জিং: আউট-অফ-ব্যান্ড বার্তা ক্রম এবং পেলোড স্পেসিফিকেশনকে নির্দেশ করে।

সারণি ৮: নির্ভুলতা নির্ণয়ের অপারেশনসমূহ।

রেঞ্জিং ক্ষমতা অনুরোধ অপারেশন

সারণি ৯-এ রেঞ্জিং ক্যাপাবিলিটি রিকোয়েস্ট মেসেজটির সংজ্ঞা দেওয়া হয়েছে।

সারণি ৯: রেঞ্জিং সক্ষমতার অনুরোধ।

রেঞ্জিং সক্ষমতা প্রতিক্রিয়া অপারেশন

সারণি ১০-এ রেঞ্জিং ক্যাপাবিলিটি রেসপন্স মেসেজটির সংজ্ঞা দেওয়া হয়েছে।

সারণি ১০: দূরত্ব পরিমাপ ক্ষমতার প্রতিক্রিয়া।

রেঞ্জিং কনফিগারেশন অপারেশন

সারণি ১১-তে রেঞ্জিং কনফিগারেশন মেসেজটির সংজ্ঞা দেওয়া হয়েছে।

সারণি ১১: রেঞ্জিং কনফিগারেশন।

রেঞ্জিং কনফিগারেশন প্রতিক্রিয়া অপারেশন

সারণি ১২-তে রেঞ্জিং কনফিগারেশন রেসপন্স মেসেজটির সংজ্ঞা দেওয়া হয়েছে।

সারণি ১২: রেঞ্জিং কনফিগারেশন প্রতিক্রিয়া।

রেঞ্জিং অপারেশন বন্ধ করুন

সারণি ১৩-তে স্টপ রেঞ্জিং মেসেজটির সংজ্ঞা দেওয়া হয়েছে।

সারণি ১৩: পরিসীমা নির্ধারণ বন্ধ করুন।

রেঞ্জিং রেসপন্স অপারেশন বন্ধ করুন

সারণি ১৪-তে স্টপ রেঞ্জিং রেসপন্স মেসেজটির সংজ্ঞা দেওয়া হয়েছে।

সারণি ১৪: রেঞ্জিং প্রতিক্রিয়া বন্ধ করুন।

প্রিসিশন ফাইন্ডিং-এর মাধ্যমে অনাকাঙ্ক্ষিত ট্র্যাকিং থেকে সুরক্ষা

অবাঞ্ছিত ট্র্যাকিং সুরক্ষা বিভাগে বর্ণিত অবাঞ্ছিত ট্র্যাকিং সুরক্ষা মোড সক্রিয় করা হলে, যে ডিভাইসগুলি এই বৈশিষ্ট্যটি সমর্থন করতে চায়, তাদের জন্য এই নথিতে সংজ্ঞায়িত সমস্ত প্রিসিশন ফাইন্ডিং বার্তার ক্ষেত্রেও রিংিং বার্তাগুলির জন্য প্রমাণীকরণ পরীক্ষা এড়িয়ে যাওয়ার একই প্রক্রিয়াটি প্রযোজ্য হবে।

নির্ভুলভাবে অনুসন্ধানের জন্য রেঞ্জিং প্রযুক্তির নির্দিষ্ট বিবরণ

এই বিভাগে প্রযুক্তি-নির্দিষ্ট বিবরণ রয়েছে।

আল্ট্রা-ওয়াইডব্যান্ড (UWB) এর নির্দিষ্ট বিবরণ

UWB-এর নির্দিষ্ট বিবরণ।

নির্ভুলতা অনুসন্ধানের স্তর

রেঞ্জিং প্রযুক্তি হিসেবে UWB ব্যবহার করে প্রিসিশন ফাইন্ডিং সেশনগুলিতে দূরত্ব এবং দিক উভয় তথ্যই পাওয়া যেতে পারে। রেঞ্জিং ব্যবধান কমপক্ষে ২৪০ মিলিসেকেন্ড হওয়া প্রয়োজন, তবে সর্বোত্তম দিকনির্দেশনার জন্য ৯৬ মিলিসেকেন্ড বাঞ্ছনীয়।

কনফিগারেশন আইডি

UWB-এর জন্য আদান-প্রদান করা আউট-অফ-ব্যান্ড কনফিগারেশন ডেটাতে, একটি UWB রেঞ্জিং সেশন শুরু করার জন্য প্রয়োজনীয় সমস্ত কনফিগারযোগ্য প্যারামিটার থাকে না। কিছু প্যারামিটার নির্বাচিত কনফিগ আইডি দ্বারা পরোক্ষভাবে নির্বাচিত হয়ে যায়।

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.

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

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

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:

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:

1. Choose a random number s in Fp , as defined in the EID computation section.
2. Compute S = s * G .
3. Compute R = (Rx, Ry) by substitution in the curve equation and picking an arbitrary Ry value out of the possible results.
4. 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.
5. 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 .
6. Compute nonce = LRx || LSx .
7. Compute (m', tag) = AES-EAX-256-ENC(k, nonce, m) .
8. 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:

1. 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.
2. Given the beacon time counter value on which URx is based, compute the anticipated value of r as defined in the EID computation section.
3. Compute R = r * G , and verify a match to the value of URx provided by the sighter.
4. Compute S = (Sx, Sy) by substitution in the curve equation and picking an arbitrary Sy value out of the possible results.
5. Compute k = HKDF-SHA256((r * S)x) where (r * S)x is the x coordinate of the curve multiplication result.
6. Compute nonce = LRx || LSx .
7. 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 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.

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.

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.

Table 20: Device information event: clock sync.

ফ্যাক্টরি রিসেট

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.

Firmware updates

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.

পরিবর্তন তালিকা