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

फ़ास्ट पेयर की सेवा देने वाली कंपनी, फ़ास्ट पेयर की सेवा (UUID 0xFE2C) लागू करेगी. इसमें ये विशेषताएं शामिल हैं.

नाम एन्क्रिप्ट किया गया अनुमतियां यूयूआईडी क्या यह ज़रूरी है?
मॉडल आईडी नहीं पढ़ें FE2C1233-8366-4814-8EB0-01DE32100BEA ज़रूरी है
कुंजी के आधार पर डिवाइसों को जोड़ना नहीं लिखें और सूचना दें FE2C1234-8366-4814-8EB0-01DE32100BEA ज़रूरी है
पासकी नहीं लिखें और सूचना दें FE2C1235-8366-4814-8EB0-01DE32100BEA ज़रूरी है
खाते की कुंजी नहीं लिखें FE2C1236-8366-4814-8EB0-01DE32100BEA ज़रूरी है
अतिरिक्त डेटा नहीं लिखें और सूचना दें FE2C1237-8366-4814-8EB0-01DE32100BEA *C1
मैसेज स्ट्रीम पीएसएम हां पढ़ें FE2C1239-8366-4814-8EB0-01DE32100BEA *C2
अन्य पासकी नहीं पढ़ने, लिखने, और सूचना देने की अनुमति FE2C123A-8366-4814-8EB0-01DE32100BEA *C3
FP Device Action नहीं लिखें और सूचना दें FE2C123B-8366-4814-8EB0-01DE32100BEA *C4

शर्तों के मुताबिक ज़रूरी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू क्या यह ज़रूरी है?
0 uint8 मैसेज का टाइप 0x10 = कार्रवाई का अनुरोध ज़रूरी है
1 uint8 फ़्लैग अलग-अलग ज़रूरी है
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: रॉ रिस्पॉन्स (टाइप 0x01). एन्क्रिप्ट (सुरक्षित) किया जाता है, ताकि टेबल 1.4 में एन्क्रिप्ट किया गया रिस्पॉन्स जनरेट किया जा सके.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 मैसेज का टाइप 0x02 = Key-based Pairing Extended Response
1 uint8 फ़्लैग
  • बिट 0 (एमएसबी): अगर सेवा देने वाली कंपनी का डिवाइस सिर्फ़ LE है, तो 1. ऐसा न होने पर, 0. अगर बिट 0 को 1 पर सेट किया जाता है, तो सीकर यह मान लेगा कि बिट 1 को 1 पर सेट किया गया है.
  • बिट 1: अगर सेवा देने वाली कंपनी को LE बॉन्डिंग पसंद है, तो 1. ऐसा न होने पर, 0.
  • बिट 2: अगर दूसरे पते का टाइप रैंडम है, तो 1. अगर सार्वजनिक है, तो 0.
  • बिट 3 से 7 को आने वाले समय में इस्तेमाल करने के लिए रिज़र्व किया गया है. इन्हें अनदेखा किया जाना चाहिए.
 अलग-अलग
2 uint8 सेवा देने वाली कंपनी के पतों की संख्या
मान्य वैल्यू 1 और 2 हैं.		 अलग-अलग
3 - 8 या
3 - 14
  • पहला पता, प्राइमरी डिवाइस का आइडेंटिटी पता होना चाहिए. साथ ही, अगर बीआर/ईडीआर बॉन्डिंग को प्राथमिकता दी जाती है, तो यह बॉन्ड करने लायक होना चाहिए
  • अगर दूसरा पता उपलब्ध है, तो वह बॉन्ड किया जा सकने वाला पता होना चाहिए
 अलग-अलग
9 - 15 या 15 रैंडम वैल्यू (सॉल्ट) अलग-अलग

टेबल 1.3.2: रॉ रिस्पॉन्स (टाइप 0x02). एन्क्रिप्ट (सुरक्षित) किया जाता है, ताकि टेबल 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 खाते की कुंजी (एन्क्रिप्ट की गई) अलग-अलग

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

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

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

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

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

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

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

ऑक्टेट ब्यौरा वैल्यू
0 से 7 HMAC-SHA256 के पहले आठ बाइट. अलग-अलग
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 में बिट 2 के ज़रिए, नाम को आपकी दिलचस्पी के हिसाब से बनाने का अनुरोध), तो फ़ास्ट पेयर की सेवा देने वाली कंपनी को ये काम करने होंगे:

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

  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. एचएमएसी-एसएचए256 जनरेट करने के लिए,

    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 से पहले आठ बाइट को डेटा पैकेट के प्रीफ़िक्स के तौर पर लें.

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

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

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

खासियत: मैसेज स्ट्रीम पीएसएम

BLE डिवाइस: मैसेज स्ट्रीम पीएसएम देखें

खासियत: अतिरिक्त पासकी

BLE डिवाइस: अतिरिक्त पासकी देखें

खासियत: एफ़पी डिवाइस ऐक्शन

फ़ास्ट पेयर सेवा की विशेषता एन्क्रिप्ट किया गया अनुमतियां यूयूआईडी
एफ़पी डिवाइस ऐक्शन नहीं लिखें और सूचना दें FE2C123B-8366-4814-8EB0-01DE32100BEA

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

