Simple fast pair design

I design the simple fast pair service authentication flow as below:

for the initial pairing: the simple fast pair authentication flow

User central device:phone peripheral device:earbuds ①:user login on the phone ②:Set as discoverable mode, and do ble advertising ③:earbud advertising data ④:parse the adv data from earbuds, no acount key filter,and pop UI to indicate user that found a new device user click "connect" on UI ⑤:generate private/public keys, get public key of earbud from remote ,which will be used to generated ASE ⑥:Write encrypted pairing request (UUID 0x1234) and non-encrypted public key of phone ⑦:get the public key of phone and private key of earbud, use them to generate ASE key. assume this key to decrypt pairing request ⑧:send key-based pairing response ⑨:decrypt pairing response which will get BR addr of earbuds ⑩:change both IO Capability to Display Yes/No for MIMT protect ⑪:Do numeric pairng,both will generate 4 bytes passkey ⑫:write passkey characteristic (UUID 0x1235)request confirm passkey to yes or no ⑬:write passkey characteristic request, encrypted by ASE key confirm passkey "yes or no" ⑭ :generate account key by ASE key ⑮:write account key to earbud earbud has no account key , so update account key for earbud ⑯:notification account key characteristic(UUID 0x1236) ⑰:get the account key from earbud, and upload it to remote server ⑱:change the IO capablity to the original ⑲:central and peripheral do the SDP and subsequence procedure User central device:phone peripheral device:earbuds

①:user login the account and get the paired devices list and the related accountkey from the remote server.

②: user open the earbuds box which will set the earbuds to discoverable and connectable mode.

③:peripheral device advertising BLE data which will including mode ID and account key filter(first pair have no account key filter) if have,and should keep advertising at least 2min

④:central device parse the adv data from earbuds, and will match mode ID, if this adv is the expected one, will compare account key filter , as for the first time pairing ,no acount key filter(6 bytes) will be found,and pop UI to indicate user that found a new device.

⑤:central device will get the public key of earbuds by mode ID from remote server, and generate public/private key locally, then calculate ASE key.

⑥:central device will send pairing request by using ASE key to encrypt pairing request data and non-encryption public key of central device.

⑦:earbuds will get the public key ,along with local private key to calculate ASE key which will be used to decrypt the pairing request data.

⑧:earbuds send the pairng response to central device, the data will be encrpted by ASE Key which include the BR addr of earbuds.

⑨:central device decrypte the pairing response data and get the BR MAC address of earbuds.

⑩: central device and periphral will change the IO Capability to Display Yes/No as for MIMT protection.

⑪:central device will initial pairing procedure by using Numeric method and will generate 6 digital(4 bytes) passkey.

⑫ ⑬:central device and peripheral do the "passkey" authentication.the passkey message will be encrypted by ASE key.

⑭ :central device will generate Account key by using ASE key.

⑮: central device will write account key characteristic (0x1236) to earbuds

⑯: peripheral device will notificate account key characteristc with local account key to the central device

⑰:get the account key from earbud, and upload it to remote server

⑱:change the IO capablity to the original

⑲:central and peripheral do the SDP and subsequence procedure

for the subsequence pairing: the simple fast pair authentication flow

User central device:phone peripheral device:earbuds ①:user login on the phone ②:Set as discoverable mode, and do ble advertising ③:earbud advertising data ④:parse the adv data from earbuds, found a acount key filter,and pop UI to indicate user that found a new device user click "connect" on UI ⑤:use the account key as ASE key ⑥:Write encrypted pairing request (UUID 0x1234) and non-encrypted public key of phone ⑦:use the local account key as ASE key to decrypt pairing request ⑧:send key-based pairing response which include BR mac of peripheral device ⑨:decrypt pairing response which will get BR addr of earbuds ⑩:change both IO Capability to Display Yes/No for MIMT protect ⑪:Do pairing by using numeric method, both will generate 4 bytes passkey ⑫:write passkey characteristic (UUID 0x1235)request confirm passkey to yes or no ⑬:write passkey characteristic request, which be encrypted by ASE key confirm passkey "yes or no" ⑭:write account key to earbud ⑮:as earbud has exist account key, so will discard it ⑯:notification account key characteristic (UUID 0x1236) ⑰:get the account key from earbud, and upload it to remote server ⑱:change the IO capablity to the original ⑲:central and peripheral do the SDP discovery and subsequence procedure User central device:phone peripheral device:earbuds

①:user login the account and get the paired devices list and the related accountkey from the remote server.

②: user open the earbuds box which will set the earbuds to discoverable and connectable mode.

③:peripheral device advertising BLE data which will including mode ID and account key filter,and should keep advertising at least 2min.

④:central device parse the adv data from earbuds, and will match mode ID, if this adv is the expected one, will compute the local accout key filter and compare account key filter with local one, if equal, and pop UI to indicate user that found a new device.

⑤:central device will use the account key as ASE key.

⑥:central device will send pairing request by using ASE key to encrypt pairing request data and non-encryption public key of central device.

⑦:earbuds will use local account key as ASE key which will be used to decrypt the pairing request data.

⑧:earbuds send the pairng response to central device, the data will be encrpted by ASE Key which include the BR addr of earbuds.

⑨:central device decrypte the pairing response data and get the BR MAC address of earbuds.

⑩: central device and periphral will change the IO Capability to Display Yes/No as for MIMT protection.

⑪:central device will initial pairing procedure by using Numeric method and will generate 6 digital(4 bytes) passkey.

⑫ ⑬:central device and peripheral do the "passkey" authentication.the passkey message will be encrypted by ASE key.

⑭ :central device will generate Account key by using ASE key.

⑮: central device will write account key characteristic (0x1236) to earbuds

⑯: peripheral device will notificate account key characteristc with local account key to the central device

⑰:get the account key from earbud, and upload it to remote server

⑱:change the IO capablity to the original

⑲:central and peripheral do the SDP and subsequence procedure

note:

1:we assume that periphral only have one account key.

2: ASE key generation method:

  • using secp256 method to generate 512 bits public key and 256 bits

    private key

  • using remote public key and local private key to generate 256 bits

    original ASE key,and then do SHA-256 hash, then get the first 128

    bits(16 bytes) of the result to treat as final ASE key.

  • account key filter in advertising data: account key has 16 bytes, we

    will do SHA128,and get the first 6bytes as account key filter which be

    show in advertising data.

相关推荐
jiang_bluetooth16 天前
Bluetooth LE AUDIO架构概述
架构·蓝牙·ble audio·le audio
WPG大大通18 天前
芯驰X9SP与汽车麦克风-打造无缝驾驶体验
车载系统·汽车·硬件工程·蓝牙·开发板·麦克风
byte轻骑兵19 天前
【0x0019】HCI_Remote_Name_Request详解
蓝牙·通信协议·hci
byte轻骑兵21 天前
【0x0001】HCI_Set_Event_Mask详解
蓝牙·通信协议·hci
宋者为王23 天前
【朝花夕拾】蓝牙&WiFi常识篇
蓝牙·p2p·热点·ap·wifi直连
AscendKing25 天前
uniapp对接蓝牙
uni-app·蓝牙
再遇当年1 个月前
小米运动健康与华为运动健康在苹手机ios系统中无法识别蓝牙状态 (如何在ios系统中开启 蓝牙 相册 定位 通知 相机等功能权限,保你有用)
ios·蓝牙·智能手表·权限·苹果手机·小米手表·小米运动健康
SuperHeroWu71 个月前
【HarmonyOS】鸿蒙应用低功耗蓝牙BLE的使用心得 (三)
华为·蓝牙·harmonyos·鸿蒙·低功耗蓝牙·ble
记帖1 个月前
STM32WB55RG开发(3)----生成 BLE 程序连接手机APP
蓝牙·stm32cubemx·ipcc·ble·无线·stm32wb55rg·hsem
记帖1 个月前
STM32WB55RG开发(1)----开发板测试
蓝牙·stm32cubemx·ble·无线·stm32wb55rg·开发板测试