Applied Cryptography Spring 2015 DVD and CSS encryption.

Applied Cryptography

Spring 2015

DVD and CSS encryption

What is CSS?

CSS: Content Scramble System.

It is the data scrambling method used to garble the content of a DVD disc.

Data on DVD is protected by CSS,DVD can not be copied.

Only be usable with licensed DVD playback mechanisms.

Windows and MAC have CSS license. Linux does not.

[From Andy Brown et al]

How does CSS work?

Every DVD player on the market today is coded with a small set of "player keys" Every DVD disc on the market today is coded with a "disk key", identifying that disc. When a DVD player attempts to read a DVD, the player uses it's player key and proceeds down the list of encrypted disk keys on the disc .


Disk and player keys Each player has a small number of keys Each disk is encoded using a disk key. Each disk contains a hidden sector. This sector is

pre-written to all 0’s on writable DVDs. This sector holds a table containing the disk key

encrypted will all 409 possible player keys. It also holds the disk key encrypted with the disk

key. The player decrypts the appropriate entry in the

table and then verifies that it has correctly decoding the disk key, by decoding the encrypted disk key.

The encryption mechanism is the same as we discussed earlier for other keys.

[From G.Kesden]

Disk and player Keys

[From F.Stevenson]

Every disk has a disk key data block that is organized as follows:

5 bytes hash of decrypted disk key ( hash ) disk key encrypted with player key 1 (dk1 ) disk key encrypted with player key 2 (dk2 ) ... disk key encrypted with player key 409 (dk409)

Suppose the player has a valid key for slot 213, it will calculate (1) Kd = DA( dk213 , Kp213 )

To verify that Kd is correct, the following check is done, if the checkfails, it will try the next player key.

(2) Kd = DA( hash , Kd )

Data transfer

[From D.Touretzky]

Data transfer

Decrypt disk key Verify disk key (hash) Decrypt the title key Data decrypted by the XOR

of the title key and the sector


System overview

DVD Player

DVD

Hidden Area

Player Keys

“Secret” Key

Region Code

&c

Computer/Host

Bus

“Secret Key”

Bus KeyBus Key

Per title Title Key

Table of Encrypted Disk Keys Disk Key Hash Region Code

[From G.Kesden]

Overview of keysAuthentication Key This “secret” is used as part of the mutual authentication process.Session Key (Bus Key) This key is negotiated during authentication and is used to encrypt the title

and disk keys before sending them over the unprotected bus. The encryption is necessary to prevent eavesdropping.

Player Key This key is Licensed by the “DVD Copy Control Association” to the

manufacturer of a DVD player. It is stored within the player. It is used to establish the trustworthiness of the player. It is used to decrypt the disk key.

Disk Key This key is used to encrypt title key. It is decrypted using the player key.Sector Key Each sector has a 128-byte plain-text header. Bytes 80 - 84 of each

sector’s header contain an additional key used to encode the data within the sector.

Title Key This key is XORed with a per-sector key to encrypt the data within a sector[From G.Kesden]

Overview of processStep 1: Mutual Authentication

The host and the drive use a challenge-response system to establish their trustworthiness to each other. In the process, they negotiate a session key.

Step 2: Decoding disk The DVD player tries each of several player keys until it can

decode the disk key. The disk key is a disk-wide secret.

Step 3: Send disk and title keys The title and bus keys are sent from the player to the host. The

session key is used to encrypt the title and disk keys in transit to prevent a man-in-the-middle attack.

Step 4: The DVD player sends a sector to the host.

Step 5: The host decodes the title key using the disk key.

Step 6: The host decodes the sector using the title key, and a the sector

key in the sector’s header.

[From G.Kesden]

Mutual authentication

[From G.Kesden]


[From G.Kesden]

Before the DVD player will begin to send data over the bus to the host, it first go through a form of weak mutual authentication with the host. In the process, it negotiates a key for use in encrypting the data in transit over the bus. This encryption is necessary because it would otherwise be possible to snoop the plaintext data right off of the bus, rendering the prior encryption virtually useless. The key that is negotiated is known as the session key or bus key.


[From G.Kesden]

The negotiation begins when the host requests an Authentication Grant ID (AGID) from the drive. This ID is much like a session ID or a thread ID. It gives a name to this particular negotiation.

