Re: Device Discovery and Telehash

Any thoughts on access control, a) for discovery and b) for accessing the service ?

We would want to provide a simple approach that is easy to configure.

> On 8 Feb 2016, at 17:24, Tibor Pardi <tibor@zovolt.com> wrote:
> 
> Hi Drasko,
> 
> Thanks! 
> 
> P2P seems to me the natural and very obvious solution to manage device discovery. I.e. user Alice purchase a door opener device, the device goes on-line with its PPK public key and join to the P2P Kademlia DHT network, user Alice mobile/tablet device find the door on the P2P network. Later family member user Bob find and can control the device as well. The communication is end to end encrypted with symmetric AES using ECDH key exchange and the data integrity is guaranteed using ECDSA. The difficult task of device discovery can be managed with a relatively simple open source software without using Microsoft, Amazon, Google, etc. cloud nor the need of a closed source proprietary corporate software. So the open source solution can be peer reviewed to verify it complies with standards and there are no security back doors exists. As long as two users are on the internet the P2P network can be formed and more users - by the nature of P2P data sharing - should make the network more stable and responsive. On the other hand more users in the client/server paradigm require more resources, licenses, load balancer and cluster servers. 
> 
> I have designed a "private" P2P module and now I am integrating it into W3C code base. The "private" P2P allows that for example a family or business or community run a Kademlia DHT that is isolated from the public network and only designated accounts can connect to such private network. This introduces an additional layer of security as well as can isolate devices from the public network.
> 
> Please note the code is experimental and early stage, but I am working on the improvements. Please let me know if you need any assistance with the code.
> 
> Regards,
> Tibor
> 
> 
> 
> 
> 
> On Mon, Feb 8, 2016 at 4:38 PM, Drasko DRASKOVIC <drasko.draskovic@gmail.com <mailto:drasko.draskovic@gmail.com>> wrote:
> Hi Tibor,
> 
> On Mon, Feb 8, 2016 at 5:29 PM, Tibor Pardi <tibor@zovolt.com <mailto:tibor@zovolt.com>> wrote:
> > Hi Drasko
> >
> > We have started to implement a P2P device discovery module in the
> > https://github.com/w3c/web-of-things-framework <https://github.com/w3c/web-of-things-framework> project. Our P2P discovery
> > module uses the a Kademlia DHT table, the implementation and concept is very
> > similar to Telehash. I investigated Telehash as well, I understand IBM's
> > Adept (before it was abandoned) selected Telehash, but there are very little
> > Nodejs support for Telehash which I could integrate at the time. Our
> > underlying or ECDSA modules are based on Bitcoin crypto as well and use a
> > Bitcoin crypto library.
> 
> Great!
> 
> >
> > Device discovery is one of the main area which need to be addressed, and an
> > open source, decentralised, P2P device discovery mechanism that operates
> > without using a proprietary cloud or client/server module is one possible
> > way to manage the topic. In fact I believe P2P is the best possible solution
> > for device discovery.
> 
> Agreed, this is exactly my opinion also.
> 
> > P2P by definition addresses requirements such as
> > scalability and high availability without the need to spend a fortune on
> > load balancing and cluster infrastructure.
> >
> > There is a brief readme to explain our P2P device discovery module at
> > https://github.com/w3c/web-of-things-framework/tree/master/examples/p2p_demo <https://github.com/w3c/web-of-things-framework/tree/master/examples/p2p_demo>
> >
> > Please note I am updating the P2P module at the DEV branch with optimizing
> > the module, providing tests for ECDSA and ECDH and using TCP/IP by default
> > instead of UDP (several users reported that their mobile operators blocks
> > UDP traffic).
> 
> I will take a look at this solution - it looks very interesting indeed!
> 
> BR,
> Drasko
> 

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>

Received on Monday, 8 February 2016 18:22:59 UTC