MEDIAGUARD MUSINGS by John MacDonald (y aquí empezó todo)

[V0ldem0rt]

​

Gracias a Karateka, su hilo Info Viejuna y a sus aportaciones, he recordado el artículo de John MacDonald Mediaguard Musings, todos los que empezamos en la época de SECA Mediaguard lo recordaremos(c) como el inicio de todo.

MEDIAGUARD MUSINGS
BY
JOHN MACDONALD


​

This document is a first attempt at describing the digital Pay-TV encryption

system Mediaguard as sold by SECA (Societe Europeene de Controle D'Acces) and

used by some European broadcasters including CANAL+. It's not complete but it

explains the basic concepts and the most important instructions including the

decryption algorithm used and the message signature calculation. More will be

added as other functionality becomes clear.

I have written it for educational purposes only and have kept the description

at a theoretical level so that it is instructive for the reader to compare

and contrast the Mediaguard system with Eurocrypt. In some ways is it very

similar to Eurocrypt in that some concepts remain (eg Issuer, Unique Address,

Shared Address) but in others it is very different (eg Superencryption,

Pay-per-View). As far as I can tell this is the first time that different

systems have been studied to understand the requirements of a modern Pay-TV

encryption system in general. It is not my intention that the information

contained herein is used to break the laws of any country; no key information

is included, nor are any details of how to build working smartcards. It

assumes that the reader is familiar with the Eurocrypt system and uses terms

defined in that system where appropriate without explanation.

The reader should be grateful to Amadeus who has been responsible for much of

the work and to MacDouf who wrote some introductory material originally.



COMMAND STRUCTURE and ANSWER-TO-RESET

The Mediaguard system complies with the ISO 7816 standard for packet structure

and protocol, using 5 byte command headers of the form

CLA, INS, P1, P2, P3.

The only valid instruction class is C1 unlike Eurocrypt which supports both

87 and CA.

The ATR string is typically

3B F7 11 00 01 40 xx xx xx 03 0E 6C B6 D6 90 00

which tells us that the Direct Convention is used (least significant bit

first) at a transmission speed of 9600 baud, unlike Eurocrypt which uses the

Inverse Convention. The 3 masked bytes can vary, but not with each individual

card.



STARTUP

Immediately after the ATR is received the CAM sends the command header

C1 34 00 00 03

to the card which is a request for information. The card responds with 34

(the normal ISO7816 protocol) and receives 3 bytes from the CAM. These bytes

tell the card what information the CAM requires, and at startup they are

always 04 00 01. We'll look at other information requests later.

The CAM then issues

C1 32 00 00 0D

which is a request to send the information. In Mediaguard the C1 34/C1 32

commands act in pairs, the first defining the information and the second

requesting it.

The card responds with

32 B2 <11 data bytes> 04 90 00.

The data bytes can vary but are typically 01 00 00 00 00 00 00 00 00 FF FF.

The dialogue is analagous to the class 87 processing in Eurocrypt, and indeed,

it's possible for the broadcaster to send a command which disables the

startup string in the same way that the FAC block can be disabled in

Eurocrypt thus preventing the card from starting up.



CARD IDENTIFICATION

Each card has a 9-digit number printed on it which, when converted to

hexadecimal gives the 4-byte Unique Address (UA) of the card. Immediately

after the startup sequence the CAM issues

C1 0E 00 00 08

which asks the card to identify itself. The card responds with

0E 00 25 00 00 <UA> 90 00.

I don't know the significance of the first 4 bytes and I have seen other

values for the second byte; maybe its a region code.

Incidentally, facilities exist whereby the broadcaster can update a card's

UA so there should be no need to send out new cards when official cards get

hacked, this can be done over-the-air.



ENTITIES SUPPORTED

As with some Eurocrypt decoders the Mediaguard CAM wants to know at an early

stage how many and which entities are supported by the card. It begins the

process by issuing

C1 16 00 00 07.

The card responds with

16 00 00 <Entity Bitmap> <2 bytes> FF 90 00.

The Entity Bitmap consists of 2 bytes and each bit represents one entity. If

a bit is set the corresponding entity is supported. Entities are numbered from

0 from right to left. So if the Entity Bitmap is 0x03FF entities 0-9 are

supported and entities 11-15 aren't.

The two bytes following the Entity bitmap are usually 0x0000 but represent

various permissions which the card has. A typical C1 16 string is

00 00 0F FF 00 00 FF indicating that 12 entities are supported.

Entity 0 is the card Issuer Entity and entities 1-15 are Programme Provider

Entities such as CANAL+ and CanalSatellite.

Having identified the number of entities supported the CAM now proceeds to

identify them by sending

C1 12 00 00 18.

and the card responds with

12

00 00

53 45 43 41 20 20 20 20 20 20 20 20 20 20 20 20

00 00 00 00 00 00

90 00.

The first two bytes (0x0000) are the Entity Identifier, followed by 16 bytes

of the entity name ('SECA' in ASCII), followed by zeros. The issuer entity is

thus Seca with an ID of 0000. The value of parameter P1 in the C1 12 command

specifies the entity to be displayed.

The CAM then asks for the same information for each of the provider entities

beginning with

C1 12 01 00 18

and could receive

12

00 1C

28 49 29 4d 65 64 69 61 73 65 74 20 20 20 20 20

<UA>

29 9F

90 00.

The provider in this case is (I)Mediaset with an ID of 001C. Note that after

the provider name the card's UA is displayed followed by the subscription

expiry date. By the way, dates are coded exactly the same as in Eurocrypt M

but from a base year of 1990.



SUBSCRIPTIONS SUPPORTED

The last stage in the introductory process is where the CAM identifies which

Packages the card supports for each provider. A Package is a subset of the

total programmes supplied by a provider, but marketed as a single unit. For

example you could subscribe to some film channels, some sport and a nature

channel and pay incremented subscriptions based on your choice. That would

entitle you to view some packages, but not all (eg music). Each provider can

define and market up to 64 packages.

To ascertain the packages subscribed the CAM issues

C1 34 00 00 03

and, as before the card responds '34' to receive 00 00 00.

The CAM then sends

C1 32 P1 00 20

where P1 represents the entity ID.

The card responds with (for example)

32

83 00 00 00 00 00 00 00 07

04 FF FF FF FF FF FF FF FF

FF FF FF FF FF FF FF FF

FF FF FF FF FF FF 90 00.

The card sends '83' followed by the Package Bitmap, then '04' to indicate the

end of the data. The rest is just padding.

The Package Bitmap is similar to the Provider Bitmap; packages are numbered

from 0 from right to left and a set bit indicates that package number is

active. So in the example, packages 0,1 and 2 are active. Note that package

numbers run from 0x00 to 0x3F.

The CAM repeats the C1 34/C1 32 cycle for each entity in the card and has then

completed the long and rather tedious opening sequence.

We can now look at how programme decryption occurs.



ENTITLEMENT CONTROL

Mediaguard's Entitlement Control System is remarkably similar to Eurocrypt's

in that it:

- uses a pair of command headers C1 3C/C1 3A to supply

encrypted data and receive decrypted data just like the

CA 88/CA C0 Eurocrypt pair

- requires two 8-byte control words to be decrypted using

operation keys

- sends entitlement parameters in the data stream for the

card to check against its authorisations

- uses a key-dependent message signature which the card

checks to validate the message before decryption.

It does however contain some 'under the bonnet' tricks which might make it

less easy to hack than Eurocrypt, but time will tell.

Eurocrypt's ECS contains three stages:

- select entity (CA A4)

- send encrypted control words and entitlement data (CA 88)

- receive decrypted control words (CA C0).

Mediaguard only needs two stages since the entity is selected by the use of

parameter P1 for the provider. Also, whereas Eurocrypt's parameters are in the

form ID, Length, Data, Mediaguard's parameter IDs are chosen so that their

length is part of the ID. The most significant nybble of a parameter ID also

determines the length of the parameter data as follows:

Parameter ID Data Length

0x0n to 0xCn 0x00 to 0x0C

0xDn 0x10

0xEn 0x18

0xFn 0x20

where n is some hex value 0-F.

So, for example, parameter 0x71 has 7 bytes of data, but parameter 0xD1 has

16 data bytes.

Every 10 seconds or so the Mediaguard CAM sends a command header like

C1 3C 09 0C 27.

The card responds '3C' and receives data like

71 00 00 19 07 CF 00 04

27 12 89

13 01

D1 FA 55 DA FE 46 B4 E0 95 62 0D 37 9F 66 59 2A 04

82 92 A9 DB E9 C2 9C F4 9D

90 00.

Parameter P1 defines the provider (entity 0x09) and P2 the key to be used for

decryption (0x0C).

Eurocrypt devotees will recognise the pattern here. The data stream consists

of parameter 0x71 (0x00 -> 0x04), parameter 0x27 (0x12 0x89), parameter 0x13

(0x01) parameter 0xD1 (0xFA -> 0x04) and parameter 0x82 (0x92 -> 0x9D). As far

as I can tell the card ignores parameter 0x71, and for many providers it's

always zero. Parameter 0x27 is the transmission date (9th April 1999) and

parameter 0x13 is the package the programme is transmitted in. Parameter 0xD1

is the two 8-byte encrypted control words and parameter 0x82 is the 8-byte

message signature, akin to the Eurocrypt CA 88 hash.

It's pretty obvious what the card does. It first checks the signature, then

tests that the transmission date is before the subscription expiry date for

the provider, then checks the package bitmap that package 0x01 bit is set. It

then decrypts the control words and returns 90 00 when all is done or 9x xx

if any test fails.

Upon receipt of the terminator 90 00 the CAM sends

C1 3A 00 00 10

asking for the two decrypted control words and the card responds with

3A xx xx xx xx xx xx xx xx

xx xx xx xx xx xx xx xx

90 00

at which point the picture and sound appear.

There are 15 parameters which can be used with C1 3C. It's possible to decrypt

a single control word (parameter 0x87). The broadcaster can transmit the

maturity rating of the programme in the data stream (0x12) and the card will

check it against the Reference Maturity Rating if set by a PIN controlled

operation (see later) to enforce parental control. Packages can be promoted to

subscribers via the 0x04 parameter which offers free viewing by bypassing the

package check. Pay-per-View programmes with or without previews can be

controlled with parameters 0x15, 0x19, 0x2C, 0x2D and 0x31. Of these the

Preview parameter 0x19 is the most interesting; the data is a counter which

is decremented every time a C1 3C command is processed and when the counter

is exhausted control word decryption stops.

All of the foregoing raises the question of the algorithms used for control

word decryption and message signature, so let's examine them.



DECRYPTION ALGORITHM

The Mediaguard decryption algorithm operates on an 8-byte crypted word using

a 16-byte key to produce an 8-byte plain word. The 16-byte key consists of an

8-byte Primary key and an 8-byte Secondary key. Sometimes the Secondary key is

the same as the Primary key, at other times it is different. In order to

clarify this confusing situation let's look at keys in more detail.

Both Primary and Secondary keys are numbered from 0x00 to 0x0F so there are

potentially 16 of each. It looks like the operation keys are 0x0C to 0x0F and

that keys 0x00 to 0x0B are management keys. But Primary keys can, at the

broadcaster's whim, be numbered as 0x10 to 0x1F when they are stored in the

card. Only Primary keys so numbered can be used with the equivalent Secondary

key. The P1 parameter of the C1 32 command determines whether this will

happen, if it is of the form 0x1n.

Here's some examples:

C1 32 04 0E P3 Use Primary key 0x0E, 0x0E from provider 0x04

C1 32 14 0E P3 Use Primary key 0x0E, Secondary key 0x0E from

provider 0x04 if Primary key 0x0E is numbered

0x1E; if not, use Primary key 0x0E, 0x0E.

So now you should understand how the 16-byte key is formed for the algorithm.

The algorithm consists of two stages, key preparation and data manipulation.



Key Preparation

Imagine the key bytes are wrapped around like this:

...k15, k16, k1, k2, ..., k13, k14...

Start at k1, take the byte which 'precedes it' (ie k16), XOR this with the

byte which 'follows it' (ie k2) and a constant C. Use this as the index into

the first 256 byte table T1 and XOR the result with k1. This is the new value

of k1. The constant C has an initial value of 0, and table T1 is shown at the

end of the section.

So new k1 = old k1 XOR T1(k16 XOR k2 XOR C).

Follow this process 3 more times on k2-k4 to give:

new k2 = old k2 XOR T1(k1 XOR k3 XOR C)

new k3 = old k3 XOR T1(k2 XOR k4 XOR C)

new k4 = old k4 XOR T1(k3 XOR k5 XOR C).

Increment the constant C and do 4 more rounds on k5-k8 to give:

new k5 = old k5 XOR T1(k4 XOR k6 XOR C)

new k6 = old k6 XOR T1(k5 XOR k7 XOR C)

new k7 = old k7 XOR T1(k6 XOR k8 XOR C)

new k8 = old k8 XOR T1(k7 XOR k9 XOR C)

Increment C again and do 4 more rounds to get values for new k9, k10, k11,

k12. Repeat this last process to get values for new k13, k14, k15 and k16. At

this point C=3.

Increment C to 4 and start at the beginning again and do a complete round for

k1...k16, finishing with C=7.

Do two more complete rounds incrementing C and forming new values for all 16

'k' bytes. At this point C=15 and you've done 16 operations 4 times.

That is the end of the key preparation stage and the final values of

k1,...,k16 are what is used in the data manipulation stage.



Data Manipulation

The algorithm consists of 16 rounds. Each round operates only on 4 key bytes

and 4 data bytes. If the key bytes (after the key preparation stage) are

K1,...,K16 and the data bytes are d1,...,d8:

- rounds 1,5,9,13 use key bytes K13-K16 and data bytes d5-d8

- rounds 2,6,10,14 use K9-K12 and d5-d8

- rounds 3,7,11,15 use K5-K8 and d5-d8

- rounds 4,8,12,16 use K1-K4 and d5-d8.

Each round:

- XORs the key bytes with the data bytes

- performs the core function on the data bytes to give 4 new data

values

- XORs these values with the other 4 data bytes to give the 4 data

values d5-d8 for the next round

- processes the key bytes to give new key bytes for use in a later

round.



Step One - XOR key bytes with data bytes

----------------------------------------

This is simply:

d5 = K(i) XOR d5

d6 = K(i+1) XOR d6

d7 = K(i+2) XOR d7

d8 = K(i+3) XOR d8

where i = 13 for rounds 1,5,9,13

9 for rounds 2,6,10,14

5 for rounds 3,7,11,15

1 for rounds 4,8,12,16.



Step Two - Perform the core function

------------------------------------------

First do 4 table lookups on Table 1:

d5 = T1(d5), d6 = T1(d6), d7 = T1(d7), d8 = T1(d8)

Then use Table 2 (see below) as follows '~' means 'swap nybbles':

d5 = d8 XOR d5

d7 = T2[(~d8) + d7]

d8 = d7 XOR d8

d6 = T2[(~d7) + d6]

d7 = d6 XOR d7

d5 = T2[(~d6) + d5]

Then use Table 1 as follows:

d6 = d5 XOR d6

d8 = T1[(~d5) + d8]

d5 = d8 XOR d5

d7 = T1[(~d8) + d7]

d8 = d7 XOR d8

d6 = T1[(~d7) + d6]

Finally do:

d7 = d6 XOR d7

d6 = d5 XOR d6.

If any of the additions result in a value larger than 0xFF, 0x0100 is

subtracted from the result before performing the table lookup.

Step Three - Get data values for the next round

-----------------------------------------------

These are obtained from Table 2 as follows:

d1 = T2(d6) XOR d1

d2 = T2(d8) XOR d2

d3 = T2(d5) XOR d3

d4 = T2(d7) XOR d4

Data values d1 and d5, d2 and d6, d3 and d7, d4 and d8 are then swapped ready

for the next round.

At the end of the 16th round this swap is not performed and the decrypted

data is d1,...,d8.



Step Four - Get new key bytes for a later round

-----------------------------------------------

Perform the following operations:

K(i+3) = K(i+3) XOR T1[K(i+4) XOR K(i+2) XOR C]

K(i+2) = K(i+2) XOR T1[K(i+3) XOR K(i+1) XOR C]

K(i+1) = K(i+1) XOR T1[K(i+2) XOR K(i) XOR C]

K(i) = K(i) XOR T1[K(i+1) XOR K(i-1) XOR C]

where i = 13 for rounds 1,5,9,13

9 for rounds 2,6,10,14

5 for rounds 3,7,11,15

1 for rounds 4,8,12,16.

Where the above formulas give K suffixes outside the range 1-16, the values

should be wrapped around, eg K17 = K1, K0 = K16.

C is a value based on the round number. For rounds 1,2,...,16 C has the value

0x0F,0x0E,,,0x00.



TABLES

Table 1:

02ah,0e1h,00bh,013h,03eh,06eh,032h,048h

0d3h,031h,008h,08ch,08fh,095h,0bdh,0d0h

0e4h,06dh,050h,081h,020h,030h,0bbh,075h

0f5h,0d4h,07ch,087h,02ch,04eh,0e8h,0f4h

0beh,024h,09eh,04dh,080h,037h,0d2h,05fh

0dbh,004h,07ah,03fh,014h,072h,067h,02dh

0cdh,015h,0a6h,04ch,02eh,03bh,00ch,041h

062h,0fah,0eeh,083h,01eh,0a2h,001h,00eh

07fh,059h,0c9h,0b9h,0c4h,09dh,09bh,01bh

09ch,0cah,0afh,03ch,073h,01ah,065h,0b1h

076h,084h,039h,098h,0e9h,053h,094h,0bah

01dh,029h,0cfh,0b4h,00dh,005h,07dh,0d1h

0d7h,00ah,0a0h,05ch,091h,071h,092h,088h

0abh,093h,011h,08ah,0d6h,05ah,077h,0b5h

0c3h,019h,0c1h,0c7h,08eh,0f9h,0ech,035h

04bh,0cch,0d9h,04ah,018h,023h,09fh,052h

0ddh,0e3h,0adh,07bh,047h,097h,060h,010h

043h,0efh,007h,0a5h,049h,0c6h,0b3h,055h

028h,051h,05dh,064h,066h,0fch,044h,042h

0bch,026h,009h,074h,06fh,0f7h,06bh,04fh

02fh,0f0h,0eah,0b8h,0aeh,0f3h,063h,06ah

056h,0b2h,002h,0d8h,034h,0a4h,000h,0e6h

058h,0ebh,0a3h,082h,085h,045h,0e0h,089h

07eh,0fdh,0f2h,03ah,036h,057h,0ffh,006h

069h,054h,079h,09ah,0b6h,06ch,0dch,08bh

0a7h,01fh,090h,003h,017h,01ch,0edh,0d5h

0aah,05eh,0feh,0dah,078h,0b0h,0bfh,012h

0a8h,022h,021h,03dh,0c2h,0c0h,0b7h,0a9h

0e7h,033h,0fbh,0f1h,070h,0e5h,017h,096h

0f8h,08dh,046h,0a1h,086h,0e2h,040h,038h

0f6h,068h,025h,016h,0ach,061h,027h,0cbh

05bh,0c8h,02bh,00fh,099h,0deh,0ceh,0c5h

Table 2:

0bfh,011h,06dh,0fah,026h,07fh,0f3h,0c8h

09eh,0ddh,03fh,016h,097h,0bdh,008h,080h

051h,042h,093h,049h,05bh,064h,09bh,025h

0f5h,00fh,024h,034h,044h,0b8h,0eeh,02eh

0dah,08fh,031h,0cch,0c0h,05eh,08ah,061h

0a1h,063h,0c7h,0b2h,058h,009h,04dh,046h

081h,082h,068h,04bh,0f6h,0bch,09dh,003h

0ach,091h,0e8h,03dh,094h,037h,0a0h,0bbh

0ceh,0ebh,098h,0d8h,038h,056h,0e9h,06bh

028h,0fdh,084h,0c6h,0cdh,05fh,06eh,0b6h

032h,0f7h,00eh,0f1h,0f8h,054h,0c1h,053h

0f0h,0a7h,095h,07bh,019h,021h,023h,07dh

0e1h,0a9h,075h,03eh,0d6h,0edh,08eh,06fh

0dbh,0b7h,007h,041h,005h,077h,0b4h,02dh

045h,0dfh,029h,022h,043h,089h,083h,0fch

0d5h,0a4h,088h,0d1h,0f4h,055h,04fh,078h

062h,01eh,01dh,0b9h,0e0h,02fh,001h,013h

015h,0e6h,017h,06ah,08dh,00ch,096h,07eh

086h,027h,0a6h,00dh,0b5h,073h,071h,0aah

036h,0d0h,006h,066h,0dch,0b1h,02ah,05ah

072h,0beh,03ah,0c5h,040h,065h,01bh,002h

010h,09fh,03bh,0f9h,02bh,018h,05ch,0d7h

012h,047h,0efh,01ah,087h,0d2h,0c2h,08bh

099h,09ch,0d3h,057h,0e4h,076h,067h,0cah

03ch,0fbh,090h,020h,014h,048h,0c9h,060h

0b0h,070h,04eh,0a2h,0adh,035h,0eah,0c4h

074h,0cbh,039h,0deh,0e7h,0d4h,0a3h,0a5h

004h,092h,08ch,0d9h,07ch,01ch,07ah,0a8h

052h,079h,0f2h,033h,0bah,01fh,030h,09ah

000h,050h,04ch,0ffh,0e5h,0cfh,059h,0c3h

0e3h,00ah,085h,0b3h,0aeh,0ech,00bh,0feh

0e2h,0abh,04ah,0afh,069h,06ch,02ch,05dh



MESSAGE SIGNATURE ALGORITHM

It looks like only one signature algorithm is used for both ECM and EMM

messages.

The procedure consists of the following steps:

- initialisation of an 8-byte hash buffer

- XORing of 8 input data bytes with the buffer contents

- execution of the signature algorithm

- repetition of the last 2 steps until all input bytes have been

processed

- comparison of the result with the 8 signature data bytes.

The signature algorithm is the reverse of the decryption algorithm (like

Eurocrypt S), so I don't need to describe it in so much detail as the

decryption algorithm.

The hash buffer is initialised based on the value of the most significant

bits 7-5 of parameter P1 as follows:

- P1(7-5) = 1: initialise to (last 6 bytes of the C1 0E 00 00 08

response),0,0

- P1(7-5) = 2: initialise to the card UA

- P1(7-5) = 3: initialise to the card SA (see below)

- P1(7-5) = any other value: initialise to zero.

The algorithm consists of 16 rounds. Each round operates only on 4 key bytes

and 4 data bytes. If the key bytes (after the key preparation stage) are

K1,...,K16 and the data bytes are d1,...,d8:

- rounds 1,5,9,13 use key bytes K1-K4 and data bytes d5-d8

- rounds 2,6,10,14 use K5-K8 and d5-d8

- rounds 3,7,11,15 use K9-K12 and d5-d8

- rounds 4,8,12,16 use K13-K16 and d5-d8.

Each round:

- processes the key bytes to give new key bytes for use in a later

round

- XORs the key bytes with the data bytes

- performs the core function on the data bytes to give 4 new data

values

- XORs these values with the other 4 data bytes to give the 4 data

values d5-d8 for the next round.

The order of operations is slightly different to the decryption order since

the process is the reverse of the decryption process. Its similar to the

'left shifts, DES function' and 'DES function, right shifts' in Eurocrypt M

and S.



Step One - Get new key bytes for a later round

-----------------------------------------------

Perform the following operations:

K(i) = K(i) XOR T1[K(i+1) XOR K(i-1) XOR C]

K(i+1) = K(i+1) XOR T1[K(i+2) XOR K(i) XOR C]

K(i+2) = K(i+2) XOR T1[K(i+3) XOR K(i+1) XOR C]

K(i+3) = K(i+3) XOR T1[K(i+4) XOR K(i+2) XOR C]

where i = 1 for rounds 1,5,9,13

5 for rounds 2,6,10,14

9 for rounds 3,7,11,15

13 for rounds 4,8,12,16.

Where the above formulas give K suffixes outside the range 1-16, the values

should be wrapped around, eg K17 = K1, K0 = K16.

C is a value based on the round number. For rounds 1,2,...,16 C has the value

0x00, 0x01,...0x0F

This is unwinding the effects of the round key manipulation in the decryption

algorithm.



Step Two - XOR key bytes with data bytes

----------------------------------------

This is simply:

d5 = K(i) XOR d5

d6 = K(i+1) XOR d6

d7 = K(i+2) XOR d7

d8 = K(i+3) XOR d8

where i = 1 for rounds 1,5,9,13

5 for rounds 2,6,10,14

9 for rounds 3,7,11,15

13 for rounds 4,8,12,16.

The reversing of the suffix values unwinds the interaction of key and data

bytes compared to the decryption algorithm.



Step Three - Perform the core function

------------------------------------------

First do 4 table lookups on Table 1:

d5 = T1(d5), d6 = T1(d6), d7 = T1(d7), d8 = T1(d8)

Then use Table 2 as follows '~' means 'swap nybbles':

d5 = d8 XOR d5

d7 = T2[(~d8) + d7]

d8 = d7 XOR d8

d6 = T2[(~d7) + d6]

d7 = d6 XOR d7

d5 = T2[(~d6) + d5]

Then use Table 1 as follows:

d6 = d5 XOR d6

d8 = T1[(~d5) + d8]

d5 = d8 XOR d5

d7 = T1[(~d8) + d7]

d8 = d7 XOR d8

d6 = T1[(~d7) + d6]

Finally do:

d7 = d6 XOR d7

d6 = d5 XOR d6.

This is identical to the decryption core function, but clearly it's 'working

in the opposite direction'.



Step Four - Get data values for the next round

-----------------------------------------------

These are obtained from Table 2 as follows:

d1 = T2(d6) XOR d1

d2 = T2(d8) XOR d2

d3 = T2(d5) XOR d3

d4 = T2(d7) XOR d4

Data values d1 and d5, d2 and d6, d3 and d7, d4 and d8 are then swapped ready

for the next round.

At the end of the 16th round this swap is not performed and the signature

total is d1,...,d8 which should equal the 8 bytes following the 0x82

parameter.

I know all this stuff looks pretty daunting, but if you follow it through with

an example, you'll soon see what's going on.

To summarise, we can say that control word decryption is Mediaguard DEcryption

but message signature is Mediaguard ENcryption. The keys stored are for direct

use with Mediaguard Encryption and in each round a round key R is generated

for that round.

So we can say that the Encryption algorithm operates on round keys

R1,R2,...,R16.

The Decryption algorithm is the reverse of Encryption; the purpose of the key

preparation stage is to generate R16. In each Decryption round a round key is

generated for the next round. The round keys for Decryption are

R16,R15,...,R1. The whole procedure ensures that Decryption is exactly the

reverse of Encryption.

By the way, if anyone recognises the algorithm and its name, perhaps they'd be

kind enough to let me know.



PIN CONTROLLED OPERATIONS

The Mediaguard system protects some transactions with a PIN code to ensure

that they are performed by the subscriber only. The command C1 30 handles PIN

controlled activity.

Three variations are possible

1) C1 30 00 00 10

