Extracting X.509 certificates from devices
Article By : Wilfred Nilsen
X.509 certificates provide strong authentication, but in a practical set-up, other mechanisms such as username/password can be just as secure.
« Previously: IoT security: Why X.509 is not always the best choice
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.
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 set-up 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 set-up, 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 set-up, 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 set up 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 nonprintable 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.
Summary
Security is complex and requires manufacturers building IoT devices to carefully analyse 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.
« Previously: IoT security: Why X.509 is not always the best choice