Re: Allow encfs into jessie?
On Fri, Sep 12, 2014 at 11:58:04AM -0500, John Goerzen wrote:
> On 09/12/2014 06:46 AM, Jan Niehusmann wrote:
> > A common use case for disk encryption is to protect a lost or stolen
> > laptop. And the adversary is not some powerful agency, but a curious
> > person browsing through the hard disk before formatting it.
> >
> > I see no reason to assume that encfs is not good enough for that use
> > case, at the moment.
>
> There is, of course, also the problem of: what will people replace it
> with? I would suggest that some level of protection is better than
> none, and that the most likely outcome of removing encfs is no
> protection at all for a majority of users.
>
> Probably the most common suggestion, and only real option I am aware of,
> is ecryptfs. (LUKS and dm_crypt solve different problems.) Compared to
I did most of the work in forking and rewriting Cryptfs as eCryptfs.
I designed its encryption and key management, and I also wrote most of
the initial release of the userspace toolchain.
> encfs, ecryptfs is extremely difficult to use. For instance, by
> default, unlike encfs, you cannot change the password of ecryptfs data
> because the passphrase is directly transformed into the encryption key.
Each file gets its own randomly generated data encryption key known as
a FEK. This key is wrapped with the wrapping key (FEKEK) retrieved
from the user's session keyring. The signature for the FEKEK to use
for newly created files is the ecryptfs_sig= mount option. By having
the old FEKEK and the new FEKEK in the user session keyring and by
mounting with the new FEKEK as ecryptfs_sig=, you will role both the
FEK and FEKEK when you make a copy of any file. This isn't documented
and there's no toolchain available to automate this at the moment.
> After poring over poorly-documented things, I found a suggestion of how
> to work around this:
Agreed. Much documentation is definitely lacking.
> 1) Generate an encryption key with
>
> od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | \
> sed "s/^0000000//" | sed "s/\s*//g"
>
> 2) Pipe (I think!) the output from the above into
> ecryptfs-wrap-passphrase to encrypt it
>
> 3) Before mounting, run ecryptfs-insert-wrapped-passphrase-into-keyring
> pointing to the file saved in step 2
>
> 4) Save your precise mount options; in my case,
> ecryptfs_unlink_sigs,ecryptfs_fnek_sig=longstringhere,ecryptfs_key_bytes=32,ecryptfs_cipher=aes,ecryptfs_sig=anotherlongstring
>
> 5) Use those precise mount options later
>
> (These steps are rough; they may need a little tweaking but are close to
> the mark.)
>
> This is not friendly. At all.
Agreed. Ubuntu distilled the complexity into a single checkbox in the
installer, which gives a much more reasonable story for the typical
desktop user. However there's still far too much technical detail
exposed to the user, which has resulted in many users shooting
themselves in the foot -- e.g., by naively deleting their ~/.ecryptfs
directories in a misguided attempt to free up disk space.
I'm taking the lessons learned from years of experience with eCryptfs
out in the wild and seeing if I can do a better job in a file system
native solution.
> Additionally, although the ecryptfs audit at
> https://defuse.ca/audits/ecryptfs.htm produces fewer red flags than the
> encfs audit did, still its conclusion says "there are some red flags
> indicating it was not designed by a cryptographer."
The design was reviewed by industry-recognized cryptographers at IBM
Research.
> I also found mysterious bugs attempting to share the decrypted view of
> an ecryptfs volume using NFS.
The ideal of stacking in Linux was a nice fantasy, but it hasn't been
realized in practice. NFS is one of several examples where it just
hasn't worked out. That's one of the reasons why I'm currently
working on a file system native solution.
> Finally, encfs has an interesting reverse crypto mode where it
> presents an encrypted FUSE view over a plaintext mountpoint.
With eCryptfs, you would accomplish this by unmounting and then
reading the encrypted files directly from the lower file system.
> I can't find anything in the ecryptfs manpages about whether they're
> using SHA or MD5, but this RedHat bug from 2009 suggests it's using MD5.
> https://bugzilla.redhat.com/show_bug.cgi?id=490918 I do not know
> immediately why this was a red flag in encfs but not ecryptfs.
MD5 has known weaknesses for specific applications. Those weaknesses
have not been shown to apply to eCryptfs' use of MD5 in such a way so
as to substantially reduce its security.
That said, crypto attacks only get better, and so it's well advised to
use a hash that isn't known to have significant weaknesses. I'm not
motivated to update eCryptfs since I honestly would like to see it
deprecated.
> I should also note that even if the authenticity features of encfs are
> less than perfect, it doesn't mean the package is useless. A person
> may, for instance, care more about the encryption than MAC features.
> >>From what I can see, ecryptfs doesn't even have MAC at all.
Correct. This is one reason why I cannot currently recommend eCryptfs
given attacks against encryption that lacks integrity that have
surfaced in the past few years. My work with native file system
encryption addresses this issue.
Aside from lack of integrity and some stacking incompatibilities,
there are a couple of correctness and performance issues with
eCryptfs:
* Since the kernel doesn't support stacking semantics, there's no
mechanism to propagate a page invalidation from a lower inode page
cache to the eCryptfs inode page cache. Unless you successfully
hide all the dentry's for the lower inodes, eCryptfs can end up
stomping over changes to the ciphertext -- i.e., by backup/restore
utilities.
* Actual file sizes are in the file contents. Which makes directory
enumeration result in an open and read of every lower file,
impacting performance.
> Let's warn people about things, of course, but drop something that's
> useful if not perfect? I don't think so.
>
> Encryption, for a lot of people, is making onesself a harder target.
> Let's face it, encfs, ecryptfs, dm_crypt, anything like that is probably
> not going to completely protect a running Internet-connected machine
> from every possible well-funded adversary, since once the encrypted data
> is mounted, it is accessible until the machine is turned off. Physical
> keyloggers, social engineering, etc. can also be a threat. None of
> these tools is perfect, but they are all an *improvement*. If a laptop
> is stolen from a coffee table by an opportunistic thief, and I know its
> screen was locked and the data on it was encrypted by one of the above
> tools, I can pretty much rest easy that at least my data is safe.
The incidentally lost or misplaced laptop is just about the only
adversarial model that the currently available data-at-rest encryption
options available for Linux can effectively address.
Do not expect any currently available encryption solutions to help you
much if you are individually targeted.
> Transparent encryption can be an important layer of data security, but
> it must not start or stop there for those truly concerned about it.
>
> John
If you're interested in my current work in ext4, here are my slides
from this year's Linux Security Summit:
http://kernsec.org/files/lss2014/Halcrow_EXT4_Encryption.pdf
My current patchset implementing phase 1 (w/out integrity) is in the
ext4 unstable branch:
http://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/log/?h=unstable
If you have any suggestions from the distro integration side of
things, including how keys should be managed and passed to the kernel,
now would be a good time to let me know.
Reply to: