Viaccess algoritm.
DES
Viaccess is a modification of Eurocrypt M. In this mod the key has 8 bytes when EC-M has only 7. If the 8th byte is zero then Viaccess works exactly like EC-M. If the 8th byte is nonzero then this will trigger several different small mods. One of these mods is in DES routine. 7 key bytes are used in des but the 8th byte is used in special core function in every DES round. This mod is done just before expansion E and it alters the 5th data byte which is the first of the right-hand 4 data bytes to be used in the DES-round. Therefore it has affect in S-boxes 1,2,3 and 8. The mod is done only with this byte for expansion E and the original byte remains the same.
In this mod the 8th key byte is multiplied with the data byte for at get a 16 bit word. Then the data byte is added to this word (upper 8 bit byte is incremented if there was a carry with the lower byte). Then the 8th key byte is added to the word on the same way. Then the upper byte is subtracted from the lower byte. If there was a carry in this subtract then result is incremented by 1. Then this result byte is used instead of the original byte in expansion E.
Caution there is a little mistake in John Macdonalds FAQ at the end of each round the new L is build with the old R and not the old R3
Another modification in the DES routine is the permutation table used after xoring the bytes of the expanded data with the modified keys data the new permutation table is
32 15 4 9
25 24 20 1
5 31 11 18
13 2 27 22
6 16 12 30
28 19 7 21
3 29 26 14
10 23 8 17
Key
If the 8th keybyte is nonzero then first 7 keybytes are rotated left by 2 bytes. This means key(k1 k2 k3 k4 k5 k6 k7 k8) -> key(k3 k4 k5 k6 k7 k1 k2 k8) These modified key is used in the DES routine but in the hash routine we have to use the non modified key.
Hash
All hash algorithms are working like in EC-M when this DES modification is done.
CA 88 and CA 18 message processing:
If the 8th key byte is even then this is the last modification but if it is odd then there is still one very complicated data modification. First there is one constant which is 5Ah if the 8th key byte is odd and his lower nibble is equal to zero. If the 8th byte is odd his lower nibble is not equal to zero then this constant is A5h.
Whe have to calculate the hash like in eurocrypt but the crypted words included in the data field have to be processed with the k constant to build the real crypted word.
There for the bytes of the sanded CW are first ANDed with the constant and then XORed with the encrypted data bytes. Result bytes are then stored in the real crypted word witch
is used as input data for DES. Ofcourse DES is done with necessary mods. The non modified bytes of the CW are still used to continue the hash processing. After DES the result bytes are ready for CA C0 message or other use in CA 18 messages.
Some new litle bug was found and fixed
in algorithm by author D.S at 09.03.2001
a little bug in the viaccess algo in the key
chapter
actual version
If the 8th keybyte is nonzero then first 7 keybytes are rotated left by 2
bytes. This means key(k1 k2 k3 k4 k5 k6 k7 k8) -> key(k3 k4 k5 k6 k7 k1 k2
k8) These modified key is used in the DES routine but in the hash routine we
have to use the non modified key.
corrected one
In the DES hash routine we have to use the key as is (k1 k2 k3 k4 k5 k6 k7
k8).
But in the DES decrypt routine we build a new key in whitch the first 7
keybytes are rotated left by 2 bytes. This means key(k1 k2 k3 k4 k5 k6 k7
k8) -> key(k3 k4 k5 k6 k7 k1 k2 k8)
Regards
New information about GCA added 10 july 2001
Explanation of a possible counter measure from ViaAccess
It is based on the geographical code area (GCA) and it has been used
in the past by Viasat. The smart card code was available only
on some cop card.
The GCA is a value of 4 bytes and could be specific to each card.
When sending an ECM, you could give the right to descramble only
to the card with a GCA of a specific value (or a set of value).
If needed, you could indicate that you don't care of the GCA value
using a FF FF FF FF value.
When it is received by a decoder, the commands exchanged with the
card will be :
a) CA AC A6 00 00 to check if the card has a GCA
b) CA F8 00 08 06 9F 04 FF FF FF FF
by this command the decoder explains to the card that
the GCA is not important.
c) CA 88 01 08 LEN data
Here it is a normal CA 88 but P1=01 and not 00
What is interesting is the hash used in the CA 88.
If you do b) followed into c) by a hash computed using
for example viaprog, you will get a hash error.
Why ? because the 9F 04 FF FF FF FF is used to give
an initial value to the hash buffer used for CA 88.
It works like for EMM and CA F0.
Consequently, today, with almost available smart card hex,
there is a problem because :
command a) answer 90 08 and not 90 00
command b) answer 6D 00 because F8 is unknown.
command c) doesn't use the good initial hash buffer.
Some new litle bug was found and fixed in algorithm by author D.S at 10 july 2001
the Hrt key's allowed to discover a bug in the algo
here the current version
If the 8th key byte is even then this is the last modification but if it is odd
then there is still one very complicated data modification. First there is one
constant which is 5Ah if the 8th key byte is odd and his lower nibble is equal
to zero. If the 8th byte is odd his lower nibble is not equal to zero then this
constant is A5h.
and corrected one
If the 8th key byte is even then this is the last modification but if it is odd then there is still one very complicated data modification. First there is one constant which is 5Ah if the 8th key byte is odd and his higher nibble is equal to zero ((k8 & F0)= =0). If the 8th byte is odd his higher nibble is not equal to zero ((k8 & F0)! =0) then this constant is A5h.
Also take a look in INFORMATION area for new doc of Algoritm
