מאפיינים

שירות ההתאמה המהירה

לספק התכונה 'התאמה מהירה' יהיה שירות GATT הבא.

שירות מזהה ייחודי אוניברסלי (UUID)
שירות ההתאמה המהירה 0xFE2C

לשירות הזה יהיו המאפיינים הבאים.

מאפיין של שירות ההתאמה המהירה מוצפן הרשאות מזהה ייחודי אוניברסלי (UUID)
מזהה דגם לא קריאה FE2C1233-8366-4814-8EB0-01DE32100BEA
התאמה מבוססת-מפתח לא כתיבה ושליחת הודעות FE2C1234-8366-4814-8EB0-01DE32100BEA
מפתח גישה לא כתיבה ושליחת הודעות FE2C1235-8366-4814-8EB0-01DE32100BEA
מפתח החשבון לא כתיבה FE2C1236-8366-4814-8EB0-01DE32100BEA

שירות מידע על המכשיר

הספק של התכונה 'התאמה מהירה' צריך גם לתמוך בשירות מידע על המכשיר.

שירות מזהה ייחודי אוניברסלי (UUID)
שירות מידע על המכשיר 0x180A

התכונות הבאות משמשות לחיפוש התקנים באמצעות התאמה מהירה.

שם מוצפן הרשאות מזהה ייחודי אוניברסלי (UUID)
גרסת הקושחה לא קריאה 0x2A26

מאפיין: מזהה המודל

המאפיין הזה מאפשר ל-Seeker לקרוא את מזהה המודל לפי הצורך, גם כשהמכשיר לא משדר במצב גלוי. הפונקציה צריכה תמיד להחזיר את הנתונים הבאים:

Octet סוג הנתונים תיאור ערך
‎0 - 2 uint24 מזהה דגם משתנה

מאפיין: התאמה מבוססת-מפתח

המאפיין הזה קובע את ההליך של התאמה מבוססת-מפתח. בתהליך הזה, רמת אמון מסוימת נקבעת על ידי אימות העובדה שגם המבקש וגם הספק מחזיקים במפתח ששותף מראש. המפתח שונה בכל מקרה:

  • תרחיש 1: המפתח המשותף מבוסס על זוג המפתחות הציבורי/הפרטי למניעת זיוף, ועל זוג המפתחות הציבורי/הפרטי של המכשיר המחפש, שמשתנה בכל ניסיון התאמה.

    • הספק נמצא במצב התאמה.
    • הבודק מוודא שהספק מחזיק במפתח הפרטי למניעת זיוף.

    שימו לב: במצב התאמה, הספק יכול גם להתאים בדרך הרגילה, למשל להתאמה למכשיר שלא תומך בהתאמה מבוססת-מפתח של התאמה מהירה.

  • מקרה 2: המפתח ששותף מראש הוא אחד ממפתחות החשבון.

    • בדרך כלל הספק לא נמצא במצב התאמה. (אבל זה לא חובה – הספק צריך לתמוך בשימוש במפתח חשבון גם במצב התאמה).
    • הצד שמחפש והצד שמספק מאמתים כל אחד בנפרד שהצד השני מחזיק במפתח החשבון.

שני המקרים דומים מאוד, למעט המפתח המשותף מראש שבו נעשה שימוש, ולכן הם משולבים בהליך.

פורמט נתונים

בהליך מוסבר איך משתמשים בכל פורמט.

Octet סוג הנתונים תיאור ערך חובה?
‫0 - 15 uint128 בקשה מוצפנת משתנה חובה
‫16-79 מפתח ציבורי משתנה אופציונלי

טבלה 1.1: בקשה מוצפנת, שנכתבה למאפיין על ידי המבקש.

