Air-Gapped Threat Model
Air-gapped verification eliminates network-based trust dependencies. The verifier operates on an isolated machine with no network access, ensuring the verification result cannot be influenced by external systems.
What threats does air-gapped verification address?
Air-gapped verification provides strong guarantees against several attack classes that affect network-dependent verification systems.
Network Manipulation
Attackers cannot intercept, modify, or forge responses from verification APIs. There's no API to attack because verification is entirely local.
Service Availability
Verification cannot be blocked by DoS attacks on remote services. If you have the bundle and verifier, you can verify regardless of network conditions.
Vendor Lock-in
Verification doesn't require contacting the original issuer. If the vendor disappears, your bundles remain verifiable.
Coercion Attacks
An attacker cannot coerce a remote service to return false results. The math either checks out or it doesn't, locally.
What threats remain despite air-gapping?
Air-gapped verification has boundaries. It proves the bundle is internally consistent and properly signed. It cannot prove things about the real world.
- ✕Compromised signing key: If the issuer's private key was stolen, forged bundles will verify
- ✕Execution bypass: The bundle proves what governance claimed happened; it cannot prove the workload wasn't run ungoverned separately
- ✕Clock manipulation: If the original system clock was wrong and no TSA was used, timestamps may be inaccurate
- ✕Selective disclosure: The bundle may not contain all runs—only the ones the producer chose to bundle
What is the trust boundary?
The trust boundary defines what you must trust for verification results to be meaningful.
Must Trust
- ✓Verifier implementation is correct
- ✓Issuer's public key is authentic
- ✓Cryptographic primitives (Ed25519, SHA-256)
- ✓Your verification machine isn't compromised
Don't Need to Trust
- —Bundle producer's server
- —Network infrastructure
- —Third-party APIs
- —Internet connectivity
How do we handle key distribution?
For air-gapped verification to work, you need the issuer's public key. This creates a bootstrap problem: how do you get the key without network access?
- ■Pre-installed keys: Enterprise deployments may pre-install trusted issuer keys on verification machines
- ■Key in bundle: Bundle includes issuer public key; verifier checks against known key_id
- ■Out-of-band transfer: Key fingerprint verified via phone call, physical media, or separate channel
Frequently asked questions
Does air-gapped mean completely offline?
Yes, for verification. The verifier must run entirely offline with no network calls. Bundle creation may use network for TSA tokens, but verification doesn't need them—it just validates the tokens that are already in the bundle.
What if TSA tokens need online validation?
TSA tokens are validated by checking their signatures against the TSA's public key, which can be pre-installed. The token itself contains all information needed for verification.
Is this really necessary for most use cases?
For high-assurance scenarios (defense, critical infrastructure, legal disputes), yes. For routine audits, the capability exists even if you verify on a networked machine. The point is you could verify offline if you needed to.