69 comments

[ 4.6 ms ] story [ 144 ms ] thread
IoT seems hopeless because

- There are so many different kinds of devices and different hardware

- Vendors want to maximize profits like everyone else, which entails making new devices all the time, and ending support on the last model fairly quickly (typically within two years,) but consumers regularly keep their devices for more than two years.

- Hardware vendors historically were not software vendors. For many IoT makers, this is their first real foray into software. The mistakes being made are amateurish, at a level that we saw on PCs in the mid-90s.

- Although there are some IoT standards, they're mostly concerned with communications, not the operating system. It feels like we're still 5+ years off from something as basic as automatic updates being a given (even just notifying users that an update is available and allowing them to easily install it is a challenge currently.)

Two things that are really bothersome:

- A huge number of IoT devices don't need the 'I'. They are perfectly capable of serving their purpose without an Internet connection (e.g. over Bluetooth,) but a huge attack surface is added to make you able to configure the device via a central website, or simply to monetize usage data.

- It is futile to trust each vendor to have the security expertise to lock down every device. An "IoT operating system" would be highly desirable, but there is nothing anywhere near real world implementation, and given the heterogeneous of hardware components it doesn't seem likely something non-Linux-based will come along.

Brickerbot is hostile and aggressive and shouldn't be necessary, but maybe it is. That's beside the point, though: Nobody has to be given permission to brick insecure IoT devices. Vendors don't feel it where it hurts (the bottom line,) and consumers increasingly just don't care (studies show people have grown accustomed to security incidents -- "it happens to everyone and everything; replace it and move on, there's nothing you can do")

Hacks made Microsoft shape up in the 90s and early 2000s, but Windows has only become actually secure since after Vista. Maybe just don't buy IoT devices for another 5-10 years, or at least put them on a separate vlan.

There are a bunch of groups trying to spread the word, but it doesn't seem many vendors are listening (or if they are, they don't have the capability to really secure their devices.) We've had some success with Securing Smart Cities working with local and state governments, and trying to address some of these issues before hilariously insecure IoT hardware becomes ubiquitous in cities/related to critical infrastructure: http://securingsmartcities.org/

It's hard to see how it's not going to get much, much worse before it gets better.

Linux is very secure. The problem is linux is general purpose and that means it can do a lot of things. You don't need "non-linux" (and it would only help a little) - you need a set of sane defaults which eliminate attack vectors.
Linux (as in distributions, homegrown or not) has "ok" security. But unless vendors go through a lot of steps to both lock it and what runs on it down, and make sure issues are addressed in a timely manner, it's not.

The key will likely be something like Android, that's based on the Linux kernel, but locks the vendors into some notion of a safe environment, and applies updates in a timely manner (the Linux kernel still has frequent critical security fixes.)

(Having vendors be able to articulate what the devices should be able to connect to or do, and having the OS/runtime enforce that would be a huge step forward.)

But Android itself is also insecure primarily due to fragmentation and end-of-lifeing, hence the feeling of hopelessness.

Want to create a startup? Create an SIoT certification and a Linux distrib which provides all services by default and in a compliant manner.
>A huge number of IoT devices don't need the 'I'. They are perfectly capable of serving their purpose without an Internet connection (e.g. over Bluetooth,) but a huge attack surface is added to make you able to configure the device via a central website, or simply to monetize usage data.

I always feel the need to disagree with this.

The biggest "value add" in most of my "connected" stuff is the fact that I can access and manage it from outside the home.

Z-Wave light switches are nice, but being able to turn them off when I forgot to after i've left is a huge bonus (and taking it a step further and tracking my and my families phones and turning them all off when nobody is home automatically).

A thermostat I can control when I'm on the couch is a convenience, but a thermostat that notices when I'm at work or the store or a friends house and turns off during that time saves tons of money and energy.

A garage door that I can control from anywhere in my house is normal, but a garage door that I can have ensure it's closed when i'm not home, and that I can open for a friend that showed up to my house 20 minutes before I did is awesome.

