ncs 1.8.0 + NFC + OOB + nrf52833

[embeddedER]

Hi Team,

We are in process of developing pairing mechanism for our peripheral device. We are considering using NFC for OOB. Here is what we think we should be doing:

1. Use Mobile (NFC) to wake-up our peripheral device

2. Our peripheral device sends Key (unique per device) over NFC to our Mobile App

3. Our mobile app uses this "key + encryption" to pair with our device

Idea here is to restrict any other app to connect to our device.

We've few questions here:

1. Is this a viable option?

2. In above steps at Step-2, how do we send data from peripheral device to mobile app? 

3. Is there any example/blog around this?

4. Any other suggestions t this approach?

TIA!

[ovrebekk]

Hi 

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

[embeddedER]

Hi Torbjørn,

Thanks for the reply.

ovrebekk said:

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. 

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?

ovrebekk said:

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. 

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!

[ovrebekk]

Hi TIA

embeddedER said:

Could you please elaborate on this? Any example of such implementation?

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). 

embeddedER said:

Can we restrict User/Mobile from fetching data/attributes till this challenge-response is successful?

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. 

Best regards
Torbjørn

[embeddedER]

Hi Torbjørn,

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

Thanks!

[ovrebekk]

No problem TIA, I am happy to help. 

If you have more questions just let me know

Best regards
Torbjørn