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.
Bug 2130351 - SunPKCS11 PBE API Enhancements [rhel-8, openjdk-17]
Summary: SunPKCS11 PBE API Enhancements [rhel-8, openjdk-17]
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: java-17-openjdk
Version: 8.7
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: 8.8
Assignee: Francisco Ferrari Bihurriet
QA Contact: OpenJDK QA
URL:
Whiteboard:
Depends On: 2048582
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-27 21:36 UTC by Francisco Ferrari Bihurriet
Modified: 2023-06-06 20:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-06-06 20:31:53 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openjdk jdk pull 12396 0 None closed 8301553: Support Password-Based Cryptography in SunPKCS11 2023-06-06 20:31:53 UTC
Github rh-openjdk jdk pull 20 0 None Draft RH2130351: SunPKCS11 PBE API Enhancements 2023-06-06 20:34:23 UTC
Red Hat Issue Tracker RHELPLAN-135090 0 None None None 2022-10-04 16:11:45 UTC
openjdk bug system JDK-8301553 0 None None None 2023-06-06 20:31:53 UTC

Description Francisco 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 2 Francisco Ferrari Bihurriet 2023-06-06 20:31:53 UTC
This has been proposed upstream as part of https://bugs.openjdk.org/browse/JDK-8301553

Integrated as https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444


Note You need to log in before you can comment on or make changes to this bug.