Open Stack

Bryan D. Payne wrote:
> How do you specify encryption algorithms / key length?
Currently we're proposing that any necessary encryption parameters will be specified by the Nova configuration file.  The system administrator may specify the desired encryption algorithm and key length, both of which will be used for all encrypted volumes.  If neither is specified in the configuration file, default settings (e.g., dm-crypt's default settings) will be used instead.

> How do you plan to handle IVs?
dm-crypt, which we use to transparently encrypt disks, provides support for a variety of ways to generate initialization vectors (IVs). AES modes of operation supporting robust IVs that are available through Linux include Encrypted Salt-Sector Initialization Vector (ESSIV) - Linux kernel version 2.6.10 - and Xor-encrypt-xor Tweaked-codebook ciphertext Stealing (XTS) - 2.6.24.  (Note the kernel release shown is the initial release for each of these.)  XTS is specifically designed for use in volume storage applications: it minimizes the storage impact of encryption (no block size increase) and addresses some data-dependent security vulnerabilities where the encrypted data could provide hints about how the data could be decrypted.  Liskov, Rivest, and Wagner (LRW) - 2.6.20 - is another possible mode, but it is not considered sufficiently strong (as called out by the developers of the IEEE P1619 standard.)

> Need a lot more details on the key management side.  In particular, what would you implement
> here if the BP (blueprint) is accepted?
The implementation would be rolled out in several phases.  The first release would essentially be a proof of concept of the encryption capabilities.  It would have a simple key management capability used for testing the proof-of-concept implementation.  Initial versions will not integrate fully with OpenStack's existing mechanisms for authentication, which may limit their security.  A later version is planned that would be based on some basic key management capabilities that would be compatible with the Key Management Interoperability Protocol (KMIP).  The plan is to offload the complexity of implementing key management by using a KMIP server that will talk with the virtualization host to provide a secure link that would deliver the proper keys when needed.  The KMIP server would need to rely on Keystone to provide the authorization credentials validating that the correct user is accessing the block storage device and that the correct key is being accessed.

> And how does the key management link back to Keystone... or does it?
In the initial version there would be little or no linkage to Keystone. In a subsequent version, PKI support through Keystone could be used to support authentication of the key management exchanges.

> Are you linking the keys to specific users?  Or is this just a system-level encryption that has no
> direct linkage to users?
Key management is handled transparently to the user, with keys being associated with only the volume they encrypt (or decrypt).  Keys will be retrieved automatically when a user mounts a volume to which they have access.  In a later version, key management capabilities (e.g. KMIP) may allow keys to be linked to specific users or projects/tenants.

> How does this get turned on / off?  Is this something that is configured at the time a cloud is
> setup?  Or is this something that a user can optionally add when launching an instance / creating
> a volume?  Or, something in between?
To specify that a volume should be encrypted, a new option is being introduced within both the dashboard and the Cinder CLI.  Given this option, the user can choose to encrypt the volume when it's created.  Note that there will be no option to change this setting after volume creation.  System administrators will specify the encryption algorithm, key length, etc. as part of the Nova configuration.

> How does this impact performance?  CPU overhead on node?  Network overhead?  Dedup
> overhead?  Is any of this tunable or is it all or nothing?
CPU overhead: We expect some minor CPU overhead during disk writes and reads when using this feature, but the overhead must still be characterized as part of the future testing.  The use of hardware encryption features such as Intel's AES-NI could minimize the overhead.
Tunability: The AES modes and key strength of the encryption will most likely be configurable, allowing a trade-off of strength and efficiency.
Network overhead: We expect minimal network overhead because most disk encryption schemes are designed to encrypt data within approximately the same amount of storage space required by the plaintext.
Data replication:  No added overhead. (See response to network overhead.)
Deduplication overhead: Storages engines that support data deduplication will be negatively affected.  For example, volumes with different keys will not have any blocks in common, and even blocks within the same volume will have different contents when encrypted.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130111/57d66cf0/attachment.html>