- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
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
Connection successful
[my_dev]# menu gatt
[my_dev]# list-attributes
Primary Service
/org/bluez/hci0/dev_40_80_72_FE_22_67/service0006
00001801-0000-1000-8000-00805f9b34fb
Generic Attribute Profile
Primary Service
/org/bluez/hci0/dev_40_80_72_FE_22_67/service0007
6895c920-f18a-4702-a3bf-bd6b369c2a60
Vendor specific
Characteristic
/org/bluez/hci0/dev_40_80_72_FE_22_67/service0007/char0008
0fdb4e22-39a4-4200-b89f-c6170cbd883e
Vendor specific
Descriptor
/org/bluez/hci0/dev_40_80_72_FE_22_67/service0007/char0008/desc000a
00002901-0000-1000-8000-00805f9b34fb
Characteristic User Description
Descriptor
/org/bluez/hci0/dev_40_80_72_FE_22_67/service0007/char0008/desc000b
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
[my_dev]# select-attribute /org/bluez/hci0/dev_40_80_72_FE_22_67/service0007/char0008
[my_dev:/service0007/char0008]# read
00
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 ?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We finally understood our issue.
it is then the responsability of developper to check for remote device capability before settings his own.
when we manually request for pairing with command "pair" in bluetoothctl the IO capability flag sent to device is correctly set to BTM_IO_CAPABILITIES_BLE_DISPLAY_AND_KEYBOARD_INPUT
The pairing will then be procceed like we needed (display Passkey and wait for response)
On the other side when we directly "read" the Gatt Characteristic bluez consider his own IO capability flag to BTM_IO_CAPABILITIES_DISPLAY_ONLY
Cypress WICED BT Stack will then decide to not sent the Passkey challenge and accept automatically the pairing
But we don't know what we need to return from bt_management_callback to abort the pairing, WICED_BT_ERROR does not.
What should we return to abort pairing ?
It will be also nice from cypress to upgrade the documentation about bt management callback argument structure for each state.
The following field description about capabilities doesn't explicity said that we need to check for input value :
wiced_bt_dev_io_cap_t local_io_cap; /**< local IO capabilities (to be filled by application callback) */
Thanks