Friday, August 26, 2005

The DVD Content Scrambling System Explained (Part 4)

In the conclusion to the "DVD Content Scrambling System Explained" series, we'll put together all the information already presented and show how the DVD movie data can be decrypted after the disk and title keys are decrypted. The unencrypted DVD movie data can then be played with any MPEG video player software or hardware chip.

CSS Disk and Title Key Decryption

Disk key decryption (DA) and title key decryption (DB) are done using the same procedure with a different pseudo-random byte streams caused by the mode inversion previously described (in the second part). As well, both functions use different input keys to perform decryption. In the case of decrypting the disk key, the input is the player key. In the case of decrypting the title key, the input is the disk key.

To perform disk key and title key decryption, 5 bytes from the pseudo-random stream are generated, with the stream being seeded by the input key. The five byte output is then passed through the key mangling stage seen in Figure 5. This stage uses the encrypted key, a 256 byte scrambling lookup table, and exclusive or logic to yield the decrypted output key.


Figure 5. Content Scrambling System Disk and Title Key Decryption


CSS Data Decryption

After the disk and title keys have been found, the movie data can finally be decrypted using the function DC seen in Figure 6. When decrypting data, the pseudo-random byte stream is seeded with the sector key exclusively ORed with the title key. The resulting byte from the pseudo-random byte stream is then exclusively ORed with the input byte after the input has first been scrambled by a lookup table. This 256 byte lookup table is the same one that is used for key decryption. The output is now the unencrypted movie data.


Figure 6. Content Scrambling System Data Decryption


< Prev.Jump to Part 1, Part 2, Part 3, Part 4.Next >

Tuesday, August 16, 2005

The DVD Content Scrambling System Explained (Part 3)

In this third part of the "DVD Content Scrambling System Explained" series, we'll examine how the pseudo-random byte generator works. This generator is an essential part of the DVD CSS algorithm and must be examined in detail to understand how decryption is possible.

As was perviously observed, the content scrambling system involves three basic decryption functions: DA, DB, and DC. All three functions involve the same major building block seen in Figure 2. This component produces a stream of bytes that appear to be random, but are repeatable with the same initial seed (with the seed corresponding to the five byte key).


Figure 2: Content Scrambling System Pseudo-random Byte Generator



Mode LFSR17 LFSR25 Seed Value
Disk Key (DA)--Player Key
Title Key (DB)-InvertDisk Key
Data (DC)Invert-(Sector Key) XOR (Title Key)
Figure 3: Differences Between CSS Decryption Modes

This seeding key is fed into two linear feedback shift registers (LFSRs) at the beginning of the process for decrypting a key or decrypting an entire sector. In the case of the 17 bit LFSR, two of the seed bytes are put in the lower 16 bits and a '1' is placed in the most significant bit. In the case of the 25 bit LFSR, two seed bytes are placed in the most significant 16 bits. The lower 9 bits are seeded with another key with its upper 5 bits shifted left and a '1' placed into the 4th bit. The 25 bit LFSR is depicted in Figure 4, with the 3 byte seed value seen in the top of the diagram.

After seeding the LFSRs, the bits are shifted right on each clock tick. The new most significant bit shifted in is comprised of a combination of the current contents of the shift register. In the case of the 25 bit LFSR, bits 0, 3, 4, and 14 go through an exclusive or function to produce the value that is fed back to the most significant bit. This value is also shifted into another shift register to produce an output byte. Much like the 25 bit LFSR, the 17 bit one uses the same logic however bits 0 and 14 go through the exclusive or function.


Figure 4: 25-bit Linear Feedback Shift Register Module

After the two LFSR modules have produced two output bytes, their results are optionally inverted, depending on the decryption mode. Then these bytes are summed with an 8-bit adder. A final resulting byte is produced, with its carry out bit being used as the carry in bit for it next sum. Now that a pseudo random byte has been created, it can be used in the key decryption and data decryption algorithms.


< Prev.Jump to Part 1, Part 2, Part 3, Part 4.Next >

Thursday, August 11, 2005

The DVD Content Scrambling System Explained (Part 2)

In this second part of the "DVD Content Scrambling System Explained" series of posts, we'll examine how the decryption process works. But before we can decrypt a DVD movie's data, a disk key and title key must first be obtained. These two keys are found in an encrypted format on the DVD disk and are 5 bytes in size. The process in which the two keys are decrypted and used to decrypt the movie data is graphically shown below in Figure 1.


Figure 1: Content Scrambling System Key & Data Decryption

The disk key is the first key that must be decrypted. There are 409 different versions of the disk key found on the DVD disc in a hidden sector. Each version of the key can be decrypted to produce the same disk key by using a different DVD player's key. The unencrypted disk key can be found by the function DA using the player key assigned to the DVD player as well as the correct encrypted disk key. To ensure the correct version of the encrypted disk key was used, verification takes place using the DA function using a hash found on the disk as well as the recently decrypted disk key. If the same disk key is returned by the verification then it was decrypted correctly. Otherwise the DVD player will try to decrypt another version of the encrypted disk key, verify it using the hash, and repeat until it obtains the correct, decrypted disk key.

