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

nRF8001 Bonding procedures

Hi,

I've studied the "ble_HID_template.ino" example and I've come up with some doubts and need some clarifications in some points, they are listed below:

1 - Does nRF8001 D support Out of Band (OOB) Pairing? From the nRFgo Studio I can check only "Just works" and "Passkey".

2 - Can I change the security settings, from the initial ones configured in nRFgo Studio, dynamically? I am asking this because my product will have no I/O capabilities and after the first device bond and configure it (Just works pairing), then it is suppose to work with Out of Band (OOB) Pairing for the next devices (the first device will be able to configure it and create keys for the next devices).

3 - What is the content of the DynamicData stored in the nRF8001 (Data retrieved using the ReadDynamicData command) ? It is just bond related information (Like shared keys, device address and etc...). How big can it be? and how many bond device addresses can it store? (I need to fit it to my MCU EEPROM, since I am using it for other purposes as well)

4 - If I define the minimum and maximum encryption key size to 16 (or some other number) can I deduce the size of the DynamicData block?

Now for the BLE HID Template 5 - From my understanding the "lib_aci_bond" is to create bonds with new devices and "lib_aci_connect" is to connect to previously bonded devices. Is this correct?

6 - The only thing that I could differentiate that will define that "lib_aci_connect" will only connect to previously bonded devices is the variable "aci_state.bonded" when it's equal to "ACI_BOND_STATUS_SUCCESS". Is this correct? How different is the behavior of "lib_aci_connect" when you have security enabled or not? Does this behavior of only accepting previously bonded device is because of security enabled configuration or aci_state.bonded variable?

7 - When can I consider that the data packets exchanged between the paired devices are encrypted? After receiving a "ConnectedEvent" ?

Sorry for the long post, I couldn't figure out this answers by my own.

Thanks in advance!

  • Let me work through this one by one.

    1. Does nRF8001 D support Out of Band (OOB) Pairing? OOB is not supported. OOB is typically used with NFC for standard laptops.

    2. Can I change the security settings, from the initial ones configured in nRFgo Studio, dynamically? Changing IO capabilites on the fly is odd as the keys would already have been exchanged, so the link security level is already fixed when the keys are stored on the Central. You can change the IO capability by editing the Setup data that has been created and regenerating the CRC for it. Make sure that this is what you really want to do. Modify nRF8001 Setup example and doc. The BLEPeripheral Arduino project also has some good examples for the Setup and DynamicData.

    3. What is the content of the DynamicData stored in the nRF8001 (Data retrieved using the ReadDynamicData command) ? How big can it be? This contains the state information of the Client Configuration Characteristic Descriptors and the keys. When you generate the services.h file , you will see "ublue_setup.gen.out.txt", which provides some indication of the size. However you will need to verify the size on your nRF8001 Setup by looking at the actual number of ReadDynamicData messages before you freeze the space requirements. You can store as many bonds as your storage allows. Dynamic data interface over ACI.txt

    4. You can reduce the size of the dynamic data by skipping some of the stored keys but you will need to match the sizes by padding the dynamic data when doing WriteDynamicData. Ideally keep the key size to 16.

    5. "lib_aci_bond" is to create bonds with new devices and "lib_aci_connect" is to connect to previously bonded devices. Is this correct? Correct

    6. Does this behavior of only accepting previously bonded device is because of security enabled configuration or aci_state.bonded variable? This because of the security enabled configuration. If security is enabled then data will be transmitted only on the secured link. A Credit event will arrive when the data is successfully transmitted.

    7. When can I consider that the data packets exchanged between the paired devices are encrypted? After receiving a "ConnectedEvent" ? Typically the link will be encrypted when the central initiates the encryption, the data will be transmitted after the link is encrypted and a Credit Event will be sent back if the data was transmitted successfully on the security params that were set or a PipeErrorEvent may result due to a failure.

    Edit: Added links and text files for modifying the Setup and DynamicData

  • Thanks. Check below my comments:

    1. The ideia was the first device to be "First Works" and the rest would be by "OOB".

    2. How would I know which bytes refer to the keys used in the security?

    3. If I understood correctly any data event or data command that I send after the connection through bonding is set (Connection Event and Pipes are configured) it would be encrypted. Is this correct?

  • Clarification on (2) -> What is the central device being used ? How do you intend to use OOB. OOB in only distributing the STK (Key used for encryption the bonding process). In anycase OOB in the BTLE level is not supported by the nRF8001.

    (3) See attached text file for details (updated answer)

    (7) Correct, Any data successfully sent will be encrypted

  • Thanks David! The ideia behind OOB would be permitting the administrador from the module, which we are creating, to create new users, and only them, that would be able to access the module. Anyways after some research I checked that Android is not using static ble addresses anymore and moreover the OOB is related to the MAC of the devices and we need to create some related to the Mobile Phone No. Anyways bonding will not be useful to us, we are going to create the ciphering and authentication at application layer. Thanks for your support.

  • That is a reasonable call. Please accept the answer and we can close this case.

Related