Linux Security Summit 2014/Abstracts/Halcrow

Title

EXT4 Encryption (discussion)

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.