0

I am using AWS IoT with X.509 self-signed certificates for authentication. To communicate with the cloud I use MQTT.

On my device side, I have a device certificate ( deviceCert.crt ) and the device certificate private key ( deviceCert.key ) , and also the root CA certificate from Amazon (root-CA.crt)

The device certificate is of course already registered on the AWS cloud.

I realize when using an MQTT client on the device that it requires the device to contain both the device certificate and the device private key during authentication.

Why isn't the private key enough to have on the device? My guess was that the device would sign something with the device private key , and on the server end, it would use the public key from the device certificate (already stored there) to verify the signature.

Or does the device send the device certificate to the server and the server compares it with the one it has stored?

What happens exactly here?

Engineer999
  • 257
  • 1
  • 8
  • 2
    Possible duplicate of [help understanding client certificate verification](https://security.stackexchange.com/questions/25551/help-understanding-client-certificate-verification) or [SSL Client Certificate authentication](https://security.stackexchange.com/q/40016/151903) – AndrolGenhald Feb 27 '19 at 15:28
  • tl;dr the public key for every certificate isn't stored on the server. The certificate proves that the private key is the one trusted by the server, else all you're doing is proving that you own some random private key. – AndrolGenhald Feb 27 '19 at 15:30

1 Answers1

1

Two things are happening here. One is the identification, and the other is authentication.

Identification: your IoT device states who it is. This is basically a claim. This is done by sending over the certificate. The server makes sure it is an identity that actually exists by checking if the certificate was signed by a trusted root (probably one of Amazon's own). Once the server confirms the identity exists it wants proof in the form of authentication.

Authentication: your device proves it is who it claims to be by signing some data that can be verified by the public key contained in the certificate it presented earlier.

Onto your questions.

Why isn't the private key enough to have on the device?

If only this is done, the server has no way of knowing which public key to use for verification. It has to look up the public key somehow. There are various ways to do this, for instance, SSH can work without certificates. In TLS, it works by presenting a client certificate to the server, which contains this public key.

Or does the device send the device certificate to the server and the server compares it with the one it has stored?

Yes, the device sends over the certificate, but the server doesn't compare it to a stored version. It checks the trust chain.

You can check out the full flow in Wireshark. I built a sample app with certificate authentication. It works over HTTPS but the process is the same on the TLS level. Here is the post accompanying that repository.

Daniel Szpisjak
  • 1,825
  • 10
  • 19