[RFC] Ceph encryption support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
  We want to implement encryption support for Ceph.
  Currently, we have the draft design,

1 When user mount a ceph directory for the first time, he can specify a passphrase and the encryption algorithm and length of key etc. These will be stored as extend attribute of the current root directory, of course, with the passphrase being hashed several times, call it TOKEN. 2 When user try to mount an encrypted directory, a passphrase is required to given, then hash and compare with the stored TOKEN, if equal, accept to mount, otherwise reject to mount. 3 When a file is created, a random key (FEK, file encryption key) is generated, and this key is encrypted by TOKEN, we get EFEK (encrypted FEK), the EFEK and other encryption related information inherited from the root directory are stored in the extend attribute of file.
4 When a file is opened, retrieve the extend attribute, we get EFEK,
use TOKEN to decrypt EFEK, get FEK, buffered in the inode
5 When a file is read in readpage()/readpages(), the encrypted pages are decrypted transparently by using FEK, and the plain data are sent to application 6 When a file is written in writepage()/writepages(), the pages are encrypted transparently by using FEK, and then written to OSDs.

Some points,
1 We do client side encryption, the advantages are,
  (1) The data over network are encrypted;
(2) OSDs are intended to do io intensive job, we donot wanna bother them to do cpu intensive job, thus we can use cheap and low power machines (3) The implementation is OSD transparent, and mostly MDS transparent, enjoys the simplification.
2 What about if no page cache?
Block cipher algorithm is more secure than stream cipher algorithm, so we prefer the former. If no page cache, we have two choices, with encryption enabled, the same file is not allowed by opened by the second writer, alternatively, we enforce O_LAZYIO on the file, but application is supposed to be aware of this.

We plan to submit it as a blueprint for the incoming CDS, comments are welcome.

Cheers,
Li Wang
--
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




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux