מפרט אביזרי הרשת של 'איפה המכשיר שלי'

v1.3

במפרט האביזרים של רשת 'איפה המכשיר שלי' (FMDN) מוגדר גישת הצפנה מקצה לקצה למעקב אחרי מכשירי Bluetooth עם צריכת אנרגיה נמוכה (BLE) שמפיצים אותות. בדף הזה מתוארת FMDN כתוספת למפרט של Fast Pair. ספקים צריכים להפעיל את התוסף הזה אם יש להם מכשירים שתואמים ל-FMDN והם רוצים להפעיל מעקב אחר המיקום של המכשירים האלה.

מפרט GATT

צריך להוסיף למאפייני השירות של Fast Pair מאפיין נוסף של מאפיינים כלליים (GATT) עם הסמנטיקה הבאה:

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

טבלה 1: מאפייני השירות של התאמה מהירה ל-FMDN.

אימות

הפעולות הנדרשות על ידי התוסף הזה מתבצעות כפעולת כתיבה, שמאובטחת באמצעות מנגנון של אתגר-תגובה. לפני ביצוע פעולה כלשהי, ה-Seeker אמור לבצע פעולת קריאה מהמאפיין בטבלה 1, וכתוצאה מכך נוצר מאגר בפורמט הבא:

אוקטט סוג הנתונים תיאור ערך
0 uint8 מספר הגרסה הראשית של הפרוטוקול 0x01
1 עד 8 מערך בייטים מספר חד-פעמי אקראי ללא משמעות משתנה

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

לאחר מכן, ה-Seeker מחשב מפתח אימות חד-פעמי שישמש לבקשת כתיבה שתתבצע בהמשך. מפתח האימות מחושב כפי שמתואר בטבלאות 2 עד 5. בהתאם לפעולה המבוקשת, מבצע החיפוש צריך להוכיח שהוא יודע לפחות אחד מהמפתחות הבאים:

תפעול

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

אוקטט סוג הנתונים תיאור ערך
0 uint8 מזהה נתונים
  • 0x00: קריאת הפרמטרים של ה-beacon
  • 0x01: קריאת מצב ההקצאה
  • 0x02: הגדרת מפתח זהות זמני
  • 0x03: מפתח זהות חד-פעמי שקוף
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 מערך בייטים נתונים נוספים
  • 0x00: לא רלוונטי
  • 0x01: לא רלוונטי
  • 0x02: 32 בייטים שהם מפתח הזהות הזמני, מוצפן ב-AES-ECB-128 באמצעות מפתח החשבון. אם לספק כבר יש מפתח זהות זמני מוגדר, שולחים גם את 8 הבייטים הראשונים של SHA256(current ephemeral identity key || the last nonce read from the characteristic).
  • 0x03: 8 הבייטים הראשונים של SHA256(ephemeral identity key || the last nonce read from the characteristic)

טבלה 2: בקשה להקצאת איתות.

אוקטט סוג הנתונים תיאור ערך
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: בקשה לשחזור מפתח הקצאה של איתות.

אוקטט סוג הנתונים תיאור ערך
0 uint8 מזהה נתונים
  • 0x05: טבעת
  • 0x06: קריאת מצב הצלצול
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 מערך בייטים נתונים נוספים
  • 0x05: 4 בייטים שמציינים את מצב הצלצול, משך הצלצול ועוצמת הצלצול.
  • 0x06: לא רלוונטי

טבלה 4: בקשה לצלצול.

אוקטט סוג הנתונים תיאור ערך
0 uint8 מזהה נתונים
  • 0x07: הפעלת מצב הגנה מפני מעקב לא רצוי
  • 0x08: השבתת מצב ההגנה מפני מעקב לא רצוי
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 - var מערך בייטים נתונים נוספים
  • 0x07: 1 ביייט של דגלים לבקרה (אופציונלי)
  • 0x08: 8 הבייטים הראשונים של SHA256(ephemeral identity key || the last nonce read from the characteristic)

