How safe is the ownCloud encryption in a trusted LAN?

Question

ownCloud looks like a promising locally hosted dropbox alternative. However, it has been pointed out that the encryption is not exactly strong... (The ownCloud team does at least provide a list of problems themselves) But assuming I'm running an ownCloud server in a trusted LAN, is the stored data safe enough to withstand physical theft of the unpowered server? With "safe enough" I mean compared to e.g. a unmounted TrueCrypt volume.

Answer 1

Pascal's blog entry shows a few weaknesses, some of which being recalled in ownCloud's advisory, but they did not recall the worst.

The storage of encryption keys as files in /tmp is already pretty bad, especially since /tmp is a true disk-based directory in many Linux and *BSD operating system (I usually configure my /tmp to be a memory-based filesystem, but this is not the default). Therefore, some encryption keys will make it to physical storage. And it is well-known that deleting a file does not wipe the data out; it merely marks the corresponding blocks as reusable. Data is not written over until some new files are created. Thus, it can be assumed that some keys will leak if the unpowered server is stolen.

The worst weakness is about key generation. Pascal states it as:

The computation of the overall entropy, and thus the effort to guess a key, is left to the reader… Not to mention the maximal achievable amount of 4*log₂(99999-10000+1) = 65.8 bits of entropy, which are far from the recommended minimal value of 80 bits.

The bit about "65.8 bits" is misleading: it means that the way ownCloud generates keys implies a maximum entropy of that amount... assuming that the involved PRNG are perfect. But they're not. The 65.8 comes from the key production as four integers in the 10000..99999 range. But they come from a Mersenne twister PRNG, itself seeded with another PRNG, which is in turn seeded from the current time and the thread identifier. The time is taken to the microsecond; let's assume that the attacker knows that time with one-second accuracy. Let's also assume a 16-bit thread identifier. That's, at best, 36 bits of entropy. A mere PC will wade through that in a matter of, at worst, a few hours (encryption uses Blowfish, which has a rather expensive key schedule, but not that expensive).

Of course, since there is a password involved, attacking the password is probably even easier, but this low-entropy key generation prevents strengthening from a big, random password. This is rather hopeless. If the Mersenne twister was replaced with a decent, cryptographically strong PRNG with appropriate seeding (e.g. simply reading from /dev/urandom), then the other weaknesses would be sources of serious concern, but the weak seeding trumps everything.

Answer 2

My solution to this would be to use Linux's filesystem encryption (LUKS). You can encrypt everything on that server except for /boot if you wish, which will naturally include everything that ownCloud stores as well. With something like AES-256 and a good passphrase, physical compromise will still keep your data confidential. This is something that I'm increasingly doing on all my boxes. Given the power of modern microprocessors, even if you don't have a crypto accelerator, there really isn't a lot of slowdown.

The below link from the CentOS site shows how to do this. These instructions basically apply to any other GNU/Linux distro (I used Slackware for my first one).

http://wiki.centos.org/HowTos/EncryptedFilesystem

If you're running on the BSD's, then they also support filesystem encryption. I just haven't tried it there yet, but this from OpenBSD oughta get you started. OpenBSD uses its softraid utility for not just software RAID, but also whole-partition encryption.

http://www.openbsd.org/cgi-bin/man.cgi?query=softraid&sektion=4

Hope this helps,

--SYG