Skip to content

nrf51: fix AES key setup racing with hardware encryption - #11710

Draft
aidankeefe2022 wants to merge 1 commit into
wolfSSL:masterfrom
aidankeefe2022:nrf51
Draft

aidankeefe2022 wants to merge 1 commit into
wolfSSL:masterfrom
aidankeefe2022:nrf51

Conversation

@aidankeefe2022

Copy link
Copy Markdown
Member

Fixes Fenrir finding 12349.

wc_AesEncrypt() holds the crypto hardware mutex around nrf51_aes_encrypt(), but wc_AesSetKey() called nrf51_aes_set_key() without it. In SoftDevice builds this could change the global nRF51AesKey pointer between the encrypt path's setter call and its copy into the ECB record. In direct-hardware builds it could reprogram the shared ECB peripheral during an encrypt. In both cases one AES context could encrypt with another context's key.

Keep keys per context, and program them into hardware only while holding the mutex:

  • wc_AesSetKey() now only caches the key in aes->key. It no longer touches the hardware or any shared state. It also rejects a NULL userKey.
  • SoftDevice: remove the static nRF51AesKey pointer. The ECB record is filled straight from the key passed to nrf51_aes_encrypt().
  • Direct hardware: program the peripheral key inside nrf51_aes_encrypt() (under the mutex), right before nrf_ecb_crypt(), and reset it to zeros afterwards.
  • Zero the stack ECB record with ForceZero() on the success and error paths.
  • Document in nrf51.h that the nrf51 AES functions are not thread safe, that multithreaded builds need WOLFSSL_CRYPT_HW_MUTEX set to 1, and that they must not be called from interrupt handlers.

Fixes Fenrir finding 12349.

wc_AesEncrypt() holds the crypto hardware mutex around
nrf51_aes_encrypt(), but wc_AesSetKey() called nrf51_aes_set_key()
without it. In SoftDevice builds this could change the global
nRF51AesKey pointer between the encrypt path's setter call and its copy
into the ECB record. In direct-hardware builds it could reprogram the
shared ECB peripheral during an encrypt. In both cases one AES context
could encrypt with another context's key.

Keep keys per context, and program them into hardware only while
holding the mutex:

- wc_AesSetKey() now only caches the key in aes->key. It no longer
  touches the hardware or any shared state. It also rejects a NULL
  userKey.
- SoftDevice: remove the static nRF51AesKey pointer. The ECB record is
  filled straight from the key passed to nrf51_aes_encrypt().
- Direct hardware: program the peripheral key inside
  nrf51_aes_encrypt() (under the mutex), right before nrf_ecb_crypt(),
  and reset it to zeros afterwards.
- Zero the stack ECB record with ForceZero() on the success and error
  paths.
- Document in nrf51.h that the nrf51 AES functions are not thread safe,
  that multithreaded builds need WOLFSSL_CRYPT_HW_MUTEX set to 1, and
  that they must not be called from interrupt handlers.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🟡 Changes recommended

The hardware mutex remains disabled by default, leaving multithreaded direct-hardware builds vulnerable to the same key race.

1 open finding
What changed in this PR

Prevents nRF51 AES contexts from racing over shared hardware key state.

Changes:

  • Caches AES keys per context and validates null keys.
  • Programs and clears hardware keys under encryption locking.
  • Clears SoftDevice ECB records and documents concurrency requirements.
File Description
wolfssl/​wolfcrypt/​port/​nrf51.h Documents AES locking constraints.
wolfcrypt/​src/​port/​nrf51.c Removes shared key state and securely handles per-call keys.
wolfcrypt/​src/​aes.c Caches keys without programming shared hardware.

🧠 Review effort: Balanced


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment on lines +37 to +38
* builds define WOLFSSL_CRYPT_HW_MUTEX to 1 so wolfCrypt serializes its own
* calls; applications calling these directly must provide their own locking.

@wolfSSL-Fenrir-bot wolfSSL-Fenrir-bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Fenrir Automated Review — PR #11710

Scan targets checked: wolfcrypt-src, wolfcrypt-bugs, wolfcrypt-port-bugs, wolfssl-src, wolfssl-bugs
Coverage: 3 of 3 in-scope changed file(s) opened by the reviewer

Fenrir result: Approved ✅

No new issues found in the changed files.

Advisory only — this automated result does not count as a GitHub approval.

Review tier: Lite

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants