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.

  • 2
    What I find most problematic here is that you're trying to treat public keys as though they are secret. There are a number of ways this can go horribly wrong. Feb 21, 2019 at 16:45
  • Oh, I suppose they could all have the same public key, as long as only the server knows the private key, right?
    – Alex
    Feb 21, 2019 at 16:49
  • 1
    right, but in the end it's going to be nearly impossible to verify that the data came from your device and not someone who found the key and is making up data themselves. Feb 21, 2019 at 16:51
  • 2
    I think I actually misread your question. I was thinking "the device cannot just push the data" was meaning that the phone couldn't just make up data and push it to the server since it wouldn't have the device public key. If you're aware that the data can't be verified and you're ok with that then it's fine. Feb 21, 2019 at 17:00
  • 1
    @AndrolGenhald No, I meant that the device cannot directly connect to the server, so it can't just send the data encrypted with the HTTPS protocol. Thank you very much for your help! :)
    – Alex
    Feb 21, 2019 at 17:05

1 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.

  • Thank you for this, it's very helpful. My understanding - and I'm ready to be shouted at for this - was that public keys and private keys are effectively interchangeable mathematically. You encrypt with one, and decrypt with the other. The one used for decryption is designated the private key. That's probably wrong, but don't take it too seriously when I say that the device would contain the private key. I'm not concerned about authenticity, just about encryption (the phone app can provide the authenticity). Is public/private key encryption the way to go, in some form or another?
    – Alex
    Feb 21, 2019 at 23:29
  • @Alex Public keys and private keys are not interchangeable. Read this (or many other across SE, this one was just easiest for me to find). In your use case, public-key encryption is probably the way to go, and this does not benefit from key diversification at all since the same entity would hold all the private keys. It would benefit from the ability to broadcast new public keys in case the device is compromised (in a way that must be authenticated!), so if you have any budget for improvement, focus on that. Feb 22, 2019 at 9:32
  • thank you, that link was very helpful. From what I understood, I could in principle store a public key on the device (the same one one each device), use it to encrypt the message, and then decrypt with the public key on the server? I understand that this does not authenticate the message, but I think that that's fine for my purposes.
    – Alex
    Feb 22, 2019 at 11:09
  • 1
    @Alex Right. That's secure (given that you don't care about authenticity) as long as the server isn't breached. Feb 22, 2019 at 11:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .