HARDWARE SECURITY
Cryptography, chip identity, protected keys, secure storage, validation, and RTL ideas explained from the hardware point of view.
FOUR LEARNING TRACKS
Tracks follow learning goals. Comics and classroom articles are teaching formats within those tracks.
Understand hashes, encryption, identities and secure channels before choosing a mechanism.
For readers starting with security concepts.
Explore this track →
Follow trust from device identity and key storage through boot, attestation and updates.
For chip architects and system designers.
Explore this track →
Start with a firmware digest or an encrypted sensor block. Build the datapath and transfer rules, then test whether corrupted results can grant permission.
For readers with basic registers, bit operations and synchronous RTL. Begin with SHA-256 or AES, then follow Anti-Tampering Lessons 1–3 in order.
Explore this track →
Connect design claims to evaluation evidence, certification scope and product lifecycle duties.
For technical leads and product teams.
Explore this track →Reset release is not one simultaneous instant across the chip. If permission crosses a clock domain or precedes startup checks, it may be used while the system appears to be booting.
A valid signature proves that a trusted key signed these bits. It does not by itself prove the version is acceptable, that the measured image is the one about to execute, or that a key is released in the right lifecycle.
Rejecting faulty output does not prove that a cryptographic implementation leaks no information. DFA uses correct-versus-faulty output differences; SIFA conditions on faulted computations that still return a correct output and analyzes statistical bias in an intermediate value.
38 lessons
Reset release is not one simultaneous instant across the chip. If permission crosses a clock domain or precedes startup checks, it may be used while the system appears to be booting.
A valid signature proves that a trusted key signed these bits. It does not by itself prove the version is acceptable, that the measured image is the one about to execute, or that a key is released in the right lifecycle.
Rejecting faulty output does not prove that a cryptographic implementation leaks no information. DFA uses correct-versus-faulty output differences; SIFA conditions on faulted computations that still return a correct output and analyzes statistical bias in an intermediate value.
A fault campaign is a reproducible experiment specification, not a few random bit flips followed by a percentage. It records design version, targets, timing, effects, budget, oracle, and what the model cannot simulate.
A simulated fault target has engineering value only when it maps to physical behavior. Calibration is not tuning RTL parameters until a fault “looks successful”; it compares target, window, effect, repeatability, and residual mismatch against traceable measurements.
A security conclusion must say what is protected, which faults are assumed, which boundaries were tested, which counterexamples remain, and what is unknown. An evidence package is not a pile of reports; it lets another engineer reproduce the result and see its limits.
The failed image from lesson 3 still needs a closed fetch gate. This time, the verifier sends four bits instead of one. The receiver must decide which of sixteen values means permission. That decision matters as much as the encoder.
Three verifiers vote to release the same failed image. One corrupted replica can be outvoted. A shared wrong input can make all three vote yes. Before counting copies, draw what they share.
A controller must observe four completed transfers before releasing a result. Its up counter says four and its down counter says zero. Their sum is still four. Only three transfers actually occurred. A shared enable has advanced both counters together.
The controller is checking an unauthorized image. Its six-bit state changes from CHECK to RELEASE without a completed authorization. The new code is legal. A state decoder recognizes it and opens the gate. We first count which substitutions can do that.
CHECK-to-RELEASE is a legal arc. A fault changes the condition selecting it. Later, a token from transaction 1 is offered for transaction 2. Both requests can look structurally normal. We trace the evidence that should belong to each accepting event.
Software writes the same configuration twice. The shadow comparator sees a match and commits it. If both writes carry the same wrong value, the protocol still succeeds. We distinguish update consistency from permission to choose that value.
The receiver accepts a bad request at edge 2. Sticky records the error afterward, and the system resets later. The alert works, but it cannot withdraw the accepted request. We put detection and response beside the accepting edge.
Can extra check bits stop a failed boot check from becoming permission? Compare parity, complementary encoding and SECDED, then examine miscorrection and blocking before acceptance.
A bit flip that misses a request is not evidence of a defense. Define storage, timing, recovery and trust assumptions, then interpret 42 reproducible fault cases.
A correct signature result can change before it reaches the CPU. Follow the stored decision to accepted fetches, state a fault model, and separate timely blocking from later alerts.
Begin with why people hack consoles, then examine PS4, Xbox 360, PS3, 3DS, and Switch security cases before connecting threat models to Secure Boot, TEE, and SoC memory isolation.
A readable history of console media checks, region rules, interoperability, and the different ways attackers crossed trust boundaries—from TMSS to PS1 discs and PS2 software flaws.
Follow update authorization, target compatibility, anti-rollback, interruption-safe installation, trial boot, signing-key rotation, and recovery—and learn what each safeguard cannot guarantee.
Starting with a factory gateway that asks to connect, this classroom explains how Secure Boot, Measured Boot, and Remote Attestation work together—and what a successful check cannot prove.
Follow a research SoC incident through DEKs, KEKs, HUKs, authorization, rotation, revocation, recovery and cryptographic erasure. Twelve comics, a full lesson, engineering extensions and 26 runnable teaching-model tests.
Build a SHA-256 core for a firmware digest. Follow padded blocks, retained chaining state, 64 rounds and final delivery, with reference traces for debugging each stage.
Twelve comics follow a lab report across a hostile network, connecting TLS 1.3 keys, certificates, Finished and AEAD to authorization, forward secrecy and replay boundaries.
Twelve illustrated lessons start with one unfamiliar public key, open an X.509 certificate, follow its chain to a trust anchor, and finish with lifecycle, revocation, and device PKI.
Follow a repair notice through copied seals, hashes, signing, verification, and public-key trust. Twelve comics explain what a signature proves—and what still needs checking.
Twelve comics begin with the attacker's goal, then build Secure Boot from reset, a protected trust anchor, hashes, signatures, version policy, failure handling, and authenticated recovery.
Follow ECC from its 1985 origin through elliptic curves, point addition, Galois fields, scalar multiplication, and the simple idea that a private key is a number while a public key is a point.
Twelve illustrated lessons move from an exposed house key to HUK, key storage, trusted boot, secure storage, internal and external trust, and the complete hardware root-of-trust boundary.
Start with Alice's first-key problem, build an intuitive picture of primes and modular cycles, work through RSA's complete 7→13→7 example, then return to public-key identity and key exchange.
Eight illustrated lessons separate RSA factorization, the elliptic-curve discrete logarithm, Shor's period clues, and the post-quantum migration work that matters today.
Ten illustrated lessons explain SHA digests, resistance properties, the birthday bound, SHA-1's retirement, and the role of hashing in software and hardware security.
A 12-page visual guide to credentials, authentication, authorization, passwords, keys, certificates, tokens, device identity, attestation, and PUF. Start with a simple door-check story, then connect each picture to practical security design.
A nine-page classroom that turns the EU Cyber Resilience Act into a product-readiness map: scope, reporting dates, product classes, Annex I duties, conformity assessment, CE marking, and the evidence a real team must keep.
A ten-page classroom on why toner cartridge security is really a supply-chain trust problem. It starts with attacker incentives and PKI authentication, then explains why private keys, counters, and cartridge state need PUF and Secure Storage protection.
An eight-page classroom on FIPS 140-3 as a security inspection for cryptographic modules. It explains the validation flow, the assurance levels, and the hardware questions around keys, tamper response, roles, and evidence.
Thirteen illustrated lessons follow a SoC data key through PUF physics, noisy reconstruction, NeoPUF formation and readout, key wrapping, HUK derivation and system recovery.
A five-page classroom that explains AES as a repeated encryption workshop: fixed-size data blocks move through substitution, shifting, mixing, and key addition until the plaintext becomes hard to reverse without the key.
Build an iterative AES-128 core for a sensor block. Align data and round keys, define accepted transfers, hold ciphertext under backpressure, and debug against NIST intermediate values.
