The History and Status of Web Crypto API (2012)

The History and Status of Web Cryptography API

Channy Yun

Mozilla Korean Community http://www.mozilla.or.kr

About me • Before Daum

– 1997~2004 E-Commerce • Reference: SK MusicOK, iMusicLand and YBM Tutti etc.

– 1999~2004 Payment Gateway • Mypay.net, an integrated payment for SOHO business

– 2001~2004 Certificate Business • Thawte.co.kr, an authorized Reseller of Thawte and Verisign Japan

• In Daum

– 2004~ Web Standards Evangelist • Mozilla Korean Community, Leader (2002-) • W3C HTML W/G, Invited Expert(2007-) • W3C Web Crypto API Community Group, Chair (2011-) • W3C WebCryptography W/G, Invited Expert (2012-)

Agenda • History

– Legacy: crypto.signText and CAPICOM – History: XML Signature

• HTML5: from document to application

– Crypto in HTML W/G – Draft: Web Crypto API

• Raising Web Identity

– Web Identity and BrowserID

• Web Cryptography API – Public key encryption, signing message and decryption. – Use cases and key isolations

• Future plan

Legacy: crypto.signText and CAPICOM

History: XML Signature

• W3C XML Signature Syntax and Processing • http://www.w3.org/TR/xmldsig-core • From 2000, based on web services bubble • Issues on XML Canonicalization and performance in SOA applications,

lacks of web based use cases

• Web Activated Signature Protocol • http://webpki.org • From 2006, Based on XML signature proposed by Anders Rundgren • Issues on deprecated XML signature and lacks of primitive functions

such as Javascript APIs

1995 2000 2005 2010

From Document to Application

Web Hypertext Application Technology Working Group

Return to W3C - HTML5 Era

Range of HTML5

Canvas Offline

Web Form Markup

Video&Audio

Geolocation

Web Workers

XMLHttpRequest

File API

Server-Sent Events

Indexed Database API

WebGL

DOM Storage

Web Sockets

CSS3 HTML5 Buzz Word

HTML5 Device API

WebRTC

Crypto in W3C HTML W/G

• Simple Keygen • http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-

April/019206.html • http://www.w3.org/TR/html-markup/keygen.html • Integrates tightly with the form submission model • Issues on Microsoft has no intention of ever implementing the <keygen>

element. (Crypto part was changed “optional”)

• Simple form signing • http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-

October/007571.html • Strict form submission for crypto.signText

<form action="sendMoney" stricted> <input type="text" name="dollars" value="3.00" signed="signed"> <input type="text" name="account" values="1234567890"> <input type="submit" value="Sending Money!"> </form>

Draft: Web Crypto API

• http://html5.creation.net/webcrypto-api/ • Focused on certificate services, but issues on identity

Raising Web Identity

• Identity Crisis • Dead of OpenID and widely usages of OAuth • Lock-in social web giants (Facebook, Twitter) • Needs of self-managed distributed Identity system

• BrowserID and DOM Crypt (2011.5)

• Mozilla’s new identity policy • http://identity.mozilla.com/post/7616727542/introducing-

browserid-a-better-way-to-sign-in • http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-

May/031741.html

c.f. Comparison of Identity

Proposal of Web Identity W/G • http://www.w3.org/2011/08/webidentity-charter.html

– Cryptography API • Commonly-used cryptographic primitives should be made available to web application developers via a standardized API

to facilitate common operations such as asymmetric encryption key pair generation, encryption, and generation, as well as symmetric encryption, hashing, and signature verification. This work can be based upon DOMCrypt, which has already been discussed in the W3C WebApps WG, HTML WG, and IETF Web Security WG.

– Web Identity Sync • This specification should specify how web application developers can synchronize of identity information across

multiple devices like browsers. Synchronization should also work in the "Cloud" to support legacy browsers. Anonymous identities (i.e. an "empty" identity) and multiple identities should be supported. When possible, commonly used data-formats should be re-used and the design should take advantage of existing work such as Mozilla Sync.

– Identity API • This specification should specify how web application developers access session-state information and authentication

credentials to enable functionality such as easier sign-on to services. This API will build upon existing work such as the Verified Email and Session Description Protocols (BrowserID), BrowserAuth, and may optionally propose possible changes to HTML to the HTML WG as well as specify transfer of identity-related data.

• WebCrypto API Community Group • http://www.w3.org/community/webcryptoapi • http://www.w3.org/community/webcryptoapi/2011/09/15/why-web-crypto-api/ • Helping W3C Standards for cryptography and certificate services.

