Electronics Guide

Advanced Encryption Standard

The Advanced Encryption Standard (AES) has become the dominant symmetric cipher for embedded applications. Operating on 128-bit blocks with key sizes of 128, 192, or 256 bits, AES provides strong security with a structure amenable to efficient implementation on diverse hardware platforms.

Software implementations of AES typically use lookup tables to combine the SubBytes, ShiftRows, and MixColumns operations into a series of table lookups and XOR operations. A standard T-table implementation requires 4 kilobytes of ROM for the four encryption tables but achieves good performance on 32-bit processors. For more constrained systems, byte-oriented implementations working from the 256-byte substitution box alone reduce memory requirements at the cost of increased execution time.

Table-driven AES carries a security cost that has to be weighed against its speed. The table index depends on secret key material, so on any processor with a data cache the access pattern leaks through cache timing, and practical key-recovery attacks against T-table AES are well established. Simple microcontrollers without caches or speculative execution escape this particular problem, but application-class embedded processors running Linux do not. Where a table-free approach is required, bitsliced implementations represent the state across machine words and compute the substitution box with Boolean logic, giving constant-time behavior at the price of code size and a preference for processing several blocks at once.

Many modern microcontrollers include hardware AES accelerators that perform encryption and decryption operations in dedicated logic. These accelerators typically achieve throughputs of hundreds of megabits per second while consuming minimal power and freeing the CPU for other tasks. Hardware implementations also provide inherent resistance to certain side-channel attacks that plague software implementations.

Block cipher modes of operation determine how AES encrypts data larger than a single 128-bit block. Counter mode (CTR) and Galois/Counter Mode (GCM), both specified by NIST in SP 800-38A and SP 800-38D, are particularly suitable for embedded systems. CTR mode enables parallel encryption and decryption operations, while GCM provides authenticated encryption that simultaneously ensures confidentiality and integrity.

GCM imposes a strict operational constraint that embedded designers frequently underestimate: a nonce must never repeat under a given key. Repeating a nonce not only reveals the XOR of the affected plaintexts but also exposes the GHASH authentication subkey, which lets an attacker forge arbitrary messages. Devices that lack persistent counters across reset, or that clone the same key into many units, are especially prone to this failure. A monotonic counter held in non-volatile memory, a per-session key derived through key agreement, or the nonce-misuse-resistant AES-GCM-SIV construction of RFC 8452 each mitigate the risk.

Lightweight Symmetric Ciphers

For severely constrained devices such as smart cards, RFID tags, and ultra-low-power sensors, even optimized AES implementations may exceed available resources. Lightweight cryptographic algorithms address this need by trading some security margin for reduced implementation cost.

PRESENT is a lightweight block cipher operating on 64-bit blocks with 80-bit or 128-bit keys, standardized in ISO/IEC 29192-2. Its simple structure, based on a 4-bit substitution box and a bit-permutation layer, requires minimal logic gates, making it suitable for hardware implementation in area-constrained designs. Its 64-bit block is its main limitation: birthday-bound distinguishers become a concern well before a few tens of gigabytes are encrypted under one key, so 64-bit-block ciphers suit short messages and infrequent traffic rather than bulk data.

SIMON and SPECK, published by the U.S. National Security Agency in 2013, offer flexible block and key sizes optimized for different implementation constraints. SIMON targets hardware efficiency with its Feistel structure and simple round function, while SPECK achieves excellent performance in software through addition, rotation, and XOR operations. After several years of deliberation, ISO/IEC JTC 1 rejected the pair from the lightweight block cipher standard ISO/IEC 29192-2 in 2018, largely over the designers' reluctance to publish full design rationale. Both were nonetheless standardized for radio-frequency identification air interfaces in ISO/IEC 29167-21 and 29167-22, and no practical break of either cipher has been published.

The NIST Lightweight Cryptography competition selected the Ascon family in 2023, and NIST published the resulting standard, SP 800-232, in August 2025. The standard specifies Ascon-AEAD128 for authenticated encryption with associated data, Ascon-Hash256 for hashing, and the Ascon-XOF128 and Ascon-CXOF128 extendable-output functions. All four build on a single 320-bit permutation, so one compact hardware block or one software routine serves every function in the suite. That reuse is the decisive advantage on constrained parts: a device needing both authenticated encryption and hashing pays for one primitive instead of an AES engine plus a SHA-2 engine.

Stream Ciphers

Stream ciphers generate a pseudorandom keystream that is XORed with plaintext to produce ciphertext. This approach is particularly efficient when encrypting data of arbitrary length or when data arrives continuously rather than in fixed-size blocks.

