Web Cryptography API posted as W3C working draft

http://www.w3.org/TR/WebCryptoAPI/

by sweis • 14 years ago

64 46 14 years ago

zrail• 14 years ago

This looks like it could be pretty useful. The main argument against crypto in the browser is that if you send crypto js over a non encrypted channel it's vulnerable to MITM, and if you're going over HTTPS you might as well just send it plaintext. If the browsers themselves implemented secure crypto it could be a boon to certain types of applications, for example S/MIME in webmail.

daeken7• 14 years ago

I don't see this adequately defending against MITMs or XSS. You can still hook all the crypto primitives, inject new keys, or pull out existing keys from the same origin.

This scares me; a lot of people are going to assume this is secure against attacks that it simply isn't there to defend against.

jlgreco2• 14 years ago

I could see this being useful/safe iff the browser refuses to allow it to be used unless everything is already using HTTPS.

morroccomole2• 14 years ago

Indeed, browser also implement things like CSP - and we need browser to also support additional security measures that enhance the API

daeken7• 14 years ago

While I think this could be a good thing in theory, exposing such a low level crypto interface is likely to end in pain. How many people can combine the building blocks into something secure? And MITM/XSS still give up the keys to the castle.

I'd much rather see a simple high-level interface to crypto in the browser.

emily37• 14 years ago

The plan is to first nail down this low-level API, and then specify a high-level interface wrapping the low-level one that makes it much easier for most developers to get things right.

http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug...

daeken7• 14 years ago

I don't think that's enough -- in fact, I think it's worse. The low level API inherently has a broken trust model, and using that as a stopgap is going to be worse for security than it not existing at all. If anything, the low level API should be tabled in favor of the high level.

tptacek12• 14 years ago

I see talk in those threads about how the "low-level API" is logistically the right move, but not a lot of talk about how it's right in an engineering sense. Is it possible that the cart is pulling the horse here?

rbellio• 14 years ago

Something else to read in my free time now :)

tptacek12• 14 years ago

From the two quick reads I've given it, not a fan.

On the plus side: building this stuff directly into the browser image may prevent people from deploying Javascript Cryptography, which is unsafe in every environment. Systems built on the Web Cryptography bindings are at least anchored to trusted implementations of algorithms already resident in the browser.

On the minus side:

* These interfaces may have the opposite effect. Mass-market websites must support all popular browser versions. For the foreseeable future, we won't have a market in which the majority of browsers implement something like this. Unfortunately, the web crypto API is something that is very easy to duplicated "cosmetically" in Javascript. So the net effect of this in the medium term is probably negative. That said, I also understand that we've got to rip off the band-aid sometime.

* The interface is low-level. I appreciate that an API like this naturally wants to be low-level, to maximize the number of things you can build on top of it. But most of the things you could build on these particular building blocks will have subtle vulnerabilities. Not only that, but the interface doesn't appear to provide even the "envelope" abstraction that other low-level libraries present.

* So much of this design is low-level that enough of the security of the system is left to content-controlled Javascript, so many (perhaps most) of the systems that rely on this library are going to have exactly the same problem as they do now.

* The low-level building blocks they provide are incoherent. If you wanted to just expose all the little knobs and wires that it could take to implement pre-existing (and broken) crypto standards, then an interface which pretends that AES-CBC and AES-GCM are two different ways to do the same thing makes some sense; some systems need GCM, and some need CBC, and you don't have to give much thought to the difference. But this library doesn't even do that; for instance, it doesn't look like callers control the nonce in AES-CTR. A good way to sum this up: if this API succeeds in the market, there are going to be deployed, widely used systems that use RSA for bulk encryption.

If I was elected Archduke of Browser Crypto, the first standard I would propose would be a simple authenticated AES-encrypted envelope format; something like, PBKFD2-keyed HMAC-SHA256-authenticated AES-CBC messages. Something impossible to screw up, because Javascript authors aren't asked to make design decisions.

daeken7• 14 years ago

Totally agreed on every level. If you want to add security, you do it from the high level; exposing low-level building blocks is a recipe for disaster.

briansmith6• 14 years ago

I believe you are suggesting that we make a more foolproof API like keyczar. The original idea of DOMCrypt was along those lines as well. I don't think we will be able to avoid specifying and shipping the low-level API at this point. It would be nice to define such a foolproof API on top of the low-level API, prototype it with a JS implementation, get feedback on how useful it is (i.e. whether it is too limited for the use cases people have), and then push browser makers to provide this safer API natively. I think the main concern with a keyczar-like API is that we won't be able to create one that significant numbers of websites would actually use.

tptacek12• 14 years ago

