Security

The security peripherals are the hardware RNG — a true entropy source for keys and nonces — and the crypto accelerators (AES, HASH, PKA). Today the SDK wraps the RNG with core_rng over ll_rng; the accelerators are present in silicon on the M33 Cores (the W5’s BLE stack uses its AES internally) but don’t have Core wrappers yet. Use the Core / HAL / LL toggle at the top of the sidebar to switch.

Overview

The RNG is an analog-noise-based generator — genuinely random, not a PRNG seeded from a clock. It’s available on the M4 and M33 Cores; Core.ST.L0 (M0+) has no RNG. There’s no HAL layer — the Core wrapper sits straight on the register layer.

Crypto-grade keys

For cryptographic key generation, draw your seed from the hardware RNG and run it through a vetted DRBG (e.g. mbedTLS) — the SDK doesn’t add NIST health-test conditioning on top of the raw peripheral.

Random numbers

Initialize once (it enables the RNG’s 48 MHz clock and blocks until the first value is ready), then read 32-bit values or fill a buffer:

#include "core.h"   // not on Core.ST.L0

  core_rng_init();
  uint32_t r = core_rng_read();          // one 32-bit value

  uint32_t buf[4];
  uint32_t n = core_rng_fill(buf, 4);    // returns how many were generated

  if (core_rng_error()) { /* seed or clock error */ }
  core_rng_deinit();

Crypto engines

The M33 Cores carry hardware crypto blocks beyond the RNG, but which ones depends on the MCU: the W5 (STM32WBA55) has AES, PKA and HASH; the H5 (STM32H523) has PKA and HASH but no AES; the L0 and L4 have none. None is exposed as a core_* wrapper yet. On the W5 the BLE stack uses AES internally; its PKA driver is still a stub, so BLE pairing is Just Works only:

AES — hardware AES-128/256, faster and lower-power than software crypto.
PKA / ECC — public-key accelerator for elliptic-curve math (BLE pairing ECDH, certificates).
HASH — SHA-256 / HMAC for integrity and message authentication.

See the matrix below for where each stands per Core; the implementation status tracks them as they gain Core APIs.

Cross-architecture support

The RNG is verified on the W5. The L4’s passed before and awaits a re-bench after a clock-select fix (September 2026); the H5’s builds but hasn’t been bench-run; the L0 has no RNG. The crypto engines have no user API yet (hover a chip for each feature):

·L0M0+n/a●L4M41/2●W5M332/4●H5M331/3WCH (RISC-V) · Nordic (nRF54) — in development

See the implementation status for the full matrix.

Known gaps

What the SDK itself lists as missing here, straight from the header:

lowC APINo bias correction / health tests

The hardware exposes a CED (clock error) and SEIS (seed error) bit which core_rng_error checks, but there's no NIST SP 800-90B continuous-health-test wrapper. Crypto-grade users should consume the raw words through a vetted DRBG (mbedTLS, etc.).

From the @studio unsupported notes in core_rng.h — tiles@6af026f.

API reference

Default-instance · Tier 2

uint32_t core_rng_read(void);

Read a single 32-bit random value (blocking). Returns 0 on timeout — check core_rng_error() if this happens.

Lower-level · Tier 1

void core_rng_init(void);

Initialize the hardware RNG. Enables the peripheral clock, configures the RNG, and waits for the first random number to be ready. On Core.ST.L4: requires HSI48 to be running (auto-enabled if USB is used, otherwise call ll_rcc_hsi48_enable() first).

uint32_t core_rng_fill(uint32_t * buf, uint32_t count);

Fill a buffer with random 32-bit values (blocking).

int core_rng_error(void);

Check if the RNG has a seed error (entropy source failure).

void core_rng_deinit(void);

Power down the RNG peripheral.

Generated from core_rng.h — tiles@2a1a847.