Octet סוג הנתונים תיאור ערך חובה?
0 uint8 סוג ההודעה ‫0x00 = בקשת התאמה מבוססת-מפתח חובה
1 uint8 סימונים
  • ביט 0 (MSB): הוצא משימוש ומערכת Seeker מתעלמת ממנו.
  • ביט 1: הערך הוא 1 אם המבקש מבקש שהספק יתחיל את ההתאמה, והבקשה הזו מכילה את כתובת ה-BR/EDR של המבקש. אחרת, הערך הוא 0.
  • ביט 2: הערך הוא 1 אם המבקש מבקש שהספק יודיע על השם הקיים. אחרת, הערך הוא 0.
  • ביט 3: 1 אם מדובר בכתיבה רטרואקטיבית של מפתח החשבון. אחרת, הערך הוא 0.
  • הביטים 4 עד 7 שמורים לשימוש עתידי, וצריך להתעלם מהם.
 משתנה חובה
2 - 7 uint48 אחת משתי האפשרויות:
  • כתובת ה-BLE הנוכחית של הספק
  • הכתובת הציבורית של הספק
 משתנה חובה
‫8 - 13 uint48 כתובת ה-BR/EDR של המחפש משתנה הערך הזה מופיע רק אם הביט 1 או 3 של Flags מוגדר
‫n – 15 ערך אקראי (salt) משתנה חובה

טבלה 1.2.1: בקשה גולמית (סוג 0x00). הפענוח של הבקשה המוצפנת ב טבלה 1.1.

Octet סוג הנתונים תיאור ערך חובה?
0 uint8 סוג ההודעה ‫0x10 = בקשה לפעולה חובה
1 uint8 סימונים
  • ביט 0 (MSB): ‏ 1 אם מדובר בפעולה במכשיר, אחרת 0.
  • ביט 1: הערך הוא 1 אם אחריו יופיע מאפיין נתונים נוסף, אחרת הערך הוא 0.
  • הביטים 2 עד 7 שמורים לשימוש עתידי, וצריך להתעלם מהם.
 משתנה חובה
2 - 7 uint48 אחת משתי האפשרויות:
  • כתובת ה-BLE הנוכחית של הספק
  • הכתובת הציבורית של הספק
 משתנה חובה
8 uint8 שליחת הודעה לקבוצה משתנה חובה אם הביט 0 של הסימונים מוגדר
9 uint8 קוד ההודעה משתנה חובה אם הביט 0 של הסימונים מוגדר
10 uint8 תלוי בסימונים:
  • הביט 0 מוגדר: אורך הנתונים הנוספים, פחות מ-6
  • הביט 1 מוגדר: מזהה נתונים
 משתנה חובה אם ביט 0 או 1 של הסימונים מוגדרים
‫11 – n נתונים נוספים משתנה אופציונלי
‫n – 15 ערך אקראי (salt) משתנה חובה

טבלה 1.2.2: בקשה גולמית (סוג 0x10). הפענוח של הבקשה המוצפנת ב טבלה 1.1.

Octet סוג הנתונים תיאור ערך
0 uint8 סוג ההודעה ‫0x01 = תגובה להתאמה מבוססת-מפתח
1 - 6 uint48 כתובת ציבורית של הספק (BR/EDR) משתנה
‫7-15 ערך אקראי (salt) משתנה

טבלה 1.3: תשובה גולמית. מוצפן כדי ליצור את התשובה המוצפנת ב טבלה 1.4.

Octet סוג הנתונים תיאור ערך
0 -15 uint128 תשובה מוצפנת משתנה

טבלה 1.4: תגובה מוצפנת שנשלחת מהספק אל המבקש באמצעות הודעה.

מאפיין: מפתח גישה

המאפיין הזה משמש במהלך ההתאמה מבוססת המפתח

Octet סוג הנתונים תיאור ערך
‫0 - 15 uint128 בלוק מוצפן של מפתח גישה משתנה

טבלה 2.1: בלוק של מפתח גישה מוצפן. מידע על תהליך ההתאמה מבוסס המפתח לשימוש

Octet סוג הנתונים תיאור ערך
0 uint8 סוג ההודעה אחת מהאפשרויות הבאות:
  • ‫0x02 = מפתח הגישה של Seeker
  • ‫0x03 = מפתח הגישה של הספק
1 - 3 unit32 מפתח גישה בן 6 ספרות משתנה
‫4 עד 15 ערך אקראי (salt) משתנה

טבלה 2.2: בלוק סיסמאות גולמיות. גרסה מפוענחת של טבלה 2.1.

מאפיין: מפתח החשבון