ChaCha20 has emerged as a preferred stream cipher for embedded systems. Designed by Daniel Bernstein as a variant of Salsa20, ChaCha20 uses only 32-bit addition, rotation, and XOR operations, which map efficiently to general-purpose processors and are naturally constant-time because no operation depends on secret data for its timing. In the form standardized by RFC 8439, the algorithm produces keystream in 64-byte blocks from a 256-bit key, a 96-bit nonce, and a 32-bit block counter; Bernstein's original specification divides the same 128 bits differently, as a 64-bit nonce and a 64-bit counter.

Because ChaCha20 is a counter-based stream cipher, it inherits the same absolute prohibition on nonce reuse as AES-CTR and AES-GCM. Encrypting two messages with one key and one nonce discloses the XOR of the plaintexts.

ChaCha20-Poly1305 combines the ChaCha20 stream cipher with the Poly1305 message authentication code to provide authenticated encryption. RFC 8439 specifies the construction, and TLS 1.3 defines the cipher suite TLS_CHACHA20_POLY1305_SHA256 alongside the AES-GCM suites. It is well suited to embedded systems lacking AES hardware acceleration, where a table-free software AES is both slow and awkward to protect against cache and timing leakage.

RSA Implementation

RSA remains widely deployed despite its computational intensity. Security depends on the difficulty of factoring the product of two large prime numbers, requiring key sizes of 2048 bits or larger for current security requirements. RSA-2048 provides roughly 112 bits of security, and NIST's transition guidance (IR 8547) targets deprecation of algorithms at that level after 2030 and their removal from federal use after 2035. Embedded products designed today with service lives measured in decades should treat RSA as a legacy interoperability option rather than a long-term choice.

The asymmetry between RSA operations shapes system design. Verification with the common public exponent 65537 costs only 17 modular squarings and multiplications, so it is cheap enough for a bootloader on a small microcontroller. Signing and decryption require a full-length private exponent and cost hundreds of times more. Architectures that push signing to a provisioning server or a secure element and leave only verification on the device therefore fit constrained hardware well, which is why RSA and ECDSA verification persist in secure boot long after key agreement has moved elsewhere.

Efficient RSA implementation on embedded systems requires optimized modular arithmetic for large integers. Montgomery multiplication eliminates expensive division operations by working in a transformed representation, while the Chinese Remainder Theorem accelerates private key operations by performing calculations modulo the individual prime factors rather than their product.

Modular exponentiation, the core operation in RSA, is typically implemented using the square-and-multiply algorithm. However, the data-dependent execution pattern of this algorithm leaks information through timing and power consumption. Constant-time implementations use techniques such as Montgomery ladder or fixed-window exponentiation to prevent these side-channel leaks.

RSA key generation requires high-quality random numbers and primality testing. The Miller-Rabin probabilistic primality test is commonly used, with sufficient iterations to achieve acceptable confidence that generated values are prime.

Elliptic Curve Cryptography

Elliptic curve cryptography (ECC) provides security equivalent to RSA with dramatically smaller key sizes. A 256-bit elliptic curve key offers security comparable to a 3072-bit RSA key, making ECC particularly attractive for embedded systems where memory and computational resources are limited.

ECC operations are performed on points lying on an elliptic curve over a finite field. Curves over prime fields are commonly written in short Weierstrass form, y² = x³ + ax + b, though other models exist and matter in practice. The fundamental operation is scalar multiplication, computing the product of an integer scalar and a curve point through repeated point addition and doubling. Scalar multiplication dominates the cost of every elliptic curve protocol, so it is the operation that implementations optimize and that side-channel countermeasures must protect.

Several standardized curves are commonly used in embedded applications. The NIST P-256 curve, specified in FIPS 186-5, operates over a 256-bit prime field in short Weierstrass form and is the curve most widely supported by hardware accelerators, secure elements, and certificate authorities. Curve25519, designed by Daniel Bernstein and specified for key agreement in RFC 7748, instead uses a Montgomery model over the prime 2²⁵⁵ - 19. That structure permits the Montgomery ladder, in which every scalar bit triggers an identical sequence of a point addition and a point doubling, so a natural implementation is constant-time and free of exceptional cases without added countermeasures. The prime's shape also makes field reduction fast with simple 32-bit arithmetic, which is why Curve25519 performs well on Cortex-M class parts that lack a public-key accelerator.

The Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol enables two parties to establish a shared secret over an insecure channel. Each party generates an ephemeral key pair, exchanges public keys, and computes the shared secret through scalar multiplication. The shared secret can then seed symmetric key derivation for subsequent encrypted communication.

The Elliptic Curve Digital Signature Algorithm (ECDSA) provides digital signatures for authentication and non-repudiation. Signing requires a fresh secret nonce for each signature, and this requirement is the algorithm's most notorious implementation hazard. Signing two different messages with the same nonce lets an observer solve directly for the private key, and even partial nonce bias, leaked over many signatures through a side channel, is enough to recover the key by lattice methods. Embedded devices are unusually exposed here, because a weak or unseeded random generator at first boot can produce repeated nonces across an entire production run.

Two remedies are standard. RFC 6979 specifies deterministic ECDSA, deriving the nonce from the private key and the message hash through HMAC, so signing needs no entropy source at all. Alternatively, EdDSA, and in particular Ed25519 over the twisted Edwards curve edwards25519, builds deterministic nonce derivation into the algorithm itself. FIPS 186-5, published in February 2023, approved EdDSA for federal use alongside ECDSA. Ed25519 also offers complete addition formulas that require no special handling of edge cases, which removes a further class of implementation bugs. For new embedded designs without a compelling interoperability constraint, Ed25519 or deterministic ECDSA is the safer default.

Post-Quantum Cryptography

Quantum computers pose a future threat to currently deployed public-key cryptography. Shor's algorithm can efficiently factor large integers and compute discrete logarithms, breaking both RSA and elliptic curve cryptography. While large-scale quantum computers do not yet exist, the long deployment lifecycles of embedded systems, combined with the risk that adversaries record encrypted traffic today to decrypt later, motivate consideration of quantum-resistant alternatives.

In August 2024, NIST finalized its first post-quantum standards. FIPS 203 specifies ML-KEM, the module-lattice key-encapsulation mechanism derived from CRYSTALS-Kyber, while FIPS 204 specifies ML-DSA, the module-lattice digital signature algorithm derived from CRYSTALS-Dilithium. FIPS 205 adds SLH-DSA, a stateless hash-based signature scheme derived from SPHINCS+ that relies only on hash-function security as a conservative backup. These algorithms require larger keys and more computation than current elliptic curve methods, yet optimized implementations of ML-KEM and ML-DSA run on resource-constrained microcontrollers such as the Arm Cortex-M series.

For embedded designers the binding constraint is usually size rather than speed. ML-KEM-768 uses a 1,184-byte encapsulation key and a 1,088-byte ciphertext, against 32 bytes for an X25519 public key. ML-DSA-44 produces a 2,420-byte signature and a 1,312-byte public key, against 64 bytes for an Ed25519 signature. SLH-DSA is more extreme: its public keys are tiny, but signatures run from roughly 8 kilobytes for the small-signature parameter sets to several times that for the fast-signing sets. These figures matter concretely when a signature must fit in a firmware image header, when a key must live in one-time programmable memory, or when a handshake must traverse a low-power radio link with a small maximum transmission unit.

Where signing is confined to firmware and software images, the stateful hash-based schemes LMS and XMSS, approved by NIST in SP 800-208, offer another option. Their security rests only on hash functions, and verification is cheap, but each one-time key within the tree may be used exactly once. The signer must therefore track consumed indices without fail, since a single reuse can expose the key, and a restored backup or a duplicated signing server is enough to cause one. These schemes accordingly suit a controlled signing facility with disciplined state management rather than a device signing in the field, which is where the stateless SLH-DSA earns its larger signatures.

Hybrid approaches combining classical and post-quantum algorithms provide defense in depth during the transition period. A system might combine ECDH with ML-KEM for key agreement, deriving the session key from both shared secrets so that the connection stays secure even if one algorithm is later found to be weak. This is the path the web has already taken: the hybrid group pairing X25519 with ML-KEM-768 is now widely deployed in TLS 1.3 by major browsers and content delivery networks, which gives embedded implementers a well-exercised target to interoperate with.

Symmetric cryptography needs far less adjustment. Grover's algorithm offers only a quadratic speedup against exhaustive key search, and that advantage does not parallelize well, so AES-256 and SHA-384 or SHA-512 remain sound choices. The practical consequence is that a system's quantum exposure lies almost entirely in its key establishment and signature choices, not in its bulk encryption.

SHA-2 Family

