Bug 1996182

Summary: Login to the NSS software token in FIPS [java-17-openjdk, RHEL 8]
Product: Red Hat Enterprise Linux 8 Reporter: Martin Balao <mbalao>
Component: java-17-openjdkAssignee: Andrew John Hughes <ahughes>
Status: CLOSED ERRATA QA Contact: OpenJDK QA <java-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 8.5CC: jandrlik, pmikova
Target Milestone: betaKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: java-17-openjdk-17.0.0.0.33-0.5.ea.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-09 18:51:24 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:

Description Martin Balao 2021-08-20 18:26:05 UTC 
Description of problem:

When the NSS software token is configured in FIPS mode -as we do for OpenJDK's system FIPS mode-, a token login is required prior to (almost) any operation. The token login can be achieved by means of a C_Login PKCS#11 call, passing the NSSDB PIN (if any). As an example, C_CreateObject (PKCS#11 API to create keys among other objects) cannot be invoked without a login [1] [2].

OpenJDK will perform a login into the token if a KeyStore::load API is invoked and the keystore implementation is from the SunPKCS11 provider [3] [4]. However, in the case that the application does not perform such call and tries to execute a PKCS#11 action (such as importing a public RSA key into the token [5]), a CKR_USER_NOT_LOGGED_IN error will be thrown.

Proposed solution:

When in system FIPS mode, login into the token right after the SunPKCS11 security provider is initialized. The PIN for the /etc/pki/nssdb token is empty. Note: only privileged (root) users have the right to modify /etc/pki/nssdb files, so there was no need to set a PIN there. OpenJDK's FIPS mode will open the token in read-only mode.

--
[1] - https://github.com/nss-dev/nss/blob/b6145f4aaeb6970f25b497f55ed9a5476f13b715/lib/softoken/fipstokn.c#L970
[2] - https://github.com/nss-dev/nss/blob/b6145f4aaeb6970f25b497f55ed9a5476f13b715/lib/softoken/fipstokn.c#L198
[3] - https://github.com/openjdk/jdk17/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java#L752
[4] - https://github.com/openjdk/jdk17/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java#L1403
[5] - https://github.com/openjdk/jdk17/blob/dfacda488bfbe2e11e8d607a6d08527710286982/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java#L193
Comment 7 errata-xmlrpc 2021-11-09 18:51:24 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-2021:4136