Is storing the private key and public keys in same directory on server recommended, like OwnCloud does?

Question

Is this recommended or a good/normal practice? I think not.
Because I saw that OwnCloud stores all encryption keys in one directory on the server. One directory contains the private key(s) and one all public keys.

But their documentation says about their encryption: "But you should make sure to never lose this password, because that’s the only way to recover users’ files."
doc.owncloud.org/server/6.0/admin_manual/configuration/configuration_encryption.html

This seems totally wrong and unprofessional to me.
Or is there any good reason why both are stored there?

https://github.com/owncloud/core/blob/master/apps/files_encryption/lib/util.php#L60 All keys are in the main data directory, not in a special key directory somewhere else

Answer 1

Well the public keys are fine to store there. Thats why they are public. Anyways, you should seperate the private keys and make sure nobody else gets access to them. So probably storing them on another server would be good practice.

Answer 2

The public key can be distributed arbitrarily without any impact on security. Storing the public keys with the private keys is totally fine – for example OpenPGP is doing the same. At least linux stores its X.509 certificates in subfolder in /etc/ssl – this makes right management a little bit easier; but once you have access to a private key, you know where to find the public key (which is "just around the corner").

The question is: where to store the private keys. The server in the end needs access to the key, if you store it somewhere else, you'll have to make sure the software can find it (and then, an attacker can do, too). If you do not trust your server, you're lost anyway.

Where server-side encryption can help you is if you store data on another, unreliable third party (Dropbox, Amazon EWS, ...). Your reliable server encrypts the data, and all the third can see is encrypted data.

---

Client-side encryption would remove the necessity to store the private key on the server. But this would have some implications on applications that use standards like WebDAV, CalDAV, CardDAV, which are not aware of client-side encryption. This is why all that owncloud does is to (symmetrically) encrypt the private key with the user's password: this is always known by the system as soon as somebody connects, no matter what protocol is used.

Answer 3

It is so with existing asymmetric algorithms that the private key includes a copy of the public key, or allows its efficient reconstruction. Therefore, where private keys are, public keys are there too. In any case, public keys are public, so we may assume that everybody has them, including potential attackers, and regardless of where you put them in the first place. Keeping public and private keys "separate" does not really make sense: you can keep only private data separate. The public key, being public, cannot be separate from anything.

You want to put public keys in a directory because public keys are public and a directory is a way to publish them.

You may have private keys in a directory if that directory is also a repository for user private data, what would be called in the Microsoft / Active Directory world the user's roaming profile. It is up to the directory to maintain proper access rights so that only that specific user may access his own private data; private key storage may also be further protected with password-based encryption.

Now all that means is that an AD server for a Microsoft domain is indeed a very sensitive piece of hardware, and you'd better keep it safe from attackers. The same applies to OwnCloud, or any other system which stores sensitive data for user. This is unavoidable if the system's core functionality is indeed to make such sensitive data available to roaming users.