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

v1.3

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

הערה: אם אתם רוצים לשלב את תג המיקום או מכשיר לא נשמע עם אביזר לרשת "מרכז המכשירים שלי", אתם צריכים למלא את טופס ההצעה למכשיר ל"מרכז המכשירים שלי". אם אתם רוצים להוסיף תמיכה ב'מרכז המכשירים שלי' לאוזניות מעל האוזן או לאוזניות TWS, אתם צריכים למלא את טופס הצעת המכשיר במקום זאת.

מפרט GATT

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

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

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

אימות

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

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

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

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

• מפתח החשבון: מפתח החשבון של התאמה מהירה, באורך 16 בייט, כפי שמוגדר במפרט של התאמה מהירה.

• מפתח חשבון הבעלים: הספק בוחר אחד ממפתחות החשבון הקיימים כמפתח חשבון הבעלים בפעם הראשונה שמשתמש ב-Seeker ניגש למאפיין Beacon Actions. אי אפשר לשנות את המפתח של חשבון הבעלים שנבחר עד שמבצעים איפוס להגדרות היצרן של הספק. הספק לא יכול להסיר את המפתח של חשבון הבעלים כשנגמרים לו משבצות המפתחות בחשבון החינמי.

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

  • ספקים שמקבלים תמיכה ב-FHN אחרי שהם כבר משויכים (לדוגמה, באמצעות עדכון קושחה) יכולים לבחור כל מפתח חשבון קיים. מומלץ לבחור את מפתח החשבון הראשון שמשמש לקריאת מצב ההקצאה ממאפיין פעולות ה-Beacon אחרי עדכון הקושחה, בהנחה שהמשתמש שביצע את העדכון הוא הבעלים הנוכחי של הספק.

• מפתח זהות זמני (EIK): מפתח באורך 32 בייט שנבחר באופן אקראי על ידי המכשיר המחפש במהלך תהליך ההקצאה של FHN. המפתח הזה משמש ליצירת מפתחות קריפטוגרפיים שמשמשים להצפנה מקצה לקצה של דוחות מיקום. ה-Seeker אף פעם לא חושף את המידע הזה לשרת העורפי.

• מפתח שחזור: מוגדר כ-SHA256(ephemeral identity key || 0x01),‏ אחרי חיתוך ל-8 הבייטים הראשונים. המפתח מאוחסן בקצה העורפי, והכלי Seeker יכול להשתמש בו כדי לשחזר את ה-EIK, בתנאי שהמשתמש מביע הסכמה בלחיצה על לחצן במכשיר.

• מפתח טבעת: מוגדר כ-SHA256(ephemeral identity key || 0x02), נחתך ל-8 הבייטים הראשונים. המפתח מאוחסן בקצה העורפי, והמשתמש שחיפש את המכשיר יכול להשתמש בו רק כדי להפעיל צלצול במכשיר.

• מפתח לא רצוי להגנה מפני מעקב: מוגדר כ-SHA256(ephemeral identity key || 0x03), עם חיתוך ל-8 הבייטים הראשונים. המפתח מאוחסן בקצה העורפי, והמבקש יכול להשתמש בו רק כדי להפעיל מצב לא רצוי של הגנה מפני מעקב.

תפעול

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Octet	סוג הנתונים	תיאור	ערך
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).

הגדרת מפתח זהות זמני

כדי להקצות ספק שלא הוקצה כמשדר FHN, או כדי לשנות את מפתח הזהות הזמני של ספק שכבר הוקצה, המכשיר המחפש מבצע פעולת כתיבה למאפיין שכוללת בקשה מטבלה 2 עם מזהה נתונים 0x02. הספק מוודא ש:

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

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

אם הפעולה בוצעה ללא שגיאות, מפתח הזהות הארעי ישוחזר באמצעות פענוח AES-ECB-128 שלו באמצעות מפתח החשבון התואם. המפתח צריך להישמר במכשיר, ומאותו רגע הספק צריך להתחיל לפרסם פריימים של FHN. מפתח הזהות הזמני החדש נכנס לתוקף מיד אחרי שחיבור ה-BLE מסתיים. הספק שולח הודעה עם תגובה מטבלה 6 עם מזהה הנתונים 0x02.

פלח האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

ניקוי מפתח הזהות הזמני

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

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

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

אם הפעולה מצליחה, הספק שוכח את המפתח ומפסיק לפרסם מסגרות FHN. הספק שולח הודעה עם תגובה מטבלה 6 עם מזהה הנתונים 0x03. פלח האימות מוגדר כ-8 הבייטים הראשונים של HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

