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

[Martin Schanzenbach]

Hi,

On Sat, 2016-12-03 at 19:12 +0100, Daniel Golle wrote:
> 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?

I am not really familiar with openwrt or SCAL.
In general, I am doing IAM research atm. So this might be interesting
for me as well. After a brief read I am not sure how SCAL is related to
access control though. Might need to read more.

> 
> 
> 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-v
> > > isit
> > > 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
> 
>

signature.asc
Description: This is a digitally signed message part