Skip to content
This repository

Enhancement/design idea: encrypt everything: client-side end-to-end encryption using OpenPGP JavaScript implementation, not requiring additional software to be installed #106

Open
Wikinaut opened this Issue October 25, 2012 · 46 comments
Wikinaut
Collaborator

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:

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] openpgpjs/openpgpjs#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] toberndo/mailvelope#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/

Lukas Reschke
Collaborator

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

Jan-Christoph Borchardt
Collaborator

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
Collaborator

@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.
Jan-Christoph Borchardt
Collaborator
Bernhard Posselt
Collaborator

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.

Björn Schießle
Collaborator

@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
Collaborator

@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 Wikinaut closed this October 30, 2012
Wikinaut
Collaborator

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
Collaborator

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 Wikinaut referenced this issue in ether/etherpad-lite November 07, 2012
Open

Encryption #1140

Wikinaut
Collaborator

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

Sam Tuke
Collaborator

@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
Collaborator

@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.

Sam Tuke
Collaborator

@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.

Lukas Reschke
Collaborator

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

For example shipped as an extension

Wikinaut
Collaborator

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/

Jörn Friedrich Dreyer
Owner

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

Björn Schießle
Collaborator

@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
Collaborator

@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 ?

Björn Schießle
Collaborator

@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
Collaborator

@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
Collaborator

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".

Björn Schießle
Collaborator

@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
Collaborator

@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
Collaborator

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

SeeTheProgress

+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
Collaborator

@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 Wikinaut reopened this January 02, 2013
Wikinaut
Collaborator

[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."

Wikinaut
Collaborator

[UPDATE] only for information

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

[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
Collaborator

[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
Collaborator

I updated #106 (comment) .

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.

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

Sam Tuke
Collaborator

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.

SeeTheProgress

@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...

Frank Karlitschek
Owner

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 :-)

SeeTheProgress

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

Frank Karlitschek
Owner

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

Wikinaut Wikinaut referenced this issue in toberndo/mailvelope February 26, 2013
Closed

Allow updating of keys #11

Wikinaut Wikinaut referenced this issue in ether/etherpad-lite March 10, 2013
Closed

pad url is leaked whenever a link is clicked #1603

Andreas Wallner

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
Collaborator

[updated 20130426, also in the head posting]
[8] toberndo/mailvelope#45 regarding private key security

Jan-Christoph Borchardt
Collaborator

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
Collaborator

(keep-alive message) Is there any progress ?

Morris Jobke
Collaborator

@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.

Frank Karlitschek
Owner

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.

MrMrsK

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.

MrMrsK

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.