EUROCRYPT-S THE STORY SO FAR...

&

EUROCRYPT-S THE THE PLOT THICKENS...

BY

JOHN MACDONALD

Email: John MacDonald

This is a description of what I think I know about Eurocrypt-S. Its not complete and I will add to it when more is learnt, but its worth putting down on paper to see if we can move it forward. If anyone has any corrections or information to add to it, please leave me a message where you found this document and I'll get back to you.

I've had lots of help on this from Santa, The Irish Wine Taster and Amadeus. Many thanks guys.

1 WHAT I THINK I DO KNOW

- The date format used for subscription management.

- How an official card determines whether a key update is for it or not.

- The hashing algorithm used in the 18 command and the data it operates on.

- The key updating algorithm and the data it operates on.

- The hashing algorithm used to validate the 88 command and the data it operates on.


2 WHAT I KNOW I DON'T KNOW

- The meaning of the a7 0b string in the C+ 18 command.

- What the last 7 bytes of the 9e 20 packet mean most of the time.

There's probably some other small things as well. There's enough information here to build an EC-S self-updating card if you have the appropriate issuer keys and shared addresses.


3 DATE FORMAT AND SUBSCRIPTION MANAGEMENT

A new date format is used in 2 bytes ab cd as follows:

a = year from 1990
b = month (1=Jan, c=Dec)
cd= hex day value within the month.

So date 7A 11 is 17th October 1997.

The date appears in the e1 04 packet in the 88 command - I don't know what the other 2 bytes are.

Subscription data is transmitted in the 9e 20 packet in the f0 command in the first 4 of the last 5 bytes. In a log I saw these bytes were:

7A 81 7A 9F 65.

I don't know what the 5th byte is, but if you ignore the top bit of bytes 2 and 4 you get 7A 01 7A 1F which is 1st October 1997 to 31st October 1997. When the official card determines the data is for it (see below) it updates its subscription for the new month. If not, it doesn't and when the date in the 88 command exceeds the last subscription date it doesn't try to decode the control words. I don't think cards are switched off as such, but I don't know what the df 00 packet does.

Also note that when the 7th byte from the end of the 9e 20 packet is 20 or greater, the foregoing does not apply (see below).


4 F0 PROCESSING

The f0 command is where the card determines if the update data (sometimes a new subscription period, other times a new key) is for it or not.

With EC-S, each Shared Address(SA) is still 3 bytes but there are only 200 subscribers per SA not 256 as in EC-M. The 4th byte of the PPUA determines an individual card in the SA as follows:

- top 5 bits define the byte in the 9e 20 packet starting from 00000 to 11000 or decimal 24.

- bottom 3 bits define the bit in the 9e 20 packet byte starting from 000 to 111 (or 0-7).

There are decimal 25 bytes used for this purpose in the 9e 20 packet. So if the 4th byte of the PPUA was ac, this would point to byte 10101 or decimal 21, bit 4. You count the bytes from 0 and the bits from the left of the byte from 0 to 7.

So in our example, if the 9e 20 packet was:

13 b1 3e fd 6c b1 42 a3
04 79 60 90 50 40 40 03
6f f7 80 08 28 88 80 00
5b 02 01 7a 81 7a 9f 65

our byte would be the 88 in line 3. Since bit 4 is set in this byte the subscription update would be for us. It works similarly for key updates (see below).

If the update is for us the card sends 90 00 if not it sends 91 00. The 18 command immediately follows the f0 command; if the update is not for us, the 18 command is not sent.


5 HASHING ALGORITHM F0/18 COMMANDS

The code I examined did the hashing based on the management key 0. The hashing algorithm appears to be different to EC-M which was:

- "left shift, DES, byte swap".

For EC-S it seems to be:

- "IP, left shift, DES, no byte swap, IP-1".

First you zeroise an 8 byte hash buffer. Then you XOR the 1st 8 bytes of the 9e 20 packet into the buffer, then hash it as above. Then XOR the 2nd 8 bytes in and hash that. Repeat for the 3rd and 4th lots of 8 bytes. Then hash the 1st 3 bytes in the f0 08 packet from the following 18 command (padded with 5 FFs) and XOR this into the hash buffer. Finally hash the buffer once again.

The last 5 bytes of the hash buffer should equal the remaining 5 bytes in the f0 08 packet in the 18 command for the hash to work. If it doesn't, the card sends 90 40 and the (key or subscription) update doesn't happen.


6 KEY UPDATING ALGORITHM

There seem to be two different PPIDs, one set for decrypting, used with the ca88/c0 commands and one set for updating (of keys and entitlements), usedwith the caf0/18. Each of these PPIDs can have up to 16 keys (0-f) although only 0 and 1 have been seen so far. For C+ the 'decrypting' PPIDs are 002b00to 002b60 and the 'updating' PPIDs are 002bb0 to 002bf0.

The PPID and key to be used for decrypting are in the usual places namely the caa4 command preceding the ca88 and in the P2 parameter of the ca88 command.

For key updating its a little different. Firstly the PPID to be used is in thecaa4 command preceding the caf0/18 commands as would be expected. However the1st 2 bytes of the last 7 in the 9e packet of the caf0 command seem to define how the key update is to be done, as follows. If these bytes are ab cd:

a = 2 defines a key update operation

b = The index of the key being updated in the 'decrypting' PPID

c = The index of the key to be used in the 'updating' PPID

d = The last nybble of the 'decrypting' PPID to which the update applies.

As an example, here's an extract from a RDV log:

CA A4 04 00 03 00 2D 80

CA F0 00 00 22 9E 20 FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF
FF 21 01 xx xx xx xx xx

This tells the card to update key 1 for PPID 002d10 using key 0 of PPID002d80.

Now we need to know where the data from which the new key is generated is to be found.

Firstly, the encrypted new key data is transmitted in 2 parts:

- the most significant 5 bytes are the last 5 bytes of the 9e 20 packet.

- the remaining 3 bytes are the 1st 3 bytes in the f0 08 packet of the 18 command.

BUT only when the 7th from last byte of the 9e 20 packet is at least 20. The value in excess of 20 is the key index of the key to be updated. Up to now I've only seen 20 and 21, ie updates for keys 0 and 1.

Then we apply the key updating algorithm to these 8 bytes and get an 8 byte result. The algorithm used is standard EC-S, ie:

- "IP, DES, right shift, IP-1".

A new wrinkle is that before we have the new 7 byte key we must perform Permutation PC-1 on the 8 bytes. The PC-1 permutation is a standard part of the official DES never before used in Eurocrypt and is:

57 49 41 33 25 17 09 01
58 50 42 34 26 18 10 02
59 51 43 35 27 19 11 03
60 52 44 36 63 55 47 39
31 23 15 07 62 54 46 38
30 22 14 06 61 53 45 37
29 21 13 05 28 20 12 04

This means that counting from the left from 1, the 1st bit of the new key is the 57th bit of the 8 bytes, 2nd is the 49th and so on. Bits 8, 16, 24, 32,40, 48, 56, 64 of the DES output aren't used; in the official DES these are parity bits.


7 HASHING ALGORITHM FOR THE 88 COMMAND

The same algorithm is used for hashing the 88 command (IP, left shift, DES, no swap, IP-1) but it operates on different data to EC-M hashing. This time we zeroise the 8 byte hash buffer and move the 3 byte PPUID into the 1st 3 bytes followed by the 4 bytes of the e1 04 packet and ea. We then perform a hash on these 8 bytes then XOR the 1st 8 byte control word into the buffer and hash again. Finally we XOR the 2nd control word into the buffer and hash once more. The hash buffer should equal the contents of the f0 08 packet in the 88 command. If they do the card sends 90 00 otherwise 90 40.


8 OTHER UPDATES

Updates can only happen 8 bytes at a time so if the desired update is longer than this some form of chaining has to be used. If the broadcaster wants toupdate the label of a PPID, this can be up to 13 bytes (a7 0b parameter). Theupdate is done in the clear with data in the same place as for a key update.

The parameter controlling a label update is once again in the 1st 2 bytes (ab cd) of the last 7 bytes of the 9e packet of the caf0 command as follows:

a = 1 defines a label update operation

b = 0 means a new update (1st 8 bytes) 1 means a continuation of the previous label update (last 3 bytes)

c = not used

d = The last nybble of the 'decrypting' PPID to which the updateapplies.


Email: John MacDonald
December 1997

EUROCRYPT-S THE THE PLOT THICKENS...

BY

JOHN MACDONALD

This is an update of my previous paper on the Eurocrypt-S encryption system as distinct from Eurocrypt-M. I recommend that new readers first of all study my Eurocrypt-M paper since I assume here that you're familiar with its contents.

Its still not complete but some good progress has been made in the last year and since no-one else seems to be moving it forward, now seems to be a goodtime to make new information freely available. As before, I will add to it when more is learnt. If anyone has any corrections or information to add to it, please leave me a message where you found this document and I'll get back to you.

