Secure access of GATT Characteristic

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
siaz_4422716
Level 1
Level 1
First question asked First reply posted

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

0 Likes
1 Reply
siaz_4422716
Level 1
Level 1
First question asked First reply posted

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

0 Likes