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

Feature request regarding Passkey authorization

I'd like to make a feature request for the S110 SoftDevice and the nRF51822 SDK. The problem centers around the inability to use passkey authorization on a device that does not have an LCD screen. In many applications, it is either not possible or not practical to add an LCD, yet some level of security is still required.

I propose that a method be added to the SDK, perhaps like this: sd_ble_gap_sec_params_set_passkey(new_passkey);

This could be called when GAP_EVT_SEC_PARAMS_REQUEST or GAP_EVT_PASSKEY_DISPLAY is processed. Calling sd_ble_gap_sec_params_set_passkey(new_passkey); would overwrite the randomly generated passkey in the SoftDevice with one retrieved from flash memory (for example).

I realize that without internal knowledge of the SoftDevice, this might be a difficult feature to implement, but I really hope that it's possible to add something like this. Without such a feature, the alternatives are: no security; cobbled-together security; or switching to a different chip vendor. I really think the community would be happy to see this feature added. Other than this issue, the nRF51822 has been awesome and I'm really excited to be using it.

Parents
  • Hello Carles,

    I did not mean to imply that Just Works security is cobbled-together. What I meant was implementing passkey functionality on top of Just Works could lead to "cobbled-together code" on the central and peripheral sides. Just Works does give encryption, and that's great.

    Hello Pål,

    We would not be printing the passkey on the device itself.

    So far, it's a business requirement for us to have a passkey, and I believe others have the same requirement. See for example these two threads: Thread 1 Thread 2

    Pål, you also raise an excellent point that the BLE spec calls for a random passkey. I'm not 100% certain, but I believe TI allows static passkeys on the CC2540. See for example this document and search for passkey. So yes the BLE spec does call for a random passkey, but from a business requirement point of view, many applications still absolutely call for a passkey even when the spec would insist on using Just Works.

    As a developer, I'm not an expert in the real world usage of the device we are making. I don't know if Just Works would really be sufficient or not. What I do know, is that support for static passkeys would keep my code more readable and maintainable, rather than layering on a custom passkey functionality on top of Just Works.

    Anyways, thanks for taking the time to respond.

    Wes

Reply
  • Hello Carles,

    I did not mean to imply that Just Works security is cobbled-together. What I meant was implementing passkey functionality on top of Just Works could lead to "cobbled-together code" on the central and peripheral sides. Just Works does give encryption, and that's great.

    Hello Pål,

    We would not be printing the passkey on the device itself.

    So far, it's a business requirement for us to have a passkey, and I believe others have the same requirement. See for example these two threads: Thread 1 Thread 2

    Pål, you also raise an excellent point that the BLE spec calls for a random passkey. I'm not 100% certain, but I believe TI allows static passkeys on the CC2540. See for example this document and search for passkey. So yes the BLE spec does call for a random passkey, but from a business requirement point of view, many applications still absolutely call for a passkey even when the spec would insist on using Just Works.

    As a developer, I'm not an expert in the real world usage of the device we are making. I don't know if Just Works would really be sufficient or not. What I do know, is that support for static passkeys would keep my code more readable and maintainable, rather than layering on a custom passkey functionality on top of Just Works.

    Anyways, thanks for taking the time to respond.

    Wes

Children
No Data
Related