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 > > > [email protected] > > > https://lists.gnu.org/mailman/listinfo/gnunet-developers > > > > > _______________________________________________ > > 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
