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

Disable encryption on "Just Works" pairing on NRF52DK

Hey guys,

I'm working on a project and want to build up on the Nordic BLE UART example (mobile device app and node firmware). As far as I know the pairing between the node and, e.g., a mobile device works with the "just works" method in the stock examples and there is by default an unauthenticated key exchange for link encryption, right? In my use case the encryption isn't necessary, is there a way to skip this key exchange and thus the encryption? E.g. by changing some settings in the GAP or GATT initialisation?

Thanks in advance!

Bruno

Parents
  • Hi Bruno,

    BLE UART rejects pairing requests by default which prevents the connection from being secured like you wanted. A pairing requests is rejected by replying  BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP on the BLE_GAP_EVT_SEC_PARAMS_REQUEST event  like shown in code snippet below (MSC). 

    /**@brief Function for handling BLE events.
     *
     * @param[in]   p_ble_evt   Bluetooth stack event.
     * @param[in]   p_context   Unused.
     */
    static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
    {
        uint32_t err_code;
    
        switch (p_ble_evt->header.evt_id)
        {
        ...
            case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
                // Pairing not supported
                err_code = sd_ble_gap_sec_params_reply(m_conn_handle, BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, NULL, NULL);
                APP_ERROR_CHECK(err_code);
                break;
        ...
        }
    }

    If you wonder if a particular example support pairing and bonding, just check if it uses the Peer Manager module.   

Reply
  • Hi Bruno,

    BLE UART rejects pairing requests by default which prevents the connection from being secured like you wanted. A pairing requests is rejected by replying  BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP on the BLE_GAP_EVT_SEC_PARAMS_REQUEST event  like shown in code snippet below (MSC). 

    /**@brief Function for handling BLE events.
     *
     * @param[in]   p_ble_evt   Bluetooth stack event.
     * @param[in]   p_context   Unused.
     */
    static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
    {
        uint32_t err_code;
    
        switch (p_ble_evt->header.evt_id)
        {
        ...
            case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
                // Pairing not supported
                err_code = sd_ble_gap_sec_params_reply(m_conn_handle, BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, NULL, NULL);
                APP_ERROR_CHECK(err_code);
                break;
        ...
        }
    }

    If you wonder if a particular example support pairing and bonding, just check if it uses the Peer Manager module.   

Children
  • Hey Vidar,

    many thanks so far for your answer Slight smile

    But this leads to new questions, in order to check, if I'm getting it right. Sorry for my silliness!

    I always thought that there is turned on encryption by default with every established connection, i.e., I thought both parties (node and smartphone) were exchanging short term link keys in order to encrypt the following exchanged messages. Furthermore, if they would like to or the use case would require it, they could even bond to each other by exchanging long term keys. (As I already suggested, the latter one was not part of BLE UART example)

    But taking your answer into account this means, there is never link encryption enabled by default on connection establishment, except one has enabled it explicitly, e.g., with Peer Manager, right?

    Thanks again and best regards

    Bruno

  • Hi Bruno,

    No problem:) The Peer Manager handles security requests for the application making it easy add support for pairing and bonding, but it does not mean that the connection must be secured. That requirement is imposed by the security levels you have set on your characteristics. In other words, it's not necessary to  secure the link if all characteristics are set to have "open" read/write access, even if you have implemented the peer manager.  

    Security requirements for the tx characteristic in ble_nus.c are set to "open"

    uint32_t ble_nus_init(ble_nus_t * p_nus, ble_nus_init_t const * p_nus_init)
    { 
        ...
        // Add the TX Characteristic.
        /**@snippet [Adding proprietary characteristic to the SoftDevice] */
        ...
    
        add_char_params.read_access       = SEC_OPEN;
        add_char_params.write_access      = SEC_OPEN;
        add_char_params.cccd_write_access = SEC_OPEN;
        
        ...
    }

    But could have been "SEC_JUST_WORKS" to prevent access from un-paired/bonded peer devices. 

    Vidar 

  • Hi Vidar,

    thank you so much!!! You really helped me a lot.

    Bruno

Related