Find My Device के नेटवर्क ऐक्सेसरी की खास बातें

v1.3

Find My Device नेटवर्क (FMDN) की ऐक्सेसरी की खास बातों में, ब्लूटूथ कम एनर्जी (BLE) वाले डिवाइसों को ट्रैक करने के लिए, एंड-टू-एंड एन्क्रिप्टेड (E2EE) तरीका बताया गया है. इस पेज पर, एफ़एमडीएन को फ़ास्ट पेयर की सुविधा के एक्सटेंशन के तौर पर बताया गया है. सेवा देने वाली कंपनियों को इस एक्सटेंशन को तब चालू करना चाहिए, जब उनके पास ऐसे डिवाइस हों जो एफ़एमडीएन के साथ काम करते हों और वे उन डिवाइस के लिए जगह की जानकारी ट्रैक करने की सुविधा चालू करना चाहते हों.

GATT की खास बातें

फ़ास्ट पेयर सेवा में एक अन्य सामान्य एट्रिब्यूट (जीएटी) की विशेषता, यहां बताए गए मतलब के साथ जोड़ी जानी चाहिए:

फ़ास्ट पेयर सेवा की विशेषता एन्क्रिप्ट (सुरक्षित) किया गया है अनुमतियां यूयूआईडी
बीकन कार्रवाइयां नहीं पढ़ें, लिखें, और सूचना भेजें FE2C1238-8366-4814-8EB0-01DE32100BEA

टेबल 1: एफ़एमडीएन के लिए फ़ास्ट पेयर सेवा की विशेषताएं.

पुष्टि करना

इस एक्सटेंशन के लिए ज़रूरी कार्रवाइयां, लिखने की कार्रवाई के रूप में की जाती हैं, जो चुनौती-प्रतिक्रिया तकनीक से सुरक्षित होती हैं. कोई भी कार्रवाई करने से पहले, सीकर को टेबल 1 में मौजूद विशेषता से रीड ऑपरेशन करना चाहिए. ऐसा होने पर, नीचे दिए गए फ़ॉर्मैट में बफ़र होगा:

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 प्रोटोकॉल मेजर वर्शन नंबर 0x01
1 से 8 बाइट अरे वन-टाइम रैंडम नॉन्स अलग-अलग

हर रीड ऑपरेशन का नतीजा एक अलग नॉन्स में होना चाहिए और एक नॉन्स सिर्फ़ एक ऑपरेशन के लिए मान्य होना चाहिए. कार्रवाई पूरी न होने पर भी नॉन्स को अमान्य करना चाहिए.

इसके बाद, सीकर एक बार इस्तेमाल होने वाली पुष्टि करने वाली कुंजी कैलकुलेट करता है, जिसे लिखने के अनुरोध में इस्तेमाल किया जाता है. पुष्टि करने वाली कुंजी का हिसाब, टेबल 2 से लेकर 5 तक में बताए गए तरीके से लगाया जाता है. अनुरोध की जा रही कार्रवाई के आधार पर, नौकरी ढूंढने वाला यह साबित करता है कि इनमें से एक या एक से ज़्यादा कुंजियों के बारे में जानकारी है या नहीं:

ऑपरेशंस

विशेषता के लिए लिखे गए डेटा का फ़ॉर्मैट, 2 से 5 के बीच टेबल 2 में दिया जाता है. इस सेक्शन में आगे हर कार्रवाई के बारे में ज़्यादा जानकारी दी गई है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 डेटा आईडी
  • 0x00: बीकन पैरामीटर पढ़ें
  • 0x01: प्रावधान की स्थिति पढ़ें
  • 0x02: इफ़ेमरल आइडेंटिटी कुंजी सेट करें
  • 0x03: इफ़ेमरल आइडेंटिटी कुंजी मिटाएं
1 uint8 डेटा की लंबाई अलग-अलग
2 से 9 बाइट अरे एक बार पुष्टि करने वाली कुंजी HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) के पहले 8 बाइट
10 - वैरिएबल बाइट अरे अतिरिक्त डेटा
  • 0x00: लागू नहीं
  • 0x01: लागू नहीं
  • 0x02: 32 बाइट, जो कुछ समय के लिए पहचान करने वाली कुंजी हैं, AES-ECB-128 खाता कुंजी से एन्क्रिप्ट यानी सुरक्षित किया जाता है. अगर सेवा देने वाली कंपनी के पास पहले से ही, कुछ समय के लिए प्रोफ़ाइल बनाने वाली कुंजी का सेट है, तो SHA256(current ephemeral identity key || the last nonce read from the characteristic) के पहले आठ बाइट भी भेजें
  • 0x03: SHA256(ephemeral identity key || the last nonce read from the characteristic) के पहले 8 बाइट

टेबल 2: बीकन प्रावधान का अनुरोध.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 डेटा आईडी 0x04: उपयोगकर्ता की सहमति से, इफ़ेमरल आइडेंटिटी कुंजी पढ़ें
1 uint8 डेटा की लंबाई 0x08 पिक्सल
2 से 9 बाइट अरे एक बार पुष्टि करने वाली कुंजी HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length) के पहले 8 बाइट

टेबल 3: बीकन प्रॉविज़निंग कुंजी वापस पाने का अनुरोध.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 डेटा आईडी
  • 0x05: रिंग
  • 0x06: घंटी की आवाज़ की स्थिति को पढ़ें
1 uint8 डेटा की लंबाई अलग-अलग
2 से 9 बाइट अरे एक बार पुष्टि करने वाली कुंजी HMAC-SHA256(ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) के पहले 8 बाइट
10 - वैरिएबल बाइट अरे अतिरिक्त डेटा
  • 0x05: 4 बाइट जो रिंगिंग की स्थिति, रिंग की अवधि, और रिंग की आवाज़ के बारे में बताते हैं.
  • 0x06: लागू नहीं

टेबल 4: रिंगिंग का अनुरोध.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 डेटा आईडी
  • 0x07: अनचाही ट्रैकिंग सुरक्षा मोड चालू करें
  • 0x08: अनचाही ट्रैकिंग सुरक्षा मोड को बंद करें
1 uint8 डेटा की लंबाई अलग-अलग
2 से 9 बाइट अरे एक बार पुष्टि करने वाली कुंजी HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data) के पहले 8 बाइट
10 - वैरिएबल बाइट अरे अतिरिक्त डेटा
  • 0x07: एक बाइट के कंट्रोल फ़्लैग (ज़रूरी नहीं)
  • 0x08: SHA256(ephemeral identity key || the last nonce read from the characteristic) के पहले 8 बाइट

टेबल 5: अनचाही ट्रैकिंग के लिए सुरक्षा का अनुरोध.

टेबल 6 में दिए गए ट्रिगर की सूचनाओं को सही तरीके से लिखा जाता है.

0x05: रिंग की स्थिति में बदलाव के अलावा, डेटा आईडी वाली सूचनाएं, राइटिंग ट्रांज़ैक्शन के पूरा होने से पहले भेजी जानी चाहिए. इसका मतलब है कि नई सूचना लिखने के अनुरोध के लिए रिस्पॉन्स पीडीयू भेजे जाने से पहले.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 डेटा आईडी
  • 0x00: बीकन पैरामीटर पढ़ें
  • 0x01: प्रावधान की स्थिति पढ़ें
  • 0x02: इफ़ेमरल आइडेंटिटी कुंजी सेट करें
  • 0x03: इफ़ेमरल आइडेंटिटी कुंजी मिटाएं
  • 0x04: उपयोगकर्ता की सहमति से, इफ़ेमरल आइडेंटिटी कुंजी पढ़ें
  • 0x05: रिंग की स्थिति में बदलाव
  • 0x06: घंटी की आवाज़ की स्थिति को पढ़ें
  • 0x07: अनचाही ट्रैकिंग सुरक्षा मोड चालू करें
  • 0x08: अनचाही ट्रैकिंग सुरक्षा मोड को बंद करें