קריאת מפתח הזהות הזמני בהסכמת המשתמש

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

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

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

Octet	סוג הנתונים	תיאור	ערך
0	uint8	הפעלת צלצול	מסיכת ביטים עם הערכים הבאים: ביט 1 ‏ (0x01): השמעת צלצול בצד ימין ביט 2 ‏ (0x02): השמעת צלצול בצד שמאל ביט 3 ‏ (0x04): צלצול ‫0xFF: צלצול בכל הרכיבים ‫0x00: הפסקת הצלצול
1 - 2	uint16	חסימה זמנית	הזמן הקצוב לתפוגה בדצי-שניות. הערך לא יכול להיות אפס ולא יכול להיות גדול מהערך ששווה ל-10 דקות. הספק משתמש בערך הזה כדי לקבוע כמה זמן הטלפון יצלצל לפני שהוא יושתק. אם רכיב כלשהו במכשיר כבר מצלצל, הגדרת הזמן הקצוב לתפוגה מבטלת את ההגדרה הקיימת. אם ring operation מוגדר כ-0x00, המערכת מתעלמת מהזמן הקצוב לתפוגה.
3	uint8	נפח	‫0x00: ברירת מחדל ‫0x01: נמוך ‫0x02: בינוני ‫0x03: גבוה המשמעות המדויקת של הערכים האלה תלויה ביישום.

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

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

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

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

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

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

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

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

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

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

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

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

כדי להפעיל או להשבית את מצב ההגנה מפני מעקב לא רצוי של המשואה, המאתר מבצע פעולת כתיבה למאפיין, שכוללת בקשה מטבלה 5 עם מזהה נתונים 0x07 או 0x08 בהתאמה.

כשמפעילים מצב הגנה לא רצוי מפני מעקב

הספק יוצר את פלח הנתונים באופן הבא:

Octet	סוג הנתונים	תיאור	ערך
0	uint8	דגלי בקרה	‫0x01: דילוג על אימות של צלצול. אם ההגדרה הזו מופעלת, בקשות לשיחות נכנסות לא מאומתות כשמצב ההגנה מפני מעקב לא רצוי מופעל. אם לא מוגדר דגל (הבייט הוא אפס), אפשר להשמיט את קטע הנתונים לגמרי ולשלוח קטע נתונים ריק. ההגדרות האלה תקפות רק עד להשבתת מצב ההגנה מפני מעקב לא רצוי.

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

כשמצב ההגנה הלא רצוי מפני מעקב מופעל, ה-beacon צריך להפחית את תדירות הסיבוב של כתובת ה-MAC הפרטית לפעם אחת ב-24 שעות. המזהה הארעי של המוצר המפורסם צריך להמשיך להתחלף כרגיל. סוג המסגרת צריך להיות 0x41. הסטטוס משתקף גם בקטע דגלים עם גיבוב.

כשמשביתים מצב לא רצוי של אמצעים לחסימת מעקב

הספק מוודא ש:

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

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

כשמשביתים את מצב ההגנה מפני מעקב לא רצוי, ה-beacon אמור להתחיל לסובב את כתובת ה-MAC בקצב רגיל שוב, בסינכרון עם סיבוב המזהה הארעי. סוג המסגרת צריך להיות מוגדר בחזרה ל-0x40. הסטטוס משתקף גם בקטע hashed flags.

אם הפעולה בוצעה בהצלחה, הספק שולח הודעה עם תשובה מטבלה 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).

חיפוש מדויק

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

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

תהליך השימוש בתכונה 'חיפוש מדויק'

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

איור 1: תהליך אופייני של הודעות בחיפוש מדויק

המכשיר היוזם הוא המכשיר שמותקנת בו האפליקציה "מרכז המכשירים שלי", ושהופעלה בו התכונה 'איתור מדויק'. המכשיר היוזם הוא המכשיר שמנסה לאתר את המכשיר השני.

מכשיר המשיב הוא המכשיר שמכשיר היוזם מנסה לאתר.

המכשיר היוזם שולח הודעת בקשה לקביעת טווח למכשיר המשיב, שבה הוא מפרט את הטכנולוגיות לקביעת טווח שהוא רוצה ללמוד עליהן מהמכשיר המשיב. המכשיר המשיב ישלח בחזרה את ההתראה Ranging Capability Response (תגובה לגבי יכולת מדידת מרחק), שתכיל מידע על טכנולוגיות מדידת המרחק הנתמכות ועל היכולות שלהן. המענה יכלול רק מידע שהתבקש על ידי מי שיזם את הבקשה. רשימת היכולות תמוין לפי העדיפות של טכנולוגיית מדידת הטווח שהמכשיר המשיב מעדיף, כשהיכולת הראשונה ברשימה היא בעדיפות הגבוהה ביותר.

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

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

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

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

פעולות של חיפוש מדויק

בטבלה 8 מוצגות פעולות FHNA שמוגדרות במסמך הזה ונדרשות לחיפוש מדויק. כל חלק משנה מגדיר את הודעת ה-FHNA לכל אחת מהפעולות, בעוד שתוכן השדה Additional Data מתייחס למפרט Ranging: Out-of-band message sequence and payload.

פעולה	מזהה נתונים	תיאור
בקשה ליכולת של טווח	0x0A	פעולת בקשת היכולת שתשלח ממכשיר היוזם למכשיר המשיב. בתוכן הנתונים של הפעולה הזו יפורטו כל טכנולוגיות המדידה שהמכשיר היוזם רוצה לדעת עליהן מהמכשיר המגיב.
תגובה בנושא יכולת מדידת מרחק	0x0A	זוהי התגובה להתראה על הפעולה Ranging Capability Request. היא מכילה מידע על היכולות של כל טכנולוגיית טווח נתמכת שהמבקש ביקש.
הגדרת טווח	0x0B	פעולת ההגדרה של טווח המרחק מכילה את ההגדרות של טכנולוגיות לקביעת טווח המרחק, שבאמצעותן המכשיר היוזם רוצה להתחיל לקבוע את טווח המרחק עם המכשיר המגיב.
תגובה להגדרת טווח	0x0B	זו התגובה להתראה על פעולת הגדרת הטווח. הוא מכיל נתונים לגבי התחלת מדידת הטווח במכשיר המשיב באמצעות טכנולוגיות מדידת הטווח המבוקשות, על סמך ההגדרה שסופקה.
RFU	0x0C	הפעולה עם מזהה הנתונים הזה לא נמצאת בשימוש והיא שמורה לשימוש עתידי.
הפסקת מדידת הטווח	0x0D	פעולת עצירת מדידת הטווח שנשלחת מהמכשיר היוזם מכילה מידע על טכנולוגיות מדידת הטווח שבהן המכשיר המגיב צריך להפסיק למדוד את הטווח.
הפסקת התשובה	0x0D	זו התגובה להתראה על הפעולה Stop Ranging. הוא מכיל נתונים שמעידים אם פעולת ההפסקה של טכנולוגיית טווח ספציפית הצליחה או לא.

טבלה 8: פעולות של חיפוש מדויק.

פעולה של בקשת יכולת טווח

בטבלה 9 מוגדרת הודעת בקשת יכולת טווח.

Octet	סוג הנתונים	תיאור	ערך
0	uint8	מזהה נתונים	‫0x0A – פעולת בקשת יכולת טווח
1	uint8	אורך הנתונים	משתנה
2	מערך בייטים	מפתח אימות חד-פעמי	‫8 הבייטים הראשונים של HMAC-SHA256(מפתח החשבון, מספר הגרסה הראשית של הפרוטוקול || הערך האחרון של ה-nonce שנקרא מהמאפיין || מזהה הנתונים || אורך הנתונים || נתונים נוספים).
10	מערך בייטים	נתונים נוספים	הודעת בקשה ליכולת מדידת מרחק כפי שמוגדר במפרט מדידת מרחק: רצף הודעות ומטען ייעודי (payload) מחוץ לפס (גם הכותרת וגם המטען הייעודי)

טבלה 9: בקשה ליכולת של טווח.

פעולת התגובה של יכולת מדידת המרחק

בטבלה 10 מוגדרת הודעת התגובה של יכולת הטווח.

Octet	סוג הנתונים	תיאור	ערך
0	uint8	מזהה נתונים	‫0x0A: תגובה לגבי יכולת מדידת מרחק
1	uint8	אורך הנתונים	משתנה
2	מערך בייטים	מפתח אימות חד-פעמי	‫8 הבייטים הראשונים של HMAC-SHA256(מפתח החשבון, מספר הגרסה הראשית של הפרוטוקול || הערך האחרון של ה-nonce שנקרא מהמאפיין || מזהה הנתונים || אורך הנתונים || נתונים נוספים || 0x01).
10	מערך בייטים	נתונים נוספים	הודעת תגובה על יכולת מדידת מרחק כפי שמוגדר במפרט מדידת מרחק: רצף הודעות ומטען ייעודי (payload) מחוץ לפס (גם הכותרת וגם המטען הייעודי)

