Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionFrancisco Ferrari Bihurriet
2022-09-27 21:36:35 UTC
As part of the work for RHELPLAN-112612 [1] we implemented support for the following PBE algorithms in SunPKCS11:
| Algorithm name | Derivation | Mac | Cipher | SecretKeyFactory |
|-------------------------------|--------------|-----|--------|------------------|
| "PBEWithHmacSHA1AndAES_128" | new (PBKDF2) | | x | x |
| "PBEWithHmacSHA224AndAES_128" | new (PBKDF2) | | x | x |
| "PBEWithHmacSHA256AndAES_128" | new (PBKDF2) | | x | x |
| "PBEWithHmacSHA384AndAES_128" | new (PBKDF2) | | x | x |
| "PBEWithHmacSHA512AndAES_128" | new (PBKDF2) | | x | x |
| "PBEWithHmacSHA1AndAES_256" | new (PBKDF2) | | x | x |
| "PBEWithHmacSHA224AndAES_256" | new (PBKDF2) | | x | x |
| "PBEWithHmacSHA256AndAES_256" | new (PBKDF2) | | x | x |
| "PBEWithHmacSHA384AndAES_256" | new (PBKDF2) | | x | x |
| "PBEWithHmacSHA512AndAES_256" | new (PBKDF2) | | x | x |
| "HmacPBESHA1" | old (PKCS12) | x | | x |
| "HmacPBESHA224" | old (PKCS12) | x | | x |
| "HmacPBESHA256" | old (PKCS12) | x | | x |
| "HmacPBESHA384" | old (PKCS12) | x | | x |
| "HmacPBESHA512" | old (PKCS12) | x | | x |
| "HmacPBESHA512/224" | old (PKCS12) | x | | x |
| "HmacPBESHA512/256" | old (PKCS12) | x | | x |
| "PBKDF2WithHmacSHA1" | new (PBKDF2) | | | x |
| "PBKDF2WithHmacSHA224" | new (PBKDF2) | | | x |
| "PBKDF2WithHmacSHA256" | new (PBKDF2) | | | x |
| "PBKDF2WithHmacSHA384" | new (PBKDF2) | | | x |
| "PBKDF2WithHmacSHA512" | new (PBKDF2) | | | x |
Since SunJCE SecretKeyFactory implementations are allowed in FIPS (they don't perform any cryptographic operation) we also left them enabled. A SunJCE SecretKeyFactory implementation is used by the PKCS#12 keystore code [2], through the "PBE" → "PBEWithMD5AndDES" alias [3], because "PBEWithMD5AndDES" was not implemented in SunPKCS11.
We decided to implement SecretKeyFactory services in SunPKCS11 (for the algorithms already implemented in other services) in the sake of completeness, and thinking in the PBE upstream proposal we are planning to do. Also, we decided that those SecretKeyFactory services should perform key derivation, as with SunJCE's "PBKDF2*" secret key factories, despite the following SunJCE behavior:
• "HmacPBE*" secret key factories don't exist in SunJCE
• "PBEWithHmac*And*" secret key factories don't perform derivation, they just put the password into a SunJCE password-only PBEKey (any salt or iterations count value from the PBEKeySpec is lost) [4]
During the analyses performed for some behaviours documented in OPENJDK-991 [5] (in the comments), we determined that we need some improvements for SunPKCS11 SecretKeyFactory implementations to be finished and properly interoperable:
• "*" secret key factories (all):
• Special invalid PBEKeySpec corner cases in ::generateSecret() (avoid a JNI call into the PKCS#11 token that we know will fail)
• If itCount < 1, throw InvalidKeySpecException: Iteration count must be a non-zero positive integer
• If keySize < 1, throw InvalidKeySpecException: Key length must be a non-zero positive integer
• If keySize % 8 != 0, throw InvalidKeySpecException: Key length (in bits) must be an 8 multiple
• Review and re-think ::translateKey()
• Avoid a NullPointerException when an unrelated-algorithm SecretKeyFactory is asked to translate a PBEKey [6]
• Identify PBE SecretKey instances from the own SecretKeyFactory and return them untranslated
• Try to enable interoperation with other providers' implementations of javax.crypto.interfaces.PBEKey, as long as they have all the required information (SunJCE password-only com.sun.crypto.provider.PBEKey doesn't implement this interface)
• "PBKDF2*" secret key factories:
• Generated keys should keep the original algorithm (currently, they use "Generic"), although the underlying key type will still be CKK_GENERIC_SECRET
• Those generated keys only work in Mac algorithms and won't work with Cipher algorithms
• This is because, for the case that concerns us, NSS expects CKK_AES [7], so we should stop giving the CKA_ENCRYPT attribute to the key in vain (see P11Util.java:64-68 [8] and P11SecretKeyFactory.java:282-285 [9])
• This is fine, since SunJCE "PBKDF2*" keys don't work either in their Mac nor Cipher services, the common use case seems to be just calling key.getEncoded() to get the derived key bytes (which can also be considered as a salted hash of the password)
• "HmacPBE*" & "PBEWithHmac*And*" secret key factories:
• Try to maintain the original algorithm as the key algorithm (currently, we use "Generic" & "AES" respectively)
• Generated keys, which are already derived, should work in Mac & Cipher services for the exact same algorithm
• Currently, this doesn't work, we need to skip the key derivation in such cases
The goal of this enhancement is to implement the aforementioned improvements, including any required test adjustment, and creating new test cases for SecretKeyFactory + Cipher and SecretKeyFactory + Mac use cases.
[1] https://issues.redhat.com/browse/RHELPLAN-112612
[2] https://github.com/openjdk/jdk17u/blob/jdk-17.0.4-ga/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java#L860-L877
[3] https://github.com/openjdk/jdk17u/blob/jdk-17.0.4-ga/src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java#L216
[4] https://github.com/openjdk/jdk17u/blob/jdk-17.0.4-ga/src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java#L61
[5] https://issues.redhat.com/browse/OPENJDK-991
[6] https://github.com/rh-openjdk/jdk/blob/1e26894969d911776f60eaa557d25a2b389060da/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L206
[7] https://github.com/nss-dev/nss/blob/NSS_3_67_RTM/lib/softoken/pkcs11c.c#L1240-L1243
[8] https://github.com/rh-openjdk/jdk/blob/1e26894969d911776f60eaa557d25a2b389060da/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java#L64-L68
[9] https://github.com/rh-openjdk/jdk/blob/1e26894969d911776f60eaa557d25a2b389060da/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L282-L285
Comment 2Francisco Ferrari Bihurriet
2023-06-06 20:31:53 UTC
As part of the work for RHELPLAN-112612 [1] we implemented support for the following PBE algorithms in SunPKCS11: | Algorithm name | Derivation | Mac | Cipher | SecretKeyFactory | |-------------------------------|--------------|-----|--------|------------------| | "PBEWithHmacSHA1AndAES_128" | new (PBKDF2) | | x | x | | "PBEWithHmacSHA224AndAES_128" | new (PBKDF2) | | x | x | | "PBEWithHmacSHA256AndAES_128" | new (PBKDF2) | | x | x | | "PBEWithHmacSHA384AndAES_128" | new (PBKDF2) | | x | x | | "PBEWithHmacSHA512AndAES_128" | new (PBKDF2) | | x | x | | "PBEWithHmacSHA1AndAES_256" | new (PBKDF2) | | x | x | | "PBEWithHmacSHA224AndAES_256" | new (PBKDF2) | | x | x | | "PBEWithHmacSHA256AndAES_256" | new (PBKDF2) | | x | x | | "PBEWithHmacSHA384AndAES_256" | new (PBKDF2) | | x | x | | "PBEWithHmacSHA512AndAES_256" | new (PBKDF2) | | x | x | | "HmacPBESHA1" | old (PKCS12) | x | | x | | "HmacPBESHA224" | old (PKCS12) | x | | x | | "HmacPBESHA256" | old (PKCS12) | x | | x | | "HmacPBESHA384" | old (PKCS12) | x | | x | | "HmacPBESHA512" | old (PKCS12) | x | | x | | "HmacPBESHA512/224" | old (PKCS12) | x | | x | | "HmacPBESHA512/256" | old (PKCS12) | x | | x | | "PBKDF2WithHmacSHA1" | new (PBKDF2) | | | x | | "PBKDF2WithHmacSHA224" | new (PBKDF2) | | | x | | "PBKDF2WithHmacSHA256" | new (PBKDF2) | | | x | | "PBKDF2WithHmacSHA384" | new (PBKDF2) | | | x | | "PBKDF2WithHmacSHA512" | new (PBKDF2) | | | x | Since SunJCE SecretKeyFactory implementations are allowed in FIPS (they don't perform any cryptographic operation) we also left them enabled. A SunJCE SecretKeyFactory implementation is used by the PKCS#12 keystore code [2], through the "PBE" → "PBEWithMD5AndDES" alias [3], because "PBEWithMD5AndDES" was not implemented in SunPKCS11. We decided to implement SecretKeyFactory services in SunPKCS11 (for the algorithms already implemented in other services) in the sake of completeness, and thinking in the PBE upstream proposal we are planning to do. Also, we decided that those SecretKeyFactory services should perform key derivation, as with SunJCE's "PBKDF2*" secret key factories, despite the following SunJCE behavior: • "HmacPBE*" secret key factories don't exist in SunJCE • "PBEWithHmac*And*" secret key factories don't perform derivation, they just put the password into a SunJCE password-only PBEKey (any salt or iterations count value from the PBEKeySpec is lost) [4] During the analyses performed for some behaviours documented in OPENJDK-991 [5] (in the comments), we determined that we need some improvements for SunPKCS11 SecretKeyFactory implementations to be finished and properly interoperable: • "*" secret key factories (all): • Special invalid PBEKeySpec corner cases in ::generateSecret() (avoid a JNI call into the PKCS#11 token that we know will fail) • If itCount < 1, throw InvalidKeySpecException: Iteration count must be a non-zero positive integer • If keySize < 1, throw InvalidKeySpecException: Key length must be a non-zero positive integer • If keySize % 8 != 0, throw InvalidKeySpecException: Key length (in bits) must be an 8 multiple • Review and re-think ::translateKey() • Avoid a NullPointerException when an unrelated-algorithm SecretKeyFactory is asked to translate a PBEKey [6] • Identify PBE SecretKey instances from the own SecretKeyFactory and return them untranslated • Try to enable interoperation with other providers' implementations of javax.crypto.interfaces.PBEKey, as long as they have all the required information (SunJCE password-only com.sun.crypto.provider.PBEKey doesn't implement this interface) • "PBKDF2*" secret key factories: • Generated keys should keep the original algorithm (currently, they use "Generic"), although the underlying key type will still be CKK_GENERIC_SECRET • Those generated keys only work in Mac algorithms and won't work with Cipher algorithms • This is because, for the case that concerns us, NSS expects CKK_AES [7], so we should stop giving the CKA_ENCRYPT attribute to the key in vain (see P11Util.java:64-68 [8] and P11SecretKeyFactory.java:282-285 [9]) • This is fine, since SunJCE "PBKDF2*" keys don't work either in their Mac nor Cipher services, the common use case seems to be just calling key.getEncoded() to get the derived key bytes (which can also be considered as a salted hash of the password) • "HmacPBE*" & "PBEWithHmac*And*" secret key factories: • Try to maintain the original algorithm as the key algorithm (currently, we use "Generic" & "AES" respectively) • Generated keys, which are already derived, should work in Mac & Cipher services for the exact same algorithm • Currently, this doesn't work, we need to skip the key derivation in such cases The goal of this enhancement is to implement the aforementioned improvements, including any required test adjustment, and creating new test cases for SecretKeyFactory + Cipher and SecretKeyFactory + Mac use cases. [1] https://issues.redhat.com/browse/RHELPLAN-112612 [2] https://github.com/openjdk/jdk17u/blob/jdk-17.0.4-ga/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java#L860-L877 [3] https://github.com/openjdk/jdk17u/blob/jdk-17.0.4-ga/src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java#L216 [4] https://github.com/openjdk/jdk17u/blob/jdk-17.0.4-ga/src/java.base/share/classes/com/sun/crypto/provider/PBEKey.java#L61 [5] https://issues.redhat.com/browse/OPENJDK-991 [6] https://github.com/rh-openjdk/jdk/blob/1e26894969d911776f60eaa557d25a2b389060da/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L206 [7] https://github.com/nss-dev/nss/blob/NSS_3_67_RTM/lib/softoken/pkcs11c.c#L1240-L1243 [8] https://github.com/rh-openjdk/jdk/blob/1e26894969d911776f60eaa557d25a2b389060da/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java#L64-L68 [9] https://github.com/rh-openjdk/jdk/blob/1e26894969d911776f60eaa557d25a2b389060da/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L282-L285