Cryptography in Home Entertainment
A look at content scrambling in DVDs

By Mark Barry
June 2004


    Did you know that every time you watch a DVD, a simple cryptosystem is at work behind the scenes?  A cryptosystem, while watching DVDs?  Why would anyone need a cryptosystem for playing DVDs on their home television?  Well, there is a very good answer to that question!
    As you might know, illegal copying and distribution of digital media such as music and video is quite common.  You have probably at one time or another had your own experience with this activity.  So who cares if you copy some music or videos and give them to your friends?  Well, the entertainment industry sure cares!  When your friends are getting free music and videos, the entertainment industry is not profiting.  It's that simple.  So when the DVD standard for movies on disc was being developed in the mid-1990's, Hollywood studios had a vested interest in doing something about copyright protection.  In 1996 the Content Scrambling System (CSS) was agreed upon.

How CSS Works in DVD Copy Protection

    First of all, how would someone copy a movie from DVD, and why?  DVD video is stored in the MPEG-2 format which is easily portable to a personal computer (as a .mpg or sometimes .vob file) where it can be viewed.  Theoretically all someone would have to do is copy over the MPEG video files and voila!, they have their favorite movie on their computer.  Then their friends could download it, or with the dawn of DVD burners, it could be re-burned and shared that way.  There needs to be a way of locking out this sort of activity yet still letting the owner (buyer) view it.
    The solution is a sort of crypto/authentication system between an actual DVD disc and the DVD player.  A DVD player, of course, does not copy and store the video contents but is responsible only for playback.  So the idea is to make sure that only a player is able to read the DVD.  This brings us to the common Alice, Eve, and Bob example.  Alice of course is trying to communicate with Bob without Eve knowing what she is saying.  A DVD disc (Alice) is trying to communicate its video data to a DVD player (Bob).  It doesn't trust what a computer (Eve) might do with the data.  In essence, the video data on a DVD is encrypted (or scrambled) as the DVD player reads it.  The DVD player, in turn, knows how to decrypt the data and play the video.  At this point "Eve's Easy DVD Copy Software" doesn't know what to do with the encrypted data and thus cannot copy and view the video as a simple MPEG file.  (As a side note, you may have heard of "Rippers" which do not decrypt the DVD data themselves, but instead record (or "rip") the standard video that the DVD player outputs.  That's a different story).
    So basically only the DVD players have the "key" to decrypt a DVD, right?  Yes, that's correct (for now).  A not-for-profit organization called the DVD CCA (DVD Copy Control Association) is responsible for distributing keys to the various DVD player manufacturers (Sony, Panasonic, etc).   Keys are not issued to just any "Joe Blow", and commercial DVD player manufacturers actually pay big bucks to obtain a license to use a key. Decrypting/descrambling circuitry is then added to the DVD player and the key is hard-coded in.  It is virtually impossible to find a key inside a piece of hardware.  Thus the copying problem has been solved...for now...

The Problem with CSS

The problem with CSS is that the underlying cryptosystem and keys need to remain secret.  Even modern cryptosystems are completely open and their workings can be known by anyone.  Cryptosystems where the encryption/decryption algorithm must be kept secret are generally a very poor choice.  CSS also has a very small number of keys (around 400 only) -- another weakness in any cryptosystem.  Only the DVD player manufacturers have knowledge of the keys and cryptosystem, and in general, they can be trusted with it.  But with so many DVD player manufacturers and millions of DVD users, something is bound to go wrong; secrets will leak or someone will crack the system.  And unfortunately for the movie industry, that's exactly what happened.


