תהליך ההתאמה המהירה

התהליך

במקום להפעיל מיד כל אחד מהליכי הקישור הרגילים של BR/EDR או BLE, המחפש מפעיל קודם התראות במאפיין ההתאמה מבוססת-מפתח, ואז כותב אליו את הנתונים בטבלה 1.1.

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

  1. אם השדה האופציונלי של המפתח הציבורי קיים:
    1. אם המכשיר לא במצב התאמה, מתעלמים מהכתיבה ויציאה.
    2. אחרת:
      1. משתמשים במפתח הציבורי שהתקבל (נקודה של 64 בייט בעקומה האליפטית secp256r1), במפתח הפרטי למניעת זיוף המותקן מראש, וגם ב-secp256r1, ובאלגוריתם Elliptic-Curve Diffie-Hellman כדי ליצור מפתח AES של 256 ביט.
      2. שימוש ב-SHA-256 כדי לבצע גיבוב (hash) של מפתח AES של 256-ביט.
      3. קח את 128 הביטים הראשונים של התוצאה. זהו מפתח ה-AES נגד זיוף, שישמש אותך בשלב הבא.

  2. באמצעות AES-128, מנסים לפענח את הערך. מכיוון שהערך הוא בלוק AES יחיד של 16 בייט, לא נדרש מצב צופן IV או מרובה בלוקים.

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

    3. הערך מפוענח בהצלחה אם הפלט תואם לפורמט טבלה 1.2.1 או טבלה 1.2.2 (כלומר, אם הוא מכיל את כתובת ה-BLE הנוכחית של ספק ההתאמה המהירה או את הכתובת הציבורית של ספק ההתאמה המהירה).

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

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

  3. אם לא נמצא מפתח שהצליח לפענח את הערך, מתעלמים מהכתיבה ומהיציאה.

    1. מומלץ לספור את הכשלים האלה. כשמספר הכשלים מגיע ל-10, נכשלים מיד בכל הבקשות החדשות. מאפסים את מספר התקלות אחרי 5 דקות, אחרי הפעלה או אחרי הפעלה.

  4. אם לא, שומרים את המַפְתח כ-K. מסמנים את ה-K כניתן להשתמש בו לפענוח מפתחות גישה וכתיבה של שם מותאם אישית שהתקבלו בקישור LE הזה, אבל לא לכתיבה אחרת או לכתיבה באף קישור אחר. מפעילים טיימר כדי למחוק את הערך K אחרי 10 שניות אם ההתאמה לא התחילה. מוחקים גם את K אם קישור ה-LE הזה מתנתק.

  5. מפיקים את ה-Raw Response באורך 16 בייטים שמוצג בטבלה 1.3, על ידי שרשור הסוג וכתובת ה-BR/EDR של הספק, ואז ממלאים את שארית החבילה בבלוק של בייטים אקראיים (כלומר salt).

  6. הצפנת התגובה הגולמית באמצעות K, על מנת להפיק את התגובה המוצפנת בגודל 16 בייטים שתוצג בטבלה 1.4. יש לשלוח אותה באמצעות הודעה לגבי מאפיין ההתאמה המבוסס על מפתח.

  7. קוראים את דגל הבקשה:

    1. אם בייט 2 של הסימונים של הבקשה מוגדר ל-1, שולחים הודעה למאפיין של נתונים נוספים עם שם מותאם אישית.
    2. אם בבייט סימונים של הבקשה יש ביט 1 שמוגדר ל-1:
      1. משמעות הדבר היא שהמחפש מבקש מהספק להתחיל קישור לכתובת BR/EDR של המחפש, שנמצאת בבייטים 8-13.
      2. צריך לשלוח בקשת התאמה לכתובת BR/EDR של המחפש. בקשת ההתאמה צריכה להיות כפי שמתואר בהמשך (השלב 'במהלך ההתאמה').
      3. הסיבה לכך היא שצריך להפעיל את הספק כדי לעקוף בעיה במכשירים מסוימים.
    3. אם בבייט סימונים של הבקשה יש ביט 1 שמוגדר ל-0:
      1. מחכים 10 שניות לכל היותר לבקשת התאמה. אם לא יתקבל אישור, יצאו.
      2. שימו לב שזו יכולה להיות בקשת BR/EDR מכתובת אחרת (הכתובת הציבורית של המחפש, במקום הכתובת הפרטית שניתן לפענח). במהלך ההתאמה נאמת מחדש שהמכשיר שממנו נשלחה הבקשה נמצא ב-K.

  8. במהלך ההתאמה:

    1. כשמתקבלת חבילת בקשה/תגובה מהמחפש: אם יכולות המכשיר בבקשה הן Noinput/NoOutput, צריך לסיים את ההתאמה, כדי להימנע משימוש בשיטת ההתאמה של Just Works.
    2. לבקשת ההתאמה/חבילת התגובה שנשלחה על ידי הספק: מגדירים את השדה Device Capabilities (יכולות המכשיר) ל-Display/YesNo (תצוגה/כןלא) ומגדירים את Authentication Products (דרישות האימות) לערך MITM Protection required (נדרשת הגנה על ידי MITM). הפעולה הזו מפעילה את שיטת ההתאמה המספרית להשוואת ביצועים (שנקראת גם אישור מפתח גישה ב-Android). אנחנו מסתמכים על כך כדי לאשר שהמכשיר המבקש הוא אכן המחפש המהיר, ושאין "אדם בתווך". דוגמאות
    3. הסיבה לכך: שיטת ההתאמה 'מחוץ למסגרת' מתאימה יותר, אבל הפלטפורמה לא חושפת אותה בכל הגרסאות הרצויות של Android.

  9. כשנדרש אישור של מפתח הגישה, ממתינים עד 10 שניות לכתיבה במאפיין מפתח הגישה.

    1. בדרך כלל, בעזרת שיטת ההתאמה הזו, המשתמשים מאשרים שמפתחות הגישה שמוצגים במסך של כל מכשיר זהים. במקום זאת, רק לצורך ההתאמה הזו אנחנו מעבירים אותם באמצעות BLE, מוצפן באמצעות המפתח המשותף מראש המהימן.
    2. שימו לב: אין להשתמש בגישה הזו במכשירים עם מסך או מקלדת, מכיוון שהגנה כזו גורמת לפגיעה קלה בהגנת MITM. לכן התכונה 'התאמה מהירה' עדיין לא תומכת בסוגי המכשירים האלה.
    3. אם פג התוקף של הטיימר של 10 שניות בלי לכתוב מפתח גישה, מוחקים את K.

  10. כשערך נכתב במאפיין של מפתח גישה, זהו הבלוק של מפתח הגישה המוצפן. מפענחים אותו באמצעות K כדי לקבל בלוק של מפתחות גישה גולמיים, בפורמט שמוצג בקטע מאפיין: מפתח גישה > טבלה 2.2 - (סוג = מפתח הגישה של המחפש).

  11. אם הפענוח נכשל, מתעלמים מהכתיבה ומוחקים את K.

  12. אחרת, הבלוק של מפתחות הגישה הגולמיים מכיל מפתח גישה בן 6 ספרות, PSeeker, שהוא מפתח הגישה שהמחפש מצפה לו.

  13. משווים את PSeeker עם מפתח הגישה הצפוי שלנו, PProvider.

    1. אם הערכים שווים, יש להשיב 'yes' לאישור.
    2. אחרת, עליך להשיב 'לא' לאישור. ההתאמה תיכשל.

  14. גם אם ההתאמה נכשלה, תוכלו ליצור עוד בלוק של מפתחות גישה גולמיים, בפורמט שמוצג במאפיין: מפתח גישה > טבלה 2.2, שמכיל את מפתח הגישה הצפוי שלנו, >.

    1. מוודאים שהבלוק הוא מהסוג הנכון (מפתח הגישה של הספק; פרטים בטבלה). הערה: אין להשתמש שוב ב-salt מבלוק מפתחות הגישה שהתקבל מהמחפש. יוצרים ערך אקראי חדש.

  15. מצפינים את הבלוק של מפתחות הגישה הגולמיים באמצעות K, ושולחים את הבלוק של מפתח הגישה המוצפן שהתקבל באמצעות התראה במאפיין של מפתח הגישה.

  16. אם המחפש מקבל ומפענח את מפתח הגישה הנכון P, הוא גם ישיב 'כן' לאישור, וההתאמה תצליח.

    1. אם ההתאמה מצליחה, מסמנים את K בתור ניתן לשימוש לצורך פענוח מפתח החשבון שכותב בקישור ה-LE הזה, אבל לא לכל מפתח גישה שכתוב או לכתיבה באף קישור אחר. מפעילים טיימר כדי למחוק את K אחרי 10 שניות. מוחקים גם את ה-K אחרי כל ניסיון לכתוב מפתח חשבון, וכמו בשלב 4, אם קישור ה-LE מתנתק.
    2. אם ההתאמה נכשלת, מוחקים את K.

  17. מחזירים את שדה יכולות הקלט/פלט לברירת המחדל של יכולות קלט/פלט (I/O) ואת דרישות האימות לברירת המחדל, כדי שצמדים חדשים ימשיכו לפעול כצפוי.

שימו לב שעבור ספקים שלא דורשים חיבורים, המחפש לא שולח בקשת התאמה לספק. זהו שלב 8 – מדלגים על שלב 17. בנוסף, "K" משמש בשדה מאפיין מפתח חשבון.

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