מאפיינים
שירות התאמה מהירה
לספק ההתאמה המהירה יהיה שירות 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 |
סימונים
|
משתנה | חובה |
2 - 7 | uint48 |
אחת משתי האפשרויות:
|
משתנה | חובה |
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 |
אחת משתי האפשרויות:
|
משתנה | חובה |
8 | uint8 |
קבוצת הודעות | משתנה | חובה אם הסימונים של Bit 0 מוגדרים |
9 | uint8 |
קוד הודעה | משתנה | חובה אם הסימונים של Bit 0 מוגדרים |
10 | uint8 |
תלויה בסימונים:
|
משתנה | חובה אם הערך של 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 |
סוג הודעה | אחת מהאפשרויות:
|
3 - 1 | unit32 |
מפתח גישה בן 6 ספרות | משתנה |
4 - 15 | ערך אקראי (מלח) | משתנה |
טבלה 2.2: בלוק של מפתחות גישה גולמיים. גרסה מפוענחת של טבלה 2.1.
מאפיין: מפתח חשבון
לאחר ההתאמה, מבצע ההתאמה המהירה יכתוב מפתח חשבון לספק ההתאמה המהירה.
8 תווים | סוג הנתונים | תיאור | תמורה לכסף |
---|---|---|---|
0 - 15 | uint128 |
מפתח חשבון (מוצפן) | משתנה |
עם קבלת בקשת כתיבה, ספק ההתאמה המהירה יבצע את הפעולות הבאות:
- מפענחים את מפתח החשבון באמצעות הסוד המשותף שנוצר בשלב 4 בתהליך.
- לספקים שזקוקים לחיבורים (שיטה נפוצה):
- לפני הפענוח, חשוב לוודא שהסוד המשותף שימש לפענוח הבקשה למפתח הגישה משלב 12. אם השלב הזה לא עבר באמצעות הסוד הזה, מתעלמים מהכתיבה ויוצאים.
- בשלב הזה לא נשתמש שוב בסוד המשותף (K בהליך) בהתאמה. יש לדחות כל בקשה שמוצפנת באמצעות המפתח הזה בלי להפעיל מחדש את התהליך.
- לספקים שזקוקים לחיבורים (שיטה נפוצה):
- צריך לוודא שהערך המפוענח מתחיל ב-
0x04
. אם לא, אפשר להתעלם מהכתיבה ולצאת. - בדקו אם ברשימת המפתחות של החשבון יש מקום לערך החדש.
- אם לא, מוחקים מהרשימה את הערך הכי פחות בשימוש.
- מוסיפים את הערך החדש לרשימה.
מפתחות חשבונות שברשימה משמשים במהלך התאמה מבוססת-מפתחות.
מאפיין: גרסת קושחה
המאפיין הזה מאפשר למחפש לקרוא את גרסת הקושחה של הספק לפי הצורך. הוא תמיד צריך להחזיר את הנתונים הבאים:
8 תווים | סוג הנתונים | תיאור | תמורה לכסף |
---|---|---|---|
0 - var | utf8s |
קוד גרסה קודמת של קושחה | משתנה |
צריך לכלול אותו במחרוזת utf8 אחת, גם אם יש יותר מקושחה אחת (למשל, 3 קושחה לאוזניה השמאלית, לאוזנייה הימנית ולנרתיק). הספק יכול גם להחזיר את המחרוזות הספציפיות עבור מקרים מיוחדים:
status-update: אם הספק מעדכן כרגע לקושחה חדשה. לחלופין, הספק יכול להחזיר את גרסת הקושחה המדורגת.
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:
|
טבלה 3.2: נתונים גולמיים. מפוענח מהנתונים המוצפנים ב טבלה 3.1.
כשמתקבלת התראה (למשל, בקשת שם מותאם אישית דרך Bit 2 בטבלה 1.2.1), ספק ההתאמה המהירה צריך לבצע את הפעולות הבאות:
- יצירת 8 בייטים קריפטוגרפיים אקראיים עבור Nonce.
להצפין את הנתונים באמצעות AES-CTR, שבו כל בלוק של 16 בייטים נוצר באמצעות
encryptedBlock[i] = clearBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))
איפה
- מפתח AES הוא הסוד המשותף משלב 4 בתהליך.
- ClearBlock[i] הוא בלוק בגודל 16 בייט שמתחיל מנתונים[i * 16]. הבלוק האחרון יכול להיות קטן מ-16 בייטים.
יוצרים את הנתונים המוצפנים, באמצעות מחרוזות הבאות - הצפנת MPNBlock[0], encryptedBlock[1],...).
יצירת HMAC-SHA256 על ידי
sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, encrypted_data)))))
איפה
- K נוצר על ידי concat(shared_secret, 48 bytes ZEROs), וה-shared_secret הוא שלב 4 בהליך.
- ב-opad יש מרווח פנימי חיצוני של 64 בייטים, שמכיל בייטים שחוזרים על עצמם בערך
0x5C
. - ב-iPad יש מרווח פנימי פנימי של 64 בייטים, שמכיל בייטים שחוזרים על עצמם בערך
0x36
.
משתמשים ב-8 הבייטים הראשונים מה-HMAC-SHA256 כקידומת של חבילת הנתונים.
עם קבלת בקשת כתיבה, ספק ההתאמה המהירה יבצע את הפעולות הבאות:
- מאמתים את תקינות הנתונים על ידי בדיקת 8 הבייטים הראשונים של HMAC-SHA256.
פענוח הנתונים המוצפנים באמצעות AES-CTR, שבו כל בלוק נוצר באמצעות
clearBlock[i] = encryptedBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))
איפה
- מוצפנת בלוק[i] הוא בלוק של 16 בייטים שמתחיל ב-encrypted_data[i * 16]. הבלוק האחרון יכול להיות קטן מ-16 בייטים.
- מפתח AES נוצר או מזוהה מלחיצת היד, למשל
- במתן שם לתהליך 1, הוא מ-ECDH ולא ייעשה בו שימוש שוב בהתאמה הזו. יש לדחות את כל הבקשות שמגיעות עם הצפנה באמצעות המפתח הזה בלי להפעיל מחדש את התהליך.
- בשלב 2 למתן שם, זהו המפתח לחשבון.
מבצעים שרשור(clearBlock[0], clearBlock[1],...) כדי ליצור את הנתונים הגולמיים.