The Internet of Things Security Foundation (IoTSF) ManySecured Special Interest Group (SIG) is working to outline high level solutions to a design flaw/problem that affects millions of IoT devices and standard Internet routers. We are also encouraging the development of working prototypes of potential solutions that can be tested for scale and usability.
The Problem
Anyone who has tried to use a browser to configure or manage a device on their home network will be familiar with the following situation. Firstly, one needs to know the device’s local IP address, which is used in lieu of a hostname in the URL. Then, one typically needs to use the unencrypted version of HTTP, i.e. HTTP rather than HTTPS, potentially exposing passwords and other sensitive information to eavesdropping. If one tries to use HTTPS, then the browser will most likely display a dire-sounding warning saying that the connection is not private and attackers might be trying to steal information. Someone with knowledge of networking and security will understand what this really means and make an informed judgement about whether to proceed, but an average home user will either be scared off or will unlearn normally safe guidance about not interacting with a web site unless the closed padlock is displayed in the browser’s address bar.
Background to Problem
Internet Browsing
Consider what happens during normal Internet browsing over HTTPS. When a URL is entered or a link clicked, the browser needs to work out where to send the request. It extracts the contents of the hostname field from the URL. If the result is an IP address, this can be used directly, otherwise if it is a DNS-compliant domain name, the browser uses DNS to look up the corresponding address. To prove its legitimacy, the web site to which the request is sent returns its TLS certificate. The browser checks that the certificate is valid, that the signature can be traced back to a root of trust the browsers recognises, and that the domain information is consistent with the hostname in the request. If all this is good, a TLS connection is initiated. As part of the set-up phase, the web server demonstrates possession of the secret key corresponding to the public key disclosed in the certificate. Why can this not happen on a home network?
Home networks almost always use private IPv4 address space, most commonly, 192.168.0.0/16. This means that large numbers of unrelated devices around the world will have the same local IP address. Consequently, certificates citing such addresses would have little or no value unless local in scope, i.e. issued by a Certificate Authority (CA) that is trusted only within the local network. Furthermore, IP addresses on home networks are subject to change — they are mostly issued dynamically and IoT devices are often mobile — so even on a local basis, certificate management would be challenging. The situation is a little better if devices are given (fully qualified) hostnames against which certificates are issued. Hostname-to-local-address mappings can be registered with the DNS system, but the IP addresses returned would only make sense in the context of particular local networks. For example, it could work fine for fixed devices with static IP addresses, but the IP address would only correspond to the target device if the browser and the device were on the same local network.
Solutions to Problem
What is needed is a local means of address resolution. One already exists in the form of Multicast DNS (mDNS for short). To use mDNS, a host wishing to know an IP address on the local network sends a request to resolve the target name to other hosts via the link-local multicast address. Hosts able to answer the query do so, normally again using multicast so that all hosts may update their caches of name-address records. One restriction is that the hostname must have only two elements separated by a dot, the second of which is “local” (e.g. MyPrinter.local). The mDNS name will not be unique and due to the rules against signing certificates for local names, browsers will not trust these certificates.
In order to identify an optimal solution, we explore the background concepts to potential solutions in greater depth e.g.
- Addressing: How is a device connected to the network (e.g. ethernet), how is it addressable (e.g. RFC1918 IPv4) and how does it implement name resolution (e.g. DNS or mDNS) The physical and logical addressing are a means for a browser to identify the local scope. The IP and DNS names are relevant because they are used by the browser to locate the device and in TLS certificates these are used as identifiers for the device. CA/Browser Forum uses the term “internal names” for IP and DNS names used in a local scope.
- Browser: Current browsers following CA/Browser Forum requirements show a padlock icon for certificates that are signed by a Root Certification Authority (CA), and generic security warnings are displayed for certificates that are not verified. How can a secure connection be established to local web servers and does this require a change in the browser?
- Certificates: For public Internet certificates the browser behaviour follows clearly defined TLS certificate management principles. For the local web server scenario, what changes are needed to make the certificate chain work?
- Device Onboarding: How do the IoT devices get onboarded on the network and how does the browser discover connectable IoT devices?
Find Out More
More detail of the problem, background, technical requirements and potential solutions can be found in the ‘SUIB Documents‘ on the ManySecured Technical Documents website.
The solutions outlined in documents are not intended to be complete – they are ‘Work in Progress’. Our objective is to explore the details of the problem, and outline high level solutions for further investigation and refinement.
We actively welcome comments and improvements to these documents.
Get Involved
If the problems highlighted above are of concern, you would like to find out more and are interested in joining the SIG, please get in touch.