טבלה 5: בקשה להגנה מפני מעקב לא רצוי.

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

יש לשלוח התראות עם מזהה נתונים שאינו 0x05: שינוי מצב של צלצול לפני השלמת עסקת הכתיבה שמפעילה את ההתראה, כלומר לפני שליחת PDU תגובה לבקשת הכתיבה.

אוקטט סוג הנתונים תיאור ערך
0 uint8 מזהה נתונים
  • 0x00: קריאת הפרמטרים של ה-beacon
  • 0x01: קריאת מצב ההקצאה
  • 0x02: הגדרת מפתח זהות זמני
  • 0x03: מפתח זהות חד-פעמי שקוף
  • 0x04: קריאה של מפתח זהות זמני עם הסכמת המשתמש
  • 0x05: שינוי בסטטוס הצלצול
  • 0x06: קריאת מצב הצלצול
  • 0x07: הפעלת מצב הגנה מפני מעקב לא רצוי
  • 0x08: השבתת מצב ההגנה מפני מעקב לא רצוי
1 uint8 אורך הנתונים משתנה
2 - 9 מערך בייטים אימות פירוט לפי פעולה
10 - var מערך בייטים נתונים נוספים
  • 0x00: 8 בייטים שמציינים את עוצמת השידור, ערך השעון, שיטת ההצפנה ויכולות הצלצול, מוצפנים ב-AES-ECB-128 באמצעות מפתח החשבון (עם מילוי באפסים)
  • 0x01: 1 ביייט שמציין את מצב ההקצאה, ואחריו המזהה הזמני הנוכחי (20 או 32 בייטים), אם רלוונטי
  • 0x04: 32 בייטים שהם מפתח הזהות הזמני, מוצפן ב-AES-ECB-128 באמצעות מפתח החשבון
  • 0x05: 4 בייטים שמציינים את המצב החדש ואת הגורם להפעלת השינוי
  • 0x06: 3 בייטים שמציינים את הרכיבים שמצלצלים באופן פעיל ואת מספר הדצי-שניות שנותרו עד שהצלצול יסתיים
  • מזהי נתונים אחרים שמשתמשים בנתונים נוספים ריקים

טבלה 6: התגובה של שירות ה-Beacon.

בטבלה 7 מפורטים קודי השגיאה האפשריים של GATT שמוחזרים על ידי הפעולות.

קוד תיאור הערות
0x80 לא מאומת הקוד מוחזר בתגובה לבקשת כתיבה כשהאימות נכשל (כולל במקרה שבו נעשה שימוש במזהה חד-פעמי ישן).
0x81 ערך לא חוקי הערך הזה מוחזר אם צוין ערך לא חוקי או אם מספר הבייטים בנתונים שהתקבלו לא צפוי.
0x82 לא התקבלה הסכמה מהמשתמש התגובה מוחזרת בתגובה לבקשת כתיבה עם מזהה הנתונים 0x04: קריאת מפתח זהות זמני בהסכמת המשתמש כשהמכשיר לא נמצא במצב התאמה.

טבלה 7: קודי שגיאה של GATT.

קריאת הפרמטר של ה-beacon

המכשיר המחפש יכול לשלוח לשרת שאילתות לגבי הפרמטרים של ה-beacon על ידי ביצוע פעולת כתיבה למאפיין, שמכילה בקשה מטבלה 2 עם מזהה הנתונים 0x00. הספק מוודא שמפתח האימות החד-פעמי שסופק תואם לאחד ממפתחות החשבון ששמורים במכשיר.

אם האימות נכשל, הספק מחזיר שגיאה לא מאומתת.

אם הפעולה בוצעה בהצלחה, הספק שולח הודעה עם תגובה מטבלה 6 עם מזהה הנתונים 0x00. הספק יוצר את מקטע הנתונים באופן הבא:

