Encryption in Nextcloud

Originally published at: Encryption in Nextcloud - Nextcloud

Providing strong protection of data is the biggest benefit Nextcloud has over public clouds. Self-hosting means you are in control over your data. Of course, un-authorized access has to be stopped and this is where encryption comes in. In this blog post we’ll discuss the different types and layers of encryption used by Nextcloud to keep your data safe. We will discuss the threats the different kinds of encryption are designed to protect against, aiding system administrators in defining their threat model and taking the appropriate security measures. See our website for more about security and encryption.

What is encryption?

Encrypting data means mashing it up in a way that makes it nearly impossible for somebody else to read it without a secret token called the encryption key. A simple example is the Caesar cipher: just shift every letter in the alphabet a fixed number of characters. Say you choose 3. An A then becomes a D, a B becomes an E and so on. A message like meet me now becomes phhw ph qrz. Unless you know how many letters to shift, that is, the key (3 in this case) it is very hard to find out the content of the message.

Modern encryption is far more complicated than that, using mathematical tricks to make it extremely hard to break. You can learn more about those techniques on this Wikipedia page.

What is Threat Modelling?

Thread Modelling is the process of determining what threats are relevant and need to be protected against. It is used by system administrators to ensure their systems are correctly configured and provide adequate protection without unduly burdening users with overly complicated security hurdles.

Let’s give an example. Say you want to protect your car. Without asking “from what”, you might make the wrong decisions. Even a thick wall and a canal around your house with crocodiles, while probably effective against burglary, wouldn’t protect the car against heavy hail, something a simple roof would have done.

Of course, in an IT environment, you have multiple types of data. From customer data and fiscal year reports to the photos from last year’s Christmas party. While the latter could be embarrassing, generally speaking one could expect a draft fiscal year report in an enterprise traded on the stock exchange to require a greater degree of protection. Ideally even IT staff should not be able to access some of these files!

A simple approach to threat modelling is asking yourself: “what do I want to protect myself from?” Think of an imaginary attacker and think what they could do to breach your security. Then find solutions for the approaches you found. A formalized version of this approach is using ‘attack trees’ which was invented by security expert Bruce Schneider. You see an example attack tree for a virus attack here:

See the wikipedia page about threat modelling for more details and some history, and check this page about attack trees.

Encryption in Nextcloud

Nextcloud offers multiple layers of encryption for your data. First, data is protected when being transferred between clients and servers as well as between servers. Second, data can be encrypted on storage; and last but not least, we offer end-to-end encryption in the clients.

Each has their place and offers a different kind of protection, suitable to protect from a specific type of threat. We will describe each type of encryption and what it protects against.

Encryption during data transfer

Transfer encryption used by Nextcloud secures the connections between servers and clients. This uses standard TLS, a secure communication protocol used by HTTPS. HTTPS is what makes the lock in your browser address bar turn green! It is configured in the webserver, like Apache or NGINX, and our manual contains some instructions here. We strongly recommend to always use Nextcloud with TLS and we’ll warn system administrators strongly if it is not turned on.

Threat model

Nextcloud uses ‘plain and simple’ HTTP traffic for all file handling, which can be protected with TLS. TLS protects against attempts to capture data in transit between the server and client. It does not protect against a hacked device or server, but prevents data transfers on insecure networks like public WiFi networks, mobile devices or third party networks from being intercepted and is thus invaluable for a Nextcloud deployment.

Storage encryption

The Nextcloud Server Side Encryption feature provides secure storage of data by encrypting each file with a unique file key before it is stored. File keys are encrypted, in turn, either by a server wide key (default for feature and performance reasons) or a per-user key. Server Side Encryption provides protection for data on external storage as the files are encrypted before they are sent to storage and the keys never leave the Nextcloud server.

A server-wide key stores a server password in the Nextcloud data directory and uses it to decrypt the server key in the users’ data directory, which in turn is used to decrypt data.

When using per-user keys, the key in the data directory is per user and encrypted with the user password. We take great care to ensure keys never enter storage but keys will be kept in memory on the Nextcloud server for the duration of user login sessions to facilitate decryption and encryption of data.

Note that the Nextcloud desktop synchronization clients check for updates every 30 seconds, frequently and predictably providing a window for a malicious server administrator or hacker to steal the keys from the user session!

And note that Server Side Encryption only encrypts the content of files, not their name or folder structure. Using object storage like S3 works around this limitation as that type of storage back-end never leaks file or folder names.

Also note that when external storage is not used and a server-wide key is used, storing the encryption keys together with the data means little protection is afforded in cases the drives are stolen. For this threat model, a full-disk-encryption technology is often a better choice than the built-in Server Side Encryption in Nextcloud. dm-crypt, eCryptFS and EncFS tend to be good choices on the server, also allowing modern encryption acceleration features in CPU’s and operating systems to be used.

Learn more about Server-side encryption on our storage page.

Threat model

Server Side Encryption protects data on storage as long as that storage is not on the same server as Nextcloud itself.

Per-user keys only offer additional protection over a server-wide key in the case of physical theft of the Nextcloud server and storage or a security breach of the sever provided the user(s) do NOT log in for the duration of the breach. A full, undetected Nextcloud server breach by skilled attackers or malicious server administrator still risks exposing user data.

Client side end-to-end encryption

The ultimate protection of user data is provided by end-to-end Encryption. The Nextcloud end-to-end encryption feature is designed such that the server never has access to unencrypted files or keys, nor does server-provided code ever handle unencrypted data which could provide avenues for compromise.

Nextcloud makes end-to-end encryption very easy to use, seamlessly handling key exchange by the server without leaking any data and facilitating easy sharing with other users and collaboration. However, it comes with a feature loss as any type of online file editing and access to encrypted data as well as public sharing and sharing to groups is not possible for data in folders that are end-to-end encrypted.

Users can activate the Nextcloud end-to-end encryption feature for one or more folders. The content of each of these folders will be fully hidden from the server, including file names and directory structure. To sync the data with other devices, users have to enter a code created by the first device. Once that is done, end-to-end encrypted folders are seamlessly synced between devices. Users can share encrypted folders with other users on their server without any need for re-encrypting and re-uploading the data or having to enter passwords for either sender or recipient.

Cryptographic Identity Protection in the form of server signed certificates and a Trust On First Use (TOFU) model protects against attackers trying to impersonate other users. Nextcloud supports an optional offline administrator recovery key and allows a complete audit log. Enterprises can optionally employ a secure HSM to to issue certificates to users.

Nextcloud File Access Control can be employed to enforce end-to-end encryption in Nextcloud based on set criteria, for example group membership of users, file extension, size and more. This way, a sub-set of sensitive data can be afforded the highest level of protection while other data and users can continue to benefit from the easy public file exchange and online collaboration capabilities of Nextcloud.

As an example, Nextcloud enables a system administrator to ensure that all files created by the Finance department have to be end-to-end encrypted while other departments can collaborate and share to their hearts’ desire.

Note that the very nature of end-to-end encryption means there is no access to data through the web interface, nor any public sharing. This is because a browser would need to decrypt the files locally for the user to see them, but the code to do that has to come in the form of javascript from the server. This would break the trust model: End-to-end encryption is meant to protect from the server and thus one can’t trust the code from the server to decrypt the data and not sent a copy of the secure key to a third party server. This is more extensively discussed in an article from the security experts at the NCC Group. End-to-end schemes that have a browser component are no more secure than server-side encryption, which is why we recommend using instead if access through a browser is needed.

Learn more about End-to-end Encryption on our website. Note that as of August 2020, end-to-end encryption is available on the latest releases of the desktop and mobile clients. It requires Nextcloud server 19 with version 1.5.2 or version 20 with 1.6.1. Sharing between users is not yet implemented and on the roadmap for 2021.

Threat model

End-to-end Encryption in Nextcloud is designed to protect user data against any attack scenario between user devices, even in case of a undetected, long-term security breach or against untrusted server administrators.

It does not protect the data on user devices themselves and theft of an unencrypted, unlocked user device would enable an attacker to get access to private keys.

Conclusion

Encryption is used by Nextcloud to protect your data in transit and on external storage – and with End-to-end Encryption even against an untrusted server. When setting up a self-hosted file sync and share solution, it is wise to develop a threat model, determining clearly what threats the server should protect against, and then configuring the server environment to ensure protection against the identified threats. This blog post should then help choose the correct type(s) of encryption to employ to achieve the desired level of protection.