The original reason behind the DVD scrambling system "needing" to be cracked was the lack of software DVD players for the Linux operating system.  The CCA had issued licenses to various software companies allowing them to develop players for non-Linux systems, but because of the open source nature of Linux, the CCA denied offering licenses to Linux developers.  (They certainly didn't want their cryptosystem open source!)  At this point, the only way someone could develop a DVD player for Linux was to figure out the system themselves.   That "someone" is generally credited as being 15-year-old Jon Johansen.  In late October 1999, he released on the Internet, a software program called DeCSS that could actually decrypt the contents of DVDs.  Johansen acknowledges though that the majority of the cracking source code came from anonymous contacts he had over the Internet.  As hinted at from the name, it un-does CSS, something only licensed DVD players could (or were allowed to!) do.  The cat had been let out of the bag.  The DVD cryptosystem is no longer secret.

After DeCSS

After learning about DeCSS, the CCA was far from happy.   Their secret cryptosystem and handful of secrets keys were already circulating the internet.  In a few months following the first release of DeCSS, Norwegian authorities (Johansen's residence was in Norway) showed up at Johansen's home, seized his computers and even his cell phone, and led him off for questioning.  Backed by the CCA and other groups such as the MPAA from the United States, "The National Authority for Investigation and Prosecution of Economic and Environmental Crime" of Norway prosecuted Johansen for "gaining unauthorized access to data" and "copyright infringement."   During his time in and out of court, hacker geeks and techie types grew in mass support of Johansen.  Many argued he had done nothing wrong; he had really only created a program to read data off his own purchased DVDs.  He hadn't pirated anything, only made a program to view his DVDs in Linux.  After much legal hubbub, Johansen was eventually acquitted in January 2003 and all charges dropped.   But subsequent legal action in the United States ensued.  The CCA fought to have DeCSS banned.  They led a massive search and destroy effort, sweeping the Internet trying to find websites offering DeCSS or even linking to it.  Numerous lawsuits were filed and court battles fought.  But to make a long story short, the CCA had no other choice but to give up its fight.  Like anything spread over the Internet, it is virtually impossible to stop.  In addition, several courts ruled that DeCSS was nothing more than free speech, protected by the first amendment.

Since the CSS system has been implemented in (probably millions) of DVD players and (also probably millions or billions) of DVD discs worldwide, the now "cracked" system has little hope for being recalled and fixed.  So the motion picture industry can only hope that nobody uses DeCSS to pirate movies, and prosecute those who do.  For now it looks like CSS is here to stay and overall will still keep the common DVD user honest.  In the mean time, the weakness of the CSS system had certainly taught the rest of the industry a lesson.  An emerging standard of DVD audio was to use "CSS II", a similar successor of CSS.  But since the cracking of CSS in 1999, certainly a better cryptosystem was needed.  Content Protection for Pre-recorded Media (CPPM), developed by 4C (comprising of IBM, Intel, MEI, and Toshiba), was agreed upon in mid-2000.  CPPM uses the Cryptomeria Cipher (C2) for content encryption, (which won't be discussed here).  It proves to be stronger than CSS.

More on the Creation of DeCSS

In a hardware implementation, CSS is very secure against hacks.  As mentioned before, getting into the workings of hardware is very difficult.   But with software implementations of CSS, any skilled hacker can get into and closely analyze what is happening in the CSS decryption process.  With CSS being of most interest to Linux users, and Linux users being mostly the geek/hacker types, it didn't take long for the cryptosystem to be torn apart.  Although Jon Johansen has been given much media attention as the cracker of CSS, he admits he really wasn't.  An anonymous German hacker was responsible for the CSS crack and a group called the Masters of Reverse Engineering (MoRE) claimed credit for writing the guts of DeCSS, the software.  There are also claims that a group called "Drink or Die" (DoD) had also been working on CSS decryption.  Hinting by the name of such organizations, "the anonymous German" was able to reverse engineer existing (licensed) DVD player software (available in non-Linux operating systems) in order to crack the cryptosystem.

One aid in cracking the system was a software player called XingDVD, distributed by Xing Technologies, a subsidiary of RealNetworks.  The developers of XingDVD neglected to encrypt the CSS decryption key (oops!).  After a bit of digging around, the hacker was able to find this 5 byte (40 bit) key in plaintext.   Johansen, learning of this discovery, was able to further guess about 170 keys used in other players. 

A Closer Look at CSS

Although the following is not a complete description of CSS, it will give you a good sense of what is going on.  One way the developers of CSS attempted to make the system more complicated was by utilizing a multi-stage decryption process with several sets of keys.  There are three sets of keys associated with the system:

The first step performed in playing your favorite DVD after inserting it in the player is authentication.  The DVD disc and player must set up a trusting relationship.  This is also part of the CSS process which involves the checking and decrypting of keys.  This is a somewhat complicated multi-step process and will only be mentioned in passing.  After successful authentication, another multi-step process takes place to ultimately decrypt the scrambled video data.  The player key is used to decrypt the disc key which in turn is used to decrypt the title key(s) which in turn is used to decrypt the video data [see diagram].

Now for a rough description of the hardware implementation of CSS.  To encrypt a stream of bits (such as the video data), a pseudo-random bit stream must be created and then XORed with the input bits.  This pseudo-random bit stream appears random but is really generated from keys.  The idea behind XORing the input stream and the pseudo-random stream to produce an encrypted output stream, is that it can be "un-XORed" with the original pseudo-random stream to produce the original input stream.  Because the DVD player knows how to re-produce the pseudo-random bit stream by knowing the proper key and decryption scheme, it can decrypt the data on the DVD disc.  The main components in generating the pseudo-random bit stream or "CSS Cipher Stream" are two Linear Feedback Shift Registers (LFSRs) (Don't worry, you don't need to know the details to understand what they're used for).  To generate the CSS Cipher Stream to encrypt the video data, the LFSRs are "seeded" with the title key. [Note: these explanations and diagrams only cover encryption of the video data and do not take into account encryption of disc key, title key, or authentication.  It should stay simpler this way.]  The 17-bit LFSR is seeded with the first two bytes of the title key (16 bits), plus an extra 1-bit to make sure the LFSR doesn't go into "null cycling."  The 25-bit LFSR is seeded with the last three bytes of the title key (24 bits), plus an extra 1-bit as before.  From the 17-bit LFSR there are "taps" off bit registers 1 and 15.   From the 25-bit LFSR there are taps off bit registers 11, 19, 20, and 23.   These taps are XORed (or added with only the least-significant bit kept) and fed back to the input of the LFSR [See diagram].  On each clock cycle, the LFSR "shifts", outputting a bit and taking in a new "feedback" bit.   After 8 clock cycles each LFSR has output 8 bits (equaling one byte).  The two output bytes from the two LFSRs are added together (with the carry bit thrown out) to get the CSS Cipher Stream byte.  This key-generated byte is XORed with the "plaintext" video data to produce the CSS "ciphertext" scrambled data.   Of course, this process continues to encrypt the whole section of video data.  The entire CSS encrypting process takes place right before the DVD is mastered (or "burned") to disc.  This process is essentially un-done by the player when playing your DVD.

Further Research

What you have just read is only a preview of CSS, DeCSS, and the adventures of "DVD Jon."  These topics really touch on all sorts of subjects such as electrical engineering, computer science, cryptography (of course), and legal issues surrounding digital media.  The "Informative Links" below can provide you with a much more in-depth look at these topics.  Thanks for reading.

Informative Links: