4 ms·

There isn't a section in the book that covers IoT specifically. Most of the book is relevant to the topic because it provides a generic foundation that's necess

by ivanr 5y ago

There isn't a section in the book that covers IoT specifically. Most of the book is relevant to the topic because it provides a generic foundation that's necessary for more specific use cases. I feel that in many situations the solution for IoT PKI is to find a good vendor who will support you, and there's plenty of those around to choose from. If you have a moment, I would appreciate if you could share some more specific questions, and perhaps your use cases. That will help me understand if it's something I can cover in a future update. That said, the book is already quite big at 500 pages.

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 ago
  If 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 ago
    Thanks!

by ivanr 5y ago

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 ago
If 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 ago
  Thanks!