[Secure Coding] master: Added RSA key generation procedures (56f3511)

[Eric Christensen]

Repository : http://git.fedorahosted.org/git/?p=secure-coding.git

On branch  : master

> ---------------------------------------------------------------
commit 56f351145bcdd5edd7d2a00c25e0df4fd665ae7d
Author: Eric Christensen <echriste(a)redhat.com&gt;
Date:   Fri May 30 09:07:40 2014 -0400

    Added RSA key generation procedures


> ---------------------------------------------------------------
 Securing_TLS/en-US/OpenSSL.xml |   31 +++++++++++++++++++++++++++++++
 1 files changed, 31 insertions(+), 0 deletions(-)

diff --git a/Securing_TLS/en-US/OpenSSL.xml b/Securing_TLS/en-US/OpenSSL.xml
index 191564f..df458d9 100644
--- a/Securing_TLS/en-US/OpenSSL.xml
+++ b/Securing_TLS/en-US/OpenSSL.xml
@@ -160,5 +160,36 @@ EXP-KRB5-RC4-MD5        SSLv3
 			</para>
 		</section>
 	</section>
+	<section
id="sect-Fedora_Security_Team-Securing_TLS-OpenSSL-Generating_Crypto">
+		<title>Generating Crypto</title>
+		<para>Properly generating keys and certificates is as important as the ciphers
suite being used to secure the circuit.  The best cipher can be broken with improperly
generated keys.</para>
+
+		<section
id="sect-Fedora_Security_Team-Securing_TLS-OpenSSL-Generating_Crypto-RSA">
+			<title>Generating RSA keys</title>
+			<para>RSA keys are the most common key type used to secure SSL and TLS circuits.
 It's relatively simple to generate keys and we'll describe how and why
now.</para>
+			<para>
+<screen>
+openssl genrsa -aes128 -out key_name.key 3072
+</screen>
+This will generate a 3072-bit RSA key that is sufficently large for true 128 bits of
security.  To obtain 256 bits of security the RSA key will need to be 15360 bits.  If you
require that type of security, however, a ECDSA key should be utilized.
+<important><para>The industry standard 2048-bit RSA key only provides 112
bits of security.<footnote><para>NIST SP 800-57 Part 1, Rev 3 <ulink
url="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part...
/></para></footnote></para></important>
+
+<screen>
+openssl rsa -in key_name.key -out key_name.key
+</screen>
+This simply removes the password that was placed on the key at generation.  You can do
this once you are sure you no longer need to protect the key (like when it's going to
be used on the server).
+
+<screen>
+openssl req -new -key key_name.key -out key_name.csr
+</screen>
+This will generate a certificate signing request (<abbrev>CSR</abbrev>) to
provide to your certificate authority (<abbrev>CA</abbrev>) for signing.
+
+<screen>
+openssl x509 -req -days 365 -sha384 -in key_name.csr -signkey key_name.key -out
key_name.crt
+</screen>
+<emphasis>Optional</emphasis> - This last step isn't generally necessary.
 This is what the CA does on their side except they use their key in place of key_name.key
to sign your key.  By doing this you are creating a self-signed certificate which is not
very useful and should only be used for testing purposes.
+			</para>
+		</section>
+	</section>
 </chapter>

[Pavel Kankovsky]

On Fri, 30 May 2014 sparks(a)fedoraproject.org wrote:

>  diff --git a/Securing_TLS/en-US/OpenSSL.xml
> b/Securing_TLS/en-US/OpenSSL.xml
>  index 191564f..df458d9 100644
>  --- a/Securing_TLS/en-US/OpenSSL.xml
>  +++ b/Securing_TLS/en-US/OpenSSL.xml
>  @@ -160,5 +160,36 @@ EXP-KRB5-RC4-MD5        SSLv3
>   			</para>
>   		</section>
>   	</section>
>  +	<section
> id="sect-Fedora_Security_Team-Securing_TLS-OpenSSL-Generating_Crypto">
>  +		<title>Generating Crypto</title>
>  +		<para>Properly generating keys and certificates is as important as the ciphers
> suite being used to secure the circuit.  The best cipher can be broken with improperly
> generated keys.</para>
>  +
>  +		<section
> id="sect-Fedora_Security_Team-Securing_TLS-OpenSSL-Generating_Crypto-RSA">
>  +			<title>Generating RSA keys</title>
>  +			<para>RSA keys are the most common key type used to secure SSL and TLS
> circuits.  It's relatively simple to generate keys and we'll describe how and why
> now.</para>
>  +			<para>
>  +<screen>
>  +openssl genrsa -aes128 -out key_name.key 3072
>  +</screen>
>  +This will generate a 3072-bit RSA key that is sufficently large for true 128 bits of
> security.  To obtain 256 bits of security the RSA key will need to be 15360 bits.  If you
> require that type of security, however, a ECDSA key should be utilized.
>  +<important><para>The industry standard 2048-bit RSA key only provides 112
> bits of security.<footnote><para>NIST SP 800-57 Part 1, Rev 3 <ulink
> url="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part...
> /></para></footnote></para></important> 
etc...  but "OpenSSL pitfalls" in defensive-coding/en-US/Features-TLS.xml
warns that

	OpenSSL command-line commands, such as <command>openssl
	genrsa</command>, do not ensure that physical entropy is used
	for key generation--they obtain entropy from
	<filename>/dev/urandom</filename> and other sources, but not
	from <filename>/dev/random</filename>.  This can result in
	weak keys if the system lacks a proper entropy source (e.g., a
	virtual machine with solid state storage).  Depending on local
	policies, keys generated by these OpenSSL tools should not be
	used in high-value, critical functions.

