From the Canyon Edge -- :-Dustin

Wednesday, June 27, 2012

Opaque Object Storage

Gazzang has built an interesting business around Transparent Data Encryption, building on top of eCryptfs, adding some mandatory access controls and policy management in a product we call zNcrypt.

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!


Wednesday, June 20, 2012

Introducing Gazzang zTrustee!

I'm out at the GigaOM Structure conference in sunny San Francisco this week, where Gazzang has launched its newest product -- Gazzang zTrustee!  My colleagues and I have dedicated the last 6 months to the design, architecture, development and testing of this new product, and I'm thrilled to finally be able to speak freely about it.

Gazzang's original product, zNcrypt is a transparent data encryption solution -- a GPLv2 encrypted filesystem built on top of eCryptfs, adding mandatory access controls and a dynamic policy structure.  zNcrypt enables enterprise users to secure data in the cloud, meet compliance regulations, and sleep well at night, ensuring that all information is encrypted before written to the underlying storage.

As of today, Gazzang's newest product, zTrustee is an opaque object storage system, ultimately providing a flexible, secure key management solution for data encryption.  Any encryption system, at some point, requires access to keys, and those keys should never be stored on the same system as the encrypted data.  While zTrustee was initially designed to store keys, it can actually be used to put and get opaque data objects of any type or size.

Planet Ubuntu readers might recognize a few small-scale ancestors of zTrustee in other projects that I've authored and talked about here in the past...  The encrypted pbputs and pbget commands now found in the pastebinit package are similar, in principle, to zTrustee's secure put and get commands.  But rather than backing uploads with a pastebin server, we have implemented a powerful, robust, enterprise-ready web service with extensive, flexible policies, redundancy, and fault-tolerance.  The zEscrow utility and service are also similar in some other ways to zTrustee, except that zEscrow is intended to share keys with a backup service, while zTrustee blindly and securely stores opaque objects, releasing only to authenticated, allowed clients per policy.

Planet Ubuntu readers may be pleased to hear that our zTrustee servers are currently running Ubuntu 12.04 LTS server, replicated across multiple cloud providers.  The RESTful web service is built on top of a suite of high quality open source projects, including: apache2, python wsgi, postgresql, sqlalchemy, postfix, sks, squid, gnupg, and openssl (among others).

The zTrustee client is a lightweight python utility, leveraging libcurl, openssl, and gnupg to send and receive encrypted, signed JSON blobs, to and from one or more zTrustee servers.  The client utilizes the zTrustee Python library, which does the hard work, encrypting, decrypting, and processing the messages to and from the zTrustee server.  You'll soon be able to interface with zTrustee using either the command line interface, or the Python library directly in your Python scripts.

We've turned our current focus onto Android, while developing a Java interface to zTrustee, so that Java programs and Android applications will soon be able to interface with zTrustee, putting and getting certificates and key material and thereby enabling mobile encryption solutions.  Looking a little further out down our road map, we'll also use these Java extensions to support zTrustee clients on iOS, Mac, and Windows.

While I'm big fan and proponent of eCryptfs and zNcrypt, I plainly recognize that there are lots of other ways to encrypt data -- dmcrypt, TrueCrypt, FileVault, BitLocker, HekaFS, among many others.  From one perspective, encrypting and decrypting data is now the easy part.  Where to store keys, especially in public/private/hybrid cloud environments, is the really hard part.  Many people and organizations have punted on that problem.  Well as it happens, I like hard problems, and Gazzang likes market opportunities and for that, we're both proud to promote zTrustee as a new solution in this space.

This post is intended as a very basic or brief introduction to the concept, and I'll follow this with a series of examples and tutorials as to how you might use the zTrustee client, library, and mobile interfaces.


Friday, June 15, 2012

ecryptfs-utils-97 released

It's been a little while, apologies for that, but we've just released ecryptfs-utils-97!

I'm really excited about this eCryptfs release, as it includes contributions from 9 different individuals employed by 4 different open source companies.  A big thanks to all contributors!
  1. Kees Cook (Google)
  2. Andreas Raster
  3. George Wilson (IBM)
  4. Sergio Pena (Gazzang)
  5. Colin King (Canonical)
  6. Colin Watson (Canonical)
  7. Serge Hallyn (Canonical)
  8. Dustin Kirkland (Gazzang)
  9. Tyler Hicks (Canonical)
The full changelog is below.  As usual, please file any new issues in Launchpad.


ecryptfs-utils (97) quantal; urgency=low

  [ Kees Cook ]
  * src/pam_ecryptfs/pam_ecryptfs.c: LP: #938326
    - exit, rather than return to prevent duplicate processes

  [ Andreas Raster ]
  * src/desktop/ecryptfs-find:
    - $mounts was quoted once too often

  [ George Wilson ]
  * src/key_mod/ecryptfs_key_mod_openssl.c,
    src/key_mod/ecryptfs_key_mod_tspi.c: LP: #937331
    - IBM would like to grant a license exception for key modules that
      require linking to OpenSSL. The change should make the modules
      shippable by Linux distributions

  [ Dustin Kirkland ]
  * debian/copyright:
    - note the GPLv2 SSL exception granted by IBM for the key modules
  * debian/control, debian/copyright, doc/manpage/ecryptfs.7,
    doc/manpage/ecryptfs-add-passphrase.1, doc/manpage/ecryptfsd.8,
    doc/manpage/ecryptfs-generate-tpm-key.1, doc/manpage/ecryptfs-
    insert-wrapped-passphrase-into-keyring.1, doc/manpage/ecryptfs-
    manager.8, doc/manpage/ecryptfs-mount-private.1,
    doc/manpage/ecryptfs-recover-private.1, doc/manpage/ecryptfs-rewrap-
    passphrase.1, doc/manpage/ecryptfs-rewrite-file.1,
    doc/manpage/ecryptfs-setup-private.1, doc/manpage/ecryptfs-setup-
    swap.1, doc/manpage/ecryptfs-stat.1, doc/manpage/ecryptfs-umount-
    private.1, doc/manpage/ecryptfs-unwrap-passphrase.1,
    doc/manpage/mount.ecryptfs.8, doc/manpage/mount.ecryptfs_private.1,
    doc/manpage/pam_ecryptfs.8, doc/manpage/umount.ecryptfs.8,
    doc/manpage/umount.ecryptfs_private.1, README,
    - use the new website where appropriate
  * debian/control:
    - update to suggest zescrow-client

  [ Sergio Peña ]
  * src/libecryptfs/cipher_list.c: LP: #922821
    - add the new name of the blowfish cipher (linux >= 3.2)
  * src/include/ecryptfs.h, src/libecryptfs/main.c,
    src/utils/mount.ecryptfs.c: LP: #917509
    - use execl() to mount ecryptfs
    - this allows us to support any arbitrary mount options in

  [ Tyler Hicks ]
  * doc/manpage/ecryptfs.7:
    - Remove the note saying that the passphrase and openssl key modules are
      available by default. That's true upstream but not always true in distro
  * tests/
    - Make upper and lower mount point arguments optional by automatically
      creating directories in /tmp by default.
    - Make it possible to run only userspace tests without having to specify
      unused mount information
    - Accept a comma-separated list of lower filesystems to test on and loop
      through all kernel tests for each lower filesystem
    - Accept a comma-separated list of tests to run
  * tests/lib/
    - Unset $ETL_DISK just before etl_remove_disk() successfully returns
  * tests/userspace/
    - Also build 'make check' tests when building with --enable-tests
  * include/ecryptfs.h, libecryptfs/,
    libecryptfs/cipher_list.c, libecryptfs/module_mgr.c,
    utils/io.h: LP: #994813
    - remove overly complicated implementation to detect what ciphers
      are supported by the currently running kernel's crypto api
    - prompt for the entire supported cipher list, if the user selects a
      cipher that their kernel doesn't support, the mount will fail
      and the kernel will write an error message to the syslog
  * src/libecryptfs/module_mgr.c:
    - Use correct blowfish block size when displaying supported ciphers to
      the user
  * tests/kernel/, tests/kernel/,
    - Add simple test case for incorrect handling of umask and default POSIX
      ACL masks
  * tests/kernel/, tests/kernel/lp-994247/test.c,
    tests/kernel/, tests/kernel/tests.rc:
    - Add test case for incorrect handling of open /dev/ecryptfs file
      descriptors that are passed or inherited by other processes

  [ Colin King ]
  * tests/lib/
    - etl_lumount() should use DST rather than SRC dir so it can run on Lucid
    - use file system appropriate mkfs force flag
    - cater for correct ext2 default mount flags
  * tests/kernel/, tests/kernel/lp-509180/test.c:
    - test for trailing garbage at end of files
  * tests/kernel/, tests/kernel/lp-524919/test.c:
    - test case for checking lstat/readlink size
  * tests/kernel/, tests/kernel/lp-870326/test.c:
    - test case for open(), mmap(), close(), modify mmap'd region
  * tests/kernel/
    - test case for lsattr
  * tests/kernel/
    - test case for stat modify time
  * tests/kernel/
    - test case for clearing ECRYPTFS_NEW_FILE flag during truncate
  * tests/lib/, tests/kernel/,
    tests/kernel/ (LP: #1007159):
    - Add test library function for estimating available space in lower fs
    - Use new library function in tests that need to create large files

  [ Colin Watson ]
  * src/utils/ecryptfs-setup-swap: Skip /dev/zram* swap devices
    LP: #979350

  [ Serge Hallyn ]
  * src/utils/mount.ecryptfs_private.c:
    - EoL fixes

 -- Dustin Kirkland Fri, 15 Jun 2012 09:32:48 -0500

Monday, June 4, 2012

zEscrow Lightning Talk Live Demo

The Friday lightning talks from the Ubuntu Developer Summit (Quantal in Oakland) are now up! You can now watch my 5 minute introduction and live demo of zEscrow here.