A signing key with export disabled
WebCrypto keyEach new vault has its own non-extractable P-256 signing key in IndexedDB. WebCrypto blocks private-key export. Same-origin scripts can still use the key; this is not hardware isolation.
ECHO ID · SECURITY
Protect your identity. Know the limits.
Vault Lock protects the owner key for your Echo ID card after setup is verified. Before setup, its legacy owner entry is unencrypted. Claim Proofs and other Echo features use separate keys with separate protections. We describe the scope here so you can make an informed choice.
How your identity is protected
Verified encrypted owner storage
passphrase vaultSetup encrypts the owner secret with AES-256-GCM and PBKDF2 at 310,000 iterations. It reads back and decrypts the saved record before replacing the original plaintext owner entry. Your existing owner ID is preserved.
Check a key without revealing a secret
key-control evidenceThe device-key check signs a challenge without decrypting the owner secret. It proves that the stored key works. It does not prove fresh human approval, grant permission, or establish someone's identity.
Optional passkey unlock
WebAuthn PRFCompatible browsers can seal the secret using a passkey-derived key. Authenticator verification is required and may use a PIN. Passkeys may sync; this flow does not certify hardware backing or biological presence.
The threat model, in the open
Two ways to lock an Echo ID, each with its own honest ledger. A green column is what the layer genuinely stops. A red column is what it cannot — stated plainly, because a security page that only lists wins is marketing.
passphrase vault
defends against
- After verified setup, the owner entry contains encrypted recovery data and public metadata, without its original plaintext secret.
- WebCrypto refuses private-key export for the separate vault signing key.
- A device-key check verifies a challenge signature without revealing the owner secret. It does not authorize an action.
- PBKDF2 with 310,000 iterations adds cost to offline passphrase guesses; use a strong passphrase.
cannot defend
- Before setup completes, the legacy owner entry is unencrypted. Close older Echo ID tabs before migrating.
- Same-origin scripts can use the stored signing key even while the secret is locked. Unlocked secrets are present in page memory.
- A compromised browser, malicious extension, altered delivered code, weak passphrase, or copies already made of the secret.
- Other Echo keys have separate custody. Claim Proofs currently uses an exportable spine key in localStorage.
passkey / biometric
defends against
- On a compatible browser, WebAuthn PRF unlocks encrypted owner data after required authenticator verification; a PIN may satisfy it.
- The passkey unlock flow does not require typing the vault passphrase.
- WebAuthn credentials are scoped to the relying party. Setup verifies that the saved encrypted record can unlock.
cannot defend
- Once unlocked, the secret is in this page's memory. Compromised code can read it.
- Passkeys may sync between devices. This flow does not attest hardware isolation or biometric identity.
- Unsupported PRF, loss of every unlock and backup, or a compromised browser or device.
Recovery stays with you
We provide no operator reset for this local owner secret. Keep your unlock method and an owner-key backup you control. Browser storage can be cleared or lost. A device-key check does not back up its signing key.
The browser, device and delivered application code remain part of the trust boundary. These protections do not establish immunity from compromise or an independent security audit.
Verify, don't trust
Verify It YourselfEvery claim, and the exact way to falsify it →Transparency PledgeWhy total transparency is the only kind that counts →Your Echo IDGenerate one and engage Vault Lock →Boundary of OwnershipWhat can never be sold, and why →
Choose what to protect, retain your recovery options, and verify the specific boundary before relying on it.