I really do think that the "I" in IoT is absolutely necessary (in many cases, not all), but I agree with the rest of your points.

(before people start commenting on the tracking stuff, it's all implemented on a home-server where the phones literally "phone home" to that server, nothing is processed outside the house)

By all means, if the Internet connection serves a purpose, great. But a sleep monitoring gadget probably doesn't need an Internet connection just to show your sleep score. For all the flak Fitbit has gotten, at least it gets this right (syncs over Bluetooth.)
All of those are great use-cases. But do you really want each of those devices to be added to the external threat surface? Perhaps it would be better to have everything talk to a central hub over a local protocol (ZigBee, Bluetooth, etc) and then that hub be the main connection out to the Internet at large. As it is now, it's still a bit of a free for all. And at least if you have a hub model where you can secure that one device (or replace it if it is compromised), you don't have to replace all of your individual IoT devices when something bad does happen.

A good example of this is my garage door opener. Instead of building a WiFi connection into the opener itself, there is a separate little gateway device that sits inside my house. The gateway talks to the door (RF) and to the Internet (ethernet). I can still control my garage door, but if something is compromised, I can always detach that gateway and still have a working (secure) garage door.

It seems so silly to me to not use the ubiquitous "RF" broadcasting stations already in everyone's house, that also includes an "okay" addressing system, a security firewall, high bandwidth communications protocol, and more.

Why not focus on software which can use WiFi more securely and with a better focus on local connectivity? I can understand the "ultra low power" needs, but many of these devices are mains powered, and that's not really a concern.

But yes, what I do right now for the most part is use z-wave which is connected to a central "hub" which is then connected to the outside world. But IMO that's a hacky-workaround for this problem, not a real solution.

This is a great idea, but it would inevitably fail. All we'd end up with is each and every IoT company coming out with their own "hub" product that only works with it's own devices. Want to control Philips Hue bulbs? You have to have a Philips IoT hub connected to the Internet. Belkin smart plugs? They'll connect only to a Belkin smart hub. Xyz Manufacturer sprinkler system? Xyz hub. Oh, and by the way, those hubs will all have insecure software thrown together by an underpaid E.E. too.
If router security weren't such a mess as well, that'd be the perfect integration point. Better home routers already can provide VPN connections, have apps for mobile devices to set those up, can isolate different devices in the local network ("guest WLAN", "child protection" features), ...

At the same time, a lot of IoT stuff only connects to the outside to be reachable by its apps, and maybe sent notifications. The router could manage these things instead, independent of any device-specific "cloud" service.

I do think a large part of the reason so many devices need "internet" access is because we (as developers) have failed to come up with a good way of accessing these things locally.

So many things in my house have static IP addresses because I want to access them locally, it's an absolute pain in the ass and not at all something that your average person could manage.

Having an IoT device send all of it's data to a "cloud" server is the easiest and most fullproof way to make sure everyone can use see it. Without that, you are looking at complicated local addressing systems, hoping that your users aren't using client isolation or something like it (and you WILL get calls because they tried to use the device on a hotel network where each client is isolated and it didn't work), and ugly URLs at best.

You don't need IoT for any of those use cases. For the first two you just need occupancy detection. You can do that locally with passive infrared sensors. And for letting your friend into your garage you just need a keypad lock. They can phone you and ask for the code. If the lock supports multiple codes you can tell them only the backup code so you can change it and lock them out again later without inconveniencing yourself.
>You don't need IoT for any of those use cases.

This is a shitty response. It's like telling the person who wants a better mousetrap to just live somewhere that doesn't have mice. It might be a "solution" but it's not a good one.

>You can do that locally with passive infrared sensors.

So now you want me to purchase 10+ infrared sensors for throughout my small condo? And what happens when my pets set them off? what happens when I'm laying still on the couch? What happens when I'm taking a shower?

I can just get a keypad? what happens when I want to change my keycode while I'm away for a week? What about the nice notification I get on my phone when someone opens a door or the garage door when I'm not home? What about the snapshot of the security camera I have sent to my phone every time someone enters the house when nobody is home? What about the routine which begins warming/cooling my house when i'm less than 15 minutes from home?

Those aren't solutions, they are shitty workarounds that only work in a fraction of the situations. Just like most other "solutions" that attempt to act like every single thing is 100% possible without outside communication are.

PIR sensors are reasonably cheap and have low power consumption. They could be battery powered and connected to a local low-power wireless network (transmitting only, and at low data rate), which would make installation easy. It wouldn't take much battery capacity to beat the expected lifespan of a IoT device. They're generally good at discriminating between humans and pets, but if a pet did trigger it the worst that would happen is you waste a little electricity or fuel as you give it some light or heat you didn't intend to. You stand to lose much more if somebody hacks your internet connected solution. And if you're laying still enough to avoid triggering a PIR sensor you're probably sleeping and want the light off. And most phones are not waterproof so they cannot be used in the shower, so IoT does no better there.

I think it's unlikely that the IoT door lock features add enough security to make up for the increased attack surface compared to the local only version.

The point is that my phone is with me, so If i'm in the shower, the phone isn't 300 miles away, so if the phone says it's home, it's significantly more reliable than an IR sensor which will say i'm not home because i was out of sight for 15 minutes in the shower (or perhaps sitting on the toilet for that time, during which all the lights in my house turn off, my PC powers down, my doors lock, my thermostat goes into "away" mode, the water heater goes into "vacation mode", etc...)

I've had IR light switches before, not only do they have tons of false positives (I ended up removing it because I would roll over in bed and the lights would turn on at 1AM...), but they have a significant number of false negatives (I can't count the number of times i've had to stand up and wave at the damn thing like a crazy person to get it to turn the light on because it shut it off on me when i was sitting reading).

I also have 2 of them as part of my "home automation" system, and they are mostly useless. You say they are good at telling people from pets, but my 2 small cats set them off about 30-50 times a day, and if I point them up to where they don't go off that often any more, they won't go off for people at that point.

And like I said above, this isn't just "turns some lights on for a few minutes", this is turning the thermostat on/off, turning the water heater on/off, lights, locks, doors, tvs, computers, fans, speakers, etc...

And they STILL don't solve the other issues. What about notifications when someone enters/leaves the house? What about pre-heating/cooling the house when i'm close to home? what about external camera access? what about the alerts about water leakage, or gas usage while i'm not home? or the notification that I left oven on?

Why try to "reduce attack surface" of my door lock, when it's feet away from a window? I personally think a lock which sends a notification when used, or IoT devices which notify when used and nobody is home is magnitudes more "secure" than a dumb lock which will do nothing while all of my stuff is stolen.

Telling me I don't need those things isn't a "solution", it's letting perfect be the enemy of good.

>> An "IoT operating system" would be highly desirable

>> it doesn't seem likely something non-Linux-based will come along

The Mbed seems like ARM's answer to that, and it seems pretty good, works well of the mcu scale, and not that many vulnerabilities. But customers can't reliably choose it when buying, hence companies don't usually use it at scale. Simply put, IOT security is a "market for lemons".

What's needed is an mcu(or maybe a communication module), that comes with connectivity + security + updates from a major player - in a way that the product designers can't hurt security(no matter what mistake they make) - for example, by only offering a secure link to the company secure cloud server.

Than when users buy online, they can see that "this product's security is provided by Amazon/ARM/etc or maybe even a small third-party brand[1], with guaranteed updates for X years, or updates for $Y per year".

And it should be easy to verify that fact - for example, by using an app to scan the box or product label, and communicating with the product.

At this point, if this is done affordably, some users may decide to pay for that security, right ?

[1]It's possible to build good security and security brands online, like copperheadOs, for example.

That, branded with a stamp that goes on the box that merchants will pressure vendors to obtain because the non-stamp ones cause a lot of complaints, could be very positive.
IoT is going to change the world, so it's great to tackle this issue while it's in a premature stage
In a way it is a bit unfair to IoT manufacturers. The problem is that to make something secure today, you need to be a network protocol specialist, a linux specialist, an expert cryptographer, etc. And guess who are IoT designers? Either a low level technician in a big western company or a guy hacking stuff together on the side of a factory floor in China.

To me it is unreasonable to ever expect that all of them will be linux specialists, expert cryptographers, network specialists, etc.

Fundamentally we are at the convergence of software and hardware, but the software is too complicated, give people too many ways to shoot themselves in the foot.

I'd argue we need better software, not IoT manufacturers sinking ressources in hundreds of unrelated expertises.

This is giving too much credit to IoT manufacturers as posing it as too difficult. Truth is, in most cases absolutely nothing is done to keep them secure (quite the opposite).

To drive a car or keep people's Credit Card information you need certain certification. What makes no sense for me is to assume that keeping kids records on a public DB because someone has no clue on what they are doing is reasonable (for example). Or that needing an internet connection for turning off your heater is reasonable.

We need to understand IoT is not a toy, we should require certification, fines or both.

We're reaching a point where it really doesn't matter why a given company isn't capable of making a bulletproof software addition to their hardware. When cars were giant steel death traps, car safety standards improved. You probably couldn't sell most 50's era cars today because of it.

Similarly, I don't think it's unreasonable to hold IoT manufacturers accountable for releasing blatant security vulnerabilities into the wild (like that webcam that DDoS'd all those sites).

This isn't an "aww, growing pains" kinda moment of care for the poor budding IoT industry. They need to realize that they must be held accountable.

Edit: "bulletproof" isn't even what's being asked, but putting some thought into the security of their IoT devices is something we must demand of manufacturers

Honestly, my biggest objection is that there's so much nearly pointless IoT stuff out there.

If a product desperately needs network connectivity, but is still prohibitively expensive to secure, I'm sympathetic. (Not forgiving, mind, but I understand the difficulty.) But when you're releasing a wifi teakettle, or a networked lightswitch that's talking to one other switch 5 feet away? At that point I think there's basically no excuse at all. Teakettles work great as is, adding insecure network support creates a product substantially worse than one without any software at all.

More theoretically, I can imagine an IoT product so good that they should just pay for the externalities they cause and keep manufacturing. But most insecure products out there today are creating far more externality than value, and wouldn't exist if they had to deal with the harm they cause.

Yes. It is completely unreasonable to expect that manufacturers of cheap electronics will implement security solutions on their own for their 20$ home routers, IP cameras etc. Even huge, international companies' failing security doesn't surprise anyone and newly discovered vulnerabilities are common news. Sure, you can ban importing all connected devices that are not certified by some strict security standard, but that would probably rise prices more than users, accustomed to cheap electronics, would want to pay. And how bans on commodity goods work we know pretty well from "war on drugs"..

The only realistic solution I can think of is creation of the open communication and security protocols with easily available standard libraries. A good example is HTTPS, which is far from perfect now, but is common today thanks to TLS and OpenSSL. We need something like Linux kernel - free, widespread, well understood, easy to port and use. Few big companies could make it work, but the problem is that there's not much money in creating open protocols and FOSS libraries. Maybe some IoT orientated Linux kernel branch with minimal set of functionality, safer of out-of-box configuration and basic security solutions preinstalled?

OpenEmbedded/Yocto is one such Linux "distro", https://www.yoctoproject.org/ecosystem/iot

There is also the open-source Zephyr RTOS for IoT, of Intel WindRiver lineage, under Linux Foundation governance, https://www.zephyrproject.org

Edit: See http://mender.io for OTA updates (open-source client and server). If IoT device vendors separate their application code from the base operating system, e.g. via containers or virtualization, it may be possible for a vendor-authorized subscription service (like Mender) to deliver OTA updates for security-critical components.

I have used OpenEmbedded/Yocto, but it pretty much falls under "roll your own solution" category. I know there are many projects and papers written that try to address IoT security, but there's no clear leaders yet. Making hardware projects might span to few years, you can't simply grab something from GitHub, base your project on it and risk it going out of existence in few months.
Ring stored WiFi credentials in plaintext on their video doorbells -- would you say it requires a cryptographer, a network specialist and an embedded device expert to know that was a terrible move for a home security device you can walk up and physically rip off the outside of someone's house?

IoT manufacturers don't have to contract Linus Torvald to review their code, but it's entirely reasonable to expect IoT manufacturers to use existing best practices to secure these products.

I would say, based on my experience that indeed it does require some level of specialization which most don't have today. I'm fighting with an IoT manufacturer right now because they ship the same root private key on every one of their devices. This is a pretty simple concept to understand:

"Are all your device privates derived from the same key? Do you ask your users to install your public root to get past security warnings?"

Yet they clearly don't understand PKI 101 and think what they are doing is completely appropriate because they are "following standards" while of course missing the bigger picture entirely.

Yeah, these are not subtle embedded-systems bugs were talking about. These are frequently things that would make any halfway-experienced programmer or sysadmin refuse a release. If your security failure gets revealed and the entire software industry screams "what were you thinking?!", you don't get to plead that finding the bug was too tricky and complex.

Hell, the Ring issue wouldn't even require one direct employee to avoid. You could solve that in a 30 minute call to an "is this obviously terrible?" hotline.

I don't think this is a fair assessment.

When I got to make a website, I don't say I can't make it secure because I can't afford to be an expert in security at every level of the OSI. I say I'm not an expert in every level of the OSI so I rely on accepted best practices and community standards to make my site secure.

I don't replace HTTPS with my own standard because I can't afford to make an adequate and secure replacement. If IoT makers can't make their own custom solutions secure then they need to build their devices out of standardized pieces that are secure.

"they need to build their devices out of standardized pieces that are secure."

That's exactly the problem with IoT-- there's no standard, out-of-box solutions right now. Try to google for "IoT security": you will find a bunch of (mostly proprietary) competing solutions with no clear leaders among them. See my other comment on this thread, were I've provided HTTPS as an example for IoT ecosystem. I'm an experienced embedded developer and most often, when it comes to security, I still have resort back to "invent my own" security solution, because I can't find anything that fits project needs.

afaict you can't use HTTPS in any reasonable way with IoT. There are no solutions that don't cost $$$$$$$+

note: I know you were not suggesting HTTPS as a solution only as an example of a standard used other places. I'm only pointing it out as another example of an issue IoT has which is lack of solutions .

Why do you need to spend money to use HTTPS with IoT?
how do you get a cert for each device? let's encrypt limits the number of certs per domain (that includes sub domains). so unless you expect users to get their own domains for their IoT devices they can't get a free cert based on user unique subdomains you provide.

The only solution I know of is Plex's solution which was to partner with a CA for $$$$$$

https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

>> when it comes to security, I still have resort back to "invent my own" security solution

What's wrong with using the mbed security stack as a standard for mcu's ?

> In a way it is a bit unfair to IoT manufacturers. The problem is that to make something secure today, you need to be a network protocol specialist, a linux specialist, an expert cryptographer, etc.

Sorry, but this is complete and utter nonsense.

Nobody is asking IoT manufacturers to provide perfect security. It's about the absolute minimum basics. There's one single security mechanism that's totally obvious that would have completely prevented the whole Mirai botnet: Don't use default passwords. It's not too much to ask for that.

This is the same reason why all the software on "Smart TVs" and digital picture frames and net-connected refrigerators and in-car navigation systems all SUCK. They're made by hardware companies, not software companies. I've worked for mostly hardware companies in my career, and most of them just don't grok software. Most hardware companies see software as just some line item on the BOM, equivalent to a bolt or bracket, that just needs to be delivered with the product somehow. Nobody cares if it is secure, or if the UI is fast, or if the fonts look good. They just need to check off that line item somehow so they can ship the product.

Try to find a piece of hardware in your home that was not built by a software company where the software is even close to decent.

> The problem is that to make something secure today, you need to be a network protocol specialist, a linux specialist, an expert cryptographer, etc.

A self-updating debian install with a unique random password you deliver in a piece of paper inside the box should be enough.

If it isn't then there's something very odd with the legal processes, as your team of experts wouldn't be able to deliver it either.

The title IMO is clickbait in the way of "discover how ___"; I'd change it to: "Bricking IoT devices gives incentives for better security".
I think the morality of this issue is extremely interesting. A single insecure IoT device isn't a problem at all, but in huge quantities they become a form of Internet weaponry.

Imagine if white hats were given legal immunity to hack devices that are easy to hack (for some definition of "easy") and, for example, replace the firmware with something that flashes some red text reading "contact manufacturer for replacement", and simultaneously closing the security hole in of which they came in the first place.

This would be a sort of middle ground, giving consumers a minor annoyance rather than a bricked device, but still leveling the playing field between white hats and black hats.

Perhaps adding a $1 bounty per device for the white hats, paid by the device manufacturer. Then the manufacturer would be forced to purchase insurance, who would want to look at the security of the software before giving a offer on the policy.

This insurance concept is and interesting idea, I think.

Unfortunately, insurance is all about risk management. In layman's terms: why bother worrying about security when you can just buy insurance for it. Then they'll pick up the tab for any problems, right?

Insurance can be a powerful force for creating standards. Most of the building codes in existence were created by the insurance industry. The NFPA (National Fire Protection Association) was originally sponsored by a collaboration of insurance underwriters. [1]

Insurers want to make sure that a building meets the code before offering insurance on it. If a building collapses or burns down and it is later shown that it was not built to code, the insurance policy will be void.

I imagine similar incentives would hold for IoT security. The insurance would be contingent on the manufacturer following all available best practices to show that they did all they could to make the device secure.

[1] http://www.nfpa.org/about-nfpa/nfpa-overview/history-of-nfpa

When I worked upon software for the oil industry for the building of oil rigs. The whole aspect of testing and insurance was very much key and Llyods of London have dedicated inspectors who would inspect and sign of parts as and when completed and without them, no insurance could be offered.

So for large scale key area's you will find that insurance/reinsurance companies have more than actuaries giving values to a risk. It is in their interest after all, more so when large sums of money are equally at risk of theirs.

AS for driving standards, yes, it happens. Though in some cases it happens after the horse has bolted.

For example in the UK ALL insurance has a premium added to it to cover people who have high-risk properties subject to flooding and with many houses built upon flood planes in the 80's with low regard to risk of flooding than they should, then it is a sticky plaster solution that fixes a legacy issue that we all end up paying for. That is the concern with IoT and I do fear that a solution that see's everybody paying the premium to cover the issues of the past, will transpire either directly or indirectly.

Insurance companies don't pick up tabs, they spread out risk, and make a profit in the end if they've calculated the right probability of failure. The insured parties, together, are paying the tab, plus the profit for the insurance company. Only by inspecting a device and its software can an insurance company calculate a reasonable estimate of the risk of breach, and thereby reduce the risk of unprofitably to a tolerable level.
The incentive is the premium. That's going to be based on the technical crappiness of a product.

It's not going to be affordable to cheapo-Chinese manufacturers, so they won't bother. Their products will remain cheap and people who don't know (or don't care) will keep buying it.

If you want to make insurance "work" you need a system similar to roads, with every device registered and insured to connect.

Now we have insurance companies deciding what we're allowed to run. I don't like this future.

> Imagine if white hats were given legal immunity to hack devices that are easy to hack (for some definition of "easy") and, for example, replace the firmware with something that flashes some red text reading "contact manufacturer for replacement", and simultaneously closing the security hole in of which they came in the first place.

I think something comparable to this is going to be necessary. There's simply not enough pressure to fix devices otherwise.

With IoT especially, we seem to have an ugly incentive structure where there's no motivation to improve security unless there are lots of high-profile failures (and perhaps attendant lawsuits) that create demand. White hat work is often prohibited and almost always disdained - we've all seen stories of disclosures being completely ignored. So we get bad security not because consumers don't care about flaws but because they never know the weaknesses are there.

I know it's kind of a rhetorical question, but I think the answer is obviously: make it cost them significant amounts of money if they do not.

So, the question then becomes, how do you make it cost them significant amounts of money?

Here's an idea:

There exists an FCC ID for every device that uses the RF spectrum. Similarly, there should be a similar required license for any device/product that operates on the Internet.

The license should be easy to get initially (basic examination by 3rd party). However, once the product is out on the market, if it is shown to be demonstrably broken (insecure), the license is revoked. It now becomes illegal to operate or sell the product as-is (both for user and manufacturer). It now has to be disconnected from the Internet (or the user and manufacturer face a fine).

Devices that are produced in very low quantities will be exempt from this (prototypes, specialty equipment, etc).

This is similar to the mandatory safety checking of a motor vehicle.

A cop pulls you over since your car mirrors are broken? You need to fix them before its legal to drive.

Some one finds out that all models have a fatal life-endangering flaw? It is now both illegal to drive them, and to sell new ones (as-is). Note that in this case, manufacturers will always foot the bill and do a recall.

I get that this is extreme. I don't see how anything else would work, though.

I like this quote I saw here:

> The "S" in "IoT" stands for "Security".

From another IoT comment [0] that I just posted:

• Develop a standard interface/protocol for integrating IoT devices with the major mobile operating systems:

• Upon unboxing an IoT device and first power-on, require physical contact (via NFC?) with user's primary smartphone/wearable, and register the device with the user's third-party cloud account (e.g. Apple's iCloud/HomeKit).

• Only allow control of the IoT device from the smartphones/wearables that are signed into the user's iCloud/Google/Microsoft/etc. account.

• Web interfaces for IoT control should require two-factor authentication on the user's smartphone/wearable, again like the web interfaces for iCloud/Google/Microsoft accounts.

• Expose a different set of controls based on the user's physical distance from the IoT device, and the level of authentication on the controlling phone/wearable. For example: To unlock your front door you'd have to be standing right there (similar to unlocking a MacBook with the Apple Watch) but you could turn the lights on/off from across the world if you've unlocked your phone and entered your iCloud/Google/Microsoft password – and only from that phone.

• Sharing control with spouses/family could be similar to how Family Sharing for the App Store currently works; set a level of access on each IoT device for each member, and fallback on asking the family "admins" for permission.

No doubt there must be some non-apparent holes in this, but just throwing an idea out there.

[0] https://news.ycombinator.com/item?id=14077965

" Upon unboxing an IoT device and first power-on, require physical contact (via NFC?) with user's primary smartphone/wearable, and register the device with the user's third-party cloud account (i.e. Apple's iCloud/HomeKit)."

Sorry, you lost me here. The last thing we need right now is another database of users' personal information. Why every gadget should be attached to my personal phone?

"Only allow control of the IoT device from the smartphones/wearables that are signed into the user's iCloud/Google/Microsoft/etc. account."

No again. It's enough Google owns my phone and email, I don't want it to own my home. What happens when Google's algorithm decides to ban you for no apparent reason (there are plenty of such horror stories around)?

Tl;DR if that's the price to pay for IoT security, I'm resorting back to "dumb" devices or going to live in woods.

That is sort of similar to how Apple's Continuity/Handoff/etc. currently works though, isn't it?

Your iDevices, once registered on the same iCloud account, just talk to themselves, without needing to tell or ask Apple anything, other than just checking that you've signed into the same iCloud account.

I don't use Apple products, so can't comment on how that works, but Apple is a rare company that owns it all: hardware, software, support, so the hardest part of any solution -- agreement of different parties -- disappears.
I like some of these ideas, mainly because they aren't "absolutist".

One of the major problems I've seen again and again (especially on this site) is people saying things like "these devices should be 100% local". That's not realistic.

It seems like many attempts to improve the situation are met with hostility that they aren't "perfect" and the people trying to help lose interest because they are being fought on all sides.

The healthy technology market will force IoT manufacturers to take security seriously. It is not the job of a government to punish a corporation for failing to implement what should now be basic tenets of product quality and suitability.

The loss of customers and reputation should a major security concern arise is a serious market driver and calls for regulation will only ensure that nobody does anything until a multitude of governments agree on a standard. As further food for thought, do you honestly trust the government to make the best choices for your security as a private citizen?

I don't buy that argument.

If "customers and reputation" were sufficient, we wouldn't need regulations on the safety of e.g. medical stuff, food and cars. (And history, as well as comparison with other countries, confirms that we do need those.)

Whenever one needs to establish a minimum of quality (and this is what that's ultimatively about), establishing laws mostly works, while trusting the market mostly fails.

Markets are good at many things, but are really bad at establishing a minimum of quality (or provision with basic supplies, for that matter).

> The loss of customers and reputation should a major security concern arise

The potentially nice thing about regulation is that you can have some level of trust in a compliant manufacturer. In your example, customers don't know anything about the security of their chosen vendor until a breach happens.. At which point, presumably they leave that manufacturer (and they fix their shit or die), and go to a new manufacturer who hasn't had a breach yet, or has used PR expertise to hide their mishaps, or... maybe they are actually secure. But who knows? Customers don't have the details they need to do anything but hop about randomly between manufacturers.

> The healthy technology market will force IoT manufacturers to take security seriously.

What? It might force companies not to bleed user data, yeah - people got pretty upset about the dolls spying on their children. But "enabling a DDoS" is a textbook externality. It doesn't hurt the device buyers appreciably, most of them don't even know it's happening, but it causes lots of harm to someone who didn't contract with the company.

More broadly: do you see any evidence at all that the market is actually solving this? It's pleasant to say an efficient market would handle this, but the market we actually have is one where people sell broken products to customers who pay before the flaws are revealed, then move on to a new company name if their reputation gets bad enough. Add in overseas production so that you can't even sue if the seller violates a contract, and the real-world market isn't making any progress on this.

Would it be worth an effort if there was an open source protocol of secure communication of IOT devices?

For example, many solutions use MQTT, why not make a secure TCP/UDP one by implementing one of the higher layers in OSI stack?

By aggressively exploiting insecure devices and maximizing damages to the end customer.

Either IoT market will die because of this or the IoT will become IoST - internet of secure things.

For what I see, this is a problem for the consumer market on one side and for the small manufacturers on the other. Big industrial players like General Electric, Bosch, Phillips, etc. are deep in this already with their QA protocols and their own software platforms, think of Predix.io. Nothing more than another line or an extension of home / office / factory appliances for them.
Liability. Liability, liability, liability.
For consumer devices the solution could be the consumer protection legislation. For example in EU the manufacturers/sellers are responsible for the devices after the sale. The exact time is not defined, but I believe for average consumer electronics 2 years is kind of minimum. During that period the manufacturer is responsible for defects in the products. The responsibility means they need to fix them, provide new (working) gadget or provide financial compensation.

If we would defined that device with a known security vulnerability is broken, the manufacturers/resellers would need to take action. Suddenly there would be direct financial consequences for shipping broken devices for which updates don't exist. I'm sure this would quite quickly lead to manufacturers putting more effort on providing updates and maybe even to proactively preventing security issues.

Bricking devices is unlikely to help; the manufacturer already got his money. Indeed, economics are the fundamental problem - the manufacturer has zero incentives to do anything correctly.

Laws can't solve all problems, but I think they could help.

See "What laws should be created to improve computer security?" - https://www.dwheeler.com/essays/law-security.html - because I think some could help.