אוקטט סוג הנתונים תיאור ערך
0 uint8 הספק המכויל העוצמה המכווננת כפי שהתקבלה ב-0m (ערך בטווח [-100, 20]). מיוצג כמספר שלם עם סימן, ברזולוציה של 1dBm.
1 עד 4 uint32 ערך השעון ערך השעון הנוכחי בשניות (big endian).
5 uint8 בחירת עקומה העקום האליפטי שמשמש להצפנה:
  • 0x00 (ברירת המחדל): SECP160R1
  • 0x01: SECP256R1 (נדרשת פרסום מורחב)
6 uint8 רכיבים מספר הרכיבים שיכולים לצלצל:
  • 0x00: מציין שהמכשיר לא יכול לצלצל.
  • 0x01: מציין שרק רכיב אחד יכול לצלצל.
  • 0x02: מציין ששני רכיבים, האוזניות השמאלית והימנית, יכולים לצלצל בנפרד.
  • 0x03: מציין ששלושה רכיבים, האוזניות השמאלית והימנית והאריזה, יכולים לצלצל בנפרד.
7 uint8 יכולות צלצול האפשרויות הנתמכות הן:
  • 0x00: אי אפשר לבחור את עוצמת הקול של הצלצול.
  • 0x01: יש אפשרות לבחור את עוצמת הצלצול. אם ההגדרה מוגדרת, הספק צריך לקבל ולטפל ב-3 רמות עוצמת קול כפי שמפורט בקטע פעולת צלצול.
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).

קריאת מצב ההקצאה של ה-beacon

המכשיר המחפש יכול לבצע שאילתה לספק לגבי מצב ההקצאה של ה-beacon על ידי ביצוע פעולת כתיבה למאפיין שמכיל בקשה מטבלה 2 עם מזהה הנתונים 0x01. הספק מוודא שמפתח האימות החד-פעמי שסופק תואם לאחד ממפתחות החשבון שמאוחסנים במכשיר.

אם האימות נכשל, הספק מחזיר שגיאה לא מאומתת.

אם הפעולה בוצעה בהצלחה, הספק שולח הודעה עם תגובה מטבלה 6 עם מזהה הנתונים 0x01. הספק יוצר את מקטע הנתונים באופן הבא:

אוקטט סוג הנתונים תיאור ערך
0 uint8 מצב ההקצאה מסכת ביט עם הערכים הבאים:
  • ביט 1 (0x01): מוגדר אם מוגדר למכשיר מפתח זהות זמני.
  • ביט 2 (0x02): מוגדר אם מפתח האימות החד-פעמי שסופק תואם למפתח של חשבון הבעלים.
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 מהספק, ה-Seeker מבצע פעולת כתיבה למאפיין, שמכילה בקשה מטבלה 2 עם מזהה הנתונים 0x03. הספק מאמת את הפרטים הבאים:

  • מפתח האימות החד-פעמי שסופק תואם למפתח של חשבון הבעלים.
  • מפתח הזהות הזמני המגובב תואם למפתח הזהות הזמני הנוכחי.

אם הספק לא הוקצה כמגדלור 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 הפעלת צלצול מסכת ביט עם הערכים הבאים:
  • ביט 1 (0x01): השמעת צלצול בצד ימין
  • ביט 2 (0x02): השמעת צלצול בצד שמאל
  • ביט 3 (0x04): כיסוי של טבעת
  • 0xFF: צלצול בכל הרכיבים
  • 0x00: הפסקת הצלצול
1 - 2 uint16 חסימה זמנית זמן הקצוב לתפוגה בעשישיות השנייה. הערך לא יכול להיות אפס, וגם לא יכול להיות גדול מ-10 דקות.
הספק משתמש בערך הזה כדי לקבוע כמה זמן הטלפון יצלול לפני שהוא יעבור למצב 'שקט'. אם כבר יש רכיב במכשיר שמצלצל, הזמן הקצוב לתפוגה מבטל את הזמן הקצוב לתפוגה שכבר בתוקף.

