Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
    
You cannot equate the security of ownCloud to that of a TrueCrypt volume. TC is vastly superior in terms of long term storage, but ownCloud operates under a completely different security model. Even so, that list of CVEs is worrying... –  Polynomial Oct 15 '12 at 12:49
    
@Polynomial You're probably right that TC is superior, so the question is, is ownCloud sufficient? I read that ownCloud 5.0 shall provide client-side encryption, but the more important question is of course, how secure is the encryption at all... –  Tobias Kienzler Oct 15 '12 at 12:55
    
Sufficient for what? Grandma's secret cookie recipe? Probably. Personal finance information? Maybe. It depends. Corporate secrets? Maybe. It depends. Classified military documents? Probably not. –  Polynomial Oct 15 '12 at 12:57
    
@Polynomial Internal software. Let's say, sufficiently secure to make brute-forcing into the data painful enough to make e.g. programming ones own clone of the software seem the easier path –  Tobias Kienzler Oct 15 '12 at 13:01
    
So corporate secrets, then? Bruteforcing is only one of the few potential attacks, especially judging from the CVE list. –  Polynomial Oct 15 '12 at 13:02

2 Answers 2

up vote 9 down vote accepted

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*log2(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.

share|improve this answer
    
Thank you for your elaborate answer. According to the changelog, the randomization has been improved (although I don't see how the linked commit does so). So let's say the PRNG was replaced by something like TrueCrypt's "Enter 320 random characters" things would improve a lot, correct? –  Tobias Kienzler Oct 15 '12 at 14:28
    
The openssl_ function used acts as a CSPRNG, based on platform-specific entropy sources, so it has significantly better entropy than the Mersenne twister PRNG. –  Polynomial Oct 15 '12 at 14:30
    
If they fix the PRNG things, then the remaining issues take over: this is still weak, only less blatantly so. The whole proceedings reveal a lot on the competence of the ownCloud developers at doing cryptography, and that lot is not very encouraging. I would suggest not putting too much trust in it. –  Thomas Pornin Oct 15 '12 at 14:32
    
In fact, there is a commit from just yesterday that uses /dev/random, if openssl_random_pseudo_bytes fails... –  Tobias Kienzler Oct 15 '12 at 14:34
    
@ThomasPornin So my best bet is hoping someone with a stronger cryptography background helps them out, or wait and see whether ownCloud 5.0's announced client-side encryption does a better job... –  Tobias Kienzler Oct 15 '12 at 14:36

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

share|improve this answer
    
In fact I settled for LUKS / dmcrypt shared via CIFS/Samba, so after a reboot one has to SSH into the machine to mount the container. Not as transparent as I desired, but probably the best shot... –  Tobias Kienzler Feb 20 '13 at 18:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.