Variable security code download for an embedded processor

This application claims the benefit of the following provisional Application Nos. and filing dates: 60/140,189, filed Jun. 18, 1999; 60/138,381, filed Jun. 9, 1999; and 60/138,164, filed Jun. 8, 1999.

This invention related in general to data processing devices and more specifically to an apparatus and methods for allowing a processing device to utilize flexible security when receiving information downloads.

BACKGROUND INFORMATION

Processing devices often have embedded programs or firmware stored in non-volatile memory. The firmware is executed by an embedded processor to achieve the desired functionality. Conventional high security applications have relied upon read only memory (ROM) to store the firmware.

Lower security processing devices have begun storing firmware in a reprogrammable memory device. The ability to reprogram the processing device is desired because this feature allows efficient debugging of the firmware. Those skilled in the art appreciate that firmware development typically requires many revisions. Reprogrammable memory avoids the need to discard an integrated circuit which includes the memory each time the firmware revision changes. Furthermore, the ability to reprogram the memory allows firmware upgrades of the processing device in the field as new bugs are fixed or as new features are added.

Although reprogrammable memory is readily available, the ability to reprogram a high security processing device is problematic. In the cable television industry, for example, there are risks that a “cable pirate” could use the reprogrammability feature to disable any security features designed to thwart pirates by replacing the firmware. Accordingly, the reprogrammability aspect is desired, but is viewed as impractical for security reasons.

Conventional high security processing devices use an integral ROM which is masked into an application specific integrated circuit (ASIC) at the time of manufacture. Masked ROMs add little to the cost of the ASIC and cannot be changed by pirates in order to defeat the security.

However, the firmware cannot be changed once the ASIC is produced. Accordingly, all debugging of the firmware takes place on emulators and prototype ASIC devices before production ASICs are manufactured. Use of emulators is problematic because they are typically much slower than a production ASIC and they are often not exact replicas of the production ASIC. With regard to debugging with a prototype ASIC device, they are expensive and a number of prototype ASICs could be required to iteratively debug a design. It can take weeks to produce another iteration of prototype ASIC which could cause serious delay to a development program. As those skilled in the art appreciate, firmware debugging of masked ROMs is a slow and expensive proposition.

In summary, it appears desirable to develop a processing device which is reprogrammable, but not susceptible to later attack by pirates. This device should reduce the design cycle for producing the ASIC by allowing debug of the firmware after ASIC production. Furthermore, the device should allow field upgrades of the firmware as new bugs are found or as new features are added.

SUMMARY OF THE INVENTION

According to the invention, an apparatus and methods allow for a processing device to utilize flexible security when receiving information downloads. In a first embodiment, a method stores information within a processing device. The method receives a download via a first input path which includes a first breakable link and stores the download within the processing device. At some point, a key is also stored within the processing device. A ciphertext download is received via a second input path which includes a second breakable link. The ciphertext download is decrypted utilizing the key and the resulting plaintext download is stored within the processing device.

In another embodiment, a method stores information within a processing device utilizing two paths. First plaintext information is loaded through a first download path extending from outside the processing device to memory, whereafter, the first plaintext information is stored in memory. At some point, a key is stored within the processing device. To enhance security, the first download path is disabled. Ciphertext information is loaded through a second download path, whereupon the ciphertext information is decrypted with the key to produce second plaintext information.

In yet another embodiment, a processing device includes a download port, a decryption engine, a memory, a first download path, a second download path, and a mechanism for disabling the first download path. The download port interfaces with outside of the processing device. The first download path extends between the download port and memory and the second download path extends between the download port and a ciphertext input of the decryption engine. The mechanism for disabling the first download path prevents digital data from passing along that path.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram representation of an embodiment of a processing device which has multilevel code download security;

FIG. 2 is a block diagram which schematically illustrates an embodiment of a breakable link;

FIG. 3 is a flow diagram showing various code downloads encountered during development of the code in one embodiment;

FIG. 4 is a flow diagram depicting steps encountered while booting an embodiment of the processing device;

FIG. 5 is a block diagram of another embodiment of a processing device with multilevel information download security; and

FIG. 6 is a flow diagram showing a process for downloading information to the processing device.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