The scene at the moment is dominated by many people whose only interest is free TV. They have bought a cheap pic programmer and some chips, and know how to program them or how to input remote control key updates. (Witness the postings to astc saying "gimmee the codes"). THIS INFORMATION IS NOT FOR YOU. Pay up, get a life and sleep soundly at night.

Equally low in the scheme of things are those with the same skills as the group above whose main interest is selling pirate cards based on programs designed by other people. (Witness the number of standard cards sold as commodities by unscrupulous dealers who can't support them). THIS IS NOT FOR YOU EITHER. Just carry on being parasites until you curl up and die.

Nor is it for the out-and-out commercial hackers who sell their wares at vastly inflated prices only to stop support when they think their offerings have been hacked by others (or just want more cash). They know all this anyway.

But if you think this stuff is fun, doesn't hurt anyone, and represents a technical challenge where you can acquire new skills and be creative, you should get some pleasure from it.

It really fightens me when I see (for example) the Gem Plus card as used by Canal+ advertised as suitable for financial transactions and high-security applications. I wouldn't want to risk MY money on that kind of 'high security'. I guess at the end of the day I think that by not keeping things secret standards will improve.

End of sermon.

The updates to this paper deal with another key updating algorithm used by Canal+ as well as the latest decryption algorithm. Some people have called this S3 but I really don't know what that means.

These updates have been discovered as a result of some terrific work by a very small number of individuals who are too shy to claim publicly the credit which is rightly theirs.

Many thanks guys.

I would also like to thank the 'Scans' (PPR) for their seemingly inexhaustible supply of cards of all types. You must be extremely rich either in money or in friends.


1 PICTURE DECRYPTION

As is well-known, the standard algorithm used to decrypt the control words in the CA 88 packet is:

    - "IP, DES, right shifts, IP-1".

Until a few days ago this was used exclusively by Canal+, RDV, TV2 etc. It has been suspected for the last year that the Canal+ card supported more than one decryption and key updating algorithm and that these would be used as progressive ECMs in a planned way as soon as the broadcaster thought that the
hackers were having an easy time of it.

We have just had an example of this policy in action. Up to now, Canal+ has used operation keys 0-3 on entity 00 2b 1 and key 0 on entity 00 2b 3 to decrypt the film channels. Then a few days ago, they switched to key d on entity 00 2b 1, with all other entities in the bouquet staying as usual. This activity switched off all pirate cards in Europe at a stroke. Nobody had ever heard of an operation key d in this context.

The key index value determines which of the decryption algorithms will be used, grouped in ranges of four, 0-3, 4-7, 8-b, c-f. Using keys 0-3 triggers the 'standard' algorithm, the algorithms used for keys 4-7 and 8-b are unknown, and keys c-f trigger the 'new' algorithm.

This new algorithm is based on Triple-DES which has become popular with card manufacturers because of its supposed immunity to a blitz-style attack. Triple-DES uses two keys and consists of three DES operations as follows:

    - "IP, DES, right shifts, IP-1" using key 1 on the control word
then
    - "IP, left shifts, DES, IP-1" using key 2 on the output from 1st DES
then
    - "IP, DES, right shifts, IP-1" using key 1 on the output from 2nd DES.

The output from the final DES is the output from Triple-DES.

This is the new algorithm that Canal+ uses to decrypt the control words in the CA 88 packet. The input to the process is now obvious, but how are the two keys obtained? Nobody had ever seen any updates over-the-air for keys other than 0-3.

Actually the keys used are 0-3, but imagined in the positions c-f.

So for the command:

    -CA 88 00 0D 24

the keys used are 1 and 2. For CA 88 00 0E 24 the keys would be 2 and 3, and for CA 88 00 0F 24 the keys would be 3 and 0. I think you get the idea by now.


2 HASHING ALGORITHMS FOR THE 88 COMMAND

When 'standard' picture decryption is used, the hashing algorithm is:

    -"IP, left shifts, DES, IP-1".

We zeroise the 8 byte hash buffer and move the 3 byte PPUID into the 1st 3 bytes followed by the 4 bytes of the e1 04 packet and ea. We then perform a hash on these 8 bytes then XOR the 1st 8 byte control word into the buffer and hash again. Finally we XOR the 2nd control word into the buffer and hash once more. The hash buffer should equal the contents of the f0 08 packet in the 88 command. If they do the card sends 90 00 otherwise 90 40.

When the "new" picture decryption algorithm is in force, the hashing algorithm is Triple-DES in reverse, ie:

    - "IP, DES, left shifts, IP-1" using key 1 on the input data
then
    - "IP, right shifts, DES, IP-1" using key 2 on the output from 1st DES
then
    - "IP, DES, left shifts, IP-1" using key 1 on the output from 2nd DES.
   
This hash operation is performed three times on the same data as in the "standard" situation and the same comparison made to determine validity of the data packet.


3 F0 PROCESSING

The F0 command is where the card determines if the update data (sometimes a new subscription period, other times a new key) is for it or not.

With EC-S, each Shared Address(SA) is still 3 bytes but there are only 200 subscribers per SA not 256 as in EC-M. The 4th byte of the PPUA determines an individual card in the SA as follows:

    - top 5 bits define the byte in the 9e 20 packet starting from 00000 to 11000 or decimal 24.

    - bottom 3 bits define the bit in the 9e 20 packet byte starting from 000 to 111 (or 0-7).

There are decimal 25 bytes used for this purpose in the 9e 20 packet. So if the 4th byte of the PPUA was ac, this would point to byte 10101 or decimal 21, bit 4. You count the bytes from 0 and the bits from the left of the byte from 0 to 7.

So in our example, if the 9e 20 packet was:

    13 b1 3e fd 6c b1 42 a3
    04 79 60 90 50 40 40 03
    6f f7 80 08 28 88 80 00
    5b 02 01 7a 81 7a 9f 65

our byte would be the 88 in line 3. Since bit 4 is set in this byte the subscription update would be for us. It works similarly for key updates (see below).

If the update is for us the card sends 90 00 if not it sends 91 00. The 18 command immediately follows the F0 command; if the update is not for us, the 18 command is not sent.

Canal+ seem to use a slightly different system whereby they only check whether an entitlement update is for a particular subscriber, preferring to send key updates with the subscriber flags all set. They thus rely on the entitlement update controlling the decryption process rather than the reception of a new key by only authorised subscribers.


4 KEY UPDATING ALGORITHMS

There seem to be two different PPIDs, one set for decrypting, used with the CA 88/C0 commands and one set for updating (of keys and entitlements), used with the CA F0/18. Each of these PPIDs can have up to 16 keys (0-f) although only 0 and 1 have been seen so far. For C+ the 'decrypting' PPIDs are 00 2b 1 to 00 2b 6 and the 'updating' PPIDs are 00 2b b to 00 2b c.

The PPID and key to be used for decrypting are in the usual places namely the CA A4 command preceding the CA 88 and in the P2 parameter of the CA 88 command.

For key updating its a little different. Firstly the PPID to be used is in the CA A4 command preceding the CA F0/18 commands as would be expected. However the 1st 2 bytes of the last 7 in the 9e packet of the CA0 command seem to define how the key update is to be done, as follows. If these bytes are ab cd:

    a = 2 defines a key update operation

    b = The index of the key being updated in the 'decrypting' PPID

    c = The index of the key to be used in the 'updating' PPID

    d = The last nybble of the 'decrypting' PPID to which the update applies.

As an example, here's an extract from a RDV log:

CA A4 04 00 03    00 2D 80

CA F0 00 00 22    9E 20 FF FF FF FF FF FF FF FF
        FF FF FF FF FF FF FF FF
        FF FF FF FF FF FF FF FF
        FF 21 01 xx xx xx xx xx

This tells the card to update key 1 for PPID 002d10 using key 0 of PPID 002d80.   

Now we need to know where the data from which the new key is generated is tobe found.

Firstly, the encrypted new key data is transmitted in 2 parts:

    - the most significant 5 bytes are the last 5 bytes of the 9e 20 packet.

    - the remaining 3 bytes are the 1st 3 bytes in the f0 08 packet of the 18 command.

BUT only when the 7th from last byte of the 9e 20 packet is at least 20. The value in excess of 20 is the key index of the key to be updated. Up to now I've only seen 20 and 21, ie updates for keys 0 and 1.

Then we apply the key updating algorithm to these 8 bytes and get an 8 byte result. The algorithm used is standard EC-S, ie:

    - "IP, DES, right shifts, IP-1".

A new wrinkle is that before we have the new 7 byte key we must perform Permutation PC-1 on the 8 bytes. The PC-1 permutation is a standard part of the official DES never before used in Eurocrypt and is:

        57 49 41 33 25 17 09 01
        58 50 42 34 26 18 10 02
        59 51 43 35 27 19 11 03
        60 52 44 36 63 55 47 39
        31 23 15 07 62 54 46 38
        30 22 14 06 61 53 45 37
        29 21 13 05 28 20 12 04

This means that counting from the left from 1, the 1st bit of the new key is the 57th bit of the 8 bytes, 2nd is the 49th and so on. Bits 8, 16, 24, 32,40, 48, 56, 64 of the DES output aren't used; in the official DES these areparity bits.

It has been known for some time that the above algorithm did not apply to Canal+ but nonetheless many search engines appeared on the web with which to obtain management keys by a 'brute force' attack. In fact it's highly unlikely that Canal+ management keys can be obtained by this method.

So, what algorithm do Canal+ use for updating operation keys?

Well, its similar to the one above, but instead of a single DES operation, Triple-DES is used. The encrypted key data is obtained as described above, (5 bytes from CA F0 and 3 bytes from CA 18) and the information defining the entity and operation key to be updated and the management key to use all still applies as above. Of course two management keys are needed; if management key 0 is indicated then 0 and 1 are used. I haven't seen any others used so far.

So we know the input data and we know the keys to use. The algorithm used is:

    - "IP, DES, right shifts, IP-1" using key 1 on the input data
then
    - "IP, left shifts, DES, IP-1" using key 2 on the output from 1st DES
then
    - "IP, DES, right shifts, IP-1" using key 1 on the output from 2nd DES.

The output from this process is fed through permutation PC-1 (see above) to obtain the new 7 byte operation key.

As a matter of interest, I know there was some discussion among key searchers about whether the 'parity bits' lost in PC-1 were in fact real parity bits, or all zeros or ones. To put everybody's mind at rest they appear to be random.


5 OTHER UPDATES

Updates can only happen 8 bytes at a time so if the desired update is longer than this some form of chaining has to be used. If the broadcaster wants to update the label of a PPID, this can be up to 11 bytes (a7 0b parameter). The update is done in the clear with data in the same place as for a key update.

The parameter controlling a label update is once again in the 1st 2 bytes (ab cd) of the last 7 bytes of the 9e packet of the CA F0 command as follows:

    a = 1 defines a label update operation

    b = 0 means a new update (1st 8 bytes)
          1 means a continuation of the previous label update (last 3 bytes)

    c = not used

    d = The last nybble of the 'decrypting' PPID to which the update applies.


6 DATE FORMATS AND SUBSCRIPTION MANAGEMENT

A new date format is used in 2 bytes ab cd as follows:

    a = year from 1990
    b = month (1=Jan, c=Dec)
    cd= hex day value within the month.

So date 7A 11 is 17th October 1997.

The date appears in the e1 04 packet in the 88 command - the other two bytes are THEME and LEVEL.

Subscription data is transmitted in the 9e 20 packet in the f0 command in the first 4 of the last 5 bytes. In a log I saw these bytes were:

    7A 81 7A 9F 65.

The 5th byte is THEME and LEVEL. If you ignore the top bit of bytes 2 and 4 you get 7A 01 7A 1F which is 1st October 1997 to 31st October 1997. When the official card determines the data is for it (see below) it updates its subscription for the new month. If not, it doesn't and when the date in the 88 command exceeds the last subscription date it doesn't try to decode the control words.

Canal+ transmit the subscription update in the usual 8 bytes (last 5 of the 9e 20 packet and 1st 3 of the f0 08 packet in CA 18). The 1st byte of the update parameter is '02', and the LS nybble of the 2nd byte indicates the entity to be updated.

So a packet like

CA F0 00 00 22    9E 20 xx xx xx xx xx xx xx xx
        xx xx xx xx xx xx xx xx
        xx xx xx xx xx xx xx xx
        xx 02 01 xx xx xx xx xx

with its following CA 18 command updates 00 2b 1 with a new subscription period. If you decrypt these bytes using the key update algorithm you get packets like

    8C 81 8C 9F 6D 6F 00 00.

Ignoring the top bits of bytes 2 and 4 you get 8C 01 8C 1F ie 1st December 1998 to 31st December 1998 for the next subscription period. Presumably the next two bytes are THEME and LEVEL (65 and 67?). The last 2 bytes are just padding.


On a final note, if anyone publishes any software or web site information as a result of reading this paper, perhaps they would do me the courtesy of acknowledging this paper as their reference, and send me if possible, a copy of their programs.

Have fun.


John MacDonald
December 1998