FIELD OF THE INVENTIONThe present invention relates to the field of memory management, and more particularly to securing updates to a non-volatile memory used to store program code.[0001]
BACKGROUND OF THE INVENTIONMany computer systems include a non-volatile memory to store basic input/output system (BIOS) program code. The BIOS code is usually the lowest layer of software in a computer system and acts as an interface between system hardware and higher-layer software. For example, the BIOS typically includes routines for managing system startup and for controlling various hardware components such as a wait-state generator, hardware timers, interrupt controllers and so forth.[0002]
Because BIOS routines interact extensively with system hardware, they are often invoked at a privilege level that allows unrestricted memory and I/O access. This makes the BIOS space (i.e., the memory space allocated to the BIOS) a particularly likely candidate for malicious attack. If unauthorized code (e.g., a computer virus) is substituted for BIOS code, the unauthorized code will likely be able to access a broad range of system devices that privilege-level protections would otherwise prevent. As a result, a successful attack on the BIOS space can result in considerable damage to a computer system, including the loss of sensitive information.[0003]
In modern computer systems, flash memory devices (e.g., flash electrically-erasable, programmable read-only memory (flash EEPROM)) are often used to store BIOS code. By sending the appropriate commands, flash devices can be erased and reprogrammed. While this makes it easier to install updated BIOS software, it also opens the door to malicious attack on the BIOS space. For example, some BIOS developers post updated BIOS code on sites of the World Wide Web (“the web”) from which they can be downloaded and installed. One seeking to introduce unauthorized code into the BIOS space (i.e., an “attacker”) could modify the posted BIOS code or even intercept and modify the code during download. Alternatively an attacker might masquerade as a legitimate BIOS developer to induce a computer user to download and install unauthenticated code. For example, the attacker could post unauthenticated code on a website and represent the code as being provided by a legitimate developer.[0004]
FIG. 1 is a data flow diagram that illustrates one prior-art technique for preventing unauthorized access to the BIOS space. Initially,[0005]program code10 is obtained in a computer system that includes a processor22, asystem memory11, an updatable,non-volatile memory device12, a bus20 and aninterrupt generator28. When adata transfer program19 is executed, writecircuitry26 within the processor22 transfers theprogram code10 across bus20 along with commands to theflash device12 to write the program code into a predetermined space withinstorage array18. Theinterrupt generator28 snoops the signals transferred across the bus20 and can therefore detect when a write access to theflash device12 is being attempted. In response to detecting a write access attempt, theinterrupt generator28 asserts aninterrupt29 to interrupt the processor22. In response to the interrupt, the processor22 invokes an interrupt service routine27 (typically stored in system memory11) to validate the source of the data write, for example, by determining whether a predetermined value is present in the program code10 (e.g., header or trailer information).
If the interrupt service routine (ISR)[0006]27 determines that the attempted write access to theflash device12 is valid, theISR27 is exited and transfer of theprogram code10 is resumed. To prevent repeated interrupt generation after the initial validation operation, theinterrupt generator28 may be disabled until after the transfer is complete.
One disadvantage of the above-described technique is that it is relatively easy to circumvent. For example, the vector to the[0007]ISR27 can be changed so that when the interrupt from theinterrupt generator28 is received, a substitute ISR is invoked. This substitute ISR may then disable the interrupt generator without validating theprogram code10 that is attempting to write to theflash device12. Unauthorized program code may then be written to theflash memory device12. Alternatively, an attacker may access the code ofISR27 to learn the authenticating value (or set of values) that is expected in theprogram code10 and where the authenticating value is stored. The attacker can then store the authenticating value in unauthorized program code so that theISR27 erroneously validates the unauthorized program code. Again, the unauthorized program code may be written to theflash memory device12.
SUMMARY OF THE INVENTIONAn apparatus and method for preventing unauthorized updates to a non-volatile memory are disclosed. A sequence of encoded values is received in a non-volatile memory device. The sequence of encoded values is decoded in a decoding circuit in the non-volatile memory device to generate a sequence of decoded values and the sequence of decoded values is stored in the non-volatile memory device.[0008]
Other features and advantages of the invention will be apparent from the accompanying drawings and from the detailed description that follows below.[0009]
BRIEF DESCRIPTION OF THE DRAWINGSThe present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements and in which:[0010]
FIG. 1 is a data flow diagram that illustrates one prior-art technique for preventing unauthorized access to a BIOS space;[0011]
FIG. 2 is a data flow diagram that illustrates a method of updating contents of a non-volatile memory device according to one embodiment;[0012]
FIG. 3 diagrams one embodiment of a method for generating the encoded program code that restricts access to the encoding technique;[0013]
FIG. 4 is a diagram of a flash memory device according to one embodiment;[0014]
FIG. 5 is a diagram illustrating the components of a keystream-based encoding/decoding system according to one embodiment; and[0015]
FIG. 6 depicts one embodiment of a[0016]keystream generator89 that is used to decode an encoded image.
DETAILED DESCRIPTIONAccording to embodiments of the present invention, computer security is increased by writing pre-encoded program code to an enhanced-security, non-volatile memory device. Prior to publishing program code, a software developer encodes the program code using a predetermined encoding technique. When the published, encoded program code is obtained by a consumer and written to the enhanced-security, non-volatile memory device, a decoding circuit within the non-volatile memory device decodes the program code before it is stored in the device's non-volatile storage array. The decoded program code may then be fetched and executed in a conventional manner.[0017]
If an attacker attempts to transfer unauthorized, unencoded program code to the non-volatile memory device, the decoding circuit will garble the unauthorized code to prevent its execution. While this does not prevent overwriting of contents of the non-volatile memory, it does prevent the storage of program code which, if executed, could result in a loss of valuable or sensitive data. Thus, it is an intended advantage of the present invention to provide enhanced computer security by preventing unauthorized program code from being successfully stored in a non-volatile memory device. Other features and advantages of the present invention will be apparent from the following description and the accompanying drawings.[0018]
FIG. 2 is a data flow diagram that illustrates a method of updating contents of a non-volatile memory device according to one embodiment.[0019]Program code10 is encoded according to a predetermined encoding technique and then published for distribution as encodedprogram code50. As discussed below, any number of different encoding techniques may be used to generate the encodedprogram code50. Also, because an important application of the present invention is to prevent the BIOS space from being written with unauthorized program code, the program code is occasionally referred to as BIOS code in the following description. Application of the present invention is not limited to securing BIOS code, however, and the program code may generally be any program code or data for which enhanced security is desired.
After the[0020]program code10 has been encoded, the encodedprogram code50 is transferred to acomputer system21 that includes a processor22, a non-volatile memory device32 asystem memory11 and a bus20. Thenon-volatile memory device32 is shown in FIG. 2 and described in the following description as a flash memory device, although any non-volatile memory device that can-be erased and reprogrammed in-circuit may be used.
After the encoded[0021]program code50 has been received in the computer system21 (e.g., stored in the system memory11),writing circuitry26 in the processor22 is used to transfer the encodedprogram code50 to theflash memory device32 via the bus20. The encoded program code is transferred to theflash memory device32 one word at a time in response to execution ofprogram code51. The word-size of each word transferred is determined by the width of the data portion of the bus20 or by the software used to control thetransfer51, or both. In any case, the encodedprogram code50 is received by theflash memory device32 as a stream of data words.
In one embodiment, the flash device includes writing[0022]circuitry36, readingcircuitry14, astorage array18 anddecoding logic38. The writingcircuitry36 within theflash memory device32 transfers the encodedprogram code50 todecoding logic38. Thedecoding logic38 decodes the encodedprogram code50 to recover theoriginal program code10. The decoded program code (i.e., recovered program code10) is then stored in thestorage array18. Under software control, readingcircuitry24 within the processor22 may fetch the decoded program code via the readingcircuitry14 in theflash memory device32. The decoded program code may then be executed by the processor22 in a conventional manner.
According to one embodiment, access to the technique for encoding program code is restricted to authenticated software developers to prevent unauthorized persons from circumventing the security mechanism described above. FIG. 3 diagrams one embodiment of a method for generating the encoded program code (e.g., encoded[0023]program code50 of FIG. 2) that restricts access to the encoding technique to authenticated software developers. Atstep41, asoftware developer54 presents authentication information to a non-volatilememory component manufacturer57 in a request to be authenticated as a legitimate software developer. The authentication information may include, but is not limited to, documents affirming the identity of the software developer, information obtained by visiting the software developer's site to assure its legitimacy and security procedures, and so forth. If thesoftware developer54 is authenticated atstep43, then thememory component manufacturer57 grants thesoftware developer54 access to the encoding device or encoding computer program atstep45. According to one embodiment, thememory component manufacturer57 grants access to the encoding device or program by encoding program code on behalf of thesoftware developer54. In this way, thememory component manufacturer57 maintains possession of the encoding device or program, thus enhancing system security. In an alternate embodiment, thememory component manufacturer57 may release the encoding device or program to thesoftware developer54 to allow thesoftware developer54 to perform the encoding operation.
At[0024]step47, the program code is encoded into an encoded image (e.g., encodedprogram code50 of FIG. 2) by thesoftware developer54 or by thememory component manufacturer57 on the software developer's behalf. Atstep49, thesoftware developer54 releases the encoded image for publication. Atstep51, aconsumer55 obtains the encoded image of the software developer's program code, for example, by downloading the encoded image from a website or by purchasing a computer-readable medium having the encoded image stored thereon (e.g., CD-ROM or diskette) from a retailer. Atstep53, theconsumer55 executes a program (e.g.,program code51 of FIG. 2) to transfer the encoded image to anon-volatile memory device32 that contains decodinglogic38. Thedecoding logic38 restores the encoded program code to its executable form so that the program code may be fetched and executed.
FIG. 4 is a diagram of a[0025]flash memory device32 according to one embodiment. Theflash memory device32 includes input andoutput buffers61 and63,control logic65, decodinglogic38, anaddress buffer67, anaddress counter69, blockselect logic80, wordselect logic82, gating/sensing circuitry70 and astorage array18 arranged in blocks0 to N−1. Theflash memory device32 may include other components that are not shown (e.g., page buffers and page buffer control circuitry). Theflash memory device32 receives and outputs data on an N-bit wide data bus71, receives addresses on an M-bitwide address bus73 and receives control signals output enable74, write enable75 and chip enable76 on acontrol bus72. In one embodiment, thecontrol bus72,address bus73 and data bus71 are included in the bus20 shown in FIG. 2.
The[0026]control logic65 receives the output enable74, write enable75 and chip enablesignals76 and issues control signals to theoutput buffer61,input buffer63 andaddress buffer67 in response. For example, when the write enable signal and the chip enable signals are asserted, thecontrol logic65 issues control signals to enable an input value from the data bus71 into theinput buffer63 and an address from theaddress bus73 into theaddress buffer67. The input value is then delivered from theinput buffer63 to either thedecoding logic38 or thecontrol logic65 based on whether the input value is a command or data. For example, if a data transfer was completed in the preceding transfer cycle, the next input value may be assumed to be a command and is therefore delivered to thecontrol logic65. Input values that are part of a commanded data transfer are delivered to thedecoding logic38 and then to the gating/sensing circuitry70. The gating/sensing circuitry70 programs (writes) each decoded value received from thedecoding logic38 in thestorage array18.
Assuming that a command to write a sequence of values (e.g., program code) has been received in the[0027]control logic65, thecontrol logic65 will cause the address from theaddress buffer67 to be stored in theaddress counter69 and will then signal theaddress counter69 to increment the address as each data value is written to thestorage array18. The blockselect logic80 and wordselect logic82 receive each incremental address from theaddress counter69 and decode the address to select a block within thestorage array18 and a location within the selected block, respectively, at which a decoded data value is stored. The gating/sensing circuitry70 is used to perform the actual programming (writing) and sensing (reading) operations. When a command is received to read data from thestorage array18, a value is output from the addressed location (as selected by the blockselect logic80 and word select logic82), amplified by the gating/sensing circuitry70 and driven onto the data bus71 by theoutput buffer61, all under control of thecontrol logic65.
For each unit of program code received from the data bus[0028]71 and buffered in theinput buffer63, thecontrol logic65 signals thedecoding logic38 to generate a new decoding value that is applied to decode the unit of program code. Each decoded program code value is supplied to the gating/sensing circuitry70 which programs the decoded program code value into a respective storage location selected by the blockselect logic80 and the wordselect logic82.
The sequence of decoding values generated by the[0029]decoding logic38 and applied to decode an incoming program code sequence is referred to as a keystream. A keystream is generated by a logic element called a keystream generator which may be implemented in software or by a wide variety of circuits.
FIG. 5 is a diagram illustrating the components of a keystream-based encoding/decoding system according to one embodiment. As shown, a[0030]program code sequence10 is exclusive-or'd (e.g., by exclusive-or gate85) word-by-word with akeystream84 to produce an encodedimage50. When the encodedimage50 is transferred to a non-volatile memory device that includes decoding logic38 (e.g., thenon-volatile memory device32 of FIG. 4), akeystream generator89 within thedecoding logic38 applies thesame keystream84 that was used to produce the encodedimage50 to the recover the originalprogram code sequence10. The following illustrates the logical equivalence between a code sequence that has been twice exclusively-or'd with the same keystream and the original code sequence:
(CODE XOR KEY) XOR KEY=CODE XOR (KEY XOR KEY)=CODE XOR0=CODE
According to one embodiment, the encoded[0031]image50 is produced by executing a computer program to generate thekeystream84 and to XOR the individual keystream values with respective words of the program code sequence. Because the decoding logic is implemented in hardware, a circuit-basedkeystream generator89 is used in one embodiment to generate thekeystream84 applied to decode the encodedimage50.
FIG. 6 depicts one embodiment of a[0032]keystream generator89 that is used to decode an encoded image. Thekeystream generator89 is one of a class of pseudo-random-sequence generators known as a linear feedback shift register (LFSR). TheLFSR89 includes two components: ashift register91 and afeedback function93. With each shifting of theshift register91, a new most-significant bit94 is output as part of the keystream, and aninput bit95 is inserted at the beginning of theshift register91. In one embodiment, the shift register is shifted in response to a control signal (e.g., fromcontrol logic65 of FIG. 4) that is asserted with each new program code value received. Other clocking sources may be used to shift the contents ofshift register91 in alternative embodiments.
The[0033]feedback function93 is typically an exclusive-or combination of bits at selected bit positions of theshift register91. These selected bit positions are referred to as taps. By appropriate selection of the taps, theLFSR89 can be made to output a keystream that does not repeat until after2n−1 key bits have been generated, n being the number of bits in theshift register91. In alternate embodiments, other circuits may be used to generate the keystream, including, but not limited to, combinations of LFSRs in which the output of one or more LFSRs are logically combined, used to select between outputs of other LFSRs, used to clock other LFSRs, and so forth.
According to one embodiment, a single bitstream generated by a[0034]keystream generator89 is applied to decode a sequence of program code values. A single bit output by thekeystream generator89 may be applied to each bit of a program code word so that a word filled with all1's or all0's would be used to decode each word of program code. This is shown in FIG. 6 by the exclusive-or combination (element86) of the most significant bit of theshift register91 with each of the N-bits of a word of incoming program code. Alternatively, the keystream generator may be clocked so that N bits of the keystream are generated and respectively applied to each of the N-bits of an encoded word of program code. For example, each of the bits in an N-shift register could be respectively applied to the N-bits of an encoded word of program code. The shift register would then be clocked (i.e., shifted) N times to generate a new N-bit keyword for application to the next word of program code.
In another embodiment, N separate bitstreams may be generated by a keystream generator to produce a keyword made up of N different key bits. This may be accomplished, for example by providing N differently designed LFSR circuits that operate in parallel to generate the N-bit keyword, or by providing N identically designed LFSR circuits that are seeded differently (e.g., the shift registers of the individual LFSRs may be initialized to different values).[0035]
According to yet another embodiment, a transfer protocol may be defined in which one or more predetermined values are appended to the beginning of a program code sequence to seed the LFSR circuits. When the seed value prefix is received in the non-volatile memory, the seed values act to initialize the keystream generator to a predetermined state before the output of the keystream generator is applied to the succeeding program values. Logic may be included in the decoding logic to suppress storage of the seed values in the non-volatile storage array or the starting address at which the program code is to be stored may be adjusted to account for storage of the seed values.[0036]
Another non-volatile memory device comprises storage elements, reading circuitry to retrieve encoded data from the storage elements and to output the data on a data path, and decoding circuitry coupled to the reading circuitry to decode the encoded data retrieved from the storage elements before the reading circuitry outputs the data on the data path.[0037]
A sequence of encoded values is stored in storage elements of a non-volatile memory device. The encoded sequence of values is retrieved from the storage elements in response to a read request. The encoded sequence of values is decoded in a decoding circuit within the non-volatile memory device to generate a sequence of decoded values. The sequence of decoded values is output.[0038]
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly to be regarded in an illustrative rather than a restrictive sense.[0039]