LSC Security Benefits with Static Passkey

[moon.kim]

Hi. 

I try to implement LESC using nRF52810.

But I use a Static passkey because my device doesn't have a keyboard or display.

One question is, is LESC more secure than Legacy when using a Static passkey?

I understand that using a Static passkey is not safe from MITM attacks. Is LESC safe from MITM attacks when using Static Passkey?

I've been pondering for days and couldn't come to a conclusion.

[Simonr]

Hi

LESC is generally more secure than Legacy mode, so I would suggest using LESC over Legacy either way. Keep in mind that LESC was introduced in BLE v.4.2, and will not work if both devices don't support BLE v.4.2 or newer.

Using LESC with a static passkey should provide sufficient protection against MITM attacks as long as you don't leak that static passkey somehow. This way only the two devices that are pairing should have access to the static passkey, and protect against MITM that way. You can check out this link for some documentation if you'd like. Static passkey would fall under the PasskeyDisplay method where both devices enter the key. I would also suggest checking out if the ECDH key generation would be of interest to you, as this is, by far, more secure than using "just" a pass-key.

Best regards,

Simon

[moon.kim]

Hi, Simonr

I have a few questions.

1. Using the static passkey corresponds to the PasskeyDisplay method.

Simonr said:

Static passkey would fall under the PasskeyDisplay method where both devices enter the key.

If so, can't static passkey be used in Numeric Comparison using ECDH?

2. I have seen about LESC, MITM and passkey before. According to this, using static passkey, LESC is also vulnerable from MITM attack. 

Which parts are safer from MITM attacks compared to LE Leagcy?

The Bluetooth specification states that the passkey should be randomised for every pairing attempt. 
The protocol is not designed to be used with a static passkey. 
If you use a static passkey in the LESC model, as mentioned in the referenced post, an attacker trying to "log in" to your device will succeed in at most 20 attempts since for every failed attempt, it will reveal the next bit that was incorrect. 
The protocol is built upon 80 exchanged packets, where 4 packets, 2 in each direction confirms that 1 extra bit of the passkey match between the two devices.