JavaScript Cryptography


Co-founder whiteout.io






"doing crypto in the browser is like  performing
open heart surgery in a sewage plant" 

Security is About EcOnomics




JS CRYPTO - Attack Surfaces


  • Browsers are complex, each works differently
  • XSS (cross site scripting)
  • No constant time algs (pure js crypto)
  • No cross-platform key storage (iOS keychain)

Native Crypto - Attack Surfaces


  • No view src for installed apps
  • Memory safety (Heartbleed)
  • App codebase per platform

 => LOC correlate to the # of bugs in software.
The biggest risk is human error.




Can we serve all platforms

with one codebase?




DEMO

Whiteout Mail

Architecture


But why not via Web Server?


  • Drive by Web designed to run untrusted code
  • Served code can change at any time
  • Server can compromise individual users

=> you're trusting the web server with your data

Threat Modeling

Is this a service...

I trust with my data ?

=> Web server deployment

  • Elster Online (taxes)
  • Netflix (premium content)

I don't trust (completely) with my data ?

=> Installed / Packaged App

  • Whiteout Mail (my email)
  • Spideroak (my files)


  • Exposes native crypto to JS
  • AES, RSA, SHA, ...
  • Encrypt and decrypt
  • Hashing, sign and verify
  • Generate and store keys

JS Security - Best Practices (1)


  • HSTS (HTTP Strict Transport Security)
  • Certificate pinning
  • CSP (Content Security Policy)
  • 'use strict'; and jshint in CI
  • JSON.parse (never eval)

JS SECURITY - BEST PRACTICES (2)


  • Escape strings before rendering
  • Native  WebCrypto (constant time)
  • Engineering best practices (testing, reviews)
  • Security audits by independent pros
  • Open source the (crypto) code



Thank You



Blog post to these slides:

tankredhase.com/2014/04/13/heartbleed-and-javascript-crypto/

JavaScript Cryptography

By tanx

JavaScript Cryptography

Lessons learned and best practices for JavaScript cryptography

  • 1,428