"It's funny how crap third-party programmers never feature in threat models."
Really, this is how the world will end.
Arm hopes to release open-source code early next year that will help secure Internet-of-Things devices – by encrypting their communications and installing over-the-air security fixes. The firmware will be a reference implementation of what processor core designer Arm calls its Platform Security Architecture, details of which …
On the principle, this is a good idea as ARM has probably serious folks in this area, and surely, none can be as awful in security as the best one from IoT vendors.
But this alone won't solve the problem: "make it idiot proof and the Universe will create a better idiot".
Regulation will probably be the final blow to those security blunders.
Regulation will deliver the Glorious World of Next Tuesday.
The IoT equivalent of the VW engineer who coded the EPA test beating code, will be all over the regulation mandated code.
That's what humans do.
Someone erects a barrier and there will be an enormous mass of others looking for ways to defeat that barrier.
Self driving vehicles? Meet the Hot Rodders of the 21st Century.
There will be races for self driven vehicles. There will be contests to crown the fastest hack of a self driver. Autocross events with rapid self configuring obstacles.
Events to see which possible target out many the vehicle chooses to hit to avoid the others. The pregnant lady with a pram or the OAP? Add a wheelchair to any possibe victim. A barrister with a case of briefs? A TB patient in an Iron Lung. The Queen (the Monarch from Saxe-Coburg and Gotha).
How many targets does it take overwhelm the self driver and it chooses to stop dead on the roadway. It will have that choice, no?
Ooh, roundabouts. Many multiple lane roundabouts.
Now I want to purchase a self driver.
I think ARM is going to be challenged to license v8-M cores; there just isn't a compelling advantage over the existing v7-M offerings. The described procedures sound reasonable, but they could also be implemented on v7-M (or earlier kit). Tying it to v8-M makes it look like it has been hamstrung by the corporate office's sales aspirations.
web-facing fridges and freezers
If present trends continue, by 2035 house prices will be so expensive that most people can't afford the space for fixed appliances. Instead they'll order food just-in-time from the nearest freezer-point / auto-kitchen, delivered by solar-drone to their home-pod, using a meal-scheduler app that runs in the cloud and reports how much CO2 they've produced to the global enviro-tracking centre.
I can't see how the kit makers in China could be arsed with this
If I understand it correctly; This is a reference design. You know the thing everyone cuts-n-pastes before bolting on their own flavour of IOT waffle.
1. Down load ref design + firmware
2. Bolt on some bullshit
I'm a real-time/embedded developer who was brought on-board to tackle late-breaking cybersec issues on a new military system that was due to be delivered ASAP.
We weren't allowed trust our external routers and firewalls, so we had to configure local firewalls. No problem. We created fully stateful firewalls that understood our M2M protocols. Again, no big problem. We fuzzed our firewalls for months of machine time. No problems. We thought we had things locked down.
Then I learned the local firewall couldn't share ANYTHING with the local application. Which, as it turns out, was what pushed for the external firewall boxes in the first place. Houston, we have a problem!
We had a low-power multi-core x86 CPU, so we added a thin hypervisor, partitioned the memory and hardware, put the firewall and app on separate cores, and begged permission to ship what we had. Permission was granted, but only after many tedious hours of phone conferences with the Powers that Be.
Turned out to be an elegant and powerful solution. One I think should be generalized to all IoT, in that the application must not be permitted any direct network access and must run in a VM. A second VM should contain the firewall and the network hardware. The hypervisor should be a dumb as possible.
So, when will ARM ship M-family processors with VM hardware & instruction support? Is TrustZone fully equivalent?
"So, when will ARM ship M-family processors with VM hardware & instruction support? Is TrustZone fully equivalent?"
VM, crypto modules, hardware for secure boot etc. means more core bloat in the design which eats into the low-cost low-power part of the ARM sales advantage against other CPUs which already have these options but cost more and consume more power. You had most if not all of those facilities on the x86 CPU platform you were working on, if ARM want to match that capability for security purposes they're going to have to go head-to-head with existing products in terms of cost and power consumption.
We don't need locked down bootloaders as an attacker won't worry about staying persistent on the device. However users may want their own, more secure firmware on the device.
The problem we're currently facing are idiocity (using the userspace from your BSP) as well as incredibly complex protocols (TR-069).
Sounds a bit like trying to secure a prison cell by bolting a high-security chrome-vanadium lock to the wooden prison bars. There seems to be miles of leeway to fuck it all up in the "main application" - even with best practices (yeah right), no device will ever get supported indefinitely (by which I mean past five minutes - hey, look! Squirrel!)...
If ARM, or the device manufacturer, are the only people who have the signing keys for the firmware for the IoT device you have in your home, or office, or factory, then you, as the end purchaser, have no control over what software gets loaded and run. This is has precisely the same privacy, security and control issues as the Intel Management Engine (ME) or AMD's Platform Security Processor (PSP).
Most people are not bothered about the firmware running in their toasters, fridges, thermostats, audio assistants, 'smart' TVs, printers, video conferencing equipment or mobile phones; and you can argue it is a good thing that they can just use the items without having to bother about firmware updates. On the other hand, some people are only to aware of what can happen when you allow third parties to fiddle about with software running on machines in your premises.
We could do with some good ideas on how to give the average Joe/Josephine User control over the devices they are buying in abundance.
Well there's your problem right there. Just because something has a mains plug attached doesn't imply that it needs to have an Ethernet cable also. A fridge or freezer has one simple job - keep stuff cold. Adding "features" just bumps up the price and gets in the way of the simple job.
Applicable to many things. You'd think a TV would have one simple job (accept video input, show it on the screen) but no, the Smart TV can do loads of stuff for about as long as the manufacturer is interested (which is roughly up until you have made the purchase). Thanks, but if I want YouTube on my TV I'll buy a plug in gizmo so I can choose what and how and "update" it with a more recent one of I want.
...how a nice "safe" boot loader thingy will fix the problem of hardcoded credentials? How about running an insecure telnet daemon with a cracked root password? How about a programming flaw where a faulty http request can bypass the entire authentication mechanism? Note that said mechanism amounts to GET /something?user=USERNAME&pass=PASSWORD sent as clear text... Oh, and this update mechanism touted here is only going to be worth a damn it the device maker bothers to make an update. Years of empirical evidence and MILLIONS of devices that never saw one single update whatsoever are all you need to know.
Nothing will change.
Maybe we, the consumers, would be better starting a movement to reject devices that are not open source? Okay, open source does not equal safe, however it does mean that somebody somewhere can do something about the issue when it becomes clear that the manufacturer can't be bothered...
We don't need extra layers of encryption, we need the damn source.
Biting the hand that feeds IT © 1998–2022