Zenko’s encryption scheme is architected around bucket-level encryption. This reflects a design bias toward wholesale operations such as bucket- and site-level replication and away from object-level operations.
Slightly different from AWS SSE, Zenko bucket encryption (except for bucket
creation) is transparent to the application. Buckets are created with a special
x-amz-scal-server-side-encryption header (value:
specifies that the bucket’s objects shall be encrypted, with no need thereafter
to change any Object PUT or GET calls in the application, because encryption and
decryption are automatic (encrypt on PUT, decrypt on GET). AWS SSE is
comparatively intrusive, requiring special headers on all Object Create calls,
including Object Put, Object Copy, Object Post, and Multi-Part Upload requests.
Zenko’s Key Management Service (KMS) integration for bucket encryption is similar to that of SSE-C. Scality requires that customers provide the KMS, which is responsible for generating encryption keys on PUT calls and for retrieving the same encryption key on GET calls. This architecture ensures that Zenko does not store encryption keys. Currently, Zenko is integrated with one KMS solution, Gemalto SafeNet KeySecure.
Zenko uses standard OpenSSL, 256-bit encryption libraries to perform the payload encryption/decryption. This also supports the Intel AES-NI CPU acceleration library, making encrypted performance nearly as fast as non-encrypted performance.
As of version 1.2.1, Zenko is modified to accept object encryption headers. Object-level encryption is not supported; however, Zenko no longer throws an error when it encounters object-level encryption headers, provided bucket-level encryption is enabled and the correct protocol is used. Objects and buckets may or may not be encrypted, but under no circumstances does Zenko allow an object with an unsupported cryptographic protocol pass as safely encrypted, either to an unencrypted bucket, or using an unsupported encryption protocol at the bucket or object level.
If Zenko encounters an object-level encryption header and bucket-level
encryption is not set for the buckets transferring or replicating the object, S3
Connector responds with a
400: InvalidArgument error.
Likewise, if Zenko encounters an encryption header
a value other than
AES256, it returns