Encryption, DRM, and the Web Cryptography API
Secrets and Keys
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.
Polyfills
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.
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.
Asymmetry
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
(incl. VAT)