This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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... Slight smile 

  • It works fine ! i just replace false by true and now, no more issue.

    I can pair with device ID as passkey. I'm aware it is not the more secure ( i understand in 20 step the hacker can be paired ). On this point i don't understand why bluetooth protocol give the information of what bit is ok and what bit is not ... What interesst there is to do this at the end , it is just giving the possibility to guess the code after 20 trial no ? 

  • Hi again, 

    Please be aware that in this process: 

    The random number is generated after each step. So even if the hacker can try again it will be a new random number and they can't guess the correct bit after 20 times. But anyway using same static passkey would compromise the security protection of the method and it's not recommended by the spec. 

  • Ok i see. But in my case as the code is not refeshed after each connexion, it is not perfectly secure , but in my application it is not really important and i don't really have another way to proceed unfortunately.

    I just tried to connect a third phone, and it connect ! without asking the pairing first ?!

    Is it linked to the fact that i only have three as  FDS_VIRTUAL_PAGES  ? Meaning two paired device possible?

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

  • 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

Related