Penetration Test Report (Defuse): gocryptfs cryptography design audit

Security Audit of gocryptfs v1.2
Focus: Main-Feature Cryptography Design
Taylor Hornby
taylor@defuse.ca
Defuse Security
March 6, 2017
Contents
1 Introduction 1
1.1 Audit Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Findings 3
2.1 File-Level Ciphertext Malleability . . . . . . . . . . . . . . . . . . . . 3
2.2 File ID Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Directory IV Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Same Key Used for Both GCM and EME Modes . . . . . . . . . . . . 6
2.5 No Integrity Protection for File Permissions . . . . . . . . . . . . . . 7
2.6 Pushing the Limits of GCM . . . . . . . . . . . . . . . . . . . . . . . 7
3 Good Things 8
3.1 Clear Protocol Design Documentation . . . . . . . . . . . . . . . . . . 8
3.2 No Fallback to Old On-Disk Formats . . . . . . . . . . . . . . . . . . 9
4 Recommendations and Future Work 9
4.1 Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2 In-depth Audit of the Implementation . . . . . . . . . . . . . . . . . . 9
4.3 Audit the EME Implementation . . . . . . . . . . . . . . . . . . . . . 9
4.4 Audit Reverse Mode and AES-SIV . . . . . . . . . . . . . . . . . . . 10
4.5 Audit for Non-Cryptographic Vulnerabilities . . . . . . . . . . . . . . 10
5 Conclusion 10
6 Acknowledgements 11
Appendix A Proofs-of-Concept 13
1
Abstract
This reportdocuments a two-dayauditofthe gocryptfs encryptedfilesystem. Unlike
full-disk encryption systems, gocryptfs encrypts files individually using chunked
AES-GCM (Galois Counter Mode) and encrypts filenames with AES-EME (ECB-
Mix-ECB). Our audit focused on the crypgography design of gocryptfs’s main file
encryption features; it excluded its dependencies and its more complicated “Reverse
Mode” feature that uses deterministic AES-SIV (Synthetic Initialization Vector)
encryption. We did not look at the implementation code except when it was necessary
to understand some aspect of the design.
We found that gocryptfs provides excellent confidentiality against a passive
adversary, i.e. one that does not tamper with the encrypted files. On the other hand,
we found that gocryptfs provides no security at all against an active adversary
who can modify the ciphertexts while having read access to any subdirectory of the
mounted filesystem. Against a less-powerful active adversary who can modify the
ciphertextsbuthasno accesstothemountedfilesystem,gocryptfskeepsfilecontents
secret and provides imperfect integrity protection. In at least one case, imperfections
in the integrity protections lead to a break of confidentiality. It is possible that the
integrity imperfections lead to further confidentiality breaks depending on which
applications are using the filesystem.
We believe the reason these vulnerabilities exist is because gocryptfs doesn’t
have a clearly spelled-out threat model. Some of the attacks seem hard to avoid
given gocryptfs’s performance goals and may have been introduced “by design” to
meet these goals. We suggest writing down an explicit threat model and updating
the website to better communicate the security guarantees that gocryptfs provides.
This way,users are less likely to rely on it in ways which would make them vulnerable.
1 Introduction
This report describes the findings of a two-day security audit of the gocryptfs
encrypted filesystem. From the project’s web page [5],
gocryptfs uses file-based encryption that is implemented as a mountable
FUSE filesystem. Each file in gocryptfs is stored [in] one corresponding
encrypted file on the hard disk...
The encrypted files can be stored in any folder on your hard disk, a USB
stick or even inside the Dropbox folder. One advantage of file-based encryp-
tion as opposed to disk encryption is that encrypted files can be synchro-
nised efficiently using standard tools like Dropbox or rsync. Also, the size
of the encrypted filesystem is dynamic and only limited by the available
disk space.
We audited version 1.2 of gocryptfs, specifically Git revision 9b57384.
1.1 Audit Scope
Our audit was very short (just two days), so it focused exclusively on gocryptfs’s
cryptography design for its main use case. We looked at the implementation, but only
when it was necessary to understand the design. The following potential sources of
vulnerability were not examined.
• Most of the gocryptfs source code.
• The implementations of crypto the primitives Scrypt, GCM, EME, and AES.
• The proofs of GCM’s and EME’s security properties.
• The implementation ofthe crypto/rand cryptographically-secure random num-
ber generator that gocryptfs relies on for generating random keys, salts, and
IVs.
• Non-cryptographic bugs in gocryptfs, like remote code execution bugs and
bugs in the filesystem implementation that could lead to accidental too-open
access permissions.
• gocryptfs’s“ReverseMode”aswellasnormaloperationwithAES-SIVinstead
of AES-GCM.
1
• Whether or not gocryptfs’s in-memory keys can be leaked to the system’s
swap file (there’s no code to lock keys in memory, so they probably are).
• Side-channel attacks.
The most notable omission is that we did not look into the “Reverse Mode”
design or implementation. In “Reverse Mode”, gocryptfs gives you an encrypted
view of a directory of plaintext files. In this mode, gocryptfs encrypts the files
deterministically using AES-SIV so that re-mounting the same directory results in
the same ciphertexts. This feature is important for making efficient incremental
backups possible. Deterministic encryption is difficult to get right, so we strongly
recommend a future audit that focuses exclusively on the AES-SIV features.
1.2 Threat Model
For the purposes of this audit, we’ve defined three stereotypical kinds of adversary
with the aim of capturing a variety real-world attack scenarios. Eve represents an
adversary who has the ability to write to the mounted filesystem and has read-only
access to the gocryptfs ciphertext as it changes over time. Mallory is an adversary
who has full read-write access to the ciphertext directory as well as read-write access
to part of the mounted filesystem. Dropbox is in roughly between Eve and Mallory,
with full read-write access to the ciphertext but no access at all to the mounted
filesystem.
Ciphertext Mounted filesystem
Eve Read-only Write-only
Dropbox Read-write No access
Mallory Read-write Read-write to some directories
For example, if you use gocryptfs to encrypt files on a USB drive, and then
you lose the drive and someone finds it, you need to be secure against Eve. We’ve
given Eve write-only access to the mounted filesystem to account for chosen plaintext
attacks, e.g. Eve can social-engineer the victim into placing a file of Eve’s choice onto
the gocryptfs filesystem before gaining access to the ciphertext. If you’re uploading
gocryptfs-encrypted files to the cloud, then you need to be secure against Dropbox,
since the cloud storage provider can both see and modify the ciphertext, but doesn’t
have access to any part of the mounted filesystem. Mallory corresponds to giving an
2
untrusted user full access to the ciphertext directory as well as to some subdirecto-
ries of the mounted filesystem; it’s the most powerful kind of adversary gocryptfs
could reasonably be expected to be secure against. Taking social-engineering chosen-
plaintext attacks into account, an actual cloud storage provider’s capabilities may be
closer to Mallory than to Dropbox.
The vulnerabilities we discovered are classified according to which of the three
adversaries can exploit the vulnerability and what they can gain by doing so.
2 Findings
gocryptfs doesn’t have a documented threat model, so it’s unclear what counts as
a vulnerability and what doesn’t. Not having a threat model made the audit more
difficult,since we hadto guess whatsecurityguarantees the average userwouldexpect
gocryptfs to provide after they