מכשיר Bluetooth עם צריכת אנרגיה נמוכה (BLE)
הטמעת שירות ההתאמה המהירה (GFPS) של Google למכשירי BLE היא תואם ל-Bluetooth Core Specification גרסה 4.2 ואילך.
הנספח הבא למפרט ההתאמה המהירה יאפשר תמיכה למכשירים עם צריכת אנרגיה נמוכה (LE) בלבד ולמכשירים עם צריכת אנרגיה נמוכה (LEA) ב-GFP.
רמות תאימות
מילות המפתח 'יהיה', 'חובה', 'יהיה', 'יכול', 'יכול' ו'יכול' שמצוינות במפרט כמפורט למטה:
מונח | תיאור |
---|---|
חייבת | נדרש כדי – משמש להגדרת דרישות. |
חייב | משמש לביטוי: תוצאה טבעית של דרישת חובה שצוינה קודם לכן או הצהרת עובדות שלא ניתן לערער עליה (כזו שתמיד נכונה, ללא קשר לנסיבות). |
רצון | זה נכון - משמש רק לצורך הצהרת עובדות. |
צריך | מומלץ – מציינים שיש כמה אפשרויות שמומלץ להשתמש בהן כמתאימים במיוחד, אבל לא חובה. |
מאי | מותר – משמש להצגת אפשרויות. |
יכולה | הוא יכול – משמש לקשר הצהרה באופן סיבתי. |
מאפיין התאמה מבוססת-מפתחות
הודעה מהמחפש לספק
הבקשה הגולמית type 0x00
של מאפיין התאמה מבוססת-מפתחות משתמשת ב-Bit 4
כדי לציין אם ה-seeker תומך ב-BLE Device Specification, ומשתמש ב
ביט 5 כדי לציין אם ה-Finder תומך ב-LE Audio.
אוקטט | סוג הנתונים | תיאור | ערך | חובה? |
---|---|---|---|---|
0 | uint8 |
סוג הודעה | 0x00 = בקשת התאמה מבוססת-מפתח |
חובה |
1 | uint8 |
דגלים
|
משתנה | חובה |
2 - 7 | uint48 |
אחת משתי האפשרויות:
|
משתנה | חובה |
8 - 13 | uint48 |
כתובת BR/EDR של המבקש | משתנה | הצגה רק אם הוגדר ביט 1 או 3 דגלים |
n - 15 | ערך אקראי (מלח) | משתנה | חובה |
הודעה מהספק למחפש
כשמוגדר ביט 4 של הבקשה, הודעת התשובה החדשה type 0x02
עבור
אפשר להשתמש במאפיין הצמדה מבוסס-מפתחות כדי ליצור קשר נוסף
למחפש.
אוקטט | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 |
סוג הודעה | 0x02 = תגובה מורחבת של התאמה מבוססת-מפתחות |
1 | uint8 |
דגלים
|
משתנה |
2 | uint8 |
מספר כתובות הספק (בגרסה הנוכחית, המספר הוא 1 או 2, כי עלינו לשנות את מצב הצפנה של בלוקים ל-AES-CTR אם המספר הוא >= 3) |
משתנה |
3 - 8 או 3 - 14 |
|
משתנה | |
9 - 15 או 15 | ערך אקראי (מלח) | משתנה |
ספק שתומך במפרט מכשיר BLE יקרא Bit 4 ו-Bit 5 להבין את היכולות של המחפש
- כאשר Bit 4 הוא 0, הספק יתעלם מ-Bit 5 ויגיב עם הפורמט
type 0x01
- כש-Bit 4 הוא 1,
- לספק LE בלבד, התשובה שלו צריכה להיות
type 0x02
כדי לציין LE העדפה ליצירת קשרים. - לספק של מצב כפול, הוא יכול לתת תשובה עם
type 0x02
כדי לציין העדפה לחיבור בין BR/EDR או LE.
- לספק LE בלבד, התשובה שלו צריכה להיות
- לטיפול במקרים של ספק מצב כפול של LE Audio (LEA): דוגמה: התאמה עם ספק מצב כפול של LEA לצורך השוואה
מאפיין PSM של שידור הודעות (Protocol Service Multiplexor)
כדי לתמוך בשידור הודעות במכשירי BLE, התכונה 'התאמה מהירה' תיצור לתחזק ערוץ BLE L2CAP לשליחה ולקבלה של הודעות. התאמה מהירה שרת L2CAP ישתמש בבקרת זרימה מבוססת-אשראי מסוג LE.
מאפיין זה מאפשר למחפש לקרוא את ערך ה-PSM ולאחר מכן ליצור חיבור L2CAP מאובטח באמצעות ערך ה-PSM.
מאפיין שירות ההתאמה המהירה | מוצפנת | הרשאות | מזהה ייחודי אוניברסלי (UUID) |
---|---|---|---|
PSM של שידור הודעות | כן | קריאה | FE2C1239-8366-4814-8EB0-01DE32100BEA |
אוקטט | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 |
מדינה
|
משתנה |
2-1 | uint16 |
ערך PSM יהיה בטווח שבין 0x80 ל-0xFF | משתנה |
הערה: ב-TWS, יש
מהרכיבים הבאים: ראשי ומשני. התפקיד של הרכיבים האלה
שניתנים להחלפה בתנאים מסוימים. בהנחה ש-A הוא רכיב ראשי ו-B הוא
רכיב משני, עקב התרוקנות הסוללה של רכיב A , יש צורך ברכיב B
יכול לקחת את תפקיד הרכיב הראשי, והתרחיש הזה נקרא role switch
.
אחרי role switch
, אם הספק
לא ניתן לטפל בשידור ההודעות בהתאמה המהירה, היא תנתק באופן יזום את
חיבור L2CAP קיים. מי שרוצה את ההתאמה המהירה יכול ליצור מחדש את L2CAP
חיבור לשידור הודעות עם הרכיב הראשי החדש.
מאפיין נוסף של מפתח גישה
מאפיין זה נועד לספק הגנה מפני MITM רכיבים.
הגנת CSIS Fake Member MITM
כדי להשתמש בהתאמה מהירה נדרשת הגנת MITM במסגרת תהליך ההתאמה. כ-CSIS לא מספק הגנת MITM, התכנון הנוכחי של FP למספר צריך להרחיב את הרכיבים כדי לספק הגנה מפני MITM רכיבים.
הגדרת מאפיין
מאפיין השירות להתאמה מהירה | מוצפנת | הרשאה | מזהה ייחודי אוניברסלי (UUID) |
---|---|---|---|
מפתח גישה נוסף | כן | קריאה,כתיבה,עדכון | FE2C123A-8366-4814-8EB0-01DE32100BEA |
הודעות
פורמט ההודעה חל על פעולות קריאה, כתיבה ושליחת הודעות.
פורמט נתונים מוצפן
הנתונים המוצפנים נשלחים באמצעות חיבור GATT בהתאמה מהירה.
אוקטט | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0-15 | uint128 | חסימה של מפתח גישה נוסף מוצפן | משתנה |
פורמט של נתונים גולמיים
לאחר פענוח הנתונים המוצפנים באמצעות סוד משותף, הפורמט הוא כך:
אוקטט | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | סוג הודעה | אחד מ-
|
1-3 | uint24 | מפתח גישה בן 6 ספרות | משתנה |
4-9 | uint48 | הכתובת של רכיב הקישור ליעד | משתנה |
10 | uint8 | קוד סטטוס, משמש רק בפעולת קריאה | אחד מ-
|
11-15 | ערך אקראי (מלח) | משתנה |
הרכיב העיקרי (הרכיב הראשון הקשור) הוא הגשר בין ההתאמה המהירה המחפש ורכיבי החיבור הנוספים. המאפיין יש לפעול בהתאם להנחיות:
- כשמקבלים בקשת כתיבה מ'המחפש התאמה מהירה', הספק
- צריך להגדיר את הכתובת של הרכיב שאליו רוצים לקשר
- שליחת מפתח הגישה לרכיב שקשור לקישור
- יש להגדיר את קוד הסטטוס למצב 'בהמתנה', 0x01
- כשמקבלים בקשת קריאה לפני שמקבלים מפתח גישה מהרכיב
את הקשר, הספק יחזיר הודעה עם
- מפתח גישה, כל ערך
- הכתובת של הרכיב שאליו רוצים לקשר
- קוד סטטוס בהמתנה, 0x01
- לפני שהספק שולח התראה למחפש ההתאמה המהירה, מגדיר את התוצאה.
לבקשת הקריאה עם
- מפתח הגישה מהרכיב שרוצים לקשר
- הכתובת של הרכיב שאליו רוצים לקשר
- קוד סטטוס הצלחה, 0x00
- אם קיימת שגיאה שלא ניתן לשחזר בצד הספק, מגדירים את התוצאה
- מפתח גישה, כל ערך
- הכתובת של הרכיב שאליו רוצים לקשר
- קוד סטטוס של כישלון, 0x02
ראו תרשים MITM ו תרשים MITM 2 לפרטים נוספים.
דרישות של מכשיר LE
פרסום LE
עבור מצב ניתן לגילוי או מצב בלתי ניתן לגילוי, הספק ישתמש ב-RPA כדי לפרסם נתוני התאמה מהירה.
יכולת חיבור
במכשירים שתומכים ב-LE, המחפש צריך ליצור קשר עם חיבור LE. אחרי שעוברים את האימות שמבוסס על מפתחות להתאמה מהירה, הספק יאפשר התקשרות עם RPA ויגדיר את יכולת הקלט (IO) כ-DisplayYesNo לצורך אימות מפתח גישה להתאמה מהירה.
דרישות למכשיר LEA
פרסום LEA
במכשירים עם שני פיצ'רים: במצב גלוי, הספק יפרסם נתוני התאמה מהירה עם Identity address. במקרה שלא ניתן לגלות את המצב, הספק יפרסם את נתוני ההתאמה המהירה באמצעות RPA. מומלץ מאוד להשתמש במודעות מדור קודם (BT 4.2) כדי לתמוך בתוכניות ישנות יותר לצורך תאימות לאחור. חובה לשנות את ה-IRK בכל פעם שהמכשיר מתאפס להגדרות המקוריות.
במכשירים ללא מצב כפול: עבור מצב גלוי או מצב שלא ניתן לגילוי, הספק ישתמש במצב מורחב פרסום (BT 5.0) עם RPA כדי לפרסם נתונים של התאמה מהירה.
המודעה המחוברת ל-LE שמכילה נתונים של שירות FP תכלול CAS UUID בהתאם Bluetooth Adapter Profile (BAP 1.0.1) פרופיל אודיו נפוץ לדרישה. לפרסומת שאינה ניתנת לגילוי אם אין מספיק מקום פנוי בפרסומת מדור קודם בגלל ההכללה של נתוני סוללה ו-SASS, במקרה כזה, חובה לכלול CAS UUID בתגובה לסריקה.
יכולת קישור LEA
המחפש צריך ליצור קשר עם חיבור ה-LE הקיים. אחרי המעבר אימות התאמה מהירה באמצעות מפתחות, ספק המצב הכפול יאפשר יצירת קשר עם כתובת זהות ו-RPA חיבור ל-RPA, והגדרת יכולת ה-IO, DisplayYesNo להתאמה מהירה אימות מפתח הגישה.
ערוץ תקשורת פנימי בין רכיבים
חיבור ה-GATT הקיים נשמר כדי לבצע הגנת MITM רכיבים נוספים. הרכיב הראשי המקושר יטפל בהודעה בין Fast Pairseeker לבין שאר הרכיבים שלו.
התקשורת הפנימית משמשת עבור Initial Pair
ו-Subsequent Pair
- כשתהליך התאמה מבוססת-מפתחות עובר אל הרכיב הראשי, הרכיב ישלח הודעה כדי לשנות את יכולת ה-IO של שנותר רכיבים
- לאחר השלמת ההתאמה המהירה, הרכיב הראשי ישלח הודעה לאיפוס יכולת IO של שאר הרכיבים שלו
- כשמפעילים תהליך של מפתח גישה נוסף, הרכיב הראשי צריך לטפל מסירת מפתחות גישה בין התכונה 'חיפוש באמצעות התאמה מהירה' לבין שאר הרכיבים שלה
הגיע הזמן לשנות את יכולת הקלט (IO)
- שינוי היכולת של הקלט/פלט (IO) ל-DisplayYesNo לאחר השלמת תהליך ההתאמה מבוססת-המפתח
- אם המכשיר כולל מספר רכיבים, יש להגדיר את כל הרכיבים DisplayYesNo
- חריג אחד שלפיו הספק צריך
אין לשנות את יכולת ה-IO ל-DisplayYesNo היא
Retroactive Pair
, ש-Bit 3 שלו של 'בקשת התאמה מבוססת-מפתחות' מוגדרת ל-1. ראו הודעה מהמחפש לספק
- שינוי יכולת הקלט/פלט (IO) להגדרת ברירת המחדל
- התאמה ראשונית
- אם חיבור ה-LE מנותק, צריך לסיים את ההתאמה המהירה
- אם לא נדרשת כתיבה נוספת של מפתח גישה, אחרי החיבור של המפתח הראשי בקשה בעוד 15 שניות, סיום הסשן של ההתאמה המהירה
- אחרי שמתקבלת בקשת כתיבה נוספת של מפתח גישה, אם הרכיב לא נוצר קשר בתוך 15 שניות. כלומר, מסיים את סשן ההתאמה המהירה
- לאחר קישור כל הרכיבים, אם לא נדרשת כתיבה של מפתח לחשבון בקשה תוך 15 שניות, סיום סשן ההתאמה המהירה
- לאחר שהתקבלה בקשה לכתיבה של מפתח חשבון, מגדירים זמן קצוב לתפוגה של 15 שניות לערך סיום ההתאמה המהירה
- ההתאמה הבאה
- אם חיבור ה-LE מנותק, צריך לסיים את ההתאמה המהירה
- אם לא נדרשת כתיבה נוספת של מפתח גישה, אחרי החיבור של המפתח הראשי בקשה תוך 15 שניות, סיום סשן ההתאמה המהירה
- אחרי שמתקבלת בקשת כתיבה נוספת של מפתח גישה, אם הרכיב לא נוצר קשר בתוך 15 שניות. כלומר, מסיים את סשן ההתאמה המהירה
- לאחר קישור כל הרכיבים, סיום ההתאמה המהירה
- התאמה ראשונית
הסתרת אינדיקציה לממשק המשתמש
כשהאוזניות לא מוכנות להתאמה, הספק ישתמש ב-type 0b0010
כדי להגדיר אינדיקטור של הסתרה של ממשק המשתמש לנתונים של מפתח החשבון, כדי להנחות את המחפש לא להציג
ממשק משתמש של התאמה מאוחרת יותר (למידע נוסף, ניתן לעיין בקטע מטען ייעודי (payload) של פרסום: נתוני חשבון בהתאמה מהירה).
דרישות למכשיר LE Audio
דרישות Bluetooth
כדאי לעיין במאמר המלצות ל-Android, לאוזניות LE Audio.
תמיכה ב-CTKD
במכשירים עם מצב כפול, חובה להשתמש ב-CTKD מ-LE ל-BR/EDR, או בתאימות ל דרישות של BAP.
הכרזה על היעד
ציוד היקפי ישתמש בהודעה ממוקדת כדי לבקש חיבור ממכשיר מרכזי מותאם. הודעות מטורגטות מוגדרות ב-BAP וב-CAP לניהול החיבורים בהתאם ל-CAP 1.0 בטבלה 8.4 (p48/58).
תמיכה בשרת GATT EATT
פרוטוקול EATT מאפשר למכשיר המרכזי לשלוח עסקאות GATT מרובות במקביל כשהמכשיר מחובר. במכשיר שתומך ב-CSIP, העלייה תגדל את הביצועים של חיבור הפרופיל, ובקרוב מתחילים ליצור קשר עם CSIP עבור האוזניות האחרות.
שמירה במטמון חזק של GATT (מומלץ מאוד)
אם הספק הוא לא מכשיר יחיד אלא הגדרה מתואמת עם הטמעת CSIP, כדי לצמצם את מספר לגילוי השירות והאצת החיבור, הספק צריך להטמיע שמירה במטמון GATT שהוגדר ב-Bluetooth 5.1.
הדרישות להתאמה מהירה
פרסום LE
עבור מצב גלוי או מצב בלתי גלוי, אם למכשיר יש מספר רכיבים, נתוני התאמה מהירה יתפרסמו על ידי הרכיב הראשי. אם המכשיר לא מוכן להתאמה הבאה, הרכיב המשני לפרסם נתונים של התאמה מהירה בשביל תכונות מורחבות. לראות הסתרת האינדיקציה לממשק המשתמש.
הרשאות הגישה לשירות GATT
מסד הנתונים של GATT צריך להיות זהה לכל חיבורי ה-GATT מסוג LE Transport. LE Audio (0x184E) ייכלל במסד הנתונים של GATT של חיבור בהתאמה מהירה.
דוגמה: התאמה לספק במצב LEA כפול
תרחיש 1 – כאשר המחפש לא תומך ב-LEA
לספק תהיה תאימות לאחור למחפש שלא תמיכה ב-LEA.
רכיבים
- ספק: A2DP/HFP/LEA
- מחפש: A2DP/HFP
ההתנהגות הצפויה של זוג ראשוני / הזוג העוקב
- הספק מפרסם את שירות ההתאמה המהירה
נתונים (0xFE2C) עם כתובת זהות (ראשית) או RPA (בהמשך).
- שימוש בפרסום מדור קודם
- המחפש מקבל פרסומת עם כתובת זהות שתשמש כראשי או כמודעה RPA להתאמה לאחר מכן
- המחפש שולח בקשה להתאמה מבוססת-מפתח
- ביט-5 הדגל של בקשת התאמה מבוססת-מפתחות מוגדר ל-0
- הספק שולח תגובת התאמה מבוססת-מפתח עם כתובת ציבורית באחת
הבאים:
- אם נעשה שימוש בסוג הודעה 0x01, הכתובת תהיה כתובת ציבורית.
- אם סוג ההודעה הוא 0x02
- Bit-0 יהיה 0
- Bit-1 יהיה 0
- הכתובת תהיה כתובת ציבורית
- מי שרוצה יוצר קשר עם תדרי BR/EDR
- היכולת IO מוגדרת כ-DisplayYesNo ל-BR/EDR
- תהליך האימות של מפתח גישה להתאמה מהירה בין המחפש והספק
תרחיש 2 – כאשר המחפש תומך ב-LEA
רכיבים
- ספק
- תמיכה ב-A2DP/HFP/LEA
- רכיב יחיד
- מחפש
- SupportA2DP/HFP/LEA
ההתנהגות הצפויה של זוג ראשוני / הזוג העוקב
- הספק מפרסם את שירות ההתאמה המהירה
נתונים (0xFE2C) עם כתובת זהות (ראשית) או RPA (בהמשך).
- שימוש בפרסום מדור קודם
- המחפש שולח בקשה להתאמה מבוססת-מפתח
- ביט-5 הדגל של בקשת התאמה מבוססת-מפתחות מוגדר ל-1
- הספק שולח תגובת התאמה מבוססת-מפתחות עם סוג ההודעה 0x02
- Bit-0 יהיה 0
- Bit-1 יהיה 1
- הכתובת היא כתובת זהות
- המחפש יוצר קשר עם
חיבור LE בתעבורה LE
- הכיוון של CTKD הוא מ-LE ל-BR/EDR
- יכולת ה-IO מוגדרת כ-DisplayYesNo עבור LE
- תהליך האימות של מפתח גישה להתאמה מהירה בין המחפש והספק
תרחיש 3 – כאשר המחפש תומך ב-LEA וב-CSIP מעורבים
רכיבים
- ספק
- תמיכה ב-A2DP/HFP/LEA
- רכיבים מרובים
- הרכיב הראשי הוא BR/EDR/LE
- הרכיב המשני הוא LE בלבד
- מחפש
- תמיכה ב-A2DP/HFP/LEA
ההתנהגות הצפויה של זוג ראשוני / הזוג העוקב
- הרכיב הראשי מפרסם את ההתאמה המהירה
נתוני שירות (0xFE2C) עם כתובת זהות (ראשית) או RPA (המשך).
- שימוש בפרסום מדור קודם
- המחפש שולח בקשת התאמה מבוססת-מפתחות לרכיב הראשי
- ביט-5 הדגל של בקשת התאמה מבוססת-מפתחות מוגדר ל-1
- הרכיב הראשי שולח תגובת התאמה מבוססת-מפתחות עם סוג ההודעה 0x02
- Bit-0 יהיה 0
- Bit-1 יהיה 1
- הכתובות הן :
- הכתובת הראשונה היא כתובת הזהות של הרכיב הראשי
- הכתובת השנייה היא הכתובת שאפשר לקשר לרכיב המשני, הרכיב השני משתמש גם בכתובת הזאת כדי לבצע פרסום של CSIP
- המחפש יוצר קשר עם
רכיב בחיבור ה-LE הקיים
- הכיוון של CTKD הוא מ-LE ל-BR/EDR
- יכולת ה-IO מוגדרת כ-DisplayYesNo עבור LE
- המחפש יוצר קשר עם
רכיב שהכתובת שלו היא מהתאמה מורחבת של מפתחות
- היכולת IO תהיה מסוג DisplayYesNo. אחרת, יש לדחות את בקשת ההתאמה
- המחפש והספק מבצעים תהליך הגנת MITM לצורך התאמה של הרכיב המשני, הספק יטמיע את שני התרחישים
- המחפש ימתין עד להתחברות לרכיב המשני
תרשים רציף ל-MITM
הסשן הזה מתאר את הרצף של התהליך להגנה מפני MITM.
קבלת מפתח גישה מהרכיב שמקושר בהתראה
קבלת מפתח גישה מהרכיב שמקושר באמצעות קריאה
בעיה ידועה
שיטת FP for LEA עברה אופטימיזציה לעבודה עם Android V(Android 15).
לעומת זאת, נתקלנו במספר בעיות באוזניות שתומכות ב-LEA אבל אין התאמה מהירה עם הטמעת LEA בצורה נכונה (כלומר, רק התאמה מהירה מעל קלאסי). באופן ספציפי, ולדוגמה, במקרים שבהם לא נוצרת RPA של הספק באמצעות המפתח הנכון לפתרון זהויות (IRK), ולא ניתן לפענח את הכתובת. לא הצלחנו לבדוק רשימה מקיפה של אוזניות האישיות שלנו, הבדיקות המוגבלות שלנו חשפו בעיות שונות, כולל כשלים כדי להציג התראות על הסוללה של אוזניית הכפתור, היעדר מעבר לאודיו (SASS) פונקציונליות, כשלים ראשוניים רחבים בהתאמה הראשונית ועוד.
לכן, אנחנו ממליצים מאוד לשותפים להטמיע את אפשרות ההתאמה המהירה (LEA) מפרט למכשירים חדשים ולמכשירים קיימים בשדה (באמצעות עדכונים אלחוטיים) שתומכים בשני מצבים.