The next thing that happens is the host generates an arbitrary stream of bytes called a nonce or challenge and sends it to the drive. The drive then encrypts this stream of bytes and sends them back to the host. The host then decrypts the byte stream and ensures that it is correct. It assumes that the drive is authentic, because it knew the correct secret and algorithm to encode the nonce.


[From G.Kesden]

The host performs exactly the same operation. It generates a nonce, encrypts it, and sends it to the host. The host in turn encrypts the nonce and sends it back to the drive. The drive then decrypts the nonce and makes sure that it is in fact correct. At this point, both the host and the drive trust each other. This seems to be a fairly weak authentication scheme, because it is based on a secret private key. But this key really can't be all that secret, since it is presumedly in the firmware inside of every DVD player and drive.

Linear Feedback Shift Register (LFSR) Pseudo-random bit stream

One technique used to encode a stream is to XOR it with a pseudo-random bit stream. If this random-looking bit stream can be regenerated by the receiver of the message, the receiver will be able to decode the message by repeating the XOR operation.

Linear Feedback Shift Register (LFSR) The LFSR is one popular technique for generating a pseudo-

random bit stream. After the LFSR is seeded with a value, it can be clocked to generate a stream of bits.

Unfortunately, LFSRs aren’t truly random – they are periodic and will eventually repeat.

In general, the larger the LFSR, the greater its period. There period also depends on the particular configuration of the LFSR.

If the initial value of an LFSR is 0, it will produce only 0’s, this is sometimes called null cycling

LFSRs are often combined through addition, multiplexers, or logic gates, to generate less predictable bit streams.

[From G.Kesden]

Generic LFSR

output

Feedback Functionfeedback path

taps

The register is seeded with an initial value.

At each clock tick, the feedback function is evaluated using the input from the tapped bits. The result is shifted into the leftmost bit of the register. The rightmost bit is shifted into the output.

Depending on the configuration (taps and feedback function), the period can be less than optimal.

[From G.Kesden]

CSS: LFSR-17

garbage

Exclusive Or (XOR)

feedback path

taps

output

115

417

This register is initialized, or salted with two bytes of or derived from the key

During the salting, a 1-bit is injected a bit 4, to ensure that the register doesn’t start out with all 0s and null-cycle.

The value being shifted in is used as the output, not the typical output bit, which in the case of CSS goes off into the ether.

[From G.Kesden]

CSS: LFSR-25

garbage

Exclusive Or (XOR)

feedback path taps

output

115 4

25

This register is initialized, or salted with three bytes of or derived from the key

During the salting, a 1-bit is injected a bit 4, to ensure that the register doesn’t start out with all 0s and null-cycle.

The value being shifted in is used as the output, not the typical output bit, which in the case of CSS goes off into the ether.

5

[From G.Kesden]

CSS: LFSR addition

LFSR-17

LFSR-25

1 byte

1 byte

key

key

Optional bit-wise inverter

+ 8-bit add

carry-out

Output byte

carry-out from prior addition

8 ticks

8 ticksOptional bit-wise inverter

CSS uses a 40-bit, or 5 byte key.

[From G.Kesden]

It is worth noting that this is a pretty week way of using the LFSRs. Other approaches use more LFSRs, and do more complicated things with them, including clocking them at different rates, or combining them using multiplexers -- but not here.

LFSR output inversion

Bit-wise Invert Output Of LFSR

LFSR-17 LFSR-25

Authentication Yes Yes

Session key No No

Title Key No Yes

Data Yes No

[From G.Kesden]

CSS: data decryption

Output byte from LFSRs

Input data byte

Exclusive Or (XOR)Output data byte

Sector LFSR-17 is seeded with bytes 0 and 1 of the title key XORed with byte 80 and 81 of the sector header. A 1 is injected at bit 4, shifting everything right by one bit.

LFSR-25 is seeded with bytes 2, 3, and 4 of title key XORed with bytes 82, 83, and 84 of the sector header. A 1 is injected at bit 4, shifting everything right by one bit.

The output of LFSR-17 is bit-wise inverted before adding to LFSR-25.

Much as with DES, a table-based substitution is performed on the input data.

Table-based substitution

[From G.Kesden]

