इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

v1.3

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

GATT स्पेसिफ़िकेशन

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

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

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

पुष्टि करना

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

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

हर बार डेटा पढ़ने पर, एक अलग नॉन्स जनरेट होना चाहिए. साथ ही, एक नॉन्स सिर्फ़ एक बार इस्तेमाल किया जा सकता है. अगर कार्रवाई पूरी नहीं हो पाती है, तब भी नॉन्स को अमान्य कर देना चाहिए.

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

खाता कुंजी: फ़ास्ट पेयर खाता कुंजी, जो 16 बाइट की होती है. इसकी जानकारी, फ़ास्ट पेयर की खास जानकारी में दी गई है.

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

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

कुछ समय के लिए मान्य पहचान कुंजी (EIK): यह 32-बाइट की एक कुंजी होती है, जिसे FMDN की प्रोवाइज़निंग प्रोसेस के दौरान, खोजकर्ता अपने हिसाब से चुनता है. इस कुंजी का इस्तेमाल, क्रिप्टोग्राफ़ी पासकोड बनाने के लिए किया जाता है. इन पासकोड का इस्तेमाल, जगह की जानकारी वाली रिपोर्ट को एंड-टू-एंड एन्क्रिप्ट (E2EE) करने के लिए किया जाता है. Searcher, इसे कभी भी बैकएंड को नहीं दिखाता.

रिकवरी पासकोड: इसे SHA256(ephemeral identity key || 0x01) के तौर पर तय किया गया है. इसे पहले आठ बाइट तक काट दिया गया है. पासकोड को बैकएंड पर सेव किया जाता है. साथ ही, खोज करने वाला व्यक्ति ईआईके को वापस पाने के लिए इसका इस्तेमाल कर सकता है. हालांकि, इसके लिए ज़रूरी है कि उपयोगकर्ता डिवाइस पर बटन दबाकर सहमति दे.
रिंग बटन की कुंजी: इसे SHA256(ephemeral identity key || 0x02) के तौर पर तय किया गया है. इसमें पहले आठ बाइट का इस्तेमाल किया जाता है. यह कुंजी बैकएंड पर सेव होती है और खोजने वाला व्यक्ति इसका इस्तेमाल सिर्फ़ डिवाइस को रिंग करने के लिए कर सकता है.
अनचाही ट्रैकिंग रोकने वाली कुंजी: इसे SHA256(ephemeral identity key || 0x03) के तौर पर दिखाया जाता है. इसमें पहले आठ बाइट काट दिए जाते हैं. पासकोड, बैकएंड पर सेव होता है. साथ ही, खोज करने वाला व्यक्ति इसका इस्तेमाल सिर्फ़ अनचाही ट्रैकिंग से सुरक्षा मोड को चालू करने के लिए कर सकता है.

ऑपरेशंस

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

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
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)` के पहले आठ बाइट
10 - var	बाइट ऐरे	अतिरिक्त डेटा	0x00: लागू नहीं 0x01: लागू नहीं 0x02: 32 बाइट, जो कुछ समय के लिए मान्य रहने वाली पहचान कुंजी होती है. इसे खाता कुंजी से एईएस-ईसीबी-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)` के पहले आठ बाइट

