Skip to main content

Integrating With External Systems

In the above sections we defined and contrasted four different methods securing the browser to local web server connection by outlining different mechanisms for provisioning a new IoT device, with both a name and a usable certificate.

In addition, we have outlined the browser changes needed in each scenario to make this workable in practice.

We need to recognize that although standard browsers each have a trusted CA list, different ecosystems and roots of trust exist; many of which are more appropriate and more relevant to the IoT trust case.

For each of these "alternative roots of trust", we could explore two different integration scenarios:

  1. Primary integration: where this alternative root of trust is the primary and possibly the sole root of trust. It replaces the CA browser roots in the TLS negotiation. By implication, this "alternative root" is deemed sufficient in itself to bootstrap the secure connection between user browser and endpoint device.
  2. Secondary integration: where the information extracted from the alternative root of trust, complements or augments the browsers TLS negotiation process.

Typically for these alternative roots of trust, there are two types of trust embodied in the cryptographic artefacts:

  1. Device attestation: which for an IoT device is essentially who manufactured the device, and what guarantee can be provided.
  2. Device ownership: who is the current owner? Has the device been provisioned onto a logical user domain or network?

It is worth reflecting that both of these statements are somewhat different to the security semantics for a typical web certificate issued by CA. These types of certificates are essentially saying:

  • I, as a user, trust that you, as a CA, have issued this certificate, to this organisation (making the appropriate checks) using this name, and that the organisation has been careful not to lose the private key attached to that certificate.

The list and methods that follow are high level and illustrative only. Some of the detail needed to for full analysis is not yet in the public domain, and some simply requires much more detailed analysis of the source technical documents.

Matter​

https://buildwithmatter.com/ Matter provides cryptographic artefacts for both device attestation and user ownership.

FIDO​

https://fidoalliance.org/specs/fidoiot/FIDO-IoT-spec-v1.0-wd-20200730.html FIDO provides cryptographic artefacts for both device attestation and user ownership.

iDevID​

https://1.ieee802.org/security/802-1ar/ iDevID provides cryptographic artefacts for device attestation only.

MUD​

https://datatracker.ietf.org/doc/html/rfc8520 Manufacturer Usage Description (MUD) specification provides cryptographic artefacts for device attestation only. But depending on how the MUD document was discovered, it could be prone to spoofing.

Integration​

For each of these methods a deep dive analysis is required to see how these cryptographic artefacts can be surfaced, so they can be practically used in the browser TLS negotiation session.