While this invention is susceptible of embodiments in many different forms, there is shown in the drawings and will herein be described in detail, a number of embodiments of the invention with the understanding that the present disclosure is to be considered as an exemplification of the principles of the invention and is not intended to limit the broad aspects of the invention to the embodiment illustrated.

In the Figures, similar components and/or features have the same reference label. Various components of the same type are distinguished by following the reference label by a dash and a second label that distinguishes among the similar components in the same figure. If only the first reference label is used in the following disclosure, the description is applicable to any one of the several similar components.

A block diagram of one embodiment of the processing device <b>100</b> is illustrated in FIG. <b>1</b>. The processing device <b>100</b> includes a processor <b>104</b>, a masked ROM <b>108</b>, a code storage RAM <b>112</b>, a download port <b>116</b>, a first fuse circuit <b>120</b>-<b>1</b>, a second fuse circuit <b>120</b>-<b>2</b>, an access limiter circuit <b>124</b>, a crypto engine <b>128</b>, and personalization memory <b>132</b> all interfaced to each other by a system bus <b>136</b>. Preferably, all the blocks depicted in the figure are fabricated on the same integrated circuit or application specific integrated circuit (ASIC). Alternatively, the blocks could be integrated into a tamper proof enclosure such as a multichip module.

The processor <b>104</b> generally controls the operation of the processing device <b>100</b>. Firmware or code in the masked ROM <b>108</b> and code storage RAM <b>112</b> is executed by the processor <b>104</b> to control the operation of the processing device <b>100</b>. In this embodiment, the processing device <b>100</b> performs security operations related to a television set top box. Preferably, the processor is a MIPS® type embedded core, however, any number of processing cores could also be used.

The masked ROM <b>108</b> contains a portion of the firmware called the boot ROM which is the first code executed by the processor <b>104</b> while booting. The content of this memory <b>108</b> is formulated before the ASIC is produced. After fabrication of the ASIC, the contents of the masked ROM <b>108</b> cannot be altered. Accordingly, the boot ROM firmware is preferably very simple to avoid the risk of bugs which may require redesigning of the ASIC. The boot ROM verifies the contents of the code storage RAM <b>112</b>, checks the state of the fuse circuits <b>120</b>, loads any keys into the crypto engine <b>128</b>, and passes control to any firmware in the code storage RAM <b>112</b>. A universal key common to all units could be derived from the boot ROM which allows using cryptographic functions before unique keys are loaded. Generally, the boot ROM of this embodiment does not interact with any bus peripherals other than the RAM <b>112</b>.

In this embodiment, the remainder of the firmware is located in the code storage RAM <b>112</b>. Preferably, the code storage random access memory (RAM) is static RAM backed-up with a battery such that it is non-volatile. However, other embodiments could use an EEPROM, flash memory, magnetic core memory, or other non-volatile types of memory. After execution of the boot ROM code, the processor executes the firmware in the code storage RAM <b>112</b>. Two different portions of firmware reside in the code storage RAM <b>112</b>, namely the boot strap and the application code. The boot strap code is executed after the boot ROM code and checks any information stored in the personalization memory <b>132</b> to load any unique keys and performs detailed verification of the application code. After execution of the boot strap code, the application code is executed. This code performs the functions required by the processing device. In this embodiment, the application code performs security related functions associated with a television set top box such as encryption and decryption.

The download port <b>116</b> provides an interface to the processing device <b>100</b> for testing and code loading. This embodiment allows three different security levels for access to the processing device <b>100</b> from the download port <b>116</b>. To access the download port <b>116</b>, a probe is connected to the boundary scan interface of the ASIC. Preferably, the download port <b>116</b> is an extended JTAG interface which is coupled by an additional interface to the system bus <b>136</b> and allows mastering the bus <b>136</b>. The ability to master the system bus <b>136</b> is made possible by a direct memory access (DMA) circuit within the download port <b>116</b>.

The download port <b>116</b> interfaces to the system bus <b>136</b> through first and second input paths. The first path is selectively interrupted by a first fuse circuit <b>120</b>-<b>1</b>. The first fuse circuit <b>120</b>-<b>1</b> includes one or more breakable links which either physically or logically breaks the conduction of digital data through the first input path. In this way, unfettered access to the system bus <b>136</b> from the download port <b>116</b> through the first path can be permanently disabled. In a similar manner to the first path, the second path is interrupted by a second fuse circuit <b>120</b>-<b>2</b>. The second path is further interrupted by the access limiter circuit <b>124</b>. Interaction with the system bus <b>136</b> is curtailed by the limiter circuit <b>124</b> such that the second path can only access an address for a cipher text input of the crypto engine <b>128</b>. Accordingly, any information sent to the processing device <b>100</b> through the second path must be decrypted by the crypto engine <b>128</b> before it is useful.

