Secure Embedded Microcontroller Image Loading

Abstract

A system and method for providing secure image loading includes a microcontroller. The microcontroller has a plurality of physically alterable internal components (PMICs). Each of the plurality of PMICs is alterable only once. The system includes an image loader configured to load a boot image from the microcontroller's memory and a checksum calculator configured to calculate a checksum value for the boot image. The system further includes a checksum burner configured to modify the plurality of PMICs to create a binary representation of the image's checksum value. A checksum value for the image is calculated. This checksum value is written to the microcontroller. This value is burned into the microcontroller using the PMIC. Furthermore, a response to a checksum mismatch is burned into the microcontroller using the PMIC residing within the microcontroller.

Description

[Technical field]

[0001] The present disclosure relates to image loading, and more particularly, to ensuring that the correct boot image is loaded. [Background technology]

[0002] Currently, computers load an image from off-chip non-volatile storage. This image is assumed to be valid and secure. However, an attacker may compromise the image and security of a computer by loading a modified image. If the compromised image is loaded onto an associated computer, the computer may be used for any purpose desired by the person who modified the image. Such purposes may be either intentional or unintentional by the user, potentially creating unauthorized security vulnerabilities within an organization.

[0003] Therefore, there is a need in the art to address the above problems. Summary of the Invention

[0004] Viewed from a first aspect, the present invention provides a system for providing secure boot image loading, the system comprising: a microcontroller; a plurality of physically alterable internal components (PMICs) disposed on the microcontroller, each PMIC being alterable only once; an image loader configured to load a boot image from a memory of the microcontroller; a checksum calculator configured to calculate a checksum value of the boot image; and a checksum burner configured to modify the plurality of PMICs to create a binary representation of the checksum value of the boot image.

[0005] Viewed from a further aspect, the present invention provides a method comprising calculating a checksum value of a boot image, writing the checksum value to a microcontroller, burning the checksum value into the microcontroller, and burning a response to a checksum mismatch into the microcontroller.

[0006] Viewed from a further aspect, the present invention provides a method of securing boot image loading, the method comprising: loading the boot image from a microcontroller; calculating a checksum value of the boot image; comparing the checksum value to a stored checksum value that is permanently burned into the microcontroller; in response to a match when comparing the checksum value with the stored checksum value, causing loading of the boot image to continue; and in response to a mismatch when comparing the checksum value with the stored checksum value, executing a mismatch response.

[0007] Viewed from a further aspect, the present invention provides a computer program product for securing boot image loading, the computer program product comprising a computer readable storage medium readable by a processing circuit and storing instructions for execution by said processing circuit to perform a method of the present invention.

[0008] Viewed from a further aspect, the present invention provides a computer program stored on a computer readable medium and loadable into an internal memory of a digital computer, said computer program comprising software code portions for performing the steps of the present invention when said program is executed on a computer.

[0009] An embodiment of the present disclosure is directed to a system for providing secure image loading. The system includes a microcontroller. The microcontroller has a plurality of physically alterable internal components (PMICs). Each of the plurality of PMICs is alterable only once. The system further includes an image loader configured to load a boot image from a memory of the microcontroller and a checksum calculator configured to calculate a checksum value of the boot image. The system further includes a checksum burner configured to alter the plurality of PMICs to create a binary representation of the checksum value of the image.

[0010] Embodiments of the present disclosure are directed to a method of creating a secure image on a microcontroller. A checksum value for the image is calculated. The checksum value is then written to the microcontroller. This value is then burned into the microcontroller using a PMIC present in the microcontroller. A response to a checksum mismatch is also burned into the microcontroller using a PMIC present in the microcontroller.

[0011] Embodiments of the present disclosure are directed to a method for securing boot image loading. A boot image is loaded from a microcontroller. A checksum value of the loaded boot image is then calculated. This value is then stored in the microcontroller and compared to a checksum value that is burned into the microcontroller. If a match is found between the checksum value and the stored checksum value, the boot image is allowed to continue loading. If a mismatch is found, a mismatch response is executed. The mismatch response is programmed into the microcontroller.

