nrf51288-DK BLE peripheral security

The Pixl would support this, yes - all of the official Espruino Bluetooth boards have it enabled.

I would expect that the read/write would fail if the security restrictions weren't met - as you figured out something like NRF.setSecurity({passkey:"123456", mitm:1, display:1}); should do it I'd have thought.

However: The Pixl will remember the pairing info from last time - which may not be secure. Have you tried setting it all up, then clearing the bonding info on your phone and connecting again and seeing if that works better?

Hi Gordon,
Yes, I've reset on both sides (on Pixl, wiping the flash and hard booting before pushing a new config; on the phones, deleting the pairing and powering bluetooth off/on). It's usually pretty clear in the WireShark trace when an existing pairing relationship is present so I'm confident it's forgotten.

Do I understand you correctly that the security configuration in the characteristic is passive (i.e. not used in determining the bonding requirements)? If that's the case then having the possibility to indicate different sets of requirements per characteristics seems over the top as it can never influence the setup.

I've tried using NRF.setSecurity({passkey:"123456", mitm:1, display:1}); and combinations thereof to no avail. As I mentioned it doesn't even appear in a dump() once it is pushed so I'm not sure what's happening.

From your WireShark trace, when secure request is made, your central provides "SecureConnection, MITM & Bonding" auth parameters. I'm just guessing that this is what your central wants to have, i.e. it is requesting to establish secure link with MITM and also store keys. I'm speculating again, this list of parameters is made by Bluez based on peripheral advertisement packages (which contains some capabilities flags). I think your central (bluez) does not specify lesc parameter just because it does not know if your peripheral supports it, It could be that you have to set up your peripheral to advertise lesc capability so that Bluez knows what to do.

Can you please try to set this?

NRF.setSecurity({lesc: 1});

I assume that this will make your peripheral to advertise that it supports lesc and give a hint for Bluez to try to use lesc algorithm.

Hi Vlad,

Secure Connection is LESC - it's the 5th bit in the AuthReq byte (see screenshot). I'm not using Bluez and peripheral advertisement packets do not include anything about the security capabilities. But, yes, this is the security association desired by the central (Android and iOS).

So here the central is requesting Bonding, MITM and LESC. The response from the Pixl only indicates Bonding (screenshot is of the Pixl response), so it proceeds without the other two.

I have re-run with the following configuration to exactly the same result - no success.

NRF.setSecurity({lesc: 1});

NRF.setServices({
  0xBCDE : {
    0xABCD : {
      value : "Hello", // optional
      maxLen : 5, // optional (otherwise is length of initial value)
      readable : true,   // optional, default is false
      writable : true,   // optional, default is false
//      notify : true,   // optional, default is false
      security: { // optional
        read: { // optional
          encrypted: false, // optional, default is false
          mitm: false, // optional, default is false
          lesc: false, // optional, default is false
          signed: false // optional, default is false
        },
        write: { // optional
          encrypted: false, // optional, default is false
          mitm: false, // optional, default is false
          lesc: true, // optional, default is false
          signed: false // optional, default is false
        }
      },
      onWrite : function(evt) { // optional
        print("Got ", evt.data); // an ArrayBuffer
      }
    }
    // more characteristics allowed
  }
  // more services allowed
});

1 Attachment

Hi @cefitzger, ~afaik Bluez is used in android~ (wrong, it used to be up until 4v). Anyways, I wonder what happens when you NRF.setSecurity({lesc: 1}); and then manually initiate bonding? This flow (central initiated) could be different to the one that you are trying to do (when peripheral responses with an error and then central automatically initiates secure connection). I'm just trying to narrow it down, there might be nothing to do with characteristic security.

Hi @Vlad,

Bluez was used in Android before 4.2 but now it uses Bluedroid as I understand. In any case, I repeated the test with iOS which definitely does not use Bluez as I couldn't get the it working as an alternative to CoreBlueTooth.