The structure of the two input paths allows for multi-level security of the processing device <b>100</b>. Unrestricted, partially restricted and fully restricted security levels are possible by selectively interrupting the paths through the fuse circuits <b>120</b>. In the unrestricted mode, the first fuse circuit <b>120</b>-<b>1</b> is closed allowing the download port <b>116</b> to freely access and master the system bus <b>136</b> through the first path. This mode allows testing of the processing device <b>100</b> and downloading plaintext firmware into the code storage RAM <b>112</b>. The partially restricted mode uses the second path which passes through the access limiter circuit <b>124</b>. To force the partially restricted mode, the first fuse circuit <b>120</b>-<b>1</b> interrupts conduction of digital data through the first path. Thus, only a conduction path to the ciphertext input of the crypto engine <b>128</b> is possible in the partially restricted mode. Accordingly, any downloads must be encrypted such that the crypto engine <b>128</b> properly decrypts the download. In the fully restricted mode, the download port <b>116</b> cannot access the system bus <b>136</b> at all because the first and second paths are respectively interrupted by the first and second fuse circuits <b>120</b>. Activation of both fuse circuits <b>120</b> allows nearly the same level of security possible in conventional devices which are not reprogrammable.

The fuse circuits <b>120</b> interrupt the conduction path of digital data through the fuse circuit <b>120</b>. Preferably, the fuse circuits <b>120</b> are activated through a dedicated pin of the integrated circuit package for the processing device <b>100</b>. In other embodiments, the processor <b>104</b> could programmably activate the fuse through a software command. Whether by programming through a pin or by a software command, the conduction path is permanently disabled once the fuse is activated. Permanent activation of the fuse circuit <b>120</b> is preferably achieved by burning away a polysilicon fuse to inhibit conduction, however, other known techniques could also be used.

Each processing device <b>100</b> is preferably personalized with unique identifiers and keys. This information is stored in personalization memory <b>132</b>. The identifiers include an unit address which uniquely identifies a particular set top box. Preferably, the unit address is written in write protected memory which cannot be overwritten after being written the first time. The personalization memory <b>132</b> also includes one or more keys. Certain cryptographic algorithms require a number of keys, such as the triple Data Encryption Standard (triple-DES). Additionally, there may be a umber of cryptographic engines with each having different keys. To enhance security, some keys may be stored in encrypted form.

There are two ways to download keys into the processing device <b>100</b>. In he first method, the keys are downloaded through the first path from the download port <b>16</b> directly into personalization memory <b>132</b>. However, after blowing the first fuse circuit <b>120</b>-<b>1</b>, download data passing through the download port <b>116</b> is forced through the access limiter <b>124</b> directly into the crypto engine <b>128</b> and then into code storage RAM <b>112</b>. Adding new keys after the first fuse circuit <b>120</b>-<b>1</b> is blown, requires writing a key into the code storage RAM <b>112</b> which is then stored in the personalization memory <b>132</b> by the firmware. To write the key into the personalization memory <b>132</b>, the firmware could periodically, or upon download, write the key from the code storage RAM <b>112</b> into the personalization memory <b>132</b>.

The processing device <b>100</b> has the ability to encrypt and decrypt data using the crypto engine <b>128</b>. In this embodiment, the crypto engine <b>128</b> uses a triple-DES algorithm implemented in hardware which uses 112 or 168 bit keys. However, any number of symmetric or asymmetric algorithms could alternatively be used or even a non-standard algorithm could be used. The crypto engine <b>128</b> is interfaced to the system bus <b>136</b> and is mapped to the address space such that the ports for the crypto engine <b>128</b> are at different addresses. For example, the key input, ciphertext input and plaintext output have three different addresses. By manipulating the addresses, the various ports may be passed information. Although the above discussion only describes the crypto engine <b>128</b> being used to decrypt firmware, preferably the crypto engine <b>128</b> is used for a number of security related purposes in the processing device <b>100</b>.

