Exploring the Future Potential of AI-Enabled Smartphone Processors
The History and Status of Web Crypto API (2012)
1. The History and Status of
Web Cryptography API
Channy Yun
Mozilla Korean Community
http://www.mozilla.or.kr
2. 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-)
3. 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
5. 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
6. From Document to Application
1995 2000 2005 2010
Web Hypertext Application
Technology Working Group
8. Range of HTML5
HTML5 Buzz Word CSS3
Geolocation
Canvas HTML5 Offline
WebRTC
Web Workers
Device API
Web Form Markup
File API
Video&Audio Web Sockets
WebGL
Server-Sent Indexed
XMLHttpRequest DOM Storage
Events Database API
9. 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>
10. Draft: Web Crypto API
• http://html5.creation.net/webcrypto-api/
• Focused on certificate services, but issues on identity
11. 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
13. 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.
14. 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.
19. • 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
20. 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
21. 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)
22. 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/
23. References in Korean
1. 액티브X 없이 공인인증서 쓴다
http://www.zdnet.co.kr/news/news_view.asp?artice_id=2
0120323121226
2. 공인인증서 액티브X와 결별하려면
http://www.zdnet.co.kr/news/news_view.asp?artice_id=2
0120329124248
3. 전자서명 웹 표준화 안되나?
http://channy.creation.net/blog/884
4. ActiveX 걷어낼 웹표준 만든다
http://blog.creation.net/519
5. WebCrypto API의 현재와 미래
http://channy.creation.net/blog/884
