Security model
Trust boundaries should be inspectable.
This page states what Silentnox stores, what it protects against, and where the model ends. Treat it as an integration guide, not a substitute for your own threat analysis.
Cryptography
- HKDF derives a per-request data-encryption key from shards K and S.
- AES-256-GCM provides confidentiality and integrity.
- Project keys are generated once and must remain server-side.
Silentnox retains
- A protected platform shard
- Project and record metadata
- Operational and audit events
Silentnox does not retain
- Your project key
- Encrypted field blobs
- Field plaintext after a request
Threats the split-custody model addresses
It reduces the impact of a database-only compromise, a Silentnox storage-only compromise, and accidental plaintext persistence in your application database. An attacker needs access to both custodians or to the live runtime path where both inputs meet.
Explicit limitations
- A compromised application runtime may observe the project key, blob, and returned plaintext.
- Incorrect logging in your application can leak request inputs or responses.
- Client-side use exposes the project key and is unsupported.
- Availability depends on access to both key shards and the Silentnox service.
- Key rotation requires re-encrypting values that must use the new key.
Integration requirements
- Keep the project key in an environment variable or managed secrets service.
- Call encryption and decryption endpoints from trusted backend code only.
- Never log plaintext, project keys, or complete request payloads.
- Restrict outbound network access and rotate credentials after suspected compromise.
- Review audit logs and disable a project key when activity is unexpected.