1 uint8 डेटा की लंबाई अलग-अलग
2 से 9 बाइट अरे पुष्टि करना हर कार्रवाई के बारे में ज़्यादा जानकारी
10 - वैरिएबल बाइट अरे अतिरिक्त डेटा
  • 0x00: 8 बाइट से पता चलता है कि ट्रांसमिशन पावर, क्लॉक वैल्यू, एन्क्रिप्ट (सुरक्षित) करने का तरीका, और रिंगिंग की क्षमता क्या है. साथ ही, AES-ECB-128 को खाता कुंजी (शून्य पैडेड) से एन्क्रिप्ट यानी सुरक्षित किया गया है
  • 0x01: 1 बाइट, जो प्रावधान की स्थिति को दिखाती है. इसके बाद, लागू होने पर मौजूदा कुछ समय के लिए आईडी (20 या 32 बाइट) होती है
  • 0x04: 32 बाइट, जो कुछ समय के लिए पहचान करने वाली कुंजी हैं, AES-ECB-128 खाता कुंजी से एन्क्रिप्ट यानी सुरक्षित किया गया है
  • 0x05: 4 बाइट, जो नई स्थिति को दिखाती है और बदलाव के लिए ट्रिगर होती है
  • 0x06: 3 बाइट से पता चलता है कि कॉम्पोनेंट सक्रिय रूप से रिंग कर रहे हैं और रिंग के लिए कितने डेसीसेकंड बचे हैं
  • अन्य डेटा आईडी, खाली अतिरिक्त डेटा का इस्तेमाल करते हैं

टेबल 6: बीकन सेवा का जवाब.

टेबल 7 में, कार्रवाइयों से मिले संभावित GATT गड़बड़ी कोड की सूची दी गई है.

कोड ब्यौरा ज़रूरी जानकारी
0x80 प्रमाणीकृत नहीं किया गया पुष्टि करने में नाकाम होने पर, लिखने के अनुरोध के जवाब में लौटाया गया (इसमें पुराने नॉन्स का इस्तेमाल करने वाला केस भी शामिल है).
0x81 अमान्य वैल्यू कोई अमान्य वैल्यू दिए जाने या मिलने वाले डेटा में अनचाहे बाइट होने पर, नतीजे दिखाए जाते हैं.
0x82 उपयोगकर्ता की सहमति नहीं है डेटा आईडी के साथ लिखने के अनुरोध के जवाब में वापस भेजा गया 0x04: उपयोगकर्ता की सहमति से इफ़ेमरल आइडेंटिटी कुंजी पढ़ें, जब डिवाइस 'दूसरे डिवाइस से जोड़ने वाला मोड' में न हो.

टेबल 7: GATT के गड़बड़ी कोड.

बीकन का पैरामीटर पढ़ें

सीकर, बीकन के पैरामीटर के लिए सेवा देने वाले से क्वेरी कर सकता है. इसके लिए वह डेटा आईडी 0x00 वाली टेबल 2 से मिली अनुरोध वाली विशेषता के लिए लिखने का काम कर सकता है. सेवा देने वाली कंपनी इस बात की पुष्टि करती है कि एक बार दी जाने वाली पुष्टि करने वाली कुंजी, डिवाइस पर सेव की गई किसी भी खाता कुंजी से मेल खाती है.

अगर पुष्टि नहीं हो पाती है, तो सेवा देने वाली कंपनी, बिना पुष्टि वाली गड़बड़ी का मैसेज दिखाती है.

डाउनलोड हो जाने पर, सेवा देने वाली कंपनी, टेबल 6 से 0x00 डेटा आईडी वाले जवाब की सूचना देती है. सेवा देने वाली कंपनी, डेटा सेगमेंट इस तरह बनाती है:

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 कैलिब्रेट किया गया पावर 0 मीटर पर मिली कैलिब्रेट की गई पावर (रेंज [-100, 20] में कोई वैल्यू है). साइन किए गए पूर्णांक के तौर पर दिखाया जाता है. इसका रिज़ॉल्यूशन 1 dBm होता है.
1 से 4 uint32 घड़ी का मान सेकंड में मौजूदा घड़ी का मान (बड़ा एंडियन).
5 uint8 कर्व चुनना एन्क्रिप्ट (सुरक्षित) करने के लिए इस्तेमाल किया जा रहा एलिप्टिक कर्व:
  • 0x00 (डिफ़ॉल्ट): SECP160R1
  • 0x01: SECP256R1 (एक्सटेंडेड विज्ञापन की ज़रूरत है)
6 uint8 घटक घंटी बजने वाले कॉम्पोनेंट की संख्या:
  • 0x00: यह बताता है कि डिवाइस रिंग नहीं कर सकता.
  • 0x01: इससे यह पता चलता है कि सिर्फ़ एक कॉम्पोनेंट में घंटी बज सकती है.
  • 0x02: इससे पता चलता है कि बायां और दायां ईयरबड, दो कॉम्पोनेंट अलग-अलग घंटी बजा सकते हैं.
  • 0x03: इससे पता चलता है कि तीन कॉम्पोनेंट, जैसे कि बायां और दायां बड और केस, अलग-अलग रिंग कर सकते हैं.
7 uint8 रिंग करने की सुविधाएं इस्तेमाल किए जा सकने वाले विकल्प ये हैं:
  • 0x00: रिंगिंग वॉल्यूम चुनने की सुविधा उपलब्ध नहीं है.
  • 0x01: रिंगिंग वॉल्यूम चयन उपलब्ध है. अगर यह नीति सेट है, तो सेवा देने वाली कंपनी को वॉल्यूम के तीन लेवल स्वीकार करने और मैनेज करने चाहिए, जैसा कि रिंग करने की कार्रवाई में बताया गया है.
8-15 बाइट अरे पैडिंग (जगह) 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 वाली टेबल 2 से मिला अनुरोध कर सकता है. सेवा देने वाली कंपनी इस बात की पुष्टि करती है कि एक बार इस्तेमाल की जाने वाली पुष्टि करने वाली कुंजी, डिवाइस पर सेव की गई किसी भी खाता कुंजी से मेल खाती है.

अगर पुष्टि नहीं हो पाती, तो सेवा देने वाली कंपनी, बिना पुष्टि वाली गड़बड़ी का मैसेज दिखाती है.

डाउनलोड हो जाने पर, सेवा देने वाली कंपनी, टेबल 6 से 0x01 डेटा आईडी वाले जवाब की सूचना देती है. सेवा देने वाली कंपनी, डेटा सेगमेंट इस तरह बनाती है:

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 प्रावधान की स्थिति बिटमास्क में ये वैल्यू होती हैं:
  • बिट 1 (0x01): यह सेट करें कि डिवाइस के लिए, कुछ समय के लिए पहचान वाली कुंजी सेट की गई है या नहीं.
  • बिट 2 (0x02): सेट करें कि क्या एक बार पुष्टि करने वाली कुंजी, मालिक के खाते की कुंजी से मैच करती है.
1 - 20 या 32 बाइट अरे कुछ समय के लिए सेव किया गया मौजूदा आइडेंटिफ़ायर 20 या 32 बाइट (इस्तेमाल किए जा रहे एन्क्रिप्शन के तरीके के आधार पर), अगर डिवाइस के लिए कोई सेट किया गया है, तो बीकन से दिखाए गए मौजूदा इफ़ेमरल आईडी को दिखाता है.

पुष्टि करने वाले सेगमेंट को HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) के पहले आठ बाइट के तौर पर दिखाया जाता है.

कुछ समय के लिए पहचान करने वाली कुंजी सेट करें

सेवा देने वाली कंपनी को एफ़एमडीएन बीकन के तौर पर सेट करने या उसकी इफ़ेमरल आइडेंटिटी कुंजी बदलने के लिए, सीकर दो टेबल से अनुरोध करता है. इसमें डेटा आईडी 0x02 की मदद से, दूसरी टेबल से किया गया अनुरोध शामिल होता है. सेवा देने वाली कंपनी पुष्टि करती है कि:

  • एक बार पुष्टि करने वाली कुंजी, मालिकाना हक वाले खाते की कुंजी से मेल खाती है.
  • अगर इफ़ेमरल आइडेंटिटी कुंजी का हैश दिया गया था, तो थोड़े समय के लिए इस्तेमाल की जाने वाली मौजूदा कुंजी, कुछ समय के लिए प्रोफ़ाइल बनाने वाली मौजूदा कुंजी से मैच करती है.
  • अगर इफ़ेमरल आइडेंटिटी की कुंजी का हैश नहीं दिया गया था, तो पुष्टि करें कि प्रोवाइडर को पहले से ही FMDN बीकन के तौर पर सेट नहीं किया गया था.

अगर पुष्टि नहीं हो पाती, तो सेवा देने वाली कंपनी, बिना पुष्टि वाली गड़बड़ी का मैसेज दिखाती है.

