מאפיינים

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

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

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

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

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

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

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

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

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

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

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

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

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

פורמט נתונים

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

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

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

אוקטט	סוג הנתונים	תיאור	ערך	חובה?
0	uint8	סוג הודעה	0x00 = בקשת התאמה מבוססת-מפתח	חובה
1	uint8	דגלים Bit 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		ערך אקראי (מלח)	משתנה	חובה

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

אוקטט	סוג הנתונים	תיאור	ערך	חובה?
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 Bit 1 מוגדר: מזהה נתונים	משתנה	חובה אם הגדרת הסימונים 0 או 1
11 - n		נתונים נוספים	משתנה	אופציונלי
n - 15		ערך אקראי (מלח)	משתנה	חובה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מאפיין שירות ההתאמה המהירה	מוצפנת	הרשאות	מזהה ייחודי אוניברסלי (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	Nonce, משמש להצפנת AES-CTR.	משתנה
16 – var	נתונים מוצפנים.	משתנה

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

אוקטט	סוג הנתונים	תיאור	ערך
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. cleanBlock[i] הוא בלוק של 16 בייט שמתחיל מ-data[i * 16]. האחרון הגודל המקסימלי של בלוקים הוא 16 בייטים.

3. ביצוע concat(EncryptionBlock[0], encryptionBlock[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 כקידומת של הנתונים מנה.

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

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. יש לבצע concat(clearBlock[0], clearBlock[1],...) כדי ליצור את הנתונים הגולמיים.