UPDATED VERSION OF

"EVERYTHING YOU WANTED TO KNOW ABOUT EUROCRYPT

BUT

WERE AFRAID NOBODY WOULD TELL YOU"

BY

JOHN MACDONALD

Revised, Updated and Expanded January 1997

This file contains most of what 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). I have also read the official specification so its now fairly complete.

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 asks the card for general-purpose data (called FAC for 
Facility data in Eurocryptspeak). The data is stored in blocks and P3 
specifies that the DC will send 3 bytes containing the block reference to the 
card. The 3 bytes are called F, NP1 and NP2 (Numero Prestataire). F can have 
the values 00 (read first block), or 40 (read next block) indicated by the
FAC number NP1 NP2. If the msb of F is set the next 2 bits point to a block
start associated with FAC number NP1 NP2 and P1 P2 are the block reference. 
The idea behind FAC data is that the programme provider can introduce data
which is specific to that service which can be interpreted by a decoder to 
aid authentication etc using a chained block structure.

So to process an 02 instruction, send 02 to the DC as an acknowledgement, 
then get P3 bytes. If any of these bytes are 40 then send 90 08, else send 
90 00.

INSTRUCTION 04

Next the DC sends a packet

	87 04 00 00 07

The 04 instruction is requesting the result from the card selecting the FAC 
specified in the 02 instruction. The result consists of 7 bytes containing
block reference (2 bytes), block length (2 bytes), followed by 3 zero bytes.

So first acknowledge by sending 04, then send the following string:

	00 15 00 04 00 00 00. 

Finally, 90 00 is sent.

INSTRUCTION 06

The DC then sends a packet like

	87 06 00 00 04

which is asking for the FAC data block already specified by the previous
exchange from the card. P3 is the number of bytes to be sent (0-ff) and P1 P2 
is the relative address from the start of the block. All the PIC programs I've
seen send 

	10 02 ca 20 00

followed by 90 00. I don't know exactly what this is except that the 20 byte 
defines the decryption algorithm to be used. The Eurocrypt specification 
allows for many algorithms, although only one has been implemented in the 
smartcards I've seen.

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. If you send 90 08 the DC displays 
the 'no access' message.

Actually the 3 bytes identify a channel or a group of channels (Programme
Provider Identifier or PPID in Eurocryptspeak) - for example, all the TV3s are 
00 04 0 and CANAL+ is 10 00 2 (the ls nybble of byte 3 is not used). 

Card programs typically use this data to construct a byte between 1 and n 
where n is the number of PPIDs (known as Entities) 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 
88 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

Each of the substrings is a separate parameter in the form

	parameter-id, parameter-length, parameter-data.

There are over 30 of these parameters, and we'll describe the more important
ones as we go along. In the example above, e1 is DATE + THEME/LEVEL.

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. There are sixteen
codings of theme in use from 01->0f and ff. Each theme can have a level from
00 to ff. This coding is a way of restricting access to channels or even
single programmes. (For example, Supersport is a theme/level contained within
the Filmnet PPID). Of course genuine cards check that the date, theme and 
level are consistent with the subscription data, but pirate cards don't do
this! 

The ea parameter (called the Even and Odd Control Word cryptogram) 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 f0 parameter contains a length byte (08) followed by 8 bytes.This is a 
checksum for verification purposes and it's described later in this paper.

There are variations on the parameters used in the 88 instruction 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.

Another form of the c0 instruction is

	ca c0 00 00 06

This packet can occur immediately after an entity selection packet ca a4. 
and is asking the card to send the 3 bytes of channel identification followed
by 20 00 8f. These last 3 bytes mimic memory and access modes authorised for 
the entity in official cards. Some decoders (eg Philips, Nokia) issue this 
instruction as part of the remote control interface (see below) and if the 
pirate card doesn't support this form the card can lock up the channel.

The final form of the c0 instruction is

	ca c0 00 00 04

which asks for ppv information. The card should send ff f4 00 20.

CONSULTATION INFORMATION

There is a wide range of information which the card can supply and which is
requested by the decoder at various stages. The DC issues an ac command in 
the form

	ca ac P1 00 00

where P1 defines an information type, followed by 

	ca b8 00 00 P3

whereupon the card sends P3 bytes of information data.

