Threat model
What the model is trying to protect
Section titled “What the model is trying to protect”NAILS is built around a dual-environment workflow where a visible system remains plausible on its own and a separate hidden environment can be activated when needed.
Cases where NAILS is most useful
Section titled “Cases where NAILS is most useful”Casual inspection
Section titled “Casual inspection”This is where the design is strongest.
- the visible system can remain ordinary and believable
- hidden session state is not meant to live on the visible system after proper deactivation
Disk focused forensic review after proper deactivation
Section titled “Disk focused forensic review after proper deactivation”This is also an important target for the design.
- the documented evaluation reported clean results for the standard deactivate path in the cited test scenarios
- the hidden storage backend still matters a great deal
Cases where NAILS is weaker or out of scope
Section titled “Cases where NAILS is weaker or out of scope”Running or recently running systems
Section titled “Running or recently running systems”If an adversary can capture memory, the problem changes. NAILS does not claim to solve that.
Hardware or firmware compromise
Section titled “Hardware or firmware compromise”The project runs above those layers, so compromise there can see through the operating system.
Coercive adversaries
Section titled “Coercive adversaries”Technical design cannot remove legal or physical pressure.
Operational conclusion
Section titled “Operational conclusion”Use NAILS when your workflow actually matches this model. If your primary need is amnesic boot media, broad VM isolation, or stronger resistance to active physical compromise, start with a different tool.