อุปกรณ์บลูทูธพลังงานต่ำ (BLE)

การติดตั้งใช้งาน Google Fast Pair Service (GFPS) สำหรับอุปกรณ์ BLE เข้ากันได้กับข้อกำหนดหลักของบลูทูธ v4.2 ขึ้นไป

ภาคผนวกต่อไปนี้ในข้อกำหนดการจับคู่ด่วนจะช่วยให้รองรับ เฉพาะอุปกรณ์เสียงพลังงานต่ำ (LE) และเสียงพลังงานต่ำ (LEA) ใน GFPS

ระดับการปฏิบัติตามข้อกำหนด

คำว่า "ต้อง" "ต้อง" "จะ" "ควร" "อาจ" และ "สามารถ" ที่กล่าวถึงในข้อกำหนดมีคำอธิบายดังนี้

คำศัพท์ คำอธิบาย
ต้อง ต้อง - ใช้เพื่อกำหนดข้อกำหนด
ต้อง ใช้เพื่อแสดง
ผลลัพธ์ตามธรรมชาติของข้อกำหนดบังคับที่ระบุไว้ก่อนหน้านี้
หรือ
ข้อความที่ระบุข้อเท็จจริงที่ปฏิเสธไม่ได้ (ข้อความที่เป็นจริงเสมอไม่ว่าในสถานการณ์ใดก็ตาม)
พินัยกรรม เป็นความจริงที่ว่า - ใช้ในข้อเท็จจริงเท่านั้น
ควร ขอแนะนำให้ - ใช้เพื่อระบุว่าในความเป็นไปได้หลายอย่าง มีความเป็นไปได้หนึ่งที่แนะนำว่าเหมาะสมเป็นพิเศษ แต่ไม่จำเป็นต้องใช้
พฤษภาคม ได้รับอนุญาตให้ - ใช้เพื่ออนุญาตตัวเลือก
สามารถ สามารถ - ใช้เพื่อเชื่อมโยงข้อความในลักษณะที่เป็นเหตุเป็นผล

ลักษณะการจับคู่ตามคีย์

ข้อความจากผู้ขอถึงผู้ให้บริการ

คำขอแบบดิบ type 0x00 ของลักษณะการจับคู่ตามคีย์ใช้บิต 4 เพื่อระบุว่า Seeker รองรับข้อกำหนดของอุปกรณ์ BLE หรือไม่ และใช้บิต 5 เพื่อระบุว่า Seeker รองรับ LE Audio หรือไม่

Octet ประเภทข้อมูล คำอธิบาย ค่า ต้องระบุไหม
0 uint8 ประเภทของข้อความ 0x00 = คำขอจับคู่ตามคีย์ บังคับ
1 uint8 ธง
  • บิตที่ 0 (MSB): เลิกใช้งานแล้วและ Seeker จะไม่สนใจ
  • บิต 1: 1 หาก Seeker ขอให้ Provider เริ่มการจับคู่ และคำขอนี้มีที่อยู่ BR/EDR ของ Seeker ไม่เช่นนั้นจะเป็น 0
  • บิต 2: 1 หากผู้ขอต้องการให้ผู้ให้บริการแจ้งชื่อที่มีอยู่ ไม่เช่นนั้นจะเป็น 0
  • บิตที่ 3: 1 หากใช้สำหรับการเขียนคีย์บัญชีย้อนหลัง ไม่เช่นนั้นจะเป็น 0
  • บิตที่ 4: 1 หาก Seeker รองรับข้อกำหนดของอุปกรณ์ BLE ไม่เช่นนั้นจะเป็น 0
  • บิตที่ 5: 1 หาก Seeker รองรับ LE Audio ไม่เช่นนั้นจะเป็น 0
  • บิตที่ 6-7 สงวนไว้สำหรับการใช้งานในอนาคต และควรเพิกเฉย
 แตกต่างกันไป บังคับ
2 - 7 uint48 โดยใช้วิธีใดวิธีหนึ่งต่อไปนี้
  • ที่อยู่ BLE ปัจจุบันของผู้ให้บริการ
  • ที่อยู่ประจำตัวของผู้ให้บริการ
 แตกต่างกันไป บังคับ
8 - 13 uint48 ที่อยู่ BR/EDR ของ Seeker แตกต่างกันไป แสดงเฉพาะในกรณีที่ตั้งค่าบิตสถานะ 1 หรือ 3
n - 15 ค่าแบบสุ่ม (Salt) แตกต่างกันไป บังคับ

ข้อความจากผู้ให้บริการถึงผู้ขอรับบริการ

เมื่อตั้งค่าบิตที่ 4 ของคำขอแล้ว คุณจะใช้ข้อความตอบกลับใหม่ type 0x02 สำหรับ ลักษณะการจับคู่ตามคีย์เพื่อระบุตัวเลือกการเชื่อมต่อเพิ่มเติม ให้กับ Seeker ได้

Octet ประเภทข้อมูล คำอธิบาย ค่า
0 uint8 ประเภทของข้อความ 0x02 = คำตอบเพิ่มเติมของการจับคู่ตามคีย์
1 uint8 ธง
  • บิต 0 (MSB): 1 หากผู้ให้บริการเป็นอุปกรณ์ LE เท่านั้น มิฉะนั้นจะเป็น 0 หากตั้งค่าบิต 0 เป็น 1 Seeker จะถือว่าตั้งค่าบิต 1 เป็น 1
  • บิตที่ 1: 1 หากผู้ให้บริการต้องการการเชื่อมต่อ LE หรือ 0 หากไม่ต้องการ
  • บิตที่ 2: 1 หากประเภทที่อยู่ของที่อยู่ 2 เป็นแบบสุ่ม 0 หากเป็นแบบสาธารณะ
  • บิตที่ 3-7 สงวนไว้สำหรับการใช้งานในอนาคต และจะไม่มีผล
 แตกต่างกันไป
2 uint8 จำนวนที่อยู่ของผู้ให้บริการ
(ในเวอร์ชันปัจจุบัน จำนวนคือ 1 หรือ 2 เนื่องจากเราต้องแก้ไขโหมดการเข้ารหัสแบบบล็อกเป็น AES-CTR หากจำนวน >= 3)		 แตกต่างกันไป
3 - 8 หรือ
3 - 14
  • ที่อยู่แรกต้องเป็นที่อยู่ประจำตัวของอุปกรณ์หลัก และต้องเชื่อมต่อได้หากต้องการการเชื่อมต่อ BR/EDR
  • ที่อยู่รองต้องเป็นที่อยู่ที่สามารถออกพันธบัตรได้หากมี
 แตกต่างกันไป
9 - 15 หรือ 15 ค่าแบบสุ่ม (Salt) แตกต่างกันไป

ผู้ให้บริการที่รองรับข้อกำหนดของอุปกรณ์ BLE จะต้องอ่านบิตที่ 4 และบิตที่ 5 เพื่อทำความเข้าใจความสามารถของผู้ค้นหา

  • เมื่อบิต 4 เป็น 0 ผู้ให้บริการจะไม่สนใจบิต 5 และตอบกลับด้วยรูปแบบ type 0x01
  • เมื่อบิตที่ 4 เป็น 1
    • สำหรับผู้ให้บริการ LE เท่านั้น ผู้ให้บริการจะต้องตอบกลับด้วย type 0x02 เพื่อระบุค่ากำหนดการเชื่อมโยง LE
    • สำหรับผู้ให้บริการในโหมดคู่ จะตอบกลับด้วย type 0x02 เพื่อระบุการตั้งค่าการจับคู่ BR/EDR หรือ LE
  • สำหรับกรณีผู้ให้บริการโหมดคู่ LE Audio (LEA) โปรดดูตัวอย่าง: การจับคู่กับผู้ให้บริการโหมดคู่ LEA เพื่อเป็นข้อมูลอ้างอิง

ลักษณะของ PSM (Protocol Service Multiplexor) ของสตรีมข้อความ

หากต้องการรองรับสตรีมข้อความสำหรับอุปกรณ์ BLE การจับคู่ด่วนจะสร้างและ รักษาช่อง L2CAP ของ BLE เพื่อส่งและรับข้อความ จับคู่ด่วน เซิร์ฟเวอร์ L2CAP จะต้องใช้การควบคุมโฟลว์ตามเครดิต LE

ลักษณะนี้ช่วยให้ Seeker อ่านค่า PSM แล้วสร้างการเชื่อมต่อ L2CAP ที่ปลอดภัยด้วยค่า PSM

ลักษณะของบริการการจับคู่ด่วน มีการเข้ารหัส สิทธิ์ UUID
PSM ของสตรีมข้อความ ใช่ อ่าน FE2C1239-8366-4814-8EB0-01DE32100BEA
Octet ประเภทข้อมูล คำอธิบาย ค่า
0 uint8 รัฐ
  • 0x00 = ไม่ทราบ FP Seeker จะลองอีกครั้งหลายครั้ง
  • 0x01 = พร้อมเชื่อมต่อ
  • 0x02 = ไม่พร้อมใช้งาน FP Seeker จะไม่ใช้คอมโพเนนต์นี้ในการเชื่อมต่อในครั้งนี้
 แตกต่างกันไป
