Air-gapped evidence transfer

1. The problem: cloud hops break isolation and trust

Air-gapped networks exist for a reason. Classified research, trading systems, industrial control, legal hold stores, and investigative evidence are kept off the internet so that exfiltration requires physical access. That isolation is the control.

Evidence still has to move. A forensic image collected on an isolated workstation needs to reach legal review. Audit logs from an OT enclave need to reach a SIEM in the enterprise zone. A device seized in the field needs to arrive at the lab intact. Every one of those moves crosses a trust boundary.

Most teams solve this with a workaround: copy to USB by hand, re-upload through a cloud drive, email a zip, or stage through a shared bucket that both sides can reach. Each of those is a cloud hop or an uncontrolled hand-off. The moment a file transits infrastructure you do not control — or is copied without a verifiable record — two questions become unanswerable:

• Was it altered in transit? Without a content hash taken at the source and bound to the transfer, a single flipped bit, a truncated copy, or a substituted file looks identical to the original.
• Who handled it and when? Without a signed chain of custody, you have a gap in the timeline. An auditor, opposing counsel, or regulator can reasonably ask whether the evidence you present is the evidence you collected.

The cost is not theoretical. Incomplete transfer logs trigger deeper audits. Evidence that cannot prove its own integrity gets excluded or discounted. Incident response slows because analysts will not act on logs they cannot trust. And the security team ends up rebuilding the gap-crossing workflow under pressure instead of designing it once.

The requirement is straightforward: evidence must cross air gaps without transiting a third-party cloud, and after the transfer any party must be able to prove the file is byte-for-byte what was sealed at the source.

2. What good looks like on your infrastructure

A minimal, auditable design has four properties. None of them requires sending data to a vendor or trusting a single operator.

1. Sealed at source. The bundle is hashed and signed inside the source enclave before it is ever written to removable media. The hash, file manifest, collector identity, and timestamp are captured in a manifest that is itself signed with a key held in that enclave.
2. Carried out-of-band. The sealed file travels on removable media, over a one-way diode, or on any physical transport — but never through a shared cloud relay. The transport is untrusted; the seal is what provides assurance.
3. Verified on ingest. The receiving enclave refuses to import until the signature and every content hash verify. A failed check is a blocked transfer, not a warning to click through.
4. Anchored independently. The hash receipt is stored separately from the bundle — in your own evidence store and, optionally, in an append-only log — so future verification does not depend on the same system that holds the file.

When those four properties hold, the air gap stays intact as a security boundary and the transfer itself becomes an auditable event. You can answer both critical questions — what was moved and who attests to it — from artifacts your own infrastructure produced.

Everything described here runs on your infrastructure. Lorca Labs software deploys into your enclaves as containers or sidecars, connects to your storage and your key management, and never routes evidence through a Lorca-operated cloud.

3. How the transfer works — seal, carry, verify

Think of the workflow in three stages. Each stage produces a receipt your auditor can inspect later without needing to trust any single person's account of events.

Seal

An operator or automated collector in the source enclave selects the evidence — files, disk images, log exports, or a case folder. Evidence Locker assembles them into a bundle, computes a cryptographic hash per file, and writes a manifest that lists every file, its hash, its size, the collector, and a timestamp. The manifest is signed with an enclave-held key. Hash Anchor records the bundle hash and manifest hash as a separate receipt. At this point the bundle is tamper-evident: any later change invalidates the hash.

Carry

Air-Gap Courier packages the signed bundle as a self-describing courier file — encrypted at rest and ready for out-of-band transport. For environments that need an additional binding between content and receipt, Stego Audit Carrier can embed a compact audit payload inside an ordinary carrier file so the proof travels inside the media rather than alongside it. The choice is policy-driven: use the standard courier for most moves, add the stego carrier when operating in locations where a separate manifest file would draw unwanted attention or when you want the content and its receipt cryptographically bound inside one object. In all cases no network connection between enclaves is required.

