Service Layer high complexity Shared Component backend
0
Dependencies
2
Dependents
1
Entities
0
Integrations

Description

Encrypts confidentiality declaration content before upload to Supabase Storage, consistent with the encrypted assignment handling requirements used elsewhere in the platform. Manages encryption keys scoped to the organization.

Feature: Driver Administration and Confidentiality Declarations

declaration-encryption-service

Summaries

Protecting the confidentiality of declaration documents is a legal and reputational imperative. This service ensures that sensitive assignment disclosures stored in cloud storage are encrypted at the application layer, meaning that even a storage breach would not expose readable documents. By managing encryption keys at the organization scope, it also supports multi-tenant data isolation requirements and positions the platform to meet enterprise security standards and data protection regulations. This directly reduces liability exposure and strengthens the trust proposition with enterprise clients who demand demonstrable data security controls.

High-complexity service requiring careful security architecture review before implementation begins. Key decisions include key management strategy (self-managed vs. KMS such as AWS KMS or Supabase Vault), encryption algorithm selection (AES-256-GCM recommended), and key rotation policy. Dependencies include the Supabase Storage upload pipeline and any compliance requirements specifying key custody.

Testing must cover encryption roundtrip correctness, integrity verification failure paths, and key rotation without data loss. Security review and penetration testing should be scheduled as explicit milestones. Estimate 6–10 days including security review, implementation, and thorough testing. Key rotation logic adds significant complexity.

Backend service with five interfaces: encryptDeclaration, decryptDeclaration, generateEncryptionKey, rotateKey, and verifyIntegrity. Use authenticated encryption (AES-256-GCM) so the ciphertext includes an authentication tag, satisfying the tamper-evidence requirement in verifyIntegrity. Org-scoped keys should be stored in a secrets manager or KMS, never in the application database. The encryptDeclaration method should return a structured blob containing the IV, ciphertext, and auth tag to ensure decryptDeclaration is stateless with respect to IV storage.

Key rotation must re-encrypt existing blobs atomically or implement a versioned key envelope pattern so old blobs remain decryptable during transition. Integrate with the declaration storage upload pipeline as a pre-upload transform step.

Responsibilities

  • Encrypt declaration content before storage upload
  • Decrypt declaration content for authorized reading
  • Manage org-scoped encryption keys
  • Ensure encrypted blobs are verifiably tamper-evident

Interfaces

encryptDeclaration(content, orgId)
decryptDeclaration(encryptedBlob, orgId)
generateEncryptionKey(orgId)
rotateKey(orgId)
verifyIntegrity(encryptedBlob)

Relationships

Dependents (2)

Components that depend on this component

Related Data Entities (1)

Data entities managed by this component

API Contract

View full contract →
REST /api/v1/declaration-encryption 8 endpoints
GET /api/v1/declaration-encryption
GET /api/v1/declaration-encryption/:org_id
POST /api/v1/declaration-encryption/encrypt
PUT /api/v1/declaration-encryption/:org_id
DELETE /api/v1/declaration-encryption/:org_id
POST /api/v1/declaration-encryption/decrypt
+2 more