Core: Enhancement/design idea: encrypt everything: client-side end-to-end encryption using OpenPGP JavaScript implementation, not requiring additional software to be installed [$25]

[Wikinaut]

I file this as suggestion to overcome several problems with the server-side encryption of pre-4.5 versions.

Situation ownCloud (as far as I understand it)

• when using the server-side encryption, you cannot share files. Files are encrypted per single key for all files in the user directory. Sharing would require to pass the key to the person with whom you want to share the file.

Current developments:

• http://sebsauvage.net/wiki/doku.php?id=php:zerobin is a opensource online pastebin/discussion board where the server has zero knowledge of hosted data. Data is encrypted/decrypted in the browser using 256 bits AES. See also http://www.heise.de/security/meldung/Interessantes-Konzept-fuer-verschluesselte-Pastes-1541988.html
• http://gpg4browsers.recurity.com/ and http://www.openpgpjs.org/ (new [1]) and http://www.heise.de/newsticker/meldung/OpenPGP-im-Browser-1381826.html

Using the mentioned techniques it would become possible

• to have a possibility for a platform independent (browser-) client-side encryption and decryption of files. All data traffic to the server would be encrypted, all files are only stored encrypted on the server, and no server-side encryption will be necessary any longer.
• to assign all users a user key (each user has their own user key), and all their files got encrypted (client-side) with their specific user's key
• to share (encrypted) files, given that they are encrypted with more than the key of the user, for example the user key and a key for another user, or for another group who shares one group key.
• enterprise users, where in enterprises usually the installation of additional software is prohibited, can participate as any other user, because the en/decryption takes place in their browsers and does not require installation of any software (GPG, openPGP, ...) except a contemporary HTML5 browser which is capable to run the client-side crypto algorithms.
• all traffic is encrypted
• no plain files on the server

[0] https://github.com/openpgpjs/openpgpjs/wiki/Introduction#wiki-impl-js Other OpenPGP JavaScript implementations
[1] http://www.openpgpjs.org/
This project aims to provide an Open Source OpenPGP library in JavaScript so it can be used on virtually every device. Instead of other plugins that are aimed at using e.g. NPAPI (meaning they are intended to run native code), OpenPGP.js is meant to bypass this requirement (i.e. people will not have to install gpg on their machines in order to use the software). The idea is to implement all the needed OpenPGP functionality in a JavaScript library, to reuse it in other projects and to provide example applications and browser plugins. It should allow you to sign, encrypt, decrypt, and verify any kind of text - in particular e-mails - as well as managing keys.

[2] https://github.com/openpgpjs/openpgpjs/issues/12 Feature: PGP encrypted file upload/download
[3] https://github.com/hellais/up-crypt client side AES encrypted file upload.

[UPDATED 20121210]

[4] http://www.mailvelope.com/ Mailvelope is a browser extension that allows to exchange encrypted emails following the OpenPGP encryption standard.
[5] https://github.com/toberndo/mailvelope

[updated 20130102]

[6] http://www.dp-dhl.com/en/media_relations/press_releases/2012/docwallet_documents_manager_for_the_ipad.html Deutsche Post AG end-to-end AES-256 encryption for documents
[7] http://www.heise.de/ct/inhalt/2013/02/42/ "PDF-Tresor von der Post" article in "c't" 2013/2 page 42

[updated 201304261]

[8] https://github.com/toberndo/mailvelope/issues/45 regarding private key security

[updated 20131114]

I just found these cloud services claiming to offer end-to-end encrypted cloud services

[9] SpiderOak https://spideroak.com/
[10] TeamDrive http://www.teamdrive.com/de/

[LukasReschke]

@samtuke @schiesbn May I ask you to have a look at this request?

[jancborchardt]

The problem with encryption is not the implementation, but the simple fact that if you lose your password, your files are gone.

This doesn’t map to anything we know in the physical space about security, so we can’t advertise it as that. When I lock my apartment and lose my key, I can still get in somehow. But when I forget my password (which happens often to many people) everything is gone.

We have people losing data even when not using encryption, so we shouldn’t move forward with heavier features before we have the core working. I get that it’s interesting and encryption is very relevant, but it’s also really easy to lose all your data. And we don’t want that to happen, ever.

[Wikinaut]

@jancborchardt

The problem with encryption is not the implementation, but the simple fact that if you lose your password, your files are gone.

You misunderstood my suggestion. Please let me explain.I wanted to give admins who like ownCloud a tool for enhanced privacy and security. This requires an end-to-end encryption which the former (user-data based, server-side) encryption could not offer.

My design idea lists all current third-party development, which could probably be used to develop a robust plugin for ownCloud to allow such an end-to-end, client-side encryption.

