🚀 go-pugleaf

You must be really board today.

"john Smith" <fraustein@hotmail.com> wrote in message
news:ufqbh68rtqu60e@news.supernews.com...
> Keeping Secrets in Hardware: the Microsoft XBox Case
>
> Study
>
> Andrew "bunnie "Huang
>
> AI Memo 2002-008 May 26,2002
>
>
>
> m a s s a c h u s e t t s  i n s t i t u t e  o f  t e c h n o l o g y
>
> a r t i f i c i a l  i n t e l l i g e n c e  l a b o r a t o r y.
>
> Abstract
>
> This paper discusses the hardware foundations of the cryptosystem employed
> by the Xbox TM video game console from Microsoft. A secret boot block
> over-lay is buried within a system ASIC. This secret boot block decrypts
and
> verifies portions of an external FLASH-type ROM. The presence of the
secret
> boot block is camouflaged by a decoy boot block in the external ROM. The
> code contained within the secret boot block is transferred to the CPU in
the
> clear over a set of high-speed busses where it can be extracted using
simple
> custom hardware. The paper concludes with recommendations for improving
the
> Xbox security system.
>
> One lesson of this study is that the use of a high-performance bus alone
is
> not a sufficient security measure, given the advent of inexpensive, fast
> rapid prototyping services and high-performance FPGAs.
>
>
>
> Introduction and Background
>
> Every cryptosystem is based on some kind of secret, such as a key.
> Regardless of the cipher, the security of a cryptosystem is only as strong
> as the secrecy of the key. Thus, some of the most startlingly effective
> attacks on a cryptosystem involve no ciphertext analysis, but instead find
> flaws in the protocols that manage the keys. Cryptosystems based on
> symmetric ciphers are particularly vulnerable to protocol attacks, since
> both the sender and the receiver must be trusted to have a copy of the
same
> secret key.Despite the difficulty of key management in symmetric ciphers,
> they remain attractive because of their algorithmic simplicity and high
> throughput when compared to public key ciphers.
>
> Symmetric cipher key management becomes especially problematic when the
> receiving party is not trusted or is in a position that can be easily
> compromised. This is where tamper-resistant hardware comes into play; a
> summary of tamper-resistance guidelines can be found in [6]. Many systems
> employ tamper-resistant hardware techniques in varying degrees, including
> the Sandia National Labs' "Stronglink" micromechanical 24-bit lock [2],
the
> Clipper chip [1], IBM's 4758 PCI Cryptographic Coprocessor [3],
> Cryptographic Smartcards [5] [4], Automatic Teller Machines (ATMs), and
now,
> video game consoles. However, trusting inadequate physical security
measures
> to protect important secrets is risky. [14] and [15] present examples of
how
> some of the aforementioned tamper-resistant systems can be defeated with
> surprisingly simple and direct methods.
>
> In the case of the Xbox TM video game console from Microsoft, the secret
> being protected is a key and an algorithm for decrypting and verifying a
> bootloader. This bootloader then decrypts and verifies a kernel image.
Both
> the bootloader and kernel image are contained in an unsecured FLASH ROM.
The
> kernel then verifies the authenticity and integrity of the applications it
> runs. Thus, a chain of trust is grown, bottom up, from a seed of trust.
This
> seed-the secret key and an algorithm-is planted in a physically secure,
> secret boot block.
>
> The Xbox architecture results in the deployment of large number of
identical
> devices, all of which contain the same secret information. As the analysis
> below illustrates, the security of such a system can be readily
compromised,
> even if the secret is protected by tamper-resistant hardware and obscured
by
> algorithmic complexity.
>
> 2 Xbox Hardware Cryptosystem Overview
>
> The Xbox crypto protocol presents a strong defense in the face of
unsecured
> FLASH ROM-based modifications. Please refer to figure 1. The Xbox boots
from
> a 512-byte secret boot block that is hard-coded into the southbridge
system
> ASIC (the "MCPX"). This boot block performs the following functions, in
> order:
>
> _ loads the "jam tables", i.e., initializes the console chipset
>
> _ turns on the processor caches
>
> _ decrypts the kernel bootloader, contained in FLASH ROM
>
> _ verifies that decryption was successful
>
> _ jumps to the decrypted kernel bootloader
>
> 3.The bootloader then performs some more system initialization, decrypts a
> kernel image from FLASH ROM, decompresses and verifies the decrypted
image,
> and enters the kernel. The kernel decryption key is stored within the
> bootloader image. Note that the secret boot block code is structured so
that
> the bootloader decryption key is never written to main memory, thus
> defeating an attack that involves eavesdropping on the main memory bus.
>
> The bootloader is encrypted with RC-4 using a 128-bit key. The decryption
> algorithm and key are stored in the secret boot block and executed by the
> Pentium CPU; the busses between the secret boot block and the CPU are not
> encrypted but assumed to be secure due to their high speeds. The
decryption
> of the bootloader image is verified by checking for a 32-bit magic number
> near the end of the plaintext stream. This check only ensures that the
> ciphertext stream was not corrupted; one with knowledge of the secret key
> and the magic number can easily create original bootloader images. It is
> fairly clear from the code structure of the secret boot block that such a
> simple, unreliable check was employed because there was not enough space
for
> anything else. The magic number check might also confuse efforts to create
> original bootloader code based on a key obtained without full knowledge of
> the secret boot block's contents, such as through a personnel leak or
brute
> force. However, a brute force approach to re-covering the bootloader is
> probably out of the question, since distributed.net's "bovine" effort,
> running for over 4 years and currently capable of testing over 100
> gigakeys/s, is still working on a 64-bit RC-5 cipher at the time of
writing
> [7].
>
> Given this secure boot protocol, modifying the contents of the FLASH ROM
> alone will stand a very low chance of revealing anything useful about the
> console 1 .This is compounded by the fact that the FLASH ROM contains a
> decoy boot block with halfway reasonable looking decryption and
> initialization code. The algorithm in the decoy boot block is a
bastardized
> RC-4, and of course applying this algorithm on the ROM contents yields
> nothing but white noise. Further discussion on how the secret boot block
was
> discovered is contained in the next section.
>
>
>
> 3 Breaking the Physical Security
>
> This section provides a chronology of how the Xbox's physical security was
> reverse engineered. Reading out the FLASH ROM contents and tracing the
> processor's execution starting from the boot vector proved to be futile,
as
> the contents of the boot block in the FLASH ROM were a decoy, cleverly
> designed to thwart such activity. The code within the FLASH ROM boot block
> followed the same general flow as the code within the secret boot block,
but
> the decryption algorithm, the keys and the ciphertext start location were
> incorrect. This initially resulted in a great deal of confusion but was
> later
>
> explained by the discovery of the secret boot block overlay. The
realization
> of the existence of a secret boot block happened as a result of the
> observation that overwriting the processor reset vector in the FLASH ROM
has
> no effect on the Xbox boot sequence. This led to a series of experiments
> that mapped out.
>
> The block is believed to be 512 bytes in length, situated at the highest
> location in processor physical memory. The following approaches were then
> considered for extracting the secret boot block contents:
>
> _ decapping the MCPX southbridge ASIC
>
> _ using the JTAG boundary scan on the Pentium to step through the "real"
> boot sequence
>
> _ probing the main memory bus for any portions of the boot block that were
> written to memory
>
> _ probing the processor-northbridge bus using a logic analyzer or custom
> hardware
>
> _ probing the HyperTransport northbridge-southbridge bus using custom
> hardware
>
>
>
> The direct approach of decapping the MCPX southbridge ASIC was rejected
> be-cause this ASIC appears to be manufactured in a 0.13_ process with
> perhaps 6 or 7 metal layers (figure 2). Extracting the bootblock from this
> ASIC would require a de-layering facility and access to an electron
> microscope. While there are companies such as Chipworks that specialize in
> these kinds of services, it is a difficult, expensive, and time-consuming
> task.
>
> Figure 2: Die shot of the MCPX Southbridge ASIC
>
> The JTAG boundary scan approach was rejected on the grounds that the TRST#
> pin, used to hold the JTAG chain in reset, was tied active in a manner
that
> was difficult to modify without removing the processor. Removal and
> socketing of the processor was considered to be prohibitively expensive
and
> time consuming; the cost of a BGA socket for the Pentium III is estimated
to
> be in the hundreds to thousands of dollars. In addition, the JTAG boundary
> scan codes for the Pentium III are largely proprietary and would have to
be
> reverse engineered as well.
>
>
>
> SDRAM probing was rejected on the grounds that far too many pins (128 data
> pins 6.alone) had to be simultaneously probed, and on the grounds that the
> decryption routine and/or key could be held entirely in processor cache
and
> never written to SDRAM. Also, the cost of solder-on
> TQFP-100-to-logic-analyzer adapters is prohibitive (around $600 per
adapter;
> four are required). Probing the processor-northbridge bus was rejected for
> similar reasons: at least 64 data pins had to be probed, and tapping such
a
> large number of GTL+ signals without causing signal integrity issues was
> thought to be very difficult.
>
> The northbridge-southbridge bus, however, showed promise because of its
> simplicity. The bus has a low signal count (10 unique) and all the signal
> traces are laid out on the console's motherboard in a straight
flow-through
> fashion (12-mil center-to-center spacing within a differential pair,
13-mil
> spacing between differential pairs, see figure 4). In addition, the clock
> and strobe signals for both the transmit and receive directions are
clearly
> labeled on the motherboard, perhaps for manufacturing debug and test
reasons
> (figure 3). Data on the nVidia nForce chipset [9], a close relative to the
> Xbox chipset, indicates that the bus uses the Hyper Transport (formerly
> known as Lightning Data Transport (LDT)) protocol. The specifications for
> the Hyper Transport protocol are open and readily available. [8]
>
> Figure 3: Hyper Transport bus layout showing silkscreen information
>
> The primary difficulties in tapping the Hyper Transport bus are its high
> speed (200 MHz DDR) and its use of differential signaling (few logic
> analyzers come with support for differential signaling). It is interesting
> to note that Hyper Transport bus protocol 7.analyzers are commercially
> available from vendors such as FuturePlus, but they cost upward of
$25,000.
> This price does not include the high-end logic analyzer required to drive
> the protocol analyzer.
>
> The alternative solution to tapping the northbridge-southbridge Hyper
> Transport bus was to build a relatively cheap, fully custom,
> differential-to-single-ended "Tap Board", and to connect the output of
this
> board to an FPGA. A Xilinx Virtex-E part was used in this study because it
> was readily available, as it was used as part of the author's thesis work;
> however, a better choice would be any of the new Xilinx Virtex-II FPGAs. A
> suitable Virtex-II FPGA would cost about $50 in single quantities.
>
> The custom Tap Board uses a two-layer, 6 mil trace/space, 15 mil hole
> process from Advanced Circuits, offered at a price of $33 per board in
small
> quantities. A Texas Instruments SN65LVDS386 LVDS-to-TTL converter was used
> to turn the differential Hyper Transport signals into a single-ended
format.
> It turns out that the Hyper Transport physical signaling specification is
> similar to LVDS, but with a different common-mode offset. The output of
the
> converter drives a cable to the FPGA board. The FPGA is configured to
> receive the high speed signals with the CTT (Center-Tap Terminated)
"Select
> I/O" option. CTT is chosen because it allows the single-ended TTL drivers
to
> be terminated with a low impedance to 1.5V and still function properly.
Note
> that although Virtex-E FPGAs support LVDS directly, the target FPGA board
> was not originally designed to support the LVDS configuration.
>
>
>
> Figure 4: Dimensions of the Hyper Transport signal traces on the
> motherboard. The Tap Board has on one edge a pattern of traces with no
> solder mask that matches the pattern of traces on the Xbox motherboard.
The
> Tap Board was soldered directly to the Xbox's northbridge-southbridge bus.
> Only the receive-direction Tap Board was mounted for this study. The
mating
> edge was shaped using a belt sander, so that the tapping traces were flush
> with the edge of the board, and the board could be mounted at a reclined
> angle to enhance solderability. The solder mask on the Xbox was re moved
> with fine-grit sand paper, and the Tap Board was carefully aligned by
hand,
> and then held roughly in place by soldering a coarse piece of wire between
> the Tap Board and the motherboard. A hard-setting adhesive, such as
> Miller-Stephenson Epoxy 907, was ap-plied to fix the angle and mating
> distance of the Tap board to the motherboard; once the epoxy was cured,
the
> holding wire was removed, and the traces between the Tap Board 8.and the
> Xbox motherboard were easily soldered using a fine-tip iron and a
> microscope.
>
> Figure 5: Tap Board connected to the FPGA board.
>
> The FPGA board was originally developed by the author for another work.
The
> polarity of the Hyper Transport bus signals was determined by probing the
> idle state of the wires, assuming that their idle state had a value of
0x00.
> Those signals that had the positive and negative pairs swapped relative to
> the Tap board layout idled to a "1". Signals with inverted polarity were
> restored to their true value within the trace capture FPGA.
>
>
>
> Figure 6: Close-up of the Tap Board mounted in the Xbox
>
> A Xilinx Virtex-E FPGA was used to capture traces of Hyper Transport bus
> activity. It was difficult getting the FPGA to manage the 200 MHz DDR data
> rates with 9. low skew. However, careful hand-layout of the input
registers,
> post-layout timing simulations at nominal temperature and voltage, and
> iterations to manually tweak delays and skews eventually centered the
clock
> signal within the data signal on the FPGA's input registers. The retimed
> data was then demultiplexed to a very manageable 100 MHz single-data rate
> 32-bit wide bus and written into a bank of FIFOs, along with a sequence
> count that recorded at what cycle relative to a reset signal the data was
> captured. Some additional logic was incorporated into the FPGA that
> discarded idle values (0x0000 0000) from the trace FIFOs and formatted the
> de-serialized data relative to the strobe signal, clearly identified on
the
> Xbox motherboard as "RXD8 / RXD*8" (figure 3) in sector 5D (the Xbox
> motherboard has a coordinate system printed on its periphery).
>
> The reset signal can be determined by probing traces near the Hyper
> Transport bus that behaved like a reset signal. In reality, it is possible
> that some signal that was not the true reset signal was used to trigger
the
> trace capture, but that is irrelevant as the signal chosen seemed to
display
> a consistent timing relationship with respect to the bus. In fact, the
> signal used to trigger the trace capture exhibited a 350 ns runt pulse
about
> 67 ms after power-on-reset; this runt pulse was filtered out by a state
> machine, as it was erroneously restarting the trace capture.
>
> Once traces of data were captured by the FPGA, the order of the bits on
the
> Hyper Transport bus relative to the Tap Board layout could be determined.
> This can be done by correlating known values in the FLASH ROM with data
> values captured on the Hyper Transport bus. A 1's count can be used to
> identify candidate patterns and data sequences for manual correlation.
> Fortunately, very early on in the trace several distinctive, sequential
> values are grabbed from the FLASH ROM: a few values from the lowest
address
> in FLASH ROM, followed by a few values from the boot vector, which happens
> to be identical between the decoy FLASH ROM contents and the secret boot
ROM
> contents. The order of the traces for the receive-direction bus on the
> motherboard are believed to be, from the outside to the inside, bit 8 (CTL
> strobe), 4#, 0#, 7#, 2#, 3#, CLK#, 5, 6#, and 1#. Signals with # after
them
> are inverted with respect to the Tap Board layout.
>
> The raw trace data captured by the FPGA was then dumped to files and
> manually processed. An example illustrating the format of trace data can
be
> found in figure 7. The sequence number was critical in determining the
> boundaries of cache traces; blocks
>
> of 8 or 16 words are fetched by the processor, even when the caches are
off.
> Trace data was differentiated between secret boot code and FLASH ROM data
by
> searching for the first word of the candidate trace in a dump of the FLASH
> ROM; if the data could not be found in the FLASH ROM, it was guessed to be
> secret boot code. Because the processor boots with its caches off, the
first
> roughly 24 million bus cycles contained repeated line fills of the "jam
> table" initialization code, and were ignored as they just performed the
> wrote initialization of the chipsets. The caches were then turned on by
the
> boot code, and very clear and simple to read blocks of instructions and
data
> were found. These instruction traces were mapped into the secret boot
block
> using the decoy FLASH ROM boot block as a template. The recovered block of
> code was then disassembled, and the decryption algorithm was determined to
> be 128-bit RC-4.
>
> Because the location of the 128-bit key within the secret boot block was
> ambiguous (the Tap Board only provides data traces without addresses), a
> brute-force search was 10.
>
> 00000097 : 664A1D55 ::: E : 000000C6
>
> 00000D5C : 05F108F6 ::: F : 01000000
>
> 00000DE0 : 2A1A2841 ::: 1 : CC003000
>
> 00000E5D : B6FE7F68 ::: E : A0552C01
>
> 00000EDA : 5932C662 ::: 1 : 000000FD
>
> 00000F57 : F9FBA4C1 ::: E : C7C94000
>
> 00000FD4 : F7F9B6AE ::: 1 : 000000C6
>
> 00001051 : 73376133 ::: E : 9EC49400
>
> 000010CE : FD0127AD ::: 1 : 000000D6
>
> 0000114B : 34E8FD29 ::: E : C7C94000
>
> 00001245 : 1814A022 ::: 1 : 000000C6
>
> 000012C2 : 38EBD672 ::: E : C7C94000
>
> 00022526 : C6C0847E ::: 1 : 000000C6
>
> 00022527 : A26216BB ::: E : C7C94000
>
> 00022528 : 99DA5F80 ::: E : 000000C6
>
> 00022529 : 453862E3 ::: 1 : C7C94000
>
> 000226D5 : B6DF18C0 ::: E : 000000C6
>
> 000226D6 : DA562768 ::: 1 : C7C94000
>
> 000226D7 : 0F1D66E3 ::: E : 000000C6
>
> 000226D8 : DDC59B59 ::: 1 : 8D42CBCD
>
>
>
> Figure 7: An example illustrating the format of trace data captured by the
> FPGA.
>
> Format of the data is "sequence : data ::: aligner : unaligned data".
> utilized to help isolate the key. A 16-byte sliding "guess key" window
over
> the captured data trace was used as input to an RC-4 decryption engine,
and
> a histogram of the data output was used to determine when the key was
found.
> This information helped resolve some ambiguities in the placement of the
> data within the secret boot block, and a full picture of the important
code
> within the secret boot block was assembled. Now that the secret boot
> procedure is understood, it is possible to encrypt a new ROM for the Xbox
> console, and to further study the structure of the Xbox bootloader and
> kernel. Given the RC-4 algorithm, the 128-bit key, and the magic check
> number at the end of the decrypted segment, one can run original code on
the
> Xbox.
>
> 4 Lessons Learned
>
> One lesson of this study is that the use of a high-performance bus alone
is
> not a sufficient security measure; the advent of cheap, fast rapid
> prototyping services and high performance FPGAs allows even poor students
to
> create devices that can tap the bus. However, encrypting a bus introduces
> its own problems. A secure cipher on a high performance bus significantly
> impacts latency, power consumption, and reliability. Power consumption is
> increased because the activity factor for the bus approaches 100%, if the
> encryption scheme is any good. In this case, the power consumed driving
the
> bus 11.would increase by over an order of magnitude, as the observed
> activity factor on the northbridge-southbridge bus was well below 10%.
> Reliability is hurt because a single bit error, even during an idle cycle,
> can corrupt large blocks of data; with a stream cipher, the corruption
would
> extend until the stream is resynchronized.
>
> A compromise solution to the problem is to simply not trust any bus in the
> system. In this case, the secret boot block might employ a digital
signature
> protocol, such as Authenticode R , using public key algorithms and one-way
> hashes. [10] Then, all security rests in the secrecy of the private key,
and
> the strength of the public key algorithm.
>
> In order to prevent employee leaks from spreading a private key, a system
> similar to the BBN SignAssure TM could be used to manage the key so that
no
> human ever has knowledge of the private key. The principal drawback of
this
> method is that it requires extra silicon area to be spent on storing a
> larger secret boot block, as it is probably difficult, if not impossible,
to
> code a full public key encryption algorithm plus key storage and hardware
> initialization code within 512 bytes. The above suggestion does not
prevent
> someone from eavesdropping and obtaining the plaintext of the operating
> system code, but it does effectively defeat any attempt to run original
> code. The public key scheme could be defeated, however, by a mechanism
that
> snoops the main memory bus and patches plaintext in main memory. As
> discussed previously, this approach is possible, but difficult; however,
the
> tenacity of an attacker should not be underestimated. For example, a known
> attack on the Sony Playstation2 console was developed that is rumored to
> work by dynamically patching its high-performance RAMBUS memory system.
The
> difficulty of a memory patch attack could be increased by using a simple
> periodic hash and check of the critical code regions in memory.
>
> Buffer overrun exploits are also a point of weakness, and they work
> regardless of the secret boot protocol. An attacker sniffing an insecure
bus
> could obtain the decrypted kernel code and analyze it for weaknesses.
> However, any machine architecture that employs guarded pointers [11] is
much
> more difficult, if not impossible, to attack using buffer overruns. A
fast,
> efficient guarded pointer scheme with a simple hardware implementation is
> described in [12]. This scheme can easily be adapted to work in a 64-bit
> architecture.
>
> A. Kerckhoffs (1835-1903) once stated that the security of a
> cryptosystemmust not depend on keeping the algorithmsecret; this is
referred
> to as Kerckhoffs' Principle.[13] Another way of stating this is that there
> is no security through obscurity. In particular, it is an error to assume
> that a secret, distributed along with the information it guards, is  never
> revealed. For example, the Sega Dreamcast uses a proprietary
GD-ROMsoftware
> format; but, the drive can read CD-ROM disks. The discovery of a back door
> in the Dreamcast OS allowed executables to be run directly from a standard
> CD-ROM, thus nullifying the barrier presented by the proprietary
> GD-ROMformat. Other systems that rely on well-hidden secrets, including
the
> Clipper chip [14] and the smartcards used widely throughout Europe to
> control access to services such as pay-TV, cell phones and gas, have been
> shown to be surprisingly vulnerable. [15] In this case, the Tap Board and
> trace capture FPGA design was developed in spare time over the duration of
> three weeks-including the 5-day turn time for board fabrication-for a
total
> cost of around $50 per board. In other words, if you ship your secrets in
> your hardware, it is a good assumption that the users will eventually-and
> perhaps quickly-know your secrets.
>
> The failure of the Microsoft Xbox console security protocol is compounded
by
> the fact that, as a console manufacturer, design-for-test and
> design-for-manufacturability is paramount. Creating a console with too
much
> security makes it difficult to debug and manufacture. For example, the
> backside of the Xbox motherboard is populated with test points-including
> test points for every pin on the FLASH ROM. These were originally
installed
> because of the desire to quickly test for faults during manufacturing. The
> flip side is that one could build a custom "bed-of-nails" tester jig that
> uses the the FLASH-ROM test points to reprogram Xbox motherboards with any
> desired code.
>
> This method would be fast, inexpensive and solder-free. The lesson here is
> that even if a manufacturer is very confident about their trust model and
> security protocols, it must guard against the possibility that they may
> someday be broken. To this extent, a simple physical security measure,
such
> as a spray-on conformal coating, would severely hamper the re-use of test
> structures for improper purposes. This of course greatly complicates the
> repair of hardware failures in the field, but that is a business trade-off
> the manufacturer must make.
>
> A more radical alternative would be to design the gaming system using
> proprietary hardware and proprietary media formats, thus limiting the
> practical impact of any at-tack on the console. Game consoles are
> manufactured in very high volumes, so the cost of developing a simple but
> effective proprietary format can be amortized. The format could then be
> patented, providing protection against unauthorized use without the need
for
> secrecy. This approach was taken by Nintendo with their Nintendo 64
console.
> [16] Although patents have a 20 year lifetime, this is an eternity in the
> video game console industry: the original Nintendo Entertainment System
> (NES) had its debut in 1985.
>
> 5 Future Work
>
> Understanding the secret Xbox boot protocol is just the first step in
> understanding the Xbox. It is now possible to investigate the kernel and
> bootloader in more detail. It has been determined that the kernel is also
> encrypted with RC-4/128, and it is also believed to be compressed using
LZX
> compression, a scheme employed by Microsoft's canonical distribution
format,
> the "Cabinet" file. The structure and function of the kernel is still
being
> investigated.
>
> One important issue to investigate is the privacy of users who use the
Xbox
> for on-line tasks. It is known, through a parallel effort of the author,
> that information such as the serial number of the console is stored
> electronically and is probably accessible to the kernel. What happens to
> this information when the Xbox is plugged into the internet?
>
> Because of the encryption used to secure the Xbox, the nature of the
> information that is relayed to Microsoft's on-line game servers is
unknown.
> Thus, important future work is to try to determine what the Xbox reveals
> about the user's identity and personal gaming habits.
>
> Addendum
>
> It has recently been called to the author's attention that the hardware
> initialization procedure of the Xbox contains a significant weakness. [17]
> Recall from section 2 that the first step in the Xbox boot process is to
> load the "jam tables" that configure the console's chipsets. This jam
table
> initialization procedure involves a lengthy and complex sequence of writes
> to various memory-mapped hardware register locations. As a result, the
> initialization procedure is implemented using a simple bytecode
interpreter
> that reads initialization commands and data from the FLASH ROM. These
> bytecode commands-stored as plaintext-can be manipulated to cause the
> initialization procedure to abort before the kernel
decryption/verification
> routine is executed, and to instead run insecure code directly out of the
> FLASH ROM. In other words, with plaintext-only modifications in the FLASH
> ROM, one can entirely bypass the Xbox's security mechanism. One could
easily
> fix this security hole, however, by verifying the jam table's contents
prior
> to bytecode execution with a one-way hash function, or by explicitly
coding
> all initialization functions within the secure boot block. Both of these
> solutions, however, would require the secure boot block to grow
> significantly from its current 512-byte size, and neither solution allows
> easy changes to the initialization procedure in case a bug is found or in
> case the hardware evolves as a result of cost reduction efforts.
>
> Acknowledgments
>
> The author would like to acknowledge the support of the on-line electronic
> community. The author would also like to thank the Electronic Frontier
> Foundation for providing legal counsel. Hal Abelson and Tom Knight also
> provided invaluable moral support. Finally, the author would like to thank
> Nikki Justis for all her love and support, and for giving him such an
> interesting toy for Christmas.
>
>
>
> References
>
> [1] Federal Information Processing Standards Publication, FIPS PUB 185:
> Escrowed
>
> Encryption Standard (EES) http://www.itl.nist.gov/fipspubs/fip185.htm
>
> [2] Thomas W. Krygowski, Jeffry J. Sniegowski, M. Steven Rodgers, Stephen
>
> Montague, James J. Allen, Jerome F. Jakubczak, Samuel L. Miller,
> Infras-tructure,
>
> Technology and Applications Of Micro-Electro-Mechanical Systems
>
> (MEMS), Sandia National Laboratories, Intelligent Micromachine Department,
>
> http://www.mdl.sandia.gov/Micromachine, also appears in Sensor Expo 1999.
>
> [3] IBM, IBM 4758 PCI Cryptographic Coprocessor,
>
> http://www.ibm.com/security/cryptocards/
>
> [4] Gemplus (a smartcard vendor), Gemplus Corporate Website,
>
> http://www.gemplus.com
>
> 14.[5] Pil Joon Lee, Eun Jeong Lee, Yong Duk Kim, How to Implement
> Cost-Effective
>
> and Secure Public Key Cryptosystems Proceedings of the First International
> Work-shop
>
> on Cryptographic Hardware and Embedded Systems (CHES), August 1999.
>
> [6] Federal Information Processing Standards Publication, FIPS
>
> PUB 140-2: Security Requirements for Cryptographic Modules,
>
> http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
>
> [7] distributed.net, distributed.net: Project RC5,
> http://www.distributed.net/rc5/
>
> [8] HyperTransport Consortium, HyperTransport TM I/O Link Specification,
> Version
>
> 1.03, http://www.hypertransport.org
>
> [9] nVidia Corporation, nForce MCP Product Overview, 06.01v1,
>
> http://www.nvidia.com
>
> [10] Microsoft Developer Network, Introduction to Code Signing,
>
> http://msdn.microsoft.com/workshop/security/authcode/intro
authenticode.asp
>
> [11] Nicholas P. Carter, Stephen W. Keckler, and William J. Dally,
Hardware
> support
>
> for fast capability-based addressing, Proceedings of ASPLOS VI, October
> 1994,
>
> pp. 319-27.
>
> [12] Jeremy Brown, J.P. Grossman, Andrew Huang, and Thomas F.
>
> Knight, Jr., A capability representation with embedded address
>
> and nearly-exact object bounds, Project Aries Technical Memo 5,
>
> http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-05.pdf
>
> [13] Auguste Kerckhoffs, La cryptographie militaire, Journal des sciences
> militaires,
>
> vol. IX, pp. 5-38, Jan. 1883, pp. 161-191, Feb. 1883.
>
> [14] R. Anderson and M. Kuhn, Tamper Resistance - a Cautionary Note,
> Proceedings
>
> of the Second Usenix Workshop on Electronic Commerce, pp. 1-11, November
>
> 1996.
>
> [15] R. Anderson and M. Kuhn, Low Cost Attacks on Tamper Resistant
Devices,
>
> IWSP: International Workshop on Security Protocols, LNCS, 1997.
>
> [16] Van Hook, et al., High Performance Low Cost Video Game System with
> Co-processor
>
> Providing High Speed Efficient 3D Graphics and Digital Audio Signal
>
> Processing, U.S. Patent 6,239,810, May 29, 2001.
>
> [17] Private conversation with visor. visor can be reached by sending a
> personal mes-sage
>
> to visor on www.xboxhacker.net
>
>
>
> Andrew Huang's page:
http://web.mit.edu/bunnie/www/proj/anatak/xboxmod.html
>
> Andrew Huang's Tech Memo in pdf:
> ftp://publications.ai.mit.edu/ai-publications/2002/AIM-2002-008.pdf
>
>
>