Two years ago ownCloud introduced server-side Encryption and now ownCloud 8.1 introduces a reworked version, dealing with many of the downsides of the initial Encryption implementation and introducing new capabilities. Read on to learn why these changes were made and how it can help you!
Encryption
The purpose of the encryption app in ownCloud is to encrypt files transparently on the ownCloud server before they get written to the storage. This means that you still have to trust the administrator of your ownCloud server, but at the same time you can utilize external storage from untrusted sources without the fear of privacy violations. Your data is also securely encrypted while the server is turned off, protecting from physical theft of the drives or server – though for this purpose, entire-disk-encryption is usually a better solution. You can read an earlier blog with more details about this here.
During the two years since the release of the Encryption app we learned a lot about our encryption– how it is used by our users and what they expect from it. It was time to take all the feedback and considerations into account and design the next generation of server side encryption, now part of ownCloud 8.1. We had two main criteria for the new encryption system:
- Backward compatibility
- Modularity
New in ownCloud 8.1: Control encryption on external storage
Backward Compatibility
For compatibility reasons we used the same encryption algorithm (4096-bit strong key-pairs for the users’ private and public key and the files key are encrypted with AES-256 by default). We needed to change the location of the keys, but the upgrade process will take care of it. We thus cover the most important compatibility concerns, however, this does not mean the upgrade is entirely unattended. The “files_encryption” app no longer exists in ownCloud 8.1. Instead we have the core functionality “Server-Side Encryption” and the app “Default Encryption Module.”
Please note that ownCloud Server 8.1.0 has some issues which occasionally cause migration problems. We recommend to wait for the 8.1.1 release if you have a current ownCloud installation with the Encryption app enabled. For new installations, or installations without encryption currently enabled, Encryption 2.0 in ownCloud Server 8.1.0 is working well.
Upgrading
After updating to ownCloud 8.1 the administrator needs to enable both the “Default Encryption Module” and the core functionality of “Server-Side Encryption” in the administrator settings. Once this is done the migration script needs to be executed. For small installations this can be done directly from the admin settings, but we really recommend to use the occ tool instead and call “./occ encryption:migrate” in the terminal. This will avoid time out settings for PHP scripts in the server causing a broken migration. We also recommend to enable maintenance mode before starting the migration to make sure that no up- or downloads start during migration. See the documentation for more details and see our note above with regards to upgrading to ownCloud Server 8.1.0.
Caveats
There are a few behavioral changes which will be noticeable for users. One is that, to avoid time outs in the PHP scripts leaving systems in a broken state, Encryption 2.0 only deals with new files. This means that it won’t encrypt unencrypted files after being enabled, nor will it re-encrypt files during the upgrade to ownCloud 8.1. Not being able to re-encrypting old files is not a problem as the encryption is compatible with the earlier used algorithm. If you enable an encryption app with a different algorithm, ownCloud will pick the right app for the right file, ensuring that new or modified files use the new algorithm while keeping the old files accessible. This also means that disabling encryption is not really possible – at least not such that the files are decrypted.
A future ownCloud release is planned to introduce the ability to re-encrypt, decrypt or encrypt all files to the ownCloud command line tool.
Choosing a back end
Modularity
One of the main reasons for the new encryption system was to provide more modularity. We learned over the last two years that it is almost impossible to meet the requirements of all users with one application. Users wanted to use different keys, key management systems and different encryption algorithms for different groups or files. Other users wanted to be able to reset the password even if the owner forgot it, or to be able to add users to groups and not have to re-encrypt or re-share files. Such abilities decrease security, which is, for other users, the highest priority.
Encryption 2.0 makes it much easier to adjust the encryption to your needs by writing your own encryption module which can implement the encryption algorithm or key management you want. This allows compliance with specific rules and regulations regarding key management or choice of algorithm, giving the right balance between security and convenience.
It also makes it possible to integrate with existing encryption infrastructure. Imagine you have a setup with a storage system, say an appliance offering SMB/NFS access, which has encrypted data residing on it. You currently access these files with a specific tool which can read and decrypt the files, but you want to make them available over multiple platforms and in the browser.
You can add your appliance as external storage in ownCloud, but it would not be able to access the files. On the other hand, you could migrate all data to ownCloud encryption– IF you would be willing to abandon your current application for accessing the files. With Encryption 2.0, you would be able to implement your current encryption algorithm and key management in ownCloud, preserving your existing work flows while adding the convenience and productivity benefits of ownCloud.
Another improvement is that Encryption 2.0 is more flexible with respect to which files get encrypted. The old encryption was designed to only encrypt files in data/user/files. Now the encryption module can encrypt or skip any files in data/user like previews, search index and more.
Architecture overview of encryption 2.0
Architecture
To make all this possible, the encryption system was split into two parts. Core contains the shared functionality of the encryption modules. It makes sure that every file gets encrypted before writing it to the storage and gets decrypted again before it is served to the user. It reacts on sharing actions and notifies the encryption module about the changes. If the internal key storage is used, core also takes care of moving keys if files get moved, deleting them if files get deleted and so on.
The second part is the encryption module. Each encryption module needs to implement an interface which specifies the methods needed by core.
The module encrypts and decrypts the data, creates the keys needed by the encryption algorithm and either hands them over to the internal key storage or manages them within the encryption module, potentially working with external key storage and management tools.
If you keep key management in the core module, creating an encryption module is not very hard as you don’t have be as careful about ownCloud internals like sharing, trashbin, key management and so on. That’s all handled by core and you can concentrate on the encryption as such. You can also implement your own key management in your encryption module but then of course you also have to handle more internal actions manually, e.g. track your keys in file move operations, trashbin behaviour, and so on.
Details on how to develop an Encryption 2.0 module is being worked on in the ownCloud Documentation.
Enabled server-side encryption
Future
Encryption 2.0 is more a beginning than an end point. Based on the many diverging needs of users, new encryption modules can and will be written, allowing users to choose exactly how much flexibility, security or ease of use they want.
If you want to get started with Encryption in ownCloud Server 8.1, check out the documentation. There is also an Encryption 2.0 whitepaper on ownCloud.com you might find interesting.
Thanks to Encryption 2.0 developer Björn Schießle for his extensive input for this post
