Security in IoT and especially in home security solutions has been subject for several recent articles and debate, for instance see http://thenewstack.io/snooping-webcam-reveals-security-dangers-internet-things/.
Since the article above covers the general security issues of P2P, the same concerns of course apply to Nabto based solutions – this post addresses these concerns and summarizes the security principles of our platform, some of it applies to P2P solutions in general.
Basically, to allow a peer-to-peer connection to be established to a device, such as a camera, the camera must communicate with a central service that knows about the camera’s network configuration. This is not any different than in e.g. IP telephony where the IP phone central knows about each IP phone’s network configuration and needs to communicate periodically with each IP phone to allow other peers to make calls to it:
When a Nabto enabled device (e.g. a P2P IP camera) is turned on, it will try to register itself with its associated central services. Our approach to this is to use DNS – each Nabto enabled device has an associated DNS hostname, for instance <some-id>.p2p.vendor.net. This DNS name resolves to the Nabto “phone central” services, we denote this the “Nabto basestation”:
The registration with the basestation takes place using strong cryptography using HMAC/SHA256 and AES128 with a per device unique shared secret. This allows a secure, private channel to be setup between the basestation and the device; all subsequent remote communication with the device is then encrypted for confidentiality and integrity. This approach without the need for asymmetric cryptography on the device enables Nabto to work on even the most resource constrained devices, e.g. sub 1-dollar 8-bit MCUs.
The client that communicates with the device is authenticated through an RSA X509 certificate. When a client initiates a connection towards a device, a secure channel is first established between client and basestation using a regular RSA based TLS handshake. A session key is then established and exchanged between client and device, along with IP information to allow a P2P connection attempt.
Once a connection is established, the device owner controls who accesses the device, the traffic cannot be manipulated and an attacker cannot intercept the communication.
This is all good as long as you can trust the owner of the basestation and that what I said above is actually true about the device code. The Nabto platform allows vendors to host their own private basestation – and most of our biggest customers indeed do that today. This means that Nabto is completely out of the loop. And that the vendor can have their servers located in their desired geographical region – so no need for communication with seemingly random hosts in e.g. China. The vendor can hence have a trust relationship solely with their customers (the end-user), the end-user sees no peculiar traffic between their device and an unknown 3rd party.
Our device SDK is open source, you can download everything on Github so you can see exactly what the communication is about. Of course this is not a guarantee – the individual vendor could in principle change the source code. But if you inspect the communication with e.g. Wireshark and correlate with the available source code, the task for understanding the individual vendor’s product for an analyst is indeed simpler.
With all the above being said – much of the current discussion about P2P security is about the owner of the device not being able to turn P2P access off: It is of course up to the vendor to control how to activate the Nabto P2P functionality – but we make it simple to do so, we have a single “master switch”; if not turned on, there is absolutely no P2P related communication taking place.
For more information on security in the Nabto platform, don’t hesitate to contact us on [email protected] or take a look in our security guide TEN036 Security in Nabto Solutions.
