Skip to main content

SUIB Technical Requirements

Document purpose​

This document outlines the technical requirements that need to be satisfied in order to connect and configure IoT end point devices securely in a usable fashion over an internet browser.

Requirements​

Encryption​

The connection between the browser user agent and the IoT end point device must be encrypted.

It must be infeasible to perform a man in the middle attack on the payload of traffic.

Implementation notes: the current de facto standard is that browser sessions on the local intranet are over HTTP. HTTPS connections typically generate end user warnings that make them unpalatable for both the device manufacturer and end users.

Usable Discovery​

The browser user agent must be able to discover local end point devices in a usable fashion. [what is meant by usable fashion? How do we test this requirement?]

Implementation notes: the current de facto standards for discoverability are:

  1. mDNS.
  2. Well known IP addresses.
  3. Globally resolvable domain name that resolves to a local address.

Each of these solutions has limitations and drawbacks.

Addressability​

It should be possible to address an IoT end point device through the browser user agent interface using a persistent link.

This link could be a shareable URL.

Implementation notes:

Could be using HTTP/S:// URI Scheme

OR new scheme to be identified, e.g.: IOT://

Local resolution​

Discovery, address resolution and encryption negotiation should work when the router is not connected to the public internet.

Implementation notes:

There are a number of reasons why this is an important requirement:

  • We may decide to configure and administer the local IoT devices before internet connections are enabled.
  • The current security policy might quarantine or isolate new, non-configured devices from public internet access as good security practice.
  • Internet connectivity might be lost temporarily; we should still reasonably expect the administration and configuration use-cases to be viable.
  • Some device use-cases do not need connection to the open internet to be useful, therefore it is unreasonable to insist on it purely for administrative purposes.

End point validation security qualities​

The security negotiation process between the browser user agent and the end point IoT device should factor in known security qualities of any secrets used in that negotiation and declare the nature and limitations of any encrypted session to calling functions.

Implementation notes:

The complexity here lies in the fact that it is easier to preserve the secrecy of private keys on internet servers, around which existing certificate negotiation protocols have been designed, versus the difficulty of securing private keys on local devices with limited or no physical security.

Client UI confirmation of encryption​

The client user interface should present a visual confirmation to the user that traffic is encrypted.

Implementation notes:

Typically this is done using icons in the browser address bar (e.g.: padlock).

This requirement assumes/ means it is highly likely that we will need to request fundamental changes to the browser behaviour for new classes of certificate.

Client UI confirmation of end point validation​

The client user interface should present a visual confirmation to the user that the end point is validated.

Implementation notes:

Typically this is implemented with icon differentiation and/or details options on certificates [what is meant by details options?]

This requirement assumes/ means it is highly likely that we will need to request fundamental changes to the browser behaviour for new classes of certificate.

Revocation/Lifecycle​

It should be possible to revoke the IoT end point certificate if it is suspected that the key (or part of a key chain ) has become compromised. [who can (or is best placed to) revoke - user, manufacturer, ISP?]

Implementation notes:

Do we need to consider the certificate lifecycle? Normal HTTPS certificates have a lifecycle. If we develop a new set of protocols and conventions for issuing "local certs" - what is the lifecycle? Who is responsible for issuing? Does a third party "authorise". Is there a time limit? Who can revoke ?

This introduces some fundamental questions about what stakeholder will provide such revocation capabilities?

Manufacturer Service independence​

The security method defined should not be dependent on the continued availability of manufacturer specific servers. The device should continue to be able to provision [provision what - certificates?] even if the manufacturer no longer supports the device or goes out of business. Note: in some cases the requirement may refer to a service provider server (e.g.: ISP or CSP) provisioning certificates.

Implementation notes:

The systems created to address the security requirement should be resilient [...resilient to what - non-availability of a specific remote server (OEM/service provider].

If the IoT device has utility, which is not bound to the continued hosting of a remote service (e.g. a speaker), the security and administration protocols should not introduce new dependencies which could result in the "Bricking" of the device if an internet service is taken offline.

General resilience​

The technical solution defined should pass common sense tests [requirements need to be testable - common sense is not!] of resilience, scalability and resistance to threats inside and outside the network. [what levels of resilience, scalability and resistance? Threats evolve over time - what is today's "nation state" capability may become available to hackers within the support period of a device]

Practical considerations​

These requirements should not be deemed absolute requirements, but requirements of degree.

To address fundamental security vulnerabilites and usability issues, changes will need to be made. These changes could impact:

  1. The implementation of the browser which is being used.
  2. The implementation of the IoT endpoint, in particular the HTTP/S server process running on the IoT end point.
  3. Impacts to the supply chain, to either configure or operate both the client and server end points.

Minimise impact on browser​

Technical changes to the browser user agent are to be minimised.

We need to be aware that any changes to browser implementations may impact mobile phone browsers, PC browsers, TV browsers, etc., each with multiple operating systems and impacting multiple browser ecosystems.

Minimise impact on end point​

Many of the solutions to be considered may require a change in the behaviour of the IoT end point.

Most IoT end points don't currently serve HTTPS, only HTTP. Those that do serve HTTPS may need to behave differently to the current browsers.

Minimise impact on the supply chain​

Many potential solutions will require changes to the way the supply chain works, with impact on the distribution and retail sectors. Or there could be impact to the creation of new certificate authorities or DNS behaviour. Some specifically technical considerations:

  • Does a new CA entity need to be created and defined?
  • Do new DNS capabilities need to be created and defined?
  • Do we need to consider the portioning of device certificate endpoints (for the creation of a CSR for example)?

Minimise the impact of the end user​

Do we expect the user to behave differently, e.g. only user certain types of browsers for this provisioning use case? [what is meant by this example?]