[crypto] Ensure TLS signable digests cover a shared secret

The signable digest value is used to bind the server identity to the
shared secret, and so the digest must be computed over the parameters
used to establish the shared secret in order to be meaningful.

The secure channel will refuse to bind the peer identity on the basis
of a verified signable digest if the channel does not already contain
key material derived from a shared secret.

A signable digest that was erroneously constructed before a shared
secret was applied is therefore guaranteed to be unusable for binding
the channel, provided that the caller uses a sensible sequence of
operations (i.e. constructs the signable digest and then immediately
attempts to use it to bind the peer identity).

Strengthen this guarantee further by refusing to generate a signable
digest value unless the key schedule already contains key material.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
This commit is contained in:
Michael Brown
2026-09-13 15:55:37 +01:00
parent 356bb14f33
commit 7a3b423f69
+10
View File
@@ -759,6 +759,16 @@ int tlskey_tbshash ( struct tls_key_schedule *tlskey,
return -EPROTO;
}
/* Signable digest values must be constructed over the
* parameters used to establish a shared secret, and so a
* shared secret must exist.
*/
if ( ! ( tlskey->kdf.flags & TLSKEY_KDF_KEYED ) ) {
DBGC ( tlskey, "TLSKEY %p cannot generate signable digest "
"without a shared secret\n", tlskey );
return -EPROTO;
}
/* Generate digest value */
DBGC2 ( tlskey, "TLSKEY %p generating signable %s %s digest\n",
tlskey, end->name, digest->name );