3 ms·
My main usecase is for remote meter reading. The plan so far is to install self signed certificates at manufacturing and then to update them periodically with O
by coupdejarnac 5y ago
My main usecase is for remote meter reading. The plan so far is to install self signed certificates at manufacturing and then to update them periodically with OTA. OTAs will be fetched via https. The device will communicate with our backend via mqtt with tls, but not using mutual tls. I suppose I'm asking if this is a suitable approach for deploying a device that mostly has one direction communication.
I suppose my biggest gripe is that it has been hard to find sources of best practices. Almost everything I find is amateurish/not designed to scale or white papers designed to sell services. Or when I encounter best practices, they are too vague to be actionable.
- ivanr 5y agoIf you don't want to do mutual authentication then may not need to do anything special. In theory, your servers can get a regular certificate from a public CA. You would get better security with a private CA, ensuring that your devices submit data only to you and not to an impersonator. Without mutual authentication you won't be able to authenticate the devices themselves. Perhaps you intend to have a different mechanism, perhaps sign the messages? I feel that signing the messages would provide better security guarantees as the signatures will accompany the data. I think the most important aspect to get right is to have the ability to update the root material. No matter what CAs you end up using, their roots will eventually expire and will need to be replaced. Clearly, you don't want to lose the root material as that would be catastrophic. Using two separately managed roots would probably be a good idea. AWS and Google have private CA services, and EJBCA is also worth exploring, for example: https://doc.primekey.com/ejbca/solution-areas/iot-and-device-identities https://doc.primekey.com/ejbca/solution-areas/iot-and-device...
- coupdejarnac 5y agoThanks!