<br><br><div class="gmail_quote">On Thu, Mar 14, 2013 at 10:03 AM, Edward Shishkin <span dir="ltr">&lt;<a href="mailto:edward@redhat.com" target="_blank">edward@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, 13 Mar 2013 16:04:14 -0700<br>
Anand Avati &lt;<a href="mailto:anand.avati@gmail.com">anand.avati@gmail.com</a>&gt; wrote:<br>
<br>
&gt; On Wed, Mar 13, 2013 at 3:05 PM, Edward Shishkin &lt;<a href="mailto:edward@redhat.com">edward@redhat.com</a>&gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Dear all,<br>
&gt; &gt;<br>
&gt; &gt; This requires openssl of version &gt;= 1.0.1c<br>
&gt; &gt;<br>
&gt; &gt; Is it possible to upgrade the openssl on the machines, which<br>
&gt; &gt; perform smoke tests? Any ideas? I can provide the instructions..<br>
&gt; &gt;<br>
&gt; &gt; I hope this feature will be useful and popular.<br>
&gt; &gt;<br>
&gt; &gt; Thanks,<br>
&gt; &gt; Edward.<br>
&gt; &gt;<br>
&gt; &gt;<br>
<br>
<br>
</div>Hi Avati,<br>
<br>
Actually, 1.0.1 (without &#39;c&#39;) will also work, but, I guess, it won&#39;t<br>
make us more happy..<br>
<div class="im"><br>
<br>
&gt; Thanks for posting the patches! Can you give a quick summary of what<br>
&gt; 1.0.1c features are being used in the translator?<br>
<br>
<br>
</div>The following features are used (absent in 1.0.0):<br>
<br>
1) XTS:  cipher mode for data encryption;<br>
2) GCM:  cipher mode for metadata encryption and authentication;<br>
3) CMAC: mode for authentication of non-encrypted part of metadata;<br>
<div class="im"><br>
<br>
&gt; Is it possible to<br>
&gt; re-implement some code to depend on openssl-1.0.0?<br>
<br>
<br>
</div>Perhaps, we can find a replacement for (3) in the 1.0.0 (using HMACs<br>
instead of CMACs). However, absence of (1) and (2) seems to be a real<br>
problem: 1.0.0 doesn&#39;t have algorithms suitable for our purposes.<br>
Existing ones do have different issues. For example, the popular mode<br>
CBC doesn&#39;t sustain overwrites with the same key, etc.<br>
<br>
We can copypaste the absent code to the crypt translator. However, it<br>
would mean that this code will be beyond the reach of openssl people,<br>
which is not good..<br>
<div class="im"><br>
<br>
&gt; The build system<br>
&gt; is CentOS 6.3 (~= RHEL 6.3) - which is a very popular &quot;base&quot; for<br>
&gt; deploying glusterfs. I suspect depending on 1.0.1c openssl will be<br>
&gt; more than just a &quot;build server dependency&quot; issue.<br>
<br>
<br>
</div>Maybe it makes sense to ifdef the crypt translator and the related<br>
code (depending on the openssl version, or having the respective<br>
header files, say &lt;openssl/cmac.h&gt;)? I can see similar tricks in<br>
the current Gluster code (HAVE_BD_XLATOR and friends)..<br>
<br></blockquote><div><br></div><div>Either ifdef away the build of the entire translator, or copy-paste the missing functionality in 1.0 into contrib/openssl/ and conditionally compile with these if missing in the build environment?</div>
<div><br></div><div>Avati</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
Edward.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
&gt;<br>
&gt; Avati<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; On Wed, 13 Mar 2013 17:25:41 -0400 (EDT)<br>
&gt; &gt; John Mark Walker &lt;<a href="mailto:johnmark@redhat.com">johnmark@redhat.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt; This marks an interesting development in GlusterFS. If you&#39;ve been<br>
&gt; &gt; &gt; looking for data encryption, you may want to try this patch.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -JM<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -------- Original Message --------<br>
&gt; &gt; &gt; Subject: Change in glusterfs[master]:      Transparent data<br>
&gt; &gt; &gt; encryption and metadata authentication... From: &quot;Edward Shishkin<br>
&gt; &gt; &gt; (Code Review)&quot; &lt;<a href="mailto:root@dev.gluster.com">root@dev.gluster.com</a>&gt; To:<br>
&gt; &gt; &gt; CC:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Edward Shishkin has uploaded a new change for review.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Change subject:      Transparent data encryption and metadata<br>
&gt; &gt; &gt; authentication              in the systems with non-trusted<br>
&gt; &gt; &gt; server<br>
&gt; &gt; ......................................................................<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Transparent data encryption and metadata authentication<br>
&gt; &gt; &gt;              in the systems with non-trusted server<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; This new functionality can be useful in various cloud<br>
&gt; &gt; &gt; technologies. It is implemented via a pair of the following<br>
&gt; &gt; &gt; interacting translators:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; . encryption/crypt, which works on client side and performs<br>
&gt; &gt; &gt; encryption and authentication;<br>
&gt; &gt; &gt; . features/oplock, which works on server side and resolves<br>
&gt; &gt; &gt; &quot;conflicts&quot;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;             1. The class of algorithms for data encryption,<br>
&gt; &gt; &gt;            that can be supported by this pair of translators<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The mentioned pair of translators can support any atomic symmetric<br>
&gt; &gt; &gt; block cipher algorithms (which require to pad plain/cipher text<br>
&gt; &gt; &gt; before performing encryption/decryption transform (see glossary<br>
&gt; &gt; &gt; in atom.c for definitions). In particular, it can support<br>
&gt; &gt; &gt; algorithms with the EOF issue (which require to pad the end of<br>
&gt; &gt; &gt; file by extra-data).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; In most cases crypt translator translates the pair (offset, count)<br>
&gt; &gt; &gt; passed by user to different values, and resolves individual<br>
&gt; &gt; &gt; -&gt;write() -&gt;truncate(), etc. file operations to read-modify-write<br>
&gt; &gt; &gt; sequences.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; A volume can contain files encrypted by different algorithms. For<br>
&gt; &gt; &gt; newly created files one can specify desirable algorithm at mount<br>
&gt; &gt; &gt; time via a respective option of crypt translator.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Currently only one algorithm is supported: AES_XTS.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Example of algorithms, which can not be supported by this pair of<br>
&gt; &gt; &gt; translators:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 1. Asymmetric block cipher algorithms, which inflate data, e.g.<br>
&gt; &gt; &gt; RSA; 2. Symmetric block cipher algorithms with inline MACs for<br>
&gt; &gt; &gt; data authentication.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;                    2. Implementation notes.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; a) Atomic algorithms<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Since any process in a stackable file system manipulates with<br>
&gt; &gt; &gt; local data (which can be obsoleted by local data of another<br>
&gt; &gt; &gt; process), atomic cipher algorithms without proper support can<br>
&gt; &gt; &gt; lead to non-POSIX behavior. To resolve the &quot;collisions&quot; we<br>
&gt; &gt; &gt; introduce a special helper translator (features/oplock), which<br>
&gt; &gt; &gt; works on the server and manages requests (queues, grants access)<br>
&gt; &gt; &gt; of read/write issued by the clients. When an exclusive access is<br>
&gt; &gt; &gt; granted to client, the last one performs cipher transform and<br>
&gt; &gt; &gt; proceeds the stack. After all the client&#39;s work is done on the<br>
&gt; &gt; &gt; server, the oplock translator drops the access, and wakes up the<br>
&gt; &gt; &gt; next request in the queue (if any). Our implementation guarantees<br>
&gt; &gt; &gt; that an access will be granted to every concurrent process, which<br>
&gt; &gt; &gt; accesses the same file (i.e. the process won&#39;t hang).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; b) Algorithms with EOF issue<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Such algorithms require to pad the end of file with some<br>
&gt; &gt; &gt; extra-data. Without proper support this will result in losing<br>
&gt; &gt; &gt; information about real file size. Keeping a track of real file<br>
&gt; &gt; &gt; size is a responsibility of the mentioned features/oplock<br>
&gt; &gt; &gt; translator. When writing/truncating a file, the oplock translator<br>
&gt; &gt; &gt; cuts the padding and stores the last one as a special extended<br>
&gt; &gt; &gt; attribute with the key &quot;trusted.ceof&quot;. When reading a file,<br>
&gt; &gt; &gt; oplock translator appends the respective padding. So, in the<br>
&gt; &gt; &gt; bricks every file has its real size.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Comment. This makes transparent encryption incompatible with<br>
&gt; &gt; &gt; GlusterFS striping and replication translators, which spawn<br>
&gt; &gt; &gt; extra-writes to stripe/replica files without due interaction with<br>
&gt; &gt; &gt; the oplock translator.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;                   3. Non-trusted servers and<br>
&gt; &gt; &gt;                      Metadata authentication<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; We assume that server, where user&#39;s data is stored on is<br>
&gt; &gt; &gt; non-trusted. It means that the server can be subjected to various<br>
&gt; &gt; &gt; attacks directed to reveal user&#39;s encrypted personal data. We<br>
&gt; &gt; &gt; provide protection against such attacks.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Every encrypted file has specific private attributes (cipher<br>
&gt; &gt; &gt; algorithm id, atom size, trusted object id, etc), which are<br>
&gt; &gt; &gt; packed to a string (so-called &quot;format string&quot;) and stored as a<br>
&gt; &gt; &gt; special extended attribute with the key &quot;trusted.cfmt&quot;. We<br>
&gt; &gt; &gt; protect the string from tampering. This protection is mandatory,<br>
&gt; &gt; &gt; hardcoded and is always on. Without such protection various<br>
&gt; &gt; &gt; attacks (based on extending the scope of per-file secret keys)<br>
&gt; &gt; &gt; are possible.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Our authentication method has been developed in tight<br>
&gt; &gt; &gt; collaboration with Red Hat security team and is implemented as<br>
&gt; &gt; &gt; &quot;metadata loader of version 1&quot; (see file metadata.c). This method<br>
&gt; &gt; &gt; is NIST-compliant and is based on checking 8-byte per-link MACs<br>
&gt; &gt; &gt; created(updated) by FOP-&gt;create(), FOP-&gt;link(), FOP-&gt;unlink(),<br>
&gt; &gt; &gt; FOP-&gt;rename() by the following unique entities:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; . link name;<br>
&gt; &gt; &gt; . trusted file&#39;s uuid, specially created on the (trusted) client<br>
&gt; &gt; &gt; side<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Every time, before manipulating with a file, we check it&#39;s MACs at<br>
&gt; &gt; &gt; FOP-&gt;open() time. Some FOPs don&#39;t require a file to be opened<br>
&gt; &gt; &gt; (e.g. FOP-&gt;truncate()). In such cases the crypt translator opens<br>
&gt; &gt; &gt; the file mandatory.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;                         4. Generating keys<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Unique per-file keys are derived by NIST-compliant methods (file<br>
&gt; &gt; &gt; keys.c) from the<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; a) parent key;<br>
&gt; &gt; &gt; b) unique trusted object-id of the file;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Per-volume master key, provided by user at mount time is in the<br>
&gt; &gt; &gt; root of this &quot;tree of keys&quot;.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Those keys are used to:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 1) encrypt/decrypt file data;<br>
&gt; &gt; &gt; 2) encrypt/decrypt file metadata;<br>
&gt; &gt; &gt; 3) create per-file and per-link MACs for metadata authentication.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;                           5. Instructions<br>
&gt; &gt; &gt;                   how to use the new functionality<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 1) Specify an option &quot;encrypt&quot; when creating a volume.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;    Example:<br>
&gt; &gt; &gt;    # gluster volume create myvol encrypt pepelac:/root/exp8<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 2) On the client side, when mounting a volume, specify the<br>
&gt; &gt; &gt; absolute name of the file, which contains per-volume master key,<br>
&gt; &gt; &gt; overriding the option &quot;key&quot; of the crypt translator. This file<br>
&gt; &gt; &gt; should contain 256-bit AES key in the hex form, i.e. 64 symbols.<br>
&gt; &gt; &gt; Crypt translator accepts the first 64 symbols of the specified<br>
&gt; &gt; &gt; file. Other extra-symbols are ignored.<br>
&gt; &gt; &gt;    After successful mount the file with master key may be removed.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;    Example:<br>
&gt; &gt; &gt;    # glusterfs --xlator-option=myvol-crypt.key=/home/edward/mykey<br>
&gt; &gt; &gt; \ --volfile-id=myvol --volfile-server=pepelac /mnt/gluster<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; WARNING! Losing the master key means losing the data of the whole<br>
&gt; &gt; &gt; volume without any chances to recovery.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;                6. Options of the crypt translator<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; . &quot;key&quot; (specifies names of the file which contains per-volume<br>
&gt; &gt; &gt; master key); . &quot;kbits&quot; (specifies size of per-file key for data<br>
&gt; &gt; &gt; encryption), possible values:<br>
&gt; &gt; &gt;    . &quot;256&quot; default value<br>
&gt; &gt; &gt;    . &quot;512&quot;<br>
&gt; &gt; &gt; . &quot;blocksize&quot; (specifies the atom size), possible values:<br>
&gt; &gt; &gt;    . &quot;512&quot;<br>
&gt; &gt; &gt;    . &quot;1024&quot;<br>
&gt; &gt; &gt;    . &quot;2048&quot;<br>
&gt; &gt; &gt;    . &quot;4096&quot; default value;<br>
&gt; &gt; &gt; . id of algorithm for data encryption (hidden option);<br>
&gt; &gt; &gt; . id of metadata loader (hidden option);<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;                        7. Test cases<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Any workload, which involves the following file operations:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -&gt;create();<br>
&gt; &gt; &gt; -&gt;open();<br>
&gt; &gt; &gt; -&gt;readv();<br>
&gt; &gt; &gt; -&gt;writev();<br>
&gt; &gt; &gt; -&gt;truncate();<br>
&gt; &gt; &gt; -&gt;ftruncate();<br>
&gt; &gt; &gt; -&gt;link();<br>
&gt; &gt; &gt; -&gt;unlink();<br>
&gt; &gt; &gt; -&gt;rename();<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;                         8. TODOs:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 1) Currently iov_len coincides with atom_size (4K by default). We<br>
&gt; &gt; &gt; can introduce larger units for IOs to improve performance.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 2) Show encryption status (on/off) of the volume in gluster volume<br>
&gt; &gt; &gt; info.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Change-Id: I2601fe95c5c4dc5b22308a53d0cbdc071d5e5cee<br>
&gt; &gt; &gt; Signed-off-by: Edward Shishkin &lt;<a href="mailto:edward@redhat.com">edward@redhat.com</a>&gt;<br>
&gt; &gt; &gt; ---<br>
&gt; &gt; &gt; M cli/src/cli-cmd-parser.c<br>
&gt; &gt; &gt; M <a href="http://configure.ac" target="_blank">configure.ac</a><br>
&gt; &gt; &gt; M doc/gluster.8<br>
&gt; &gt; &gt; M xlators/encryption/Makefile.am<br>
&gt; &gt; &gt; A xlators/encryption/crypt/Makefile.am<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/Makefile.am<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/atom.c<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/crypt-common.h<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/crypt-mem-types.h<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/crypt.c<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/crypt.h<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/data.c<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/keys.c<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/metadata.c<br>
&gt; &gt; &gt; A xlators/encryption/crypt/src/metadata.h<br>
&gt; &gt; &gt; M xlators/features/Makefile.am<br>
&gt; &gt; &gt; A xlators/features/oplock/Makefile.am<br>
&gt; &gt; &gt; A xlators/features/oplock/src/Makefile.am<br>
&gt; &gt; &gt; A xlators/features/oplock/src/oplock-mem-types.h<br>
&gt; &gt; &gt; A xlators/features/oplock/src/oplock.c<br>
&gt; &gt; &gt; A xlators/features/oplock/src/oplock.h<br>
&gt; &gt; &gt; M xlators/mgmt/glusterd/src/glusterd-volgen.c<br>
&gt; &gt; &gt; M xlators/mgmt/glusterd/src/glusterd-volume-ops.c<br>
&gt; &gt; &gt; M xlators/mgmt/glusterd/src/glusterd.h<br>
&gt; &gt; &gt; 24 files changed, 10,159 insertions(+), 19 deletions(-)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;   git pull ssh://<a href="http://git.gluster.org/glusterfs" target="_blank">git.gluster.org/glusterfs</a> refs/changes/67/4667/1<br>
&gt; &gt; &gt; --<br>
&gt; &gt; &gt; To view, visit <a href="http://review.gluster.org/4667" target="_blank">http://review.gluster.org/4667</a><br>
&gt; &gt; &gt; To unsubscribe, visit <a href="http://review.gluster.org/settings" target="_blank">http://review.gluster.org/settings</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Gerrit-MessageType: newchange<br>
&gt; &gt; &gt; Gerrit-Change-Id: I2601fe95c5c4dc5b22308a53d0cbdc071d5e5cee<br>
&gt; &gt; &gt; Gerrit-PatchSet: 1<br>
&gt; &gt; &gt; Gerrit-Project: glusterfs<br>
&gt; &gt; &gt; Gerrit-Branch: master<br>
&gt; &gt; &gt; Gerrit-Owner: Edward Shishkin &lt;<a href="mailto:edward.shishkin@gmail.com">edward.shishkin@gmail.com</a>&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Gluster-devel mailing list<br>
&gt; &gt; <a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
&gt; &gt; <a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
&gt; &gt;<br>
<br>
</div></div></blockquote></div><br>