कामयाब होने पर, AES-ECB-128 इफ़ेमरल आइडेंटिटी कुंजी को वापस लाने के लिए, मेल खाने वाली खाता कुंजी का इस्तेमाल करता है. कुंजी को डिवाइस पर बने रहना चाहिए और उस समय से, प्रोवाइडर को एफ़एमडीएन फ़्रेम का विज्ञापन देना शुरू कर देना चाहिए. नई इफ़ेमरल आइडेंटिटी कुंजी, बीएलई कनेक्शन खत्म होने के तुरंत बाद लागू हो जाती है. सेवा देने वाली कंपनी, टेबल 6 से 0x02 डेटा आईडी वाले जवाब की सूचना देती है.

पुष्टि करने वाले सेगमेंट को HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) के पहले आठ बाइट के तौर पर दिखाया जाता है.

कुछ समय के लिए प्रोफ़ाइल बनाने वाली पहचान कुंजी मिटाएं

सेवा देने वाले व्यक्ति या कंपनी के बीकन वाले हिस्से को इस्तेमाल से बाहर करने के लिए, नौकरी ढूंढने वाला, विशेषता के हिसाब से डेटा में बदलाव करता है. इसमें डेटा आईडी 0x03 वाले टेबल 2 से किया गया अनुरोध शामिल होता है. सेवा देने वाली कंपनी पुष्टि करती है कि:

  • एक बार पुष्टि करने वाली कुंजी, मालिकाना हक वाले खाते की कुंजी से मेल खाती है.
  • हैश की गई इफ़ेमरल आइडेंटिटी कुंजी, कुछ समय के लिए प्रोफ़ाइल बनाने वाली मौजूदा कुंजी से मैच करती है.

अगर प्रोवाइडर को एफ़एमडीएन बीकन के रूप में प्रावधान नहीं किया गया है या पुष्टि नहीं हो पाती है, तो यह बिना पुष्टि वाली गड़बड़ी दिखाता है.

डाउनलोड हो जाने पर, सेवा देने वाली कंपनी कुंजी को भूल जाती है और एफ़एमडीएन फ़्रेम के विज्ञापन दिखाना बंद कर देती है. सेवा देने वाली कंपनी, टेबल 6 से 0x03 डेटा आईडी वाले जवाब की सूचना देती है. पुष्टि करने वाले सेगमेंट को HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) के पहले आठ बाइट के तौर पर दिखाया जाता है.

उपयोगकर्ता की सहमति से, इफ़ेमरल आइडेंटिटी कुंजी पढ़ें

यह विकल्प सिर्फ़ खोई हुई कुंजी को वापस पाने के लिए उपलब्ध होता है, क्योंकि कुंजी को सिर्फ़ स्थानीय तौर पर नौकरी ढूंढने वाला सेव करता है. हालांकि, यह सुविधा सिर्फ़ तब उपलब्ध होती है, जब डिवाइस दूसरे डिवाइस से जोड़ने वाले मोड में होता है. इसके अलावा, डिवाइस पर बटन दबाने के कुछ समय बाद (इसमें उपयोगकर्ता की सहमति शामिल होती है) भी होती है.

क्लियर टेक्स्ट कुंजी को वापस पाने के लिए, सीकर को बैकएंड में रिकवरी कुंजी सेव करनी होगी. हालांकि, यह EIK को सेव नहीं करता.

EIK को पढ़ने के लिए, सीकर एट्रिब्यूट में लिखने की कार्रवाई करता है. इसमें टेबल 3 से मिला अनुरोध शामिल है, जिसका डेटा आईडी 0x04 है. सेवा देने वाली कंपनी पुष्टि करती है कि:

  • हैश की गई रिकवरी कुंजी, अनुमानित रिकवरी कुंजी से मेल खाती है.
  • डिवाइस EIK रिकवरी मोड में है.

अगर पुष्टि नहीं हो पाती, तो सेवा देने वाली कंपनी, बिना पुष्टि वाली गड़बड़ी का मैसेज दिखाती है.

अगर डिवाइस दूसरे डिवाइस से जोड़ने वाले मोड में नहीं है, तो सेवा देने वाली कंपनी, 'उपयोगकर्ता की सहमति नहीं है' वाली गड़बड़ी दिखाती है.

डाउनलोड हो जाने पर, सेवा देने वाली कंपनी, टेबल 6 से 0x04 डेटा आईडी वाले जवाब की सूचना देती है.

पुष्टि करने वाले सेगमेंट को HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) के पहले आठ बाइट के तौर पर दिखाया जाता है.

रिंग कॉल की कार्रवाई

सीकर, सेवा देने वाले से किसी विशेषता के लिए लिखने का अनुरोध कर सकता है. इसमें, टेबल 4 से मिला अनुरोध 0x05 डेटा आईडी के साथ शामिल होता है. सेवा देने वाली कंपनी, डेटा सेगमेंट इस तरह बनाती है:

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 रिंग कॉल की कार्रवाई बिटमास्क में ये वैल्यू होती हैं:
  • बिट 1 (0x01): दाईं ओर रिंग करें
  • बिट 2 (0x02): बाईं ओर रिंग करें
  • बिट 3 (0x04): रिंग केस
  • 0xFF: सभी कॉम्पोनेंट पर घंटी बजाएं
  • 0x00: घंटी की आवाज़ बंद करें
1 से 2 uint16 टाइम आउट की संख्या टाइम आउट डेसीसेकंड में. शून्य नहीं होना चाहिए और 10 मिनट के बराबर से ज़्यादा नहीं होना चाहिए.
सेवा देने वाली कंपनी इस वैल्यू का इस्तेमाल यह तय करने के लिए करती है कि खुद को बंद करने से पहले, घंटी कितनी देर तक बजे चाहिए. अगर डिवाइस का कोई भी कॉम्पोनेंट पहले से बज रहा है, तो टाइम आउट की सुविधा, पहले से लागू सिस्टम को बदल देती है.

अगर रिंग की कार्रवाई 0x00 पर सेट है, तो टाइम आउट को अनदेखा कर दिया जाता है.
3 uint8 आवाज़ बढ़ाने/घटाने का स्लाइडर
  • 0x00: डिफ़ॉल्ट
  • 0x01: कम
  • 0x02: मीडियम
  • 0x03: ज़्यादा
इन वैल्यू का सही मतलब, लागू करने के तरीके पर निर्भर करता है.

अनुरोध मिलने पर, सेवा देने वाली कंपनी पुष्टि करती है कि:

  • एक बार पुष्टि करने वाली कुंजी, रिंग कुंजी से मेल खाती है.
  • अनुरोध की गई स्थिति उन कॉम्पोनेंट से मेल खाती है जो रिंग कर सकते हैं.

अगर प्रोवाइडर को एफ़एमडीएन बीकन के रूप में प्रावधान नहीं किया गया है या पुष्टि नहीं हो पाती है, तो यह बिना पुष्टि वाली गड़बड़ी दिखाता है. हालांकि, अगर सेवा देने वाली कंपनी के पास अनचाही ट्रैकिंग से जुड़ी सुरक्षा चालू है और अनचाही ट्रैकिंग सुरक्षा के अनुरोध को ट्रिगर करने के लिए रिंगिंग ऑथेंटिकेशन फ़्लैग वाला विकल्प चालू है, तो सेवा देने वाली कंपनी को उस जांच को छोड़कर आगे बढ़ जाना चाहिए. पुष्टि करने वाला डेटा सीकर की ओर से अब भी दिया जाना चाहिए, लेकिन इसे किसी आर्बिट्रेरी वैल्यू पर सेट किया जा सकता है.

घंटी बजना शुरू होने या बंद होने पर, एक सूचना भेजी जाती है, जैसा कि टेबल 6 में बताया गया है. इसमें डेटा आईडी 0x05 के साथ बताया गया है. सूचना में शामिल कॉन्टेंट के बारे में यहां बताया गया है:

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 रिंगिंग स्थिति
  • 0x00: शुरू हो गया
  • 0x01: शुरू या बंद नहीं किया जा सका (अनुरोध किए गए सभी कॉम्पोनेंट सीमा से बाहर हैं)
  • 0x02: रोका गया (समय खत्म)
  • 0x03: रोका गया (बटन दबाएं)
  • 0x04: रोका गया (GATT अनुरोध)
1 uint8 रिंगिंग कॉम्पोनेंट अनुरोध में बताए गए तरीके के मुताबिक, लगातार बज रहे कॉम्पोनेंट का बिटमास्क.
2 से 3 uint16 टाइम आउट की संख्या डेसिबल में घंटी बजने में शेष समय. अगर डिवाइस की घंटी बजना बंद हो गई है, तो 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 अनुरोध) के साथ सूचना भेजनी चाहिए. यह अनुरोध मौजूदा स्थिति के पैरामीटर को बदल देता है, ताकि घंटी बजने की अवधि बढ़ाई जा सके.