I think such warning (and perhaps an advice to use -randfile /dev/random?)
should be reflected in documents telling people to use openssl genrsa et 
al. to generate keys.

Come to think of it, maybe it would also be a good idea to patch these 
commands to print the warning when they are used to generate new keys 
without a good source of entropy.

-- 
Pavel Kankovsky aka Peak                      "Que sais-je?"

[Florian Weimer]

On 06/08/2014 03:48 PM, Pavel Kankovsky wrote:

>  etc...  but "OpenSSL pitfalls" in
> defensive-coding/en-US/Features-TLS.xml
>  warns that
>
>  	OpenSSL command-line commands, such as <command>openssl
>  	genrsa</command>, do not ensure that physical entropy is used
>  	for key generation--they obtain entropy from
>  	<filename>/dev/urandom</filename> and other sources, but not
>  	from <filename>/dev/random</filename>.  This can result in
>  	weak keys if the system lacks a proper entropy source (e.g., a
>  	virtual machine with solid state storage).  Depending on local
>  	policies, keys generated by these OpenSSL tools should not be
>  	used in high-value, critical functions.
>
>  I think such warning (and perhaps an advice to use -randfile /dev/random?)
>  should be reflected in documents telling people to use openssl genrsa et
>  al. to generate keys. 
"-randfile /dev/random" hopefully does not offer any real benefit.

>  Come to think of it, maybe it would also be a good idea to patch
> these
>  commands to print the warning when they are used to generate new keys
>  without a good source of entropy. 
Currently, there is no non-blocking way to detect that the kernel pool 
has been initialized.  I proposed a patch to add a variable under 
/proc/sys, but that wasn't accepted.  There have been some recent 
discussions on the kernel and systemd side, but no one feels 
responsible, so there hasn't been any actual progress.

-- 
Florian Weimer / Red Hat Product Security Team

[Pavel Kankovsky]

On Mon, 9 Jun 2014, Florian Weimer wrote:

> >  I think such warning (and perhaps an advice to use -randfile
> >  /dev/random?) should be reflected in documents telling people to use
> >  openssl genrsa et al. to generate keys.
>
>  "-randfile /dev/random" hopefully does not offer any real benefit. 
BTW: A small erratum: the correct name of the option seems to be "-rand" 
rather than "-randfile". I am sorry I got it wrong.

It guarantees that keys are generated from good entropy. How that can't be 
a real benefit?

Unfortunately, it turns out OpenSSL is very entropy-hungy and it sucks 
2048 bytes every time it gets a device as a parameter to "-rand". This 
means it drains the kernel entropy pool pretty quickly, it takes a long 
time to finish and most of the precious bits of entropy are wasted. :(

> >  Come to think of it, maybe it would also be a good idea to patch
> these
> >  commands to print the warning when they are used to generate new keys
> >  without a good source of entropy.
>
>  Currently, there is no non-blocking way to detect that the kernel pool 
>  has been initialized.  I proposed a patch to add a variable under 
>  /proc/sys, but that wasn't accepted. [...] 
There are three possible levels:

0. Generate the key and do not care about entropy. This is listed merely 
for the sake of completeness. I hope (against all odds) no one is ever 
going to do that intentionally.

1. The key may be generated using recycled entropy as long as the 
recycling is done by a cryptographically secure generator and the 
amount of entropy used to seed the generator is sufficient.

2. The key shall be generated using fresh entropy--or a dedicated 
generator seeded with a sufficient amount of fresh entropy.

Personally, I think the second level should be preferred for any long-term 
keys. But it would not make sense to do any checks in this case because 
there would be a race condition between the check and an attempt to 
acquire the entropy. One can do a non-blocking read from /dev/random.

Unfortunately, the device is designed to return chunks of EXTRACT_SIZE 
bytes and it is not possible to acquire more entropy atomically (all or 
nothing). One could read_wakeup_threshold sysctl but I do not think it 
would help.

A process that would hit the bottom of the pool in the middle of reading 
would have to throw out any bytes it has read so far, or--it is 
privileged--feed them back to the kernel.

If the first level is sufficient for you and your kernel is >= 3.11
then it seems to me everything you need to do is to check whether
kernel.random.entropy_avail sysctl or RNDGETENTCNT ioctl return
a nonzero value and read from /dev/urandom. Kernels since 3.11 always 
seed the nonblocking pool with at least 128 bits (the number is hardwired) 
before they start adding bits to the input pool.

An alternative, purely userspace, solution that would work on any kernel
could be as follows: start a background process that

1. acquires a given amount of entropy from /dev/random,

2. feeds it to /dev/urandom (in fact, it does not really matter where the 
data are written because they are always mixed into both pools)

3. raises a flag telling everyone /dev/urandom has been seeded and exits.


-- 
Pavel Kankovsky aka Peak                      "Que sais-je?"