Key Management

How does envelope encryption work?

Areev uses envelope encryption: each memory has a single randomly-generated 256-bit Data Encryption Key (DEK), wrapped by the platform’s managed key service via Transit-style key wrapping. The wrapping key never encrypts grain data directly — it only wraps the memory DEK, limiting the blast radius of any single key compromise. Per-user keys are not stored; they are HKDF-derived in-process from the memory DEK plus a user identifier at runtime.

A single wrapped-DEK record is kept per memory. Areev records the DEK creation timestamp, and key canaries — encrypted known plaintext — verify that the DEK can still decrypt correctly, catching corruption before it causes data loss.

The autonomous memory engine retrieves and unwraps a memory’s DEK on access, derives the needed per-user key in process, and zeroizes both on drop, ensuring key material does not persist in process memory after use.

import requests

# Key management is transparent — store a grain and the DEK is created automatically
resp = requests.post("https://acme.areev.ai/api/memories/default/add", json={
    "subject": "john", "relation": "likes", "object": "coffee"
})

Where do the wrapping keys live?

The platform’s managed key service holds the wrapping keys. They are never extractable, never written to application disk in clear, and never leave the key service — Areev calls the service to wrap and unwrap each memory DEK. The wrapped-DEK records are stored alongside the rest of your data in your cell’s encrypted storage, and the underlying storage is further protected by transparent at-rest encryption.

You do not configure key material as a cloud customer — the managed key service provisions, rotates, and audits the wrapping keys on your behalf. The control plane records every key-handling event in the hash-chained audit trail, so you can verify rotation history and DEK lifecycle from the Console under Settings → Security → Key history.

LayerWhere it livesRotation
Wrapping keyPlatform’s managed key service (never on app disk)Managed-key-service operation
Per-memory DEKOne wrapped-DEK record per memory, wrapped by the managed key serviceOn wrapping-key rotation, or on erasure
Per-user keyDerived in-process via HKDF; never storedN/A — re-derived on demand

How does key rotation work?

Key rotation is an operation on the platform’s managed key service: it rolls the wrapping key and re-wraps each memory DEK under the new wrapping key. The DEKs themselves (and therefore grain data) do not change — only the wrapping changes, making rotation an O(memories) operation rather than O(grains). Per-user keys are unaffected because they are derived in-process from the unchanged memory DEK.

Because the managed key service performs wrap/unwrap atomically, there is no application-side multi-phase master-key re-wrap to coordinate, and no plaintext key material is ever exposed during rotation. Areev follows NIST SP 800-57 guidance for rotation cadence.

How are signing keys managed?

Areev signs grains with COSE Sign1 (RFC 9052) using EdDSA over Ed25519. Signing keys are managed separately from encryption keys, with private seeds and public verifying keys stored independently. The DID is embedded in the COSE header as the key ID; content addressing always uses SHA-256 of the inner .mg blob, never of the COSE envelope.

You can register a signing DID for your organization through the Console under Settings → Security → Signing. Once registered, Areev can auto-sign all grains in a memory without per-request key specification.