Recommended way to validate access for BLE connection during WiFi Provisioning

[Johannes Hutter]

We are building a device without display other than a couple LEDs and no input possibilities based on a nRF5340 + nRF7002. For the WiFi provisioning and for other data transfer we use a BLE link. We want to ensure that only the owner of the device can connect to it and set it up.

The plan I had was to print a random number to a label (probably both printed and encoded in a QR code) and require input of this number/key somewhere during the pairing process to avoid someone from outside the building or next apartment setting up the device or reading out data. The key would be provisioned to the device during manufacturing as well. In the end a process as you had it back in BR/EDR times with the passkey during pairing of headphones or so.

Can someone help me out here on the right terminology and feature set that I have to use and can give me advice on the compatibility?

If I get it right, you rather want to use LE Secure Connections, since they provide both Authentication and Encryption. Can I use out-of-band pairing here? I didn't find samples in both Zephyr or the NCS for out-of-band pairing without also using NFC. What is the relation/difference between OOB pairing and passkey (I guess something like the passkey could be good enough for our use case as well). Do we have to consider feature support in the mobile OSs? Does it make sense to disable the LE legacy pairing or would this be problematic for compatibility with consumer smartphones?

I guess I am actually just not capable to find the right level of documentation. Something like a sample would probably point me in the right directions.

[Hung Bui]

Hi Johannes, 

Disclaimer: We are not a security firm, so the information provided here is only a suggestion/recommendation from our point of view. 

The recommended way of building a secure connection between two embedded devices without IO capabilities is to use OOB. And the only OOB option that we have in the examples in our SDK is NFC. It's is because it's the most common OOB mean. Other options, for example serial, Wi-fi or other protocols usually not supported on BOTH devices. 

Using a QR code or a static passkey is not recommended because it's static. And being static, it's very easy to hack. It's even worst on LE Secure Connection because attacker only needs maximum 20 trials to be able to guess the static passkey. The key has to be randomized on each pairing session to be able to allow a secure pairing. If the attacker have the static passkey, it's pretty easy to act as MITM and fool the peers to connect to the MITM device.

Static passkey can only protect against passive eavesdropping. 

You may have to think about other option, such as using your own encryption to transfer the random generated key. For example you can use AES to encrypt the advertising packet. In the advertising packet you can  in addition to normal advertising data, insert the random passkey you generate for the pairing process or the OOB data. Later when pairing, your app on the phone can tell the end user to enter the passkey that you decrypt from the advertising packet or simply use the OOB data to proceed with the bonding. (note that sending OOB data via BLE make it weak, as it's not true OOB anymore , the level of security is now equal to the level of your proprietary encryption)

The drawback of this method is to the need to have a common key on both sides, and usually a common key on all devices. This is not recommended.

To avoid using the same key on all devices you can then use a printed serial number or QR code on the back of the device as the lookup index for the key or can be used to resolve/retrieve a key on the phone's side. 

Another option is to send the encrypted passkey/OOB after you have connected and before bonding. After the phone have decrypt and get the random passkey it can start the bonding process.