Bug 2052070

Summary: Enable AlgorithmParameters and AlgorithmParameterGenerator services in FIPS mode [rhel-8, openjdk-17]
Product: Red Hat Enterprise Linux 8 Reporter: Martin Balao <mbalao>
Component: java-17-openjdkAssignee: Martin Balao <mbalao>
Status: CLOSED ERRATA QA Contact: OpenJDK QA <java-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 8.6CC: ahughes, fferrari, jandrlik, pmikova, sgehwolf
Target Milestone: rcKeywords: Triaged, ZStream
Target Release: ---Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: java-17-openjdk-17.0.2.0.8-15.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2055396 2128104 (view as bug list) Environment:
Last Closed: 2022-05-10 13:32:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1994661, 2055396, 2128104, 2156945    

Description Martin Balao 2022-02-08 16:10:57 UTC
As noticed while developing the FIPS Key Importer enhancement for java-17-openjdk, some AlgorithmParameters services are required in FIPS mode. As indicated by their name, these services are used to hold data later used as input for crypto services. It is worth noticing that none of them implement the actual crypto primitives, so enabling them should not affect FIPS compliance in any sense. An analogous case can be described for AlgorithmParameterGenerator services.

In the context of fixing this bug, we should consider the following approaches:

1) Enabling all AlgorithmParameters and AlgorithmParameterGenerator services under the rationale that they do not affect FIPS compliance, that they might be required in the future or even now by yet-to-be-uncovered bugs;

2) Enabling only those known to be required at this time and update the list in farther iterations if needed;

3) Perform a thorough static analysis to determine exactly what is required now and enable the rest only if needed in the future; and,

4) Something in-between #1, #2 and #3.

As demonstrated in a first analysis of this issue, the approach #3 has more complexity than what it looks like.

--
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1994661#c6

Comment 2 Martin Balao 2022-02-08 19:59:58 UTC
AlgorithmParameterGenerator analysis
================================================

 * Implementors
  * DH
   * SunJCE.java
    * DHParameterGenerator.java
  * DSA
   * SunEntries.java
    * DSAParameterGenerator.java

 * Clients (users)
  * DH
   * ParameterCache.java
  * DSA
   * ParameterCache.java
   * DHParameterGenerator.java

Conclusions
-----------------------------------------------

AlgorithmParameterGenerator for DSA should be supported. P11KeyPairGenerator::generateKeyPair can potentially invoke ParameterCache::getDSAParameterSpec, ParameterCache::getNewDSAParameterSpec and AlgorithmParameterGenerator.getInstance("DSA"). Notice that DSAParameterGenerator::engineGenerateParameters (instance returned in the previous call) can potentially invoke AlgorithmParameters.getInstance("DSA", "SUN"). Thus, AlgorithmParameters DSA must be enabled in SUN (this is a 2nd reason in addition to [1]).

AlgorithmParameterGenerator for DH should be supported. P11KeyPairGenerator::generateKeyPair can potentially invoke ParameterCache::getDHParameterSpec and AlgorithmParameterGenerator.getInstance("DH").

--
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1994661#c6

Comment 3 Martin Balao 2022-02-08 20:11:19 UTC
AlgorithmParameters - the DSAParameters case

In java-17-openjdk, after RH1995150 [1], we took the approach of disabling all non-FIPS crypto services from security providers enabled in FIPS mode. In example, the SUN security provider is enabled in FIPS mode but its Signature services do not provide FIPS-compliant crypto and are, thus, disabled. This approach can help applications to avoid inadvertently using non-FIPS crypto while in FIPS mode.

While running the FIPS Key Importer test [2] under this configuration, we realized that the AlgorithmParameters service for the DSA algorithm is required. This service is provided by the SUN security provider and do not pose a FIPS-compliance conflict, so it can and should be enabled. Determining which other AlgorithmParameters services must be enabled in FIPS mode based on static analysis is not simple a simple task, though.

To tackle this problem, I analyzed why DSA AlgorithmParameters is needed in the first place. This could hint a pattern to look-for.

In the DSA AlgorithmParameters scneario, we need to build a P11 DSA public key from a spec (i.e.: from an encoded byte array read from a X509 certificate). A sun.security.provider.DSAPublicKey key instance will be constructed [3] and the translation to P11 will take place afterwards [4]. The point of building an intermediate DSAPublicKey object is parsing the key data from the encoded byte array form, and get values by calling well defined APIs. DSAPublicKey keys have parameters of type sun.security.provider.DSAParameters. These parameters contain information such as the prime (p), sub-prime (q) and base (g). When a DSA public key is parsed, the method X509Key::decode is called [5]. Note: X509Key is the superclass of DSAPublicKey. Parameters are parsed by AlgorithmId::decodeParams [6]. AlgorithmId::decodeParams makes use of 'AlgorithmParameters.getInstance(algidName)' to get a DSAParameters instance which will finally parse the values [7]. Once DSAPublicKey::getParams is called, the information comes from what was previously parsed [8]. As a result, a failure in 'AlgorithmParameters.getInstance(algidName)' will lead to null DSAParameters parameters and the P11 public key cannot be constructed.

--
[1] - https://bugzilla.redhat.com/show_bug.cgi?id=1995150
[2] - https://bugzilla.redhat.com/show_bug.cgi?id=1994661#c4
[3] - https://github.com/openjdk/jdk17u/blob/jdk-17+35/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java#L108
[4] - https://github.com/openjdk/jdk17u/blob/jdk-17+35/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11DSAKeyFactory.java#L52
[5] - https://github.com/openjdk/jdk17u/blob/jdk-17%2B35/src/java.base/share/classes/sun/security/x509/X509Key.java#L389
[6] - https://github.com/openjdk/jdk17u/blob/jdk-17+35/src/java.base/share/classes/sun/security/x509/AlgorithmId.java#L133
[7] - https://github.com/openjdk/jdk17u/blob/jdk-17%2B35/src/java.base/share/classes/sun/security/provider/DSAParameters.java#L72
[8] - https://github.com/openjdk/jdk17u/blob/jdk-17%2B35/src/java.base/share/classes/sun/security/provider/DSAPublicKey.java#L120

Comment 4 Martin Balao 2022-02-08 20:16:35 UTC
*** Bug 2034698 has been marked as a duplicate of this bug. ***

Comment 18 errata-xmlrpc 2022-05-10 13:32:42 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (java-17-openjdk bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2022:1768