Eurocrypt informations | "Everything you wanted to know ..." |
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
Since I wrote the original version of this paper in April 1996 I have talked to lots of people about Eurocrypt, learnt more about the system and written my own twin PIC / 1 PIC+24c16 emulators. Many people have asked me to revise the paper to include the new information, so as things are quiet at the moment, here goes....
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 :
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.
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 7816atr.txt 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:
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.
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.
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.
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.
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.
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.
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.
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:
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).
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:
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:
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.
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.
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:
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.
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.
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.
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).
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.
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.
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.
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.
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.
This was as for PPV Lock.
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:
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.
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.
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'.
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).
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-to.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.
The main steps in the process are:
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.
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.
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.
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!
There are three variations on Eurocrypt-M which together form Eurocrypt-S2.
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.
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 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.