Re: [GNUnet-developers] Project proposal: The GNUnet of autonomous Things

[Daniel Golle]

Hi Martin!

On Sat, Dec 03, 2016 at 04:38:06PM +0100, Martin Schanzenbach wrote:
> Hi,
> 
> Out of curiosity I was asking myself since you first posted this:
> Is this a call for developers or are you looking for project partners
> to potentially apply for further funding and planning?

First of all I was hoping to hear from anyone who might be doing
anything similar behind closed doors or who I haven't yet been aware
of, in order to avoid redundant work and/or reduce friction caused by
competition. Beyond that, I was getting quite a lot of feedback, most
of it in private and not on the mailing lists, some of it quite useful.
The main idea is to get funding from prpl foundation for the first
phase, which hasn't much to do with GNUnet, but also already direct
attention of the interested players towards GNUnet as a potentially
useful P2P connectivity framework. That seemed to have worked out
pretty well, I'm now in the final steps of improving the proposal
letter to be approved by prpl. Doing all that in public already
resulted in Felix <nbd> and me having some common vision of what access
control and authentication should generally look like on OpenWrt/LEDE
and I'm going to base my work upon his recent brain-child SCAL [1].
For the 2nd phase, I'm going to implement a SCAL/ubus bridge running as
a GNUnet service and for that I'm definitely looking for both, partners
as well as funding to get started with that by April or May.

What are your thoughts?


Cheers


Daniel


[1]: https://github.com/prplfoundation/scal



> 
> BR
> Martin
> 
> On Thu, 2016-11-17 at 12:39 +0100, Daniel Golle wrote:
> > Hi!
> > 
> > I want to suggest a project to be (partially) funded by prpl's
> > OpenWrt
> > project grant.
> > 
> > Abstract:
> > Implement a secure autotonomous IoT hub using OpenWrt/LEDE's ubus
> > service and the GNUnet P2P framework.
> > 
> > Introduction:
> > Despite the ongoing hype about the so-called Internet of Things, the
> > current practise is rather chaotic and severe structural flaws of IoT
> > devices became a common occurance, including easy-to-remote-exploit
> > vulnerabilities and brain-dead mistakes such as a hard-coded DNS
> > server
> > address rendering thousands of IoT connected devices unusable now
> > that
> > the server is no longer being operated.
> > Given the continous history of quite predictable security and
> > privacy-related catastrophies in the still quite infantile IoT-
> > sphere,
> > taking a step back, a radical shift of praradigms, away from the
> > patterns of Web/Cloud-based infrastrucure will help providing a much
> > more secure and reliable user experience and thereby increase trust
> > in
> > future networked applications.
> > 
> > Recent examples of typical problems related to the missing security
> > model and centralized control servers:
> > http://metropolitan.fi/entry/ddos-attack-halts-heating-in-finland-ami
> > dst-winter
> > 
> > Or hard-coded server addresses:
> > http://www.out-law.com/en/articles/2016/october/singapore-telco-visit
> > s-customers-homes-to-secure-devices-after-cyberattack/
> > 
> > Or missing security by default:
> > http://www.bbc.com/news/technology-37750798
> > 
> > From a coders point of view, the lack of a vendor-neutral abstraction
> > of low-bandwidth peripherals makes it hard to develop general purpose
> > applications which do not depend on a specific hardware or
> > middleware.
> > 
> > This projects suggest a from bottom-to-top redesign addressing the
> > diversity of components and local access methods (ranging from
> > in-kernel-only drivers to almost pure userland implementations),
> > connectivity (NAT traversal, discovery, ...) as well as security and
> > privacy-related concerns. As a first measure, a generic integration
> > of
> > low-bandwidth peripherals such as simple sensors and actors using the
> > OpenWrt/LEDE core infrastructure will provide a great improvement to
> > access and manage local IoT features. This may then be used by
> > various higher level applications, such as data-logging/monitoring,
> > WebUI or machine-to-machine communication.
> > 
> > As dependence on centralized services providing remote access has
> > shown to be problematic in terms of security and privacy as well as
> > reliability, direct connectivity or application-agnostic indirect
> > routing using well-known P2P techniques can bring about more
> > interoperatibility and sustainability. GNUnet provides (among with
> > many other things) a modular toolkit for P2P, ranging from a
> > NAT-aware multi-transport, cryptographically addressed general
> > purpose
> > overlay network to pub/sub, filesharing and real-time conversation
> > services. In a second phase of the project, this core infrastructure
> > is going to be used to provide secure, reliable and privacy-aware
> > remote access to IoT features on typical OpenWrt/LEDE target
> > hardware.
> > Using GNUnet implies inheriting all the advantages of a secure P2P
> > infrastructure which has seen  12 years of intense research and
> > several iterations of architectural revolutions within that long
> > time.
> > Having a remote-access method for ubus which already provides it's
> > own set tools to work in a wide range of environments (think: behind
> > NAT, using low-level transports such as UDP, TCP, HTTP and proper
> > HTTPS over IPv4/v6 as well as raw bluetooth and wifi injection
> > sockets
> > for local area coverage) and got it's own built-in security
> > mechanisms
> > as well as management structures (think: a distributed personal PKI)
> > also seems to be a very good match, especially due to the modular
> > nature of GNUnet which allows using only the parts needed on resource
> > constraint hardware. Obviously this may be also very useful for any
> > kind of remote-management or other sort of remote-access to ubus
> > and/or rpcd.
> > 
> > GNUnet is extremely portable, works on a great variety UNIX-like
> > systems as well as Windows and can be compiled using LLVM, thus be
> > turned into a in-browser JavaScript-monster using enscriptem, see
> > https://gnunet.io/ for an early example of an in-browser version of
> > GNUnet's anonymous filesharing service.
> > 
> > In the past 2 years I ported to OpenWrt/LEDE, contributed fixes as
> > well
> > as features back upstream and became a member of the GNUnet e.V.
> > association, mainly having applications like the above in mind. In a
> > third phase, a set of services utilizing that infrastructure such as
> > a
> > plugin for collectd (data logging), a programmable monitor/alarm
> > service polling properties and emmit events and action triggers
> > listing
> > for events and controlling actors is going to be built.
> > 
> > 
> > Project schedule
> > 
> > (I)
> > As a first step towards better integration of typical IoT USE-cases
> > into OpenWrt/LEDE, a ubus service allowing access to low-bandwidth
> > peripherals shall be created. It's modular design shall allow for
> > plugins providing access to various different APIs and low-level
> > busses. Plugins may expose read and write access to datastructures
> > and emmitt event notifications.
> > The ubus API shall be sound and well-documented. Sample plugins
> > including verbose comments utilizing and demonstrating that
> > infrastructure shall be implemented.
> > 
> > (II)
> > Once sensors and actores are available via the local ubus instance,
> > a ubus rpc proxy which operates as a GNUnet service shall be
> > implemented
> > to allow secure and privacy-aware pairing of OpenWrt/LEDE devices and
> > remote access to ubus using GNUnet.
> > 
> > (III)
> > Several follow-up users of the now available infrastructure shall be
> > created in the third phase of the project, including a plugin to
> > the most commonly used data logging service (collectd) and a polling
> > service emitting events if defined thresholds are reached.
> > A simple generic controller, similar to OpenWrt/LEDE's hotplug
> > scripts
> > (jsonscript) shall be implemented to take actions upon events.
> > 
> > 
> > Phase (I) is estimated to be about 2 to 3 months of full-time
> > development
> > time, phase (II) slightly less, phase (III) depends on the intended
> > volume and estimated adoptation of the previously created
> > infrastruture
> > by the community and it's cost should thus be evaluated after phase
> > (I)
> > has been completed and was received by the community.
> > 
> > The different phases may be funded by different parties. I consider
> > phase (I) as being most relevant to prpl and it's members.
> > 
> > 
> > Phase (I) deliverables
> > 
> > ubus IoT service
> > 
> > Methods:
> >  - list
> >  - list_plugins
> >  - get {object} {property} [property, ...]
> >  - set {object} {property} {value}
> > 
> > Plugins:
> >  - sensors (read, emmitting events)
> >  - GPIO via sysfs (read, write)
> > (- libmodbus (read, write))
> > (- libi2c (read, write))
> > (- libevdev (emitting events))
> > (- ola/DMX512 (write))
> > (- other IoT libraries like IoTivity? LinkIT?)
> > 
> > (plugins in parentheses are optional and may be implemented at a
> > later
> > point in time imho, prpl and the OpenWrt/LEDE community may suggest
> > different priorities)
> > 
> > 
> > I'm looking forward to hear from you!
> > 
> > 
> > Best regards
> > 
> > 
> > Daniel
> > 
> > _______________________________________________
> > GNUnet-developers mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/gnunet-developers



> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers