RH2023467: Enable FIPS keys export

[franferrax]

Search this PR in Red Hat Jira

RH2023467: Enable the export of keys in plain from the NSS Software Token while in FIPS mode [rhel-8, openjdk-17]

Description

In the context of RH1991003, we implemented an enhancement to import plain secret and private keys (i.e.: obtained from a file-based keystore) into the NSS Software token in FIPS mode. The goal now is to enable the reverse operation: export keys in plain from the NSS Software Token while in FIPS mode.

The scope was initially constrained to keys of CKO_SECRET_KEY class, as this is what we required for TLS 1.3 key-derivation in FIPS mode (see RH2020290). As a dependency for PKCS#12 keystores in FIPS mode (see RH2048582), we extended the exporter functionality to support keys of CKO_PRIVATE_KEY class, in colaboration with @martinuy, @akashche and myself (@franferrax).

In the same way that for the importer functionality, the exporter can be disabled by means of the com.redhat.fips.plainKeySupport system property: -Dcom.redhat.fips.plainKeySupport=false. Default behavior is enabled.

As part of this work, we aim to implement several code, debugging and reliability improvements to the FIPS Key Importer.

[gnu-andrew]

@franferrax can you run a workflow on this branch from https://github.com/franferrax/jdk/actions/workflows/submit.yml ? I've enabled actions on this repository now, so hopefully it will be automatic in future.

[franferrax]

@franferrax can you run a workflow on this branch from https://github.com/franferrax/jdk/actions/workflows/submit.yml ? I've enabled actions on this repository now, so hopefully it will be automatic in future.

Sure, running: https://github.com/franferrax/jdk/actions/runs/2309360075

Just in case, I've left the Platform(s) to execute on as default, we might want to limit this to Linux in the future (or introduce our own platforms if possible).

[gnu-andrew]

@franferrax can you run a workflow on this branch from https://github.com/franferrax/jdk/actions/workflows/submit.yml ? I've enabled actions on this repository now, so hopefully it will be automatic in future.

Sure, running: https://github.com/franferrax/jdk/actions/runs/2309360075

Just in case, I've left the Platform(s) to execute on as default, we might want to limit this to Linux in the future (or introduce our own platforms if possible).

That's fine. Yeah, I will do some local changes to the config tomorrow. We may as well leave Windows on in case we ever want to include the patches there, but I'll turn off Mac. Going on my experiences enabling this with my IcedTea fork, the config probably needs to be altered anyway to run at the appropriate point, in the absence of SKARA.

As to this patch, it looks fine & the Linux build was ok, so I'll integrate this. The Mac & Windows failures are curious; I'll see if they replicate without this patch as well.

[gnu-andrew]

Confirmed failures seen with this patch are already present in the baseline fips-17u branch: https://github.com/rh-openjdk/jdk/runs/6398670091?check_suite_focus=true

[franferrax]

Pre-submit tests workflow Linux x86/x64 tier1 failures preliminary analysis

NOTE: as already said, these failures are present at least since 6e74f28, before this pull request

• java/lang/SecurityManager/CheckAccessClassInPackagePermissions.java
  • Error: Module module jdk.crypto.ec has not been granted ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.access")
  • The jdk.crypto.ec module is not being granted the accessClassInPackage runtime permission on the jdk.internal.access package, which is expected after JDK-8055206
  • Possibly triggered by the addition of the jdk.internal.access package visibility to the jdk.crypto.ec module, in RH1995150?
• java/lang/SecurityManager/CheckSecurityProvider.java
  • Error: Unexpected provider count. Expected: 12. Actual: 11
  • The expected sun.security.ec.SunEC provider is missing from the actual providers retrieved with Security.getProviders()
  • Could be related to the same RH1995150 change

---

EDIT: this is caused by the same issue fixed for the jdk.crypto.cryptoki module in bfd7c5d, but occurring for the jdk.crypto.ec module. For the record, this was discussed and analyzed in an internal mailing list (search by Message-ID).