Why does browser cryptography matter?
What are some examples of "doomed" browser cryptography?
Or, you have a different application, where users edit private notes stored on a server. You'd like to offer your users the feature of knowing that their notes can't be read by the server. So you generate an AES key for each note, send it to the user's browser to store locally, forget the key, and let the user wrap and unwrap their data.
What's wrong with these examples?
They will both fail to secure users.
For several reasons, including the following:
If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code. The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.
That attack sounds complicated! Surely, you're better off with crypto than without it?
There are three misconceptions embedded in that common objection, all of them grave.
First, although the "hijack the crypto code to steal secrets" attack sounds complicated, it is in fact simple. Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request. Intercepting requests does not require advanced computer science. Once an attacker controls the web requests, the work needed to fatally wound crypto code is trivial: the attacker need only inject another <SCRIPT> tag to steal secrets before they're encrypted.
Finally, the security value of a crypto measure that fails can easily fall below zero. The most obvious way that can happen is for impressive-sounding crypto terminology to convey a false sense of security. But there are worse ways; for instance, flaws in login crypto can allow attackers to log in without ever knowing a user's password, or can disclose one user's documents to another user.
How are browsers hostile to cryptography?
In a dispriting variety of ways, among them:
The prevalence of content-controlled code.
The lack of systems programming primitives needed to implement crypto.
The crushing weight of the installed base of users.
Each of these issues creates security gaps that are fatal to secure crypto. Attackers will exploit them to defeat systems that should otherwise be secure. There may be no way to address them without fixing browsers.
What do you mean by "content-controlled code"? Why is it a problem?
Ok, then I'll just serve a cryptographic digest of my code from the same server so the code can verify itself.
This won't work.
What's a "malleable runtime"? Why are they bad?
You could. It's harder than it sounds, because you'd have to verify the entire runtime, including anything the DOM could contribute to it, but it is theoretically possible. But why would you ever do that? If you can write a runtime verifier extension, you can also do your crypto in the extension, and it'll be far safer and better.
"But", you're about to say, "I want my crypto to be flexible! I only want the bare minimum functionality in the extension!" This is a bad thing to want, because ninety-nine and five-more-nines percent of the crypto needed by web applications would be entirely served by a simple, well-specified cryptosystem: PGP.
The PGP cryptosystem is approaching two decades of continuous study. Just as all programs evolve towards a point where they can read email, and all languages contain a poorly-specified and buggy implementation of Lisp, most crypto code is at heart an inferior version of PGP. PGP sounds complicated, but there is no reason a browser-engine implementation would need to be (for instance, the web doesn't need all the keyring management, the "web of trust", or the key servers). At the same time, much of what makes PGP seem unwieldy is actually defending against specific, dangerous attacks.
You want my browser to have my PGP key?
Definitely not. It'd be nice if your browser could generate, store, and use its own PGP keys though.
Here's a starting point: a secure random number generator.
How big a deal is the random number generator?
Virtually all cryptography depends on secure random number generators (crypto people call them CSPRNGs). In most schemes, the crypto keys themselves come from a CSPRNG. If your PRNG isn't CS, your scheme is no longer cryptographically secure; it is only as secure as the random number generator.
But how easy is it to attack an insecure random generator, really?
It's actually hard to say, because in real cryptosystems, bad RNGs are a "hair on fire" problem solved by providing a real RNG. Some RNG schemes are pencil-and-paper solveable; others are "crackable", like an old DES crypt(3) password. It depends on the degree of badness you're willing to accept. But: no SSL system would accept any degree of RNG badness.
But I can get random numbers over the Internet and use them for my crypto!
I'll use RANDOM.ORG. They support SSL.
Imagine a system that involved your browser encrypting something, but filing away a copy of the plaintext and the key material with an unrelated third party on the Internet just for safekeeping. That's what this solution amounts to. You can't outsource random number generation in a cryptosystem; doing so outsources the security of the system.
But other languages have the same problem!
But people rely on crypto in languages like Ruby and Java today. Are they doomed, too?
Some of them are; crypto is perilous.
If Python was the standard browser content programming language, browser Python crypto would also be doomed.
A secure keystore.
A way to generate and store private keys that doesn't depend on an external trust anchor.
External what now?
Wait, can't I generate a key and use it to secure things in HTML5 local storage? What's wrong with that?
That scheme is, at best, only as secure as the server that fed you the code you used to secure the key. You might as well just store the key on that server and ask for it later. For that matter, store your documents there, and keep the moving parts out of the browser.
These don't seem like earth-shattering problems. We're so close to having what we need in browsers, why not get to work on it?
Check back in 10 years when the majority of people aren't running browsers from 2008.
That's the same thing people say about web standards.
Compare downsides: using Arial as your typeface when you really wanted FF Meta, or coughing up a private key for a crypto operation.
We're not being entirely glib. Web standards advocates care about graceful degradation, the idea that a page should at least be legible even if the browser doesn't understand some advanced tag or CSS declaration.
"Graceful degradation" in cryptography would imply that the server could reliably identify which clients it could safely communicate with, and fall back to some acceptable substitute in cases where it couldn't. The former problem is unsolved even in the academic literature. The latter recalls the chicken-egg problem of web crypto: if you have an acceptable lowest-common-denominator solution, use that instead.
This is what you meant when you referred to the "crushing burden of the installed base"?
And when you said "view-source transparency was illusory"?
Nobody verifies the software they download before they run it. How could this be worse?
Nobody installs hundreds of applications every day. Nobody re-installs each application every time they run it. But that's what people are doing, without even realizing it, with web apps.
This is a big deal: it means attackers have many hundreds of opportunities to break web app crypto, where they might only have one or two opportunities to break a native application.
But people give their credit cards to hundreds of random people insecurely.
An attacker can exploit a flaw in a web app across tens or hundreds of thousands of users at one stroke. They can't get a hundred thousand credit card numbers on the street.
You're just not going to give an inch on this, are you?
Nobody would accept any of the problems we're dredging up here in a real cryptosystem. If SSL/TLS or PGP had just a few of these problems, it would be front-page news in the trade press.
How much research do we really need? We'll just use AES and SHA256. Nobody's talking about inventing new cryptosystems.
AES is to "secure cryptosystems" what uranium oxide pellets are to "a working nuclear reactor". Ever read the story of the radioactive boy scout? He bought an old clock with painted with radium and found a vial of radium paint inside. Using that and a strip of beryllium swiped from his high school chemistry lab, he built a radium gun that irradiated pitchblende. He was on his way to building a "working breeder reactor" before moon-suited EPA officials shut him down and turned his neighborhood into a Superfund site.
The risks in building cryptography directly out of AES and SHA routines are comparable. It is capital-H Hard to construct safe cryptosystems out of raw algorithms, which is why you generally want to use high-level constructs like PGP instead of low-level ones.
What about things like SJCL, the Stanford crypto library?
SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document.
These may be real problems, but we're talking about making crypto available to everyone on the Internet. The rewards outweigh the risks!
DETROIT --- A man who became the subject of a book called "The Radioactive Boy Scout" after trying to build a nuclear reactor in a shed as a teenager has been charged with stealing 16 smoke detectors. Police say it was a possible effort to experiment with radioactive materials.