קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
תהליך ההתאמה המהירה
התהליך
במקום להפעיל מיד כל אחד מהליכי הקישור הרגילים של BR/EDR או BLE, המחפש מפעיל קודם התראות במאפיין ההתאמה מבוססת-מפתח, ואז כותב אליו את הנתונים בטבלה 1.1.
בעת טיפול בבקשת כתיבה ממחפש התאמה מהירה, ספק ההתאמה המהירה יבצע את הפעולות הבאות:
אם השדה האופציונלי של המפתח הציבורי קיים:
אם המכשיר לא במצב התאמה, מתעלמים מהכתיבה ויציאה.
אחרת:
משתמשים במפתח הציבורי שהתקבל (נקודה של 64 בייט בעקומה האליפטית secp256r1), במפתח הפרטי למניעת זיוף המותקן מראש, וגם ב-secp256r1, ובאלגוריתם Elliptic-Curve Diffie-Hellman כדי ליצור מפתח AES של 256 ביט.
שימוש ב-SHA-256 כדי לבצע גיבוב (hash) של מפתח AES של 256-ביט.
קח את 128 הביטים הראשונים של התוצאה. זהו מפתח ה-AES נגד זיוף, שישמש אותך בשלב הבא.
באמצעות AES-128, מנסים לפענח את הערך. מכיוון שהערך הוא בלוק AES יחיד של 16 בייט, לא נדרש מצב צופן IV או מרובה בלוקים.
באיזה מקש להשתמש:
אם נוצר מפתח AES למניעת זיוף בשלב 1, יש להשתמש במפתח הזה.
אם לא, כדאי לנסות כל אחד מהמפתחות ברשימת מפתחות החשבון הקבועה.
אם מפתח מפענח את הערך בהצלחה, צריך לשבור אותו ולהמשיך לשלב הבא.
הערך מפוענח בהצלחה אם הפלט תואם לפורמט טבלה 1.2.1 או טבלה 1.2.2 (כלומר, אם הוא מכיל את כתובת ה-BLE הנוכחית של ספק ההתאמה המהירה או את הכתובת הציבורית של ספק ההתאמה המהירה).
הערה: בסוף החבילה יש salt. כשאפשר, יש לעקוב אחר נתוני ה-salt האלה, ואם הספק מקבל בקשה שמכילה salt שכבר נמצא בשימוש, יש להתעלם מהבקשה כדי למנוע התקפות שליחה מחדש.
כחלופה למעקב אחר נתוני salt, אם הכתיבה כוללת את הכתובת הפרטית של הספק, דרך נוספת למנוע התקפות שליחה מחדש היא להקדים את הזמן של רוטציית הכתובת הפרטית הבאה שניתן לפענח, כך שהרוטציה תתבצע לפני אישור הכתיבה הבאה של התאמה מבוססת מפתח.
אם לא נמצא מפתח שהצליח לפענח את הערך, מתעלמים מהכתיבה ומהיציאה.
מומלץ לספור את הכשלים האלה. כשמספר הכשלים מגיע ל-10, נכשלים מיד בכל הבקשות החדשות. מאפסים את מספר התקלות אחרי 5 דקות, אחרי הפעלה או אחרי הפעלה.
אם לא, שומרים את המַפְתח כ-K. מסמנים את ה-K כניתן להשתמש בו לפענוח מפתחות גישה וכתיבה של שם מותאם אישית שהתקבלו בקישור LE הזה, אבל לא לכתיבה אחרת או לכתיבה באף קישור אחר. מפעילים טיימר כדי למחוק את הערך K אחרי 10 שניות אם ההתאמה לא התחילה. מוחקים גם את K אם קישור ה-LE הזה מתנתק.
מפיקים את ה-Raw Response באורך 16 בייטים שמוצג בטבלה 1.3, על ידי שרשור הסוג וכתובת ה-BR/EDR של הספק, ואז ממלאים את שארית החבילה בבלוק של בייטים אקראיים (כלומר salt).
הצפנת התגובה הגולמית באמצעות K, על מנת להפיק את התגובה המוצפנת בגודל 16 בייטים שתוצג בטבלה 1.4. יש לשלוח אותה באמצעות הודעה לגבי מאפיין ההתאמה המבוסס על מפתח.
קוראים את דגל הבקשה:
אם בייט 2 של הסימונים של הבקשה מוגדר ל-1, שולחים הודעה למאפיין של נתונים נוספים עם שם מותאם אישית.
אם בבייט סימונים של הבקשה יש ביט 1 שמוגדר ל-1:
משמעות הדבר היא שהמחפש מבקש מהספק להתחיל קישור לכתובת BR/EDR של המחפש, שנמצאת בבייטים 8-13.
צריך לשלוח בקשת התאמה לכתובת BR/EDR של המחפש. בקשת ההתאמה צריכה להיות כפי שמתואר בהמשך (השלב 'במהלך ההתאמה').
הסיבה לכך היא שצריך להפעיל את הספק כדי לעקוף בעיה במכשירים מסוימים.
אם בבייט סימונים של הבקשה יש ביט 1 שמוגדר ל-0:
מחכים 10 שניות לכל היותר לבקשת התאמה. אם לא יתקבל אישור,
יצאו.
שימו לב שזו יכולה להיות בקשת BR/EDR מכתובת אחרת (הכתובת הציבורית של המחפש, במקום הכתובת הפרטית שניתן לפענח).
במהלך ההתאמה נאמת מחדש שהמכשיר שממנו נשלחה הבקשה נמצא ב-K.
במהלך ההתאמה:
כשמתקבלת חבילת בקשה/תגובה מהמחפש:
אם יכולות המכשיר בבקשה הן Noinput/NoOutput, צריך לסיים את ההתאמה, כדי להימנע משימוש בשיטת ההתאמה של Just Works.
לבקשת ההתאמה/חבילת התגובה שנשלחה על ידי הספק: מגדירים את השדה Device Capabilities (יכולות המכשיר) ל-Display/YesNo (תצוגה/כןלא) ומגדירים את Authentication Products (דרישות האימות) לערך MITM Protection required (נדרשת הגנה על ידי MITM). הפעולה הזו מפעילה את שיטת ההתאמה המספרית להשוואת ביצועים (שנקראת גם אישור מפתח גישה ב-Android).
אנחנו מסתמכים על כך כדי לאשר שהמכשיר המבקש הוא אכן המחפש המהיר, ושאין "אדם בתווך". דוגמאות
הסיבה לכך: שיטת ההתאמה 'מחוץ למסגרת' מתאימה יותר, אבל הפלטפורמה לא חושפת אותה בכל הגרסאות הרצויות של Android.
כשנדרש אישור של מפתח הגישה, ממתינים עד 10 שניות לכתיבה במאפיין מפתח הגישה.
בדרך כלל, בעזרת שיטת ההתאמה הזו, המשתמשים מאשרים שמפתחות הגישה שמוצגים במסך של כל מכשיר זהים. במקום זאת, רק לצורך ההתאמה הזו אנחנו מעבירים אותם באמצעות BLE, מוצפן באמצעות המפתח המשותף מראש המהימן.
שימו לב: אין להשתמש בגישה הזו במכשירים עם מסך או מקלדת, מכיוון שהגנה כזו גורמת לפגיעה קלה בהגנת MITM.
לכן התכונה 'התאמה מהירה' עדיין לא תומכת בסוגי המכשירים האלה.
אם פג התוקף של הטיימר של 10 שניות בלי לכתוב מפתח גישה, מוחקים את K.
כשערך נכתב במאפיין של מפתח גישה, זהו הבלוק של מפתח הגישה המוצפן. מפענחים אותו באמצעות K כדי לקבל בלוק של מפתחות גישה גולמיים, בפורמט שמוצג בקטע מאפיין: מפתח גישה>טבלה 2.2 - (סוג =
מפתח הגישה של המחפש).
אם הפענוח נכשל, מתעלמים מהכתיבה ומוחקים את K.
אחרת, הבלוק של מפתחות הגישה הגולמיים מכיל מפתח גישה בן 6 ספרות, PSeeker, שהוא מפתח הגישה שהמחפש מצפה לו.
משווים את PSeeker עם מפתח הגישה הצפוי שלנו, PProvider.
אם הערכים שווים, יש להשיב 'yes' לאישור.
אחרת, עליך להשיב 'לא' לאישור. ההתאמה תיכשל.
גם אם ההתאמה נכשלה, תוכלו ליצור עוד בלוק של מפתחות גישה גולמיים, בפורמט שמוצג במאפיין: מפתח גישה>טבלה 2.2, שמכיל את מפתח הגישה הצפוי שלנו, >.
מוודאים שהבלוק הוא מהסוג הנכון (מפתח הגישה של הספק; פרטים בטבלה).
הערה: אין להשתמש שוב ב-salt מבלוק מפתחות הגישה שהתקבל מהמחפש. יוצרים ערך אקראי חדש.
מצפינים את הבלוק של מפתחות הגישה הגולמיים באמצעות K, ושולחים את הבלוק של מפתח הגישה המוצפן שהתקבל באמצעות התראה במאפיין של מפתח הגישה.
אם המחפש מקבל ומפענח את מפתח הגישה הנכון P, הוא גם ישיב 'כן' לאישור, וההתאמה תצליח.
אם ההתאמה מצליחה, מסמנים את K בתור ניתן לשימוש לצורך פענוח מפתח החשבון שכותב בקישור ה-LE הזה, אבל לא לכל מפתח גישה שכתוב או לכתיבה באף קישור אחר. מפעילים טיימר כדי למחוק את K אחרי 10 שניות. מוחקים גם את ה-K אחרי כל ניסיון לכתוב מפתח חשבון, וכמו בשלב 4, אם קישור ה-LE מתנתק.
אם ההתאמה נכשלת, מוחקים את K.
מחזירים את שדה יכולות הקלט/פלט לברירת המחדל של יכולות קלט/פלט (I/O) ואת דרישות האימות לברירת המחדל, כדי שצמדים חדשים ימשיכו לפעול כצפוי.
שימו לב שעבור ספקים שלא דורשים חיבורים, המחפש לא שולח בקשת התאמה לספק. זהו שלב 8 – מדלגים על שלב 17. בנוסף, "K" משמש בשדה מאפיין מפתח חשבון.
דוגמאות
דוגמה 1: ניסיון התאמה מוצלח
(ללא 'אדם בתווך').דוגמה 2: ניסיון התאמה כושל, עם
אדם בתווך.
[null,null,["עדכון אחרון: 2025-08-13 (שעון UTC)."],[[["\u003cp\u003eFast Pair utilizes BLE for initial key exchange and then triggers BR/EDR pairing for secure connection.\u003c/p\u003e\n"],["\u003cp\u003eThe Provider verifies the Seeker's authenticity using encryption, a shared secret, and a numeric comparison pairing method.\u003c/p\u003e\n"],["\u003cp\u003eAccount Keys are exchanged securely after successful pairing to enable seamless future connections.\u003c/p\u003e\n"],["\u003cp\u003eThe process includes anti-spoofing measures like public key cryptography and salt tracking to enhance security.\u003c/p\u003e\n"],["\u003cp\u003eThe Provider initiates the BR/EDR pairing to address compatibility issues with certain devices.\u003c/p\u003e\n"]]],[],null,["Fast Pair Procedure\n-------------------\n\n### Procedure\n\n| **Note:** Google recommends implementing the [Cryptographic Test Cases](/nearby/fast-pair/specifications/appendix/cryptotestcases \"Link to the Cryptographic Test Cases.\") to ease verification of these requirements.\n\nInstead of immediately invoking any of the normal BR/EDR or BLE bonding\nprocedures, the Seeker first enables Notifications on the Key-based Pairing\ncharacteristic, and then writes the data in [Table 1.1](/nearby/fast-pair/specifications/characteristics#table1.1 \"table 1.1\") to it.\n\nWhen handling a write request from a Fast Pair Seeker, the Fast Pair Provider\nshall do the following:\n\n1. If the optional Public Key field **is present** :\n 1. If the device is not in pairing mode, ignore the write and exit.\n 2. Otherwise:\n 1. Use the received Public Key (a 64-byte point on the secp256r1 elliptic curve), the pre-installed [Anti-Spoofing Private Key](/nearby/fast-pair/specifications/configuration#antispoofing \"Anti-Spoofing\") - also secp256r1, and the Elliptic-Curve Diffie-Hellman algorithm to generate a 256-bit AES key.\n 2. Use SHA-256 to hash the 256-bit AES key.\n 3. Take the first 128 bits of the result. This is the Anti-Spoofing AES Key, used in the next step.\n2. Using AES-128, attempt to decrypt the value. Since the value is a single\n 16-byte AES block, no IV or multi-block cipher mode is necessary.\n\n 1. Which key to use:\n 1. If an Anti-Spoofing AES Key was generated in step 1, use that key.\n 2. Otherwise, try each key in the persisted Account Key List.\n 2. If a key successfully decrypts the value, break, and continue to the next step.\n 3. The value is decrypted successfully if the output matches the format in\n [Table 1.2.1](/nearby/fast-pair/specifications/characteristics#table1.2.1 \"table 1.2.1\") or [Table 1.2.2](/nearby/fast-pair/specifications/characteristics#table1.2.2 \"table 1.2.2\") - (that is, if it\n contains either the Fast Pair Provider's current BLE address, or the Fast\n Pair Provider's public address).\n\n NOTE: At the end of the packet there is a salt attached. When\n possible, these salts should be tracked, and if the Provider receives a\n request containing an already used salt, the request should be ignored to\n prevent replay attacks.\n 4. As an alternative to tracking salts, if the write includes the Provider's\n private address, another way to prevent replay attacks is to bring\n forward the time of the next resolvable private address rotation so that\n the rotation occurs before the next Key-based Pairing write will be\n accepted.\n\n3. If no key could successfully decrypt the value, ignore the write and exit.\n\n 1. Keep a count of these failures. **When the failure count hits 10, fail\n all new requests immediately. Reset the failure count after 5 minutes,\n after power on, or after a success.**\n4. Otherwise, save the successful key as *K* . Mark this *K* as usable for\n decrypting Passkey and Personalized name writes received on this LE link, but\n not other writes nor any writes on any other link. Start a timer to discard\n *K* after 10 seconds if pairing has not been started. Also discard *K* if\n this LE link disconnects.\n\n5. Produce the 16-byte Raw Response shown in [Table 1.3](/nearby/fast-pair/specifications/characteristics#table1.3 \"table 1.3\"), by\n concatenating the type and the Provider's BR/EDR address, and then filling\n the remainder of the packet with a block of random bytes (that is, a salt).\n\n6. Encrypt the Raw Response with K to produce the 16-byte Encrypted Response\n shown in [Table 1.4](/nearby/fast-pair/specifications/characteristics#table1.4 \"table 1.4\"). Send this via a notify on the Key-based Pairing\n characteristic.\n\n7. Read the request flag:\n\n 1. **If the Request's Flags byte has bit 2 set to 1** , notify [Additional Data characteristic](/nearby/fast-pair/specifications/characteristics#AdditionalData \"Characteristic - Additional Data\") with personalized name.\n 2. **If the Request's Flags byte has bit 1 set to 1:**\n 1. This indicates that the Seeker is requesting the Provider to initiate bonding to the Seeker's BR/EDR address, which is present in bytes 8-13.\n 2. Send a pairing request to the Seeker's BR/EDR address. The pairing request must be as described below (\"During pairing\" step).\n 3. Reason this is needed: Having the Provider initiate works around an issue on some devices.\n 3. **If the Request's Flags byte has bit 1 set to 0:**\n 1. Wait up to 10 seconds for a pairing request. If none is received, exit.\n 2. Note that this might be a BR/EDR request, from a different address (the Seeker's public address, instead of its resolvable private address). We will re-verify during pairing that the requesting device is in possession of *K*.\n8. During pairing:\n\n 1. When a **pairing request/response packet** is received from the Seeker: If the Device Capabilities in the request are NoInput/NoOutput, end pairing, to avoid using the Just Works pairing method.\n 2. For the pairing request/response packet sent by the Provider: Set the Device Capabilities field to **Display/YesNo** and set Authentication Requirements to **MITM Protection Required** . This triggers the Numeric Comparison pairing method (also known as [Passkey Confirmation](https://developer.android.com/reference/android/bluetooth/BluetoothDevice.html#PAIRING_VARIANT_PASSKEY_CONFIRMATION) on Android). We rely on this to confirm that the requesting device is in fact the Fast Pair Seeker, and that there is no man-in-the-middle. See [examples](#ProcedureExamples).\n 3. Reason this is needed: The Out-of-Band pairing method would be a better fit, but the platform does not expose it on all desired versions of Android.\n9. When **confirmation of the passkey is needed** , wait up to 10 seconds for a\n write to the [Passkey characteristic](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\").\n\n 1. Normally, with this pairing method, the user would confirm that the passkeys displayed on each device's screen are identical. Instead, only for this pairing, we transfer them over BLE, encrypted with the trusted pre-shared key.\n 2. Note that this approach should not be taken for devices that have a screen or a keyboard as it makes a slight compromise on MITM protection. Fast Pair currently does not support those device types yet because of this.\n 3. If the 10 second timer expires without a passkey being written, then discard *K*.\n10. When a **value is written to the Passkey characteristic** , this is the\n Encrypted Passkey Block. Decrypt it with K to yield a Raw Passkey Block, with\n format shown in [Characteristic: Passkey](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\") *\\\u003e* [Table 2.2](/nearby/fast-pair/specifications/characteristics#table2.2 \"table 2.2\") - (type =\n Seeker's Passkey).\n\n11. If decryption fails, ignore the write and discard *K*.\n\n12. Otherwise, the Raw Passkey Block contains a 6-digit passkey\n *P~Seeker~*, which is the passkey that the Seeker expects.\n\n13. Compare *P~Seeker~* with our own expected passkey,\n *P~Provider~*.\n\n 1. If the values are equal, reply \"yes\" to the confirmation.\n 2. Otherwise, reply \"no\" to the confirmation, causing pairing to fail.\n14. Regardless of whether pairing failed, produce another Raw Passkey Block, with\n format shown in [Characteristic: Passkey](/nearby/fast-pair/specifications/characteristics#Passkey \"passkey\") *\\\u003e* [Table 2.2](/nearby/fast-pair/specifications/characteristics#table2.2 \"table 2.2\"),\n containing our own expected passkey, *P~Provider~*.\n\n 1. Ensure the block has the correct type (Provider's Passkey; see table). NOTE: Do not reuse the salt from the Passkey Block received from the Seeker. Generate a new random value.\n15. Encrypt the Raw Passkey Block with *K*, and send the resulting Encrypted\n Passkey Block via a notify on the Passkey characteristic.\n\n16. If the Seeker receives and decrypts the correct passkey *P*, the Seeker will\n also reply \"yes\" to the confirmation, and pairing will succeed.\n\n 1. If the pairing succeeds, then mark *K* as usable for decrypting Account Key writes on this LE link, but not for any subsequent Passkey writes nor any writes on any other link. Start a timer to discard *K* after 10 seconds. Also discard *K* following any attempt to write an Account Key and, as per step 4, if the LE link disconnects.\n 2. If the pairing fails, discard *K*.\n17. Switch the device capabilities field back to default I/O capabilities and\n Authentication Requirements to default so that new\n pairings continue as expected.\n\nNote that for Providers that don't require bonding, the Seeker does not send a\npairing request to the Provider, that is step 8 - step 17 are skipped. Also,\n\"K\" is used in [Account Key characteristic](/nearby/fast-pair/specifications/characteristics#AccountKey \"Account Key\").\n\n##### Examples\n\n***Example 1:** Successful pairing attempt\n(no man-in-the-middle).* ***Example 2:** Failed pairing attempt, with a\nman-in-the-middle.*"]]
