Fix to derive the wrapping key size from the parent public area - #618
Merged
Merged
Conversation
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Copilot review overview
Review effort: Lite
Findings: 1
Open (1)
What changed in this PR
This PR fixes offline wrapping in wolfTPM2_SensitiveToPrivate() by deriving the wrapping symmetric key size from the parent public area when the parent handle metadata is absent, and by explicitly rejecting zero-length wrapping keys to avoid reaching the cipher with no key.
Changes:
- Fallback to
parentKey->pub.publicArea.parameters.*.symmetric.keyBits.symwhenparentKey->handle.symmetric.keyBits.symis unset (offline/public-area-only parent). - Reject
outerWrapoperations when the derived symmetric key size is zero. - Add a unit test covering public-area-only parent behavior and zero-length key refusal.
| File | Description |
|---|---|
src/tpm2_wrap.c |
Adds key-size fallback from parent public area and rejects zero-length outer-wrap keys |
tests/unit_tests.c |
Adds unit test to exercise offline wrapping with parent public area only and validates failure on missing symmetric key bits |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
dgarske
force-pushed
the
sensitive_parent_pub
branch
from
September 29, 2026 19:50
374bec1 to
9a842d3
Compare
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
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.

Found while producing a duplication blob for a TPM that is not present, which is what
wolfTPM2_SensitiveToPrivate()is exported for. Two related problems in that function.1. A parent supplied as a public area alone failed with BAD_FUNC_ARG
SensitiveToPrivate()takes the wrapping symmetric key size fromparentKey->handle.symmetric.keyBits.sym. That field is populated when the parent is a key loaded on this TPM, but not when the caller holds only the target's public area, which is exactly the offline wrapping case.symKey.sizewas then zero and the call failed well downstream insideTPM2_AesCfbEncrypt(), returning a bareBAD_FUNC_ARGthat pointed nowhere near the cause.The public area carries the same symmetric definition, so fall back to it when the handle has none:
symDetail.symfor aTPM_ALG_SYMCIPHERparent andasymDetail.symmetricotherwise, which covers both RSA and ECC storage parents.2. A zero length symmetric key reached the cipher
With
symKey.sizezero,TPM2_KDFa_ex()returns zero for a zero length request, so therc == symKey.sizecheck compared equal and the derivation was treated as successful. The sensitive area then went toTPM2_AesCfbEncrypt()with no key at all. That failed, but only because AES rejects a zero length key, not because anything verified one had been derived. RejectsymKey.size == 0explicitly so a wrap cannot proceed without a key.Testing
make checkpasses.Verified with a three phase import flow: export the storage root key public area, wrap a symmetric key offline with the TPM unreachable, then
TPM2_ImportandTPM2_Loadit and confirm the TPM computed HMAC matches one computed in software from the original key. Before this change the offline wrap returnedBAD_FUNC_ARG; after it the flow completes.Run on a TPM 2.0 simulator with an RSA storage parent, and on TPM 2.0 hardware with an ECC storage parent, which exercises the
asymDetail.symmetricfallback for both key types.