1 - 2 uint16 ค่า PSM ต้องอยู่ในช่วง 0x80 ถึง 0xFF แตกต่างกันไป

หมายเหตุ: สำหรับ TWS จะมีคอมโพเนนต์ 2 อย่าง ได้แก่ คอมโพเนนต์หลักและคอมโพเนนต์รอง บทบาทสำหรับคอมโพเนนต์เหล่านี้สามารถ สลับกันได้ในบางเงื่อนไข สมมติว่า A เป็นคอมโพเนนต์หลักและ B เป็น คอมโพเนนต์รอง เนื่องจากแบตเตอรี่ของคอมโพเนนต์ A หมด คอมโพเนนต์ B จึงต้อง รับบทบาทเป็นคอมโพเนนต์หลัก และสถานการณ์นี้เรียกว่า role switch

หลังจาก role switch หากผู้ให้บริการ จัดการสตรีมข้อความการจับคู่ด่วนไม่ได้ ผู้ให้บริการจะต้องยกเลิกการเชื่อมต่อ L2CAP ที่มีอยู่ โดยอัตโนมัติ จากนั้นอุปกรณ์ที่กำลังค้นหาการจับคู่ด่วนจะสร้างการเชื่อมต่อสตรีมข้อความ L2CAP กับคอมโพเนนต์หลักใหม่ได้อีกครั้ง

ลักษณะเพิ่มเติมของพาสคีย์

ลักษณะนี้มีไว้เพื่อป้องกันการโจมตีแบบ MITM ในคอมโพเนนต์เพิ่มเติม

CSIS Fake Member MITM Protection

การจับคู่ด่วนต้องมีการป้องกัน MITM ซึ่งเป็นส่วนหนึ่งของขั้นตอนการจับคู่ เนื่องจาก CSIS ไม่มีการป้องกัน MITM การออกแบบ FP ปัจจุบันสำหรับคอมโพเนนต์หลายรายการ จึงต้องขยายเพื่อให้การป้องกัน MITM ในคอมโพเนนต์เพิ่มเติม

คำจำกัดความลักษณะ

ลักษณะบริการการจับคู่ด่วน มีการเข้ารหัส สิทธิ์ UUID
พาสคีย์เพิ่มเติม ใช่ อ่าน เขียน แจ้งเตือน FE2C123A-8366-4814-8EB0-01DE32100BEA

ข้อความ

ระบบจะใช้รูปแบบข้อความกับการดำเนินการอ่าน เขียน และแจ้งเตือน

รูปแบบข้อมูลที่เข้ารหัส

ระบบจะส่งข้อมูลที่เข้ารหัสโดยใช้การเชื่อมต่อ GATT ของการจับคู่ด่วน

Octet ประเภทข้อมูล คำอธิบาย ค่า
0-15 uint128 บล็อกพาสคีย์เพิ่มเติมที่เข้ารหัส แปรเปลี่ยน
รูปแบบข้อมูลดิบ

หลังจากถอดรหัสข้อมูลที่เข้ารหัสโดยใช้ข้อมูลลับที่ใช้ร่วมกันแล้ว รูปแบบจะเป็นดังนี้

Octet ประเภทข้อมูล คำอธิบาย ค่า
0 uint8 ประเภทของข้อความ 1 ใน
  • 0x00 = พาสคีย์ของ Seeker
  • 0x01 = พาสคีย์ของผู้ให้บริการ
1-3 uint24 พาสคีย์ 6 หลัก แปรเปลี่ยน
4-9 uint48 ที่อยู่ของคอมโพเนนต์การเชื่อมเป้าหมาย แปรเปลี่ยน
10 uint8 รหัสสถานะ ใช้โดยการดำเนินการอ่านเท่านั้น ข้อใดข้อหนึ่ง
  • 0x00 = สำเร็จ
  • 0x01 = รอดำเนินการ FP Seeker ลองใหม่จนกว่าจะหมดเวลา
  • 0x02 = ไม่สำเร็จ FP Seeker stop retry
11-15 ค่าแบบสุ่ม (Salt) แปรเปลี่ยน

