# Every security boundary is a decision Over the years I have analyzed devices built with secure boot, encrypted storage, secure elements, and carefully designed access controls. Some resisted every attempt to compromise them. Others surrendered their secrets in minutes. The difference was rarely the cryptography. It was almost always an assumption the designers did not realize they were making. This article explains the pattern beneath those failures, and why it matters whether you build systems, assess them, or defend them. It is the idea everything else on this site rests on, so it comes first, before any technique. ## Security is a decision Strip away the implementation and every security feature reduces to a decision the device makes: - *Is this firmware image authentic?* - *Is the debug lock engaged?* - *Is this the correct PIN?* - *Is this key allowed to leave the secure element?* The boundary is only ever as strong as that decision. A vault with a flawless lock is still open if the guard can be convinced to say "yes" when the answer is "no." In a computer, the guard is a comparison, a branch, a flag. The decision *is* the security. ## Decisions rest on assumptions, and assumptions are physical Every decision quietly assumes something is true. "Is the lock engaged?" assumes the lock value read from memory is the real value. "Is this firmware authentic?" assumes the signature check actually runs to completion. "Is this key secret?" assumes nobody can see it while it is being used. Here is the crack. In a physical device, every one of those assumptions is realized as something physical: a voltage on a power rail, a value moving across a bus, a comparison executing inside a processor, a key sitting in memory while the chip computes with it. The assumption is not an abstraction floating above the hardware. It is a measurable, disturbable, physical event happening at a specific place and a specific moment. And anything physical can be engaged by someone with physical access. ## Three ways an assumption can fail Physical attacks generally take three forms. They map onto the three things security is supposed to protect: - **Observe.** Learn something that was assumed to be hidden. This breaks *confidentiality*. You do not break in; you watch. A chip leaks tiny, secret-dependent variations in its power draw and electromagnetic field as it computes, and those variations can be read. - **Influence.** Steer a decision toward a chosen wrong outcome. This breaks *integrity*. You do not guess the PIN; you nudge the device, at the right instant, into deciding the wrong PIN was right. - **Disrupt.** Interfere with how the device is supposed to behave, even without a chosen result. This breaks *availability and safety*. A well-timed disturbance can make a step be skipped, a value be corrupted, or a safety check be missed. Side-channel analysis, fault injection, and glitching are not separate exotic arts. They are these three moves. The disciplined way to ask *which* assumption is weakest, and *how* it could be observed, influenced, or disrupted, is a short sequence of questions this project calls **The Assumption Lens**. The rest of the site is that lens applied to real targets. ## Two short illustrations **Observe (a secret that was watched, not read).** A device performs an operation with a secret key. It never exports the key; the key never crosses a wire in the clear. But the chip's power consumption rises and falls in patterns that depend on the key's bits, and an attacker measuring that power can reconstruct the key from the outside. The assumption that failed was not "the key is stored safely." It was the unspoken assumption that *using* the key does not reveal it. (See [[kocher-differential-power-analysis]], the work that established this.) **Influence or disrupt (a check that was nudged, not solved).** A locked device checks, early in boot, whether its readout protection or secure boot is in force, and refuses to cooperate if so. An attacker drops the supply voltage for a few billionths of a second at the precise moment that check runs. The check comes out wrong; the device proceeds as if unlocked, and its firmware can be read out. Nothing was decrypted and no password was found. The *decision* was disturbed in physical reality. (See [[raelize-esp32-crowbar-glitch]] for a documented case end to end.) In neither example was the cryptography broken or a secret read out of storage. In both, an assumption beneath a decision was engaged where it actually lives: in the physics. This is not just our framing. A 2025 systematization of fault injection, written to introduce the field to newcomers, defines the entire discipline as breaking "the assumption that hardware will guarantee proper execution of software", the same claim, reached independently. (See [[liu-sok-beginner-friendly-introduction-fault-injection]].) ## Why this matters whether you attack or defend This is a way of *understanding* systems, not just attacking them. The same lens that tells an attacker where a device is weakest tells a defender exactly what to harden, and tells a product team what to ask of a chip before they trust it. The same reasoning applies during design: every time an engineer says "the device will only do X if Y is true," they have implicitly defined a security assumption that deserves examination. The recurring lesson is blunt: **fault the decision, not the data.** Defenders often spend enormous effort protecting secrets while spending far less effort protecting the decisions that guard those secrets. The weakest point is rarely the key or the algorithm; it is the single decision that gates everything, and the assumption that decision takes for granted. So the defenses that actually raise an attacker's cost are the ones that protect the *decision*: make it redundant so one disturbance no longer wins, randomize its timing so the attacker cannot aim, detect the disturbance itself, and never let one check gate everything. A defense that does not change the attacker's cost is theater. ## One lens, many fields These three questions, what decision is being made, what it assumes, and whether that assumption can be observed, influenced, or disrupted, are not specific to glitching or even to hardware. They are a common language for how systems fail. Side-channel analysis is observing an assumption; fault injection and glitching are influencing or disrupting one; reverse engineering is discovering them; evaluating a secure element is validating them. The same habit applies to a medical device, where the task is identifying the assumption whose failure is dangerous, or to an AI decision system, where the hidden assumptions live in the data and the model rather than the silicon. The technique changes with the field. The questions do not. ## Where to go next - **See the lens on real hardware.** Two of the cases behind this article are documented end to end: [[kocher-differential-power-analysis]], where a secret key is recovered from power alone (observe), and [[raelize-esp32-crowbar-glitch]], where a secure-boot decision is disturbed with a voltage glitch (influence or disrupt). For the field's own framing of the same idea, see [[liu-sok-beginner-friendly-introduction-fault-injection]]. - **How this site is made**, plus the attribution, licensing, and defensive scope every entry is written under: [[About]]. More is on the way, published in the open as each piece is ready: a fully cited defender's whitepaper, and a hands-on voltage-glitching walkthrough that applies this lens end to end on hardware you own. > [!tip] > Read anything deeper on this site by asking the same questions: what decision is being made, what > does it assume, and could that assumption be observed, influenced, or disrupted? That habit, more > than any single attack, is what transfers to a device you have never seen.