IoT security: when X.509 certificate authentication may not work
Some time ago, a DEFCON paper uncovered a huge amount of unprotected MQTT brokers on the Internet. The unprotected MQTT brokers -- in combination with the openness in the MQTT protocol where one can use wildcard subscriptions and subscribe to all messages published via the broker -- makes this ordeal a major security concern.
There have been discussions on the Internet regarding the DEFCON paper, where some IoT service providers made a point in that MQTT must be used in combination with X.509 certificate authentication. Also, some IoT service providers promote or even force one into using client-side X.509 certificate authentication. However, client-side X.509 certificate authentication may not always be the best choice. In this article we will explore some of the issues related to using client-side X.509 certificate authentication and consider when other authentication types, such as username/password, may be a better choice.
What is X.509 certificate authentication?
In cryptography, X.509 is an important standard for a public key infrastructure (PKI) to manage digital certificates and their associated public key for asymmetric encryption (public-key encryption). X.509 is a key component in the Transport Layer Security (TLS/SSL) protocol -- a security layer used to secure many IoT protocols.
The TLS protocol requires the server to have an X.509 certificate; however, an X.509 certificate is optional for the client. The server certificate enables the client to authenticate the server and enables the TLS protocol to setup a secure (encrypted) communication channel with the server. A client certificate, in addition, enables the server to authenticate the client. This is known as mutual authentication, where the client authenticates the server (required) and the server authenticates the client (optional). (For an introduction to X.509 certificate authentication, see Real Time Logic's Certificate Management for Embedded Systems whitepaper.)
Practical X.509 certificate considerations
From an authentication perspective, X.509 certificates undeniably make a solution more secure, However, using X.509 certificate authentication greatly complicates a design if client-side certificates are required.
As was mentioned above, a client-side certificate enables the server to authenticate the client and can be used by the server to uniquely identify each client connected to an IoT solution. Creating a unique X.509 Certificate and the corresponding private key for each device greatly increases the complexity in the manufacturing process. When these certificates are created, they must be signed by a Certificate Authority (CA). To automate the manufacturing process, the CA certificate and the corresponding CA certificate's private key must be available during the manufacturing process. Exposing the CA certificate's private key to anyone outside your organization is a major security issue. Therefore, the CA certificate's private key should be locked up in a vault with only specified individuals having access to it.
A server must implement what is known as a certificate revocation list since it may be possible for a hacker to extract the certificate/private key pair from a device and to use this key to compromise an IoT solution. The revocation list includes the certificate's serial number of all certificates that have been exploited. For this to work, you must first find a way to detect non-conforming devices connecting to your IoT solution and then add the certificate's serial number to the revocation list. A non-conforming device could be one where a hacker that has managed to extract an X.509 certificate and the corresponding private key from a device and is then using this certificate for gaining access to the IoT solution. Such detection is very difficult.
In addition, X.509 certificates include an expiration date making it mandatory for IoT solutions to update the certificate from time to time.
As you can see, using client-side X.509 certificate authentication from an administrative perspective may be very difficult to deploy. This is likely the reason most existing solutions are based on using the same X.509 certificate/private key in all devices. SEC consult, an information security advisor, has published two reports: the first shows how industry-wide HTTPS certificate and SSH key reuse endangers millions of devices worldwide, while an updated report only nine months later revealed that such reuse had increased by 40%, further illustrating the growth in incorrect X.509 certificate authentication usage.
Extracting X.509 certificates and private keys from devices
As was previously noted, a hacker who manages to extract the X.509 certificate/private key pair from a device can use the certificate/key for either eavesdropping on the communication or for exploiting an IoT solution. A unique certificate per device makes it possible to disable the exploited certificate/key by using a revocation list; however, this requires that the IoT solution can detect the exploitation in the first place. A solution that uses the same certificate/key in all devices has lost all integrity if someone manages to extract it from any single device.
The complexity associated with extracting the certificate/key from a device greatly depends on the type of device and the components used in that device. A device based on a high-level operating system where the certificate/key is stored in a file system on an external flash memory module makes it much easier for a hacker to extract than a certificate/key for a device using internal microcontroller flash memory and where the JTAG fuse has been blown.
A device that stores any type of credentials, including X.509 certificate/private key, must have some mechanism in place for making it difficult to extract those credentials. (Download Real Time Logic's Securing Edge Nodes whitepaper for more information on securing your device.)
Alternatives to using client-side X.509 certificates
Proponents of client-side certificates will tell you that X.509 certificates provide a very strong authentication since the credentials cannot be forged. Although this is correct, in a practical setup other mechanisms such as username/password can be just as secure.
An IoT solution must be resilient to brute force authentication attacks; i.e., attacks based on trial-and-error, typically by attempting to login using a database of common passwords.
Brute force authentication attacks are impossible to perform when using client-side certificates since the attacker cannot forge the signer of the client-side certificate. However, in a practical setup, a server can easily detect recurring login attempts. Unlike a human being, a device would not provide incorrect credentials. If it does so, it will be a hacking attempt. A server can immediately detect this condition, send an alert to an operator, and permanently block the IP address. For this reason, in a practical setup, where the server side device authentication is designed intelligently, a standard username/password pair will be sufficient and will, in practice, provide the same authentication strength as client side X.509 certificates.
Note that we still recommend the use of TLS and an X.509 certificate for authenticating the server. This construction makes sure that we setup a trusted communication path between a client and the server.
Storing a username/password pair in a device makes manufacturing much easier. It also makes administration of the server much easier since you do not need to deal with revocation lists -- you can simply use a standard username/password database. However, more secure username/password pairs will be based on non printable characters -- so-called "binary credentials." For this reason, the IoT protocol should support the use of binary credentials.
The use of certificate authentication schemes other than client-side X.509 authentication becomes virtually mandatory in a mixed environment where web applications are used in combination with headless devices. An IoT solution may be designed such that web application can control devices in real time via an online server -- a so-called "broker." In such an environment, it is simply not practical to use client-side X.509 certificates since the client certificate would have to be installed in the browser.
An example of a mixed IoT solution is depicted in Real Time Logic's security for the SMQ protocol. The SMQ protocol is an IoT protocol designed specifically for being used securely in a mixed environment, even when authentication is not used or not used for all devices connected. Some application types are just too impractical to use when authentication is required to make the IoT protocol used in the IoT solution secure.
Security is complex and requires manufacturers building IoT devices to carefully analyze all software/hardware components in the solution. A recommendation for systems based on open source software or hardware is to use third-party security advisory consultants and have the security consultant perform a full penetration test of the complete product. Solutions based on purchased IoT protocols/products have the benefit of getting third-party security advisory via the support line.
Security should be at the forefront of the development process and not an afterthought. Consult with your preferred IoT solution/protocol provider prior to designing the hardware. We have seen many designs where security has been an afterthought, by which time it can be too late for us to provide good advisory on how to make the solution more secure.