Verify

On the receiving enclave the operator imports the courier file. The import workflow decrypts the bundle, re-hashes every file, verifies the manifest signature, and compares the computed hashes to both the manifest and the anchored receipt. Only on a full match does the bundle enter the receiving Evidence Locker. The import event itself is logged with the verifier identity, result, and timestamp — creating a continuous chain from collection through transfer to ingestion. If verification fails, the bundle is quarantined and the failure is recorded.

Because each stage is receipted, an auditor months later can re-derive the proof: take the file from the receiving locker, hash it, and compare it to the hash anchored at seal time. No privileged recollection is needed.

4. The four components

Each product does one job. Together they cover the full crossing. You can adopt them incrementally.

Start with Courier + Locker + Anchor for most air-gap workflows. Add Stego Audit Carrier when your threat model calls for carrier-bound or discreet auditability. Every component runs on your infrastructure and integrates with your existing KMS, storage, and identity.

5. How to verify it — receipts, hashes, and policy gates

Verifiability is the buying criterion. Ask any vendor — including us — to show you these artifacts on your infrastructure, not in a slide deck.

• Per-file hashes. SHA-256 or equivalent for every file in the bundle, recorded in the manifest. Re-hash locally and compare; no proprietary tool should be required to reproduce the check.
• Signed manifest. The manifest is signed with a key whose provenance you control. Verification should fail if any file, name, or timestamp was altered.
• Anchored receipt. The bundle hash appears in an append-only log with a timestamp independent of the bundle store. Tampering with the bundle does not tamper with the anchor.
• Policy gate on import. The receiving enclave enforces a clear rule: no valid signature and matching hashes, no ingest. The gate decision is itself logged.
• Chain-of-custody timeline. Collection, seal, courier creation, physical hand-off, import, and any re-verification each produce a timestamped, attributable receipt you can export for auditors or counsel.

In a pilot, run this sequence end to end on your own media: seal a test folder, hash-anchor it, write the courier to USB, walk it to the receiving enclave, import, then independently re-hash on the receiving side and compare to the anchor. That single loop demonstrates more than any architecture diagram.

6. Buying checklist

Use this when comparing options or scoping a pilot. Every item should be demonstrable on your infrastructure.

• ☐ Sealing and hashing happen inside the source enclave — no data sent to a vendor for processing
• ☐ Courier file is self-contained, encrypted at rest, and importable with no network link between enclaves
• ☐ Manifest covers every file with hash, size, collector, and timestamp — and is signed
• ☐ Hash Anchor stores receipts separately from bundle storage on your infrastructure
• ☐ Receiving side enforces verify-before-ingest and logs the verdict
• ☐ Removable media, diode, and manual-carry workflows are all supported — no cloud relay required
• ☐ Keys are managed in your KMS/HSM — vendor has no access to signing keys
• ☐ Full chain export (JSON or equivalent) for auditors, with no proprietary viewer required
• ☐ Studio experiment available without signup — runs against an isolated demo host so evaluators can try before installing
• ☐ No certification or compliance claims — receipts speak for themselves; your auditors make the determination

7. Common anti-patterns to avoid

These patterns look expedient and quietly undermine the isolation you built the air gap to provide.

• The shared bucket in the middle. A cloud bucket reachable from both sides collapses the air gap into a VPN. Replace it with a courier file on removable media.
• Hash after copy. Hashing the file after it lands on the destination proves nothing about what left the source. Always hash before the file leaves the source enclave.
• One receipt, one store. Storing the hash alongside the file in the same system gives an attacker one place to alter both. Anchor hashes in a separate log.
• Warning instead of gate. A dashboard that flags mismatches but still allows ingest turns integrity into a suggestion. Enforce a hard gate.
• Proprietary verification. If only the vendor's tool can verify integrity, the proof is not independent. Require open, re-computable hashes and exportable receipts.

Frequently asked questions