is issued by the CAM following a dialogue with a subscriber who wants to

create or update their PIN. The card responds with '30' and receives

00 00 00 00 00 00 xx xx 00 00 00 00 00 00 yy yy

90 00

where xx xx and yy yy are the old and new PIN. If the old PIN is incorrect the

card returns 90 10.

2) The CAM issues

C1 30 00 01 09

when a subscriber wishes to change the Reference Maturity Rating. This time

the card receives

00 00 00 00 00 00 xx xx yy

90 00

where xx xx is the PIN and yy is the new Reference Maturity Rating.

3) The CAM issues

C1 30 00 02 09

when a subscriber wants to purchase something, eg a PPV programme or some

tokens for later use. Then the card receives

00 00 00 00 00 00 xx xx yy

90 00

where xx xx is the PIN and yy is an authorisation code. The authorisation code

permits the card to process a subsequent purchase transaction.



ENTITLEMENT MANAGEMENT

Entitlement Management messages are mainly implemented by the C1 40 command.

The facilities offered are rich and powerful, with far more flexibilty than

those in Eurocrypt. Some concepts remain however; updates may be to an

individual card, to a group of cards or to all cards just as in Eurocrypt.

Each card belongs to a SA (the first 3 bytes of the UA) with 256 members of a

SA as in Eurocrypt M; a SA bitmap of subscriber activity is also used to check

