WO2007117879A1

WO2007117879A1 - Method and apparatus to mate an external code image with an on-chip private key

Info

Publication number: WO2007117879A1
Application number: PCT/US2007/064321
Authority: WO
Inventors: Peter Munguia; Dhiraj Bhatt
Original assignee: Intel Corporation
Priority date: 2006-04-07
Filing date: 2007-03-19
Publication date: 2007-10-18
Also published as: CN101433013A; JP2009525556A; EP2005642A4; EP2005642A1

Abstract

Apparatus, systems and methods for mating an external code image with an on- chip private key are disclosed including a method of receiving a code image and a code key and encrypting the code image and the code key if the code image and the code key are to be placed in unsecured storage. Other implementations are disclosed.

Description

METHOD AND APPARATUS TO MATE AN EXTERNAL CODE IMAGE WITH

AN ON-CHIP PRIVATE KEY

BACKGROUND [0001] Typical computing platforms use boot code to enable system start-up. Such code is a particularly attractive route for malevolent entities to gain access to such systems and thus requires protective mechanisms and/or schemes to prevent un-authorized access to the boot code or its image. Current methods for protecting boot code rely on physical restrictions such as burying signal layers to or from boot devices (e.g., memory devices that store boot code or boot code images), applying material such as glue to boot devices to prevent physical access, minimizing trace lengths between devices, etc. Typically, additional protection is provided in the form of a software chain of trust rooted in the boot code itself. However, a software chain of trust originating in the boot code can be compromised if the boot code itself can be accessed or replaced with malevolent boot code.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The accompanying drawings, incorporated in and constituting a part of this specification, illustrate one or more implementations consistent with the principles of the invention and, together with the description of the invention, explain such implementations. The drawings, which should not be taken to limit the invention to the specific implementations shown therein, are also not necessarily to scale nor should they be considered exhaustive, the emphasis instead being placed upon illustrating the principles of the invention. In the drawings, [0003] Figure 1 is a block diagram illustrating a system in accordance with some implementations of the invention;

[0004] Figure 2 is a block diagram illustrating a system similar to portions of the system of Fig. 1 in accordance with some implementations of the invention; and [0005] Figures 3-6 are flow charts illustrating processes in accordance with some implementations of the invention. DETAILED DESCRIPTION

