v1.3
Find Hub Network (FHN) ऐक्सेसरी स्पेसिफ़िकेशन, बीकन वाले ब्लूटूथ स्मार्ट (बीएलई) डिवाइसों को ट्रैक करने के लिए, पूरी तरह सुरक्षित तरीका तय करता है. इस पेज पर, FHN को Fast Pair की खास बातों के एक्सटेंशन के तौर पर बताया गया है. अगर सेवा देने वाली कंपनियों के पास ऐसे डिवाइस हैं जो FHN के साथ काम करते हैं और वे उन डिवाइसों के लिए जगह की जानकारी ट्रैक करने की सुविधा चालू करना चाहती हैं, तो उन्हें इस एक्सटेंशन को चालू करना चाहिए.
GATT की खास बातें
Fast Pair सेवा में, सामान्य एट्रिब्यूट (GATT) की एक और विशेषता जोड़ी जानी चाहिए. इसका सिमैंटिक इस तरह होना चाहिए:
फ़ास्ट पेयर सेवा की विशेषता | एन्क्रिप्ट (सुरक्षित) किया गया है | अनुमतियां | यूयूआईडी |
---|---|---|---|
बीकन ऐक्शन | नहीं | पढ़ने, लिखने, और सूचना पाने का ऐक्सेस | FE2C1238-8366-4814-8EB0-01DE32100BEA |
टेबल 1: FHN के लिए Fast Pair Service की विशेषताएं.
पुष्टि करना
इस एक्सटेंशन के लिए ज़रूरी कार्रवाइयां, लिखने की कार्रवाई के तौर पर की जाती हैं. इन्हें चुनौती-जवाब के तरीके से सुरक्षित किया जाता है. कोई भी कार्रवाई करने से पहले, सीक करने वाले व्यक्ति को टेबल 1 में मौजूद विशेषता से रीड ऑपरेशन करना होता है. इससे बफ़र इस फ़ॉर्मैट में दिखता है:
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | प्रोटोकॉल के मेजर वर्शन का नंबर | 0x01 |
1 - 8 | बाइट अरे | एक बार इस्तेमाल किया जाने वाला रैंडम नॉनस | अलग-अलग होती है |
हर रीड ऑपरेशन से अलग नॉनस जनरेट होना चाहिए. साथ ही, एक नॉनस सिर्फ़ एक ऑपरेशन के लिए मान्य होना चाहिए. अगर ऑपरेशन पूरा नहीं होता है, तब भी नॉनस को अमान्य किया जाना चाहिए.
इसके बाद, Seeker एक बार इस्तेमाल की जा सकने वाली पुष्टि करने वाली कुंजी का हिसाब लगाता है. इसका इस्तेमाल, बाद में किए जाने वाले राइट अनुरोध में किया जाता है. प्रमाणीकरण कुंजी का हिसाब, टेबल 2 से 5 में दिए गए तरीके से लगाया जाता है. जिस ऑपरेशन का अनुरोध किया जा रहा है उसके आधार पर, अनुरोध करने वाला व्यक्ति यहां दी गई एक या उससे ज़्यादा कुंजियों की जानकारी देता है:
खाते की कुंजी: यह 16 बाइट की फ़ास्ट पेयर खाते की कुंजी होती है. इसके बारे में फ़ास्ट पेयर के स्पेसिफ़िकेशन में बताया गया है.
मालिक खाते की कुंजी: जब कोई नौकरी ढूंढने वाला व्यक्ति पहली बार Beacon Actions की सुविधा को ऐक्सेस करता है, तब सेवा देने वाली कंपनी, मौजूदा खाता कुंजियों में से किसी एक को मालिक खाते की कुंजी के तौर पर चुनती है. चुने गए मालिकाना हक वाले खाते की कुंजी को तब तक नहीं बदला जा सकता, जब तक कि Provider को फ़ैक्ट्री रीसेट न कर दिया जाए. अगर वित्तीय सेवा देने वाली कंपनी या बैंक के पास, मुफ़्त में खाता कुंजी के स्लॉट खत्म हो जाते हैं, तो उसे मालिक के खाते की कुंजी नहीं हटानी चाहिए.
पहली बार पेयर करने पर, जो प्रोवाइडर पहले से ही FHN की सुविधा के साथ काम करते हैं या फ़ैक्ट्री रीसेट के बाद पेयर करने पर इस सुविधा के साथ काम करते हैं वे पहले खाते की कुंजी चुनते हैं. ऐसा इसलिए, क्योंकि पेयरिंग के दौरान, जब सीक करने वाला डिवाइस प्रोविज़निंग की स्थिति को पढ़ता है, तब यही एकमात्र मौजूदा खाता कुंजी होती है.
अगर किसी सेवा देने वाली कंपनी को डिवाइस को पहले से पेयर करने के बाद FHN की सुविधा मिलती है (उदाहरण के लिए, फ़र्मवेयर अपडेट के ज़रिए), तो वह मौजूदा खाता कुंजी में से कोई भी कुंजी चुन सकती है. फ़र्मवेयर अपडेट के बाद, पहली खाता कुंजी को चुनना सही है. इसका इस्तेमाल, बीकन ऐक्शन की विशेषता से प्रोविज़निंग की स्थिति को पढ़ने के लिए किया जाता है. ऐसा तब किया जाता है, जब अपडेट करने वाला उपयोगकर्ता, सेवा देने वाली कंपनी का मौजूदा मालिक हो.
एफ़ेमरल आइडेंटिटी की (ईआईके): यह 32 बाइट की एक ऐसी कुंजी होती है जिसे सीक करने वाला डिवाइस, FHN की सुविधा चालू करने की प्रोसेस के दौरान रैंडम तरीके से चुनता है. इस कुंजी का इस्तेमाल, क्रिप्टोग्राफ़िक कुंजियां पाने के लिए किया जाता है. इनका इस्तेमाल, जगह की जानकारी की रिपोर्ट को एंड-टू-एंड एन्क्रिप्ट (सुरक्षित) करने के लिए किया जाता है. सीकर, इसे कभी भी बैकएंड को नहीं दिखाता है.
ऐक्सेस वापस पाने की कुंजी: इसे
SHA256(ephemeral identity key || 0x01)
के तौर पर तय किया गया है. इसे पहले आठ बाइट में छोटा किया गया है. यह कुंजी बैकएंड पर सेव की जाती है. साथ ही, Seeker इसका इस्तेमाल EIK को वापस पाने के लिए कर सकता है. हालांकि, इसके लिए उपयोगकर्ता को डिवाइस पर मौजूद बटन दबाकर सहमति देनी होगी.रिंग की: इसे
SHA256(ephemeral identity key || 0x02)
के तौर पर तय किया जाता है. इसे पहले आठ बाइट तक छोटा किया जाता है. यह कुंजी बैकएंड पर सेव की जाती है. इसे ढूंढने वाला व्यक्ति सिर्फ़ डिवाइस को बजाने के लिए इस्तेमाल कर सकता है.ट्रैकिंग से सुरक्षा देने वाली अवांछित कुंजी: इसे इस तरह से तय किया जाता है
SHA256(ephemeral identity key || 0x03)
. इसे पहले आठ बाइट में छोटा किया जाता है. यह कुंजी बैकएंड पर सेव की जाती है. नौकरी ढूंढने वाला व्यक्ति इसका इस्तेमाल सिर्फ़ अनचाही ट्रैकिंग से सुरक्षा मोड को चालू करने के लिए कर सकता है.
कार्रवाइयां
टेबल 2 से 5 में, कैरेक्टरिस्टिक में लिखे गए डेटा का फ़ॉर्मैट दिया गया है. इस सेक्शन में, हर ऑपरेशन के बारे में ज़्यादा जानकारी दी गई है.
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | डेटा आईडी |
|
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 - var | बाइट अरे | अतिरिक्त डेटा |
|
टेबल 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 बाइट |
तीसरी टेबल: बीकन की प्रोविज़निंग कुंजी को वापस पाने का अनुरोध.
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | डेटा आईडी |
|
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 - var | बाइट अरे | अतिरिक्त डेटा |
|
चौथी टेबल: कॉल करने का अनुरोध.
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | डेटा आईडी |
|
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 - var | बाइट अरे | अतिरिक्त डेटा |
|
पांचवीं टेबल: अनचाही ट्रैकिंग से सुरक्षा पाने का अनुरोध.
लिखने की प्रोसेस पूरी होने पर, टेबल 6 में दी गई सूचनाएं ट्रिगर होती हैं.
0x05: रिंग की स्थिति में बदलाव के अलावा किसी अन्य डेटा आईडी वाली सूचनाएं, सूचना ट्रिगर करने वाले राइट लेन-देन के पूरा होने से पहले भेजी जानी चाहिए. इसका मतलब है कि राइट अनुरोध के लिए रिस्पॉन्स पीडीयू भेजे जाने से पहले सूचनाएं भेजी जानी चाहिए.
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | डेटा आईडी |
|
1 | uint8 | डेटा का साइज़ | अलग-अलग होती है |
2 - 9 | बाइट अरे | पुष्टि करना | हर ऑपरेशन के हिसाब से ज़्यादा जानकारी |
10 - var | बाइट अरे | अतिरिक्त डेटा |
|
टेबल 6: बीकन सेवा की प्रतिक्रिया.
टेबल 7 में, कार्रवाइयों से मिलने वाले संभावित GATT गड़बड़ी कोड दिए गए हैं.
कोड | ब्यौरा | नोट |
---|---|---|
0x80 | प्रमाणीकृत नहीं किया गया | यह तब दिखता है, जब पुष्टि करने में गड़बड़ी होती है. ऐसा तब भी होता है, जब पुराने नॉनस का इस्तेमाल किया गया हो. |
0x81 | अमान्य मान | यह तब दिखता है, जब कोई अमान्य वैल्यू दी गई हो या मिले हुए डेटा में बाइट की संख्या उम्मीद से ज़्यादा हो. |
0x82 | उपयोगकर्ता की सहमति नहीं ली गई | यह तब दिखता है, जब डिवाइस पेयरिंग मोड में न हो और डेटा आईडी 0x04: Read ephemeral identity key with user consent के साथ राइट अनुरोध के जवाब में दिखाया गया हो. |
टेबल 7: GATT के गड़बड़ी कोड.
बीकन के पैरामीटर को पढ़ना
सीकर, प्रोवाइडर से बीकन के पैरामीटर के बारे में क्वेरी कर सकता है. इसके लिए, उसे टेबल 2 में दिए गए अनुरोध के साथ डेटा आईडी 0x00 वाली विशेषता पर राइट ऑपरेशन करना होगा. Provider यह पुष्टि करता है कि एक बार पुष्टि करने के लिए दी गई कुंजी, डिवाइस पर सेव की गई किसी भी खाता कुंजी से मेल खाती है.
पुष्टि न होने पर, प्रोवाइडर पुष्टि न होने से जुड़ी गड़बड़ी का मैसेज दिखाता है.
अगर अनुरोध पूरा हो जाता है, तो सेवा देने वाली कंपनी, टेबल 6 में दिए गए जवाब के साथ सूचना देती है. इसमें डेटा आईडी 0x00 होता है. डेटा उपलब्ध कराने वाली कंपनी, डेटा सेगमेंट को इस तरह बनाती है:
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | कैलिब्रेट की गई पावर | 0 मीटर पर मिली कैलिब्रेट की गई पावर (यह वैल्यू [-100, 20] की रेंज में होती है). इसे पूर्णांक के तौर पर दिखाया जाता है. इसकी रिज़ॉल्यूशन 1 dBm होती है. |
1 - 4 | uint32 | घड़ी की वैल्यू | सेकंड में घड़ी की मौजूदा वैल्यू (बिग एंडियन). |
5 | uint8 | कर्व चुनना | एन्क्रिप्शन के लिए इस्तेमाल किया जा रहा इलिप्टिक कर्व:
|
6 | uint8 | घटक | घंटी बजाने की सुविधा वाले कॉम्पोनेंट की संख्या:
|
7 | uint8 | घंटी बजने की सुविधाएं | इन विकल्पों का इस्तेमाल किया जा सकता है:
|
8-15 | बाइट अरे | पैडिंग (जगह) | AES एन्क्रिप्शन के लिए ज़ीरो पैडिंग. |
डेटा को एईएस-ईसीबी-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)
के पहले 8 बाइट के तौर पर तय किया जाता है.
बीकन की प्रॉविज़निंग की स्थिति को पढ़ना
सीकर, प्रोवाइडर से बीकन की प्रोविज़निंग की स्थिति के बारे में क्वेरी कर सकता है. इसके लिए, उसे टेबल 2 में दिए गए डेटा आईडी 0x01 के साथ, अनुरोध वाली विशेषता पर राइट ऑपरेशन करना होगा. Provider यह पुष्टि करता है कि दी गई एक बार इस्तेमाल होने वाली पुष्टि करने की कुंजी, डिवाइस पर सेव की गई किसी भी खाता कुंजी से मेल खाती है.
पुष्टि न होने पर, Provider पुष्टि न होने से जुड़ी गड़बड़ी का मैसेज दिखाता है.
अगर अनुरोध पूरा हो जाता है, तो सेवा देने वाली कंपनी, टेबल 6 में दिए गए जवाब के साथ सूचना देती है. इसमें डेटा आईडी 0x01 होता है. डेटा उपलब्ध कराने वाली कंपनी, डेटा सेगमेंट को इस तरह बनाती है:
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | प्रोविज़निंग की स्थिति | यह एक बिटमास्क है, जिसमें ये वैल्यू होती हैं:
|
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)
के पहले 8 बाइट के तौर पर तय किया जाता है.
कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी कुंजी सेट करना
अगर किसी ऐसे प्रोवाइडर को FHN बीकन के तौर पर इस्तेमाल करना है जिसके लिए प्रावधान नहीं किया गया है या पहले से प्रावधान किए गए प्रोवाइडर के इफ़ेमरल आइडेंटिटी की को बदलना है, तो सीक करने वाला डिवाइस, टेबल 2 में दिए गए अनुरोध के हिसाब से, डेटा आईडी 0x02 वाले कैरेक्टरिस्टिक पर राइट ऑपरेशन करता है. कंपनी यह पुष्टि करती है कि:
- पुष्टि के लिए एक बार इस्तेमाल किया जाने वाला कोड, मालिक खाते की कुंजी से मैच करता हो.
- अगर कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी कुंजी का हैश दिया गया था, तो हैश की गई कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी कुंजी, मौजूदा कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी कुंजी से मेल खाती है.
- अगर कुछ समय के लिए इस्तेमाल होने वाली पहचान की कुंजी का हैश नहीं दिया गया है, तो पुष्टि करें कि प्रोवाइडर को पहले से ही FHN बीकन के तौर पर उपलब्ध न कराया गया हो.
पुष्टि न होने पर, Provider पुष्टि न होने से जुड़ी गड़बड़ी का मैसेज दिखाता है.
सत्यापन पूरा होने पर, मैच की गई खाता कुंजी का इस्तेमाल करके, AES-ECB-128 की मदद से इसे डिक्रिप्ट किया जाता है. इससे, कुछ समय के लिए इस्तेमाल की जाने वाली पहचान कुंजी वापस मिल जाती है. यह कुंजी डिवाइस पर सेव होनी चाहिए. इसके बाद, प्रोवाइडर को FHN फ़्रेम का विज्ञापन दिखाना शुरू कर देना चाहिए. बीएलई कनेक्शन बंद होने के तुरंत बाद, नई एफ़ेमरल आइडेंटिटी कुंजी लागू हो जाती है. Provider, टेबल 6 से मिले जवाब के साथ सूचना देता है. इसमें डेटा आईडी 0x02 होता है.
प्रमाणीकरण सेगमेंट को HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || 0x01)
के पहले 8 बाइट के तौर पर तय किया जाता है.
अस्थायी पहचान कुंजी मिटाएं
सेवा देने वाली कंपनी के बीकन वाले हिस्से को अनप्रोविज़न करने के लिए, सेवा लेने वाला व्यक्ति विशेषता पर राइट ऑपरेशन करता है. इसमें टेबल 2 से अनुरोध होता है, जिसमें डेटा आईडी 0x03 होता है. कंपनी यह पुष्टि करती है कि:
- पुष्टि के लिए एक बार इस्तेमाल किया जाने वाला कोड, मालिक खाते की कुंजी से मैच करता हो.
- हैश की गई कुछ समय के लिए इस्तेमाल होने वाली पहचान कुंजी, कुछ समय के लिए इस्तेमाल होने वाली मौजूदा पहचान कुंजी से मेल खाती है.
अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो यह बिना पुष्टि वाली गड़बड़ी दिखाता है.
सत्यापन हो जाने पर, सेवा देने वाली कंपनी कुंजी को भूल जाती है और FHN फ़्रेम का विज्ञापन दिखाना बंद कर देती है.
Provider, टेबल 6 से मिले जवाब के साथ सूचना देता है. इसमें डेटा आईडी 0x03 होता है.
प्रमाणीकरण सेगमेंट को HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || 0x01)
के पहले 8 बाइट के तौर पर तय किया जाता है.
उपयोगकर्ता की सहमति से, कुछ समय के लिए इस्तेमाल होने वाली आइडेंटिटी की को पढ़ना
यह विकल्प सिर्फ़ खोई हुई कुंजी को वापस पाने के लिए उपलब्ध है, क्योंकि कुंजी को सिर्फ़ Seeker डिवाइस पर स्थानीय तौर पर सेव किया जाता है. इसलिए, यह सुविधा सिर्फ़ तब उपलब्ध होती है, जब डिवाइस पेयरिंग मोड में हो या डिवाइस पर किसी बटन को दबाने के बाद कुछ समय के लिए उपलब्ध हो. बटन दबाने का मतलब है कि उपयोगकर्ता ने सहमति दी है.
सीकर को बैकएंड पर रिकवरी की सेव करनी होगी, ताकि वह क्लियरटेक्स्ट की को वापस पा सके. हालांकि, यह ईआईके को सेव नहीं करता है.
ईआईके को पढ़ने के लिए, सीक करने वाला डिवाइस, विशेषता पर लिखने की कार्रवाई करता है. इसमें टेबल 3 से डेटा आईडी 0x04 के साथ अनुरोध शामिल होता है. सेवा देने वाली कंपनी पुष्टि करती है कि:
- हैश की गई रिकवरी कुंजी, अनुमानित रिकवरी कुंजी से मेल खाती है.
- डिवाइस, ईआईके रिकवरी मोड में है.
पुष्टि न होने पर, Provider पुष्टि न होने से जुड़ी गड़बड़ी का मैसेज दिखाता है.
अगर डिवाइस पेयरिंग मोड में नहीं है, तो Provider, No User Consent error दिखाता है.
सर्टिफ़िकेट जारी होने पर, सेवा देने वाली कंपनी टेबल 6 में दिए गए जवाब के साथ सूचना देती है. इसमें डेटा आईडी 0x04 होता है.
प्रमाणीकरण सेगमेंट को HMAC-SHA256(recovery key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01)
के पहले 8 बाइट के तौर पर तय किया जाता है.
रिंग ऑपरेशन
सीकर, प्रोवाइडर से आवाज़ चलाने के लिए कह सकता है. इसके लिए, उसे विशेषता पर राइट ऑपरेशन करना होगा. इसमें टेबल 4 से अनुरोध शामिल होता है. इसका डेटा आईडी 0x05 होता है. डेटा उपलब्ध कराने वाली कंपनी, डेटा सेगमेंट को इस तरह बनाती है:
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | रिंग ऑपरेशन | यह एक बिटमास्क है, जिसमें ये वैल्यू होती हैं:
|
1 - 2 | uint16 | टाइम आउट की संख्या | यह टाइम आउट की अवधि है, जो डेसीसेकंड में होती है. यह शून्य नहीं होना चाहिए और 10 मिनट से ज़्यादा नहीं होना चाहिए. सेवा देने वाली कंपनी इस वैल्यू का इस्तेमाल यह तय करने के लिए करती है कि कॉल कितनी देर तक बजना चाहिए. अगर डिवाइस का कोई कॉम्पोनेंट पहले से बज रहा है, तो टाइम आउट की सुविधा चालू होने पर, वह बंद हो जाएगा. अगर रिंग ऑपरेशन को 0x00 पर सेट किया जाता है, तो टाइम आउट को अनदेखा कर दिया जाता है. |
3 | uint8 | आवाज़ |
|
अनुरोध मिलने पर, सेवा देने वाली कंपनी यह पुष्टि करती है कि:
- पुष्टि के लिए एक बार इस्तेमाल की जाने वाली दी गई कुंजी, रिंग की कुंजी से मेल खाती है.
- अनुरोध की गई स्थिति, रिंग करने वाले कॉम्पोनेंट से मेल खाती है.
अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो यह बिना पुष्टि वाली गड़बड़ी दिखाता है. हालांकि, अगर सेवा देने वाली कंपनी ने अनचाही ट्रैकिंग से सुरक्षा करने वाली सुविधा चालू की है और अनचाही ट्रैकिंग से सुरक्षा करने वाली सुविधा को ट्रिगर करने वाले अनुरोध में, रिंगिंग की पुष्टि करने वाले फ़्लैग को स्किप करने की सुविधा चालू है, तो सेवा देने वाली कंपनी को उस जांच को स्किप करना चाहिए. प्रमाणीकरण का डेटा अब भी Seeker को देना होगा, लेकिन इसे किसी भी वैल्यू पर सेट किया जा सकता है.
रिंगिंग शुरू होने या बंद होने पर, टेबल 6 में दी गई जानकारी के मुताबिक सूचना भेजी जाती है. इसमें डेटा आईडी 0x05 होता है. सूचना में शामिल कॉन्टेंट के बारे में यहां बताया गया है:
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | रिंग बजने की स्थिति |
|
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)
के पहले 8 बाइट के तौर पर तय किया जाता है.
अगर डिवाइस पहले से ही बज रहा है और उसे बजने से रोकने या बजने का अनुरोध मिलता है, तो सेवा देने वाली कंपनी को बजने की स्थिति के साथ एक सूचना भेजनी चाहिए. इसके अलावा, उसे क्रमशः 0x00: शुरू हुआ या 0x04: बंद हुआ (GATT अनुरोध) की सूचना भी भेजनी चाहिए. इस अनुरोध से, मौजूदा स्थिति के पैरामीटर बदल जाते हैं, ताकि कॉल की घंटी बजने की अवधि को बढ़ाया जा सके.
अगर सेवा देने वाली कंपनी के डिवाइस में कोई बटन है या उसमें टच सेंस की सुविधा चालू है, तो कॉल आने पर बजने वाली घंटी को बंद करने के लिए, उस बटन को दबाया जाना चाहिए.
बीकन के बजने की स्थिति पाना
बीकन की रिंगिंग की स्थिति पाने के लिए, सीक करने वाला डिवाइस, विशेषता पर राइट ऑपरेशन करता है. इसमें टेबल 4 से मिला अनुरोध होता है, जिसका डेटा आईडी 0x06 होता है. Provider यह पुष्टि करता है कि दी गई पुष्टि करने की कुंजी, रिंग की कुंजी से मेल खाती है.
अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो सेवा देने वाली कंपनी पुष्टि नहीं होने की गड़बड़ी का मैसेज दिखाती है.
सर्टिफ़िकेट जारी होने पर, सेवा देने वाली कंपनी टेबल 6 में दिए गए जवाब के साथ सूचना देती है. इसमें डेटा आईडी 0x06 होता है. डेटा उपलब्ध कराने वाली कंपनी, डेटा सेगमेंट को इस तरह बनाती है:
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | घंटी बजने से जुड़े कॉम्पोनेंट | रिंगिंग के अनुरोध में बताए गए कॉम्पोनेंट, जो रिंग कर रहे हैं. |
1 - 2 | uint16 | टाइम आउट की संख्या | घंटी बजने का बचा हुआ समय, डेसीसेकंड में. ध्यान दें कि अगर डिवाइस की घंटी नहीं बज रही है, तो 0000 वापस भेजा जाना चाहिए. |
प्रमाणीकरण सेगमेंट को HMAC-SHA256 (ring key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01)
के पहले 8 बाइट के तौर पर तय किया जाता है.
अनचाही ट्रैकिंग से सुरक्षा का मोड
अनचाहे ट्रैकिंग सुरक्षा मोड का मकसद, किसी भी क्लाइंट को सर्वर से कम्यूनिकेट किए बिना, गलत इस्तेमाल करने वाले डिवाइसों की पहचान करने की अनुमति देना है. डिफ़ॉल्ट रूप से, प्रोवाइडर को सभी आइडेंटिफ़ायर रोटेट करने चाहिए. इसके बारे में आईडी रोटेशन में बताया गया है. Find Hub सेवा, Find Hub नेटवर्क के ज़रिए, ट्रैकिंग से सुरक्षा देने वाले मोड को चालू करने का ऐसा अनुरोध भेज सकती है जिसकी ज़रूरत नहीं है. ऐसा करने से, सेवा देने वाली कंपनी कुछ समय के लिए एक तय मैक पते का इस्तेमाल करती है. इससे क्लाइंट को डिवाइस का पता लगाने और उपयोगकर्ता को संभावित अनचाही ट्रैकिंग के बारे में चेतावनी देने की अनुमति मिलती है.
बीकन के अनचाहे ट्रैकिंग से सुरक्षा देने वाले मोड को चालू या बंद करने के लिए, Seeker, विशेषता पर लिखने की कार्रवाई करता है. इसमें टेबल 5 से किया गया अनुरोध शामिल होता है. इसका डेटा आईडी क्रमशः 0x07 या 0x08 होता है.
अनचाही ट्रैकिंग से सुरक्षा देने वाला मोड चालू करने पर
डेटा उपलब्ध कराने वाली कंपनी, डेटा सेगमेंट को इस तरह बनाती है:
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | कंट्रोल फ़्लैग |
ये फ़्लैग सिर्फ़ तब तक लागू होते हैं, जब तक ट्रैकिंग से सुरक्षा देने वाले अनचाहे मोड को बंद नहीं किया जाता. |
सेवा देने वाली कंपनी यह पुष्टि करती है कि दी गई पुष्टि करने के लिए एक बार इस्तेमाल की जाने वाली कुंजी, अनचाही ट्रैकिंग से सुरक्षा देने वाली कुंजी से मेल खाती है. अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो यह पुष्टि नहीं होने की गड़बड़ी दिखाता है.
ट्रैकिंग से सुरक्षा देने वाला मोड चालू होने पर, बीकन को हर 24 घंटे में एक बार, मैक पते को रोटेट करने की फ़्रीक्वेंसी को कम करना चाहिए. विज्ञापन में दिखाए गए कुछ समय के लिए उपलब्ध आइडेंटिफ़ायर को हमेशा की तरह रोटेट करते रहना चाहिए. फ़्रेम टाइप को 0x41 पर सेट किया जाना चाहिए. यह स्थिति, हैश किए गए फ़्लैग सेक्शन में भी दिखती है.
अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड को बंद करते समय
कंपनी यह पुष्टि करती है कि:
- दी गई पुष्टि करने की कुंजी, अनचाही ट्रैकिंग से सुरक्षा देने वाली कुंजी से मेल खाती है.
- हैश की गई कुछ समय के लिए इस्तेमाल होने वाली पहचान कुंजी, कुछ समय के लिए इस्तेमाल होने वाली मौजूदा पहचान कुंजी से मेल खाती है.
अगर सेवा देने वाली कंपनी को FHN बीकन के तौर पर उपलब्ध नहीं कराया गया है या पुष्टि नहीं हो पाती है, तो सेवा देने वाली कंपनी पुष्टि नहीं होने की गड़बड़ी का मैसेज दिखाती है.
अनचाही ट्रैकिंग सुरक्षा सुविधा बंद होने पर, बीकन को सामान्य दर से फिर से मैक पते को रोटेट करना चाहिए. यह काम, कुछ समय के लिए इस्तेमाल होने वाले आइडेंटिफ़ायर के रोटेशन के साथ सिंक होना चाहिए. फ़्रेम टाइप को वापस 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)
के पहले 8 बाइट के तौर पर तय किया जाता है.
विज्ञापन वाले फ़्रेम
प्रोविज़निंग के बाद, प्रोवाइडर को हर दो सेकंड में कम से कम एक बार, FHN फ़्रेम का विज्ञापन दिखाना चाहिए. अगर फ़ास्ट पेयर फ़्रेम का विज्ञापन दिखाया जाता है, तो सेवा देने वाली कंपनी को फ़ास्ट पेयर के सामान्य विज्ञापनों में, FHN फ़्रेम को इंटरलीव करना चाहिए. उदाहरण के लिए, हर दो सेकंड में, सेवा देने वाली कंपनी को सात Fast Pair विज्ञापन और एक FHN विज्ञापन दिखाना चाहिए.
FHN विज्ञापनों के लिए, ब्लूटूथ ट्रांसमिट पावर को कम से कम 0 dBm पर सेट किया जाना चाहिए.
एफ़एचएन फ़्रेम में एक सार्वजनिक पासकोड होता है. इसका इस्तेमाल, क्राउडसोर्सिंग नेटवर्क में योगदान देने वाले किसी भी क्लाइंट की ओर से, जगह की जानकारी वाली रिपोर्ट को एन्क्रिप्ट (सुरक्षित) करने के लिए किया जाता है. दो तरह के इलिप्टिक कर्व की उपलब्ध हैं: 160-बिट की, जो लेगसी BLE 4 फ़्रेम में फ़िट होती है या 256-बिट की, जिसके लिए विज्ञापन दिखाने की बेहतर सुविधाओं के साथ BLE 5 की ज़रूरत होती है. Provider's implementation से यह तय होता है कि किस कर्व का इस्तेमाल किया जाएगा.
एफ़एचएन फ़्रेम का स्ट्रक्चर इस तरह होता है.
ऑक्टेट | मान | ब्यौरा |
---|---|---|
0 | 0x02 | लंबाई |
1 | 0x01 | फ़्लैग किए गए डेटा टाइप की वैल्यू |
2 | 0x06 | फ़्लैग डेटा |
3 | 0x18 या 0x19 | लंबाई |
4 | 0x16 | सेवा के डेटा के डेटा टाइप की वैल्यू |
5 | 0xAA | 16-बिट सेवा यूयूआईडी |
6 | 0xFE | ... |
7 | 0x40 या 0x41 | FHN फ़्रेम टाइप, जिसमें ट्रैकिंग से सुरक्षा देने वाले मोड की जानकारी नहीं दी गई है |
8..27 | 20 बाइट का कुछ समय के लिए इस्तेमाल होने वाला आइडेंटिफ़ायर | |
28 | हैश किए गए फ़्लैग |
टेबल 8: 160-बिट कर्व के साथ काम करने वाला FHN फ़्रेम.
टेबल 9 में, 256-बिट कर्व के लिए बाइट ऑफ़सेट और वैल्यू दिखाई गई हैं.
ऑक्टेट | मान | ब्यौरा |
---|---|---|
0 | 0x02 | लंबाई |
1 | 0x01 | फ़्लैग किए गए डेटा टाइप की वैल्यू |
2 | 0x06 | फ़्लैग डेटा |
3 | 0x24 या 0x25 | लंबाई |
4 | 0x16 | सेवा के डेटा के डेटा टाइप की वैल्यू |
5 | 0xAA | 16-बिट सेवा यूयूआईडी |
6 | 0xFE | ... |
7 | 0x40 या 0x41 | FHN फ़्रेम टाइप, जिसमें ट्रैकिंग से सुरक्षा देने वाले मोड की जानकारी नहीं दी गई है |
8..39 | 32 बाइट का कुछ समय के लिए इस्तेमाल होने वाला आइडेंटिफ़ायर | |
40 | हैश किए गए फ़्लैग |
टेबल 9: 256-बिट कर्व के साथ काम करने वाला FHN फ़्रेम.
कुछ समय के लिए इस्तेमाल होने वाले आइडेंटिफ़ायर (ईआईडी) का हिसाब लगाना
AES-ECB-256 की मदद से, इस डेटा स्ट्रक्चर को एन्क्रिप्ट (सुरक्षित) करके एक रैंडम नंबर जनरेट किया जाता है. इसके लिए, पहचान की कुछ समय के लिए इस्तेमाल होने वाली कुंजी का इस्तेमाल किया जाता है:
ऑक्टेट | फ़ील्ड | ब्यौरा |
---|---|---|
0 - 10 | पैडिंग (जगह) | Value = 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
का इस्तेमाल, एलिप्टिक कर्व क्रिप्टोग्राफ़िक ऑपरेशन के लिए किया जाता है.
SEC 2: Recommended Elliptic Curve Domain Parameters में कर्व की परिभाषाएं देखें. इसमें Fp
, n
, और G
की परिभाषाएं दी गई हैं.
r'
को अब r = r' mod n
कैलकुलेट करके, फ़ाइनाइट फ़ील्ड Fp
में प्रोजेक्ट किया जाता है.
आखिर में, R = r * G
का हिसाब लगाएं. यह कर्व पर मौजूद एक पॉइंट है, जो इस्तेमाल की जा रही सार्वजनिक पासकोड को दिखाता है. यह बीकन, Rx
को अपने कुछ समय के लिए मान्य आइडेंटिफ़ायर के तौर पर दिखाता है. Rx
, R
का x
कोऑर्डिनेट है.
हैश किए गए फ़्लैग
हैश किए गए फ़्लैग फ़ील्ड का हिसाब इस तरह लगाया जाता है (बिट को सबसे अहम से लेकर सबसे कम अहम तक के क्रम में रखा जाता है):
- बिट 0-4: आरक्षित (शून्य पर सेट किए गए).
- पांचवें और छठे बिट से, डिवाइस के बैटरी लेवल के बारे में पता चलता है. जैसे:
- 00: बैटरी लेवल दिखाने की सुविधा काम नहीं करती
- 01: बैटरी का लेवल सामान्य है
- 10: बैटरी लेवल कम है
- 11: बैटरी का लेवल बहुत कम है (बैटरी को जल्द ही बदलना होगा)
- अगर बीकन, ट्रैकिंग सुरक्षा के अनचाहे मोड में है, तो बिट 7 को 1 पर सेट किया जाता है. अगर ऐसा नहीं है, तो इसे 0 पर सेट किया जाता है.
इस बाइट की फ़ाइनल वैल्यू जनरेट करने के लिए, इसे SHA256(r)
के सबसे कम अहम बाइट के साथ xor किया जाता है.
ध्यान दें कि r को कर्व के साइज़ के हिसाब से अलाइन किया जाना चाहिए. अगर इसका प्रज़ेंटेशन 160 या 256 बिट से छोटा है, तो सबसे अहम बिट के तौर पर शून्य जोड़ें. अगर इसका प्रज़ेंटेशन 160 या 256 बिट से बड़ा है, तो सबसे अहम बिट को छोटा किया जाना चाहिए.
अगर बीकन, बैटरी लेवल की जानकारी देने की सुविधा के साथ काम नहीं करता है और अनचाही ट्रैकिंग से सुरक्षा देने वाले मोड में नहीं है, तो विज्ञापन से इस बाइट को पूरी तरह से हटाया जा सकता है.
ईआईडी का इस्तेमाल करके एन्क्रिप्शन
मैसेज को एन्क्रिप्ट करने के लिए m
, साइट पर मौजूद व्यक्ति (जिसने बीकन से Rx
पढ़ा है) यह तरीका अपनाएगा:
- ईआईडी कैलकुलेट करने के तरीके सेक्शन में बताए गए तरीके के मुताबिक,
Fp
में से कोई भी रैंडम नंबरs
चुनें. - Compute
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
तय करें. - Compute
nonce = LRx || LSx
. - Compute
(m’, tag) = AES-EAX-256-ENC(k, nonce, m)
. - मालिक को
(URx, Sx, m’, tag)
भेजें. ऐसा हो सकता है कि यह काम किसी ऐसी रिमोट सेवा के ज़रिए किया जा रहा हो जिस पर भरोसा नहीं किया जा सकता.
ईआईडी का इस्तेमाल करके एन्क्रिप्ट (सुरक्षित) की गई वैल्यू को डिक्रिप्ट (सुरक्षित तरीके से बदलना) करना
मालिक का क्लाइंट, जिसके पास EIK और रोटेशन पीरियड का एक्सपोनेंट होता है, मैसेज को इस तरह डिक्रिप्ट करता है:
URx
दिए जाने पर, बीकन टाइम काउंटर की वह वैल्यू पाएं जिस परURx
आधारित है. ऐसा, मालिक के क्लाइंट कंप्यूटिंगRx
वैल्यू के ज़रिए किया जा सकता है. इसके लिए, हाल ही के समय और आने वाले समय के लिए बीकन टाइम काउंटर वैल्यू का इस्तेमाल किया जाता है.URx
जिस बीकन टाइम काउंटर वैल्यू पर आधारित है उसे देखते हुए,r
की अनुमानित वैल्यू का हिसाब लगाएं. यह वैल्यू, ईआईडी का हिसाब लगाना सेक्शन में बताई गई है.R = r * G
की गिनती करें और पुष्टि करें कि यह, देखने वाले व्यक्ति या कंपनी के दिए गएURx
की वैल्यू से मेल खाता है.- कर्व के समीकरण में वैल्यू डालकर
S = (Sx, Sy)
की वैल्यू का हिसाब लगाएं. साथ ही, संभावित नतीजों में से कोई भीSy
वैल्यू चुनें. k = HKDF-SHA256((r * S)x)
की गणना करें. यहां(r * S)x
, कर्व मल्टिप्लिकेशन के नतीजे काx
कोऑर्डिनेट है.- Compute
nonce = LRx || LSx
. - Compute
m = AES-EAX-256-DEC(k, nonce, m’, tag)
.
आईडी रोटेशन
FHN फ़्रेम का विज्ञापन दिखाने के लिए, हल किए जा सकने वाले (आरपीए) या हल नहीं किए जा सकने वाले (एनआरपीए) बीएलई पते का इस्तेमाल करना ज़रूरी है. LE Audio (LEA) डिवाइसों के लिए, आरपीए ज़रूरी है. साथ ही, इसका इस्तेमाल अन्य डिवाइसों के लिए भी किया जा सकता है. हालांकि, यह उन लोकेटर टैग के लिए ज़रूरी नहीं है जो बॉन्डिंग का इस्तेमाल नहीं करते हैं.
Fast Pair विज्ञापन, FHN विज्ञापन, और उनसे जुड़े BLE पते एक साथ रोटेट होने चाहिए. औसतन हर 1024 सेकंड में रोटेशन होना चाहिए. जिस सटीक पॉइंट पर बीकन, नए आइडेंटिफ़ायर का विज्ञापन दिखाना शुरू करता है उसे विंडो में रैंडमाइज़ किया जाना चाहिए.
रोटेशन के समय को रैंडमाइज़ करने का सुझाव दिया गया है. इसके लिए, रोटेशन के अगले अनुमानित समय को सेट करें. अगर रैंडमाइज़ेशन लागू नहीं किया गया है, तो रैंडमाइज़ किए गए समय के फ़ैक्टर को 1 से 204 सेकंड की रेंज में सेट करें.
जब डिवाइस, अनचाहे ट्रैकिंग से सुरक्षा वाले मोड में होता है, तब FHN विज्ञापन का बीएलई पता तय होना चाहिए. हालांकि, FP के लिए आरपीए, विज्ञापन का पता नहीं लगाया जा सकता (जैसे, Fast Pair) को रोटेट करते रहना चाहिए. अलग-अलग प्रोटोकॉल के लिए, अलग-अलग पतों का इस्तेमाल किया जा सकता है.
बिजली चले जाने पर रिकवर करना
विज्ञापन दिखाने के समय, एफ़ेमरल आइडेंटिफ़ायर को हल करना, उसकी क्लॉक वैल्यू से जुड़ा होता है. इसलिए, यह ज़रूरी है कि बिजली गुल होने पर, प्रोवाइडर अपनी क्लॉक वैल्यू को वापस पा सके. हमारा सुझाव है कि प्रोवाइडर, हर दिन कम से कम एक बार अपनी मौजूदा घड़ी की वैल्यू को नॉनवॉलेटाइल मेमोरी में लिखे. साथ ही, बूट होने के समय प्रोवाइडर, NVM की जांच करे, ताकि यह पता चल सके कि कोई ऐसी वैल्यू मौजूद है या नहीं जिससे घड़ी को शुरू किया जा सके. एपहेमरल आइडेंटिफ़ायर के रिज़ॉल्वर, एक तय समयसीमा के अंदर रिज़ॉल्यूशन लागू करेंगे. इससे, क्लॉक में मामूली अंतर और बैटरी खत्म होने की वजह से होने वाली समस्या को ठीक किया जा सकेगा.
सेवा देने वाली कंपनियों को अब भी यह पक्का करना चाहिए कि क्लॉक में अंतर कम से कम हो, क्योंकि समस्या हल करने के लिए समय सीमा सीमित होती है. कम से कम एक और क्लॉक सिंक्रनाइज़ेशन तरीका लागू किया जाना चाहिए. जैसे, विज्ञापन दिखाने के लिए Fast Pair के ऐसे फ़्रेम जो आस-पास के डिवाइसों को नहीं दिखते या मैसेज स्ट्रीम लागू करना.
फ़ास्ट पेयर सुविधा लागू करने के दिशा-निर्देश
इस सेक्शन में, फ़ास्ट पेयर की सुविधा लागू करने के खास पहलुओं के बारे में बताया गया है. ये पहलू, FHN की सुविधा देने वाले प्रोवाइडर पर लागू होते हैं.
लोकेटर टैग से जुड़े दिशा-निर्देश
- अगर डिवाइस को सेवा देने वाली कंपनी के साथ पेयर किया गया है, लेकिन पांच मिनट के अंदर FHN की सुविधा चालू नहीं की गई है, तो सेवा देने वाली कंपनी को डिवाइस को फ़ैक्ट्री कॉन्फ़िगरेशन पर वापस लाना चाहिए. साथ ही, सेव किए गए खाते के कुंजियों को मिटा देना चाहिए. इसके अलावा, अगर डिवाइस को पेयर किया गया है, लेकिन FHN की सुविधा चालू नहीं की गई है और इस दौरान OTA अपडेट लागू किया गया है, तो भी सेवा देने वाली कंपनी को डिवाइस को फ़ैक्ट्री कॉन्फ़िगरेशन पर वापस लाना चाहिए. साथ ही, सेव किए गए खाते के कुंजियों को मिटा देना चाहिए.
- प्रोवाइडर के पेयर हो जाने के बाद, उसे अपना एमएसी पता तब तक नहीं बदलना चाहिए, जब तक कि एफएचएन की सुविधा चालू न हो जाए या पांच मिनट न बीत जाएं.
- अगर डिवाइस से कुछ समय के लिए इस्तेमाल होने वाली पहचान की कुंजी मिटा दी जाती है, तो डिवाइस को फ़ैक्ट्री रीसेट करना चाहिए. साथ ही, सेव की गई खाता कुंजियों को भी मिटा देना चाहिए.
- Provider को ब्लूटूथ से कनेक्ट करने के सामान्य अनुरोधों को अस्वीकार करना चाहिए और सिर्फ़ Fast Pair से कनेक्ट करने के अनुरोधों को स्वीकार करना चाहिए.
- सेवा देने वाली कंपनी को एक ऐसा तरीका उपलब्ध कराना होगा जिससे उपयोगकर्ता, डिवाइस को फ़ैक्ट्री रीसेट किए बिना कुछ समय के लिए विज्ञापन देखना बंद कर सकें. उदाहरण के लिए, बटनों के किसी कॉम्बिनेशन को दबाना.
- डिवाइस बंद होने के बाद, उसे फ़ास्ट पेयर के ऐसे फ़्रेम का विज्ञापन दिखाना चाहिए जिन्हें खोजा नहीं जा सकता. ऐसा तब तक होना चाहिए, जब तक रीड बीकन पैरामीटर को अगली बार चालू नहीं किया जाता. इससे Seeker को डिवाइस का पता लगाने और घड़ी को सिंक करने में मदद मिलती है. भले ही, घड़ी में काफ़ी अंतर आ गया हो.
- फ़ास्ट पेयर की सुविधा वाले ऐसे फ़्रेम का विज्ञापन करते समय, यूज़र इंटरफ़ेस (यूआई) के इंडिकेटर चालू नहीं होने चाहिए जिन्हें खोजा नहीं जा सकता.
- जब प्रोवाइडर को FHN के लिए प्रोविज़न किया जाता है, तब फ़ास्ट पेयर की सुविधा वाले ऐसे फ़्रेम का विज्ञापन नहीं किया जाना चाहिए जिन्हें खोजा जा सकता है.
- सेवा देने वाली कंपनी को, बिना पुष्टि किए किसी भी तरीके से पहचान ज़ाहिर करने वाली जानकारी (जैसे, नाम या पहचानकर्ता) को सार्वजनिक नहीं करना चाहिए.
क्लासिक ब्लूटूथ डिवाइस के लिए दिशा-निर्देश
इस सेक्शन में, क्लासिक ब्लूटूथ डिवाइसों के खास पहलुओं के बारे में बताया गया है. ये डिवाइस, एफएचएन के साथ काम करते हैं.
पहले से जुड़े डिवाइसों के लिए, FHN की सुविधा चालू करना
सीकर के साथ पेयर करने पर, प्रोवाइडर को हमेशा FHN के लिए उपलब्ध नहीं कराया जाता. हालांकि, कुछ समय बाद ऐसा किया जाता है. ऐसे में, हो सकता है कि सेवा देने वाली कंपनी के पास, बीएलई मैक पते का अप-टू-डेट वर्शन न हो. यह पता, GATT कनेक्शन बनाने के लिए ज़रूरी होता है. सेवा देने वाली कंपनी को, सेवा लेने वाले व्यक्ति के लिए कम से कम एक ऐसा तरीका उपलब्ध कराना होगा जिससे वह पहले से पेयर किए गए डिवाइस का बीएलई पता पा सके. इसके लिए, सेवा देने वाली कंपनी को इनमें से कोई एक तरीका उपलब्ध कराना होगा:
- डिवाइस बनाने वाली कंपनी, समय-समय पर Fast Pair खाते के डेटा का विज्ञापन कर सकती है. इससे, डिवाइस ढूंढने वाले व्यक्ति को बीएलई स्कैन के ज़रिए बीएलई पते का पता चल जाता है.
यह तरीका उन कंपनियों के लिए सही है जिन्होंने मैसेज स्ट्रीम लागू नहीं की है. - Provider, इस डेटा को क्लासिक ब्लूटूथ पर Fast Pair message stream के ज़रिए उपलब्ध करा सकता है.
यह तरीका उन प्रोवाइडर के लिए सही है जो ब्लूटूथ से कनेक्ट होने के दौरान, फ़ास्ट पेयर फ़्रेम का विज्ञापन नहीं करते.
दोनों तरीकों का इस्तेमाल करने से, उपयोगकर्ता के लिए डिवाइस को FHN के लिए प्रोविज़न करने की संभावना बढ़ जाती है.
फ़ास्ट पेयर की सुविधा के लिए मैसेज स्ट्रीम
Provider, Fast Pair मैसेज स्ट्रीम को लागू कर सकता है. साथ ही, इसका इस्तेमाल करके Seeker को डिवाइस की जानकारी के बारे में सूचना दे सकता है. मैसेज स्ट्रीम लागू करने से, इस सेक्शन में बताई गई कुछ सुविधाएं चालू हो जाती हैं.
जब भी मैसेज स्ट्रीम RFCOMM चैनल सेट अप किया जाता है, तब सेवा देने वाली कंपनी को डिवाइस की जानकारी वाले मैसेज भेजने चाहिए.
फ़र्मवेयर वर्शन (डिवाइस की जानकारी का कोड 0x09) और ट्रैकिंग की सुविधा
जब फ़र्मवेयर अपडेट के ज़रिए, क्रेडेंशियल देने वाले व्यक्ति या कंपनी के लिए FHN की सुविधा जोड़ी जाती है, तो कनेक्ट किया गया Seeker, उपयोगकर्ता को इसकी सूचना दे सकता है. साथ ही, उसे इस सुविधा को चालू करने का विकल्प दे सकता है. ऐसा न होने पर, उपयोगकर्ता को FHN की सुविधा चालू करने के लिए, ब्लूटूथ डिवाइसों की सूची पर मैन्युअल तरीके से जाना होगा.
इसके लिए, सेवा देने वाली कंपनी को फ़र्मवेयर वर्शन प्रॉपर्टी (कोड 0x09) का इस्तेमाल करना चाहिए, ताकि फ़र्मवेयर वर्शन को दिखाने वाली स्ट्रिंग वैल्यू की जानकारी दी जा सके. इसके अलावा, सेवा देने वाली कंपनी को ऐसे प्रोटोकॉल का इस्तेमाल करना चाहिए जिससे सेवा लेने वाले व्यक्ति को फ़र्मवेयर अपडेट की वजह से, सुविधाओं में होने वाले बदलावों के बारे में पता चल सके.
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | डिवाइस की जानकारी का इवेंट | 0x03 |
1 | uint8 | फ़र्मवेयर का वर्शन | 0x09 |
2 - 3 | uint16 | अतिरिक्त डेटा का साइज़ | अलग-अलग होती है |
var | बाइट अरे | वर्शन स्ट्रिंग | अलग-अलग होती है |
टेबल 11: डिवाइस की जानकारी देने वाला इवेंट: अपडेट किया गया फ़र्मवेयर वर्शन.
क्षमता अपडेट करने का अनुरोध (0x0601) मिलने पर, अगर सेवा देने वाली कंपनी ने FHN ट्रैकिंग की सुविधा चालू की है, तो उसे टेबल 12 में दिखाए गए तरीके से जवाब देना चाहिए.
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | डिवाइस की क्षमता को सिंक करने का इवेंट | 0x06 |
1 | uint8 | FHN ट्रैकिंग | 0x03 |
2 - 3 | uint16 | अतिरिक्त डेटा का साइज़ | 0x0007 |
4 | uint8 | FHN की सुविधा चालू करने की स्थिति | अगर कोई खाता नहीं जोड़ा गया है, तो 0x00; अगर किसी खाते से जोड़ा गया है, तो 0x01 |
5 - 10 | बाइट अरे | डिवाइस का मौजूदा बीएलई एमएसी पता | अलग-अलग होती है |
टेबल 12: डिवाइस की क्षमता सिंक करने से जुड़ा इवेंट: ट्रैकिंग की सुविधा जोड़ी गई.
मौजूदा कुछ समय के लिए इस्तेमाल होने वाला आइडेंटिफ़ायर (डिवाइस की जानकारी देने वाला कोड 0x0B)
जब प्रोवाइडर को FHN के लिए प्रोविज़न किया जाता है, तब वह मौजूदा एफ़ेमरल आइडेंटिफ़ायर (कोड 0x0B) का इस्तेमाल करके, मौजूदा ईआईडी और क्लॉक वैल्यू की जानकारी दे सकता है. इससे, क्लॉक में अंतर आने पर (उदाहरण के लिए, बैटरी खत्म होने की वजह से), सीक करने वाले व्यक्ति के डिवाइस को सिंक किया जा सकता है. ऐसा न होने पर, सीक करने वाला व्यक्ति इस काम के लिए ज़्यादा महंगा और कम भरोसेमंद कनेक्शन शुरू करता है.
ऑक्टेट | डेटा टाइप | ब्यौरा | मान |
---|---|---|---|
0 | uint8 | डिवाइस की जानकारी का इवेंट | 0x03 |
1 | uint8 | मौजूदा कुछ समय के लिए इस्तेमाल होने वाला आइडेंटिफ़ायर | 0x0B |
2 - 3 | uint16 | अतिरिक्त डेटा का साइज़ | 0x0018 या 0x0024 |
4 - 7 | बाइट अरे | घड़ी की वैल्यू | उदाहरण: 0x13F9EA80 |
8 - 19 या 31 | बाइट अरे | मौजूदा ईआईडी | उदाहरण: 0x1122334455667788990011223344556677889900 |
टेबल 13: डिवाइस की जानकारी देने वाला इवेंट: घड़ी सिंक करना.
फ़ैक्ट्री रीसेट करें
फ़ैक्ट्री रीसेट की सुविधा वाले डिवाइसों के लिए: अगर फ़ैक्ट्री रीसेट किया जाता है, तो सेवा देने वाली कंपनी को बीकन भेजना बंद करना होगा. साथ ही, उसे कुछ समय के लिए इस्तेमाल की जाने वाली पहचान की कुंजी और सेव की गई सभी खाता कुंजियां मिटानी होंगी. इनमें मालिक के खाते की कुंजी भी शामिल है.
फ़ैक्ट्री रीसेट (मैन्युअल या प्रोग्राम के हिसाब से) के बाद, सेवा देने वाली कंपनी को Fast Pair की सुविधा का विज्ञापन तुरंत नहीं दिखाना चाहिए. इससे, उपयोगकर्ता के डिवाइस को मिटाने के तुरंत बाद, पेयरिंग की प्रोसेस शुरू होने से रोकी जा सकेगी.
अनचाही ट्रैकिंग को रोकना
सर्टिफ़ाइड FHN डिवाइसों को, अनचाहे लोकेशन ट्रैकर का पता लगाने (डीयूएलटी) के लिए, क्रॉस-प्लैटफ़ॉर्म स्पेसिफ़िकेशन के लागू करने वाले वर्शन में दी गई ज़रूरी शर्तों को भी पूरा करना होगा.
डीयूएलटी के स्पेसिफ़िकेशन का पालन करने के लिए, एफएचएन से जुड़े ज़रूरी दिशा-निर्देश:
- FHN के साथ काम करने वाले किसी भी डिवाइस को Nearby Device Console में रजिस्टर किया जाना चाहिए. साथ ही, उसमें "हब ढूंढें" सुविधा चालू होनी चाहिए.
- डिवाइस में, ऐक्सेसरी के मालिक के अलावा किसी और व्यक्ति के लिए उपलब्ध सेवा और DULT स्पेसिफ़िकेशन के लागू किए गए वर्शन में बताई गई सुविधा लागू होनी चाहिए. इसमें ऐक्सेसरी की जानकारी से जुड़ी कार्रवाइयां और ऐक्सेसरी के मालिक के अलावा किसी और व्यक्ति के लिए उपलब्ध कंट्रोल शामिल हैं.
- DULT स्पेसिफ़िकेशन में बताई गई बैकवर्ड कंपैटिबिलिटी की अवधि के दौरान, इस दस्तावेज़ में बताए गए विज्ञापन वाले फ़्रेम में कोई बदलाव नहीं किया गया है.
- इस दस्तावेज़ में बताए गए "अनचाहे ट्रैकिंग सुरक्षा मोड" का मतलब, DULT स्पेसिफ़िकेशन में बताए गए "अलग स्थिति" से है.
- ऐक्सेसरी की जानकारी वाले ऑपकोड लागू करने के लिए दिशा-निर्देश:
- Get_Product_Data को कंसोल से मिला मॉडल आईडी दिखाना चाहिए. साथ ही, इसे आठ बाइट की ज़रूरत के हिसाब से शून्य से पैड किया जाना चाहिए. उदाहरण के लिए, मॉडल आईडी 0xFFFFFF को 0x0000000000FFFFFF के तौर पर दिखाया जाता है.
- Get_Manufacturer_Name और Get_Model_Name की वैल्यू, कंसोल में दी गई वैल्यू से मेल खानी चाहिए.
- अगर डिवाइस के टाइप के हिसाब से कोई दूसरी कैटगरी ज़्यादा सही नहीं है, तो Get_Accessory_Category फ़ंक्शन, "लोकेशन ट्रैकर" की सामान्य वैल्यू दिखा सकता है.
- Get_Accessory_Capabilities में, रिंग करने की सुविधा के साथ-साथ बीएलई आइडेंटिफ़ायर लुकअप की सुविधा के बारे में भी जानकारी होनी चाहिए.
- Get_Network_ID को Google का आइडेंटिफ़ायर (0x02) दिखाना चाहिए.
- Get_Identifier ओपकॉड लागू करने के लिए दिशा-निर्देश:
- यह ऑपरेशन, उपयोगकर्ता के 'पहचान' मोड को चालू करने के पांच मिनट बाद तक ही मान्य जवाब देगा. इसके लिए, बटन को एक साथ दबाना ज़रूरी है. विज़ुअल या ऑडियो सिग्नल से उपयोगकर्ता को यह पता चलना चाहिए कि सेवा देने वाली कंपनी ने उस मोड में एंट्री कर ली है. उस मोड को चालू करने के लिए, मॉडल के हिसाब से निर्देश Google को देने होंगे. ऐसा सर्टिफ़िकेट पाने के लिए करना ज़रूरी है. साथ ही, निर्देशों में कोई भी अपडेट या बदलाव करने से कम से कम 10 दिन पहले ऐसा करना होगा.
- जवाब इस तरह से बनाया जाता है: मौजूदा कुछ समय के लिए उपलब्ध आइडेंटिफ़ायर के पहले 10 बाइट, इसके बाद
HMAC-SHA256(recovery key, the truncated current ephemeral identifier)
के पहले 8 बाइट.
- एनएफ़सी के ज़रिए आइडेंटिफ़ायर लागू करने के लिए दिशा-निर्देश:
- यूआरएल के तौर पर,
find-my.googleapis.com/lookup
का इस्तेमाल करें. e
पैरामीटर के तौर पर, Get_Identifier के लिए बनाए गए जवाब का इस्तेमाल करें. यह जवाब हेक्स कोड में होना चाहिए.pid
पैरामीटर के तौर पर, Get_Product_Data के लिए बनाए गए जवाब का इस्तेमाल करें. हालांकि, इसे हेक्स कोड में बदला गया हो.
- यूआरएल के तौर पर,
- डिवाइस में आवाज़ करने वाला कॉम्पोनेंट होना चाहिए और उसमें घंटी बजाने की सुविधा होनी चाहिए. डीयूएलटी के स्पेसिफ़िकेशन के मुताबिक, साउंड मेकर को कम से कम 60 फ़ोन की पीक लाउडनेस वाली आवाज़ निकालनी चाहिए. यह आईएसओ 532-1:2017 के मुताबिक तय की गई है.
- Sound_Start ओपकॉड को लागू करने के लिए दिशा-निर्देश:
- इस निर्देश से, सभी उपलब्ध कॉम्पोनेंट में घंटी बजनी चाहिए.
- ज़्यादा से ज़्यादा वॉल्यूम का इस्तेमाल किया जाना चाहिए.
- हमारा सुझाव है कि रिंग बजने की अवधि 12 सेकंड होनी चाहिए.
- लोकेटर टैग में ऐसा तरीका शामिल होना चाहिए जिससे उपयोगकर्ता, डिवाइस को फ़ैक्ट्री रीसेट किए बिना कुछ समय के लिए विज्ञापन दिखाना बंद कर सकें. उदाहरण के लिए, बटनों के कॉम्बिनेशन को दबाना.
- खाता बंद करने के निर्देशों को सार्वजनिक तौर पर उपलब्ध यूआरएल में दस्तावेज़ के तौर पर सेव किया जाना चाहिए. साथ ही, सर्टिफ़िकेट पाने के लिए, Google को यह यूआरएल देना ज़रूरी है. इसके अलावा, निर्देशों में कोई भी अपडेट या बदलाव करने से कम से कम 10 दिन पहले, Google को इसकी जानकारी देनी होगी.
- यूआरएल में स्थानीय भाषा की सुविधा काम करनी चाहिए. क्लाइंट के हिसाब से, भाषा को क्वेरी पैरामीटर ("hl=en") के तौर पर या "accept-language" एचटीटीपी हेडर का इस्तेमाल करके उपलब्ध कराया जाएगा.
स्विच किए जा सकने वाले प्रोटोकॉल के लिए दिशा-निर्देश
- एक समय में सिर्फ़ एक प्रोटोकॉल का इस्तेमाल किया जाना चाहिए. पक्का करें कि डिवाइस पर एक साथ एक से ज़्यादा नेटवर्क काम न कर रहे हों. इस ज़रूरी शर्त का पालन करना इसलिए ज़रूरी है, ताकि अलग-अलग प्रोटोकॉल के बीच उपयोगकर्ता के संवेदनशील डेटा को एक साथ न मिलाया जाए.
- हमारा सुझाव है कि डिवाइस में हार्ड रीसेट वर्कफ़्लो शामिल करें. इससे उपयोगकर्ता, डिवाइस को किसी दूसरे नेटवर्क से फिर से सेट अप कर पाएगा.
- किसी डिवाइस को नेटवर्क से अपडेट करने की प्रोसेस, उपयोगकर्ता के लिए आसान होनी चाहिए. साथ ही, यह प्रोसेस सभी नेटवर्क के लिए एक जैसी होनी चाहिए. उपयोगकर्ता के पास यह चुनने का विकल्प होना चाहिए कि उसे कौनसे नेटवर्क का इस्तेमाल करना है. इसके लिए, किसी एक नेटवर्क को प्राथमिकता देने की ज़रूरत नहीं है. इस फ़्लो को Google की टीम से मंज़ूरी लेनी होगी.
फ़र्मवेयर से जुड़े अपडेट
ओटीए अपडेट की प्रोसेस और डिस्ट्रिब्यूशन को पार्टनर को मैनेज करना चाहिए. इसके लिए, उसे अपने मोबाइल या वेब ऐप्लिकेशन के वर्कफ़्लो का इस्तेमाल करना चाहिए.
फ़ास्ट पेयर की सुविधा, उपयोगकर्ता को सूचनाएं भेजने में मदद करती है. इससे, उपलब्ध ओटीए अपडेट के बारे में जानकारी मिलती है. इस सुविधा का इस्तेमाल करने के लिए:
- Nearby Device Console में, फ़र्मवेयर का नया वर्शन अपडेट होना चाहिए.
- आस-पास मौजूद डिवाइस कंसोल में, कंपैनियन ऐप्लिकेशन सेट होना चाहिए. इसमें फ़र्मवेयर अपडेट करने का इंटेंट होना चाहिए.
- Provider को फ़र्मवेयर वर्शन GATT विशेषता लागू करनी चाहिए.
ट्रैकिंग को रोकने के लिए, फ़र्मवेयर के वर्शन की जानकारी देने वाली विशेषता का ऐक्सेस सीमित होना चाहिए. डिवाइस को ढूंढने वाला व्यक्ति, सबसे पहले प्रोविज़निंग की स्थिति पढ़ेगा और इस स्पेसिफ़िकेशन में बताई गई पुष्टि करने वाली कुंजी देगा. इसके बाद ही, फ़र्मवेयर का वर्शन पढ़ा जाएगा. यह उसी कनेक्शन पर किया जाएगा. अगर फ़र्मवेयर के वर्शन को पढ़ने की कोशिश की जाती है और प्रोवाइडर न तो बॉन्ड किया गया है और न ही उसी कनेक्शन पर पुष्टि की गई कोई कार्रवाई पूरी हुई है, तो प्रोवाइडर को पुष्टि न होने की गड़बड़ी दिखानी चाहिए.
इनके साथ काम करता है
Find Hub नेटवर्क इस्तेमाल करने के लिए, जगह की जानकारी वाली सेटिंग और ब्लूटूथ चालू करना ज़रूरी है. इसके लिए, मोबाइल नेटवर्क या इंटरनेट कनेक्शन ज़रूरी है. यह सुविधा, Android 9 या उसके बाद के वर्शन वाले डिवाइसों पर काम करती है. साथ ही, यह सुविधा कुछ देशों में ऐसे लोगों के लिए उपलब्ध है जो उम्र से जुड़ी ज़रूरी शर्तें पूरी करते हैं.
बदलावों का लॉग
FHN वर्शन | तारीख | टिप्पणी |
---|---|---|
v1 | रिलीज़ होने से पहले इस्तेमाल करने के लिए, FHN स्पेसिफ़िकेशन की शुरुआती रिलीज़. | |
v1.1 | Feb 2023 |
|
v1.2 | अप्रैल 2023 |
|
v1.3 | दिसंबर 2023 |
|