מאפיינים

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

לספק ההתאמה המהירה צריך להיות שירות 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: המפתח ששותף מראש הוא אחד ממפתחות החשבון.

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

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

פורמט נתונים

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

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

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

אוקטט סוג הנתונים תיאור ערך חובה?
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 מוגדרות
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.

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

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

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

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

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

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

אוקטט סוג הנתונים תיאור ערך
‫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 מפתח החשבון (מוצפן) משתנה

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

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

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

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

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

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

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

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

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

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

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

אם הספק תומך ב-Find Hub, נדרשת הטמעה נוספת. פרטים נוספים זמינים במאמר בנושא עדכוני קושחה של Find Hub.

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

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

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

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

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

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

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

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

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

  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 ‎.

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

  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. בתהליך מתן השמות השני, זהו מפתח החשבון.

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