מכשיר Bluetooth Low Energy ‏ (BLE)

ההטמעה של שירות ההתאמה המהירה של Google‏ (GFPS) למכשירי BLE תואמת למפרט הליבה של Bluetooth בגרסה 4.2 ומעלה.

התוספת הבאה למפרט של התכונה 'התאמה מהירה' תאפשר תמיכה במכשירי Low Energy (LE) בלבד ובמכשירי Low Energy Audio ‏ (LEA) ב-GFPS.

רמות התאימות

מילות המפתח shall,‏ must,‏ will,‏ should,‏ may ו-can שמוזכרות במפרט מוסברות בהמשך:

מונח תיאור
צריך ‫is required to (נדרש כדי) – משמש להגדרת דרישות.
חובה משמש לציון:
תוצאה טבעית של דרישה מחייבת שצוינה קודם
או
הצהרה עובדתית שאין עליה עוררין (הצהרה שתמיד נכונה, ללא קשר לנסיבות).
צוואה it is true that – משמש רק בהצהרות עובדתיות.
should מומלץ – משמש לציון שאחת מתוך כמה אפשרויות מומלצת כמתאימה במיוחד, אבל לא נדרשת.
מאי ‫is permitted to – משמש לאישור אפשרויות.
כן יכול/ה – משמש לציון קשר סיבתי בין שני חלקי משפט.

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

הודעה ממי שמחפש עבודה למי שמציע עבודה

בבקשה הגולמית type 0x00 של מאפיין ההתאמה שמבוסס על מפתח נעשה שימוש בביט 4 כדי לציין אם המכשיר התומך תומך במפרט מכשיר BLE, ובביט 5 כדי לציין אם המכשיר התומך תומך בLE Audio.

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

הודעה מהספק למי שמחפש שירות

כשביט 4 של הבקשה מוגדר, אפשר להשתמש בהודעת התגובה החדשה type 0x02 למאפיין של התאמה מבוססת-מפתח כדי לספק אפשרויות נוספות של שיוך למכשיר המחפש.

Octet סוג הנתונים תיאור ערך
0 uint8 סוג ההודעה ‫0x02 = תשובה מורחבת להתאמה מבוססת-מפתח
1 uint8 סימונים
  • ביט 0 (MSB): ‏1 אם הספק הוא מכשיר LE בלבד, 0 אחרת. אם הביט 0 מוגדר כ-1, רכיב החיפוש יניח שהביט 1 מוגדר כ-1.
  • ביט 1: 1 אם הספק מעדיף קישור LE, אחרת 0.
  • ביט 2: 1 אם סוג הכתובת של הכתובת השנייה הוא אקראי, 0 אם הוא ציבורי.
  • ביטים 3 עד 7 שמורים לשימוש עתידי, וצריך להתעלם מהם.
 משתנה
2 uint8 מספר הכתובות של הספק
(בגרסה הנוכחית, המספר הוא 1 או 2, כי אנחנו צריכים לשנות את מצב ההצפנה בבלוק ל-AES-CTR אם המספר הוא 3 ומעלה)		 משתנה
‫3 עד 8 או
3 עד 14
  • הכתובת הראשונה צריכה להיות כתובת הזהות של המכשיר הראשי, וצריכה להיות אפשרות ליצור איתה שיוך אם מעדיפים שיוך מסוג BR/EDR
  • הכתובת השנייה תהיה כתובת שניתן לקשר אליה את המשני, אם המשני זמין
 משתנה
‫9 עד 15 או 15 ערך אקראי (salt) משתנה

ספק שתומך במפרט של מכשיר BLE צריך לקרוא את ביט 4 ואת ביט 5 כדי להבין את היכולות של המכשיר המחפש

  • אם הביט הרביעי הוא 0, הספק צריך להתעלם מהביט החמישי ולהשיב בפורמט type 0x01
  • כשהערך של ביט 4 הוא 1,
    • אם הספק תומך רק ב-LE, הוא צריך להגיב עם type 0x02 כדי לציין העדפה לחיבור LE.
    • במקרה של ספק במצב כפול, הוא יכול להגיב עם type 0x02 כדי לציין העדפה ל-BR/EDR או ל-LE bonding.
  • במקרים של ספק במצב כפול של LE Audio ‏ (LEA), אפשר לעיין בדוגמה: צימוד לספק במצב כפול של LEA

מאפיין של Message Stream PSM (Protocol Service Multiplexor)

