Hacker News Reader

Comment by alerighi | Hacker News Reader

> Remote update mechanisms can themselves present security problems in some domains.

Not really if done right to be fair. It's just a matter of implementing a signature verification of the firmware updates that are installed on the device.

> IoT is making its way into defense and enterprise environments where reliability is a matter of national security.

If it's a matter of national security surely you don't use IoT devices connected to the public internet. At least the devices are in some private network, where the traffic is under your control. So if you don't do security updates it may be acceptable under that circumstances.

View on HN

> If it's a matter of national security surely you don't use IoT devices connected to the public internet.

Of course they do. That's the flip side of PaaS and reverse-NIH syndrome, the "opex > capex" thinking: "Industry 4.0" is built on web tech, with all the practices and assumptions baked in. Your critical infrastructure is, or is about to, be running JavaScript on a docker-compose cluster, and expecting to be piecemal-updated daily.

And then, there's also "shadow IT" - going behind the back of IT and using COTS SaaS to work around red tape is still... going around IT and giving untracked third-party vendors access to organizational information and operations. "Making its way" doesn't only mean "introduced by design" - those vulnerabilities just creep in.

I would love to see frank discussion on the record of consumer-grade vs infrastructure-grade practices and what label(s) would be appropriate for each! It’s not lost on me either that the roots of much high-ticket critical infrastructure is about to rest on web tech and highly evolved descendants of 8-bit micros.

> It's just a matter of implementing a signature verification

correctly

With rollback protection, a chain of signing keys to allow revocation, time stamping, correct parsing, enough scratch space to hold an entire separate image in A/B, enough processing power to verify image signatures, etc etc.

Doing this well is very hard. Given most IoT vendors don’t yet know how to prevent XSS, there’s near zero chance they’ll get updates correct in the next decade without solid open source frameworks to leverage.

Also with right to repair, you need to be able to disable signiture checks and upload custom firmware

Yeah true, that’s a fascinating challenge that I haven’t seen particularly well discussed anywhere in detail.

It needs to be really well protected so that the owner, and only the owner can disable the chain of security, but that they can do it without unreasonable overhead and without actually involving the manufacturer (in my opinion. To handle examples like manufacturer trying to lock-in or charge fees or simply going out of business)

Perhaps the owner mints a public key pair, and the device only unlocks with proof of the private key. But in a way in which is easy for your every day person.

> It's just a matter of implementing a signature verification of the firmware updates that are installed on the device.

In principle: yes. In practice: signing keys seem to get leaked all the time.

It's not a mechanism I would blindly trust in security sensitive domains.

We could start by asking iot companies to be ISO 27002, stop saving passwords in excel files or in s3 bucket publicly accessible could help

Security is not an update, security is a cultural trait of an entity or an individual

Remote update mechanisms will be used to deliberately brick or downgrade the device (usually for petty commercial reasons), by unintended parties (e.g. Chinese spies with leverage over Chinese manufacturers), at the wrong time (e.g. one hour of outage when the smart oven should be cooking dinner), and so on.

Signature verification without human users controlling the updates means protecting an attack vector.

Reply on news.ycombinator.com