Just want to point out a minor typo: right above the Conclusion paragraph, the header says “Treat Model” and should probably be “Threat Model”

1 Like

In a Monty Python voice: Obviously we have to treat our threats someway.

2 Likes

I need a bit of clarification regarding storage / server-side encryption…

For my instance, I have a Digital Ocean Droplet with the Nextcloud SNAP installed.

I do NOT have external storage. All my Nextcloud documents, pictures, files, etc are stored on the same Digital Ocean Droplet where Nextcloud is installed.

Question 1: does server-side encryption offer ANY protection regarding my files, documents, pictures etc. when I have my Nextcloud setup this way?

Question 2: Does the answer to Question 1 change if I use the “per-user” keys (instead of server-wide key)?

Question 3: Depending on Q1 and Q2, is there any way I can protect / encrypt my files, documents, photos with the Nextcloud setup I have? I know I could use Veracrypt to create an encrypted container and then upload the encrypted container to Nextcloud, but I’m talking about encrypting the files, documents, and photos at-rest on my server without having to use something like Veracrypt.

My files I know are protected in transit, but am I correct that if someone enters my server at Digital Ocean, they would be able to get access to all my files, documents, photos? Digital Ocean has this ability, if they wanted to get into my server, correct?

Does Nextcloud 18 now come with built-in client side encryption on files, calendar, contacts, notes by default without having to set an folder encryption password?

1 Like

Of course not. Keep in mind that calendar and contacts are saved in the database and I have not seen a concept on potentially encrypting those.
The here announced E2EE in the clients is still Alpha and can’t provide basic functions like sharing.

Server-side encryption is not great for protecting your files since the key is located on the server (it has to be). It’s better than nothing, but if for example access is gained to the nextcloud instance to where occ commands can be executed, then it is trivial to change an account password. Armed with that, one can login to any account and have unencrypted access to files therein. It’s not easy to hack a Nextcloud server, but surely a droplet offers less protection thatn running your own self-hosted version (I do the latter - it’s also free of monthly charges).

For that reason, I don’t rely on server-side encryption only - I personally use Cryptomator for end to end encryption (I found the Nextcloud implementation to be too squirly for me). Cryptomator allows me to client-side encrypt all my private files. It makes sharing more difficult but not impossible. Cryptomator has also been integrated into Mountain Duck Windows File Manager which makes for seamless user access to a large degree. Overall, it’s a really good compromise that would absolutely stop a third-party from hacking your files, even if they can change your password.

I wrote up a short article on this some time ago. If you get vbored, it goes into some of the detail of how you can use ‘layers’ of encryption to protect yourself to a pretty decent level:

https://sysadmin.exploinsights.com/index.php/2018/09/17/meeting-compliance-with-the-aid-of-nextcloud-cryptomator-and-mountain-duck/

Whether you like Cryptomator or one of the alternatives (including Nextcloud’s version), I for one encourage you to evaluate and use it. It’s the ONLY way you can be completely sure your files are safe.

Good luck!

Andrew

Can you share files/folders with Cryptomator from one user to another or with a group? Thats clearly lacking for me in the Nextcloud implementation and strange …

No. You have to decrypt a file to share it. If you share a link to the decrypted file, that has to include the key to decrypt the file which defeats the purpose of E2E encryption. So neither cryptomator or Nextcloud’s E2E has that “feature”. Boxcryptor does have a feature (called whisply, located at wisply.ly) that seems to get around this but it really doesn’t - they wrap your decryption key into a link for a file. You share the link to the “encrypted file” and your customer can download an encrypted file. It works but last time I checked, only for files in DropBox, Google Drive etc. - not for your own Nextcloud, so that didn’t work for me. You basically upload a file link to your google drive and it uses that to encrypt the file on your drive. It was a bridge too far for me - I had to have a solution for files I am hosting. Check it out if you really want a conveneint solution.

For my customers, I copy or move the file I want to share from my encrypted vault to an unencrypted folder, then share a link to that. I use LAYERS of security tt protect my (and my customers) files, so even my decrypted file is protected by server-side encryption. Not perfect, but by no means terrible. Remember that you can share server-side encrypted files from Nextcloud.