दूसरी टेबल: बीकन की जानकारी देने का अनुरोध.

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
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)` के पहले आठ बाइट

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

ऑक्टेट	डेटा टाइप	ब्यौरा	मान
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)` के पहले आठ बाइट
10 - var	बाइट अरे	अतिरिक्त डेटा	0x05: चार बाइट, जिनसे घंटी बजने की स्थिति, घंटी बजने की अवधि, और घंटी की आवाज़ के बारे में पता चलता है. 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)` के पहले आठ बाइट
10 - var	बाइट ऐरे	अतिरिक्त डेटा	0x07: कंट्रोल फ़्लैग का एक बाइट (ज़रूरी नहीं) 0x08: `SHA256(ephemeral identity key \|\| the last nonce read from the characteristic)` के पहले आठ बाइट

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

टेबल 6 में दी गई सूची के मुताबिक, डेटा लिखने पर सूचनाएं ट्रिगर होती हैं.

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

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

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

टेबल 7 में, उन संभावित GATT गड़बड़ी कोड की सूची दी गई है जो ऑपरेशन से रिटर्न किए जाते हैं.

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

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

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

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

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

पुष्टि हो जाने पर, प्रोवाइडर टेबल 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) के पहले आठ बाइट के तौर पर परिभाषित किया गया है.

बीकन की प्रॉविज़निंग की स्थिति देखना

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

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

पुष्टि हो जाने पर, प्रोवाइडर टेबल 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) के पहले आठ बाइट के तौर पर परिभाषित किया गया है.

कुछ समय के लिए मान्य आइडेंटिटी पासकोड सेट करना

सेवा देने वाली जिस कंपनी के लिए अभी तक प्रावधान नहीं किया गया है उसे FMDN बीकन के तौर पर प्रावधान करने या पहले से प्रावधान की गई सेवा देने वाली कंपनी की कुछ समय के लिए मान्य पहचान कुंजी को बदलने के लिए, खोजने वाला डिवाइस, टेबल 2 से मिले अनुरोध के साथ, डेटा आईडी 0x02 वाले चैरेक्टरिस्टिक में लिखने की कार्रवाई करता है. सेवा देने वाली कंपनी यह पुष्टि करती है कि:

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

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

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

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

कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी कुंजी मिटाना

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

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

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

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

उपयोगकर्ता की सहमति लेकर, कुछ समय के लिए मान्य पहचान कुंजी को पढ़ना

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

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

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

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

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

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

रिंगिंग शुरू होने या खत्म होने पर, सूचना भेजी जाती है. इसकी जानकारी, टेबल 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 अनुरोध) में से कोई एक सूचना भेजनी चाहिए. यह अनुरोध, मौजूदा स्थिति के पैरामीटर को बदल देता है, ताकि घंटी बजने की अवधि को बढ़ाया जा सके.

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

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

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

बीकन के बजने की स्थिति जानना

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

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

पुष्टि हो जाने पर, प्रोवाइडर टेबल 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: रिंग होने पर पुष्टि करने की सुविधा को छोड़ें. सेट होने पर, अनचाहे ट्रैकिंग से बचाव मोड चालू होने पर, कॉल आने पर घंटी बजाने के अनुरोधों की पुष्टि नहीं की जाती. अगर कोई फ़्लैग सेट नहीं किया जा रहा है (बाइट में सभी शून्य हैं), तो डेटा सेक्शन को पूरी तरह से हटाकर, खाली डेटा सेक्शन भेजा जा सकता है. फ़्लैग तब तक लागू रहते हैं, जब तक अनचाहे ट्रैकिंग से सुरक्षा मोड बंद नहीं किया जाता.

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

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

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

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

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

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

पुष्टि हो जाने पर, प्रोवाइडर टेबल 6 से डेटा आईडी 0x07 या 0x08 के साथ जवाब देकर सूचना देता है.

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

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

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

FMDN विज्ञापनों के लिए, ब्लूटूथ की ट्रांसमिट पावर को कम से कम 0 dBm पर सेट किया जाना चाहिए.

ध्यान दें: हमारा सुझाव है कि डिवाइस के कम बैटरी मोड में होने पर भी, एफ़एमडीएन फ़्रेम का विज्ञापन दिखाएं. इससे, डिवाइस के खो जाने पर उसे ढूंढा जा सकता है. कुछ डिवाइसों के लिए, बैटरी लाइफ़ पर असर पड़ने की वजह से, डिवाइस बंद होने पर विज्ञापन नहीं दिखाया जा सकता. ऐसे मामलों में, हमारा सुझाव है कि डिवाइस को समय-समय पर चालू करें और कुछ समय के लिए विज्ञापन दिखाएं. उदाहरण के लिए, हर 10 मिनट में डिवाइस को चालू करें और 10 सेकंड के लिए विज्ञापन दिखाएं.

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

FMDN फ़्रेम का स्ट्रक्चर इस तरह का होता है.

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

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

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

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

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

कुछ समय के लिए लागू होने वाला आइडेंटिफ़ायर (ईआईडी) कैलकुलेट करना

एईएस-ईसीबी-256, नीचे दिए गए डेटा स्ट्रक्चर को अस्थायी पहचान की कुंजी के साथ एन्क्रिप्ट करके, एक रैंडम जनरेट करता है:

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

टेबल 10: बनावटी यादृच्छिक संख्या बनाना.

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

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

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

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

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

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

इस बाइट की फ़ाइनल वैल्यू बनाने के लिए, इसे SHA256(r) के सबसे कम अहम बाइट के साथ एक्सओआर किया जाता है.

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

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

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

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

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

EID से एन्क्रिप्ट (सुरक्षित) की गई वैल्यू को डिक्रिप्ट (सुरक्षित) करना

मालिकाना हक रखने वाले व्यक्ति का क्लाइंट, ईआईके और रोटेशन पीरियड के एक्सपोनेंट का इस्तेमाल करके, मैसेज को इस तरह डिक्रिप्ट करता है:

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

आईडी रोटेशन

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

फ़ास्ट पेयर विज्ञापन, FMDN विज्ञापन, और उससे जुड़े BLE ऐड्रेस एक ही समय पर रोटेट होने चाहिए. रोटेशन औसतन हर 1,024 सेकंड में होना चाहिए. विंडो के दौरान, बीकन को नए आइडेंटिफ़ायर का विज्ञापन दिखाने के लिए, समय को रैंडमाइज़ किया जाना चाहिए.

रोटेशन के समय को रैंडम करने के लिए, हमारा सुझाव है कि आप इसे अगले रोटेशन के अनुमानित समय पर सेट करें. अगर रोटेशन के समय को रैंडम नहीं किया गया है, तो इसे 1 से 204 सेकंड के बीच के किसी भी समय पर सेट किया जा सकता है.

जब डिवाइस, अनचाही ट्रैकिंग से सुरक्षा मोड में हो, तो FMDN विज्ञापन का बीएलई पता तय होना चाहिए. हालांकि, फ़ास्ट पेयर जैसे ऐसे विज्ञापन के लिए आरपीए, जिसे ढूंढा नहीं जा सकता, उसे बदलते रहना चाहिए. अलग-अलग प्रोटोकॉल के लिए, अलग-अलग पतों का इस्तेमाल किया जा सकता है.

बिजली बंद होने पर रिकवरी

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

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

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

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

लोकेटर टैग के लिए खास दिशा-निर्देश

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

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

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

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

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

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

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

फ़ास्ट पेयर की सुविधा से मैसेज स्ट्रीम करना

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

डीयूएलटी स्पेसिफ़िकेशन का पालन करने के लिए, एफ़एमडीएन से जुड़े काम के दिशा-निर्देश:

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

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

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

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

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

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

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

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

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

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

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

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