These environments would benefit from cryptographic primitives. Developers of web technology driven applications should be given the tools necessary to safely use crypto.
Web Technology powered applications
By this I mean applications that are written and powered by web technologies but are then packaged to run on other non-browser platform.
It is also possible to write PhoneGap Plugins that can run native device code and this could be used to collect a good pool of entropy.
Most browsers introduced in 2011 a “high quality” entropy collection function: window.crypto.getRandomValues. It is currently implemented in Chrome, Webkit (Safari, iOS) and Firefox has recently received a patch for it.
The worrying thing is that Web Hypertext Application Technology Working Group (WHATWG), a collective effort to gather suggestions for new web standards, says
This document provides no lower-bound on the information theoretic entropy present in cryptographically random values, but implementations should make a best effort to provide as much entropy as practicable.
Saying that implementations should make best effort is not acceptable for secure cryptographic functions. Requirements for randomness must be provided, otherwise the developer is required to research into the specifics of that implementation and provide in some cases disclaimers for certain browsers.
Even RFC4086 provides some guidelines on Randomness Requirements for Security.
This approach would solve the “content-controlled code” issue.
The web application needs to be verified for integrity and authenticity. You can achieve this in various different ways.
The easiest, although not the safest, is to compare the supposed application hash (SHA*) against the advertised hash. This hash can be checked across multiple different sources to be sure to get the correct one.
Another option would be to sign the application code and distribute the application signature. Practically this could be be accomplished with gpg or with x.509.
Both of these approaches are widely used to verify that the application downloaded by the user has not been tampered with and do not differ from standard problems in application distribution.
Eternal Resource Locator
Another interesting approach to validating the content of a particular web page is proposed by Ross Anderson in “The eternal resource locator: an alternative means of establishing trust on the World Wide Web“.
What the paper proposes is to implement new HTML elements that define parts of webpages that are hashed and can be checked for integrity and authenticity:
HASHBODY element denotes the hashed section of an HTML document. All the text and HTML document elements in this section will be hashed with various hashing algorithm specied in the HASH element.
- METHOD= hashalgorithm
- species the hashing algorithm. A number of algorithms may be used in parallel in order to give reassurance against cryptanalytic progress;
VALUE = hashvalue
- specifies the value of the hash;
- provides a pointer to another HTML document, called parent and specied by its URL. This enables a browser that wishes to check the page’s integrity to follow the hash chain to a suitable root. The name of the root may be given for performance reasons. If there is no parent (i.e. the document is a root) the attribute should not be omitted but instead should be set to NO.
URL = uri
- attribute optionally species where the page normally lives, and can provide basic protection against attacks involving the copying of pages to false hosts. Care is needed not to get entangled with pages that have dierent URL, typically http://www.foo.com/ and http://www.foo.com/index.html.
HASH element is an extensible container for use in identifying hash document information. It has three main functions: dene the hashing algorithm used, store the corresponding hash value and link the element to a parent. The HASH element should be used both inside the HASHBODY section and outside; the purpose is to bind the protected section to its hash and its parent. There can be as many HASH elements as hashing algorithms.
“Checking a hash involves computing the hash value on all the bytes of an HTML document between the hash-input border tags and comparing the HTML document’s URL against the value specied within the hash-input. This value is then veried against the value held in the reference in the parent document.”
Agreed that the DOM of our application cannot be modified by the remote backend server we could use localStorage for key storage.
An issue that would arise from using localStorage when opening an .html is that all .html files can read everybody’s localStorage keys. This is because the domain for all files locally loaded files is “localhost”. If the localStorage content for an .html where hashed to a unique domain based on the filename, this problem would be solved.
A workaround could be to load the keys once the application is started from a file. Read it’s content with FileAPI and upon termination prompt the user to save his keys to disk.
PhoneGap also supports localstorage and this issue should not be present since every application is executed in it’s own separate DOM and domain.
Side channel attacks
The WHATWG wiki is probably the first place to go for proposing something like this.
They already have a page talking about window.crypto.* functions, though it is crucial that they set the bar for what is an acceptable implementation of the such functions and what is not.
A very good implementation of a high-level crypto stack that exposes a simple API is NaCl by Daniel J. Bernstein and Tanja Lange.
It’s implementation and features are throughly discussed in their paper “The security impact of a new cryptographic library 3”.
What this library exposes is a minimal API that allows to complete main cryptographic operations.
- crypto_box(DATA, Nonce, PublicKey, SecretKey)
Does all the steps necessary to put data into a cryptographic box and performs public key cryptography.
This is used to generate a Public, Private key pair
- crypto_sign(DATA, SecretKey)
This is used to sign with the SecretKey a set of data
To unscramble signed DATA and retrieve it’s content
To implement these high level functions the authors of NaCl have paid attention to cryptoanalysis. These are their choices:
Specically, NaCl uses elliptic-curve cryptography, not RSA; it uses
an elliptic curve, Curve25519, that has several advanced security features; it uses
Salsa20, not AES (although it does include an AES implementation on the side);
it uses Poly1305, not HMAC; and it uses EdDSA, not ECDSA.
If such a stack were to be implemented, people would not be required to implement imperfect cryptography in pure JavasScript.
The side channel attacks that will emerge from these implementations hopefully will prompts W3C and browser vendors to expose natively written crypto API’s such as NaCl.
- Stanford Crypto Library
Core Library + Mobile Phone GUI
Google Mail integration
- Qooxdoo Crypto
(some of these links are taken from: https://github.com/openpgpjs/openpgpjs/wiki/Introduction)
Also, I am not an expert cryptographer and are still a student. I hope my reasoning does make some sense and any critiques are welcome.
There are plans to implement DOMCrypto into Webkit as well.