Open Stack

> Object Encryption: Extending Swift

This is the wrong scope for server based encryption. Swift and Cinder should use the same encryption solution.

>  Protection of data at rest: data encrypted and keys held in a separate location. Stealing the data disk still leaves the data protected.
> Keys will also be encrypted, using a Master-key. One thing to keep safe as opposed to multiple keys. A notion similar to a safe deposit box requiring a bank key and a customer key to open.

You actually want slight more than protection against the removable disks being stolen.
You also want to protect against the entire server being stolen.

A Master Key is crucial here. You want a key held on another server that will not be available from another network.
But you also want the Master Key to be specific to the server lockbox holding the master keys, so that you cannot intercept
the master key being sent to another server.

>  Key Manager will not maintain mapping between keys to objects.

Why is there a key manager at all?

Keys should be generated and stored within server specific lockboxes.
Access to the lockbox can only be authorized by a key for that lockbox that is stored within the local area network
but on a different machine.

Operationally, I cannot imagine a "cloud" solution that requires a human to re-enter a pass-phrase every time a
Server is relaunched. Anything the Openstack compute can manage is not providing enough encryption for data
at rest. Therefore migration of lockboxes needs to be very rare.

The role of a central "key manager" should be to authorize specific lockbox-to-lockbox transfer to tagged encryption keys,
rather than storing the keys itself. Central storage of keys just makes the entire system vulnerable to attacks on the 
key manager and the communications with the key manager.

> Authorization and access control support for key manager to protect from unauthorized use.

The real question is how we enable an entire set of machines to reboot without manual re-authorizing each one by hand.
They will never be re-authorized manually. Any attempt to do so will result in automated scripting of consoles, which
Will become the weak link in the entire system.

> Protection from denial of service, either from malicious activity or natural disasters by way of key replication (akin to object replication and recovery in Swift).

Actually this is more of an issue for cinder than it is for swift. Given even simple local replication of a lockbox, Swift will recover from the loss of
a lockbox the same way it would recover from loss of the entire server. If you can make the loss of a lockbox be relatively rare then it may be
preferable for Swift to *never* transfer keys. Never transferring keys will provide better security.

On the other hand, Cinder needs to copy snapshots and clone new volumes from those copied snapshots. That favors allowing keys to be
explicitly transferred from lockbox A to lockbox B. Since I think Cinder and Swift should use the same encryption solution this would obviously
be available for Swift as well.

> Use Cases

> Key Provider:

> * User (would rather not delegate trust, plans to use the same key for each object ..)

> * Auto-generation (either by the object storage system or key manager)

The only reason for a user to generate a key is if they are *not* sharing it with OpenStack.
That is called end-to-end encryption, and ultimately both need to be supported. What we
are currently describing is Service Provider encryption. 

Every time a key is communicated it is put at risk. Therefore the best keys are generated in
Server specific lockboxes, *never* exposed in plain text and only transferred to other lockboxes
under transaction specific encryption enabled by the key-manager.

>Key Scope:

>* Per object

>* Per project (within a domain)

>* Per domain

What benefit is there to per-object keys when the entire set of keys is held in the same lockbox?

Similarly, why have tenant specific keys when the Service Provider hold them?

The most natural granularity is based upon replication of still encrypted data.
For cinder that suggests a set of volumes/snapshots/clones. For Swift a Swift partition.

> Key-Storage:

> * End-User

> * Key Manager

End-user storage of keys is a separate project. But I think the OS vendors have to take the lead
on end-to-end encryption solutions. At the minimum it is a different OpenStack project.

A central key-manager is creating a single point of attack. Using multiple lockboxes is more secure, and simpler.