Can I ask what the point of enabling websites to create vulnerable cryptosystems is? I don't mean that snarkily and I'm not trying to make a point. What are the applications that would not be possible with a high-level "envelope" interface that are key use cases for the Web Crypto API?

daeken7• 14 years ago

> I think the main concern with a keyczar-like API is that we won't be able to create one that significant numbers of websites would actually use.

I'm personally much more concerned about websites using an API with significant faults than fewer websites using a solid API. The fact that an MITM or XSS can completely undermine this makes it equivalent (outside of the secure RNG -- a definite good thing) of doing all your crypto in JS. As long as the server controls how the building blocks are put together, what keys are used and when, etc, the trust model is broken.

romaniv2• 14 years ago

I think the main concern with a keyczar-like API is that we won't be able to create one that significant numbers of websites would actually use.

Why not try to create one that significant number of users will use? Stuff like automatic verification of files using a hash or signing and verifying GPG signatures on web-based message boards would be tremendously useful and don't require much support on the website side.

X-Istence• 14 years ago

We've discussed much of this before on HN, and I am slowly but surely starting to see exactly what you mean. Getting everything in crypto just right is a hard problem, especially with the disparity between different crypto providers and how it should be implemented to be secure.

The biggest issue I have is that unless low level primitives are available it is hard to work together with various other libraries/standards. Getting Java and OpenSSL based crypto to play nice is already harder than it should be, I can't imagine what a mess it would be to try to make it work with yet another standard. And at the same time if those low-level primitives are available people are going to use them instead of the higher-level functions because they have certain specific requirements.

---

Any specific reason as to why AES-CBC? If seeking is required wouldn't AES-CTR be a better choice? Or are you making assumptions that the payload size is small enough that decryption of the whole object is feasible?

tptacek12• 14 years ago

Seeking is a great example of something that you would think you'd want in a crypto API that has pitfalls when you implement it in a real cryptosystem. And it looks to me like this proposal wants to support seeking, and doesn't account for those pitfalls.

And I think you're right: I think the interface proposed here is idiosyncratic enough that it will be difficult to make it interoperable, but that idiosyncrasy doesn't buy any additional security.

ctz• 14 years ago

> Any specific reason as to why AES-CBC? If seeking is required wouldn't AES-CTR be a better choice? Or are you making assumptions that the payload size is small enough that decryption of the whole object is feasible?

Choosing nonces is hard. For a given key, nonce reuse with AES-CBC fails leaking plaintext equality of the first blocks of the two messages. This is bad. AES-CTR usually fails by leaking the entire two plaintexts. This is catastrophic.

Cobbling together AEAD schemes out of AES-unauthenticated-anything and HMAC-anything is a poor idea, and unnecessary. AES-GCM and AES-CCM are here, standard and performant. Use them.

prodigal_erik• 14 years ago

I'd like to see a declarative way to sign or encrypt parts of a document or form submission to protect them from tampering by the origin server. But js is under the control of the origin server, so I don't see this as a security advance over TLS, just a crutch for broken apps with no non-js mode using HTTP correctly.

tptacek12• 14 years ago

Minimizing the number of trusted components that are under the control of Javascript is part of the point of the interface, but as Cody and I have pointed out (and obviously you as well), there's enough left to JS that the interface doesn't really solve that problem.

One thing I would probably do as Archduke, after ordering a 70% tax on cupcakes, is have the bindings only work on HTTPS connections.

daeken7• 14 years ago

> One thing I would probably do as Archduke, after ordering a 70% tax on cupcakes, is have the bindings only work on HTTPS connections.

I support the cupcake tax (we can discuss numbers later), but I think making it work only for HTTPS connections makes that seem like the biggest issue. I believe that XSS attacks, simply due to the ease of discovery and exploitation, are a much bigger issue here. Hijacking connections to a site (whether via MITM, DNS redirection, whatever) isn't easy, but XSS is downright trivial in most cases; it's definitely the biggest concern in my mind.

briansmith6• 14 years ago

> One thing I would probably do as Archduke, after ordering a 70% tax on cupcakes, is have the bindings only work on HTTPS connections.

I am very interested in this idea, not only regarding this API, but also regarding camera/microphone APIs, where a MITM could cause all kinds of severe privacy issues. I know the idea has been discussed specifically in the context of WebRTC (can an active attacker inject JS into a page to turn on your camera & microphone and the feeds back to them?), but it seems like it may have already been shot down there.

romaniv2• 14 years ago

I would very much rather see higher-level crypto, especially crypto that could be used declaratively, without JavaScript. (Something similar to Enigmail, but for browsers.)

Heck, there isn't even a standard way to verify a hash on downloaded files.

darkhorn• 14 years ago

By the way keygen http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_k...

kzahel• 14 years ago

Yes, we all know cryptography is incredibly easy to get wrong.

