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.

[Wes]

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

[Øyvind]

Hi Wes,

Have a look at Out Of Band (OOB) pairing. With OOB pairing, the applications will have to provide the protocol implementations with authentication data on both sides, as the intention is that the OOB data is shared between the devices in a way unknown to the stack. See Volume 3, Part H - Security Manager Specification, 2.3.3 OOB Authentication data.

[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).