FIPS Java API provider and non-FIPS provider

Yes. I would recommend not mixing the two where you actually need FIPS
compliance.

Regards,

David

On 27/06/18 10:57, Rhuberg,Anthony wrote:
>  So taking a step back from the Fips and non Fios bouncy castle
> versions, it appears you would recommend regardless of the crypto
> provider we should not mix Fips and non Fips compliant security
> providers. Is that true? Or is this only an issue because of the
> bouncy castle implementation?
>
> We had considered a Fips only JVM, but started to go down the class
> loader path because it was just easier to implement (easier meeting
> taking last time). 
> ------------------------------------------------------------------------
> *From:* David Hook <dgh-rTAZ0PM/[email protected]>
> *Sent:* Tuesday, June 26, 2018 8:35:22 PM
> *To:* [email protected]
> *Subject:* Re: [dev-crypto] FIPS Java API provider and non-FIPS provider
>  
>
> Yes, I'd say this more of a FIPS friendly solution. We haven't had any
> end users to date that have been happy with the idea of mixing a FIPS
> and non-FIPS API. As an example, if a key object might be used by a
> non-FIPS section of your application you've automatically blown
> compliance - this condition applies to anything recognised in the
> security policy as a critical security parameter (CSP). The BCFIPS API
> does make it possible for FIPS and non-FIPS to exist in different
> threads, but it does this by making sure CSPs can't be used across the
> boundary (it's one of the main reasons why we ended up doing it like we
> did).
>
> The other issue with using the class loader is the JCE is inevitably
> loaded by the system class loader, the chance of a clash still exists as
> a result. You could probably quarantine the classes if you only used the
> FIPS low level API (which would reduce the chance of the system class
> loader trying to interact with the "wrong" one), but it would really be
> better to have a solution that draws a hard line between the FIPS world
> and the non-FIPS world.
>
> As I mentioned earlier as well, if the bcprov dependency is one of the
> latest, there's a good chance migrating everything else to FIPS would
> not be that hard.
>
> Regards,
>
> David
>
> On 27/06/18 08:07, Eckenfels. Bernd wrote:
> > In your case I would put all the sensitive logic to sign and handle
> keys in a dedicated VM and use it via remote call. That not only
> solves the class clash but protects your keys much better, with the
> added benefit of beeing fully compliant with all requirements the FIPS
> provider has to be actually used compliant. You can even limit admin
> access to the key store that way.
> >
> > Class loader tricks do not really work well for registered providers
> since they use the classloader from where they are registered. So it
> May or may not work.
> >
> > Bernd
> > --
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.seeburger.com&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7C6a8aa72c95744cc518ea08d5dbc6474f%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C0%7C636656567036680186&sdata=tFE4Qy84Up917b9%2F1WNVn5kZhEOFf4Y%2BdzsMV5iFN%2BA%3D&reserved=0
> > ________________________________________
> > From: Rhuberg,Anthony [[email protected]]
> > Sent: Tuesday, June 26, 2018 23:22
> > To: David Hook; Eckenfels. Bernd; [email protected]
> > Subject: RE: [dev-crypto] FIPS Java API provider and non-FIPS provider
> >
> > Hi,
> >
> > In our web application deployment within Tomcat, the bcprov.jar is
> loaded by both the common class loader and the web application class
> loader (both by third party dependencies). Our web application has a
> requirement to digitally sign a prescription (which is the reason for
> the FIPS compliant BC Java API). The entire application does not need
> to be FIPS compliant, just one of many workflows.
> >
> > Is the following a reasonable alternative to avoid the package clash?
> >
> >
> >   1.  Stop packaging bc-fips-1.0.1.jar in our web application (WAR)
> – the bcprov will exist in the common class loader and web application
> class loader
> >   2.  bc-fips-1.0.1.jar on the filesystem C:\fipsmodule
> >   3.  Create a URLClassLoader and load bc-fips-1.0.1.jar
> >   4.  Load the BouncyCastleFipsProvider class at runtime
> >
> >     public static final Provider getProvider() throws … {
> >         List<URL> urls = new ArrayList();
> >         for (File f : new File("C:/fipsmodule").listFiles()) {
> >             urls.add(f.toURL());
> >         }
> >         URLClassLoader classLoader = new
> URLClassLoader(urls.stream().toArray(URL[]::new), null);
> >         Provider provider = (Provider) classLoader
> >                
> .loadClass("org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider").newInstance();
> >         return provider;
> >     }
> >
> >     public byte[] sign(KeyStore keystore, String data) throws …{
> >        Signature signature = Signature.getInstance(“SHA256withRSA”,
> getProvider());
> >         signature.initSign((PrivateKey)
> keystore.getKey(getKeyAlias(), getKeystorePassword()));
> >         signature.update(data.getBytes());
> >         return signature.sign();
> >     }
> >
> > Thanks
> >
> > From: David Hook [mailto:dgh-rTAZ0PM/[email protected]]
> > Sent: Friday, June 22, 2018 6:13 PM
> > To: Rhuberg,Anthony <[email protected]>;
> [email protected]; [email protected]
> > Subject: Re: [dev-crypto] FIPS Java API provider and non-FIPS provider
> >
> >
> > Hi,
> >
> > Yes, the FIPS package cannot be changed as it would require
> revalidation, although that's really a financial, not a technical
> restraint.
> >
> > There is a bit more to it though - the jars can't be used in the
> same application as it would make it almost impossible to be sure that
> an application was actually FIPS compliant. You would only need a 3rd
> party library to be calling the BC lightweight API to use a
> non-certified function and it would be all over. So they cannot
> co-exist, it just won't work like that.
> >
> > I'm happy to discuss this further off list, I'd just need a bit more
> background on what you're trying to do.
> >
> > Regards,
> >
> > David
> >
> > On 22/06/18 23:48, Rhuberg,Anthony wrote:
> > Hi,
> >
> > I appreciate your help trying to resolve this conflict.
> >
> > Also, forgive my persistence.
> >
> > We require a FIPS compliant/validated crypto module. I do not think
> “spongycastle-like” is an alternative. We are including both jars
> because some of our third parties already require use of the non-FIPS
> compliant jar (not something we can readily change). If I understand
> this correctly, the conflict seems to be an issue with common classes
> in either the bcfips and bcprov jars that contain the same classes
> with different implementations (that are causing the name clashes). If
> these jars are never intended to be integrated with the same
> application, I suppose I understand that limitation, but that probably
> makes it impossible to use the bcfips jar when other third parties
> (out of our/your control) use the non-fips version.
> >
> > Can the FIPS package not be changed because that would require it to
> be revalidated (by CMVP) ? What would be the effort necessary for both
> the bcfips and bcprov to coexist? Maybe we could discuss this offline.
> >
> > Respectfully,
> > Tony
> >
> >
> > From: David Hook [mailto:dgh-rTAZ0PM/[email protected]]
> > Sent: Thursday, June 21, 2018 4:22 AM
> > To: Rhuberg,Anthony
> <[email protected]><mailto:[email protected]>;
> [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>
> > Subject: Re: [dev-crypto] FIPS Java API provider and non-FIPS provider
> >
> >
> > The FIPS package can't be changed. You could do a "spongycastle" on
> the original Bouncy Castle ones.
> >
> > The FIPS library doesn't have an implementation of the low-level BC
> library. From a FIPS point of view the low-level API breaks most of
> the existing rules, and probably a couple they did not consider.
> >
> > Providers can certainly co-exist, but package name clashes (at least
> in the system class loader) are right out.
> >
> > Regards,
> >
> > David
> >
> > On 21/06/18 06:33, Rhuberg,Anthony wrote:
> > Is it possible or an option to change the package names of bouncy
> castle fips implementation? Changing the name would create a
> independent provider that would not conflict with any other providers.
> >
> > ________________________________
> > From: Rhuberg,Anthony
> <[email protected]><mailto:[email protected]>
> > Sent: Wednesday, June 20, 2018 3:49:52 PM
> > To: [email protected]<mailto:[email protected]>;
> [email protected]<mailto:[email protected]>
> > Subject: RE: [dev-crypto] FIPS Java API provider and non-FIPS provider
> >
> > Thanks for the clarification. I found at least one class in the same
> package with a different implementation in bc-fips than bcprov. I am
> not sure that affects our workflow, but it explains the conflict.
> >
> >
> > -----Original Message-----
> > From: Eckenfels. Bernd [mailto:[email protected]]
> > Sent: Wednesday, June 20, 2018 3:19 PM
> > To: [email protected]<mailto:[email protected]>
> > Subject: RE: [dev-crypto] FIPS Java API provider and non-FIPS provider
> >
> > The problem is that BC and BcFiPS have conflicting implementation
> classes. There is some logic to that (be a plugin replacement), but
> overall it seems to hurt more than it helps. Maybe it would be a
> option to offer a FIPS jar with distinct namespace for those cases.
> >
> > --
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.seeburger.com&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7C0480b4cbfcff443e0de708d5d6e2ba56%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636651191659833148&sdata=fCAqTqOTcglZ49cyLIA6HCPBiNEp3g4i9Ijydu9sXbo%3D&reserved=0
> > ________________________________________
> > From: Rhuberg,Anthony
> [[email protected]<mailto:[email protected]>]
> > Sent: Wednesday, June 20, 2018 20:58
> > To: David Hook; Matti Aarnio;
> [email protected]<mailto:[email protected]>
> > Subject: RE: [dev-crypto] FIPS Java API provider and non-FIPS provider
> >
> > Hi again,
> >
> > I am trying to understand the conflict further and am not really
> familiar with JCA/JCE.
> >
> > If both JCE providers 'bcprov´and 'bcfips' are loaded into the same
> class loader, I do not understand the conflict if they both have
> different provider names and implementation classes. If I request a
> Signature.getinstance("SHA256withRSA", "BCFIPS"), would I not get the
> bcfips implementation and NOT the bcprov instance?
> >
> > Can multiple JCE providers be deployed within an application and the
> application decide which implementation to use without conflict? I
> guess I am expecting providers to coexist.
> >
> > Is this conflict a BC conflict only? I am asking because if we
> selected another JCE provider (to get around this issue) and still
> have bcprov in the same class loader, would we still have a similar
> conflict between another provider and bcprov?
> >
> > Thanks again,
> > Tony
> >
> > From: David Hook [mailto:dgh-rTAZ0PM/[email protected]]
> > Sent: Tuesday, June 19, 2018 6:18 PM
> > To: Rhuberg,Anthony
> <[email protected]><mailto:[email protected]>; Matti
> Aarnio <[email protected]><mailto:[email protected]>;
> [email protected]<mailto:[email protected]>
> > Subject: Re: [dev-crypto] FIPS Java API provider and non-FIPS provider
> >
> >
> > The high risk element is the JCE - it depends how it gets loaded and
> if both things make use of the respective providers. Often this means
> things end up in the system class loader and in that case there can be
> only one.
> >
> > If bcprov isn't loaded in the system class loader and/or bc-fips is
> able to satisfy the dependency anyway, you will probably be okay.
> >
> > General the problems you see if it is an issue don't make sense.
> You'll get issues with undefined methods, class not found, missing
> fields. In some cases you will get class cast exceptions where it
> seems impossible as well.
> >
> > If you want to ask the OpenSAML guys to talk to us we would be happy
> to help them update.
> >
> > Regards,
> >
> > David
> >
> > On 20/06/18 05:04, Rhuberg,Anthony wrote:
> > Just a follow up from my previous question.
> >
> > We have a configuration with a Tomcat Valve which uses opensaml
> (with a dependency on xmlsec -> bcprov-jdk15on). These classes are
> part of the root class loader (call it CLroot).
> > We just started using bc-fips-1.0.1.jar for digital signatures in a
> web application. That jar is part of the war (call it CL1).
> >
> > Based on this configuration, we expected to observe some conflict
> when executing the pathways for the Tomcat Valve and web application.
> >
> > The applications are "working", but worry that there is some unseen
> or potential problem that we have just not encountered.
> >
> > Any thoughts? Do you have an examples of how a collision (between
> the 2 jars bcprov-jdk15on - bc-fips-1.0.1.jar ) would be manifest? Do
> you have examples of typical errors when there is a conflict?
> >
> > Thanks,
> > Tony
> >
> >