[0012] The above summary is not intended to describe each example embodiment or every implementation of the present disclosure.

[0013] The drawings included in this application are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The drawings are merely illustrative of particular embodiments and are not limiting of the disclosure. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 is a block diagram illustrating a system employing secure embedded microcontroller image loading, according to an example embodiment. [Diagram 2] 4 is a flow diagram illustrating a process of how the system loads and burns a checksum value into a microcontroller in accordance with an example embodiment. [Diagram 3] 4 is a flow diagram illustrating a process of how the system operates during normal operation, according to an example embodiment. [Figure 4] 1 is a block diagram illustrating a computing system according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] While the invention is susceptible to various modifications and alternative forms, specific details of the invention have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the scope of the invention.

[0016] Aspects of the present disclosure relate to image loading, and more particularly, to ensuring that the correct boot image is loaded. Although the present disclosure is not necessarily limited to such applications, various aspects of the present disclosure will become apparent from the description of various embodiments using this context.

[0017] The present disclosure uses checksums to verify that the image loaded at system initialization matches the image the system was originally shipped with, thus preventing external memory from being altered or corrupted after manufacture without detection.

[0018] Other techniques for validating the boot image 120 use a security header or cryptographic key. This header is generated by signing the image with a private key. However, a weakness of this technique of using a signed image is that a fraudulent image could be loaded and signed with a valid key to generate the security signature expected by the system. This increases the vulnerability of the system to malicious attacks. This disclosure does not require nor discourage the use of encryption as an additional level of protection. This allows a prudent enterprise or individual to use both methods to secure their boot image 120 against unwanted or intentional modification.

[0019] 1 is a block diagram of a system employing secure embedded microcontroller 110 image loading according to an embodiment. The system includes a microcontroller 110, a boot image 120, an image loader 130, a checksum calculator 140, and a checksum burner 150.

[0020] The microcontroller 110 is a component of the system that provides embedded applications for the system. The microcontroller 110 is embodied on a single integrated circuit chip. The microcontroller 110 includes one or more processor cores (CPUs), memory, and input / output peripherals. Depending on the configuration of the microcontroller 110, the program memory may be a permanent read-only memory programmable only at the factory, or it may be a flash memory or erasable read-only memory that is field alterable. If the memory is field alterable, it may be useful to verify the integrity of the associated data on the microcontroller 110 to ensure that the data has not been altered since it was originally loaded into the microcontroller 110. The microcontroller 110 also includes several physically alterable internal components 125-1, 125-2, ..., 125-N (collectively referred to as PMIC 125).

[0021] An electronic microcontroller 110 with a physically alterable internal component (PMIC) provides an advantage over existing security techniques by ensuring that the currently loaded boot image 120 matches the original boot image 120 shipped with the microcontroller 110. The PMIC 125 is embedded inside the microcontroller 110. In some embodiments, the PMIC 125 is implemented using eFuses, a technology for dynamic real-time reprogramming of computer chips. eFuses have the advantage that once the "fuse" is burned, it cannot be reverted back to its original state. However, in some embodiments, the PMIC 125 can be an array of eFuses, or an EEPROM using logic circuits, or an EEPROM gated by eFuses. When gated by eFuses, the gate acts as a protection mechanism to prevent modification of the data / image placed across the eFuse gate.

[0022] The PMIC 125 of the microcontroller 110 is comprised of one or more cuttable devices (e.g., fuses, wires, conductive materials with defined brittleness) configured to create an open circuit. Each of the cuttable devices can operate by a sacrificial action, such as cutting. Before being cut, each cuttable device is an electronic path through which current can flow from one end to the other. Electricity can flow constantly or in response to a request to verify the cuttable device. If electricity reaches the other end, the circuit is considered closed and a closed circuit can represent a value such as "1" or "0". After being cut, each cuttable device is disconnected such that current can no longer flow from one end to the other. For example, the cuttable device can be of a brittle nature that cuts or vaporizes in response to heat, current or other related cause. If electricity does not reach the other end, the circuit is considered open and an open circuit can represent a value such as "0" or "1". The values ​​represented by an open circuit or a closed circuit are the opposite values. That is, for example, if an open circuit has a value of "1," then a closed circuit has a value of "0," and vice versa. The process of disconnecting a circuit can be accomplished by interrupting the flow of electrical current through a particular circuit, for example, by vaporizing, melting, burning, rupturing, tearing, physical modification, or otherwise. Each of the disconnectable devices can be actuated by receiving an electrical current (e.g., overcurrent, overload) that causes the formation of an open circuit.

