Add SRAM PUF (Physically Unclonable Function) support to wolfCrypt. Derives device-unique cryptographic keys from the power-on state of SRAM memory using a BCH(127,64,t=10) fuzzy extractor with HKDF key derivation.
- **wolfCrypt PUF API** (`wolfcrypt/src/puf.c`, `wolfssl/wolfcrypt/puf.h`)
- `wc_PufInit`, `wc_PufReadSram`, `wc_PufEnroll`, `wc_PufReconstruct`
- `wc_PufDeriveKey` (HKDF-SHA256), `wc_PufGetIdentity` (SHA-256 device fingerprint)
- `wc_PufZeroize` (secure context cleanup)
- `wc_PufSetTestData` (synthetic SRAM for testing without hardware)
- **BCH(127,64,t=10) error-correcting codec** - corrects up to 10 bit flips per 127-bit codeword across 16 codewords
- **`WC_PUF_SHA3` build option** - select SHA3-256 instead of SHA-256 for identity hash and HKDF (default: SHA-256)
- **Precomputed GF(2^7) tables** - `const` arrays in `.rodata` (no runtime init, thread-safe, flash-resident on embedded)
- `./configure --enable-puf` (auto-enables HKDF dependency)
- CMake: `WOLFSSL_PUF=yes`
- `WOLFSSL_USER_SETTINGS`: define `WOLFSSL_PUF` and `WOLFSSL_PUF_SRAM`
- See wolfssl-examples/puf for example implementation on STM32 NUCLEO-H563ZI (Cortex-M33, STM32H563ZI)
- Supports test mode (synthetic SRAM)
- Builds to ~13KB `.elf`
- Tested on NUCLEO-H563ZI: enrollment, noisy reconstruction, key derivation all pass
- `.github/workflows/puf.yml`: host build + test workflow for PUF feature
- Doxygen API docs for all 8 public functions
- PUF group added to `doxygen_groups.h`
scripts/pem.test:
* add setup for WOLFSSL_NO_DER_TO_PEM,
* exit early with skip code if executable dependencies are missing or WOLFSSL_NO_PEM or NO_CODING, and
* add clean skip clauses to convert_to_pem(), compare_pem(), and pem_der_exp(), if WOLFSSL_NO_DER_TO_PEM.
Two follow-ups raised by Copilot review on PR #10247:
src/pk_rsa.c: Make derAllocSz a word32 instead of int and only assign
it after a successful XMALLOC, so the cleanup path can never call
ForceZero with a wrapped-around size derived from a negative derSz.
src/pk.c: Capture allocSz at the XMALLOC call site (and clear it back
to 0 on allocation failure) so the relationship between the buffer
allocation and the recorded size is explicit and cannot drift if the
surrounding control flow changes.
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>
JacobBarthelmeh
Daniel Pouzzner
Kareem
Paul Adelsbach
David Garske
Andrew Hutchings
Mattia Moffa
Sean Parkinson
Josh Holtrop
Jeremiah Mackey
Juliusz Sosinowicz
Sameeh Jubran
Tobias Frauenschläger
Ruby Martin
Reda Chouk