Individual public keys for embedded devices?

Question

I have a hardware device, which collects data. It should then encrypt the data, and send it to a server, which should decrypt the data.

The device is an embedded system which can be programmed only once (during manufacture), and then can no longer be accessed (it can only push data to the server).

The idea I have in mind is to:

• During production (mass production), program each device with a unique public key.
• Have the server associate the corresponding private key with the device's serial number in the server's database.
• On receipt of data, use the serial number to look up the device's private key, and decrypt the message.

I'm guessing this is possible, but is it feasible? Particularly the idea of generating and storing a unique key/pair when the devices are programmed (far too many devices to do this manually), and associating it with the device's serial number in the database?

Or is this a bad idea, and is there a better way of allowing a number of IoT devices to communicate securely with a server?

N.B. I have simplified the above, but the device should actually encrypt the data, transmit it to a phone via bluetooth, and then the phone POSTs it to the server over HTTPS. The phone does not decrypt the data. This means that the device cannot just push the data to the server over HTTPS.

Answer 1

Programming devices with unique keys is pretty common, even for low-end microcontroller. It isn't available for every single device, and it has an impact on the manufacturing costs (every fraction of a second on the assembly line counts), but it's an incremental surcharge, not a whole other price bracket.

However, I don't see the point of programming devices with a unique public key. What's the point? You can burn the same public key in a whole series of devices. The only point of having different public keys would be if the corresponding private keys were on different servers.

The primary reason people put unique keys in devices is to authenticate data coming from the device. This requires a private key in the device, with a server holding all the devices' public keys.

If you want data confidentiality, and you're prepared to have a unique key in each device, you might as well save on computing power and inject a secret key and use symmetric encryption. Under most threat models, if the device's secret key is compromised, the data sent by the device is also compromised anyway, so there's no advantage in using public-key encryption.

For authenticity, on the other hand, don't use symmetric keys if you can possibly avoid it. Here asymmetric cryptography has a major benefit, which is that a breached server is harmless (with respect to data authenticity), since the server only needs to have public keys.

Whatever you do, never use “class keys”: never inject the same secret/private key into a whole class of devices. If you do that, then breaching a single device gives the attacker access to all the devices. If it costs $1000 to breach one device and the expected gain is $1 per device, nobody will do it if breaching that one device only gives access to that device, but it becomes worthwhile if breaching one device gives access to 100000 of them.