[QUERY] Does Azure Java SDK support FIPS

[dkirrane]

Query/Question

I'm looking at client side encryption. https://docs.microsoft.com/en-us/azure/storage/common/storage-client-side-encryption-java

Is there any documentation on how to setup the Azure SDK to be FIPS compliant? We use BouncyCastle FIPS - BCFIPS.

Why is this not a Bug or a feature Request? Documentation to make the client side encryption FIPS compliant.

Setup (please complete the following information if applicable):

• OS: [e.g. iOS] AKS Pod containing Spring Boot app connecting to Azure Storage
• IDE : [e.g. IntelliJ] IntelliJ

• Version of the Library used: latest

  Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

  • [ ] Query Added
  • [ ] Setup information Added

[joshfree]

@rickle-msft could you please follow up?

[joshfree]

https://docs.microsoft.com/en-us/azure/compliance/offerings/offering-fips-140-2#azure-and-fips-140-2

[rickle-msft]

@dkirrane My apologies. I discussed this with a teammate and then forgot to post our conclusions. My understanding is that FIPS compliance will depend on which implementations (providers) of the encryption algorithms you use in your environment. The SDK does not have a preference for any particular implementation, so we will use whatever the jdk gives us at runtime for the cipher. Therefore, I will say that as long as you guarantee your implementations are FIPS compliant, Storage's client side encryption should be the same.

Please let me know if your understanding differs or if you have further questions.

[gapra-msft]

Closing this as I believe the question has been answered. @dkirrane Please feel free to reopen if you have further questions.

[jhawkins1]

@gapra-msft I think this issue needs to be re-opened. We have a similar requirement that we must use FIPS Certified Cryptography Only. The SDK currently does not appear to meet the requirements, and thus causes a gap for Azure consumers / application developers for FIPS compliance. FIPS is mandated for US Federal and Canada Government Applications, and also a requirement or strong recommendation for other regulated environments. The FIPS requirement is for the paritcular Software Cryptographic Module / Provider being utilized in Java. It is not enough that the cryptography that the Provider/Module is using is a FIPS aligned cipher as eluded to in the discussion thread -- ie, using AES does not make you FIPS. It is not sufficient for the OS that the App is running on is using FIPS crypto. It is all dependent on the Java Crypto Provider being Certified via the NIST CMVP, and it being configured to only operate in FIPS mode. It appears that the SDK uses the Non-FIPS version of Bouncycastle based on the POM Files. I would request the SDK be built with the FIPS version of Bouncycastle and instantiate FIPS Mode per the BouncyCastle FIPS FAQ. This would enable Microsoft Customers / Users of the SDK to be compliant.

[gapra-msft]

@rickle-msft

[rickle-msft]

@jhawkins1 Thank you for this explanation. Can you please point me to the FIPS version of Bouncycastle and the specific section of the FAQ you're referring to?

[jhawkins1]

@rickle-msft BounyCastle FIPS Module available at: https://www.bouncycastle.org/fips-java. The Page will ask you to donate/sponsorship or commercial arrangement, but not required. To get to the Release without donation or commercial contract, select the "I will make a donation towards supporting a future release, or get a support contract, later." Same as the non-FIPS version, the FIPS version is under an MIT open source license.

Once you get past the Donate Page, you will see a Page with the available releases and links to the Binaries (JARs), Source Code (JARs), and Documentation (FIPS Security Policy, Release Notes, UserGuides, Known Issues, etc...). Below the Documentation section is Example Code and a How-to Mini-Book PDF. The usage of BC-FIPS is pretty straightforward. We are using it in various Java Applications in our Products.

[amishra-dev]

@rickle-msft did you have time to look into this?

[jhawkins1]

@rickle-msft , following up on this. Was this actually closed, and the state of the Issue has not been updated? Scanning through Release Notes in May timeframe (based on comments above), I don't see this mentioned?

[jhawkins1]

@rickle-msft , @gapra-msft , @joshfree , don't mean to be a pest, but any status update on this issue?

[rickle-msft]

@jhawkins1 Not to worry. Sorry for our slow response. I am transitioning away from this project, so I will hand this off to @jaschrep-msft and @ibrahimrabab

[jhawkins1]

@jaschrep-msft and @ibrahimrabab any updates on the resolution?

[jaschrep-msft]

@jhawkins1 I'm reading through the literature you've linked and combined with my own understanding of Java's cryptographic framework, and I do not believe we are preventing you from having a FIPS-compliant application. We acquire our crypto instances via Java's cryptographic framework, which can be set by the application developer to provide whatever implementation is desired. You as the end-developer get to choose what providers are available to the JVM in the first place, and thus can ensure only fips-compliant providers are given.

I agree with Rick's initial assessment. It would be improper of us as an SDK to go in and determine a default provider priority, as this would interfere with whatever an end developer was attempting to setup with their own application. You don't find anything in our pom files regarding these packages because determining exact crypto providers is not our concern as an SDK to be used in a larger Java application.

If you disagree with this assessment, I ask you provide the technical specifics as to why you cannot be FIPS compliant with the currently published packages, and what you would expect us to do without forcing our provider selections on other consuming applications.

[jhawkins1]

I will dig into this as this is kind of counter to what we heard on the commercial tech support side from Microsoft.. Tech Support started sending us down the path of implementing some sort of wrapper / extension to do FIPS TLS, which seemed way off base and not something we want to do... We basically gave up on Tech Support... Is there any FAQ of how to define the Crypto provider so Azure SDK is not using the default BouncyCastle, or is just the standard setup during Initialization of our App. I have not look into how the SDK is instantiating BouncyCastle.

[jaschrep-msft]

You would want to look into documentation on the Java Cryptographic Architecture, which is how all cryptographic algorithms are meant to be accessed in a Java application. There should be documentation on how to configure available algorithm providers and their priority order of access from the JCA.