v1.3
במפרט האביזר של רשת 'איפה המכשיר שלי' (FMDN) מוגדר גישת הצפנה מקצה לקצה למעקב אחרי מכשירי Bluetooth עם צריכת אנרגיה נמוכה (BLE) שמפיצים אותות. בדף הזה מתואר FMDN כהרחבה למפרט ההתאמה המהירה. ספקים צריכים להפעיל את התוסף הזה אם יש להם מכשירים שתואמים ל-FMDN והם רוצים להפעיל מעקב אחר המיקום של המכשירים האלה.
מפרט GATT
צריך להוסיף לשירות Fast Pair מאפיין נוסף של מאפיינים כלליים (GATT) עם הסמנטיקה הבאה:
מאפיין השירות של התאמה מהירה | מוצפנת | הרשאות | מזהה ייחודי אוניברסלי (UUID) |
---|---|---|---|
פעולות משׂואת רשת (beacon) | לא | קריאה, כתיבה ושליחת הודעות | FE2C1238-8366-4814-8EB0-01DE32100BEA |
טבלה 1: מאפייני השירות של התאמה מהירה ל-FMDN.
אימות
הפעולות הנדרשות על ידי התוסף הזה מתבצעות כפעולת כתיבה, שמאובטחת באמצעות מנגנון שלגרום-תגובה. לפני ביצוע פעולה כלשהי, ה-Seeker אמור לבצע פעולת קריאה מהמאפיין בטבלה 1, וכתוצאה מכך נוצר מאגר בפורמט הבא:
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | המספר של הגרסה הראשית של הפרוטוקול | 0x01 |
1 - 8 | מערך בייטים | מספר חד-פעמי אקראי ללא משמעות | משתנה |
כל פעולת קריאה צריכה להוביל לצופן חד-פעמי (nonce) שונה, וקוד חד-פעמי (nonce) אחד צריך להיות תקין רק לפעולה אחת. צריך לבטל את התוקף של המזהה החד-פעמי גם אם הפעולה נכשלה.
לאחר מכן, Seeker מחשב מפתח אימות חד-פעמי לשימוש בבקשת כתיבה שתישלח בהמשך. מפתח האימות מחושב כפי שמתואר בטבלאות 2 עד 5. בהתאם לפעולה המבוקשת, מבצע הבקשה צריך להוכיח שהוא יודע את אחד או יותר מהמפתחות הבאים:
Account key: מפתח חשבון בהתאמה מהירה בגודל 16 בייטים, כפי שמוגדר במפרט ההתאמה המהירה.
בעלים של חשבון: הספק בוחר אחד ממפתחות החשבון הקיימים כמפתח של חשבון הבעלים, בפעם הראשונה שמחפש ניגש למאפיין 'פעולות משׂואות' (beacon) לא ניתן לשנות את המפתח של חשבון הבעלים שנבחר עד לאיפוס הספק להגדרות המקוריות. הספק אסור להסיר את המפתח של חשבון הבעלים כשנגמרות לו התקינות הפתוחות למפתחות של חשבונות.
ספקים שכבר תומכים ב-FMDN במהלך ההתאמה הראשונה (או תומכים בו במהלך ההתאמה אחרי איפוס להגדרות המקוריות) בוחרים את מפתח החשבון הראשון, כי זהו מפתח החשבון היחיד הקיים כשה-Seeker קורא את מצב ההקצאה במהלך ההתאמה.
ספקים שמקבלים תמיכה ב-FMDN אחרי שהם כבר מותאמים (לדוגמה, דרך עדכון קושחה) יכולים לבחור מפתח חשבון קיים כלשהו. מומלץ לבחור את מפתח החשבון הראשון שמשמש לקריאת מצב ההקצאה מהמאפיין של פעולות ה-beacon אחרי עדכון הקושחה, בהנחה שהמשתמש שביצע את העדכון הוא הבעלים הנוכחי של הספק.
מפתח זהות זמני (EIK): מפתח באורך 32 בייטים שנבחר באופן אקראי על ידי מבצע החיפוש במהלך תהליך הקצאת ה-FMDN. המפתח הזה משמש להפקת מפתחות קריפטוגרפיים שמשמשים להצפנה מקצה לקצה של דוחות מיקומים. ה-Finder אף פעם לא חושף אותו לקצה העורפי.
מפתח שחזור: מוגדר כ-
SHA256(ephemeral identity key || 0x01)
, עם חיתוך ל-8 הבייטים הראשונים. המפתח מאוחסן בקצה העורפי, והחיפוש יכול להשתמש בו כדי לשחזר את ה-EIK, בתנאי שהמשתמש הביע הסכמה בלחיצה על לחצן במכשיר.מפתח צלצול: מוגדר כ-
SHA256(ephemeral identity key || 0x02)
, נחתך ל-8 הבייטים הראשונים. המפתח מאוחסן בקצה העורפי והוא יכול להשתמש בו רק כדי להתקשר למכשיר.מפתח להגנה מפני מעקב לא רצוי: מוגדר בתור
SHA256(ephemeral identity key || 0x03)
, נקטע ל-8 הבייטים הראשונים. המפתח מאוחסן בקצה העורפי, והחיפוש יכול להשתמש בו רק כדי להפעיל את מצב ההגנה מפני מעקב לא רצוי.
תפעול
הפורמט של הנתונים שנכתבים למאפיין מפורט בטבלאות 2 עד 5. כל אחת מהפעולות מתוארות בפירוט בהמשך הקטע.
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | מזהה נתונים |
|
1 | uint8 | אורך הנתונים | משתנה |
2 עד 9 | מערך בייטים | מפתח אימות חד-פעמי | 8 הבייטים הראשונים של HMAC-SHA256(account key, protocol major version number || the last nonce
read from the characteristic || data ID || data length || additional data) |
10 - var | מערך בייטים | נתונים נוספים |
|
טבלה 2: בקשה להקצאת משׂואות רשת (beacon)).
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | מזהה נתונים | 0x04: קריאה של מפתח זהות זמני עם הסכמת המשתמש |
1 | uint8 | אורך הנתונים | 0x08 |
2 עד 9 | מערך בייטים | מפתח אימות חד-פעמי | 8 הבייטים הראשונים של HMAC-SHA256(recovery key, protocol major version number || the last nonce
read from the characteristic || data ID || data length) |
טבלה 3: בקשה לשחזור מפתח הקצאה של משואה.
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | מזהה נתונים |
|
1 | uint8 | אורך הנתונים | משתנה |
2 עד 9 | מערך בייטים | מפתח אימות חד-פעמי | 8 הבייטים הראשונים של HMAC-SHA256(ring key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data) |
10 - var | מערך בייטים | נתונים נוספים |
|
טבלה 4: בקשת צלצול.
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | מזהה נתונים |
|
1 | uint8 | אורך הנתונים | משתנה |
2 עד 9 | מערך בייטים | מפתח אימות חד-פעמי | 8 הבייטים הראשונים של HMAC-SHA256(unwanted tracking protection key, protocol major version number
|| the last nonce read from the characteristic || data ID || data length ||
additional data) |
10 – וריאציות | מערך בייטים | נתונים נוספים |
|
טבלה 5: בקשת הגנה לא רצויה על המעקב.
כתיבת נתונים מוצלחת מפעילה התראות כפי שמפורט בטבלה 6.
צריך לשלוח התראות עם מזהה נתונים שאינו 0x05: שינוי מצב הצלצול לפני השלמת טרנזקציית הכתיבה שמפעילה את ההתראה, כלומר לפני שליחת ה-PDU של התשובה לבקשת הכתיבה.
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | מזהה נתונים |
|
1 | uint8 | אורך הנתונים | משתנה |
2 עד 9 | מערך בייטים | אימות | פירוט לפי פעולה |
10 – וריאציות | מערך בייטים | נתונים נוספים |
|
טבלה 6: התגובה של שירות ה-Beacon.
בטבלה 7 מפורטים קודי השגיאה האפשריים של GATT שהפעולות יכולות להחזיר.
קוד | תיאור | הערות |
---|---|---|
0x80 | לא מאומת | מוחזר בתגובה לבקשת כתיבה כשהאימות נכשל (כולל מקרה שבו נעשה שימוש בצפנים חד-פעמיים ישנים). |
0x81 | ערך לא חוקי | הערך הזה מוחזר אם צוין ערך לא חוקי או אם מספר הבייטים בנתונים שהתקבלו לא צפוי. |
0x82 | אין הסכמה מהמשתמש | התגובה מוחזרת בתגובה לבקשת כתיבה עם מזהה הנתונים 0x04: קריאת מפתח זהות זמני בהסכמת המשתמש כשהמכשיר לא נמצא במצב התאמה. |
טבלה 7: קודי שגיאה של GATT.
קריאת הפרמטר של האיתות
המכשיר המחפש יכול לשלוח לשרת שאילתות לגבי הפרמטרים של ה-beacon על ידי ביצוע פעולת כתיבה למאפיין, שמכילה בקשה מטבלה 2 עם מזהה הנתונים 0x00. הספק מוודא שמפתח האימות החד-פעמי שסופק תואם לאחד ממפתחות החשבון ששמורים במכשיר.
אם האימות ייכשל, הספק יחזיר שגיאה לא מאומתת.
אם הפעולה בוצעה בהצלחה, הספק שולח הודעה עם תגובה מטבלה 6 עם מזהה הנתונים 0x00. הספק בונה את פלח הנתונים באופן הבא:
אוקטט | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | הספק המכויל | ההספק המכוונן כפי שהוא התקבל ב-0m (ערך בטווח [-100, 20]). מיוצג כמספר שלם עם סימן, ברזולוציה של 1dBm. |
1 - 4 | uint32 | ערך השעון | ערך השעון הנוכחי בשניות (קצה גדול). |
5 | uint8 | בחירת עקומה | העקום האליפטי שמשמש להצפנה:
|
6 | uint8 | רכיבים | מספר הרכיבים שאפשר להשמיע צלצול:
|
7 | uint8 | יכולות צלצול | האפשרויות הנתמכות הן:
|
8-15 | מערך בייטים | מרווח | מילוי באפסים להצפנת AES. |
הנתונים צריכים להיות מוצפנים ב-AES-ECB-128 באמצעות מפתח החשבון שמשמש לאימות הבקשה.
מקטע האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data after
encryption || 0x01)
.
קריאת מצב ההקצאה של האיתות
המחפש יכול לשלוח שאילתה לספק לגבי מצב ההקצאה של האיתות על ידי ביצוע פעולת כתיבה למאפיין שמורכב מבקשה מטבלה 2 עם מזהה נתונים 0x01. הספק מוודא שמפתח האימות החד-פעמי שסופק תואם לאחד ממפתחות החשבון שמאוחסנים במכשיר.
אם האימות ייכשל, הספק יחזיר שגיאה לא מאומתת.
אם הפעולה בוצעה בהצלחה, הספק שולח הודעה עם תגובה מטבלה 6 עם מזהה הנתונים 0x01. הספק בונה את פלח הנתונים באופן הבא:
אוקטט | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | מצב ההקצאה | מסכת ביט עם הערכים הבאים:
|
1 - 20 או 32 | מערך בייטים | המזהה הזמני הנוכחי | 20 או 32 בייטים (בהתאם לשיטת ההצפנה שבה נעשה שימוש) שמציינים את המזהה הזמני הנוכחי שמוצג על ידי ה-beacon, אם הוא מוגדר למכשיר. |
מקטע האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01)
.
הגדרת מפתח זהות זמני
כדי להקצות ספק שלא הוקצה בתור משואת FMDN, או כדי לשנות את מפתח הזהות הזמני של ספק שכבר הוקצה, ה-Seeker מבצע פעולת כתיבה למאפיין שמכיל בקשה מטבלה 2 עם מזהה הנתונים 0x02. הספק מאמת את הפרטים הבאים:
- מפתח האימות החד-פעמי שסופק תואם למפתח החשבון שמוגדר כבעלים.
- אם סופק גיבוב של מפתח זהות חולף, מפתח הזהות החולף המגובב תואם למפתח הזהות החולף הנוכחי.
- אם לא סופק גיבוב של מפתח זהות זמני, צריך לוודא שהספק כבר לא הוקצה כמגדלור FMDN.
אם האימות נכשל, הספק מחזיר שגיאה לא מאומתת.
אם הפעולה מסתיימת בהצלחה, מפתח הזהות הזמני מתאושש באמצעות פענוח AES-ECB-128 באמצעות מפתח החשבון התואם. המפתח צריך להישמר במכשיר, ומאותו רגע הספק צריך להתחיל לפרסם מסגרות FMDN. מפתח הזהות הזמני החדש נכנס לתוקף מיד אחרי סיום החיבור ל-BLE. הספק שולח התראה בתשובה מטבלה 6 עם מזהה נתונים 0x02.
מקטע האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || 0x01)
.
ניקוי מפתח הזהות הזמני
כדי לבטל את ההקצאה של החלק של ה-beacon מהספק, המכשיר המחפש מבצע פעולת כתיבה למאפיין, שמכילה בקשה מטבלה 2 עם מזהה הנתונים 0x03. הספק מאמת את הפרטים הבאים:
- מפתח האימות החד-פעמי שסופק תואם למפתח החשבון שמוגדר כבעלים.
- מפתח הזהות הזמני המגובב תואם למפתח הזהות הזמני הנוכחי.
אם הספק לא מוקצה כמשׂואת רשת (beacon) FMDN או שהאימות נכשל, מוחזר שגיאה לא מאומתת.
אם הפעולה תתבצע בהצלחה, הספק ישכח את המפתח ויפסיק לפרסם מסגרות FMDN.
הספק שולח הודעה עם תגובה מטבלה 6 עם מזהה הנתונים 0x03.
מקטע האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || 0x01)
.
קריאת מפתח הזהויות הזמני בהסכמת המשתמש
האפשרות הזו זמינה רק לשחזור מפתח שאבד, כי המפתח מאוחסן רק באופן מקומי על ידי המחפש. לכן, היכולת הזו זמינה רק כשהמכשיר נמצא במצב התאמה או למשך זמן מוגבל אחרי שלחצתם על לחצן פיזי במכשיר (הלחיצה על הלחצן נחשבת להסכמה של המשתמש).
כדי לשחזר את מפתח הטקסט ללא הצפנה, המשתמש המבקש צריך לאחסן את מפתח השחזור בקצה העורפי, אבל הוא לא מאחסן את ה-EIK עצמו.
כדי לקרוא את ה-EIK, ה-Seeker מבצע פעולת כתיבה למאפיין, שמכילה בקשה מטבלה 3 עם מזהה הנתונים 0x04. הספק מוודא:
- מפתח השחזור המגובב תואם למפתח השחזור הצפוי.
- המכשיר נמצא במצב שחזור EIK.
אם האימות ייכשל, הספק יחזיר שגיאה לא מאומתת.
אם המכשיר לא נמצא במצב התאמה, הספק מחזיר הודעת שגיאה מסוג No User Consent.
אם הפעולה מצליחה, הספק יודיע עם תשובה מטבלה 6 עם מזהה הנתונים 0x04.
מקטע האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256(recovery key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01)
.
הפעלת צלצול
המכשיר המחפש יכול לבקש מהספק להשמיע צליל על ידי ביצוע פעולת כתיבה למאפיין, שמכילה בקשה מטבלה 4 עם מזהה הנתונים 0x05. הספק יוצר את מקטע הנתונים באופן הבא:
אוקטט | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | הפעלת צלצול | מסכת ביט עם הערכים הבאים:
|
2-1 | uint16 | חסימה זמנית | זמן הקצוב לתפוגה בעשישיות השנייה. הערך לא יכול להיות אפס ולא יכול להיות יותר מ-10 דקות. הספק משתמש בערך הזה כדי לקבוע כמה זמן הטלפון יצלול לפני שהוא יעבור למצב 'שקט'. הזמן הקצוב לתפוגה מבטל את זה שכבר קיים אם חלק כלשהו במכשיר כבר מצלצל. אם ring operation מוגדר כ-0x00, המערכת מתעלמת מזמן הקצאת הזמן הקצוב. |
3 | uint8 | עוצמת הקול |
|
לאחר קבלת הבקשה, הספק מאמת את הפרטים הבאים:
- מפתח האימות החד-פעמי שסופק תואם למפתח הצלצול.
- המצב המבוקש תואם לרכיבים שיכולים לצלצל.
אם הספק לא הוקצה כמגדלור FMDN או שהאימות נכשל, הוא מחזיר שגיאה ללא אימות. עם זאת, אם הספק הפעיל אמצעי הגנה לא רצויים מסוג מעקב, ובבקשת ההגנה הלא רצויה בעקבות מעקב הופעל הסימון לאימות הצלצול של הדילוג, הספק צריך לדלג על הבדיקה הזו. עדיין צפוי שהנתונים לאימות יסופקו על ידי מבקש החיפוש, אבל אפשר להגדיר אותם לערך שרירותי.
כשהצלצול מתחיל או מסתיים, נשלחת התראה כפי שמצוין בטבלה 6 עם מזהה הנתונים 0x05. תוכן ההודעה מוגדר באופן הבא:
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | מצב צלצול |
|
1 | uint8 | רכיבי הצלצול | מסכת ביט של הרכיבים שמצלצלים באופן פעיל, כפי שהם מוגדרים בבקשה. |
2 עד 3 | uint16 | חסימה זמנית | הזמן שנותר לצלצול, בדצי-שניות. אם המכשיר הפסיק לצלצל, צריך להחזיר את הערך 0x0000. |
מקטע האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256(ring key, protocol major version number || the nonce used to
initiate the ringing command || data ID || data length || additional data ||
0x01)
.
אם המכשיר כבר נמצא במצב הצלצול המבוקש כשמתקבלת בקשה לצלצל או להפסיק לצלצל, הספק צריך לשלוח התראה עם מצב צלצול או 0x00: Started או 0x04: Stopped (בקשת GATT), בהתאמה. הבקשה הזו מבטלת את הפרמטרים של המצב הקיים כדי שאפשר יהיה להאריך את משך הצלצול.
אם לטלפון של הספק יש לחצן פיזי (או שהחיישן למגע מופעל), לחיצה על הלחצן הזה בזמן שהצלצול פעיל אמורה להפסיק את הפונקציה.
מהו מצב הצלצול של איתות החיישן
כדי לקבל את מצב הצלצול של האיתות, ה-Finder מבצע פעולת כתיבה למאפיין, שכוללת בקשה מטבלה 4 עם מזהה הנתונים 0x06. הספק מוודא שמפתח האימות החד-פעמי שסופק תואם למפתח הטבעת.
אם הספק לא מוקצה כמשׂואת רשת (beacon) FMDN או שהאימות נכשל, הספק יחזיר שגיאה לא מאומתת.
אם הפעולה מצליחה, הספק יודיע עם תשובה מטבלה 6 עם מזהה הנתונים 0x06. הספק בונה את פלח הנתונים באופן הבא:
אוקטט | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | רכיבי צלצול | הרכיבים מצלצלים באופן פעיל, כפי שמוגדר בבקשת הצלצול. |
1 - 2 | uint16 | חסימה זמנית | הזמן שנותר לצלצול, בדצי-שניות. הערה: אם המכשיר לא מצלצל, צריך להחזיר את הערך 0x0000. |
מקטע האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256 (ring key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01)
.
מצב הגנה מפני מעקב לא רצוי
מצב ההגנה מפני מעקב לא רצוי נועד לאפשר לכל לקוח לזהות מכשירים שמנצלים לרעה את השירות בלי תקשורת עם השרת. כברירת מחדל, הספק צריך לבצע רוטציה של כל המזהים כפי שמתואר בקטע רוטציית מזהים. שירות 'איפה המכשיר שלי' יכול להעביר בקשה להפעלת מצב הגנה מפני מעקב לא רצוי דרך הרשת של 'איפה המכשיר שלי'. כך השירות גורם לספק להשתמש באופן זמני בכתובת MAC קבועה, שמאפשרת ללקוחות לזהות את המכשיר ולהזהיר את המשתמש על מעקב לא רצוי אפשרי.
כדי להפעיל או להשבית את מצב ההגנה מפני מעקב לא רצוי של ה-beacon, ה-Seeker מבצע פעולת כתיבה למאפיין, שמכילה בקשה מטבלה 5 עם מזהה הנתונים 0x07 או 0x08 בהתאמה.
כשמפעילים מצב של הגנה לא רצויה על המעקב
הספק יוצר את מקטע הנתונים באופן הבא:
אוקטט | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | דגלים של בקרה |
הדגלים בתוקף רק עד להשבתת מצב ההגנה מפני מעקב לא רצוי. |
הספק מאמת שמפתח האימות החד-פעמי שסופק תואם למפתח ההגנה הלא רצוי למעקב. אם הספק לא מוקצה כחיישן FMDN או שהאימות נכשל, מוחזר שגיאה לא מאומתת.
כשמפעילים את מצב ההגנה מפני מעקב לא רצוי, התדירות של רוטציית הכתובת הפרטית של ה-MAC אמורה לרדת לאחת ל-24 שעות. המזהה הזמני שמופיע בפרסום אמור להסתובב כרגיל. צריך להגדיר את סוג המסגרת לערך 0x41. המצב משתקף גם בקטע דגלים מגובבים.
מתי משביתים את מצב ההגנה מפני מעקב לא רצוי
הספק מוודא את הפרטים הבאים:
- מפתח האימות החד-פעמי שסופק תואם למפתח להגנה מפני מעקב לא רצוי.
- מפתח הזהות הזמני המגובב תואם למפתח הזהות הזמני הנוכחי.
אם הספק לא הוקצה כמגדלור FMDN או שהאימות נכשל, הספק מחזיר שגיאה ללא אימות.
כשמצב ההגנה מפני מעקב לא רצוי יושבת, ה-beacon אמור להתחיל שוב לסובב את כתובת ה-MAC בקצב רגיל, בסנכרון עם הסיבוב של המזהה הזמני. צריך להגדיר את סוג המסגרת בחזרה ל-0x40. המצב משתקף גם בקטע דגלים מגובבים.
אם הפעולה מצליחה, הספק יודיע עם תשובה מטבלה 6 עם מזהה הנתונים 0x07 או 0x08.
מקטע האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256(unwanted tracking protection key, protocol major version number ||
the last nonce read from the characteristic || data ID || data length ||
0x01)
.
מסגרות מתפרסמות
אחרי ההקצאה, הספק אמור לפרסם מסגרות FMDN לפחות פעם ב-2 שניות. אם מתבצע פרסום של פריימים בהתאמה מהירה, הספק צריך לשלב את פריימים של FMDN בפרסומות הרגילות בהתאמה מהירה. לדוגמה, כל שתי שניות, הספק צריך להציג שבע מודעות Fast Pair ומודעה אחת מסוג FMDN.
המסגרת של FMDN מכילה מפתח ציבורי שמשמש להצפנת דוחות המיקום של כל לקוח תומך שתורם לרשת ה-crowdsourcing. יש שני סוגים של מפתחות עקומות אליפטיים: מפתח של 160 ביט שמתאים למסגרות BLE 4 מדור קודם, או מפתח של 256 ביט שדורש BLE 5 עם יכולות פרסום מורחבות. ההטמעה של הספק קובעת באיזו עקומה המערכת תשתמש.
המבנה של מסגרת FMDN הוא הבא.
Octet | ערך | תיאור |
---|---|---|
0 | 0x02 | אורך |
1 | 0x01 | ערך של סוג הנתונים של סימונים |
2 | 0x06 | נתוני דגלים |
3 | 0x18 או 0x19 | אורך |
4 | 0x16 | ערך סוג הנתונים של נתוני השירות |
5 | 0xAA | UUID של שירות 16 ביט |
6 | 0xFE | ... |
7 | 0x40 או 0x41 | סוג מסגרת FMDN עם אינדיקציה למצב של הגנה מפני מעקב לא רצוי |
8..27 | מזהה זמני באורך 20 בייטים | |
28 | דגלים מגובבים |
טבלה 8: מסגרת FMDN שתומכת בעקומה של 160 ביט.
בטבלה 9 מוצגים הערכים וההיסטים בבייט של עקומה באורך 256 ביט.
Octet | ערך | תיאור |
---|---|---|
0 | 0x02 | אורך |
1 | 0x01 | ערך של סוג הנתונים של סימונים |
2 | 0x06 | נתוני דגלים |
3 | 0x24 או 0x25 | אורך |
4 | 0x16 | ערך סוג הנתונים של נתוני השירות |
5 | 0xAA | UUID של שירות 16 ביט |
6 | 0xFE | ... |
7 | 0x40 או 0x41 | סוג מסגרת FMDN עם אינדיקציה לא רצויה למצב ההגנה על המעקב |
8..39 | מזהה זמני באורך 32 בייטים | |
40 | דגלים מגובבים |
טבלה 9: מסגרת FMDN שתומכת בעקומה של 256 ביט.
חישוב של מזהה זמני (EID)
מפתח אקראי נוצר על ידי הצפנה של מבנה הנתונים הבא באמצעות מפתח הזהות הזמני באמצעות AES-ECB-256:
Octet | שדה | תיאור |
---|---|---|
0 עד 10 | מרווח | ערך = 0xFF |
11 | K | מעריך תקופת סבב |
12 עד 15 | TS[0]...TS[3] | מונה הזמן של ה-beacon, בפורמט big-endian של 32 ביט. הביטים הנמוכים ביותר של K נמחקים. |
16 - 26 | מרווח | ערך = 0x00 |
27 | K | מעריך של תקופת הרוטציה |
28 - 31 | TS[0]…TS[3] | מונה הזמן של ה-beacon, בפורמט big-endian של 32 ביט. הביטים הנמוכים ביותר של K נמחקים. |
טבלה 10: בניית מספר פסאודו-אקראי.
התוצאה של החישוב הזה היא מספר באורך 256 ביט, שמצוין כ-r'
.
בשאר החישוב, משתמשים ב-SECP160R1
או ב-SECP256R1
לפעולות קריפטוגרפיות עם עקומים אליפטיים. להגדרות של העקומות, אפשר לעיין בקטע
SEC 2: Recommended Elliptic Curve Domain Parameters, שבו מוגדרים Fp
, n
ו-G
שמצוינים בהמשך.
עכשיו החיזוי של r'
הוא לשדה הסופי Fp
באמצעות החישוב של r = r' mod n
.
לבסוף, מחשבים את R = r * G
, שהיא נקודה בעקומה שמייצגת את המפתח הציבורי שנמצא בשימוש. ה-beacon מפרסם את הערך Rx
, שהוא הקואורדינטה x
של R
, בתור המזהה הזמני שלו.
דגלים מגובבים (hashed)
שדה הדגלים המגובבים מחושב באופן הבא (הביטים מפנים מהמשמעותי ביותר למשמעותי ביותר):
- ביטים 0-4: שמורים (מוגדרים לאפסים).
- הביטים 5-6 מציינים את רמת הטעינה של הסוללה במכשיר באופן הבא:
- 00: אין תמיכה באינדיקציה של רמת הטעינה של הסוללה
- 01: רמת טעינה רגילה של הסוללה
- 10: רמת סוללה חלשה
- 11: רמת הטעינה של הסוללה נמוכה מאוד (יש להחליף את הסוללה בקרוב)
- הערך של Bit 7 מוגדר ל-1 אם איתות Bluetooth נמצא במצב הגנה לא רצויה מפני מעקב. אחרת, הערך הוא 0.
כדי להפיק את הערך הסופי של הבייט הזה, הוא עובר ב-xor עם הבייט הכי פחות משמעותי של SHA256(r)
.
שימו לב ש-r צריך להיות מיושר לגודל של העקומה. מוסיפים אפסים כסיביות המשמעותיות ביותר אם הייצוג קצר מ-160 או מ-256 סיביות, או שצריך לחתוך את הסיביות המשמעותיות ביותר אם הייצוג ארוך מ-160 או מ-256 סיביות.
אם איתות Bluetooth לא תומך בהגדרת רמת הטעינה של הסוללה והוא לא נמצא במצב הגנה לא רצוי למעקב, מותר להשמיט את הבייט הזה לגמרי מהפרסום.
הצפנה באמצעות EID
כדי להצפין הודעה m
, משתמש (שקרא את Rx
מה-חיישן) מבצע את הפעולות הבאות:
- בוחרים מספר אקראי
s
ב-Fp
, כפי שמוגדר בקטע חישוב מזהה EID. - Compute
S = s * G
. - מחשבים את
R = (Rx, Ry)
על ידי החלפה במשוואת העקומה ובחירת ערךRy
שרירותי מתוך התוצאות האפשריות. - מחשבים את מפתח AES ב-256 ביט
k = HKDF-SHA256((s * R)x)
כאשר(s * R)x
הוא הקואורדינטהx
של תוצאת ההכפלה של העקומה. לא צוין salt. - נניח ש-
URx
ו-LRx
הם 80 הביטים העליונים והתחתונים שלRx
, בהתאמה, בפורמט big-endian. באופן דומה, צריך להגדיר אתUSx
ואתLSx
עבורS
. - Compute
nonce = LRx || LSx
. - Compute
(m’, tag) = AES-EAX-256-ENC(k, nonce, m)
. - שולחים את
(URx, Sx, m’, tag)
לבעלים, כנראה באמצעות שירות מרוחק לא מהימן.
פענוח של ערכים שהוצפנו באמצעות EID
הלקוח של הבעלים, שבבעלותו ה-EIK ומעריך תקופת הרוטציה, מפענח את ההודעה באופן הבא:
- בהינתן
URx
, מקבלים את ערך המונה של זמן הפנס שממנו מבוססURx
. כדי לעשות זאת, הלקוח של הבעלים יכול לחשב את ערכיRx
של ערכי מונה הזמן של איתות החיישן עבור העבר האחרון והעתיד הקרוב. - בהתאם לערך של מונה הזמן של האיתות שעליו
URx
מבוסס, מחשבים את הערך הצפוי שלr
כפי שמוגדר בסעיף חישוב EID. - מחשבים את
R = r * G
ומאמתים שהוא תואם לערך שלURx
שסופק על ידי הכלי למעקב אחר מודעות. - מחשבים את
S = (Sx, Sy)
על ידי החלפה במשוואת העקומה ובחירת ערךSy
שרירותי מתוך התוצאות האפשריות. - מחשבים את
k = HKDF-SHA256((r * S)x)
כאשר(r * S)x
הוא הקואורדינטהx
של תוצאת ההכפלה של העקומה. - חישוב של
nonce = LRx || LSx
. - Compute
m = AES-EAX-256-DEC(k, nonce, m’, tag)
.
רוטציית מזהי משתמשים
צריך להשתמש בכתובת BLE שניתן לפתור (RPA) או כתובת BLE שלא ניתן לפתור (NRPA) כדי לפרסם מסגרות FMDN. RPA נדרש במכשירי LE Audio (LEA) ומומלץ במכשירים אחרים, מלבד תגי מיקום שלא משתמשים בחיבור.
מודעת Fast Pair, מודעת FMDN והכתובות התואמות של BLE צריכות להופיע באותו זמן. הסיבוב אמור להתרחש כל 1,024 שניות בממוצע. הנקודה המדויקת שבה ה-beacon מתחיל לפרסם את המזהה החדש חייבת להיות אקראית בתוך החלון.
הגישה המומלצת לבחירה אקראית של זמן ההחלפה היא להגדיר אותו לזמן ההחלפה הצפוי הבא (אם לא הוחל אקראיזציה) בתוספת גורם זמן אקראי חיובי בטווח של 1 עד 204 שניות.
כשהמכשיר נמצא במצב של הגנה מפני מעקב לא רצוי, כתובת ה-BLE של המודעה ל-FMDN צריכה להיות קבועה, אבל ה-RPA של המודעה ל-FP שלא ניתן לזהות (כמו התאמה מהירה) צריך להמשיך להסתובב. מותר להשתמש בכתובות שונות לפרוטוקולים השונים.
התאוששות מאובדן חשמל
פתרון המזהה הזמני קשור מאוד לערך השעון שלו בזמן הפרסום, ולכן חשוב שהספק יוכל לשחזר את ערך השעון שלו אם יש הפסקת חשמל. מומלץ שהספק יכתוב את ערך השעון הנוכחי שלו לזיכרון לא נדיף לפחות פעם ביום, ובזמן האתחול הספק יבדוק את ה-NVM כדי לראות אם יש ערך שאפשר לאתחל ממנו. פותרי המזהה הזמני יטמיעו פתרון בחלון זמן מספיק כדי לאפשר גם סטייה סבירה של השעון וגם שחזור מסוג זה של אובדן חשמל.
הספקים עדיין צריכים לעשות כל מאמץ כדי למזער את התנודות בשעון, כי חלון הזמן לפתרון הבעיה מוגבל. צריך להטמיע לפחות שיטה אחת נוספת לסנכרון השעון (פרסום פריימים של Fast Pair שלא ניתן לגלות או הטמעה של message stream).
הנחיות להטמעת Fast Pair
בקטע הזה מתוארים היבטים מיוחדים של הטמעת ההתאמה המהירה בספקים שתומכים ב-FMDN.
הנחיות ספציפיות לתגי איתור
- אם הספק מותאם, אבל לא בוצעה הקצאה של FMDN תוך 5 דקות (או אם בוצע עדכון OTA בזמן שהמכשיר מותאם אבל לא בוצעה הקצאה של FMDN), הספק צריך לחזור להגדרות המקוריות ולמחוק את מפתחות החשבון השמורים.
- אחרי שמתאימים את הספק, כתובת ה-MAC שלו לא אמורה להשתנות עד להקצאת FMDN או עד שיחלפו 5 דקות.
- אם מפתח הזהות הזמני הוסר מהמכשיר, המכשיר צריך לבצע איפוס להגדרות המקוריות ולנקות גם את מפתחות החשבון המאוחסנים.
- הספק צריך לדחות ניסיונות התאמה רגילים של Bluetooth ולקבל רק את ההתאמה המהירה.
- הספק צריך לכלול מנגנון שמאפשר למשתמשים להפסיק את הפרסום באופן זמני, בלי לאפס את המכשיר להגדרות המקוריות (לדוגמה, לחיצה על שילוב של לחצנים).
- אחרי הפסקת החשמל, המכשיר אמור לפרסם פריימים של התאמה מהירה שלא ניתנים לזיהוי עד להפעלה הבאה של קריאת הפרמטרים של ה-beacon. כך, המכשיר המחפש יכול לזהות את המכשיר ולסנכרן את השעון גם אם הייתה סטייה משמעותית בשעון.
- כשמפרסמים פריימים של התאמה מהירה שלא ניתן לגלות, לא צריך להפעיל את ההנחיות בממשק המשתמש.
- לא צריך לפרסם מסגרות של התאמה מהירה גלויה בזמן שהספק מוקצה ל-FMDN.
- הספק לא אמור לחשוף פרטים מזהים באופן לא מאומת (למשל שמות או מזהים).
הנחיות קלאסיות ספציפיות למכשיר Bluetooth
בקטע הזה מתוארים היבטים מיוחדים של מכשירי Bluetooth רגילים שתומכים ב-FMDN.
הקצאת FMDN למכשירים שכבר מותאמים
הספק לא תמיד מוגדר ל-FMDN במהלך ההתאמה עם ה-Seeker, אלא זמן מה לאחר מכן. במקרה כזה, יכול להיות שלספק אין כתובת BLE MAC עדכנית שנדרשת ליצירת חיבור GATT. הספק חייב לתמוך לפחות באחת מהדרכים הבאות כדי שהמכשיר המחפש יוכל לקבל את כתובת ה-BLE שלו כשהוא כבר מותאם:
- הספק יכול לפרסם מדי פעם את נתוני החשבון בהתאמה מהירה שמאפשרים למחפש למצוא את כתובת BLE שלו באמצעות סריקת BLE.
הגישה הזו מתאימה לספקים שלא מטמיעים את מקור הנתונים של ההודעות. - הספק יכול לספק את הנתונים האלה דרך הזרם של ההודעות של התאמה מהירה בחיבור Bluetooth רגיל.
הגישה הזו מתאימה לספקים שלא מפרסמים פריימים בהתאמה מהירה כשהם מחוברים ל-Seeker באמצעות Bluetooth.
תמיכה בשתי הגישות מגדילה את הסיכויים שהמשתמש יוכל להקצות את המכשיר ל-FMDN.
שידור הודעות בהתאמה מהירה
הספק יכול להטמיע מקור נתונים של הודעות Fast Pair ולהשתמש בו כדי להודיע למכשיר המחפש על פרטי המכשיר. ההטמעה של שידור ההודעות מאפשרת תכונות מסוימות, כפי שמתואר בקטע הזה.
הספק צריך לשלוח הודעות מידע על המכשיר בכל פעם שיוצרים ערוץ RFCOMM.
גרסת הקושחה (קוד פרטי המכשיר 0x09) ויכולת המעקב
כשעדכון קושחת מוסיף תמיכה ב-FMDN לספק, ספקית חיפוש מחוברת יכולה להודיע על כך למשתמש ולהציע להקצות את התכונה. אחרת, המשתמש צריך לנווט לרשימה של מכשירי ה-Bluetooth באופן ידני כדי להתחיל את הקצאת ה-FMDN.
כדי לאפשר זאת, הספק צריך להשתמש במאפיין גרסת הקושחה (קוד 0x09) כדי לדווח על ערך מחרוזת שמייצג את גרסת הקושחה. בנוסף, הספק צריך לתמוך בפרוטוקול שמאפשר למחפש לדעת על שינויים ביכולות בגלל עדכוני קושחה.
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | אירוע של פרטי המכשיר | 0x03 |
1 | uint8 | גרסת הקושחה | 0x09 |
2 עד 3 | uint16 | אורך נתונים נוסף | משתנה |
ו | מערך בייטים | מחרוזת גרסה | משתנה |
טבלה 11: אירוע של פרטי המכשיר: גרסת הקושחה עודכנה.
כשמתקבלת בקשה לעדכון יכולת (0x0601), אם הספק הפעיל תמיכה במעקב FMDN, הוא צריך להגיב כמו שמוצג בטבלה 12.
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | אירוע בסנכרון של יכולת המכשיר | 0x06 |
1 | uint8 | מעקב FMDN | 0x03 |
2 - 3 | uint16 | אורך נתונים נוסף | 0x0007 |
4 | uint8 | מצב ההקצאה של FMDN | 0x00 אם לא מוקצה לו ניהול הקצאות; 0x01 אם הוקצה באמצעות חשבון כלשהו |
5 - 10 | מערך בייטים | כתובת BLE MAC הנוכחית של המכשיר | משתנה |
טבלה 12: אירוע סנכרון של יכולות המכשיר: נוספה יכולת מעקב.
המזהה הזמני הנוכחי (קוד פרטי המכשיר 0x0B)
הספק יכול להשתמש במזהה הזמני הנוכחי (קוד 0x0B) כדי לדווח על ה-EID וערך השעון הנוכחיים כשהספק מוקצה ל-FMDN, ולסנכרן את המחפש במקרה של סחף בשעון (לדוגמה, בגלל סוללה מרוקנת). אחרת, ה-Seeker יוצר חיבור יקר פחות ואמין פחות למטרה הזו.
Octet | סוג הנתונים | תיאור | ערך |
---|---|---|---|
0 | uint8 | אירוע של פרטי המכשיר | 0x03 |
1 | uint8 | המזהה הזמני הנוכחי | 0x0B |
2 - 3 | uint16 | אורך הנתונים הנוספים | 0x0018 או 0x0024 |
4 עד 7 | מערך בייטים | ערך השעון | דוגמה: 0x13F9EA80 |
8-19 או 31 | מערך בייטים | מזהה EID נוכחי | דוגמה: 0x1122334455667788990011223344556677889900 |
טבלה 13: אירוע של פרטי המכשיר: סנכרון השעון.
איפוס להגדרות המקוריות
במכשירים שתומכים באיפוס להגדרות המקוריות: אם מתבצע איפוס להגדרות המקוריות, הספק צריך להפסיק את שליחת האותות ולמחוק את מפתח הזהות הזמני ואת כל מפתחות החשבון השמורים, כולל מפתח החשבון של הבעלים.
אחרי איפוס להגדרות המקוריות (ידני או פרוגרמטי), הספק לא צריך להתחיל לפרסם את התכונה 'התאמה מהירה' מיד, כדי למנוע את תחילת תהליך ההתאמה מיד אחרי שהמשתמש מחק את המכשיר.
מניעת מעקב לא רצויה
מכשירי FMDN שאושרו חייבים לעמוד גם בדרישות בגרסה להטמעה של המפרט בפלטפורמות שונות ל זיהוי מכשירי מעקב מיקום לא רצויים (DULT).
הנחיות רלוונטיות ספציפיות ל-FMDN כדי לעמוד בדרישות של מפרט DULT:
- כל מכשיר שתואם ל-FMDN צריך להיות רשום במסוף המכשיר בקרבת מקום, ולהפעיל את היכולת 'איפה המכשיר שלי'.
- המכשיר חייב להטמיע את המאפיין והשירות Accessory Non-Owner שמוגדרים בגרסה של ההטמעה של מפרט DULT, כולל הפעולות של Accessory Information וNon-owner controls.
- במהלך תקופת התאימות לאחור, כפי שמוגדרת במפרט DULT, לא יהיו שינויים בפריים המפורסם כפי שמוגדר במסמך הזה.
- 'מצב הגנה מפני מעקב לא רצוי' שמוגדר במסמך הזה מתואם ל'מצב נפרד' שמוגדר במפרט DULT.
- הנחיות להטמעת קוד הפקודה Accessory Information:
- הפונקציה Get_Product_Data אמורה להחזיר את מזהה המודל שסופק על ידי המסוף, עם מילוי באפסים כדי לעמוד בדרישת האורך של 8 בייטים. לדוגמה, מזהה הדגם 0xFFFFFF מוחזר בתור 0x0000000000FFFFFF.
- הערכים של Get_Manufacturer_Name ו-Get_Model_Name צריכים להתאים לערכי המסוף.
- הפונקציה Get_Accessory_Category יכולה להחזיר את הערך הכללי 'מכשיר למעקב מיקום' אם אין קטגוריה אחרת שמתאימה יותר לסוג המכשיר.
- ב-Get_Accessory_Capabilities צריך לציין את התמיכה בצלצול וגם בחיפוש מזהה BLE.
- Get_Network_ID צריכה להחזיר את המזהה של Google (0x02).
- הנחיות להטמעת קוד הפעולה Get_Identifier:
- הפעולה אמורה להחזיר תשובה תקינה רק במשך 5 דקות אחרי שהמשתמש הפעיל את המצב 'זיהוי', שדורש שילוב של לחיצות על לחצנים. צריך להופיע אות חזותי או אודיו כדי להודיע למשתמש שהספק עבר למצב הזה. כדי לקבל אישור, צריך לספק ל-Google את ההוראות הספציפיות למודל להפעלת המצב הזה, לפחות 10 ימים לפני כל עדכון או שינוי בהוראות.
- התשובה מורכבת מ-10 הבייטים הראשונים של המזהה הזמני הנוכחי, ואחריהם 8 הבייטים הראשונים של
HMAC-SHA256(recovery key, the truncated current ephemeral identifier)
.
- הנחיות להטמעת מזהה ב-NFC:
- ככתובת URL, צריך להשתמש ב-
find-my.googleapis.com/lookup
. - בתור הפרמטר
e
, משתמשים באותה תשובה שמותאמת ל-Get_Identifier, עם קידוד הקסדצימלי. - בתור הפרמטר
pid
, משתמשים באותה תשובה שנוצרה עבור Get_Product_Data, עם קידוד הקסדצימלי.
- ככתובת URL, צריך להשתמש ב-
- הנחיות להטמעת קוד הפקודה Sound_Start:
- הפקודה אמורה להפעיל צלצול בכל הרכיבים הזמינים.
- צריך להשתמש בנפח המקסימלי שנתמך.
- משך הזמן המומלץ לצלצול הוא 12 שניות.
- תגי מיקום חייבים לכלול מנגנון שמאפשר למשתמשים להפסיק באופן זמני את הפרסום בלי לאפס את המכשיר להגדרות המקוריות (לדוגמה, לחיצה על שילוב של לחצנים).
- הוראות ההשבתה צריכות להיות מתועדות בכתובת URL שזמינה לכולם, ולשלוח אותן ל-Google כדרישה לקבלת אישור, לפחות 10 ימים לפני כל עדכון או שינוי בהוראות.
- כתובת ה-URL צריכה לתמוך בהתאמה לשוק המקומי. בהתאם ללקוח, השפה תסופק כפרמטר של שאילתה ("hl=iw") או באמצעות הכותרת 'accept-language' ב-HTTP.
הנחיות לפרוטוקולים שניתנים להחלפה
- יש להשתמש בפרוטוקול אחד בלבד כל פעם. מוודאים שרק רשת אחת יכולה לפעול במכשיר בו-זמנית. הדרישה הזו נדרשת כדי לוודא שאין שילוב של נתוני משתמש רגישים בין פרוטוקולים שונים.
- מומלץ לשלב במכשיר תהליך עבודה של איפוס קשיח, שמאפשר למשתמש להגדיר מחדש מכשיר עם רשת אחרת.
- תהליך העדכון של מכשיר לרשת צריך להיות ידידותי למשתמש ושוויוני בין רשתות. המשתמש צריך להיות מסוגל לבחור באיזו רשת הוא רוצה להשתמש, בלי לתת עדיפות לאחת מהן. התהליך הזה צריך לקבל אישור מצוות Google.
עדכוני קושחה
השותף צריך לנהל את התהליך וההפצה של עדכוני OTA באמצעות תהליך העבודה שלו לנייד או לאפליקציית אינטרנט.
תאימות
צריך להפעיל את שירותי המיקום ואת חיבור ה-Bluetooth לרשת 'איפה המכשיר שלי'. נדרש שירות סלולרי או חיבור לאינטרנט. הגרסה פועלת ב-Android מגרסה 9 ואילך ובמדינות מסוימות, למשתמשים שעומדים בדרישות הגיל.
יומן שינויים
גרסת FMDN | תאריך | תגובה |
---|---|---|
v1 | הגרסה הראשונית של מפרט FMDN לגישה מוקדמת. | |
v1.1 | פברואר 2023 |
|
v1.2 | אפריל 2023 |
|
v1.3 | דצמבר 2023 |
|