Abstract:
Secure boot ROM emulation with locking storage device. A locking storage device is provided by combining a nonvolatile memory device such as flash or EEPROM with one-shot locking logic which write enables at least a portion of the nonvolatile memory device upon power cycling of the overall digital device. This write enable is cleared during the stage 1 bootloader process, thus providing a protected update interval for updating a stage 2 bootloader once per power cycle.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    The present invention relates to the startup of digital computing devices, and more particularly to the secure startup of digital computing devices. 
         [0002]    Digital computing devices, including desktop or laptop computers, servers, and various types of network appliances and embedded devices, are significantly more reliable from an operational and/or a security standpoint if the integrity of the system software can be validated as part of the system initialization process. Otherwise, the potential exists for this software to be corrupted through system errors or malicious behavior, and such corruption may lead to various forms of undesirable behavior. The burden of providing compatibility, particularly for older protocols and clients, falls upon the wireless system, and in particular on its access nodes. A single access node may be called upon to serve many different types and speeds of clients at the same time. 
         [0003]    This problem has been addressed in the past by implementing some sort of software image integrity check which occurs prior to loading and executing the software. Common approaches include computing a CRC-32 checksum over the software image, somehow locally storing that checksum, and then verifying the checksum against a newly computed checksum each time the software is loaded. Due to weaknesses in the CRC approach, variations using some more robust alternative function (e.g. a cryptographic hash function such as MD5 or SHA1, and/or digital signatures) are frequently used. 
         [0004]    One difficulty with such mechanisms is that they depend on a leap of faith regarding the integrity of the initial program loader (also called a “bootloader”), which is responsible for validating and loading the system software. If the bootloader is corrupted (or worse, replaced with malicious code), then the mechanism is unreliable, and the leap of faith is unjustified. In general, this is accepted as a limitation which can only be addressed by placing the bootloader in Read Only Memory (ROM). 
         [0005]    One drawback of implementing the bootloader in ROM is that, in general, it cannot be easily modified once the system is assembled. The only way to update such bootloaders is to replace the ROM element, which is typically soldered to the circuit board. This limitation may be acceptable for a simple device which is not subject to change, or for which it is acceptable to require the owner to simply purchase a new, updated version whenever additional or new functionality be desired. But for more expensive, dynamic, and long-lived devices, this is far less desirable. 
         [0006]    What is needed is a system and method for allowing a bootloader to be updated or replaced in a secure manner. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    The invention may be best understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention in which: 
           [0008]      FIG. 1  shows a target device, and 
           [0009]      FIG. 2  shows a diagram of bootloader storage. 
       
    
    
     DEFINITIONS 
       [0010]    In describing embodiments of the invention, the following Definitions are used: 
         [0011]    Target Device: the digital computing device for which the bootloader is intended. 
         [0012]    Bootloader: a special program whose purpose is to load the operating system image into RAM and transfer control to the loaded image. 
         [0013]    Multi-stage bootloader: a group of programs collectively implementing the loading function by running sequentially, with stage 1 loading stage 2, stage 2 loading stage 3, and so on. Typically, multi-stage loaders are limited to 2 or 3 stages. 
         [0014]    Bootloader storage: the storage device on/in which the bootloader resides. Note that this is typically some form of flash memory, but may include other storage technologies. Examples include Solid State Drive (SSD), and Electrically Erasable Programmable ROM (EEPROM). 
         [0015]    First (bootloader) stage: the initial stage of the bootloader which is responsible for selecting and loading the second stage. 
         [0016]    Second (bootloader) stage: the stage responsible for loading the operating system into RAM and transferring control to it. 
         [0017]    Image validation: describes the method used to ensure image integrity and authorization. 
         [0018]    Bank select configuration—a stored value indicating which stage 2 “bank” is active. 
         [0019]    Verification key: a cryptographic key used in the validation algorithm. 
         [0020]    Verification chain: a chain of one or more verification keys leading to a root of trust. 
         [0021]    Root of trust: the root in a trust hierarchy, typically the public key of a root Certification Authority (CA), but a single, trusted verification key may be simultaneously considered to be a verification chain (with one link) and a root of trust. 
         [0022]    Locking storage device: flash memory, solid state drive, EEPROM, or other non-volatile storage device which provides an electronic locking capability, usually via adjustment of one of the device input signals. This locking capability disallows writing to one or more portions or to the entirety of the storage device. 
         [0023]    One-shot locking logic: a logic circuit which can be triggered exactly once per power cycle; resetting this signal requires removing and re-applying power. 
         [0024]    One-shot storage lock: a combination of a locking storage device and one-shot locking logic such that upon initialization, storage is unlocked (i.e. writable), but at some point in the initialization process, the one-shot device is triggered, locking storage until a power cycle occurs. 
         [0025]    Locking trigger: the signal which, when applied to the one-shot locking logic, “trips” the circuit, causing storage to be locked (write protected). 
       DETAILED DESCRIPTION 
       [0026]    Embodiments of the invention relate to updating or replacing a bootloader in a target digital computing device such that only an authorized version may be used, and doing so in a secure manner. While the invention is illustrated using a two-stage bootloader and associated configuration embodied contiguously within a single locking storage device, other configurations are also possible. According to an embodiment of the invention, when the device is powered up, a one-shot storage lock is enabled, allowing writing to a locking storage device used for bootloader storage. The first stage bootloader is executed, and as part of that execution, checks to see if an update to the second stage bootloader is available. If an update is not available, the locking trigger is executed, locking storage, and execution continues with the second stage of the bootloader. If an update to the second stage bootloader is available, the update is verified, and written to the locking storage device. After the write completes, the locking trigger is executed, locking storage, and execution continues, with the updated second stage bootloader. 
         [0027]      FIG. 1  shows a block diagram of a target device  100  according to an aspect of the invention. Central processing unit (CPU)  110  is connected to memory hierarchy  120 , which contains instructions and data. Such memory hierarchy  120  contains a mix of non-volatile memory such as read-only memory (ROM), flash memory, or electrically programmable read-only memory (EEPROM), volatile memory such as RAM, and optionally mass storage such as Flash, compact flash, or disc. CPU  110  is also connected to input-output devices such as network adapters, displays, and the like, not shown for clarity. 
         [0028]    Power supply  130  takes power from a source (not shown) such as an AC source, 802.3af Power over Ethernet, a direct current source, or the like, and provides regulated DC voltages to operate target device  100 . As is known to the art, while these voltages may be regulated with precision, they may vary during the power-up interval, going from zero to their regulated levels. Therefore a reset generator  140  is provided which monitors one or more regulated voltages from power supply  130 , and generates reset signals which do not allow for device operation until the outputs of power supply  130  have stabilized. Suitable reset generators include the MAX811 from Maxim, the ADM709 manufactured by Analog Devices, the PCD1252 family of devices from NXP Semiconductor, and similar components from companies such as National Semiconductor, Linear Technologies, Texas Instruments, and the like. 
         [0029]    According to an aspect of the invention, as target device  100  powers up, signaled for example by a reset signal from reset generator  140 , one-shot locking logic  150  is set by reset generator  140  producing a write enable signal  160  to the locking storage device portion of memory hierarchy  120 . This write enable signal is only provided when target device  100  powers up. 
         [0030]    As is known to the art, when CPU  110  is reset, it follows a reset sequence detailed by its manufacturer. As examples, some CPUs start fetching instructions from memory location 0000; other CPUs fetch an address from a predefined memory address, and then begin executing instructions at the memory location thus pointed to. As is known to the art, memory  120  at these addresses must be present at device reset, and is commonly provided by a persistent memory, such as read-only memory (ROM), flash memory, or electrically programmable read-only memory (EEPROM). This first section of instruction code is the stage 1 bootloader. 
         [0031]    According to the present invention, and referring to  FIG. 2 , a portion  170  of non-volatile memory  200  forms a locking storage device. One-shot locking logic  150  write enables  160  this portion on receipt of a power-on reset signal  145 . Non-volatile memory may be a Flash memory device, an EEPROM, or a combination of non-volatile memory devices. 
         [0032]    As device  100  starts up, the stage 1 loader  210  does the following: 
         [0033]    Complete additional processor Initialization, such as initializing RAM, stack pointers, memory maps, interrupts, and the like. 
         [0034]    Optionally, initialize a secondary storage device containing the stage 2 loader (if it is not contained in the same storage device  200  as stage 1). 
         [0035]    Optionally, transfer a copy of itself into RAM, and continue execution there. This step is often performed if there is a speed difference between fetching and executing instructions from the non-volatile memory containing the stage 1 loader and from RAM. 
         [0036]    Test for presence of stage 2 update. This update  260  may be contained in the same storage device  200  as the stage 1 bootloader, or a different persistent storage device. If no update present, execute one-shot locking logic  150 , disabling write enable  160 , which disables writes to the bootloader storage segment. 
         [0037]    One-shot locking logic  150  may be triggered to disable write enable  160 , write protecting the bootloader storage segment in many ways, depending on the architecture of the particular device. In a CPU supporting an I/O register architecture, the trigger may be mapped to a particular I/O register, or to a bit in an I/O register. In memory-mapped architectures, the trigger may be mapped to accessing a particular memory location or range of memory locations. 
         [0038]    If an update is present: 
         [0039]    Validate the update image. This may be done through techniques such as checksums, validating a digital signature  265  attached to the image, validating a cryptographic signature of the image such as a hash, or other cryptographic process. 
         [0040]    Examine bank select configuration for stage 2; select the inactive bank  230   240  and write the stage 2 update to that bank  230   240 . The active bank may be stored as an environment variable in locking storage  220 . 
         [0041]    Update the bank select value, making the newly copied stage 2 loader the active bank 
         [0042]    Execute one-shot locking logic  150 , disabling write enable  160 , which disables writes to bootloader storage segment. 
         [0043]    Note that regardless of whether the update completes successfully or an error occurs, the one-shot locking logic is executed, write-protecting bootloader storage. 
         [0044]    Make any necessary preparations for second stage loading. 
         [0045]    If there are multiple copies of the second stage, check the bank select configuration to determine which bank  230   240  is active/valid 
         [0046]    Validate the selected second stage image, using a checksum or digital signature 
         [0047]    If the active second stage bootloader does not validate, reselect the older second stage bootloader 
         [0048]    Optionally load the second stage bootloader into RAM 
         [0049]    Transfer control to the second stage bootloader 
         [0050]    While this embodiment of the invention provides for a backup copy of the second stage bootloader, an alternate embodiment may use only one storage area  230  for storing the second stage bootloader. In this case, updates to the second stage bootloader are applied in place. Failure of this updated second stage bootloader results in an inoperable device colloquially known as a brick. 
         [0051]    As shown in  FIG. 2 , nonvolatile storage  200  has a portion protected as locking storage. This locked portion may include the stage 1 bootloader  210  and protected environment variables  220 , or the memory area  210  used by stage 1 bootloader may be write protected at all times. In other embodiments, locking storage  170  may be present as a separate nonvolatile memory device, or the entire nonvolatile memory  200  may be locked. 
         [0052]    As an example, a 64 kbyte nonvolatile storage device such as an EEPROM may be used for nonvolatile storage device  200 . The first 16 kbytes may be dedicated to stage 1 bootloader  210  and environmental variables  220 . The second 16 kbytes may be dedicated to bank 0 stage 2 bootloader storage  230 , the third 16 kbytes dedicated to bank 1 stage 2 bootloader  240 , and the final 16 kbytes dedicated to holding update image  260  and signature  265 . 
         [0053]    While the invention has been described in terms of various embodiments, the invention should not be limited to only those embodiments described, but can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is this to be regarded as illustrative rather than limiting.