This service is under active development. Features may change without notice.
← Back to Documentation

Security & Encryption

Sirr is designed around a single principle: secrets must be unrecoverable without the correct key material. This page documents the encryption-at-rest architecture, key management strategy, and threat model.

Threat Model

Sirr's encryption protects against:

  • Database file exfiltration — An attacker obtains the database file from disk or a backup. Without the master key, all stored secrets are ciphertext.
  • Container compromise — An attacker gains shell access to the running container. Because the master key is loaded from a mounted file (not an environment variable), it is not visible via docker inspect or /proc.
  • Backup theft — Database backups are encrypted by nature. The master key is stored separately from the database, so stealing one without the other is useless.
  • Host-level compromise — Docker volumes, inspect output, and container memory are exposed. Client-side encryption (Tier 2) protects against this scenario — even a compromised host cannot decrypt user data.

Two-Tier Encryption Architecture

1

Server-Side Encryption (Mandatory)

All data stored in the embedded database is encrypted using AES-256-GCM. The master encryption key is derived at server startup and held only in memory.

  • Master key loaded from a mounted key file at /run/secrets/master.key or a host-mounted volume
  • Key file read once at startup — can be unmounted afterward
  • Server refuses to start without a valid key (fail-closed)
  • Master key is never passed as an environment variable, baked into the Docker image, or generated at build time
2

Client-Side Encryption (Optional, Recommended)

Users may encrypt secrets client-side before submitting them to the API. In this mode, the server stores an opaque encrypted blob. The server cannot decrypt the data — only the user holds the key.

Users who opt out of client-side encryption are still protected by Tier 1 server-side encryption. For high-sensitivity data, we recommend using both tiers for defense in depth.

Master Key Delivery

The master key must be provided to the Sirr server at startup. Approved methods, ranked by security:

MethodSecurityNotes
Mounted key fileHighKey file on host with 0400 permissions, mounted read-only into container.
Docker SecretsHighMounted at /run/secrets/, stored encrypted in Swarm's Raft log.
External KMSHighestServer fetches key from KMS at boot. Adds external dependency.
Environment variableNot recommendedVisible via docker inspect, /proc, and orchestrator logs. Local development only.

Key Rotation

Sirr supports zero-downtime key rotation. Each encrypted record stores a key version identifier, enabling graceful migration between keys.

  1. 1Generate a new master key.
  2. 2Start the server with both old and new keys (dual-key mode).
  3. 3Re-encrypt all records with the new key.
  4. 4Remove the old key and restart with only the new key.

Backup Strategy

Database backups are encrypted by nature — the data on disk is AES-256-GCM ciphertext. The master key file must be backed up separately and stored in a physically or logically separate location from the database backups.

Important: If the master key is lost and no backup exists, all data is irrecoverable by design. Consider implementing Shamir's Secret Sharing to split the master key backup across multiple trusted parties.

Compliance Alignment

Sirr's encryption-at-rest architecture implements technical controls that align with the following standards. Sirr has not undergone formal third-party certification audits for these frameworks.

  • GDPR Art. 32 — Addresses the encryption-at-rest requirement for protecting personal data with appropriate technical measures
  • SOC 2 (CC6.1 & CC6.7) — Implements logical access controls and encryption controls described in the SOC 2 Trust Services Criteria
  • ISO 27001 Annex A.10 — Implements cryptographic controls for key management, encryption at rest, and key rotation as described in the standard

Audit logging is available for all CRUD operations on secrets to support access trail requirements.

The bootstrap problem

Every secrets manager faces the same challenge: someone has to provide the first key. HashiCorp Vault uses an “unseal” ceremony. AWS KMS relies on hardware security modules. Sirr's approach — a mounted key file with strict host-level permissions — is a pragmatic and secure solution for a self-hosted service. The real security comes from ensuring the encrypted database and the master key never live in the same place.