SlideShare a Scribd company logo

The History and Status of Web Crypto API (2012)

•
•
Channy Yun
Channy Yun

The document discusses the history and status of the Web Cryptography API. It outlines the legacy approaches to cryptography in web browsers like crypto.signText and CAPICOM. It then summarizes the development of the Web Cryptography API, from early proposals in the HTML5 working group to the current W3C Web Cryptography working group developing the standard. The API aims to provide common cryptographic functions like encryption and signatures to web applications through a standardized JavaScript API.

Related slideshows

Web Development - Lecture 1
Web Development - Lecture 1Web Development - Lecture 1
Web Development - Lecture 1
 
HTML5 표준 소개
HTML5 표준 소개HTML5 표준 소개
HTML5 표준 소개
 
HTML5: An Introduction To Next Generation Web Development
HTML5: An Introduction To Next Generation Web DevelopmentHTML5: An Introduction To Next Generation Web Development
HTML5: An Introduction To Next Generation Web Development
 
1 of 24
Download to read offline
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
From Document to Application 1995 2000 2005 2010 Web Hypertext Application Technology Working Group
Return to W3C - HTML5 Era
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
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=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
Thanks for listening: Q&A Channy Yun Twitter: @channyun E-mail: channy@mozilla.or.kr Blog: http://channy.creation.net

More Related Content

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
  • 7. Return to W3C - HTML5 Era
  • 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
  • 12. c.f. Comparison of Identity
  • 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.
  • 15. Web Cryptography API http://www.w3.org/2012/webcrypto/WebCryptoAPI/
  • 16. • Basic – Hash – Mac – Random Number • window.crypto.getRandomValues • https://dvcs.w3.org/hg/domcrypt/raw-file/tip/Overview.html
  • 17. • Public Key Encryption • Encrypt and sign message
  • 18. • Decrypt a received blob • Sign and verify
  • 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
  • 24. Thanks for listening: Q&A Channy Yun Twitter: @channyun E-mail: channy@mozilla.or.kr Blog: http://channy.creation.net