כדי לתמוך בהזרמת הודעות למכשירי BLE, התכונה 'התאמה מהירה' תיצור ותתחזק ערוץ BLE L2CAP לשליחה ולקבלה של הודעות. התאמה מהירה שרת L2CAP צריך להטמיע בקרה על זרימת נתונים מבוססת-קרדיט LE.

המאפיין הזה מאפשר למכשיר המחפש לקרוא את ערך ה-PSM, ואז ליצור חיבור L2CAP מאובטח לפי ערך ה-PSM.

מאפיין שירות ההתאמה המהירה מוצפן הרשאות מזהה ייחודי אוניברסלי (UUID)
Message Stream PSM כן קריאה FE2C1239-8366-4814-8EB0-01DE32100BEA
Octet סוג הנתונים תיאור ערך
0 uint8 מדינה (State)
  • ‫0x00 = לא ידוע. הכלי FP Seeker ינסה שוב כמה פעמים
  • ‫0x01 = מוכן להתחבר
  • ‫0x02 = לא זמין. הפעם, רכיב ה-FP Seeker לא ישמש לחיבור
 משתנה
1 - 2 uint16 הערך של PSM צריך להיות בטווח שבין 0x80 ל-0xFF משתנה

הערה: ל-TWS יש שני רכיבים: ראשי ומשני. התפקיד של הרכיבים האלה ניתן להחלפה בתנאים מסוימים. נניח ש-A הוא הרכיב הראשי ו-B הוא הרכיב המשני. בגלל ניקוז הסוללה ברכיב A, רכיב B צריך לקחת את התפקיד של הרכיב הראשי , והתרחיש הזה נקרא role switch.

אחרי role switch, אם הספק לא יכול לטפל בזרם ההודעות של ההתאמה המהירה, הוא צריך לנתק באופן יזום את חיבור L2CAP הקיים. אחרי כן, רכיב החיפוש של 'התאמה מהירה' יכול ליצור מחדש את החיבור של זרם ההודעות L2CAP עם הרכיב הראשי החדש.

מאפיין נוסף של מפתח גישה

המאפיין הזה נועד לספק הגנה מפני התקפות MITM ברכיבים הנוספים.

CSIS Fake Member MITM Protection

התכונה 'התאמה מהירה' דורשת הגנה מפני התקפות MITM כחלק מתהליך ההתאמה. מכיוון ש-CSIS לא מספק הגנה מפני מתקפות MITM, צריך להרחיב את העיצוב הנוכחי של FP למספר רכיבים כדי לספק הגנה מפני מתקפות MITM ברכיבים הנוספים.

הגדרת מאפיין

מאפיין שירות ההתאמה המהירה מוצפן הרשאה מזהה ייחודי אוניברסלי (UUID)
מפתח גישה נוסף כן קריאה,כתיבה,שליחת הודעות FE2C123A-8366-4814-8EB0-01DE32100BEA

הודעות

פורמט ההודעה חל על פעולות קריאה, כתיבה והתראה.

פורמט נתונים מוצפן

הנתונים המוצפנים נשלחים באמצעות חיבור GATT של התכונה 'התאמה מהירה'.

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

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

Octet סוג הנתונים תיאור ערך
0 uint8 סוג ההודעה אחת מהאפשרויות:
  • ‫0x00 = מפתח הגישה של המבקש
  • ‫0x01 = מפתח הגישה של הספק
1-3 uint24 מפתח גישה בן 6 ספרות משתנה
4-9 uint48 כתובת רכיב היעד של ה-bonding משתנה
10 uint8 קוד סטטוס, נעשה בו שימוש רק בפעולת קריאה אחת מהאפשרויות הבאות:
  • ‫0x00 = הצלחה
  • ‫0x01 = בהמתנה. ניסיון חוזר של חיפוש טביעת אצבע עד שתפוג ההמתנה
  • ‫0x02 = כישלון. FP Seeker stop retry
