Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm no security expert, and maybe one can explain this to me, but why can't we just inspect the data before it is encrypted? Like isn't it gathered in some way, encrypted, then sent? And on the receiving end it has to decrypt, so we look at that (naively what files change). Unless this is all stored as encrypted I don't see why you can't do this. I mean this should prevent mitm attacks but also let those controlling devices inspect packets. Right? Or am I missing something (if so I'm legitimately interested. Lots of this stuff just seems like black box to me, and I'm sure others)


Sure - just get a root shell prompt on your thermostat and I'd be happy to walk you through the rest.


It is encrypted on the device. How are you going to get access to it?


My confusion is that I think there has to be a command that is encryptThisDataToBeSent(data). Can't you just look at data? Before it is encrypted? Or is data encrypted at all times? But if that's true, then the difference of sending encrypted data is kinda moot.


If you can root the device and replace the firmware, sure. Or do extremely difficult hardmodding to tap the data buses, perhaps.

But both of those approaches are very difficult and resource-intensive. The first requires many, many hours of reverse engineering to find a security hole which allows you to write unsigned firmware to the device (or find a way to sign your own firmware and then upload it), then hack the firmware to do your snooping (good luck if the firmware updates are encrypted!).

The second is so fiddly and awkward, I've never heard of anyone actually doing it.


Okay I guess that makes sense. If I'm understanding you could get that information but you don't have access to the memory addresses unless you crack the firmware? Though in the case of Mozilla, wouldn't that be open so this wouldn't be that big of an issue?


> you could get that information but you don't have access to the memory addresses unless you crack the firmware.

Correct, from the moment the IoT device puts a packet on the line, it is encrypted end to end. This is a fundamental aspect of TLS to prevent snooping. To view unencrypted data, you have to access it prior to being sent out on the network which requires you to gain root privileges on the IoT device.


That makes sense. Thanks for the explanation!


The threat comes from closed-source devices.

If these closed-source devices send un-encrypted data, you can MiTM these devices when they're on your network. But if they're encrypted, you're SOL.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: