• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 53 subscribers
  • Views 2470 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BLE Pairing

Xu Li1
Prodigy 70 points

Other Parts Discussed in Thread: CC2540

I am trying to test the Keyfob demo with iOS app "Bluetooth Multitool", and problem occurred when I modified the keyfobdemo.c file as follows:

// Setup the GAP Bond Manager
  {
    uint8 pairMode = GAPBOND_PAIRING_MODE_INITIATE;
    uint8 mitm = TRUE;
    uint8 ioCap = GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT;
    uint8 bonding = TRUE;

  .......
  }

The only slight change allowing "Just work" pairing will caused problem when I pressed "Cancel" for pairing, and the iOS app keep asking for pairing again and again! Can someone tell me where the problem is?

  • 0
    Expert 2170 points

    I believe MITM protection is not possible with GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT;  suggest you try same with mitm=FALSE.

  • 0 in reply to Richard Dolf
    Prodigy 70 points

    Thank you for your reply. But the problem is still not been solved. The first time I clicked 'Cancel', and next time I clicked 'Pair', and it would show me pairing dialog again and again. I guess the hardware side does not response properly when users click 'Cancel' with iOS app, which would cause problem with the following pairing process. Can you suggest anything?

  • 0 in reply to Xu Li1
    Prodigy 20 points

    Have you made any progress on this? I've been trying the same thing today. I don't have any issues writing to an attribute tagged as GATT_PERMIT_AUTHEN_WRITE when I use GAPBOND_IO_CAP_DISPLAY_ONLY and type in the passkey on the iPhone. I used the sniffer to capture the sequence and I can see the write request which triggers the pairing and then the pairing exchange and finally the value being written properly in a secure packet.

    When I change the peripheral IO capabilities to GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT, the pairing dialog displays on the iPhone and after I hit pair, a second or so later the alert opens again. This goes on over and over. Looking at a sniffer capture, this case starts very similarly where the iPhone tries to write the attribute, an error (INSUF_AUTHENTICATION) is returned so the iPhone initiates pairing. Pairing completes and I see secure packets exchanged. However, this time when the iPhone tries to write the attribute with a secure packet, the peripheral once again replies with the INSUF_AUTHENTICATION error so the iPhone initiates pairing again...

    Is there something else that needs to be done beyond the initial pairing to enable attribute writes in the "just works" pairing mode?

     

  • 0 in reply to Mike Foley1
    Expert 2170 points

    Security procedures can occur at two different points in time:
    1) when either device requests that the connection be encrypted
    2) when the central device tries to read/write a characteristic whose permissions require authentication.

    Case 1:
    - if either device requires MITM protection, the link is authenticated and encrypted with user input (or some OOB process). Authentication will fail if either device has no io capabilities (GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT).
    - if neither device requires MITM protection, 'just works' procedure is used to encrypt (but not authenticate) the link.

    Case 2:
    - Authentication requires user input which in turn requires that both devices have some IO capabilities.

    In summary, GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT is incompatible with MITM=true and is incompatible with GATT_PERMIT_AUTHEN_WRITE or GATT_PERMIT_AUTHEN_READ

  • 0 in reply to Richard Dolf
    Genius 4125 points

    I found the same as per Richard's response above. See my post here also:

    http://e2e.ti.com/support/low_power_rf/f/538/t/302987.aspx 

  • 0 in reply to Richard Dolf
    Prodigy 20 points

    Thanks. I've been starting security following Case 2. For my current app, I don't need MITM middle protection so I'll try to proceed down Case 1. From my initial testing this afternoon, I don't see the API to have the CC2540 peripheral make this request, but I'll keep looking. If not, I'll just require PIN input.