BLE Pairing and security stack implementation

I am developing a product using the nRF51822 BLE, I was able to interface all my peripherals and setup the softdevice stack accordingly.

Now I am looking to add a pairing and security layer on the same to start the provisioning process and make the same secure.

1. The BLE device at factory reset will be active to pair and send/ receive data via the services, These services are currently open and I used nrf connect APP to communicate, can I make then hidden so that no one else can see those?How?

2. At the time when device is not bonded with any central, what should be the architecture to enable pairing. Note that the device is headless and does not have any HMI. Is there any application note or literature that I can follow to do the same?

3. Once the pairing is complete, I want the communication to be encrypted, I guess the nordic supports AES encryption, is there any example or literature I can follow?

4. Also should the authorisation process involve a digital certifacate method to make sure the pairing is safe and avoids any MITM. 

What I want exactly is to use my device over a mobile application and the pairing, communication should be secure. Any application note or literature link is highly appreciated.

Thanks and regards

  • Hi,

    1. The BLE device at factory reset will be active to pair and send/ receive data via the services, These services are currently open and I used nrf connect APP to communicate, can I make then hidden so that no one else can see those?How?

    No, there is no way to "hide" services. Once a device connects it can discover all services. There is no need to include the service(s) in advertising packets or scan response packets, though.

    2. At the time when device is not bonded with any central, what should be the architecture to enable pairing. Note that the device is headless and does not have any HMI. Is there any application note or literature that I can follow to do the same?

    That is entirely application specific, and up to you. What fits your product? Is it possible to power cycle or reset it to put it in pairing mode, for instance?

    3. Once the pairing is complete, I want the communication to be encrypted, I guess the nordic supports AES encryption, is there any example or literature I can follow?

    The nRF SDKs support standard Bluetooth pairing, both legacy pairing and LE Secure Connections. Regardless of how you pair, a secured link is always encrypted with 128 bit AES-CCM (according to the Bluetooth specification). I suggest you check out the peer manger library in nRF5 SDK 12.3.

    4. Also should the authorisation process involve a digital certifacate method to make sure the pairing is safe and avoids any MITM. 

    There is no use of certificates in the bluetooth specification. However, there are MITM protection features supported as defined in the Bluetooth specification, but all those depends on having a HMI of some sort. Without it, Bluetooth does not provide any way to guarantee MITM protection.

  • 1.

    No, there is no way to "hide" services. Once a device connects it can discover all services. There is no need to include the service(s) in advertising packets or scan response packets, though.

    Okay, so when you say scan response packets, you are talking about the pairing sequence? I am using a modified UART_BLE example code which sets the nRF in peripheral mode and can be easily connected using the nRF connect app, what do I need to do to enable a pairing method?

    2.

    That is entirely application specific, and up to you. What fits your product? Is it possible to power cycle or reset it to put it in pairing mode, for instance?

    The device is battery operated, so power cycle method is a bit out of picture. I can use make a sequence that enables the device to pair with a mobile and if the mobile unpairs it, then we can restart the whole pairing process.

    3.

    Okay will look into this

    4. Then what can be the best implementation to avoid any such attacks?

    I hope the application is somewhat clear. To reiterate below is the exact application I am implementing

    1. I have some sense data that will be communicated to the mobile application

    2. Mobile applications generate some triggers(not periodic, about 50 over 24Hours lets say) to operate a couple of peripherals that are part of a different characterstic

    3. Now as soon as the device boots up, currently it waits for any central (mobile connection), I am using the nRF-connect APP for demo purpose, and then I am able to see and control the characteristics as required.

    4. All I want to do is to add a provisioning/ pairing process in the same and make the overall communication secure. I came across security modes and levels and I think I am looking for a security mode 1 level 4 communication.

    Firstly am I thinking this in a wrong way? what is the right approach here?

    Thanks for the reply, much appreciated.

  • shwetank vishnu said:
    Okay, so when you say scan response packets, you are talking about the pairing sequence?

    No. The pairing has nothing to do with peer being able to see services. What I was referring to was the scan response packet, which is an "extra" advertising packet. The point was that it is optional which (if any) service UUIDs you include there. But other than that, any peer that connects and does service discovery can see all available services.

    shwetank vishnu said:
    UART_BLE example code which sets the nRF in peripheral mode and can be easily connected using the nRF connect app, what do I need to do to enable a pairing method?

    The UART/Serial Port Emulation over BLE example does not support pairing out of the box, so you need to add support for that. That involves adding the peer manager library to your code, as well as modules it depends on (like FDS). I suggest you refer to an example that allready has peering to see how this is done and which files you need to include etc, and the sdk_config.h configuration. A good such example is the Heart Rate Application.

    shwetank vishnu said:
    The device is battery operated, so power cycle method is a bit out of picture.

    Yes, unless you can remove and re-insert the battery.

    shwetank vishnu said:
    I can use make a sequence that enables the device to pair with a mobile and if the mobile unpairs it, then we can restart the whole pairing process.

    You cannot know from the nRF side if the phone has deleted the bonding information or not, so this method will not work in practice. You either need to allow pairing all the time, or alternatively have a method which you use to make the device enter pairing mode.

    shwetank vishnu said:
    4. Then what can be the best implementation to avoid any such attacks?

    There is no standard way to implement MITM protection without buttons or display. You can use a static passkey for instance which is unequal for each device, but this can be easily hacked, so it will only provide protection against someone accidentally connecting to your device. A malicious attacker can easily circumvent this.

    shwetank vishnu said:
    I came across security modes and levels and I think I am looking for a security mode 1 level 4 communication.

    As your device doe snot have I/O capabilities you can only achieve security mode 1 level 2 (though you can trick it by using a static pass key, but that does not give you any real protection as described above). Also, note that for level 4 you need to use LE Secure Connections.

    shwetank vishnu said:
    Firstly am I thinking this in a wrong way? what is the right approach here?

    I am not sure. I think you need to establish what the required minimum security level is for your product. If you need proper MITM protection, then you need to modify your HW. This may also the case if you need to limit when the device can be in pairing mode.

Related