The SHA-2 family, specified in FIPS 180-4, includes SHA-224, SHA-256, SHA-384, and SHA-512, producing hash values of the indicated bit length. SHA-256 is the most commonly used variant, offering a good balance of security and performance for embedded applications. The 64-bit variants, SHA-384 and SHA-512, are faster than SHA-256 on 64-bit processors but slower on the 32-bit cores typical of embedded work, so SHA-256 is usually the right default on a microcontroller.

SHA-256 processes data in 512-bit blocks through 64 rounds of compression. Each round combines message schedule values with working variables using addition, rotation, and logical operations. A straightforward implementation holds an eight-word chaining value (32 bytes), eight 32-bit working variables (32 bytes), and a fully expanded 64-word message schedule (256 bytes), for 320 bytes of state. Because each schedule word depends only on the four preceding it at fixed offsets, memory-constrained implementations replace the full schedule with a rolling window of sixteen words, cutting that 256 bytes to 64 and bringing total state below 130 bytes at a modest cost in arithmetic.

Hardware acceleration for SHA-256 is available in many microcontrollers, particularly those targeting security applications. Hardware implementations achieve significantly higher throughput than software while potentially offering side-channel resistance through constant-time operation.

SHA-3 and SHAKE

SHA-3, standardized as FIPS 202 in August 2015, uses an entirely different construction from SHA-2. Based on the Keccak sponge function, SHA-3 absorbs input data into a state array and squeezes output of the desired length. This sponge construction enables extendable-output functions (XOFs) that produce arbitrary-length output. It also resists length-extension attacks by design, whereas the Merkle-Damgard structure of SHA-2 does not, which is why a naive keyed hash of the form H(key || message) is unsafe with SHA-256 but sound with SHA-3.

SHAKE128 and SHAKE256 are XOFs derived from the SHA-3 construction. These functions can generate output of any desired length, making them useful for key derivation, mask generation, and other applications requiring variable-length output.

The Keccak permutation at the heart of SHA-3 operates on a 1600-bit state organized as a five-by-five array of 64-bit lanes. The permutation maps very well to hardware, where its bitwise structure yields high throughput at modest gate count. Software on 32-bit microcontrollers fares less well, because 200 bytes of state must stay resident and each 64-bit lane rotation must be synthesized from 32-bit operations; the bit-interleaving technique recovers much of the loss but adds code. In practice SHA-3 is chosen on constrained parts for its sponge properties and its XOFs rather than for raw speed, and Ascon-Hash256 is often the better fit when only a compact hash is needed.

Lightweight Hash Functions

Constrained embedded devices may lack resources for standard SHA-256 implementation. Lightweight hash functions reduce state size and computational requirements while maintaining security appropriate for their intended applications.

PHOTON and SPONGENT are lightweight hash functions based on sponge constructions with reduced state sizes. These designs target hardware implementation efficiency, achieving small gate counts suitable for integration into smart cards and RFID tags.

The ASCON permutation, standardized by NIST for lightweight cryptography, also serves as the basis for a hash function. Ascon-Hash256 provides a compact, efficient 256-bit hash suitable for the most constrained embedded devices, allowing a single permutation to support both authenticated encryption and hashing.

HMAC Construction

HMAC (Hash-based Message Authentication Code), specified in RFC 2104 and FIPS 198-1, constructs a MAC from any cryptographic hash function. The construction applies the hash function twice with the key mixed into distinct inner and outer padding constants, which both defeats length-extension attacks and preserves security even if the underlying hash function loses collision resistance.

HMAC-SHA256 is widely used in embedded systems for message authentication, key derivation, and pseudorandom number generation. The construction inherits the performance characteristics of the underlying hash function, benefiting from any available hardware acceleration.

Implementing HMAC requires careful key handling. Keys shorter than the hash block size should be padded, while longer keys should be hashed to the appropriate length. The secret key must be protected from disclosure through memory protection and secure storage.

CMAC and GMAC

Cipher-based Message Authentication Code (CMAC), specified in NIST SP 800-38B, constructs a MAC using a block cipher, typically AES. CMAC processes the message in cipher-block chaining mode with special handling for the final block, derived from two subkeys, producing a tag no longer than the cipher's block size. The final-block treatment is what makes CMAC secure for variable-length messages, a property that plain CBC-MAC lacks.

GMAC, defined alongside GCM in NIST SP 800-38D, is the authentication-only variant of Galois/Counter Mode, using the Galois field multiplication at the heart of GCM without encrypting a payload. GMAC achieves high throughput where hardware accelerates the carry-less polynomial multiplication, but it inherits GCM's nonce requirements in full.

