Security Model

This document describes the security model of VeilVault: the assumptions it makes, the guarantees it provides, and the boundaries it does not cross.

VeilVault is a security-first, offline-only password vault developed by CodeVeil.

This document is intentionally high-level. Certain implementation details are not disclosed publicly to reduce attack surface.

Core Security Goals

VeilVault is designed to:

• Protect stored secrets at rest if the device is lost or stolen
• Make offline attacks against the vault computationally expensive
• Prevent silent downgrade or partial unlock states
• Ensure tampering with vault data is detected
• Keep all sensitive material confined to the user’s device

VeilVault does not attempt to solve problems that require servers, accounts, or trust in third parties.

Why Offline-Only

VeilVault is designed to operate without any network dependency.

This decision is intentional and defines many of its security properties.

By being offline-only, VeilVault:

• Eliminates server-side attack surfaces
• Removes the need to trust remote infrastructure
• Avoids account-based identity and recovery systems
• Prevents silent data transmission or synchronization
• Ensures that vault security depends only on the device and the master password

These properties are not achievable in designs that rely on cloud services or remote synchronization. The tradeoff is deliberate.

VeilVault gives up cross-device convenience and recovery mechanisms in exchange for:

• reduced complexity
• fewer trust assumptions
• clearer security boundaries

This aligns with VeilVault’s security-first philosophy.

Trust Boundaries

Device-Local Operation

VeilVault operates entirely on the user’s device.

• No cloud storage
• No accounts
• No synchronization services
• No server-side processing

All cryptographic operations, key derivation, encryption, and decryption occur locally.

User-Controlled Access

Access to the vault is controlled by a master password chosen by the user.

• There is no password recovery mechanism
• There is no backdoor or escrowed key
• If the master password is lost, the vault cannot be accessed again

This is a deliberate design decision.

Cryptographic Foundations (High-Level)

VeilVault uses modern, well-established cryptographic primitives:

• A memory-hard key derivation function to derive encryption keys from the master password
• Authenticated encryption to provide both confidentiality and integrity of vault data

Cryptographic primitives are used conservatively and are not custom-designed. Specific parameters and internal constructions are intentionally not disclosed in public documentation.

Vault Encryption & Integrity

• All vault contents are encrypted as a whole
• Encryption provides confidentiality and tamper detection
• Any modification to encrypted vault data causes unlock to fail
• Incorrect passwords and corrupted vault files are handled as hard failures

There is no partial unlock, degraded mode, or “best-effort” decryption.

Key Lifecycle & Memory Handling

• The master password is handled as mutable character data, not immutable strings
• Derived encryption keys exist only in memory
• Keys are present only while the vault is unlocked
• Keys are cleared when:
  • the vault is locked
  • the app is backgrounded and auto-lock triggers
  • an emergency wipe is performed
  • the process terminates

Keys are never written to disk in plaintext form.

Session Isolation

VeilVault maintains explicit session states:

• Locked
• Unlocked (real vault)
• Decoy session

Each session state has strict boundaries.

Decoy Sessions

• Decoy unlocks never load real vault data
• Real encryption keys are never derived in decoy mode
• Decoy data is completely isolated from the real vault
• After a decoy unlock, biometric unlock is suppressed until a real unlock occurs

This prevents accidental exposure of real vault contents after a decoy interaction.

Biometric Unlock (Optional)

Biometric authentication is optional and explicitly user-enabled.

• Biometrics never replace the master password
• Enrollment requires prior master password authentication
• Biometric secrets are invalidated when:
  • the master password changes
  • the vault is wiped

Biometrics are a convenience feature, not a primary security boundary.

PanicHold & Emergency Actions

VeilVault includes user-triggered actions designed for high-risk situations.

• PanicHold features immediately obscure sensitive content or lock the vault
• PanicHold actions are non-destructive and reversible
• Emergency wipe permanently deletes local vault data
• Emergency wipes do not affect licensing or trial state
• After an emergency wipe, importing a previous vault is required to regain access

Emergency wipe is the only destructive action.

Failure Behavior

VeilVault is designed to fail safely.

• Wrong passwords do not leak information
• Corrupted vault data does not partially decrypt
• Authentication failures do not alter vault state
• Save operations use atomic replacement to avoid data loss

Silent failure modes are avoided.

Threat Assumptions

VeilVault assumes:

• The operating system is not compromised
• The device is not rooted
• The user does not voluntarily disclose their master password

VeilVault does not claim to protect against:

• Malware with root or kernel-level access
• Hardware-backed extraction by advanced adversaries
• Attacks performed while the vault is unlocked and visible
• Compromise of the device’s operating system

Non-Goals

VeilVault explicitly does not attempt to provide:

• Cross-device security guarantees
• Account-based recovery
• Remote wipe via servers
• Protection against all possible physical attacks

Security is defined by clear boundaries, not unrealistic promises.

Transparency Statement

VeilVault documents its security model to enable informed user decisions.

Some implementation details are intentionally withheld to reduce attack surface while preserving meaningful transparency. This balance is deliberate.

← Back to Docs