Custom authentication for MITM in LE Secure

[Nathan O.]

Hi,

I am working on a product based on an nRF52832 (SDK 15.3, S112 6.1).

The device uses the Nordic UART service, modified to force access parameters to JUST_WORKS for now.

The device has a couple of switches but no keypad or display. I would like to integrate authentication in the following manner :

1. The user (smartphone) connects to the device.
2. The user tries to access the Nordic UART service.
3. It then starts a pairing request to the device.
4. The device enter a special "waiting for authentication mode" where the LED indicates to the user that he needs to do a particular series of actions with the buttons to confirm it's wish to authenticate.
5. The user then press one button, and while keeping it presses a second button and release both (example of user actions)
6. The device acknowledges the identity of the user and the pairing is accepted.
7. Bonding info are stored for future encrypted connections

I know I won't get proper MITM protection that way but at least I should get something a bit better than Just Works : An attacker who does not have physical access to the device would not be able to confirm using the button presses and would then be rejected.

Is it something that is do-able ? If so how ?

I saw things on the forum related to using constant key with a keypress mode but haven't found any code example.

Regards.

[Vidar Berg]

Hi,

You can define a static passkey to use for pairing through the options API (sd_ble_opt_set) then claim to have display capabilities in your security parameters. This should allow you to support numeric comparison or Passkey bonding (MSC). But as you said, it won't give proper MITM protection. I recommend you to take a look at the discussions around that here in this thread: https://devzone.nordicsemi.com/f/nordic-q-a/35856/questions-about-lesc-mitm-and-passkey

The other alternative you suggested of implementing a custom authentication challenge at the application level should be an option as well. However, I think it may be easier to not interfere  with the pairing process (ie let it complete in step 3) but instead, make the FW app limit control access until the custom authentication is complete. Maybe consider deleting the pairing at step 7 if step 4-6 failed.

Regards,

Vidar

[Nathan O.]

Thanks for your answer.

From the tests I have made, it seems that anytime I set either DISPLAY or KEYBOARD capability, the smartphone shows automatically either a textbox or a code to enter on the device. I guess with the statis passkey the behavior would be the same ? I could then just tell the user (via the mobile app) to enter a specific static passkey but I don't see how it would allow me to setup the button press authentication I proposed in my question.

The objective with doing it via the pairing process was that the user would only have to do it once (on first pairing) and not on each connection. If I move the button press authentication process (steps 4 - 6) to the application layer, then I won't have a way to identify a smartphone from a previous bonded connection.

Or maybe there is a way to get information related to the bonding and handle a database of "application level authenticated device" on the application side ?

[Vidar Berg]

Nathan O. said:

Or maybe there is a way to get information related to the bonding and handle a database of "application level authenticated device" on the application side ?

 It is. You can use the Peer manager pm_peer_data_app_data_store() function to store app-related data for a bonded device. So this should allow you to make the authentication a one-time operation together with the bonding.

[Nathan O.]

Thanks, I'll investigate this path then.

Last question : on the link you posted before, someone mention a "20 attempts hack" available to guess a static passkey. Do you confirm this ? Is there any article / documentation regarding the easyness to hack it ? I would have assumes a hacker to have 1 change in a million to guess it...

[Vidar Berg]

I don't know how easy it would be to perform a MITM attack, but each pairing attempt leaks bits of information, so it is not a one in a million chance to guess the correct key. And as noted in the SD API documentation, "Repeated pairing attempts using the same preprogrammed passkey makes pairing vulnerable to MITM attacks." Maybe the peer manager PM_RA_PROTECTION feature could help to mitigate the risk.