Need input for Certificate generation

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Need input for Certificate generation

Pravesh Rai

Hi,

 

At one place, we are using following logic for generating self-signed certificate:

 

#define SEED_SIZE 128

 

k = RAND_status();

while(k == 0)

{

// custom logic for getting random numbers from system variables

...

 

CryptGenRandom(hCryptProv, SEED_SIZE, buf);     // On Windows OS

apr_generate_random_bytes(buf, SEED_SIZE);      // On Linux OS

 

...

           

//RAND_seed(buf, SEED_SIZE);

      RAND_add(buf, SEED_SIZE, (20/100) * SEED_SIZE);

 

      k = RAND_status();

}

 

...

 

RSA_generate_key(2048, RSA_F4, NULL, NULL);

 

Even though RAND_status() always return 1 (OK), our analysis shows that the certificates generated using this logic is not having enough entropy. Also tried another approach of calling RAND_seed / RAND_add, without checking for RAND_status(), but even that doesn’t help.

 

Can anybody please help me in understanding the limitation of this logic or suggest any other approach?

 

Thanks,

Pravesh

Reply | Threaded
Open this post in threaded view
|

Re: Need input for Certificate generation

Jeffrey Walton-3
On Thu, Nov 15, 2012 at 6:03 AM, Pravesh Rai <[hidden email]> wrote:

> Hi,
>
> At one place, we are using following logic for generating self-signed
> certificate:
>
> #define SEED_SIZE 128
>
> k = RAND_status();
> while(k == 0)
> {
> // custom logic for getting random numbers from system variables
> ...
>
> CryptGenRandom(hCryptProv, SEED_SIZE, buf);     // On Windows OS
> apr_generate_random_bytes(buf, SEED_SIZE);      // On Linux OS
Hugh? What's wrong with /dev/{u}rand, /dev/hwrand, and vritio_prng?

>
> //RAND_seed(buf, SEED_SIZE);
> RAND_add(buf, SEED_SIZE, (20/100) * SEED_SIZE);
>
>       k = RAND_status();
>
> }
I'm not sure 20% effective entropy is a good estimate here. If its
coming from the OS, its likely higher. If its coming from an Entrop
Key or other hardware device, I would estimate it nearly 100% (if not
100%)

Plus, there may be a bug there. Perform a cast to a double before the divide:
    ((double)20/100) * SEED_SIZE

>
> RSA_generate_key(2048, RSA_F4, NULL, NULL);
>
Reasonable.

> Even though RAND_status() always return 1 (OK), our analysis shows that the
> certificates generated using this logic is not having enough entropy. Also
> tried another approach of calling RAND_seed / RAND_add, without checking for
> RAND_status(), but even that doesn’t help.
Citation, please. Is this a headless server? Or being run in
virtualized environment?

> Can anybody please help me in understanding the limitation of this logic or
> suggest any other approach?
Add entropy via an Entropy Key, fetch bytes from random.org (be sure
to pin the certificate), or do some key agreements and feed the peer's
pubic key back into OpenSSL's PRNG (see paper below).

"When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities
and Hedging Deployed Cryptography",
www.isoc.org/isoc/conferences/ndss/10/pdf/15.pdf. I actually use their
techniques (hedging) on everything, even mobile devices.

Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Need input for Certificate generation

J. J. Farrell-2
> From: Jeffrey Walton [mailto:[hidden email]]
>
> On Thu, Nov 15, 2012 at 6:03 AM, Pravesh Rai <[hidden email]>
> wrote:
> >...
> > #define SEED_SIZE 128
> >...
> > //RAND_seed(buf, SEED_SIZE);
> > RAND_add(buf, SEED_SIZE, (20/100) * SEED_SIZE);
> >
> >       k = RAND_status();
> >
> > }
> I'm not sure 20% effective entropy is a good estimate here. If its
> coming from the OS, its likely higher. If its coming from an Entrop
> Key or other hardware device, I would estimate it nearly 100% (if not
> 100%)
>
> Plus, there may be a bug there. Perform a cast to a double before the
> divide:
>     ((double)20/100) * SEED_SIZE

