- From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
- Date: Fri, 17 Aug 2012 15:19:19 +0200
- To: Tobie Langel <tobie@fb.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Christopher Kula <cjkula@gmail.com>
Tobie, Thanks for this use case. This will help us to address ACTION-28 related to script signed. The WG will check if this is addressed or not with our current draft API http://www.w3.org/2012/webcrypto/WebCryptoAPI/ . Regards, Virginie Gemalto Chair of Web Crypto WG -----Original Message----- From: Tobie Langel [mailto:tobie@fb.com] Sent: vendredi 17 août 2012 14:47 To: public-webcrypto-comments@w3.org Subject: Use Case: Cryptographic primitives can help check source integrity before executing Javascript code previously stored in local storage. 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/ [2]: http://www.sec.t-labs.tu-berlin.de/spring/content/spring7_02_slides_lekies. pdf
Received on Friday, 17 August 2012 13:19:46 UTC