We are on the process to secure our bluetooth device based on CYBT-213043-02 module
We use ModusToolBox Version: 2.0.0
Wiced BT SDK version : release-v2.1.0
We use CYBT-213043-EVAL has development board for this project
You will find our project based on Exercise 4B.4 attach to this post.
Our Bluetooth pairing device is an Ubuntu 18.04 running Bluez stack/Bluetoothctl v5.48
Another bluetooth pairing device is an debian running Bluez stack/Bluetoothctl v5.50
The first state that we want to achieve is to validated the paring/bonding with a Passkey Entry.
Then we want to constrain the read/write/notify access of Gatt Characteristic only to the client that have been already paired (with the passkey process).
Following the labs ( https://github.com/cypresssemiconductorco/CypressAcademy_WBT101_Files ) one way to achieve this goal is to follow the Exercise 4B.4 (Advanced) Add a Pairing Passkey from WBT101-04B-BLE-Ntfy-Sec.pdf
To secure our GATT access we understood that we need to fill the Read (authentificated) box on Bluetooth Configurator in each characteristic permissions that we want to protect
Using this setup we observe the following behaviour when trying to read a characteristic "Counter" implemented as Read (authentificated) :
Performing a connect to the device with bluez, without asking for pairing.
Request a read on the characteristic "Counter"
[bluetooth]# connect 40:80:72:FE:22:67
Attempting to connect to 40:80:72:FE:22:67
[CHG] Device 40:80:72:FE:22:67 Connected: yes
[my_dev]# menu gatt
Generic Attribute Profile
Characteristic User Description
Client Characteristic Configuration
[my_dev]# select-attribute /org/bluez/hci0/dev_40_80_72_FE_22_67/service0007/char0008
The "read" command in bluez trigger a automatic pairing request to the device and the following Bluetooth Management event :
BT EVENT 13 BTM_SECURITY_REQUEST_EVT
BT EVENT 10 BTM_PAIRING_IO_CAPABILITIES_BLE_REQUEST_EVT
BT EVENT 12 BTM_ENCRYPTION_STATUS_EVT
The GATT callback succeed since we are pairred with remote device
It seem that the WICED Stack simply ignore the PAIRING_IO_CAPABILITIES during event 10
p_event_data->pairing_io_capabilities_ble_request.auth_req = BTM_LE_AUTH_REQ_SC_MITM_BOND;
p_event_data->pairing_io_capabilities_ble_request.init_keys = BTM_LE_KEY_PENC|BTM_LE_KEY_PID;
p_event_data->pairing_io_capabilities_ble_request.local_io_cap = BTM_IO_CAPABILITIES_DISPLAY_ONLY;
And allow the device to be paired without waiting for Passkey entry, in fact BTM_PASSKEY_NOTIFICATION_EVT is not call
Have we miss something to force our security policy and force pairing using a PassKey ?