Skip to main content

Gateway Issued Certificate

The gateway issued certificate is a specialization of the intelligent-speaker/application mechanism described previously.

In this scenario, the specialized onboarding code runs in the home router rather than in a smartphone or intelligent speaker.

This approach does not exclude interactions with smartphones and/or speakers via an API.
At present there are no industry standard APIs into home routers, so the app/skill would likely be home router manufacturer specific.
In the future, the TR-369 (USP) specification may become more common.
It is presently quite common for home router manufacturers and/or the ISPs that distributed them to have a smartphone app that controls the home router.
See, for instance, https://www.ripe.net/publications/docs/ripe-759 figure 1 anticipates this API.

When the certificate is issued by the gateway there are a number of advantages:

  1. The gateway can give each IoT device a globally unique name.
  2. The gateway can arrange for the unique name to be resolvable by the DNS to the gateway to the local address assigned, by the gateway to the device.

While the gateway could operate a private certification authority, to be communicated with smartphone and desktop systems in the home through some to be defined mechanism. (Perhaps the API above), if the gateway additionally has a forward DNS zone delegated to it, then it can use ACME (RFC8555) to get WebPKI/CABForum certificates issued. It is easiest for the gateway would use the DNS-01 challenge method, but in some cases where the device cooperates, the HTTP-01 method could also be used.

There are many mechanisms to deal with the delegation of DNS to the home router:

  1. various dynamic DNS systems, including dyndns, noip, cloudns, etc. Many home routers have interfaces to these systems already.
  2. by delegation of a sub-name to the device using, for instance https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ and https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/ (this works very well when the ISP providers the router)
  3. through extensions to TR-69
  4. provisioned by the home router manufacturer
  5. or (for advanced users) via some other manual process

Since the name to IP address mapping can be handled locally by the home router, the access to the local device (once onboarded and provided a certificate), can be guaranteed even if the Internet connectivity is down.

The home router can also consider itself to be an IoT device, and can secure connectivity to itself using this method.

Device onboarding methods which can be used include:

  1. FIDO IoT onboarding
  2. CSA/MATTER
  3. BRSKI/RFC8995

This approach has the advantage of:

  1. Being locally resolvable: will work with no access to the Internet.
  2. Reduce infrastructure requirement: this approach limits the amount of server resident infrastructure that needs to be created and supported.
  3. Increase end user control: an end user has more autonomy, both in terms of physical hosting of equipment, and reducing the dependency on manufacturer, or manufacturer assisted resources for the ongoing operation of their device.

The disadvantages are:

  1. Hardware device security dependency: the router/gateway in this scenario has privileged access to the private signing keys used in the certificate issuance. This changes the attack surface.

Certificate Issuance​

The certificate issuing process at a technical protocol level is not dissimilar to the process defined in the DNS device name model. As usual, the following steps are needed.

  1. End point device generates a unique public private key pair.
  2. Ideally at this point the private key is stored in trusted hardware and provides only a signing function to the client applications.
  3. A name for the device is identified, which reliably resolves to the physical address of the devices (and ideally tracks any physical address changes).
  4. A CSR request is created, combining the local name with the public key.
  5. The CSR is sent to the router/gateway. The router/gateway must implement the CA functions by an interoperable protocol/API to be defined.
  6. The router/gateway sends back the signed certificate to the end-point IoT device.

The fundamental difference here is that in this process (as opposed to DNS device name) the device does not have to be pre-provisioned with a globally addressable DNS and CA server. In this model, the device can locally discover an addressing and CA service directly under the user's control.

Browser Pre-Provisioning​

If the gateway uses a global name, and obtains a standard certificate, then no further interactions with the browser are necessary.

However, if the certificates are not global, then for a router/gateway-issued certificate model to work then the browser(s) need to be pre-provisioned with the router/gateway's public key.

This is a one-off provisioning event that must happen between the browser and the router/gateway in question.

Operational Flow​

The operational flow of the gateway-issued certificate model is fairly straight forward.

  1. The user types (or otherwise discovers) the local name of the target device into the browser address bar.
  2. The augmented browser uses a local name resolution process to turn the local name into a usable physical address.
  3. The browser initiates the TLS negotiation, via the usual method.
  4. The IoT end point device responds with the provisioned certificate.
  5. The browser validates the certificate, and issues warnings or proceeds (see browser decision flow).

Browser Customisations​

As intimated in the browser solution section, this approach will require some critical browser changes. To summarise these changes:

  • The browser needs to recognise local names, and use the appropriate name resolution method.
  • The browser needs to adapt its certificate check algorithm to include the router/gateway root key (note further adaptations are possible at this step).
  • The browser needs to change the warnings given to the user and other UI feedback.