I wrote a blog entry on that some time ago for compliance record keeping purposes. If you’re interested, you can read it here:

https://sysadmin.exploinsights.com/index.php/2018/09/20/securely-sharing-files-from-nextcloud/

I went to considerable effort to develop my sharing strategy as I work all over the world and yet i have to have a very secure way of sharing files. It works for me - only a very determined hacker can get at my fiiles, and I don’t have anything THAT valuable - just customer data, letters and such so I assess this to be “adequate”. In practice, what i do is probably better than 95%+ of all other companies, so I don’t feel too bad abut my setup. :slight_smile:

Remember that Security is NOT convenient. There’s a price you have to pay. I worked hard to make my price small, but it’s still there. Good luck.

Andrew

2 Likes

Server Side Encryption is only really useful if you use a an external storage like Objectstorage S3 at another, untrusted provider.

Nextcloud server-side encryption encrypts files stored on the Nextcloud server, and files on remote storage that is connected to your Nextcloud server. Encryption and decryption are performed on the Nextcloud server. All files sent to remote storage will be encrypted by the Nextcloud server, and upon retrieval, decrypted before serving them to you and anyone you have shared them with.

https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/encryption_configuration.html

1 Like

Thanks for the insights! What is your take on the owncloud E2EE encryption in the web browser?
https://marketplace.owncloud.com/apps/e2eeshare
It seems to support sharing.

1 Like

Yep I agree with that - external (preferably remote) storage is the best way to deploy server side encryption. :+1:

Likely similar to the Whisp.ly app from Boxcryptor. I always liked that feature but did not like that it wouldn’t work on Nextcloud. I think this is a good option. It’s certainly more convenient than decrypting and then sharing a file via Nextcloud’s built-in functionality, but note that it has to share the decryption key as part of the link to the file. That is a potential exposure point since the key can be used to decrypt other files on the same server if they can be accessed.

I personally would use this for my install since the convenience factor is better than the downside risk of exposing my customers files, but I wouldn’t trust for extremely precious or high intrinsic value information, especially on a publicly avai;able server. Java script for this is available for this as Open Source so it would not be beyond the wit of man to write this for nextcloud such that it can offer the same e2e sharing service.

Good find.

Andrew

so I found one more E2E Nextcloud encryption app, but it works with Windows and Mac (not Linux). Mountain Duck. It’s basically a Windows Manager extension but it allows you to create links to shared encrypted files in Nextcloud. Like Whisp.ly, it has to share the encryption key with the link, but it’s still a reasonable approach. It’s a subscription service and it also requires Cryptomator as the backend encryption software. Might be worth checking out. I own both but haven’t used MountainDuck for ages (as I use Linux for most of my daily driving). :slight_smile:

Any solution that offers access through the browser can not protect from a server breach, and this is not really end-to-end encryption as that is what E2EE is meant to protect you from. This is easy to understand if you ask yourself where the code that does the encryption and decryption in the browser comes from. The answer is: the server. If you do not trust the server, you can’t trust that it does not send you code that sends an attacker (or the admin) a copy of your data, or the keys.

These kind of “end-to-end encryption in the browser” solutions are essentially security theater, not providing real security.

Read this (also linked to in the blog): https://www.nccgroup.com/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

3 Likes

This is true but it’s still better then nothing - I’m a ProtonMail user :wink:

Maybe a browser plugin could function as a trust anchor for checking that the javascript is signed from the project and was not changed on the server.

Or the E2EE should happen completely in a plugin provided by the project and not by a hoster?

Gruss

Dominik

Yes, that would solve it. But if you’re installing an app anyway (and that is what a browser extension is) then why not install the desktop client :wink:

The benefit of E2EE in a browser would be with things like public links and using a browser in a public library or such where you don’t have the desktop client. But in those cases, you also can’t install a browser extension - so you gain nothing, really.

Hope that answers the question, even though perhaps not in a satisfactory way :wink:

Note that there are some attempts to use new and upcoming browser features to sign and check javascript code that might solve this problem. It isn’t established technology yet, but some day this might be doable.