Hi Jacob,
Thanks for such a detailed reply. But I am having one concern that how
an application can know whether it si secure or not. Fips uses
GetSystemTimeAsFileTime() for PRNG test which is having granuality of 1 ns,
but my application is running even at faster rate so same value is being
generated for current as well as for last request. Is there any provision
inside Openssl which ensures that unique randon numbers will be generated or
application need to add some delay for each new connection request.
Regards,
Alok
On Thu, Sep 15, 2011 at 6:02 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:
> On 9/14/2011 6:33 PM, alok sharma wrote:
>
>> Hi,
>> I am having my client server on Windows. The server is concurrent
>> and
>> having each thread for each connection. When the number of connection
>> increases to 400-500 i.e having high thread load, my server crashes. I
>> debuged it and found that it gives error (“random number
>> generator:FIPS_RAND:prng error") when it tries to invoke SSL_accept(). My
>> server is Fips compliant. I looked furthur inside openssl code and found
>> issue with fips_rand() method (fips/rand/fips_rand.c). Following is my
>> observation.
>> The error is generated at following point
>> fips_rand()
>> {
>> .............................
>> ............................
>>
>> if (!ctx->test_mode)
>> fips_get_dt(ctx);
>> AES_encrypt(ctx->DT, I,&ctx->ks);
>> for (i = 0; i< AES_BLOCK_LENGTH; i++)
>> tmp[i] = I[i] ^ ctx->V[i];
>> AES_encrypt(tmp, R,&ctx->ks);
>> for (i = 0; i< AES_BLOCK_LENGTH; i++)
>> tmp[i] = R[i] ^ I[i];
>> AES_encrypt(tmp, ctx->V,&ctx->ks);
>> /* Continuous PRNG test */
>> if (ctx->second)
>> {
>> if (fips_prng_fail){
>> memcpy(ctx->last, R, AES_BLOCK_LENGTH);
>>
> The above line may cause the next test to fail too if "fips_prng_fail" was
> set by something else.
>
> RANDerr(RAND_F_FIPS_RAND,RAND_
>> R_PRNG_STUCK);
>> }
>> if (!memcmp(R, ctx->last, AES_BLOCK_LENGTH))
>> <-----------------------------**-------------- The check is failing as
>> the
>> current encrypted and last one are same
>> {
>> RANDerr(RAND_F_FIPS_RAND,RAND_**R_PRNG_STUCK);
>> ctx->error = 1;
>> fips_set_selftest_fail();
>> return 0;
>> }
>> }
>> memcpy(ctx->last, R, AES_BLOCK_LENGTH);
>> ..............................**..............................**
>> ...........
>> ..............................**..............................**
>> ..........
>>
>> }
>>
>> I think under heavy load openssl continous PRNG test is failing. It might
>> be
>> generating the same values as it applies AES encryption over the data
>> taken
>> from fips_get_dt(ctx).
>>
> Yes, that is (technically) how the code tests if the RNG is failing badly.
> This is a symptom, not a cause.
> The chance of this happening if the RNG is good for anything is
> 1 in 2**128 per test run, thus very unlikely, the chance of this happening
> more
> than once on the same (working) computer is astronomically small.
>
> So the real problem is that this self-test seems to have found an actual
> security problem. Running this kind of test to discover such security
> problems is a FIPS requirement.
>
> What the error is apparently saying is that the PRNG as running on your
> machine is *not* FIPS quality and must not be used for any government
> work (and probably not for anything else either!).
>
> For windows platform this function takes
>> GetSystemTimeAsFileTime(). like
>> ..........
>> .........
>> #ifdef OPENSSL_SYS_WIN32
>> GetSystemTimeAsFileTime(&ft);
>> buf[0] = (unsigned char) (ft.dwHighDateTime& 0xff);
>> buf[1] = (unsigned char) ((ft.dwHighDateTime>> 8)& 0xff);
>> buf[2] = (unsigned char) ((ft.dwHighDateTime>> 16)& 0xff);
>> buf[3] = (unsigned char) ((ft.dwHighDateTime>> 24)& 0xff);
>> buf[4] = (unsigned char) (ft.dwLowDateTime& 0xff);
>> buf[5] = (unsigned char) ((ft.dwLowDateTime>> 8)& 0xff);
>> buf[6] = (unsigned char) ((ft.dwLowDateTime>> 16)& 0xff);
>> buf[7] = (unsigned char) ((ft.dwLowDateTime>> 24)& 0xff);
>> .........................
>> .........................
>>
> If this is the only PRNG seeding used on your machine, then your setup
> is very insecure. As a bare minimum you should make sure the code that
> grabs entropy from the Windows CryptoAPI PRNG (which is also FIPS
> certified) is also enabled.
>
> This seeding source is not very random at all, and it is only a (short)
> matter
> of time before it will produce something so predictable it should not pass
> any
> quality tests, including FIPS tests.
>
>
>
>> Please help in this regard. I am using openssl version 0.9.8o.
>> Regards,
>> Alok
>>
>>
> ______________________________**______________________________**__________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
