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 good
time 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 frightens 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 algoritms 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 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 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 are
parity 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 (but don't
bother with PC-1) 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.
7 HASHING ALGORITHMS F0/18 COMMANDS
The basic hashing algorithm is different to EC-M which was:
- "left shifts, DES, byte swap".
For EC-S it is:
- "IP, left shifts, 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.
Canal+ use the same approach as this except that 'Triple-DES in reverse' is
used as described in Section 2 as the basic hash function.
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.
koobas.hobune.stream
.gif){kind=small}
