• State Verified Answer
  • Replies 5 replies
  • Subscribers 88 subscribers
  • Views 962 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 261293
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE security on the remote device

Vojislav

Hi, 

I am working on a device that has nrf52 as an additional BLE chip that does not run the main logic but provides UART over BLE to the application processor (NUS). In the firmware for the nrf52, there is some logic for handling messages. As a user, you can be in the range of the device, and connect to it with your mobile device (phone, tablet) but you will not be able to interact with it physically. So on one end, we have a device that has a keyboard and display (your mobile device) and on the other side, there are hundreds of devices you need to securely connect to without physical access to them. Some parameters can be changed in the device on a daily basis since it also has other long-range connectivity options.
The additional issue can be an authorized person trying to connect to the device all the time and draining the power from the device, which is not good. 

What I am trying to figure out is what is the best way to do security for this device. All suggestions are welcomed. 

Parents
  • 0

    Hi 

    Will your devices have a connection to the Internet through any of these 'other long-range connectivity options' ?

    If so your mobile device should be able to establish a secure, authenticated connection to your device by accessing a database in the cloud. 

    Restricting a single user from connecting too often or too long can be handled locally by the device. 

    Unfortunately there is no way to exclude specific devices from connecting to you, but once a connection is established and you get the connected event you can choose to disconnect if you see that this device is connecting too often. 

    Also, the Bluetooth connection itself is not a big power hog (normally advertising is more power intensive, since each packet is sent three times on three different channels), but perhaps you will start some other activities in the application as a result of the connection?

    Best regards
    Torbjørn

  • 0 in reply to ovrebekk

    Hi Torbjørn,

    Thanks for the answer. Yes, the device will have an internet connection over nrf91. The device will be provisioned and the data would be on the server to which users with the mobile device would have access. 

    What you describe sounds to me like an application-level security/authentication. Am I right? 
    This will be done, but I pre to that I wanted to add some BLE security. When figuring everything out we thought that setting static passkey is a good idea (I know it is not good security), and if somebody is connecting to often (to brute force it for example) the device will disable BLE for a week and change the passkey next time when it is connected to serer over LTE. At the moment the biggest concern I see with that is that mobile devices (iOS, Android) would not let you automatically pass the static passkey to the application, and it is not acceptable to us that users do this manually. 

  • +1 in reply to Vojislav

    Hi Vojislav

    The OOB pairing mode in BLE allows you to provide authentication data over a secondary physical channel (the nRF91 LTE connection in this case), and unless a hacker can intercede both the BLE link and the secondary data link they won't be able to hack the Bluetooth connection.

    So the security itself would still be done by the Bluetooth stack, the application just needs to facilitate the transfer of out of band authentication data. 

    Normally OOB is done over NFC, but in principle any other communication channel can be used. 

    Unfortunately it seems iOS does not support manual insertion of OOB data, so this would not work on iOS devices. 

    It should be possible to do something similar with a passkey (sending the passkey over the LTE link), but again this would not be totally seamless on iOS devices: The closest you get is displaying a passkey in the iOS app, and then having to enter the same key in a passkey popup triggered by iOS. 

    You mention static passkey earlier, which basically voids authentication altogether. If man in the middle protection is not needed you can do this, but it is obviously not as secure as establishing a proper, authenticated link. 

    Best regards
    Torbjørn

Reply
  • +1 in reply to Vojislav

    Hi Vojislav

    The OOB pairing mode in BLE allows you to provide authentication data over a secondary physical channel (the nRF91 LTE connection in this case), and unless a hacker can intercede both the BLE link and the secondary data link they won't be able to hack the Bluetooth connection.

    So the security itself would still be done by the Bluetooth stack, the application just needs to facilitate the transfer of out of band authentication data. 

    Normally OOB is done over NFC, but in principle any other communication channel can be used. 

    Unfortunately it seems iOS does not support manual insertion of OOB data, so this would not work on iOS devices. 

    It should be possible to do something similar with a passkey (sending the passkey over the LTE link), but again this would not be totally seamless on iOS devices: The closest you get is displaying a passkey in the iOS app, and then having to enter the same key in a passkey popup triggered by iOS. 

    You mention static passkey earlier, which basically voids authentication altogether. If man in the middle protection is not needed you can do this, but it is obviously not as secure as establishing a proper, authenticated link. 

    Best regards
    Torbjørn

Children
Related
Terms of service