[0023] The PMIC 125 can directly cause the action. In some embodiments, the PMIC 125 can include logic to read the number of cuttable devices and their current state. In some embodiments, the logic is not included in the PMIC 125. For example, the logic can be located in a sensor or computer that houses the PMIC 125. In another example, the logic can be located in a second integrated circuit and communicatively coupled to the PMIC 125 via logic traces on a circuit board or via a communication cable or other wire. In some embodiments, the PMIC 125 can directly apply a current to the cuttable device. In some embodiments, the PMIC 125 can indirectly apply a current to the cuttable device and directly apply a second current to the cuttable device. In a first example, a first current is applied to a wire adjacent to the plurality of cuttable devices, thereby increasing the temperature (e.g., heating) of the cuttable device. After heating, a second current is applied directly to one or more of the plurality of cuttable devices, thereby cutting one or more of the cuttable devices and resulting in the formation of one or more permanent open circuits. In some embodiments, the current applied to the cuttable devices in the PMIC 125 to cause cutting is provided by an external source. In this embodiment, the PMIC 125 does not have the internal capability to cut any of the cuttable devices. In this manner, the pattern of the cuttable devices cannot be easily changed once the microcontroller 110 has been programmed.

[0024] The boot image 120 is a computer file that contains the complete contents and structure of a computer storage medium. When the boot image 120 is transferred to the microcontroller 110, the boot image 120 allows the associated hardware of the microcontroller 110 to boot or load. The boot image 120 includes an operating system, utilities, and diagnostics. The boot image 120 may also include boot and data recovery information. The image may also include applications that are specific to the particular end use of the microcontroller 110. After the boot image 120 is constructed, it can simply be copied to the device and remains patchable within reasonable limits and disposable in case of problems. This can be done because, unlike other images, the pure boot image 120 does not contain mission-critical data. The pure boot image 120 does not contain configuration files or data that cannot be recreated from pre-made executables. Specifically, end user data is not part of boot image 120, although some operating systems require that copies of user preferences or configuration files be maintained within boot image 120 itself, for example, the Microsoft Windows® Registry. Boot image 120 of the present disclosure is generally fixed at the time microcontroller 110 is incorporated into the associated system such that no modification of boot image 120 is expected during the life of the corresponding system. However, there may be cases where boot image 120 may be modified. Such modifications may be intentional, such as when an error is later identified in boot image 120 after distribution. Conversely, such modifications may be unintentional (from the perspective of the system owner), such as a hacker or other malicious source of modification making modifications to boot image 120 to enable malicious use of the associated system or data on the system.Although this disclosure describes the image as a boot image, it should be understood that any image that a user wants to protect from corruption or other modification may be used, such as an application image.

[0025] The image loader 130 is the part of the system that loads the boot image 120 from the microcontroller 110 memory into the system's memory. The image loader 130 is stored in the system's ROM; however, in some embodiments, it may be stored elsewhere. The image loader 130 may place the boot image 120 into memory in preparation for the boot image 120 to be executed. The image loader 130 reads the contents of the boot image 120 into memory and performs other necessary tasks to prepare the boot image 120 for execution. After the loading is complete, control is passed to the loaded program code. The image loader 130 may perform a series of basic hardware tests to ensure that the system is ready to execute the boot image 120. One of the tests performed by the image loader 130 is to verify the checksum associated with the loaded boot image 120. If the checksum of the boot image 120 does not match the checksum burned into the microcontroller 110, the image loader 130 then follows a set of instructions burned into the microcontroller 110. These instructions instruct the image loader 130 how to proceed if there is a mismatch between the checksums. These instructions may include instructions to abort or otherwise stop the loading and execution of the boot image 120, to notify an administrator or other user of the mismatch, or to request additional user input before proceeding with the loading and execution of the boot image 120. Other responses to a mismatch may also be programmed into the microcontroller 110. In some embodiments, the microcontroller 110 may go through the process of examining the checksum value and executing the mismatched instructions.

[0026] The checksum calculator 140 is a component of the system that calculates a checksum of the boot image 120. The checksum calculator 140 takes the boot image 120 and applies a process to the boot image 120 to calculate a checksum value for the boot image 120. The checksum calculator 140 may employ any technique for calculating the checksum, such as parity byte, parity word, modulus sum, or position dependent. In some embodiments, the checksum may be calculated using a hash function. The length of the checksum depends on the level of security desired in the device and the number of eFuses present in the microcontroller 110. The size of the checksum may range between 1 bit and 1024 bits. However, if a cryptographic hash function is used, the checksum may have any number of bits. The checksum calculator 140 calculates the checksum of the boot image 120 before the boot image 120 is initially loaded onto the microcontroller 110, such as at the factory. The checksum calculator 140 also calculates a checksum of the boot image 120 each time the boot image 120 is loaded by the image loader 130. This checksum value is provided to the checksum burner 150 at the first opportunity and to the image loader 130 at all subsequent opportunities. In some embodiments, there are two checksum calculators 140 and 141. The first checksum calculator 140 is maintained where the boot image 120 is initially loaded into the microcontroller 110, and the second checksum calculator 141 is located on a device associated with the microcontroller 110. In this embodiment, both checksum calculators 140 and 141 implement the same technique for calculating the checksum such that both calculators obtain the same value for the same boot image 120.

[0027] The checksum burner 150 is the component of the system that burns the checksum value calculated by the checksum calculator 140 into the microcontroller 110. The checksum is burned into the microcontroller 110 using the PMIC 125 portion of the microcontroller 110. The checksum value is converted to a binary value. This binary value is then burned in by changing the cut / uncut state of some of the PMICs 125 so that the corresponding value represents the checksum value. For example, if a 256-bit checksum is used and the calculated value is "120EA8A25E5D487BF68B5F7096440019", the corresponding binary representation of the checksum is: 00110001 00110010 00110000 01000101 01000001 00111000 01000001 00110010 00110101 01000101 00110101 01000100 00110100 00111000 00110111 01000010 01000110 00110110 00111000 01000010 00110101 01000110 00110111 00110000 00111001 00110110 00110100 00110100 00110000 00110000 00110001 00111001

[0028] To burn this value into the microcontroller 110, the microcontroller 110 must have at least 256 PMICs 125 available. The checksum burner 150 then burns the corresponding circuit open or closed depending on the method used to determine a "0" or a "1". However, the microcontroller 110 can have any number of PMICs 125 so that not all of the available PMICs 125 are used for the checksum. Also, the checksum can be any number of bits. However, the microcontroller 110 must have at least as many PMICs 125 as there are bits in the checksum.

[0029] The checksum burner 150 is further configured to burn instructions into the microcontroller 110 on how the image loader 130 responds to a mismatch between the burned-in checksum and a checksum calculated for the boot image 120 when the image loader 130 loads the boot image 120. A complete set of instructions can be burned into the microcontroller 110. To burn in a complete set of instructions, the microcontroller 110 needs to have a sufficient number of PMICs 125 available to allow for the installation of the instructions in binary form. However, in some embodiments, only a portion of the instructions are burned into the microcontroller 110. In such an embodiment, the portion of the instructions can include a pointer to a location where the complete set of instructions is stored. For example, an address is burned into the microcontroller 110 such that if a mismatch occurs, the image loader 130 accesses that address from the microcontroller 110 and goes to that address to obtain the set of instructions that it needs to perform in response to the mismatch. However, other methods of directing the image loader 130 to the set of instructions via the burned-in PMIC 125 can also be used.