Much as was the case with DES, bytes of the plaintext are runthrough a table-based S-box prior to the XOR operation. Upon decoding, this operation is reversed. Although the initial permutation substitution in DES was performed to improve the runtime of DES on 8-bit machines, the reason for this substitution is unclear to me. It doesn't appear to me to improve either the runtime or the strength of CSS...

CSS: data decryption

0x33,0x73,0x3b,0x26,0x63,0x23,0x6b,0x76,0x3e,0x7e,0x36,0x2b,0x6e,0x2e,0x66,0x7b, 0xd3,0x93,0xdb,0x06,0x43,0x03,0x4b,0x96,0xde,0x9e,0xd6,0x0b,0x4e,0x0e,0x46,0x9b, 0x57,0x17,0x5f,0x82,0xc7,0x87,0xcf,0x12,0x5a,0x1a,0x52,0x8f,0xca,0x8a,0xc2,0x1f, 0xd9,0x99,0xd1,0x00,0x49,0x09,0x41,0x90,0xd8,0x98,0xd0,0x01,0x48,0x08,0x40,0x91, 0x3d,0x7d,0x35,0x24,0x6d,0x2d,0x65,0x74,0x3c,0x7c,0x34,0x25,0x6c,0x2c,0x64,0x75, 0xdd,0x9d,0xd5,0x04,0x4d,0x0d,0x45,0x94,0xdc,0x9c,0xd4,0x05,0x4c,0x0c,0x44,0x95, 0x59,0x19,0x51,0x80,0xc9,0x89,0xc1,0x10,0x58,0x18,0x50,0x81,0xc8,0x88,0xc0,0x11, 0xd7,0x97,0xdf,0x02,0x47,0x07,0x4f,0x92,0xda,0x9a,0xd2,0x0f,0x4a,0x0a,0x42,0x9f, 0x53,0x13,0x5b,0x86,0xc3,0x83,0xcb,0x16,0x5e,0x1e,0x56,0x8b,0xce,0x8e,0xc6,0x1b, 0xb3,0xf3,0xbb,0xa6,0xe3,0xa3,0xeb,0xf6,0xbe,0xfe,0xb6,0xab,0xee,0xae,0xe6,0xfb, 0x37,0x77,0x3f,0x22,0x67,0x27,0x6f,0x72,0x3a,0x7a,0x32,0x2f,0x6a,0x2a,0x62,0x7f, 0xb9,0xf9,0xb1,0xa0,0xe9,0xa9,0xe1,0xf0,0xb8,0xf8,0xb0,0xa1,0xe8,0xa8,0xe0,0xf1, 0x5d,0x1d,0x55,0x84,0xcd,0x8d,0xc5,0x14,0x5c,0x1c,0x54,0x85,0xcc,0x8c,0xc4,0x15, 0xbd,0xfd,0xb5,0xa4,0xed,0xad,0xe5,0xf4,0xbc,0xfc,0xb4,0xa5,0xec,0xac,0xe4,0xf5, 0x39,0x79,0x31,0x20,0x69,0x29,0x61,0x70,0x38,0x78,0x30,0x21,0x68,0x28,0x60,0x71, 0xb7,0xf7,0xbf,0xa2,0xe7,0xa7,0xef,0xf2,0xba,0xfa,0xb2,0xaf,0xea,0xaa,0xe2,0xff

One of substitution tables

Five different tables are used for different encryption/decryption modes

CSS: key decryption

1 30 2 4

2 41 3 5

Bytes of Ciphertext

Bytes of Plaintext

Table lookup

Table lookup

Table lookup

Table lookup

Table lookup

+ + + + +

Table lookup

Table lookup

Table lookup

Table lookup

Table lookup

+ + + + +

Lk LkLk Lk

Lk

Lk LkLk Lk Lk

Note: Lk is the input byte decrypted using the same scheme as shown for data bytes, with the inverters set for the key type. [From G.Kesden]

Weakness #1: LFSR Cipher Brainless:

240 isn’t really very big – just brainlessly brute-force the keys

With 6 Output Bytes: Guess the initial state of LFSR-17. Clock out 4 bytes. Use those 4 bytes to determine the corresponding 4 bytes of output

from LFSR-25. Use the LFSR-25 output to determine LFSR-25’s state. Clock out 2 bytes on both LFSRs. Verify these two bytes. Celebrate or guess again. This is a 216 attack.

