Public key infrastructure (PKI) certificates are the best available technology to use in internet of things (IoT) devices for secure communication, access control and code security – but the way it is done requires thorough considerations. In this text, PKI expert Tamás Horváth explains how to validate the certificates in IoT devices.
PKI is the best available technology to provide communication security, access control and code security in IoT applications. In a recent blog, I explored the special aspect of certificate lifecycle management in view of the great variety of possible product supply chains and operation scenarios in IoT. In this blog, I am exploring the less discussed side of an IoT PKI: How to validate certificates in IoT devices.
Revocation is a built-in PKI function
PKI standards – starting with X.509 in the 90’s – define a revocation infrastructure for certificates: if the private key of the certificate holder is compromised, is suspected of having been compromised or is no longer needed, the corresponding certificate can be revoked using the revocation service of the issuing Certificate Authority (CA). The CA will publicly announce the revocation to other PKI parties in two standard ways:
- Certificate revocation lists (CRLs) can be downloaded from a central CRL Distribution Point (CDP) service. A CRL lists all revoked certificates in the CA’s context.
- The revocation status (revoked or non-revoked) of an individual certificate can be queried from an OCSP service (Online Certificate Status Protocol).
These services allow a relying party – i.e. a party that wants to verify the certificate of another party – to check the revocation status. In essence, these services are central services, while they can be made available at many points of the network for better availability and global accessibility. Both CRLs and OCSP responses have a validity date and have essentially the same content. Accordingly, they can be seen to provide the same quality of validation service. CRLs and OCSP responses can also be cached in involved components to improve accessibility.
Revocation in IoT
The classical procedure for certificate validation (refer to RFC5280) includes checking the revocation status of the certificate based on a freshly retrieved or a cached CRL or OCSP response. For an IoT application, this implies that:
- the validating devices require online access to a CDP (CRL distribution point) or an OCSP responder or to another caching component with access to those.
- the CDP or OCSP service may need to cope with a large number of request.
In the classical PKI, revocation is triggered by human users, who detect and report compromise of a device to a support system. For an IoT application making use of revocation, a user or a management application (device management system, IOT platform or similar) must request the revocation of the respective certificate at the CA. This is typically done via a certificate management interface of the CA, and not via a support service of the CA.
In an IOT application, it is worth considering the following questions:
- Is it indeed meaningful and relevant to revoke the certificate of a device?
If, for example, there is no material or financial risk related to the loss of an IOT device, the revocation infrastructure may be omitted. Unfortunately, there is no standard way to mark in a certificate that there is no revocation service. The validation software behaviour should be examined for the case when no CDP or OCSP service URLs are available in the certificate being validated. In this case, the validating software MAY assume that no status validation is needed.
- Is there a human user who can report compromise of a device via a support system and is there a management system, which can trigger revocation for devices, of identifies that are no longer used or changed?
If there is no reasonable possibility for reporting a revocation case, the revocation infrastructure may be omitted.
Download the guide: ”How to build a secure IoT infrastructure.”
Certificate renewal in IOT
In a classical PKI, certificate validity is usually adjusted to the guaranteed lifetime of the carrier device (e.g. smart card or IT equipment) or to the validity of the issuing CA (which may be limited not to let CRLs grow too big). It can also be limited due to some other policy, e.g. to enforce reviewing validity of the subject identity or the authorization of the certificate holder. I want to refer to this interesting article about why certificates have a validity at all: https://security.stackexchange.com/questions/58025/why-are-certificates-limited-in-time
Certificate renewal (re-keying or re-certification) requires access to the central CA infrastructure and raises thus similar challenges of connection reliability in the IOT.
So, in IOT application, it is worth considering:
- What is the expected lifetime of the device? Are there any organizational or technical reasons to limit the certificate validity?
If not, the certificate validity may be chosen to cover the expected lifetime, to be practically infinite (e.g. year 9000) or to be undefined (represented by 99991231235959Z according to RFC 5280). The validation algorithm MUST be able to properly interpret such validity data. In that case, the renewal process and respective interface can be omitted.
- Will it be necessary to change the identity of the device?
If not and the certificate validity covers the device lifetime, a renewal process and respective interface can be omitted.
Validation with unreliable Internet connection
In the classical PKI setup, the relying (validating) party has reliable access to the CDP or OCSP service. It is straightforward to distribute these services to several parallel nodes for higher availability and global accessibility. In the standard validation algorithm, if no valid revocation information is available, the validation will yield a negative result and, for example, deny access to a service. This is to avoid “false positives”, i.e. that a revoked certificate validates successfully. This rule moves the system in the direction of security at the price of possible loss of service availability.
However, in some IOT scenarios, access to the Internet may temporarily be blocked. Examples are devices that connect to the Internet via a gateway (for example, a mobile device) or via another device (for example, a car charger). It can also be a device, which is connected with other devices during normal operation only, and cannot rely on stable Internet connection (e.g. Car2Car). In such cases, it needs to be considered:
- What happens if the relying IOT device cannot validate the certificate of another device or service? Will this cause denial of service, or a usability or safety issue?
If a frequent loss of device functionality is measured against a low probability and a low financial damage of a “false positive” validation, the application designed may decide rather to apply a tolerance for “false positives” and for better availability of functionality. If safety is at risk, the stricter approach must be applied.
- Is it possible to cache revocation information in the relying device or in an accessible other device (e.g. in the gateway)?
An example is an electric car charger that caches CRLs for the certificates of all potential cars that may connect for charging. This can be a very effective measure. However, if the CA potentially covers a large population of cars, download and storage of the CRLs may require a large amount of transferred data and storage space. In such cases, using OCSP for validation might still be a better option.
- Can the burden of obtaining revocation information be shifted to the reliably connected authenticating party?
This technique is called OCSP stapling (RFC 6066). In the above charger example, the charger may present an OCSP response when authenticating at the connected electric car. OCSP stapling is supported for TLS server authentication. It is unfortunately not supported for TLS client authentication, but an application architect may decide to implement it at the application level of communication.
- Can the revocation process be replaced with frequent renewal of short-lived certificates?
Such an approach can relieve the relying (validating) party from accessing the CDP or the OCSP service. Instead, the reliably connected authenticating party renews its certificate with a similar frequency as CRLs would be issued. The effect is similar to that of OCSP stapling. The advantage is that CDP and OCSP services can be avoided, resulting in simpler PKI service infrastructure. The CA must instead maintain an internal blacklist (or whitelist) and refuse certificate renewal for blacklisted or deactivated devices. Renewal is supported by standard certificate management protocols, such as SCEP, CMP or EST. On the other hand, distribution of the renewal service to multiple nodes may be more challenging than with CDP or OCSP. I think this approach is interesting in cases, when the certificates need to be frequently refreshed anyway, e.g. for non-traceability or privacy reasons, or when minimizing code size in the validating device is important.
Root CA revocation
In the classical PKI, the revocation of a root CA is announced via an out-of-band mechanism, such as an independent web page, an official legal announcement or some other publicly available and trusted channel. Responsible vendors and IT administrators are then requested to remove the root CA certificate from trusted certificate stores.
An IOT device, being in the field, typically has no second mechanism to verify the revocation status of root certificates. In this case, the following consideration may be taken:
- Is there a maintenance service in the infrastructure, which can remove revoked root certificates from the trust store of the devices?
This is often the case with cars that communicate via a telematics service with the manufacturer’s backend systems. Maintenance of the trust store can also be linked to the software maintenance process of the device. To secure this type of communication, it is recommended to have an independent PKI system in place, which signs the list of trusted certificates. Otherwise, a compromised root CA will disable validation of the updated trust list.
- The self-announcement of the root CA revocation in the root CA’s own CRL is an unusual, but effective policy. Is this an applicable way for you IoT application?
It is an interesting approach to announce the root CA compromise via the CRL of the root CA itself, which is signed by the compromised key. The advantage is that no second channel or maintenance mechanism is needed, but the device itself can detect root CA compromise. The precondition for the technique is that the CDP service is not compromised. Note also that the standard validation algorithm (RFC 5280) does not support this technique, so here a customized is implementation needed. The advantage is that the regular validation algorithm will yield ‘false’ without using a second channel and additional code.
Conclusion
The classical certification validation algorithm, as defined in RFC 5280, assumes a reliable connection to a central revocation and validation infrastructure, i.e. to a CDP and/or an OCSP service. In the Internet of Things, the connection to such central service may not be as reliable as desired for reliable operation. Also, the connection to central services may be indirect via a gateway or another device. The strict application of the standard validation process may lead to loss of availability and usability. In this blog, we listed a series of possible considerations, which can improve availability and usability of the IOT service. This is due to slight changes in the use of certificate validity (life-long validity, ephemeral certificates), the validation algorithm and to techniques like caching revocation information, OCSP stapling or renewals, and the self-announcement of a root CA compromise. Our conclusion is that the application architect needs to consider the nature of the application and may accordingly chose from several options to optimize the overall performance of the IOT PKI. Our list of considerations and techniques is an invitation for further considerations and may be incomplete.
