All of lore.kernel.org
 help / color / mirror / Atom feed
From: Li Wang <liwang@ubuntukylin.com>
To: "ceph-devel@vger.kernel.org" <ceph-devel@vger.kernel.org>,
	Sage Weil <sage@inktank.com>
Subject: [RFC] Ceph encryption support
Date: Tue, 12 Nov 2013 22:10:31 +0800	[thread overview]
Message-ID: <528236D7.6020106@ubuntukylin.com> (raw)

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

             reply	other threads:[~2013-11-12 14:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-12 14:10 Li Wang [this message]
2013-11-12 17:58 ` [RFC] Ceph encryption support Gregory Farnum
2013-11-21  3:50   ` Li Wang
2013-11-13  1:07 ` Alex Elsayed
2013-11-21  7:01   ` Li Wang
2013-11-21  8:44     ` Alex Elsayed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528236D7.6020106@ubuntukylin.com \
    --to=liwang@ubuntukylin.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=sage@inktank.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.