Both CMAC and GMAC benefit from the AES hardware acceleration available in many microcontrollers, and where such acceleration exists these cipher-based MACs commonly outperform HMAC-SHA256 at equivalent security. CMAC is the usual choice when a device already has an AES engine and no hash accelerator, since it avoids compiling a hash function at all.

Whichever MAC is used, tag verification must compare the computed and received tags in constant time. A comparison that returns on the first differing byte leaks the position of the mismatch, and an attacker who can submit many forgeries and time the response can recover a valid tag byte by byte. Implementations should accumulate the difference of all bytes with XOR and OR operations and test the result once, and they must discard decrypted plaintext entirely when verification fails rather than releasing it to the application.

Poly1305

Poly1305 is a high-speed one-time authenticator that produces a 128-bit tag from a message and a single-use 256-bit key. The algorithm evaluates the message as a polynomial modulo the prime 2¹³⁰ - 5 and adds a secret value, using multiply-and-accumulate operations that map efficiently to 32-bit and 64-bit processors and require no lookup tables.

Poly1305 must be used with a unique key for each message; key reuse enables forgery attacks. In practice, Poly1305 is combined with a stream cipher like ChaCha20 that generates fresh authentication keys from a master key and message nonce.

The ChaCha20-Poly1305 authenticated encryption construction has become widely adopted as an alternative to AES-GCM. On processors lacking AES hardware acceleration, ChaCha20-Poly1305 typically achieves higher performance while providing equivalent security.

Side-Channel Attack Resistance

Side-channel attacks exploit information leakage through power consumption, electromagnetic emissions, timing variations, or other observable characteristics of cryptographic operations. Embedded systems are particularly vulnerable due to the physical accessibility of devices and the close correlation between simple processor operations and observable phenomena.

Timing attacks exploit variations in execution time that depend on secret values. Conditional branches based on key bits, early-exit optimizations, and table lookups with key-dependent indices all create timing variations that can be measured and analyzed to recover keys.

Power analysis attacks measure the power consumption of a device during cryptographic operations. Simple power analysis (SPA) directly observes power traces to identify operations, while differential power analysis (DPA) uses statistical analysis of many traces to extract key bits from small power variations correlated with intermediate values.

Constant-time implementation is the primary defense against timing and power analysis attacks. Code must execute the same sequence of operations regardless of secret values, avoiding conditional branches, variable-length loops, and memory accesses at secret-dependent addresses. This requirement significantly constrains implementation choices and typically reduces performance compared to unprotected implementations.

Masking techniques protect against power analysis by splitting secret values into random shares that are processed independently and recombined only at the end of computation. Boolean masking XORs secrets with random masks, while arithmetic masking adds random values. Higher-order masking uses multiple shares for increased protection against sophisticated attacks.

Fault Attack Countermeasures

Fault attacks deliberately induce errors in cryptographic computations through voltage glitches, clock manipulation, electromagnetic pulses, or laser illumination. By analyzing faulty outputs, attackers can recover secret keys with dramatically fewer operations than required for exhaustive search.

Differential fault analysis against AES can recover the complete key from a small number of faulty ciphertexts. The attack exploits the algebraic structure of AES to deduce key bytes from differences between correct and faulty outputs.

Countermeasures include redundant computation, where critical operations are performed multiple times and results compared before use. Integrity checking verifies that intermediate values remain consistent throughout computation. Hardware sensors can detect glitching attempts and trigger protective responses such as key erasure.

Algorithm-level countermeasures modify the computation to be inherently resistant to certain fault classes. Infection countermeasures propagate faults through subsequent computation in ways that prevent useful analysis of faulty outputs.

Random Number Generation

Cryptographic security depends fundamentally on high-quality random numbers for key generation, nonces, and protocol randomness. Predictable or biased random numbers enable attacks that bypass cryptographic protection entirely.

Hardware random number generators (HRNGs) extract entropy from physical phenomena such as thermal noise, ring oscillator jitter, or metastable circuits. Many microcontrollers include integrated HRNGs that provide raw entropy or conditioned random output suitable for cryptographic use.

Deterministic random bit generators (DRBGs) stretch limited entropy into larger quantities of pseudorandom output. NIST SP 800-90A defines approved DRBG constructions based on hash functions and block ciphers; the elliptic-curve construction Dual_EC_DRBG that the standard once contained was withdrawn in 2014 after analysis showed it could accommodate a back door, and it should never appear in new designs. DRBGs must be seeded with sufficient entropy and reseeded periodically to maintain security.

