Feature request regarding Passkey authorization

[Wes]

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.

[Carles]

Hi there,

Without such a feature, the alternatives are: no security; cobbled-together security; or switching to a different chip vendor.

Why would the "Just Works" pairing method be "cobbled-together security" ?

For devices that have none or basic IO capabilities, you can use the Just Works pairing method, which is defined by the specification and supported by the SoftDevice, and gives you full encryption (albeit with no MITM protection).

[Pål Håland]

One additional comment to this one,

"Volume 3, Part H - Security Manager Specification, 2.3.5 Pairing Algorithms, 2.3.5.3" states that if the device displays the passkey, then that device shall display a randomly generated passkey value between 000000 and 999999.

If this passkey is printed on the casing of the device, then this passkey is as insecure as just works. Because visual lookup of the pin + sniffing the transaction of the pairing will enable decoding the link at a later point.

If you feel this security/pairing is insufficient it is possible to implement some proprietary encryption on top of this. This has to be done on both sides.