1. Applied Cryptography
Spring 2015
DVD and CSS encryption

2. 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]

3. 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 .
[From Andy Brown et al]

4. 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]

5. Disk and player Keys
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 check
fails, it will try the next player key.
(2)        Kd = DA( hash , Kd )
[From F.Stevenson]

6. Data transfer
[From D.Touretzky]

7. 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
[From Andy Brown et al]

8. System overview DVD Player Computer/Host “Secret Key” Player Keys
Region Code
&c
DVD
Hidden Area
Bus Key
Bus
Bus Key
Per title Title Key
Table of Encrypted Disk Keys Disk Key Hash Region Code
[From G.Kesden]

9. Overview of keys Authentication 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 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]

10. Overview of process Step 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]

11. Mutual authentication
[From G.Kesden]

12. Mutual authentication
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]

13. Mutual authentication
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]

14. Mutual authentication
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.
[From G.Kesden]

15. 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]

16. Generic LFSR output taps feedback path Feedback Function
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]

17. CSS: LFSR-17 garbage feedback path taps Exclusive Or (XOR) output4
feedback path
taps 15 1
Exclusive Or (XOR)
output
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]

18. CSS: LFSR-25 garbage feedback path taps Exclusive Or (XOR) output15 5 4 1
taps
Exclusive Or (XOR)
output
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.
[From G.Kesden]

19. CSS: LFSR addition CSS uses a 40-bit, or 5 byte key. key 1 byte
8 ticks
Optional bit-wise inverter
Output byte
+ 8-bit add
key
1 byte
LFSR-25
carry-out
8 ticks
Optional bit-wise inverter
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.
carry-out from prior addition
[From G.Kesden]

20. Bit-wise Invert Output Of LFSR
LFSR output inversion
Bit-wise Invert Output Of LFSR
LFSR-17
LFSR-25
Authentication
Yes
Session key No
Title Key
Data
[From G.Kesden]

21. CSS: data decryption Output byte from LFSRs Output data byte
Much as was the case with DES, bytes of the plaintext are run
through 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...
Output byte from LFSRs
Output data byte
Exclusive Or (XOR)
Table-based substitution
Input data byte
Sector LFSR-17 is seeded with bytes 0 and 1 of the title key XORed with byte 80 and 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.
[From G.Kesden]

22. CSS: data decryption One of substitution tables
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

23. CSS: key decryption Bytes of Ciphertext 1 2 3 4 + + + + + + + + + +1 2 3 4
Table lookup
Table lookup
Table lookup
Table lookup
Table lookup Lk Lk Lk Lk + + + + + Lk
Table lookup
Table lookup
Table lookup
Table lookup
Table lookup Lk Lk Lk Lk Lk + + + + +
Bytes of Plaintext 1 2 3 4 5
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]

24. 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]

25. Weakness #1: LFSR Cipher
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.
[From G.Kesden]

26. 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]

27. 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 videostream
in realtime, which effectively meant that any computer that could play
a DVD could crack one.
[From G.Kesden]

28. 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]

29. Weakness #3: Mangled Output
[From A.Stevenson]

30. Copy protection methods integrated within DVDs
Copy Generation Management System (CGMS)
Analog Protection System (APS)
Content Scrambling System (CSS)
[From Andy Brown et al]

31. 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)
[From Andy Brown et al]

32. APS
A 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
[From Andy Brown et al]

33. 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.

34. 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.

35. AACS

36. AACS

37. AACS
MKB = Media Key Block Process MKB = Subset-Difference Tree system Km = Media Key Kvu = Volume Unique Key Encrypted Key = Encrypted Title Key Kt = Title Key

38. AACS

39. AACS

40. AACS - general scheme

41. 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.

42. AACS

43. AACS

44. 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.

45. MKB and subset difference module
Device keys
As 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).

46. MKB and subset difference module
How the revocation works:

47. MKB and subset difference module
But how we can revoke #1 AND #8?:

48. MKB and subset difference module
Multiple levels of trees:

49. Subset difference revocation scheme

50. Subset difference revocation scheme

51. Subset difference revocation scheme

52. AACS - general scheme

53. Organization of the disk

54. AACS - authentication

55. AACS and “traitor tracing”

56. Jon Johansen Jon Johansen [From Y.Liang]
void 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; }
Jon Johansen
[From Y.Liang]

57. cladDVD

58. Shortest CSS C code :)
/* efdtt.c Author: Charles M. Hannum */
/* */
/* Thanks to Phil Carmody 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^i&1,i=i/2^j&1<<24;for(j=127;++j<n
;c=c>y)c+=y=i^i/8^i>>4^i>>12,i=i>>8^y<<17,a^=a>>14,y=a^a*8^a<<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;}}

59. CSS clothing etc

60. “Illegal” primes:)
Directly executable code of DECSS for Linux i386

61. CSS in musical performances
void 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; }