Skip to content

cryptocb: add AES CryptoCB key import support and tests #9658

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
douzzer merged 1 commit into from
Feb 3, 2026
Merged

cryptocb: add AES CryptoCB key import support and tests #9658

douzzer merged 1 commit into from
Feb 3, 2026
+987 −27

Conversation

@sameehj
Copy link
Contributor

@sameehj sameehj commented Jan 14, 2026 •
edited
Loading 

Add CryptoCB-based AES key import support to enable Secure Element
offload without exposing raw AES key material to wolfCrypt.

This change introduces a new optional CryptoCB hook
(WOLF_CRYPTO_CB_AES_SETKEY) that allows AES keys to be imported into
external devices (e.g. Secure Elements or HSMs) and referenced via an
opaque handle stored in aes->devCtx. When this mode is active, wolfCrypt
stores only key metadata and routes AES-GCM operations through CryptoCB,
bypassing software key storage and GCM table generation.

Key points:
- Add wc_CryptoCb_AesSetKey() callback for AES key import
- Update AES SetKey paths to support key import mode with graceful
  fallback to software when CryptoCB is unavailable
- Skip GCM H/M table generation when AES-GCM is handled by the device
- Preserve existing software AES behavior when devId is INVALID_DEVID

Testing:
- Add unit test for CryptoCB AES SetKey behavior
- Add end-to-end AES-GCM offload unit test that verifies:
  * SetKey, Encrypt, Decrypt, and Free are routed via CryptoCB
  * Correct ciphertext/auth tag generation
  * Correct plaintext recovery after decrypt
  * Proper lifecycle handling of device context handles
- Tests use a mock Secure Element that internally performs software AES
  to validate routing without requiring hardware

@sameehj sameehj requested a review from douzzer January 14, 2026 14:35
@devin-ai-integration
Copy link
Contributor

devin-ai-integration bot commented Jan 14, 2026

🛟 Devin Lifeguard found 2 likely issues in this PR

  • check-all-return-codes snippet snippet: Capture the return value of wc_CryptoCb_UnRegisterDevice() in each test (e.g., ret = wc_CryptoCb_UnRegisterDevice(TEST_CRYPTOCB_AES_DEVID); ExpectIntEQ(ret, 0);) to ensure any error is detected.
  • limit-stack-usage snippet snippet: Use the WOLFSSL_SMALL_STACK pattern in the two newly added test functions: dynamically allocate the large local objects (Aes aes, the plaintext/ciphertext/authTag buffers, etc.) with XMALLOC/XFREE (guarded by #ifdef WOLFSSL_SMALL_STACK) instead of placing them on the stack.

@sameehj
please take a look at the above issues which Devin flagged. Devin will not fix these issues automatically.

@sameehj
Copy link
Contributor Author

sameehj commented Jan 14, 2026

retest this please

@sameehj sameehj force-pushed the aes-offload branch 2 times, most recently from b3bcd1c to fd6d469 Compare January 15, 2026 16:17
julek-wolfssl
julek-wolfssl previously requested changes Jan 15, 2026
View reviewed changes
Copy link
Member

@julek-wolfssl julek-wolfssl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see "proxy-key" appearing multiple times in the PR. What does it mean?
The ORIGINAL: comments should be cleaned up.

@julek-wolfssl
Copy link
Member

julek-wolfssl commented Jan 15, 2026

Is it possible to setup a gh action that tests this with wolfHSM? At the very least this new config should be added to os-check.yml.

@sameehj sameehj force-pushed the aes-offload branch 4 times, most recently from be96866 to ea7e61d Compare January 16, 2026 17:05
@sameehj sameehj changed the title cryptocb: add AES proxy-key support and end-to-end CryptoCB AES-GCM t… cryptocb: add AES CryptoCB key import support and tests Jan 16, 2026
@sameehj
Copy link
Contributor Author

sameehj commented Jan 16, 2026

I see "proxy-key" appearing multiple times in the PR. What does it mean? The ORIGINAL: comments should be cleaned up.

Dropped proxy-key terminology
and dropped 'ORIGINAL" comments

@sameehj sameehj force-pushed the aes-offload branch 10 times, most recently from 5e03e8f to b02f16b Compare January 22, 2026 18:23
@douzzer
Copy link
Contributor

douzzer commented Jan 23, 2026

retest this please

@sameehj sameehj force-pushed the aes-offload branch 4 times, most recently from a7d4524 to 39d2c2a Compare January 26, 2026 18:18
@sameehj
Copy link
Contributor Author

sameehj commented Jan 27, 2026

retest this please

@sameehj sameehj force-pushed the aes-offload branch 2 times, most recently from ece931c to 6e377c0 Compare January 30, 2026 11:32
douzzer
douzzer requested changes Feb 3, 2026
View reviewed changes
Copy link
Contributor

@douzzer douzzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this implementation looks really strong.

I left comments with reconciliation suggestions for the conflicts, and a comment on a stray linefeed that snuck in. otherwise, LGTM!

@sameehj
cryptocb: add AES CryptoCB key import support and tests
425dc13 
Add CryptoCB-based AES key import support to enable Secure Element
offload without exposing raw AES key material to wolfCrypt.

When WOLF_CRYPTO_CB_AES_SETKEY is defined, wolfCrypt invokes a CryptoCB
callback during AES key setup. Behavior is determined by the callback
return value:

- If callback returns 0: Key is imported to the device (aes->devCtx).
  Key is NOT copied to wolfCrypt RAM; GCM H/M tables are NOT generated.
  Full hardware offload is assumed.

- If callback returns CRYPTOCB_UNAVAILABLE: Device does not support
  SetKey. Normal software path is used; key is copied to devKey for
  optional encrypt/decrypt acceleration.

- Any other error: Propagated to the caller.

Key points:
- Add wc_CryptoCb_AesSetKey() callback for AES key import
- Update AES SetKey paths to call CryptoCB and branch on return value
- Skip GCM H/M table generation when callback succeeded (devCtx set)
- Preserve existing behavior when devId is INVALID_DEVID or
  WOLF_CRYPTO_CB_AES_SETKEY is not defined

Testing:
- Add unit test for CryptoCB AES SetKey (verifies key isolation when
  callback succeeds)
- Add end-to-end AES-GCM offload test (SetKey, Encrypt, Decrypt, Free
  via CryptoCB)
- Tests use a mock SE with software AES to validate routing

Enable with: CPPFLAGS="-DWOLF_CRYPTO_CB_AES_SETKEY -DWOLF_CRYPTO_CB_FREE"

Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
@sameehj
Copy link
Contributor Author

sameehj commented Feb 3, 2026

retest this please

@douzzer douzzer self-requested a review February 3, 2026 18:20
douzzer
douzzer approved these changes Feb 3, 2026
View reviewed changes
Copy link
Contributor

@douzzer douzzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wolfssl-multi-test.sh ... pr-check:

final tally for 425dc1372d with build env c2c7829175: all 51 selected checks succeeded.

@douzzer douzzer merged commit 492ff38 into wolfSSL:master Feb 3, 2026
419 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@douzzer douzzer douzzer approved these changes

@julek-wolfssl julek-wolfssl julek-wolfssl left review comments

Assignees

@sameehj sameehj

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@sameehj @julek-wolfssl @douzzer