Remote access technologies

(Remote access to a dLink camera).

Tim Panton

You have an IoT device that sits behind NAT (which is true of allmost all IoT) - it might be on a domestic wifi or on a 4/5g network. Imagine you want to access it remotely - say via it’s built in webservice.

How can you best go about this?

Here are some established ways.

Port forwarding

In effect give the device a public IP address. This looks simple, but in practice it isn’t because:

• You’ll have to configure the router to do the port forwarding - in the domestic context, this might be one of 100 router brands all with different screens you need to document.
• The device is now visible to every hacker on the planet, take a ‘safari’ on shodan.io if you think no one will find it. Automated hacks ensure it will be attacked
• The IP address probably won’t stay constant, unless you pay extra, so you need to add something like DynDNS to keep track of it
• The device will need to run https - and hence have a certificate to ensure that users can actually access it from a modern web browser without problems
• If you have many devices on the same network you’ll have to manage port allocation too.

IPv6

In theory you can arrange for your device to get a global IPV6 address.

• In practice this isnt’ supported by enough ISPs to be a viable strategy, yet
• It has most of the same security problems as Port forwarding

Dedicated IoT cloud services

Your device makes an outbound connection (often a websocket) to a ‘twin’ in the cloud. Users use a web service (or mobile app) to change the state of the twin, which periodically syncs with the real device. This is the current ‘best practice’ advised by the cloud providers. However:

• It is quite costly in AWS (or other) monthy fees
• It introduces extra latency in the aditional hop and processing.
• It centralizes key managment - your users log into AWS so their keys/passwords are stored there, as are the keys for your devices. This is a honeypot for hackers, if they get admin access to your cloud, they have all your devices.
• If there are cloud outages, your devices are unreachable - even if they and you are still on-line.

VPN

All your devices join a VPN - giving them additional IP addresses that are reachable by your users - provided they also join the same VPN. It has the benefit of encrypting the traffic too.

• VPNs are not trivial to set up - the certificates have to be distributed securely to endpoints including your user’s smartphones
• VPN clients need to be installed and configured on all the devices (both IoT and user).
• Accessing an http service over an encrypting VPN will still give a security warning in all modern browsers - so it ‘looks’ insecure to users.
• The VPN server will need to have the capacity to support all the traffic/user numbers you have - scaling a VPN isn’t trivial.
• If certificates (or devices) fall into the wrong hands, then the VPN is open to attacks from the inside.
• VPNs terminate at the network layer, so a misconfigured VPN may end up routing the user’s email/netflix traffic in addition to allowing access to the IoT device.

As you can see none of these established ways are ideal - they all have pros and cons. None of them are especially user friendly.

So is there a better way?

|pipe| has a new solution to this problem

We use WebRTC datachannels to ‘proxy’ web (and other) traffic from an IoT device up into the browser of an authorized user. We have built a fresh webRTC implementation targeting IoT hardware, which acts as a secure protocol proxy between local (on device) services and the user’s smartphone browser. This has a nice bunch of properties:

• It is encrypted end-to-end
• All keys are held at the edge (no centralized keystore/honeypot)
• The endpoints don’t need PKI certificates
• WebRTC uses self-signed certificates
• Validated using |pipe|’s patented method
• WebRTC does NAT traversal
• WebRTC will find the lowest latency path between the endpoints, which makes this ideal for latency sensitive applications like lighting
• The connection terminates in the user’s browser page, so the path is only used for that application, not for general youtube viewing!
• We can proxy http: and ws: - meaning that you probably don’t need to change the device web pages much (if at all)
• We can use the same connection to transmit low latency audio and video data at the same time as proxing web traffic

This last point is really useful in the context of remote security cameras etc. With |pipe| you can have a live low latency video feed into a users browser and a proxy channel to the builtin UX. Just like being on the local LAN - but with better security and no messy setup. With |pipe|’s lend-borrow QR transaction you can also easily grant short term access to a second user - a subject matter expert perhaps.

I won’t go into technical depths here, but I will say that the solution is standards based and uses the latest browser capabilities (e.g. service workers, webRTC certificate managment and transferable streams) to achive it.

And here’s a block diagram of how it works.