The issue of "if you lose your password, your files are gone" is a no-issue and valid for everyone, everywhere. When using a "cloud" solution, this does not solve users' backup problems, which are users' issues.

• I suggest you label this bug as "enhancement". and leave it open for further discussion.

[jancborchardt]

Yeah, I’m just saying we need to be aware of it. Because in the free
software community we have this discussion on encryption all the time. But
we have to see that it’s really hard and it will lead to problems if we
don’t do it right. And to data loss, which is simply not acceptable.

On Mon, Oct 29, 2012 at 8:38 AM, Wikinaut [email protected] wrote:

The issue of "if you lose your password, your files are gone" is a
no-issue and valid for everyone, everywhere.

How is it a non-issue if you lose your files? Also, it’s valid for almost
no one, as most web service allows you to reset your password somehow. It’s
only a problem if you lose the encryption key (if your files are encrypted
with your password).

[BernhardPosselt]

This will be hard to do without problems. We are currently trying to get dependency injection going so we can create unittests more easily, so this will very likely be taking a long time to implement. But I like the idea and i think i get the usecase.

But maybe talk to Sam Tuke, he's the guy in charge of the encryption app.

[schiessle]

@samtuke and I are working on a new encryption system at the moment. It will be based on openssl to avoid any additional dependencies and will provide server- and client-side encryption without loosing other features like file sharing.

@Wikinaut thanks for your detailed description of OpenPGP JS. It is always good to know about alternatives. But if you don't mind I would like to close the issue since we are already working on it, even if we decided to use something different.

[Wikinaut]

@samtuke and @schiesbn I agree to close this enhancement "bug". Please keep me informed about progress of your client-side projects, and let me participate in user interface tests.

[Wikinaut]

added http://forum.owncloud.org/viewtopic.php?f=4&t=2184#p4079

citation from there:

To protect against the vulnerabilities and attack vectors you describe in your response, client-side encryption is a solution. I used to work for Amazon Web Services; I would often recommend client-side encryption to customers who were concerned about confidentiality. I would recommend that customers retain possession of keys or escrow them with an unrelated third party. When an application needs to perform some work, it should request the keys (over a secure channel) and retain them only in memory for only so long as necessary to do the work.

You might be interested in something called homomorphic encryption, an area of research that is exploring ways to perform work on encrypted information without decrypting it first.

[Wikinaut]

addition:

see also https://www.boxcryptor.com - it's a partial solution of my proposal. Partial, because it does not run in the browser.

You want to encrypt Dropbox, Google Drive or Microsoft SkyDrive and access your data from everywhere without worrying about data security or give up comfort? Then BoxCryptor is the perfect software for you. It has never been easier and more user-friendly to encrypt your data without losing the advantages of cloud storage.

You want to store highly sensitive files in the cloud? Your contracts, your bank details or your dissertation? BoxCryptor uses the AES-256 standard to encrypt and protect your files. AES-256 is classified by the U.S. Government to protect “TOP SECRET” information. In the Unlimited versions you can add an additional security layer by encrypting filenames.

Read also http://www.howtogeek.com/67074/how-to-encrypt-your-cloud-based-drive-with-boxcryptor/ (Loss of security of your saved data when password for your cloud account has leaked)

[Wikinaut]

not fully related to client-side encryption but touching security aspects which are relevant for ownCloud in some aspects, too:

Forensic dropbox documentation and links in article

• http://www.heise.de/security/artikel/Dropbox-ist-ziemlich-sicher-1746596.html
• "A CRITICAL ANALYSIS OF DROPBOX SOFTWARE SECURITY" http://archive.hack.lu/2012/Dropbox%20security.pdf by EADS IT staff
• https://www.heise.de/artikel-archiv/ct/2012/13/88 c't 2012/13 pp. 88-91 Kontrolle ist besser. Daten auf Online-Speichern schützen Schlagwörter: TrueCrypt, EncFS, Kryptographie, Cloud-Speicher, 7-Zip, AxCrypt, Cloud-Dienste, BoxCryptor

[samtuke]

@Wikinaut it looks like the client side encryption will be release after the server side version, I'm not sure when. You might be interested in this person's explanation of why client side encryption in the browser is not secure: http://secushare.org/end2end

This boils down to "A web browser just isn't suited for 100% private communications as it is built to do what the web server tells it to. "

[Wikinaut]

@samtuke : when you have the javascript code locally and trust the code, it's as safe as a local installation of e.g. GnuPG.exe and when you load the encryption libraries from your own ownCloud server which you control, it's also safe.

[samtuke]

@Wikinaut How would the user get the JS onto their local machine if not via their web browser? I agree that if the user is also the ownCloud server admin then they could trust the JS received from that server, but people in that situation constitute a small use case. Most ownCloud users access a server administrated by somebody else and would find it difficult to authenticate the JS they receive in my view.