Good catch, definitely a bug - '(20/100) * SEED_SIZE' is just a long-winded way of saying '0'.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Need input for Certificate generation

Jeffrey Walton-3
In reply to this post by Jeffrey Walton-3
On Thu, Nov 15, 2012 at 10:41 AM, Jeffrey Walton <[hidden email]> wrote:
> On Thu, Nov 15, 2012 at 6:03 AM, Pravesh Rai <[hidden email]> wrote:
>>
>> CryptGenRandom(hCryptProv, SEED_SIZE, buf);     // On Windows OS
>> apr_generate_random_bytes(buf, SEED_SIZE);      // On Linux OS
>>
Speaking of poor documentation.....

I looked at the "header" and the "source". They are different "style
sheets" applied to the same file (I expected to see the H file, and
the C file). Neither had comments. Confer
http://apr.apache.org/docs/apr/0.9/apr__general_8h-source.html and
http://apr.apache.org/docs/apr/0.9/group__apr__random.html.

I'll reproduce it here without the markup:

apr_status_t apr_generate_random_bytes(
    unsigned char * buf,
    int length
)

So, there are a few problems here. First is no documentation. Verbum
sapienti sat.

Second, you don't know what conditions need to be satisfied to define
APR_HAS_RANDOM (did you even know it was there?). This could be fixed
with documentation, but APR chose otherwise.

Third, you don't know what the function returns on success. Is there a
apr_succes? Or apr_true? This could be fixed with documentation, but
APR chose otherwise.

Fourth, the API tells you a negative length is acceptable. This could
be fixed with documentation, but APR chose otherwise. A negative
length makes no sense whatsoever (I know, its not limited to APR). I
would encourage you to write a few negative self-tests and submit it
to the project: send in a NULL`buf`, a zero `length`, and a negative
`length`. See how the library handles it. Since they botched the API
design, I would not be surprised if they SIGABRT on you (that's how
*not* to build a resilient system).

Fifth, there is probably some internal state, but we don't know that
for sure. This could be fixed with documentation, but APR chose
otherwise. If there is state, you don't know where it came from or its
quality. Did they limit themselves to (1) Time of Day, (2) Mac
address, (3) /dev/{u}rand, (4) the kernel's hwrand, or (5) virtio
gear? Perhaps some other clever combination? Are they constantly
hedging (probably not)? If there is no state, they have already broken
you (that's how *not* to build a resilient system).

This is a bit more personal taste, but I require PRNGs to be thread
safe. So Sixth, is the library thread safe? Is the call to
apr_generate_random_bytes() thread safe? I would definitely write a
multithreaded self test and try to break it. I can email you a set if
you need a canned test that spins up 64 threads (hit me off list).

Headless servers, entropy starvation, and rollbacks are a concern in
modern environments. OpenSSL and other entropy gathers, such as EDG,
don't account for the later. Its best to take the bull by the horns
and do it yourself. At minimum, you need to call RAND_add() with
entropy external to /dev/{u}rand.

The following may also be useful to you:
* Analysis of the Linux Random Number Generator, eprint.iacr.org/2006/086.pdf
* Cryptanalysis of the Random Number Generator of the Windows
Operating System, eprint.iacr.org/2007/419.pdf

Most recent analysis of Linux RNG (AFAIK):
* Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network
Devices, https://factorable.net/paper.html

Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Need input for Certificate generation

Graham Leggett
On 16 Nov 2012, at 4:36 AM, Jeffrey Walton <[hidden email]> wrote:

> On Thu, Nov 15, 2012 at 10:41 AM, Jeffrey Walton <[hidden email]> wrote:
>> On Thu, Nov 15, 2012 at 6:03 AM, Pravesh Rai <[hidden email]> wrote:
>>>
>>> CryptGenRandom(hCryptProv, SEED_SIZE, buf);     // On Windows OS
>>> apr_generate_random_bytes(buf, SEED_SIZE);      // On Linux OS
>>>
> Speaking of poor documentation…..

Why are you discussing APR on the openssl list? Surely if you had a problem with the APR documentation this would be a matter for the APR lists instead?

> I looked at the "header" and the "source". They are different "style
> sheets" applied to the same file (I expected to see the H file, and
> the C file). Neither had comments.

