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).