The "anti-patterns" that turned the IoT into the Internet of Shit


#1

Originally published at: http://boingboing.net/2017/05/03/bad-design-thinking.html


#2

Yea but come​ on, that’s hardly a typical example. The Brave Little Toaster was in the middle of a nightmare dream sequence!


#3

I’d certainly be very hard pressed(and at least as unmotivated) to argue that ‘IoT’ isn’t farcically bad; but I would have liked to see slightly more nuance in one area:

Unencrypted Bootloader
Far from being in a datacenter, IoT devices can be left in insecure environments - as such extra precautions need to be taken to protect the memory on such a device.
Take the example of an IoT traffic counting device, installed in a locked cabinet at a roadside. A malicious adversary can break into the cabinet and steal the device with physical force. With the device in their possession they can extract software from the embedded system chip on the device to obtain the software running on it. By reverse engineering this software they can learn secrets in the memory of the onboard microcontroller.
When IoT devices can contain sensitive data in memory, locking them away may not always be sufficient. One solution to this problem is to encrypt the bootloaders on such devices - this provides a degree of cryptographic assurance that the secrets on the device will remain secret.

It is true that an unencrypted bootloader makes it much easier to run whatever software you want on something(and that a competently implemented crypto bootloader is one of the most stubborn foundations of a device that will never break free of its mothership, no matter what its owner might have to say on the matter); but, aside from this being a deeply mixed blessing in terms of vendor motives; it lulls people into a specific class of dangerous assumptions: especially note “this provides a degree of cryptographic assurance that the secrets on the device will remain secret”: there are, certainly, some IoT ‘secrets’ that you want to keep secret; and can only do so by making the device tamper resistant(most notably sensor and configuration data gathered by the device or provided by the user); but there are other ‘secrets’ that are much more dangerous than they ought to be precisely because the designer depended on secrecy, rather than good practice.

I’m reminded of the story of some IoT lightbulbs that were set up to use AES to protect their RF traffic; but every single unit produced shipped with identical keys. The physical design of the bulbs made it rather inconvenient for researchers to get access, no handy serial headers here; but they only had to tear down one in order to obtain the keying material used on every last unit in service. Either the vendor was clueless, or they assumed that the tamper-resistance was enough to let them get away with the most pathological keying scheme they could possibly have chosen.

There is certainly a place for tamper-resistant hardware; but unless implemented with far more care than is usual, even the owner is generally treated as ‘tampering’; and the “Oh, that’s encrypted!” presents a nasty temptation to ignore bad practices that will become disastrous if even a single unit is subjected to a proper teardown; or a situation where the bootloader is locked down tight; but the networked OS it boots is riddled with holes; and all the fancy crypto just ensures that only a signed and blessed grievously buggy image can be booted and promptly exploited, which isn’t much of an improvement.


#4

To use IoT or not? It can be boiled down to the choice between making my own toast and calling the fire department.


#5

Yup, they are right. Developers don’t consider security in their development. Look, most developers don’t even consider basic stuff like SQL injections. So, all the more so, who thinks about preventing their clock app from being used as part of a DDoS attack.

Until security becomes priority, this stuff will still happen. Now, how will security become a priority – if I knew that I would be rich.


#6

My biggest issue with IoT are not some technical nuances, but the underlying problem: household appliances last for ages. Many people don’t replace a toaster or a fridge for decades. Who would seriously expect tech companies to keep the firmware updated for that long?


#7

Call me old-fashioned, but my coffee maker has nothing to say to the internet at large, and vice versa.


#8

I do believe that one of the earliest connected devices was a coffee maker.

Otherwise, as @Konservenknilch stated, its been obvious since the first attempts at IoT fridges 15 or more years ago that this was a bad idea from the get go.


#9

I agree. I honestly didn’t want my light-bulbs, toasters, coffee makers, water boilers, fridges and what-not to be networked before I heard of all these IoT problems, and I sure as hell don’t want them to be now.


#10

This topic was automatically closed after 5 days. New replies are no longer allowed.