--- a/Overview.html Mon Jan 07 17:48:08 2013 -0500
+++ b/Overview.html Wed Apr 10 17:01:44 2013 -0400
@@ -20,10 +20,10 @@
<![endif]-->
- <link rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD" type="text/css" /></head>
+ <link rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-ED" type="text/css" /></head>
<body>
- <div class="head"><div><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" width="72" height="48" alt="W3C" /></a></div><h1>Web Cryptography API Use Cases</h1><h2>W3C Working Draft <em>8 January 2013</em></h2><dl><dt>This Version:</dt><dd><a href="http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130108/">http://www.w3.org/TR/2013/WD-webcrypto-usecases-20130108/</a></dd><dt>Latest Published Version:</dt><dd><a href="http://www.w3.org/TR/webcrypto-usecases/">http://www.w3.org/TR/webcrypto-usecases/</a></dd><dt>Latest Editor’s Draft:</dt><dd><a href="http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html">http://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html</a></dd><dt>Editor:</dt><dd><a href="http://arunranga.com/">Arun Ranganathan</a>, Mozilla Corporation <arun@mozilla.com></dd><dt>Participate:</dt><dd></dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr />
+ <div class="head"><div><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" width="72" height="48" alt="W3C" /></a></div><h1>Web Cryptography API Use Cases</h1><h2>W3C Working Draft <em>April 10 2013</em></h2><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr />
<div class="section">
<h2>Abstract</h2>
@@ -44,7 +44,7 @@
report can be found in the <a href="http://www.w3.org/TR/">W3C technical
reports index</a> at http://www.w3.org/TR/.
</em></p><p>
- This document is the 8 January 2013 <b>First Public Working Draft</b> of the
+ This document is the April 10 2013 <b>Editor's Draft</b> of the
<cite>Web Cryptography API Use Cases</cite> specification.
Please send comments about this document to
@@ -84,7 +84,7 @@
<a href="https://dvcs.w3.org/hg/webcrypto-usecases">W3C public Mercurial Repository</a>.
</p>
<p>
- Publication as a Working Draft does not imply endorsement by the
+ Publication as an Editor's Draft does not imply endorsement by the
W3C Membership. This is a draft document and may be updated, replaced
or obsoleted by other documents at any time. It is inappropriate to cite
this document as other than work in progress.
@@ -291,28 +291,23 @@
</div>
<div id="data-integrity" class="section">
<h3>3.3. Code Sanctity and Bandwidth Saver</h3>
- <p>A major social networking site wishes to optimize website performance by storing JavaScript and other resources in local storage, preventing a needless server roundrip. The social network site wishes to verify that these resources have not been tampered with; the service uses <a href="#localStorage"><code>localStorage</code></a> and <a href="#IndexedDB"><code>IndexedDB</code></a> to store assets for their web pages, notably JavaScript. Their threat model is such that the social networking site implicitly trusts the HTTP connection (which uses <a href="#TLS">TLS</a>), the browser, and the HTTP cache, but cannot vouch for <a href="#localStorage"><code>localStorage</code></a> or <a href="#IndexedDB"><code>IndexedDB</code></a>. Let us take the case of a couple who have gone from being "In a Relationship" to "It's Complicated." John Doe uses the social networking site often, while Jane Doe, a JavaScript programmer, packs her bags to move out of the apartment.</p>
+ <p>A major social networking site wishes to optimize website performance by storing JavaScript and other resources in local storage, preventing a needless server roundrip. The social network site wishes to verify that these resources have not been tampered with; the service uses <a href="#localStorage"><code>localStorage</code></a> and <a href="#IndexedDB"><code>IndexedDB</code></a> to store assets for their web pages, notably JavaScript. </p>
<div class="example"><div class="exampleHeader">Example</div>
- <p>This illustrates a worst case scenario, in which <code>localStorage</code> is compromised by a malicious user. Normally, the social networking site deploys code of the sort below, which John Doe's browser runs everytime he logs into the social networking site.</p>
+ <p>This illustrates current practice, in which <code>localStorage</code> is used to store assets locally. Normally, the social networking site deploys code of the sort below, which a user's browser runs everytime he logs into the social networking site.</p>
<div class="block"><div class="blockTitleDiv"><span class="blockTitle">ECMAScript</span></div><div class="blockContent"><pre class="code"><code class="es-code">
function init() {
var src = window.localStorage.getItem('src');
<span class="comment">// up until now env is safe</span>
if (src) {
<span class="comment"> // now whatever code was in src will be executed</span>
- eval(src);
+ JSON.parse(src);
} else {
<span class="comment">// fetch the code using xhr, populate localStorage</span>
<span class="comment">// with it. Execute it.</span>
}
}
</code></pre></div></div>
- <p>But at some point in time, a malicious user -- Jane Doe -- with access to the JavaScript console of John Doe's browser does something of the sort:</p>
- <div class="block"><div class="blockTitleDiv"><span class="blockTitle">ECMAScript</span></div><div class="blockContent"><pre class="code"><code class="es-code">
- window.localStorage.setItem('src', evil_code);
- <span class="comment">// evil_code makes requests to Jane Doe's server with data about John Doe</span>
- </code></pre></div></div>
- <p>John Doe's use of the social network is thus compromised by Jane Doe's script injection, since the next time he logs in, and <code>init()</code> is called, <code>evil_code</code> is run, which may make requests to Jane's server with query strings that reveal who John chats with, and even the contents of these messages. To mitigate against situations like this, the social networking site might do something like this:</p>
+ <p>Using the WebCrypto API, the social networking site might do something like this:</p>
<div class="block"><div class="blockTitleDiv"><span class="blockTitle">ECMAScript</span></div><div class="blockContent"><pre class="code"><code class="es-code">
<span class="comment">// Synchronously retrieve a SHA-256 digest of the pristine version of the code</span>
<span class="comment">// This is retrieved from the server</span>
@@ -351,11 +346,11 @@
}
</code></pre></div></div>
- <p>In this case, <code>getHashFromServer()</code> is guaranteed to be untampered with, since it connects to the server or the HTTP cache, which are above suspicion in this threat model.
+ <p>In this case, <code>getHashFromServer()</code> is runs within the origin of the page of the social networking site, within TLS.</p>
</p>
<div class="note"><div class="noteHeader">Note</div><p>The conversion to an <a href="#TypedArray"><code>ArrayBufferView</code></a> must be consistent with the conversion to bits on the server side, so that the SHA-256 digests can be compared acurately.</p></div>
</div>
-<p>Since their threat model trusts the network layer (which includes <a href="#TLS">TLS</a>, and a distributed web cache not entirely on their own servers) but mistrusts the user's machine to store code via <a href="#localStorage"><code>localStorage</code></a> and <a href="#IndexedDB"><code>IndexedDB</code></a> the <a href="#WebCrypto">WebCrypto API</a> offers mitigations:</p>
+
<ol>
<li><p>As in the example above, the social network can generate a digest of the material extracted from the client storage, and compare this to a pristine version of the digest that the social networking site makes available to the client. If the two digests match, the code is deemed safe. [<a href="#digest">DIGEST</a>]</p></li>
<li><p>They can improve on the model above by "signing with an HMAC" (or "signed hash") and then verifying the HMAC. This model offers one level more robustness, since the verification occurs within the WebCrypto API, as opposed to within the application. [<a href="#sign">SIGN</a> | <a href="#hmac">HMAC</a> | <a href="#verify">VERIFY</a>]</p></li>