विशेषताएं

फ़ास्ट पेयर की सुविधा

फ़ास्ट पेयर की सुविधा देने वाली कंपनी के पास, यह GATT सेवा होनी चाहिए.

सेवा यूयूआईडी
Fast Pair Service 0xFE2C

इस सेवा में ये सुविधाएं होनी चाहिए.

फ़ास्ट पेयर सेवा की विशेषता एन्क्रिप्ट किया गया अनुमतियां यूयूआईडी
मॉडल आईडी नहीं पढ़ें FE2C1233-8366-4814-8EB0-01DE32100BEA
की-आधारित पेयरिंग नहीं लिखें और सूचना दें FE2C1234-8366-4814-8EB0-01DE32100BEA
पासकी नहीं लिखें और सूचना दें FE2C1235-8366-4814-8EB0-01DE32100BEA
खाते की कुंजी नहीं लिखें FE2C1236-8366-4814-8EB0-01DE32100BEA

डिवाइस की जानकारी देने वाली सेवा

फ़ास्ट पेयर की सुविधा देने वाली कंपनी को डिवाइस की जानकारी देने वाली सेवा भी उपलब्ध करानी चाहिए.

सेवा यूयूआईडी
डिवाइस की जानकारी देने वाली सेवा 0x180A

फ़ास्ट पेयर सीकर में ये विशेषताएं होती हैं.

नाम एन्क्रिप्ट किया गया अनुमतियां यूयूआईडी
फ़र्मवेयर का वर्शन नहीं पढ़ें 0x2A26

खासियत: मॉडल आईडी

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

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 से 2 uint24 मॉडल आईडी बदलता रहता है

खासियत: कुंजी के आधार पर डिवाइसों को जोड़ना

यह विशेषता, कुंजी के आधार पर डिवाइसों को जोड़ने की प्रोसेस को कंट्रोल करती है. इस प्रोसेस में, यह पुष्टि करके भरोसे का एक लेवल तय किया जाता है कि Seeker और Provider, दोनों के पास पहले से शेयर की गई कुंजी है. हर मामले में, कुंजी अलग होती है:

  • पहला केस: पहले से शेयर की गई कुंजी, स्पूफ़िंग रोकने वाली सार्वजनिक/निजी कुंजी के जोड़े पर आधारित होती है. साथ ही, यह सीकर की अपनी सार्वजनिक/निजी कुंजी के जोड़े पर आधारित होती है. यह जोड़ा, पेयर करने की हर कोशिश के लिए बदल जाएगा.

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

    ध्यान दें कि पेयरिंग मोड में होने पर, सेवा देने वाली कंपनी सामान्य तरीके से भी पेयर कर सकती है. उदाहरण के लिए, किसी ऐसे डिवाइस से पेयर करने के लिए जो Fast Pair की कुंजी पर आधारित पेयरिंग की सुविधा के साथ काम नहीं करता है.

  • दूसरा मामला: पहले से शेयर की गई कुंजी, खाते की कुंजियों में से एक है.

    • आम तौर पर, प्रोवाइडर दूसरे डिवाइस से जोड़ने वाले मोड में नहीं होता. (हालांकि, यह ज़रूरी नहीं है. सेवा देने वाली कंपनी को, दूसरे डिवाइस से जोड़ने वाले मोड में भी खाते की कुंजी का इस्तेमाल करने की सुविधा देनी चाहिए.)
    • सीकर और प्रोवाइडर, दोनों यह पुष्टि करते हैं कि दूसरे के पास खाते की कुंजी है.

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

डेटा फ़ॉर्मैट

हर फ़ॉर्मैट को इस्तेमाल करने का तरीका देखें.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू क्या यह ज़रूरी है?
0 - 15 uint128 एन्क्रिप्ट (सुरक्षित) किया गया अनुरोध बदलता रहता है ज़रूरी है
16 से 79 सार्वजनिक कुंजी बदलता रहता है वैकल्पिक

