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

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. בהתאם לפעולה המבוקשת, מבצע הבקשה צריך להוכיח שהוא יודע את אחד או יותר מהמפתחות הבאים:

תפעול

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

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

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

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

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

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

Octet סוג הנתונים תיאור ערך
0 uint8 מזהה נתונים
  • 0x00: קריאת הפרמטרים של ה-beacon
  • 0x01: קריאת מצב ההקצאה
  • 0x02: הגדרת מפתח זהות זמני
  • 0x03: מפתח זהות חד-פעמי שקוף
  • 0x04: קריאה של מפתח זהות זמני עם הסכמת המשתמש
  • 0x05: שינוי בסטטוס הצלצול
  • 0x06: קריאת מצב הצלצול
  • 0x07: הפעלת מצב הגנה מפני מעקב לא רצוי
  • 0x08: השבתת מצב ההגנה מפני מעקב לא רצוי
1 uint8 אורך הנתונים משתנה
2 עד 9 מערך בייטים אימות פירוט לפי פעולה
10 – וריאציות מערך בייטים נתונים נוספים
  • 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 על ידי ביצוע פעולת כתיבה למאפיין, שמכילה בקשה מטבלה 2 עם מזהה הנתונים 0x00. הספק מוודא שמפתח האימות החד-פעמי שסופק תואם לאחד ממפתחות החשבון ששמורים במכשיר.

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

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

אוקטט סוג הנתונים תיאור ערך
0 uint8 הספק המכויל ההספק המכוונן כפי שהוא התקבל ב-0m (ערך בטווח [-100, 20]). מיוצג כמספר שלם עם סימן, ברזולוציה של 1dBm.
1 - 4 uint32 ערך השעון ערך השעון הנוכחי בשניות (קצה גדול).
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).

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

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

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

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

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

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

לאחר קבלת הבקשה, הספק מאמת את הפרטים הבאים:

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

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

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

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

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

מהו מצב הצלצול של איתות החיישן

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

  1. בוחרים מספר אקראי s ב-Fp, כפי שמוגדר בקטע חישוב מזהה EID.
  2. Compute S = s * G.
  3. מחשבים את R = (Rx, Ry) על ידי החלפה במשוואת העקומה ובחירת ערך Ry שרירותי מתוך התוצאות האפשריות.
  4. מחשבים את מפתח AES ב-256 ביט k = HKDF-SHA256((s * R)x) כאשר (s * R)x הוא הקואורדינטה x של תוצאת ההכפלה של העקומה. לא צוין salt.
  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. 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, עם קידוד הקסדצימלי.
  • הנחיות להטמעת קוד הפקודה 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
  • ההגדרה של חשבון ניהול (AK) של הבעלים עודכנה.
  • הוספנו המלצה לשחזור מפסקת חשמל בתגים למיקום.
  • הוסבר מתי מתבצעת רנדומיזציה של כתובת ה-MAC.
  • הוסבר בהרחבה על רוטציית כתובת ה-MAC במצב הגנה מפני מעקב לא רצוי.
  • הוספנו הנחיה לגבי דרכים להשבתת תג מיקום.
v1.3 דצמבר 2023
  • נוספה הבהרה לגבי מידע מזהה שנחשפים על ידי תגי איתור.
  • נוספה דרישה להטמיע את המפרט למניעת מעקב לא רצוי.
  • הוספנו הנחיות למכשירים עם פרוטוקולים להחלפה.