[openstack-dev] [nova][cinder][barbican] Why is Cinder creating symmetric keys in Barbican for use with encrypted volumes?

Farr, Kaitlin M. Kaitlin.Farr at jhuapl.edu
Wed May 31 20:06:01 UTC 2017

Lee, a few thoughts on your previous email.  Many of the details I think you
already know, but I'm clarifying for posterity's sake:

    > However the only supported disk encryption formats on the front-end at
    > present are plain (dm-crypt) and LUKS, neither of which use the supplied
    > key to directly encrypt or decrypt data. Plain derives a fixed length
    > master key from the provided key / passphrase and LUKS uses PBKDF2 to
    > derive a key from the key / passphrase that unlocks a separate master
    > key.

    This is true.  When we retrieve the key from Barbican, we don't use the key bytes
themselves to encrypt the volume. We format the key as a string and use it as a
passphrase.  You can see this for both the LUKS encryptor [2] and the cryptsetup
encryptor [3].  We pass in a "--key-file=-" parameter (which indicates the "keyfile"
should be read from stdin) and then pass in the formatted key.  But according to
the documentation, "keyfile" is a misnomer.  I think it would be clearer if dm-crypt
renamed it to something like "passwordfile" because it's still used by dm-crypt and
luks as a passphrase [4].

    > I also can't find any evidence of these keys being used directly on the
    > backend for any direct encryption of volumes within c-vol. Happy to be
    > corrected here if there are out-of-tree drivers etc that do this.

    There are two options for control_location for the volume encryption type:
'front-end' (nova) and 'back-end' (cinder) [5].  'front-end' is the default, and I
know where the code logic is that sets up the encryptors for the front-end,
now in os-brick [1].  But I cannot find any logic that handles the case for 'back-end'.
I would think the 'back-end' logic would be found in Cinder, but I do not see it.
I am under the impression that it was just a placeholder for future functionality.

    > IMHO for now we are better off storing a secret passphrase in Barbican
    > for use with these encrypted volumes, would there be any objections to
    > this? Are there actual plans to use a symmetric key stored in Barbican
    > to directly encrypt and decrypt volumes?

    It sounds like you're thinking that using a key manager object with the type
"passphrase" is closer to how the encryptors are using the bytes than using the
"symmetric key" type, but if you switch over to using passphrases,
where are you going to generate the random bytes?  Would you prefer the
user to input their own passphrase?  The benefit of continuing to use symmetric
keys as "passphrases" is that the key manager can randomly generate the bytes.
Key generation is a standard feature of key managers, but password generation
Is not.

On a side note, I thought the latest QEMU encryption feature was supposed to
have support for passing in key material directly to the encryptors?  Perhaps
this is not true and I am misremembering.

    Hopefully that helps,


    1. https://github.com/openstack/os-brick/blob/6cf9b1cd689f70a2c50c0fa83a9a9f7c502712a1/os_brick/encryptors/__init__.py#L62
    2. https://github.com/openstack/os-brick/blob/6cf9b1cd689f70a2c50c0fa83a9a9f7c502712a1/os_brick/encryptors/luks.py#L63-L87
    3. https://github.com/openstack/os-brick/blob/6cf9b1cd689f70a2c50c0fa83a9a9f7c502712a1/os_brick/encryptors/cryptsetup.py#L104-L129
    4. https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption#Keyfiles
    5. https://docs.openstack.org/admin-guide/dashboard-manage-volumes

More information about the OpenStack-dev mailing list