欢迎来到即将发布的 MinIO 文档版本! 此页面上的内容正在积极开发中 可能随时更改。 如果找不到您要找的内容,请查看我们的 历史文档。 感谢您的耐心等待。 我们期待您贡献自己强大的力量,帮助更多的中国技术开发者![翻译]

Encryption and Key Management

MinIO supports key security features around object-level and network-level encryption:

Server-Side Object Encryption

MinIO supports Server-Side Object Encryption (SSE) of objects, where MinIO uses a secret key to encrypt and store objects on disk (encryption at-rest). MinIO SSE requires Transport Layer Security (TLS).

MinIO supports the following SSE encryption types:

SSE-S3

The MinIO server en/decrypts an object using a secret key managed by an external Key Management System (KMS). MinIO SSE-S3 requires using MinIO KES for supporting scalable distributed cryptographic operations using the KMS.

MinIO supports both automatic and client-driven encryption of objects before storing the data to disk. MinIO automatically decrypts objects using the required keys on read for any client with read permission for the bucket and object.

MinIO can only decrypt an object if it can retrieve the Customer Master Key (CMK) used to encrypt an object from the configured KES service.

MinIO SSE-S3 provides similar functionality to Amazon Server-Side Encryption with Amazon-Managed Keys. MinIO SSE-S3 supports multiple KMS providers in addition to AWS KMS, including Thales CipherTrust (formerly Gemalto KeySecure) and Hashicorp KeyVault.

SSE-C

The MinIO server en/decrypts an object using a secret encryption key provided by the application as part of the HTTP request. SSE-C requires the application to manage key creation and storage. MinIO never stores encryption keys specified as part of SSE-C.

MinIO supports client-driven encryption of objects before storing the data to disk. MinIO automatically decrypts objects using a client-specified key on read. Only clients which specify the correct encryption key can successfully retrieve the protected object. Clients must additionally have read permission for the bucket and object.

SSE-C encrypted objects are not compatible with MinIO bucket replication. For MinIO deployments configured for SSE-S3 automatic encryption, writing an object with SSE-C encryption headers prevents SSE-S3 encryption of that object.

MinIO SSE-C provides similar functionality to Amazon Server-Side Encryption with Customer Keys.

Encryption Process Overview

MinIO uses three distinct keys when performing server-side encryption or decryption:

Key

Description

External Key (EK)

An external secret key used to generate and encrypt additional encryption keys.

  • For SSE-C, the EK is the client-provided encryption key. MinIO never stores this key to disk and requires the application to perform all key management operations.

  • For SSE-S3, the EK is generated by MinIO KES using a Customer Master Key (CMK) stored in the configured external KMS. KES returns a plain-text representation of the EK for performing cryptographic operations, and a CMK-encrypted representation of the EK for storage alongside the object metadata.

    See the KES Wiki for more information on configuring KES.

MinIO cannot decrypt objects encrypted using SSE-C or SSE-S3 without the associated EK or CMK respectively. Disabling or deleting these keys results in associated encrypted objects being rendered unreadable. See Secure Erasure and Locking for more information.

Key Encryption Key (KEK)

A 256-bit unique random secret key deterministically generated by MinIO at the time of each cryptographic operation. MinIO never stores the KEK on disk.

The key-derivation algorithm uses a pseudo-random function (PRF) that takes the EK, a randomly generated initialization vector, and a context consisting of values like the bucket and object name.

Object Encryption Key (OEK)

A 256-bit unique random secret key used to encrypt or decrypt an object. MinIO generates an OEK when first encrypting an object. MinIO encrypts the OEK using the KEK and stores the encrypted OEK as metadata with the object.

MinIO decrypts the OEK into RAM as part of cryptographic operations. MinIO never stores the OEK on disk in an unecrypted format.

All secret keys generated by MinIO are 256-bits long. MinIO uses a cryptographically secure pseudo-random generator (CSPRNG) as part of key generation. In the context of SSE, the MinIO CSPRNG only enforces that the generated values are unique rather than truly random.

The following diagrams describe the key hierarchy built by MinIO for each object. Each tab corresponds to the specific hierarchy for SSE-S3 and SSE-C respectively:

Content Encryption

The MinIO server uses an authenticated encryption scheme (AEAD) to en/decrypt and authenticate the object content. The AEAD is combined with some state to build a Secure Channel. A Secure Channel is a cryptographic construction that ensures confidentiality and integrity of the processed data. In particular, the Secure Channel splits the plaintext content into fixed size chunks and en/decrypts each chunk separately using an unique key-nonce combination.

The following text diagram illustrates Secure Channel Construction of an encrypted object:

The Secure Channel splits the object content into chunks of a fixed size of 65536 bytes. The last chunk may be smaller to avoid adding additional overhead and is treated specially to prevent truncation attacks. The nonce value is 96 bits long and generated randomly per object / multi-part part. The Secure Channel supports plaintexts up to 65536 * 2^32 = 256 TiB.

For S3 multi-part operations, each object part is en/decrypted with the Secure Channel Construction scheme shown above. For each part, MinIO generates a secret key derived from the Object Encryption Key (OEK) and the part number using a pseudo-random function (PRF), such that key = PRF(OEK, part_id).

Cryptographic Primitives

The MinIO server uses the following cryptographic primitive implementations:

Pseudo-Random Functions (PRF)

HMAC-SHA-256

AEAD

ChaCha20Poly-1305 by default.

AES-256-GCM for x86-64 CPUs with the AES-NI extension.

Secure Erasure and Locking

For SSE-S3 encrypted objects, MinIO requires access to both the KMS and the Customer Master Key (CMK) used to encrypt the object(s). You can leverage this functionality to erase or lock some or all encrypted objects by disabling access to the EK or CMK used for SSE-S3 encryption. For example:

  • Seal the KMS such that it cannot be accessed by MinIO server anymore. This locks all SSE-S3 encrypted objects protected by any CMK stored on the KMS. The encrypted objects remain unreadable as long as the KMS remains sealed.

  • Seal/Unmount one/some CMK(s). This locks all SSE-S3 encrypted objects protected by the CMK(s). The encrypted objects remain unreadable as long as the CMK(s) remains sealed.

  • Delete one/some CMK(s). This renders all SSE-S3 encrypted objects protected by the CMK(s) as permanently unreadable. This is equivalent to securely erasing all SSE-S3 encrypted objects protected by the CMK(s). The combination of deleting CMK(s) and deleting the data may fulfill regulatory requirements around secure deletion of data.

    Deleting a master key is typically irreversible. Exercise extreme caution before intentionally deleting a master key.

For SSE-C encrypted objects, MinIO requires access to the encryption key used to secure those objects. You can render an encrypted object as temporarily or permanently unreadable by disabling or deleting the secret key used to encrypt that object.

Transport Layer Security (TLS)

MinIO supports Transport Layer Security (TLS) encryption of incoming and outgoing traffic.

TLS is the successor to Secure Socket Layer (SSL) encryption. SSL is fully deprecated as of June 30th, 2018. MinIO uses only supported (non-deprecated) TLS protocols (TLS 1.2 and later).

See Transport Layer Security (TLS) for more complete instructions on configuring MinIO for TLS.