अगर प्रोवाइडर के पास फ़िज़िकल बटन है या टच सेंस चालू है, तो उस बटन को दबाकर रखने पर, घंटी बजने का फ़ंक्शन बंद हो जाना चाहिए.

बीकन के बजने की स्थिति का पता लगाएं

बीकन की घंटी बजने की स्थिति जानने के लिए, सीकर विशेषता के हिसाब से लिखने की कार्रवाई करता है. इसमें डेटा आईडी 0x06 वाली टेबल 4 से किया गया अनुरोध शामिल होता है. सेवा देने वाली कंपनी इस बात की पुष्टि करती है कि एक बार इस्तेमाल की जाने वाली पुष्टि करने वाली कुंजी, रिंग कुंजी से मेल खाती है.

अगर सेवा देने वाली कंपनी को एफ़एमडीएन बीकन के तौर पर सेट नहीं किया गया है या पुष्टि नहीं हो पाती है, तो सेवा देने वाली कंपनी बिना पुष्टि वाली गड़बड़ी दिखाती है.

डाउनलोड हो जाने पर, सेवा देने वाली कंपनी, टेबल 6 से 0x06 डेटा आईडी वाले जवाब की सूचना देती है. सेवा देने वाली कंपनी, डेटा सेगमेंट इस तरह बनाती है:

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 रिंगिंग कॉम्पोनेंट कॉम्पोनेंट लगातार बज रहे हैं, जैसा कि रिंगिंग अनुरोध में बताया गया है.
1 से 2 uint16 टाइम आउट की संख्या डेसिबल में घंटी बजने में शेष समय. ध्यान दें कि अगर डिवाइस की घंटी नहीं बज रही है, तो 0x0000 कोड लौटाया जाना चाहिए.

पुष्टि करने वाले सेगमेंट को HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01) के पहले आठ बाइट के तौर पर दिखाया जाता है.

अनचाही ट्रैकिंग के लिए सुरक्षा मोड

अनचाहा ट्रैकिंग सुरक्षा मोड का मकसद, किसी भी क्लाइंट को ऐसे डिवाइस की पहचान करने में मदद करना है जो सर्वर से कनेक्ट न करते हों. डिफ़ॉल्ट रूप से, सेवा देने वाली कंपनी को सभी आइडेंटिफ़ायर को बदलना चाहिए, जैसा कि आईडी रोटेशन में बताया गया है. Find My Device की सेवा, Find My Device नेटवर्क की मदद से ट्रैकिंग के अनचाहे सुरक्षा मोड को चालू करने का अनुरोध भेज सकती है. ऐसा करने से, सेवा देने वाली कंपनी कुछ समय के लिए एक तय MAC पते का इस्तेमाल करती है. इससे क्लाइंट को डिवाइस की पहचान करने में मदद मिलती है और उपयोगकर्ता को अनचाही ट्रैकिंग के बारे में चेतावनी दी जाती है.

बीकन के अनचाहे ट्रैकिंग सुरक्षा मोड को चालू या बंद करने के लिए, सीकर विशेषता के लिए लिखने की कार्रवाई करता है. इसमें टेबल 5 से मिला अनुरोध शामिल होता है, जिसका डेटा आईडी 0x07 या 0x08 होता है.

अनचाही ट्रैकिंग के लिए सुरक्षा मोड को चालू करते समय

सेवा देने वाली कंपनी, डेटा सेगमेंट इस तरह बनाती है:

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 कंट्रोल फ़्लैग
  • 0x01: घंटी बजने की पुष्टि वाला चरण छोड़ें. अगर नीति को सेट किया जाता है, तो अनचाहे ट्रैकिंग सुरक्षा मोड में रिंग करने के अनुरोधों की पुष्टि नहीं की जाती है.
अगर कोई फ़्लैग सेट नहीं किया जा रहा है (बाइट में शून्य का मान है), तो डेटा सेक्शन को पूरी तरह से हटाकर डेटा सेक्शन खाली करना ज़रूरी है.
फ़्लैग तब तक लागू होते हैं, जब तक अनचाहा ट्रैकिंग सुरक्षा मोड बंद नहीं किया जाता.

सेवा देने वाली कंपनी इस बात की पुष्टि करती है कि एक बार पुष्टि करने वाली कुंजी, अनचाही ट्रैकिंग सुरक्षा कुंजी से मेल खाती है या नहीं. अगर प्रोवाइडर को एफ़एमडीएन बीकन के तौर पर सेट नहीं किया गया है या पुष्टि नहीं हो पाती है, तो पुष्टि न की गई गड़बड़ी दिखेगी.

अनचाहा ट्रैकिंग सुरक्षा मोड चालू होने पर, बीकन को MAC निजी पते की रोटेशन फ़्रीक्वेंसी को हर 24 घंटे में एक बार पर कम करना चाहिए. विज्ञापन किया गया कुछ समय के लिए इस्तेमाल होने वाला आइडेंटिफ़ायर, सामान्य तरीके से बदलता रहना चाहिए. फ़्रेम टाइप 0x41 पर सेट होना चाहिए. यह स्थिति हैश किए गए फ़्लैग सेक्शन में भी दिखती है.

अनचाही ट्रैकिंग के लिए सुरक्षा मोड को बंद करते समय

सेवा देने वाली कंपनी पुष्टि करती है कि:

  • एक बार इस्तेमाल की जाने वाली पुष्टि करने वाली कुंजी, ट्रैकिंग की अनचाही सुरक्षा कुंजी से मेल खाती है.
  • हैश की गई इफ़ेमरल आइडेंटिटी कुंजी, कुछ समय के लिए प्रोफ़ाइल बनाने वाली मौजूदा कुंजी से मैच करती है.

अगर प्रोवाइडर को एफ़एमडीएन बीकन के रूप में सेट नहीं किया गया है या पुष्टि नहीं हो पाती है, तो सेवा देने वाली कंपनी बिना पुष्टि वाली गड़बड़ी दिखाती है.

अनचाहे ट्रैकिंग सुरक्षा मोड के बंद होने पर, बीकन को MAC पते को फिर से सामान्य दर पर घुमाना शुरू कर देना चाहिए. साथ ही, यह फिर से कुछ समय के लिए आइडेंटिफ़ायर के रोटेशन के साथ सिंक होना चाहिए. फ़्रेम टाइप को वापस 0x40 पर सेट किया जाना चाहिए. यह स्थिति हैश किए गए फ़्लैग सेक्शन में भी दिखती है.

सफलता मिलने पर, सेवा देने वाली कंपनी डेटा आईडी 0x07 या 0x08 के साथ टेबल 6 से जवाब मिलने पर सूचना देती है.

पुष्टि करने वाले सेगमेंट को HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01) के पहले आठ बाइट के तौर पर दिखाया जाता है.

विज्ञापन वाले फ़्रेम

प्रावधान करने के बाद, सेवा देने वाली कंपनी को हर दो सेकंड में कम से कम एक बार एफ़एमडीएन फ़्रेम का विज्ञापन देना चाहिए. अगर फ़ास्ट पेयर फ़्रेम का विज्ञापन दिखाया जाता है, तो सेवा देने वाली कंपनी को फ़ास्ट पेयर सुविधा के सामान्य विज्ञापनों में, एफ़एमडीएन फ़्रेम को इंटरलीव करना चाहिए. उदाहरण के लिए, हर दो सेकंड में, सेवा देने वाली कंपनी को सात फ़ास्ट पेयर विज्ञापन और एक एफ़एमडीएन विज्ञापन का विज्ञापन करना चाहिए.

एफ़एमडीएन फ़्रेम में एक सार्वजनिक कुंजी होती है. इसका इस्तेमाल, जगह की जानकारी की रिपोर्ट को एन्क्रिप्ट (सुरक्षित) करने के लिए किया जाता है. ऐसा ऐसे क्लाइंट के पास होता है जो क्राउडसोर्सिंग नेटवर्क में योगदान देता है. दो तरह की इलिप्टिक कर्व कुंजियां उपलब्ध हैं: लेगसी BLE 4 फ़्रेम में फ़िट होने वाली 160-बिट कुंजी या 256-बिट कुंजी, जिसके लिए लंबे समय तक विज्ञापन दिखाने की सुविधाओं के साथ BLE 5 की ज़रूरत होती है. प्रोवाइडर को लागू करने की प्रोसेस से यह तय होता है कि कौनसा कर्व इस्तेमाल किया जाएगा.