[0006] The following description refers to the accompanying drawings. Among the various drawings the same reference numbers may be used to identify the same or similar elements. While the following description provides a thorough understanding of the various aspects of the claimed invention by setting forth specific details such as particular structures, architectures, interfaces, techniques, etc., such details are provided for purposes of explanation and should not be viewed as limiting. Moreover, those of skill in the art will, in light of the present disclosure, appreciate that various aspects of the invention claimed may be practiced in other examples or implementations that depart from these specific details. At certain junctures in the following disclosure descriptions of well known devices, circuits, and methods have been omitted to avoid clouding the description of the present invention with unnecessary detail. [0007] Figure 1 illustrates an example system 100 according to some implementations of the invention. System 100 includes a media processor 102 coupled to a display controller 104, a cryptographic module 106, storage media 107 and a communications pathway 108. System 100 also includes memory 110 (e.g., dynamic random access memory (DRAM), static random access memory (SRAM), non-volatile memory such as flash memory, etc.) coupled to pathway 108, a display 112 coupled to controller 104, and an input/output (I/O) controller 114 coupled to pathway 108. In addition, system 100 includes wireless transmitter circuitry and wireless receiver circuitry 116 coupled to I/O controller 114 and an antenna 118 (e.g., dipole antenna, narrowband Meander Line Antenna (MLA), wideband MLA, inverted "F" antenna, planar inverted "F" antenna, Goubau antenna, Patch antenna, etc.) coupled to circuitry 116. [0008] System 100 may be any system suitable for the cryptographic processing of cryptographic keys, data or software instructions such as boot code or boot code images in accordance with implementations of the invention as will be described in greater detail below. Moreover, system 100 may assume a variety of physical implementations. For example, system 100 may be implemented in a personal computer (PC), a networked PC, a server computing system, a handheld computing platform (e.g., a personal digital assistant (PDA)), a gaming system (portable or otherwise), a 3D capable cellular telephone handset, etc. In addition, while all components of system 100 may be implemented within a single device, such as a system-on-a-chip (SOC) integrated circuit (IC), components of system 100 may also be distributed across multiple ICs or devices. For example, media processor 102, module 106, storage 107, pathway 108, memory 110, controller 114, circuitry 116 and antenna 118 may be implemented, in part, as multiple ICs contained within a single computing platform, such as a personal computer (PC) or a set top box (STB) to name a few examples, while display controller 104 may be implemented in a separate device such as display 112 coupled to media processor 102. Clearly, many such permutations are possible consistent with the functionality of system 100 as described herein. [0009] Media processor 102 may comprise special purpose or general purpose processor core (s) including any control and/or processing logic, hardware, software and/or firmware, capable of processing audio and/or image and/or video data and of providing display controller 104 with image and/or video data. Processor 102 may also utilize cryptographic module 106 to encrypt or decrypt cipher keys, data and/or software instructions such as boot code, and may provide encrypted or decrypted keys, data and/or software instructions such as boot code to memory 110 and/or storage 107 as will be explained in greater detail below. Those skilled in the art will recognize that processor 102 may also include control logic for controlling access to storage media 107 and/or memory 110. Moreover, while Fig. 1 shows cryptographic module 106 as a distinct device the invention is not limited in this regard and, for example, cryptographic module 106 may be implemented in media processor 102. [0010] Processor 102 may further be capable of performing any of a number of additional tasks that support mating an external code image with an on-chip private key. These tasks may include, for example, although the invention is not limited in this regard, obtaining external code images from devices external to system 100 by, for example, downloading such code images via antenna 118, transmitter and receiver circuitry 116 and I/O controller 114. Those skilled in the art will recognize that processor 102 may undertake other support tasks such as, initializing and/or configuring registers within module 106 or controller 104, interrupt servicing, etc. In addition, although the invention is not limited in this regard, processor 102 may include two or more processor cores. While Fig. 1 may be interpreted as showing media processors 102 and 104 as distinct devices, the invention is not limited in this regard and those of skill in the art will recognize that media processor 102 and display controller 104 and possibly additional components of system 100 may be implemented within a single IC. [0011] Display controller 104 may comprise any processing logic, hardware, software, and/or firmware, capable of converting graphics or image data supplied by media processor 102 into a format suitable for driving display 112 (i.e., display-specific data). For example, while the invention is not limited in this regard, processor 104 may provide graphics and/or image and/or video data to controller 104 in a specific color format, for example in a compressed red-green-blue (RGB) pixel format, and controller 104 may process that RGB data by generating, for example, corresponding liquid crystal display (LCD) drive data levels, etc. In addition, the invention is not limited to a particular type of display 112. Thus display 112 may be any type of display such as a LCD display, or an electroluminescent (EL) display, to name a few examples. [0012] Bus or communications pathway(s) 108 may comprise any mechanism for conveying information (e.g., encrypted code images, keys, etc.) between or amongst any of the elements of system 100. For example, although the invention is not limited in this regard, communications pathway(s) 108 may comprise a multipurpose bus capable of conveying, for example, code images and code keys to processor 102. Alternatively, pathway(s) 108 may comprise a wireless communications pathway

[0013] Figure 2 illustrates a system 200 similar to portions of system 100 and in accordance with some implementations of the invention. System 200 includes a cryptographic module (CM) 202 including encryption logic (EL) 204 and decryption logic (DL) 206, a one-time-programmable (OTP) memory 208 storing at least one private key 209, key derivation logic (KDL) 210 coupled to both OTP memory 208 and CM 202, unsecured storage 212 coupled to CM 202, secured storage 214 coupled to CM 202, and processor core(s) 216 coupled to secured storage 214 and CM 202. System 200 may be any system suitable for the cryptographic processing of keys, data or software instructions such as boot code or boot code images in accordance with implementations of the invention as will be described in greater detail below.

