[Commotion-discuss] Security and remote management for embedded devices

Dan Staples danstaples at opentechinstitute.org
Tue Dec 3 13:55:38 UTC 2013


I just finished reading a very interesting talk by cybersecurity expert
Dan Geer: http://geer.tinho.net/geer.suitsandspooks.8ii12.txt.

The talk is pretty broad and waxes philosophical, but it brings up some
interesting points about increasing attack surfaces (especially with
proliferating embedded systems), automation, and the ability of humans
to manage the security of increasingly interdependent networks. Some of
this we can apply to Commotion:


"So should or should not an embedded system have a remote management
interface?  If it does not, then a late discovered flaw cannot be
fixed without visiting all the embedded systems which is likely to
be infeasible both because some will be where you cannot again go
and there will be too many of them anyway.  If it does have a remote
management interface, the opponent of skill focuses on that and,
once a break is achieved, will use those self-same management
functions to ensure that not only does he retain control over the
long interval but, as well, you will be unlikely to know that he
is there.

Perhaps what is needed is for at least some computers to be more
like humans, and I most assuredly do not mean artificially intelligent.
By "more like humans" I mean this: Embedded systems, if having no
remote management interface and thus out of reach, are a life form
and as the purpose of life is to end, an embedded system without a
remote management interface must be so designed as to be certain
to die no later than some fixed time.  Conversely, an embedded
system with a remote management interface must be sufficiently
self-protecting that it is capable of refusing a command.  Inevitable
death and purposive resistance are two aspects of the human condition
we need to replicate, not somehow imagine that to overcome them is
to make an improvement."


I know for a fact there are Commotion networks and nodes out there that
have been abandoned, are using wildly out of date firmware, but are
probably still reachable in public spaces. What is our responsibility to
those devices (can I allude to Shelley's Frankenstein here?)? Certainly
the end-user has the freedom to setup and modify their Commotion devices
however they want, but would it be wise, security-wise, for us to
implement by default some sort of end-of-life mechanism for nodes that
aren't actively maintained or managed through a remote administration tool?

Just some food for thought...

Dan

-- 
Dan Staples

Open Technology Institute
https://commotionwireless.net
OpenPGP key: http://disman.tl/pgp.asc
Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9


More information about the Commotion-discuss mailing list