Pairing with qr code for passkey, production managament with crc and bootloader

[Olfox]

Hi,

My product have no keyboard or display , no nfc too. We want a paring procedure to not let open the connexion to everybody not paired first.

My idea was to use a fixed passkey into the code, and print into a qr code this passkey and mac adress. Our smartphone app will use this two parametres to scan and list only the product with concerned mac adress and then establish a paired connexion with the passkey, previously got by scanning the qr code.

My software also use secure bootloader to do DFU (s113 + ble_app_buttonless_dfu_ + secure_booloader_s113_pca10100) , nrf52833.

My questions is : 

1. Where to find this passkey into the code to set it ?

2. In production, i will have to personnalise this passkey into each product, making a different .hex with a specific crc to be able to boot i guess. Fastest way will be to build to get the good crc and flash only the memory adresse with good crc and passkey. Is it the good way to proceed ?

3. If it is, may be we need some script to first change the passkey into the source code, then build application , and finally program the device with nrfconnect command ? It seems to be quiet heavy but may be the unic solution?

4. in case of update of the firmware with dfu once customers has bought the product, does it means we will have to generate a unic zip for each product sales ? What is just impossible. So finally i dont't really see how to proceed a part of placing the passykey somewhere into the memory that is independant of crc check, what i don't think possible.

I didn't found easiest way to do something quiet simple in fact. This seems to be a typical case for BLE products , no?

Thanks a lot for your help, there is so many questions...  

[Hung Bui]

Hi Florian, 

1. If you look for "static passkey" in devzone you should be able to find many example code for that, for example this: https://devzone.nordicsemi.com/f/nordic-q-a/15030/how-to-set-a-static-passkey-on-nrf52832-pca10040

2. You can think of using the device ID in the FICR as the passkey. It can be consider unique to each device. The passkey has only 1 mil possibilities anyway. 

3. If you use device ID in  FICR you don't need to change the code for each device. But you need to read the FICR of each of the device to print the QR code later on. 

4. If you use Device ID you don't need to do modify the firmware for each device. 

[Olfox]

It is ok it works.

On first connexion, i'm able to type the 6digit pincode extract from the 6 lsb of DEVICE_ID0. 

But i have a strange effect. Once first phone paired it works fine. Then i pair a second phone, it works too. But when i try to connect the first phone, i get an error mesage on Android sayong " Association refused by myNrfDevice" where my Nrf device is my nrf52833.

Is it possible to have two paired device or more ?

Also when i try to dis associate on android side and then try to do the association process with pin code again, i have the same message ans i get this error on my nrf console:

<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Bonding, error: 133

I need to "Erase all" with SES to clean the nrf and then i can try again. It seems to be linked to the softdevice may be that keep in memory the second private key or something like this may be.

[Hung Bui]

Any phone can connect to your device without bonding/pairing if you don't use a whitelist. If you have a characteristic that require encryption, then bonding will be triggered. 

By having a static passkey your device has a slightly higher MITM protection compared to passkey. But it's not as good as having a randomized passkey. 

[Olfox]

Wooo there is no way to avoid connexion without entering pairing ? Because imagine my nrf advertise, and somebody not paired connect, and keep connexion.  As at the moment i have only one central connected at a time, it will be impossible for autorized mobil to connect on my nrf :( ....

I have set all my charachetristic to BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM and now i see pop up the pairing input windows, but for the dfu characteristique and the default Generic access, generic attribute and secure DFU service, it is still accesible. Ok for DFU there is then the check with signature.

I noticed NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS exist in the sdk_config.h bit i don't know really the impact it could have

[Hung Bui]

You can disconnect the connection after a period of time if it doesn't initiate pairing or if you don't recognize that  device.

 
But using whitelist is the best way of avoiding an unwanted central to connect to your device. You need either the central address or the central's IRK to setup whitelist. 

Note that one can easily jam the advertising channels and block any connection. 

You set NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS when you want to use the same bonding you used on your device to the central when doing DFU. 
it's normal that the generic access , generic attribute is accessible without encryption. 
If you want you can set the DFU service to require bonding. 

[Olfox]

OK thanks i see the idea.

So in my case the good way to work is: 

-on my application: scan qr code to get the static passkey and static ble adresse of my nrf. Scan nrf mac @, connect and ask pairing by reading a protected characteristic for example.

Then on nrf side, once paired, add the central in the whitelist. Enable the connection only for white list device. But here i see the issue, how futur mobil can connect if they are not in the list ? As my own way to update the list is to request pairing, and to do so , connexion needs to be established ?

Again, thank you for your help Hung i really appreciate it.

[Hung Bui]

Hi again Florian, 
Then you can create a "pairing mode" where you can put your device into open advertising which accept connection from a new phone. After connection and pairing, it can switch back to whitelist mode. 

 
You can either use a physical button, or a BLE command to put the device into this "open" mode. 
Another, maybe more elegant is to use NFC for that. So the new phone need to write something to the NFC data to switch the device to pairing mode. 

[Olfox]

Ok i understand.

To sum up, my problematic is to avoid an infinite connexion of non paired device. To protect this, i need to close connexion to a whitelist. As i need to setup this whitelist by pairing, i need to have at a certain moment the possibility to let open the connexion. As i don't have button nfc or keyboard ( because my product is not accessible) i only have the possibility to close connexion of a non paired device after a certain amount of time.

I see two possibility:

1. Always allow any body to connect, but close connexion if they didn't ask for pairing or if they have not been paired already in the past ( by checking their adress and compare to my whitelist)

Problematic: someone who try in loop to connect will still monopolize connexion. 

2. Only after inserting the batterie, start a init_pairing mode for let say 2minutes , that let connexion open to have a chance to pair. Create a byte ALLOW_PAIRING in a bluetooth characteristic that the first paired phone can write to restart the nrf in init_pairing mode and let the chance to a second phone to pair. Its is your first proposal i think :). 

Problematic: if your first phone is dead , the only way to pair, is to remove battery to proceed a init_pairing mode.

I don't really see other way to do at the moment.

Concerning adress, is it always fixed on ble ? I have read youcan have non resolve adress?

Where is it possible to protect DFU please , because i have enable NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS but it disable a lot of cosde beacause of some  #ifdef in ble_dfu_unbouded.c and the call there is in main.c to 

// Initialize the async SVCI interface to bootloader before any interrupts are enabled.
                err_code = ble_dfu_buttonless_async_svci_init();

[Hung Bui]

Hi Florian, 

If you don't have any button, and still want to find a way to set the device to "pairing" mode you can think of including an accelerometer that user can shake the device to put it to pairing mode. Of course it may increase BOM. 

Another option is to give the majority of the time to advertise with whitelist and short period of time (for example 5 s per minute) to advertise in "open" mode, this would give the chance for other device to connect and pair. And still give most of the priority to paired devices. 

Regarding address, both the central and the peripheral can have resolvable random addresses that change over time. To be able to recognize the bonded device they would need to use an IRK to resolve the address. The IRK is exchanged after bonding. 

Please try to follow the documentation on how to use the NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS. If you share bonding with the bootloader you shouldn't use ble_dfu_unbonded.c. 

[Olfox]

Thanks Hung,

Thanks for this tips.

I already have an accelerometre on my systeme to wake up on rotation, but my systeme is in a shaking environement so i would prefere may be the second options. I have to understand a bit more how to work with whitelist and irk :) .

Thanks for the link for DFU.