ส่วนประกอบหลัก (ส่วนประกอบแรกที่เชื่อมต่อ) คือบริดจ์ระหว่างตัวค้นหาจับคู่ด่วนกับส่วนประกอบการเชื่อมต่อเพิ่มเติม ลักษณะเฉพาะต้องเป็นไปตามหลักเกณฑ์ต่อไปนี้

  • เมื่อได้รับคำขอเขียนจาก Fast Pair Seeker ผู้ให้บริการต้องดำเนินการดังนี้
    • ตั้งค่าที่อยู่ของคอมโพเนนต์ที่จะเชื่อมโยง
    • ส่งพาสคีย์ไปยังคอมโพเนนต์ที่จะจับคู่
    • ตั้งรหัสสถานะเป็นรอดำเนินการ 0x01
  • เมื่อได้รับคำขออ่านก่อนได้รับพาสคีย์จากคอมโพเนนต์ ที่กำลังเชื่อมโยง ผู้ให้บริการจะต้องส่งคืนข้อความที่มี
    • พาสคีย์ ค่าใดก็ได้
    • ที่อยู่ของคอมโพเนนต์ที่จะเชื่อม
    • รหัสสถานะรอดำเนินการ 0x01
  • ก่อนที่ผู้ให้บริการจะส่งการแจ้งเตือนไปยังอุปกรณ์ที่ค้นหาการจับคู่ด่วน ให้ตั้งค่าผลลัพธ์ สำหรับคำขออ่านด้วย
    • พาสคีย์จากคอมโพเนนต์ที่กำลังเชื่อมต่อ
    • ที่อยู่ของคอมโพเนนต์ที่จะเชื่อม
    • รหัสสถานะสำเร็จ 0x00
  • หากเกิดข้อผิดพลาดที่กู้คืนไม่ได้ในฝั่งผู้ให้บริการ ให้ตั้งค่าผลลัพธ์
    • พาสคีย์ ค่าใดก็ได้
    • ที่อยู่ของคอมโพเนนต์ที่จะเชื่อม
    • รหัสสถานะล้มเหลว 0x02

ดูรายละเอียดเพิ่มเติมได้ที่แผนภาพ MITM 1 และ แผนภาพ MITM 2

ข้อกำหนดของอุปกรณ์ LE

LE Advertising

สำหรับโหมดที่ค้นพบได้หรือโหมดที่ค้นพบไม่ได้ ผู้ให้บริการต้องใช้ RPA เพื่อ โฆษณาข้อมูล Fast Pair

ความสามารถในการเชื่อมต่อ

สำหรับอุปกรณ์ที่รองรับ LE ผู้ค้นหาต้องสร้างการเชื่อมต่อกับ การเชื่อมต่อ LE ที่มีอยู่ หลังจากผ่านการยืนยันการจับคู่ตามคีย์การจับคู่ด่วนแล้ว ผู้ให้บริการจะต้องอนุญาตการเชื่อมต่อกับ RPA และตั้งค่าความสามารถของ IO เป็น DisplayYesNo สำหรับการยืนยันรหัสผ่านการจับคู่ด่วน

ข้อกำหนดของอุปกรณ์ LEA

LEA Advertising

สำหรับอุปกรณ์แบบ 2 โหมด สำหรับโหมดที่ค้นพบได้ ผู้ให้บริการจะต้องโฆษณาข้อมูลการจับคู่ด่วนด้วยที่อยู่ระบุตัวตน สำหรับโหมดที่ค้นหาไม่ได้ ผู้ให้บริการจะต้องโฆษณาข้อมูลการจับคู่ด่วนด้วย RPA ขอแนะนำอย่างยิ่งให้ใช้การโฆษณาเดิม (BT 4.2) เพื่อรองรับอุปกรณ์รุ่นเก่า เพื่อให้เข้ากันได้แบบย้อนหลัง คุณต้องเปลี่ยน IRK ทุกครั้งที่รีเซ็ตอุปกรณ์เป็นค่าเริ่มต้น

สำหรับอุปกรณ์ที่ไม่ใช่แบบดูอัลโหมด สำหรับโหมดที่ค้นพบได้หรือโหมดที่ค้นพบไม่ได้ ผู้ให้บริการจะต้องใช้ การโฆษณาแบบขยาย (BT 5.0) ที่มี RPA เพื่อโฆษณาข้อมูล Fast Pair

โฆษณาที่เชื่อมต่อได้ของ LE ซึ่งมีข้อมูลบริการ FP ต้องมี UUID ของ CAS ตามข้อกำหนดของโปรไฟล์อะแดปเตอร์บลูทูธ (BAP 1.0.1) และโปรไฟล์เสียงทั่วไป

ผู้ให้บริการสามารถระบุความสามารถของ LEA ได้โดยการรวม UUID ของ CAS (0x1853) ไว้ในข้อมูลบริการ (ประเภท AD 0x16) หรือ UUID ของคลาสบริการแบบ 16 บิต (ประเภท AD 0x02 หรือ 0x03) โดยไม่คำนึงถึงโหมดที่ค้นพบได้