טבלה 10: תגובה של יכולת דירוג.

פעולת הגדרת טווח

בטבלה 11 מוגדרת ההודעה Ranging Configuration.

Octet	סוג הנתונים	תיאור	ערך
0	uint8	מזהה נתונים	‫0x0B – הגדרת תצורת מדידת טווח
1	uint8	אורך הנתונים	משתנה
2	מערך בייטים	מפתח אימות חד-פעמי	‫8 הבייטים הראשונים של HMAC-SHA256(מפתח החשבון, מספר הגרסה הראשית של הפרוטוקול || הערך האחרון של ה-nonce שנקרא מהמאפיין || מזהה הנתונים || אורך הנתונים || נתונים נוספים).
10	מערך בייטים	נתונים נוספים	ההודעה Ranging Configuration (הגדרת טווח) כפי שמוגדר במפרט Ranging: Out-of-band message sequence and payload (גם הכותרת וגם המטען הייעודי).

טבלה 11: הגדרת טווח.

פעולת תגובה להגדרת טווח

בטבלה 12 מוגדרת הודעת התגובה של הגדרת הטווח.

Octet	סוג הנתונים	תיאור	ערך
0	uint8	מזהה נתונים	‫0x0B – הגדרת תגובה להגדרת טווח
1	uint8	אורך הנתונים	משתנה
2	מערך בייטים	מפתח אימות חד-פעמי	‫8 הבייטים הראשונים של HMAC-SHA256(מפתח החשבון, מספר הגרסה הראשית של הפרוטוקול || הערך האחרון של ה-nonce שנקרא מהמאפיין || מזהה הנתונים || אורך הנתונים || נתונים נוספים || 0x01).
10	מערך בייטים	נתונים נוספים	הודעת Ranging Configuration Response (תגובה להגדרת טווח) כפי שמוגדר במפרט Ranging: Out-of-band message sequence and payload (גם הכותרת וגם המטען הייעודי).

טבלה 12: תגובה להגדרת טווח.

הפסקת פעולת מדידת הטווח

בטבלה 13 מוגדרת ההודעה Stop Ranging.

Octet	סוג הנתונים	תיאור	ערך
0	uint8	מזהה נתונים	‫0x0D – עצירה של מדידת טווח
1	uint8	אורך הנתונים	משתנה
2	מערך בייטים	מפתח אימות חד-פעמי	‫8 הבייטים הראשונים של HMAC-SHA256(מפתח החשבון, מספר הגרסה הראשית של הפרוטוקול || הערך האחרון של ה-nonce שנקרא מהמאפיין || מזהה הנתונים || אורך הנתונים).
10	מערך בייטים	נתונים נוספים	ההודעה Stop Ranging כפי שמוגדר במפרט Ranging: Out-of-band message sequence and payload (גם הכותרת וגם המטען הייעודי).

טבלה 13: עצירת טווח.

הפסקת פעולת התגובה לטווח

בטבלה 14 מוגדרת ההודעה Stop Ranging Response.

Octet	סוג הנתונים	תיאור	ערך
0	uint8	מזהה נתונים	‫0x0D – תגובה של עצירת טווח
1	uint8	אורך הנתונים	משתנה
2	מערך בייטים	מפתח אימות חד-פעמי	‫8 הבייטים הראשונים של HMAC-SHA256(מפתח החשבון, מספר הגרסה הראשית של הפרוטוקול || הערך האחרון של ה-nonce שנקרא מהמאפיין || מזהה הנתונים || אורך הנתונים || נתונים נוספים || 0x01).
10	מערך בייטים	נתונים נוספים	ההודעה Stop Ranging Response כפי שמוגדר במפרט Ranging: Out-of-band message sequence and payload (גם הכותרת וגם המטען הייעודי)

טבלה 14: Stop Ranging Response.

הגנה מפני מעקב לא רצוי באמצעות איתור מדויק

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

פרטים ספציפיים על טכנולוגיית טווחים לחיפוש מדויק

בקטע הזה מפורטים פרטים שספציפיים לטכנולוגיית הטווח.

פרטים ספציפיים על Ultra Wideband‏ (UWB)

פרטים ספציפיים לגבי UWB.

רמת הדיוק של התכונה 'איתור מדויק'

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

מזהי הגדרות

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

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

