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