[0014] Like system 100, system 200 may assume a variety of physical implementations. While all components of system 200 may be implemented within a single device, such as a system-on-a-chip (SOC) integrated circuit (IC), components of system 100 may also be distributed across multiple ICs or devices. Moreover, processor core(s) 216 may comprise any special purpose or a general purpose processor core(s) including any control and/or processing logic, hardware, software and/or firmware, capable of supporting mating an external code image with an on-chip private key in accordance with implementations of the invention as will be explained in greater detail below. [0015] CM 202 may comprise any processing logic, hardware, software, and/or firmware, capable of enabling the mating of an external code image with a private key in accordance with implementations of the invention as will be explained in greater detail below. CM 202 may receive one or more code images (e.g., CodeA, CodeB, etc) and associated encryption keys (e.g., K_A, K_B, etc) from devices external to system 200. CM 202 may also receive private key 209 from OTP memory 208. In addition, CM 202 may receive one or more keys from derivation logic 210 where those keys have been derived from private key 209. [0016] CM 202 may then use EL 204 to encrypt each code image with an associated code key and store the resulting encrypted code image in unsecured storage 212. CM 202 may also use EL 204 and encryption keys such as private key 209 or the derived keys provided by derivation logic 210 to encrypt each code key and may then store the encrypted code key in unsecured storage 212 along with the associated encrypted code image. CM 202 may further use DL 206 to decrypt an encrypted code key retrieved from unsecured storage 212, use that decrypted code key to decrypt an associated encrypted code image, and store the resulting decrypted or clear code key and clear code image in secured storage 214. CM 202 may undertake these encryption and decryption tasks in response to commands issued by processor core(s) 216. The functionality of CM 202 may be similar to that of CM 106 of Fig.1.

[0017] The invention is not limited to a particular type of code key and/or to a particular type of cryptographic process implemented by EL 204 and DL 206. Thus, for example, those skilled in the art will recognize that the code keys associated with the code images and provided to system 200 may be dependent on the type of encryption process used by EL 204 to encrypt the code images with the code keys. Hence, for example, the code keys may be consistent with well known Public Key Infrastructure (PKI) techniques, such as the Rivest, Shamir, and Adelman (RSA) digital signature algorithm (DSA). Alternatively, the code keys may be keys consistent with other cryptographic schemes such as symmetric keys or random unique keys, to name a few more examples. [0018] Unsecured storage 212 may be, for example, any storage means that is user- accessible. In other words, the contents of storage 212 may be accessed by a user of system 200 in a conventional manner. For example, storage 212 may be a fixed nonvolatile memory device (e.g., flash memory, hard disk drive, etc.), or a removable nonvolatile memory device (e.g., a memory card containing flash memory, etc.) to name several examples. Thus, for example, storage 212 may be off-chip memory that is formed in a semiconductor substrate other than the semiconductor substrate incorporating CM 202 and/or processor core(s) 216. [0019] By contrast, secured storage 214 may be any storage means that is user- inaccessible. In other words, the contents of storage 214 may not be accessed by a user of system 200 in a conventional manner. For example, storage 214 may be on-chip or cache memory that is formed in the same semiconductor substrate as CM 202 and/or processor core(s) 216. Alternatively, for another example, storage 214 may comprise system memory, such as double-data-rate (DDR) random-access-memory (RAM), formed on a separate semiconductor substrate and coupled to processor core(s) 216 by a high speed system bus. Moreover, while Fig. 2 shows private key 209 held in OTP 208, the invention is not limited in this regard, and those skilled in the art will recognize that private key 209 could be held securely in other means such as polysilicon fuses, read-only memory (ROM) or logic gates, etc.

[0020] Figure 3 is a flow chart illustrating a process 300 for mating an external code image with an on-chip private key in accordance with some implementations of the invention. While, for ease of explanation, process 300 may be described with regard to system 100 of Fig. 1 and/or system 200 of Fig. 2 the invention is not limited in this regard and other processes or schemes supported by appropriate devices in accordance with the claimed invention are possible. While process 300 and related processes are discussed below using the example of a code image, the invention is not limited in this regard and contemplates the term code image to encompass any information confidential or otherwise, whether executable code or non-executable data. Thus the term code image encompasses a code image, a boot code image, one or more keys, or data in general, confidential or otherwise, to name several examples.

