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.

相关推荐
万户猴2 天前
【Android蓝牙-8】蓝牙安全机制全面解构:加密、认证与数据保护
蓝牙
万户猴2 天前
【Android蓝牙-七】蓝牙通信配置文件(Profile)详解:Android开发者必懂的蓝牙通信基础
蓝牙
万户猴4 天前
【Android蓝牙-六】蓝牙数据通信机制详解:GATT与ATT服务的技术实现
蓝牙
万户猴4 天前
【Android蓝牙-五】Android蓝牙配对与连接机制:从 Bonding 到 GATT 连接
蓝牙
万户猴5 天前
【Android蓝牙-四】Android 蓝牙设备发现与广播机制深度解析
蓝牙
万户猴6 天前
【Android蓝牙通信一】蓝牙扫盲篇
蓝牙
万户猴6 天前
【Android蓝牙通信三】蓝牙机制深度解析:从 API 到系统调度
蓝牙
Try1harder9 天前
ESP32-idf学习(二)esp32C3作服务端与电脑蓝牙数据交互
物联网·嵌入式·蓝牙·乐鑫·esp32c3
Json_15 天前
uni-app 框架 调用蓝牙,获取 iBeacon 定位信标的数据,实现室内定位场景
前端·uni-app·蓝牙
别说我什么都不会18 天前
【鸿蒙开发】蓝牙Socket应用开发案例
蓝牙·harmonyos