that a shared update is for an individual subscriber, using a CUSTWP byte

which is the last byte of the UA. The SA bitmap is conveyed in the C1 40

datastream however, which accounts for why these strings are much longer than

Eurocrypt. Remember in the latter, the SA bitmap is in a separate command

(CA F0).

All in all, the C1 40 command supports 33 parameters which permits a wide

variety of updates from single keys to complete providers. There are many more

options than Eurocrypt for deleting keys, packages, providers, PPV events and

subscriptions which must make it very difficult to 'switch on' an expired

card.

I will focus on the more common and interesting parameters.

If you look at a typical C1 40 command it could be

C1 40 19 82 35

and after the card responds with '40' the CAM sends a data stream like

96 E8 5D 3B 97 26 6E B1

82 0F 87 17 D3 5C 87 47

34 5E 39 79 2F 8E 84 4C

16 E2 3A 6A A3 40 30 C9

05 5F BB 01 56 11 7C 4F

BF 1F C3 32 21 BD 13 D9

60 53 25 CB 9E

90 00.

There's no discernible pattern in the packet because the data is encrypted

using Primary key 02 (and maybe Secondary key 02) for Provider 09. This

technique is called Superencryption and it means that encrypted data (such as

operation keys) is encrypted again before transmission. Superencryption is