[0021] Process 300 may begin with the provision of a code image [act 302]. In some implementations of the invention, act 302 may be undertaken by wireless receiver 116 receiving via antenna 118 a boot code image (e.g., CodeA), and I/O controller 114 conveying that boot code image to EL 204 of CM 202 located within media processor 102. Act 302 is not, however, limited to boot code images or to obtaining code images wirelessly and, thus, act 302 may comprise providing the code image through other devices (not shown) coupled to system 100 by, for example, by I/O controller 114. Process 300 may continue with the provision of a code key [act 304]. Act 304 may be undertaken along the same lines as discussed directly above with regard to act 302.

[0022] Process 300 may continue with the encryption of the code image [act 306]. In some implementations of the invention, EL 204 may use the code key provided in act 304 (e.g., K_A) to encrypt the code image. For example, EL 204 may employ well known cryptographic techniques, such as the Advanced Encryption Standard (AES) algorithm to undertake act 306. However, as noted above, the invention is not limited to any particular encryption technique employed by EL 204 in undertaking act 306 or any encryption and/or decryption acts described herein. Process 300 may then continue with the placement of the encrypted code image in unsecured storage [act 308]. One way to undertake act 308 is to have CM 202 place the encrypted code image (e.g., eCodeA(KA)) in storage 212. [0023] Process 300 may continue with the provision of an encryption key [act 310]. In some implementations of the invention, act 308 may be undertaken by having CM 202 obtain the private key 209 from OTP 208 and employ that key as an encryption key. Alternatively, KDL 210 and EL 204 may undertake act 310 by obtaining private key 209 from OTP 208 and using private key 209 as a root key to derive the encryption key. [0024] Figure 4 is a flow chart illustrating a process 400 for providing an encryption key in accordance with some implementations of act 310 of process 300. While, for ease of explanation, process 400 may be described with regard to system 100 of Fig. 1 and/or system 200 of Fig. 2 the invention is not limited in this regard and other processes or schemes supported by appropriate devices in accordance with the claimed invention are possible.

[0025] Process 400 may begin with the provision of a master key [act 402]. In some implementations of the invention, KDL 210 may undertake act 402 by deriving a master key using well known PKI techniques and providing that master key to CM 202. Those skilled in the art will recognize that the invention is not limited to hardware implementations of key derivation, such as KDL 210, and also contemplates deriving keys using, for example, an external software application to derive keys such as the master key of act 402 or similar acts. Process 400 may then continue with the provision of a private key [act 404]. In some implementations of the invention, act 404 may be undertaken by having CM 202 obtain the private key 209 from OTP 208.

[0026] Process 400 may continue with the encryption of the master key [act 406] and the storage of the resulting encrypted master key [act 407]. In some implementations of the invention, act 406 may be undertaken by EL 204 using well known encryption techniques and the private key provided in act 404, while act 407 may be undertaken by CM 202 providing the encrypted master key to unsecured storage 212. Process 400 may then continue with the provision of a platform key [act 408] and the encryption of the platform key [act 410] using the master key. Acts 408 and 410 may be undertaken in the same manner as acts 404 and 406 respectively as described above. The product of act 410, the encrypted platform key, may be stored [act 412] in, for example, unsecured storage 212. The platform key provided in act 408 may be used as the encryption key provided in act 310 of process 300. [0027] While process 400 depicts the use of two keys, a master key and a platform key, the invention is not limited to particular types of keys employed in process 400 nor is the invention limited to the use of two keys in process 400. Thus, for example, additional keys may be employed in processes similar to process 400. [0028] Returning to Fig. 3, process 300 may then continue with the encryption of the code key [act 312] using the encryption key provided in act 310. Once again, in some implementations of the invention, act 312 may be undertaken by EL 204 using well known encryption techniques to encrypt the code key with the encryption key provided in act 310. Process 300 may then conclude with the placement of the encrypted code key (e.g., QK_A) in unsecured storage [act 314]. One way to undertake act 314 is to have CM 202 place the encrypted code key in storage 212 in association with the corresponding code image that was encrypted with the code key in act 306.