[LukasReschke]

How would the user get the JS onto their local machine if not via their web browser?

For example shipped as an extension

[Wikinaut]

How would the user get the JS onto their local machine if not via their web browser?

• from read-only CD/DVD .....
• from a secured, peer-reviewed, open source repository like github

<!-- just as an example -->

<script src="https://raw.github.com/Wikinaut/fdiff/master/fdiff.js"></script>

This works: to pull in Javascript directly from a github repo. You may like the idea or not.
Yes, I also read this http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/

[butonic]

@schiesbn can you provide more details on the planned implementation? Or can you point me to a branch?

[schiessle]

@butonic Be have a branch files_encryption both in core and mirall.

the idea is quite simple:

• all files are encrypted by a symmetric key
• users have a asymmetric RSA key (similar to GnuPG)
• the public keys and the private keys are stored on the server
• the symmetric file-key gets encrypted with all public keys from users which should have access to the given file

The differences between client and server side encryption:

server side encryption:

• key gets generated on the server
• password of the private key is the same as the account password so that the server can encrypt the files

client side:

• keys are generated on the client
• user can choose an arbitrary (strong) password for his private key so that only the user at the client can encrypt his files

[Wikinaut]

@butonic wrote under point 3

the public keys and the private keys are stored on the server

"private keys stored on the server" are usually a "no go". But let me ask for what purpose (other than to apply a signature) do we need private keys on the server ?

[schiessle]

@Wikinaut You need the key on the server to easily transfer it to other devices. Let's say you set up client side encryption on your mobile phone and don't upload the keys to the server. Afterwards you want to access your files with your laptop, personal computer, tablet,... Somehow the key needs to be able to move between this devices in a user friendly way.

Regarding security. There were some security experts involved when we made this decision. Their opinion was, that this is not a problem as long as the user uses a strong pass phrase. But I was not involved in this part of the planing. If necessary, @karlitschek can say more about it.

[Wikinaut]

@schiesbn wrote

You need the key on the server to easily transfer it to other devices. Let's say you set up client side encryption on your mobile phone and don't upload the keys to the server. Afterwards you want to access your files with your laptop, personal computer, tablet,..

You can avoid storing the users' private keys on the server. It's a "no go".

You only only need to

encrypt also to the file owner

• encrypt the files you want to have on your other devices also to yourself
• using your public key stored on the server.

Decrypt such files as any other user on your local device.
This common practice for mails etc. I do not see the (dangerous) need to store the users private key on the server.

[Wikinaut]

I am pretty much against storing any private key on the server, but will leave a final decision to the security auditors.

And storing of private keys on servers can be avoided in most cases by using key agents such as "Pageant".

[schiessle]

@Wikinaut but to decrypt your files you need the private key on all devices. A key agent doesn't solve the problem that you need to be able to move the private key between many different devices.

[Wikinaut]

@schiesbn wrote

but to decrypt your files you need the private key on all devices.

Yes, of course. But everyone can deploy this key using a second "channel" - by encrypted mail for example, by encrypted zip file or by USB-cable or the like,, and the transmission is only required one time per device (if you store the private key on the device, for example like APG does).

I am only saying, that storing on a server is a "no go". I am not alone with this view.

Please correct me, if I am wrong with my view, or my proposal to also encrypt to the file owner.

[Wikinaut]

UPDATE 20121210

[4] http://www.mailvelope.com/ Mailvelope is a browser extension that allows to exchange encrypted emails following the OpenPGP encryption standard.
[5] https://github.com/toberndo/mailvelope

[ghost]

+1 for @Wikinaut ideas and implementation
Using a browser extension could verify the js to de/encrypt stuff
All files would really be encrypted
Public sharing could be assumed to not use encrypted files or have the decryption key in the url... (one time key for each file, not sure if applicable)

[Wikinaut]

@seetheprogress wrote:

Public sharing could be assumed to not use encrypted files or have the decryption key in the url... (one time key for each file, not sure if applicable)

These concepts ( decryption key in the url after #hash part ) are described here http://sebsauvage.net/wiki/doku.php?id=php:zerobin

The decryption key is in the anchor part of the URL (#…) which is never sent to server.

code see https://github.com/sebsauvage/ZeroBin

[Wikinaut]

[updated 2013-01-02][reopened, because the issue of "encrypting everything" (i.e. end-to-end) is still "hot"]

Deutsche Post AG end-to-end AES-256 encryption for documents

Citation from http://www.dp-dhl.com/en/media_relations/press_releases/2012/docwallet_documents_manager_for_the_ipad.html Deutsche Post's technical lead for DocWallet says:

"Our security concept responds to the troubling development today that central servers are increasingly the target of hacker attacks," ... "This is why DocWallet only transfers and saves encrypted documents."

• http://www.heise.de/ct/inhalt/2013/02/42/ "PDF-Tresor von der Post" article in "c't" 2013/2 page 42

[Wikinaut]

[UPDATE] only for information

"Megas erster Krypto-Fauxpas " http://www.heise.de/security/meldung/Megas-erster-Krypto-Fauxpas-1790137.html HEISE 23.01.2013

• http://www.heise.de/security/meldung/Megas-erster-Krypto-Fauxpas-1790137.html HEISE 23.01.2013 (German)
• http://www.heise.de/security/artikel/Mega-Facts-1789018.html (German)
• http://www.h-online.com/security/features/Mega-facts-1789685.html (English)
• http://www.h-online.com/news/item/Mega-s-first-crypto-faux-pas-1790286.html (English)
• https://mega.co.nz/#blog_3 (English)
• http://www.techweekeurope.co.uk/news/kim-dotcom-mega-fileshare-security-law-105024 + Update how the integrity of client-side Javascript is checked, https:// with 1024 and 2048 bit
• http://www.spiegel.de/netzwelt/web/mega-verschluesselung-in-der-kritik-a-879184.html

[UPDATE]

https://mega.co.nz/#blog_3

A word on cryptography
January 22nd 2013
The cloud storage market is dominated by players that do not take advantage of cryptography beyond HTTPS and server-side encryption. Since we set out to improve this rather dissatisfying situation three days ago, some news outlets have made attempts to dismantle our crypto architecture. Frankly, we were not too impressed with the results and would like to address the points that were raised:
ars technica: "Megabad: A quick look at the state of Mega's encryption"

He confirmed the user password is used to create the master AES-128 master encryption key, which is held on Mega servers, which in turn unlocks private keys and the user’s content. This means Mega could indeed be ordered to find keys and then open up user content.

[Wikinaut]

[UPDATE]
https://mega.co.nz/#blog_3

A word on cryptography
January 22nd 2013
The cloud storage market is dominated by players that do not take advantage of cryptography beyond HTTPS and server-side encryption. Since we set out to improve this rather dissatisfying situation three days ago, some news outlets have made attempts to dismantle our crypto architecture. Frankly, we were not too impressed with the results and would like to address the points that were raised:
ars technica: "Megabad: A quick look at the state of Mega's encryption"

[Wikinaut]

I updated https://github.com/owncloud/core/issues/106#issuecomment-12631099 .

The http://www.techweekeurope.co.uk/news/kim-dotcom-mega-fileshare-security-law-105024 "Kim Dotcom’s Mega Fileshare Service Riddled With Security Holes" has interesting details in its "Update" section and user comments.

[simonbuehler]

@Wikinaut: nice ideas, but this would break plain webdav access?

[samtuke]

The plan for owncloud is that client side encryption will be added in future, and when this is enabled, normal webui access will be disabled.

[ghost]

@samtuke since when is the plan to disable the webui?
I still would love the approach of using an owncloud browser extension with verified javascript de/encryption which therefore can decrypt on webui view...

[karlitschek]

A Javascript encryption is definitely a good idea. But I want to mention that this is not easy and done in a few hours. So we have to implement all the encrytpion features that we want to have step by step. If someone want's to implement the javascript part for ownCloud 6 that we can use. otherwise web access doesn't work with client side encryption enabled. Volunteers welcome :-)

[ghost]

Ok so client side encryption per folder would be possible?
De/encryption keys stored on the server? At least encrypted I assume?

[karlitschek]

I don't know how to answer that. :-) Everything is possible if someone implements it. ;-)

[andreasWallner]

Decryption in the Browser seems like a very bad idea, as long as the crypto functions are not provided by/included into the browser. This talk http://www.youtube.com/watch?v=kLt_uqSCEUA is one of the reasons for my doubts.

What they did was: When users surfed via their proxy server, they would inject code into a page, that would load a JS, which in turn would change JS references on the page to refer to versions of those file that included malicious code. While in this case they needed users to surf via their proxy server, the same stuff could also e.g. be done via drive-by downloads.

In the end it seems that JS code in the browser is not always secure. Providing users with the above mentioned functionality, when they might not understand the special risks involved might not be a very good idea.

[Wikinaut]

[updated 20130426, also in the head posting]
[8] https://github.com/toberndo/mailvelope/issues/45 regarding private key security

[jancborchardt]

Changed milestone to »Maybe someday« because we focus on making ownCloud stable over introducing more features.

You an also contribute directly by providing a patch – see the developer manual. :)

Thank you!

[yaplej]

A solution that allows the user to encrypt locally and still share files with other users would be ideal.

I think something like wuala that was mentioned here would be ideal.
https://owncloud.com/blog/more-to-security-than-encryption

http://dcg.ethz.ch/publications/srds06.pdf

[Wikinaut]

(keep-alive message) Is there any progress ?

[MorrisJobke]

@Wikinaut Not yet, but as far as I can remember end-to-end encryption is planned in the (far?) future. Maybe @karlitschek or @schiesbn knows more.

[karlitschek]

This is still an interesting idea. But a lot of work. It will probably take some time until something like that is implemented. Unless someone helps to implement it of course.

[MrAndMrsK]

I would like to help with such an extension, but there are owncloud-architecture/roadmap related learning-curve challenges and a perceived "even if you do a lot of the work, we don't see it as a priority for merging into the official product" risk.

Perhaps if OwnCloud devs could merely propose an architecture for this feature that fits within the current code (which they know best) so get the ball rolling. That way individual developers could work towards that implementation.

[crazybaud]

@MrMrsK I have the same point of view.

[MrAndMrsK]

I would trek off in this direction:

The goal is to protect the privacy of data and metadata as much as possible from the host, and do so efficiently in terms of space and bandwidth and server CPU. The goal is not to hide data or metadata from other authenticated users. Traditional permissions mechanisms can handle that already.

I believe OwnCloud uses WebDAV which as I understand it can accept multiple and arbitrary properties associated with each resource and that these properties can be set transactionally. Each owncloud user account has an owncloud-instance-published public key, Pub_u. Each Pri_u complement is stored on the server, but encrypted by the user's password which should be strong and unrecoverable by the host.

For each upload, the file, p, is encrypted by the client using a new randomly generated symmetric key, k, to get c = k(p). The file is crytohashed, h. c, h and each k'_u = Pub_u(k) (of users who should be able to read) are stored on the server.

