6

I am working on a project where I have a sensor connected to a WIFI module. Whenever the sensor is triggered, it will send a message to the cloud via MQTT. Eventually I tens of thousands of these devices deployed everywhere. These sensors will rarely be triggered, maybe only once a week randomly.

What is the best method for provisioning these devices? Assuming I have 10K users each with 1 sensor. Do I need to setup 10K MQTT user accounts or just 1 account and have 10K topics? I will want to be able to know which device has been triggered and also send back information to the device.

Users will use a mobile app to setup the IOT device. From the app, they can set the WiFi SSID and password for the IOT device to connect to their home WiFi. I presume users will also need to register for an account with our platform after which a MQTT server address, port number, user id and password will be created for them on the app and forwarded to the IOT device for connecting to the MQTT server.

How can this process of creating MQTT accounts be automated? Is there a way to do this on any of the Cloud IOT services out there (eg. AWS, Google Cloud, Microsoft Azure, IBM etc etc).

Improve this question
2
  • 1
    you could use something as simple as one MQTT account and one topic for all of the devices and the published data containing a device serial number
    – jsotola
    Apr 7, 2020 at 7:54
  • But that means once the account details are compromised then you need to change the credentials on all the devices while they are in the field (this is a none trivial task)
    – hardillb
    Apr 7, 2020 at 8:35

1 Answer 1

Reset to default
5

The cloud IoT providers all tend to use per device certificates to identify each device individually.

You have 2 choices here:

  1. You flash the certificate to the device at manufacturing time.
  2. You use the platforms HTTP interfaces to provision the certificate to the device at the point it is connected to the wifi and registered to a user.

Both of these approaches work well, but the first means you need to flash a unique image to each device which can add overhead to the manufacturing.

A certificate per device means you can revoke that certificate should it become compromised.

One downside of using certificates is that the hardware you choose probably needs to support a secure element to store the private key in so it can not be easily compromised which may add cost.

The devices should publish to topics based on either the CN of the certificate or the serial number and you can then associate that with the users account.

Improve this answer
4
  • Thanks @hardillb. I am actually using the ESP32 wifi module for this application. I think it supports AES-128. Would that be suitable for encrypting the private key?
    – Kian
    Apr 7, 2020 at 9:04
  • But where would you keep the encryption key used by the AES?
    – hardillb
    Apr 7, 2020 at 9:05
  • I am beginning to understand more about how the certificates work. Am trying it out using AWS. I was reading some examples online and one article mentioned: "Attaching the certificates in the code is a very bad practice, it compromises the security of your AWS account" So I think I sort of understand what you mean now by having a secure element to store the keys. I can't just store them in the microcontroller's flash right? If that is the case, you mentioned about having a secure element to store the key, do you mean dedicated hardware? If so, do you have any recommendations?
    – Kian
    Apr 10, 2020 at 7:52
  • A bit of googling suggests that the ESP32 has support for secure boot and encrypted flash with the AES key for the flash stored in the eFuse (a type of secure element) so you should be able to store the cert/keys on the encrypted flash and have it be relatively secure.
    – hardillb
    Apr 10, 2020 at 11:10

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.