EUROCRYPT-S
THE STORY SO FAR...
BY
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), 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
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 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 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.
John MacDonald
December 1997