Bit of a long one, sorry. We run about 50 street-cabinet energy loggers for a council, each behind a small LTE router with an ordinary operator SIM, all reporting into one Hermetry org. Last month the council brought in a pen tester for an unrelated review and he decided to have a go at us too. He set up one of those fake base stations in a van, forced a test cabinet down to 2G and showed he could see traffic leaving it.
Now I’ve got an email from IT asking me to “confirm the IoT traffic is secure end to end” by Friday.
What I know about our setup:
- 38 of the loggers are newer units, they speak MQTT over TLS on 8883, no problem.
- 12 are older loggers with SIM800 modems that can’t do TLS (or can, but not with a modern cipher suite). For those someone ticked plain MQTT on their profile two years ago and they publish on 1883.
- All of them are in the same device profile at the moment.
What the tester saw was from one of the old ones. He showed me a capture with CONNECT and what looked like our access token in the username field. That bit made my stomach drop.
So two questions really. Is the cellular radio encryption doing anything for us here? And what’s the sensible way to deal with the 12 old units without a truck roll to each cabinet this month?
Wouldn’t the SIM provider’s encryption cover that? I thought mobile networks encrypt everything over the air anyway.
Only between the phone and the tower, and 2G’s version of it is weak, which is why the van trick works. After the operator’s core it’s plain internet. Treat the radio as untrusted.
Thanks Laura, that’s roughly what I feared. The SIM800 units are on firmware we can update remotely in theory, but the vendor stopped answering emails in 2024.
Did our final-year project on almost exactly this (smart meters over 2G, we sniffed our own). Everything Laura said. Here’s what I’d do in your position, in this order.
First, split the profile. Make a new profile for the 38 TLS units and leave it on the default, TLS only on 8883. Move them over. That profile’s devices can’t log in on 1883 at all, so even if somebody pokes at them nothing goes in clear.
Second, the 12 old ones get their own profile with plain MQTT allowed, and you lock it down hard:
- Allowed networks: put in only the address range your operator’s traffic comes from. Ask the operator for a private APN if you can, then it’s their private range. Anything outside gets refused (CONNACK 5).
- Commands allowed without TLS: leave it empty, or at most
sys.info. Neversys.reboot. Other commands just wait for a TLS session, which these units will never have, so they expire. - Allowed authentication: only access token if that’s all they use.
Third, rotate the token of the cabinet the tester captured, and honestly all 12, because they’ve been crossing the internet in clear for two years.
Firmware updates and device settings are never sent in clear anyway, so you’re not leaking those. Everything above is on this page: Device transport security. For IT, the honest answer is “38 are encrypted end to end, 12 are not and are fenced in until they’re replaced”.
Did the split yesterday and it went fine. The operator could give us a private APN for the old 12, took one call and a form. Allowed networks is now their /24 and nothing else. Rotated the 12 tokens and pushed the new ones through the vendor’s SMS config channel, two cabinets didn’t take it so I’ll have to visit those anyway.
IT accepted the “fenced in until replaced” line, with a replacement date. The tester re-ran his van thing on a TLS unit and got nothing readable.
We got the same audit question at our plant last year. The allowed networks list was the thing that got the auditors off our backs, worth doing even on the TLS profile.
- You must be logged in to reply to this topic.
Join the conversation
Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.