The wider standards family divides the problem: SP 800-90A covers the deterministic output stage, SP 800-90B covers entropy sources and specifies the continuous health tests, including the repetition count and adaptive proportion tests, that a source must run while operating, and SP 800-90C covers how the two are combined into a complete construction. Designers integrating a microcontroller's on-chip generator should confirm that its health tests are enabled and that failures are surfaced rather than silently ignored.

Boot-time entropy is the recurring embedded failure. A device that generates a key pair or a nonce immediately after reset may draw from a generator that has not yet accumulated entropy, and because every unit of a production run starts from the same state, the resulting keys can collide across the whole fleet. Surveys of deployed network devices have repeatedly found duplicate keys traceable to exactly this cause. Robust designs block cryptographic operations until the entropy source reports readiness, preserve a seed in non-volatile memory across reboots, and mix in device-unique values such as a serial number or physically unclonable function response.

Testing random number generators presents unique challenges, as any finite output sequence could in principle be produced by a deterministic process. Statistical test suites such as NIST SP 800-22 evaluate distributional properties, but passing them proves only the absence of gross defects; a counter encrypted under AES passes every such test while remaining perfectly predictable to anyone holding the key. Meaningful assurance comes from a documented entropy source model, min-entropy estimation on raw samples before conditioning, and continuous health monitoring in the field.

Software Libraries

Mbed TLS, formerly PolarSSL and now maintained under the TrustedFirmware.org umbrella, provides a compact cryptographic library and TLS stack designed for embedded systems. The library offers a small footprint, modular build configuration that lets unused algorithms be compiled out, and implementations of common algorithms including AES, SHA-256, RSA, and elliptic curve cryptography.

wolfSSL is another embedded-focused library covering TLS, DTLS, and a wide range of cryptographic algorithms. It includes assembly optimizations for Arm Cortex-M processors and integration layers for the hardware accelerators on popular microcontroller families, and it is frequently chosen where certified builds, such as FIPS 140-3 validated modules, are a procurement requirement.

The PSA Crypto API, defined by Arm and published through PSA Certified, matters more than any single library because it standardizes the interface rather than the implementation. Application code calls the same functions whether the operation runs in software, in an on-chip accelerator, or inside a secure element, and key material is referenced by opaque handle rather than by pointer, so keys need never enter application memory. Mbed TLS implements the API, and several silicon vendors ship it over their own security subsystems, which makes portable embedded cryptographic code considerably more attainable than it once was.

Libsodium provides a high-level cryptographic API designed for ease of use and resistance to implementation errors, emphasizing secure defaults, constant-time primitives, and modern algorithms such as Curve25519, Ed25519, and ChaCha20-Poly1305. Its footprint suits application-class embedded processors better than small microcontrollers, for which the trimmed-down TweetNaCl or a vendor-integrated stack is a closer fit.

Micro-ECC provides a minimal implementation of elliptic curve cryptography for embedded systems, covering ECDH and ECDSA over common NIST curves in a few kilobytes of code. Libraries in this class are useful when a design needs public-key operations and nothing more, and their narrow scope is part of the appeal: less code to audit and less to fit in flash.

Whatever the choice, the selection criteria differ from those on a server. Actively maintained code with a track record of prompt security advisories matters more than benchmark results, because a library compiled into a fielded device is difficult to replace. Designers should also confirm that the specific build enables constant-time paths, since some libraries offer faster variants that trade away side-channel resistance.

Hardware Acceleration

Modern microcontrollers increasingly include dedicated cryptographic accelerators. These hardware engines perform encryption, hashing, and public-key operations with higher throughput and lower power consumption than software implementations.

AES accelerators are the most common cryptographic hardware, available even in low-cost microcontrollers. Hardware AES implementations typically support multiple modes of operation and key sizes, with DMA integration for processing large data volumes without CPU intervention.

Hash accelerators for SHA-256 and SHA-512 offload the computationally intensive compression function from the CPU. Some implementations support simultaneous processing of multiple hash contexts, enabling efficient hashing of multiple data streams.

Public-key accelerators for RSA and elliptic curve operations vary widely in capability. Basic accelerators provide modular arithmetic primitives, while more sophisticated engines perform complete key generation, signature, and key agreement operations with side-channel protection.

True random number generator (TRNG) hardware provides entropy for cryptographic applications. TRNGs should include health monitoring to detect failures and conditioning to improve statistical quality of raw entropy.

Secure Elements