used when the most significant bit of P2 is set in the C1 40 command, and it's

used to make it hard for anyone to understand what the data is, although

experienced hackers will know that it doesn't necessarily make the hacking

process any more difficult.

So the card takes each block of 8 bytes and decrypts it using the Mediaguard

decryption algorithm (leaving the last 5 bytes alone) to obtain a packet which

does have the usual structure. Typical parameters obtained in this way could

be:

0x21, 0x22 xx xx subscription

0x30, 0x32 xx xx xx PPV details

0x42, 0x43 xx xx xx xx of various sorts

0x41 xx xx xx xx UA

0x80 (8 bytes) package bitmap for provider

0x90 (9 bytes) primary key

0x91 (9 bytes) secondary key

0xd0 (16 bytes) provider label

0xf0 (32 bytes) SA bitmap

and finally

0x82 (8 bytes) message signature.

In addition, it is possible to use parameters 0xD1 (two encrypted control

words) and 0x87 (one encrypted control word) with C1 40. There are other

parameters as well which will delete a PIN, delete keys, PPV events and so on.

The two key parameters 0x90 and 0x91 contain a key index and 8 bytes of

encrypted key data which is decrypted using the Mediaguard decryption

algorithm as described earlier.

Updates may be addressed to all subscribers, a group of subscribers, or a

