BC FIPS enabled mode show less supported ciphers than doc claimed.

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

BC FIPS enabled mode show less supported ciphers than doc claimed.

HC Ping
Hello,

I was not able to find fip email list, so pasting here.

I am using bcfips/bcjsse provider.
  Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);
  Security.insertProviderAt(new BouncyCastleJsseProvider("fips:BCFIPS"), 2);

With RSA key and certificate Signature Algorithm sha256WithRSAEncryption, with fips I saw only 4 TLS_ECDHE_RSA_xxx ciphers:
  TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

But according to https://downloads.bouncycastle.org/fips-java/BC-FJA-(D)TLSUserGuide-1.0.0.pdf, I think those TLS_RSA_WITH_xxx should also be OK, such as TLS_RSA_WITH_AES_256_CBC_SHA256. Any idea why I didn't see it? Anyway to turn it on?

Thanks
Huican
Reply | Threaded
Open this post in threaded view
|

Re: BC FIPS enabled mode show less supported ciphers than doc claimed.

David Hook-3

The cipher suites available in FIPS mode are dictated by:

https://csrc.nist.gov/publications/detail/sp/800-52/rev-1/final

You'll find the acceptable ones in Section 3.3.1 starting on page 14.

I think BC provides full coverage, other than the GCM ones which can't
be supported. The additional RSA ones are not on the accepted list
though, so that is why they are missing.

Regards,

David

On 26/10/18 6:01 am, HC Ping wrote:

> Hello,
>
> I was not able to find fip email list, so pasting here.
>
> I am using bcfips/bcjsse provider.
>   Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);
>   Security.insertProviderAt(new
> BouncyCastleJsseProvider("fips:BCFIPS"), 2);
>
> With RSA key and certificate Signature Algorithm
> sha256WithRSAEncryption, with fips I saw only 4 TLS_ECDHE_RSA_xxx ciphers:
>   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
>   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>
> But according to
> https://downloads.bouncycastle.org/fips-java/BC-FJA-(D)TLSUserGuide-1.0.0.pdf,
> I think those TLS_RSA_WITH_xxx should also be OK, such as
> TLS_RSA_WITH_AES_256_CBC_SHA256. Any idea why I didn't see it? Anyway
> to turn it on?
>
> Thanks
> Huican



Reply | Threaded
Open this post in threaded view
|

Re: BC FIPS enabled mode show less supported ciphers than doc claimed.

David Hook-3

Okay, that's quite a good question...

So there are two parts to the story.

The first part is that it's really bad to reuse an IV with the same GCM
key.

The way this is addressed in FIPS 140-2 is by having some conditions
that need to be met when a GCM implementation is certified and also by
adding some guidance to the security policy about how the GCM
implementation can be used. The long and short of this is that a GCM IV
must be created within the boundary of the module, the intention of this
seems to be that the certifying lab should be able to verify that the IV
creation, if being generated using a sequential generator, will never
repeat.

The second part is that TLS provides a mechanism for generating IVs so
they don't repeat, however in most worlds this is implemented in the
protocol layer, which is outside the boundary of the module.

The result of this is that generally there's no way of certifying the
generator, without moving the whole TLS implementation to within the
boundary. You can't just do what is done with the JSSE Provider FIPS
mode, where you can justify the claim of compliance on the basis that
everything related to the crypto is outsourced to the underlying JCE
provider (which presumably is FIPS certified) - the GCM IV is calculated
too high up.

Consequently at the moment most of us can't support GCM as we can't
generate the IV in a manner that's within the FIPS guidelines. Getting
something changed once you certify a module is expensive and time
consuming (for everyone) so for those of us with layered implementations
such as you have in Java and C#, moving the TLS implementation into the
boundary of a FIPS module would be the path to insanity - you only have
to look at some of the issues which have shown up in TLS in the last
couple of years. We've also all just started on the adventure that is
TLS 1.3 as well, it is not hard to see the fun that would cause.

NIST have revised the guidance on this a couple of times now, we think
in the most recent revision the guidance is finally where we can provide
a mechanism within the module boundary which can be used by our TLS API
safely, while still providing a testing lab with the ability to ensure
we're "walking the talk". We're going to include this in 1.0.2, but for
now 1.0.1 and 1.0.0 are not capable of supporting GCM with the JSSE.

I hope that explains it.

Regards,

David

On 27/10/18 3:16 am, Jon Moroney wrote:

> Sorry to butt in, but why can’t GCM modes be supported?
>
>> On Oct 25, 2018, at 8:34 PM, David Hook <[hidden email]> wrote:
>>
>>
>> The cipher suites available in FIPS mode are dictated by:
>>
>> https://csrc.nist.gov/publications/detail/sp/800-52/rev-1/final
>>
>> You'll find the acceptable ones in Section 3.3.1 starting on page 14.
>>
>> I think BC provides full coverage, other than the GCM ones which can't
>> be supported. The additional RSA ones are not on the accepted list
>> though, so that is why they are missing.
>>
>> Regards,
>>
>> David
>>
>> On 26/10/18 6:01 am, HC Ping wrote:
>>> Hello,
>>>
>>> I was not able to find fip email list, so pasting here.
>>>
>>> I am using bcfips/bcjsse provider.
>>>   Security.insertProviderAt(new BouncyCastleFipsProvider(), 1);
>>>   Security.insertProviderAt(new
>>> BouncyCastleJsseProvider("fips:BCFIPS"), 2);
>>>
>>> With RSA key and certificate Signature Algorithm
>>> sha256WithRSAEncryption, with fips I saw only 4 TLS_ECDHE_RSA_xxx ciphers:
>>>   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
>>>   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>>>   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
>>>   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
>>>
>>> But according to
>>> https://downloads.bouncycastle.org/fips-java/BC-FJA-(D)TLSUserGuide-1.0.0.pdf,
>>> I think those TLS_RSA_WITH_xxx should also be OK, such as
>>> TLS_RSA_WITH_AES_256_CBC_SHA256. Any idea why I didn't see it? Anyway
>>> to turn it on?
>>>
>>> Thanks
>>> Huican
>>
>>
>