SHA-1 is the Secure Hash Algorithm recommended by the Federal government in FIPS publication 180-1 (http://www.itl.nist.gov/
fipspubs/fip180-1.htm). Devised by the NSA and based on Ronald L.
Rivest’s MD4 message digest algorithm, SHA-1 works on messages of
any length less than 264bits in length, and it produces a 160 bit output.
The SHA-1 hash algorithm starts with a deterministic 160-bit seed state;
this state is blended with a block of 512 bits of message data over four rounds. Each round consists of a series of non-linear functions, rotations, shifts and XORs. The result of a round is used to seed the next round’s computation. In general, 280 random messages need to be generated, hashed and “simultaneously” compared in order to find two messages that have the same hash value (i.e., a hash collision). Finding two random messages that have the same hash is known as the “birthday attack,”
named after the probabilistic phenomenon called the “birthday para-dox”: the probability that two people share the same birthday in a room of 23 people is better than 50%. On the other hand, 2160 random messages need to be generated, hashed and compared in order to find a message that hashes to the same value as a specific message. Thus, the strength of a hash function depends heavily upon the manner in which it is used.
TEA
TEA, or tiny encryption algorithm, was developed by David Wheeler and Roger Needham at the Computer Laboratory of Cambridge University. (The developers have a web page for TEA at http://
vader.brad.ac.uk/tea/tea.shtml; much of the material pre-sented here is gleaned from that page.)
As its name implies, TEA is a compact, fast encryption algorithm suitable
void encipher(unsigned long *const v,unsigned long *const w, const unsigned long *const k)
{
register unsigned long
y=v[0], z=v[1], sum=0, delta=0x9E3779B9, a=k[0], b=k[1], c=k[2], d=k[3], n=32;
while(n—>0) { sum += delta;
y += (z << 4)+a ^ z+sum ^ (z >> 5)+b;
z += (y << 4)+c ^ y+sum ^ (y >> 5)+d;
}
w[0]=y; w[1]=z;
}
Listing 7-1: TEA Algorithm in ANSI C3
3 Code is from http://vader.brad.ac.uk/tea/source.shtml#ansi
Figure 7-1: Tea cipher usage scenarios.
TEA used as a hash function
Figure 7-2: Inner structure of TEA. This diagram depicts a single round of TEA, which is repeated 32 times for the full cipher. The key schedule is described in the boxes on the right for use as both a cipher and as a hashing function.
A B
for encrypting real-time data streams and embedded applications where processor performance and storage space is tight. TEA has a 128-bit key and it operates on 64-bits of data at a time, and each of its 32 rounds uses only shifts, XORs and additions. (The algorithm, given in Listing 7-1 and Figure 7-2, is optimized for implementation on 32-bit general-purpose processors.)
The bantam TEA algorithm is believed to be quite secure when used to encrypt and decrypt data. However, TEA is not used for encryption in the Xbox; it is actually used as a hash function by operating the cipher in a modified Davies-Meyer mode. The region to be hashed is divided into 64-bit blocks. These source data blocks are used as half of the key input to TEA. The other half of the key input comes from the result of the previous TEA operation, and the first TEA operation uses a magic number as its input.
The result is a 64-bit hash function, as depicted in Figure 7-1. This hash is weak against birthday attacks, especially given the computational effi-ciency of TEA, as only 232 message pairs need to be tested on average to find a collision. Even though a birthday attack does not apply in the Xbox’s usage scenario, the Xbox runs the hash twice, each time with a different magic number seed, and concatenates the results to generate a single 128-bit hash value — probably in an attempt to foil brute-force attacks.
Unfortunately, TEA has a weakness in its key schedule: every TEA key has four related keys. In other words, for every key, you can generate three other keys that produce the same ciphertext result with the same input data. Related-key generation is as simple as complementing pairs of key bits (bits 31 and 63 is one pair, bits 95 and 127 are the other pair).
This makes TEA unsuitable for use as a hash function, and this weakness is well documented in the paper “Key-schedule cryptanalysis of IDEA, G-DES, GOST, SAFER, and triple-DES,” by John Kelsey, Bruce Schneier, and David Wagner, presented many years ago at CRYPTO 1996. This weakness was later leveraged by a team headed by Andy Green to break the second version of the Xbox security scheme.
RC-4
RC-4 (Ron’s Code or Rivest Cipher 4) is a variable key-length stream cipher by Ron Rivest. The heart of RC-4 is the keystream generator. It can be thought of as a cryptographic pseudo-random number generator (CPRNG). The output of the CPRNG is XOR’d one byte at a time with a plaintext stream to generate the ciphertext. Decryption is accomplished in a similar fashion. Loosely speaking, the generator is “seeded” with a value (the key) of up to 256 bytes (2048 bits) long. If the key is shorter than 256 bytes, it is repeated to fill out the 256 bytes before use as a seed; this enables variable-length keys. In the Xbox, the key is 16 bytes (128 bits) in length, and thus the cipher is dubbed RC-4/128.
typedef struct rc4_key { unsigned char state[256];
unsigned char x;
unsigned char y;
} rc4_key;
void prepare_key(unsigned char *key_data_ptr, int key_data_len, rc4_key *key) {
unsigned char swapByte, index1, index2;
unsigned char* state;
short counter;
state = &key->state[0];
for(counter = 0; counter < 256; counter++) state[counter] = counter;
key->x = 0; key->y = 0;
index1 = 0; index2 = 0;
for(counter = 0; counter < 256; counter++) { index2 = (key_data_ptr[index1] + state[counter] + index2) % 256;
swap_byte(&state[counter], &state[index2]);
index1 = (index1 + 1) % key_data_len;
} }
void rc4(unsigned char *buffer_ptr, int buffer_len, rc4_key *key) {
Listing 7-2: RC-4 code in C, from original Usenet posting.4
4 Code from http://www.cc.jyu.fi/~paasivir/crypt/rciv/
rc4article.txt. Minor white-space modifications to make it all fit on one page. The swap byte function definition is also not included, but you can guess what it does by its name.
RC-4 is thought to be a strong cipher, although there are a few known weaknesses in the key scheduling algorithm that can be leveraged in poorly designed cryptosystems, such as WEP. Scott Fluhrer, Itsik Mantin, and Adi Shamir document these weaknesses in a paper titled “Weaknesses in the Key Scheduling Algorithm of RC4,” presented at the Eighth Annual Workshop on Selected Areas in Cryptography (August 2001). None of these weak-nesses can be applied against the Xbox’s implementation of RC-4.
There is, however, a potential problem in the way that RC-4 is used in the first version of the Xbox security. RC-4 is used on the Xbox to encipher a stream of x86 code, and no significant check is performed on the deciphered code to ensure the integrity of the plaintext. This means that changes in the ciphertext will lead to changes in the code that the Xbox executes. The trick is to figure out a change in the ciphertext that leads to a meaningful code modification. Since RC-4 encrypts one byte at a time and x86 opcodes can be as short as a single byte, it requires no more than 28 = 256 iterations to “brute force” an instruction into a single known location by mutating the ciphertext.
Determing which location to brute force can be tricky, but I suspect a lot of information could be derived by mutating ciphertext bits and observing what happens to the pattern of instruction fetches, even with the caches turned on. The goal would be to try and identify the location of a jump opcode’s operands and to modify the jump destination such that the secured program jumps into an unsecured region of memory.
The process would be similar to playing the classic board game “Battle-ship.” Keep in mind that the attack is so easy that guessing through a kilobyte of code only requires a maximum of 218 iterations. The guessing process could be automated by integrating a logic analyzer with a ROM emulator via a control script running on a host computer.
The history behind RC-4 is actually quite interesting. RC-4 was invented in 1987 by Ron Rivest, and was kept as a trade secret by RSA Security, Inc. until it was released in 1994 by an anonymous post to a cypherpunks mailing list (see Listing 7-2). As a result of RC-4’s virtues of simplicity and robustness, it has found its way into numerous applications, including WEP, SSL, SQL, and CDPD. While the source code for RC-4 is widely
Figure 7-3: Use of RSA with session keys.
key
Figure 7-4: RSA used to implement digital signatures.
distributed and well known, the cipher is still the intellectual property of RSA Security. I wouldn’t recommend integrating it into a commercial product without first obtaining a license from RSA Security.
RSA
RSA is a public-key algorithm devised by Ron Rivest, Adi Shamir and Leonard Adleman in 1977. In a public-key algorithm, two distinct keys are used, a public key and a private key. As their names imply, the private key must be kept secret, while the public key can be freely distributed. The math behind RSA is briefly described in the sidebar titled “The RSA Algorithm.” You need not understand the details of the math behind RSA to grasp how RSA is used in the context of the Xbox.
Brute-force attacks are currently thought to be infeasible on RSA with keylengths in excess of about a thousand bits. Also note that one cannot be too cavalier about how RSA is integrated into a cryptosystem. There are some attacks against protocols that use RSA, such as tricking the private key holder into signing carefully crafted messages that can then be used to derive the signer’s private key.
Encrypting a message using RSA is as simple as invoking RSA on a message. However, RSA encryption works on message blocks that are too short and the encryption process is too slow to be practical for most messages. Thus, RSA is typically used to encrypt a single-use random key, called a session key, for a fast symmetric cipher such as AES that is then used to encrypt the bulk message. This process is illustrated in Figure 7-3.
In addition to encryption, RSA enables digital signatures. A digital signature allows parties exchanging messages over an insecure medium to guarantee that messages are not forged and are not modified. The message does not have to be encrypted. A typical digital signature protocol works as follows: The sender computes a hash of the message to be sent. This hash is then encrypted with the sender’s private key and included with the message plaintext. The receiver decrypts the encrypted message hash using the sender’s public key, and compares this hash against a locally
computed hash of the received message. If the decrypted hash sent with the message and the locally computed hash agree, then the receiver could conclude that the message is authentic and unaltered. This process is outlined in Figure 7-4.
If this protocol sounds complex to you, it is. There are a lot of places where things can go wrong. The receiver could have a false copy of the sender’s public key. The sender could have had his private key compro-mised. The hash could have weaknesses. Employing digital signatures in an adversarial environment requires attention to detail at all levels of the system design.
In the Xbox, digital signatures are used to control the distribution and sale of programs for the console. Microsoft is effectively in control of both the sender and the receiver of messages. The receivers — Xbox consoles — are programmed to only run programs that are digitally signed by Microsoft. In an ideal world, this guarantees that Microsoft has the final