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!

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

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

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