สำหรับโฆษณาที่ค้นพบไม่ได้ หากมีพื้นที่ไม่เพียงพอในโฆษณารุ่นเดิมเนื่องจากการรวมข้อมูลแบตเตอรี่และ SASS คุณจะต้องรวม UUID ของ CAS ไว้ในการตอบกลับการสแกนในกรณีนั้น

ความสามารถในการเชื่อมต่อ LEA

Seeker ต้องสร้างการเชื่อมต่อกับ LE ที่มีอยู่ หลังจากผ่านการยืนยันการจับคู่ตามคีย์ของ Fast Pair แล้ว ผู้ให้บริการโหมดคู่จะต้องอนุญาตการเชื่อมต่อกับที่อยู่ประจำตัวและ RPA ในขณะที่ผู้ให้บริการที่ไม่ใช่โหมดคู่จะต้องอนุญาตการเชื่อมต่อกับ RPA และตั้งค่าความสามารถของ IO เป็น DisplayYesNo สำหรับการยืนยันพาสคีย์ของ Fast Pair

ช่องทางการสื่อสารภายในระหว่างคอมโพเนนต์

ระบบจะคงการเชื่อมต่อ GATT ที่มีอยู่ไว้เพื่อดำเนินการป้องกัน MITM ใน คอมโพเนนต์เพิ่มเติม คอมโพเนนต์ที่ผูกหลักจะจัดการการนำส่งข้อความ ระหว่างอุปกรณ์ที่ใช้ฟีเจอร์จับคู่ด่วนและคอมโพเนนต์ที่เหลือ

การสื่อสารภายในใช้สำหรับ Initial Pair และ Subsequent Pair

  • เมื่อขั้นตอนการจับคู่ตามคีย์ผ่านคอมโพเนนต์หลัก คอมโพเนนต์หลัก จะต้องส่งข้อความเพื่อเปลี่ยนความสามารถของ IO ของคอมโพเนนต์ที่เหลือ
  • เมื่อการจับคู่ด่วนเสร็จสมบูรณ์ คอมโพเนนต์หลักจะส่งข้อความเพื่อรีเซ็ตความสามารถของ I/O ของคอมโพเนนต์ที่เหลือ
  • เมื่อเรียกใช้ขั้นตอนรหัสผ่านเพิ่มเติม คอมโพเนนต์หลักจะจัดการ การส่งรหัสผ่านระหว่างเครื่องมือค้นหาการจับคู่ด่วนกับคอมโพเนนต์ที่เหลือ

เวลาในการเปลี่ยนความสามารถของ IO

  • เปลี่ยนความสามารถของ IO เป็น DisplayYesNo เมื่อขั้นตอนการจับคู่ตามคีย์ผ่าน
    • หากอุปกรณ์มีคอมโพเนนต์หลายรายการ ให้ตั้งค่าคอมโพเนนต์ทั้งหมดเป็น DisplayYesNo
    • ข้อยกเว้นหนึ่งที่ผู้ให้บริการต้องไม่เปลี่ยนความสามารถของ IO เป็น DisplayYesNo คือ Retroactive Pair ซึ่งบิตที่ 3 ของคำขอการจับคู่ตามคีย์ตั้งค่าเป็น 1 ดูข้อความจากผู้ค้นหาถึงผู้ให้บริการ
  • เปลี่ยนความสามารถของ IO เป็นการตั้งค่าเริ่มต้น
    • การจับคู่ครั้งแรก
      • หากการเชื่อมต่อ LE ถูกตัด ให้สิ้นสุดเซสชันการจับคู่ด่วน
      • หลังจากจับคู่อุปกรณ์หลักแล้ว หากไม่มีคำขอเขียนพาสคีย์เพิ่มเติม ภายใน 15 วินาที ให้สิ้นสุดเซสชันจับคู่ด่วน
      • หลังจากได้รับคำขอเขียนพาสคีย์เพิ่มเติม หากคอมโพเนนต์ ที่กำลังเชื่อมต่อไม่ได้เชื่อมต่อภายใน 15 วินาที ให้สิ้นสุดเซสชันการจับคู่ด่วน
      • หลังจากเชื่อมต่อคอมโพเนนต์ทั้งหมดแล้ว หากไม่มีคำขอเขียนคีย์บัญชี ภายใน 15 วินาที ให้สิ้นสุดเซสชันการจับคู่ด่วน
      • หลังจากได้รับคำขอเขียนคีย์บัญชี ให้ตั้งค่าหมดเวลาเป็น 15 วินาทีเพื่อ สิ้นสุดเซสชันการจับคู่ด่วน
    • การจับคู่ครั้งถัดไป
      • หากการเชื่อมต่อ LE ถูกตัด ให้สิ้นสุดเซสชันการจับคู่ด่วน
      • หลังจากเชื่อมโยงอุปกรณ์หลักแล้ว หากไม่มีคำขอเขียนพาสคีย์เพิ่มเติมภายใน 15 วินาที ให้สิ้นสุดเซสชันจับคู่ด่วน
      • หลังจากได้รับคำขอเขียนพาสคีย์เพิ่มเติม หากคอมโพเนนต์ ที่กำลังเชื่อมต่อไม่ได้เชื่อมต่อภายใน 15 วินาที ให้สิ้นสุดเซสชันการจับคู่ด่วน
      • เมื่อเชื่อมต่อคอมโพเนนต์ทั้งหมดแล้ว ให้สิ้นสุดเซสชันการจับคู่ด่วน

ซ่อนข้อบ่งชี้ UI

เมื่อชุดหูฟังไม่พร้อมสำหรับการจับคู่ ผู้ให้บริการต้องใช้ type 0b0010 เพื่อตั้งค่าการซ่อนข้อบ่งชี้ UI สำหรับข้อมูลคีย์บัญชีเพื่อแจ้งให้ผู้ค้นหาไม่แสดง UI การจับคู่ที่ตามมา (ดูเพย์โหลดการโฆษณา: ข้อมูลบัญชี Fast Pair)

ข้อกำหนดของอุปกรณ์ LE Audio

ข้อกำหนดสำหรับบลูทูธ

ดูคำแนะนำเกี่ยวกับชุดหูฟัง LE Audio สำหรับ Android

การสนับสนุน CTKD

สำหรับอุปกรณ์แบบ 2 โหมด จะต้องมี CTKD จาก LE ไปยัง BR/EDR และสอดคล้องกับข้อกำหนดของ BAP

ประกาศเกี่ยวกับเป้าหมาย

อุปกรณ์ต่อพ่วงต้องใช้การประกาศที่กำหนดเป้าหมายเพื่อขอการเชื่อมต่อ จากอุปกรณ์ส่วนกลางที่จับคู่ไว้ ประกาศที่กำหนดเป้าหมายจะกำหนดไว้ใน BAP และ CAP สำหรับการจัดการการเชื่อมต่อตามตารางที่ 8.4 (หน้า 48/58) ของ CAP 1.0

รองรับเซิร์ฟเวอร์ GATT EATT

EATT ช่วยให้อุปกรณ์ส่วนกลางส่งธุรกรรม GATT หลายรายการแบบขนานได้ เมื่ออุปกรณ์เชื่อมต่อแล้ว สำหรับอุปกรณ์ที่รองรับ CSIP ระบบจะเพิ่ม ประสิทธิภาพการเชื่อมต่อโปรไฟล์ แล้วเริ่มกระบวนการจับคู่ CSIP สำหรับหูฟังเอียร์บัดอื่นๆ ในเร็วๆ นี้

หากผู้ให้บริการไม่ใช่เพียงอุปกรณ์เดียว แต่เป็นชุดอุปกรณ์ที่ประสานงานกันซึ่งมีการติดตั้งใช้งาน CSIP เพื่อลดจำนวนครั้งในการค้นหาบริการและเพิ่มความเร็วในการเชื่อมต่อ ผู้ให้บริการควรติดตั้งใช้งานการแคช GATT ที่กำหนดไว้ใน Bluetooth 5.1

ข้อกำหนดการจับคู่ด่วน

LE Advertising

สำหรับโหมดที่ค้นพบได้หรือโหมดที่ค้นพบไม่ได้ หากอุปกรณ์มีคอมโพเนนต์หลายรายการ คอมโพเนนต์หลักจะต้องโฆษณาข้อมูลการจับคู่ด่วน หากอุปกรณ์ไม่พร้อมสำหรับการจับคู่ครั้งต่อๆ ไป คอมโพเนนต์รองจะโฆษณาข้อมูลการจับคู่ด่วนสำหรับฟีเจอร์เพิ่มเติมได้ ดูซ่อนข้อบ่งชี้ UI

ระดับการเข้าถึงบริการ GATT

ฐานข้อมูล GATT ต้องเหมือนกันสำหรับการเชื่อมต่อ GATT ของการรับส่ง LE ทั้งหมด บริการ LE Audio (0x184E) จะต้องรวมอยู่ในฐานข้อมูล GATT ของการเชื่อมต่อการจับคู่ด่วน

ตัวอย่าง: การจับคู่กับผู้ให้บริการโหมดคู่ LEA

สถานการณ์ที่ 1 - เมื่อ Seeker ไม่รองรับ LEA

ผู้ให้บริการต้องมีความเข้ากันได้แบบย้อนหลังกับผู้ค้นหาที่ไม่รองรับ LEA

คอมโพเนนต์
  • ผู้ให้บริการ: A2DP/HFP/LEA
  • Seeker: A2DP/HFP
ลักษณะการทำงานที่คาดไว้สำหรับการจับคู่ครั้งแรก / การจับคู่ครั้งต่อๆ ไป
  • ผู้ให้บริการจะโฆษณาข้อมูลบริการ Fast Pair (0xFE2C) โดยใช้ที่อยู่ระบุตัวตน (ครั้งแรก) หรือ RPA (ครั้งต่อๆ ไป)
    • ใช้การโฆษณาเดิม
  • ผู้ขอรับบริการจะได้รับโฆษณาของผู้ให้บริการพร้อมที่อยู่ประจำตัวสำหรับการจับคู่ครั้งแรกหรือ RPA สำหรับการจับคู่ครั้งต่อๆ ไป
  • Seeker ส่งคำขอการจับคู่ตามคีย์
    • ตั้งค่าบิตแฟล็ก 5 ของคำขอการจับคู่ตามคีย์เป็น 0
  • ผู้ให้บริการจะส่งการตอบกลับการจับคู่ตามคีย์พร้อมที่อยู่สาธารณะในรูปแบบใดรูปแบบหนึ่งต่อไปนี้
    • หากใช้ข้อความประเภท 0x01 ที่อยู่จะต้องเป็นที่อยู่สาธารณะ
    • หากใช้ข้อความประเภท 0x02
      • บิตที่ 0 ต้องเป็น 0
      • บิตที่ 1 ต้องเป็น 0
      • ที่อยู่ต้องเป็นที่อยู่สาธารณะ
  • Seeker สร้างการเชื่อมต่อกับ BR/EDR transport
    • ตั้งค่าความสามารถของ IO เป็น DisplayYesNo สำหรับ BR/EDR
  • ผู้ค้นหาและผู้ให้บริการทำตามขั้นตอนการยืนยันพาสคีย์ของการจับคู่ด่วน

สถานการณ์ที่ 2 - เมื่อผู้ค้นหาข้อมูลรองรับ LEA

คอมโพเนนต์
  • ผู้ให้บริการ
    • รองรับ A2DP/HFP/LEA
    • คอมโพเนนต์เดียว
  • ผู้บรรยาย
    • รองรับ A2DP/HFP/LEA
ลักษณะการทำงานที่คาดไว้สำหรับการจับคู่ครั้งแรก / การจับคู่ครั้งต่อๆ ไป
  • ผู้ให้บริการจะโฆษณาข้อมูลบริการ Fast Pair (0xFE2C) โดยใช้ที่อยู่ระบุตัวตน (ครั้งแรก) หรือ RPA (ครั้งต่อๆ ไป)
    • ใช้การโฆษณาเดิม
  • Seeker ส่งคำขอการจับคู่ตามคีย์
    • ตั้งค่าบิตแฟล็ก 5 ของคำขอการจับคู่ตามคีย์เป็น 1
  • ผู้ให้บริการจะส่งการตอบกลับการจับคู่ตามคีย์ที่มีประเภทข้อความ 0x02
    • บิตที่ 0 ต้องเป็น 0
    • บิตที่ 1 ต้องเป็น 1
    • ที่อยู่คือที่อยู่ของข้อมูลประจำตัว
  • Seeker สร้างการเชื่อมต่อกับ การเชื่อมต่อ LE ที่มีอยู่ในการรับส่ง LE
    • ทิศทาง CTKD คือจาก LE ไปยัง BR/EDR
    • ตั้งค่าความสามารถของ IO เป็น DisplayYesNo สำหรับ LE
  • ผู้ค้นหาและผู้ให้บริการทำตามขั้นตอนการยืนยันพาสคีย์ของการจับคู่ด่วน

สถานการณ์ที่ 3 - เมื่อผู้ค้นหาให้การสนับสนุน LEA และ CSIP ที่เกี่ยวข้อง

คอมโพเนนต์
  • ผู้ให้บริการ
    • รองรับ A2DP/HFP/LEA
    • คอมโพเนนต์หลายรายการ
      • คอมโพเนนต์หลักคือ BR/EDR/LE
      • คอมโพเนนต์รองใช้ได้เฉพาะกับ LE
  • ผู้บรรยาย
    • รองรับ A2DP/HFP/LEA
