With the addition of zTrustee to the Gazzang product portfolio, we have entered an even more interesting, ambitious, new space in modern Cloud computing -- Opaque Object Storage.
eCryptfs and zNcrypt provide "transparent" data encryption, in that when the encrypted filesystem is mounted, allowed users, applications and processes (possessing the appropriate keys) are allowed to seamlessly read and write data as regular files and directories to the mounted storage filesystem. No user, application, or process needs to know anything about encryption -- they simply read and write data "transparently" from and to files and directories. Input/output operations are trapped in the Linux filesystem layer, and eCryptfs handles encrypting and decrypting files as necessary. Assuming you have safeguarded your keys appropriately, an offline attacker with physical or remote access to the disk would not have access to mounted filesystem and instead only see the cryptographically protected data.
zTrustee was designed from the ground up to store and serve the keys necessary to make eCryptfs and zNcrypt work properly. But we implemented it in a manner in which we can store and serve keys, certificates, files, directories, and data of any type -- similar to some object storage systems. However, we added our considerable security expertise to our implementation, and use encryption yet again to our customer's advantage. Each of these objects stored in zTrustee are actually encrypted and signed with the public GPG keys of the client storing and/or retrieving the data. This means that even an administrative user with full root access on the zTrustee server will not have introspection into the contents of the data blobs stored as deposits on the zTrustee server. For this reason, we're calling these deposits "Opaque Objects", and noting that our zTrustee server provides "Opaque Object Storage".
Moreover, the fine-grained security policies that govern the release of these deposits further differentiate zTrustee from various other object storage products. Beyond the individual encryption of each zTrustee deposit (object), the policy by which an object is released can:
- limit the TTL (time to live)
- limit the number of times it can be retrieved (e.g. Mission Impossible message)
- be disabled (and later enabled)
- be purged entirely
- required 0 - N trustees authenticate and "vote" or "sign off" on the release
- be retrieved by an authenticated, signed/encrypted client, or
- be retrieved anonymously using a nonce URL
With this level of policy control, encryption, and cryptographic signature enforcement, we believe we've built something really quite interesting and useful for modern Cloud computing applications.
Stay tuned for some examples!
:-Dustin
