Changing batteries in thermometer breaks encrypyion

[Komzpa]

Describe the bug
I looked at some gaps in my data and decided to change batteries in some of my pvvx-firmware flashed thermometers. After that they did not come back.

To Reproduce

• Enable and set up encryption
• Pull out battery from device and put it back in
• The counter resets on device but does not reset on receiver, rendering the sensor unusable.

Logger: bthome_ble.parser
Source: components/bthome/init.py:48
First occurred: March 19, 2024 at 7:15:41 PM (4875 occurrences)
Last logged: 12:42:54 AM

bed in-side CB9C: The new encryption counter (148) is lower than the previous value (154553). The data might be compromised. BLE advertisement will be skipped.
entrance 48 7E17: The new encryption counter (194) is lower than the previous value (67117068). The data might be compromised. BLE advertisement will be skipped.
nook 02CD: The new encryption counter (33221) is lower than the previous value (3103785729). The data might be compromised. BLE advertisement will be skipped.
bed in-side CB9C: The new encryption counter (149) is lower than the previous value (154553). The data might be compromised. BLE advertisement will be skipped.
plant shelf 531B: The new encryption counter (4723) is lower than the previous value (1642324699). The data might be compromised. BLE advertisement will be skipped.

Additional context
Probably need to reset encryption counter if there haven't been a correct value in last couple measurements/seconds? I've seen a note that only overflow is allowed for now, maybe it's ok to allow low values for restarting the sequence too.

[Ernst79]

Just restart Home Assistant and it should be fine again.

[Komzpa]

I restarted Home Assistant, this helped. However the issue seems to re-occur still:

It looks like voltage of the battery dipped once below good level, device rebooted and never came back in HA. I would love to be able to use these batteries a bit longer, they're reporting that they're 100% and device seems to work fine with just occasional hiccups.

[Komzpa]

The issue unfortunately continues to plague my setup.

[Ernst79]

So, the issue isn't the battery change (as you can fix that with a restart of HA, and will only occur once every one or 2 years). But the problem is more related to the fact that the sensor becomes out of range, e.g. due to low battery voltage (which can happen due to low temperature for example).

In the PR you propose. you allow for the encryption counter to be lower than the previous value once, to allow for this situation, right?

[Komzpa]

Yes. I bought a bunch of sensors from aliexpress and they came with 80-90% alive batteries. I assumed initially that the batteries in them died completely or below some level where they are not sending bluetooth anymore. However when I was changing batteries devices looked fine, and later the issue got repeated even on new batteries.

I will be slowly debugging the pull request as I learn how it all works here, I will not mind if someone picks it up before me either.

I allow a reset once per 100 advertisements, so if someone does a replay while main sensor is alive it will get jammed, but if there's only one on the line it won't. However if the counter resets in principle this means attacker can record high-counter advertisements (even one) and use them to jam low-counter real device, even now. Maybe it's worth disabling this protection at all for now and if needed maybe address it in v3 or later with tracing full state machine of the possibilities, and treat encryption as enhanced CRC instead until then.

[thecode]

@Komzpa my experience with sensors from AliExpress was that they sometime have old or cheap batteries that won't last long, but if I understand correctly you already replaced the batteries. Can you add a link to the sensor which is making you problems? I can try to order one to understand if it is an hardware issue and if there is a way to improve it.

[Komzpa]

@thecode these are LYWSD03MMC with pvvx firmvare 4.7 and BTHomev2 + encryption enabled. The listing I ordered from is not up anymore but it was 10-pack from this store: https://aliexpress.ru/store/5064078, devices feel legit. I replaced the batteries in three of them, I see that it did not solve the issue in them so I stopped replacing batteries for now.

If I disable encryption my HA starts hallucinating new sensors at those devices supposedly due to some bit flips. Could it be that some CRC is not being checked on some other level? I see there is supposedly three octets of CRC on this diagram and that should kinda be enough to reject faulty messages?

[Komzpa]

Findings of this weekend:

• I read through HA core, bthome-ble code and BlueZ docs and cannot find any place where CRC is being checked. ChatGPT suggests it's in the adapter firmware but internet is full of advice how to implement your own CRC checking-or-recovery in those advertisements when making your ble thingy. Someone more knowledgeable should look into it, for now it looks like CRC is indeed never checked.

• The actual issue after debugging in my env seems to be that when encryption counter gets corrupted the decryption fails but the counter gets reset to corrupted value anyway. You can likely fix that by swapping the block of code that decrypts and the code that checks the counter to check the counter after decryption.

[Ernst79]

The encryption part is also a bit out of my knowledge field. We use the same type of encryption as xiaomi-ble / xiaomi MiBeacon. But that is due to my limited knowledge, we just copied that more or less.

[thecode]

@Komzpa I have the same device from same seller, but didn't flash it with custom firmware, I will try to flash with pvvx firmware this weekend and report back.

The CRC is part of the Bluetooth receiver, not of this project, as far as I understand if the CRC is incorrect the receiver will drop he packet.

[Komzpa]

I'm running #119 for 5 days on my system without issues. I hope that can be reviewed and merged.

[Ernst79]

@thecode you mentioned that you were going to do some tests, did you had time to do that? Can we merge the PR #119 ?

[thecode]

Sorry, I somehow missed this comment, I think it is good

[Ernst79]

Should be fixed in 3.9.3