11-15 ערך אקראי (salt) משתנה

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

  • כשספק מקבל בקשת כתיבה ממכשיר שמחפש מכשירים להתאמה מהירה, הוא צריך
    • הגדרת הכתובת של הרכיב שמבצעים בו איגוד
    • שליחת מפתח הגישה לרכיב שמבצע את ההתאמה
    • הגדרת קוד הסטטוס למצב המתנה, 0x01
  • כשספק מקבל בקשה לאישור קריאה לפני שהוא מקבל מפתח גישה מהרכיב שמקושר אליו, הוא צריך להחזיר הודעה עם
    • מפתח גישה, כל ערך
    • הכתובת של הרכיב שמקשרים
    • קוד סטטוס בהמתנה, 0x01
  • לפני שהספק שולח התראה למכשיר שמחפש התאמה מהירה, הוא מגדיר את התוצאה של בקשת הקריאה עם
    • מפתח גישה מהרכיב שמבצעים איתו שיוך
    • הכתובת של הרכיב שמקשרים
    • קוד סטטוס של הצלחה, 0x00
  • אם יש שגיאה שלא ניתן לתקן בצד הספק, צריך להגדיר את התוצאה
    • מפתח גישה, כל ערך
    • הכתובת של הרכיב שמקשרים
    • קוד סטטוס הכשל, 0x02

פרטים נוספים זמינים בתרשים MITM 1 ובתרשים MITM 2.

דרישות לגבי מכשירי LE

LE Advertising

במצב גלוי או במצב לא גלוי, הספק ישתמש ב-RPA כדי לפרסם נתונים של Fast Pair.

יכולת הדבקה

במכשירים עם תמיכה ב-LE, מכשיר החיפוש צריך ליצור שיוך לחיבור ה-LE הקיים. אחרי שעוברים את האימות של ההתאמה המבוססת על מפתח של התאמה מהירה, הספק צריך לאפשר שיוך עם RPA ולהגדיר את יכולת הקלט/פלט ל-DisplayYesNo לצורך אימות של מפתח גישה להתאמה מהירה.

דרישות לגבי מכשירים של רשויות אכיפת חוק

LEA Advertising

למכשירים עם מצב כפול: במצב גילוי, הספק יפרסם נתוני התאמה מהירה עם כתובת הזהות. במצב לא ניתן לגילוי, הספק יפרסם נתוני התאמה מהירה באמצעות RPA. מומלץ מאוד להשתמש בפרסום מדור קודם (BT 4.2) כדי לתמוך במכשירים ישנים לצורך תאימות לאחור. צריך לשנות את מפתח ה-IRK בכל פעם שמבצעים איפוס להגדרות המקוריות במכשיר.

במכשירים שאינם במצב כפול: במצב גלוי או במצב לא גלוי, הספק ישתמש בפרסום מורחב (BT 5.0) עם RPA כדי לפרסם נתונים של FastPair.

הפרסום של LE Connectable שמכיל נתוני שירות FP צריך לכלול CAS UUID בהתאם לדרישות של Bluetooth Adapter Profile (BAP 1.0.1) ושל Common Audio Profile.

הספק יכול לציין יכולת LEA על ידי הכללת ה-UUID של CAS ‏(0x1853) בנתוני השירות (סוג AD‏ 0x16) או ב-UUID של מחלקת השירותים (16 ביט) (סוג AD‏ 0x02 או 0x03), ללא קשר למצב הגילוי.

במקרה של מודעות שלא ניתן לגלות, אם אין מספיק מקום במודעות מדור קודם בגלל הכללה של נתוני סוללה ו-SASS, חובה לכלול את ה-UUID של CAS בתגובה לסריקה.

יכולת שילוב של LEA

ה-Seeker צריך ליצור קשר עם חיבור ה-LE הקיים. אחרי שעוברים אימות של התאמה מבוססת-מפתח של התאמה מהירה, ספק במצב כפול צריך לאפשר שיוך עם כתובת זהות ו-RPA, וספק שלא במצב כפול צריך לאפשר שיוך עם RPA ולהגדיר את יכולת הקלט/פלט ל-DisplayYesNo לאימות של מפתח גישה להתאמה מהירה.

ערוץ תקשורת פנימי בין רכיבים

החיבור הקיים של GATT נשמר כדי לבצע הגנה מפני התקפות MITM על הרכיבים הנוספים. הרכיב הראשי המצורף יטפל במסירת הודעות בין מכשיר החיפוש של התכונה 'התאמה מהירה' לבין הרכיבים הנותרים שלו.

התקשורת הפנימית משמשת ל-Initial Pair ול-Subsequent Pair

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