टेबल 1.1: एन्क्रिप्ट किया गया अनुरोध, जिसे सीकर ने विशेषता के लिए लिखा है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू क्या यह ज़रूरी है?
0 uint8 मैसेज का टाइप 0x00 = कुंजी के आधार पर डिवाइस को फ़ोन से जोड़ने का अनुरोध ज़रूरी है
1 uint8 फ़्लैग
  • बिट 0 (एमएसबी): इसे अब इस्तेमाल नहीं किया जाता और Seeker इसे अनदेखा कर देता है.
  • बिट 1: अगर सीक करने वाला व्यक्ति, प्रोवाइडर से बॉन्डिंग शुरू करने का अनुरोध करता है और इस अनुरोध में सीक करने वाले व्यक्ति का बीआर/ईडीआर पता शामिल है, तो बिट 1 की वैल्यू 1 होगी. अन्यथा, 0.
  • बिट 2: 1, अगर सीकर यह अनुरोध करता है कि प्रोवाइडर को मौजूदा नाम की सूचना देनी चाहिए. अगर ऐसा नहीं है, तो 0 दिखेगा.
  • तीसरा बिट: अगर यह खाते की कुंजी को पिछली तारीख से लिखने के लिए है, तो 1. अगर ऐसा नहीं है, तो 0 दिखेगा.
  • बिट 4 से 7 को आने वाले समय में इस्तेमाल करने के लिए रिज़र्व किया गया है. इन्हें अनदेखा किया जाना चाहिए.
 अलग-अलग ज़रूरी है
2 - 7 uint48 इनमें से कोई एक तरीका अपनाएं:
  • सेवा देने वाली कंपनी का मौजूदा बीएलई पता
  • सेवा देने वाली कंपनी का सार्वजनिक पता
 अलग-अलग ज़रूरी है
8 - 13 uint48 नौकरी ढूंढने वाले व्यक्ति का बीआर/ईडीआर पता अलग-अलग होती है यह सिर्फ़ तब मौजूद होता है, जब फ़्लैग बिट 1 या 3 सेट हो
n - 15 रैंडम वैल्यू (सॉल्ट) अलग-अलग होती है ज़रूरी है

टेबल 1.2.1: रॉ अनुरोध (टाइप 0x00). टेबल 1.1 में, एन्क्रिप्ट किए गए अनुरोध से डिक्रिप्ट किया गया.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू क्या यह ज़रूरी है?
0 uint8 मैसेज का टाइप 0x10 = कार्रवाई का अनुरोध ज़रूरी है
1 uint8 फ़्लैग
  • बिट 0 (एमएसबी): अगर यह डिवाइस की कार्रवाई है, तो 1. ऐसा न होने पर, 0.
  • बिट 1: अगर इसके बाद अतिरिक्त डेटा की विशेषता होगी, तो 1. ऐसा न होने पर, 0.
  • बिट 2 से 7 को आने वाले समय में इस्तेमाल करने के लिए रिज़र्व किया गया है. इन्हें अनदेखा किया जाना चाहिए.
 अलग-अलग ज़रूरी है
2 - 7 uint48 इनमें से कोई एक तरीका अपनाएं:
  • सेवा देने वाली कंपनी का मौजूदा बीएलई पता
  • सेवा देने वाली कंपनी का सार्वजनिक पता
 अलग-अलग ज़रूरी है
8 uint8 ग्रुप चैट शुरू करें अलग-अलग अगर फ़्लैग बिट 0 सेट है, तो यह ज़रूरी है
9 uint8 मैसेज कोड अलग-अलग होती है अगर फ़्लैग बिट 0 सेट है, तो यह ज़रूरी है
10 uint8 फ़्लैग पर निर्भर करता है:
  • बिट 0 सेट है: अतिरिक्त डेटा की लंबाई, 6 से कम है
  • बिट 1 सेट है: डेटा आईडी
 अलग-अलग अगर फ़्लैग बिट 0 या 1 सेट है, तो यह ज़रूरी है
11 - n अतिरिक्त डेटा अलग-अलग वैकल्पिक
n - 15 रैंडम वैल्यू (सॉल्ट) अलग-अलग होती है ज़रूरी है

