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.

[Ole Morten]

Lots of Nordic employees here already, but I'd like to highlight a couple of things that you should be aware of: Even when using a passkey an attacker that listens in to the bonding can decrypt all later communication between the two devices bonding. This is also mentioned in the spec, Volume 3, Part H, section 2.3.5.4:

The Passkey Entry STK generation method provides very limited protection against eavesdroppers during the pairing process because of the limited range of possible TK values which STK is dependent upon. If the attacker is not present during the pairing process then confidentiality and authentication can be established by using encryption on a future connection.

However, a randomly generated passkey gives you protection against MITM attacks (1):

The passkey Entry method provides protection against active “man-in-the-middle” (MITM) attacks as an active man-in-the-middle will succeed with a probability of 0.000001 on each invocation of the method.

Implicitly, a random passkey also means that the user can be certain which device he have bonded to (2), which may be useful if he has several equal devices.

If you print the passkey on a label, and assume that an attacker can read the label beforehand, (1) above is lost. If the passkey on the label is the same on all devices, both (1) and (2) are lost.

In my opinion, having a requirement to use a passkey is hence meaningless. The requirement should state what kind of security you want, and what kind of attacks you want to protect against.

• If you need protection against an eavesdropper listening in while bonding, you have to solve this on the application layer.
• If you can assume that bonding happens in a secure environment, but want to protect against eavesdroppers later, it doesn't matter at all whether you use Passkey or Just Works, since they both end up using the same kind of encryption.
• If you need protection against MITM-attacks (1), you have to use a random passkey with a display (or assume that the attacker can't read the label beforehand, and can then use labels with passkeys that are unique per device).
• If you need the ability for the user to know for sure which device he bonds to (2), but don't really care about the security level, you can use labels with passkeys that are unique per device (or a display with random passkeys).