2

I have multiple IoT devices that will be connected to a cloud based platform in order to control these devices (IoT node running baremetal arm SoC).

These IoT nodes would be deployed and, during configuration, they would create a secure communication channel with backend generating a synmmetric key (one symmetric key per node). Once this symmetric key is generated and secure channel is created, there should not be a problem.

In order to avoid MITM attacks during configuration I would like to understand the implication and risks of using Station-to-Station protocol (STS).

This requires certificates for authentication.

Before key exchange using Diffie-Hellman, both endpoints should force to authenticate, this implies generating certificates for both endpoints. For this specific scenario, the option of generating a certificate signed by a CA per IoT for a unique initial operation during IoT device configuration seems too expensive for the application (certificate management, pay for certificate loading services).

One alternative regarding certificate is the generation of a self-signed certificate per IoT device. This certificate will only be used during IoT device deployment, so is it really useful for this specific case?

  • How then would the CA trust the self signed certificate? I think you are falling into a chicken and egg problem – usr-local-ΕΨΗΕΛΩΝ May 8 '20 at 11:58
  • @usr-local-ΕΨΗΕΛΩΝ thank you very much. That´s the reason of my question. I really don´t understand the utility of having a self-signed certificate... – LazyTurtle May 8 '20 at 11:59
  • I linked that Q&A because I see similarities. Anyway int the other answer I recommended to work on the device while still in the factory – usr-local-ΕΨΗΕΛΩΝ May 8 '20 at 18:01
1

Considering your self-signed certificate is unique per device (which is absolutely should be), then yes there's massive advantage to using these as opposed to plain text or a shared certificate. This raises the effort required to exploit the process which is the purpose of security features. Yes it can be defeated locally, but not in a repeatable way and certainly not against all deployed devices.

You could consider using certificate pinning on your code and validating the server connection in that way. There are issues with this due to firmware images being infrequently updated and servers invariably changing.

The effective solution to this is having factory provisioning of unique signed certificates I'm afraid. You may get away with using a self-signed CA if you also apply certificate pinning.

This is a huge and complex field and I am glad you are thinking of these implications. I work with a couple of absolute experts in the field and we get to see the bad, the ugly and the "don't even want to touch that".

Also plex did amazing things around using signed TLS certs on internal deployments. Yeah it's a tangent but pretty interesting: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

  • just spotted @usr-local-ΕΨΗΕΛΩΝ wrote something along the same lines on the linked post. should have read it before I wrote this one :) – Pedro May 8 '20 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.