I'm building an embedded device that I plan on distributing. Periodically the device will poll my server to check for updates and commands. I'd like the device to verify that any messages(JSON strings parsed by a client written in Go) and updates are actually from me.

My plan is to use use Go's crypto/ecdsa library to generate a private/public key pair for each device, store the public key on the embedded device, and sign every message with the private key. The device will then verify any received messages with its public key.

From what I've learned so far it seems that the RNG (on the server that's signing the messages) could be a potential weak spot. Are there any other obvious flaws/issues I'm missing?

  • 1
    $\begingroup$ Why would you need a new keypair for each device? It seems more sensible to have only one keypair (i.e. the keypair of your server) and embed the public ky into the devices. As the devices neither need to generate keys, nor produce signatures, their RNG is not a problem. $\endgroup$
    – Maeher
    Aug 11, 2013 at 6:04
  • $\begingroup$ @Maeher I was thinking along the lines of if an attacker were able to reconstruct/steal one, or a few, private keys, he wouldn't be able to spoof messages to all of the devices. I also edited my question to make it clear I'm talking about the RNG on the server that's signing messages , not on the devices. $\endgroup$ Aug 11, 2013 at 6:16
  • 1
    $\begingroup$ I'd use a deterministic variant of ECDSA. Perhaps Ed25519, perhaps Thomas Pornin's proposal and perhaps a simple hash of private key and message hash. $\endgroup$ Aug 11, 2013 at 8:58

1 Answer 1


Since you asked in general "Are there any other obvious flaws/issues I'm missing", I would recommend that you would take a critical look at the whole update process flow. I would not consider the quality of the PRNG at your server as an obvious weak point, as long as it is reasonably strong, since on servers you have quite a bit of choice of reasonably good routines to generate a fair PRN (note that it is quite acceptable to generate a pair of good PGP keys on a regular server or client machines).

Critical review of the update process as a whole should consider the following, by no means an exhaustive, list:

  1. A server that is opened to the public internet usually exhibits a fairly wide attack surface - OS, apps, services, open ports etc. If I were an attacker, I would first try to penetrate your server, and use your private key in there to send malicious update commands out.
  2. You need to secure the environment of your embedded processor. I assume that you discount the possibility of direct physical acess to the embedded system (otherwise all security bets are off), but you do need to think about other issues like flooding the device's comm channel with badely signed messages generated by an attacker, thus causing DOS on your embedded system. You may possibly mitigate this with a watchdog timer that will kill the update loop after a set time.
  3. I concur with maeher - questioning the need to generate a key pair for each device. This will be a nighmare of a management vis a vis the chance of private key compromise: How would you remotely identify the client in order to know which private key to use for the signature going to that particular client? would you send a bunch of records for each client to test them all in order to find the one recognized sig in them? would you first send a client ID in the clear and respond with the appropriate signed message? I would also, as maeher proposed, recommend one key pair with all clients will have the same public key.
    If you are really concerned about someone stealing your private keys, you may want to consider having all the keys expired after each update and regenerating a new pair for the next update cycle (the new pair will be signed by the old one before expiring). This is not as strong as a unique pair for each client, but certainly more manageable.

When you consider the above, it does make a difference if your embedded app is just an industrial controller, or a system whose failure due to a rogue update will cause a regional catastrophe.

  • $\begingroup$ You're probably right that using one key pair is probably worth the trade off. To your first point, I had thought about the vulnerability of the server, and I've been thinking about keeping the private key on a local machine, then signing any updates/messages before I push them to the server (this should be fairly infrequent). $\endgroup$ Aug 11, 2013 at 21:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.