Server-Side Encryption of Objects

MinIO Server-Side Encryption (SSE) protects objects as part of write operations, allowing clients to take advantage of server processing power to secure objects at the storage layer (encryption-at-rest). SSE also provides key functionality to regulatory and compliance requirements around secure locking and erasure.

MinIO SSE uses the PGSTY KES and an external Key Management Service (KMS) for performing secured cryptographic operations at scale. MinIO also supports client-managed key management, where the application takes full responsibility for creating and managing encryption keys for use with MinIO SSE.

SILO implements the S3 encryption request interfaces described in AWS Server-Side Encryption and supports the following encryption strategies:

MinIO SSE requires enabling Network Encryption (TLS).

Secure Erasure and Locking

KES and SILO can cache key material. Sealing a key store or revoking access is not guaranteed to invalidate cached keys immediately; account for cache expiry and active processes when testing revocation.

SSE-KMS and SSE-S3 objects require the external key (EK) recorded in their metadata. Key availability affects access as follows:

• Sealing the key store or disabling access to an EK prevents decryption only once usable cached key material is also unavailable. Verify revocation across all SILO and KES instances; sealing the backend alone is not proof that reads have stopped.
• Permanently losing every usable copy of an EK, including cached copies and backups, makes objects that still depend on it unrecoverable.

Preserve the original keys until all required object versions have been migrated and their decryption verified.

For more information, see:

• SSE-KMS Secure Erasure and Locking
• SSE-S3 Secure Erasure and Locking
• SSE-C Secure Erasure and Locking

Cryptographic Construction

The following facts describe the construction shared by the SSE schemes. They are audit-level reference material: not necessary for configuring or using SSE, but useful when reviewing what is actually stored and in what form. The description originates from the encryption design notes inherited from upstream MinIO and retained by Silo.

• Object content is en/decrypted with an authenticated encryption scheme (AEAD) organized as a Secure Channel: the plaintext is split into fixed-size chunks, and each chunk is sealed separately with a unique key-nonce combination. The last chunk may be smaller and is treated specially to prevent truncation attacks.
• For multi-part objects, each part is sealed with its own key derived from the Object Encryption Key (OEK) and the part number through a PRF — so the OEK itself is never used directly as a part key.
• The PRF is HMAC-SHA-256. The pinned sio implementation prefers AES-256-GCM when hardware acceleration is available (including supported x86 and ARM64 CPUs), and ChaCha20-Poly1305 otherwise.
• Object encryption keys are 256 bits. The content-encryption format uses 96-bit nonces; the separate key-sealing metadata carries a 256-bit IV. These are different fields and must not be confused.
• The chunk size is 65536 bytes, which bounds a single encrypted object or part at 65536 * 2^32 = 256 TiB of plaintext at the cryptographic-format level. This is not the supported S3 object or multipart-part size limit.
• Object-key derivation and key-sealing IV generation use crypto/rand; sio also defaults to that cryptographically secure random source. Neither keys nor nonces should be replaced with merely unique counters.