1 Reply Latest reply on Feb 26, 2020 8:16 AM by siaz_4422716

    Secure access of GATT Characteristic




      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



          Generic Attribute Profile

      Primary Service



          Vendor specific




          Vendor specific




          Characteristic User Description




          Client Characteristic Configuration

      [my_dev]# select-attribute /org/bluez/hci0/dev_40_80_72_FE_22_67/service0007/char0008

      [my_dev:/service0007/char0008]# read


      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                                                                                              


      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 ?




        • 1. Re: Secure access of GATT Characteristic

          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) */