Generating deterministic X.509 certificates?

Question

Is there a way to deterministically create an RSA private-key for an X.509 certificate, ideally through a library which has been vetted already?

i.e. user enters some phrase like "this is my private group", and that seed value is used to generate a private RSA key which I can then use as a certificate authority. But in such a way I can get the same key predictably on different machines from just that seed value.

My use case is I would like to support pre-shared keys in my application, but use the existing X.509 support it uses for keying. If I could create a predictable X.509 certificate from some initial value, then this would be trivial since users could verify each other's certificates against the generated key.

I would like to avoid hand-rolling a library to do this for obvious reasons, but this doesn't seem to be a commonly done thing - even though obviously various systems which support PSK must, internally, be doing something quite similar.

Answer 1

At the moment, I see no big problem here, at least, from the PoV of the algorithm itself.

1. Seed a PRNG with e.g. a hash of your key phrase.
2. Use the PRNG to generate the RSA key pair.
3. Use a library to generate the certificate, putting your key material in it.

Determinism is achieved through the use of PRNG seeded with the same key phrase (likely salted and put through e.g. SHA-256), so the output is the same for same input. All the required algorithms can be easily implemented in Python, or existing code can be reused, from e.g. Python-RSA. The only required adjustment would be using your PRNG instead of what it's using now.

Point 3 is the hardest part as I'm no big expert in libraries, but this seems to be a part of another problem (generating a certificate from existing key material). This falls into the "what is the best library for..." category.

As usual: whipping your own crypto is generally discouraged and frowned upon, unless you are Bruce Schneier. ;-)

Answer 2

As @Dmitry indicates, what you envision is feasible. RSA key pair generation, actually any key pair generation, feeds on a PRNG; the PRNG itself is a deterministic algorithm that "extends" an initial random seed into an arbitrarily long sequence of pseudorandom bytes. You could use a strong password hashing function and use the resulting hash value as seed for a PRNG.

However, there are some side issues which can be bothersome. For instance:

• Password hashing works best when there is a salt, which is not secret but must be stored somewhere.
• Changing your password implies changing your private key, which is usually quite inconvenient.
• The public key (which is public) can be used as a test for an offline dictionary attack: attackers can try passwords "at home" until a match is found with the known public key.

I expanded more on that subject in this answer.

Remember that the certificate (which contains the public key) must be stored somewhere, since you cannot recreate it from the password (the certificate is signed by the CA, and you cannot recompute that signature, since you are not your own CA). You could generate your private key "normally", encrypt it with some password-based encryption system, and store it along with the certificate; this would be equivalent, from a security point of view, to password-to-RSA-key derivation; but at least it would work with existing formats and tools (you could use PKCS#12, aka "pfx", as the password-protected archive format for both the certificate and the private key).

Answer 3

I did some investigation and found some interesting notes I thought worth sharing, but not a definitive answer. I generated several certificates and compared them. I was using this line:

Windows:

openssl req -new -x509 -key priv.pem -out pub.pem -h -subj '//CN=test'

Linux (not tested):

openssl req -new -x509 -key priv.pem -out pub.pem -h -subj '/CN=test'

Then I compared the contents and they did not match.

I used Python to get more information about the certificates:

from cryptography.x509 import load_pem_x509_certificate
from cryptography.hazmat.backends import default_backend
pub_str = open(pub_fname).read().encode()
cert_obj = load_pem_x509_certificate(pub_str, default_backend())
public_key = cert_obj.public_key()

I found that cert_obj.serial_number, cert_obj.not_valid_after, cert_obj.not_valid_before differed (also cert_obj.signature differed but I assume this is a result of the other fields not matching).

I was able to specify the serial number via command line (Windows):

openssl req -new -x509 -key priv.pem -out pubX.pem -set_serial 219363692778776146107430278182615926685007820639  -subj '//CN=test'

but NOT the dates. At this point I thought I should just store the certificate file. There are some other possible avenues unexplored. Perhaps using Python to generate the certificate instead of openssl might make it possible to specify those values. There is also alternative commands that allow the dates to be specified (I saw gossl mentioned online but was unable to confirm).

Answer 4

X509 certificate are, basically, made of several kind of information:

• The certificate declarative data which includes everything that the certificates claims about the key owner (mostly what you find in the certificate subject fields but also commonly additional OIDs like )
• The certificate scoping data (for instance: key usage, validity period, etc.)
• The public half of the key pair associated with the certificate.
• The certificate trust chain information (who guarantee that the declarative and scoping data is correct) and revocation data
• Some technical fields (which algorythm is used, what's the certificate serial number, etc.)

You can put anything you want in both the declarative and scoping data and you can control what's in the technical fields (mostly) as long as your CA accepts to validate your cert as you submit it (or as long as you're using self-signed certificates).

The public key part of the certificate is dictated by whatever key algorythm you decided to use. You could use the same key for all your certificates although I wouldn't suggest you do so: there is no valid reason to do so in practice and it could threaten the security of the whole system depending on how the keys are used.

Finally, the trust information includes mostly the issuer reference (which you mostly can decide or, at least, know in advance in most case) and the digital signature of the whole certificate (which you have no way of knowing or control over). Using a self-signed certificate would not help you, in this case, since the only way for the two signature to be 100% identical would be for every part of the signature data to be identical as well: you might as well make a copy of the original certificate instead of signing it twice.

The good news, however, is that while you shouldn't use the same key for several certificate, you do not have to. You can simply create your own CA and have your application verify all certificates against that CA root: that will allow all your users to verify the keys you're distributing - including future keys - while not requiring your to weakening the infrastructure thing by reusing a fixed set of keys.

Pinning the certificate authority - instead of the leaf certificate - is a bit more complex to implement but it's also more flexible and allow for more complex usage scenarii.