3

I'm currently in the process of designing the security model for an IoT product my company is developing.

The device will be connected to the internet via WiFi and shall communicate with our company's server only.

  • The communication will be done via HTTPS
  • During physical product assembly, the server's SSL fingerprint will be stored on the device. The device uses this fingerprint to make sure that it actually talks to its "home" server everytime it establishes a connection

A problem with this approach arises as soon as the server's SSL certificate changes. All devices in the field will then no longer be able to connect to the server due to a failing fingerprint check.

A partial solution would be to create a time period in which the server would distribute its new fingerprint to all connected devices, along with the exact time it becomes valid. The devices could store the new key and use it starting from the advertised date. But this doesn't solve the problem for devices which are not online during the fingerprint distribution period.

Is there any potential solution to this problem which I might have overlooked? What is "the right way" to do such a thing? (I can't be the first one to do it, can I?)

Improve this question
2
  • I am not an expert in this field, but this sounds like self-signed ssl certificate I believe that for security you should not use self-signed certificates
    – vakus
    Commented Apr 10, 2017 at 15:42
  • 2
    Roll out PKI solution using X509 certificates. This allows you have a trusted CA that remains static and use it to issue and revoke certificates. For your IoT devices, anything signed by your CA can be trusted. I also suggest you investigate rolling out complete setup with mutual authentication, where each device is issued a unique certificate. This will also allow you authenticate IoT devices when they connect to your server.
    – Kirill Sinitski
    Commented Apr 10, 2017 at 15:42

2 Answers 2

Reset to default
4

This sounds like you haven't created an update mechanism for the product that you are releasing. This is of significant more concern than updating signatures for pinned certificates. How will the product be updated in the event security improvements need to be made or bugs need to be fixed?

The product should be released with an initial signature for all TLS connections. The update mechanism should be capable of pulling down an updated firmware image and deploying it to the device. The device should only request these updates over a TLS encrypted channel. The server side update deployment code should sign all firmware updates with a private key. The public key used for signature validation should be embedded in the firmware when the device is released. This way you are able to update the TLS signatures using the update mechanism as well as the public keys that are used for firmware image validation.

Make sure that you update the TLS signature values and the public keys used for image validation before they expire, this may mean you have a 3 month update period prior to the expiration of either. This period should be defined based off of how long it generally takes users to update the product; you want to give everyone significant time to update their device and a method to perform a manual firmware download/update in the event these values/keys are not updated before they expire.

Improve this answer
2
  • Thank you for your suggestions! I do actually have the update mechanism in place - it is very close to what you describe in your answer. Sorry if my wording was misleading. Could you elaborate on the difference between checking the server's SSL fingerprint and embedding the server's public key in the device? Is there any difference at all (from a security point of view)?
    – Oromis
    Commented Apr 10, 2017 at 19:53
  • Validating the certificates fingerprint is done to ensure that the application is communicating with the proper remote system over TLS and prevents MiTM. The embedded public key is used to validate the signature that is sent alongside the firmware updates. This signature is generated over the firmware update itself. This validation occurs to ensure someone didn't modify the firmware update.
    – user144242
    Commented Apr 11, 2017 at 17:50
1

Why not using on your server a certificate trusted by a certificate authorities, so your IoTs can use the existing PKI mechanisms to check for revocations, and you can change the certificate of your server anytime you want.

Improve this answer
2
  • I don't want to rely on the PKI alone. See owasp.org/index.php/Certificate_and_Public_Key_Pinning for a discussion why pinning the server certificate is a reasonable security policy.
    – Oromis
    Commented Apr 11, 2017 at 14:56
  • You can use HPKP for pinning too. And if your HPKP headers brick the device, after the max-age, the HPKP pin will be deleted and it will fallback to only the PKI check. Easier to avoid mistakes, easier to rotate keys.
    – Tom
    Commented Apr 11, 2017 at 15:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .