Why Passwords are not equivalent to X.509 Certificates for IoT Devices?
A Password is just a string of characters. It does not provide any information about the user - the User <-> Password relation is stored in some external system, it is not “embedded” into the password itself.
A Password does not have any information about the expiry date. Once again, the expiry date is stored in some external system, it is not “embedded” into the password itself.
There are several ways to crack passwords. A strong password policy can mitigate this threat, but that policy needs to be enforced by some external system.
An X.509 Certificate provides the User <-> Certificate relation stored in the Subject field (Subject: CN=gg-thing-0001).
An X.509 Certificate has “embedded” information about the expiry date:
|
|
An X.509 Certificate includes the Public Key while the corresponding Private Key is securely stored on the IoT Device. The X.509 Certificate does not include the Private Key!
To impersonate the certificate owner, the attacker has to “guess” the Private Key corresponding to the Public Key embedded into X.509 Certificate - that is typically way more difficult than cracking passwords.
That is why I strongly recommend using X.509 Certificates for IoT Devices instead of the “username/password” combination.
Update: I received many questions regarding this topic. I included the most interesting questions and my answers with additional comments below. Feel free to reach out to me in case of any further questions!
Additional comments:
Certificates management is a very important functionality in any IoT solution. At minimum it should cover:
- initial deployment of a dedicated Certificate onto every Device
- rotation of Certificates that are about to expire
- revocation of Certificates
There are multiple ways to automate the initial deployment of a dedicated Certificate onto every Device. I created a simplified decision matrix to help you identify a suitable approach based on your needs:
https://www.thingrex.com/fleet_strategic_options/
You asked questions regarding the rotation of Certificates.
Q: Certificate rotation brings additional complexity to the project.
A: If you decide to use passwords, you should implement a process to change (rotate) them. Using static passwords without a mechanism to change them is a security vulnerability.
The X.509 Certificate rotation process is crucial to keep the IoT environment secure. It introduces some additional complexity but so does the “password rotation” process.
I described a sample, automated solution on the official AWS Blog: https://aws.amazon.com/blogs/iot/how-to-manage-iot-device-certificate-rotation-using-aws-iot/
AWS IoT Device Defender triggers the rotation process for certificates that are going to be expired within 30 days. I am aware that 30 days rotation window might not be applicable for every use case - in that case implementation of custom logic is required.
Q: CSR (Certificate Signing Request) file has to travel from a Device to the CA (Certificates Authority).
A: Generating the Certificate Signing Request at the IoT Device is the solution I recommend. This way the Private Key is securely stored at the Device during the Certificate rotation process. CSR does not contain any confidential information and maintains the cryptographic relation with the corresponding Private Key. The Certificate Authority (CA) can generate an X.509 Certificate based on the CSR and send that Certificate back to the IoT Device. It is worth remembering that the X.509 Certificate is not enough to impersonate the IoT Device - only the pair Private Key and Certificate can be used as the Proof of Identity.
Q: Do my organization needs to have a CA running in order to manage all these issued certificates?
A: There is no need for an organization to manage Certificate Authority (CA) infrastructure, you can leverage the AWS-managed CA to sign certificates.
If you prefer to manage the Certificate Authority externally to AWS you can do so. In that case, you need to register your CA with AWS IoT. This way you have full control over the Root of Trust (CA) and AWS IoT Core will recognize certificates signed by that CA.
Q: How will an IoT Device renew the certificate once it expires?
A: A device can not communicate with AWS IoT Core using an expired certificate so you need to provide a “backup connectivity” solution. The specific architecture depends on the actual business case.
Q: How to manage compromised IoT Devices?
A: To handle potentially compromised Devices, I typically implement an automated process that deactivates Certificates used by those Devices - this way I stop them from interacting with my system. If I confirm that a specific Device was not compromised, I can activate its Certificate in the AWS IoT Core so it can resume communication with my system.
Q: I can not use the HSM (Hardware Security Module), does it make sense to use Private Keys and Certificates in that case?
A: Hardware Security Module (HSM) contains a dedicated chip that prevents tampering and provides a secure store of Private Keys.
In my opinion, usage of Private Keys and Certificates without the HSM is still a better approach than username/password. You can always revoke the Certificate in case the corresponding Private Key gets extracted by the attacker.
Content of an X.509 Certificate can be displayed using the openssl command:
|
|
Output:
|
|