Once the disk key has been obtained, it is used to decrypt a title key. This key is assigned to each "title" on the DVD. Such titles can range from the entire movie to a behind the scenes video. The title key is found in an encrypted form on the disk and must be decrypted by the DB function using the disk key.

Now that the title key has been found, the movie can now be decrypted. The movie’s data is spread out over many 2048 byte sectors on the DVD disk. The movie data, found after the 128 byte sector header, can be decrypted by the function DC using the encrypted data, the title key, and another key called the sector key. This sector key is found in an unencrypted format in bytes 80 to 84 of the sector header.


< Prev.Jump to Part 1, Part 2, Part 3, Part 4.Next >

Tuesday, August 09, 2005

The DVD Content Scrambling System Explained (Part 1)

This next series of posts will explain the DVD Content Scrambling System (CSS), beginning with an overview of what CSS was designed for and how the details of the secret algorithm became to be known. Part 2 will give a functional overview of how DVD movie data can be decrypted only after disk and title keys have first been decrypted. Finally, Parts 3 and 4 will finish by explaining the actual decryption algorithms used for decrypting the two keys and the movie data. I originally wrote all four parts for a university course in which I implemented DeCSS (the CSS decryption procedure) in hardware.

What Is the Content Scrambling System?
Most commercial DVD movies discs are protected by the access control scheme known as Content Scrambling System (CSS). This system was designed to restrict the viewing of a movie to only authorized playback devices. It does this by way of encrypting the movie data and charging manufacturers of DVD playback devices licensing fees for the use of a decryption key, called a player key. In addition to paying for a license, manufacturers must agree to implement several restrictions within in their player to obtain they key. Such restrictions include limiting where in the world the movie can be viewed, preventing the movie from being recorded onto a VHS video cassette by using Macrovision technology, ensuring that certain movie sections cannot be fast forwarded past, etc.

The content scrambling system was also designed to help prevent simple forms of piracy. This is accomplished by storing the movie in an encrypted format. Thus copies of a DVD movie file made to a hard drive or to a writable DVD would not be playable. However it must be stressed that this encryption only prevents casual piracy from taking place. Using professional duplication facilities, one could copy an entire CSS protected DVD disc, including the encrypted movie as well the decryption keys. Commercial DVD burners are in fact restricted, in that they do not allow burning of the decryption keys needed to watch a movie.

Though CSS was initially a closely guarded trade secret, a reverse engineered software implementation of the CSS decryption algorithm was anonymously published on the Internet in 1999 as part of a Linux DVD player project. The Motion Picture Association of America (MPAA) used litigation to try to try to contain the algorithm, filing hundreds of lawsuits including famous cases against a 15 year old Norwegian, a magazine publisher, and a CMU university professor. The action backfired, causing the source code to be widely spread and the algorithm to be well studied. (More history of DeCSS is given in the series A Brief History of DVD Copying)


< Prev.Jump to Part 1, Part 2, Part 3, Part 4.Next >

Friday, August 05, 2005

A Brief History of DVD Copying (Part 3)

On August 17, 2000 U.S. District Judge Lewis Kaplan ruled in favour of eight major motion picture studios in their fight against the magazine 2600's posting of the DeCSS code. Not only did the ruling prevent 2600 from distributing copies of the source doe, but it also prohibited the act of linking to web pages that had the code. The judge also made the incredible statement that "computer code is not purely expressive any more than the assassination of a political figure is purely a political statement." The Electronic Frontier Foundation, which was paying for the defence of 2600, appealed the decision and but was denied the opportunity for a new case less than a year later.

While the 2600 DeCSS court cases were taking place in New York another round of legal battles were taking place in California. This time however the DVD movie trade group was not having any luck. In fact by the time the case had been reached the state's Supreme Court in 2003 (after numerous appeals) the court ruled that the publication of DeCSS information on decoding of DVDs should be protected by freedom of speech laws. Conceding defeat on January 25, 2004 the DVD trade group dropped its suit against a California programmer for posting the DeCSS code, all but giving up all future fights in America.

Half-way around the world, the DVD trade group was had similar results in their court case against Norwegian Jon Johansen. The prosecutors had hoped for a 90-day suspended sentence, confiscation of his computer and the payment of all court costs. Instead the teenager was found innocent of violating computer break-in laws and set free in January 7th, 2003. Their ruling was to the point:

"The court finds that someone who buys a DVD film that has been legally produced has legal access the film. Something else would apply if the film had been an illegal ... pirate copy"

The aftermath of the DeCSS court cases made the code one of the most spread and studied algorithms ever. The legality of the code is still questionable even in 2005. Less than a year ago, the manufacturers of commercial DVD copying program named DVD-X-Copy (which included a DeCSS derivation) had to shut down after being served with several lawsuits from the motion picture industry. As well new technologies have recently been developed that supposedly break DeCSS types of programs from reading and copying DVD movie discs. And several new formats have been proposed to replace DVDs in the upcoming years. These new formats will include much stronger copying protection.