The Algorithm Series: Digital Rights Management (DRM)
Anytime I write about digital rights management (DRM), I'm reminded that the opinions around codec or format wars are simple skirmishes compared to the strong feelings the term "DRM" evokes. On the one hand, there's the fact that many consumers despise DRM. And not just consumers who are bent on piracy. During my international travels, I can't tell you the number of complaints I've overheard from parents who download several movies for their children to watch during a long-haul flight, only to have geofencing (restrictions around geographies), 24-hour time constraints, or some other form of rights management impede their ability to pacify their children.
On the other hand, within our industry, there are groups that strongly advocate for a particular DRM scheme, such as Apple FairPlay, Google Widevine, Microsoft PlayReady, or open source options, which are all designed to protect content licensors' rights while giving purchasers, renters, and subscribers flexible and fair options for watching content.
In this final Algorithm Series article of 2020, I'll take a step back from those strong opinions and look at the math behind two aspects of DRM: content encryption and license generation.
So if you're interested in which DRM solution is best for your particular use case, I urge you to search for "DRM" here on Streaming Media. But if you want to understand why the industry has coalesced around the math that underpins state-of-the-art encryption and license approaches, read on. I'll start with lessons learned in the early days of copy protection, then show how they inform today's modern DRM solutions.
Starting at the Beginning: VHS
There have been numerous approaches to enforcing rights management for premium content, many of which start from the premise of segmenting the world into various regions. While there was a smattering of this back before the days of consumers viewing premium content at home, with theatrical releases being delivered to movie theaters on a country-by-country basis, the concept didn't really gain traction until the advent of home video rentals and sales.
Starting with the Macrovision copy protection scheme, which would create "snowy" imagery on any VHS tape duplication, the studios began segmenting the world into regions that first accounted for over-the-air (OTA) television transmission formats—NTSC, PAL, SECAM—and then by a rough equivalent of continents, since PAL and SECAM were still in use in various former English or French colonies.
With the advent of digital video delivery on DVDs, which were sold to consumers as perfect digital copies but also had the potential to be duplicated by consumers as perfect digital copies, there was a tightening of rights management on more than just a regional basis.
As part of the premium content protection agreements that studios demanded from the consumer electronics (CE) industry, manufacturers of DVD players were required to incorporate hard-locked regions as a first line of defense in the DVD players they sold. So a DVD player sold by Sony in Europe would only play mass-produced DVDs that were designated for the same region. Any attempt to play DVDs sold in Europe in a DVD player sold in North America would result in a region error being displayed on the screen of the North American DVD player.
In some ways, it wasn't a hard sell for CE manufacturers to meet the studios' demands, since many of the media and entertainment conglomerates owned both studios and CE device manufacturers. But it turned out that the studios and industry representatives at the Motion Picture Association of America (MPAA) weren't satisfied with just using regional locks on DVD players or on the discs themselves. That desire for additional security led to what was arguably the world's first DRM solution: the Content Scramble System (CSS).
CSS was included in each DVD player as a joint rights-management scheme and as encryption functionality, allowing the studios and CE manufacturers to blacklist DVD player models from particular manufacturers via the combined use of firmware updates for the DVD player itself and updated blacklists on newer mass-produced DVDs.
Cracking the Code
The problem with CSS, though, is that it acted exactly the same on any DVD player and also had to work the same for any software-based DVD player on Macintosh and Windows-compatible computers. And those software-based DVD players provided an attack vector that CE devices, with their hard-coded ROMs and chips, did not.
Once CSS was cracked for one device—through the efforts of an ingenious Norwegian teenager, Jon Lech Johansen, who was able to reverse engineer CSS and release an application called DeCSS, earning the nickname "DVD Jon"—it was cracked for all DVDs played on computers and even on older DVD players through hacked firmware updates. Even though the MPAA sued Johansen, he was acquitted of all charges because his intended use of DeCSS was to allow him to view his purchased DVDs on a Linux-based PC, which did not have official software-based DVD player support at the time.
What the studios learned from Johansen's release of DeCSS and his subsequent indictment and acquittal, which occurred right as streaming video was first making inroads, turned out to be a bit of a blessing in disguise. Since the HD-DVD and Blu-ray format battle was heating up, the studios were able to get additional concessions from CE manufacturers, using the internet-connected features of these newer 720p and 1080p shiny discs to issue continuously updated, near real-time blacklists of offending CE devices.
What Streaming Learned From Shiny Discs
Streaming premium content requires several trade-offs that weren't necessarily needed in the shiny disc era, but are derived from lessons learned in the transition from VHS to DVD to Blu-ray.
First, there's a need for significantly higher encryption, since online digital content often resides in a single set of master files (MP4 video files or AAC audio files, which are fragmented at the time of delivery based on permutations of video resolutions and language tracks). Those files need to withstand significant attempts to decrypt the content either during storage (what we'd call "at rest" attacks) or when it's being fragmented and streamed (what we'd call "in transit" attacks). Second, to combat issues such as the shortcoming of having a single overall key for CSS, there is no permanent license key held in a CE device that receives today's modern OTT streams.
The advent of smartphones with higher-resolution screens, along with consumer demand for studios and streaming services to fulfill their promise to deliver content anywhere to any device, means that modern streaming needs flexible rights management but also strong licensing that can authenticate that a particular user is authorized to play.
Security, Speed, and Scale
Even a cursory dive into DRM math will lead to discussions around how to maintain security while also scaling up licensing solutions. The biggest limitation to scaling DRM is the computational intensity of certain aspects of the encryption and license-generation process.
While it's possible to increase the security of content and generate licenses that use larger and larger alphanumeric permutations, the trade-off comes with requiring a greater use of computational resources at both the server and the end-user device.
An asymmetrical versus symmetrical debate permeates academic papers on DRM, but the current state of thinking is that it's best to focus on symmetrical for content encryption (using AES-based encryption), while focusing on asymmetrical cryptography for license key generation.
The streaming industry has fairly well settled on AES encryption as the choice for protecting content at rest and in transit. But what exactly is AES? According to "A Robust Computational DRM Framework for Protecting Multimedia Contents Using AES and ECC," a 2020 paper from researchers at Suez Canal University in Egypt, "AES is a symmetric cryptographic algorithm that takes its name from the key length, such [as] AES-128, AES-192 and AES-256."
The paper notes that AES is more secure than its predecessors, but that its true benefit comes from its speed, regardless of the key length: "[I]t is not just used to obtain a high level of security, but also it is used to achieve high speed and efficiency. … AES executes 10, 12, or 14 rounds depending on the key length, such that for the 128-bit key it executes 10 rounds, for the 192-bit key it executes 12 rounds and for the 256-bit key it executes 14 rounds. In the implemented system, AES-256 with 14 [rounds] is used to encrypt and decrypt the data."
A schematic of a typical DRM system (Used with permission from the paper "A Robust Computational DRM Framework for Protecting Multimedia
Contents Using AES and ECC")
While AES is symmetrical, license key generation for DRM uses an asymmetrical approach. The move away from symmetrical cryptography for key generation—which was used in earlier physical VHS tapes, DVDs, and Blu-ray discs—is significant and is an important lesson for streaming DRM authentication. "[Symmetric key cryptography] is focused towards ensuring secure communication between sender and receiver by using [the] same secret key," according to the often-quoted paper "Cryptography: A Comparative Analysis for Modern Techniques."
As mentioned earlier in the article, the symmetric key approach was used in solutions such as CSS for DVDs, but since it was an immutable key, we've already seen the issues that a seemingly "secret" key faces when it's hacked or reverse engineered. "[A]symmetric cryptography (also called public key cryptography) secures communication by using public and private keys," according to the paper.
Cracking the Code (Again)
In asymmetric cryptography, which first gained popularity a few decades ago via the PGP app for securing email and text-based documents, the public key is paired with a private key. This is a detail that only the person generating the private key knows, unless he or she forwards it on to others with whom the email or document is being shared.
RSA Corp. had a significant lock on cryptography for passwords and licenses, starting with government and military uses (I remember using key fobs with rotating numbers as far back as 1993 at a U.S. Department of Defense facility) and moving into corporate and enterprise use cases in the late 1990s.
RSA used a random number generator with two primes for the public key, but research found that the RSA algorithm wasn't as secure as had been previously thought. "Our team studied millions of active digital certificates that rely on the RSA algorithm," writes JD Kilgallin of the Keyfactor security research group in a late 2019 blog post titled "The Irony (and Dangers) of Predictable Randomness." "Spoiler alert: we found that 1 in every 172 certificates are vulnerable to attack due to poor random number generation."
This issue, which centers on the fact that RSA uses two randomly generated prime numbers of sufficient size and then multiplies them (whereby the two primes are then considered factors of the multiplied number) makes what Kilgallin notes is "a calculation that is computationally infeasible to reverse-engineer from the result" unless the two prime numbers are not truly random.
["I]t is possible there could be a duplicate," Kilgallin writes. "And if two public keys share a common factor, it takes nothing more than a few microseconds of computation and simple mathematics to find the other factors, and compromise both keys." Kilgallin and the Keyfactor team were able to break nearly 250,000 RSA public keys this way.
One answer to this problem would be to radically increase the size of the primes, but then the computations become a bit more intensive. In practical terms, that means an end user's device would require more time to validate the license key issue. In turn, there would be more time required to decrypt the encrypted content, meaning that both battery life and time to access the content would suffer.
A flow chart showing how a DRM key exchange functions (Used with permission from the paper "A Robust Computational DRM Framework for Protecting Multimedia Contents Using AES and ECC")
Enter the Elliptical
To address the issues pointed out earlier, along with the trend toward ever-increasing key lengths as a way to further limit the potential of a public key being compromised, researchers began discussing the practicality of RSA scaling up to meet DRM licensing demands. Those discussions, and further research, eventually led to another form of cryptography, using elliptical curves (known as ECC).
The Suez Canal University paper notes that one of the major benefits of ECC, compared with the RSA approach, is speed: "ECC offers the maximum level of security with smaller key size," the researchers write, noting that a 256-bit ECC key size can "achieve the same level of security that the RSA algorithm can achieve using a greater key size (3072-bit)." As such, there are fewer computational resources required, which lessens power constraints and, since the key itself is shorter, less bandwidth consumption at the outset of the authentication process.
According to the paper, "From a security view, the time needed to break down ECC takes full exponential time. For example, ECC with 160-bit key size takes 9.6x 1011 million instructions per year (MIP) … with the best-known attack to be broken down."
So what exactly is ECC? I'm limited on space to fully describe the process by which ECC can be implemented, but here's a brief overview of the math.
Unlike the RSA approach, which uses basic multiplication of two primes to generate factors on which to decode the key, ECC uses points on a curve. ECC keys are ephemeral, meaning that they're ideal for sessions-based use cases, such as a streaming DRM license. Therefore, academics are now recommending an approach called ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) key exchange.
"Elliptic curves have a rich algebraic structure that can be put to use for cryptography," writes Avinash Kak, of Purdue University, in notes from a lecture called "Elliptic Curve Cryptography and Digital Rights Management." In addition, he writes, "Elliptic curves are called elliptic because of their relationship to elliptic integrals in mathematics. An elliptic integral can be used to determine the arc length of an ellipse."
Kak does a great job of breaking down the math behind ECC. He shows how the simplest curves are straight lines, followed by conics (either positive as parabola or negative as hyperbola), followed by elliptical curves in their standard configuration (also known as the Weierstrass Equation), which can be written this way:
y2 = x3 + ax + b
Kak writes, "To give the reader a taste of the parameters used in elliptic curves meant for real security, here is an example:"
y2 = x3 + 31768908125132550347
According to Kak, "This elliptic curve is used in the Microsoft Windows Media Digital Rights Management Version 2."
Kak also notes that this can be written as:
y = ±√x3 + ax + b
Kak has two major warnings for those who would use elliptical curves in cryptography: Don't use singular curves (which can also be expressed as non-smooth curves), and make sure that the calculations are done as modulo prime. "[C]alculations with real numbers are prone to round-off errors," he writes. "Cryptography requires error-free arithmetic."
A taxonomy of cryptography techniques, showing symmetric and asymmetric cryptography (Used with permission from the paper "Cryptography: A Comparative Analysis for Modern Techniques")
One of the best ways to generate unique numbers, as noted in the previous RSA discussion, is to use prime numbers, because they are divisible only by themselves and 1. But when it comes to the error-free arithmetic that Kak is referencing, prime numbers alone are not enough. For that, we need to use modulo prime.
"[T]he security of ECC depends on finding out how many times a point G participates in a sum like G + G + ... + G," writes Kak, noting that the number of times is determined by the private key. "[I]f some integer XA is your private key … you derive your public key by adding the point G to itself XA times."
Kak also notes that the combination of the value of XA, which is only known by the user, and modulo prime creates a significant barrier to decrypting a license key: "Since the attacker would not know the value of XA, he would not be able to take advantage of such exponentially increasing jumps [of adding G to itself XA times]. There is one more important factor at play here: all these calculations are carried out modulo a prime p (in the most commonly used form of ECC)."
I discussed modulo in a previous Algorithm Series article, and I encourage you to test out how modulo—the remainder of a division of two numbers—works when it comes to modulo and prime numbers.
To try it for yourself, pick a prime number, subtract 1 from it, and then divide it from another prime number from which you've subtracted 1. Here are three examples:
- 37 is a prime number, so subtracting 1 from it equals 36. 23 is also a prime number, so subtracting 1 from it equals 22. 36 divided by 22 equals 1.636363, with the decimals repeating to infinity.
36 ÷ 22 = 1.636363 …
- Likewise, 83 is a prime number, so subtracting 1 from it equals 82, and 82 divided by 22 equals 3.727272, with the decimals repeating to infinity.
82 ÷ 22 = 3.727272 …
- Finally, 67 is a prime number, so subtracting 1 from it equals 66, and 66 divided by 22 yields 3.
66 ÷ 22 = 3
What's interesting about modulo prime (and especially the prime minus 1 approach used by ECC) is that the result can be one of three potential rational numbers: a whole number (with no decimals), a single decimal point (so not subject to rounding), or a pretty number. That's what my wife, a math teacher, refers to as a remainder. It contains repeating decimals that can also be converted into a fraction (e.g., 3.3333 could be converted into 3 1/3 because the 3 after the decimal point repeats itself to infinity).
Internal Attacks andthe Future of DRM Licenses
The future of license key generation depends not just on the inability of an attacker to solve significant computational puzzles, but also on the assumption that proprietary solutions aren't revealed to the general public. Just such a scenario took place when Windows Media DRM was one of the key DRM solutions. In 2001, a user with the moniker "Beale Screamer" posted not just the details of how Windows Media DRM version 2 worked, but also provided the FreeMe tool to strip away DRM protection from version 1 and version 2. Microsoft came out with a third version (labeled as version 10) of Windows Media DRM, but according to Kak, that was also cracked.
That type of scenario, perhaps, is what's driving the industry toward the use of a modified version of ECC when it comes to decryption, especially given the likelihood that ECC's shorter key lengths mean faster hand-shaking protocols, which in turn means wider adoption for ECC as well as wireless communications.
One such approach suggested by both Kak and the researchers from Suez Canal University is the Elliptic Curve Digital Signature Algorithm (ECDSA), which is used to validate a license generated by ECC. "Digital Signature is used to guarantee that the contents of the critical messages sent from the server to desktop or web application will not be altered in transit," according to the paper from the Suez Canal University researchers, "especially in sending the license key, decryption key, user's license and the encrypted video." They suggest that a combination of ECC approaches be used in their proposed new DRM solution: "In the proposed system, the Elliptic Curve Diffie-Hellman (ECDH) is used during the process of key exchanging, while the Elliptic Curve Digital Signature Algorithm (ECDSA) is used in the digital signature process."
While this model has been successful in gaming consoles, such as the Sony PlayStation, it's likely that we'll find ourselves back here again in a year or two, discussing how best to use a newer form of cryptography to handle DRM licensing.
Will 2022 be the year UDP finally shows its streaming mettle? The Quick UDP Internet Connections (QUIC) protocol might make the difference. First, though, OTT platforms need to make technical decisions about HTTP/3 that could further fragment the market.
Multiple DRM technologies make protection content a challenge, but with the right support, a flexible approach, and use of the cloud, publishers can keep their precious video out of the wrong hands
While publishers wait for a single content encryption system that works across all browsers, standards bodies debate the future of EME. Here's what rights management will look like in a post-plugin world.
This session explores the evolution of DRM, including EMEs, and discusses how publishers can support a multi-vendor DRM scenario.