ลักษณะการทำงานที่คาดไว้สำหรับการจับคู่ครั้งแรก / การจับคู่ครั้งต่อๆ ไป
  • คอมโพเนนต์หลักจะโฆษณาข้อมูลบริการ Fast Pair (0xFE2C) ด้วยที่อยู่ระบุตัวตน (เริ่มต้น) หรือ RPA (ต่อมา)
    • ใช้การโฆษณาเดิม
  • Seeker ส่งคำขอการจับคู่ตามคีย์ไปยังคอมโพเนนต์หลัก
    • ตั้งค่าบิตแฟล็ก 5 ของคำขอการจับคู่ตามคีย์เป็น 1
  • คอมโพเนนต์หลักจะส่งการตอบกลับการจับคู่ตามคีย์ที่มีประเภทข้อความ 0x02
    • บิตที่ 0 ต้องเป็น 0
    • บิตที่ 1 ต้องเป็น 1
    • ที่อยู่มีดังนี้
      • ที่อยู่แรกคือที่อยู่ประจำตัวของคอมโพเนนต์หลัก
      • ที่อยู่รายการที่ 2 คือที่อยู่ที่เชื่อมโยงได้สำหรับคอมโพเนนต์รอง คอมโพเนนต์ที่ 2 จะใช้ที่อยู่นี้เพื่อโฆษณา CSIP ด้วย
  • Seeker สร้างการเชื่อมต่อกับคอมโพเนนต์หลัก ในการเชื่อมต่อ LE ที่มีอยู่
    • ทิศทาง CTKD คือจาก LE ไปยัง BR/EDR
    • ตั้งค่าความสามารถของ IO เป็น DisplayYesNo สำหรับ LE
  • Seeker สร้างการเชื่อมต่อกับคอมโพเนนต์รอง ซึ่งมีที่อยู่จาก Key-based Pairing Extended Response
    • ความสามารถของ IO ต้องเป็น DisplayYesNo ไม่เช่นนั้นให้ปฏิเสธคำขอจับคู่
  • ผู้ขอและผู้ให้บริการจะทำตามขั้นตอนการป้องกัน MITM เพื่อจับคู่ คอมโพเนนต์รอง ผู้ให้บริการจะต้องใช้ทั้ง 2 สถานการณ์
  • ผู้ค้นหาจะรอจนกว่าจะเชื่อมต่อกับคอมโพเนนต์รอง

แผนภาพลำดับสำหรับ MITM

เซสชันนี้มีไว้เพื่ออธิบายลำดับขั้นตอนการป้องกันการโจมตีแบบ MITM

รับพาสคีย์จากคอมโพเนนต์ที่เชื่อมโยงโดยการแจ้งเตือน

รับพาสคีย์จากคอมโพเนนต์ที่เชื่อมโยงโดยการอ่าน

ปัญหาที่เป็นที่ทราบแล้ว

FP สำหรับ LEA ได้รับการเพิ่มประสิทธิภาพให้ทำงานร่วมกับ Android V(Android 15)

ในทางกลับกัน เราพบปัญหามากมายกับชุดหูฟังที่รองรับ LEA แต่ไม่มีการติดตั้งใช้งานจับคู่ด่วนที่ถูกต้องผ่าน LEA (เช่น จับคู่ด่วนผ่าน Classic เท่านั้น) เช่น เมื่อไม่ได้สร้าง RPA ของผู้ให้บริการ ด้วยคีย์การแก้ปัญหาข้อมูลระบุตัวตน (IRK) ที่ถูกต้อง และไม่สามารถแก้ปัญหาที่อยู่ได้ แม้ว่าเราจะยังไม่ได้ทดสอบรายการการกำหนดค่าชุดหูฟังที่ครอบคลุม แต่การทดสอบแบบจำกัดของเราพบปัญหาต่างๆ ซึ่งรวมถึงการไม่แสดงการแจ้งเตือนแบตเตอรี่ของหูฟังเอียร์บัด การไม่มีฟังก์ชันการสลับเสียง (SASS) การจับคู่ครั้งแรกและครั้งต่อๆ ไปล้มเหลวในวงกว้าง และอื่นๆ

ดังนั้น เราขอแนะนำให้พาร์ทเนอร์ใช้ข้อกำหนด Fast Pair-LEA สำหรับทั้งอุปกรณ์ใหม่และอุปกรณ์ที่มีอยู่ (ผ่านการอัปเดตทางอากาศ) ที่รองรับโหมดคู่