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

[Martin Schanzenbach]

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?

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

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