4 ms·
Why not just use self-signed certificates for those sorts of devices with a 50 year expiry or something like that? Surely setting up your CA or even embedding a
by KronisLV 5y ago
Why not just use self-signed certificates for those sorts of devices with a 50 year expiry or something like that? Surely setting up your CA or even embedding a single long term certificate (or chain) within your own device isn't too much a hassle, right?
Realistically, your toaster, fridge or lightbulbs will only talk to a particular set of hosts within the vendor's walled garden, so there's no need to have a trust chain for the entirety of the Internet anyways. Provided that your IoT devices aren't doing anything shady otherwise. Assuming that you even need or want IoT devices.
- lultimouomo 5y agoI am deploying a system where IoT devices first contact a bootstrap endpoint, authenticated by a private CA whose root cert is hardcoded in the device firmware. The bootstrap endpoint communicates the URL and CA root cert of the actual web services. This allows us to have the services themselves implemented as serverless functions using the cloud provider HTTPS/MQTT facilities. Does anyone see potential issues with that?
- konschubert 5y agoThe only issue is if the private key of your root Cert gets leaked. Then you won't have a way to issue a new one to your device.
- teddyh 5y agoEven if the root cert is hardcoded, the root cert might still have an expiration date, and the firmware code might still check that.
- lultimouomo 5y agoGood point. When this happens I'll be dead though, and so will be those devices. If we both turn out to be immortal I'll need to provide a firmware upgrade with a new CA root, possibly 10 years or so ahead of the expiration so every device has a chance to auto-upgrade.
- teddyh 5y agoIt could quite possibly be easy to simply disable or remove the expiration check from the firmware code. My point was only that it’s an issue that one might not immediately think of.