That doesn't mean providing the primitives to implement bad crypto is responsible for the bad crypto.

I think the main benefit of this will be improved speed over existing standard javascript crypto support libraries (sjcl, jsbn).

daeken7• 14 years ago

> That doesn't mean providing the primitives to implement bad crypto is responsible for the bad crypto.

In this case, it absolutely does. Not only will people most likely put them together incorrectly (which isn't the API's fault), but it doesn't provide any defense against cases where the browser is running code not intended by the server, e.g. MITM and XSS. As soon as the browser is running bad code, this is 99.9% equivalent to existing JS crypto (the exception being the secure RNG). The trust model here just doesn't hold up.

sleevi4• 14 years ago

While the trust issue you raise is legitimate, it's not one we're trying to solve (or at least, not yet, and I hope not soon)

You may ask then, "Well, what's the point of this API if you're not going to solve it?"

The answer is that solution for the trust model issues are being addressed concurrently and, unquestionably, more adequately, in other W3C working groups, the WHATWG, the IETF, and other such standards bodies. For example, the development of Content Security Policy, the hopeful formation of the Sys Apps WG, offline apps that execute in their own origin, the proposed <browser> tag, the formalization of the things as basic as the web origin concept (RFC 6454), Web Intents as a service-agnostic IPC mechanism. There are a number of efforts going on to address and enhance the overall security and utility of the platform. Our WG is providing just one small part of the overall picture.

Every concern about malleability of the run-time applies equally so when you're not doing JS crypto - native or browser-mediated. Storing something in localStorage/IndexedDB? Well, now you've got an opportunity to turn transient XSS into persistent, stored XSS. Does that mean localStorage/IndexedDB are doomed to failure or fundamentally flawed for not addressing that? No. Are cookies complete and utter garbage due to all of their known issues? No (or at least, not /complete/ ;-)

I recognize that there are a variety of security decisions and trade-offs being presented in this API, decisions that will have to be made by site authors. It may be that this is completely unacceptable - and I would hope, by now, that people feeling that way would be sending mail to public-webcrypto-comments@w3.org saying that. However, for the use cases that have been presented and expressed, the trade-offs have been understood and are, thus far, acceptable, which is why this WG has continued the path its on and why the participants have, so far, believed in the utility of the API.

As far as algorithms go, our failure (thus far) to include DSA is hardly going to be the end of SSH (for which many still use DSA keys), just like our failure (thus far) to include ElGamal or MD5 are not going to mean the death of PGP/GPG. However, by not including them, it also means that there's no way to implement such applications, even if all other concerns were controlled for - and that would suggest our API is incomplete and a less-compelling alternative. Suggesting that failing to implement PKCS#1 v1.5 will finally mean the end of it is unrealistic.

So far, our stated goal has been to produce a low-level API that has applicability for a number of situations, as captured both in the use cases of the draft and in the companion use cases wiki. The core functionality starts with "Secure key store. Secure RNG". In order to support "secure key store," it's necessary to define what you can do with these "secure" keys, hence, the specification of certain operations and algorithms.

We're not (thus far) attempting to create an enveloping format - that's something that the IETF JOSE WG is doing, and that various groups and standards ranging from XML DSig to CMS to S/MIME have done or tried to do.

We're not (thus far) attempting to create the one-true-perfectly-safe-full-of-cryptographic-kittens-and-puppies "box" and "unbox" - it's interesting, unquestionably useful, but getting two crypto-geeks, let alone a hundred, to agree on what that operation is composed of is a sisyphean effort. Should it be Sals20 or AES-GCM? Why not Blowfish? Monkey knife-fighting appears more civilized then some of those crypto-political discussions - and makes more progress to boot.

By providing the low-level API, application developers can make an informed decision on what that "box" looks like to them, or relying on cryptographically skilled developers to produce libraries (ala KeyCzar, ala NaCl) to do that for them. Yes, it also means that uninformed developers can start smashing things together and leading to wonderfully painful crypto-explosions. However, you don't see WebGL being lamented for its lack of built-in VRML support (I hope...), and neither do I think this API should include the kitchen sink, bathtub, robe, and matching slippers in order to be useful and applicable for many web developers.

Yes, screwdrivers are wonderfully useful tools, and it's fairly hard to hurt yourself with one. But sometimes you really need a hammer - or a chainsaw, or a level, or a drill - in order to do the right job. This API is merely a toolbox - dangers and all - not the One True Solution to all the Bad Crypto.

morroccomole2• 14 years ago

For the record this is only the First Public Working Draft. A lot can and will change. We are looking for commentary to understand if we are on the right track

wglb• 14 years ago

So is this "Bad Crypto made Easy"?

Web Cryptography API posted as W3C working draft

Related Stories