The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / pc / crypto / eurocryp.doc < prev next >

Wrap

Text File | 2003-06-11 | 26.5 KB | 705 lines

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.