הגיע הזמן לשנות את יכולת הקלט/פלט

  • שינוי יכולת הקלט/פלט ל-DisplayYesNo כשנוהל ההתאמה מבוסס-המקשים עבר
    • אם למכשיר יש כמה רכיבים, צריך להגדיר את כל הרכיבים לערך DisplayYesNo
    • יוצא מן הכלל: הספק לא ישנה את היכולת של IO ל-DisplayYesNo אם Retroactive Pair, שביט 3 של בקשת השיוך מבוססת המפתח שלו מוגדר כ-1. ראו הודעה מהמבקש לספק
  • שינוי יכולת הקלט/פלט להגדרת ברירת המחדל
    • התאמה ראשונית
      • אם החיבור ב-LE מנותק, צריך לסיים את סשן ההתאמה המהירה
      • אחרי שהמכשיר הראשי משויך, אם לא מתקבלת בקשת כתיבה נוספת של מפתח גישה תוך 15 שניות, הסשן של ההתאמה המהירה מסתיים
      • אחרי קבלת בקשת כתיבה נוספת של מפתח גישה, אם הרכיב שמבוצעת אליו התאמה לא מותאם תוך 15 שניות, סשן ההתאמה המהירה מסתיים
      • אחרי שכל הרכיבים משויכים, אם לא מתקבלת בקשת כתיבה של מפתח החשבון תוך 15 שניות, הסשן של צימוד מהיר מסתיים.
      • אחרי שמתקבלת בקשת כתיבה של מפתח החשבון, מגדירים זמן קצוב לתפוגה של 15 שניות לסיום הסשן של התאמה מהירה
    • התאמה הבאה
      • אם החיבור ב-LE מנותק, צריך לסיים את סשן ההתאמה המהירה
      • אחרי שהמפתח הראשי משויך, אם לא מתקבלת בקשת כתיבה נוספת של מפתח גישה תוך 15 שניות, הסשן של צימוד מהיר מסתיים.
      • אחרי קבלת בקשת כתיבה נוספת של מפתח גישה, אם הרכיב שמבוצעת אליו התאמה לא מותאם תוך 15 שניות, סשן ההתאמה המהירה מסתיים
      • כשכל הרכיבים מחוברים, מסיימים את סשן ההתאמה המהירה.

הסתרת סימון בממשק המשתמש

אם האוזניות לא מוכנות לצימוד, הספק ישתמש ב-type 0b0010 כדי להגדיר הסתרה של אינדיקציה בממשק המשתמש לגבי נתוני מפתח החשבון, כדי להודיע למכשיר המחפש לא להציג ממשק משתמש לצימוד בהמשך (ראו Advertising payload: Fast Pair Account Data).

דרישות לגבי מכשירים עם LE Audio

דרישות Bluetooth

המלצות לאוזניות LE Audio ל-Android

תמיכה ב-CTKD

במכשיר עם מצב כפול, חובה להשתמש ב-CTKD מ-LE ל-BR/EDR בהתאם לדרישות של BAP.

הודעה על טירגוט

מכשיר היקפי צריך להשתמש בהודעה ממוקדת כדי לבקש חיבור ממכשיר מרכזי משויך. ההגדרה של הודעות ממוקדות מופיעה ב-BAP וב-CAP לניהול חיבורים בהתאם לטבלה 8.4 (עמוד 48 מתוך 58) ב-CAP 1.0.

תמיכה בשרת GATT EATT

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

אם הספק הוא לא מכשיר יחיד אלא קבוצה מתואמת עם הטמעה של CSIP, כדי לצמצם את מספר הפעמים שמתבצעת בדיקת זמינות של שירותים ולזרז את החיבור, הספק צריך להטמיע את GATT Caching שמוגדר ב-Bluetooth 5.1.

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

LE Advertising

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

חשיפה של שירות 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
      • ביט 0 צריך להיות 0
      • הביט הראשון צריך להיות 0
      • הכתובת צריכה להיות כתובת ציבורית
  • התוקף יוצר קשר עם פרוטוקול התעבורה BR/EDR
    • היכולת של IO מוגדרת ל-DisplayYesNo עבור BR/EDR
  • התקן המחפש והספק מבצעים את תהליך האימות של מפתח הגישה באמצעות התאמה מהירה

תרחיש 2 – כשהכלי לחיפוש תומך ב-LEA

רכיבים
  • ספק
    • תמיכה ב-A2DP/HFP/LEA
    • רכיב יחיד
  • Seeker
    • SupportA2DP/HFP/LEA