[0029] In accordance with some implementations of the invention, process 300 may be undertaken two or more times to result in two or more encrypted code images (e.g., eCodeA(KA), eCodeB(K_B), etc.) and associated encrypted code keys (e.g., eKA, eK_B, etc.) being placed in unsecured storage (e.g., storage 212). In addition, the encryption of each code key may be undertaken using a different platform key unique to each code key. [0030] Figure 5 is a flow chart illustrating a process 500 for mating an external code image with an on-chip private key in accordance with some implementations of the invention. While, for ease of explanation, process 500 may be described with regard to system 100 of Fig. 1 and/or system 200 of Fig. 2 the invention is not limited in this regard and other processes or schemes supported by appropriate devices in accordance with the claimed invention are possible.

[0031] Process 500 may begin with the provision of an encrypted code key [act 502]. In some implementations of the invention, act 502 may be undertaken by having CM 202, in response to one or more commands from processor core(s) 216, obtaining an encrypted code key (e.g., QK_A) from unsecured storage 212 where, for example, CM 202 had placed that encrypted code key in storage 212 in act 314. Process 500 may then continue with the provision of a decryption key [act 504]. In some implementations of the invention, act 504 may be undertaken by having CM 202 obtain the private key 209 from OTP 208 and employ private key 209 as a decryption key. Alternatively, KDL 210 and EL 204 may undertake act 504 by obtaining private key 209 from OTP 208 and using private key 209 as a root key to derive the decryption key. [0032] Figure 6 is a flow chart illustrating a process 600 for providing a decryption key in accordance with some implementations of act 504 of process 500. While, for ease of explanation, process 600 may be described with regard to system 100 of Fig. 1 and/or system 200 of Fig. 2 the invention is not limited in this regard and other processes or schemes supported by appropriate devices in accordance with the claimed invention are possible.

[0033] Process 600 may begin with the provision of an encrypted master key [act 602] . In some implementations of the invention, CM 202 may undertake act 602 by obtaining an encrypted master key from unsecured storage 212. Process 600 may then continue with the provision of a private key [act 604]. In some implementations of the invention, act 604 may be undertaken by having CM 202 obtain the private key 209 from OTP 208.

[0034] Process 600 may continue with the decryption of the encrypted master key [act 606]. In some implementations of the invention, act 606 may be undertaken by DL 206 using well known decryption techniques and the private key provided in act 604. Process 600 may then continue with the provision of an encrypted platform key [act 608] and the decryption of the encrypted platform key [act 610] using the decrypted master key resulting from act 606. Acts 608 and 610 may be undertaken in the same manner as acts 604 and 606 respectively as described above. The product of act 610, the decrypted platform key, may then be used as the decryption key provided in act 504 of process 500. [0035] Returning to Fig. 5, process 500 may then continue with the decryption of the encrypted code key [act 506] using the decryption key provided in act 504. In accordance with some implementations of the invention, act 506 may be undertaken by DL 206 using well known decryption techniques to decrypt the encrypted code key with the decryption key provided in act 504. Process 500 may then continue with the placement of the decrypted code key in secured storage [act 510]. One way to undertake act 510 is to have CM 202 place the decrypted or clear code key (e.g., K_A) in storage 214.

[0036] Process 500 may then continue with the provision of an encrypted code image [act 508]. In some implementations of the invention, act 508 may be undertaken by CM 202 obtaining an encrypted code image (e.g., eCodeA(K_A)) from unsecured storage 212 where that encrypted code image is associated with the encrypted code key (e.g., eKλ) obtained in act 502. The encrypted code image may then be decrypted [act 512] using the associated decrypted code key resulting from act 506. In some implementations of the invention, act 512 may be undertaken by DL 206 using well known decryption techniques to decrypt the encrypted code image (e.g., eCodeA(KA)) using the associated decrypted code key (e.g., K_A). Process 500 may then conclude with the placement of the decrypted code image in secured storage [act 514]. One way to undertake act 514 is to have CM 202 place the decrypted or clear code image (e.g., CodeA) in storage 214. [0037] In accordance with some implementations of the invention, process 500 may be undertaken two or more times to result in two or more decrypted or clear code images (e.g., CodeA, CodeB, etc.) and associated decrypted code keys (e.g., K_A, K_B, etc.) being placed in secured storage (e.g., storage 214).

[0038] Systems 100/200 and/or processes 300-600 may, in accordance with some implementations of the invention, support hardware encrypt and decrypt functions that are destination specific (i.e., where the destination is unsecured storage versus secured storage) where those encrypt and decrypt hardware functions allow the mating of the contents of an external device (e.g., an external device providing a code image) to the IC chip containing a private key. In particular, where those encrypt and decrypt hardware functions allow the mating of multiple boot code images in a secure boot application or in storing other private keys off chip. Thus, in accordance with some implementations of the invention, a host application having access to the chip with the private key may issue a command to the hardware function to encrypt a known code key, where the code key has been used to protect (i.e., encrypt or sign) a code image, and place the encrypted code key in unsecured storage with the encrypted code image. The host application may then issue a second command to the hardware function to decrypt the encrypted code key and use the recovered code key to access (i.e., decrypt) the code image. In this manner, only a device or system with the private key used to create the encrypted code key can recover the code key and access the code image. [0039] In addition, in accordance with some implementations of the invention, because the code image is protected by an externally provided code key, any number of independently protected code images may be created using distinct, independent code keys. In this way, application code from different external sources may likewise be mated to the device or system holding the private key. Further, when the private key is a shared secret the owner of the shared secret can create the encrypted code key using an equivalent encrypt function without requiring the actual device or system (e.g., systems 100 or 200). Thus, in accordance with some implementations of the invention, code image updates can be applied in the field and initial boot code programming can be done at manufacturing time without having to reveal the private key to the device or system customer and without having to run a special application on the device or system prior to programming the image.

[0040] The acts shown in Figs. 3-6 need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. For example, acts in processes 300, 400, 500 and/or 600 may be undertaken in parallel when processing multiple code images each having unique master and/or platform keys. In addition some acts may be undertaken before other acts. For example, the act 310 of process 300 may be undertaken prior to acts 302-308. Further, at least some of the acts in this figure may be implemented as instructions, or groups of instructions, implemented in a machine-readable medium. [0041] While the foregoing description of one or more instantiations consistent with the claimed invention provides illustration and description of the invention it is not intended to be exhaustive or to limit the scope of the invention to the particular implementations disclosed. Clearly, modifications and variations are possible in light of the above teachings or may be acquired from practice of various implementations of the invention. For example, the code images processed in processes 300 and 500 can be any arbitrary "secret" data such as a set of encryption keys or other data such as algorithm parameters. Clearly, many other implementations may be employed to enable mating an external code image with an on-chip private key consistent with the claimed invention. [0042] No device, element, act, data type, instruction etc. set forth in the description of the present invention should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article "a" is intended to include one or more items. Moreover, when terms or phrases such as "coupled" or "responsive" or "in communication with" are used herein or in the claims that follow, these terms are meant to be interpreted broadly. For example, the phrase "coupled to" may refer to being communicatively, electrically and/or operatively coupled as appropriate for the context in which the phrase is used. Variations and modifications may be made to the above- described implementation(s) of the claimed invention without departing substantially from the spirit and principles of the invention. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims.

Claims

WHAT IS CLAIMED:

1. A method comprising: receiving a code image and a code key; and encrypting the code image and the code key before placing the code image and the code in unsecured storage.

2. The method of claim 1 , wherein unsecured storage comprises storage that is user- accessible.

3. The method of claim 1 , wherein encrypting the code image and the code key if the code image and the code key are to be placed in unsecured storage comprises: encrypting the code image with the code key; and encrypting the code key with a first key.

