How to do TLS on embedded devices in a home network?

Question

If you have a router or webcam with a web interface on a home network, can the connection between the browser and the device be secured against a man in the middle attacker? What should device manufacturers do to offer transport level security?

Assume the device gets some DHCP assigned RFC1918 address, like 192.168.1.123, and that a dedicated attacker with physical access can access all files on his own device.

If this is impossible, are there any other ways to offer secure access to an embedded device on a home network?

Answer 1

This can be done by certificates on domain names that point to RFC1918 addresses.

Each device gets its own subdomain (c12345.umbrellacams.com), and each subdomain has its own certificate. When installing the device in the network, it has to send its address to the server in order to update the DNS entry on the subdomain. When the user visits the camera in the browser, they can check the domain name against the serial number on the camera to make sure they are connected to the correct camera.

An attacker can buy a camera and extract the private key from it, but then he can only MitM his own subdomain, c98765.umbrellacams.com, and not other subdomains such as c12345.umbrellacams.com.

When on another network, the domain c12345.umbrellacams.com points to a different device, but since that device does not have the private key of the certificate it can't establish a valid TLS connection.

More details in my blog post, A method to do TLS on IoT devices.

Answer 2

It's not a complete answer, and it's not applicable for all applications, but I'm adding it anyway.

IKEA's Trådfri uses DTLS. They print a sticker with the MAC of the device and a secret key (~80 bits), with a QR code. The IKEA app lets you scan this, effectively authenticating the device to the app, and the app to the DTLS device.

It's not really applicable with for instance a camera, but in many other applications where you have either M2M or app2M-communication it may very well be applicable. It essentially proves that you have physical access to the device - and if I want I can remove the sticker as well...

And I'm really looking forward to other answers to this question!

Answer 3

Being on a RFC1918 address and likely with no domain, it can't have a publicly trusted certificate, but it doesn't need it is vulnerable to man in the middle attacks. You only need the user to be able to connect to the real device the first time, and then it can locally store the exception (TOFU: Trust On First Use).

That first time, you likely also need to configure many other parameters for the embedded device, so there's likely a special way there (which may be more or less secure). For instance, if the user connected through a wired connection, he can be quite certain that initial connection was to the right device.

Some additional ideas:

• Don't come with a pregenerated certificate, create a new one.
• But don't do so at a point where you still not have enough entropy.
• And keep this certificate between restarts
• Ideally, allow regeneration from the web interface and even the user to upload a certificate they generated themselves (maybe even signed by a CA)
• By default, do not allow access outside the subnet, but require explicitly configuring that.
• Do not use default users and passwords. Force the user to set a password when installing the device (maybe offer him one randomly generated on the device, not derivated by the MAC or serial!).