So if I understand correctly, they used hard coded constants to generate keys that only have 44 bits of entropy, which is brute forcible for $10, but you have to do it per device. They presumably did this to make pairing the bridge and sensor easier while not using a static key for all devices. Not the worst compromise I guess.
I've been working on an open source solution on and off for a number of years called http://y-drip.com. It uses Wi-Fi so battery life is only a few months and range is limited. My next design is probably going to use LoRa, but this complicates things a lot because now I have two devices (bridge and sensor) that need to be paired, support over-the-air updates, etc.
What's the best way to have them share keys without adding expensive hardware like Bluetooth or NFC. The sensor also needs to be waterproof so there's no exposed ports. Increasing from 44 bits to 128 would help, but if the key generation is done over the air it can be sniffed right?
I think most ZigBee and Thread chips use 2.4 GHz which limits distance. A lot of water meters are underground on the front yard somewhere so sub gigahertz radio would penetrate better. The modulation scheme of LoRa also allows for greater distance at the cost of data rate. It's also super low power.
> I reached out to Flume. They were very responsive, and their CTO shared an overview of their already-in-progress plans to further improve the product’s privacy and security.
Read: There will be a firmware update that further "secures" the device from owners who would like to use it without the "cloud" and the "app".
i feel like it doesnt matter how secure the rf transport is, if ultimately ur data gets uploaded to a corporate cloud, and the only way to access it is through some shady cloud app
its a nice experiment, but i wouldnt say the security is good...
good security would havr everything documented with sourcecode,user generated keys, and a opensource server/client, whose code can be examined fully
Interesting timing, I have spent the last week with Claude reverse engineering the on-air protocol and I'm getting pretty close to building a secondary "listener" receiver that will collect measurements from my bridge + sensor pair locally.
To Flume's credit, it required me to dump the firmware from the bridge device's ESP8266 in order to extract my key. I didn't consider an approach like this article took, given I have direct access to the HW and there's no flash protection on the 8266.
If you document this somewhere I'd love to read about it! I took the approach of sniffing the packets between the radio and mcu on the bridge board, got most of the way into reverse engineering that, then helped build this instead:
I am planning a write up once I get it working. I'd be happy to share.
My setup is a logic analyzer tap on the SPI bus between 8266 and the RFM69 on the bridge device to log raw traffic, and my secondary RX (ESP32 + RFM69) for over-the-air traffic.
Also, I have a gas meter sensor based on your work half-built on my workbench. I plan to set that up once I finish my Flume distraction. Great work, thank you!
No need — I simply plugged into the exposed programming header on the gateway.
The sensor has an Atmel SAMD part which I assume has the security bit set. I didn't need to dump that firmware directly as it exists within the gateway flash.
Flume seems like a great company and product. They have always been really responsive when I contacted them.
My meter gets submerged in water from time to time, so I was sure to seal it with silicon grease and tape.
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.
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.
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.
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.
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.
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.
So if I understand correctly, they used hard coded constants to generate keys that only have 44 bits of entropy, which is brute forcible for $10, but you have to do it per device. They presumably did this to make pairing the bridge and sensor easier while not using a static key for all devices. Not the worst compromise I guess.
I've been working on an open source solution on and off for a number of years called http://y-drip.com. It uses Wi-Fi so battery life is only a few months and range is limited. My next design is probably going to use LoRa, but this complicates things a lot because now I have two devices (bridge and sensor) that need to be paired, support over-the-air updates, etc.
What's the best way to have them share keys without adding expensive hardware like Bluetooth or NFC. The sensor also needs to be waterproof so there's no exposed ports. Increasing from 44 bits to 128 would help, but if the key generation is done over the air it can be sniffed right?
Why not LoraWAN - has built in encryption (via preshared keys) and receiver stations + processing software already exists (Chirpstack).
That would simplify things. How do nodes usually identify themselves to be able to join the network? Maybe a QR code?
> is probably going to use LoRa
why not Zigbee or Thread?
I think most ZigBee and Thread chips use 2.4 GHz which limits distance. A lot of water meters are underground on the front yard somewhere so sub gigahertz radio would penetrate better. The modulation scheme of LoRa also allows for greater distance at the cost of data rate. It's also super low power.
Thanks, makes sense.
Interference. It is underground and surrounded by dirt and concrete which sucks for 2.4 ghz absorption. And like three other people said: distance.
Distance.
> I reached out to Flume. They were very responsive, and their CTO shared an overview of their already-in-progress plans to further improve the product’s privacy and security.
Read: There will be a firmware update that further "secures" the device from owners who would like to use it without the "cloud" and the "app".
We need a law that makes such iot devices local capable, or maybe a rs485/rs233 like interface like in solar panels
It didn't really factor into the break here but, it's amazing people still use ECB even though the famous penguin image is well over a decade old now.
It is so easy to use CTR mode. But don’t forgot you need to control the plaintext to break ECB.
i feel like it doesnt matter how secure the rf transport is, if ultimately ur data gets uploaded to a corporate cloud, and the only way to access it is through some shady cloud app
its a nice experiment, but i wouldnt say the security is good... good security would havr everything documented with sourcecode,user generated keys, and a opensource server/client, whose code can be examined fully
Interesting timing, I have spent the last week with Claude reverse engineering the on-air protocol and I'm getting pretty close to building a secondary "listener" receiver that will collect measurements from my bridge + sensor pair locally.
To Flume's credit, it required me to dump the firmware from the bridge device's ESP8266 in order to extract my key. I didn't consider an approach like this article took, given I have direct access to the HW and there's no flash protection on the 8266.
If you document this somewhere I'd love to read about it! I took the approach of sniffing the packets between the radio and mcu on the bridge board, got most of the way into reverse engineering that, then helped build this instead:
https://github.com/tronikos/esphome-magnetometer-water-gas-m...
But I always wanted to finish pulling flume data to home assistant, without the cloud.
I am planning a write up once I get it working. I'd be happy to share.
My setup is a logic analyzer tap on the SPI bus between 8266 and the RFM69 on the bridge device to log raw traffic, and my secondary RX (ESP32 + RFM69) for over-the-air traffic.
Also, I have a gas meter sensor based on your work half-built on my workbench. I plan to set that up once I finish my Flume distraction. Great work, thank you!
> My setup is a logic analyzer tap on the SPI bus between 8266 and the RFM69 on the bridge device
I'd done exactly the same, though my efforts were pre-Claude. If you want my logs/data, username at gmail.
How did you get the epoxy off the ESP? I use a mill but I only have a 30% success rate.
No need — I simply plugged into the exposed programming header on the gateway.
The sensor has an Atmel SAMD part which I assume has the security bit set. I didn't need to dump that firmware directly as it exists within the gateway flash.
The gateway had an open debug port?!?!
Flume seems like a great company and product. They have always been really responsive when I contacted them. My meter gets submerged in water from time to time, so I was sure to seal it with silicon grease and tape.
As usual, the weak point is key generation and management.
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.
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.
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.
Lack of the authentication means an adversary can feed any data to the receiver.
Local data access is a win, I agree
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.
>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
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.
09 F9 !!
[dead]
> 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.