 koobas.hobune.stream
|
|
Close Help | ||||||||||||||
| Eurocrypt informations | "Eurocrypt-S the story so far ..." |
EUROCRYPT-S THE STORY SO FAR ...
BY
JOHN MACDONALD (jm@wedzboyz.com)
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.
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.
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.
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).
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.
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.
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), used with 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 002b00 to 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 the caa4 command preceding the caf0/18 commands as would be expected. However the 1st 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 updat 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 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.
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.
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 13 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 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 update applies.
December 97.
.gif){kind=small}