[0030] FIG. 2 is a flow diagram illustrating a process of how the system loads and burns a checksum value into the microcontroller 110, according to an embodiment. The process begins by calculating a checksum for the image to be loaded into the microprocessor. This is shown at step 210. The process may employ any technique for calculating the checksum, such as parity byte, parity word, modular sum, or position dependent. In some embodiments, the checksum may be calculated using a hash function. The length of the checksum depends on the level of security desired in the device and the number of eFuses present. The size of the checksum may range between 1 bit and 2048 bits. The number of bits in the checksum is not limited to the number of bits listed above, as the number of bits available for the checksum is expected to continue to increase. However, if a cryptographic hash function is used, the checksum may have any number of bits. The desired boot image 120 is passed through a checksum calculator 140 to determine the value of the checksum.

[0031] After the checksum is calculated, the system proceeds to write the checksum to the microprocessor, as shown at step 220. In order to write the checksum to the microprocessor, the checksum burner 150 receives the checksum value and then determines which PMICs 125 of the microcontroller 110 need to be disconnected. In this manner, the checksum burner 150 determines which PMICs 125 need to have their corresponding changed values. Again, depending on how the system determines what the "0" or "1" is will determine which particular PMIC 125 needs to be disconnected.

[0032] After the checksum is written to the hardware, the system proceeds to burn the checksum into the PMIC 125. This is shown in step 230. To write the checksum to the microprocessor, the checksum burner 150 disconnects the corresponding PMIC 125 so that a corresponding value of "1" or "0" is formed. The process of disconnecting a circuit can be accomplished, for example, by evaporating, melting, burning, rupturing, tearing, physically altering, or otherwise interrupting the flow of current through a particular circuit. Each of the PMICs 125 can be activated by receiving a current (e.g., overcurrent, overload) that causes the formation of an open circuit.

[0033] Following the burning of the checksum, the system then proceeds to determine the response that the hardware should take if the checksum does not match the checksum of the image being loaded. This is shown in step 240. The checksum burner 150 then burns this response into the microcontroller 110 via the additional PMIC 125 carried by the microcontroller 110. In some embodiments, a complete set of responses to a mismatch is burned into the microcontroller 110. However, in other embodiments, only a portion of the responses is burned into the microcontroller 110. For example, an address or other pointer to the complete set of instructions can be burned into the microcontroller 110 such that the image loader 130 will follow the provided address to retrieve and execute the complete set of instructions in response to a mismatch.

[0034] 3 is a flow diagram showing a process of how the system operates during normal operation to ensure that the system loads properly. The process begins by loading the boot image 120 into sRAM, as shown at step 310. The boot image 120 may be loaded into sRAM using any known method for loading an image into memory. In some embodiments, the boot image 120 is loaded into a memory location other than sRAM.

[0035] When the boot image 120 is loaded into memory, a checksum of the boot image 120 is calculated. This is shown at step 320. The checksum calculator 140 calculates the checksum value of the boot image 120 using the same process used to calculate the checksum value burned into the microcontroller 110. For example, the checksum calculator 140 may employ any method for calculating the checksum, such as parity byte, parity word, modulus sum, or position dependent. Also, in some embodiments, the checksum may be calculated using a hash function. The size of the checksum may range between 1 bit and 2048 bits. However, if a cryptographic hash function is used, the checksum may have any number of bits.

[0036] The checksum value is provided to the image loader 130. The image loader 130 then compares the checksum value received from the checksum calculator 140 with the checksum value burned into the microcontroller 110, as shown in step 330. If the checksum values ​​match, the image loader 130 continues to load the boot image 120, and continues the process of loading the boot image 120, as shown in step 340.

[0037] If the checksum values ​​do not match, the image loader 130 then determines a response to the mismatch. This is shown at step 350. The image loader 130 then checks with the microcontroller 110 to determine if there is a set of instructions that need to be followed if a mismatch occurs. These instructions may include complete or partial instructions on how to respond to a mismatch. If complete instructions are given, the image loader 130 follows those instructions. However, if partial instructions are given, the image loader 130 may follow those partial instructions to get the complete set of instructions. As mentioned above, partial instructions may instruct the image loader 130 to go to a particular location to get the complete set of instructions. By having only a pointer to the complete set of instructions, a user of the system may change those instructions at a later date without affecting the security of the overall system. The instructions may instruct image loader 130 to, for example, stop loading boot image 120, continue loading boot image 120 but notify a user or administrator of the mismatch, notify a user or administrator of the mismatch and await further instructions from the user or administrator, allow the image to load without further action, or take any other action desired by the user or administrator.

