The Web Cryptography API is a proposed addition to the HTML5 specification that will support cryptography for web applications. Modern browsers already have support for several cryptographic technologies. The new Web Cryptography API will extend this cryptography support to web applications through the Domain Object Model (DOM) used for web development.

The new API, which is based on the future ability of web browsers to encrypt and decrypt application data using JavaScript, is currently under review by the World Wide Web consortium (W3C) as a draft. This promising technology reaches well beyond the HTTPS transport security used with many websites, unleashing a flexible new paradigm for encryption in the web space. For example, a custom app could encrypt and store data in the cloud prior to transmission via WebSockets or WebRTC.

Although privacy advocates applaud new techniques for better and more flexible encryption, the Free Internet community has expressed alarm about the Web Cryptography API and has even asked the W3C to stop working on it. The reason for this concern is the potential for this technology to serve as a vehicle for Digital Rights Management (DRM) restrictions to online content.

The online movie rental service Netflix, for example, and the British broadcaster BBC, are already planning to implement DRM based on the encryption features in HTML5. Netflix designates this copy protection as “HTML5 Premium Video Extensions,” and the BBC considers it justified to restrict access to its programs to British TV license payers only.

The W3C proposal for the Web Cryptography API goes by the name of Encrypted Media Extensions (EME) and is currently in the draft phase. We decided to look at the Web Cryptography API and see what the fuss is about.

Polyfills

Implementation of the Web Cryptography API in the Chrome browser, and in Mozilla Firefox has already begun. Until the browsers include full support, developers are using polyfills to retrofit individual features. These browser patches – named after a popular British filler paste – are JavaScript libraries that a web browser downloads off the web as needed. One of these polyfills is PolyCrypt. Although PolyCrypt implements an older design of the Web Cryptography API, it is well suited for demonstration purposes. The software license is currently unclear, but PolyCrypt is available on the web for free use. The developer binds PolyCrypt into an HTML document, like any other JavaScript file. For the polyfill to work, it needs to load the HTML document via a web server. Figure 1 shows PolyCrypt in use in the browser’s JavaScript console.

Figure 1: The console in the Chrome browser uses PolyCrypt to evaluate the call to encrypt("abc").

WebCrypto by Netflix is another implementation of a polyfill. In contrast to PolyCrypt, WebCrypto is not a JavaScript library but a natively compiled browser plugin for Google Chrome.

Symmetrical Encryption

The Web Cryptography API supports several encryption technologies. The AES symmetric encryption method, for instance, is suitable for protecting application data in a cloud. Listing 1 shows how to use AES together with the Web Cryptography API.

Listing 1: Encrypting Application Data

01 var encRawKey = "4ea1...b2bf";
02 var encAlg = {
03  name : "AES-GCM",
04  params : {
05   iv : hex2bin("534aea17"),
06   additionalData: hex2bin("534aea17"),
07   tagLength: 128
08  }
09 };
10 function encrypt(text) {
11  polycrypt.importKey("raw", hex2bin(encRawKey)).oncomplete = function(e) {
12   var key = e.target.result;
13   polycrypt.encrypt(encAlg, key, str2bin(text)).oncomplete = function(e) {
14    var cipher = e.target.result;
15    polycrypt.decrypt(encAlg, key, cipher).oncomplete = function(e) {
16     console.log("encrypted: "+bin2str(cipher));
17     console.log("decrypted: "+bin2str(e.target.result));
18    };
19   };
20  };
21 }

Line 1 stores a key (truncated in the listing) for encrypting and decrypting application data in the variable encRawKey as a hexadecimal numerical sequence. The encAlg variable in lines 2-9 stores a configuration object.

Listing 1 selects the AES algorithm in GCM mode in the name field with the initialization vector from iv and the user ID from additionalData to encrypt() (in line 13) and decrypt() (in line 15).

The values for the initialization vector and the user ID must be specified as byte sequences. The conversion is handled by the hex2bin() function. Within the encrypt function, line 11 uses polycrypt.importKey() to import the key from line 1. The raw format specification in this call means that the key needs to be converted into a byte sequence.

The browser runs the importKey() function asynchronously; this also applies to the API methods encrypt , decrypt , generateKey , sign , or verify . If successful, the browser executes the callback function specified for all the methods for the onComplete event. Lines 11 to 20 show this callback function. The function uses the imported key in the key variable in the encrypt call (line 13) for the encryption process.

In the decrypt call (line 15), the key is used to decrypt the message from the text variable (line 10). bin2str() converts the encrypted and decrypted messages to a readable string for output on the console (lines 16 and 17). Figure 1 shows symmetric encryption in use.

Asymmetry

