First asked on StackOverflow and referred to this board, here:

I have an embedded system (Netburner 5441x) that encodes public-private RSA keypairs into devices. I have ported OpenSSL into the system but the embedded processor cannot make RSA keypairs fast enough for production goals. So the next logical step is to have the embedded system get keys from a PC based server next to the machine, rather than make them on board.

What is the correct protocol for key transfer between the two nodes? Is there a network protocol widely used by keystores or HSMs? I've read most of the PKCS#N documents and it looks like it's all about object formats, but it's a lot of information and I may have missed something. Similarly, posts here mention X.509 but that looks to me like a certificate format and not a network protocol.

Should I just open a secure socket and send passphrase protected DER objects with no other framing?

Is there a standard for this kind of thing?

  • Is the Netburner device capable of making GET requests to a web server over HTTPS?
    – mti2935
    Jun 6, 2022 at 14:50
  • @mti: sure. Are you suggesting just HTTP GET the DER file and don't worry about any more network protocol? Jun 6, 2022 at 15:25
  • 2
    Yes, you read my mind. Modern TLS (e.g. TLS 1.2 or 1.3) over HTTPS is about as good as it gets when it comes to a secure protocol between a client and a server. It seems like you ought to be able to setup a web server that generates the key pairs, then have the Netburner device request the key pairs from the web server using TLS over HTTPS through a simple API. You just need a way for the Netburner to authenticate the server (this can be done using a CA signed certificate or a self-signed certificate pinned by the netburner), and the server should authenticate the client as well.
    – mti2935
    Jun 6, 2022 at 15:46
  • That's a great suggestion and gives me permission to make up a proprietary protocol. But the OP asks for the "right way." If I were to buy a commercial keystore or HSM, would it do something proprietary like this that's known only to client software controlled by the vendor, or would it follow some standard that's open to other clients? If the latter, what is that standard? Jun 6, 2022 at 16:04
  • 1
    WRT the 'right way' to do this - I'm not sure there is a right way. Generally, the idea of moving private keys around is shunned upon, and therefore I don't think you'll find a 'standard' way of doing this. Most HSM's do not provide a way to export private keys for this reason. But, I read your post on SO, and I understand you have a unique use case here. I don't love the idea of moving private keys over the network, but if you have no other option, then using a tried-and-true secure protocol like TLS over HTTPS would be my recommendation.
    – mti2935
    Jun 6, 2022 at 16:22

1 Answer 1


As a general rule, you don't. Private keys aren't supposed to leave the device where they're generated. If RSA keys are too expensive to compute, you might be able to make it work with elliptic curve / Ed25519 keys, assuming there's a suitable way to use them for your use case, or perhaps use more (or more powerful) devices to compute them.

However, if you must, there are a few options. One is to use a physical connection, such as USB or a direct network link, to another device (possibly special-purpose, or possibly a full PC). This provides the greatest protection against remote attacks, and local / physical attacks on either device can be handled together with the same security measures.

Another option is trust in modern secure network protocols. SSH (use the latest version and modern ciphers, and have trusted keys on both ends, you must reject unrecognized keys) or TLS (ideally version 1.3 or whatever is newest, ideally with mutual authentication, and ideally using pinned public keys / certificates) are both very secure. There's also IPSec, which I know less about but I believe is generally considered secure, and various other protocols. Once configured, this could be as simple as an HTTPS GET request. However, secure protocol implementations are very tricky things - there have been many vulnerabilities found in all the popular ones - even when the protocols and primitives are themselves fine. It's definitely better to avoid network exposure entirely if possible.

You must log in to answer this question.

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