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.

相关推荐
再遇当年6 天前
小米运动健康与华为运动健康在苹手机ios系统中无法识别蓝牙状态 (如何在ios系统中开启 蓝牙 相册 定位 通知 相机等功能权限,保你有用)
ios·蓝牙·智能手表·权限·苹果手机·小米手表·小米运动健康
SuperHeroWu76 天前
【HarmonyOS】鸿蒙应用低功耗蓝牙BLE的使用心得 (三)
华为·蓝牙·harmonyos·鸿蒙·低功耗蓝牙·ble
记帖9 天前
STM32WB55RG开发(3)----生成 BLE 程序连接手机APP
蓝牙·stm32cubemx·ipcc·ble·无线·stm32wb55rg·hsem
记帖11 天前
STM32WB55RG开发(1)----开发板测试
蓝牙·stm32cubemx·ble·无线·stm32wb55rg·开发板测试
Lenzetech17 天前
科技资讯|谷歌Play应用商店有望支持 XR 头显,AR / VR设备有望得到发展
科技·物联网·ar·xr·蓝牙·find my
Lenzetech19 天前
蓝牙资讯|苹果AirPods Pro 2推出听力测试、助听器和听力保护等功能
科技·物联网·蓝牙·find my
Marko_Chai22 天前
Android BLE 杂谈
android·蓝牙
Lenzetech1 个月前
Find My平板键盘|苹果Find My技术与键盘结合,智能防丢,全球定位
科技·物联网·蓝牙·find my
Lenzetech1 个月前
蓝牙资讯|iOS 18.1 正式版下周推送,AirPods Pro 2耳机将带来助听器功能
科技·物联网·蓝牙·find my