Induced failure as an attack
Fault injection deliberately changes execution, data, timing, voltage, clock, temperature, light, electromagnetic conditions, memory, storage, or communication so a security mechanism produces an unsafe result. Tampering can open a device, probe buses, replace components, attach debug tools, modify firmware, or alter sensors and recovery paths.
The objective can be to skip a verification, change a branch, expose a key, reduce entropy, bypass retry limits, corrupt a measurement, or force a weaker recovery mode.
Model physical and logical access
Define possession time, equipment, proximity, repeatability, device cost, and whether the attacker can destroy samples. Include logical fault sources such as malformed peripheral input, memory disturbance, unsafe debug access, power loss during update, and compromised firmware.
Trace the critical state from input through verification, use, storage, output, and zeroization. Identify single decisions where one corrupted bit, instruction, counter, or result can grant authority.
Resistance, detection, and recovery
Use protected enclosures, sensors, shields, hardened storage, debug lockout, redundant checks, temporal and spatial diversity, integrity codes, safe-state transition, zeroization, and independent verification where the threat warrants them. Verify critical results before use and make failure explicit.
Protect update and recovery with the same or stronger authorization as normal boot. Record tamper evidence without relying on attacker-writable state. Replace or revoke a device whose key or state may have been exposed.
Failure and residual risk
Tamper evidence shows that something may have happened; it does not always prevent or identify the attack. A sensor can create denial of service. Redundant checks can share one fault. Debug features can reappear in manufacturing or recovery modes. Zeroization may not remove remanence, backups, derived keys, or external copies.
Tamper resistance raises attacker cost under a stated laboratory and physical model. It is not an absolute property and can age as tools and techniques improve.
Pomerium boundary
Pomerium software depends on its host, cryptographic libraries, key custody, and platform. It does not make commodity hosts tamper resistant or detect physical fault injection. Operators must decide whether platform custody, hardware modules, verified boot, key revocation, and replacement meet the threat. Pomerium can protect administrative routes but cannot protect a device after its lower-layer trust is lost.
Evaluation checklist
- Which voltage, clock, light, electromagnetic, temperature, memory, debug, bus, firmware, or update fault can reach a security decision?
- Can one corrupted check, counter, branch, measurement, random value, or recovery action grant authority?
- What prevents, detects, records, and recovers from the exact fault under the stated attacker equipment and time?
- Do redundant mechanisms share the same code, clock, power, sensor, key, or recovery failure?
- How are keys, identities, evidence, and relying-party trust revoked after suspected tampering?