FMDN फ़्रेम को इस तरह से बनाया जाता है.

ऑक्टेट वैल्यू ब्यौरा
0 0x02 लंबाई
1 0x01 फ़्लैग किए गए डेटा टाइप की वैल्यू
2 0x06 फ़्लैग करने से जुड़ा डेटा
3 0x18 या 0x19 लंबाई
4 0x16 सेवा के डेटा टाइप की वैल्यू
5 0xAA 16-बिट सेवा का यूयूआईडी
6 0एक्सएफ़ई ...
7 0x40 या 0x41 अनचाही ट्रैकिंग सुरक्षा मोड संकेत के साथ एफ़एमडीएन फ़्रेम टाइप
8.27 20-बाइट इफ़ेमरल आइडेंटिफ़ायर
28 हैश किए गए फ़्लैग

टेबल 8: 160-बिट कर्व के साथ काम करने वाला एफ़एमडीएन फ़्रेम.

टेबल 9 में 256-बिट कर्व के लिए बाइट ऑफ़सेट और वैल्यू दिखाई गई हैं.

ऑक्टेट वैल्यू ब्यौरा
0 0x02 लंबाई
1 0x01 फ़्लैग किए गए डेटा टाइप की वैल्यू
2 0x06 फ़्लैग करने से जुड़ा डेटा
3 0x24 या 0x25 लंबाई
4 0x16 सेवा के डेटा टाइप की वैल्यू
5 0xAA 16-बिट सेवा का यूयूआईडी
6 0एक्सएफ़ई ...
7 0x40 या 0x41 अनचाही ट्रैकिंग सुरक्षा मोड संकेत के साथ एफ़एमडीएन फ़्रेम टाइप
यूरो 32-बाइट का इफ़ेमरल आइडेंटिफ़ायर
40 हैश किए गए फ़्लैग

टेबल 9: 256-बिट कर्व के साथ काम करने वाला एफ़एमडीएन फ़्रेम.

इफ़ेमरल आइडेंटिफ़ायर (ईआईडी) का कैलकुलेशन

इफ़ेमरल आइडेंटिटी कुंजी की मदद से, इस डेटा स्ट्रक्चर को एन्क्रिप्ट (सुरक्षित) करने के लिए, AES-ECB-256 से एक रैंडम जनरेट किया जाता है:

ऑक्टेट फ़ील्ड ब्यौरा
0 से 10 पैडिंग (जगह) वैल्यू = 0xFF
11 K रोटेशन पीरियड घातांक
12 से 15 TS[0]...TS[3] बीकन टाइम काउंटर, 32-बिट बिग-एंडियन फ़ॉर्मैट में. सबसे कम के बिट मिटा दिए जाते हैं.
16 से 26 पैडिंग (जगह) वैल्यू = 0x00
27 K रोटेशन पीरियड घातांक
28 से 31 TS[0]...TS[3] बीकन टाइम काउंटर, 32-बिट बिग-एंडियन फ़ॉर्मैट में. सबसे कम के बिट मिटा दिए जाते हैं.

टेबल 10: स्यूडोररैंडम नंबर बनाना.

इस कैलकुलेशन का नतीजा एक 256-बिट नंबर है, जिसे r' के तौर पर दिखाया जाता है.

बाकी गणना के लिए, SECP160R1 या SECP256R1 का इस्तेमाल इलिप्टिकल कर्व क्रिप्टोग्राफ़िक ऑपरेशन के लिए किया जाता है. एसईसी 2: सुझाए गए एलिप्टिक कर्व डोमेन पैरामीटर में कर्व की परिभाषाएं देखें. इसमें Fp, n, और G के बारे में बताया गया है.

r = r' mod n का हिसाब लगाने पर, अब r' को सीमित फ़ील्ड Fp में जोड़ा जा सकता है. आखिर में, R = r * G की गणना करें, जो इस्तेमाल की जा रही सार्वजनिक कुंजी को दिखाने वाले कर्व पर मौजूद पॉइंट है. बीकन Rx का विज्ञापन करता है, जो R के x निर्देशांक के रूप में, इसके इफ़ेमरल आइडेंटिफ़ायर के तौर पर है.

हैश किए गए फ़्लैग

हैश किए गए फ़्लैग फ़ील्ड की गिनती इस तरह की जाती है (बिट को सबसे अहम से लेकर सबसे कम अहम तक के रेफ़रंस के तौर पर इस्तेमाल किया जाता है):

  • बिट 0-4: रिज़र्व किया गया (शून्य पर सेट करें).
  • बिट 5-6, डिवाइस के लिए बैटरी लेवल के बारे में इस तरह बताते हैं:
    • 00: बैटरी लेवल संकेत काम नहीं करता
    • 01: सामान्य बैटरी लेवल
    • 10: कम बैटरी लेवल
    • 11: बैटरी का लेवल बहुत कम है (बैटरी जल्दी बदलना ज़रूरी है)
  • अगर बीकन अनचाहे ट्रैकिंग सुरक्षा मोड में है, तो बिट 7 को 1 पर सेट किया जाएगा, नहीं तो 0 पर सेट किया जाएगा.

इस बाइट की आखिरी वैल्यू बनाने के लिए, इसकी वैल्यू xor-ed है. साथ ही, यह सबसे कम SHA256(r) बाइट है.

ध्यान दें कि r को कर्व के साइज़ के हिसाब से अलाइन किया जाना चाहिए. अगर रिप्रज़ेंटेशन 160 या 256 बिट से कम है, तो शून्य को सबसे अहम बिट के तौर पर जोड़ें या सबसे अहम बिट के 160 या 256 बिट से बड़ा होने पर, सबसे अहम बिट को छोटा किया जाना चाहिए.

अगर बीकन, बैटरी स्तर संकेत के लिए काम नहीं करता है और वह अनचाहे ट्रैकिंग सुरक्षा मोड में नहीं है, तो इस बाइट को विज्ञापन से पूरी तरह हटाया जा सकता है.

ईआईडी के साथ एन्क्रिप्ट (सुरक्षित) करने का तरीका

मैसेज m को एन्क्रिप्ट करने के लिए, साइटर (इसके लिए बीकन से Rx पढ़ रहा है) को ये काम करना होगा:

  1. ईआईडी का हिसाब सेक्शन में बताए गए तरीके के मुताबिक, Fp में कोई रैंडम नंबर s चुनें.
  2. S = s * G कैलकुलेट करें.
  3. कर्व समीकरण में प्रतिस्थापन के ज़रिए R = (Rx, Ry) की गणना करें और संभावित नतीजों में से आर्बिट्ररी Ry मान चुनें.
  4. 256-बिट AES कुंजी k = HKDF-SHA256((s * R)x) का हिसाब लगाएं, जहां (s * R)x, कर्व में गुणा करने के नतीजे का x कोऑर्डिनेट है. नमक की जानकारी नहीं दी गई है.
  5. URx और LRx को बिग-एंडियन फ़ॉर्मैट में, Rx के ऊपरी और निचले 80-बिट होने दें. इसी तरह, S के लिए USx और LSx तय करें.
  6. nonce = LRx || LSx कैलकुलेट करें.
  7. (m’, tag) = AES-EAX-256-ENC(k, nonce, m) कैलकुलेट करें.
  8. मालिक को (URx, Sx, m’, tag) भेजें. ऐसा रिमोट सेवा से किया जा सकता है जिस पर भरोसा न किया जा सके.

ईआईडी की मदद से एन्क्रिप्ट की गई वैल्यू को डिक्रिप्ट करना

मालिक का क्लाइंट, जिसके पास EIK और रोटेशन पीरियड घातांक है, मैसेज को इस तरह से डिक्रिप्ट करता है:

  1. URx दिया गया, बीकन समय काउंटर मान पाएं जिस पर URx आधारित है. मालिक के क्लाइंट की मदद से, यह काम हाल ही के और आने वाले समय के लिए, बीकन टाइम काउंटर वैल्यू के लिए Rx वैल्यू की गणना कर सकता है.
  2. बीकन के समय काउंटर की उस वैल्यू के आधार पर जिस पर URx आधारित है, r की अनुमानित वैल्यू का पता लगाएं, जैसा कि ईआईडी कंप्यूटेशन सेक्शन में बताया गया है.
  3. R = r * G कंप्यूट करें और पुष्टि करने वाले व्यक्ति की ओर से दी गई URx वैल्यू से मेल खाने वाले नतीजे पाएं.
  4. कर्व समीकरण में प्रतिस्थापन के ज़रिए S = (Sx, Sy) की गणना करें और संभावित नतीजों में से आर्बिट्ररी Sy मान चुनें.
  5. k = HKDF-SHA256((r * S)x) का हिसाब लगाएं, जहां (r * S)x, कर्व को गुणा करने के नतीजे का x निर्देशांक है.
  6. nonce = LRx || LSx कैलकुलेट करें.
  7. m = AES-EAX-256-DEC(k, nonce, m’, tag) कैलकुलेट करें.

