keywissel

12 december 2002

Is er al iemand die weet of ze bij seca2 meerdere keywissels doen dan bij seca1,of gebruiken ze bij seca2 ook 1 key per provider per maand?

Azazel · 12 december 2002

@Digitalsat2002,

Vanaf de introduktie van de V7, ben ik natuurlijk gaan kijken naar keywissels. Wat ik je hierover kan vertellen is dat de waardes checksum van de operationele keys (OK), steeds veranderen bij een actualisering van keys, OC, 0D. Voor zover ik heb kunnen zien is dat de OK 0E niet veranderd is.

Maar het vreemde hieraan is, dat de waardes checksum verschillend zijn bij elke 'gebruiker', tenminste voor zover ik andere logs heb kunnen zien.

Zie hier de waardes van mijn V7 (laatste twee mnd), let wel dat de waardes checksum natuurlijk verzonnen zijn.

Oktober

01: 00 5D = 5C FF FF FF FF FF FF FF FF AA 00 81 - Primaire key 0C

01: 00 0C = 5E FF FF FF FF FF FF FF FF BB 00 81 - ,, ,, 0E

01: 00 1C = 5D FF FF FF FF FF FF FF FF CC 00 81 - ,, ,, 0D

02: 00 13 = FE FF FF FF FF FF FF FF FF DD 00 82 - ,, ,, 0E

03: 00 1A = FE FF FF FF FF FF FF FF FF EE 00 83 - ,, ,, 0E

November

01: 00 0A = 0C FF FF FF FF FF FF FF FF FF 00 81 - Primaire key 0C

01: 00 0C = FE FF FF FF FF FF FF FF FF GG 00 81 - ,, ,, 0E

01: 00 1C = 5D FF FF FF FF FF FF FF FF HH 00 81 - ,, ,, 0D

02: 00 13 = 5C FF FF FF FF FF FF FF FF II 00 82 - ,, ,, 0E

03: 00 1A = 5E FF FF FF FF FF FF FF FF JJ 00 83 - ,, ,, 0E

Hieruit kunnen we opmaken dat er in ieder geval elke maand een keywissel plaatsvind, steeds de 0c op de maand zelf en de volgende de 0D. De 0E is tot op heden nog niet veranderd. Geruchten gaan rond dat dit waarschijnlijk de key is voor de VIP kaarten.

Wanneer men een C1 40 ontvangt (C1 40 01 B1 5C), en dus de kaart actualiseerd is er iets wat nog vreemd is, waarom is het zo dat alle OK hetzelfde zijn voor alle 'gebruikers' maar met verschillende checksum??

In de theorie stuurt men actualisaties voor elk 256 'gebruikers' die dezelfde SA hebben, maar veronderscheiden door de CUSTW, de laatste byte van de PPUA.

Mischien heeft het te maken met de Master Key, die zou naar alle waarschijnlijkheid voor elk kaart verschillend zijn....

Hoop dat het zo een beetje duidelijk is.

Saludos!

'Azazel miembro del equipo RAIDEN, la resitencia.'

13 december 2002

Weet je wat ik ook merkwaardig vind?ik heb een bruikleen seca2 kaart in een aston 1.05 en als ik de geldigheidsduur opvraag van de kaart staat er van 01/01/90 tot 09/12/2002.met daaronder de nummmers waarvoor de kaart geldig is.volgens de geldigheid dat de decoder geeft zou de kaart verlopen moeten zijn,en geen beeld hebben.We zijn nu de 13de en ik heb nog steeds beeld en ben zeker dat het een originele kaart is.Hoe komt het dat de einddatum staat op 09/12/2002 en dat ik vandaag de 13de nog beeld heb.Of is die datum niet meer geldig voor seca2 kaarten?Graag wat uitleg over die datum en seca2 kaarten.

alvast bedankt.

Hemant · 13 december 2002

Algoritme is bij mij bekend, maar ik weet niet verder wat het systeem ermee

doet, in theorie kan ik met een plain/cipher combinatie of met enkele

metingen van zulke DES algoritmes kraken. Kost wel wat tijd, maar wat ik

niet kan opmaken uit de tekst is of er sessie sleutels gebruikt worden. Want

dan is het zinloos om de sleutel te kraken.

EUROCRYPT-S 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 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 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 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 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.

Have fun.

14 december 2002

@hermant

mag ik vragen wat dit vreselijk oude gedoe eurocrypt te maken heeft met wat azazel gezegt heeft hier ??

en wat het te maken heeft met seca2 ?

joepie · 14 december 2002

is dit blad vuling

hihi

groeten ronald

Inloggen

keywissel

Aanbevolen berichten

Gast

Azazel

Gast

Hemant

Gast

joepie

Maak een account aan of log in om te reageren

Account aanmaken

Inloggen

Wie is er online 0 leden

Overig

Activiteit