[From G.Kesden]

Weakness #1: LFSR Cipher

[From G.Kesden]

The second attack that we are going to talk about requires 6 bytes of LFSR output. It isn't a terribly useful attack, since we don't usually happen to have six bytes hanging around, but it is interesting to talk about, since it provides a 216 attack on the encryption algorithm. In other words, it allows us to crack the whole 40-bit key, if we have 6 bytes of output and crack the 16-bit (plus 1) register by brute force.

Weakness #2: LFSR Cipher With 5 Output Bytes: Guess the initial state of LFSR-17 Clock out 3 bytes Determine the corresponding output bytes from LFSR-25 This reveals all but the highest-order bit of LFSR-25

Try both possibilities for MSB Clock back 3 bytes Select the setting where bit 4 is 1 (this holds for the initial case). It is possible that both satisfy this – try both.

Verify as before This is a 225 attack

[From G.Kesden]

Weakness #2: LFSR Cipher With 5 Output Bytes: Guess the initial state of LFSR-17 Clock out 3 bytes Determine the corresponding output bytes from LFSR-25 This reveals all but the highest-order bit of LFSR-25

Try both possibilities for MSB Clock back 3 bytes Select the setting where bit 4 is 1 (this holds for the initial case). It is possible that both satisfy this – try both.

Verify as before This is a 225 attack

Less than 1min on 450MHz processor.Ironically, a 450MHz processor was stated as the minimum necessary to decompress a DVD-compliant MPEG-2 videostreamin realtime, which effectively meant that any computer that could play a DVD could crack one.

[From G.Kesden]

Weakness #3: Mangled Output With Known ciphertext and plaintext

Guess Lk4

Work backward and verify input byte This is a 28 attack. Repeat for all 5 bytes – this gives you the 5 bytes of known output for

prior weakness.

This attack can recover 5 bytes of the output of the LFSRs, given both the ciphertext and the plaintext. This 5 bytes can then be used as the 5 output bytes needed for the attack above. Recall the mangling function we talked about earlier. This attack is based on taking a guess and reversing that function. [From G.Kesden]

Weakness #3: Mangled Output

[From A.Stevenson]

Copy protection methods integrated within DVDs

Copy Generation Management System (CGMS) Analog Protection System (APS) Content Scrambling System (CSS)


CGMS

Each sector of a DVD disc includes CGMS that defines how many times the data can be copied.

Three copying “states”:

--copy enable, copy one generation, copy

never Two formats:

--analog(i.e., CGMS-A), digital(i.e., CGMS-D)


APSA method of forcing copies to be degraded or inhibited when copies are made of video signals containing the Macrovision signals.

Two separate technologies:

Automatic Gain Control (AGC)

Color Stripe


CPRM (Content Protection for Recordable Media)CPRM/CPPM is a mechanism for controlling the copying, moving

and deletion of digital media on a host device such as a personal computer, or other digital player. It is a form of Digital Rights Management (DRM) developed by The 4C Entity, LLC (consisting of IBM, Intel, Matsushita and Toshiba).

The CPRM/CPPM Specification defines a renewable cryptographic method for protecting entertainment content when recorded on physical media. The currently implemented method utilizes the Cryptomeria cipher (C2) algorithm for symmetric encryption. The types of physical media supported include, but are not limited to, recordable DVD media and flash memory (note that the available 0.9 revision includes only the portions of the specification covering DVD media). The most widespread use of CPRM is arguably in Secure Digital cards.

CPRM (Content Protection for Recordable Media)The Cryptomeria cipher, commonly referred to as C2, is a

proprietary block cipher defined and licensed by the 4C Entity. It is the successor to CSS algorithm (used for DVD-Video) and was designed for the CPRM/CPPM Digital Rights Management scheme which are used by DRM-restricted Secure Digital cards and DVD-Audio discs.

The C2 symmetric key algorithm is a 10-round Feistel cipher. Like DES, it has a key size of 56 bits and a block size of 64 bits. The encryption and decryption algorithms are available for peer review, but implementations require the so-called "secret constant", the values of the substitution boxes, which are only available under a license from the 4C Entity.

AACS

MKB = Media Key BlockProcess MKB = Subset-Difference Tree systemKm = Media KeyKvu = Volume Unique KeyEncrypted Key = Encrypted Title KeyKt = Title Key

AACS - general scheme

AES-G

AES-G is an AES-based one-way function that takes two inputs of length 128 bits, and produces an output of size 128 bits.

MKB and subset difference module

The idea is this: the truck cannot make tight turns (90 degrees is its best) and it can't go into reverse. When you look at the picture you can imagine to which places the truck can actually drive.

MKB and subset difference module

Device keysAs you can see the truck has to drive north first and then goes south. This is always the case: first north (NE/NW) then south (S/SE/SW).

MKB and subset difference moduleHow the revocation works:

MKB and subset difference moduleBut how we can revoke #1 AND #8?:

MKB and subset difference moduleMultiple levels of trees:

Subset difference revocation scheme

AACS - general scheme

Organization of the disk

AACS - authentication

AACS and “traitor tracing”

Jon Johansen[From Y.Liang]

Jon Johansenvoid CSSdescramble(unsigned char *sec,unsigned char *key) {unsigned int t1,t2,t3,t4,t5,t6; unsigned char *end=sec+0x800; t1=key[0]^sec[0x54]|0x100; t2=key[1]^sec[0x55]; t3=(*((unsigned int *)(key+2)))^(*((unsigned int *)(sec+0x56))); t4=t3&7;t3=t3*2+8-t4;sec+=0x80; t5=0; while(sec!=end) { t4=CSStab2[t2]^CSStab3[t1]; t2=t1>>1; t1=((t1&1)<<8)^t4; t4=CSStab5[t4]; t6=(((((((t3>>3)^t3)>>1)^t3)>>8)^t3)>>5)&0xff; t3=(t3<<8)|t6; t6=CSStab4[t6]; t5+=t6+t4; *sec++=CSStab1[*sec]^(t5&0xff); t5>>=8;}

cladDVD

Shortest CSS C code :)/* efdtt.c Author: Charles M. Hannum <[email protected]> *//* *//* Thanks to Phil Carmody <[email protected]> for additional tweaks. */ /* */ /* Length: 434 bytes (excluding unnecessary newlines) */ /* */ /* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */

#define m(i)(x[i]^s[i+84])<<unsigned char x[5],y,s[2048];main(n){for(read(0,x,5);read(0,s,n=2048);write(1,s,n))if(s[y=s[13]%8+20]/16%4==1){int i=m(1)17^256+m(0)8,k=m(2)0,j=m(4)17^m(3)9^k*2-k%8^8,a=0,c=26;for(s[y]-=16;--c;j*=2)a=a*2î&1,i=i/2^j&1<<24;for(j=127;++j<n;c=c>y)c+=y=iî/8î>>4î>>12,i=i>>8^y<<17,a^=a>>14,y=aâ*8â<<6,a=a>>8^y<<9,k=s [j],k="7Wo~'G_\216"[k&7]+2^"cr3sfw6v;*k+>/n."[k>>4]*2^k*257/8,s[j]=k^(k&k*2&34)*6^c+~y;}}

CSS clothing etc

“Illegal” primes:)

Directly executable code of DECSS for Linux i386

CSS in musical performancesvoid CSSdescramble(unsigned char *sec,unsigned char *key) {unsigned int t1,t2,t3,t4,t5,t6; unsigned char *end=sec+0x800; t1=key[0]^sec[0x54]|0x100; t2=key[1]^sec[0x55]; t3=(*((unsigned int *)(key+2)))^(*((unsigned int *)(sec+0x56))); t4=t3&7;t3=t3*2+8-t4;sec+=0x80; t5=0; while(sec!=end) { t4=CSStab2[t2]^CSStab3[t1]; t2=t1>>1; t1=((t1&1)<<8)^t4; t4=CSStab5[t4]; t6=(((((((t3>>3)^t3)>>1)^t3)>>8)^t3)>>5)&0xff; t3=(t3<<8)|t6; t6=CSStab4[t6]; t5+=t6+t4; *sec++=CSStab1[*sec]^(t5&0xff); t5>>=8;}

Applied Cryptography Spring 2015 DVD and CSS encryption.

Documents

Transcript of Applied Cryptography Spring 2015 DVD and CSS encryption.