Re: Device Discovery and Telehash

<<< How does this solution compares to Telehash/Adept? >>>

Conceptually it is similar as Telehash terms of that both solutions use a
Kademlia distributed hash table and end-to-end encrypt the data between
peers, so there are only encrypted messages circulated on the network.
Since IBM selected Telehash for Adept I was considering to integrate it.
Telehash is a widely used and mature solution and I understand we should
try use it instead of reinventing the wheel. The problem is (apart from the
problem what I have mentioned with the Nodejs code), in my opinion there is
a need in IoT for deployments in which the access to a device is limited to
certain users. For example, it is probably not a good idea to expose a home
automation system of a family home or a home CCTV camera or a door device
of a smart car to the Telehash public network. P2P public networks expose
certain metadata and peer information, and that could be a security concern
for certain use cases. For that reason I introduced the private network
concept (which I tried to explain in my previous email) that is still a P2P
topology and operates without the need of a proprietary, corporate owned
cloud infrastructure, but don't expose the devices to the public network.
IMHO Telehash could be very suitable for public devices such as weather
sensors to broadcast weather data to potentially millions of users (our
solution is capable to do that as well, but Telehash is already a powerful
P2P network).
We should introduce a factory pattern design in our code, which allows to
select the underlying P2P provider, and then Telehash can be selected as
the transport provider in case someone prefers using Telehash. Such factory
pattern design will be a fairly easy change in the code and then it would
be great if someone could integrate Telehash.


<<<  Is there any other project using this security approach - i.e. is this
something already deployed and tested by the industry somehow >>>

A few users have contacted me about the P2P topology and interested in
deploying the solution once it is matured and we can provide reference
designs on a hardware. So now I am trying to create reference designs on
Raspberry Pi, STM32 and Atmel boards. It would be great to organize some
pilot projects using P2P!

As for the security approach, please note this approach is nothing more
than using a standard, well tested, widely used and very basic PPK
cryptography infrastructure. User A sign the message with the private key
and User B verify the message using the public key of User A. Using PPK
cryptography allows to manage both authentication and guaranty data
integrity. Terms of this we are not reinventing the wheel and we are using
FIPS compliant standard PPK cryptography.


<<< 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 agree. I can understand why solution provider corporates who sell IoT
systems prefer oAuth and all its attachments like authorisation servers. I
am sure it is a very sensible business proposition as well as the best for
many use cases, but I agree, for IoT a more lightweight solution should be
a better fit.


<<<  I think it would be smart to document these propositions/specs
somehow, not to lost them in the e-mails. >>>

Absolutely, and I will try my best to update the document with new UML
diagrams. I am a voluntary contributor and I just need to find some time to
do this.


<<< 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? >>>

I believe Dave has already created a Wiki and asked the community that
please help or feel free to write the content. It would be great to have a
Wiki, as you said it can be a useful repository.


Regards,
Tibor


On Tue, Feb 9, 2016 at 7:40 AM, Drasko DRASKOVIC <drasko.draskovic@gmail.com
> wrote:

> 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
>