आईडी का रोटेशन

एफ़एमडीएन फ़्रेम के विज्ञापन के लिए, रिज़ॉल्व करने लायक (आरपीए) या रिज़ॉल्व न करने लायक (एनआरपीए) बीएलई पते का इस्तेमाल किया जाना चाहिए. LE Audio (LEA) डिवाइसों के लिए RPA ज़रूरी है. दूसरे डिवाइसों के लिए इसका सुझाव दिया जाता है. हालांकि, ऐसे लोकेटर टैग को छोड़कर जो बॉन्डिंग का इस्तेमाल नहीं करते, इसका सुझाव दिया जाता है.

फ़ास्ट पेयर विज्ञापन, एफ़एमडीएन विज्ञापन, और उनसे जुड़े बीएलई पते एक ही समय पर रोटेट होने चाहिए. औसतन हर 1024 सेकंड में रोटेशन होना चाहिए. जिस सटीक पॉइंट पर बीकन नए आइडेंटिफ़ायर का विज्ञापन शुरू करता है उसे विंडो में किसी भी क्रम में लगाया जाना चाहिए.

रोटेशन समय को किसी भी क्रम में लगाने का सुझाव यह है कि उसे अगले अनुमानित घूर्णन समय (अगर कोई रैंडमाइज़ेशन लागू नहीं किया गया) पर सेट करें और 1 से 204 सेकंड की रेंज में एक पॉज़िटिव रैंडम टाइम फ़ैक्टर पर सेट करें.

जब डिवाइस अनचाहे ट्रैकिंग सुरक्षा मोड में हो, तो FMDN विज्ञापन का BLE पता ठीक कर दिया जाना चाहिए. हालांकि, एफ़पी के हिसाब से न खोजे जा सकने वाले विज्ञापन (जैसे कि फ़ास्ट पेयर) के आरपीए को बार-बार घुमाना पड़ता है. अलग-अलग प्रोटोकॉल के लिए, अलग-अलग पतों का इस्तेमाल किया जा सकता है.

पावर सप्लाई बंद होने से उबरना

'कुछ समय के लिए आइडेंटिफ़ायर' को ठीक करने का काम, विज्ञापन दिखाए जाने के समय की घड़ी की वैल्यू के हिसाब से होता है. इसलिए, बिजली की कमी होने पर, सेवा देने वाली कंपनी को क्लॉक वैल्यू वापस मिलनी चाहिए. हमारा सुझाव है कि सेवा देने वाली कंपनी, दिन में कम से कम एक बार अपनी मौजूदा क्लॉक वैल्यू को ऐसी मेमोरी में लिखें जो बार-बार न बदलती हो. साथ ही, बूट करने के समय, सेवा देने वाली कंपनी एनवीएम की जांच करके पता करती है कि क्या कोई ऐसी वैल्यू मौजूद है जिससे शुरू करना है. कुछ समय के लिए इस्तेमाल होने वाले आइडेंटिफ़ायर के रिज़ॉल्वर एक ऐसी समयावधि में समाधान लागू करेंगे जो क्लॉक ड्रिफ़्ट और इस तरह की बिजली के नुकसान की भरपाई करने के लिए काफ़ी हो.

सेवा देने वाली कंपनियों को भी घड़ी के उतार-चढ़ाव को कम करने की पूरी कोशिश करनी चाहिए, क्योंकि समस्या को हल करने की समयसीमा सीमित है. घड़ी को सिंक करने का कम से कम एक और तरीका लागू किया जाना चाहिए. जैसे, खोजे न जा सकने वाले फ़ास्ट पेयर फ़्रेम के विज्ञापन दिखाना या मैसेज स्ट्रीम को लागू करना.

फ़ास्ट पेयर की सुविधा लागू करने से जुड़े दिशा-निर्देश

इस सेक्शन में, एफ़एमडीएन की सुविधा देने वाली कंपनियों पर फ़ास्ट पेयर की सुविधा लागू करने के खास पहलुओं के बारे में बताया गया है.

लोकेटर टैग से जुड़े खास दिशा-निर्देश

  • अगर प्रोवाइडर को जोड़ा गया था, लेकिन एफ़एमडीएन को पांच मिनट के अंदर इस्तेमाल नहीं किया गया था (या अगर डिवाइस को जोड़े जाने के दौरान ओटीए अपडेट लागू किया गया था, लेकिन एफ़एमडीएन का प्रावधान नहीं था), तो सेवा देने वाली कंपनी को अपने फ़ैक्ट्री कॉन्फ़िगरेशन पर वापस जाना होगा और सेव किए गए खाते की कुंजियों को मिटाना होगा.
  • सेवा देने वाली कंपनी के जुड़ जाने के बाद, उसे अपना MAC पता तब तक नहीं बदलना चाहिए, जब तक कि FMDN को सेट न किया जाए या 5 मिनट बीत जाए.
  • अगर कुछ समय के लिए पहचान वाली कुंजी को डिवाइस से हटा दिया जाता है, तो डिवाइस को फ़ैक्ट्री रीसेट करना चाहिए और सेव की गई खाता कुंजियों को भी साफ़ करना चाहिए.
  • सेवा देने वाली कंपनी को ब्लूटूथ की मदद से दूसरे डिवाइस से जोड़ने की सामान्य कोशिशों को अस्वीकार कर देना चाहिए. साथ ही, सेवा देने वाली कंपनी को सिर्फ़ फ़ास्ट पेयर की सुविधा के साथ काम करने की सुविधा को स्वीकार करना चाहिए.
  • सेवा देने वाली कंपनी को एक ऐसा तरीका शामिल करना चाहिए जिससे उपयोगकर्ता, डिवाइस को फ़ैक्ट्री रीसेट किए बिना कुछ समय के लिए विज्ञापन दिखाना बंद कर सकें. उदाहरण के लिए, बटन को एक साथ दबाकर रखना.
  • पावर सप्लाई बंद होने के बाद, डिवाइस को ऐसे फ़ास्ट पेयर फ़्रेम का विज्ञापन देना चाहिए जिनका पता नहीं लगाया जा सकता. ऐसा तब तक होगा, जब तक रीड बीकन पैरामीटर की अगली बातचीत शुरू न हो जाए. इससे सीकर डिवाइस का पता लगाता है और घड़ी को सिंक करता है, भले ही घड़ी में समय के साथ ज़्यादा बदलाव हुआ हो.
  • ऐसे फ़ास्ट पेयर फ़्रेम का विज्ञापन करते समय जिन्हें खोजा नहीं जा सकता, लेकिन यूज़र इंटरफ़ेस (यूआई) के संकेत चालू नहीं होने चाहिए.
  • अगर प्रोवाइडर को एफ़एमडीएन के लिए प्रावधान किया गया है, तो खोजे जा सकने वाले फ़ास्ट पेयर फ़्रेम का विज्ञापन नहीं दिखाया जाना चाहिए.
  • सेवा देने वाली कंपनी को, पहचान की पुष्टि करने वाली किसी भी जानकारी को बिना पुष्टि किए नहीं दिखाना चाहिए. जैसे, नाम या आइडेंटिफ़ायर.

ब्लूटूथ डिवाइस के लिए खास दिशा-निर्देश

इस सेक्शन में, एफ़एमडीएन के साथ काम करने वाले क्लासिक ब्लूटूथ डिवाइसों के खास पहलुओं के बारे में बताया गया है.

पहले से जोड़े गए डिवाइसों के लिए एफ़एमडीएन प्रॉविज़निंग