UWB Initiator and Responder

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

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

פרמטרים אחרים שקשורים ל-UWB

• צריך לתמוך בערוץ 9
• כדי לקבל הנחיות אופטימליות, מומלץ להשתמש במרווח מדידה של 96ms. אחרת, צריך לתמוך במרווח של 240ms.
• מומלץ להשתמש במשך זמן של משבצת של 1ms כדי לחסוך בסוללה, אבל גם משך זמן של 2ms נתמך.
• השבב של ה-UWB צריך להיות תואם לפחות ל-FIRA v1.2 + P-STS.
• המאפיין BPRF הוא חובה, והמאפיין HPRF הוא אופציונלי אבל מומלץ. המצב הנתמך או הנבחר נקבע לפי אינדקס הפתיח הנתמך או הנבחר.
• סוג אבטחת הסשן: P-STS

פרטים ספציפיים על בדיקת תקינות הערוץ (CS) ב-BLE

פרטים ספציפיים של BLE CS.

רמת הדיוק של התכונה 'איתור מדויק'

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

הקשר הנדרש בין המכשירים

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

נדרשת פעולה מצד המשיב ב-CS

בניגוד ל-UWB, שבו שני המכשירים נדרשים לקרוא ל-API של UWB כדי להתחיל ולסיים את טווח המרחק, ב-CS רק המכשיר היוזם נדרש להתחיל את טווח המרחק של CS על ידי קריאה למערך הפרוטוקולים של Bluetooth. שאר ההפעלה בצד המכשיר המגיב מתבצעת בתוך הפס באמצעות Bluetooth ‏ (BT). המשמעות היא שכאשר מתקבלת הודעת הגדרת טווח או הודעת הפסקת מדידת הטווח עבור CS, הצד המשיב לא צריך לעשות כלום אם Bluetooth מופעל, מלבד להשיב עם הודעת התראה על תגובת הגדרת הטווח. המכשיר המשיב יכול להשתמש בהודעות האלה כטריגר לעדכון ממשק המשתמש אם יש מסך, או ללא קשר למסך, כדי לספק משוב חזותי על מצב המכשיר, למשל להבהב את נוריות ה-LED של המכשיר.

Wi-Fi NAN RTT

פרטים ספציפיים על Wi-Fi NAN RTT.

רמת הדיוק של התכונה 'איתור מדויק'

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

BLE RSSI

פרטים ספציפיים של BLE RSSI.

רמת הדיוק של התכונה 'איתור מדויק'

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

מסגרות של פרסומות

אחרי ההקצאה, הספק אמור לפרסם פריימים של FHN לפחות פעם אחת בכל 2 שניות. אם ספקי השירות מפרסמים מסגרות של התאמה מהירה, הם צריכים לשלב את מסגרות ה-FHN בתוך הפרסומים הרגילים של התאמה מהירה. לדוגמה, כל שתי שניות, הספק צריך לפרסם שבע מודעות Fast Pair ומודעה אחת של FHN.

עוצמת השידור של Bluetooth שמוגדרת לפרסום של FHN צריכה להיות לפחות 0 dBm.

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

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

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

מסגרת FHN בנויה כך:

Octet	ערך	תיאור
0	0x02	אורך
1	0x01	ערך סוג הנתונים של הדגלים
2	0x06	נתוני סימונים
3	‫0x18 או 0x19	אורך
4	‫0x16	הערך של סוג הנתונים של נתוני השירות
5	‫0xAA	מזהה UUID של שירות 16 ביט
6	0xFE	...
7	‫0x40 או 0x41	סוג מסגרת FHN עם אינדיקציה לא רצויה של מצב הגנה מפני מעקב
‫8..27		מזהה זמני באורך 20 בייט
28		דגלים מגובבים

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

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

Octet	ערך	תיאור
0	0x02	אורך
1	0x01	ערך סוג הנתונים של הדגלים
2	0x06	נתוני סימונים
3	‫0x24 או 0x25	אורך
4	‫0x16	הערך של סוג הנתונים של נתוני השירות
5	‫0xAA	מזהה UUID של שירות 16 ביט
6	0xFE	...
7	‫0x40 או 0x41	סוג מסגרת FHN עם אינדיקציה לא רצויה של מצב הגנה מפני מעקב
‫8..39		מזהה זמני באורך 32 בייט
40		דגלים מגובבים

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

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

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