Valid information type parameters are many and varied, with some of them not 
even implemented in official cards. Here are the main types:

	a4      Unique Address (UA), 5 bytes which uniquely identifies a
		card.

	a5      Programme Provider User Address (PPUA), 4 bytes consisting 
		of a Shared Address (3 bytes) and position within the group
		(CUSTWP, 1 byte). The shared address defines a group of 256
		official cardholders with CUSTWP defining which one each
		cardholder is.

	a6      Group Customer Address, 4 bytes consisting of a Geographical
		Code (3 bytes) and a Subject Code (1 byte). I'm not sure
		this has been implemented but most superior cards (eg COP, 
		Battery) have some token values for this data.

	a7      Label, 01-10 bytes of literal data to describe the programme
		provider (eg Filmnet1/2).

	a8      Dates + Theme/Level, 6 bytes of which 4 are the subscription 
		start/end dates followed by 2 bytes of valid theme and level 
		codes. This data is updated monthly (see below) if the
		subscription is paid.

	a9      Subscription Link, 7 bytes consisting of subscription start/
		end dates followed by 3 bytes called CUSTWD. Each bit of 
		CUSTWD points to a list of classes (1=allowed, 0=denied)
		stored in official cards. This mechanism allows the
		programme provider to offer subscriptions by class, but I'm
		not aware of anyone who's done it.

	aa      Prebooked PPV, consisting of 2 3-byte start/end programme
		numbers for which PPV has been booked.

Similar parameters exist for Impulse PPV (coded as e4, b4) and for paid-for
in advance programmes (01-05). Finally, we have:

	06      Reference Maturity Rating, 1 byte normally 0f.

	08      Lock Status, 1 byte normally 0f for all locks off.

I know these aren't very interesting, but perhaps they'll acquire more 
significance later on when we look at card updating and the remote control
interface.

Anyway, upon receipt of the ac packet the card should send ac 90 00. Upon
receipt of the b8 packet the card should send the ac information type
parameter followed by its length followed by the information requested
then 90 08 (not sure why this is so).

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. Also, how do programme providers download new keys
to their official cards? Well, this is where the 18 instruction comes in. It
is used to update entitlements.

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. 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. Generally speaking keys 00-07 are called Management keys and are 
used to alter entitlements (key 00 is the Issuer key) and keys 08-0f are the 
Operation keys used to decrypt the ECW and OCW to descramble the transmission.

The P1 parameter in the 18 packet can be: 

	00      Instruction addressed to entire audience
	01      Instruction addressed to shared group of customers
	02      Instruction addressed to a single customer.

Let's see what happens first when P1=00.

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 18 is used instead of 88 to get the last 8 bytes.

A typical string obtained in this way would be (broken into substrings 
for readibility)

	a0 01 00
	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

Bytes 1-3 are the control parameter (CTRL parameter a0). The third byte
controls the type of entitlement update to be performed by the card as
defined below:

	00      enter new entitlement
	10      enter free entitlement
	2x      invalidate entitlement
	4x      delete entitlement.
	x=0     entity
	x=1     FAC data
	x=2     key data.

Byte 5 is the length of the second substring which contains the channel id 
bytes (10 00 30 for Cine Cinemas) concatenated with the management 
key to be used (06 in this case). The next substring is preceded by type and
length bytes followed by 2 dates (17th and 22nd Jan 1996) followed by theme 
and level bytes.

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 
parameter type ef is 8 bytes of encrypted key data.

When this is fed through the decryption algorithm (see later) with the 
management key (06) an 8 byte plain word is obtained, the first 7 bytes of 
which are the new key (09). Many people think that an 18 packet must mean
that a key change is on the way. This is wrong; only 18 packets containing
the ef parameter (called CLE in Eurocryptspeak) are updating a key.

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. In fact, the latest twin PIC PCBs don't
have a touch pad any more.

The last substring is a checksum as per the 88 instruction.

The foregoing has dealt with the case where P1=0. I've only ever seen the 
French channels use this for key updating; Filmnet, etc use the value P1=01.
All the PIC code I've seen explicitly excludes processing of 18 packets with
P1<>0. This is one reason why the automatic key update only works with
CANAL+ and Cine Cinemas.

When P1=01 the 18 instruction is used to update entitlements for those
subscribers sharing an address, ie having the same Shared Address. (Remember 
the a5 parameter? Well the first 3 bytes of this are the SA). In order to 
tell the card which of the possible 256 subscribers should receive the update
the f0 instruction is used.

Immediately before the 18 01 instruction a packet like

	ca f0 00 04 22

is sent to the card. f0 is the 'process address' instruction and its purpose
is to tell the card which subscribers in the group should have the update.
The card should send 0f to the DC to receive a character hex 22 (ie decimal
34) times. The following is taken from a TV1000 log:

	9e 20 ff ff ff...decimal 32 times...ff ff ff

The 9e byte identifies the parameter as an address field (ADF) of length 20
bytes followed by 256 bits of address data, one for each member of the
shared address. The CUSTWP value in the a5 parameter defines which one of 
these bits applies to the subscriber (starting at 0 counting from the right).
If that bit is set the subscriber should get the update, if not it shouldn't.
In the example above all subscribers in the group should receive the update.

