Repository : http://git.fedorahosted.org/git/?p=secure-coding.git
On branch : master
commit 56f351145bcdd5edd7d2a00c25e0df4fd665ae7d Author: Eric Christensen echriste@redhat.com 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_part1_rev3_general.pdf" /></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>
On Fri, 30 May 2014 sparks@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_part1_rev3_general.pdf" /></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.
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.
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.
security@lists.fedoraproject.org
-
Eric Christensen -
Florian Weimer -
Pavel Kankovsky