Really?

According to the source code, the header file is here:

https://svn.apache.org/repos/asf/apr/apr/branches/1.4.x/include/apr_general.h

The implementation is platform specific (that's the point of APR), and for unix it is here:

https://svn.apache.org/repos/asf/apr/apr/branches/1.4.x/misc/unix/rand.c

Both the header and source contain comments.

> Confer
> http://apr.apache.org/docs/apr/0.9/apr__general_8h-source.html and
> http://apr.apache.org/docs/apr/0.9/group__apr__random.html.

Why would you choose the obsolete v0.9 of APR as an example, when the latest version is v1.4.6? Have you read the documentation at http://apr.apache.org/ that covers this?

> I'll reproduce it here without the markup:
>
> apr_status_t apr_generate_random_bytes(
>    unsigned char * buf,
>    int length
> )
>
> So, there are a few problems here. First is no documentation. Verbum
> sapienti sat.

APR uses doxygen as a documentation generation system: http://en.wikipedia.org/wiki/Doxygen

The documentation is generated from the source headers, for example:

/**
 * Generate random bytes.
 * @param buf Buffer to fill with random bytes
 * @param length Length of buffer in bytes
 */
APR_DECLARE(apr_status_t) apr_generate_random_bytes(unsigned char * buf,
                                                    apr_size_t length);

The phrase "generate random bytes" is woefully inadequate, so I did the right thing and raised the issue on the right mailing list, archived here:

http://www.mail-archive.com/dev@.../msg24968.html

> Second, you don't know what conditions need to be satisfied to define
> APR_HAS_RANDOM (did you even know it was there?). This could be fixed
> with documentation, but APR chose otherwise.

If you look closer at APR, you'll notice that to build it, you run the configure script generated by a tool called autoconf. If you had occasion to care where APR_HAS_RANDOM came from, you would ensure that you understood autoconf and how it tests for system capability at compile time. It is not APR's job to re-document the autoconf tool: http://en.wikipedia.org/wiki/Autoconf

> Third, you don't know what the function returns on success. Is there a
> apr_succes? Or apr_true? This could be fixed with documentation, but
> APR chose otherwise.

The error codes are documented extensively here: http://apr.apache.org/docs/apr/1.4/group__apr__errno.html

> Fourth, the API tells you a negative length is acceptable. This could
> be fixed with documentation, but APR chose otherwise.

Really? The API specifies a length of apr_size_t. If you read the documentation (Hint: try a google search for "site:apr.apache.org apr_size_t") you discover that apr_size_t is documented here as being equivalent to size_t:

http://apr.apache.org/docs/apr/1.4/group__apr__platform.html

In turn, size_t is defined as an unsigned type, such as unsigned int, depending on your platform.

By reading the documentation you would have discovered that a negative length is not possible.

> A negative
> length makes no sense whatsoever (I know, its not limited to APR). I
> would encourage you to write a few negative self-tests and submit it
> to the project: send in a NULL`buf`, a zero `length`, and a negative
> `length`. See how the library handles it. Since they botched the API
> design, I would not be surprised if they SIGABRT on you (that's how
> *not* to build a resilient system).

I would suggest instead that you read the documentation.

> Fifth, there is probably some internal state, but we don't know that
> for sure. This could be fixed with documentation, but APR chose
> otherwise. If there is state, you don't know where it came from or its
> quality. Did they limit themselves to (1) Time of Day, (2) Mac
> address, (3) /dev/{u}rand, (4) the kernel's hwrand, or (5) virtio
> gear? Perhaps some other clever combination? Are they constantly
> hedging (probably not)? If there is no state, they have already broken
> you (that's how *not* to build a resilient system).

Correct, and I have raised this on the [hidden email] list, just as you should have done.

> This is a bit more personal taste, but I require PRNGs to be thread
> safe. So Sixth, is the library thread safe? Is the call to
> apr_generate_random_bytes() thread safe? I would definitely write a
> multithreaded self test and try to break it. I can email you a set if
> you need a canned test that spins up 64 threads (hit me off list).

This should be documented, yes. Again, raised it on the APR list?

As to writing an elaborate test, why not read the source as described above? If you had you would have discovered that either /dev/random, EGD, or truerand is used to generate the randomness, and you would be able to read the documentation on those to determine whether they are thread safe or not. Look for the documentation on /dev/random, EGD or truerand by using Google.

> Headless servers, entropy starvation, and rollbacks are a concern in
> modern environments. OpenSSL and other entropy gathers, such as EDG,
> don't account for the later. Its best to take the bull by the horns
> and do it yourself. At minimum, you need to call RAND_add() with
> entropy external to /dev/{u}rand.
>
> The following may also be useful to you:
> * Analysis of the Linux Random Number Generator, eprint.iacr.org/2006/086.pdf
> * Cryptanalysis of the Random Number Generator of the Windows
> Operating System, eprint.iacr.org/2007/419.pdf
>
> Most recent analysis of Linux RNG (AFAIK):
> * Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network
> Devices, https://factorable.net/paper.html
To bring this back to OpenSSL, missing documentation is a real problem. OpenSSL has chosen man pages as its preferred method of documentation, but not all API functions have man pages, and I believe that needs to be fixed. Most specifically, I believe patches submitted with new functionality that is not documented should be rejected by the project until the person making the submission finishes the job.

Users however are expected to read that documentation that does exist, and understand the documentation and library within the wider context in which it is deployed.

Regards,
Graham
--


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Need input for Certificate generation

Jeffrey Walton-3
On Fri, Nov 16, 2012 at 9:17 AM, Graham Leggett <[hidden email]> wrote:

> On 16 Nov 2012, at 4:36 AM, Jeffrey Walton <[hidden email]> wrote:
>
>> On Thu, Nov 15, 2012 at 10:41 AM, Jeffrey Walton <[hidden email]> wrote:
>>> On Thu, Nov 15, 2012 at 6:03 AM, Pravesh Rai <[hidden email]> wrote:
>>>>
>>>> CryptGenRandom(hCryptProv, SEED_SIZE, buf);     // On Windows OS
>>>> apr_generate_random_bytes(buf, SEED_SIZE);      // On Linux OS
>>>>
>> Speaking of poor documentation…..
>
> Why are you discussing APR on the openssl list? Surely if you had a problem with the APR documentation this would be a matter for the APR lists instead?
Poor documentation was a recent thread on the list.

I don't use APR, and I don't care about it. I won't be taking any time
to join their mailing list or report bugs. For what its worth, I think
its great that you did.

I was more concerned with his use of a possibly defective PRNG. That's
why I took the time to explain the problems with the PRNG.

Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Need input for Certificate generation

Jakob Bohm-7
In reply to this post by Jeffrey Walton-3
On 11/16/2012 3:36 AM, Jeffrey Walton wrote:
> ...
> Headless servers, entropy starvation, and rollbacks are a concern in
> modern environments. OpenSSL and other entropy gathers, such as EDG,
> don't account for the later. Its best to take the bull by the horns
> and do it yourself. At minimum, you need to call RAND_add() with
> entropy external to /dev/{u}rand.
>
Would you care to elaborate on the following points:

1. What do you mean by "rollback"

2. What RNG/PRNG are you referring to as "EDG"

3. What exactly makes /dev/{u,}random in current (not ancient) Linux
  kernelsinsecure given an appropriate supply of entropy?

Note that the two papers you site on the Linux kernel PRNG are:

I. A 6 year old document, presumably not applicable to the code in
  currentkernel versions.

II. A document about the consequences of using any PRNG without
sufficiententropy input, with the Linux kernel PRNG as a common
example.  This wouldpresumably be irrelevant if feeding the kernel
plenty of external entropy, e.g.by getting it from a hardware RNG
hooked up to a trusted server (under yourown control of cause).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Need input for Certificate generation

Jeffrey Walton-3
Hi Jacob,

On Fri, Nov 16, 2012 at 1:22 PM, Jakob Bohm <[hidden email]> wrote:

> On 11/16/2012 3:36 AM, Jeffrey Walton wrote:
>>
>> ...
>>
>> Headless servers, entropy starvation, and rollbacks are a concern in
>> modern environments. OpenSSL and other entropy gathers, such as EDG,
>> don't account for the later. Its best to take the bull by the horns
>> and do it yourself. At minimum, you need to call RAND_add() with
>> entropy external to /dev/{u}rand.
>>
> Would you care to elaborate on the following points:
>
> 1. What do you mean by "rollback"
Virtual Machine rollback attacks.

> 2. What RNG/PRNG are you referring to as "EDG"
EDG is Entropy Gatering Daemon. I was talking to John Steven about it
over the summer (John is CTO of Cigital, OWASP member, and part of the
project). EDG does not take measure to mitigate rollback attacks.

> 3. What exactly makes /dev/{u,}random in current (not ancient) Linux
>  kernelsinsecure given an appropriate supply of entropy?


> Note that the two papers you site on the Linux kernel PRNG are:
>
> I. A 6 year old document, presumably not applicable to the code in
>  currentkernel versions.
I don't believe this is correct. For example, the Linux generator
still lacks forward secrecy.

> II. A document about the consequences of using any PRNG without
> sufficient entropy input, with the Linux kernel PRNG as a common
> example.  This would presumably be irrelevant if feeding the kernel
> plenty of external entropy e.g. by getting it from a hardware RNG
> hooked up to a trusted server (under your own control of course).
The "trusted server" is a problem. First some background.

The Linux kernel folks *disabled* feeding data into the generator
based on interrupts because the attacker may control it. For example,
the arrival of a network packet. There's a real problem of starvation,
especially in headless servers and mobile devices. The problem was
highlighted (again) in a recent paper: "Mining Your Ps and Qs:
Detection of Widespread Weak Keys in Network Devices,"
https://factorable.net/paper.html. See Section 5 where the analysis
occurs and 5.1, "Weak entropy and the Linux RNG".

If I go to https://www.wisemo.com, I initiated that connection so its
not under control of an attacker). The exchange contains some random
(but public) data - namely, Wisemo's public key. A passive attacker on
the public internet may be able to observe the exchange. So we can
improve entropy in the generator at the cost of leaking information
about state input.

If the server is within my logical security boundary (for example, my
LAN/MAN segment), the attacker probably cannot observe the exchange.
In this case, I can improve entropy in the generator without the side
effect of leaking information about state input. Later, when the
machine goes out on the internet, its quality of random numbers will
be improved.

You should join us over at the cryptography mailing list
(http://lists.randombit.net/mailman/listinfo/cryptography).

> e.g. by getting it from a hardware RNG
I personally use an Entropy Key when I need  to ensure I have
sufficient bits to generate a long term key
(http://www.entropykey.co.uk). I carry it with me in my laptop bag.

I know of a number of medium and large size enterprises that don't use
hardware, and rely on the software generator provided by the OS. Those
enterprises include financial institutions in New York.

This is a true story. I'm a security architect, and this got pushed to
the team for risk acceptance. One financial institution was having
problems with entropy depletion in a virtual environment. The
appliance was apparently running out, and could not push sufficient
entropy to its hosts (it was blocking in calls to /dev/random, if I
recall correctly). The vendor stated we should delete /dev/random and
then link it to /dev/urandom (or vice versa), so the generator would
not block.

Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Need input for Certificate generation

Jakob Bohm-7
On 16-11-2012 19:57, Jeffrey Walton wrote:

> Hi Jacob,
> On Fri, Nov 16, 2012 at 1:22 PM, Jakob Bohm <[hidden email]> wrote:
>> On 11/16/2012 3:36 AM, Jeffrey Walton wrote:
>>> ...
>>> Headless servers, entropy starvation, and rollbacks are a concern in
>>> modern environments. OpenSSL and other entropy gathers, such as EDG,
>>> don't account for the later. Its best to take the bull by the horns
>>> and do it yourself. At minimum, you need to call RAND_add() with
>>> entropy external to /dev/{u}rand.
>> Would you care to elaborate on the following points:
>> 1. What do you mean by "rollback"
> Virtual Machine rollback attacks.

And how would an attacker rollback the victims VM?, an attacker with that
level of control is already presumably able to access the VMs data,
storage and execution state directly.

>> 2. What RNG/PRNG are you referring to as "EDG"
> EDG is Entropy Gatering Daemon. I was talking to John Steven about it
> over the summer (John is CTO of Cigital, OWASP member, and part of the
> project). EDG does not take measure to mitigate rollback attacks.

Ah, I thought that was called "EGD"

>> 3. What exactly makes /dev/{u,}random in current (not ancient) Linux
>> kernelsinsecure given an appropriate supply of entropy?
>> Note that the two papers you site on the Linux kernel PRNG are:
>> I. A 6 year old document, presumably not applicable to the code in
>> currentkernel versions.
> I don't believe this is correct. For example, the Linux generator
> still lacks forward secrecy.

Do you mean "lack forward secrecy" as in past random bits can be predicted
from later random bits (very bad) or "lack forward secrecy" as in internal
PRNG state may reveal bits output in the recent past (less of a concern for
most real attacks).

>> II. A document about the consequences of using any PRNG without
>> sufficient entropy input, with the Linux kernel PRNG as a common
>> example. This would presumably be irrelevant if feeding the kernel
>> plenty of external entropy e.g. by getting it from a hardware RNG
>> hooked up to a trusted server (under your own control of course).
> The "trusted server" is a problem. First some background.
> The Linux kernel folks *disabled* feeding data into the generator
> based on interrupts because the attacker may control it. For example,
> the arrival of a network packet. There's a real problem of starvation,
> especially in headless servers and mobile devices. The problem was
> highlighted (again) in a recent paper: "Mining Your Ps and Qs:
> Detection of Widespread Weak Keys in Network Devices,"
> https://factorable.net/paper.html. See Section 5 where the analysis
> occurs and 5.1, "Weak entropy and the Linux RNG".

What I said, the consequences of entropy starvation and ignoring the
starvation.

> If I go to https://www.wisemo.com, I initiated that connection so its
> not under control of an attacker). The exchange contains some random
> (but public) data - namely, Wisemo's public key. A passive attacker on
> the public internet may be able to observe the exchange. So we can
> improve entropy in the generator at the cost of leaking information
> about state input.

And what if (hypothetically speaking) I had doctored that public key
to negatively affect the entropy of some well known PRNG when used
with some well known hedging software (I haven't, but you have to
take my word for it).

> If the server is within my logical security boundary (for example, my
> LAN/MAN segment), the attacker probably cannot observe the exchange.
> In this case, I can improve entropy in the generator without the side
> effect of leaking information about state input.

Of cause, I recommend having it within the data center, as the amount
of entropy requested by a server is likely to be a valuable side
channel.

>   Later, when the
> machine goes out on the internet, its quality of random numbers will
> be improved.

Only if your PRNG is secure against a partially known/chosen entropy
attack, not all are.  For instance the PRNG entropy management code
might batch up enough raw entropy for a full PRNG state and then
discard the past state to improve long term forward secrecy, this
would be a great strategy with trusted secret entropy sources, but
fatal if fed large amounts of attacker-known/chosen entropy, as it
would make the state completely known.

> You should join us over at the cryptography mailing list
> (http://lists.randombit.net/mailman/listinfo/cryptography).
>> e.g. by getting it from a hardware RNG
> I personally use an Entropy Key when I need to ensure I have
> sufficient bits to generate a long term key
> (http://www.entropykey.co.uk). I carry it with me in my laptop bag.

I personally try not to let the world know precisely what brand and
version of countermeasures I use, just in case of a 0-day.

> I know of a number of medium and large size enterprises that don't use
> hardware, and rely on the software generator provided by the OS. Those
> enterprises include financial institutions in New York.
> This is a true story. I'm a security architect, and this got pushed to
> the team for risk acceptance. One financial institution was having
> problems with entropy depletion in a virtual environment. The
> appliance was apparently running out, and could not push sufficient
> entropy to its hosts (it was blocking in calls to /dev/random, if I
> recall correctly). The vendor stated we should delete /dev/random and
> then link it to /dev/urandom (or vice versa), so the generator would
> not block.

Yeah, typical incompetent support, and or management forcing the
engineers to provide a quick fix even if only a slower fix is possible.
Happens all the time to safety measures much more important than this.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Need input for Certificate generation

Jeffrey Walton-3
On Sat, Nov 17, 2012 at 10:56 PM,  <[hidden email]> wrote:

> On 16-11-2012 19:57, Jeffrey Walton wrote:
>>
>> Hi Jacob,
>> On Fri, Nov 16, 2012 at 1:22 PM, Jakob Bohm <[hidden email]> wrote:
>>>
>>> On 11/16/2012 3:36 AM, Jeffrey Walton wrote:
>>>>
>>>> ...
>>>> Headless servers, entropy starvation, and rollbacks are a concern in
>>>> modern environments. OpenSSL and other entropy gathers, such as EDG,
>>>> don't account for the later. Its best to take the bull by the horns
>>>> and do it yourself. At minimum, you need to call RAND_add() with
>>>> entropy external to /dev/{u}rand.
>>>
>>> Would you care to elaborate on the following points:
>>> 1. What do you mean by "rollback"
>> Virtual Machine rollback attacks.
> And how would an attacker rollback the victims VM?, an attacker with that
> level of control is already presumably able to access the VMs data,
> storage and execution state directly.
It could happen accidentally by the folks in the data center.

>>> 2. What RNG/PRNG are you referring to as "EDG"
>>
>> EDG is Entropy Gatering Daemon. I was talking to John Steven about it
>> over the summer (John is CTO of Cigital, OWASP member, and part of the
>> project). EDG does not take measure to mitigate rollback attacks.
> Ah, I thought that was called "EGD"
My bad...

...

>> If I go to https://www.wisemo.com, I initiated that connection so its
>> not under control of an attacker). The exchange contains some random
>> (but public) data - namely, Wisemo's public key. A passive attacker on
>> the public internet may be able to observe the exchange. So we can
>> improve entropy in the generator at the cost of leaking information
>> about state input.
> And what if (hypothetically speaking) I had doctored that public key
> to negatively affect the entropy of some well known PRNG when used
> with some well known hedging software (I haven't, but you have to
> take my word for it).
Point taken, but the attacker is not going to control *that* many
machines. Or at least I don't believe he/she can.

...

>> I know of a number of medium and large size enterprises that don't use
>> hardware, and rely on the software generator provided by the OS. Those
>> enterprises include financial institutions in New York.
>> This is a true story. I'm a security architect, and this got pushed to
>> the team for risk acceptance. One financial institution was having
>> problems with entropy depletion in a virtual environment. The
>> appliance was apparently running out, and could not push sufficient
>> entropy to its hosts (it was blocking in calls to /dev/random, if I
>> recall correctly). The vendor stated we should delete /dev/random and
>> then link it to /dev/urandom (or vice versa), so the generator would
>> not block.
> Yeah, typical incompetent support, and or management forcing the
> engineers to provide a quick fix even if only a slower fix is possible.
> Happens all the time to safety measures much more important than this.
I caught a lot of heat for pointing it out (the folks in engineering
had their heart's set on using it), and calling "bullshit" on the
recommendation. I think it was my presentation....

Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]