There is no way to manually(or programatically - the system decides) initiate bonding on iOS (in Android there invariably is but I'm only using that as a control for iOS, not developing on it).

It does appear that it is not related to the characteristic security as it is the system level that fails to respond with the appropriate Auth Response (the Insufficient Auth message does not contain any info on the required Auth - that is the responsibility of the AuthReq sequence). Looking to @Gordon for an update on the NRF.setSecurity configs not working.

I still think having a simply security yes/no at the characteristic level is the right approach. If the settings there are declarative (cannot influence the bonding) because the system handles the bonding, having options that have no effect will result in failures where there are mismatches.

Looks like NRF.setSecurity updates the peer manager settings immediately and also saves state so it can be restored at startup. This wasn't added to what the dump() command returned, but I just fixed that.

If you're interested:

https://github.com/espruino/Espruino/blob/master/targets/nrf5x/bluetooth.c#L1849
https://github.com/espruino/Espruino/blob/master/targets/nrf5x/bluetooth.c#L1834

However pm_sec_params_set states:

Function for providing pairing and bonding parameters to use for pairing procedures.

Which implies that when pairing those security requirements will be used, but perhaps something else needs setting to ensure that pairing is forced?

Pairing and bonding are forced with the request from the master (AuthReq with the bonding flag set to 0x01) but the Pixl doesn't reply with LESC or MITM as per the NRF.setSecurity configuration. In fact it adheres exactly to the definition just above the links you provide in the bluetooth.c code:

static ble_gap_sec_params_t get_gap_sec_params() {
  ble_gap_sec_params_t sec_param;
  memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));

  // Security parameters to be used for all security procedures.
  // All set to 0 beforehand, so
  sec_param.bond           = 1;                     /**< Perform bonding. */
  //sec_param.mitm           = 0;                     /**< Man In The Middle protection not required. */
  //sec_param.lesc           = 0;                     /**< LE Secure Connections not enabled. */
  //sec_param.keypress       = 0;                     /**< Keypress notifications not enabled. */
  sec_param.io_caps        = BLE_GAP_IO_CAPS_NONE;  /**< No I/O capabilities. */
  //sec_param.oob            = 0;                     /**< Out Of Band data not available. */
  sec_param.min_key_size   = 7;                     /**< Minimum encryption key size. */
  sec_param.max_key_size   = 16; 

This is the exact configuration proposed by the Pixl to the central as seen in the trace.

I haven't got a build environment set up - any chance you could supply a build with the following parameter definitions for me to test in case it's the update process that isn't working?

static ble_gap_sec_params_t get_gap_sec_params() {
  ble_gap_sec_params_t sec_param;
  memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));

  // Security parameters to be used for all security procedures.
  // All set to 0 beforehand, so
  sec_param.bond           = 1;                     /**< Perform bonding. */
  sec_param.mitm           = 1;                     /**< Man In The Middle protection required. */
  sec_param.lesc           = 1;                     /**< LE Secure Connections enabled. */
  //sec_param.keypress       = 0;                     /**< Keypress notifications not enabled. */
  sec_param.io_caps        = BLE_GAP_IO_CAPS_NONE;  /**< No I/O capabilities. */
  //sec_param.oob            = 0;                     /**< Out Of Band data not available. */
  sec_param.min_key_size   = 7;                     /**< Minimum encryption key size. */
  sec_param.max_key_size   = 16; 

@cefitzger, I use docker to build espruino firmware. It is a mater of 10 mins to install docker daemon and you have a proper stable environment. More details here: https://github.com/espruino/Espruino/blob/master/Dockerfile

Once you've build it first time, you can then use this docker file to speed up the process (it will just copy sources and won't install build chain):

FROM espruino:latest

COPY . /espruino
WORKDIR /espruino

ENV RELEASE 1
CMD ["bash", "-c", "source scripts/provision.sh ALL && make"]

OK, thanks. I'll give it a go next week when I get some time.

Also https://github.com/espruino/Espruino/blob/master/README_Building.md - if you have Linux set up (even the built-in 'Bash on Windows') it's just:

git clone https://github.com/espruino/Espruino
cd Espruino
source scripts/provision.sh PIXLJS
BOARD=PIXLJS DFU_UPDATE_BUILD=1 RELEASE=1 make