• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 1218 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.

A bonded client forgets about its bonding

Oliver Mader
Prodigy 180 points
Other Parts Discussed in Thread: CC2540

Hey,

in my scenario exists a peripheral (cc2540) with a bonded iPhone 5 client. The questions is what happens if the iPhone forgets about the bond, e.g. the user removes the paired peripheral from the settings. I assume the bond on the peripheral remains, because if I connect again and try to read a characteristic which needs authentication the iPhone doesn't recreate the bond and I get errors about insufficient permissions.

The problem exists basically in both case if one of the communication partners forgets about the bond. What is the correct behavior in such case?

Thanks in advance

  • 0
    TI__Mastermind 23440 points

    Hi Oliver,

    Where do you get this message? What does it say?

    In essence, iOS is a bit buggy when it comes to the case where one side has forgotten the pairing. If the bond exists, the CC2540/41 stack will say "insufficient encryption", which iOS at least 6.0.1 doesn't understand; it's expecting "insufficient authentication", which is what is sent when the two parties haven't been authenticated. If a bond exists, authentication is assumed to have been done, so only re-enabling of encryption is asked for by the peripheral.

    A workaround is to modify the read callback for the given service on the CC2540 and, depending on what UUID is requested to be read, always return INSUFF_AUTHEN, and at the same time remove _AUTHEN_ from the ATT table permissions to work around the "correct" logic.

    someReadAttrCB()
    {
      bStatus_t status = SUCCESS;
    <-- -->
      // Require security for all characteristics
      if ( linkDB_Encrypted( connHandle ) == FALSE )
      {
        return ATT_ERR_INSUFFICIENT_AUTHEN;
      }
    <-- -->

    The correct behavior as I read the BT Core Spec would have been:
     - iOS loses key; iOS receives INSUFF_ENCRYPT -> re-pair, because the fault is on iOS side.
     - Peripheral loses key; iOS receives Reject Indication Key Missing -> notify user because of potential security risk, then re-pair

    The last time I tried, iOS didn't handle the reject indication.

    Best regards,
    Aslak 

  • 0 in reply to Aslak N.
    Prodigy 180 points

    Hey Aslak,

    thanks for your fast response.

    The suggested workaround indeed does what it should, for the first behavior. The second one doesn't work properly as you pointed out. But the problem lies on iOS side. Thanks for the clarification.

    Sincerely, Oliver