टेबल 1.2.2: रॉ अनुरोध (टाइप 0x10). टेबल 1.1 में, एन्क्रिप्ट (सुरक्षित) किए गए अनुरोधों को डिक्रिप्ट किया गया.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 मैसेज का टाइप 0x01 = कुंजी के आधार पर डिवाइस को जोड़ने का जवाब
1 - 6 uint48 सेवा देने वाली कंपनी का सार्वजनिक (बीआर/ईडीआर) पता अलग-अलग
7 - 15 रैंडम वैल्यू (सॉल्ट) अलग-अलग

टेबल 1.3: रॉ रिस्पॉन्स. टेबल 1.4 में एन्क्रिप्ट किया गया जवाब जनरेट करने के लिए एन्क्रिप्ट किया गया है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 -15 uint128 एन्क्रिप्ट (सुरक्षित) किया गया जवाब अलग-अलग होती है

टेबल 1.4: एन्क्रिप्ट किया गया रिस्पॉन्स, जिसे प्रोवाइडर ने सूचना के ज़रिए सीकर को भेजा है.

खास सुविधा: पासकी

इस विशेषता का इस्तेमाल, की-आधारित पेयरिंग की प्रक्रिया के दौरान किया जाता है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 - 15 uint128 एन्क्रिप्ट किया गया पासकी ब्लॉक अलग-अलग

टेबल 2.1: एन्क्रिप्ट (सुरक्षित) किया गया पासकी ब्लॉक. इस्तेमाल करने के लिए, कुंजी के आधार पर पेयर करने की प्रक्रिया देखें.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 मैसेज का टाइप इनमें से एक:
  • 0x02 = Seeker's Passkey
  • 0x03 = सेवा देने वाली कंपनी की पासकी
1 से 3 unit32 छह अंकों वाली पासकी अलग-अलग
4 - 15 रैंडम वैल्यू (सॉल्ट) अलग-अलग होती है

टेबल 2.2: रॉ पासकी ब्लॉक. टेबल 2.1 का डिक्रिप्ट किया गया वर्शन.

खासियत: खाते की कुंजी

पेयर करने के बाद, फ़ास्ट पेयर की सुविधा वाला सीकर, फ़ास्ट पेयर की सुविधा वाले प्रोवाइडर को खाते की कुंजी देगा.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 - 15 uint128 खाते की कुंजी (एन्क्रिप्ट की गई) अलग-अलग

लिखने का अनुरोध मिलने पर, फ़ास्ट पेयर Provider ये काम करेगा:

  1. तरीके के चौथे चरण में जनरेट किए गए सीक्रेट पासवर्ड का इस्तेमाल करके, खाते की कुंजी को डिक्रिप्ट करें.
    • सेवा देने वाली ऐसी कंपनियों के लिए जिन्हें बॉन्ड की ज़रूरत होती है (सामान्य):
      • डिक्रिप्ट करने से पहले, पुष्टि करें कि शेयर किए गए सीक्रेट का इस्तेमाल, 12वें चरण में पासकी के अनुरोध को डिक्रिप्ट करने के लिए किया गया था. अगर इस सीक्रेट का इस्तेमाल करके यह चरण पूरा नहीं हुआ है, तो इस राइट को अनदेखा करें और बाहर निकलें.
    • इस समय, शेयर किए गए सीक्रेट पासवर्ड (प्रक्रिया में K) का इस्तेमाल, इस पेयरिंग के लिए फिर से नहीं किया जाएगा. इस कुंजी से एन्क्रिप्ट (सुरक्षित) किए गए किसी भी अनुरोध को अस्वीकार कर दिया जाना चाहिए. इसके लिए, प्रोसेस को रीस्टार्ट करने की ज़रूरत नहीं है.
  2. पुष्टि करें कि डिक्रिप्ट की गई वैल्यू, 0x04 या 0xFF से शुरू होती हो. अगर ऐसा नहीं है, तो इस मैसेज को अनदेखा करें और बाहर निकलें.
    • अगर वैल्यू 0x04 है, तो:
      • देखें कि सेव की गई खाते की कुंजी की सूची में नई वैल्यू के लिए जगह है या नहीं.
      • अगर ऐसा नहीं है, तो सूची से सबसे पुरानी वैल्यू मिटाएं.
      • सूची में नई वैल्यू जोड़ें.
    • अगर वैल्यू 0xFF है, तो:
      • इसे कुछ समय के लिए किया गया पेयरिंग सेशन मानें और कोई कार्रवाई न करें.
      • ऐसा खाते की कुंजी को पहले की तारीख से लिखने के फ़्लो की वजह से हो सकता है.
      • कुंजी को सेव न करें. साथ ही, इसका इस्तेमाल खाते की कुंजी की सूची, एन्क्रिप्ट करने के तरीके या MAC कैलकुलेशन में न करें.
      • बॉन्ड हटाने की सुविधा, किसी खास सुविधा से जुड़े इवेंट या टाइम आउट होने पर ट्रिगर होती है. एलई ऑडियो शेयर करने की सुविधा के लिए, हमारा सुझाव है कि कुछ समय के लिए सेशन डिसकनेक्ट होने के 10 मिनट बाद, बीएलई बॉन्ड और लिंक की को हटा दें.

सूची में मौजूद खाते की कुंजियों का इस्तेमाल, कुंजी के आधार पर डिवाइसों को जोड़ने के दौरान किया जाता है.

विशेषता: फ़र्मवेयर का वर्शन

इस विशेषता की मदद से, सीकर ज़रूरत पड़ने पर प्रोवाइडर के फ़र्मवेयर के वर्शन को पढ़ सकता है. इसे हमेशा यह डेटा दिखाना चाहिए:

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 - var utf8s फ़र्मवेयर का रिविज़न कोड अलग-अलग

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

  1. status-updating: अगर प्रोवाइडर, फ़िलहाल नए फ़र्मवेयर पर अपडेट कर रहा है. इसके अलावा, प्रोवाइडर, स्टेज किए गए फ़र्मवेयर का वर्शन दिखा सकता है.

  2. status-abnormal: अगर प्रोवाइडर की स्थिति असामान्य है. उदाहरण के लिए, फ़र्मवेयर का अपडेट न होने की वजह से, डिवाइस ठीक से काम नहीं कर रहा है. इस वैल्यू की वजह से, Seeker एक मैसेज दिखाएगा. इससे उपयोगकर्ता को पता चलेगा कि उसे अब अपडेट करना होगा.

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

  • कनेक्ट किए गए डिवाइसों के पास, कभी भी ऐक्सेस होना चाहिए
  • जब प्रोवाइडर डिवाइस खोजे जाने लायक हो, तब किसी भी डिवाइस के पास उसका ऐक्सेस होना चाहिए

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

विशेषता: अतिरिक्त डेटा

इस सेवा में ये विशेषताएं होनी चाहिए.

फ़ास्ट पेयर सेवा की विशेषता एन्क्रिप्ट किया गया अनुमतियां यूयूआईडी
डेटा नहीं लिखें और सूचना दें FE2C1237-8366-4814-8EB0-01DE32100BEA
फ़ास्ट पेयर की सुविधा वाली पुरानी सेवा की विशेषता (इसे 1/1/2021 को बंद कर दिया जाएगा) एन्क्रिप्ट किया गया अनुमतियां यूयूआईडी
डेटा नहीं लिखें और सूचना दें 0x1237

इस विशेषता को लिखने या इसकी सूचना देने से पहले, विशेषता FE2C1234-8366-4814-8EB0-01DE32100BEA के ज़रिए हैंडशेक होना चाहिए, ताकि शेयर किया गया सीक्रेट मिल सके. इस विशेषता से मिलने वाले डेटा को एन्क्रिप्ट (सुरक्षित) करने के लिए, एईएस-सीटीआर का इस्तेमाल किया जाएगा. इसका एल्गोरिदम नीचे बताया गया है. यह मोड, 16 बाइट के एक ब्लॉक से ज़्यादा डेटा के लिए ज़्यादा सुरक्षित है. डेटा के रखरखाव को पक्का करने के लिए, HMAC-SHA256 का इस्तेमाल किया जाएगा. इसके बारे में यहां भी बताया गया है.

ऑक्टेट ब्यौरा वैल्यू
0 से 7 HMAC-SHA256 के पहले 8 बाइट. अलग-अलग
8 - 15 Nonce, जिसका इस्तेमाल एईएस-सीटीआर एन्क्रिप्शन के लिए किया जाता है. अलग-अलग
16 - var एन्क्रिप्ट (सुरक्षित) किया गया डेटा. अलग-अलग होती है

