RSS Feed

Category Archives: globaleaks

How to improve JavaScript cryptography

Posted on

The point of this post is not to solve every problem but rather to move towards a safer environment where JavaScript is a first class language that is able to have the same set of problems as every other first class language (eg: C, Java, C++, etc).

There has been a lot of discussion, lately, about wether or not JavaScript should ever be used for cryptography. Some have strongly argued that it is a terrible idea, while others have started working on projects to make it possible. They’re both right in some cases.

With the development of browsers and the adoption of web technologies, even outside of browsers, I believe the idea of JavaScript crypto should not be prematurely discarded as the Matasano Security article does. Statements such as “JavaScript crypto isn’t a serious research area” is very bad for the advancement of security. In the context of web browsers as it stands today, Matasano is correct. However, we know that we can improve things and we must consider that there are two actual core issues – the first is the application and the second is the language and core libraries. The former will almost always follow the latter. We must improve the language and core libraries before we can expect that Matasano’s comments will no longer be relevant.

Why JavaScript cryptography is important

Web technologies are becoming more and more used, not only applied to browsers. PhoneGap and AppCelerator allow you to write HTML5 and JavaScript applications that are then built to run inside as native mobile applications.

These environments would benefit from cryptographic primitives. Developers of web technology driven applications should be given the tools necessary to safely use crypto.

Raising awareness of the importance of cryptography in the HTML5/JavaScript environment may prompt writers of standards to introduce a secure implementation of it into the standards of tomorrow.

I will now illustrate the cases in which JavaScript cryptography makes sense, what problems can be solved today and the steps necessary for solving the remaining problems tomorrow.

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 the case of PhoneGap where programmer will write a HTML5/JavaScript application that is then built, based on webkit, to become a native iOS, Android, Blackberry or Symbian app. What would make sense is to write the application in a way that all the necessary DOM and JavaScript is already loaded and stored inside the application. All the network communication that is made should not alter the DOM.

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.

In the case of appcelerator the programmer still writes HTML5/JavaScript, but the application for mobile device that comes out is written in the code native to the target device. You therefore don’t suffer the issues that would rise from a standard Webkit, not having DOM to interact with.

window.crypto.getRandomValues

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.

DOM manipulation

One of the arguments raised by Matasano is that it is impossible to create secure cryptography inside of a browser because you depend on “content-controlled code”. What they mean by content controlled code is that certain elements that are fetched to build a webpage may contain executable JavaScript code.

An idea that came to mind when rethinking the design of GlobaLeaks is to have the web application preloaded from a secure location (installed as a browser plugin or downloaded  and run from file system). The only requests that are made to the remote web server are REST requests that are used by the preloaded JavaScript code to build DOM elements and such. You will never be running any code from the remote site, just building the elements from the JSON response using the pre-loaded application logic.

This approach would solve the “content-controlled code” issue.

We are therefore moving most of the web application logic into the client written in Javascript, interacting with servers only for the application data like Unhosted project does.

Thanks to CORS (Cross-Origin Resource Sharing) it’s possible to do cross-domain ajax. A javascript application can run in the context of a browser being loaded locally (just saving a self-contained .html file) or from a web page.

If the server just handles backend REST services, thus without interfering with the Javascript Application, it has no way of subverting the application data logic.

Application verification

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:

The HASHBODY element

The 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 speci ed in the HASH element.

The HASH element
Attribute definitions:

METHOD= hashalgorithm
speci es the hashing algorithm. A number of algorithms may be used in parallel in order to give reassurance against cryptanalytic progress;

VALUE = hashvalue

specifi es the value of the hash;

PARENT= uri

provides a pointer to another HTML document, called parent and speci ed 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 speci es 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 di erent URL, typically http://www.foo.com/ and http://www.foo.com/index.html.

The HASH element is an extensible container for use in identifying hash document information. It has three main functions: de ne 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 speci ed within the hash-input. This value is then veri ed against the value held in the reference in the parent document.”

Key storage

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

Side channel attacks cannot be fully prevented until we have a full cryptographic stack build into HTML/JavaScript. This required cooperation from W3C to integrate in the specification a full proposal for the window.crypto API.

A variety of papers on the matter of timing side channels attacks exist.

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.
  • crypto_sign_keypair()
    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
  • crypto_sign_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:

Speci cally, 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.

While it is true that we cannot fully prevent side channel attacks in native JS implementations I still believe it is of use to implement crypto in JavaScript.

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.

Who is working on JavaScript Cryptography

(some of these links are taken from: https://github.com/openpgpjs/openpgpjs/wiki/Introduction)

Plugins

If we assume that we have a plugin that is written in JavaScript, we can also assume that the code injection issues are out of scope. Obviously this is an implementation issue but this assumption is the same for nearly all other plugin systems. If the core language and core libraries do not support things in the ideal case, it’s extremely unlikely that it will ever work in any case.

Conclusions

JavaScript cryptography allows us to build secure cross-platform multi-device applications that aren’t necessarily delivered as standard web applications. Weither you like it or not web technologies are here to stay, we should start working on

If I haven’t convinced you that JavaScript crypto is not a bad idea, I hope to have least managed to spark your curiosity in the topic and make you think twice before disregarding JavaScript as an insecure technology.

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.

You can find me on twitter on twitter as @hellais and to comment on this topic we should use the hashtag #JSCrypto.

Updates

28-12-2011:

@sideshowbarker mentioned on twitter of the existence of DOMCrypt. This is indeed an interesting project towards specifying a high level crypto API for Mozilla.

There are plans to implement DOMCrypto into Webkit as well.

Advertisements

GlobaLeaks participation to the 39° Congress of The Nonviolent Radical Party, Transnational e Transparty

Posted on

GlobaLeaks will be present at the 39° Congress of The Nonviolent Radical Party, Transnational e Transparty.

Here is the statement:

GlobaLeaks: Transparency & Public disclosure at their best

GlobaLeaks strives to increase accountability and transparency in our society. When information that affects the public remains hidden, democracy and economies cease to function properly.

When the government is not transparent and accountable for their actions, public should obtain it autonomously. Thanks to anonymity technologies it is possible to create a distributed network of sites that enforce transparency and openness at any level.

It is called “GlobaLeaks”.

What is GlobaLeaks?

GlobaLeaks is the first open-source whistleblowing framework. It empowers anyone to easily set up and maintain a whistleblowing platform. GlobaLeaks can help many different types of users: media organizations, activist groups, corporations and public agencies.

Possible use cases of GlobaLeaks

Transparency Activism

Non-governmental and informal activist organizations can set up independent whistleblowing sites to uncover corruption or other problems locally, or within specific industries.
This can be true even when the issues might not get attention nationally or among the mainstream.
Anonymity backed by technological security can help such organizations even in places where organized crime is dominant or human rights are not guaranteed.
Collaboration with citizen journalism initiatives, blogger and social networks permit political and activism organization to leverage the power of public disclosure to increase transparency and bring to citizens relevant information about hidden malpractice in their society.

Media

Media outlets, including newspapers, websites, magazines and non-profit journalism associations, can set up a GlobalLeaks interface to collect anonymous reports from sources that will be protected by default. Some media organizations already have deployed whistleblowing sites to accept “leaks” that can inform their investigative journalism, but it is difficult for journalistic organizations to maintain the technology necessary for security and privacy. GlobaLeaks can provide an open-source alternative that could be used by any of these organizations and others. Several media organizations already are seriously considering the use of GlobaLeaks.

Public Agencies

Public agencies can use GlobaLeaks to involve citizens in spotting tax evasion, corruption, market manipulation and other problems. Famous public whistleblowing services already exist and include those in the U.S IRS, U.S. SEC, and the EU Antitrust. GlobaLeaks can help protect those citizens who want to help investigators.

Learn more:

http://www.globaleaks.org/
https://github.com/globaleaks
https://twitter.com/globaleaks
http://planet.globaleaks.org/
https://github.com/globaleaks/advocacy

GlobaLeaks Hackathon 0×02

But standing in water up to their knees three very unimportant little people where doing the best they could with an idea and that’s about all they had and I don’t know maybe that night these three people were making history but anyway what I’m telling to tell you folks here we are.

In Milan last week the second GlobaLeaks hackathon reached it’s conclusion. Overall it has been a very productive week and I wish to tell you what we accomplished and what the next steps will be.

The first major news bulletin is that we have three new Random GlobaLeaks Developers: fox, maker and mpodroid. Fox and maker are two awesome python hackers, I had lots of fun coding with them until late in the morning. Marco Pozzato (mpodroid) is a true Java Ninja and he coded the Android application for GlobaLeaks in one 1h train trip.

What have we accomplished

Before the hackathon GlobaLeaks was just the demo of a prototype, no real world functionality was introduced. Let’s go through the features we have implemented:

To get a better view of what we have hacked on in the past days take a look at the commit history between the 23rd and the 25th of September.

There is still lot’s of work to do

GlobaLeaks is now much closer to the goal of having an Open Source easy to use Whistleblowing platform, but we are not quite there yet. This is why we need you to join us and start hacking on it. It does not matter from what background you are from, be it syadmin, coder, legal or writing. The beauty of GlobaLeaks is that it brings together people from an array of different backgrounds. The greatness of GlobaLeaks is it’s diversity.

We have defined three milestones:

You can look at their page to see the attached issues and was needs to be done to get the software to that point. By the end of October we will be shipping GlobaLeaks 0.1. No need to tell you how excited we are about this.

I think this concludes the summary, for more information go and take a look at GlobaLeaks github page.

Join us on IRC: #GlobaLeaks irc.oftc.net
Follow us on twitter: @GlobaLeaks

Keep on hacking in the free world!

A Random GlobaLeaks Developer