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

Preston Rhea prestonrhea at opentechinstitute.org
Wed Dec 4 12:53:39 UTC 2013


"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." ==
https://www.youtube.com/watch?v=a_saUN4j7Gw

On Tue, Dec 3, 2013 at 8:55 AM, Dan Staples
<danstaples at opentechinstitute.org> wrote:
> 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
> _______________________________________________
> Commotion-discuss mailing list
> Commotion-discuss at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-discuss
>



-- 
Preston Rhea
Field Analyst, Open Technology Institute
New America Foundation
+1-202-570-9770
Twitter: @prestonrhea



More information about the Commotion-discuss mailing list