אם הערך של ring operation מוגדר כ-0x00, המערכת מתעלמת מזמן הקצאת הזמן הקצוב.
3 uint8 עוצמת הקול
  • 0x00: ברירת מחדל
  • 0x01: נמוך
  • 0x02: בינונית
  • 0x03: רמה גבוהה
המשמעות המדויקת של הערכים האלה תלויה ביישום.

לאחר קבלת הבקשה, הספק מוודא ש:

  • מפתח האימות החד-פעמי שסופק תואם למפתח הטבעת.
  • המצב המבוקש תואם לרכיבים שיכולים לצלצל.

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

כשהצלצול מתחיל או מסתיים, נשלחת התראה כפי שמפורט בטבלה 6 עם מזהה הנתונים 0x05. תוכן ההודעה מוגדר באופן הבא:

אוקטט סוג הנתונים תיאור ערך
0 uint8 מצב צלצול
  • 0x00: התחיל
  • 0x01: נכשלה ההפעלה או ההפסקה (כל הרכיבים המבוקשים לא נמצאים בטווח)
  • 0x02: הפסקה (תפוגה)
  • 0x03: מושהה (לחיצה על לחצן)
  • 0x04: Stopped (בקשת GATT)
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), בהתאמה. הבקשה הזו מבטלת את הפרמטרים של המצב הקיים, כדי שאפשר יהיה להאריך את משך הצלצול.

אם לטלפון של הספק יש לחצן פיזי (או שהחיישן למגע מופעל), לחיצה על הלחצן הזה בזמן שהטלפון מצלצל אמורה להפסיק את הפונקציה.

אחזור סטטוס הצלצול של ה-beacon

כדי לקבל את מצב הצלצול של ה-beacon, ה-Seeker מבצע פעולת כתיבה למאפיין, שמכילה בקשה מטבלה 4 עם מזהה הנתונים 0x06. הספק מאמת שמפתח האימות החד-פעמי שסופק תואם למפתח הטבעת.

אם הספק לא הוגדר כמגדלור 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 דגלים לבקרה
  • 0x01: דילוג על אימות במהלך צלצול. כשההגדרה הזו מופעלת, בקשות לצלצול לא מאומתות במצב של הגנה מפני מעקב לא רצוי.
אם לא מוגדר דגל (הבייטים כוללים רק אפסים), אפשר להשמיט את הקטע של הנתונים לגמרי ולשלוח קטע נתונים ריק.
הדגלים בתוקף רק עד להשבתת מצב ההגנה מפני מעקב לא רצוי.

הספק מוודא שמפתח האימות החד-פעמי שסופק תואם למפתח להגנה מפני מעקב לא רצוי. אם הספק לא הוקצה בתור משואת 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 שניות. אם מתבצעת פרסום של מסגרות Fast Pair, הספק צריך להטמיע את המסגרות של FMDN בתוך המודעות הרגילות של Fast Pair. לדוגמה, כל שתי שניות, הספק צריך להציג שבע מודעות Fast Pair ומודעה אחת מסוג FMDN.

צריך להגדיר את עוצמת השידור של Bluetooth למפרסמים ב-FMDN לפחות ל-0dBm.

המסגרת של FMDN מכילה מפתח ציבורי שמשמש להצפנת דוחות המיקום של כל לקוח תומך שתורם לרשת ה-crowdsourcing. יש שני סוגים של מפתחות של עקומה אליפטית: מפתח של 160 ביט שמתאים לפריימים מדור קודם של BLE 4, או מפתח של 256 ביט שדורש BLE 5 עם יכולות פרסום מורחבות. ההטמעה של הספק קובעת באיזו עקומה נעשה שימוש.

המבנה של מסגרת FMDN הוא:

אוקטט ערך תיאור
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 דגלים מגובבים (hashed)

טבלה 8: מסגרת FMDN שתומכת בעקומה של 160 ביט.

בטבלה 9 מוצגים הערכים וההיסטים של הבייטים לעקומה של 256 ביט.

אוקטט ערך תיאור
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 דגלים מגובבים (hashed)

