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

    Secure access of GATT Characteristic

    siaz_4422716

      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

        • 1. Re: Secure access of GATT Characteristic
          siaz_4422716

          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