Certificate background
Existing TLS certificate practices
Certificates are currently being used for deployed IOT devices. Many gateways and IoT devices host a both a HTTP and a HTTPS webserver for device onboarding and device management purposes. Users are most often directed to the HTTP administrative web server for the following reasons:
- The aggressive security warnings disconcert users, leading to support calls.
- Many browsers make it quite difficult to "click through" past the warning to the "insecure" destination web page.
A solution that embraces the use of well-formed X.509 certificates will have to be combined with new browser behaviours (above section) if it is to be useful.
Certificate Semantics and Security Bootstrap
When the browser connects to the gateway or end point device over HTTPS, the characteristics of the security established are determined by both the characteristics of the certificate being used, and the mechanism by which the certificate was provisioned on the device. (Viable methods of revocation are also relevant). In order to fully understand the qualities of the various solutions, it is worth outlining different options:
0. No certificate (null)
In the simplest case there is no certificate and the website is hosted unencrypted
This method is the defector standard. It should be strongly discouraged. It fails to implement zero trust principles. It leaves critical information, in particular passwords, in the clear.
1. Non device unique - self-signed certificate (NU-S/S)
In this scenario the exact same certificate is burned into "all devices" of this class.
The certificate subject common name is the same as the issuer common name. The certificate is signed by itself. The common name can be arbitrary.
This method will generate browser errors under CA/Browser forum current guidelines.
This method is actively being used by some device manufacturers.
This method should be discouraged.
2. Non device unique - untrusted root-signed certificate (NU-U/S)
In this scenario the exact same certificate is burned into "all devices" of this class.
The certificate is signed by an untrusted root.
By untrusted we mean the signing authority does not correspond to any authority recognised by convention in most web browsers
3. Device unique - self-signed certificate (U-S/S)
In this scenario a public/private key pair is generated unique to this device.
This key pair could be generated in the factory, or during device initialisation.
The common name could be
- Arbitrary text: e.g. "pre-set certificate".
- MAC address: presumably unique to this device, but meaningless in current browser-based certificate check.
- Unique device address: e.g. GUID.
This class of certificate is self-signed
This method will fail the certificate verification under current CA/Browser Forum guidelines and would generate browser errors, unless an exception is accepted for the certificate.
Both these methods 2 and 3 are in use today on real deployed devices. This method generates strong warnings on current browsers.
These warnings could be made more usable with browser changes.
These methods introduce a weakness, that that compromised private key credentials taken from the device mean that it is very easy to "spoof" a manufacture end point device.
These methods should be discouraged.
4. Device unique - untrusted root-signed certificate (U-U/S)
better term for untrusted root
This scenario is like scenario 2, but instead of self-signing the certificate, it is signed by an untrusted root.
It is the same as scenario 5, but the root certificate is not pre-approved in the browser.
5. Device unique - locally-signed certificate (U-L/S)
local non cloud CA
In this method a certificate is signed by binding a unique device common name to a unique public key for this end point device.
This certificate is signed by a local entity, for example a mobile application or a gateway hosted signing service.
For this method to work:
- A CSR must be generated as part of a one-off binding event.
- The CSR must be issued to and processed by the local service.
- The end point address used in the CSR, must resolve locally.
This method requires all the browsers on all the systems to add the gateway certificate that has signed all the local certificates. This requires the certificates to remain local. This may cause problems when internet servers start serving local certificates, but the common name would not match the certificate.
These methods are all slight variants of one another. They improve on 1&2 in that the impact of private key compromise is limited.
The private key per device could be implemented at different points in the lifecycle.
Browser changes are required to unpack the certificate and establish a qualified measure of trust from the signatures, and any a priority trust base provisioned into the modified browser.
These use facing impacts of this trust base will need to be presented to the user.
Many of the solutions below, are examples of this solution
6. Device unique - CA root signed certificate (U-CA/S)
In this method a certificate is signed binding a unique device common name, to a unique public key on this end point device.
This certificate is signed by one of the trusted roots that the browsers use.
For this method to work:
- A CSR must be generated as part of a one-off binding event.
- The CSR must be issued to and signed by one of the Root CAs.
- The common name used in the CSR must be publicly DNS resolvable, at least for the duration of the signing.
This method can be used without generating any browser security warnings. It is the method used by the flexible names Device DNS Name solution.
Device DNS Name provides a description of how we may achieve this method. This is still under investigation.
IoT Certificate Key Usage
Certificates have the parameter fields Key Usage and Extended Key Usage. These parameters describe the purpose of the certificate. For certificates used on the internet the extended key usage is set to server authentication (id-kp 1): https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.3
The key usage parameters of a normal certificate are typically Digital Signature, Key Encipherment and Client and Server Authentication. Other extended key usages are for client authentication, code signing, email protection and timestamping.
A new extended key usage dedicated to IoT could create a certificate class which would be allowed to be signed by a certification authority, vendor or any other authority. Browsers would be able to distinguish the certificate to be of local significance only.
id-kp 10 could be assigned as Local Device. Since this is different than a normal Server Authentication certificate the browser can check that the connection is local and the certificate is signed by a device vendor or IoT authority (FIDO, Matter, CACERT) that acts as root for these certificates.
pre-authenticaiton method on the TLS...
Non TLS based security
TODO
needs more intro. needs combining wiht alternative roots of trust
needs more intro
TLS enables encryption on the session layer, but it's possible to provide encryption for different protocols or in a different layer.
If the device is in possession of a public private key pair, the device may sign one or more tokens, relating to the status of the devices.
In addition the device may be in possession of tokens signed by externally recognised authorities, that containing the devices public key, which also express key information relating to the status of the device.
The only real difference here relates to the expression of the claim. For example these claims could be rendered as JWT's, CBOR Object Signing and Encryption and Verified Credentials.
?? This method would require changes to the TLS stack, to accommodate these new credentials as part of the authorisation negotiation. ??
Alternative Root of Trust
To solve the problem of establishing a trusted secure connection between a browser and a locally hosted web server, we could look outside of traditional TLS certificate semantics and use alternative methods to negotiate a secure TLS session and represent the results of this negotiation.
There are multiple sources of such information from which security could be established. Some of these methods could work in isolation, others can be combined.
Each of these methods could complement, or replace the existing root of trust negotiation method.
The results of this security negotiation could be manifest in a classic X.509 certificate, in which case we may make use of Extended Key Usage (see below), it could be made manifest in a more complex key signing hierarchies (with multiple additional root of trust) , or it could be made manifest in non certificate based representation (see below).
Cert/Key storage
need to be careful on how its done....
Interesting tools
TODO
see if we can find examples of local certs on this database
https://crt.sh/ check for use of intrenal issued certs