EVRYTHING YOU WANTED TO KNOW ABOUT EUROCRYPT
BUT
WERE AFRAID NOBODY WOULD TELL YOU
BY
JOHN MACDONALD
This file contains everything I know about the Eurocrypt TV scrambling
system. I have built this knowledge up from scratch by reading articles
(very few and far between), disassembling PIC programs and then working out
what they do (interesting) and watching decoder<->card traffic using a
season-type PC interface (lots of tripping over cables and running between
rooms). Its not complete, but there's more in it than I've seen anywhere else.
I have written this for two reasons:
1 If any of this is new to you, I hope you find it useful,
enjoyable and instructive.
2 If you know more than this, please share it with me and I
will update/correct this to form what will hopefully become
a definitive document on the subject.
You can contact me on the BBS where you found this file.
I'll describe the DC<->card protocol, what each instruction does, and how
the DES-based decryption algorithm works for Eurocrypt M and S2. Unless
specified, all numbers are in hex.
1 The Decoder<->Card Protocol
When you insert the card into the DC the DC sends a signal down the reset
line as per the ISO 7816 standard and waits for the card to respond. The
card sends an answer-to-reset sequence of bytes (ATR) which tells the DC
information about the behaviour of the card itself, such as transmission
parameters, manufacturing details etc.
For Eurocrypt, the ATR seems to be the 9 byte sequence
3f 67 2f 00 11 14 00 03 68
For anyone who is interested in the nitty-gritty of this, there's a very
good explanation in a file called atr.zip written by JC, available on BBSs
and the web.
The ISO standard defines that the DC addresses the card by sending a 5 byte
header to it containing:
INSTRUCTION CLASS
INSTRUCTION CODE
followed by 3 parameters usually called P1, P2, P3.
The instruction class is either 87 or ca and can be ignored (I'm not sure
of its significance) and the P3 byte is usually a length byte denoting the
number of bytes to follow or the number of bytes expected to be received
by the DC.
How the card behaves depends upon the values of the 5 byte header, but it
usually sends at some point a 2 byte message called SW1, SW2. This is 90 00
meaning the instruction in the header executed OK or 90 08 meaning there
was some kind of error. This SW1, SW2 message is also sent at the end of the
ATR.
2 Instruction Processing
INSTRUCTION 02
After receiving the ATR, the DC sends instruction 02 as:
87 02 00 00 03
The 02 instruction seems to be sending 3 bytes to the card - what these mean
I've no idea. So to process an 02 instruction, if P3<>0 send 02 to the DC
as an acknowledgement, then get P3 bytes (3 in the example). If any of these
bytes are 40 then send 90 08, else send 90 00.
INSTRUCTION 04
Next the DC sends a packet like
87 04 00 00 07
The 04 instruction is requesting some result from the card following the 02
instruction. So first acknowledge by sending 04 (if P3<>0). All the PIC code
I've looked at sends a fixed message
00 15 00 00 followed by 3 padding bytes such as ff
I don't know what this means. Finally, 90 00 is sent.
INSTRUCTION 06
The DC then sends
87 06 00 00 04
which is asking for a block of data from the card. Again, all the PIC
programs send
10 02 ca 20 ff
followed by 90 00.
I guess this sequence of 02, 04, 06 is some kind of authentication of the
card and the fixed sequences give the right answers.
From here on in the instruction class changes to ca.
INSTRUCTION A4
The a4 instruction is used to give the card information about the channel's
identity which is used by the card for key selection, expiry data,
entitlements, parental control and pay-per-view (PPV) controls. There are
several forms of this instruction - we'll concentrate on the form for
channel identification and come back to the others later.
The DC sends
ca a4 04 00 03
which tells the card that 3 bytes are to be received which indicate the
channel's id. So since P3<>0 (3 in this case) send a4 to the DC then
receive the three bytes. Then send 90 00. I think that if you send 90 08
the DC displays the 'no access' message but I haven't tested this.
Actually the 3 bytes can identify a channel or a group of channels -
for example, all the TV3s are 00 04 00 and CANAL+ is 10 00 20. Card programs
typically use this data to construct a byte between 1 and n where n is
the number of ids supported by the card. We'll call this byte CHAN# and use
it later on.
INSTRUCTION 88
Immediately after the a4 instruction the DC sends a packet like
ca 88 00 08 24
88 instruction processing is the main decoding work done by the card
protocol handler. The P2 byte (08 in the example) is the key number to be
used to decode the encrypted data obtained shortly. Each channel has a
number of 7 byte keys which are used in the decryption and this byte defines
which one is to be used. If the card doesn't have this key stored in its
memory then no decryption can occur! The P3 byte indicates the number of
bytes to be received by the card, in this example hex 24 ie decimal 36.
In the 24 byte string are two encrypted 8 byte words which have to be
decrypted using the 7 byte key. Obviously, the P2 and P3 values vary from
channel to channel and time to time.
The card must send 77 to the DC in order to receive one of the P3 (24) bytes.
It must do this repetitively until there are 8 bytes left, then it must send
89 and receive the last 8 bytes directly. Finally the card sends 90 00.
A typical string obtained in this way would be (broken in to substrings for
readibility)
df 00
e1 04 20 21 ff 7f
ea 10 ca a8 e2 1b 4b 7b db 66 8c 29 0a 3b 32 4d 61 5f
f0 08 8a 18 2d 8b 91 e2 cd 84
Byte 2 always seems to be zero, and the 4th byte indicates the length of the
next substring and I think is always 4 though I haven't checked this
exhaustively. Bytes 5 and 6 represent a date with the first 7 bits being
the year from 1980, the next 4 bits the month and the last 5 the day of
the month. So the date shown (20 21) is year 0010000 or decimal 16,
month 0001 or 1, and day 00001 or 1 ie January 1 1996. Bytes 7 and 8 are
theme and level.
The substring beginning ea contains a length byte (10 or decimal 16)
followed by 2 8 byte words. These are the 2 encrypted words which have
to be decrypted into 2 8 byte plain words by the card using the 7 byte key
defined in the 88 packet for the channel defined in the preceding A4
instruction. I'll explain how this is done later.
The substring beginning f0 contains a length byte (08) followed by 8 bytes.
This is some kind of checksum which is compared with another bit of
decryption to verify the result, but I'm not sure of the details.
There are variations on this string which cause lots of complexity in the
PIC code I've examined, but basically the idea is straightforward.
INSTRUCTION C0
Immediately after the exchange described in the last section the DC sends
the following packet
ca c0 00 00 12
This instruction is asking the card to send the two plain words to the DC
and if these are correct, the picture is unscrambled. (Hooray!)
The card should first send c0 acknowledging the instruction then ea 10,
followed by the 10 (decimal 16) bytes of plain data. This equates to the
12 bytes requested in P3.
I have seen another form of the c0 instruction, namely
ca c0 00 00 06
From examination of PIC code it seems that this instruction is asking the
card to send the 3 bytes of channel identification (obtained via the a4 04
instruction) followed by 20 00 8f. I don't know what these last 3 bytes mean.
INSTRUCTION 18
Some of you may wonder how the auto-update feature on twin PIC cards works,
where (usually once a month) the card can deduce what the new key is for
CANAL+ and Cine Cinemas. Well, this is where the 18 instruction comes in.
Prominent in the DC<->card traffic for these channels is a packet like
ca 18 00 06 29
The P2 byte (06 in the example) is the key number to be used to decode the
encrypted data obtained shortly in order to obtain the new key. If the
card doesn't have this key stored in its memory then no decryption can occur
and the auto-update won't work. For a reason I don't know, CANAL+ and Cine
Cinemas use keys 05 and 06 only for this purpose. Therefore in all the PIC
programs I've examined, these keys are present with space in the EEPROM for
the new keys when they've been found.
The P3 byte indicates the number of bytes to be received by the card, in
this example hex 29 ie decimal 41.
In the 29 byte string is an encrypted 8 byte word which has to be decrypted
using the 7 byte 06 key. The result of this operation is an 8 byte plain
word of which the first 7 bytes are the new key.
Obviously, the P2 and P3 values vary from channel to channel and time to time.
The string of length P3 (29 in the example) is obtained in exactly the same
way as for instruction 88 except that e7 is used instead of 77 to get a
byte from the DC and 19 is used instead of 89 to get the last 8 bytes.
A typical string obtained in this way would be (broken into substrings
for readibility)
a0 01 22
a1 03 10 00 36
a8 06 20 31 20 36 ff ff
a1 03 10 00 39
ef 08 14 c4 cb d7 2c 16 1a f2
f0 08 aa fa 7f c8 b2 65 db 4a
Byte 2 is the length of the first substring- I don't know the significance
of this. Byte 5 is the length of the second substring which contains the
channel id bytes (10 00 30 for Cine Cinemas) concatenated with the base key
to be used (06 in this case). The next substring is preceded by type and
length bytes followed by what look like 2 dates (17th and 22nd Jan 1996)
followed by either theme and level bytes or just ff padding.
The fourth substring is similar to the second except that it contains the
number of the new key to be obtained (09 in the example). The fifth
substring (after the type and length bytes) is a 8 byte encrypted word.
When this is fed through the decryption algorithm (see later) with the base
key (06) a 8 byte plain word is obtained, the first 7 bytes of which are
the new key (09).
Given the foregoing, I can't see the need for a touch pad on the twin PIC
card, since the program can find the new key for itself when necessary -
perhaps someone can enlighten me.
The last substring is a checksum as per the 88 instruction.
Again there are variations in the number and length of substrings which
can appear, and most of the complexity (and amateurish code) in the PIC
programs I've seen is trying to cope with all the variations of 18 and
88 substrings with one piece of code. There must be lots of simple ECMs
which would break this code very easily.
REMOTE CONTROL INTERFACE
There are some instructions which are only used when the remote control is
used (on mine its a PPV button) for display, parental lock, consultation
and PPV purposes. The exact display format of these depends on the DC used,
but this section describes how the DC<->traffic works. Of course if you're
only interested in decryption you don't need to implement any of this.
The instructions used are AC, B8, 24 and two variations of the A4 instruction.
The P1 parameter varies in these instructions and acts as a sub-instruction.
I'm going to assume that the card sends the instruction to the DC whenever
P3<>0 as an acknowledgement and that it terminates with 90 00 as before.
PPV (or whatever its called on your handset)
When you ask for a display via the handset the decoder sends the following
packets
ca a4 00 00 00
ca ac 08 00 00
ca b8 00 00 03
Remember CHANN# described when we discussed the a4 04 instruction? Well, the
a4 00 instruction tells the card to zeroise this number. The ac 08
instruction tells the card to select the Lock Status (whatever that is!) and
the b8 is asking for 3 bytes from the card, presumably the Lock status. The
card that I monitored sent 08 01 08 to the DC which then issued
ca a4 00 00 00
ca 24 00 00 09
I'm not sure what is happening here, but the card sent 25 and the DC then
sent 00 00 00 00 00 00 00 00 08 to the card.
CONSULTATION
When you take the consultation option from the main menu, the DC sends the
following packet
ca a4 00 00 00
to clear CHANN#, then
ca a4 02 00 00
ca ac a7 00 00
ca b8 00 00 12
which we'll call Packet A.
The a4 02 instruction tells the card to increment CHANN# by 1, the ac a7
instruction asks the card to select the Label for that channel, and the b8
instruction asks the card to send back 12 (decimal 18) bytes containing
the channel Label (eg the literal TV 1000). The card should send a7 as an
acknowledgement, 10 as a length byte, 0e Label bytes padded as necessary,
and 00 00.
The DC continues to send Packet A until the supported limit of CHANN# is
exceeded, although its not exactly clear how this sequence terminates.
CONSULTATION - CHANNEL SELECT
You use the down arrow keys on your handset to select the channel you wish
to consult and press a select key. The DC sends the following
ca a4 00 00 00
to clear CHANN# followed by
ca a4 02 00 00
for each time you pressed the down arrow on your remote. This enables the
card to increment CHANN# to the correct value for the channel selected. The
DC then sends
ca ac a7 00 00
ca b8 00 00 12
requesting the channel Label and the card reponds as with Packet A.
Let's call this sequence Packet B. The DC then sends
ca ac ac 00 00
ca ac b1 00 00
ca ac b2 00 00
ca ac ad 00 00
I've no idea what this does.
SUBSCRIPTION
When you take the Subscription option, Packet B is invoked followed by
ca ac a8 00 04
from the DC. The ac a8 instruction is asking for 2 dates (4 bytes) from
the card, presumably subscription start/end dates. The card responds with
(for example) 00 21 27 9f (Jan 1st 1989 and Dec 31st 1999). The DC then
sends
ca b8 00 00 08
asking for 8 bytes containg subscription data. The card I monitored sent
a8 for acknowledgement, 06 as a length byte followed by 00 21 ff 9f ff ff.
presumably this was 2 dates (Jan 1st 1980 and Dec 31st 2007) followed by
theme and level bytes.
SUBSCRIPTION/LINK
I don't even know what this means, but the DC<->card traffic is Packet B to
get the channel Label, then the DC sends
ca ac a9 00 04
to which the card sends 4 date bytes, then the DC sends
ca b8 00 00 02
asking for 2 data bytes. The card sends a9 05, then the DC sends
ca b8 00 00 05
and the card I monitored sent 00 21 ff 9f bc which was 4 date bytes
followed by a class byte (whatever that is).
PREBOOKED PPV
When this option is taken, the traffic is Packet B to get the Label, then
the DC sends
ca ac aa 00 06
presumably asking for 6 bytes containing the PPV pool value. The card I
monitored sent 00 00 00 ff ff ff which is probably some big number.
IMPULSE PPV
I observed this to be the same as for Prebooked PPV except that the ac
subinstruction was e4 not aa. The DC also responded with the 4 packet
sequence at the end of Consultation - Channel Select above.
ACCESS CONTROL
My DC supports four locks, PPV, Consultation, Parental Control and New
Secret Code and these are independent of any channel so no Packet B
processing is apparent. In each case the DC cleared CHANN# with the
ca a4 00 00 00 packet first.
PPV LOCK
When I took the unlock option the DC sent
ca 24 00 00 09
to the card which then received 8 zero bytes followed by 09. This
presumably would write some data to a genuine card.
CONSULTATION LOCK
This was as for PPV Lock.
PARENTAL CONTROL
The DC sent
ca ac 06 00 00
which is asking the card to selct a Maturity Rating (Universal, PG etc),
followed by
ca b8 00 00 03
to which the card responded with 06 01 06. I would have thought the DC
would send a 24 instruction to update the card with the Maturity
rating selected from the onscreen menu, but I didn't observe this.
NEW SECRET CODE
The dialogue is as per the PPV Lock then the DC sends
ca 24 01 00 10
and the card receives 0e bytes of zero followed by a four-nybble secret
code.
INSTRUCTION 26
This instruction is catered for in the PIC code I've examined, but I've
never monitored its purpose. All the PIC code does is send 6e 90 00 to
the DC.
THE DECRYPTION SYSTEM
So far I've described how the key for a channel is obtained, how the two
encrypted words are obtained, and how the decrypted words are sent to the
DC. The next sections deal with the algorithm which is applied to the key
and an encrypted word to obtain a decrypted word.
The algorithm is based upon the Data Encryption Standard originally
created for the secure transmission of military data. There is a very good
scholarly paper on this standard in a file called des-how-.txt by Matthew
Fischer of The University of Iowa on the Web and BBSs which is worth a read.
The Eurocrypt system has two flavours, Eurocrypt-M and Eurocrypt-S2 which are
currently used by TV channels. I'll describe M first, then S2.
In this section all numbers are decimal unless stated otherwise, not hex.
EUROCRYPT-M
The main steps in the process are:
- key preparation
- data word manipulation
- process iteration.
In other words, we perform some operations on the key, then manipulate
the data word, do some interaction between the two (based on exclusive
ORing) and repeat the process several times until we have the decrypted
word. In fact the process is performed (decimal) 16 times.
KEY PREPARATION
This is very straightforward. We have a 7 byte or 56 bit key which we split
into two 28 bit halves and we rotate each half 1 or 2 bits to the left
depending which of the 16 rounds we're on then put the two halves together.
A single rotation left means that the first (most significant or left hand)
bit moves to the last (least significant or right hand) position and all the
other bits move one to the left.
The exact number of left rotations is determined by the table:
Round 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
No of rotations 1 1 2 2 2 2 2 2 1 2 2 2 2 2 2 1
We then create a new 48 bit key by reordering 48 of the bits in the 56 bit
shifted key according to the pattern:
14 17 11 24 1 5
3 28 15 6 21 10
23 19 12 4 26 8
16 7 27 20 13 2
41 52 31 37 47 55
30 40 51 45 33 48
44 49 39 56 34 53
46 42 50 36 29 32
This means that the new 1st bit is the 14th old bit, new 2nd bit is old 17th
and so on with the new 48th bit being the old 32nd bit. The old bits 9, 18,
22, 25, 35, 38, 43, 54 are not used. This operation is called a Permutation
and the table is called Permuted Choice 2 or PC-2 in DES terminology.
Preparation of the key is now complete for a single round. Note that net
result is that we have a new 48 bit key for use later on.
DATA WORD MANIPULATION
The encrypted data word is 8 bytes or 64 bits long. The first thing to do is
to split this into two halves each 32 bits long called L and R. Then we
build a new R called R1 of length 48 bits by using the pattern:
32 1 2 3 4 5
4 5 6 7 8 9
8 9 10 11 12 13
12 13 14 15 16 17
16 17 18 19 20 21
20 21 22 23 24 25
24 25 26 27 28 29
28 29 30 31 32 1
This means our R1 has its 1st bit as old R's last bit, its 2nd bit as old
R's 1st bit and so on with its last bit being the ols R's 1st bit. As you
can see, some of old R's bits are used more than once. The table is called
the Expansion or E-Table.
We now XOR this 48 bit R1 with the 48 bit key we prepared earlier, and we
split the result up into eight 6-bit blocks. Each of these blocks is used
to locate an entry in one of the eight tables below, called Substitution
or S-Boxes.
Substitution Box 1
14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13
Substitution Box 2
15 1 8 14 6 11 3 4 9 7 2 13 12 0 5 10
3 13 4 7 15 2 8 14 12 0 1 10 6 9 11 5
0 14 7 11 10 4 13 1 5 8 12 6 9 3 2 15
13 8 10 1 3 15 4 2 11 6 7 12 0 5 14 9
Substitution Box 3
10 0 9 14 6 3 15 5 1 13 12 7 11 4 2 8
13 7 0 9 3 4 6 10 2 8 5 14 12 11 15 1
13 6 4 9 8 15 3 0 11 1 2 12 5 10 14 7
1 10 13 0 6 9 8 7 4 15 14 3 11 5 2 12
Substitution Box 4
7 13 14 3 0 6 9 10 1 2 8 5 11 12 4 15
13 8 11 5 6 15 0 3 4 7 2 12 1 10 14 9
10 6 9 0 12 11 7 13 15 1 3 14 5 2 8 4
3 15 0 6 10 1 13 8 9 4 5 11 12 7 2 14
Substitution Box 5
2 12 4 1 7 10 11 6 8 5 3 15 13 0 14 9
14 11 2 12 4 7 13 1 5 0 15 10 3 9 8 6
4 2 1 11 10 13 7 8 15 9 12 5 6 3 0 14
11 8 12 7 1 14 2 13 6 15 0 9 10 4 5 3
Substitution Box 6
12 1 10 15 9 2 6 8 0 13 3 4 14 7 5 11
10 15 4 2 7 12 9 5 6 1 13 14 0 11 3 8
9 14 15 5 2 8 12 3 7 0 4 10 1 13 11 6
4 3 2 12 9 5 15 10 11 14 1 7 6 0 8 13
Substitution Box 7
4 11 2 14 15 0 8 13 3 12 9 7 5 10 6 1
13 0 11 7 4 9 1 10 14 3 5 12 2 15 8 6
1 4 11 13 12 3 7 14 10 15 6 8 0 5 9 2
6 11 13 8 1 4 10 7 9 5 0 15 14 2 3 12
Substitution Box 8
13 2 8 4 6 15 11 1 10 9 3 14 5 0 12 7
1 15 13 8 10 3 7 4 12 5 6 11 0 14 9 2
7 11 4 1 9 12 14 2 0 6 10 13 15 3 5 8
2 1 14 7 4 10 8 13 15 12 9 0 3 5 6 11
The entry in the S-Box is found by using the 1st and 6th bits of the 6 bit
block as the row (0, 1, 2, or 3) and the middle 4 bits as the column
(0 - 15). Also, the 1st 6 bit block uses S-1, the 2nd S-2, and so on with
the 8th using S-8.
You will notice that each of the S-Box entries is between 0 and 15; we now
form a new R called R2 from each of the located S-Box entries in order
giving us a new 32 bit R2.
The last operation is to create a (third and final) R called R3 from R2 by
using the following Permutation or P Table:
16 7 20 21
29 12 28 17
1 15 23 26
5 18 31 10
2 8 24 14
32 27 3 9
19 13 30 6
22 11 4 25
This means that the 1st bit of R3 is the 16th of R2, the 2nd is the 7th
and so on, with the 32nd being the 25th bit of R2.
PROCESS ITERATION
The net result of the previous section was to split the encrypted word into
two halves, ignore the left-hand one L and eventually create a new right-
hand one R3.
Now we XOR L and R3 together, and we've finished a decryption round.
For the next round, we treat R3 as the left-hand half of a new data word and
the result of the XOR operation as the right-hand half and repeat the
process of key preparation (for that round) and data manipulation (of the
new data word). We do this 16 times and we end up with a last left-right
pair of 32 bits each.
Put these together and we have a decrypted 8 byte word.
Continue the whole decryption process for the second encrypted word obtained
from the 88 instruction dialogue and then both can be sent to the DC via
the C0 instruction dialogue and the TV picture is unscrambled!
EUROCRYPT-S2
There are three variations on Eurocrypt-M which together form Eurocrypt-S2.
KEY PREPARATION
The key is split into a left and right pair as before. However, no left
shifting is performed prior to data word manipulation; the shifting is
performed after the manipulation and the shifts are to the right, not the
left.
DATA WORD MANIPULATION
Before performing the E-table operation, a new data word should be created
using the following permutation:
58 50 42 34 26 18 10 2
60 52 44 36 28 20 12 4
62 54 46 38 30 22 14 6
64 56 48 40 32 24 16 8
57 49 41 33 25 17 9 1
59 51 43 35 27 19 11 3
61 53 45 37 29 21 13 5
63 55 47 39 31 23 15 7
This means that the new data word is 64 bits long, and its 1st bit is the
original word's 58th and so on. This is called the Initial Permutation or IP
and is performed once per 16 decryption rounds.
After the decryption is complete as per Eurocrypt-M (ie after 16 rounds),
the decrypted data word is permuted using the following table:
40 8 48 16 56 24 64 32
39 7 47 15 55 23 63 31
38 6 46 14 54 22 62 30
37 5 45 13 53 21 61 29
36 4 44 12 52 20 60 28
35 3 43 11 51 19 59 27
34 2 42 10 50 18 58 26
33 1 41 9 49 17 57 25
This means that the final decrypted word is 64 bits long and its first bit
is the previous word's 40th and so on. This is called the Inverse Initial
Permutation or IP**-1.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
