On Tue, Oct 14, 2014 at 5:20 PM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
On Tue, Oct 14, 2014 at 4:53 PM, Jim Gettys <jg@xxxxxxxxxxxxxxx> wrote:
>
>
> On Tue, Oct 14, 2014 at 4:44 PM, Phillip Hallam-Baker
> <phill@xxxxxxxxxxxxxxx> wrote:
>>
>> On Tue, Oct 14, 2014 at 3:57 PM, Jim Gettys <jg@xxxxxxxxxxxxxxx> 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