wolfCrypt Now Supports SRAM PUF for Device-Unique Keys

    • The problem

    Almost every connected device holds a secret key to sign firmware, authenticate a TLS session, or encrypt stored data. Keeping that key out of an attacker’s hands is the hard part, and it is not just a small-device problem. Store it in on-chip or external flash and anyone with JTAG, an exposed debug port, or access to the flash bus can read it out. Burn it into eFuses and it can still be recovered by decapping the die. A secure element or TPM solves this but adds cost, board space, and another supplier to qualify — and many designs, large and small, ship without one.

    wolfCrypt’s new SRAM PUF support is a software option for exactly those designs. It builds a device-unique key from the random values a block of RAM holds the instant the chip powers on. Those startup values differ from one chip to the next but repeat on the same chip, so with error correction wolfCrypt rebuilds the identical key on every boot. Nothing is written to flash or fuses: the key exists only in RAM, only while it is in use.

    The tech

    When SRAM powers on, each cell settles to a 0 or 1 based on microscopic manufacturing variation that cannot be controlled or cloned. The resulting pattern is random between chips but repeatable on the same chip — a silicon fingerprint. It is slightly noisy, so a few bits flip from boot to boot, which means you cannot use the raw bits as a key directly.

    wolfCrypt cleans that up with a BCH(127,64,t=10) fuzzy extractor — 16 codewords, each correcting up to 10 flipped bits — followed by HKDF-SHA256 to produce a 256-bit device key. There are two phases:

    • Enroll once, at provisioning. wc_PufEnroll reads the SRAM and produces public helper data plus a device identity. The helper data is safe to store in plain flash; it reveals nothing about the key and only tells the error corrector how to snap a future noisy reading back to the enrolled value.
    • Reconstruct every boot. wc_PufReconstruct uses the stored helper data to recover the exact same stable bits, and wc_PufDeriveKey regenerates the key.

    The key lives only for the moment it is used, then wc_PufZeroize wipes it. Desolder the flash and you find only public helper data; power off the board and the SRAM is just random noise. There is nothing to extract.

    Using it

    Enable it with –enable-puf (which pulls in HKDF automatically), WOLFSSL_PUF=yes under CMake, or WOLFSSL_PUF in your user_settings.h. It needs only a block of uninitialized SRAM at a known address, reserved with a NOLOAD linker region — so it runs on essentially any MCU, no vendor-specific part required. The whole feature adds roughly 13 KB, and a host/synthetic mode lets you develop and test it in CI with no hardware.

    #include 

wc_PufCtx ctx;
byte helper[WC_PUF_HELPER_BYTES];   /* public, store in flash */
byte key[WC_PUF_KEY_SZ];            /* 32-byte derived key    */

/* Enroll once at provisioning */
wc_PufInit(&ctx);
wc_PufReadSram(&ctx, (const byte*)PUF_SRAM_ADDR, WC_PUF_RAW_BYTES);
wc_PufEnroll(&ctx);
/* persist ctx.helperData to flash for later boots */

/* Reconstruct and derive every boot */
wc_PufInit(&ctx);
wc_PufReadSram(&ctx, (const byte*)PUF_SRAM_ADDR, WC_PUF_RAW_BYTES);
wc_PufReconstruct(&ctx, helper, sizeof(helper));
wc_PufDeriveKey(&ctx, (const byte*)"tls-identity", 12, key, sizeof(key));

/* ... use key ... */
wc_PufZeroize(&ctx);
ForceZero(key, sizeof(key));

    Because wc_PufDeriveKey is HKDF with a caller-supplied label, one PUF yields many independent, purpose-specific keys — a TLS identity key, a firmware-decryption key, a data-at-rest key — with no extra storage. A complete bare-metal example is in the wolfssl-examples repository. We have tested it on an STM32H5 (NUCLEO-H563ZI), and are working on further validation across additional platforms such as the Xilinx Zynq-7000.

    Learn more:

    If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.

    Download wolfSSL Now