Hi Kevin,
I implemented a prototype for HKDF derivation with SunPKCS11. This was
tested with the NSS Software Token v3.90, both in FIPS and non-FIPS
configurations. Testing includes the 7 vectors in RFC 5869 (*),
derivation of a DH base key, derivation of a ECDH base key and use of
derived keys for Cipher and Mac services. In each case I did key and
data derivation under the following modes: extraction-expansion,
extraction and expansion. All of this should be enough coverage of TLS
1.3 key derivation. I'll adjust this prototype to the final API —once we
have it— and make a proposal.
I would like to add two more pieces of feedback from the SunPKCS11 side:
For TLS 1.3 derivation, it would be desirable to handle the salt as a
Key object in the HKDFParameterSpec (instead of a byte[]). The TLS 1.3
key schedule [1] takes the salt from a previous key derivation —so it's
naturally a key—, except for the Early Secret where it's all 0's. For
SunPKCS11 this has 2 concrete benefits: 1) we don't need to re-build the
salt as a key each time and 2) we can operate in FIPS-compliant mode.
Different implementations of the API may need similar consistency checks
over the derivation parameters. Would be good if these checks are done
at HKDFParameterSpec construction time. For example, output length has
to be greater than 0.
Regards,
Martin.-
--
(*) Vector #1 does not work in FIPS mode because the salt's length is
too small.
[1] - https://datatracker.ietf.org/doc/html/rfc8446#section-7.1
On 7/20/23 16:05, Kevin Driver wrote:
As a newly minted committer and Oracle employee tasked with the
following, I thought I should send an introductory mail to the list and
start a discussion on adding a standard API for key derivation functions
(KDFs) to the Java Platform. You may have noticed the KEM [1] APIs and
associated implementation coming in JDK 21. KDF [2] is another building
block in support of HPKE [3] (which requires KEM and KDF as
dependencies/primitives). HPKE will become important during the
transition to post-quantum cryptography.
The concept of a KDF implementation within the security libraries is not
entirely new (a JEP was put forth previously but withdrawn [4]); however
it is time to formalize an API, add some additional implementations, and
make some older implementations available for use in a more standard way.
We look forward to your feedback on the below proposal and would be
interested in any thoughts on the design considerations listed at the end.
To wit, I’ll try to give a brief overview of the following:
- high level design
- current status
- design considerations
**High Level Design**
In general, this diagram encapsulates a lot of our intended trajectory
(see attached diagram).
The new KDF APIs will serve as an umbrella over an RFC 5869 [5]
implementation of HKDF, existing PBE implementations, and future
implementations. However, our current plans are to allow algorithms,
such as PBE, to continue to be accessible in the manner they are today
(with possible deprecation at some point in the future).
In addition, JSSE has a “sibling” implementation of something very
similar to RFC 5869 (but perhaps somewhat specialized for the JSSE
use-cases), so it will likely be merged into the “proper”/main RFC 5869
implementation and called/utilized in a fashion similar to how JSSE does
today. One goal is certainly to be minimally disruptive to JSSE
implementation code where possible, so as to not incur a massive
retesting/validation effort for TLS.
Also related to JSSE, one of the reasons for the Tls* classes (mentioned
in the SunJCE provider) being located in restricted packages, I’m told,
is because there was not yet a KDF API available. The classes described
are in:
• sun.security.internal.interfaces
• sun.security.internal.spec
A side-goal/benefit of this work will be to relocate the above classes
out of their restricted packages (ie - not in sun.security.internal any
longer).
**Current Status**
Currently we (Oracle) have a set of KDF framework APIs as well as an
implementation of RFC 5869 and a TLSPrfKDF implementation, which were
developed previously but not yet made available. I have taken up this
work, and I’m working through suggested modifications and/or
improvements. There are, however, a few ongoing points of discussion, a
couple of which I will be bringing forward today.
**Design Considerations**
• What, if any, JSSE implementations are there outside of Oracle which
might be affected by the choice to relocate the Tls* classes from their
SunJCE restricted packages? We are interested in speaking with those
affected by this potential change.
• APIs in JCE have historically been “multi-phased” (ie - Cipher’s init,
update, doFinal). However, it is also somewhat en vogue to lean toward
immutability as much as possible. We’re weighing the relative merits of
a “one and done” style API with lots of parameters vs a more
“traditional” multi-phased approach.
[1] https://openjdk.org/jeps/452
[2] https://en.wikipedia.org/wiki/Key_derivation_function
[3] https://www.rfc-editor.org/rfc/rfc9180.html
[4] https://bugs.openjdk.org/browse/JDK-8189808
[5] https://www.rfc-editor.org/rfc/rfc5869.html
I will followup in a few weeks with more detail and will look forward to
your feedback in the meantime. Thanks for your interest/participation!
Kevin Driver
Mobile: +1.512.431.5690
Java Security Libraries
