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

Question about passkey, bonding, and pairing

Hi, I mostly use the SDK 7.2 or SDK 10 and S110 7.1 or 8.0

since I have multiple custom boards that uses revision 2 and 3 chips.

My custom board I'm about to use has no displays or buttons so I use this settings.

sd_ble_gap_sec_params_t sec_params;
sec_params.io_caps = BLE_GAP_IO_CAPS_DISPLAY_ONLY;

My custom board uses nRF51822-QFAA and it is connected to Texas Instrument's MCU (TM4C123GH6PM) to commuciate via UART.

I have questions about passkey example from github.

1) Does passkey always require bonding?

Although I saw the Passkey Entry Diagram, I'm thinking of a scenario that

each side (central like iPhone and the peripheral) don't leave each IRK and address.

So I'm wondering it is okay to use pairing with passkey.

Also, when using passkey, does this always require MITM protection?

sd_ble_gap_sec_params_t sec_params;
memset(&sec_params, 0, sizeof(sec_params));
sec_params.timeout = 30;
sec_params.bond = 1;
sec_params.mitm = 1;
sec_params.io_caps = BLE_GAP_IO_CAPS_DISPLAY_ONLY;
  1. About this part,

    uint8_t passkey[] = "123456"; // The question is about this value ble_opt_t ble_opt; ble_opt.gap.passkey.p_passkey = &passkey[0]; uint32_t err_code = sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &ble_opt);

does the passkey has to be numbers (ASCII 0, 0x30 ~ 9, 0x39)?

I tried to use uint8_t passkey[] = "ABCDEF"; instead but sd_ble_opt_set returned an error.

  1. I'm about to change the uint8_t passkey[] = "123456"; using a timer that timeouts every 30 minutes like the following picture peridocially.

Passkey

Suppose I connected this peripheral with my iPhone when the passkey value was 345612.

After resetting the peripheral, the passkey will be 123456.

In this state (passkey equal to 123456), when my phone requests connection,

(since my phone used passkey 345612 in the past) will it connect? I hope I can get the reason too.

  1. If pairing + passkey is not possible, then I'm thinking of "phase shifting".

In detail, I'm thinking something like this since BLE blacklisting is impossible.

I want specific phones (let's say this is group A) to bond (with passkey) to my peripheral by triggering GPIO pins using the TM4C MCU.

When the TM4C is not triggering, then the nRF chip uses pairing with NUS, knowing that group A will not request connections and other phones will request connection.

Then do I need to call sd_softdevice_disable for "changing the phase" (passkey bonding - NUS pairing).

-Best Regards, Mango

Parents
  • First things first; you might be aware of this, but I'm writing it because it's a common misconception. The example you are referring to is a static passkey example, used for devices that want to pretend that they have a display by having a static code instead. It offers basically no extra security over normal pairing with BLE_GAP_IO_CAPS_NONE, but it can be used to make sure that you are pairing with the correct device (out of many).

    Static passkey is NOT a form for password protection for the devices.

    1) Does passkey always require bonding?

    It doesn't require bonding specifically, but it does require pairing, since Passkey Exchange is a special step that only may happen during the pairing process. Bonding only adds the exchange of keys, so it only adds an extra step after the pairing procedure has completed successfully.

    2) does the passkey has to be numbers (ASCII 0, 0x30 ~ 9, 0x39)?

    Yes, the specification mandates this.

    3) Will a device be able to connect once the key changes?

    The static passkey has nothing to do with connection. It will only occur during a pairing/bonding attempt, and only if at least one side requires MITM, you have display IO caps and the peer has keyboard IO caps. If you meant to ask if it would encrypt successfully, then the answer is yes, but only if the devices bonded. The static passkey is only involved in calculating the session temporal key, which is only used during the very first encryption after pairing. In future pairings, the devices can use the long-term key, but this is only exchanged during bonding. Without bonding, you would have to enter the pin again every time, and no history of the previous pin should remain - because you did not bond.

Reply
  • First things first; you might be aware of this, but I'm writing it because it's a common misconception. The example you are referring to is a static passkey example, used for devices that want to pretend that they have a display by having a static code instead. It offers basically no extra security over normal pairing with BLE_GAP_IO_CAPS_NONE, but it can be used to make sure that you are pairing with the correct device (out of many).

    Static passkey is NOT a form for password protection for the devices.

    1) Does passkey always require bonding?

    It doesn't require bonding specifically, but it does require pairing, since Passkey Exchange is a special step that only may happen during the pairing process. Bonding only adds the exchange of keys, so it only adds an extra step after the pairing procedure has completed successfully.

    2) does the passkey has to be numbers (ASCII 0, 0x30 ~ 9, 0x39)?

    Yes, the specification mandates this.

    3) Will a device be able to connect once the key changes?

    The static passkey has nothing to do with connection. It will only occur during a pairing/bonding attempt, and only if at least one side requires MITM, you have display IO caps and the peer has keyboard IO caps. If you meant to ask if it would encrypt successfully, then the answer is yes, but only if the devices bonded. The static passkey is only involved in calculating the session temporal key, which is only used during the very first encryption after pairing. In future pairings, the devices can use the long-term key, but this is only exchanged during bonding. Without bonding, you would have to enter the pin again every time, and no history of the previous pin should remain - because you did not bond.

Children
  • Thanks for pointing my misconception.

    However, what do you mean by Static passkey is NOT a form for password protection for the devices. ?

    Do you mean that, even the passkey value is 123456, any centrals can connect with the peripheral by

    typing the wrong passkey value (like 000000)? Or is it about encryption?

    Also, I check this link and this is quite similar to question 4.

    Implementing similar thing in the link, do I have to call sd_softdevice_disable when changing modes?

  • To clarify my statement again, static passkey is a way to pretend to have a display. It is only relevant in the pairing scenario, and has no effect on connection establishment. There is no mechanism in Bluetooth Low Energy that lets you require a password or pin code to connect to a device, although the passkey is often confused as such. The only type of access control (for connect requests and scan requests) is white-listing, with addresses and/or identity resolving keys (IRK).

    Once you are connected, you can start the pairing procedure however. And it is during the pairing procedure that the static passkey may be used - in the very specific scenario mentioned above. If the peer does not support security, or doesn't react to the initiated pairing attempt, it can freely read and write to characteristics that does not require a security mode above "OPEN".

    For your last question, I am not 100% sure, but I believe that you do not need to disable the SoftDevice to change the static passkey. You should avoid changing the static passkey while a pairing is in progress though.

Related