karanpopali | 24 Sep 23:23 2013
Picon

FIPS OpenSSL default DRBG continuous test failing

I'm using FIPS OpenSSL on Android and it FIPS_rand_bytes() fails continuous
test after sometime. I read in the SecurityPolicy that if it fails then we
need to uninstantiate and re-instantiate the DRBG.

Few questions:
1. Is there any way to avoid this? Will using HMAC DRBG or Hash DRBG help?
2. Is this a FATAL error?
3. If we hit this error, do we need to restart the process or just
uninstantiate/re-instantiate is enough?

Version info:
FIPS canister: 2.0.1
OpenSSL: 1.0.1c

Thanks,
Karan

--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-default-DRBG-continuous-test-failing-tp46646.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

David Jacobson | 25 Sep 18:34 2013
Picon
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

According to FIPS 140, the continuous test fails if two consecutive 
values from the RNG are the same. No matter how strange or low-entropy 
the seeding, this should happen only with vanishingly small 
probability.  So something is seriously wrong.  You absolutely should 
not try to work around this.  You must find the root cause and fix it.

Also you imply that this is repeatable.  Are the failures exactly 
repeatable?  If so, this would suggest that you have no entropy at all.

     --David

On 9/24/13 2:23 PM, karanpopali wrote:
> I'm using FIPS OpenSSL on Android and it FIPS_rand_bytes() fails continuous
> test after sometime. I read in the SecurityPolicy that if it fails then we
> need to uninstantiate and re-instantiate the DRBG.
>
> Few questions:
> 1. Is there any way to avoid this? Will using HMAC DRBG or Hash DRBG help?
> 2. Is this a FATAL error?
> 3. If we hit this error, do we need to restart the process or just
> uninstantiate/re-instantiate is enough?
>
> Version info:
> FIPS canister: 2.0.1
> OpenSSL: 1.0.1c
>
> Thanks,
> Karan
>
>
(Continue reading)

Karan Popali | 25 Sep 19:10 2013
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

Thanks David.

If I use the default DRBG, do I need to set the entropy?

-Karan


On Wed, Sep 25, 2013 at 9:34 AM, David Jacobson <dmjacobson <at> sbcglobal.net> wrote:
According to FIPS 140, the continuous test fails if two consecutive values from the RNG are the same. No matter how strange or low-entropy the seeding, this should happen only with vanishingly small probability.  So something is seriously wrong.  You absolutely should not try to work around this.  You must find the root cause and fix it.

Also you imply that this is repeatable.  Are the failures exactly repeatable?  If so, this would suggest that you have no entropy at all.

    --David

On 9/24/13 2:23 PM, karanpopali wrote:
I'm using FIPS OpenSSL on Android and it FIPS_rand_bytes() fails continuous
test after sometime. I read in the SecurityPolicy that if it fails then we
need to uninstantiate and re-instantiate the DRBG.

Few questions:
1. Is there any way to avoid this? Will using HMAC DRBG or Hash DRBG help?
2. Is this a FATAL error?
3. If we hit this error, do we need to restart the process or just
uninstantiate/re-instantiate is enough?

Version info:
FIPS canister: 2.0.1
OpenSSL: 1.0.1c

Thanks,
Karan



--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-default-DRBG-continuous-test-failing-tp46646.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org



David Jacobson | 26 Sep 05:28 2013
Picon
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

I'm an expert on random number generators and knowledgeable about FIPS 140.  But I'm not knowledegable about the RNG facilities on OpenSSL.  In general you don't "set" the entropy, rather you set up an entropy source.  However, some systems do allow running on a fixed input string.  But the design of the system needs to combine that with some other things like date&time, processor serial number, etc., that together make a value that will never occur more than once.

    --David

On 9/25/13 10:10 AM, Karan Popali wrote:
Thanks David.

If I use the default DRBG, do I need to set the entropy?

-Karan


On Wed, Sep 25, 2013 at 9:34 AM, David Jacobson <dmjacobson <at> sbcglobal.net> wrote:
According to FIPS 140, the continuous test fails if two consecutive values from the RNG are the same. No matter how strange or low-entropy the seeding, this should happen only with vanishingly small probability.  So something is seriously wrong.  You absolutely should not try to work around this.  You must find the root cause and fix it.

Also you imply that this is repeatable.  Are the failures exactly repeatable?  If so, this would suggest that you have no entropy at all.

    --David

On 9/24/13 2:23 PM, karanpopali wrote:
I'm using FIPS OpenSSL on Android and it FIPS_rand_bytes() fails continuous
test after sometime. I read in the SecurityPolicy that if it fails then we
need to uninstantiate and re-instantiate the DRBG.

Few questions:
1. Is there any way to avoid this? Will using HMAC DRBG or Hash DRBG help?
2. Is this a FATAL error?
3. If we hit this error, do we need to restart the process or just
uninstantiate/re-instantiate is enough?

Version info:
FIPS canister: 2.0.1
OpenSSL: 1.0.1c

Thanks,
Karan



--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-default-DRBG-continuous-test-failing-tp46646.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org




nehakochar | 28 Sep 00:10 2013
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

Hi,

I've run into this error too, but is seen intermittently in my case during
regression when there is a lot of traffic, meaning a lot of invocations to
OpenSSL's DRBG.

What could be the possible causes of the continuous RNG test to fail for the
default DRBG in FIPS-mode?
My first guess was low entropy and I was thinking in the direction of
feeding more entropy into kernel's pool but David's post says "No matter how
strange or low-entropy the seeding, this should happen only with vanishingly
small probability.", and "But the design of the system needs to combine that
with some other things like date&time, processor serial number, etc., that
together make a value that will never occur more than once.". I understand
and agree with these statements, but still trying to understand the real
cause of this failure.