Folders (collections) also each have their _own_ k, also stored as encrypted metadata and encrypted for each target Pub_u - and they have their _own_ h which is just a simple composite of the content's hashes (a basic xor?). Nested files\/folders' (resources') names are encrypted by the collection's key. (The hashes seem useful for detecting changes and can easily be updated up the WebDAV collection hierarchy in a transaction -- maybe not)

Clients use their Pri_u() to recover each k as needed. Clients store files unencrypted and probably don't need to store any public keys or sharing - these can be referenced of the server at the time that owncloud is probably already checking for conflicts.

User Groups can be supported too with each user having access to the Group's Pri_g stored and served as part of the owncloud user management. This would cut down on the number of Pub_u(k) operations needed for each upload. Also, the k doesn't really need to change each time, allowing the client to forego those expensive asymmetric crypto operations.

If any k is compromised, only that file version is affected. If any Pri_u is compromised, it should be added to a revocation list to exclude it from new uploads, but re-encrypting all files immediately is unnecessary if we can assume that the attacker already has the old versions backed up. k must be regenerated when replacing a file that has a Pri_u on the revocation list.

No file-by-file encryption is necessary. If I'm wrong about WebDAV being used, perhaps the real protocol can still support custom properties.

Is this realistic?

It may be obvious that I understand little about OwnCloud's architecture and WebDAV's capabilities. I don't mean
to make any of this sound trivial to implement. I'm just trying to get a problem-solving discussion going.

Thanks!

[howlett]

I have an issue running ownCloud locally because the uplink in my area is quite slow. I don't like the idea of trusting a 3rd party server to host my ownCloud, so I was thinking of altering the files_encryption app to send a url of the encrypted file and the key to the client until end-to-end encryption is supported. This way I could leverage external storage such as Amazon S3 (or whatever server stores the file) to send encrypted blobs directly to the client and only have my slow uplink send the address and key. Certainly less secure because the private key is being sent over the wire (although, encrypted).

Is this a feasible stop-gap between full end-to-end?
This idea is similar to what @Wikinaut has posted form zerobin.

In the long term, I was thinking that the current files_encryption app could be leveraged to map encrypted keys -> encrypted blobs. Private keys would not be stored on the server for reasons discussed above. Sharing files would require the client side to decrypt the key with your private key and encrypt with the receiver's public key.

If I understaind @MrMrsK is suggesting storing the private key on the server but protect it by a password/passphrase? This would solve the out-of-band key exchange, but I fear most users would set this password/passphrase to the exact same thing as the login password.

Can a developer comment on @MrMrsK and my suggestions? I've branched ownCloud/core and ownCloud/mirall to have a look but would very much like a nod on the plan before I invest a lot of time on this.

[dragotin]

@cornelius as we talked about...

[orion1024]

Hello,

I'm curious about the status of this feature as well.
Is there work going on about it, or is is still low priority stuff ?

[schiessle]

I'm curious about the status of this feature as well.

This would be basically a new encryption app, as described above. To my knowledge nobody works on something like that.

Additionally it would be possible to extend the exiting app with client side encryption, not on a JavaScript level but with the sync- and mobile clients. This would need relative small changes on the server side and some bigger changes on the client side. I would happily assist people working on it. But to my knowledge nobody picked it up so far.

[orion1024]

Understood, thanks for your quick answer !

I'm currently thinking about working on this, but I need to work out if I can spend the time needed, as this is long-term commitment (that and the fact that I have zero actual experience in this field, even i I am very interested in it).

[tflidd]

I would love to have a real client-to-client encryption. I put a little money on bountysource for it: https://www.bountysource.com/issues/906318-enhancement-design-idea-encrypt-everything-client-side-end-to-end-encryption-using-openpgp-javascript-implementation-not-requiring-additional-software-to-be-installed

[orion1024]

Hello,

I plan to work on this feature (not as a browser client though).
I'm looking for people willing to help.

@MrAndMrsK @howlett if you are still interested feel free to contact me.

@schiesbn thanks for your offer, I will take you up on it ! I sent an email to the dev mailing list with some details, hope it was the right place.

[howlett]

I'm still very interested, but I have very little time to do development
work at home. I will try and help where i can. Do you have a link to your
email to the dev mailing list?

Liam

On Sat Nov 22 2014 at 13:35:25 Mathieu Bourrier [email protected]
wrote:

Hello,

I plan to work on this feature (not as a browser client though).
I'm looking for people willing to help.

@MrAndMrsK https://github.com/MrAndMrsK @howlett
https://github.com/howlett if you are still interested feel free to
contact me.

@schiesbn https://github.com/schiesbn thanks for your offer, I will
take you up on it ! I send an email to the dev mailing list with some
details, hope it was the right place.

—
Reply to this email directly or view it on GitHub
https://github.com/owncloud/core/issues/106#issuecomment-64090385.

[orion1024]

Hello Liam,

No problem at all, any kind of help is welcome.
Here is the email :
https://mailman.owncloud.org/pipermail/devel/2014-November/000719.html

I'm still working on the threat model and listing the main features that are needed ; once I'm satisfied with the 1st version I will make it available so that people can comment it if they wish.
Should be one more week I think.

@schiesbn : I saw your email, thanks for the support. If I can build on the existing encryption app then all the better ! I'm trying to write down what the app should be able to do right now, looking forward to your opinion on how easily you think the existing app can integrate the features I'm listing.

[orion1024]

Hello,

I finished the first draft for the app. It is available here :
https://cloud.airmail.fr/public.php?service=files&t=a9fe1a55a59374dd6bc399f4ff4d60db
It covers the philosophy behind it, the threat model and a list of features.

Any comment/question/suggestion is more than welcome of course.

cheers

[rafcosta]

Hello all,

We have been following this thread with some attention. We are interested in the client-side encryption feature, if possible without loosing any of the existing functionalities. In my mind it may make sense to bring the actual server-side encryption to the client-side, thus distributing computing, securing data and maintaining compatibility. Maybe the original developers ( @schiesbn ) could help on designing that.

I believe we should also address client-side encryption in two ways: one where the actual files in the client filesystem remain in clear text and other where they remain cyphered.

@orion1024 we will read your document and comment it.
@karlitschek we believe we will be able to help with man power, but we want to make it in line with owncloud expectations and future developments.

Regards,

RC

[orion1024]

@rafcosta : great to see you're interested. Note that as is it the document is still a draft and I will update it this weekend with some clarifications.

I believe we should also address client-side encryption in two ways: one where the actual files in the client filesystem remain in clear text and other where they remain cyphered.

Do you mean that it should provide both options, or that the end goal should be able to keep the files encrypted ? If the former : what value would there be in that ? if we can provide end-to-end encryption why offer a less secure option to the user ?

@karlitschek we believe we will be able to help with man power, but we want to make it in line with owncloud expectations and future developments.

Agreed

[rafcosta]

@orion1024 : I mean it should provide both options. Security is just one vertice of one equilateral triangle, being the other two Functionality and Usability (or easy-of-use). If you just focus on Security, you will "drop" Functionality and Usability and, eventually, lose users. Technologically we can provide end-to-end encryption and we can achieve, almost, 100% Security (if it exists) but, in my opinion, it was never a technological "thing". Above all, we must adopt Security maintaining the most Functionality and Usability we can, dropping them in levels (tradeoffs). The majority of the users will not understand that if they lose their password (and believe me, they will lose it), they lose all their files, including the ones in their computers/devices ... Thus, we should give it as an optional, warning them of the consequences or their decision. I believe we should have 3 options:

• Server Side encryption only;
• Client Side encryption (clear text files and folders in the user end);
• Client Side encryption + (encrypted files and folders in the user end).

If possible, we should allow both the Client Side encryption simultaneous, on a folder base, for instance. With this approach we would have a three security level, easy explainable to users with the associated tradeoffs in terms of Functionality and Usability. I also think we should consider browser access where possible (I know the "browser" is not a secure platform, but once again we need tradeoffs ... browser are still used for digital certificates and bank access ...)

Regards,

RC

[orion1024]

@rafcosta

Good points. Providing the user with options is fine.
The choice should actually be user friendly itself

• make it clear what the tradeoff are
• encouraging better security (easily accessible explanations on how to remember passwords for instance)
• make the transition possible from one level to another as smooth and as painless as possible for the user

For the browser : I'm not sure of the benefits of it

• For mobile access, the apps are more usable anyway.
• For laptop/desktop, even if it spares the user the installation of the client, he would still need to manage his encryption keys. It may even be more cumbersome than just installing the client.
• It does not "unbreak" all the apps that run on the server side since decryption would still occur on the client side.
• the user still wouldn't be able to access the files directly on its file system, so it would mean a change in his way of working with files.

The "browser is not secure" point is not necessarily the most relevant : by the time we get around it (if we decide to do it), the status of browser encryption safety might have improved. Because I would see this feature as a lower priority than the regular client and mobile apps.

What do you think ?

[rafcosta]

@orion1024

I agree with you in the user friendly.

Relatively to the browser, that is the only way we have, for now, collaborative work, like sharing. Do you see it happen any other way?

[orion1024]

By sharing do you mean concurrent collaborative editing ? as in https://www.youtube.com/watch?v=xsqSLeppxm0

If yes, that is a feature I was willing to give up.
I didn't think it was a feature that was used that much, and a high maintenance feature as well (it seems very dependent of the type of file that it can be used with).
I may be wrong of course.

Sharing files would still be possible in the sense that people can get access to the same file and edit it sequentially. The editing apps (like Word/LibreOffice tracking change feature) already allows for very good collaborative editing, and will do a better job at this than any ownCloud app we might come up with.

[rafcosta]

@orion1024

By sharing I mean file sharing. Collaborative editing is a feature I will give up also. Right now you can only share a folder or file using the web interface. How are you thinking on doing it?

RC

[schiessle]

@orion1024 Thanks a lot for your initiative. By now, I didn't had time to look at your document in detail. But I will come back with some feedback.

If possible, we should allow both the Client Side encryption simultaneous, on a folder base,

It is already planed to allow the admin to enable/disable encryption based on the storage, see https://github.com/owncloud/core/issues/12216. This setting could be extended to allow the user to enable/disable it per folder. One thing we need to keep in mind in this case is that it could make it quite expensive to move files between encrypted and unencrypted folders. Also enabling/disabling it for large folders could create performance issues and lead to timeouts, etc.

By sharing I mean file sharing. Collaborative editing is a feature I will give up also. Right now you can only share a folder or file using the web interface.

If the client side encryption is based on the current server-side encryption than sharing will continue to work. I think that's the preferred way.

[rafcosta]

Hello @schiesbn

One thing we need to keep in mind in this case is that it could make it quite expensive to move files between encrypted and unencrypted folders.

I agree, but if you allow client side encryption based in the server side encryption, you are distributing the load ...

If the client side encryption is based on the current server-side encryption than sharing will continue to work. I think that's the preferred way.

That is my opinion also.

RC

[orion1024]

By sharing I mean file sharing. Collaborative editing is a feature I will give up also. Right now you can only share a folder or file using the web interface. How are you thinking on doing it?

I would add a GUI in the clients.

[rafcosta]

@orion1024

I would add a GUI in the clients.

Ok, that will do the "trick". But, perhaps, the web interface can also make sense. If the client side encryption is based in the server side encryption, the web interface will just work. You can then choose to deploy it or not, according to your needs.

[orion1024]

A small update on things ; I plan to add some details on the current document to clarify specific points during the holidays, and start putting priorities on the features.
Also, adding @rafcosta feedback regarding local encryption of course.

In January I would like to start the actual design of the cryptography protocol and other security-related stuff.
From what @schiesbn has said and what I can see of the current server-side encryption implementation, I think some modifications will be necessary to implement all the features I listed. This is not necessarily a bad thing in itself, but I don't wish to start working in a direction that would go against anything ownCloud devs might have planned.

Also, regarding the use case of using the browser to enable sharing of client-encrypted folder : that would require the server to do the work, which is not possible as we don't trust the server in our threat model (and this is the core of client-side encryption). This is mentioned in the feature list section of the document :

Unless a specific security requirement needs otherwise, all clear-text data information handling is done on the client side. Obviously for the encryption of data, but revocation and approval for instance should also occur on the client-side first, and then be sent encrypted on the host.

If we can't make that statement true in all cases, there would be no point in working on client-side encryption I think.

Another thing : if you guys wishes to discuss this more directly we can use the IRC channel or something else, I'm totally open for suggestions.

[karlitschek]

@orion1024 Very cool. Looking forward to your work

[jospoortvliet]

@orion1024 this is cool stuff ;-)

