DFU OTA of encrypted peripherals from MITM to LESC causes subsequent LTK encryption to fail

RE: DFU OTA of encrypted peripherals from MITM to LESC causes subsequent LTK encryption to fail

Hung Bui — Thu, 22 Sep 2022 08:07:41 GMT

Hi Roi,

The easiest way is to clear the application database after you do DFU update. You can write a signature in flash to mark that it's the first time the new firmware running or not.
So if the application start fresh then you will not have any problem with "allow re-pairing". You can keep it as NO and the device will bond to the central as a new device.

The only draw back I can see is that the user will have to bond the central with the peripheral again , this time with LESC + passkey.

I don't see any other solution that can increase the security without re-bonding.

RE: DFU OTA of encrypted peripherals from MITM to LESC causes subsequent LTK encryption to fail

Roiger — Wed, 21 Sep 2022 14:48:38 GMT

Gotcha.
So lets step back a second:
What would be the safest way to go about this from scratch?
We have MITM peripherals, bonded and encrypted with an mitm only (not OOB) LTK, which as you say is "sniffable".
After DFU to lesc - how would we go about re-pairing the centrals in the most correct way?
Thanks!

Roi

RE: DFU OTA of encrypted peripherals from MITM to LESC causes subsequent LTK encryption to fail

Hung Bui — Wed, 21 Sep 2022 13:47:19 GMT

Hi again Roi,

With regard to #1. If the "not LESC MITM" was performed with OOB (NFC for example) then the LTK generated from such bond can be considered safe. But if the LTK was generated by passkey then it shouldn't be considered safe. Anyone within the radio range with a sniffer that listen to the bonding process (when the LTK generated) can get the LTK.

On #2 , it's up to you, but as mentioned, with legacy bonding only MITM with OOB can be considered secure. Legacy MITM with passkey is not safe. LESC MITM with passkey is considered secure.

RE: DFU OTA of encrypted peripherals from MITM to LESC causes subsequent LTK encryption to fail

Roiger — Wed, 21 Sep 2022 13:03:19 GMT

Hi Hung!
Thanks very much for your swift and informative reply!
I think it would be best if I try and focus our more general question into a specific case, and maybe we can discuss it from there:

1) Our current logic dictates that non-MITM_protected and/or non-LESC connections are immediately disconnected. My suggestion is to broaden this to include our non-LESC but yet MITM LTKs, in that if a device is none of the following, it will be disconnected:

mitm_protected and lesc - this is a new device that is pairing with lesc, and this is fine by us.
not lesc, but mitm_protected and bonded and encrypted - this should cover our MITM-only LTKs case

2) Characteristics will revert to being mitm protected, and not lesc protected

Can this described case be taken advantage of in any way you can think of? Is this safe and best-practice?

Many Thanks ahead of time!

Roi

RE: DFU OTA of encrypted peripherals from MITM to LESC causes subsequent LTK encryption to fail

Hung Bui — Wed, 21 Sep 2022 08:41:45 GMT

Hi Roi,

I assume the other question Moving from MITM to LESC can be handled here and we can close it.

Could you let me know the main goal of moving from legacy MITM to LESC MITM and keeping LTK ? It's to support the future bond that it should use LESC+MITM or to improve the current bond (current LTK) that the security level of the same LTK change from legacy MITM to LESC MITM ?

By using the previously shared LTK, the level of security when you connect and encrypt will remains the same as it was before, I believe in this case level 3, not level 4 as MITM+LESC is.

So if you configure your characteristic with level 4 encryption requirement, then it will not allow the peer device to access if the security level doesn't meet the requirement.

As far as I know the LTK of legacy MITM bond and LTK of LESC bond are exchangeable. I don't see any different with the LTK between LESC and legacy bonding, except on how it's generated. But not on how it's used after the bond has already be established.

So what we need to look at is why the bonding is failed.

Have you checked and made sure the same LTK has been used after you do DFU update , to see if the peer manager is able to read the key after the DFU update ?
I would suggest to capture a sniffer trace to see what happens when the link is established after DFU update. And also check the log on both device to see which error you have.

Regarding "m_flag_allow_repairing ", you should use it with care. As you already notice, by enabling this, there is a security risk that attacker can pretend to be your central and force a new bond with your device.

So you may think of a secure way of doing this , for example using an extra challenge response scheme , that only when the peer passes a challenge from the application, you allow the re-pairing to be enable and they can bond after that.