ncs 1.8.0 + NFC + OOB + nrf52833

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!

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

  • 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!

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

  • 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!

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

Related