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]

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.