Skip to Content
EnterpriseSecurityKey Management

Key Management

Encryption key management in enterprise deployments is entirely under customer control. This page explains the key hierarchy, operational procedures, and GDPR implications.

Key Hierarchy

Pepper Key (256-bit, in your Azure Key Vault) │ HKDF-Expand(pepper, applicationId + dataSubjectExternalId) Per-Subject Salt (256-bit, stored in your PostgreSQL data_subjects table) │ AES-256-GCM(salt, session_payload) Encrypted Session Blob (in your PostgreSQL or Azure Blob Storage)

Pepper Key: A single master secret per tenant. Stored in your Azure Key Vault. Never transmitted to Veriproof.

Per-Subject Salt: Derived via HKDF from the pepper key and a stable data subject identifier. Stored in your PostgreSQL data_subjects table. Not directly a key — it is the derivation input. Destroying the salt makes the derived key unrecoverable.

Session Encryption: Each entire session payload is encrypted with AES-256-GCM using the derived per-subject key. The GCM authentication tag provides integrity verification.

Pepper Key Operations

Viewing Pepper Key Metadata

az keyvault secret show \ --vault-name your-kv-name \ --name "veriproof-pepper" \ --query "{name:name, created:attributes.created, version:id}"

Rotating the Pepper Key

Pepper key rotation is a destructive operation that requires re-encrypting all session data. Contact support@veriproof.app before rotating the pepper key. Rotation must be performed as a coordinated operation to avoid data loss.

The rotation process:

  1. Veriproof generates a new pepper key in coordination with you
  2. A migration worker re-derives per-subject salts using the new pepper
  3. Session payloads are re-encrypted with the new derived keys
  4. The old pepper key is retired (but kept in Key Vault as a previous version for 90 days)
  5. After 90 days, the old version is deleted

Emergency Pepper Key Destruction

If you need to destroy all session data immediately (e.g. in response to a breach), destroying the pepper key makes all encrypted session data permanently unrecoverable:

# Disable (reversible for 90 days if soft delete is enabled) az keyvault secret set-attributes \ --vault-name your-kv-name \ --name "veriproof-pepper" \ --enabled false # Permanent deletion (irreversible if purge protection is disabled) az keyvault secret delete \ --vault-name your-kv-name \ --name "veriproof-pepper"

If purge protection is enabled (recommended), the key enters a 90-day recovery window after deletion. To permanently purge it immediately, you must first remove purge protection — but this cannot be done once it is enabled. Plan your Key Vault policies accordingly.

GDPR Erasure (Key Destruction)

Erasing a data subject under GDPR in enterprise mode:

  1. The portal’s GDPR dispatcher identifies all per-subject salt entries for the data subject
  2. Each salt is deleted from the data_subjects table in your PostgreSQL
  3. Without the salt, the derived encryption key cannot be reconstructed
  4. All session payloads for the data subject become permanently unreadable

An erasure certificate is generated and cryptographically signed by your portal. The certificate records the data subject ID, the timestamp, and confirms that the salt destruction was completed.

For the full GDPR erasure workflow, see GDPR Erasure.

Key Vault Security Recommendations

RecommendationReason
Enable soft delete (90-day window)Allows recovery from accidental deletion within 90 days
Enable purge protectionPrevents permanent deletion during the soft-delete window
Enable diagnostic loggingAudit all access and operations on the Key Vault
Use Managed Identity for accessAvoids storing Key Vault credentials in application settings
Grant minimum permissionsPortal: get. Ingest API: get, set. No delete for app identities.
Monitor for anomalous access patternsSet up Microsoft Defender for Key Vault
Last updated on