אחרי ההתאמה, התכונה 'התאמה מהירה' תכתוב מפתח חשבון לספק של התכונה 'התאמה מהירה'.

Octet סוג הנתונים תיאור ערך
‫0 - 15 uint128 מפתח החשבון (מוצפן) משתנה

כשספק Fast Pair מקבל בקשת כתיבה, הוא מבצע את הפעולות הבאות:

  1. מפענחים את מפתח החשבון באמצעות סוד לשימוש עם טוקן צרכן שנוצר בשלב 4 בתהליך.
    • לספקים שדורשים שילוב (נפוץ):
      • לפני שמפענחים, צריך לוודא שהסוד לשימוש עם טוקן צרכן שימש לפענוח בקשת מפתח הגישה משלב 12. אם השלב הזה לא עבר באמצעות הסוד הזה, צריך להתעלם מהכתיבה הזו ולצאת.
    • בשלב הזה, הסוד המשותף (K בתהליך) לא ישמש יותר להתאמה הזו. צריך לדחות את כל הבקשות שמוצפנות באמצעות המפתח הזה בלי להפעיל מחדש את התהליך.
  2. מוודאים שהערך המפוענח מתחיל ב-0x04 או ב-0xFF. אם לא, צריך להתעלם מהפעולה הזו ולצאת.
    • אם הערך הוא 0x04:
      • בודקים אם יש מקום לערך החדש ברשימת מפתחות החשבון שנשמרה.
      • אם לא, מוחקים מהרשימה את הערך שהשימוש בו היה הכי מזמן.
      • מוסיפים את הערך החדש לרשימה.
    • אם הערך הוא 0xFF:
      • התייחסו לזה כאל סשן זמני של התאמה ואל תבצעו שום פעולה.
      • זה יכול לקרות בתהליך כתיבת מפתח חשבון רטרואקטיבית.
      • אל תשמרו את המפתח ואל תשתמשו בו ברשימת מפתחות החשבון, בהצפנה או בחישובים של MAC.
      • הסרת הקשר מופעלת על ידי אירוע או פסק זמן שספציפיים לתכונה. במקרה של שיתוף אודיו ב-LE, מומלץ מאוד להסיר את הקישוריות ב-BLE ואת מפתח הקישור 10 דקות אחרי הניתוק של הסשן הזמני.

מפתחות החשבון ברשימה משמשים במהלך שיוך מבוסס-מפתח.

מאפיין: גרסת קושחה

המאפיין הזה מאפשר ל-Seeker לקרוא את עדכון הקושחה של ה-Provider לפי הצורך. הפונקציה צריכה תמיד להחזיר את הנתונים הבאים:

Octet סוג הנתונים תיאור ערך
‫0 – var utf8s קוד גרסת הקושחה משתנה

היא צריכה להיות מוצגת כמחרוזת utf8 אחת, גם אם יש יותר מגרסת קושחה אחת (למשל, 3 גרסאות קושחה לאוזנייה השמאלית, לאוזנייה הימנית ולנרתיק) אצל הספק. הספק יכול גם להחזיר את המחרוזות הספציפיות למקרים מיוחדים:

  1. ‫status-updating: אם הספק מעדכן כרגע לקושחה חדשה. לחלופין, הספק יכול להחזיר את הגרסה של הקושחה שהועברה להמתנה.

  2. ‫status-abnormal: אם הספק נמצא במצב לא תקין. לדוגמה, יכול להיות שהמכשיר לא פועל כי עדכון הקושחה נכשל. הערך הזה יגרום לכך שהכלי Seeker יציג הודעה למשתמשים כדי ליידע אותם שהם צריכים לעדכן אותו עכשיו.

הספק צריך להגביל את הגישה למאפיין Firmware Revision כדי למנוע מעקב אחרי המכשיר. הגבלות מוצעות:

  • למכשירים שמחוברים באמצעות Bluetooth צריכה להיות גישה בכל שלב
  • לכל מכשיר צריכה להיות גישה כשהספק גלוי

מאפיין: נתונים נוספים

השירות הזה צריך לכלול את המאפיין הבא.

