JamesMorris at 16:42, 15 July 2014

2014-07-15T16:42:18Z

← Older revision		Revision as of 16:42, 15 July 2014
Line 1:		Line 1:
	== Title ==		== Title ==

	EXT4 Encryption		EXT4 Encryption (discussion)

	== Presenter ==		== Presenter ==

JamesMorris: New page: == Title == EXT4 Encryption == Presenter == Michael Halcrow & Ted Ts'o, Google == Abstract == eCryptfs has served its purpose reasonably well in the years since it was merged upstream...

2014-07-15T16:41:57Z

New page: == Title == EXT4 Encryption == Presenter == Michael Halcrow & Ted Ts'o, Google == Abstract == eCryptfs has served its purpose reasonably well in the years since it was merged upstream...

New page

== Title ==

EXT4 Encryption

== Presenter ==

Michael Halcrow & Ted Ts'o, Google

== Abstract ==

eCryptfs has served its purpose reasonably well in the years since it
was merged upstream, but its extensive use in ChromeOS and Ubuntu has
revealed several shortcomings, many related to inherent problems with
stacked filesystems in Linux. Perhaps the most pertinent issue is that
cryptanalysis has advanced since eCryptfs was designed almost a decade
ago, and its susceptibility to Adaptive Chosen Ciphertext (CCA2)
attacks is an increasing cause for concern. Furthermore, dm-crypt,
loop-AES, TrueCrypt, etc. all lack cryptographically strong
integrity. Linux users are left without any really great options.

Changing the encryption mode to support both strong confidentiality
and integrity carries with it additional complexity and performance
challenges. We endeavor to leverage filesystem-layer intelligence in
EXT4 to manage integrity data. Lukas Czerner at Red Hat plans to
implement per-block metadata in 2014, a feature which we expect we can
use to intelligently and efficiently store additional cryptographic
data necessary to implement IND-CCA2-secure encryption modes like
AES-GCM. We also have options available to us in the event per-block
metadata isn't realized in the near future, which we would like to
discuss at LSS 2014.

eCryptfs suffers from a major correctness issue, in that a page dirty
in the lower filesystem page cache cannot propagate to a page dirty in
the eCryptfs page cache. Current deployments paper over this bug by
attempting to mask lower filesystem dentry's with things like eCryptfs
overlay mounts. We can eliminate this problem by implementing the
encryption directly in the data path of EXT4.

We will also incorporate customer feedback from years of eCryptfs use
in the field to avoid many of the key management and usability
pitfalls that users have reported. We will also address performance
issues that eCryptfs suffers from due to its inherent disadvantage of
being constrained to an entirely separate layer above another
filesystem. eCryptfs has also notoriously had a sort of "stack once,
debug everywhere" phenomenon, in that unintended interactions with
nuances in behavior of various lower filesystems have prevented
eCryptfs from either working at all or working reliably. eCryptfs is
commonly stacked on EXT4, and so native EXT4 encryption will
immediately resolve the performance, correctness, and security issues
that the majority of eCryptfs users deal with today.

Linux Security Summit 2014/Abstracts/Halcrow - Revision history

JamesMorris at 16:42, 15 July 2014

JamesMorris: New page: == Title == EXT4 Encryption == Presenter == Michael Halcrow & Ted Ts'o, Google == Abstract == eCryptfs has served its purpose reasonably well in the years since it was merged upstream...