Encryption, key management, and storage

DEEP DIVE

Understand the mechanism and its impact.

An algorithm name alone does not explain which risks are reduced. Use address storage and delivery examples to explore keys and data flows.

Separate data and encryption keys

An envelope-encryption example encrypts personal data with a DEK and protects the DEK with a KEK. Use authenticated encryption and reject tampered data before use.

DEK / KEK

Database access must not also grant access to KMS-managed keys.

nonce / authentication tag

Avoid nonce reuse with AES-GCM and reject failed authentication tags.

Additional authenticated data (AAD)

Bind tenant_id, record_id, and schema_version to detect ciphertext substitution.

Key rotation

Distinguish rewrapping DEKs during KEK rotation from re-encrypting data during DEK rotation.

CLOUD KEY MANAGEMENT

Cloud key services for key custody.

The address Vault uses Azure Key Vault to manage its KEK. Separate permission to use the key protecting data encryption keys (DEKs) from database access.

Azure

Use Azure Key Vault; choose Azure Managed HSM where a dedicated HSM environment is required.

AWS

The current DEV product is a delivery-address API on Azure. Email sending, identity images, OCR and AWS KMS integration are not included. General architecture examples and other-cloud designs are separate from the functions available with this product. Confirm storage location, operating responsibilities and additional integrations during onboarding.

OneNym's role

Combine cloud key management with workflow-level rules governing who can retrieve which data, for what purpose, and until when.

Store ciphertext and wrapped DEKs, not persistent plaintext DEKs. Compromised key-use permissions can enable decryption, so separate data, key, and administrative access.

Minimize decryption paths

Separate database connectivity from decryption authority. Only authorized operations decrypt required fields, keeping unnecessary personal data out of responses, logs, and exceptions.

Field-level responses

Return only permitted fields, such as the address needed for delivery.

Administrative access

Separate routine and emergency operations with strong authentication, time limits, and audit records.

Search design

Searching encrypted fields requires a separate design. Search hashes also carry matching and guessing risks.

Deletion, backups, and recovery

Define retention by purpose. Track deletion across source data, replicas, backups, and partners. Reapply deletion records after restoration to prevent deleted data returning.

Deletion completion

Record logical deletion, physical deletion, and key destruction separately.

Key destruction

Consider dedicated keys only when every recoverable copy can be removed, including backups. Destroying shared keys affects other records too.

Recovery targets

Define RPO and RTO and test recovery in practice.

Audit logs

Record actor, operation, target reference, time, and outcome. Do not log personal data or raw tokens.

DATA / INTEGRATION EXAMPLE

Data and integration example

These samples explain the design. Field names and values are illustrative, not an executable API reference.

{
  "operation": "Vault record metadata example",
  "record": {
    "tenant_id": "tenant_a",
    "record_id": "rec_example_01",
    "schema_version": 1,
    "ciphertext": "<encrypted bytes>",
    "wrapped_dek": "<wrapped key>",
    "kek_version": "key-version-2",
    "retention_until": "<agreed retention date>",
    "status": "active"
  }
}

This example explains storage layout. Follow the cryptographic library's format for nonces and tags. Encryption alone cannot prevent abuse of legitimate decryption permissions.

Related technical designs

Integration designed for your workflows.

Map retained data, partners, and required actions to identify ways to reduce exposure.