3

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?

Larry Martin
  • 33
  • 3
  • Is the Netburner device capable of making GET requests to a web server over HTTPS? – mti2935 Jun 06 '22 at 14:50
  • @mti: sure. Are you suggesting just HTTP GET the DER file and don't worry about any more network protocol? – Larry Martin Jun 06 '22 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 06 '22 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? – Larry Martin Jun 06 '22 at 16:04
  • I'm not sure why you feel that this solution uses a proprietary protocol. TLS (over HTTPS) is an open protocol that provides secrecy, integrity, and authenticity. So, the protocol is no secret. But, even through the attacker knows that TLS/HTTPS is being used, he cannot (easily) break it. This is the idea behind [Kerchoff's Principle](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle). – mti2935 Jun 06 '22 at 16:13
  • 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 06 '22 at 16:22
  • @mti: Ok, thank you. You answered my question. I still want to know what network protocols are used by commercial HSM and keystore systems, but I guess that is another question. If you publish your comment as an answer I will accept it. – Larry Martin Jun 06 '22 at 17:20
  • I'm glad this helped. I really don't care all that much about upvotes, so there is no need to re-post all of this in an answer, but thanks anyway. My final thought is that if there is some way you can generate the keypairs on the Netburner, then that would be ideal. I understand that RSA key generation on the Netburner is too slow to do in real time for your production application, but maybe there is some way that a batch of keypairs can be generated on the device in advance and stored, so that the keys are already on the device when needed? – mti2935 Jun 06 '22 at 19:23
  • If the _PC based server next to the machine_ is the only device that's connected to the machine and the PC based server isn't connected to another system, then this is a closed system. The protocol used to transfer from the server to the machine is less of a concern. Instead, you should be concerned with topics such as the physical security of the system, access control, and the processes and procedures you define to ensure that, for example, the private key is securely deleted from the server as soon as the machine has confirmed it's been successfully received. – garethTheRed Jun 06 '22 at 20:06

1 Answers1

2

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.

CBHacking
  • 40,303
  • 3
  • 74
  • 98