[0038] 4, there is shown a schematic block diagram of an exemplary computer system 401 that may be used to implement one or more of the methods, tools and modules described herein and any associated functionality (e.g., using one or more processor circuits or computer processors of a computer), in accordance with an embodiment of the present disclosure. In some embodiments, the major components of computer system 401 may include one or more CPUs 402, a memory subsystem 404, a terminal interface 412, a storage interface 416, an I / O (input / output) device interface 414, and a network interface 418, all of which may be communicatively coupled, directly or indirectly, for inter-component communication via a memory bus 403, an I / O bus 408, and an I / O bus interface unit 410.

[0039] Computer system 401 may include one or more general purpose programmable central processing units (CPUs) 402-1, 402-2, 402-3, and 402-N, collectively referred to herein as CPUs 402. In some embodiments, computer system 401 may include multiple processors, as is typical of larger systems. However, in other embodiments, computer system 401 may instead be a single CPU system. Each CPU 402 may execute instructions stored in memory subsystem 404, and may include one or more levels of on-board cache.

[0040] The system memory 404 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 422 or cache memory 424. The computer system 401 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 426 may include a non-removable, non-volatile magnetic medium, such as a "hard drive." Although not shown, a magnetic disk drive may be included for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), or an optical disk drive may be included for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. Additionally, the memory 404 may include flash memory, such as a flash memory stick drive or flash drive. The memory devices are connectable to the memory bus 403 by one or more data media interfaces. The memory 404 may include at least one program product having a set (e.g., at least one) of program modules configured to implement the functions of various embodiments.

[0041] 4 shows memory bus 403 as a single bus structure providing a direct communication path between CPU 402, memory subsystem 404, and I / O bus interface 410, memory bus 403 may, in some embodiments, include multiple different buses or communication paths that may be arranged in any of a variety of configurations, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Also, while I / O bus interface 410 and I / O bus 408 are shown as single respective units, computer system 401 may, in some embodiments, include multiple I / O bus interface units 410 and / or multiple I / O buses 408. Also, while multiple I / O interface units are shown isolating I / O bus 408 from the various communication paths to the various I / O devices, in other embodiments some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0042] In some embodiments, computer system 401 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients), and in some embodiments, computer system 401 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or any other suitable type of electronic device.

[0043] It should be noted that Figure 4 is intended to illustrate representative major components of an exemplary computer system 401. However, in some embodiments, the individual components may have greater or less complexity than shown in Figure 4, there may be other or additional components than those shown in Figure 4, and the number, type and configuration of such components may vary.

[0044] One or more programs / utilities 428, each having at least one set of program modules 430, may be stored in memory 404. The programs / utilities 428 may include a hypervisor (also called a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or a combination thereof, may include an implementation of a network environment. The programs 428 and / or program modules 430 generally perform the functions or methods of the various embodiments.

[0045] The present invention may be a system, method, or computer program product, or combination thereof, of any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions stored thereon for causing a processor to implement aspects of the present invention.

[0046] A computer readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves with instructions recorded thereon, and any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses through a fiber optic cable), or electrical signals transmitted over wires.

[0047] The computer readable program instructions described herein may be downloaded from a computer readable storage medium into each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0048] The computer readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or procedural programming languages, such as object oriented programming languages, such as Smalltalk®, C++, and the "C" programming language, or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer as a stand-alone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer readable program instructions to carry out aspects of the invention by personalizing the electronic circuitry using state information of the computer readable program instructions.

[0049] Aspects of the present invention are described with reference to flowchart illustrations and / or block diagrams that illustrate methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0050] These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing device to produce a machine such that the instructions, executed by the processor of the computer or other programmable data processing device, form means for implementing the functions / operations specified in the blocks of the flowcharts and / or block diagrams. These computer readable program instructions may be stored in a computer readable storage medium such that the computer readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / operations specified in the blocks of the flowcharts and / or block diagrams, and may instruct a computer, programmable data processing device, or other device, or combination thereof, to function in a particular manner.

[0051] The computer readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device and executed on the computer, other programmable apparatus, or other device to produce a computer-implemented process such that the instructions, which execute on the computer, other programmable apparatus, or other device, implement the functions / acts specified in the flowchart and / or block diagram blocks.

[0052] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur in a different order than that noted in the drawings. For example, two blocks shown in succession may in fact be executed substantially in parallel, depending on the functionality involved, or the blocks may be executed in reverse order, as the case may be. It should also be understood that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or may embody a combination of dedicated hardware and computer instructions.

[0053] The description of various embodiments of the present disclosure is provided for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many changes and modifications will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terms used in this specification are selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A system for providing secure boot image loading, comprising: A microcontroller; a plurality of physically alterable internal components (PMICs) disposed on the microcontroller, each PMIC being alterable only once; an image loader configured to load a boot image from a memory of the microcontroller; a checksum calculator configured to calculate a checksum value of the boot image; a checksum burner configured to modify the plurality of PMICS to create a binary representation of the checksum value of the boot image; Including, the image loader is configured to execute a mismatch response if a checksum value in the plurality of PMICS (hereinafter referred to as a first checksum value) and a checksum value of the boot image when the boot image is loaded (hereinafter referred to as a second checksum value) are not the same; the mismatch response is burned into the plurality of PM ICs; The system.

2. 2. The system of claim 1, wherein the image loader is configured to invoke the checksum calculator to calculate a second checksum value of the boot image each time the boot image is loaded and to compare the second checksum value with the first checksum value in the plurality of PMICs to determine whether the second checksum value and the first checksum value are the same.

3. 3. The system of claim 2, wherein the image loader is configured to continue loading the boot image if the first checksum value and the second checksum value are the same.

4. 4. The system of claim 1, wherein the mismatch response prevents further loading of the boot image.

5. The system of claim 1 , wherein the mismatch response alerts a user to the mismatch.

6. 6. The system of claim 5, wherein the no match response further prevents the loading of the boot image until a response is received from the user.

7. 7. The system of claim 1, wherein the mismatched responses burned into the plurality of PMICS are partial responses.

8. The system of claim 7 , wherein the partial response is a pointer to an address where a complete no-match response is stored.

9. 1. A method for securing a boot image load, comprising: loading the boot image from a microcontroller, the microcontroller having a plurality of physically alterable internal components (PMICs) disposed thereon, each PMIC being alterable only once; calculating a checksum value of the loaded boot image; writing said calculated checksum value to a microcontroller; Burning the written checksum value into the PMIC of the microcontroller; burning into the PMIC of the microcontroller a response to a mismatch when comparing a checksum value of the boot image when the boot image is loaded with a checksum value burned into the PMIC of the microcontroller; The method comprising:

10. 10. The method of claim 9, wherein the calculated checksum values ​​are burned into the plurality of PMICS as a binary representation of the checksum values.

11. The method of claim 10, further comprising: continuing to load the boot image in response to a match upon said comparison; executing a mismatch response in response to a mismatch upon said comparing; The method of claim 9 or 10, further comprising:

12. The method of claim 11 , wherein the non-match response is permanently burned into the microcontroller.

13. The method of claim 11 or 12, wherein the mismatch response stops further loading of the boot image.

14. The method of claim 11 , wherein the mismatch response alerts a user to the mismatch.

15. 15. The method of claim 14, wherein the no match response further stops further loading of the boot image until a response is received from the user.

16. 16. The method of claim 11, wherein the no-match response is a partial response as a pointer to an address where the complete no-match response is stored.

17. 1. A computer program for securing a boot image load, comprising: A computer program product for causing a processing circuit to carry out a method according to any one of claims 9 to 16.

18. A storage medium storing the computer program according to claim 17.

19. 20. A system configured to execute the computer program of claim 18.

Images