ncs 1.8.0 + NFC + OOB + nrf52833

RE: ncs 1.8.0 + NFC + OOB + nrf52833

Hung Bui — Fri, 26 Aug 2022 10:21:17 GMT

Hi again,

Actually I found that we have a blog related to this topic. Please have a look at this:
Simple Application-level Authentication

There is an example code provided at the end of the blog.

RE: ncs 1.8.0 + NFC + OOB + nrf52833

Hung Bui — Tue, 16 Aug 2022 09:21:36 GMT

Hi,

I'm back.

There are 2 tasks that you need to achieve here.

First task is to dynamically change the attribute table. I have made an example you can have a look here: RE: How shall i define multiple services in GATT Server database, so that only 1 service is seen by GATT Client at a time ?

The second task is to authenticate your app with the device. You have different option here, if you want to avoid any user interaction (then you don't have MITM protection) you can think of encrypting all communication using your own encryption mechanism, maybe based on the serial number of the device. Meaning you have a database of all your device with the ID is the serial number. Each device will have a hard coded encrypt/decrypt key. By typing the serial number of the device into the app on the phone, the app can go to cloud and get the encrypt/decrypt key and then can encrypt the communication.

You can also do challenge response authentication, but you should only use this if you are planning to do additional encryption later on. To do challenge response authentication, you can use any encryption method. Different method will give you different level of security. You can use, for example RSA . The example is located in \nrf\samples\crypto\rsa\ . What you can do is to provide a plaintext message (randomly generated) and the peer device need to encrypt it with a key. The peer device send back the encrypted message and then on the NRF52 device you can decrypt it and check if it match with the original randomly generated plaintext.

RE: ncs 1.8.0 + NFC + OOB + nrf52833

embeddedER — Wed, 10 Aug 2022 20:58:27 GMT

Hi Torbjørn,

[quote userid="2116" url="~/f/nordic-q-a/90173/ncs-1-8-0-nfc-oob-nrf52833/380077"]

There are a couple of ways to do this, yes. One way is to simply clear all the relevant attributes until the phone is authenticated, at which point the peripheral can set the attributes as required.

Another way is to only add the relevant service(s) after the phone is authenticated, so that the phone will not be able to access them before that. The service handling the challenge-response stage would obviously need to be there from the start, along with standard services such as the GAP and GATT services.

[/quote]

I am finding it hard to implement above stuff and not able to find the proper example. Could you please help me pointing to some sample code related to this?

How can I achieve the challenge-response? There is no example in the ncs v1.8.0 that I could find for this.

Thanks!

RE: ncs 1.8.0 + NFC + OOB + nrf52833

ovrebekk — Fri, 05 Aug 2022 11:27:49 GMT

No problem TIA, I am happy to help.

If you have more questions just let me know 🙂

Best regards
Torbjørn

RE: ncs 1.8.0 + NFC + OOB + nrf52833

embeddedER — Thu, 04 Aug 2022 19:08:11 GMT

Hi Torbjørn,

I think I got what you are saying for challenge-response mechanism. I'll need to explore and try this.

Thanks!

RE: ncs 1.8.0 + NFC + OOB + nrf52833

ovrebekk — Thu, 04 Aug 2022 10:18:31 GMT

Hi TIA

[quote user="harshal034"]Could you please elaborate on this? Any example of such implementation? [/quote]

I don't think we have an example for this, no, but if the phone has a way to get a serial number from the cloud this should be pretty easy to implement.

The peripheral sends a challenge, which could be as simple as sending its own 48-bit BLE address. Then the phone needs to request the serial number from the cloud (using the BLE address to identify the peripheral), and send this back to the peripheral as a response to the challenge.

If you want to ensure that the challenge/response stage can not be intercepted by anyone nearby you need to either go through the normal Bluetooth pairing stage first, before you send the challenge from the peripheral side, or you need to add some additional security to the challenge/response step in the application.

One way to manually encrypt the challenge/response stage would be for the peripheral to generate a private/public keypair, and include the public key in the challenge. The phone would then have to encrypt the response with the public key, ensuring that only the peripheral would be able to read the response (using the private key to decrypt it).

[quote user="harshal034"]Can we restrict User/Mobile from fetching data/attributes till this challenge-response is successful?[/quote]

There are a couple of ways to do this, yes. One way is to simply clear all the relevant attributes until the phone is authenticated, at which point the peripheral can set the attributes as required.

Best regards
Torbjørn

RE: ncs 1.8.0 + NFC + OOB + nrf52833

embeddedER — Wed, 03 Aug 2022 17:38:13 GMT

Hi Torbjørn,

Thanks for the reply.

[quote userid="2116" url="~/f/nordic-q-a/90173/ncs-1-8-0-nfc-oob-nrf52833/379809"]You could run some kind of proprietary 'challenge and response' step after you have connected, and have the peripheral disconnect if the mobile app doesn't provide the right response. [/quote]

Could you please elaborate on this? Any example of such implementation? Can we restrict User/Mobile from fetching data/attributes till this challenge-response is successful?

[quote userid="2116" url="~/f/nordic-q-a/90173/ncs-1-8-0-nfc-oob-nrf52833/379809"]The question is how likely it is that the wrong phone tries to connect to your device?
If you configure your advertise packet with a unique, proprietary 128-bit UUID, and don't use a local name or any standard 16-bit UUID's, then other phones would normally not attempt to connect to your device. [/quote]

Our Aim mainly is to ensure that even if someone wants to intentionally hack into our system, they shouldn't be able to modify configurations in our system after pairing.

TIA!

RE: ncs 1.8.0 + NFC + OOB + nrf52833

ovrebekk — Wed, 03 Aug 2022 07:49:03 GMT

You could run some kind of proprietary 'challenge and response' step after you have connected, and have the peripheral disconnect if the mobile app doesn't provide the right response.

The mobile phone would still be allowed to start the pairing procedure, if you are not able to finish the proprietary authentication step first, but you could always delete the bond on the peripheral side after the authentication fails.

The question is how likely it is that the wrong phone tries to connect to your device?
If you configure your advertise packet with a unique, proprietary 128-bit UUID, and don't use a local name or any standard 16-bit UUID's, then other phones would normally not attempt to connect to your device.

Best regards
Torbjørn

RE: ncs 1.8.0 + NFC + OOB + nrf52833

embeddedER — Tue, 02 Aug 2022 15:49:53 GMT

Thanks Torbjørn for getting back on this.

Is there any other way we can restrict only our Mobile Application to pair with our peripheral then?

RE: ncs 1.8.0 + NFC + OOB + nrf52833

ovrebekk — Tue, 02 Aug 2022 10:49:53 GMT

Hung is currently on vacation, and I will help you out in the mean time.

Unfortunately there is no way to skip the user confirmation on the mobile side. There is no API on the phone side to configure a static passkey directly from the app, this is handled by the OS directly meaning you will always get the extra confirmation step. This is the same both on iOS and Android.

Normal NFC OOB pairing is supported in Android, but not in iOS.

Best regards
Torbjørn

RE: ncs 1.8.0 + NFC + OOB + nrf52833

embeddedER — Tue, 26 Jul 2022 17:14:49 GMT

Hi Hung,

I liked the idea of "challenge and response authentication", however, one of our future extension is to have our own Central Device which may not have OOB/NFC, but will have a way to know the serial number of our peripheral via cloud.

So, OOB we are considering just to send serial number from the peripheral to the mobile.

Referring to your quote:

"Yes you can do what you planed. So instead of showing a pass key on a display. You only provide the passkey with your own way of encryption into NFC. The phone then read NFC data and in your app you can decrypt the data to show the user the passkey. However the pairing process will be not very smooth as there will be a popup from the system to ask for inputting the passkey, and then you need to switch to the app to read NFC."

Is there a way we can skip that "confirmation step" from the user? Basically idea is to use the static key so that there is no user interruption is required. We will anyway need to find a way to connect our central which won't have keyboard/display to pair with our peripheral using serial number that it knows.

So the question is, can we really skip user confirmation (mobile and central device) if we use the static pass-key? (This static pass-key will be unique and known to peripheral and mobile in some way, either via NFC or cloud)

TIA!

RE: ncs 1.8.0 + NFC + OOB + nrf52833

Hung Bui — Tue, 26 Jul 2022 09:21:25 GMT

Hi,

Yes you can do what you planed. So instead of showing a pass key on a display. You only provide the passkey with your own way of encryption into NFC. The phone then read NFC data and in your app you can decrypt the data to show the user the passkey. However the pairing process will be not very smooth as there will be a popup from the system to ask for inputting the passkey, and then you need to switch to the app to read NFC.

I would propose the following instead:

You can define a procedure required before the NFC provides the OOB data for pairing.
For example a challenge and response authentication. The app on the phone need to read the NFC data (challenge) and then write back the response to the NFC tag. The nRF52 will then check the response, if it's correct then it will start the pairing process and provide the OOB data to NFC for the phone to pair as usual.

RE: ncs 1.8.0 + NFC + OOB + nrf52833

embeddedER — Mon, 25 Jul 2022 16:21:59 GMT

Hi Hung,

Thanks for the reply. I'll have look at Bluetooth SIG standard again. And we are planning to use LESEC pairing.

Do you have any suggestion on how do we restrict pairing with only our Mobile application along with OOB?

One way that I can think of is to just use NFC to wake-up the our peripheral (not OOB process) and share the serial number to the Mobile Application over NFC. Mobile application then use this serial number + secret recipe to generate numeric pairing key and use the same for pairing (no user interaction required and only our Mobile app can generate this valid pairing key). Peripheral can also generate the same numeric pairing key using the same serial number + secret recipe.

TIA!

RE: ncs 1.8.0 + NFC + OOB + nrf52833

Hung Bui — Mon, 25 Jul 2022 11:58:41 GMT

Hi,

I'm not so sure you are following the Bluetooth SIG standard OOB pairing .

Are you planning to do Legacy Pairing or LESC pairing ?

Please have a look at section 2.3.5.6.3 Vol 3 Part H in the Bluetooth spec v5.2 to have an overview on how OOB pairing works:

In your list, I'm not so sure if you can do what you define in step 4. The phone won't let you modify the bonding key to add the "secret shared key" to use in the BLE encryption.

What oob_data_request() does is to request the application on the nRF52 to provide the OOB data (Ra and Ca) . The local data is generated in the application via the call paring_key_generate()

The passkey_confirm() call back has nothing to with OOB. It on applicable for numeric comparison pairing.

RE: ncs 1.8.0 + NFC + OOB + nrf52833

embeddedER — Fri, 22 Jul 2022 21:13:58 GMT

Hi Hung,

We are planning to use our Mobile App on the NFC reader side.

Let me add some more details here to explain what we want to do:
1. Our Peripheral device will be by default in the sleep mode and not advertising anything.
2. We will have our own Mobile application which will be installed on Android/iPhone with NFC capability.
3. When someone scans our Peripheral device with our Mobile App, our peripheral device sends OOB local data (confirm value and random value).
4. To ensure that only our mobile app can pair with our peripheral, once OOB is confirmed, we are planning to pair with the key which will be generated based on the OOB data passed during NFC read plus "secret shared key". e.g. simply XOR the data received during OOB with the fixed key which is known to our peripheral and our mobile app only.
5. Since our mobile app can generate this paired key, it can utilize the same for BLE pairing (instead of displaying key or asking it to user).

Any comments on above flow?

As per my understanding, when OOB pairing is used, by default BLE stack verifies the OOB data sent to NFC reader (by callback function defined in oob_data_request).

So, during pairing I was expecting it to work in a flow like:
1. Call back provided in oob_data_request() gets called, which basically makes sure that this is the same device which read the NFC is going for pairing (stopping MITM)
2. Then callback provided in passkey_confirm() is called, which basically confirms the passkey provided by Our Mobile App with the passkey our peripheral has.

Is this understanding right?

TIA!

RE: ncs 1.8.0 + NFC + OOB + nrf52833

Hung Bui — Fri, 22 Jul 2022 07:50:09 GMT

Hi,

Please test the default example and make sure it works and you can send bond information via NFC before modifying it.

Do you have control over both sides of the connection ? What do you use on the NFC reader side ?

Please note that if you plan to do something not defined in the Bluetooth SIG spec I don't think a normal phone would support that.
I don't understand what you meant by "secret key".
If you want nobody but only your app/mobile can pair to your device, you would need to implement your own proprietary mechanism to block pairing from other devices. As far as I know the OOB pairing protocol in BLE doesn't support this.
What it does support is to stop pairing after it is paired to certain devices (whitelisting)

RE: ncs 1.8.0 + NFC + OOB + nrf52833

embeddedER — Thu, 21 Jul 2022 22:04:17 GMT

Hi Hung,

Thanks for the response. I checked peripheral_nfc_pairing_example. However, we have a little different usecase here.

We want to wake-up the device using NFC, transfer OOB data to reader, and then for pairing, we want to use Serial Number (passed in NDEF) to reader + secret key (pre-shared with device and mobile app) to generate "pairing key".

And then we want to use this "pairing key" so that no body but only our Mobile application can pair with our peripheral device.

I am trying to implement the same. I've enabled oob_data_request in auth_cb:

static struct bt_conn_auth_cb conn_auth_callbacks = {
	.passkey_display = auth_passkey_display,
	.passkey_confirm = auth_passkey_confirm,
	.oob_data_request = auth_oob_data_request,
	.cancel = auth_cancel,
	.pairing_complete = pairing_complete,
	.pairing_failed = pairing_failed
	};

However, auth_oob_data_request is never called in my code.

As per my understanding, auth_oob_data_request should be called first and then auth_passley_confirm. Am I missing anything here?

I am expecting is to use OOB to ensure only our device woke-up peripheral and then use new pairing key for pairing.

TIA!

RE: ncs 1.8.0 + NFC + OOB + nrf52833

Hung Bui — Wed, 20 Jul 2022 13:52:18 GMT

Hi,
1. Yes, I don't see any problem with this.

2. The pairing data should be passed to NFC tag and then the peer device (phone) can read the data via NFC. Please have a look at the tnep_initial_msg_encode() function in the example in #3.

3. Please have a look at this example. It's located in \nrf\samples\bluetooth\peripheral_nfc_pairing.

4. Please study the example, it's the most common implementation of NFC pairing.