IoT security: Why X.509 is not always the best choice
Article By : Wilfred Nilsen
X.509 certificates make a solution more secure, but using it greatly complicates a design if client-side certificates are required.
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).
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.
Next: Extracting X.509 certificates from devices »
