Security Whitepaper

The Identity-Driven Cryptosystem.

We do not claim "Magic". We utilize a verifiable Transient Envelope Encryption model. Keys are managed strictly by cryptographic hardware and post-quantum algorithms, ensuring Zero Persistence of your secrets.

Cryptographic Primitives

DATA ENCRYPTION (DEK)

AES-256-GCM

The secret payload is encrypted Client-Side using AES-256 in Galois/Counter Mode (GCM). This ensures authenticated encryption.

INTERNAL KMS ALGORITHM

CRYSTALS-Kyber

Our Internal KMS uses Kyber-1024 (NIST Post-Quantum standard) for key encapsulation, protecting DEKs against harvest-now-decrypt-later attacks.

ROOT OF TRUST

Cloud KMS (HSM)

The master seeds for our Internal KMS are protected by Cloud HSMs (AWS KMS / Google Cloud KMS) with FIPS 140-2 Level 3 validation.

CLIENT IDENTITY

ECC (X25519)

Every client (Agent, Web UI, CLI) generates an ephemeral Curve25519 key pair to perform Elliptic-Curve Diffie-Hellman (ECDH) key agreement. Private keys never leave the device.

ENTERPRISE CONTROL

BYOK Support

Enterprise customers can bring their own Customer Managed Key (CMK) to envelope our Internal KMS keys.

TRANSPORT SECURITY

TLS 1.3 Only

We strictly enforce TLS 1.3 with HSTS. All data is encrypted in transit, adding a secondary layer of protection.

Data Encryption Keys (DEKs) Isolation Policy

The Ennote Platform employs a Zero-Persistence architecture where Data Encryption Keys (DEKs) are encapsulated by a master Key Encryption Key (KEK). We call this Ephemeral Key Exposure.

During specific actions - specifically Access Requests or Master Key Rotation - the system performs an automated, transient re-wrapping operation. During this process, DEKs are briefly decapsulated in volatile memory (RAM) exclusively to be immediately re-wrapped using a derived session key for the target recipient.

Transient Processing

Plaintext keys exist only in volatile memory for the duration of the cryptographic operation (milliseconds).

No Persistence

At no point are plaintext DEKs written to disk, logs, databases, or persistent storage.

Audit Trail

Every re-wrapping event is logged in the immutable Audit Log as a privileged system operation.

The Lifecycle of a Secret

ENCRYPTION FLOW

1
Ephemeral Key Generation Client generates a random 256-bit DEK. This key exists only in RAM and is never written to disk.
2
Encapsulation (KEM) Data is encrypted with the DEK. The DEK is then encapsulated using the KMS Public Key (Kyber) into a secure Key Capsule.
3
Encrypted Storage We store the encrypted payload. The DEK is locked inside the Capsule, unreadable to the storage layer.

DECRYPTION FLOW

1
Identity Verification Client authenticates and sends its ephemeral X25519 Public Key to the KMS.
2
Atomic Re-Wrapping Inside the KMS enclave, the DEK is decapsulated in volatile RAM. The server performs ECDH with the Client's Public Key to derive a secure session key, wraps the DEK with it, and immediately flushes memory.
3
Client Decryption Client derives the identical shared session key using its private X25519 key, unwraps the DEK, and decrypts the secret data locally.

Infrastructure Hardening

Encryption at Rest
All databases and backups are encrypted at the storage level. Physical theft of disks yields no data.
Cloudflare WAF
We use Cloudflare WAF to block SQL injection, XSS, and volumetric attacks at the edge.
Strict Access Control
Engineers have no access to customer data keys. All administrative actions are logged and require MFA.

Compliance & Operations

Security isn't just code; it's people and processes. We adhere to rigorous operational standards.

SOC 2 ArchitectureBuilt strictly on SOC 2 Principles

Employee VettingBackground Checks & Hardware MFA

GDPR & CCPA ReadyPrivacy-First Architecture & DPAs

Vulnerability Disclosure

We offer Safe Harbor for good-faith security research. Please do not attempt DDoS or social engineering.

Report Issue security.txt

Security you don't have to build yourself.

Start managing secrets with hardware-backed encryption today.

Start for Free Read Docs