[LEDE-DEV] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things

[Sukru Senli]

Hi Daniel,

Regarding (Phase 2 - ubus rpc proxy), I had opened a thread in October: https://lists.openwrt.org/pipermail/openwrt-devel/2016-October/042252.html

Currently we are working on a solution where multiple OpenWrt devices share a common ubus which allows us to control all devices from a single point.

Our initial development is based on websockets (we have replaced uhttpd with our websocket solution). ACL is still handled by rpcd.

Once we are done with the initial development, we are planning to share the code with the community so that anyone who is interested can try it out and provide feedback and/or contribute.

As the next step we were planning to investigate another approach where websockets are not used for proxying but instead a lower level ubus proxying, ubus monitor, and ubus ACLs (instead of rpcd) are used.

If you agree that we are trying to achieve the same goal here, maybe we should see how we can cooperate.

Regards,
Sukru

________________________________________
From: openwrt-devel [openwrt-devel-bounces at lists.openwrt.org] on behalf of Daniel Golle [daniel at makrotopia.org]
Sent: Thursday, November 17, 2016 12:39 PM
To: openwrt at lists.prplfoundation.org; lede-dev at lists.infradead.org; openwrt-devel at lists.openwrt.org; gnunet-developers at gnu.org
Cc: Kathy Giori
Subject: [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things

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-amidst-winter

Or hard-coded server addresses:
http://www.out-law.com/en/articles/2016/october/singapore-telco-visits-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
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel