Zero TLS 1.3 traffic keys after AES SE offload#10246
Open
sameehj wants to merge 1 commit intowolfSSL:masterfrom
Open
Zero TLS 1.3 traffic keys after AES SE offload#10246sameehj wants to merge 1 commit intowolfSSL:masterfrom
sameehj wants to merge 1 commit intowolfSSL:masterfrom
Conversation
When WOLF_CRYPTO_CB_AES_SETKEY is enabled and a CryptoCB callback
imports the AES key into a Secure Element (aes->devCtx != NULL), the
TLS-layer copy in keys->{client,server}_write_key has no further
consumer: the software key schedule is not populated on offload.
ForceZero it in SetKeysSide() per provisioned side.
The static IVs (keys->{client,server}_write_IV and
keys->aead_{enc,dec}_imp_IV) are left intact because BuildTls13Nonce()
reads aead_{enc,dec}_imp_IV on every record (RFC 8446 Section 5.3).
Scope: TLS 1.3, non-DTLS, non-QUIC. DTLS 1.3 needs the write keys
in Dtls13EpochCopyKeys; TLS 1.2 needs them for rehandshake; QUIC is
untouched pending audit.
Add two memio tests (test_wc_CryptoCb_Tls13_Key_{Zero_After_Offload,
No_Zero_Without_Offload}) that pin AES-GCM and check key / IV state
after the handshake and a KeyUpdate round.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
|
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.
Description
When WOLF_CRYPTO_CB_AES_SETKEY is enabled and a CryptoCB callback imports the AES key into a Secure Element (aes->devCtx != NULL), the TLS-layer copy in keys->{client,server}_write_key has no further consumer: the software key schedule is not populated on offload. ForceZero it in SetKeysSide() per provisioned side.
The static IVs (keys->{client,server}write_IV and keys->aead{enc,dec}imp_IV) are left intact because BuildTls13Nonce() reads aead{enc,dec}_imp_IV on every record (RFC 8446 Section 5.3).
Scope: TLS 1.3, non-DTLS, non-QUIC. DTLS 1.3 needs the write keys in Dtls13EpochCopyKeys; TLS 1.2 needs them for rehandshake; QUIC is untouched pending audit.
Add two memio tests (test_wc_CryptoCb_Tls13_Key_{Zero_After_Offload, No_Zero_Without_Offload}) that pin AES-GCM and check key / IV state after the handshake and a KeyUpdate round.
Testing
Built and ran the full
unit.testsuite:./configure --enable-cryptocb --enable-aesgcm --enable-tls13
CPPFLAGS='-DWOLF_CRYPTO_CB_AES_SETKEY
-DHAVE_MANUAL_MEMIO_TESTS_DEPENDENCIES'
make && ./tests/unit.test
Result: 0 failed / 1036 skipped / 337 passed / 1373 total. The two new
memio tests (
test_wc_CryptoCb_Tls13_Key_Zero_After_Offloadandtest_wc_CryptoCb_Tls13_Key_No_Zero_Without_Offload)Checklist