single subscriber depending on the values of the most significant 3 bits of

parameter P1 as described earlier. In each of the four cases the signature

hash buffer is initialised to a different value. The message signature for

C1 40 command is based upon the Mediaguard encryption algorithm also as

described earlier.

That completes the description of the mainstream functionality of Mediaguard;

I'll summarise next other features which are either of marginal interest or

need more work to understand.

OTHER FACILITIES

It is possible to see which keys are in a card by using the C1 34 command with

parameters 06 00 01 followed by C1 32 P1 00 12 repeatedly where P1 is the

provider number. However you'll need to know something of the internal record

structure to make sense of the results and key data is blanked out as 8 0xFF

bytes anyway.

It may be possible to send a command to the card which changes its mode so

that it has a slightly different ATR. In this mode the command C1 44 can be

used (and several others). These commands change the card's functionality and

allow alternative ways of doing things with some clever encryption. I'm not

clear whether the card mode is there to provide a built-in ECM capability or

for personalising, validation and testing purposes.

Finally, more work needs to be done to understand the exact minutiae of PPV;

when this is clear I'll update the document.





On a final note, if anyone publishes any software or web site information as

a result of reading this paper, perhaps they would do me the courtesy of

acknowledging this paper as their reference, and send me if possible, a copy

of their programs.

Enjoy.



John MacDonald

September 1999