|
Coming soon |
1. STM32WB - BLE White List
1.1. From advertiser point of view
As soon as a device advertises with the parameter "allow scan request - allow connect request from devices in white list" (use of aci_gap_set_undirected_connectable, advertising filter policy = 0x03) No HCI_LE_ADVERTISING_REPORT events are sent by the device but it answers to SCAN_REQ.
1.2. For advertiser and scanner
To add a device in white list, devices need to be bonded. To get the address of the bonded device: use of aci_gap_get_bonded_devices thanks to which we get the number of bonded devices, address types and addresses of bonded devices. Then use aci_gap_configure_whitelist. The whitelist is written in RAM.
1.3. For scanner
An other possibility is to use for connection: aci_gap_start_auto_connection_establish_proc aci_gap_start_selective_connection_establish_proc
1.4. Add a device in White List: Phase 1
1.5. Legacy pairing and fixed pin
initiated by the peripheral
aci_gap_set_io_capability(0x00) (IO_CAP_DISPLAY_ONLY)
aci_gap_set_authentication_req(0,0,0,0,7,16,0 (use fixed pin), 111111 (used fixed pin),0)
(no bonding, no MITM, secure connection pairing not supported, keypress notification not supported, min encryption key size, max encryption key size, use of fixed pin, fixed pin (used), public address type)
1.6. Secure connection
aci_gap_set_io_capability(0x04) (IO_CAP_KEYBOARD_DISPLAY)
aci_gap_set_authentication_req(0,1,1,1,7,16,1,111111, 0)
(no bonding, MITM, secure connection pairing not supported, keypress notification not supported, min encryption key size, max encryption key size, no use of fixed pin, fixed pin (not used), public address type)
2. Additional information - BLE characteristics and security permissions
2.1. STM32WB - BLE GATT characteristic
When a characteristic is created (aci_gatt_add_char), following security permissions could be given:
- 0x00: none
- 0x01: AUTHEN_READ (need authentication to read)
- 0x02: AUTHOR_READ (need authorization to read)
- 0x04: ENCRY_READ (need encryption to read)
- 0x08: AUTHEN_WRITE (need authentication to write)
- 0x10: AUTHOR_WRITE (need authorization to write)
- 0x20: ENCRY_WRITE (need encryption to write)
2.1.1. READ and WRITE properties
A characteristic is created with properties READ and WRITE
2.2. AUTHEN_READ and AUTHEN_WRITE security permissions
After the discovery of services and characteristics, if the client tries to read or write this characteristic, an error is returned (ACI_GATT_ERROR_RESP_EVENT) with error_code=0x05 (insufficient authentication)
Set MITM (in aci_gap_set_authentication_requirement) is necessary and need of start pairing to be able to read/write the characteristic with 'need authentication' permissions.
Security permission 'need authentication' is more restrictive than 'need encryption'.
2.3. ENCRY_READ and ENCRY_WRITE security permissions
After the discovery of service and characteristic, if the client tries to read or write this characteristic, an error is returned (ACI_GATT_ERROR_RESP_EVENT) with error_code=0x0F (insufficient encryption)
If the devices are paired and encryption is started, read and write operations can be done. No need to set MITM and need of starting pairing to be able to read/write the characteristic with 'need encryption' permissions
2.4. AUTHOR_READ and AUTHOR_WRITE security permissions
The way to use characteristic with 'need authorization' permissions: after the connection_complete_event, the server sends the command aci_gap_set_authorization_requirement (for current connection handle) the master initiates pairing. When the pairing is complete, ACI_GAP_AUTHORIZATION_REQ_EVENT is generated on server side which sends aci_gap_authorization_resp(conn_handle, authorize) then the client can read/write the characteristic.