On Mon, 2015-12-14 at 14:32 -0800, Gregory Farnum wrote: > On Mon, Dec 14, 2015 at 2:02 PM, Martin Millnert <mar...@millnert.se> > 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*
An important part of why we moved to LUKS for key dm-crypt is that LUKS does some useful things to allow a form of key rotation. The master key is never changed (except at reformat), but it also is never disclosed beyond the host's kernel. What is stored on the disks and/or on the key servers is a key-encryption-key. The process for rotating the key encryption key is pretty sensible, given the constraints, because they go to good lengths to rewrite the blocks where the old KEK encrypted the master key. > 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 The the good reason to use dm-crypt is that novel cryptography is NOT a good thing. The dm-crypt stuff is well used and well understood, and any potential attacks against it are likely to be widely reported and property analysed. Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Team https://samba.org Samba Development and Support, Catalyst IT https://catalyst.net.nz/services/samba -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
