BCFIPS 1.0.2 MAKING BLOCKING CALLS ON ENTROPY

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

BCFIPS 1.0.2 MAKING BLOCKING CALLS ON ENTROPY

Deepak Ladha
This post was updated on .
Hi,

We are planning to do bcfips version rollup for our product as below -
bc-fips: 1.0.1 => 1.0.2
bc-fips-pkix: 1.0.1 => 1.0.3

During the version roll up validation, we have observed that the product
processes that internally consume bcfips APIs were either failing to start
or taking much longer in comparison to prior bcfips version.

On a server (so far we have tried VMs only), when the product was installed
with v1.0.1 jars, everything worked well. No issue was seen with the
processes that consume bcfips APIs. On the same server, when the versions
were rolled up, these processes failed to start up. We found out that there
were blocking calls (/dev/random) for entropy and because the server had low
entropy, processes were not starting up.

On a separate server with entropy in range > 3K, we have not seen processes
startup issue yet with the newer jars.

So, as per our findings, newer bcfips jars use blocking calls (/dev/random)
for entropy, and on servers with lower entropy it is hitting the issue /
getting exposed.

We have tried passing following jvm argument but it has not helped -
     -Djava.security.egd=file:/dev/urandom

Following the user guide troubleshooting section, we have also tried adding
configuration string to provider in java.security file but that has not
worked either -    
       security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider C:HYBRID;ENABLE{All}

Can anyone suggest how to address the issue of blocking calls with newer
bcfips jars on server with lower entropy ?

Java.security
---------------
# /dev/urandom is required for performance on Linux
securerandom.source=file:/dev/urandom
java.security.egd=file:/dev/urandom

# The list of providers required.
security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
C:HYBRID;ENABLE{All}
security.provider.2=com.sun.net.ssl.internal.ssl.Provider BCFIPS
security.provider.3=sun.security.provider.Sun

JDK
----
OpenJDK Zulu 8


Thanks,
Deepak



--
Sent from: http://bouncy-castle.1462172.n4.nabble.com/Bouncy-Castle-Dev-f1462173.html

Reply | Threaded
Open this post in threaded view
|

Re: BCFIPS 1.0.2 MAKING BLOCKING CALLS ON ENTROPY

David Templar-2
Hi,

Just my comments on playing with 1.0.2 - had a few issues on my server (2019 ) and Desktop till refresh and change of Java SDK.

If you use Android... Well it does work... but....

Betrer replies will probably come from Mr Hook, or

Mr Dettman and others.  


Kind regards,

David Templar


From: Deepak Ladha <[hidden email]>
Sent: Tuesday, April 21, 2020 7:51:39 PM
To: [hidden email] <[hidden email]>
Subject: [dev-crypto] BCFIPS 1.0.2 MAKING BLOCKING CALLS ON ENTROPY
 
Hi,

We are planning to do bcfips version rollup for our product as below -
bc-fips: 1.0.1 => 1.0.2
bc-fips-pkix: 1.0.1 => 1.0.3

During the version roll up validation, we have observed that the product
processes that internally consume bcfips APIs were either failing to start
or taking much longer in comparison to prior bcfips version.

On a server (so far we have tried VMs only), when the product was installed
with v1.0.1 jars, everything worked well. No issue was seen with the
processes that consume bcfips APIs. On the same server, when the versions
were rolled up, these processes failed to start up. We found out that there
were blocking calls (/dev/random) for entropy and because the server had low
entropy, processes were not starting up.

On a separate server with entropy in range > 3K, we have not seen processes
startup issue yet with the newer jars.

So, as per our findings, newer bcfips jars use blocking calls (/dev/random)
for entropy, and on servers with lower entropy it is hitting the issue /
getting exposed.

We have tried passing following jvm argument but it has not helped -
     -Djava.security.egd=file:/dev/urandom

Following the user guide troubleshooting section, we have also tried adding
configuration string to provider in java.security file but that has not
worked either -
   
security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
C:HYBRID;ENABLE{All}


Can anyone suggest how to address the issue of blocking calls with newer
bcfips jars on server with lower entropy.

Java.security
---------------
# /dev/urandom is required for performance on Linux
securerandom.source=file:/dev/urandom
java.security.egd=file:/dev/urandom

# The list of providers required.
security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
C:HYBRID;ENABLE{All}
security.provider.2=com.sun.net.ssl.internal.ssl.Provider BCFIPS
security.provider.3=sun.security.provider.Sun


Thanks,
Deepak



--
Sent from: http://bouncy-castle.1462172.n4.nabble.com/Bouncy-Castle-Dev-f1462173.html

Reply | Threaded
Open this post in threaded view
|

Re: BCFIPS 1.0.2 MAKING BLOCKING CALLS ON ENTROPY

David Hook-3
In reply to this post by Deepak Ladha
Hi,

Something is not right about this, BC-FJA has used /dev/random since 1.0.0

First thing I'd recommend is enable hardware RNG if you can, most
virtual environments now support it. On Linux this usually means
installing rng-tools.

Second thing, if you're going to use /dev/urandom keep in mind it is not
FIPS compliant (I know there are arguments about how good/bad it is one
way or the other, however NIST are not currently inviting comment on
this matter).

Third, if C:HYBRID;ENABLE{All} does not make a difference, does the
application import a large number of RSA keys on startup by chance?

Thanks,

David

On 22/4/20 4:51 am, Deepak Ladha wrote:

> Hi,
>
> We are planning to do bcfips version rollup for our product as below -
> bc-fips: 1.0.1 => 1.0.2
> bc-fips-pkix: 1.0.1 => 1.0.3
>
> During the version roll up validation, we have observed that the product
> processes that internally consume bcfips APIs were either failing to start
> or taking much longer in comparison to prior bcfips version.
>
> On a server (so far we have tried VMs only), when the product was installed
> with v1.0.1 jars, everything worked well. No issue was seen with the
> processes that consume bcfips APIs. On the same server, when the versions
> were rolled up, these processes failed to start up. We found out that there
> were blocking calls (/dev/random) for entropy and because the server had low
> entropy, processes were not starting up.
>
> On a separate server with entropy in range > 3K, we have not seen processes
> startup issue yet with the newer jars.
>
> So, as per our findings, newer bcfips jars use blocking calls (/dev/random)
> for entropy, and on servers with lower entropy it is hitting the issue /
> getting exposed.
>
> We have tried passing following jvm argument but it has not helped -
>      -Djava.security.egd=file:/dev/urandom
>
> Following the user guide troubleshooting section, we have also tried adding
> configuration string to provider in java.security file but that has not
> worked either -
>    
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> C:HYBRID;ENABLE{All}
>
>
> Can anyone suggest how to address the issue of blocking calls with newer
> bcfips jars on server with lower entropy.
>
> Java.security
> ---------------
> # /dev/urandom is required for performance on Linux
> securerandom.source=file:/dev/urandom
> java.security.egd=file:/dev/urandom
>
> # The list of providers required.
> security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider
> C:HYBRID;ENABLE{All}
> security.provider.2=com.sun.net.ssl.internal.ssl.Provider BCFIPS
> security.provider.3=sun.security.provider.Sun
>
>
> Thanks,
> Deepak
>
>
>
> --
> Sent from: http://bouncy-castle.1462172.n4.nabble.com/Bouncy-Castle-Dev-f1462173.html
>