4. The method of claim 3, wherein encrypting the code key with a first key comprises: encrypting a second key with a private key; encrypting the first key with the second key; and encrypting the code key with the first key.

5. The method of claim 1 , further comprising: decrypting the encrypted code image and the encrypted code key before placing the code image and the code key in secured storage.

6. The method of claim 5, wherein secured storage comprises storage that is user- inaccessible.

7. The method of claim 5, wherein decrypting the code image and the code key if the code image and the code key are to be placed in secured storage comprises: decrypting the code key with a first key; and decrypting the code image with the code key.

8. The method of claim 7, wherein decrypting the code key using a first key comprises: decrypting a second key with a private key; decrypting the first key with the second key; and decrypting the code key with a first key.

9. The method of claim 1, wherein the code image comprises one of a code image, a boot code image, a key, or data.

10. The method of claim 1 , further comprising: receiving another code image and another code key; and encrypting the another code image and the another code key if the another code image and the another code key are to be placed in unsecured storage.

11. An apparatus comprising: user-accessible storage; user-inaccessible storage; encryption logic to encrypt a first code image and a first code key to provide an encrypted first code image and an encrypted first code key if the first code image and the first code key are to be placed in the user-accessible storage; and decryption logic to decrypt the encrypted first code image and the encrypted first code key if the first code image and the first code key are to be placed in the user- inaccessible storage.

12. The apparatus of claim 11 , further comprising: memory to hold a private key, wherein the encryption logic is at least capable of encrypting the first code key with the private key.

13. The apparatus of claim 11 , further comprising: memory to hold a private key; and key derivation logic at least capable of deriving an encryption key from the private key, wherein the encryption logic is at least capable of encrypting the first code key with the encryption key.

14. The apparatus of claim 11, wherein the user-inaccessible storage comprises one of memory formed in the same semiconductor substrate as the encryption logic, or memory coupled to the encryption logic by a system bus.

15. The apparatus of claim 11, wherein the encryption logic at least further capable of encrypting a second code image and a second code key to provide an encrypted second code image and an encrypted second code key if the second code image and the second code key are to be placed in the user-accessible storage, and wherein the decryption logic at least further capable of decrypting the encrypted second code image and the encrypted second code key if the second code image and the second code key are to be placed in the user-inaccessible storage.

16. The apparatus of claim 11, wherein the user-accessible storage comprises one of a fixed non- volatile memory device, or a removable non- volatile memory device.

17. The apparatus of claim 11, wherein the code image comprises one of a code image, a boot code image, a key, or data.

18. A system comprising: user-accessible storage; user-inaccessible storage; encryption logic at least capable of encrypting a first code image and a first code key to provide an encrypted first code image and an encrypted first code key if the first code image and the first code key are to be placed in the user-accessible storage; decryption logic at least capable of decrypting the encrypted first code image and the encrypted first code key if the first code image and the first code key are to be placed in the user-inaccessible storage; and wireless receiver circuitry coupled to the encryption logic, the receiver circuitry at least capable of receiving the first code image and the first code key.

19. The system of claim 18, further comprising: memory to hold a private key, wherein the encryption logic is at least capable of encrypting the first code key with the private key.

20. The system of claim 18, further comprising: memory to hold a private key; and key derivation logic at least capable of deriving an encryption key from the private key, wherein the encryption logic is at least capable of encrypting the first code key with the encryption key.

21. The system of claim 18, wherein the user-inaccessible storage comprises one of memory formed in the same semiconductor substrate as the encryption logic, or memory coupled to the encryption logic by a system bus.

22. The system of claim 18, wherein the encryption logic at least further capable of encrypting a second code image and a second code key to provide an encrypted second code image and an encrypted second code key if the second code image and the second code key are to be placed in the user-accessible storage, and wherein the decryption logic at least further capable of decrypting the encrypted second code image and the encrypted second code key if the second code image and the second code key are to be placed in the user-inaccessible storage.

23. The system of claim 18, wherein the user-accessible storage comprises one of a fixed non- volatile memory device, or a removable non- volatile memory device.

24. The system of claim 18, wherein the code image comprises one of a code image, a boot code image, a key, or data.