BLE-STACK: Ensuring read/write only with MITM protection

Hey Jessica,

Please find below an example of one of the characteristics. Some are also writable, but other than that, they're all very similar:

      // Temperature Declaration
      {
        { ATT_BT_UUID_SIZE, characterUUID },
        GATT_PERMIT_READ,
        0,
        &temperatureProps
      },

        // Temperature Value
        {
          { ATT_BT_UUID_SIZE, temperatureUUID },
          GATT_PERMIT_AUTHEN_READ,
          0,
          (uint8_t *)&temperatureValue
        },

        // Temperature Client Characteristic Configuration
        {
          { ATT_BT_UUID_SIZE, clientCharCfgUUID },
          GATT_PERMIT_READ | GATT_PERMIT_AUTHEN_WRITE,
          0,
          (uint8_t *)&temperatureClientCharCfg
        },

        // Temperature User Description
        {
          { ATT_BT_UUID_SIZE, charUserDescUUID },
          GATT_PERMIT_READ,
          0,
          temperatureUserDesc
        },

Thanks for your help.

Good day,
Assaf

Assaf, 

Is there a reason you used "GATT_PERMIT_READ | GATT_PERMIT_AUTHEN_WRITE" instead of "GATT_PERMIT_AUTHEN_READ | GATT_PERMIT_AUTHEN_WRITE" for your client characteristic configuration? I tried reproducing your error with our simple_peripheral example and was able to get it to work. I added a password to my GAP Bond Manager like you did and changed the notify characteristic  configuration to use "GATT_PERMIT_AUTHEN_READ | GATT_PERMIT_AUTHEN_WRITE." 

-Jessica

Hey Jessica,

Jessica H. said:

Is there a reason you used "GATT_PERMIT_READ | GATT_PERMIT_AUTHEN_WRITE" instead of "GATT_PERMIT_AUTHEN_READ | GATT_PERMIT_AUTHEN_WRITE" for your client characteristic configuration?

Sadly, however, adding GATT_PERMIT_AUTHEN_READ does not solve the issue.
First off, I'll note that reading the characteristic when it requires authentication and not supplying a pass key is indeed blocked. What I saw earlier is probably some iOS caching values after they were received via notification. I needed to turn Bluetooth off and on via iOS settings for it to be cleared. Receiving still works even when authentication is needed.

I too was unable to reproduce the issue with the simple peripheral example. It seems weird since the only difference is that the simple peripheral uses a timer and I rely on an interrupt. Other than that the profile code and, specifically, sending the notification uses the same APIs.

However, I did notice that the GATTServApp_ProcessCharCfg() function for sending the notification has an "authenticated" parameter. Setting that to TRUE, does not sent notifications anymore. So that's a good enough solution for me.

With all this in mind, I was wondering what the best approach to protecting information is with BLE.
Should I only require authentication for the "sensitive" characteristics or should I also modify the SDK's standard profiles?
Do I need to protect the client characteristic configuration if the value itself requires authentication?
Perhaps it's better to initiate pairing with GAPBOND_PAIRING_MODE_INITIATE and somehow detect if a passkey was used and close the connection if not.

Thanks,
Assaf

Hey JXS,

Thank you for your input.

The client configuration characteristic was supposedly protected with GATT_PERMIT_AUTHEN_WRITE as the LightBlue app behaved differently with it (the "listen for notifications" button didn't change to "stop listening").

As for sending the notifications themselves, I'm using GATTServApp_ProcessCharCfg() when the value is changed internally (via the XXX_SetParamer() function). This seems to be on par with the simple profile.

Finally, what did make the difference in my case, was setting the "authenticated" parameter for the above function to TRUE (i.e. requiring an authenticated session before sending a notification).

When set to FALSE, notifications were sent. When it was set to TRUE, notifications were received only when I provided a passkey for pairing. To me it seems that the stack was aware of the authentication status.

I can try to grab a network dump if that's of interest to get a better understanding of what's going on.

As for terminating the connection when MITM protection is not used. I understand how to implement it, but was wondering what's the common practice to protect information. Require authentication per characteristic or initiate pairing immediately and terminated the connection if it wasn't authenticated. More to the point, does it make sense to expose the device info service (which doesn't require authentication by default) or should everything be protected?

Thanks again,

Assaf

Hey JXS,

JXS said:

The stack does load the previous CCCD values for bonded connections

When I loaded the simple peripheral example, I actually erased all flash to make sure I have a clean slate and that's why I wasn't able to reproduce it there.
I now have a better understanding of the scenarios at play here and I don't expect this to actually be an issue as the central would still need to know the passkey at one point.

I understand that caching the CCCD is part of the specifications, but I wonder if it should be cleared when bonding is done again for the same client (as is the case when removing the peripheral from the iOS settings).

Anyways, I'll mark this issue as resolved. Thanks Jessica and JXS for all your help.

Good day,
Assaf