[Oliveaniss]

One thing I appreciate about this kind of research is that it doesn't assume every wireless protocol must end with a catastrophic vulnerability.

A result of "the security is actually pretty good" is arguably just as valuable as finding a critical flaw. It helps distinguish between systems that are merely proprietary and those that were designed with a reasonable threat model in mind.

I'd be interested to know where the remaining weaknesses lie. Are they primarily in the RF protocol itself, key management, device provisioning, or the surrounding cloud infrastructure? In many IoT systems, the radio protocol ends up being the strongest component while the weakest link is somewhere else entirely.

[ivlad]

44 bits of security is not “pretty good”. The post author used Python, but anything more performant would result almost real-time decryption.

There are no performance implications of using a proper 128 key because they are doing AES anyway. If they were resource constrained and choose a variant of TEA encryption due to constraints, it would be understandable, but no, the encryption is implemented in hardware.

There also seems there is no message authentication, a rookie mistake.

[nvme0n1p1]

44 bits is horrible obviously, but maybe it's fine for this use case?

The attack vector is: an adversary can get close to your water meter and after brute forcing the key, wirelessly read the numbers they could have just physically looked at the water meter to read anyway.

Meanwhile the device owner can decrypt the signal and locally get access to their own data without being tied to the cloud or a proprietary vendor app. I think that's a win.

[ivlad]

Lack of the authentication means an adversary can feed any data to the receiver.

Local data access is a win, I agree

[ssl-3]

Last I tried in my small city in Ohio, it seemed like all of the natural gas meters as well as all of municipal water meters were broadcasting their readings and messages in-the-clear for anyone within RF earshot to decode as long as they had an inexpensive SDR dongle and a copy of (IIRC) rtl_433.

It was summertime and the gas meters were boring, but the water meters were pretty chatty.

44 bits is a lot more than 0.

[ivlad]

If someone eats junk food at McDonald’s it does not mean I should eat junk food at Burger King. If someone does not encrypt their radio comms, it does not mean I should be satisfied with breakable encryption.

[dylan604]

>44 bits of security is not “pretty good”.

Hey, that's 4 bits stronger encryption than DVDs, and it's only like 30 years later to get those additional 4 bits

[ErroneousBosh]

I have encountered a particular radio bridge type device that by default uses the CSS key as its encryption key to hide its messages from the inquisitive user with an RTLSDR.

I feel like there was some sort of Heated Discussion over whether or not the OTA traffic should be encrypted to enhance shareholder value or not, and someone took the chaotic good route.

[ivlad]

09 F9 !!

[badatnames]

> the security is actually pretty good

I had a slightly different read.. their CTO replied directly and in an affirmative manner. It's amazing how the human touch helps align and build understanding. How many of these have you read where it's just a scathing product teardown devoid of any appreciation for any work that's otherwise been put in.