[orion1024]

Hello,

an update on things.
As I finished the first document describing intents and features, I moved on to the design of the crypto system.
As of now, it is far from finished, but I think it is at a point where someone that wants to contribute ideas/remarks has enough material to get a good idea of where I'm headed.

Here is the document (remember : this is ongoing work !) :
https://cloud.airmail.fr/public.php?service=files&t=d475f3c9d77e99d8b413977729be5f0e

And the first document with intents and features (needs some updates with the release of ownCloud 8). Still open for review of course :
https://cloud.airmail.fr/public.php?service=files&t=a9fe1a55a59374dd6bc399f4ff4d60db

Frank/jos : thanks for the support :)

[jospoortvliet]

@LukasReschke I bet you want to have a look ;-)

[orion1024]

Hello,

a new update. First, I dubbed the "ownCloud client-side encryption" feature as ownCrypt, for brievity sake. This will do at least as a temporary name.

The encrypted storage system (at least the core of it) is stabilized as far as I am concerned, so I switched to making a graph that explains more visually how the system works.
The text document grew a bit too difficult to my taste and I thought a graph would help other people to understand it more easily.

You can get the current graph here. Use yED to read it (free software).
Here is the PDF if you want a quick look at it without needing yED.

What's next :

• putting more use cases in graph
• most importantly, I will begin seeking out feedback and advice from others on the cryptographic strength and scalability of the current design before I build further on the current design. As I don't have any prior experience in crypto engineering I need more confidence in the foundation of the cryptosystem.
• begin work on other aspects of the cryptosystem that are not directly dependant on how the files are stored : key exchange, key management, for instance. Key exchange particularly is a big and interesting topic.
• integration with ownCloud current capabilities (for instance, the new sharing API coming in OC 8.1 will be instrumental for ownCrypt).

