Re: Device Discovery and Telehash

Hi Dave

I think, at least for my use cases, perhaps the simplest solution is how
the W3C web-of-things-framework handles the access control via the P2P
protocol.

Each node - which can be either a human or device user - has an ECC PPK
public-private key pair and an account name. Prior connecting and sending
data to each other, the devices and human users have to be aware of each
others' public key and account name. The account name is 8-16 bytes and ECC
public key is 32 bytes so it is particularly suited for a constrained
device environment. An administrator user (in home environment typically
the home owner or the admin of a solution provider) has access to the
device and can update the device with the list of users' public key and
account name. The list include the users that could access to the device.
Alternatively, a web or any kind of online service can configure the device
with the list of permitted account details. If this is not suitable for
some use cases, then we can configure the device with only one admin public
key and account name, which means such admin account has permission to
configure the device with the allowed user list (or in fact with any
configuration data) by connecting to the device once the device is on-line.
(probably this latest is the simplest configuration).
The human user knows the device's account name and can search for the
device's public key via the P2P or centralized web network. Alternatively,
the human user can load the device's public key from a file prior
connecting to the network, which would even further eliminate the security
threats of certain attacks such as Sybil attack (please note since all
messages are signed with the public key in my opinion the room for a Sybil
attack is very limited, but still we have to think about that in a P2P
network. Of course on a client/server environment Sybil attack is not an
issue).
On a private or closed network that limits the access via a firewall to a
known user base the public key pre-configuration can be avoided - only the
account name is required. And then, once the devices and users are on-line
then they can get each others public key by querying it based on account
name from the key repository via the P2P, WWW or WS protocols.
Once both parties are aware of each others' public keys then the ECDH key
exchange is performed to agree on an a symmetric AES key. Following the
ECDH key exchange all messages will be encrypted with the symmetric AES
from end to end, purely peer to peer without using an authentication server
or any centralized solution.
The parties can change/update their public key at any time since the
message of the new public key is signed with the existing public key so the
originator of the new key can be verified by all interested parties.

As for the services, the concept is similar: a PPK key pair is assigned to
he service as well and then the authentication, access control follow the
device-to-human and device-to-device method.

This solution is based on standards. The ECC implementation is FIPS
compliant, it uses recommended ECC curves and all messages are standard
JWT, JWS and JWE compliant data streams.

I think the above satisfies your requirement with regards to easy
configuration - it can be as simple as having one public key and one
account name on the device (the admin account which pushes the
configuration messages to the device).

For my use cases I need a solution in which the access control,
authentication and provisioning can be handled without using any
centralized authority or authentication server, without any cloud based or
client/server solution, but I think such public/private key based
authentication/access control scheme would work on a client/server topology
as well. Personally, I prefer this simple but secure solution over the more
resource consuming oAuth and other popular but complex authentication
schemes.

Regards,
Tibor




On Mon, Feb 8, 2016 at 6:22 PM, Dave Raggett <dsr@w3.org> wrote:

> 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> wrote:
>
>> Hi Tibor,
>>
>> On Mon, Feb 8, 2016 at 5:29 PM, Tibor Pardi <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 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
>> >
>> > 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>
>
>
>
>