PDA

View Full Version : SecureStore and SecureReader. Interest?



deitch
20 Jun 2008, 9:37 AM
Folks,

Referencing the WriteStore extension I posted a while back: http://extjs.com/forum/showthread.php?t=20783 and http://jsorm.com

When I first did this, I began to write a SecureStore, a Store that would retrieve its information from the server as encrypted and decrypt only client-side. This is meant to follow the host-proof hosting or zero-knowledge application that is sometimes promoted. It would include both decryption and encryption, as well as all the write properties of WriteStore.

Is there any interest in it?

jay@moduscreate.com
21 Jun 2008, 6:32 AM
if data is to be encrypted over the wire, why not simply ride https?

deitch
21 Jun 2008, 6:31 PM
Hi Jgarcia,

Definitely, use https. In this case, I am referring to data that is encrypted even on the server, and is only ever decrypted on the client. Client enters encryption/decryption key, data is in the clear only in his/her browser, and is then encrypted before being sent to the server.




if data is to be encrypted over the wire, why not simply ride https?

Eric24
23 Jun 2008, 9:10 AM
Sounds interesting. So I assume for this model to really work, the cipher key would have to be based on something the user typed in (password, passphrase) each time they logged in, which wouldn't be used for server-side authentication, but instead only stored locally in the browser (and thus destroyed when the browser/tab was closed). Is there any other secure way to make this work?

deitch
23 Jun 2008, 11:02 AM
That was the idea. I originally intended to do this as part of write-store. write-store has a mode wherein with every write the entire data set is transmitted. This is very useful if you are storing the data as a flatfile on the server side, i.e. no real journalling going on server-side. The next logical step is that if the data is complete, sometimes the server cannot even decrypt it. I believe the term used is host-proof hosting.

In any case, this got sidetracked, I have less use for it, but with most of the work done, I can bring it back if there is enough interest.


Sounds interesting. So I assume for this model to really work, the cipher key would have to be based on something the user typed in (password, passphrase) each time they logged in, which wouldn't be used for server-side authentication, but instead only stored locally in the browser (and thus destroyed when the browser/tab was closed). Is there any other secure way to make this work?

Yossi
27 Jun 2008, 2:31 AM
sounds like a great idea..!

xantus
30 Aug 2008, 11:02 AM
bump

deitch
30 Aug 2008, 4:58 PM
Hi Xantus,

Why the bump? There has not been exactly overwhelming interest....

deitch

moegal
31 Aug 2008, 5:57 AM
I could use something as well.

Marty

xantus
23 Nov 2008, 7:56 PM
bumping this again

deitch
24 Nov 2008, 9:30 AM
So it looks like there is some interest. I will clean up the code, get an initial launch on its own. After that, I want to find some way to make this part of write-store. In many ways, write-store has become its own database, not just a way to push data back. It includes transactions in detail, data control, etc.

I will post here a link to the http://jsorm.com download when done.

tonedeaf
25 Nov 2008, 2:11 AM
@deitch
I'm a little unclear on the process which you would actually use to make the store secure. Like how the encryption/decryption keys will be generated. And as it'll be written in javascript, how easy / difficult would it be for someone to reverse engineer the decryption keys.

I would be interested in such an extension is it is truly secure. We can also discuss the procedures you would actually use to calculate the encryption / decryption keys before you write the extension, so that we can brainstorm the best method.

deitch
25 Nov 2008, 6:31 PM
I agree wholeheartedly. Like any good encryption, it needs to be transparent, with the key the only secret. If I log onto my online bank, it uses SSL. Everyone knows SSL, but without the session key, they cannot decrypt my data or perform man-in-the-middle attacks.

It is a pity that OpenSSL is C only. It is so solid and reliable, and has all the encryption algorithms in it, that I would love to use it as a base, knowing I could trust it.

The problem with any JavaScript-based encryption is that you must still trust the server. Sure, it has (theoretically) uncrackable data (encrypted by Blowfish or Twofish or Rijndael/AES or ... ), but since the script itself is served up by the server to the browser, a corrupt server could serve up code that leaks the data or the key, rather than protecting it.

Since there is interest here, here are my thoughts:
1) You have a store and a reader, like any other store.
2) The reader is a regular reader (XML, JSON, whatever) wrapped around a decrypter.
3) When the data is received by the proxy, it is passed to the decrypter, which decrypts the data into plaintext, then passes it on to the reader, which converts it into records and hands it to the Ext.data.Store.

Thus, for the whole thing to work, you need a decrypter in between the proxy and the reader. Or, in other words, you have two "readers" chained along. (This sounds a lot like filter chaining in Java servlet engines.) The first reader decrypts to plain text which the second reader can decode to records.

The first reader would be configured with the reader to pass information to, the key, and the encryption algorithm. The trick to this is to ensure that the encryption algorithm is not homegrown, but rather use a trusted existing implementation, if it exists. I usually rely on BouncyCastle for Java and OpenSSL for C or command-line, but that is obviously not an option here.

Initially, I would only do symmetric encryption. The computing demands of asymmetric / public-key are far greater, and should probably not be handled in JavaScript on a browser quite yet.


@deitch
I'm a little unclear on the process which you would actually use to make the store secure. Like how the encryption/decryption keys will be generated. And as it'll be written in javascript, how easy / difficult would it be for someone to reverse engineer the decryption keys.

I would be interested in such an extension is it is truly secure. We can also discuss the procedures you would actually use to calculate the encryption / decryption keys before you write the extension, so that we can brainstorm the best method.

tonedeaf
27 Nov 2008, 11:31 AM
The first reader would be configured with the reader to pass information to, the key, and the encryption algorithm.
If I understand correctly, we instantiate this reader with a decryption key using javascript code and even if the decryption key is linked to dynamic "salt" like user password, its still easy to find out the key using a javascript debugger.

So, what is the application for a secure store? Useful only in cases where you need a host-proof solution?

Also, what methods can we use for generating the encryption/decryption key, so that a hosting provider who has access to your data still cannot figure it out?

deitch
27 Nov 2008, 5:41 PM
If I understand correctly, we instantiate this reader with a decryption key using javascript code and even if the decryption key is linked to dynamic "salt" like user password, its still easy to find out the key using a javascript debugger.

Yes, correct. Any cryptography always assumes that the platform on which the actual encryption/decryption is done is secure. That is the same weakness for a JavaScript debugger on Firefox/IE/Safari/Opera/... as it is a binary debugger on a C program on Windows or Java debugger on anywhere or etc. I agree wholeheartedly that this is a very big assumption. However, it is one we make every day. It would be no less secure than just about everything we do nowadays.


So, what is the application for a secure store? Useful only in cases where you need a host-proof solution?

I would think so, yes. Admittedly, you have a weakness in that the same host is serving up the JavaScript code, so it is easy to circumvent. Let's open it up to discussion: what is it people want to use this for?



Also, what methods can we use for generating the encryption/decryption key, so that a hosting provider who has access to your data still cannot figure it out?

Every algorithm we want to use would have to be included, unless the browser somehow gave us access to the algorithms it already uses for SSL from within JavaScript (unlikely). My recommendations would be:

Start simply with a simple symmetric algorithm
Use the standard for password-based encryption PBKDF, which is PKCS #12, I believe