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 3 hours ago | parent [-]

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 2 hours ago | parent | next [-]

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.

▲

dylan604 2 hours ago | parent | prev [-]

>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

	▲	ivlad 2 hours ago \| parent [-]
		09 F9 !!