Skip to main content

Evidence encryption and key custody

Assayra stores evidence in a versioned PLENC2 envelope. Each object receives a new random 256-bit data-encryption key (DEK) and AES-256-GCM nonce. The DEK is wrapped by a key-encryption key (KEK); plaintext evidence and plaintext DEKs are never written to object storage.

Authenticated context binds all four dimensions:

tenant ID + processing region + data class + evidence ID

Changing any dimension makes decryption fail. This prevents an object copied between tenants, regions, evidence records or data classes from becoming valid in its new location.

Data classes​

  • identity_core
  • document_evidence
  • biometric_evidence
  • screening_data
  • fraud_telemetry
  • decision_record
  • audit_security
  • model_evaluation

KEK providers​

ProviderUse
localDeveloper workstation only; production configuration rejects it
aws_kmsRegional AWS KMS key aliases with mandatory encryption context
remoteCustomer or Assayra HSM/key broker over authenticated HTTPS/mTLS topology

The default KMS alias template is alias/proofline/{region}/{tenantId}/{dataClass}. All three placeholders are required in production. Outer S3 SSE-KMS is defense in depth; it does not replace the application envelope.

Rotation and deletion​

Assayra can rewrap the DEK under a new KEK version without decrypting the evidence payload. Cryptographic erasure disables/destroys the applicable KEK only after legal hold, retention, backup and multi-party authorization checks. Legacy PLENC1 reads are a migration-only option and production configuration rejects enabling them.

For customer-controlled custody, implement the Evidence key broker contract and keep key administration separate from Assayra platform operators.

Remote key broker contract​

The complete deployment-neutral HTTP contract, error behavior, audit events, threat model and operational requirements are maintained in the repository as docs/EVIDENCE_KEY_BROKER_CONTRACT.md. The broker must not log plaintext DEKs, bearer credentials, evidence identifiers joined with applicant identity, or request bodies.