InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Multiparty Verified Code Execution on Modern Browsers

IP.com Disclosure Number: IPCOM000239207D
Original Publication Date: 2014-Oct-20
Included in the Prior Art Database: 2014-Oct-20
Document File: 6 page(s) / 70K

Publishing Venue

Linux Defenders

Related People

Pablo Guerrero: AUTHOR


A process that allows a user to securely execute a web application without trusting a single server. This opens the possibility to safe web client cryptography without extensions. It uses bookmarks as intermediate storage for the code, that it’s verified using additional independent servers. It also makes use of the locally generated HTML error pages as a clean environment to execute the verified code. Finally, it’s extended to support multiple applications, user preferences, and secure password-based private data.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 20% of the total text.

Page 01 of 6

Multiparty Verified Code Execution On Modern Browsers

Pablo Guerrero - siriux@gmail.com - http://greenentropy.com - October 2014

Motivation and previous work

The idea of verifying the code that is executed on the browser has been discussed for a long time. It's important, because it could open the door to implementing secure client applications that doesn't need to trust any single server, while keeping the benefits of the modern web.

The problem is that javascript (JS) and the web are considered insecure environments to implement cryptography for different reasons. A good review on the potential security risks can be found at http://matasano.com/articles/javascript-cryptography/.

The typical way this problem is solved is by installing a browser extension that is able to verify signed pages before running them using the public key of a trusted source. This has the problem of installing the browser extension, which is inconvenient in the best case, or impossible in some systems or devices that are not under the user control (enterprise computers, mobile devices and tablets, public computers, ...).

A similar scenario are the browser specific apps, that are also signed and delivered by the browser creators.

An ideal solution would involve verification of the code using multiple independent servers to avoid a single point of trust. It's also important that it's simple to use by any user, and that it can run on any modern desktop and mobile browser without installing an extension. At the same time, it has to solve the potential risks of JS described in the previous link.

Simplifying the problem

Some of the criticism for JS comes from the malleability of the language and the lack of primitives needed for cryptography, but this is no longer true. All modern browsers (including IE11) have access to window.crypto.getRandomValues that is the most basic primitive needed for cryptography.

Also, there are well written and tested JS crypto libraries for the most common algorithms. And, if you don't trust them, it's possible to use trusted implementations written in C/C++ using Emscripten.

The malleability of the language problem can be reduced to a much simple problem. Right now it's a standard practice to render web pages directly on the client using only JS. This can be easily done in such a way that the data for rendering cannot secretly execute JS from the DOM side.

Page 02 of 6

At the same time, standard technologies such as AJAX, CORS, data URLs, ... allow to load extra assets as plain text before they are used in the page. This can be used to verify the assets by simple inspection or using previously computed hashes that are directly stored on the JS code. This can be automated and standardized by libraries.

These methods allow us to reduce the problem to a much simple one. If you are able to execute some verified JS code on a clean environment (known JS and DOM state), using the previous standard techniques you can be sure that the JS...