On Mon, Dec 14, 2015 at 2:02 PM, Martin Millnert <martin@xxxxxxxxxxx> wrote: > On Mon, 2015-12-14 at 12:28 -0800, Gregory Farnum wrote: >> On Mon, Dec 14, 2015 at 5:17 AM, Radoslaw Zarzynski > <snip> >> > In typical case ciphertext data transferred from OSD to OSD can be >> > used without change. This is when both OSDs have the same crypto key >> > version for given placement group. In rare cases when crypto keys are >> > different (key change or transition period) receiving OSD will recrypt >> > with local key versions. >> >> I don't understand this part at all. Do you plan to read and rewrite >> the entire PG whenever you change the "key version"? How often do you >> plan to change these keys? What is even the point of changing them, >> since anybody who can control an OSD can grab the entire current key >> set? > > You may have leaked keys without having leaked ciphertext. > The typical use case for FDE/SED is IMO being able to RMA drives. > Nothing more than that. Yeah, but you necessarily need to let people keep using the old key *and* give them the new one on-demand if they've got access to the system, in order to allow switching to the new key. You need to wait for all the data to actually be rewritten with the new key before you can consider it secure again, and that'll take a loooong time. I'm not saying there isn't threat mitigation here, just that I'm not sure it's useful against somebody who's already obtained access to your encryption keys — if they've gotten those it's unlikely they won't have gotten OSD keys as well, and if they've got network access they can impersonate an OSD and get access to whatever data they like. I guess that still protects against an external database hack from somebody who gets access to your old hard drives, but...*shrug* > >> > For compression to be effective it must be done before encryption. Due >> > to that encryption may be applied differently for replication pools >> > and EC pools. Replicated pools do not implement compression; for those >> > pools encryption is applied right after data enters OSD. For EC pools >> > encryption is applied after compressing. When compression will be >> > implemented for replicated pools, it must be placed before encryption. >> >> So this means you'll be encrypting the object data, but not the omap >> nor xattrs, and not the file names on disk. Is that acceptable to >> people? It's probably fine for a lot of rbd use cases, but not for >> RGW, CephFS, nor raw RADOS where meaningful metadata (and even *data*) >> is stored in those regions. I'd rather a solution worked on the full >> data set. :/ >> -Greg > > This is indeed the largest weakness of the proposal. > > I'm lacking a bit on the motivation for what problem this solution > solves that a dm-crypt-based solution doesn't address? When, except for > snooping, is it a desired design to not encrypt all the things? > > I guess one could say: "ciphertext would be transferred on the network". > But, it's incomplete. Internal transport encryption (and better auth) > for Ceph is a different problem. > > I'd probably rather dm-crypt key management processes were refined and > improved (saying this without knowing the state of any current > implementations for Ceph), and have a solid FDE solution than a solution > that doesn't encrypt metadata. Only encrypting data but not metadata > isn't sufficient anymore... Yeah, I'd rather see dm-crypt get done well rather than in-Ceph encryption like this. If we want to protect data I think that's a lot more secure (and will *stay* that way since encryption is all that project does), and adding TLS or similar to the messenger code would give us on-the-wire protection from the clients to the disk. -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
