Threat model

Designed around realistic attacker goals.

Phantom products are designed to protect sensitive data against a range of realistic threat scenarios.

This page outlines the primary threat assumptions considered during system design, along with clear limits on what the products are not meant to solve.

Data theft

Protection against copied vault data and stolen storage.

Credential theft

Protection against password-only attacks where possession is also required.

Integrity attacks

Detection of tampered containers and modified vault structures.

Scope limits

Clear acknowledgment of coercion, firmware, and host compromise risks.

Data Theft

Attackers may attempt to access encrypted vault data through device theft, storage compromise, unauthorised file copying, or system intrusion.

Phantom vaults are encrypted at rest and require the correct unlock conditions before access is possible.

Offline Vault Extraction

If an attacker gains access to encrypted vault containers without the required unlock components, vault contents remain encrypted and inaccessible.

Vault unlocking requires multiple components working together.

Credential Theft

Passwords alone are often insufficient protection.

Phantom systems can require the presence of a trusted USB device before unlocking sensitive environments. Without that device, password-based attacks cannot proceed.

Operational risks

Device loss and integrity attacks

If a device containing encrypted data is lost or stolen, vault contents remain protected by encryption and hardware-bound access requirements.

Recovery mechanisms are designed to restore access only to legitimate users.

Attackers may also attempt to modify encrypted containers or vault structures. Phantom systems verify vault integrity before allowing access.

Out of scope

What Phantom systems do not claim to solve

  • Physical coercion
  • Hardware implants
  • Compromised operating systems
  • Malicious firmware

Users operating in high-risk environments should assume the host system itself may be compromised.

Related pages

The threat model works best next to the architecture

Threat assumptions, design principles, and implementation detail should be read together.