W3C home > Mailing lists > Public > public-wot-ig@w3.org > February 2016

Re: Device Discovery and Telehash

From: Drasko DRASKOVIC <drasko.draskovic@gmail.com>
Date: Tue, 9 Feb 2016 08:40:51 +0100
Message-ID: <CAEk6gTD02oa=X8u5DNOk=AA2Vj=F4wMgm+=C_gkf+PmWSCiWBw@mail.gmail.com>
To: Tibor Pardi <tibor@zovolt.com>
Cc: Public Web of Things IG <public-wot-ig@w3.org>, Dave Raggett <dsr@w3.org>
Hi Tibor,
On Feb 9, 2016 12:07 AM, "Tibor Pardi" <tibor@zovolt.com> wrote:
> 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.

This solution looks interesting indeed.

I am not a security expert, so I have a few questions:
- How does this solution compares to Telehash/Adept?
- Is there any other project using this security approach - i.e. is this
something already deployed and tested by the industry somehow?

I totally agree that we should look for something lightweight and avoid
heavy implementations like oAuth. As I told before, I was looking for
Meshblu-like approach - but it is patented :(.

I saw that you have already documented something here:
https://github.com/w3c/web-of-things-framework/blob/master/security.md. I
think it would be smart to document these propositions/specs somehow, not
to lost them in the e-mails.

>From my experience GitHub wiki has been useful, especially if few of us can
edit it. Otherwise we can use Markdown files in the repo, but this demands
commits for each change.

Dave,
any opinions on creating wiki?

BR,
Drasko
Received on Tuesday, 9 February 2016 07:41:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 10 February 2016 08:15:37 UTC