BTHome is not secure at all

[tomasjakubik]

Hi, I was wondering how secure would something like Shelly BLU Button be for opening a garage for example. For me a basic replay protection is a must.

I found this bit of code. I see new_encryption_counter >= 100 as a condition to discard the advertisement. My guess would be that it needs to be more than > 0, because you would have only one attempt to sync after changing a battery.

Am I right that first 100 presses (and also 100 after 4 billion presses) are not protected from replay?

But I would expect something like > 10 and a clear description in the comment and in the device manual that you need to press it N times before it becomes secure-ish. I also wonder if Shelly gateway uses the same code?

If there was a two way communication (as discussed here #146) there could be a challenge response thingy which would be much more secure. The Shelly BLU Button seems like it can vibrate, so there has to be some sort of two way communication when used in the Shelly ecosystem.

[Ernst79]

BTHome is a BLE format that is used for passive BLE advertising, so it is limited to one way communication. For two way communication, reading and writing GATT characteristics is required, which is out of the scope of the BTHome project at the moment.

BLE advertisements are often send multiple times per minute, moreover BLE reception isn’t always as reliable as one would wish. I do understand that is not the case for things like buttons, but e.g the encrypted xiaomi sensors with with pvvx firmware can send like 20messages per minute. So, yes, overruling replay protection is possible in the first 100 messages. I don’t know a safer option to prevent this, without having sensors being blocked. It’s a balance between allowing some messages to not arrive after e.g. a battery change or counter cycle reaching the end, and blocking messages that should not be blocked.

[tomasjakubik]

Thanks for the response. I tried to improve the security in Home Assistant. If the message counter drops under 150, the garage door will block itself. It is just one boolean helper and one action more, no need for scripting. It it relatively easy to click through this in the beginning or when you change a battery. It shouldn't roll over 2^32 while the battery is alive.

I am not an expert on encryption, so I only hope you just cannot create a message with an arbitrary counter. For example by xoring a few bits over a recorded message. That would defeat the purpose of the encryption entirely.

I closed this issue, but feel free to change its state if this project uses a different process.

[tomasjakubik]

So I have some unfortunate new findings.

You need to manually enable encryption, otherwise it is totally unencrypted. You need the Shelly BLE Debug app. In there you can encrypt the advertisements, copy the key and insert it into Home Assistant.

But it doesn't matter at all, because this will accept unencrypted messages anyway. The attacker can compose an unencrypted message however and whenever he pleases. It will never get to the decrypt function in the first place.

Also, the Packet Id that gets to Home Assistant is not the encryption counter. I didn't find where that number is taken from. It wraps after 255, so it is unusable to do the protection I was planning to do in the Home Assistant.

Unless you can convince me otherwise (and fix the software):
⚠️ BTHome in Home Assistant is not secure at all! Never use it for opening doors nor for checking that the doors are closed! ⚠️

[Ernst79]

You are right that encryption is not giving full protection . The only protection BTHome offers is that broadcasted messages in encrypted mode can’t be read without encryption key. That doesn’t mean that other devices can send data, while pretending to be the first sensor. Unfortunately, I don’t think there is anything we can do about this, as BTHome is a passive BLE format (only broadcasting).

So I wouldn’t make automation that unlock your house.

I’ll update the docs to better describe this.

[tomasjakubik]

If the extension could be configured to only allow encrypted messages, the attacker probably could not fabricate a valid message. I am not sure about that. The entire BTHome might want a security audit by someone with enough experience.

When you touch up the docs, please also warn that the Door/Window sensors are not to be trusted as well.

[thecode]

You are right that encryption is not giving full protection . The only protection BTHome offers is that broadcasted messages in encrypted mode can’t be read without encryption key. That doesn’t mean that other devices can send data, while pretending to be the first sensor. Unfortunately, I don’t think there is anything we can do about this, as BTHome is a passive BLE format (only broadcasting).

So I wouldn’t make automation that unlock your house.

I’ll update the docs to better describe this.

I agree with what you explained above, I am not sure if this would be the right way, but a mitigation for this can be to decline accepting non-encrypted packets once a key for a device is set, we know that we expect an encrypted payload if the user has provided a key.

First packet - no key, HA is informed that user need to provide a key, user provide a key, HA feed this into BTHome, from this point if the packet is flagged as non-encrypted but a key is provided it will be dropped or trigger a reconfiguration flow in HA allowing the user to remove the key if this was intended by the user.

[Ernst79]

Yes, that sounds like a possible solution. In the meantime, I’ll add a warning, as I’m very busy at work right now. I won’t have time to look into this shortly. If someone else is willing to add this, it would be more than welcome.

Note that this is also the case for other BLE integrations, like Xiaomi-BLE

Edit: Warning has been added to the bthome.io webpage. (encryption section).

[IvoGruber]

I agree with what you explained above, I am not sure if this would be the right way, but a mitigation for this can be to decline accepting non-encrypted packets once a key for a device is set, we know that we expect an encrypted payload if the user has provided a key.

This would be good first step to improve the situation. But a replay attack in general is still possible even with that change. To avoid this, the encryption counter should be used as nounce. The receiver accepts it only once. Since it is not practicable to store all those nounces you can use the counter property (it increases) to ensure that. You only accept advertisements that have a counter value than the last one seen.

I am not an advanced python coder (even not a beginner) but as far as I understand you already try to do that here!? Not sure but I would assume that that code is not reached? Are there unit-tests for this?

One problem is that after restart, the counters on your side are set back to 0?! In beacon mode that problem mabye is solved within 30 seconds (for shelly devices), if the device is close to the house/garage. But that is might not always the case. So maybe it's a good idea to let home assistant or other clients store the counter in some persistent database and after restart hand the stored values over to the library to use those higher values immediately?! Maybe the encryption counter should even be a sensor in home assistant (that could be disabled by default).

Keep in mind that it is still possible (but in the scenario of opening looks not very useful) to attack if the receiver does not get the last advertisement to open the door but the attacker can record it and replay it later. Since the user, that wants to open the door, will likely try again soon, the attacker usually can not use the recorded advertisement. But just in case it is might helpful to enable the beacon mode to reduce the risks further!

Not sure, but if I get it right, the shelly buttons reset the counter to 0 after battery change?! But do they also keep the old encryption key? If so, users should be advised to change the key after battery change. Of course that also holds if the counter overflows, but at least for shellies that should be rare. No button will survive 4 billion presses and even with one beacon per second this will take 136 years. (shellies send out beacon only every 30 seconds as far as I remember).

[sur5r]

With #297 merged it would be great if someone could help implenting the Reconfigure flow for HA.

[IvoGruber]

I would guess this file needs to be adjusted/enhanced.
There is already a Reauthentication flow, that I would have assumed to be the right spot. I guess it is/was triggered if you change the bindkey on the device, but I am not sure.
I tried some weeks ago this: disabled the encryption on the button. Than checked if button presses are still accepted. That was the case (and is of course what this issue is about). Than I activated encryption again. This created a new bindkey on the device. As a result I was asked to enter the (new) bindkey again.
This is somehow okay and wanted, but I would prefer to give the user an additional warning in that dialog, that this could be an attack, and should not happen, unless he (the user) changed the bindkey/encryption actively. We should keep in mind, that an attacker can choose the key here and might take something like "00000..." or something the user might produces by just pressing enter!
I would assume that the reauth flow should also be activated, when the user just disables encryption on the device, and than offer to delete the bindkey only. Not sure if that needs another change in bthome codebase. Of course a warning should be displayed in this case also, but this time it should warn, that this would be an attack, unless encryption was actively disabled on the device. The user should than also have the option to ignore the deletion of the bindkey.
The reconfigure flow might just needs to allow to delete the binkey, since reauth will/should allow to enter a new bindkey anyway afterwards.
My python skills are still very limited (just read first parts of the official docs) and can not promise to find enough time to set up an environment to play with, since time for this is also very limited on my side (even if motivation is high). If I make progress on this I will report.

[Ernst79]

Please note that the PR was merged, but no new release was created, due to an error in the lintcommit message (probably you used a capital letter, which isn’t allowed). I need to figure out how to trigger a release.