מאפיינים

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

לספק ההתאמה המהירה יהיה שירות 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

מאפיין: מזהה דגם

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

8 תווים סוג הנתונים תיאור תמורה לכסף
2-0 uint24 מזהה דגם משתנה

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

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

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

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

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

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

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

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

פורמט נתונים

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

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

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

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

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

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

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

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

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

8 תווים סוג הנתונים תיאור תמורה לכסף
0 -15 uint128 תשובה מוצפנת משתנה

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

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

במאפיין הזה נעשה שימוש במהלך התאמה מבוססת-מפתחות.

8 תווים סוג הנתונים תיאור תמורה לכסף
0 - 15 uint128 בלוק של מפתח גישה מוצפן משתנה

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

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

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

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

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

8 תווים סוג הנתונים תיאור תמורה לכסף
0 - 15 uint128 מפתח חשבון (מוצפן) משתנה

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

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

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

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

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

8 תווים סוג הנתונים תיאור תמורה לכסף
0 - var utf8s קוד גרסה קודמת של קושחה משתנה

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

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

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

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

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

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

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

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

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

8 תווים תיאור תמורה לכסף
0 - 7 8 הבייטים הראשונים של HMAC-SHA256. משתנה
8 - 15 Nonce, בשימוש בהצפנת AES-CTR. משתנה
16 - var נתונים מוצפנים. משתנה

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

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

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

כשמתקבלת התראה (למשל, בקשת שם מותאם אישית דרך Bit 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 בייט שמתחיל מנתונים[i * 16]. הבלוק האחרון יכול להיות קטן מ-16 בייטים.

  3. יוצרים את הנתונים המוצפנים, באמצעות מחרוזות הבאות - הצפנת MPNBlock[0], encryptedBlock[1],...).

  4. יצירת HMAC-SHA256 על ידי

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

    איפה

    1. K נוצר על ידי concat(shared_secret, 48 bytes ZEROs), וה-shared_secret הוא שלב 4 בהליך.
    2. ב-opad יש מרווח פנימי חיצוני של 64 בייטים, שמכיל בייטים שחוזרים על עצמם בערך 0x5C.
    3. ב-iPad יש מרווח פנימי פנימי של 64 בייטים, שמכיל בייטים שחוזרים על עצמם בערך 0x36.

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

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

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

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

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

    איפה

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

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