מאפיין של שירות ההתאמה המהירה מוצפן הרשאות מזהה ייחודי אוניברסלי (UUID)
נתונים לא כתיבה ושליחת הודעות FE2C1237-8366-4814-8EB0-01DE32100BEA
מאפיין ישן של שירות התאמה מהירה (הוצא משימוש ב-1/1/2021) מוצפן הרשאות מזהה ייחודי אוניברסלי (UUID)
נתונים לא כתיבה ושליחת הודעות 0x1237

לפני כתיבה או שליחת הודעה למאפיין הזה, צריך לבצע לחיצת יד דרך מאפיין FE2C1234-8366-4814-8EB0-01DE32100BEA כדי ליצור סוד לשימוש עם טוקן צרכן. הצפנה באמצעות AES-CTR תשמש להצפנת נתונים שזורמים דרך המאפיין הזה. האלגוריתם מוגדר בהמשך. המצב הזה מאובטח יותר כשמדובר בנתונים שגדולים מבלוק אחד של 16 בייט. האימות יתבצע באמצעות HMAC-SHA256 כדי לוודא את תקינות הנתונים, כפי שמוגדר בהמשך.

Octet תיאור ערך
‫0 - 7 ‫8 הבייטים הראשונים של HMAC-SHA256. משתנה
‫8-15 ערך חד-פעמי (Nonce), שמשמש להצפנת AES-CTR. משתנה
‫16 – var נתונים מוצפנים. משתנה

טבלה 3.1: מנות נתונים שנשלחות מהספק אל המבקש באמצעות הודעה, או מהמבקש אל הספק באמצעות פעולת כתיבה.

Octet סוג הנתונים תיאור ערך
‫0 – var byte array נתונים ‫varies, צריך לפענח אותו בהתאם למזהה הנתונים של טבלה 1.2.2:
  • ‫0x01(שם מותאם אישית): utf8s

טבלה 3.2: נתונים גולמיים. הפענוח בוצע מנתונים מוצפנים ב טבלה 3.1.

כשמתקבלת בקשה לשליחת התראה (למשל, בקשה לשם מותאם אישית באמצעות Bit 2 בטבלה 1.2.1), ספק Fast Pair צריך לבצע את הפעולות הבאות:

  1. יוצרים 8 בייטים אקראיים מבחינה קריפטוגרפית בשביל Nonce.

  2. הצפנת הנתונים באמצעות AES-CTR, כאשר כל בלוק של 16 בייט נוצר באמצעות

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

    איפה

    1. מפתח ה-AES הוא הסוד המשותף משלב 4 בתהליך.
    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 הוא משלב 4 בהליך.
    2. ‫opad הוא ריפוד חיצוני של 64 בייטים, שמורכב מבייטים חוזרים עם הערך 0x5C.
    3. ‫ipad הוא ריפוד פנימי של 64 בייטים, שמורכב מבייטים חוזרים עם הערך 0x36.

  5. לוקחים את 8 הבייטים הראשונים מ-HMAC-SHA256 כקידומת של חבילת Data ‎.

כשספק Fast Pair מקבל בקשת כתיבה, הוא מבצע את הפעולות הבאות:

  1. כדי לוודא את תקינות הנתונים, בודקים את 8 הבייטים הראשונים של HMAC-SHA256.

  2. פענוח הנתונים המוצפנים באמצעות AES-CTR, כאשר כל בלוק נוצר באמצעות

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

    איפה

    1. ‫encryptedBlock[i] הוא בלוק של 16 בייט שמתחיל מ-encrypted_data[i * 16]. הבלוק האחרון יכול להיות קטן מ-16 בייט.
    2. מפתח AES נוצר או מזוהה מתוך הלחיצת יד, לדוגמה:
      1. בתהליך מתן השם 1, הוא מגיע מ-ECDH ולא ישמש שוב להתאמה הזו. צריך לדחות כל בקשה שמתקבלת מוצפנת עם המפתח הזה בלי להפעיל מחדש את התהליך.
      2. בתהליך מתן השמות 2, זהו מפתח החשבון.

  3. מבצעים concat(clearBlock[0], clearBlock[1],...)‎ כדי ליצור את הנתונים הגולמיים.