Secure elements are dedicated security chips that store keys and perform cryptographic operations in tamper-resistant hardware. By isolating secret keys from the main processor, secure elements protect against software vulnerabilities and many physical attacks. They occupy the same design space as the larger hardware security modules used in servers and payment infrastructure, scaled down to a component costing a fraction of a dollar.

Common secure element interfaces include I2C and SPI for communication with the host processor. Command sets vary by vendor but typically include key generation, signature operations, encryption, and secure storage of certificates and configuration data.

A useful property of many secure elements is that a private key generated on the device can be marked non-extractable, so it never leaves the chip in any form. The host can request signatures or key agreement but cannot read the key, which means compromising the application processor does not by itself yield the device identity. Provisioning practice matters as much as the hardware: keys injected at manufacture must be unique per device, and a supplier that programs one key across a product line eliminates the benefit entirely.

Trusted Platform Module (TPM) chips implement standardized secure element functionality for computing platforms. TPM 2.0, published by the Trusted Computing Group and adopted as ISO/IEC 11889, specifies key hierarchies, platform configuration registers for measured boot, and remote attestation. Though originally aimed at personal computers, TPM 2.0 and firmware TPM implementations now appear in embedded and industrial designs.

Integrated security subsystems within system-on-chip devices provide comparable protection without an external component, typically as a separate processor core with its own memory and key storage. Arm TrustZone is a related but distinct mechanism: it partitions a single core into secure and non-secure states, forming the basis of many trusted execution environments by isolating secure code and keys from the main application and its operating system. That isolation is a strong software boundary, not tamper resistance, and TrustZone alone does not defend against an attacker with physical access to probe or glitch the die. Designs facing a physical threat model combine isolation with dedicated tamper-resistant storage.

Key Generation and Storage

Keys must be generated from high-quality random sources with sufficient entropy for the intended security level. Symmetric keys should be generated directly from random bytes, while asymmetric keys require additional processing to produce valid key pairs.

Secure key storage protects keys from extraction by unauthorized parties. Options include encrypted storage using device-unique keys, hardware-protected key stores in secure elements, and one-time programmable memory for permanent keys.

Key derivation functions generate multiple keys from a single master secret. HKDF (HMAC-based Key Derivation Function), specified in RFC 5869 and approved in NIST SP 800-56C, is widely used for deriving symmetric keys from shared secrets established through key agreement. Its two-stage extract-then-expand structure first condenses a non-uniform shared secret into a fixed-length pseudorandom key, then expands that into as many independent keys as the protocol needs, each bound to a distinct context string. Binding derived keys to context in this way prevents a key intended for one purpose or direction from being accepted for another.

Where a key must be derived from a human-chosen password rather than a random secret, an ordinary KDF is inadequate, because the input has too little entropy to resist offline guessing. Deliberately slow, memory-hard functions such as PBKDF2 with a high iteration count, scrypt, or Argon2 raise the cost per guess. On microcontrollers the work factor must be tuned against the device's own modest performance, which limits how much protection this approach can buy; where possible, embedded designs should avoid password-derived keys altogether.

Key Distribution

Symmetric keys must be distributed to communicating parties through secure channels. In manufacturing, keys may be injected during production in controlled facilities. In the field, asymmetric key agreement protocols establish shared secrets without pre-shared keys.

Public-key infrastructure (PKI) distributes public keys through signed certificates that bind keys to identities. Certificate chains enable verification back to trusted root authorities, though embedded systems must carefully manage certificate storage and revocation checking.

Key wrapping protects keys during storage and transport by encrypting them with other keys. The wrapped key can be safely stored or transmitted, with unwrapping possible only by parties holding the wrapping key. NIST SP 800-38F specifies the AES key wrap algorithms for this purpose; they authenticate as well as encrypt, so a tampered wrapped key is rejected rather than unwrapped into unpredictable material. A common embedded pattern stores application keys wrapped under a device-unique key that exists only inside a secure element or fuse-programmed hardware, so a firmware image dumped from external flash yields nothing usable on another device.

Key Lifecycle Management

Keys have finite lifetimes based on cryptographic strength, usage volume, and policy requirements. Session keys may last only for a single communication session, while device identity keys may remain valid for the device's entire operational life.

Key rotation replaces keys before they become vulnerable due to excessive use or advancing cryptanalysis. Rotation procedures must maintain service continuity while transitioning to new keys.

Key revocation invalidates compromised or no-longer-trusted keys. Embedded systems face challenges in revocation because devices may lack continuous network connectivity to receive revocation information. Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) provide mechanisms for checking certificate validity when connectivity is available.

