1
Microcontrollers / Re: How would you do a heating controller, IOT client, securely?
« Last post by tellurium on Today at 06:20:44 am »Thanks. Yeah, I saw those - using https and talking to a web server. I was wondering if you could share any detail about this mechanism. How will you authenticate with the server and/or have the server authenticate with the device? Other than encrypting updates will you do any additional authentication or validation of them? I guess you'll have storage for at least 2 firmware images and a roll-back mechanism for failed updates. Any other specific security related functionality?
I ask because I have a similar project for a client who a) doesn't want to spend money on security and b) has an existing web infrastructure to which he is adding the device I am working on for him so I have to follow an existing web API. It's easy to say stuff like, "well this device will be turned off most of the time" and there's only going to be hundreds or thousands of them in the field so no-one will care so we don't have to worry about the attacks zilp has detailed but I'm still nervous, if only for my reputation, because I know how this client will react if the device is ever compromised (he'll blame everyone but himself).
One way I've described earlier:
DEVICE <---- Websocket over TLS ---> BACKEND <---- HTTPS -----> OPERATOR
The backed would terminate connections from devices. Devices can be authenticated either:
a) using TLS certificates - so-called two-way TLS. That's the way how AWS IoT authenticates devices
b) using auth tokens, or password strings. Both device and backend would store those, and device can send either a token ot its hash in the WS handshake
For users / administrators, the backed would provide a usual HTTP REST API. Usual auth schemas are user/pass login, or Oauth.
Now, OPERATOR can authenticate with BACKEND and send REST API calls to list devices, see their status, change their config, update them, etc.