Re: [LEDE-DEV] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things
Hi Daniel, I would like to ask you if the Vehicular networks is something that could also be added in the future to this project of yours. I mean, there's already alot of development towards 802.11p / DSRC / WAVE. The linux kernel already supports OCB but despite the existent work towards providing the atk5k and ath9k support for 802.11p, ath5k -> https://github.com/Componentality/openwrt-compat-wireless ath9k -> https://github.com/CTU-IIG/802.11p-linux there were no merges or patches additions to OpenWRT in the past. Since Vehicular networks do belong to the IoT context, In my opinion, it could be something to at least be discussed in the context of your project proposal. What do you think? On 17 November 2016 at 11:39, 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-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 > http
Re: [LEDE-DEV] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things
Hi Sukru, On Tue, Nov 22, 2016 at 08:52:57PM +, Sukru Senli wrote: > 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. I was following your posts and do believe there is quite some overlap. It would thus be feasible to generalize the common parts (ubus call proxy, ubus service proxy, ubus remote monitor) by agreeing on a shared interface the actual implementations shall use. In that way, people can choose whether they want WebSockets, TR-069 or a suitable P2P framework depending on their specific needs. Has anything of your current approach at IOPSYS been made available publicly (eg. on github?) >From what I can tell there is also some overlap with Felix' proposed System Configuration Abstraction Layer, just that my envisioned use exceeds system configuration as it includes sensors, events and actors rather than just access to a configuration model. Cheers Daniel > > Regards, > Sukru > > > From: openwrt-devel [openwrt-devel-boun...@lists.openwrt.org] on behalf of > Daniel Golle [dan...@makrotopia.org] > Sent: Thursday, November 17, 2016 12:39 PM > To: open...@lists.prplfoundation.org; lede-dev@lists.infradead.org; > openwrt-de...@lists.openwrt.org; gnunet-develop...@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 oth
Re: [LEDE-DEV] [OpenWrt-Devel] Project proposal: The GNUnet of autonomous Things
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-boun...@lists.openwrt.org] on behalf of Daniel Golle [dan...@makrotopia.org] Sent: Thursday, November 17, 2016 12:39 PM To: open...@lists.prplfoundation.org; lede-dev@lists.infradead.org; openwrt-de...@lists.openwrt.org; gnunet-develop...@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)
