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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
