Introduction to the new ownCloud Encryption App


Last weekend we released a first preview version of the new encryption app. This wouldn’t be possible without the work done by Sam Tuke and Florin Peter. Thanks a lot for all your work! Let me take the opportunity to tell you some details about the app, what it does and how it works.

The encryption app for ownCloud 5 was a complete re-write. We moved from the relatively weak blowfish algorithm to the more secure AES algorithm. The complete encryption is built on top of OpenSSL a well-known and tested encryption library. Further, the encryption app is integrated into ownCloud seamlessly. This means that the encrypt and decrypt happens transparently so that you can still use all the other features from ownCloud like sharing, different viewer apps, WebDAV access etc.

To make this possible, we decided to perform the encryption server-side. Still the architecture allows us to implement client-side encryption as an additional option later. Server-side encryption is especially interesting for users who also use the external storage app. Combining the external storage app with the encryption app allows you to use external storage without giving any 3rd-party provider access to your data.

ownCloud uses the users log-in password for encryption. This means that you should choose a strong password in order to protect your data. It is important to know that by default a user will lose access to his data if he loses his log-in password. As an additional feature the administrator can generate a recovery key which allows him to recover user data. Once this feature is activated in the administrator settings every user can enable the recovery key in his personal settings. By default the recovery key is disabled. Every user can decide for himself whether he wants this additional protection against password loss or not. Since we are using server-side encryption this feature does not reduce the security. Keep in mind that your ownCloud administrator will always be able to intercept your data because everything gets encrypted and decrypted at the server. Since ownCloud is Free Software you can choose a trustworthy administrator freely or decide to be your own administrator if you wish.

Let’s talk about some technical details and how the encryption works. The encryption is based on three different keys: every user has a private/public key-pair, every file has a file-key and to give multiple users access to a file we have share-keys.

Every user has an asymmetric 4096-bit strong key-pair which consists of a private and a public key. The private key is encrypted with the users log-in password, for the encryption AES-128 is used. Additionally there are up to two system-wide key-pairs: One for public link shares which allows ownCloud to decrypt files which are shared as public link and if enabled the recovery-key-pair.

In order to not always have to encrypt and decrypt large files we have introduced the file-keys which are 183 byte strong ASCII keys. The file-key is used to encrypt the users file symmetrically with AES-128. Than the file-key gets encrypted with the public keys from all users with access to the file. This means that if a user gets added or removed from a file we only have to re-encrypt the small file-key instead of the whole file.

Every time a file-key gets encrypted to multiple users OpenSSL generates for each user an additional share-key. Only the combination of the users private key with the corresponding share-key enables the user to decrypt the given file again.

Everybody is welcome to test the new encryption app and report issues on our mailing list or preferable directly on GitHub. But keep in mind that this is a preview version, you should always have a backup of your unencrypted data!

flattr this!