Secure key destruction ensures that keys cannot be recovered after they are no longer needed. Memory containing keys should be overwritten before it is released, and devices should provide mechanisms for key erasure upon detecting tampering or reaching end of life.

Erasure is harder in practice than it appears. An optimizing compiler is entitled to remove a call that clears a buffer the program never reads again, and this dead-store elimination has silently defeated key wiping in real code; implementations should use a function the toolchain cannot discard, such as memset_s, explicit_bzero, or a volatile-qualified write loop. Copies also propagate: keys may persist in stack frames, in registers spilled during a context switch, in DMA buffers, or in a core dump. Flash memory adds its own difficulty, since wear-leveling and erase-block granularity mean an overwrite may leave the original data intact elsewhere on the device, which is a strong argument for storing keys only in wrapped form or inside dedicated hardware that supports genuine erasure.

TLS for Embedded Systems

Transport Layer Security (TLS) protects network communications between embedded devices and servers. Embedded TLS implementations balance security, code size, and memory requirements, often supporting only essential cipher suites and features.

TLS 1.3, specified in RFC 8446, simplifies the protocol and removes legacy algorithms while improving security and reducing handshake latency from two round trips to one. Its smaller algorithm menu is a direct benefit to embedded implementers, because static RSA key transport, CBC-mode cipher suites, renegotiation, and compression, all sources of past vulnerabilities, are simply gone. DTLS 1.3, specified in RFC 9147, carries the same design to datagram transports for devices communicating over UDP.

Cipher suite selection affects both security and resource requirements. Modern suites based on AES-GCM or ChaCha20-Poly1305 with ephemeral elliptic curve key exchange provide strong security at reasonable embedded cost, and the choice between them usually follows the hardware: use AES-GCM where the part has an AES accelerator, ChaCha20-Poly1305 where it does not.

Certificate handling, rather than the cipher suites, is often what strains a constrained device. A chain of X.509 certificates can consume several kilobytes of RAM to parse and validate, and the parsing code itself has a poor security history. Devices operating in closed ecosystems can avoid the problem with pre-shared keys or raw public keys, the latter specified in RFC 7250, which authenticate a peer by a known key rather than a certificate chain. For the most constrained networks, the object security approach of OSCORE protects application payloads end to end across intermediaries at far lower overhead than a TLS record layer, with EDHOC providing the matching lightweight key exchange.

A protocol is only as good as its identity checks. Embedded TLS clients must validate the server certificate chain against a trust anchor and verify the identity in it; disabling verification during development and shipping that configuration remains one of the most common and most damaging embedded security defects. Certificate expiry deserves equal attention, since a device with no reliable clock cannot evaluate validity dates, which argues for a trusted time source or an authentication scheme that does not depend on one.

Secure Boot

Secure boot verifies firmware integrity and authenticity before execution, preventing unauthorized code from running on the device. The boot process forms a chain of trust from hardware root to application code. The discussion here covers the cryptographic mechanics; secure boot and attestation examines the full process and how a device proves its state to a remote party.

The first stage of secure boot typically runs from immutable ROM, establishing the root of trust. This code verifies the next boot stage using public-key signatures or symmetric authentication before transferring control.

Each subsequent boot stage verifies the next, extending the chain of trust through bootloader, operating system, and application layers. Failure at any stage prevents booting, ensuring only authorized code executes.

Firmware Updates

Secure firmware update mechanisms protect against installation of malicious or corrupted firmware. Updates must be authenticated to verify origin and encrypted where the image itself is confidential. The cryptographic essentials appear below; firmware update security covers delivery, staging, and recovery in detail.

Digital signatures provide strong authentication of firmware origin. The device stores the update authority's public key and verifies signatures before accepting updates. Multiple signatures can require approval from multiple parties.

Rollback protection prevents reinstallation of older, potentially vulnerable firmware versions. Monotonic counters or version numbers stored in secure memory ensure that only firmware at least as new as the installed version can be applied. Without this control, an attacker can simply replay a properly signed but superseded image to reintroduce a patched vulnerability.

Order of operations matters as much as the cryptography. A device must verify the signature over a complete image before executing any part of it, which on parts with limited RAM usually means staging the image in external flash or a second internal bank and verifying in place. Interrupted updates must leave a bootable system, so designs commonly keep two images and switch only after verification succeeds. The update format specified in RFC 9019 and the SUIT manifest work provide a standardized way to express these requirements for constrained devices, and long-lived products should plan for the signing keys themselves to be replaceable, since an algorithm sound at design time may not remain so across a twenty-year service life.