सीकर के साथ जोड़ते समय, प्रोवाइडर हमेशा एफ़एमडीएन के लिए उपलब्ध नहीं होता है. हालांकि, इसके कुछ समय बाद तक ऐसा किया जा सकता है. ऐसी स्थिति में, हो सकता है कि सेवा देने वाली कंपनी के पास GATT कनेक्शन बनाने के लिए ज़रूरी BLE MAC पता न हो. सेवा देने वाली कंपनी को इनमें से कम से कम एक तरीका उपलब्ध कराना चाहिए, ताकि सीकर को पहले से कनेक्ट होने पर भी उसका BLE पता मिल सके:

  • सेवा देने वाली कंपनी समय-समय पर फ़ास्ट पेयर खाते के डेटा का विज्ञापन दे सकती है, जिसकी मदद से नौकरी ढूंढने वाले को BLE स्कैन के ज़रिए उसका BLE पता मिल जाता है.
    यह तरीका उन कंपनियों के लिए सही है जो मैसेज स्ट्रीम को लागू नहीं करती हैं.
  • सेवा देने वाली कंपनी, क्लासिक ब्लूटूथ पर फ़ास्ट पेयर मैसेज स्ट्रीम के ज़रिए यह डेटा दे सकती है.
    यह तरीका उन कंपनियों के लिए सही है जो ब्लूटूथ पर सीकर से कनेक्ट होने पर, फ़ास्ट पेयर फ़्रेम के विज्ञापन नहीं दिखाती हैं.

दोनों तरीकों का इस्तेमाल करने से इस बात की संभावना बढ़ जाती है कि उपयोगकर्ता, एफ़एमडीएन के लिए डिवाइस का प्रावधान कर सके.

फ़ास्ट पेयर मैसेज स्ट्रीम

सेवा देने वाली कंपनी, फ़ास्ट पेयर मैसेज स्ट्रीम लागू कर सकती है और उसका इस्तेमाल, नौकरी ढूंढने वाले को डिवाइस की जानकारी के बारे में सूचना देने के लिए कर सकती है. मैसेज स्ट्रीम लागू करने पर, कुछ सुविधाएं चालू हो जाती हैं, जैसा कि इस सेक्शन में बताया गया है.

सेवा देने वाली कंपनी को हर बार मैसेज स्ट्रीम RFCOMM चैनल शुरू होने पर एक बार डिवाइस की जानकारी वाला मैसेज भेजना चाहिए.

फ़र्मवेयर वर्शन (डिवाइस की जानकारी का कोड 0x09) और ट्रैकिंग की क्षमता

जब फ़र्मवेयर अपडेट की वजह से, सेवा देने वाली कंपनी को एफ़एमडीएन की सुविधा मिलती है, तो कनेक्ट किया हुआ सीकर, उपयोगकर्ता को इस बारे में सूचना दे सकता है और उसका प्रावधान करने का विकल्प दे सकता है. ऐसा न होने पर, एफ़एमडीएन को सेट अप करने के लिए, उपयोगकर्ता को मैन्युअल तरीके से ब्लूटूथ डिवाइस की सूची पर जाना होगा.

इसकी अनुमति देने के लिए, सेवा देने वाली कंपनी को फ़र्मवेयर वर्शन प्रॉपर्टी (कोड 0x09) का इस्तेमाल करके, फ़र्मवेयर वर्शन के बारे में बताने वाली स्ट्रिंग की वैल्यू रिपोर्ट करनी चाहिए. इसके अलावा, सेवा देने वाली कंपनी को उस प्रोटोकॉल के साथ भी काम करना चाहिए जो फ़र्मवेयर अपडेट की वजह से, सीकर को क्षमता में होने वाले बदलावों के बारे में बताता है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 डिवाइस की जानकारी से जुड़ा इवेंट 0x03
1 uint8 फ़र्मवेयर का वर्शन 0x09
2 से 3 uint16 अतिरिक्त डेटा लंबाई अलग-अलग
var बाइट अरे वर्शन स्ट्रिंग अलग-अलग

टेबल 11: डिवाइस की जानकारी से जुड़ा इवेंट: फ़र्मवेयर का अपडेट किया गया वर्शन.

क्षमता अपडेट करने का अनुरोध (0x0601) मिलने पर, अगर सेवा देने वाली कंपनी ने एफ़एमडीएन ट्रैकिंग के लिए सहायता चालू की हुई है, तो उसे टेबल 12 में दिखाए गए तरीके के मुताबिक जवाब देना चाहिए.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 डिवाइस की क्षमता का सिंक इवेंट 0x06
1 uint8 एफ़एमडीएन ट्रैकिंग 0x03
2 से 3 uint16 अतिरिक्त डेटा लंबाई 0x0007
4 uint8 एफ़एमडीएन प्रावधान की स्थिति प्रावधान नहीं होने पर 0x00; अगर किसी खाते से प्रावधान किया गया है, तो 0x01
5 - 10 बाइट अरे डिवाइस का मौजूदा BLE MAC पता अलग-अलग

टेबल 12: डिवाइस की क्षमता को सिंक करने का इवेंट: अतिरिक्त ट्रैकिंग सुविधा.

कुछ समय के लिए इस्तेमाल होने वाला मौजूदा आइडेंटिफ़ायर (डिवाइस की जानकारी का कोड 0x0B)

एफ़एमडीएन के लिए सेवा देने वाली कंपनी के पास, मौजूदा ईआईडी और क्लॉक वैल्यू की रिपोर्ट करने के लिए, मौजूदा कुछ समय के लिए आइडेंटिफ़ायर (कोड 0x0B) का इस्तेमाल करने का विकल्प होता है. ऐसा, क्लॉक ड्रिफ़्ट (उदाहरण के लिए, बैटरी खत्म होने की वजह से) में सीकर को सिंक करने के लिए किया जा सकता है. अगर ऐसा नहीं है, तो इस मकसद के लिए सीकर ज़्यादा महंगा और कम भरोसेमंद कनेक्शन शुरू करता है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 डिवाइस की जानकारी से जुड़ा इवेंट 0x03
1 uint8 कुछ समय के लिए सेव किया गया मौजूदा आइडेंटिफ़ायर 0x0 अरब
2 से 3 uint16 अतिरिक्त डेटा लंबाई 0x0018 या 0x0024
4 से 7 बाइट अरे घड़ी का मान उदाहरण: 0x13F9EA80
8 - 19 या 31 बाइट अरे मौजूदा ईआईडी उदाहरण: 0x1122334455667788990011223344556677889900

टेबल 13: डिवाइस की जानकारी से जुड़ा इवेंट: घड़ी सिंक.

फ़ैक्ट्री रीसेट करें

फ़ैक्ट्री रीसेट की सुविधा वाले डिवाइस के लिए: अगर फ़ैक्ट्री रीसेट किया जाता है, तो सेवा देने वाली कंपनी को बीकन बंद करना होगा और मालिक की खाता कुंजी के साथ ही, कुछ समय के लिए इस्तेमाल की जाने वाली पहचान कुंजी और सेव किए गए सभी खाता कुंजियों को मिटाना होगा.

फ़ैक्ट्री रीसेट (मैन्युअल या प्रोग्राम के हिसाब से) के बाद, सेवा देने वाली कंपनी को फ़ास्ट पेयर की सुविधा का विज्ञापन तुरंत शुरू नहीं करना चाहिए, ताकि उपयोगकर्ता के डिवाइस को मिटाए जाने के तुरंत बाद दूसरे डिवाइस से जोड़ने का फ़्लो शुरू न हो.

अनचाही ट्रैकिंग से बचाव

सर्टिफ़ाइड एफ़एमडीएन डिवाइसों को भी यह ज़रूरी है कि वे अनचाही लोकेशन ट्रैकर की पहचान करने (डीयूएलटी) के लिए, क्रॉस-प्लैटफ़ॉर्म स्पेसिफ़िकेशन के लागू वर्शन की ज़रूरी शर्तों को पूरा करते हों.

DULT की खासियतों का पालन करने के लिए, एफ़एमडीएन से जुड़े खास दिशा-निर्देश:

  • एफ़एमडीएन के साथ काम करने वाला कोई भी डिवाइस, Nearby Device Console में रजिस्टर होना चाहिए. साथ ही, उस डिवाइस में "Find My Device" सुविधा चालू होनी चाहिए.
  • डिवाइस को ऐसी ऐक्सेसरी लागू करनी होगी जो बिना मालिक वाली सेवा और सुविधाओं को लागू करती है. ये सुविधाएं, DULT स्पेसिफ़िकेशन के लागू किए गए वर्शन में बताई गई हैं. इनमें ऐक्सेसरी की जानकारी से जुड़ी कार्रवाइयां और बिना मालिक वाले कंट्रोल भी शामिल हैं.
  • पुराने सिस्टम के साथ काम करने की अवधि के दौरान, जैसा कि DULT स्पेसिफ़िकेशन में बताया गया है, इस दस्तावेज़ में बताए गए तरीके से विज्ञापन वाले फ़्रेम में कोई बदलाव नहीं होता.
  • इस दस्तावेज़ में बताया गया "अनचाहा ट्रैकिंग सुरक्षा मोड", DULT स्पेसिफ़िकेशन में बताए गए "अलग किए गए स्टेटस" से मैप किया गया है.
  • ऐक्सेसरी जानकारी ऑपकोड को लागू करने के लिए दिशा-निर्देश:
    • Get_Product_Data को कंसोल से मिले मॉडल आईडी को लौटाना चाहिए, जिसमें 8-बाइट की ज़रूरी शर्त को पूरा करने के लिए कोई पैड नहीं जोड़ा गया हो. उदाहरण के लिए, मॉडल आईडी 0xFFFFFF को 0x0000000000FFFFFF के तौर पर दिखाया जाता है.
    • Get_Manufacturer_Name और Get_Model_Name, कंसोल में दी गई वैल्यू से मेल खाने चाहिए.
    • अगर कोई भी दूसरी कैटगरी, डिवाइस के टाइप के हिसाब से बेहतर नहीं है, तो Get_Accessory_Category सामान्य "Location Tracker" वैल्यू दिखा सकता है.
    • Get_Accessory_Capabilities में रिंगिंग के साथ-साथ BLE आइडेंटिफ़ायर लुकअप के बारे में जानकारी होनी चाहिए.
    • Get_Network_ID को Google का आइडेंटिफ़ायर (0x02) दिखाना चाहिए.
  • Get_Identifier ऑपकोड को लागू करने के लिए दिशा-निर्देश:
    • उपयोगकर्ता के 'पहचान' मोड चालू करने के बाद, इस कार्रवाई से सिर्फ़ 5 मिनट के लिए मान्य रिस्पॉन्स मिलना चाहिए. इसके लिए, कई बटन दबाकर रखने की ज़रूरत होती है. विज़ुअल या ऑडियो सिग्नल से, उपयोगकर्ता को पता चलना चाहिए कि सेवा देने वाली कंपनी ने वह मोड चालू किया है. इस मोड को चालू करने के लिए, खास तौर पर Google को निर्देश दिए जाने चाहिए. ये निर्देश, सर्टिफ़िकेशन के लिए ज़रूरी होने पर ही दिए जाने चाहिए. साथ ही, निर्देशों में किसी भी तरह के बदलाव या बदलाव करने से कम से कम 10 दिन पहले ये निर्देश दिए जाने चाहिए.
    • रिस्पॉन्स, इस तरह से तैयार किया जाता है: कम समय के मौजूदा आइडेंटिफ़ायर के पहले 10 बाइट और इसके बाद, HMAC-SHA256(recovery key, the truncated current ephemeral identifier) के पहले 8 बाइट.
  • Sound_Start ऑपकोड को लागू करने के लिए दिशा-निर्देश:
    • निर्देश से सभी उपलब्ध कॉम्पोनेंट में घंटी बजनी चाहिए.
    • तय सीमा से ज़्यादा वॉल्यूम का इस्तेमाल किया जाना चाहिए.
    • हम 12 सेकंड तक की घंटी बजने का सुझाव देते हैं.
  • लोकेटर टैग में एक ऐसा तरीका होना चाहिए जिससे उपयोगकर्ता, डिवाइस को फ़ैक्ट्री रीसेट किए बिना कुछ समय के लिए विज्ञापन दिखाना बंद कर दें (उदाहरण के लिए, बटन को एक साथ दबाकर रखना).
    • खाता बंद करने से जुड़े निर्देशों को सार्वजनिक तौर पर उपलब्ध यूआरएल में दर्ज किया जाना चाहिए. साथ ही, सर्टिफ़िकेशन के लिए इस जानकारी को Google को देना ज़रूरी है. किसी भी तरह के अपडेट या निर्देशों में बदलाव किए जाने से कम से कम 10 दिन पहले यह जानकारी Google को दी जानी चाहिए.
    • यूआरएल में स्थानीय भाषा के हिसाब से काम करना चाहिए. क्लाइंट के आधार पर, भाषा को क्वेरी पैरामीटर ("hl=hi") के तौर पर या "accept-language" एचटीटीपी हेडर का इस्तेमाल करके दिया जाएगा.

स्विच किए जा सकने वाले प्रोटोकॉल के दिशा-निर्देश

  • एक बार में सिर्फ़ एक प्रोटोकॉल का इस्तेमाल किया जाना चाहिए. पक्का करें कि डिवाइस पर एक साथ एक से ज़्यादा नेटवर्क काम न कर सकते हों. इस ज़रूरी शर्त से यह पक्का होता है कि अलग-अलग प्रोटोकॉल के बीच, उपयोगकर्ता का संवेदनशील डेटा एक साथ न इकट्ठा हो.
  • हमारा सुझाव है कि डिवाइस में हार्ड रीसेट वर्कफ़्लो को शामिल करें. इससे उपयोगकर्ता, किसी दूसरे नेटवर्क पर डिवाइस को फिर से सेट अप कर पाएंगे.
  • डिवाइस को नेटवर्क पर अपडेट करने की प्रोसेस, उपयोगकर्ता के लिए आसान होनी चाहिए. साथ ही, यह प्रोसेस नेटवर्क पर बराबर होनी चाहिए. उपयोगकर्ता के पास किसी भी नेटवर्क को प्राथमिकता दिए बिना, यह चुनने की सुविधा होनी चाहिए कि वह किस नेटवर्क का इस्तेमाल करना चाहता है. इस फ़्लो को Google टीम से मंज़ूरी मिलना ज़रूरी है.

फ़र्मवेयर से जुड़े अपडेट

ओटीए अपडेट की प्रोसेस और डिस्ट्रिब्यूशन, पार्टनर को अपने मोबाइल या वेब ऐप्लिकेशन वर्कफ़्लो का इस्तेमाल करना चाहिए.

इनके साथ काम करता है

Find My Device का नेटवर्क इस्तेमाल करने के लिए, जगह की जानकारी वाली सेटिंग और ब्लूटूथ चालू करना ज़रूरी है. इसके लिए, मोबाइल नेटवर्क या इंटरनेट कनेक्शन ज़रूरी है. यह सुविधा Android 9 या इसके बाद के वर्शन पर काम करती है. यह सुविधा कुछ देशों में, उम्र से जुड़ी ज़रूरी शर्तें पूरी करने वाले उपयोगकर्ताओं के लिए उपलब्ध है.

बदलावों का लॉग

एफ़एमडीएन वर्शन तारीख टिप्पणी
v1 रिलीज़ होने से पहले इस्तेमाल करने के लिए, एफ़एमडीएन की खास जानकारी की शुरुआती रिलीज़.
v1.1 Feb 2023
  • अनचाही ट्रैकिंग सुरक्षा मोड का एक cleartext संकेत जोड़ा गया है.
  • अनचाहे ट्रैकिंग सुरक्षा मोड में होने पर, रिंग करने वाले अनुरोधों की पुष्टि करने की प्रक्रिया को छोड़ने के लिए एक विकल्प जोड़ा गया.
v1.2 अप्रैल 2023
  • मालिक की AK की परिभाषा अपडेट की गई.
  • लोकेटर टैग में, पावर सप्लाई की समस्या को ठीक करने के लिए सुझाव जोड़ा गया.
  • एमएसी पते को किसी भी क्रम में लगाने के बारे में साफ़ तौर पर जानकारी जोड़ी गई.
  • अनचाही ट्रैकिंग सुरक्षा मोड में होने पर, MAC पते के रोटेशन के बारे में साफ़ तौर पर जानकारी जोड़ी गई.
  • लोकेटर टैग को बंद करने के तरीके के बारे में दिशा-निर्देश जोड़ा गया.
v1.3 दिसंबर 2023
  • लोकेटर टैग से बिना अनुमति के सार्वजनिक की गई जानकारी को पहचानने के बारे में साफ़ तौर पर बताया गया है.
  • अनचाही ट्रैकिंग को रोकने के लिए बनी खास जानकारी को लागू करने के लिए, एक शर्त जोड़ी गई.
  • स्विच किए जा सकने वाले प्रोटोकॉल डिवाइसों के लिए, दिशा-निर्देश जोड़े गए.