The next packet logged was:

	ca 18 01 04 19

which when processed yielded (broken down into substrings):

	a1 03 00 04 1d
	ef 08 5b 8e c8 c9 e1 6e 8d 84
	f0 08 06 9b 23 87 cc d2 32 af.

a1 is the PPID parameter with key index d, ef is the (encrypted) new key and
f0 is the checksum. So this packet tells the card to decrypt the 8 ef bytes
using management key 4 for TV1000 to obtain operation key d. This value is 
stored in the card for use when the channel switches over to key d at a later
time (usually 2-6 weeks later).
  
Official cards check that the update was meant for them by checking the 
CUSTWP bit value as described above and by performing the checksum algorithm 
(see later) starting with the Shared Address (SA) in bytes 6-8 of the HASH
buffer. If the checksum obtained doesn't match the f0 values, the card knows
the update was not meant for that SA and doesn't apply the update. By the
way, it is common for a channel to update the management key its just used
ready for the next update, to make the process of getting the new operation
key harder for hackers.

The last part of the puzzle occurs in the 18 02 packet. This instruction
applies only to the individual subscriber it's meant for. The following
was observed from a CANAL+ log:

	ca 18 02 00 18

which when processed yielded:

	a5 04 00 00 00 00
	a8 06 1a a1 1a de ff ff
	f0 08 4e c4 f4 78 0f c5 6f df.

This packet is meant for user 00 in Shared Address 00 00 00 and is giving
theme and level entitlements of value ff from date 1a a1 (1/5/93) to date
1a de (30/6/93). The checksum is calculated (using key 0) by first placing 
the card's Unique Address (a4 parameter) in bytes 4-8 of the HASH buffer. 
This means that the checksum will fail if applied to any card other than the 
one the packet was meant for.

The foregoing means that if you know the management keys for a channel and
have a valid PPUA analysis of logged data can give you new operation keys.
Also, armed with this knowledge you should be able to switch on expired
official cards. 
 
Finally, with unique issuer keys, individual subscribers could have 
personalised management keys, but the administration of these would surely 
be a nightmare for the programme provider.

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.

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 eg MENU)

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 send information about whether the channel is 
locked with a parental control secret code and the b8 is asking for 3 bytes 
from the card, one byte of which is the Lock Status (parameter 08).

The card should respond to all b8 instructions by sending the previous ac
information type followed by P3-2, and then P3-2 bytes of data. 

The card that I monitored sent 08 01 00 to the DC which then issued

	ca a4 00 00 00
	ca 24 00 00 09

The 24 instruction denotes PIN-controlled activities based on a secret code
entered for parental control purposes. Pirate cards which can update keys
using the DC remote control use this instruction to obtain the key data.
Official cards of course work completely differently with the 24 instruction.

There are four variants of the 24 instruction for different values of P1:

	00      Modify lock status
	01      Modify PIN code
	02      Modify maturity rating
	03      Modify purchase ceiling.

The Eurocrypt standard defines four locks, or items that can only be changed
if accompanied by the correct PIN. These are preselection area, consultation,
maturity rating and impulse PPV. These are stored in the 08 parameter's
ls nybble with 0 meaning unlocked and 1 meaning locked. The 24 00 asks the 
card to change the lock bits. In the example the card sent 24 and the DC then
sent 00 00 00 00 00 00 00 00 08 to the card. These are the 8-byte PIN 
followed by the new lock status value. This is unlocking the consultation
option.

Most pirate cards ignore 24 instructions and just absorb P3 bytes.

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, thus providing the DC with Label information about all the 
supported entities on the card. The sequence terminates by the card sending
90 08 after the a4 02 instruction which would exceed the number of supported
entities if incremented.

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. This enables the DC to display the Label
at the top of the consultation sub-menu. 

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 subscription + theme/level
(parameter a8). 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.
This was 2 dates (Jan 1st 1980 and Dec 31st 2007) followed by
theme and level bytes (ALL in both cases).

SUBSCRIPTION/LINK

This is subscription per class (see above) and the DC<->card traffic is 
Packet B to get the channel Label, then the DC sends

	ca ac a9 00 04
	ca b8 00 00 05 

asking for the a9 parameter data. The card I monitored sent 00 21 ff 9f bc 
which was 4 date bytes followed by a class byte.

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
	ca b8 00 00 08
 
asking for the aa parameter data.. The card I monitored sent aa followed by
06 then 00 00 00 ff ff ff.

IMPULSE PPV

This is the same as for Prebooked PPV except that the ac information type is 
e4 not aa. 

Some decoders, notably Philips also send the ac c0 00 00 06 packet asking
for details of memory usage for the channel in the card. Processing this
packet has been described earlier.
 
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 unlocking
process has already been described.

CONSULTATION LOCK

