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

v1.3

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

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

מפרט GATT

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

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

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

אימות

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

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

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

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

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

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

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

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

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

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

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

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

Octet	סוג הנתונים	תיאור	ערך
0	uint8	מצב הקצאת הרשאות	מסיכת ביטים עם הערכים הבאים: ביט 1 (0x01): מוגדר אם מוגדר מפתח זהות זמני למכשיר. ביט 2 ‏ (0x02): מוגדר אם מפתח האימות החד-פעמי שסופק תואם למפתח של החשבון שמוגדר כבעלים.
‫1 עד 20 או 32	מערך בייטים	מזהה זמני נוכחי	‫20 או 32 בייט (בהתאם לשיטת ההצפנה שבה נעשה שימוש) שמציינים את המזהה הארעי הנוכחי שמשודר על ידי משואת ה-Bluetooth, אם מוגדר מזהה כזה למכשיר.

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

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

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

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

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

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

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

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

הספק מוודא ש:

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

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

טבלה 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	מערך בייטים	נתונים נוספים	הודעת Ranging Capability Response כפי שמוגדר במפרט Ranging: Out-of-band message sequence and 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 (טווח: רצף הודעות ומטען ייעודי (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: הפסקת השימוש ב-Ranging.

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

בטבלה 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: הפסקת התגובה לשינוי הטווח.

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

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

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

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

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

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

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

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

מזהי הגדרות

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

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

מאותת UWB ומגיב UWB

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

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

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

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

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

שחזור לאחר אובדן מתח

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

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

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

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

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

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

הנחיות ספציפיות למכשירי Bluetooth קלאסיים

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

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

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

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

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

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

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

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

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

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

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

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

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

• כל מכשיר שתואם ל-FHN צריך להיות רשום ב-Nearby Device Console, והיכולת מרכז המכשירים שלי צריכה להיות מופעלת בו.
• המכשיר צריך להטמיע את השירות ואת המאפיין 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. הכלי Seeker קורא קודם את מצב ההקצאה ומספק מפתח אימות, כפי שמוגדר במפרט הזה, ורק לאחר מכן קורא את גרסת הקושחה. הפעולה הזו תתבצע באותו חיבור. אם מתבצע ניסיון לקרוא את עדכון הקושחה, והספק לא מקושר או שלא הושלמה בהצלחה פעולה מאומתת באותו חיבור, הספק צריך להחזיר שגיאה לא מאומתת.

תאימות

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

יומן שינויים

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