Security Appliance Key Generation

Question

For devices like decrypting HTTPS proxies, there is often a built-in mechanism for generating a key-pair and CSR. An admin can then have their in-house authority sign the CSR with a subordinate CA template, and bind the certificate to the CSR in the appliance. In this case, the private key doesn't leave the appliance (and generally cannot be exported).

The same appliances often provide an option to upload an encrypted private key and certificate. In this scenario, the admin would use (for example) OpenSSL to generate the key and CSR on a separate machine, procure the certificate, and then upload them. The advantages in that case are the ability to store the private key for backup, potentially to specify longer key lengths, and add additional information to the CSR that may not be available in the generation wizard on the appliance. This of course assumes a solid key escrow/backup process.

My question is: Assuming there is a hardened, dedicated, offline machine (or "vault") for generating the key and CSR, which is the preferred method? From a security best-practice perspective, should the key be generated on the target appliance using the wizard, or the dedicated "OpenSSL" machine?

Answer 1

Generally you should generate key pairs on the device itself. That way your key stays at the location it is used for, minimizing the possibility to attack. Besides that, you can be certain that the certificate is compatible with the protocol. Certificates follow a well established standardized protocol (X509v3) but there certainly will still be implementation differences, if just because of the complexity of the data structure.

There is generally no need to backup . If the key is lost you can simply regenerate a new set of key pair -> CSR -> certificate. This is because you generally trust a higher level certificate than the root certificate. For a professional setup I would certainly not go for a self signed certificate (a certificate chain of length 1). One reason for distributing a certificate would be a load balancing cluster in which you want to reuse the key / certificate - it that is not taken care for automatically.

If you really require special certificate details (a specific name, key size etc.) then you could import the key / certificate using a PKCS#12 key store or similar. However please remember that preciously few people will actually look at the certificates. You're the person securing the infrastructure, after all.

I'd spend most of the time thinking about accessibility of the certificates and of course the validity period of your certificates. It seems you try and follow good crypto practices for this part of the setup. Time to think about the other parts. Generally time spend splitting hairs means that other parts of the system are forgotten.

Answer 2

I’d second the comments that the method that least exposes the key should be preferred, i.e. generating it on the device.

If you want to be diligent, I’d ask the manufacturer how they generate the random numbers, and ask them for a means of getting a number of random numbers (say couple 100,000s) from the device. You can then subject those random numbers to a randomness test.

Another point to watch out for is if the device implements state of the art encryption & hash methods, and if the manufacturer provides software updates. If either of the two points is negative, you might prefer to generate certs on a different system.