This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF51822 Peripheral with Passkey

Hi, like many others, I'm confused with Peripheral Passkey Connection.

I'm playing with the ble_app_hrs, in order to be able to setup a Connection Passkey (for the moment I would like to have a static hard-coded passkey). The goal of my application is to connect to the nRF51822 Peripheral using a Smartphone/Tablet and to be prompted to input a Passkey.

On main.c I set up these sec parameters:


#define SEC_PARAM_TIMEOUT                    30    
#define SEC_PARAM_BOND                       1
#define SEC_PARAM_MITM                       0
#define SEC_PARAM_IO_CAPABILITIES            BLE_GAP_IO_CAPS_KEYBOARD_ONLY
#define SEC_PARAM_OOB                        0
#define SEC_PARAM_MIN_KEY_SIZE               7
#define SEC_PARAM_MAX_KEY_SIZE               16

Then in the function on_ble_evt(ble_evt_t * p_ble_evt) in the case BLE_GAP_EVT_CONNECTED I've added err_code = sd_ble_gap_authenticate(m_conn_handle, &m_sec_params); to let the Peripheral initiate the security establishment (is this correct?).

The call of this function generates the event: BLE_GAP_EVT_SEC_INFO_REQUEST which I think I should reply with sd_ble_gap_sec_info_reply, is it correct?

I can't understand how to fill the parameters for the sd_ble_gap_sec_info_reply

Are those sec parameters correct for this application purposes?

Thanks for any help/suggestions.

Regards, Samuele.

Parents
  • Hi, thanks for your answer.

    So, setting a static passkey to pair with a Peripheral Device seems to be unfeasible... unless you write your own application-auth layer on top of BLE.

    I was thinking about the passkey pairing because I have a BLE Peripheral Device that needs to work in 2 modes: CONF_MODE and WORK_MODE, in CONF_MODE the device should expose some configuration services/characteristics that only a Device Manager (the man who know the password) should be able to edit, while in WORK_MODE the device exposes others services/characteristics, those needed for its ordinary work. The two operating modes are switched by pressing a button on the board.

    Do you have any experience/suggestions/solutions on how to implement a BLE Peripheral Device that should be capable to authenticate only the users that have the right "password"?

    Thanks again for your answer. Regards, Samuele.

Reply
  • Hi, thanks for your answer.

    So, setting a static passkey to pair with a Peripheral Device seems to be unfeasible... unless you write your own application-auth layer on top of BLE.

    I was thinking about the passkey pairing because I have a BLE Peripheral Device that needs to work in 2 modes: CONF_MODE and WORK_MODE, in CONF_MODE the device should expose some configuration services/characteristics that only a Device Manager (the man who know the password) should be able to edit, while in WORK_MODE the device exposes others services/characteristics, those needed for its ordinary work. The two operating modes are switched by pressing a button on the board.

    Do you have any experience/suggestions/solutions on how to implement a BLE Peripheral Device that should be capable to authenticate only the users that have the right "password"?

    Thanks again for your answer. Regards, Samuele.

Children
  • I don't have any readymade suggestions for anything like this, but it's certain that implementing this on the application level is better than trying to use a static Bluetooth passkey for bonding. Since passkeys are only 6 digits, it would be trivial for someone to brute-force this if wanted.

    One possibility could for example be to have the two devices share a key beforehand (i.e. as part of the firmware image and of the app), and then doing encryption of a dynamically shared value, comparing the results and then only let the device access the configuration mode if the values matches. If security is of great concern, I would however recommend you to talk to some security expert before moving ahead, as there could very well be flaws in such scheme, that I've overlooked.

    Also, I think you're better off by just always having the services there, but just disallowing operations before authentication has been passed. This saves you the trouble of sending Service Changed indications and similar, when the service setup changes.

    Finally, since I believe my first reply answered your original question, I'd be happy if you could accept it, to clear up this question. :)

Related