Octet	שדה	תיאור
‫0 עד 10	מרווח	Value = 0xFF
11	K	מעריך של תקופת הרוטציה
‫12-15	TS[0]...TS[3]	מונה הזמן של אות ה-Beacon, בפורמט big-endian של 32 ביט. הביטים הנמוכים ביותר נמחקים.
‫16-26	מרווח	ערך = 0x00
27	K	מעריך של תקופת הרוטציה
‫28-31	TS[0]...TS[3]	מונה הזמן של אות ה-Beacon, בפורמט big-endian של 32 ביט. הביטים הנמוכים ביותר נמחקים.

טבלה 17: בנייה של מספר פסאודו-אקראי.

הערה: ההנחה היא שלמכשיר יש מונה זמן של 32 ביט בשניות.

הערה: מעריך התקופה של הרוטציה קבוע ומוגדר ל-10, שמתאים ל-1,024 שניות.

התוצאה של החישוב הזה היא מספר בן 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 אם ה-beacon נמצא במצב הגנה מפני מעקב לא רצוי, אחרת הוא מוגדר ל-0.

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

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

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

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

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

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

1. בוחרים מספר אקראי s ב-Fp, כמו שמוגדר בקטע חישוב מזהה הלקוח.
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, מקבלים את ערך מונה הזמן של ה-beacon שעליו מבוסס URx. אפשר לעשות את זה באמצעות חישוב Rx של ערכי זמן האות וערכי מונה עבור העבר הקרוב והעתיד הקרוב במחשב הלקוח של הבעלים.
2. בהינתן ערך מונה הזמן של ה-beacon שעליו מבוסס 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. ‫Compute nonce = LRx || LSx.
7. ‫Compute m = AES-EAX-256-DEC(k, nonce, m’, tag).

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

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

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

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

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

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

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

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

הנחיות להטמעה של התאמה מהירה

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

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

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

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

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

הקצאת מכשירים שכבר בוצעה בהם התאמה באמצעות FHN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Octet	סוג הנתונים	תיאור	ערך
0	uint8	אירוע פרטי מכשיר	0x03
1	uint8	מזהה זמני נוכחי	0x0B
2 - 3	uint16	אורך נתונים נוסף	‫0x0018 או 0x0024
‫4 - 7	מערך בייטים	ערך השעון	דוגמה: 0x13F9EA80
‫8 עד 19 או 31	מערך בייטים	מספר ה-EID הנוכחי	דוגמה: 0x1122334455667788990011223344556677889900

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

איפוס להגדרות המקוריות

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

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

מניעת מעקב לא רצוי

מכשירי FHN מאושרים צריכים גם לעמוד בדרישות שבגרסת ההטמעה של המפרט חוצה הפלטפורמות בנושא איתור של מכשירי מעקב לא רצויים (DULT).

הנחיות רלוונטיות שספציפיות ל-FHN כדי לעמוד בדרישות המפרט של DULT:

• כל מכשיר שתואם ל-FHN צריך להיות רשום ב-Nearby Device Console, והיכולת Find Hub צריכה להיות מופעלת בו.
• המכשיר צריך להטמיע את השירות והמאפיין 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 יכולה להחזיר את הערך הכללי Location Tracker (מכשיר למעקב אחר מיקום) אם אין קטגוריה אחרת שמתאימה יותר לסוג המכשיר.
  • הפונקציה 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 פון, כפי שמוגדר בתקן ISO 532-1:2017.
• הנחיות להטמעה של אופקוד Sound_Start:
  • הפקודה אמורה להפעיל צלצול בכל הרכיבים הזמינים.
  • מומלץ להשתמש בנפח המקסימלי הנתמך.
  • המשך המומלץ של הצלצול הוא 12 שניות.
• תגי מיקום צריכים לכלול מנגנון שמאפשר למשתמשים להפסיק זמנית את הפרסום בלי לאפס את המכשיר להגדרות המקוריות (לדוגמה, לחיצה על שילוב של לחצנים).
  • ההוראות להשבתה צריכות להיות מתועדות בכתובת URL שזמינה לציבור, וצריך לספק אותן ל-Google כדרישה לקבלת אישור, ולפחות 10 ימים לפני כל עדכון או שינוי בהוראות.
  • כתובת ה-URL צריכה לתמוך בלוקליזציה. בהתאם ללקוח, השפה תסופק כפרמטר של שאילתה (‎"hl=en"‎) או באמצעות כותרת ה-HTTP‏ ‎"accept-language"‎.

הנחיות לגבי פרוטוקול שאפשר להחליף

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

עדכוני קושחה

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

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

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

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

תאימות

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

יומן שינויים

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