Re: Use Case: Cryptographic primitives can help check source integrity before executing Javascript code previously stored in local storage.

On 2012-08-17 15:14, Mountie Lee wrote:
> Hi.
> I totally agree "checking JS source integrity"
> 
> I have read many threads for similar purpose. 
> - Signed JS at http://www.w3.org/2012/webcrypto/wiki/Use_Cases#Signed_web_applications
> - JS Integrity checking from my previous mails at http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Aug/0007.html
> - preventing swap of sensitive values at http://lists.w3.org/Archives/Public/public-webcrypto-comments/2012Aug/0041.html
> 
> basic security consideration is keeping "same origin policy" at http://www.w3.org/2012/webcrypto/WebCryptoAPI/#security-implementers

Mountie,

> but I still think the API need a protection mechanism from client side vulnerabilities.

Nobody disagrees that this would be great but nobody is able to tell how that
would work for the simple reason that the API and the client is the same
environment.  I.e. it would be sort of protecting youself against yourself.

Windows 8 has a trusted computing platform module that protects the
entire OS from malicious modifications.  This and similar solutions
will be our best bet.

Regards,
Anders

> 
> regards
> mountie.
>  
> On Fri, Aug 17, 2012 at 9:47 PM, Tobie Langel <tobie@fb.com <mailto:tobie@fb.com>> wrote:
> 
>     Hi,
> 
>     I was asked to provide more information on the following use case we
>     (Facebook) submitted when this group was chartered:
> 
>     "Cryptographic primitives can help check source integrity before executing
>     Javascript code previously stored in local storage."
> 
>     Is is common for web applications to store JavaScript code in
>     localSotrage/IndexedDB etc. and execute portions of it as needed by the
>     application, sometimes after having patched the code through a delta
>     update downloaded from the server[1]. This is mainly done for performance
>     reasons and to reduce network traffic.
> 
>     Code stored in localStorage/IndexedDB, etc. is vulnerable to malicious
>     attempts by users of the same device to modify it in order to gain access
>     to the data of another user of the same device. This is typically a
>     problem when different users are using the same OS level user and
>     consequently have access to the same browser; a very common scenario on
>     mobile.
> 
>     Until the stored code is executed, however, the environment is immune to
>     this problem. A simple mitigation strategy when online involves
>     checksumming the code to verify it wasn't tampered with before executing
>     it. This requires downloading a crypto library and checksums, neither of
>     which can be stored locally.
> 
>     Cryptographic primitives would make downloading a dedicated library
>     unneccessary, would be much faster, and would avoid the risk of
>     accidentally storing the crypto library in localStorage (which is a
>     mistake which is bound to happen).
> 
>     This vulnerability and a similar mitigation strategy has been described
>     recently[2] by Sebastian Lekies.
> 
>     Hope this helps,
> 
>     --tobie
> 
>     ---
>     [1]:
>     http://www.stevesouders.com/blog/2010/07/09/diffable-only-download-the-delt
>     as/ <http://www.stevesouders.com/blog/2010/07/09/diffable-only-download-the-delt as/>
>     [2]:
>     http://www.sec.t-labs.tu-berlin.de/spring/content/spring7_02_slides_lekies.
>     pdf <http://www.sec.t-labs.tu-berlin.de/spring/content/spring7_02_slides_lekies. pdf>
> 
> 
> 
> 
> 
> -- 
> Mountie Lee
> 
> Tel : +82 2 2140 2700
> E-Mail : mountie@paygate.net <mailto:mountie@paygate.net>
> Twitter : mountielee
> 
> =======================================
> PayGate Inc.
> THE STANDARD FOR ONLINE PAYMENT
> for Korea, Japan, China, and the World
> 
> 
> 
>

Received on Friday, 17 August 2012 13:41:44 UTC