• State Verified Answer
  • Replies 2 replies
  • Subscribers 64 subscribers
  • Views 1514 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 101523
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ble_app_proximity without bond_manager

Olivier Scalbert

Hello,

I am playing with the s110 ble_app_proximity example. As I do not want to store info in flash, I do not want to use the bond manager, that stores data in flash. I have naively comment out the bond_manager_init(), but now I have problem to connect ... It seems I do not receive the BLE_GAP_EVT_CONNECTED. What should I do ?

Thanks,

Olivier

  • 0

    Does the board actually start advertising? If not, I'd recommend you to follow the steps outlined in this question, with regard to app_error_handler().

    In general, if you don't want to use the bond manager, you still have to make sure that you reply all the neccessary events coming from the softdevice, primarily the BLE_GATTS_EVT_SYS_ATTR_MISSING event, that's normally handled by the softdevice. The most basic way to reply to this is the following, in main.c's on_ble_evt():

    
        case BLE_GATTS_EVT_SYS_ATTR_MISSING:
            err_code = sd_ble_gatts_sys_attr_set(m_conn_handle, NULL, 0);
            APP_ERROR_CHECK(err_code);
            break;

    If you want to support establishing encryption on the link, only not storing the bonding information, you should also set the SEC_PARAM_BOND to 0.

    However, I have to say that this request sounds a little strange. Why exactly do you want to avoid flash writes? Do you not want to use encryption at all, or do you want to do encryption, but just not store any keys?

    If you want to do the former, you should be aware that some of the Bluetooth SIG services actually requires the use of encryption to be spec compliant.

    If the latter, you should be aware that any attacker listening in on the key exchange of BLE will be able to eavesdrop all communication, rendering the entire encryption ineffective. In the common case, where both devices store the keys, this is not as much of a problem, since two devices exchanges keys only once. An attacker would therefore have to be listening in while bonding, or else he will not be able to decrypt later communication. However, if you don't store keys, this key exchange will happen on each and every connection, and hence make eavesdropping a lot easier. Also, at least on iOS, you will get the pairing popup that the user have to manually press for each connection if you don't store the keys, which may make the user experience less than optimal.

    I'd therefore recommend you to think thoroughly through the implications of this choice before doing it.

    Edit: Language clarification.

Related