# Security architecture
Three trust boundaries. Zero-existence credential storage. Tamper-evident audit chains — technically accurate, verifiable by your security team.
## Architecture overview
DVE uses a three-layer model. Each layer has a distinct trust boundary and data scope.
### DVE Agent
Passphrase-derived key material, local encryption/decryption, agent identity keys, session unlock. Plaintext credentials **only while unlocked on the endpoint** — never sends passphrase or derived encryption keys to the server.
### Relay
Distributes license state and org policy blobs to agents; optional dedicated relay per org at higher tiers. Policy and license metadata only — **no credential content**.
### Backend
User/org management, encrypted envelope storage, append-only audit chains, SSO/SCIM/SIEM integrations. Encrypted credential envelopes, HMAC-indexed metadata, hash-linked chain blocks, user identity hashes.
The agent is required on every machine that accesses credentials. Without an unlocked agent session, credential APIs return unauthorized — credentials are not decrypted server-side for routine access.
## Key material lifecycle
1. **Passphrase (user-held):** Known only to the user. Never transmitted to PhantomKey infrastructure in any form.
2. **KDF (key derivation):** The agent derives encryption keys from the passphrase using HKDF and established KDF parameters. Derivation runs locally.
3. **Encryption key:** Used to encrypt credential payloads before they leave the endpoint. The key material remains on the device during normal operation.
4. **Encrypted envelope:** Ciphertext and associated metadata are sent to the backend for storage. The server cannot reverse the envelope without the user's keys.
5. **Server storage:** The backend stores opaque envelopes, identity HMACs, and append-only chain blocks — not decryption keys.
**Passphrase recovery:** PhantomKey cannot reset or recover a user's passphrase. Losing the passphrase means losing access to credentials encrypted under that key material. Organizations should designate a backup attestor during genesis setup.
## Audit chain
Multiple append-only hash chains per organization. Each block links to its predecessor — insert-only triggers prevent deletion or in-place modification.
### Permission chain
IAM events, license changes, support token operations, deployment policy.
### Credential chains
Credential envelopes and credential-related audit events.
### Audit chains
Access events, SIEM delivery records, import jobs, SSO/SCIM events.
What the chain proves: Recorded events existed in sequence and were not retroactively altered. It does not prove the semantic content of encrypted credential payloads — auditors rely on chain exports plus organizational process.
## Cryptographic primitives
| Primitive | Use in DVE |
|-----------|------------|
| **Ed25519** | Agent identity key pairs; signature verification for agent-authenticated API requests |
| **X25519** | Ephemeral key exchange (e.g., sealed-box delivery of org genesis material to agents) |
| **AES-256-GCM** | Symmetric encryption of credential payloads and sealed secrets |
| **HMAC-SHA256** | Credential metadata indexing (type, folder, tag lookups) without storing searchable plaintext |
| **HKDF** | Key derivation from passphrases and protocol-specific info strings |
| **SHA-256** | Audit chain block hashing (each block links to predecessor hash) |
Implementations use established libraries (`@phantomkey/core` on agent and backend). Specific protocol details are available under NDA for enterprise security review.
## Zero-existence model
What PhantomKey cannot do — by architecture, not policy.
### Decrypt under court order
We do not hold decryption keys. Ciphertext without keys is not recoverable by PhantomKey.
### Reset master passphrase
Passphrase never reaches our servers. Recovery requires organizational procedures (backup attestor, re-provisioning).
### See credential access without cooperation
Access events are on the customer's audit chain. Support tokens grant **administrative** access to org settings and chain exports — not credential decryption.
### Recover plaintext from backups
Database contains encrypted envelopes and chain blocks, not keys or plaintext secrets.
Zero existence means the server never holds plaintext credentials or the keys to decrypt them. PhantomKey still monitors relay health, agent check-ins, and org-level metrics via PK-Internal tooling.
## Penetration testing & compliance
### Penetration testing
DVE has undergone **internal penetration testing** during development. An **external penetration test by an independent firm is planned** — results will be published or shared under NDA when complete.
Do not represent DVE as having passed external penetration testing until that assessment is finished and reviewed.
### Certifications posture
DVE provides **compliance reporting tools** (evidence exports, access reports) to support **your** SOC 2 or ISO 27001 programs.
DVE is **not** marketed as SOC 2 Type II certified, HIPAA compliant, or FedRAMP authorized unless PhantomKey completes those programs and updates this page. Evaluate DVE against your own control frameworks using this architecture and available evidence exports.
## Responsible disclosure
If you discover a security vulnerability in DVE or PhantomKey infrastructure, email **security@phantomkey.pro** with a description, reproduction steps, and affected component (agent, backend, relay). We aim to acknowledge reports within two business days and will coordinate disclosure timelines with researchers acting in good faith.
Do not test against customer production orgs without authorization. Scope authorized testing to your own tenant or a designated test environment arranged with PhantomKey.
Executive FAQ — verifiable answers for security leaders →