טבלה 9: מסגרת FMDN שתומכת בעקומה של 256 ביט.

חישוב מזהה זמני (EID)

מפתח אקראי נוצר על ידי הצפנה של מבנה הנתונים הבא באמצעות מפתח הזהות הזמני באמצעות AES-ECB-256:

אוקטט שדה תיאור
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, בתור המזהה הזמני שלו.

דגלים מגובבים

השדה של הדגלים המעורבבים מחושב באופן הבא (הפנייה לביטים היא מהמשמעותי ביותר לפחות משמעותי):

  • ביטים 0-4: שמורים (מוגדרים לאפסים).
  • הביטים 5-6 מציינים את רמת הטעינה של הסוללה במכשיר באופן הבא:
    • 00: אין תמיכה באינדיקציה של רמת הטעינה של הסוללה
    • 01: רמת טעינה רגילה של הסוללה
    • 10: רמת הטעינה של הסוללה נמוכה
    • 11: רמת הטעינה של הסוללה נמוכה מאוד (יש להחליף את הסוללה בקרוב)
  • ביט 7 מוגדר ל-1 אם האות מופעל במצב של הגנה מפני מעקב לא רצוי, ול-0 במקרים אחרים.

כדי ליצור את הערך הסופי של הבית הזה, מבצעים פעולת XOR עם הבית המשמעותי הכי פחות של SHA256(r).

שימו לב ש-r צריך להיות מיושר לגודל של העקומה. מוסיפים אפסים כסיביות המשמעותיות ביותר אם הייצוג קצר מ-160 או מ-256 סיביות, או שצריך לחתוך את הסיביות המשמעותיות ביותר אם הייצוג ארוך מ-160 או מ-256 סיביות.

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

הצפנה באמצעות EID

כדי להצפין הודעה m, משתמש שרואה את האות (אחרי שקורא את Rx מהחיישן) צריך לבצע את הפעולות הבאות:

  1. בוחרים מספר אקראי s ב-Fp, כפי שמוגדר בקטע חישוב EID.
  2. מחשבים את S = s * G.
  3. מחשבים את R = (Rx, Ry) על ידי החלפה של ערך Ry שרירותי מתוך התוצאות האפשריות במשוואת העקומה.
  4. מחשבים את מפתח ה-AES באורך 256 ביט k = HKDF-SHA256((s * R)x), כאשר (s * R)x היא הקואורדינטה x של תוצאת הכפלת העקומה. לא צוין מלח.
  5. נניח ש-URx ו-LRx הם 80 הביטים העליונים והתחתונים של Rx, בהתאמה, בפורמט big-endian. באופן דומה, מגדירים את USx ואת LSx עבור S.
  6. Compute nonce = LRx || LSx.
  7. Compute (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
  8. שולחים את (URx, Sx, m’, tag) לבעלים, אולי דרך שירות מרוחק לא מהימן.

פענוח של ערכים מוצפנים באמצעות EID

לקוח הבעלים, שברשותו נמצאים ה-EIK והחזקה של מעריך תקופת הרוטציה, מפענח את ההודעה באופן הבא:

  1. בהינתן URx, מקבלים את ערך המונה של זמן הפנס שממנו מבוסס URx. אפשר לעשות זאת על ידי חישוב הערכים של Rx בלקוח של הבעלים עבור ערכי מונה הזמן של האותות בעבר הקרוב ובעתיד הקרוב.
  2. על סמך ערך המונה של זמן הפנס שממנו מבוסס URx, מחשבים את הערך הצפוי של r כפי שמוגדר בקטע חישוב מזהה המכשיר (EID).
  3. מחשבים את הערך של R = r * G ומוודאים שהוא תואם לערך של URx שסופק על ידי הכלי למעקב אחר מודעות.
  4. מחשבים את S = (Sx, Sy) על ידי החלפה של ערך Sy שרירותי מתוך התוצאות האפשריות במשוואת העקומה.
  5. מחשבים את k = HKDF-SHA256((r * S)x), כאשר (r * S)x הוא הקואורדינטה x של תוצאת הכפלת העקומה.
  6. מחשבים את nonce = LRx || LSx.
  7. מחשבים את m = AES-EAX-256-DEC(k, nonce, m’, tag).

רוטציית מזהי משתמשים

צריך להשתמש בכתובת BLE שניתן לפתור (RPA) או שלא ניתן לפתור (NRPA) כדי לפרסם מסגרות FMDN. RPA נדרש במכשירי LE Audio (LEA) ומומלץ במכשירים אחרים, מלבד תגי מיקום שלא משתמשים בחיבור.

מודעת Fast Pair, מודעת FMDN והכתובות התואמות של BLE צריכות להופיע בסבב באותו זמן. הסיבוב אמור להתרחש בממוצע כל 1,024 שניות. הנקודה המדויקת שבה ה-beacon מתחיל לפרסם את המזהה החדש צריכה להיות אקראית בתוך החלון.

הגישה המומלצת לבחירה אקראית של זמן ההחלפה היא להגדיר אותו לזמן ההחלפה הצפוי הבא (אם לא הוחל אקראיזציה) בתוספת גורם זמן אקראי חיובי בטווח של 1 עד 204 שניות.

כשהמכשיר נמצא במצב של הגנה מפני מעקב לא רצוי, כתובת ה-BLE של המודעה ב-FMDN צריכה להיות קבועה, אבל ה-RPA של מודעה לא גלויה ב-FP (כמו התאמה מהירה) צריך להמשיך להסתובב. מותר להשתמש בכתובות שונות לפרוטוקולים השונים.

שחזור לאחר הפסקת חשמל

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

ספקים עדיין צריכים לעשות כל שביכולתם כדי למזער את השגיאות בשעון, כי חלון הזמן לפתרון הוא מוגבל. צריך להטמיע לפחות שיטה אחת נוספת לסנכרון השעון (פרסום פריימים של Fast Pair שלא ניתנים לגילוי או הטמעה של מקור הנתונים של ההודעות).

הנחיות להטמעת Fast Pair

בקטע הזה מתוארים היבטים מיוחדים של הטמעת התכונה 'התאמה מהירה' אצל ספקים שתומכים ב-FMDN.

הנחיות ספציפיות לתג איתור

  • אם הספק מותאם, אבל לא בוצעה הקצאה של FMDN תוך 5 דקות (או אם בוצע עדכון OTA בזמן שהמכשיר מותאם אבל לא בוצעה הקצאה של FMDN), הספק צריך לחזור להגדרות המקוריות ולמחוק את מפתחות החשבון השמורים.
  • אחרי שמתאימים את הספק, לא צריך לשנות את כתובת ה-MAC שלו עד שמקצים את FMDN או עד שחולפות 5 דקות.
  • אם מפתח הזהות הזמני נמחק מהמכשיר, המכשיר אמור לבצע איפוס להגדרות המקוריות ולמחוק גם את מפתחות החשבון השמורים.
  • הספק צריך לדחות ניסיונות התאמה רגילים של Bluetooth ולקבל רק התאמה של Fast Pair.
  • הספק חייב לכלול מנגנון שמאפשר למשתמשים להפסיק באופן זמני את הצגת המודעות בלי לאפס את המכשיר להגדרות המקוריות (לדוגמה, לחיצה על שילוב של לחצנים).
  • אחרי הפסקת החשמל, המכשיר אמור לפרסם פריימים של התאמה מהירה שלא ניתנים לזיהוי עד להפעלה הבאה של קריאת פרמטרים של משואות. כך המכשיר המחפש יכול לזהות את המכשיר ולסנכרן את השעון גם אם הייתה סטייה משמעותית בשעון.
  • כשמפרסמים פריימים של התאמה מהירה שלא ניתן לגלות, לא צריך להפעיל את ההנחיות בממשק המשתמש.
  • לא צריך לפרסם מסגרות של התאמה מהירה גלויה בזמן שהספק מוקצה ל-FMDN.
  • הספק לא אמור לחשוף פרטים מזהים באופן לא מאומת (למשל שמות או מזהים).

הנחיות ספציפיות למכשירי Bluetooth Classic

בקטע הזה מוסבר על היבטים מיוחדים של מכשירי Bluetooth רגילים שתומכים ב-FMDN.

הקצאת FMDN למכשירים שכבר הותאמו

הספק לא תמיד מוגדר ל-FMDN במהלך ההתאמה עם ה-Seeker, אלא זמן מה לאחר מכן. במקרה כזה, יכול להיות שלספק אין כתובת MAC עדכנית של BLE שנדרשת כדי ליצור חיבור GATT. הספק חייב לתמוך לפחות באחת מהדרכים הבאות כדי שהמכשיר המחפש יוכל לקבל את כתובת ה-BLE שלו כשהוא כבר מותאם:

  • הספק יכול לפרסם מדי פעם את נתוני החשבון של Fast Pair שמאפשרים למכשיר המחפש למצוא את כתובת ה-BLE שלו באמצעות סריקת BLE.
    הגישה הזו מתאימה לספקים שלא מטמיעים את מקור ההודעות.
  • הספק יכול לספק את הנתונים האלה דרך הזרם של ההודעות של התאמה מהירה ב-Bluetooth הקלאסי.
    הגישה הזו מתאימה לספקי תוכן דיגיטלי שלא מפרסמים פריימים של התאמה מהירה בזמן שהם מחוברים למכשיר החיפוש באמצעות Bluetooth.

תמיכה בשתי הגישות מגדילה את הסיכויים שהמשתמש יוכל להקצות את המכשיר ל-FMDN.

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

הספק יכול להטמיע מקור נתונים של הודעות Fast Pair ולהשתמש בו כדי להודיע למכשיר המחפש על פרטי המכשיר. הטמעת מקור הנתונים של ההודעות מאפשרת להשתמש בתכונות מסוימות, כפי שמתואר בקטע הזה.

הספק צריך לשלוח הודעות עם פרטי המכשיר בכל פעם שמוקם ערוץ RFCOMM להעברת ההודעות.

גרסת הקושחה (קוד פרטי המכשיר 0x09) ויכולת המעקב

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

כדי לאפשר זאת, הספק צריך להשתמש במאפיין Firmware version (קוד 0x09) כדי לדווח על ערך מחרוזת שמייצג את גרסת הקושחה. בנוסף, הספק צריך לתמוך בפרוטוקול שמאפשר למבקש לדעת על שינויים ביכולות עקב עדכוני קושחה.

אוקטט סוג הנתונים תיאור ערך
0 uint8 אירוע של פרטי המכשיר 0x03
1 uint8 גרסת הקושחה 0x09
2 עד 3 uint16 אורך הנתונים הנוספים משתנה
var מערך בייטים מחרוזת הגרסה משתנה

טבלה 11: אירוע של פרטי המכשיר: גרסת הקושחה עודכנה.

כשהספק מקבל בקשה לעדכון יכולות (0x0601), אם הוא הפעיל תמיכה במעקב אחרי FMDN, הוא צריך להשיב כפי שמתואר בטבלה 12.

אוקטט סוג הנתונים תיאור ערך
0 uint8 אירוע סנכרון של יכולות המכשיר 0x06
1 uint8 מעקב אחר מספרים קבועים לחיוג 0x03
2 עד 3 uint16 אורך הנתונים הנוספים 0x0007
4 uint8 מצב הקצאת הרשאות של FMDN 0x00 אם לא הוקצה, 0x01 אם הוקצה על ידי חשבון כלשהו
5 - 10 מערך בייטים כתובת ה-MAC הנוכחית של המכשיר ב-BLE משתנה

טבלה 12: אירוע סנכרון של יכולות המכשיר: נוספה יכולת מעקב.

מזהה זמני נוכחי (קוד פרטי המכשיר 0x0B)

הספק יכול להשתמש בהמזהה הזמני הנוכחי (קוד 0x0B) כדי לדווח על הערך הנוכחי של EID ושל השעון כשהספק הוקצה ל-FMDN, כדי לסנכרן את ה-Seeker במקרה של סטייה בשעון (לדוגמה, בגלל סוללה ריקה). אחרת, ה-Seeker יוצר חיבור יקר פחות מהימן פחות למטרה הזו.

אוקטט סוג הנתונים תיאור ערך
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, עם קידוד הקסדצימלי.
  • המכשיר חייב לכלול רכיב להשמעת צלילים ולתמוך בפונקציית הצלצול. בהתאם למפרט DULT, מכשיר הקול צריך להפיק צליל עם עוצמת קול מינימלית של 60 דציבל (phon) לפי הגדרת ISO 532-1:2017.
  • הנחיות להטמעת קוד הפקודה Sound_Start:
    • הפקודה אמורה להפעיל צלצול בכל הרכיבים הזמינים.
    • צריך להשתמש בנפח המקסימלי שנתמך.
    • משך הזמן המומלץ לצלצול הוא 12 שניות.
  • תגי מיקום חייבים לכלול מנגנון שמאפשר למשתמשים להפסיק באופן זמני את הפרסום בלי לאפס את המכשיר להגדרות המקוריות (לדוגמה, לחיצה על שילוב של לחצנים).
    • הוראות ההשבתה צריכות להיות מתועדות בכתובת URL שזמינה לכולם, ולספק אותן ל-Google כדרישה לקבלת אישור, לפחות 10 ימים לפני כל עדכון או שינוי בהוראות.
    • כתובת ה-URL צריכה לתמוך בהתאמה לשוק המקומי. בהתאם ללקוח, השפה תסופק כפרמטר של שאילתה ("hl=iw") או באמצעות הכותרת 'accept-language' ב-HTTP.

הנחיות לפרוטוקולים שניתן להחליף ביניהם

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

עדכוני קושחה

התהליך וההפצה של עדכוני OTA צריכים להיות מנוהלים על ידי השותף באמצעות תהליך העבודה שלו באפליקציה לנייד או לאינטרנט.

התכונה 'התאמה מהירה' תומכת בשליחת התראות למשתמש על עדכוני OTA זמינים. כדי להשתמש במנגנון הזה:

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

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

תאימות

צריך להפעיל את שירותי המיקום ואת ה-Bluetooth כדי להשתמש ברשת 'איפה המכשיר שלי'. נדרשת תוכנית סלולרית או חיבור לאינטרנט. התכונה פועלת ב-Android מגרסה 9 ואילך ובמדינות מסוימות למשתמשים שעומדים בדרישות הגיל.

יומן שינויים

גרסת FMDN תאריך תגובה
v1 הגרסה הראשונית של מפרט FMDN לגישה מוקדמת.
v1.1 פברואר 2023
  • נוספה אינדיקציה בטקסט ללא הצפנה של מצב ההגנה מפני מעקב לא רצוי.
  • נוספה אפשרות לדלג על אימות של בקשות לצלצול במצב של הגנה מפני מעקב לא רצוי.
v1.2 אפריל 2023
  • עודכנו ההגדרות של AK של הבעלים.
  • הוספנו המלצה לשחזור מחשיפה לחשמל בתגים למיקום.
  • הוסבר מפורט יותר על רנדומיזציה של כתובות MAC.
  • הוסבר בהרחבה על רוטציית כתובות MAC במצב של הגנה מפני מעקב לא רצוי.
  • הוספנו הנחיה לגבי דרכים להשבתת תג מיקום.
v1.3 דצמבר 2023
  • הוסבר בהרחבה על פרטים מזהים שנחשפים על ידי תגי מיקום.
  • נוספה דרישה להטמיע את המפרט למניעת מעקב לא רצוי.
  • הוספנו הנחיות למכשירים עם פרוטוקולים להחלפה.