PermaLinkAjax And Crypto: The Obstacles To Public Key Encryption In The Browser
12:29:21 PM

Two days ago, I demonstrated that Ajax is a viable architecture for practical browser-based secret key encryption. I have since gone on to investigate how I might use Ajax for a practical implementation of public key cryptography. Let me start by defining some attributes that I want to see in a practical solution.

  • Convenience Users should only have to enter one piece of secret information per session to access their private key.

  • Transparency Code is open to inspection so that users can be certain that software is not stealing private keys or transmitting plaintext data through hidden channels.

  • Location Independence Users should not have to physically carry their private key with them in order to use a browser on another computer.

  • Platform Independence Users should be able to use Windows, Mac, or Linux, with recent popular browsers.

  • Separation of Custody Private keys, even in encrypted form, are not stored with encrypted data, and vice versa.

Of these five attributes, the first two are very highly desirable. Ajax seems like a good architecture for achieving Convenience because it facilitates retrieving (via HTTP) and caching private key information. The key doesn't have to be re-loaded after each page transition because there are no page transitions. As for Transparency, the "j" in Ajax stands for Javascript, which makes it pretty clear that Ajax fits the bill.

The last attribute, separation of custody, is a good idea but strictly speaking it should not be necessary. Some people do store Notes Id files in the Domino Directory, or on open file shares, relying for security solely on the strength of the pass-phrase required for decrypting the private key. I don't recommend either practice, but that's really only because I don't tend to trust users to keep their pass-phrases secure. And as it turns out, Ajax does not provide any help in facilitating separation of custody. At least not in the way I had envisioned. So, this is an attribute that I think we're going to have to do without.

I should probably explain that last remark. The obvious way to implement Separation of Custody would be to store an X.509 certificate on one http server, and encrypted data on another. The server with the certificates and the server with the data would be managed completely separately. Furthermore, the certificates would be encrypted on the certifcate server, and authentication could be required in order to access it (although requiring authentication does work against Convenience since you would definitely not want the same passphrase used for authentication and for decrypting the certificate!). The problem here is that Ajax, or more specifically the xmlHTTPRequest object, will not allow you to access two servers within one application. In fact, it will only allow you to access the server that the Javascript code that calls it came from. That really doesn't surprise me. I had to test it, just in case, but if it had worked I probably would have been more worried than pleased. Javascript has always had safeguards against code accessing information from a server other than the one that the code was served from. You can't have code in one frame get data from another frame, for example, if the frames' content came from two different servers.

So, now I need to decide how to proceed on the crypto project. Which of the five attributes do I throw out? It's actually not 100% obvious that I have to throw out Separation of Custody. That could still be achieved, but at the expense of Location Independence, if I can find a way to store a the private key locally. Browsers already have a key store built in, actually, so I should rephrase that point. Storing a private key isn't the problem. Reading a local key store from Javascript is the problem. It could be done with either a downloaded signed Java applet, but that throws away Transparency (and unless things have improved in recent years on the "runs anywhere" front, it quite likely throws away Platform Indpendence as well), or some pre-installed ActiveX code (e.g, Windows Scripting Host includes functions that can access the file system) but that throws out Platform Independence.

Another option would be to have the user paste a private key into a field in the browser. This might not really be as bad as it sounds. Yes, Location Independence is gone, but in this case Platform Independence and Transparency could be preserved. Convenience could be maintained by entering the key once into page that contains a script that generates a GreaseMonkey script. The GreaseMonkey script would store the encrypted key, prompts you for the pass-phrase, decrypts the key, and enters it for you. So all you'd have to do is generate the script and add it to your GreaseMonkey configuration. What? You don't have GreaseMonkey? You're not running Firefox? Oops! There goes Platform Independence!

On the other hand, since I already know how to use BlowFish in Javascript for strong pass-phrase based encryption and decryption, losing Separation of Custody by storing the certificates in encrypted form on the same server as the data isn't really that bad an option.

Additional articles in this series...

    Is Ajax The Answer For Crypto In Browser-Based Applications
    Proof of Concept: Browser-Based Field Encryption With Blowfish Via Ajax
    An Improvement To The Classic Ajax Coding Pattern
    A Further Improvement To The Ajax Coding Pattern
    Why Ajax And Crypto Intrigue Me

This page has been accessed 501 times. .
Comments :v

1. Stephan H. Wissel05/15/2005 02:38:50 AM

Hi Richard,
I really enjoy this little series. It opens up good possibilities. I was thinking about the separation of custody. what would happen if you write something like (markup brackets omitted)

script language="JavaScript"
var myPrivateKey = "";
script language="JavaScript" src="URL_to_link_custody_domain" /script
script language="JavaScript" src="URL_to_mainDomain" /script

Would the custody Domain see "myPrivateKey" if it was loaded from maindomain?

In case that doesn't work: The script from the custody domain could alter the dom and put the key into a hidden design element. The Dom should be accessible from all scripts (?)

Of course security needs to be carefully considered since you could view the rendered source (there's a nice FF extension). But I guess that's only similar dangerous as using the JS debugger.

2. Nathan T. Freeman05/16/2005 04:07:25 AM

"You can't have code in one frame get data from another frame, for example, if the frames' content came from two different servers."

Actually, you *can* as long as they're identified as being in same document domain. There's a header tag you need, and the DNS domains have to match.

3. Richard Schwartz05/16/2005 06:11:32 PM

Interesting info, Nathan. I'll look into it. It could mean that if you can trust the DNS provider (possibly yet another party) to keep the data servers and certificate servers separate even though they appear to be in the same domain, then you can have effective separation of custody. Interesting.


4. vesoftware11/05/2013 11:01:04 PM

Agen Bola Promo 100% SBOBET IBCBET Casino Poker Tangkas Online
ITUPOKER.COM AGEN POKER ONLINE INDONESIA TERPERCAYA : Toko belanja online murah, Promo heboh jual barang hanya Rp 1,-

5. cialis09/23/2016 05:57:02 AM
Homepage: , , and forget about it for a couple hours.

6. chenyingying10/17/2016 12:15:06 AM

7. dongdong806/28/2017 11:43:03 PM

Enter Comments^

Email addresses provided are not made available on this site.

You can use UUB Code in your posts.

[b]bold[/b]  [i]italic[/i]  [u]underline[/u]  [s]strikethrough[/s]

URL's will be automatically converted to Links

:-x :cry: :laugh: :-( :cool: :huh: :-) :angry: :-D ;-) :-p :grin: :rolleyes: :-\ :emb: :lips: :-o
bold italic underline Strikethrough

Remember me    

Monthly Archive
Responses Elsewhere

About The Schwartz


All opinions expressed here are my own, and do not represent positions of my employer.