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

[Roiger]

Hi,
Following my previous ticket on the matter, Moving from MITM to LESC  , I have attempted to DFU an MITM bonded device to LESC code, such that the peripheral device will disconnect connections that are not lesc and mitm_protected (the disconnect on mitm_protection had already existed in our code before, as explained in my previous ticket).

As a result, the subsequent connection fails, since the LTK that was used for MITM-only encryption is not LESC.

I have also attempted to re-authenticate - but the peripheral disconnects the central given that a bond already exists..

As I see it, we have a few possible solutions:

• Given a connection that is already bonded+encrypted+mitm_protected but not lesc, peripheral should delete it's bond data on the central, and return a disconnect message which the central would then perceive as "erase LTK for this etag". This would initiate pairing from scratch (with LESC) on the subsequent connection. We are not fond of this solution, as we are not sure of all the security repercussions, and would not like a potential attacker to be able to cause us to delete bonds by pretending to be our central. If we would use this solution, it would only be as a patch until a better solution is reached, or this DFU is deemed impossible.
• Changing our aforementioned disconnect case from "not lesc or not mitm_protected" to "not mitm_protected or not encrypted". Again, the same questions arise.
• m_flag_allow_repairing is set to false in our code - we could set it potentially to true, allowing us to authenticate even if an LTK already exists on the central.

My question in essence is:

• Is one of the aforementioned solutions good practice? If so, which one?
• If not - what is the best practice to DFU peripherals in the field from mitm only to mitm+LESC? Is this possible?

Thanks!

Roi

[Hung Bui]

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. 

[Roiger]

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

[Hung Bui]

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. 

[Roiger]

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

[Hung Bui]

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.