This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2540 pairing/bonding process

Other Parts Discussed in Thread: CC2540

Hi, I have many questions related to BLE pairing/bonding process, search through the internet gives no valued result, so I ask here.

Firstly I meet problem trying to pair 2 CC2540 central and peripheral (I use simpleBLE sample code, BLE lib version 1.3).

Setting for central device: GAPBOND_PAIRING_MODE_INITIATE, MITM=TRUE, BONDING_MODE=FALSE, GAPBOND_IO_CAP_DISPLAY_ONLY.

Setting for peripheral: GAPBOND_PAIRING_MODE_WAIT_FOR_REQ, MITM=TRUE, BONDING_MODE=FALSE, GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT

But the pairing process is always SUCCESS, event if I program 2 different passcode into 2 device. What is wrong?

And I have some questions:

1. Are pairing and bonding 2 different process? Pairing is process to share passcode, create keys, encrypt link... and Bonding is process to save these key, is it right?

2. In simpleBLE sample project, the link encryption is done in pairing process or I need to add this function myself?

3. I use only passcode (6 digits PIN) to pair 2 device, and then the connection is keep in long run, and no more authentication is done in this long time, so is there any chance the man-in-the-middle can trick my connection and fake 1 of 2 devices?

Any comment helps me very much. Thank you.

  • Hi Tuan,

    1. They are different processes. Pairing is the process of sharing Short Term Keys (STKs) used to encrypt the link. If bonding option is selected, Long Term Keys (LTKs) will be exchanged as well for later use upon re-connection for fast re-encryption without having to go through the whole pairing process again. It's the process of re-connect + re-encrypt that's called bonding. Pairing is only valid for a particular connection.

    2. Correct.

    3. The whole idea with MITM protection is that you transfer a key outside the BLE link. This could be a passcode (shown on a display on one device and entered on the other) or NFC or any other medium that allows out of band authentication. If you have stated "no I/O capabilities" (GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT), you will not authenticate the link. The pairing method will be JustWorks instead of pin/passcode, this is how you would "trick" the solution.

    Best Regards


  • Thank you for your answers, Joakim.

    1 & 2. I understand, thank you.

    3. So I misunderstood. I though that giving IO_CAP_NO_INPUT_NO_OUTPUT will let both 2 devices to use DEFAULT_PASSCODE.

    But my question #3 is: If the link is encrypted, is there any chance that the 3rd person can listen and trick/fake to become 1 of 2 connected device and talk to other?

  • Hi, could you please help, my pairing process still do not work properly.

    On central side, I set IO_CAP_DISPLAY_ONLY, and remove "simpleBLECentralPasscodeCB".

    On peripheral side, if I set IO_CAP_KEYBOARD_ONLY, the central will check the PIN and return "pairing fail" if PIN is not match. But if I set IO_CAP_NO_INPUT_NO_OUTPUT, then the Central do not check PIN anymore and the pairing process is always SUCCESS. So it's very easy for anyone else to connect to my central device and destroy my system.

    How to make the central device always check peripheral 's PIN?

  • Hi Tuan,

    Tuan Pham said:
    But my question #3 is: If the link is encrypted, is there any chance that the 3rd person can listen and trick/fake to become 1 of 2 connected device and talk to other?

    Only if the 3rd person was eavesdropping during pairing process and performed man in the middle attack. 

    Tuan Pham said:
    So it's very easy for anyone else to connect to my central device and destroy my system.

    Then have a check at the application level if the connected device can be trusted, by for example having a unique number stored in a characteristic. You can also check IEEE address (if it's known).

    Best Regards

  • Thanks Joakim,

    Joakim Lindh said:

    Only if the 3rd person was eavesdropping during pairing process and performed man in the middle attack. 

    I'm glad to hear this :)

    Joakim Lindh said:

    So it's very easy for anyone else to connect to my central device and destroy my system.

    Then have a check at the application level if the connected device can be trusted, by for example having a unique number stored in a characteristic. You can also check IEEE address (if it's known).

    [/quote]

    I mean I need to check if the pairing process is success with any method other than "Just works", but currently I cannot find how to check, my BLE central always indicates PAIRING SUCCESS.

    From Bluetooth specs, if one of devices set IO_CAP_NO_INPUT_NO_OUTPUT, then passkey will not be used. So I cannot use "passkey entry" method, I will change to use out-of-band.

    From Bluetooth specs also:

    If the initiating device has Out of Band data and the responding device does not have Out of Band data then the responding device may send the Pairing Failed command with the error code “OOB Not Available” instead of the Pairing Response command.

    I tried: I set OOB_enabled_flag to FALSE on Peripheral, and expect my Central to indicate PAIRING FAIL, but no, it's still SUCCESS.

    So, how can I force my Central device to use "passkey entry" or "out-of-band" only, if these 2 method cannot be used, so return Pairing FAIL?

    If pairing is always success, how can I know which method was used?

  • Hi, thanks Joakim for answers, now I understand the whole image of Bluetooth security, there are 3 difference processes: pairing, authenticating, and bonding.

    For my latest problem, I need to check the authState in gapAuthCompleteEvent_t packet, and I can get the authentication status which is zero if "Just works" was used.

    Thank you again.

  • Hi Pham,

    unfortunately the answer to your question is YES, there is a chance that the 3rd person can listen the encrypted communication.

    Foollow this presentation by Mike Ryan: http://lacklustre.net/bluetooth/how_smart_is_bluetooth_smart-mikeryan-shmoocon_2013.pdf

    And also see his web site: http://lacklustre.net/bluetooth/#talks

    Gabriele

  • Hi Everyone,

    Sorry to "awake" this thread, I have a few questions regarding this topic.

    I am implementing an application using the Keyfob demo project as a base.  I am looking for a solution with the following features:

    1) The application only allow the connection /pairing from new devices(smartphone for example) when a certain Pin of the CC2540 microcontroller is turned High (pressing a button for example)

    2) The application allows the connection /bonding of devices that were previously paired.

    For this reason I have some questions related with this thread. 

    1) Can I I perform the 1) Feature using as default the GAPBOND_PAIRING_MODE equal to GAPBOND_PAIRING_MODE_NO_PAIRING and after, when the button is pressed I put the GAPBOND_PAIRING_MODE equal to GAPBOND_PAIRING_MODE_WAIT_FOR_REQ?

    2) In  this situation (GAPBOND_PAIRING_MODE equal to GAPBOND_PAIRING_MODE_NO_PAIRING) the bonding will still work in the same way and accept previously paired devices?

    3) What is the difference between the GAPBOND_IO_CAP_DISPLAY_ONLY and GAPBOND_IO_CAP_KEYBOARD_DISPLAY? In both the situations it is necessary to perform the pairing with pass code for a connection with a new device, right?

    4) How can I erase all the devices from my bond table?

    Many thanks in advance, 

    Miguel

     

  • Hi,

    Can anyone give me some help. I really need it.

    Thanks in advance,

    Miguel