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

การใช้งานบริการจับคู่ด่วนของ Google (GFPS) สำหรับอุปกรณ์ BLE เข้ากันได้กับข้อกำหนดหลักของบลูทูธเวอร์ชัน 4.2 ขึ้นไป

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

ระดับความสอดคล้อง

ด้านล่างคือคีย์เวิร์ด "ต้อง" "ต้อง" "จะ" "ควร" "อาจ" และ "สามารถ" ที่กล่าวถึงในข้อกำหนดเฉพาะ

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

ลักษณะเฉพาะของการจับคู่คีย์ตาม

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

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

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

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

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

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

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

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

ลักษณะเฉพาะของ PSM (โปรโตคอลบริการโปรโตคอล)

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

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

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

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

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

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

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

การป้องกัน MITM สำหรับสมาชิกปลอม CSIS

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

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

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

ข้อความ

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

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

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

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

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

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

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

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

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

ข้อกำหนดของ LE Device

โฆษณา LE

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

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

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

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

การโฆษณา LEA

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

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

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

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

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

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

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

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

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

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

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

ซ่อนสัญญาณบอกสถานะ UI

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

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

ความต้องการของบลูทูธ

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

ฝ่ายสนับสนุนของ CTKD

สำหรับอุปกรณ์ Dual Mode จำเป็นต้องมี CTKD จาก LE ไปยัง BR/EDR ในลักษณะที่สอดคล้องกับ ข้อกำหนดของ BAP

ประกาศเป้าหมาย

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

การสนับสนุนเซิร์ฟเวอร์ GATT EATT

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

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

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

โฆษณา LE

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

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

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

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

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

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

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

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

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

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

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

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

เซสชันนี้จะอธิบายลำดับของกระบวนการป้องกันของ MITM

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

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

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

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

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

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