RFR: 8353578: Refactor existing usage of internal HKDF impl to use the KDF API [v4]

[Weijun Wang]

On Thu, 17 Apr 2025 21:35:36 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.
>> 
>> This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.
>> 
>> Thanks in advance for the review~
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Undo the special workaround for JSSE in PKCS11 HKDF impl.

src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java line 131:

> 129: 
> 130:             // derive handshake secret
> 131:             return hkdf.deriveKey(type, HKDFParameterSpec.ofExtract()

The line above may fail because the `hkdf` object has been used once on line 121 with zero-valued salt and IKM, which selected the software-based HKDF from SunJCE. At this point, however, `sharedSecret` is the result of ECDH and may be non-extractable if produced by an HSM, making it incompatible with the SunJCE implementation. To avoid this issue, get a new `hkdf` by calling `hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm)` before this line.

src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line 851:

> 849:             return hkdf.deriveKey("TlsBinderKey",
> 850:                     HKDFParameterSpec.expandOnly(earlySecret, hkdfInfo,
> 851:                     hashAlg.hashLength));

Is it possible to combine the 2 `deriveKey` calls above into a single Extract-Then-Expand call? Then you don't need to clean up `earlySecret`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2060472356
PR Review Comment: https://git.openjdk.org/jdk/pull/24393#discussion_r2060479191