On Tue, Oct 14, 2014 at 5:20 PM, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com
wrote:
On Tue, Oct 14, 2014 at 4:53 PM, Jim Gettys <jg(_at_)freedesktop(_dot_)org>
wrote:
On Tue, Oct 14, 2014 at 4:44 PM, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)com> wrote:
On Tue, Oct 14, 2014 at 3:57 PM, Jim Gettys
<jg(_at_)freedesktop(_dot_)org> wrote:
There is a serious issue lurking here: it is *not* safe for devices to
be
without software updates. And it isn't safe to presume the upstream
manufacturer is being diligent in providing those updates. And
nagging
end
users to do something that they don't understand is also not a
solution.
I think we need to divide divide devices into 'simple enough to not
need updates' and 'make use of a standard update process'.
There are few network connected devices "simple enough to not need
updates",
IMHO. Distinguishing those that do from those that don't is just about
impossible.
Courtesy of Moore's law, even "simple" devices are often/usually based on
millions of lines of code.
There are IP network devices and serial bus devices. I would like a
mechanism that would allow us to bring serial bus devices into the
Internet of things architecture without putting IP on them.
Hmmm... and they talk to what? with what code? And with BadUSB out there
(unprotected writable flash is dangerous)?
I think I could write a formal model of IP and prove an IPstack
correct. I certainly would not want to though. And I certainly don't
think I could go much more complex.
The IP stack is the least of your worries. Go look at
802.11g/802.11n/802.11ac drivers/stack and fear, and despair
at issues such as shellshock and heartbleed that run in user space (but let
you 0wn the devices).
The moral of the honeymoon effect is that zero-day
vulnerability discovery is *very* different that normal "bugs", and
occur
much later.
I already know of one serious widespread issue in a binary blob device
driver that will
likely never leave the ecosystem. It's bad enough we'd update the devices,
if only we could (and we can't; the devices only support manual upgrade).
And by the time the vulnerability was discovered, it's not clear that the
build systems/expertise still existed in the silicon vendor to do the fix,
and certainly not in the downstream ecosystem that used that silicon.
These "hidden monocultures" mean that your ecosystem, which you thought was
vibrant with many sources of supply, actually are often close to
monopolies, and those companies make no money out of fixing your security
nightmare.
The sort of things I think need to be network addressable but not
updatable are things like temperature sensor drivers, motor speed
controllers, PID controllers and the like.
My car has 30 computers in it (and a newer model would likely have
60). There is one on every wheel counting the rotations for the ABS
system. Do I really want them all to be updatable?
I think those devices just emit signals, and we don't "talk" to them. I
can
see sensors just being "output only" devices (though that creates a
different problem: network pollution.
A light switch is a writable device.
The switch is a "read" device. It's the light bulb(s) that is(are) the
writable device(s).
- Jim