टेबल 3.1: डेटा पैकेट, जिसे प्रोवाइडर, सूचना के ज़रिए सीकर को भेजता है या सीकर, राइट के ज़रिए प्रोवाइडर को भेजता है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 - var byte array डेटा अलग-अलग है, तो उसे टेबल 1.2.2 के डेटा आईडी के हिसाब से डिकोड करें:
  • 0x01(personalized name): utf8s

टेबल 3.2: रॉ डेटा. टेबल 3.1 में मौजूद एन्क्रिप्ट (सुरक्षित) किए गए डेटा को डिक्रिप्ट किया गया.

जब सूचना देने का अनुरोध किया जाता है (जैसे, टेबल 1.2.1 में Bit 2 के ज़रिए नाम को पसंद के मुताबिक बनाने का अनुरोध), तो Fast Pair Provider को ये काम करने होंगे:

  1. Nonce के लिए, क्रिप्टोग्राफ़िक तौर पर रैंडम आठ बाइट जनरेट करें.

  2. एईएस-सीटीआर का इस्तेमाल करके डेटा को एन्क्रिप्ट (सुरक्षित) करें. इसमें हर 16-बाइट ब्लॉक को जनरेट करने के लिए,

    encryptedBlock[i] = clearBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))

    कहां

    1. एईएस कुंजी, तरीके के चौथे चरण में शेयर किया गया सीक्रेट पासवर्ड है.
    2. clearBlock[i], 16-बाइट का ब्लॉक है. यह data[i * 16] से शुरू होता है. आखिरी ब्लॉक 16 बाइट से कम का हो सकता है.

  3. एन्क्रिप्ट किया गया डेटा बनाने के लिए, concat(encryptedBlock[0], encryptedBlock[1],...) को लागू करें.

  4. HMAC-SHA256 को जनरेट करने के लिए,

    sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, encrypted_data)))))

    कहां

    1. K को concat(shared_secret, 48-byte ZEROs) से जनरेट किया जाता है. shared_secret, प्रोसेस के चौथे चरण से मिलता है.
    2. opad, 64 बाइट की बाहरी पैडिंग है. इसमें 0x5C वैल्यू वाले दोहराए गए बाइट शामिल होते हैं.
    3. ipad, 64 बाइट की इनर पैडिंग है. इसमें 0x36 वैल्यू वाले रिपीटेड बाइट शामिल होते हैं.

  5. डेटा पैकेट के प्रीफ़िक्स के तौर पर, HMAC-SHA256 से पहले 8 बाइट लें.

डेटा सेव करने का अनुरोध मिलने पर, फ़ास्ट पेयर की सुविधा देने वाली कंपनी को ये काम करने होंगे:

  1. HMAC-SHA256 के पहले आठ बाइट की जांच करके, डेटा की अखंडता की पुष्टि करें.

  2. एईएस-सीटीआर का इस्तेमाल करके, एन्क्रिप्ट किए गए डेटा को डिक्रिप्ट करें. इसमें हर ब्लॉक को जनरेट करने के लिए,

    clearBlock[i] = encryptedBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))

    कहां

    1. encryptedBlock[i], 16 बाइट का ब्लॉक है. यह encrypted_data[i * 16] से शुरू होता है. आखिरी ब्लॉक 16 बाइट से कम का हो सकता है.
    2. एईएस कुंजी को हैंडशेक से जनरेट किया जाता है या उसकी पहचान की जाती है. उदाहरण के लिए,
      1. नाम देने की प्रोसेस 1 में, यह ECDH से लिया गया है. इसका इस्तेमाल इस पेयरिंग के लिए दोबारा नहीं किया जाएगा. इस कुंजी के साथ एन्क्रिप्ट (सुरक्षित) किए गए किसी भी अनुरोध को अस्वीकार कर दिया जाना चाहिए. इसके लिए, प्रक्रिया को फिर से शुरू करने की ज़रूरत नहीं है.
      2. नाम देने के फ़्लो 2 में, यह खाते की कुंजी होती है.

  3. रॉ डेटा बनाने के लिए, concat(clearBlock[0], clearBlock[1],...) को लागू करें.