Some technical details about Videocrypt

---------------------------------------



Markus Kuhn -- 1994-06-18





In this file, I'll collect some of the details known or assumed about

the Videocrypt pay-TV access control system. Consider it as some kind

of frequently asked questions list with answers about the system.





1  Basic principle



Videocrypt encodes the TV image by cutting each line of the image in

two pieces at some cut point and then exchanges these two line

fragments in the broadcasted pictures. E.g. if a line like



   0123456789



passes the encoder, the output might look like



   4567890123



where the digits represent the pixels of the image. There are 256

possible cut points and there are no cut points directly near the image

border (the miniumum distance from the margin is about 12-15% of the

image width) which is the reason why you sometimes still can see

vertical patterns even on an encrypted image. The sound is currently

not encrypted.



Several times per second, a computer at the broadcasting station

generates a 32 byte long message which is broadcasted encoded together

with forward error correction information in the first invisible lines

of the TV signal similar to teletext. About every 2.5 seconds, one of

these 32-byte messages is processed in the encoder by a secret hash

algorithm which transforms the 32-byte message into a 60-bit value.

These 60 bits are then used by a second algorithm in order to determine

the 8-bit cut point coordinates for each line for the next 2.5 seconds.

No details about this second algorithm are known, but think of it just

as some kind of 60-bit pseudo random number generator (PRNG) were the

60-bit output from the secret hash function is used as a start value

(seed).



The decoder receives the 32-byte messages and other data together with

the TV signal, applies some error correction algorithms and passes all

32-byte packets to the smart card in the decoder's card slot. The smart

card implements the same secret hash function and answers with the same

60-bit value as the one which is used in the encoder. By using this

60-bit answer from the card, the decoder hardware can generate with the

same PRNG the same cut point sequence as the encoder and can so

reconstruct the original image by again exchanging the two line

fragments. The secret hash function is a cryptographically strong

system which is designed so that it is extremely difficult to guess the

algorithm of this function by looking at many pairs of 32-byte/60-bit

values.



Apart from being the source for the generation of the 60-bit PRNG seed,

the 32-byte messages from the broadcasting station contain card numbers

so that individual cards can be addressed and they contain commands

like activation, deactivation, or show-a-message for the addressed

card. In addition, the 32-byte packets contain a digital signature

(currently 4 bytes) that allows the card to test whether the 32-byte

messages really originate from the encoder and have not been generated

by someone analysing the card. Again, this digital signature like the

hash function has been designed so that it is difficult to find out how

to generate a correct signature by looking at enough examples. This

prevents choosen-text attacks, where someone tries to probe the secret

hash function with very carefully selected 32-byte messages and this

prevents hackers to generate new activation commands for the card.



In early 1993, someone managed to get access to the secret hash

functions of several stations which use Videocrypt (e.g., British Sky

Broadcasting, Adult Channel, JSTV, BOB, Red Hot TV). All these systems

used the same hash and signature algorithm and the only difference

between the stations was a 32-byte secret key table. It is not known,

how it was possible to get this information. Either someone from the

company who manufactured the cards (News Datacom) released this

information or it was possible for someone to read out the EPROM

contents of the card processor (less likely, but also theoretically

possible). With this knowledge it was then quite easily possible for

the original hackers to produce 'clone cards'. These are simple PCBs

with a cheap microcontroler (e.g. one of Microchip's PIC family), which

implements only the secret hash function and serial I/O procedures in

its EPROM and answers with the correct 60-bit values to 32-byte

messages just as the real cards do. For several channels, clone cards

are still available, but BSkyB distributed new 09 series cards in

spring 1994 and switched on 1994-05-18 to a new secret hash function.

Consequently, all clone cards stopped to work. It is not known whether

only the secret 32-byte key was changed, or whether also the hash

and/or signature algorithm have been modified. Even if the algorithm is

still the same, it is extremely difficult to find out the new 32-byte

key table.



The clone cards didn't implement any interpretation procedures for card

activation or deactivation and pay-per-view functions, so their

software is considerably simpler than the one in the real cards. This

resulted in some tiny differences between the reaction of the clone

card software and the reaction of the original card software on

pathological 32-byte messages. These differences were used in counter

measures against clone cards several times in 1993 and 1994 by BSkyS in

order to deactivate clone cards, but it was quite easy each time to

find out these tiny bugs in the clone card software and correct it.



There is an Intel 8052 microcontroler in the decoder which manages the

communication between the smart card and the rest of the system. As the

software of this processor is not read protected, it was also possible

to reprogram this chip (by using the EPROM version 8752BH) so that the

hash algorithm is performed inside the decoder. Then no external card

is needed at all for the channels for which the hash algorithm was

implemented in the 8752.



More detailed basic information about Videocrypt has been published in

the European patent EP 0 428 252 A2 ("A system for controlling access

to broadcast transmissions"). You can order a copy for little money

from the European Patent Office if you are interested.





2  Security of the Videocrypt system



The system is very secure, because all secret parts that are essential

to a successful decryption are located in the smart card and if the

card's secret hash algorithm/key becomes known, it can easily be

replaced by just sending new cards to the subscribers. This card

exchange can also be used if details about the format of the commands

hidden in the 32-byte sequences sent to the card become known.



There are however at least two obvious security flaws of the system

which can't be removed by new smart card generations:



  - The dialog between the card and the decoder is the same synchronously

    for all Videocrypt decoders switched to this channel. I.e., the decoder

    doesn't add any card specific or decoder specific information to the

    traffic. This makes it possible to use one card for several decoders.

    E.g. it is possible to record the 32-byte messages broadcasted by

    the station during an evening with a PC, then send these messages to

    someone else with an original card who asks his card for the 60-bit

    answers to all the recorded messages. If this person then sends

    these 60-bit answers back, then you can use this data in order

    to descramble the VCR recorded program of this evening (delayed data

    transfer). However, decoding VHS recorded encrypted signals produces

    minor color distortions and a few VCRs don't preserve the Videocrypt

    data stream in the first invisible lines that accompanies the TV

    signal. It is also possible to distribute the 60-bit answers from

    one card in real-time with cables to many decoders in a house or

    with radio signals to many decoders in a larger region.



  - The simple cut-and-exchange encryption method and the fact that two

    consecutive lines in an image are almost always nearly identical

    makes it possible to try all 256 possible cut points and to select

    the one which causes both lines to fit together best. This method

    has alreday been implemented on fast PC's with framegrabbers which

    load the image into the memory and display it corrected on the computer

    screen (many seconds per frame), on parallel supercomputers which

    allow almost real-time decryption and with special hardware that

    achieves real-time decryption. Howevery, with this decoding method,

    there are severe image quality losses and many additional problems

    which together with the high hardware costs required (much higher

    than a regular subscription) don't make this approach very practical

    for every day usage.



Both these security gaps in the videocrypt systems don't allow

comfortable and easy high quality decryption like using a card, but the

described methods have already been successfully used by a few

technically skilled peoples for watching encrypted program.





3  ISO card protocol



The card and the protocol used to cummunicate with it conform exactly

to the international standard ISO 7816. The options used from this

standard are: T=0 asynchronous halfduplex character transmission

protocol, active low reset and inverse convention. Only a few basic

principles of the ISO protocol will be explained here. For much more

detailed information, please read the ISO standard which you can order

from your national standards body (e.g. DIN, ANSI, AFNOR, BSI, DS,

etc.). There are three parts of the standard: ISO 7816-1 describes

physical characteristics of the card and quality tests a card has to

survive, ISO 7816-2 describes the location and meaning of the contacts

and ISO 7816-3 (most important) describes the electrical

characteristics, the answer-to-reset message and the protocol. 



The data format is an asynchronous 9600 bit/s serial format similar to

that used on RS-232 lines with 8 data bits, 1 parity bit and two stop

bits. The parity is even (but if inverse bit meaning convention is

used, a RS-232 interface has to be programmed for odd parity in order

to produce the correct bit). There is also an error detection and

character repetition mechanism in the protocol which is not supported

by RS-232 interfaces: If the receiving device (card or decoder) detects

a parity error, it sends an impulse during the stop bit time. This will

tell the sender to retransmit one byte.



After a reset impulse to the card, the card answers with an

answer-to-reset message with some information about the requirements of

the card. If the first byte is 3fh, then this means that in order to

read the bytes with a RS-232 interface, you'll have to invert and

reverse all bits. A typical answer-to-reset looks e.g. like the

following one:



     3f fa 11 25 05 00 01 b0 02 00 00 4d 59 00 81 80 

         |  |  |  |  | | 'historic characters' with|

         |  |  |  |  | | information about chip and|

         |  |  |  |  | | software version, etc.    |

         |  |  |  |  |

         |  |  |  |  +- low nibble: protocol type T=0,

         |  |  |  |     high nibble: end of ISO part

         |  |  |  |

         |  |  |  +- requests 5 additional stop bits  

         |  |  |

         |  |  +- encodes programming voltage and max. programming

         |  |     current (here: 5V, 50mA)

         |  |

         |  +- clock freq.: 11h=3.5 MHz, 31h=7 MHz

         |

         +- the 0ah low nibble means: 10 'historic characters' which

            are not defined in the ISO standard are appended to

            the reset answer



The answer-to-reset message has a variable length format. Some bits

specify whether certain bytes are present or not. If the lowest bit in

the high nibble of the second byte is 1, then the above shown third

byte is present and determines the relation between the bit rate and

the clock frequency after the reset answer. E.g., 11h means that 372

clock cycles are one bit duration (default), i.e. with a clock

frequency of 3.5712 Mhz, the bit frequency is 9600 Hz. In the

Videocrypt system, the bit rate is always 9600 bits/s, but a value of

31h (= factor 744) in the third byte requests a doubled clock frequency

(~7MHz) from the decoder. Other values are not supported by the

Videocrypt decoder. 



The Videocrypt decoder supports several programming voltages (5 V, 12.5

V, 15 V and 21 V, max. 50 mA current) and different numbers of stop

bits (>= 5) sent to the card. All these parameters can be selected in

the answer-to-reset. Of the 'historic characters' part, the decoder

only verifies that it is at least 7 characters long and that the values

4dh und 59h are at the positions as in the example, otherwise the card

is rejected. No more details about the information in the historic

characters part of a Videocrypt card is currently known. For the

detailed format of the answer-to-reset message, please consult ISO

7816-3.



The T=0 protocol is a half duplex master slave protocol. The decoder

can send commands to the card followed by a data transmission either to

or from the card. The card can do some limited flow control and can

request or deactivate the programming voltage VPP selected in the

answer-to-reset using "procedure bytes". If the decoder initiates a

command, it sends five header bytes to the card, e.g.



     53 78 00 00 08



The first byte (CLA) is the command class code and is always 53h in the

Videocrypt system. The second byte (INS) is the instruction code. Its

lowest bit is always 0 and instruction codes have never a 6 or 9 high

nibble (you'll see below, why). The following 2 bytes (P1 and P2) are a

reference (e.g. an address) completing the instruction code and a

Videocrypt decoder sets them always to 00 00. The final byte (P3) codes

the number of data bytes which are to be transmitted during the

command. P3=0 has a special meaning: In data transfers from the card,

it indicates 256 data bytes, in data transfers from the decoder, it

indicates 0 bytes. The direction of the data transfer is determined by

CLA and INS and must be known in advance by both the card and the

decoder.



After transmission of such a 5-byte header, the decoder waits for a

'procedure byte' from the card.



The following procedure bytes are possible:



  60h             Please wait, I'll send another procedure byte soon,

                  don't timeout.



  INS             Now let's transfer all (remaining) data bytes, I don't

                  need programming voltage.



  INS+1           Now let's transfer all (remaining) data bytes and please 

                  activate VPP.



  INS xor ffh     Now let's transfer another single data byte,

                  I don't need programming voltage.



  (INS+1) xor ffh Now let's transfer another single data byte, and please

                  activate VPP.



  6Xh or 9Xh      This byte SW1 indicates an end of the data transfer

                  and requests to deactivate VPP. A second status byte SW2

                  follows from the card. SW1 SW2 = 90 00 indicates a

                  normal termination, other values report e.g. an error.

                  

After each data transfer, the decoder waits for another procedure byte.

E.g., a typical decoder<->card dialog looks like this (command 78h

requests the 60-bit answer as 8 bytes from the card):



     decoder sends header

       53 78 00 00 08

     card sends procedure byte (all at once, no VPP)

       78

     card sends P3 data bytes

       80 52 02 79 f5 39 7c 0e

     card closes with SW1 and SW2

       90 00





4  Videocrypt protocol



The newer Videocrypt smart cards don't require any programming voltage.

Although, the ISO standard requires only 2 stop bits after each

transferred byte, Videocrypt decoders seem to require more than 5 stop

bits. As PC serial ports don't support more than 2 stop bits directly,

a card emulator software has to wait for about 0.5-1.5 ms after each

byte. Cards can announce in the answer-to-reset message, how many stop

bits they require.



A videocrypt decoder knows the following 10 commands (all with CLA=53h

and P1=P2=00h):



     INS     length (P3)      direction        purpose

    ---------------------------------------------------------------------

     70h         6            from card        serial number, etc.

     72h        16            to card          message from previous card

     74h        32            to card          message from station

     76h         1            to card          authorize button pressed

     78h         8            from card        60-bit answer

     7ah        25            from card        onscreen message

     7ch        16            from card        message to next card

     7eh        64            from card        ???

     80h         1            to card          ???

     82h        64            from card        ???



The following things are known about the data bytes of these commands:



70h:



In BSkyB cards, the 70h data contains the card issue number (e.g. 07 or

09) in the low nibble of the first byte. The high nibble of the first

byte seems to be always 2. The next 4 bytes form an 32-bit bigendian

integer value which corresponds to the decimal card number without the

final digit of the card number (which is perhaps a check digit,

algorithm unknown). The meaning of the final byte is unknown.



72h and 7ch:



Several times per second, the decoder requests with 7ch 16 bytes from

the card. If a card is removed and a new card is inserted in the

decoder without switching off the power of the decoder, then shortly

after the card reset, the decoder sends the latest 7ch data bytes from

the previous card in a 72h message to the new card. In this way, 16

bytes information (e.g. the status of a pay-per-view account or a list

of activated channels?) can be transfered from one card to the next.



74h and 78h:



The 74h command transfers the 32-byte messages from the broadcasting

station to the card. If the third bit (value 8) in the first byte is

set, then the decoder will ask with a 78h command for the 60-bit

answer. This happens about every 5th 74h packet every 2.5 seconds. The

high nibble of the final byte in the 78h data is ignored by the decoder

(only 60 bits are needed). The high nibble of the first 74h byte seems

to have the value eh or fh in normal encrypted operation and ch or dh

in the 'soft scrambled' mode where the decoder can descramble the image

even without any card. 



The following information is valid for the 07 BSkyB card and need not

necessarily be true for future smart cards, because these data bytes

don't seem to be interpreted in the decoder and so their meaning can be

exchanged. A typical BSkyB 74h packet for the 09 series card looks like

this:



  e843 0a888261 0c 29e403f6 20202020202020202020202020202020 fb54ac02 51



The second byte selects one of several 32-byte secret key tables that

are used by the hash function. When the switchover from the 07 cards to

the 09 cards happened, this value increased from 40h to 43h. In the 07

card, this value was only interpreted to find an offset into a table

with various 32-byte secret keys. The lower 7 bits of the seventh byte

contain a channel ID. The final byte 32 is a simple checksum that makes

the sum of all 32 bytes a multiple of 256. The 4 bytes 28-31 contain

the digital signature that is simply an intermediate result of the

iterations of the hash algorithm. If the checksum, the digital

signature, or some of the values in the first 7 bytes of a 74h command

aren't correct, then the 78h answer will only contain 8 00 bytes or in

some cases 01 00 00 00 00 00 00 00. The 07 card had an interesting

security hole: The card sends to the decoder as many data bytes as

specified in P3. By sending a higher length value in the command header

to the card, one can get up to 256 data bytes back which seem to be

values from the card's RAM that allow some insight into the internal

data structures of the card software.



The following theory has been proposed about the encoding of the card

addresses, but this hasn't been verified yet and might be partially or

completely wrong: A card number is perhaps represented by a 5 byte card

address consisting of a 4 byte prefix and a 1 byte suffix. Up to 16

cards with the same card address prefix can be addressed with one

32-byte message. The bytes 8-11 might contain the common prefix to the

addressed cards and the bytes 12-27 the various suffixes. If there are

less than 16 different cards to be addressed, then the same suffix byte

is repeated several times in order to fill the space. There's no good

theory about the meaning of the 4 bytes 3-6. E.g. the command which is

sent to the card could be encoded there, but no details are known and

as these bytes seem to have pretty random values, it is possible that

some of these are random bytes or time stamps and that the other bytes

are encrypted with e.g. intermediate values of the hash function (like

the signature).



76h:



If the authorize button on the decoder is pressed for a few seconds,

then the decoder will send a single 76h message with a 00 data byte to

the card.



7ah:



This command requests from the card an ASCII text which is then

displayed on the TV screen. The display field is 12 characters wide,

one or two lines high and no lowercase letters are supported. The lower

5 bits in the first byte indicate, how long the text is which is to be

displayed: 0 for no display, 12 for a single line and 24 for 2 lines.

The highest 3 bits of the first byte seem to be some kind of display

priority. The number there (0-3) must be high enough if standard

decoder messages have to be suppressed. The remaining 24 bytes contain

the ASCII test.



The meaning of the other commands is unknown, some of them are never

used currently. Some cards understand also additional instruction codes

which can't be issued by a normal decoder. E.g. a BSkyB 09 card

understands also 12h, 86h, 88h, 8ah and 8ch. These commands are perhaps

used in order to test or configurate the card at the factory, etc.



Please contact me if you find out anything new. My e-mail address is

[email protected].





5  VCL File Format



The Videocrypt Card Logfile format (VCL) is used by some peoples for

performing the delayed data transfer procedure described in section 2.

Person A with a valid card can record the dialog between the decoder

and the card for a certain program P and transmit this information as a

VCL file to person B who has no card and has recorded with a VCR only

the encrypted signal of program P. Person B now connects the Videocrypt

decoder between the VCR and the TV set and connects the card slot of

the decoder to a PC. Using the information in the VCL file, B's

computer can now also decrypt program P. This is of course only

possible for the few hours which are covered by the information in the

VCL file.



Not all of the information exchanged between the card and the decoder

is necessary for descrambling the TV signal. The VCL format uses this

fact in order to save a lot of storage space. Only 12 bytes of high

entropy (that means: almost uncompressable) are stored every 2.5

seconds. So a VCL file of a 1 hour program is only about 17 kbytes

large. In addition, VCL files don't contain any information about the

card owner (especially not the card serial number), which appears in

normal full log files. (The only potential security hole is the

remaining nibble in the 78h data, consequently it should be cleared in

order to avoid card specific information to leak into the VCL file.)



VCL files have a very simple binary format consisting of a 128 byte

header and arbitrarily many 12 byte records. At the end, VCL files may

be padded with zero bytes to a multiple of the operating system's disk

sector size, so that no RAM contents can leak in there out of an

unsecure system like MS-DOS. Don't forget to use a binary mode if you

transfer VCL files or their contents will be rendered unusable.



The 128 byte header has the following format:



      byte number       purpose



	0 -  3		ASCII String 'VCL1' which identifies the file

                        type and version of the format.

        4 -  7          The number of 12-byte records stored in this

                        file encoded as a bigendian (most significant

                        byte first) 32-bit unsigned integer value.

        8 - 23          Date and time when the recording started.

                        Format: yyyymmddThhmmssZ, where yyyymmdd are

                        year, month and day (e.g. '19940618'), hhmmss

                        are hour, minute and second (e.g. '235959'),

                        T ist just the ASCII letter T, and Z is

                        the ASCII letter Z if the time is UTC or

                        a zero byte, if the time is local time. The 

                        digits are ASCII characters.

       24 - 55          Name of the satellite or cable system from

                        which the recording was done. This is a zero

                        terminated ASCII string with only characters 

                        between 20h and 7eh. As many zero bytes are

                        appended as necessary for filling up the 32

                        bytes. The same format is also used for the next

                        two text fields. Example: 'Astra'.

       56 - 63          Name/number of the transponder from which

                        the recording was done. Example: '08' for

                        Sky One on Astra.

       64 -127          Description of what has been recorded.

                        Example: 'Star Trek: TNG, episode 123'



After the first 128 bytes follow as many 12 byte records as announced

in bytes 4-7. Each record represents a 74h/78h Videocrypt protocol pair

and constists of two fields: The first 4 bytes are the final 4 bytes of

the 74h data part, the remaining 8 bytes are the data part of the

corresponding 78h command. Four bytes of each 74h packet are enough to

allow a card emulator to quickly and reliably synchronize with the

queries of the decoder. The final four bytes of the 74h commands have

been selected because of their high entropy (signature and checksum).