Encryption & Key Management Policy¶


Owner	Joshua Curci - CTO
Applies to	All systems, infrastructure, and personnel handling Trove platform data
Last reviewed	April 2026
Review cycle	Annually

Purpose¶

This policy defines how Trove implements encryption to protect data at rest and in transit, and how cryptographic keys are managed throughout their lifecycle. It ensures that sensitive data belonging to brands, recipients, and the platform itself is protected against unauthorised access and disclosure.

Scope¶

This policy applies to:

All data stored within Trove's platform infrastructure (AWS)
All data transmitted between Trove's systems and between Trove and third parties
All cryptographic keys and secrets used by the platform
All engineers and contractors with access to Trove's systems

Encryption at Rest¶

Database¶

The Trove platform uses MySQL 8 hosted on AWS. Database storage encryption is managed at the infrastructure level through DuploCloud and AWS, ensuring data is encrypted at rest by default.

Sensitive field-level values stored in the database are encrypted before storage using AWS KMS where appropriate. This includes:

Vendor SMTP passwords (used for custom transactional email sending)
Third-party OAuth tokens (Shopify, Xero)
Other sensitive credentials stored against vendor or integration records

Passwords for user accounts and storefront access controls are hashed using bcrypt before storage. Plaintext passwords are never stored.

File Storage¶

All files stored in AWS S3 are encrypted at rest. Server-side encryption is applied to all objects using AWS-managed keys (SSE-S3) or AWS KMS-managed keys (SSE-KMS) depending on the sensitivity of the content.

This covers: - Product images and brand assets - Order export files - Any other files uploaded to or generated by the platform

Application Secrets¶

Application secrets, API keys, and credentials used by the platform are stored as environment variables managed through DuploCloud. These are not stored in source code or version control.

Particularly sensitive values are encrypted at the application level using AWS KMS before being stored, providing an additional layer of protection beyond environment variable storage.

Encryption in Transit¶

External Traffic¶

All traffic between clients (browsers, mobile) and the Trove API is encrypted using TLS 1.2 or higher. HTTP connections are redirected to HTTPS. Unencrypted connections are not accepted.

Internal Traffic¶

All traffic between Trove's internal services (API, Worker, database, AWS services) is encrypted in transit. AWS services communicate over encrypted channels by default within the AWS infrastructure.

Third-Party Integrations¶

All communication with third-party services (Auth0, Stripe, Shopify, Xero, Sentry, etc.) uses HTTPS with TLS. Webhook payloads received from third parties are validated using the signature or verification mechanism provided by the service before processing.

Email¶

Transactional emails are sent via vendor-configured SMTP connections or the system default SMTP. SMTP connections support TLS, SSL, or NONE encryption modes - vendors configuring custom SMTP are encouraged to use TLS or SSL. The system default SMTP uses TLS.

AWS Key Management Service (KMS)¶

AWS KMS is the primary key management solution for the Trove platform.

Key Usage¶

KMS keys are used for:

Encrypting sensitive values stored in the database (SMTP passwords, OAuth tokens)
Server-side encryption of sensitive S3 objects where SSE-KMS is applied
Any other application-level encryption requirements

Key Management Principles¶

KMS keys are managed within AWS and accessed via IAM roles with least-privilege permissions
Application code does not have direct access to raw key material - all encryption and decryption operations are performed via the KMS API
Key usage is logged via AWS CloudTrail, providing an audit trail of all cryptographic operations
Key rotation is managed in accordance with AWS KMS defaults and reviewed annually

Access Control¶

Access to KMS keys is restricted via IAM policies to only the services and roles that require it. No individual user account should have direct KMS key access unless explicitly required for a specific operational task and approved by the CTO.

JWT Tokens¶

Authentication tokens are issued by Auth0 as signed JWTs. Token signing keys are managed by Auth0 and rotated in accordance with Auth0's key management practices.

The Trove API validates JWT signatures on every authenticated request. Tokens are short-lived to limit the impact of token compromise. Refresh token handling follows Auth0's recommended security practices.

Five token types are in use:

Token Type	Purpose
Vendor	Brand user sessions in the Admin Portal
Recipient	Gift recipient access to storefronts
Admin	Internal platform administration
Shopify OAuth	Shopify integration authorisation flow
Xero OAuth	Xero integration authorisation flow

Secrets Management¶

All application secrets follow these rules:

Secrets are never hardcoded in source code or committed to version control
Secrets are stored as environment variables managed through DuploCloud
Sensitive values are additionally encrypted with AWS KMS before storage in the database
Local development uses separate credentials from production - production secrets are never used locally
If a secret is suspected to have been compromised, it must be rotated immediately and the CTO notified

See the Secure Development Policy for additional requirements around secrets in the development workflow.

Key and Secret Lifecycle¶

Stage	Requirement
Creation	Keys and secrets are generated using cryptographically secure methods. Weak or default credentials are not permitted.
Storage	Stored in DuploCloud environment configuration or encrypted via AWS KMS. Never in source code or plain text files.
Rotation	AWS KMS keys are rotated per AWS defaults. Application secrets and third-party API keys are rotated at least annually, or immediately on suspected compromise.
Revocation	Compromised or unused credentials are revoked immediately. Access is removed as part of the offboarding process.
Destruction	Secrets removed from active use are deleted from all storage locations. KMS key deletion follows AWS KMS key deletion policies including the mandatory waiting period.

Prohibited Practices¶

The following are explicitly prohibited:

Storing plaintext passwords, secrets, or private keys in source code, configuration files, or documentation
Committing .env files or credentials to the git repository
Using weak or deprecated cryptographic algorithms (MD5, SHA-1 for security purposes, DES, RC4)
Transmitting sensitive data over unencrypted connections
Using self-signed certificates in production
Sharing encryption keys or secrets between team members via unencrypted channels (email, Slack, etc.)

Non-Compliance¶

Violations of this policy may result in suspension of system access pending review, and in serious cases, termination of employment or contract. Where a violation contributes to a data breach, it may also trigger the Breach Response Plan.