Full-system encryption has obvious benefits which I won't explain here. However, there are several downsides, some of them I explained in cryptography on multi user systems. Another downside is that a fully-encrypted system is... secure.

Consider the following two cases:

1. Your machine is stolen, which is especially likely with notebooks. Even if you can get it back, the thief or the next illegitimate user finds the system completely unusable and will format your disk. I assume you're keeping backups anyways, but that sucks nevertheless.
2. You got no plausible deniability. In fact, having obviously encrypted[1] your system can make you look suspicious or even guilty, even if you only wanted to preserve your privacy. Something like that happens often. After all, a righteous citizen has nothing to hide, right?

With an unencrypted system, you might have a higher chance in catching the thief, as I've seen yesterday. You can watch that talk on youtube[2]. Seriously, watch it, it's hilarious!

Today, then, it turns out that something similar has happened recently.

Additionally, with an unencrypted system, you could prove that you are, in fact, not guilty when being accused of some crime. Okay, you could just hand out the keys, but there is something better: plausible deniability.

Since we still want to use an encrypted system, the idea is to use two of them. The first one, intended for everyday usage, is encrypted and hidden, the second one completely unencrypted and unprotected, but silently tracks the machine, monitors the users interactions and is backdoored and accessible for you by default.

I'm quite sure that something like what has been described in above links won't work often, at least not completely. But it might help. And setting something up like this costs time only once and does not waste that much hard drive space. It might be worth trying.

I'll save the concrete setup for another post, but here's the basic approach[3]:

1. Perform a regular setup of the fake system of your choice. Remember: it has to be usable for everyone with physical access. Leave a large enough part of the disk unpartitioned for the real thing.
2. It also has to be usable for you via the net. Setup the required software.
3. Start a LiveCD or similar. You don't want to leave traces in the fake system.
4. Set up loopback devices to somewhere in the unformatted space. These are your systems partitions. Note the start addresses and sizes.
5. Set up the encryption mechanism of your choice (e.g. dm-crypt[4]) on the loopback devices.
6. Install.
7. Setup an USB memory stick or similar as your boot device. It is unencrypted and holds boot loader, an initial system (e.g. initramfs) that knows addresses and sizes of your hidden partitions, sets up the loopback devices, checks whether the user is authorized and, if so, decrypts and boots the real system.
8. Configure the BIOS to try to boot from USB before trying to boot from hard disk.

Congratulations. Your machine runs a neatly backdoored system that boots by default and that everyone can use[5]. The only thing that might tell attackers something is the fact that the system hasn't been used for months and that the disk has some unpartitioned space left. But we all like to have a bit of emergency storage for future partitions, right?

Oh, and keep in mind to completely overwrite the disk with random data before performing the steps above.

---

1. The MBR is still on the disk, readable, and one can see that the content of each of your partitions is, for example, encrypted using dm-crypt.
2. In the likely event that this video will get removed, that talk is named "pwned by the owner: what happens when you steal a hacker's computer" and was held at DEF CON 18.
3. This approach has not been tested by me in detail, but something along these lines should work.
4. But beware! This mechanism might write unencrypted meta-information which may tell that there might be some encrypted data.
5. Which might be, in fact, another security problem as they are able to store any data there and claim it was yours.

Introduction

In this post, it is assumed that current operating systems are multi user systems[1].

There exist several reasons for users of a computer to use encryption. To name two common cases, protecting private data is interesting (a) for everyone that owns a laptop because it might easily get lost or stolen. Less interesting, but a probably far more important reason is (b) the protection against political repression, e.g. in form of police raids.

State Of The Art

Current operating systems provide three primary solutions for encryption:

1. Use no encryption at all.

While this is no solution, it is the default for people using operating systems from a certain vendor that cripples your version even further depending on how much money you've paid. If you've bought it, that is.

I assume that this is also the default on systems of the vendor that has recently been satirized in South Park.

But even GNU/Linux distributions install an unencrypted system by default. However, depending on the specific distribution it might be rather easy to install an encrypted one. At least for technically versed people. As often on GNU/Linux, Joe Regular loses.

2. Individual encryption of private data.

On all major operating systems currently used it is possible for users to set up their own cryptographic container of some sort.

Having to manage the container more or less by hand is, however, inconvenient and not completely orthogonal to regular system usage.

Worse, it is even quite insecure. As pointed out in SucurityHole, the environment in which the user has to enter the passphrase may be compromised. This solves (most likely) problems of type (a), but if someone wouldn't mind spending a tiny effort to get your data, he will be able to get it. So this solution is not reliable in case (b).

So, let's assume (a) has been solved. How can we solve (b)?

3. Full-system encryption.

Full-system encryption is usally realized using a single master passphrase that encrypts the whole (and all) hard disks. If multiple users want to access the system, there are huge problems in case you want to revoke the access of someone. Namely, a new key might have to be chosen and distributed to the specific users. Afterwards, the whole hard disk might have to be reencrypted.

On Linux there exists LUKS, the Linux Unified Key Setup. Among other things, LUKS hides the master passphrase behind an interface allowing seven keys to be set independently. This also allows for a single "master" passphrase to be changed without having to reencrypt the whole medium.

By using a special boot procedure, for example by booting from an certain USB stick that is assumed to be uncompromisable, we get a system that is safe[2]. It can only be accessed by people knowing a passphrase.

But seven individual passphrases implies that only seven individual users are allowed to use the machine physically, which is a problem in theory.

IIRC, there exists another problem on LUKS: Every passphrase is allowed to delete any other one or add new ones. It is even allowed to delete all key slots, rendering all data inaccessible until the cipher can be broken (economically). In other words, it is impossible to enforce a user management policy on this level because of the lack of any suitable mechanism.

The real problem however is that everyone who knows any passphrase has access to all data on the system. For someone knowing a passphrase, the data is as accessible as a regular hard disk is for regular people. In other words, a single user can compromise the entire system and everyones data[3].

Again, since the system itself can be compromised, an individual encrypted storage makes it only harder for attackers, but can't prevent anything reliably. If it was used, checking the compromisable part of the system[4] before handing execution to it seems to be very costly, but would solve the issue. However, sharing data between users is not possible in a space-efficient manner and publishing new modifications is cumbersome and very inelegant.

Conclusion

Encryption on current systems is intrinsically non-multiuser. Either it applies only to single users, or everyone is permitted to compromise the system, or it is hella slow and renders user interactions unusable.

A new encryption mechanism is needed that works on the basis of objects instead of complete partitions, and allows objects to be shared securely between a dynamic set of users.

Comment

In other words, obviously the initial creator has the capability to access and modify the object. She should now be able to pass (a copy of) this capability to other users, which gain access to the resource by using exactly this reference.

Sounds to me like the capability security model on steroids.

---

1. As already implied, this claim is false. Unless we're talking about a very rudimentary concept of multi-userness. But this is not the point of this post.
2. At least as long as it is turned off.
3. It currently seems to me that this is only possible with intent, though. However, in case of (b) it might be possible to force such intent onto single users.
4. Which is essentially the current install of the OS.