RE: 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]
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]]
Sent: Wednesday, June 20, 2018 20:58
To: David Hook; Matti Aarnio; [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]>; Matti Aarnio <[email protected]>; [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


From: Matti Aarnio [mailto:[email protected]]
Sent: Tuesday, June 05, 2018 2:33 PM
To: Rhuberg,Anthony <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: Re: [dev-crypto] FIPS Java API provider and non-FIPS provider

Hi Tony,

The detail that affects more than "in same JVM" is "are they in same class loader?"

WARs are loaded into separate class loader chains.
WAR1 gets loader chain:  CL1, CLroot.
WAR2 gets loader chain:  CL2, CLroot.

If neither BCFIPS nor BCPROV are in CLroot, and instead in separate WARs, then the libraries will not see each other, and no collision happens.

The "CLroot" is server/lib/ in current Tomcats.
The "CLn" is webapps/warname/WEB-INF/lib/

Best Regards, Matti

On 05.06.2018 21:01, Rhuberg,Anthony wrote:

We have an application deployed within Tomcat and that application is uses Apache CXF which has a dependency on bcprov-jdk15on-1.51.

Referring to: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bouncycastle.org%2Ffips-java%2FBCFipsIn100.pdf&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7C0480b4cbfcff443e0de708d5d6e2ba56%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636651191659833148&sdata=Uu0MQygo4cUAhLyJarXP1W30tz1sEcvY2u9N993brcY%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bouncycastle.org%2Ffips-java%2FBCFipsIn100.pdf&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7Ce60fa34500a84aeb1a7a08d5cb12c856%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636638203905695412&sdata=wmqUcMfgAVX7I2s%2F6rXx2ZCBUnzZZRRMKMBWZXLPR3o%3D&reserved=0>: "The provider jar itself has no external dependencies, but it cannot be used in the same JVM as the regular Bouncy Castle provider. The classes in the two jar files do not get along".

We are integrating FIPS Java API provider into another application WAR. We have not encountered an issues yet, but wanted to know what kinds of errors are expected if two applications use different Bouncy Castle Java implementations within the same JVM.

Thanks,Tony



CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.











SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.seeburger.de&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7C0480b4cbfcff443e0de708d5d6e2ba56%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636651191659833148&sdata=XDo7F4rA%2BTro3va1SqqA9eaq8zlVomq%2BY5RLMdVGYSI%3D&reserved=0               Registergericht/Commercial Register:
e-mail: [email protected]               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.