Encryption, DRM, and the Web Cryptography API

Secrets and Keys

Article from Issue 157/2013
Author(s): , Author(s):

The controversial Web Cryptography API offers flexible encryption for web applications, but it also lays the groundwork for content providers to implement more powerful access restrictions through DRM.

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" [1], and the BBC considers it justified to restrict access to its programs to British TV license payers only [2].

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


Implementation of the Web Cryptography API in the Chrome browser [5], and in Mozilla Firefox [6] 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 [7]. 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 [8] 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 [9] 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. 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

Encrypting Application Data


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.


The RSA asymmetric encryption method [10] 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. 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.

Listing 2

Signing a 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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Cryptography and Provable Security

    A concept called provable security brings the rigor of mathematics to the art of cryptography.

  • Doghouse – Privacy Matters

    "maddog" recalls some of the history of encryption and PGP and discusses why they should matter to everyone.

  • Coming of Age

    Age, a modern encryption tool, could soon replace PGP and GPG when it comes to file encryption.

  • EncryptPad

    EncryptPad provides symmetric text encryption directly from the editor. You can also use EncryptPad to encrypt binary data.

  • DM-Crypt

    If you’re serious about keeping secrets, try hard disk encryption with DM-Crypt and LUKS.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More