60 Responses to “Introduction to the new ownCloud Encryption App”

  1. @AshNazir says:

    RT @schiessle: Introduction to the new #ownCloud Encryption App, including some technical details: http://t.co/RULzD4Gp3y

  2. @planetdfde says:

    Neue Publizierung: Bjoern Schiessle (BeS): Introduction to the new ownCloud Encryption App http://t.co/Trl0r5PiDv #planetdfde

  3. New #encryption app for @ownCloudcom 5 released using asymmetric 4096-bit key-pair for AES-128 server-side http://t.co/VjVXXD29Ix @ZKprivacy

  4. RT @schiessle: Introduction to the new #ownCloud Encryption App, including some technical details: http://t.co/RULzD4Gp3y

  5. @andisugandi says:

    RT @fkarlitschek: Björn blogged about the new ownCloud 5 encryption system http://t.co/s12wEdpFoB

  6. RT @ownCloudcom: Bjoern introduces technical details of the ownCloud encryption app beta http://t.co/AXeXZZ82GM Please, test with great care and backup!

  7. Alessandro says:

    “Keep in mind that your ownCloud administrator will always be able to intercept your data because everything gets encrypted and decrypted at the server.”

    Sorry for the naive question: so the point in which I have to trust the administrator is when I upload the file. Is that right?

  8. “Sorry for the naive question: so the point in which I have to trust the administrator is when I upload the file. Is that right?”

    Basically you have to trust the administrator of your ownCloud server all the time. Your files arrive unencrypted on the server and leave the server unencrypted. The administrator could intercept your data both during upload and during download. But he could also manipulate the ownCloud code to do all kind of nasty stuff, don’t encrypt at all, make a copy before encryption (and/or after decryption), etc.

    • Benjamin says:

      First of all, thanks for the great work!

      Let me add to Alessandro`s “naive” question. How can it be achieved that the server itself only sees encrypted gibberish, in the sense of proper end-to-end encryption?
      I know that the traffic is protected by WebDAVS or HTTPS, is that also true for the sync app on mobile devices?

      Looking forward to your answer!
      Benjamin

      • > I know that the traffic is protected by WebDAVS or HTTPS, is that also true for the sync app on mobile devices?

        Yes, also the sync apps can connect to your server over HTTPS.

        But this doesn’t solve your initial question. In this case only the way between your computer and the server would be protected, the data would still arrive unencrypted at your server. For real end-to-end encryption we would need to implement client side encryption. As said in the article, it is possible to extend the current encryption app to provide client side encryption too. But this would probably make a large parts of the web interface useless because apps like the picture app, video streaming app, etc could no longer access your files.

        • Mark says:

          > As said in the article, it is possible to extend the current encryption app to
          > provide client side encryption too. But this would probably make a large parts of the
          > web interface useless because apps like the picture app, video streaming app, etc
          > could no longer access your files.
          I wouldn’t mind loosing functionality in the webinterface. The main reason for using it is the partly broken contact sync functionality in KDE. As soon as the sync capabilities in Android, KDE and (Windows) are working, I would only need the web interfaces in case of emergencies. For those who need it, couldn’t there be a browser plugin for accessing the encrypted data from the webinterface which does the de/encryption in the browser?

  9. Matthias says:

    Where can I find information on how to migrate existing OC files into encrypted storage mode? Before the actual upgrade, I mean ;-).

    • I don’t know if I understand your question correctly. If you simply want to use the new encryption system I would recommend to first upgrade to a version where it is included, this would be OC5.0.7 once it is ready or to a release candidate as an early adopter. After that you simply can enable the encryption app. During the next log-in all your files will be encrypted automatically. This means that the first log-in after enabling the app can take some time, don’t interrupt this process. I would strongly recommend to make a back-up of your files first!

      If you want to test the upgrade path explicitly I would recommend to start from OC4.5, enable the old encryption app, create some files and folders and than upgrade to the OC5.0.7 release candidate.

      Hope this answers your question.

      • Matthias says:

        Excellent. The first-login-after-activation part was the answer to my question. I’m eager to upgrade my 5.0.6 to 5.0.7 once it’s stable.

  10. […] Schießle escribe sobre o novo aplicativo de cifrado de ownCloud, que agora usa o cifrado AES, […]

  11. Hennes says:

    I am running into all kind of strange issues with encryption enabled:
    Users can’t change their passwords any more when the password recovery feature is enabled. A password change by the user requires the admin recovery password.
    Disabling the encryption app leaves the files encrypted. Recovery is very tedious via the versioning system. Also, after the the encryption app is disabled, all key files stay in place and apparently users can’t change their passwords at all (Class ‘OCA\Encryption\Util’ not found at /var/www/html/owncloud/settings/ajax/changepassword.php#31).

    • Thanks for your Feedback, Hennes!

      > Users can’t change their passwords any more when the password recovery feature is enabled.

      I just tried it, seems that we introduced some problems here in the final stage of the encryption app during implementation of the recovery feature. I will look into it.

      > Disabling the encryption app leaves the files encrypted.

      You are right. I think I should have mentioned it, this feature was not intended to be developed for the first version. We are looking into possibilities to provide such a feature in the future but it is not that easy since the app gets disabled by the admin but only the user is able to decrypt his files.

      > Recovery is very tedious via the versioning system.

      I don’t uderstand this sentence, can you elaborate? Versioning has nothing to do with encryption.

      > Also, after the the encryption app is disabled, all key files stay in place and apparently users can’t change their passwords at all

      It’s OK that all keys stays in place because you should be able regain access to your files by re-enabling the app. The other issue is already known and a fix is prepared.

  12. Hennes says:

    > Recovery is very tedious via the versioning system.

    I don’t uderstand this sentence, can you elaborate? Versioning has nothing to do with encryption.

    Well – to “recover” encrypted files I looked into the possibility to take the unencrypted versions from the versioning system. Files which existed before the encryption app was enabled still existed in an unencrypted version.

  13. Matthias says:

    Hi, I just installed the the encryption app on my owncloud system, when I now download some files they are all encrypted and I am not able to open them. What did I do wrong?

    • > I just installed the the encryption app on my owncloud system, when I now download some files they are all encrypted and I am not able to open them.

      That’s strange. On our mailing list someone reported a similar issue. But until now neither I nor another ownCloud developer was able to reproduce this behaviour.

      Are you able to debug the problem? Any error messages in your web server log or in owncloud.log. This sounds like the encryption app isn’t activated on your system for some reasons. Because that’s the only situation when the plain content will be returned. If the app is enabled and loaded every data will be piped through the encryption system before output.

      • Matthias says:

        The Owncloud Logs shows:

        Debug core include path for class “OCA_FirstRunWizard\Config” starts with “apps/” 11.06.2013 0:14
        Debug core Adding user backend instance of OC_User_Database. 11.06.2013 0:14
        Fatal PHP set_time_limit() has been disabled for security reasons at /var/www/web4/html/cloud/lib/base.php#412 11.06.2013 0:13
        Debug core include path for class “OCA_FirstRunWizard\Config” starts with “apps/” 11.06.2013 0:13
        Debug core Adding user backend instance of OC_User_Database. 11.06.2013 0:14
        Fatal PHP set_time_limit() has been disabled for security reasons at /var/www/web4/html/cloud/lib/base.php#412

  14. Matthias says:

    Is there a way to encrypt your data again?

    • Hennes says:

      If the files are not decrypted automatically look for the previous versions of the files. In my setup they were unencrypted (the versioning system created a copy before the encryption happened) . It should also be possible to use openssl directly (the keys are stored in your /data).

  15. Gurit says:

    First of all think you very much for the great work around the encryption app!

    I am aware that it is hard to find a suitable middle way between security and usability. But the current concept seams to be a good compromise and I did not experience any problem during my testing.
    But there is one thing which disturbs me a bit on the current implementation. Even the file content is properly encrypted, the file/folder name is still visible in plain text on the file system.

    This issue allows anyone who has access to the system a fast and wide overview over the “kind and purpose” of the stored data and allows to profile the user.

    As mentioned in other postings here, the administrator can basically do everything but it is something different to actively intercept some traffic than having information in plain sight on the file system which you can just browse.

    In my opinion it would be a great security advancement to also have the file/folder name encrypted.

    So are there any plans to realise something like the in the future?

    • Thanks for your positive feedback!

      > In my opinion it would be a great security advancement to also have the file/folder name encrypted.

      This probably comes down to a performance issue. We using a file cache on the database to store additional meta information and also for fast access to the directory listings.

      If we encrypt the file names we would need to decrypt every single file name before displaying a directory listing in the browser the same would be true for every sync client request. I’m sceptical that this would work performance wise for large ownCloud installations.

      Alternatively we could decrypt the file name only on the file system level and keep a plain text mapping in the database. This would solve the performance issue but would probably not solve the privacy issue, at least not in all circumstances.

  16. Hi,

    I had encryption disabled installed owncloud and the new encryption started encrypting everything! I don’t want anything to be encrypted!

    You must check if encryption was disabled and do not encrypt anything.

    Edwin

    • Also when you have the Encryption “Enabled” this causes a major problem because as you call OC_Filesystem Setup, it stalls forever and cannot complete. In summary, owncloud messed up all the filesystem even after backing everything up!!!!

    • If the app is disabled no files will be encrypted. Are you sure that the app was disabled?

    • I would be more inclined to a solution where Encryption is disabled at all times and if anyone wants to mount an encrypted filesystem where they have control of all keys, let them do it
      For example http://code.google.com/p/encfs/

      • Encfs and mounting encrypted file systems is something completely different from the ownCloud encryption app. The ownCloud encryption app is disabled by default and if you prefer a standard file-system-level encryption you are free to use this, instead of the ownCloud encryption app.

  17. OU says:

    I have a basic understanding question:

    Owncloud needs to decrypt the files to make them accessible via a browser. This means, the files will be stored in plain on a server during a user session.

    If this is the case, what is the purpose of the encyrption? It makes only the things more complicated…

    • The files get decrypted on demand, for example if you download a file the file gets decrypted during download. But you are right, that this happens on the server. It’s a pure server-side-encryption.
      As I explained in the article this will not protect you against an evil ownCloud administrator but it gives you additional security if someone gets access to the data directory only or if you use external storages. For example if you mount your Dropbox, Google Drive or whatever into ownCloud and enable the encryption than the external storage provider will no longer be able to read your data.

      • OU says:

        “For example if you mount your Dropbox, Google Drive or whatever into ownCloud and enable the encryption than the external storage provider will no longer be able to read your data.”

        I get it… From security point of view, I think this is the selling point of everything… Owncloud allows you to operate your data in Cloud securely (by collecting all other data providers in a single interface). The requisite is that ownCloud must be operated/stored trustworthy…

        The Philosophy of OwnCloud is “OWN”Cloud. So, if there is an evil admin, that is basically you or, your admin whom you are supposed to trust…

  18. […] To find out more about how the encryption works or to test out the app visit Schiessle Blog  […]

  19. […] mit SyncClient und Android App waren kein Problem. Wichtig zu wissen ist, dass es sich (wie in diesem Artikel beschrieben) um eine serverseitige Verschlüsselung handelt, d.h. die Serveradministrator_innen […]

  20. nottings says:

    “Every user has an asymmetric 4096-bit strong key-pair which consists of a private and a public key. The private key is encrypted with the users log-in password, for the encryption AES-128 is used.”

    This does not make sense to me. How would an AES-128 (a symmetric crypto) result in a public/private key pair?

  21. […] Übrigens gibt es auf der diesjährigen FrOSCon einen einstündigen Track von Björn Schießle. In seinem Blog hat er übrigens zuletzt ein Thema angeschnitten, dass mich als nächstes interessiert: ownCloud und Verschlüsselung. […]

  22. […] Details zur neuen App findet ihr auch bei einem der Entwickler Björn Schießle in seinem Blogpost. Insgesamt eine gute Sache, besonders wenn man ownCloud in Verbindung mit der Anbindung an Dropbox […]

  23. @Vorkbaard says:

    En een nieuwe encryptie-app: http://t.co/fNKwRftL4K #ownCloud Daar zat ik op te wachten!

  24. guest says:

    Hello,

    have you a picture/diagram with a overview how does the Encryption App works.

    THX for the app and an answer ;-)

  25. Miles Hingston says:

    Thanks for your contributions to ownCloud. I have a CSV file that is frequently updated that I need to be able to decrypt and read outside of ownCloud so it can be used by another webapp. I’m trying to interface with the included crypt library (/apps/files_encryption/lib/crypt.php) but I’m not sure I have the right approach, do I need to decrypt the user private key file with my passphrase and use the output from that as the passphrase to decrypt the file? This is what I have so far, would be grateful if you could give me a quick pointer or two. Thank you.

    require_once “/apps/files_encryption/lib/crypt.php”;
    use OCA\Encryption;
    $content = file_get_contents(“OC_encrypted_file.csv”);
    $noPadding = Encryption\Crypt::removePadding($content);
    $meta = substr($noPadding, -22);
    $iv = substr($meta, -16);
    $decrypt = Encryption\Crypt::decrypt($content, $iv, “my_passphrase”);
    echo $decrypt;

    • In order to decrypt a file you need some more steps, here is an example:

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      
      require_once 'crypt.php';
       
      // first get users private key and decrypt it
      $encryptedUserKey = file_get_contents("/YOUR_OWNCLOUD_ROOT/data/USER/files_encryption/USER.private.key");
      $decryptedUserKey = OCA\Encryption\Crypt::decryptPrivateKey($encryptedUserKey, "YOUR_LOGIN_PASSWORD");
       
      // now we need to decrypt the file-key, therefore we use our private key and the share key
      $shareKey = file_get_contents("/YOUR_OWNCLOUD_ROOT/data/USER/files_encryption/share-keys/FILENAME.USER.shareKey");
      $encryptedKeyfile = file_get_contents("/YOUR_OWNCLOUD_ROOT/data/USER/files_encryption/keyfiles/FILENAME.key");
      $decryptedKeyfile = OCA\Encryption\Crypt::multiKeyDecrypt($encryptedKeyfile, $shareKey, $decryptedUserKey);
       
      // finally we can use the decrypted file-key to decrypt the file
      $encryptedContent = file_get_contents("/YOUR_OWNCLOUD_ROOT/data/USER/files/FILENAME");
      $decryptedContent = OCA\Encryption\Crypt::symmetricDecryptFileContent($encryptedContent, $decryptedKeyfile);
       
      echo "result: " . $decryptedContent . "\n";
  26. Philipp says:

    I’m not sure that i understood it correctly.

    Each user has a keypair – okay.
    Every file has a filekey – encrypted with the public key of each user having access rights…
    “In order to not always have to encrypt and decrypt large files we have introduced the file-keys which are 183 byte strong ASCII keys. The file-key is used to encrypt the users file symmetrically with AES-128. Than the file-key gets encrypted with the public keys from all users with access to the file. This means that if a user gets added or removed from a file we only have to re-encrypt the small file-key instead of the whole file.”

    And the share key is for?

    “Every time a file-key gets encrypted to multiple users OpenSSL generates for each user an additional share-key. Only the combination of the users private key with the corresponding share-key enables the user to decrypt the given file again.”

    • The share-keys are a technical necessity. If you perform multi-key encryption with openssl-seal, tan openssl encrypts the data with a randomly generated secret key. This key gets encrypted again with the provided public keys. That’s the newly generated “share-keys”. In order to decrypt the data again you need your share-key and your private key.

  27. @dabidmp says:

    Bukatzeko #owncloud zifraketa ikusi eta gero banoa lo. Introduction to ownCloud Encryption App http://t.co/vyCGymqGxx

  28. despens says:

    How does sharing in between users and public sharing work with the encryption enabled?

    I wonder if it would be beneficial to enable encryption per directory?

    • For sharing between users a file gets encrypted with the public keys of all users with access to the file. For public link share we have a key-pair with an empty passphrase. If a file gets shared as public link it gets also encrypted to the “public-user” so that ownCloud can decrypt the file again without a special passphrase.

  29. RT @lightcoin: [old post, new to me] Introduction to the new @ownCloud #Encryption App http://t.co/3yvnGYF953 #crypto #pcloud

  30. @ownCloud says:

    @BartLorica The ownCloud Encryption App uses AES. Details are here http://t.co/oAYQXd3Gkg

  31. @bvdlatisit says:

    Introduction to the new ownCloud Encryption App http://t.co/okLo6z1QXc #AES128 #rijndael

  32. […] war mich hier die beste Wahl, weil es in den neueren Versionen (> 5.0) serverseitige Verschlüsselung unterstützt. Nachteile: owncloud bietet nur eine Cloudinstanz pro Client an. Sprich, wer zwei Cloudhoster hat, […]

  33. zmelvin says:

    Thank you for the great work you’ve done with the encryption app.

    I’ve noticed a problem that creates an errorless failure when encrypting. I am running ownCloud on RHEL 6 server with FIPS enabled. FIPS mode, as I’m sure you know, prevents the running of any algorithm not approved by FIPS. In crypt.php multiKeyEncrypt() makes a call to openssl_seal() which uses RC4 for encryption. Because RC4 is not a FIPS approved algorithm the call fails with no exception being thrown.

    I know this is a problem I create by enabling FIPS mode, but thought you might like to know my findings.