Using an RSA private key simultanously as an AES encryption key to generate random numbers?

Question

Currently I'm implementing a PRNG for an embedded system. Using the RFC 4086 I've decided to use the X9.17 - to be more specific the successor X9.31- standard to implement my PRNG. X9.17 uses DES, but X9.31 uses AES!

Now I need to specify the value of the AES key for X9.31. I know that at least my AES key must be unpredictable to an adversary. Because of this I want to use the RSA private key of the certificate which belongs to my embedded device. (This value is currently the only one that from my point of view that is unpredictable.)

My idea how to generate the AES key from the RSA private key:

AES_key= SHA1(RSA private key || date)

But is it OK to (ab)use a RSA signing key as a symmetric AES key, to encrypt the seed and finally generate random values? Is there any serious security weakness?

Answer 1

On a general and administrative basis, reusing the same private key for distinct usages is bad.

For this specific case, this should be fine (although you should use SHA-256 instead of SHA-1, if only for reasons of public relations: SHA-1 has bad press and any use of SHA-1 for a new design will be questioned), subject to the important caveat below.

The current date is a monotonous scale. However, your device does not have direct access to that physical value; it only has a clock which provides a discrete (it works by small increments, e.g. 1 second each) approximation of the current date. If you try to generate your AES key twice in the same second, and the "current date" changes only once per second, then you get the same seed, hence the same output, which can be bad. Also, more importantly, if the user (or attacker) can set the clock, then he can potentially enforce a seed reuse, leading to a PRNG sequence repeat. "Setting the clock" must be thought in a wide sense: an attacker who have the device in his hands may try to freeze or cook it, because quartz are sensitive to temperature. He may also play with the power input, e.g. adding a high frequency signal into it, on the hope that it would interact with the quartz and change its oscillating frequency. Possibilities are quite endless; the bottom line is that it is very hard for an embedded device to have an accurate, secure notion of the current time. Even getting a value which an attacker cannot force to repeat can be quite a challenge.

A more robust version would use a counter, which you increase every time you need a new AES key. Make sure that the counter is large enough that it cannot overflow (e.g. use a 64-bit counter). The counter must have permanent storage and never be reset throughout the lifetime of the device; you must also update the counter storage before using the counter value in the PRNG.

By the way, using the RSA private key as PRNG seed will not help you when it comes to actually generating the RSA private key itself. So either you generate the RSA private key externally and import it into the device (e.g. as part of factory initialization), or you have a problem. This might lead to another problem, depending on your exact situation: if a user can force the value of the RSA private key, then he can predict the PRNG output. You do not give information on your security model to know whether this can be an issue for you.

Answer 2

As a general rule: in an embedded device, by injecting a secret into an algorithm, you open the door to channel leakage attacks into the implementation of the algorithm (e.g. Differential Power Analysis).

Here, you plan to inject the RSA private key into the hash. If an adversary could trigger that a few hundred times, this would be a plausible setup to mount a DPA attack (in particular, the "date" field supplies the variability needed for such attacks), and might be easier than a DPA attack on the RSA implementation itself. This illustrate the already made point that reusing a secret is bad.

A workaround could be doing your AES_key generation only once, and in a trusted location; then storing that internally for later use.

Note: you have a chicken-and-egg problem if you want to use the PRNG to generate the RSA private key, which is the original purpose of the PRNG in X9.31

Note: X9.31 predates AES by over a decade, and thus does not use AES. The proper reference to what you plan is likely section 3 in this NIST-recommended addition to ANSI X9.31-1988.

Answer 3

A related note on making use of an RSA private key as an AES key:

The most significant half of an RSA private key is not difficult to predict. If the public exponent value $e$ is $65537$, then are only $65537$ possible values.

One could approximate $\phi(n)$ - Euler's Totient function - by the RSA modulus n and guess the small set of of possible values for the most significant half of RSA. The size of set is just $e$.

For example, let's say the RSA modulus $n$ is $2048$-bit. Usually the private key d will also be about $2048$-bit or $2047$-bit. In contrast to our believe that there are $2^{1024}$ possible most significant half possibilities for d, actually there are only e possible values.

A demo of this can be found [1].

[1]. https://www.youtube.com/watch?v=ftRdRHUd258&feature=youtu.be