[tls] Centralise pseudorandom data generation#1740
Merged
Conversation
mcb30
force-pushed
the
tlssched
branch
4 times, most recently
from
6d59fb6 to
c2a0bb1
Compare
TLS version 1.3 has a formal key schedule based on HKDF, and requires the client to be able to recall ephemeral secrets at multiple points within the connection lifecycle. For example: the ephemeral private key for X25519 key exchange may be required when constructing ClientHello (for a TLS version 1.3 key share) or when constructing ClientKeyExchange (if subsequently falling back to use TLS version 1.2), and again when parsing a ServerHello key share or a ServerKeyExchange. Some ephemeral private keys may be large (e.g. for ffdhe4096). Avoid the need to store these large (and variably sized) private keys by instead instantiating a standalone HKDF instance that we seed with per-connection random data and subsequently use to generate ephemeral private keys on demand. (Note that this instance is unrelated to the HKDF instance defined in the formal key schedule for TLS: we are choosing to reuse HKDF for this purpose simply because supporting TLS version 1.3 will already require HKDF support to be present.) We use the key exchange algorithm name (e.g. "x25519") as additional information to ensure separation between keys used for different purposes. Since the initial random seed is generated afresh for each connection, and since there can meaningfully be only one ephemeral private key per key exchange algorithm per connection, this is sufficient to ensure separation. Having instantiated this HKDF, we then also use it to generate the client random bytes (with the label "client random"), to generate the random portion of the pre-master secret for classic RSA key exchange (with the label "classic pre-master"), and to generate the random portion of record IVs (using the authentication header structure, which is already guaranteed to be unique per record within a connection). Doing this allows us to eliminate all other calls to the RNG, and removes some potential failure paths. We reset the HKDF on a connection restart and on connection close, to preserve the property of forward secrecy. Signed-off-by: Michael Brown <mcb30@ipxe.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TLS version 1.3 has a formal key schedule based on HKDF, and requires the client to be able to recall ephemeral secrets at multiple points within the connection lifecycle. For example: the ephemeral private key for X25519 key exchange may be required when constructing ClientHello (for a TLS version 1.3 key share) or when constructing ClientKeyExchange (if subsequently falling back to use TLS version 1.2), and again when parsing a ServerHello key share or a ServerKeyExchange.
Some ephemeral private keys may be large (e.g. for ffdhe4096). Avoid the need to store these large (and variably sized) private keys by instead instantiating a standalone HKDF instance that we seed with per-connection random data and subsequently use to generate ephemeral private keys on demand.
We use the key exchange algorithm name (e.g. "x25519") as additional information to ensure separation between keys used for different purposes. Since the initial random seed is generated afresh for each connection, and since there can meaningfully be only one ephemeral private key per key exchange algorithm per connection, this is sufficient to ensure separation.
Having instantiated this HKDF, we then also use it to generate the client random bytes (with the label "client random"), to generate the random portion of the pre-master secret for classic RSA key exchange (with the label "classic pre-master"), and to generate the random portion of record IVs (using the authentication header structure, which is already guaranteed to be unique per record within a connection). Doing this allows us to eliminate all other calls to the RNG, and removes some potential failure paths.
We reset the HKDF on a connection restart and on connection close, to preserve the property of forward secrecy.