Nagra 2: Boxkey Experiment

Backgound:

In our previous experiment we discussed the CONTROL words used in Nagra 1

and Nagra 2 and proposed a "thought" experiment whereby one could
conclusively determine if the CONTROL words are the same for both streams.
We introduced the IDEA encryption algorithm and suggested that this is the
cryptographic technique used with Nagra 2. Without attempting the actual
experiment, we concluded based on bandwidth considerations alone, that the
same MPEG-2 stream is being used for both Nagra 1 and Nagra 2 (i.e. - the
provider would be foolish to use twice as much video bandwidth to transmit
the same pictures to us---satellite bandwidth costs hundreds of millions of
dollars). Based on this, we concluded with a great deal of certainty that
the CONTROL words (which are used to "put together" the decoded MPEG-2
packets) were the same. Of course, with Nagra 1, we know that the CONTROL
words are encrypted using the cryptographic algorithm called DES. We also
know the Key0 and Key1 which is used with DES. Thus, we have no problem
decrypting the CONTROL words for the Nagra 1 stream.

What about the Nagra 2 stream? We surmised that the NAgra 2 stream uses the
encryption algorithm known as IDEA with different keys, namely IKey0 and
IKey1 which are unknown to us, but must reside somewhere in the EEPROM of
the Nagra 2 cards. But why are we justified in assuming that IDEA is the
encryption being used for Nagra 2? The answer is that "this is what the
experts" think! Not good enough...we need to be absolutely certain. We need
to prove this!

The following experiment will help us make sense out of the Nagra 2
encryption being used and also shed some light on the location of the
boxkeys used by Nagra 2.

Requirements:

-a subbed Nagra 2 system

-a Nagra 1 system
-two dataloggers; one for Nagra 1 setup and 1 for Nagra 2 setup
-copy of: "Applied Cryptography", By: Bruce Schneier (IDEA is outlined on
pp.319 / DES is outlined on pp. 270)

Experiment:

Okay, we know from Nagra 1 that before the card gives the CONTROL words to
the receiver for processing, it encrypts them using DES and the receiver's 8
byte boxkey. This is the same boxkey you all enter into your ROM cards, etc.
This occurs when a command $13 is issued.
It is very likely that Nagra 2 encrypts the CONTROL words using IDEA before
it sends them to the receiver. But, what does it use for the boxkeys? The
same boxkeys as the Nagra 1 cards? Remember, IDEA requires a keylength of 16
bytes, whereas the original boxkeys we all know about are only 8 bytes long.
If we knew what boxkeys are being used for Nagra 2, then theoretically, we
could decrypt both the CONTROL words for Nagra 1 and NAgra 2 and compare to
see if they are the same! If they are, then we have found the boxkeys used
by Nagra 2, confirmed that 16 byte IDEA is being used and are well on our
way to decrypting Nagra 2 video.

Clearly, the 16 byte boxkeys being used must reside somewhere on the
receiver firmware. We can easily dump the firmware and store the hex values
in a text file. Now, write a high level C program that implements the IDEA
algorithm. See Schneir for the mathematical details -- the coding should be
straight forward. Next, write a routine that takes 16 bytes from the
firmware dump and tries to use that as the boxkeys for Nagra 2. Try
decrypting the Nagra 2 CONTROL words and see if they match the ones we know
from Nagra 1. IF they don't match, try different bytes from the firmware
dump. Keep trying! Most likely, the boxkeys for IDEA will be near or
adjacent to the serial number of the card in the firmware! Also, compare
the dumps of 2 different subbed Nagra 2 systems (with the exact same
subscription). Where the dumps differ is most likely the location of the
boxkeys!

Before you can try this, you will need to log the NAgra 1 and 2 streams and
tune into the same channel simultaneously. Log a few command $13 packet
responses and their corresponding Nagra 2 responses SIMULTANEOUSLY. If
someone is willing to do this and post it for us, it would make it a lot
easier to proceed with our Boxkey experiment!

Feedback from all the experts in this hobby would be greatly appreciated!

Good Luck!

nagraman
Regarding IDEA/DES (taken from another website)

DES is an algorithm developed in the 1970s. It was made a standard by the US government, and
has also been adopted by several other governments worldwide. It is widely used, especially in
the financial industry.
DES is a block cipher with 64-bit block size. It uses 56-bit keys. This makes it fairly easy to
break with modern computers or special-purpose hardware. DES is still strong enough to keep
most random hackers and individuals out, but it is easily breakable with special hardware by
government, criminal organizations, or major corporations. In large volumes, the cost of beaking
DES keys is on the order of tens of dollars. DES is getting too weak, and should not be used in
new designs.

IDEA (International Data Encryption Algorithm) is an algorithm developed at ETH Zurich in

Switzerland. It uses a 128 bit key, and it is generally considered to be very secure. It is currently
one of the best public known algorithms. It is a fairly new algorithm, but it has already been
around for several years, and no practical attacks on it have been published despite of numberous
attempts to analyze it.
IDEA is patented in the United States and in most of the European countries. The patent is held
by Ascom-Tech. Non-commercial use of IDEA is free. Commercial licenses can be obtained by
contacting idea@ascom.ch <mailto:idea@ascom.ch>.

Several implementations of IDEA are freely available. See e.g. SSLeay, PGP source code, and
Ssh source code, idea86, Crypto++.

Cryptographic systems need cryptographically strong random numbers that cannot be guessed by
an attacker. Random numbers are typically used to generate session keys, and their quality is
critical for the quality of the resulting systems. The random number generator is easily
overlooked, and becomes the weakest point of the system.

Some machines may have special purpose hardware noise generators. Noise from the leak
current of a diode or transistor, least significant bits of audio inputs, times between interrupts,
etc. are all good sources of randomness when processed with a suitable hash function. It is a
good idea to acquire true environmental noise whenever possible.

Examples of cryptographic random number generators can be found e.g. in PGP source code,
Noiz, and Ssh source code.

Disclaimer: Any opinions and evaluations presented here are speculative, and the author cannot
be held responsible for their correctness