[Secure Coding] master: sect-Defensive_Coding-TLS-OpenSSL: Mention "openssl genrsa" entropy issue (564ffc8)
Repository : http://git.fedorahosted.org/git/?p=secure-coding.git
On branch : master
commit 564ffc80149307d0a99724e2689ed3a8816513bf Author: Florian Weimer fweimer@redhat.com Date: Fri Apr 25 13:47:22 2014 +0200
sect-Defensive_Coding-TLS-OpenSSL: Mention "openssl genrsa" entropy issue
defensive-coding/en-US/Features-TLS.xml | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml index 936910d..f4da007 100644 --- a/defensive-coding/en-US/Features-TLS.xml +++ b/defensive-coding/en-US/Features-TLS.xml @@ -186,6 +186,15 @@ verify</command> result in an exit status of zero. </para> <para> + 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>. Keys generated by + these tools should not be used in high-value, critical + functions. + </para> + <para> The OpenSSL server and client applications (<command>openssl s_client</command> and <command>openssl s_server</command>) are debugging tools and should <emphasis>never</emphasis> be
On Fri, 2014-04-25 at 14:33 +0000, fweimer@fedoraproject.org wrote:
Repository : http://git.fedorahosted.org/git/?p=secure-coding.git
On branch : master
commit 564ffc80149307d0a99724e2689ed3a8816513bf Author: Florian Weimer fweimer@redhat.com Date: Fri Apr 25 13:47:22 2014 +0200
sect-Defensive_Coding-TLS-OpenSSL: Mention "openssl genrsa" entropy issue
Hello Florian, Is there some pre-compiled version of this guide? It fails to compile out of the box.
regards, Nikos
On 04/28/2014 09:15 AM, Nikos Mavrogiannopoulos wrote:
Is there some pre-compiled version of this guide? It fails to compile out of the box.
Deleting the file en-US/Web_Applications.xml should enable it to compile.
The official web version is somewhat out of data, unfortunately, because we cannot update it right now. Eric has the details.
On Pá, 2014-04-25 at 14:33 +0000, fweimer@fedoraproject.org wrote:
Repository : http://git.fedorahosted.org/git/?p=secure-coding.git
On branch : master
commit 564ffc80149307d0a99724e2689ed3a8816513bf Author: Florian Weimer fweimer@redhat.com Date: Fri Apr 25 13:47:22 2014 +0200
sect-Defensive_Coding-TLS-OpenSSL: Mention "openssl genrsa" entropy issue
defensive-coding/en-US/Features-TLS.xml | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml index 936910d..f4da007 100644 --- a/defensive-coding/en-US/Features-TLS.xml +++ b/defensive-coding/en-US/Features-TLS.xml @@ -186,6 +186,15 @@ verify</command> result in an exit status of zero. </para> <para>
- 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>. Keys generated by
- these tools should not be used in high-value, critical
- functions.
</para>
This one is quite questionable. We should not make impression that /dev/urandom is insecure apart from situations where the kernel is not seeded with entropy. Of course in case of diskless machines the entropy seeding of the kernel entropy pool might be very scarce and just after boot the entropy in the pool might be insufficient. But once the kernel pool is properly seeded once the generated pseudorandom numbers are secure. I would say that keys for high-value, critical functions (but how are these really defined) should not be generated on virtual machines or diskless routers or similar machines where the entropy sources are limited.
On 04/28/2014 02:36 PM, Tomas Mraz wrote:
diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml index 936910d..f4da007 100644 --- a/defensive-coding/en-US/Features-TLS.xml +++ b/defensive-coding/en-US/Features-TLS.xml @@ -186,6 +186,15 @@ verify</command> result in an exit status of zero. </para> <para>
- 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>. Keys generated by
- these tools should not be used in high-value, critical
- functions.
</para>This one is quite questionable. We should not make impression that /dev/urandom is insecure apart from situations where the kernel is not seeded with entropy.
I tried to word in a way that doesn't give the impression that /dev/urandom is insecure, while still pleasing those who strongly think that long-term key material should be generated from /dev/random.
Of course in case of diskless machines the entropy seeding of the kernel entropy pool might be very scarce and just after boot the entropy in the pool might be insufficient. But once the kernel pool is properly seeded once the generated pseudorandom numbers are secure. I would say that keys for high-value, critical functions (but how are these really defined) should not be generated on virtual machines or diskless routers or similar machines where the entropy sources are limited.
Is there a way to check in /proc that the kernel has initialized the pool? I know the kernel prints a message. A low value in /proc/sys/kernel/random/entropy_avail does not necessarily mean that no entropy was mixed into the pool.
Is it possible to express that a seeded /dev/urandom is needed as a systemd dependency?
On Po, 2014-04-28 at 14:55 +0200, Florian Weimer wrote:
On 04/28/2014 02:36 PM, Tomas Mraz wrote:
diff --git a/defensive-coding/en-US/Features-TLS.xml b/defensive-coding/en-US/Features-TLS.xml index 936910d..f4da007 100644 --- a/defensive-coding/en-US/Features-TLS.xml +++ b/defensive-coding/en-US/Features-TLS.xml @@ -186,6 +186,15 @@ verify</command> result in an exit status of zero. </para> <para>
- 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>. Keys generated by
- these tools should not be used in high-value, critical
- functions.
</para>This one is quite questionable. We should not make impression that /dev/urandom is insecure apart from situations where the kernel is not seeded with entropy.
I tried to word in a way that doesn't give the impression that /dev/urandom is insecure, while still pleasing those who strongly think that long-term key material should be generated from /dev/random.
The fact is that once the kernel entropy pool is properly seeded the theoretical properties of the random numbers outputted from /dev/random and /dev/urandom do not differ that much. The only difference is in case where the attacker could snapshot the kernel entropy pool contents and no sufficient reseed could happen before the key was generated. However in this case using /dev/random would just mean that the system would wait for additional entropy giving the attacker the possibility to obtain additional snapshot.
Of course in case of diskless machines the entropy seeding of the kernel entropy pool might be very scarce and just after boot the entropy in the pool might be insufficient. But once the kernel pool is properly seeded once the generated pseudorandom numbers are secure. I would say that keys for high-value, critical functions (but how are these really defined) should not be generated on virtual machines or diskless routers or similar machines where the entropy sources are limited.
Is there a way to check in /proc that the kernel has initialized the pool? I know the kernel prints a message. A low value in /proc/sys/kernel/random/entropy_avail does not necessarily mean that no entropy was mixed into the pool.
Unfortunately I do not know of such way. Perhaps this should be added as additional /proc value?
Is it possible to express that a seeded /dev/urandom is needed as a systemd dependency?
Given the above it is probably not possible. However Fedora init process currently reseeds entropy pool with data saved from previous boot cycle before shutdown.
On 04/28/2014 03:05 PM, Tomas Mraz wrote:
I tried to word in a way that doesn't give the impression that /dev/urandom is insecure, while still pleasing those who strongly think that long-term key material should be generated from /dev/random.
The fact is that once the kernel entropy pool is properly seeded the theoretical properties of the random numbers outputted from /dev/random and /dev/urandom do not differ that much. The only difference is in case where the attacker could snapshot the kernel entropy pool contents and no sufficient reseed could happen before the key was generated. However in this case using /dev/random would just mean that the system would wait for additional entropy giving the attacker the possibility to obtain additional snapshot.
The idea is that a blocking generator such as /dev/random should be secure even against a full cryptanalysis of the pool mixing primitives. I don't know if the Linux /dev/random design hits this goal.
I agree that this is *probably* not practically relevant, but I don't want to cover this particular debate in the guidelines.
What about this version? Do you think it's sufficiently balanced?
<para> 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. </para>
Is there a way to check in /proc that the kernel has initialized the pool? I know the kernel prints a message. A low value in /proc/sys/kernel/random/entropy_avail does not necessarily mean that no entropy was mixed into the pool.
Unfortunately I do not know of such way. Perhaps this should be added as additional /proc value?
Hmm, that could make sense.
On the other hand, blocking until entropy is available could result in preventing system startup because nothing is running that would trigger entropy production.
On Po, 2014-04-28 at 15:22 +0200, Florian Weimer wrote:
On 04/28/2014 03:05 PM, Tomas Mraz wrote:
I tried to word in a way that doesn't give the impression that /dev/urandom is insecure, while still pleasing those who strongly think that long-term key material should be generated from /dev/random.
The fact is that once the kernel entropy pool is properly seeded the theoretical properties of the random numbers outputted from /dev/random and /dev/urandom do not differ that much. The only difference is in case where the attacker could snapshot the kernel entropy pool contents and no sufficient reseed could happen before the key was generated. However in this case using /dev/random would just mean that the system would wait for additional entropy giving the attacker the possibility to obtain additional snapshot.
The idea is that a blocking generator such as /dev/random should be secure even against a full cryptanalysis of the pool mixing primitives. I don't know if the Linux /dev/random design hits this goal.
I agree that this is *probably* not practically relevant, but I don't want to cover this particular debate in the guidelines.
What about this version? Do you think it's sufficiently balanced?
<para>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. </para>
OK, that's better.
Is there a way to check in /proc that the kernel has initialized the pool? I know the kernel prints a message. A low value in /proc/sys/kernel/random/entropy_avail does not necessarily mean that no entropy was mixed into the pool.
Unfortunately I do not know of such way. Perhaps this should be added as additional /proc value?
Hmm, that could make sense.
On the other hand, blocking until entropy is available could result in preventing system startup because nothing is running that would trigger entropy production.
Yes, but having indicative /proc value shouldn't really harm.
On 04/28/2014 03:31 PM, Tomas Mraz wrote:
What about this version? Do you think it's sufficiently balanced?
<para>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. </para>
OK, that's better.
Thanks.
Is there a way to check in /proc that the kernel has initialized the pool? I know the kernel prints a message. A low value in /proc/sys/kernel/random/entropy_avail does not necessarily mean that no entropy was mixed into the pool.
Unfortunately I do not know of such way. Perhaps this should be added as additional /proc value?
Hmm, that could make sense.
On the other hand, blocking until entropy is available could result in preventing system startup because nothing is running that would trigger entropy production.
Yes, but having indicative /proc value shouldn't really harm.
There's now a discussion upstream: https://lkml.org/lkml/2014/4/28/494
On Mon, 28 Apr 2014, Florian Weimer wrote:
On 04/28/2014 03:05 PM, Tomas Mraz wrote:
The fact is that once the kernel entropy pool is properly seeded the theoretical properties of the random numbers outputted from /dev/random and /dev/urandom do not differ that much.
The idea is that a blocking generator such as /dev/random should be secure even against a full cryptanalysis of the pool mixing primitives.
Strictly speaking, the pool mixing primitives (twisted GFRS) would be easy to break were they not protected by the hash function (SHA-1) used to transform bits in a pool into output.
IMHO, /dev/random is supposed to return "fresh" bits of entropy and even an advesary with access to unlimited computing power and an unlimited supply of observed bits acquired from /dev/random (or urandom) should be unable to guess anything about output that has not been observed.
On the other hand, /dev/urandom "recycles" entropy (until it is reseeded). A very powerful adversary who observes enough bits of output might be able to reconstruct its internal state and recompute unknown output.
This is a substantial theoretical difference.
I don't know if the Linux /dev/random design hits this goal.
Good question. I am inclined to say "probably no" because it seems to me it depends on the properties of SHA-1 and SHA-1 is far from perfect. But do not quote me, I am not a cryptologist.
security@lists.fedoraproject.org
-
Florian Weimer -
fweimer＠fedoraproject.org -
Nikos Mavrogiannopoulos -
Pavel Kankovsky -
Tomas Mraz