The RSA asymmetric encryption method is suitable for protecting application data in transit via WebSockets and WebRTC. In contrast to a symmetric method, RSA uses a pair of keys. The two communication partners use the third-party public key to encrypt, and their own private key to decrypt, a message.

Additionally, RSA is used to sign a message, thus allowing its authentication. Listing 2 shows the combination of RSA and the Web Cryptography API for signing a message.

Listing 2: Signing a Message

01 var sigKeyAlg = {
02  name: "RSASSA-PKCS1-v1_5",
03  params: {
04   modulusLength: 512,
05   publicExponent: new Uint8Array([0x01, 0x00, 0x01])
06  }
07 };
08 var sigAlg = {
09  name: "RSASSA-PKCS1-v1_5",
10  params: { hash: "SHA-1" }
11 };
12 function signature(text) {
13  var arr = str2bin(text);
14  polycrypt.generateKey(sigKeyAlg).oncomplete = function(e) {
15   var key = e.target.result;
16   polycrypt.sign(sigAlg, key.privateKey, arr).oncomplete = function(e) {
17    var sign= e.target.result;
18    polycrypt.verify(sigAlg, key.publicKey, sign, arr).oncomplete = function(e) {
19     console.log("verifyed?: "+e.target.result);
20    };
21   };
22  };
23 };

The configuration object in lines 1-7 provides information for generating a key pair in the call to generateKey() (line 14): The name field selects a variant of the RSA algorithm, whereas modulusLength selects the modulus to be used and publicExponent the public exponent. Lines 8 to 11 save a configuration object for parameterizing the calls to the sign() (line 16) and verify() (line 18) methods. The hash parameter stipulates the SHA-1 algorithm, which generates a checksum for the text message.

The callback function for calling generateKey() and the onComplete event (lines 14 to 22) uses the private key from the privateKey component in line 16 to generate the signature. In line 18, it uses the publicKey to verify the signature. Line 19 outputs the result of the verification on the JavaScript console.

Thanks to cryptographic functions of this type, developers can program an application that allows, for example, an encoded video file to be played only in a specific browser within a single session. This means that providers like Netflix or BBC can easily use this HTML5 extension to apply DRM.

Resistance

These efforts have met with some resistance from the Electronic Frontier Foundation (EFF). The US organization for digital civil rights has fought DRM for years. In May 2013, the EFF submitted formal objection to the statutes of the HTML Working Group to the W3C: In the opinion of the Foundation, the Encrypted Media Extensions contradict W3C’s vision of an open web and excludes certain browsers and platforms from the World Wide Web. EME obstructs interoperability and the participation of any interested party in the web.

The Free Software Foundation (FSF) has added its voice to this criticism, having always fought against “Digital Restrictions Management” (Figure 2).

Figure 2: The Free Software Foundation fights Digital Rights Management in its “Defective by Design” campaign.

Activists have coined the term “Hollyweb” for the current threat, referring to an Internet that is based on the ideas of the movie corporations in Hollywood. On May 3, 2013, they celebrated anti-DRM day and handed over a letter of protest to the W3C with tens of thousands of signatures.

A formal objection to EME has also been filed by software developer Andreas Kuckartz. Kuckartz has been an Invited Expert in the W3C’s HTML Working Group for two years. He sees problems with open source software licenses in EME: “Since GPLv3, DRM, and free software are no longer compatible.” In his opinion, there is no obligation for the W3C to comply with the entertainment industry’s desire for digital rights management. The standardization process still has several stages to go through, he says, and the output is unclear. “If the W3C leaves DRM out of the standards, anybody interested in doing so could design it on their own,” he cautiously predicts.

W3C CEO Jeff Jaffe, on the other hand, argues that DRM will be present on the web anyway (through technologies such as Flash and Silverlight) regardless of whether the W3C throws its weight behind a technology standard. In an interview with CNET, Jaffe points out, “There is going to be protected content on the Web … . We should have one Web with as much commonality as possible, where one is able to access free content as well as protected content. The other approach is to say if someone wants to have DRM content, that should be its own walled garden, cordoned off. We don’t want the Web to be a bunch of cordoned-off apps.”

The EFF counters that building restrictive technologies into an open standard is unworkable and contrary to the spirit of the W3C. “Accepting EME could lead to other rightsholders demanding the same privileges as Hollywood, leading to a Web where images and pages cannot be saved or searched, ads cannot be blocked, and innovative new browsers cannot compete without explicit permission from big content companies.”

As of now, the W3C seems committed to continuing the development and adoption of the Web Cryptography API, but even if the controversial API isn’t accepted as an official W3C standard, you can bet the entertainment industry’s effort to build DRM into the Internet isn’t going to go away anytime soon.