Web Cryptography W/G • http://www.w3.org/2011/11/webcryptography-charter.html

• Primary API Features in scope are: – key generation, encryption, decryption, deletion, digital signature generation and

verification, hash/message authentication codes, key transport/agreement, strong random number generation, key derivation functions, and key storage and control beyond the lifetime of a single session. In addition, the API should be asynchronous and must prevent or control access to secret key material and other sensitive cryptographic values and settings. Encryption and decryption include both symmetric and asymmetric cryptography.

• Secondary API Features that may be in scope are: – control of TLS session login/logout, derivation of keys from TLS sessions, a simplified

data protection function, multiple key containers, key import/export, a common method for accessing and defining properties of keys, and the lifecycle control of credentials such enrollment, selection, and revocation of credentials with a focus enabling the selection of certificates for signing and encryption.

• Out of scope: – features including special handling directly for non-opaque key identification schemes,

access-control mechanisms beyond the enforcement of the same-origin policy, and functions in the API that require smartcard or other device-specific behavior.

Web Cryptography API

http://www.w3.org/2012/webcrypto/WebCryptoAPI/

• Basic – Hash

– Mac

– Random Number • window.crypto.getRandomValues • https://dvcs.w3.org/hg/domcrypt/raw-file/tip/Overview.html

• Public Key Encryption

• Encrypt and sign message

• Decrypt a received blob

• Sign and verify

• Major Functions – Signature, MAC, Public Key Encryption, Symmetric

Encryption and Hash

• Requirements – a standard, cross-browser API – the speed of native crypto implementation – the security of isolating the keys from JavaScript code – persistent key storage and access to system cert/key

• Use Cases

– http://www.w3.org/wiki/NetflixWebCryptoUseCase – http://www.w3.org/wiki/KoreaWebCryptoUseCase

Collecting use cases • Primary features

• Secure messaging • Encrypted web applications • Storing local storage • Encrypted bill • Client authentications

• Secondary features • Financial Transaction: Online bank • Credit card process • SSL VPN • Handling S/MIME mail • Handling XML Encryption

• http://www.w3.org/community/webcryptoapi/wiki/Use_Cases

Key isolations proposed by Ryan Sleevi

• Origin-bound: – generated via .generateKey() bound to a single origin with short-lived (session

cookie style?) • Use case: DHE/ECDHE/PAKE key agreement for opportunistic encryption of chat over Websockets,

where the intermediary is not trusted. • Use case: Perhaps some binding of a user login/cookie data to some encrypted context. The key is only

as useful as long as the cookie lives, and vice-versa.

• Persistent: – effectively super-cookie that might apply to cookies/cache/other data.

• Use case: "identity key" with a service might be used for mail signing, HTML5 file storage, online chat, etc. single origin or shared with multiple origins

– Keys may be stored in software (managed by the UA), in the OS or some global key store (making them available to other applications beyond the UA), in "the cloud" as part of some sync service, or even stored on another device such as TPM or smart card.

• Use Case: For embedders (such as Netflix), for purchase USB TPMs

• High Value: – a strong correlation to certain high value transactions - particularly where

force of law is involved. Unlike the above 'persistent' keys, HVKs are strongly correlated to identity, and may reflect government or financial services issuance. • Use Case: Signing a legal document - tax forms, contract, performing 'sensitive' transactions (bank

transaction confirmation, etc)

Future Plan

• Secondary API spec – aka. Web Certificate Service API – TLS login/out, key management including

import/export and signing/verification – Discussions for smartcard and USB token

• Get started – Join W3C WebCryptography W/G

• http://lists.w3.org/Archives/Public/public-webcrypto/

– Join W3C WebCrypto API Community Group • http://www.w3.org/community/webcryptoapi/

References in Korean 1. 액티브X 없이 공인인증서 쓴다

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20120323121226

2. 공인인증서 액티브X와 결별하려면 http://www.zdnet.co.kr/news/news_view.asp?artice_id=20120329124248

3. 전자서명 웹 표준화 안되나? http://channy.creation.net/blog/884

4. ActiveX 걷어낼 웹표준 만든다 http://blog.creation.net/519

5. WebCrypto API의 현재와 미래 http://channy.creation.net/blog/884

Thanks for listening: Q&A Channy Yun

Twitter: @channyun E-mail: [email protected] Blog: http://channy.creation.net