While the recent revelations are not all that surprising, they did stir the pot a bit and made people at least a tad more aware of the problems of personal privacy in the modern age.
I’ll try to refrain from any comments on the politics and hypocrisy of today’s world as I don’t consider my blog and Planet KDE to be a place for this. Though, it will be hard. :)
Plasma Vault
I’ve mentioned in a recent blog post) that I’ve been working on the integration of different data encryption solutions into the Plasma workspace.
The point of the project is not to provide a new encryption mechanism, but to provide a user-friendly interface to the existing ones that will be integrated into Plasma for improved security.
Integration points and the UI
The main interface is the Plasma applet that will show up inside of your system tray / notification area. From there, you can create new vaults, open and close them.
There is one big difference between creating a UI for Plasma Vault and creating an interface for regular applications and applets.
We usually tend to avoid showing big chunks of text to the user, and all errors to be unnoticeable. When Plasma crashes, it silently restarts and shows just a small icon in the tray that will easily be ignored. And yes, we also hate wizards.
Wizards
For Vault, and for other encryption tools, we need to show more text as the user needs to understand exactly what is being done. What are the benefits and what are the disadvantages of most options. All the security mechanisms in the world are just useless if used improperly.
For this reason, creating a new Vault is done through a detailed wizard that our translation teams are probably going to hate me for. The wizard allows the user to choose what encryption system to use, and configure the specifics for them.
Errors
As for the errors, none can be ignored. There is no option to have “silent failures”. All errors need to be visually explicit.
Now, failures to create or open a vault are quite obvious – you don’t have the access to the data, but errors closing the vault are a different story.
If the vault can not be closed due to an application accessing a file inside the vault, the user might be unaware of the fact that the data is still accessible to anyone who might have the access to the system.
For this reason, the Vault applet will show a nice red icon until you manage to fix the error. The icon and the error message will not just go away after a few seconds like it is the case with the device notifier applet.
I’m even pondering to add the option to forcefully kill all the applications that are using the vault, but that will probably not end up in the first release.
Currently available backends
When creating a vault, there are a three backends that you can use.
The old, but almost true, encfs
, the newcommer
cryfs
and the user-friendly wrapper for
dm-crypt
called Tomb
.
EncFS
EncFS is one of the old solutions which provides a transparent FUSE-based overlay file-system.
This means that the encrypted files live in your normal file system and they get decrypted when they are accessed through the virtual file system.
EncFS has been with us for quite a long time. It has gone under an independent security audit which detected a few problems with the design and implementation.
There are two bigger problems with EncFS.
The first one is that it creates one encrypted file for each file in the encrypted system, and the encrypted files have the same directory structure as the directories in the encrypted system. This classifies as a meta-information leak because the attacker might be able to guess some things from the number of files, the directory organization and file sizes. For example, you might have encrypted the files copied from an installation disc of some operating system you don’t have the license for – it would be easy to guess which OS it is just by looking at the number of files and the directory structure.
The more serious flaw is that the encryption techniques used are potentially vulnerable to cracking in the cases where the attacker can access multiple encrypted versions of a file.
This means it is not a good idea to use EncFS to encrypt your data that you sync to the cloud.
CryFS
CryFS is a more modern FUSE-based overlay file-system. It does not have the problems that EncFS has.
Instead of creating one encrypted file for each file in the FUSE filesystem, it splits them into chunks and encrypts all the chunks separately. Because of this, the attacker can not deduce any information related to the number of files just by looking at the encrypted data. It also does not expose the directory structure through the organization of the encrypted data.
While these are welcome improvements over EncFS, it is worth noting that there are no independent security audits of CryFS. So, while it does not have the same problems that EncFS has, it is possible that it has others.
This is the main reason why Plasma Vault supports both EncFS and CryFS – to give the user a choice between a solution that has issues, but for which the issues are known, and a solution that should be safer, but for which we don’t really know whether it is.
Tomb
The newest addition to the Plasma Vault family is Tomb. It is considered experimental, and in order to enable it in the first Plasma Vault release, you will need to add the following to plasmavaultrc:
[General]
enableExperimentalBackends=true
Unlike EncFS and CryFS, Tomb does not create an overlay-file system.
It is just a simple script that makes it easy to create encrypted
container files which get mounted like any other block device in your
system. It relies on cryptsetup/dm-crypt
for the actual
encryption.
For this reason, even if the Tomb project itself is not as mature and
as bug-free as it should be, it can be considered secure. Since it is
just a wrapper over system-provided tools, the only problem you might
have with it is that in the case of a bug, it will not be able to mount
your encrypted file. In that case, you would need to do it manually by
calling losetup/cryptsetup
and friends,
The main disadvantage of Tomb is that you need to define the size of the container file in advance – it will not grow automatically when you add new files.
Vaults versus whole-system encryption
This is the thing I get asked often – why would someone want to use Vaults when we can encrypt the whole system, including the swap partition?
I have two answers here.
The first is that this is not an either-or question. It is not Vaults versus whole-system encryption, it is Vaults AND/OR whole-system encryption.
If you want to be as secure as possible, use both.
The second answer is the reason why the whole-system encryption is not enough. When we enter the decryption password, all the data is readable until the system is powered off.
If an attacker gets the access to the system while it is powered on, all the data is accessible.
Vaults provide an additional layer of security – compartmentalization of sensitive data. You can open and close them as you wish, and usually you keep them closed. If an attacker is able to access your system, he can only access the data from the vaults open at that time.
Vaults and activities
One feature that plays really nicely with the compartmentalization is that Vaults can be connected to activities.
For each Vault, you can choose the activities that it should be available in. This means that it will show up only in those activities, and that it will automatically get closed when you switch from the activity it belongs to.
This way, the user does not need to think about closing the vaults manually – that operation becomes the part of the workflow.
I hope the wizard will not just expose every aspect of encryption technologies to the user and expect them to make an informed decision. Yes, it's good that all the different methods and options are available, but this is a case where the "simple by default, powerful when needed" mantra is more important than ever.
If you'd ever like usable security input, you know where to find me :)