BLE device authorization without prior knowledge

[jasr93]

Hello,

I'm designing an application where I intend to authorize different users to access the functionalities of a device based on the nRF54 family.

The general idea is that the user would log into the app, and only if they are an authorized user would they be allowed access to the device's functionalities.

My question is, can I use the encryption and authentication mechanisms of the BLE standard to accomplish this?

Reading about the different supported security mechanisms, I can't see how the device could distrust all smartphones that try to connect to it by default, and how the app could verify the device's legitimacy.

I understand that the alternative would be to allow all smartphones to connect by default, and then exchange encrypted data between the app and the device using a key known only to the device and the app.

However, I wanted to know if something like this would be possible at the BLE standard level.

I've read about the possibility of creating a whitelist, but the truth is that users would only be authorized at the app level. Even if it were possible to link the user to their mobile device's BLE address, I can't think of how to pass this information to the device using only BLE, since it's the device's only interface for communicating with the outside world.

Thanks in advance

[tesc]

Hi,

The general idea is that the user would log into the app, and only if they are an authorized user would they be allowed access to the device's functionalities.

My question is, can I use the encryption and authentication mechanisms of the BLE standard to accomplish this?

It is possible to use BLE security levels for not providing access to given BLE services on the device. You can have a custom (specific to your application) way to control the device's willingness to pair and increase the security level, thereby gatekeeping the particular BLE services.

I understand that the alternative would be to allow all smartphones to connect by default, and then exchange encrypted data between the app and the device using a key known only to the device and the app.

Yes, this could be one way to enforce authentication.

There may be a way using BLE mechanisms only, where you use a static passkey for the pairing. However, then you must be in full control of the central side of the connection. For smartphone centrals, pairing is typically handled by the OS, which gives the user a prompt for writing inn the passkey. Then you cannot automatically use the passkey from behind the scenes (in the phone app), but rather you have to tell the user the passkey explicitly. I don't quite see how you could work around that limitation. You may also not trust the phone app to work directly with the key.

In general, regardless of how you choose to approach the use case, I think you will end up with a scheme close to the following:

• Your device allows initial connections, from any device.
• Main BLE services are protected by requiring higher security level, which is a BLE mechanism.
• In order for the device to accept higher security level, some application specific authentication and/or authorization is needed. For this, you would typically use a custom BLE service on the device, for communication during this authentication/authorization process.
• In case of failure to authenticate, the device disconnects.
• Possibly also: If authentication doesn't happen within a timeout, the device disconnects.

I've read about the possibility of creating a whitelist, but the truth is that users would only be authorized at the app level. Even if it were possible to link the user to their mobile device's BLE address, I can't think of how to pass this information to the device using only BLE, since it's the device's only interface for communicating with the outside world.

Yes, I fully agree.

The general idea is that the user would log into the app, and only if they are an authorized user would they be allowed access to the device's functionalities.

Let me revisit this part of your question. It is important with such a use case, to carefully consider the security implications surrounding what keys are used, what communications/devices those keys unlock, where the keys are stored, where the keys are sent, and so on and so forth.

For instance, one shared key for all devices, which is handled unencrypted by the smartphone, would be relatively easy to get hold of by a malicious user or compromised smartphone app, and the implication of one shared key is that any successful attacker now has access to all devices world-wide.

There are ways to mitigate risks, such as e.g.:

• Each device using unique keys. (Breaking into one device doesn't provide access to other devices.)
• End-to-end encryption of communication between device and cloud, with man-in-the-middle protection. For instance through use of a Diffie-Hellman key exchange. (Then the smartphone cannot listen in on the communication, preventing malicious users or compromised apps from snatching secrets.)
• Other techniques and security measures as you see fit.

Of course, such mitigations may add both complexity and cost to a solution, so I encourage you to do a cost/benefit analysis on what level of protection is right for your use case. (I.e. think about the cost v.s reward for a would-be attacker of breaking in, as well as the cost of security measures v.s. cost of security breach for you and your end user.)

Regards,
Terje