@schiesbn
@Raydiation

I am very interested in your opinion on the current state of the design. Even more so if, according to your knowledge of the current server and client code/roadmap, you think that some of my design intents might conflict with yours, or simply not mesh well together.

[jospoortvliet]

https://conference.owncloud.org/conference/oCC2015/proposal/72 talk is on YouTube.

[jospoortvliet]

https://www.youtube.com/watch?v=EI-Zyf8lOws
https://www.youtube.com/watch?v=5AM3340c9DQ
;-)

Did you make any progress lately, @orion1024 ?

[orion1024]

Thanks for the links and the work on the videos Jos !

Right now I'm busy studying the client code and how to best integrate ownCrypt into it, since ownCrypt will need to run deep in the sync logic and we want to avoid my code getting in the way of regular development.
Once I get a good grasp on this I will start working with the desktop guys to get their opinion/approval on my plans.

In parallel, there is also ongoing work with a French university in order to get more people involved in the project, especially people knowledgeable in cryptography. Nothing confirmed yet, hence my silence, but I'm hopeful.
Stay tuned...

[jospoortvliet]

/me just occasionally likes to kick @orion1024 to get some status info :innocent:

[orion1024]

We said no kicks :)

I've been at nearly full throttle for the past month, so if everything goes as planned you will hear from me around new Eve.
Fingers crossed !

[orion1024]

Here is the promised update.

I created a new issue in the client repository to kick off the ownCrypt integration discussion.
First step is to agree with the client team how the integration should happen codewise, and then off we code.

I will keep posting updates here but most of the technical discussion will now take place at the new issue.

[jospoortvliet]

Awesome! Let's see what people say. I guess you'll have to wait a bit until they're all back on the job, though...

[tflidd]

There is a new client-side transparent encryption solution (open source): https://cryptomator.org/
It should be possible to use this on top of owncloud.

[fpietrosanti]

OpenPGP.js as per 13 Feb 2015, do support entire operation via native WebCrypto API https://github.com/openpgpjs/openpgpjs/releases/tag/v2.0.0 .

[JavaZauber]

+1
this would be awesome

[xlyz]

+1

[Ardakilic]

+1 for this, too.

[Hamsterman]

+1