टेबल 4.1: डेटा पैकेट, जिसे सेवा देने वाली कंपनी, सूचना के तौर पर सेवा पाने वाले को भेजती है या सेवा पाने वाला, सेवा देने वाली कंपनी को राइट के तौर पर भेजता है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 - var byte array कार्रवाई का अनुरोध इनमें से एक:
  • पसंद के मुताबिक नाम पढ़ें, 0x01
  • निजी नाम लिखें, टेबल 4.3.1 देखें
  • एक साथ काम करने वाले सेट की जानकारी पढ़ें, 0x02
  • डिवाइस की सुविधाओं के बारे में जानें, 0x03

टेबल 4.2: रॉ डेटा. टेबल 4.1 में एन्क्रिप्ट (सुरक्षित) किए गए डेटा से डिक्रिप्ट किया गया डेटा, जिसे सीकर ने प्रोवाइडर को राइट के तौर पर भेजा है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 - var byte array कार्रवाई का जवाब इनमें से एक:
  • पसंद के मुताबिक नाम, टेबल 4.3.1 देखें
  • कोऑर्डिनेटेड सेट की जानकारी, टेबल 4.3.2 देखें
  • डिवाइस की सुविधाएं, टेबल 4.3.3 देखें
  • गड़बड़ी का कोड
    • 0x80 (Unsupported Request)
    • 0x81 (अमान्य अनुरोध)

टेबल 4.3: रॉ डेटा. टेबल 4.1 में एन्क्रिप्ट (सुरक्षित) किए गए डेटा से डिक्रिप्ट किया गया डेटा, जिसे सेवा देने वाली कंपनी ने सूचना के तौर पर सीकर को भेजा है.

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 कार्रवाई ID 0x01
1 - var utf8s पसंद के मुताबिक नाम बदलता रहता है

टेबल 4.3.1: Personalized Name Format

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 कार्रवाई ID 0x02
1 uint8 फ़ास्ट पेयर की सुविधा वाले कोऑर्डिनेटेड सेट के सदस्य का टाइप
  • 0x00: बायां कॉम्पोनेंट
  • 0x01: दायां कॉम्पोनेंट
2 uint8 एक जैसे सेट का साइज़ कॉम्पोनेंट की संख्या
3 uint8 पहचान की पुष्टि करने वाली कुंजी का टाइप सेट करना 0x01 (सामान्य टेक्स्ट एसआईआरके)
4 - 19 uint128 पहचान की पुष्टि करने वाली कुंजी की वैल्यू सेट करें 16-बाइट डेटा, कोऑर्डिनेटेड सेट आइडेंटिफ़िकेशन सर्विस देखें

टेबल 4.3.2: कोऑर्डिनेटेड सेट की जानकारी का फ़ॉर्मैट

ऑक्टेट डेटा टाइप ब्यौरा वैल्यू
0 uint8 कार्रवाई ID 0x03
1 - 2 uint16 डिवाइस की सुविधाएं
  • बिट 0 से 15: रिज़र्व हैं, इन्हें 0 पर सेट किया जाना चाहिए

टेबल 4.3.3: डिवाइस की सुविधाओं का फ़ॉर्मैट

फ़ास्ट पेयर की सुविधा से जुड़े ऑपरेशन

इस विशेषता के लिए दो मुख्य ऑपरेशन तय किए गए हैं

  • फ़ास्ट पेयर की सुविधा से डेटा पढ़ना: सेवा देने वाली कंपनी से डेटा पढ़ना
    1. सीकर: GATT सूचना चालू करें
    2. सेवा देने वाली कंपनी: GATT सूचना रजिस्टर की गई
    3. सीकर: GATT राइट रिक्वेस्ट, रॉ डेटा में सिर्फ़ Action ID शामिल है
    4. सेवा देने वाली कंपनी: GATT Write Response
    5. सेवा देने वाली कंपनी: GATT सूचना, रॉ डेटा में शामिल है
      • कार्रवाई ID
      • कार्रवाई के आईडी का डेटा
    6. सीकर: GATT सूचना मिली
  • फ़ास्ट पेयर राइट: सेवा देने वाली कंपनी के लिए डेटा लिखना
    1. सीकर: GATT राइट रिक्वेस्ट, रॉ डेटा में यह शामिल है
      • कार्रवाई ID
      • कार्रवाई के आईडी का डेटा
    2. प्रोवाइडर: GATT Write response

फ़ास्ट पेयर की सुविधा के साथ काम करने वाली कार्रवाई का आईडी

  • 0x01 (पसंद के मुताबिक नाम)
  • 0x02 (Coordinated set information)
  • 0x03 (डिवाइस की सुविधाएं)

फ़ास्ट पेयर की सुविधा के साथ काम करने वाली कार्रवाई का आईडी

अगर प्रोवाइडर को कार्रवाई का आईडी समझ नहीं आता है, तो वह GATT सूचना के साथ जवाब देता है. इसमें, अनुरोध के काम न करने (0x80) की जानकारी होती है. इसके बारे में टेबल 4.3 में बताया गया है.

क्रिप्टो एल्गोरिदम

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

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

  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. एचएमएसी-एसएचए256 जनरेट करने के लिए,

    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 से पहले आठ बाइट को डेटा पैकेट के प्रीफ़िक्स के तौर पर लें.

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

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

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

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

फ़ास्ट पेयर की सुविधा देने वाले डिवाइस में, डिवाइस की जानकारी देने वाली सेवा (UUID 0x180A) भी काम करनी चाहिए. फ़ास्ट पेयर की सुविधा इस्तेमाल करने वाला डिवाइस, इन विशेषताओं का इस्तेमाल करता है.

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

खासियत: फ़र्मवेयर में किया गया बदलाव

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

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

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

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

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

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

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

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