התנהגות צפויה בהתאמה ראשונית / התאמה חוזרת
  • הספק מפרסם נתונים של שירות ההתאמה המהירה (0xFE2C) עם כתובת זהות (התחלתית) או RPA (לאחר מכן).
    • שימוש בגרסה הקודמת של פרסום
  • המשתמש שולח בקשה להצמדה מבוססת-מפתח
    • הביט 5 של הדגל בבקשה לשיוך מבוסס-מפתח מוגדר כ-1
  • הספק שולח תגובה של צימוד מבוסס-מפתח עם סוג ההודעה 0x02
    • ביט 0 צריך להיות 0
    • הביט 1 צריך להיות 1
    • הכתובת היא כתובת הזהות
  • ה-Seeker יוצר קשר עם חיבור ה-LE הקיים בהעברת LE
    • הכיוון של CTKD הוא מ-LE אל BR/EDR
    • יכולת הקלט/פלט מוגדרת כ-DisplayYesNo עבור LE
  • התקן המחפש והספק מבצעים את תהליך האימות של מפתח הגישה באמצעות התאמה מהירה

תרחיש 3 – כשהכלי לחיפוש תומך ב-LEA ו-CSIP מעורב

רכיבים
  • ספק
    • תמיכה ב-A2DP/HFP/LEA
    • רכיבים מרובים
      • הרכיב העיקרי הוא BR/EDR/LE
      • הרכיב המשני הוא LE בלבד
  • Seeker
    • תמיכה ב-A2DP/HFP/LEA
התנהגות צפויה בהתאמה ראשונית / התאמה חוזרת
  • הרכיב הראשי מפרסם נתוני שירות של Fast Pair ‏ (0xFE2C) עם כתובת זהות (התחלתית) או RPA (לאחר מכן).
    • שימוש בגרסה הקודמת של פרסום
  • המשתמש שולח בקשה להצמדה מבוססת-מפתח לרכיב הראשי
    • הביט 5 של הדגל בבקשה לשיוך מבוסס-מפתח מוגדר כ-1
  • הרכיב הראשי שולח תגובה של שיוך מבוסס-מפתח עם סוג ההודעה 0x02
    • ביט 0 צריך להיות 0
    • הביט 1 צריך להיות 1
    • הכתובות מפורטות בהמשך:
      • הכתובת הראשונה היא כתובת הזהות של הרכיב הראשי
      • הכתובת השנייה היא הכתובת שאפשר לקשר אליה את הרכיב המשני, הרכיב השני משתמש גם בכתובת הזו כדי לפרסם CSIP
  • ה-Seeker יוצר קשר עם הרכיב הראשי בחיבור ה-LE הקיים
    • הכיוון של CTKD הוא מ-LE אל BR/EDR
    • יכולת הקלט/פלט מוגדרת כ-DisplayYesNo עבור LE
  • המחפש יוצר קשר עם רכיב משני שהכתובת שלו היא מתוך התגובה המורחבת של ההתאמה מבוססת-המפתח
    • יכולת הקלט/פלט צריכה להיות DisplayYesNo, אחרת צריך לדחות את בקשת ההתאמה
  • ההתקן המחפש והספק מבצעים הליך הגנה מפני התקפות MITM כדי להתאים את הרכיב המשני. הספק צריך להטמיע את שני התרחישים הבאים
  • ה-Seeker מחכה עד שהוא מתחבר לרכיב המשני

תרשים עוקב של MITM

בסשן הזה נתאר את רצף הפעולות של הליך ההגנה מפני התקפות MITM.

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

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

בעיה ידועה

התכונה 'הגנה מפני הונאה' עבור LEA עברה אופטימיזציה כדי לפעול עם Android V ‏(Android 15).

לעומת זאת, נתקלנו בבעיות רבות באוזניות שתומכות ב-LEA אבל לא מותקנת בהן ההטמעה הנכונה של התאמה מהירה באמצעות LEA (כלומר, רק התאמה מהירה באמצעות Classic). לדוגמה, אם ה-RPA של הספק לא נוצר על ידי מפתח נכון לפתרון זהויות (IRK), ולא ניתן לפתור את הכתובת. לא הצלחנו לבדוק רשימה מקיפה של תצורות אוזניות, אבל הבדיקות המוגבלות שביצענו חשפו בעיות שונות, כולל אי הצגת התראות על סוללת האוזניות, היעדר פונקציונליות של מעבר אוטומטי בין מכשירים (SASS), כשלים נרחבים בהתאמה הראשונית ובהתאמות הבאות ועוד.

לכן מומלץ מאוד לשותפים להטמיע את המפרט של Fast Pair-LEA במכשירים חדשים ובמכשירים קיימים בשטח (באמצעות עדכונים דרך האוויר) שתומכים במצבים כפולים.