Also, I saw that DRBG is fed entropy only at initialization (done once once)
and reseed. And the reseed interval for the default DRBG (NID_aes_256_ctr)
is 2^24. So, unless this failure is happening at reseed time (which I
haven't verified yet), the entropy shouldn't be directly related to this
failure. Please correct me if my understanding is not accurate.

Thanks,
Neha.

--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-default-DRBG-continuous-test-failing-tp46646p46693.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Dr. Stephen Henson | 28 Sep 14:34 2013
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

On Fri, Sep 27, 2013, nehakochar wrote:

> 
> What could be the possible causes of the continuous RNG test to fail for the
> default DRBG in FIPS-mode?

It should never happen in practice unless something bad has happened such as
memory corruption. For example there is a variable which simulates a failure
of the test which might be overwritten if something writes over memory.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

nehakochar | 1 Oct 03:15 2013
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

> It should never happen in practice unless something bad has happened such
as
> memory corruption. For example there is a variable which simulates a
> failure
> of the test which might be overwritten if something writes over memory.

It is not memory corruption from what I see. I had added a log when memcmp
would fail, and that's what I see. So, the memcmp is indeed failing.

Is this DRBG code thread-safe? If it isn't, then that could be the cause.

Thanks,
Neha.

--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-default-DRBG-continuous-test-failing-tp46646p46711.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Dr. Stephen Henson | 1 Oct 12:39 2013
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

On Mon, Sep 30, 2013, nehakochar wrote:

> > It should never happen in practice unless something bad has happened such
> as
> > memory corruption. For example there is a variable which simulates a
> > failure
> > of the test which might be overwritten if something writes over memory.
> 
> It is not memory corruption from what I see. I had added a log when memcmp
> would fail, and that's what I see. So, the memcmp is indeed failing.
> 

Can it happen soon after start up or does it seems to require a large number
of operations before it happens? I'm wondering if it might be associated with
reseeding.

> Is this DRBG code thread-safe? If it isn't, then that could be the cause.
> 

It should be thread safe if the locks are set properly. The generation
operation takes place under CRYPTO_LOCK_RAND. If the locking doesn't work
properly then race conditions could corrupt the internal state which might
cause what you are seeing.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

nehakochar | 8 Oct 02:11 2013
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

I solved it. It was an issue with the way my application had to use the
OpenSSL globals for appropriate application threading environment.
Thank you Steve for answering my questions promptly.

--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-default-DRBG-continuous-test-failing-tp46646p46798.html
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Dr. Stephen Henson | 9 Oct 16:15 2013
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

On Mon, Oct 07, 2013, nehakochar wrote:

> I solved it. It was an issue with the way my application had to use the
> OpenSSL globals for appropriate application threading environment.
> Thank you Steve for answering my questions promptly.
> 

Thank you for the update. I'm very relieved it isn't a problem in the module
itself, fixing that would've been rather irksome.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

karanpopali | 13 Oct 01:20 2013
Picon

Re: FIPS OpenSSL default DRBG continuous test failing

In my application, I've two major components which access the random generator (one is database module and other one is JNI wrapper used by Java). Therefore I think this issue is some synchronization issue.

I wrote a test app to try to reproduce the problem in multithreaded environment. And this test app crashes with FIPS_SELFTEST_FAILED error. Here's the code snippet:

<snip>
#define COUNT 300
#define THREAD_COUNT 8

void *drbg_test(void *dummy) {
    PRINT("DRBG test called");
    int i;
    int result = 0;
    int length = 16;
    unsigned char *output;
    output = new unsigned char[length];

    for (i = 0; i < COUNT; i++) {
        result = FIPS_rand_bytes(output, length);
        if (result != 1) {
            printError("RAND_bytes failed");
            abort();
        }
    }

    PRINT("DRBG test complete");

    return 0;
}

void runDRBGTest() {
    int i;

    pthread_t *threads = new pthread_t[THREAD_COUNT];

    // first thread
    pthread_create(&(threads[0]), NULL, drbg_test, NULL);
    pthread_join(threads[0], NULL);

    for (i = 1; i < THREAD_COUNT; i++) {
        PRINT("Creating thread");
        pthread_create(&(threads[i]), NULL, drbg_test, NULL);
    }
}
<snip>

I'm testing this on Android device. If I change COUNT to 100, and call the runDRBGTest method 3 times continuously, then it crashes.

I'll try to reproduce the continuous test issue.

Thanks,
Karan


On Wed, Oct 9, 2013 at 7:16 AM, Dr. Stephen Henson [via OpenSSL] <[hidden email]> wrote:
On Mon, Oct 07, 2013, nehakochar wrote:

> I solved it. It was an issue with the way my application had to use the
> OpenSSL globals for appropriate application threading environment.
> Thank you Steve for answering my questions promptly.
>

Thank you for the update. I'm very relieved it isn't a problem in the module
itself, fixing that would've been rather irksome.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]


If you reply to this email, your message will be added to the discussion below:
http://openssl.6102.n7.nabble.com/FIPS-OpenSSL-default-DRBG-continuous-test-failing-tp46646p46818.html
To unsubscribe from FIPS OpenSSL default DRBG continuous test failing, click here.
NAML


View this message in context: Re: FIPS OpenSSL default DRBG continuous test failing
Sent from the OpenSSL - Dev mailing list archive at Nabble.com.

Gmane