This was as for PPV Lock.

PARENTAL CONTROL

The DC sent

	ca ac 06 00 00

which is asking the card to select a Maturity Rating (Universal, PG etc),
followed by 

	ca b8 00 00 03 

to which the card responded with 06 01 06. Valid Maturity Ratings are:

	00              Universal
	03              PG
	06              12+
	09              15+
	0c              18+.

The idea is that if the reference maturity rating is less than the MR 
associated with the transmitted programme, the DC does not allow decryption
to take place.

The parental control lock is updated like the other locks.

NEW SECRET CODE

The dialogue is as per the PPV Lock then the DC sends

	ca 24 01 00 10

and the card receives sixteen bytes in the format: old secret code, new
secret code. These codes are usually 4 bytes long and are padded with leading
zeroes. If the old code is correct, the new one replaces it.

With armchair updating pirate cards like Multimac and SuperMac, the 24
processing is written to ignore the old code and use the new one as a new
key byte for storage in eeprom. The second byte tells the card what 
conversion to apply to the first byte and where to store the key byte. That's
why you need seven lots of four digits to perform a Multimac key update.

INSTRUCTION 26

This instruction is catered for in the PIC code I've examined, but I've
never monitored its purpose. Its not mentioned in the Eurocrypt standard and
all the PIC code does is send 6e 90 00 to the DC, which means 'instruction
unknown to card'.

GENERAL

The Eurocrypt system caters for much more than the foregoing, but much of it
has never been implemented in official cards. My guess is that instructions
like c4, 48, 1c, f4, f8, fc will be implemented in later versions (if there
are any).

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

THE CHECKSUM ALGORITHM

The Eurocrypt system includes a function whereby the card, official or 
otherwise, can check that packets received from the decoder are not corrupted
and that any control word decryption and entitlement management is done
correctly. For example, the card needs to be sure that the new CANAL + key
is the intended one before it overwrites the old one. (The single PIC cards 
don't do this but the twin PIC cards and COPs do). This function is called
the HASH function and this section describes how it works.

Any instruction packet from the DC which quotes the use of a key (most often 
18 and 88 instructions) has at the end of the packet a ten byte string 
consisting of 

		f0 08 < 8 hex bytes >

This is the HASH parameter and it always starts with f0 08. It should not be 
confused with the f0 instruction which is the 'process address' instruction. 
The HASH function appears at the end of the decoder-->card traffic following 
an instruction packet quoting the use of a key index. The 8 bytes following 
the f0 08 are the HASH digits. When the card processes the decoder 
instruction it applies the HASH algorithm to the data and checks that the 
result it gets is the same as the HASH digits. If it is it completes the 
instruction processing and sends the usual 90 00; otherwise it aborts the 
instruction processing and sends 90 08 whereupon the decoder displays the 
"HASH ERROR" message (Error 5).

I'll now describe how the HASH algorithm works.

It's based on an eight-byte buffer which is zeroised at the start of the 
instruction processing (except for ca 18 01 and ca 18 02 instructions; in 
these cases it's zeroised at the start of the preceding f0 instruction).

Bytes from the decoder-->card packet are loaded in order into the HASH
buffer by XORing each one with current occupant (usually initially zero).
When eight bytes have been loaded, the HASH function is applied to them and
the result is stored in the HASH buffer, (overwriting not XORing). Further 
packet bytes are buffered restarting at position 1 in the HASH buffer.

Loading further bytes from the packet continues in this way (XORing then
HASHing every eight bytes and overwriting) until all bytes in the packet 
prior to f0 08 have been buffered. A final HASH of the HASH buffer contents
is then performed.

The result of the final HASH should equal the eight bytes following f0 08 in
the decoder-->card packet. If it does, fine; if not, "Hash Error".

So, what's the HASH function?

Its the same as the DES function (M or S) which is used for control word
decryption except that near the end of each DES round the first and second 
bytes of the right-hand half of the eight byte word are swapped prior to 
XORing the right-hand half with the left-hand half. The key used in this
DES variation is the key specified in the decoder instruction (usually the
key index is in the fourth byte of the instruction packet).

Now you can see why you get "Hash Error" if you don't have the right key,
because the HASH function will generate incorrect values in the HASH buffer
giving a mismatch with the HASH bytes following f0 08.

Just as a matter of interest, single PIC cards ignore the HASH function
because there aren't enough registers for the HASH buffer. The auto update of 
CANAL + and Cine Cinemas is done by comparing the new key with the old and
overwriting if they're different. This is not really satisfactory but works
OK. The implementation in COP and twin PIC cards is much better, relying on
the HASH function to determine if the new key is the intended one.


I hope you find this helpful. If you think you have any improvements or
errors to correct leave me a message where you found this file and I'll be
happy to update it.




