NOTE: This page is part of the Ubuntu Specification process. Please check the status and details in Launchpad before editing. If the spec is Approved then you should contact the Assignee, or another knowledgeable person, before making changes.
This specification aims to implement directory-level encryption settings controlled by the user.
Sensitive personal data can be accessed via LiveCD or alternate OS; this information should be encrypted. It is, however, inappropriate to make mandatory encryption of all of $HOME, as loss of password leads to loss of encrypted data.
There are several.
Bob wishes to encrypt ~/finance_reports so that other users cannot read them until he's submitted them to finance for his company.
Alice wishes to prevent her brother from LiveCDing her $HOME and reading her ~/journal/ files.
Our scope is individual folders owned by the user and selected for encryption.
EncFS will be used for encryption.
Control should be managed by a user-level daemon using a configuration file in the user's $HOME directory. Lacking this configuration file, encrypted directories can be detected when accessed by the file browser or a VFS system such as gnome-vfs to allow recovery in the case of destroyed daemon configurations.
Interfaces to the user-level daemon may include a stand-alone client; but a Security tab in the file browser makes more sense.
Encrypted folders should be marked as Manual and Automatic Mount.
The daemon should be activated automatically when the user logs in, and should automatically mount Automatic Mount encrypted folders. Manual mount encrypted folders should be mounted when the user tells it to; if a VFS system such as gnome-vfs detects access to an encrypted directory (configured or visibly encrypted), it should prompt the user for manual mounting.
The password for each encrypted folder should be stored as well, encrypted via GPG key. The preferred mechanism for creating or mounting an encrypted folder should be to ask the user for their GPG key passphrase. Actual passwords per folder can be randomly generated and very long.
The interface to create an encrypted folder should give a prominently visible link to a help system entry which details the concerns and best practices of handling a GPG key and encrypted folders. The following important details should be stressed:
- GPG key management.
- A GPG private key is only backed up when the user explicitly does so.
- Losing a GPG private key renders all data encrypted to the user unreadable.
- GPG private keys are encrypted via passphrase and cannot be recovered if the passphrase is lost; they are effectively destroyed.
- Nobody else should have your GPG private key or private key passphrase, or all data is assumed readable by everyone.
- Threats protected against
- An attacker with physical access to the machine can read data they can't normally read.
- Encrypting the data prevents the attacker from reading or modifying the data.
- Encrypted data can still be destroyed by an attacker.
- Encrypted folder destruction
- Encrypted folders cannot be recovered if the GPG private key is lost.
- Each encrypted folder gets a password file encrypted by GPG; if the password file for an encrypted folder is destroyed, the contents of that folder are lost.
- Password file back-ups are made; password file back-ups can be exported explicitly to external media.
See Design; this probably needs work.
- Some work to create a Security tab in Nautilus and whatever KDE uses will have to be done.
- The EncFS daemon will have to be written.
What in the heck UI do you need for this? A 'folder' in Nautilus/Computer that says "Encrypted Folders" and lists all known encrypted folders, allowing you to activate/deactivate encryption? Context menu activation and creation via the Permissions tab (or Security as re GNOME Bug 357750) is simple enough.
- EncFS is not currently as robust as I'd like for this.
It does not mount in place; but rather mounts one directory onto another. This is probably due to the design of FUSE; I've requested a transparent access mechanism be added to FUSE, see the fuse-devel mailing list.
I would prefer a special file interface which keeps a database at /path/to/mount/..encfs.meta.db and exports ..encfs.meta.db as a character special device or socket. Writes to this device would be handled associated with the process (concurrent by multiple processes would not interleave). This would allow file-granularity encryption, with files not explicitly encrypted/plaintext inheriting from the directory setting.
- With this method, the daemon would become unnecessary; it would be built into the file system. However, some method of EncFS auto-mounting on log-in (i.e. PAM EncFS) would then be required. Individually protected files would be tricky to implement, and use of a GPG-based solution would require care in preventing GPG keys from being encrypted (by marking the file PRIMARY KEY in the database so that it would never be encrypted?).
BoF agenda and discussion
Never, ever, ever take a PAM EncFS approach; the potential for data loss is nasty. --JohnMoser
- We should allow the encryption of dot-dirs, especially Evolution and Firefox data, through some sort of control panel; these will not be easily discovered by the user.
If you want to do the work, EncFS could be made xattr controlled and we could point it straight at $HOME and do this with file-level granularity; currently, we can't.