With reference to FIG. 2, one embodiment of a breakable link <b>200</b> is shown in block diagram form. The fuse circuit <b>120</b> may contain one or more breakable links <b>200</b>. To inhibit digital data from passing through the fuse circuit <b>120</b> every line in the download path may not require a separate breakable link <b>200</b>. For example, inhibiting a single bit which enables a multiline driver could inhibit all the data lines passing through the driver. Accordingly, the fuse circuit <b>120</b> may have only one breakable link.

The breakable link <b>200</b> can logically inhibit or gate the passing of data from a signal input to a signal output. Either a fuse element <b>212</b> or a programmable bit <b>208</b> is used to either permanently or temporarily gate the signal. If the fuse element <b>212</b> is blown, a resistor activates the gating mechanism <b>204</b> to permanently inhibit conduction of digital data. Accordingly, once the first and second fuse circuits <b>120</b> in the download paths are disabled by blowing the fuse elements <b>212</b>, the processing device cannot receive new data from the download port <b>116</b>. As discussed above, the fuse element <b>212</b> is blown from an external pin or by software.

In other embodiments, a programmable bit <b>208</b>, which is addressable by the bus <b>136</b>, can temporarily gate conduction of the signal. The programmable bit <b>208</b> is mapped to the address space such that any master of the system bus <b>136</b> can write to that bit. After activation of the programmable bit <b>208</b>, the bit <b>208</b> can be deactivated by writing once again to re-enable the download path. In contrast, once the fuse <b>212</b> is blown, conduction through the gating mechanism <b>204</b> is forever disabled. The advantage of temporary activation is that it is reversible, however, this feature may pose obvious security risks.

Referring next to FIG. 3, a flow diagram of various downloads encountered during development of the code for one embodiment is shown. In step <b>304</b>, the processing device ASIC is fabricated with the masked ROM <b>108</b> containing the boot ROM firmware. Before this step, the boot ROM firmware is debugged using software and hardware emulation models of the ASIC. Since emulators are typically very slow, this process can be time consuming. To limit the boot ROM debug process, this firmware is typically small and simple. As those skilled in the art can appreciate, bugs which are not caught before producing the ASIC can require an ASIC redesign to correct mistakes in the masked ROM <b>108</b>. The schedule delays and mask costs associated with an ASIC redesign can have significant impact on the development effort.

The unit incorporating the ASIC is assembled in step <b>308</b>. In this embodiment, the unit is a television set top box which incorporates a number of integrated circuits on a printed circuit board which is housed in an enclosure. The set top box may also include a display, a content provider interface, a television interface, and/or a computer interface.

The first firmware and personalization information is typically downloaded in the factory after assembly of the circuit board. However, other embodiments could load this information before the ASIC is soldered to the circuit board. In step <b>312</b>, the unit address and key(s) are loaded into the personalization memory <b>132</b>. The first download path is preferably used for loading this information because encrypting the information is not necessary when using the first download path. The unit address is unique to each unit, but the key could be generic to all units. However, if generic keys are initially loaded, unique keys are preferably loaded before fielding the unit. Key and code loading takes place by coupling a probe to the download port <b>116</b>. The download port <b>116</b> interfaces with the pad ring of the ASIC through an extended JTAG (EJTAG) port which interfaces with pins of the ASIC through a boundary scan port. The <i>MIPS EJTAG Debug Solution</i>, Rev. 2.0, specification describes this interface and is available on the Internet at www.mips.com. The probe interfaces with a connector which is coupled to the boundary scan port. In step <b>314</b>, the boot strap firmware is loaded into the code storage RAM <b>112</b> through the first path in the same manner used to load the unit address and key. Although not shown, the boot strap firmware could require iterative debugging.

In steps <b>316</b>, <b>320</b> and <b>324</b>, the application firmware is tested and debugged in an iterative manner. The first application firmware is loaded into the code storage RAM in step <b>316</b>. At this point, the firmware has all its constituent parts with the boot ROM firmware, boot strap and application code present in the processing device <b>100</b>. However, debugging of the application code is usually necessary and begins in step <b>320</b>. A determination is made in step <b>324</b> whether the firmware is sufficiently debugged to proceed to the next phase of fielding units. If further debugging is necessary, the process loops back to step <b>316</b>.

If further debugging is not warranted at this stage, preparation is made to ship the units to the field. To provide added security, the first fuse circuit <b>120</b>-<b>1</b> is activated to inhibit digital data from passing through the first path into the processing device <b>100</b> in step <b>328</b>. Up to this point, data downloads into the processing device <b>100</b> were sent without encryption, however, downloads after this point will require encryption. As those skilled in the art can appreciate, preparing firmware encrypted in a unique key is an involved process, but, the extra security is believed necessary once the units are shipped to the public. In step <b>332</b>, the units are shipped to the field for further test or deployment.

Once fielded, additional bugs may be found in field test or in actual system use or additional features may be added to provide new functionality. In step <b>336</b>, new application firmware is loaded through the second path. Since the second path is routed through the crypto engine <b>128</b>, the firmware must be encrypted for the key in the unit. The key necessary for encryption is determined by knowing the unique unit address. The unit address is correlated with a database to the required key. To further enhance security, the database storing the keys is heavily secured.

Any debug of problems found in field testing occurs in step <b>340</b>. A determination is made in step <b>344</b> whether debugging is complete and that no additional upgrades are needed. If more debugging or upgrades are necessary or desired, the cycle continues in steps <b>336</b> and <b>340</b>.

If the firmware is acceptably robust and further upgrades are not desired, the iterative revising process of the code is completed. In step <b>348</b>, the second fuse circuit <b>120</b>-<b>2</b> is opened to inhibit coupling digital data through the second data path. At this point in the process, no data of any kind can be downloaded into the processing device <b>100</b>. Loading different firmware or keys into the set top box would require replacing the ASIC. By using this multilevel security in this way, debugging of the chip is accelerated while reducing the risk of an ASIC redesign. Further, field upgrades which revise the code are possible. Additionally, after opening both fuse circuits <b>120</b>, additional downloads to the ASIC are not possible such that the security is nearly equivalent to the conventional systems which store all the firmware in masked ROM.

Even if the download paths are disabled in the above embodiment, the processor <b>104</b> could modify the contents of the code storage RAM. To further enhance security in other embodiments, activation of the fuse circuit <b>120</b>-<b>2</b> can prevent external write access to the code storage RAM <b>112</b>. Additionally, activation of the fuse circuit <b>120</b>-<b>2</b> could disable any internal write access to the code storage RAM <b>112</b>. In this way, the code storage RAM cannot be externally or internally modified which provides security equivalent to the conventional systems which use a masked ROM for code storage.

With reference to FIG. 4, a flow diagram depicting steps encountered while booting an embodiment of the processing device is illustrated. The firmware is executed in stages starting with the boot ROM code, continuing with the boot strap code and finishing with the application code. However, other embodiments could include the functionality of the boot strap code in one of the other portions of code.

Execution by the processor <b>104</b> begins with the code stored in the masked ROM in step <b>404</b>. In step <b>408</b>, the boot ROM code validates the contents of the code storage RAM <b>112</b>. One method for validation of the code storage RAM <b>112</b> involves calculating a checksum, cyclic redundancy check (CRC), cryptographic signature, or other security mechanism. If the check passes, the bootstrap and application code are executed by the processor in step <b>412</b>. Proceeding to step <b>412</b> is the normal flow for working units in the field.

If it is determined application code is not present or is defective in step <b>408</b>, the state of the first fuse circuit <b>120</b>-<b>1</b> is checked by the boot ROM code in step <b>416</b>. If the first fuse circuit <b>120</b>-<b>1</b> is intact, the processor <b>104</b> waits for a download of firmware in step <b>420</b>. Since the first download path is intact, any download of firmware can be done as plaintext without encryption. After the download is complete, the program counter of the processor is reset so that processing begins again in step <b>404</b>.

If the first fuse circuit <b>120</b>-<b>1</b> is open, the second fuse circuit <b>120</b>-<b>2</b> is checked by the boot ROM code in step <b>424</b>. In the case that the fuse circuit <b>120</b>-<b>2</b> is broken, processing continues to step <b>428</b>. The unit at step <b>428</b> does not have valid firmware and all paths to load new firmware are broken. Accordingly, the unit is broken and the ASIC needs replacing. However, if the fuse is still intact, the processing continues to step <b>432</b> where the key is loaded from the personalization memory and into the crypto engine <b>128</b>. This step enables decryption by the crypto engine <b>128</b> as data passes through the second path.

The second path from the download port <b>116</b> to the code storage RAM <b>112</b> is further enabled in step <b>436</b>. Any data received from the download port <b>116</b> is funneled to the ciphertext input address of the crypto engine <b>126</b> by the access limiter circuit <b>124</b>. In step <b>436</b>, the plaintext output from the crypto engine <b>436</b> is directed to the code storage RAM <b>112</b> by appropriately configuring a DMA controller.

The processor <b>104</b> waits for a secure code download in step <b>440</b>. Because the first fuse circuit <b>120</b>-<b>1</b> is broken, all downloads into the processing device <b>100</b> are funneled down the second path through the crypto engine <b>128</b> and require encryption. Once new application code is decrypted and loaded into code storage RAM, the program counter of the processor is reset to begin processing at step <b>404</b> again. In this way, the boot ROM can allow downloads of application firmware with varying levels of security.

With reference to FIG. 5, another embodiment of a processing device <b>500</b> is schematically shown which has multilevel security for information downloads. The processing device <b>500</b> includes a processor block <b>504</b>, a mode select circuit block <b>508</b>, peripheral block(s) <b>512</b>, a memory subsystem block <b>516</b>, and a crypto engine block <b>520</b> which are all interconnected through a sentry block <b>524</b>. This embodiment uses an extended JTAG (EJTAG) interface to receive the downloads. This specification is herein incorporated by reference.

The processor <b>504</b> is a general purpose microprocessor which generally manages the operation of the processing device <b>500</b>. Preferably, the processor <b>504</b> is an embedded MIPS® core which includes a debug support unit (DSU) and an EJTAG circuit <b>532</b>. The DSU allows probing into the processor <b>504</b> and emulating software. Communication to the DSU occurs over the EJTAG interface with the support of the EJTAG circuit <b>532</b>. The EJTAG circuit <b>532</b> includes a direct memory access DMA circuit <b>528</b> which assists sending data to other blocks in the processing device <b>500</b> via the sentry <b>524</b>.

Attached to the processor <b>504</b> is a regulator circuit <b>536</b> which implements some of the security features of the processing device <b>500</b> under the direction of the mode select circuit <b>508</b>. The mode select circuit <b>508</b> preferably includes fuses which are blown in order to permanently set flags. However, other methods for permanently setting the flag could be used. By selectively blowing the fuses in the mode select circuit <b>508</b> a full debug access mode, an encrypted download mode and a no download mode are selected. In order to allow blowing the fuses, a mode program interface is coupled to pins on the package containing the processing device <b>500</b>.

The mode select flags are passed to the regulator <b>536</b> to activate the multilevel download security. Preferably, the fuses are blown to set the flag. The regulator <b>536</b> allows full DMA access to the blocks within the processing device <b>500</b> when no flags are set. This mode is useful during the debug phase of development, but is typically not used in production units for security reasons. When the first flag is set, the regulator <b>536</b> forces any incoming download information to the crypto engine <b>520</b>, such that addresses are ignored and are replaced by the address of the ciphertext input port of the crypto engine <b>520</b>. In this mode all downloaded information must be encrypted for the key in the processing device <b>500</b> to properly produce plaintext download information. When the second flag is set, all access to other blocks in the processing device is disabled. This mode effectively disables all ability to download information into the processing device in order to provide additional security.

Interconnections between blocks in the processing device <b>500</b> are regulated by the sentry <b>524</b>. Included in the sentry <b>524</b> and used for some transfers are a DMA circuit and crossbar switch. When transfers of information between blocks are desired, the sentry <b>524</b> checks if the blocks and datapaths between them are busy, looks for out of range addresses and handles timeouts. For example, when transferring information from the crypto engine <b>520</b> to the memory subsystem <b>516</b>, the sentry configures the DMA circuit to pass information directly to the memory subsystem <b>516</b> without intervention from the processor <b>504</b>. The crossbar switch configures the path between the crypto engine <b>520</b> and memory subsystem <b>516</b> to allow this transfer.

The crypto engine <b>520</b> processes all ciphertext information downloads from the EJTAG interface. If the first flag is not set, a destination address of the information download is selectable. Alternatively, if the first flag is set, information downloads are forced to the ciphertext input of the crypto engine <b>520</b> regardless of the desired destination. During a download with the first flag set, a path from a plaintext output of the crypto engine <b>520</b> to the memory subsystem <b>516</b> is configured to load the decrypted information into memory. Preferably, the crypto engine <b>520</b> uses a triple Data Encryption Standard (triple-DES) algorithm, but any cryptographic algorithm could be used.

The memory subsystem <b>516</b> includes different memory blocks. In this embodiment, the subsystem <b>516</b> includes a masked ROM, personalization memory and code storage RAM. Typically, information downloads are sent to the code storage RAM in order to load new firmware into the processing device <b>500</b>.

Other peripherals <b>512</b> are connected to the sentry <b>524</b> as part of the implementation of the processing device <b>500</b>. For example, a set top box processing device could include a video decoder as a peripheral <b>512</b>.

Referring next to FIG. 6, a flow diagram illustrates a process for downloading information to a processing device. This diagram demonstrates operation in the full debug access mode, encrypted download mode and no download mode.

The process begins in step <b>604</b> where an information download is received from the EJTAG interface. In step <b>608</b>, a first determination is made whether the first flag from the mode select block <b>508</b> is set. If the flag is not set, full debug access is allowed. In this mode any block in the processing device may be addressed by the DMA circuit <b>528</b> in the EJTAG circuit <b>532</b>. In step <b>612</b>, the memory is addressed, and in step <b>616</b>, the plaintext information is downloaded into memory. To enable this transfer, the crossbar switch in the sentry <b>524</b> connects the EJTAG interface to the memory.

If it is determined the first flag is set in step <b>608</b>, processing continues to step <b>620</b>. The state of the second flag from the mode select block <b>508</b> is checked in step <b>620</b>. If the second flag is set, all access to the processing device <b>500</b> through the download interface is prohibited in step <b>624</b>. However, if the second flag is not set, ciphertext information may be downloaded into the processing device <b>500</b>. In step <b>628</b>, the regulator <b>536</b> forces the address of any incoming information to the ciphertext input of the crypto engine <b>520</b>. The DMA circuit <b>528</b> in the EJTAG circuit <b>532</b> passes any downloaded information through the crossbar switch in the sentry <b>524</b> to the ciphertext input of the crypto engine <b>520</b> in step <b>632</b>. After the path to the crypto engine <b>520</b> is configured, the ciphertext download is decrypted in step <b>636</b> as it is received. The resulting plaintext is passed from the plaintext output of the crypto engine <b>520</b> to the memory subsystem <b>516</b>. The DMA circuit and crossbar switch in the sentry <b>524</b> are configured for this purpose in step <b>640</b>. The resulting plaintext is then passed to the memory subsystem <b>516</b>. By use of this process, downloading information with multilevel security is possible.

In light of the above description, a number of advantages of the present invention are readily apparent. Multiple level security is possible such that one can achieve the security of a masked ROM and the ease of debugging of a device without security. In this way, the debugging of the chip is accelerated while reducing the risk of an ASIC redesign. Additionally, the security level is nearly equivalent to conventional systems which store all the firmware in masked ROM.

A number of variations and modifications of the invention can also be used. Although the above embodiments use hardware to perform decryption, other embodiments could use software algorithms executed on a processor to perform decryption. Preferably, the software algorithm would be permanently embedded in the masked ROM to enhance security. In relation to FIG. 3, the second fuse circuit was activated in the field, however, activation could occur in the factory if the firmware were sufficiently debugged and updates were not desired. FIG. 2 demonstrated that the breakable links could use a fuse to gate the signal. Other embodiments could use a fuse in the signal path to break all electrical coupling. Although the preceding discussion relates to having the processing device on a single integrated circuit or package, other embodiments could locate the functional blocks in any number of separate packages.

The foregoing description of the invention has been presented for the purposes of illustration and description and is not intended to limit the invention. Variations and modifications commensurate with the above description, together with the skill or knowledge of the relevant art, are within the scope of the present invention. The embodiments described herein are further intended to explain the best mode known for practicing the invention and to enable those skilled in the art to utilize the invention in such best mode or other embodiments, with the various modifications that may be required by the particular application or use of the invention. It is intended that the appended claims be construed to include alternative embodiments to the extent permitted by the prior art.