Authentication/Authorization using mobile phone

[Andrew]

I have been searching for the best way to authenticate / authorize a mobile phone with a nRF52 device without much luck.

I would like to ensure that only the owner of the nRF52 device can pair with the device using their mobile phone.

Is there a best practice for this use case?

[Einar Thorsrud]

Hi,

It is difficult to have a concept of ownership initially, perhaps you can elaborate?

You can achieve something similar by using MITM protection if the nRF has for instance a button or keyboard. That would at least ensure that the person that does bonding with his phone also has physical access to the nRF52 device. Alternatively, if the nRF lack the IO capabilities required by MITM, you could for instance use a static passkey that is printed on the nRF, which the user has to enter on the phone. Again, this requires the user to have physical access to be able to see the passkey.

[Andrew]

The devices are outdoor lights, so they are in a public place and typically out of reach. We have the means of setting a password or key in the factory and communicating this to the owners of the lights.

While the passkey approach would work, I'm reluctant to use it as it is straightforward to brute force attack.

I've been looking at legacy OOB, but I think I'm missing something about how it works. I've tried setting the 16 byte key manually as follows:

case BLE_GAP_EVT_AUTH_KEY_REQUEST:
    sd_ble_gap_auth_key_reply(p_ble_evt->evt.gatts_evt.conn_handle, BLE_GAP_AUTH_KEY_TYPE_OOB, m_oob_auth_key.tk);

In nRF Connect, I'm prompted for OOB data, but whatever I enter does not work. What part of this am I missing?

[Einar Thorsrud]

Hi,

Yes, OOB could be a sensible approach in this case, but it depends on your security requirements. There are many possible ways of doing this, and all involve tradeoffs. Which out of band channel do you want to use? You could use NFC, but that would make it possible for anyone passing by to pair. Or you could hard code the key in the nRF, and transmit an ID of some sort that can be used by the phone to retrieve the key from the cloud based on the ID. This makes the security aspects simple on the nRF side but requires a secure (enough) cloud solution. This would effectively make anyone in RF range able to pair. Perhaps you could make this acceptable by only allowing pairing/bonding and only transmitting the ID in for instance the first 3 minutes after a reset (power cycle of the outdoor light)?

Andrew said:

In nRF Connect, I'm prompted for OOB data, but whatever I enter does not work. What part of this am I missing?

This looks OK, as long as you also have configured the peer manager as described for OOB under security parameters. Based on the snippet, you handle the BLE_GAP_EVT_AUTH_KEY_REQUEST correctly (as described in the Bonding: Passkey Entry, User Inputs on Peripheral or OOB MSC).

[Andrew]

Hi Einar,

I'm back at this after almost a year...hopefully you can provide some additional help.

My security requirements are relatively simple. I want to prevent unauthorized users from changing configuration (writes) on the device. Reading the data does not need to be prevented.

Our devices already advertise a unique ID (serial number), but rather than using a cloud service to lookup keys, it is feasible to provide the key via a file or QR code.

I'm imagining creating the Temporary Keys (TK) in the factory, which are not so temporary really. One would need to be stored on the device, while both would need to be provided to the mobile phone app.

Does this sound correct to you? Do you know if this method or similar has been used elsewhere? Any other recommendations?

Thank you

[Einar Thorsrud]

Hi Andrew,

I find it difficult to make any recommendations since this will be a non-standard approach and there are so many details that affect the security of such a scheme. That said, I think the approach with QR codes looks sensible, though I don't know all the details of your key lookup system, your security requirements nor exactly how the system will be used (including the requirements for user-friendliness).

Br,

Einar

[Andrew]

Okay, your note about non-standard is helpful. Is there a standard approach for only allowing bonding/pairing with a mobile phone which has the proper credentials to do so? This assumes there is no IO capabilities physical access to the device.

If not, then I expect I will need to use Just Works bonding and perform an authentication using a custom characteristic after establishing the bond.

[Einar Thorsrud]

Hi,

There is no standard approached that would work in this case, so you must use a method of your own, as you have outlined. My point about this being non-standard was that I cannot guarantee that it will be a good solution, as it is often easy to overlook potential security issues.