Working software and prototypes
Encrypted storage, on-device credential entry and FIDO are part of the current development system. The developer actively uses a V2 board for passkeys and recovery codes.
SECURITY DESIGN / IN DEVELOPMENT
Trust starts with
understanding the design.
How Vault protects files and passkeys, and the thinking behind its hardware and software.
THE COMPUTER YOU CONNECT TO
Your computer needn’t
hold every secret.
A computer is a complicated thing to trust: its operating system, applications, and the firmware beneath them. Concerns about privileged subsystems such as Intel Management Engine and AMD’s platform security processor are part of why Vault exists. Their opacity and the trust they require matter to this project.
Vault puts credential entry, key handling and encryption on a dedicated device with its own screen and controls. Your unlock credential stays on Vault, where it is used to recover the keys for your data.
HOW YOUR FILES ARE PROTECTED
One layer. Then another.
When you save a file, Vault encrypts its data through your chosen stack before writing it to storage. Here, AES adds the first layer and Camellia encrypts the result.
Encryption happens inside Vault. Reading a file reverses the layers.
A little extra caution, by choice
Choose one to four layers from AES-256, Camellia-256 and SM4-128, with a separate derived key for each layer. Different cipher families offer diversity against a weakness in one selected algorithm. Extra layers trade speed for that additional protection; integrity checks also help detect changes to encrypted data.
UNLOCKING THE MASTER KEY
Your password unlocks the key.
The layers protecting your files use keys derived from a random vault master key (VMK). That master key is also protected: it is split into shares, each wrapped with one of your selected cipher families.
ENTERED ON VAULTYour passwordor chosen unlock credential
HELD BY VAULTDevice secretsbound to this enrollment
DERIVED INSIDE VAULTUnwrapping keysa separate key for each share
Your correct password and the device-held secrets are both required to derive the keys that unwrap these shares. In this two-share example, the recovered shares are then combined using XOR to reconstruct the master key.
Without the correct password, the shares cannot be unwrapped. All shares are needed to recover the master key.
GUESSING AND DEVICE LOSS
Attempts count.
Even across restarts.
The implementation reserves an unlock attempt in persistent device state before checking the credential. A copied or replaced SD card cannot by itself reset that counter. Missing or corrupt authority state denies access rather than creating a fresh attempt allowance.
New setups offer destruction at the attempt limit. This revokes and burns the enrollment token needed to recover the master key. This removes the device’s ability to unlock the files and passkeys protected by that token.
Read the key and enrollment design ↗FIDO2 AUTHENTICATION
Approve a request.
Keep the private key.
A service holds the public key for a credential. Vault uses the private key to sign an authentication challenge, rather than sending that private key to the service.
The FIDO store is separate from the files exposed as a USB drive, but its protection depends on the vault master key. Unlocking makes FIDO available; registration and sign-in require approval on the device. The screen shows the site identifier supplied by the host, while the browser checks the website origin.
Read the FIDO implementation notes ↗USING VAULT
Files, access
and recovery.
Once you unlock storage, the connected computer can read its files. Use a computer you trust for accessing documents, and keep a separate backup or another way into your accounts.
Storage and FIDO use the same credential and attempt allowance. Reaching the destruction limit removes access to both, by destroying the enrollment token needed to unlock them.
The technical documentation covers the current protection scope, including storage rollback and firmware access. Development and hardware validation are tracked in the checklist below.
EVIDENCE AND OPEN WORK
Built in the open.
Explore the source, follow the design decisions and see the testing as development progresses. The hardware documentation explains the components we use and which parts of their designs are open.
Latest enrollment changes
The token-only enrollment change passed 30 standard host tests and 44 full host/FIDO tests under memory and undefined-behaviour sanitizers.
Production protections
Hardware interruption testing, production access restrictions, trusted boot and update policy, debug lockdown, and final security review remain release work.
Validation record ↗ · Production checklist ↗ · Source and documentation ↗
DIRECTIONS WE ARE EXPLORING
More control over
what you expose.
We’re exploring tools to unlock a selected part of the filesystem, and a duress credential that opens a separate partition.
Integrated NAND storage with a controller is another possible hardware direction. Current boards use SD storage for practical engineering and cost reasons.