US20080052530A1 - System and method to provide CPU smoothing of cryptographic function timings - Google Patents

Abstract

A system and method to smooth a cryptographic function's timing footprint is presented. A processor includes a “function timing smoother” that smoothes out spikes in the amount of time that a particular cryptographic function requires to execute. When a cryptographic function executes, the function timing smoother tracks the amount of time that the cryptographic function executes (current execution time) and compares the time with the amount of time that the same cryptographic function took for a previous execution (previous execution time). When the current execution time is less than the previous execution time, the function timing smoother adds instructions or varies an execution unit's clock speed in order to increase the cryptographic function's current execution time. Using this approach, a malicious user is not able to decipher sensitive information from the cryptographic function's timing footprint.

Description

BACKGROUND OF THE INVENTION
• 1. Technical Field
• The present invention relates to a system and method to provide CPU smoothing of cryptographic function timings. More particularly, the present invention relates to a system and method to smooth a cryptographic function's “timing footprint” by injecting instructions and/or adjusting clock speed in order to prevent malicious attacks.
• 2. Description of the Related Art
• Computer users have used techniques for protecting computer data from malicious attackers for many years. Before the Internet, a user was most concerned with a malicious attacker obtaining computer data by locating an unattended computer, and using the computer's keyboard or pointing device to retrieve data from its hard drive. In order to combat this threat, login password protection mechanisms were installed that required a user to enter a password in order to gain access to the computer. This approach prevented a malicious attacker from simply entering an area and retrieving data from the unattended computer.
• The Internet has changed the entire data security landscape because a malicious attacker no longer needs to be present at the same location as the targeted computer. Rather, the malicious attacker may be in a different country than the target computer and extract the data through an Internet connection. Especially with the onset of e-commerce, a malicious attacker has much to gain by breaking into a user's computer. In turn, data protection mechanisms were put in place to prevent such attacks. However, malicious attack technology has become more sophisticated. Although high-speed Internet connections are a benefit to a user, the high-speed Internet connections also provide a mechanism for a malicious attacker to quickly break into a user's computer.
• Therefore, as malicious attack technology becomes more sophisticated, attack prevention technology becomes more sophisticated. The Advanced Encryption Standard (AES) is the next generation standard for private key cryptography. AES scrambles a 16-byte input “n” using a 16-byte key “k” and two constant 256-byte tables. AES inserts n, k, and the 256 byte tables in various forms into arrays with array indexes in order to perform the encryption. A challenge found, however, is that it is extremely difficult to write constant-time high-speed AES software for use with a general-purpose processor. In particular, the underlying challenge is that it is extremely difficult to load an array entry in time that does not depend on the array entry's index.
• It has been shown that the amount of time that an AES variable-index array lookup consumes, which is performed at the beginning of the AES computation, is dependent upon on the array index. Furthermore, the amount of time that is consumed for the entire AES computation is well correlated to the time for this array lookup. Consequently, these AES timing values “leak” information about the input “n” and the key “k.” Therefore, a malicious attacker is able to deduce a key from the distribution of AES timings as a function of n. In short, a malicious attacker may monitor the amount of time that a processor requires to perform a cryptographic function, and deduce an encryption key and the data from the timing footprint.
• What is needed, therefore, is a system and method to mask the amount of time that a processor requires to perform a cryptographic function in order to prevent malicious attacks.
SUMMARY
• It has been discovered that the aforementioned challenges are resolved using a system and method to smooth a cryptographic function's timing footprint by injecting instructions and/or adjusting clock speed during the function's execution. A processor includes a “function timing smoother” that smoothes out spikes in the amount of time that a particular cryptographic function requires to execute. When a cryptographic function executes, the function timing smoother tracks the amount of time that the cryptographic function executes (current execution time) and compares the time with the amount of time that the same cryptographic function took during a previous execution (previous execution time). When the current execution time is less than the previous execution time, the function timing smoother adds instructions or varies an execution unit's clock speed in order to increase the cryptographic function's current execution time. Using this approach, a malicious attacker is not able to deduce sensitive information from the cryptographic function's timing footprint.
• A developer develops application code and compiles the application code, which produces executable code and a symbol file. The developer modifies the symbol file and identifies cryptographic functions that are used in the executable code. In turn, the developer deploys the executable code and the modified symbol file (function identifier file) to a user. In one embodiment, a new keyword may be added to a programming language, such as “CryptographicFunction,” which the developer may use to identify cryptographic functions by adding the keyword as a qualifier to the function.
• In yet another embodiment, in the case of compiled byte code such as Java, the byte code includes symbol information. In this embodiment, a Java Virtual Machine (JVM) is positioned between the byte code and the processor, which performs further compilations from the Java byte code into the native operating system machine code that a processor executes. In this embodiment, the JVM retrieves the cryptographic function identification information included in the byte code and passes the information to the processor during the JVM's byte code compilation.
• When a user receives the deployed code, the user loads the executable file and the function identifier file into a storage area. The user's computer includes a processor that includes an issue unit, an execution unit, and a function timing smoother. When the issue unit issues an instruction, the function timing smoother looks up the instruction (function) in the function identifier file to determine whether the instruction is a cryptographic function. When the instruction is a cryptographic function, the function timing smoother tracks and calculates the cryptographic function's “current execution time.” In addition, the function timing smoother retrieves a “previous execution time” from a timing storage area, which corresponds to the amount of time that the cryptographic function required during a previous execution.
• When the current execution time is less than the previous execution time, the function timing smoother configures a multiplexer and provides filler instructions (e.g. NOP equivalent instructions) to the execution unit, adding to the cryptographic function's current execution time, until the current execution time equals the previous execution time. By using the multiplexer and injecting instructions directly into the execution unit, the processor does not modify the executable code's code space or a code pointer corresponding to the executable code. The function timing smoother then stores the current execution time in the timing storage area, which becomes the “previous execution time” the next time the same cryptographic function executes.
• In one embodiment, the function timing smoother adjusts the clock timing to the execution unit in order to increase a cryptographic function's current execution time. In this embodiment, the function timing smoother configures a clock multiplexer and provides a slower clock in order to prolong the amount of time that the cryptographic function takes to execute.
• In another embodiment, instruction injections may be core independent. For example, on a device that includes four cores, each individual core independently smoothes the timings of their respective cryptographic functions. Consequently, the function timings may be smoothed to specific values on one core that are not the same smoothing values as the other cores.
• The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.
BRIEF DESCRIPTION OF THE DRAWINGS
• The present invention may be better understood, and its numerous objects, features, and advantages made apparent to those skilled in the art by referencing the accompanying drawings.
• FIG. 1 is a diagram showing a function timing smoother that injects instructions and adjusts clock speed in order to smooth a cryptographic function's timing footprint;
• FIG. 2A is a diagram showing cryptographic function time durations without the invention described herein;
• FIG. 2B is a diagram showing a smoothed execution time footprint using the invention described herein;
• FIG. 3 is a flowchart showing steps taken in a developer developing application code and identifying cryptographic functions included in the application code;
• FIG. 4 is a flowchart showing steps taken in a function timing smoother identifying cryptographic functions and “smoothing” their respective timing durations;
• FIG. 5 is a flowchart showing steps taken in a function timing smoother injecting No Operation (NOP) instructions as well as random instructions in order to smooth cryptographic function timings;
• FIG. 6 is a flowchart showing steps taken in a function timing smoother injecting NOP instructions and adjusting clock speed in order to smooth cryptographic function timings;
• FIG. 7 is a flowchart showing steps taken in a function timing smoother injecting NOP instructions in order to smooth a cryptographic function's timing footprint; and
• FIG. 8 is a block diagram of a computing device capable of implementing the present invention.
DETAILED DESCRIPTION
• The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention, which is defined in the claims following the description.
• FIG. 1 is a diagram showing a function timing smoother that injects instructions and adjusts clock speed in order to smooth a cryptographic function's timing footprint.Developer100 develops and compiles code, which produces an executable file (executable code119) and a “symbol” file. The developer modifies the symbol file to indicate the cryptographic function's (function identifier file117) that are used inexecutable code119. The developer deploys (deployment103)executable code119 andfunction identifier file117 to a user, which the user stores in code store115 (seeFIG. 3 and corresponding text for further details regarding development and deployment).Code store105 may be stored on a nonvolatile storage area, such as a computer hard drive.
• Once deployed to the user, the user'sprocessor100 loadsexecutable code119 intoexecutable store170 for execution, and loadsfunction identifier file117 intofunction names store180. Function names store180 andexecutable store170 may be stored on a volatile storage area, such as computer memory. As one skilled in the art can appreciate, the invention described herein may be applied to smooth other function timing footprints besides cryptographic functions.
• Core110 includesissue unit130,execution unit160, and function timing smoother120.Issue unit130 may include multiple units (e.g., fetch unit, decode unit, etc.) that retrieve instructions fromexecutable store170 and stage the instructions forexecution unit160.Execution unit160 may include multiple units to execute instructions, such as an adder, a multiplier, etc.
• Function timing smoother120 monitorsexecutable code170 execution, and when a cryptographic function executes, function timing smoother120 tracks the amount of time that the cryptographic function executes, such as 10 ms. The purpose of function timing smoother120 is to smooth out spikes in the amount of time that a particular cryptographic function requires to execute (seeFIGS. 2A and 2B for further details). In order to accomplish this task, function timing smoother120 compares a cryptographic function's “current execution time” with a “previous execution time,” and adds instructions or variesexecution unit160's clock speed if the current execution time is less than the previous execution time. Using this approach, a malicious user is not able to decipher sensitive information, such as an encryption key.
• Whenissue unit130 issues an instruction, function timing smoother120 looks up the instruction (function) in function names store180 to determine whether the instruction is a cryptographic instruction. When the instruction is a cryptographic instruction, function timing smoother120 tracks and calculates the cryptographic function's current execution time. In turn, function timing smoother120 retrieves a previous execution time fromtiming store190, which corresponds to the amount of time that the cryptographic function required during a previous execution.Timing store190 may be stored on a volatile storage area, such as computer memory.
• If the “current execution time” is less than the “previous execution time,” function timing smoother120 configuresmultiplexer140 and provides filler instructions125 (e.g. NOP equivalent instructions) toexecution unit160, which adds to the cryptographic function's current execution time, until the current execution time equals the previous execution time. By usingmultiplexer140, processing does not modifyexecutable code119's code space or a code pointer corresponding toexecutable code119. Function timing smoother120 then stores the current execution time intiming store190, which becomes the “previous execution time” the next time the same cryptographic function executes.
• In one embodiment, function timing smoother120 adjusts the clock timing toexecution unit160 in order to increase a cryptographic function's current execution time. In this embodiment, function timing smoother120 configuresclock multiplexer150 and provides a slower clock in order to prolong the amount of time that the cryptographic function takes to execute (seeFIG. 6 and corresponding text for further details).
• In another embodiment, instruction injections may be core independent. For example, on a device that includes four cores, each individual core independently smoothes the timings of their respective cryptographic functions. Consequently, the timings may be smoothed to a specific maximum on one core that is not the same smoothing timing as another core.
• FIG. 2A is a diagram showing cryptographic function time durations without the invention described herein.Graph200 shows that as a particular cryptographic function executes over a number of occurrences, the cryptographic function varies in the amount it takes to execute, which creates “footprint”210 that a malicious user may use to decipher sensitive information as discussed in the background section.
• FIG. 2B is a diagram showing a smoothed execution time footprint using the invention described herein.Graph220 includesfootprint230 that exhibit a cryptographic function's execution times being smoothed by adding instructions and/or varying the clock speed of an execution unit. As such, a malicious client is not able to decipher sensitive information fromfootprint230, such as a cryptographic key.
• FIG. 3 is a flowchart showing steps taken in a developer developing application code and identifying cryptographic functions included in the application code. Development processing commences at300, whereupon a developer develops application program code atstep310. The developer may use a traditional programming language (C++), an object-based programming language (Java), or a model-based programming language (EMF).
• Based upon the type of programming language that the developer uses, the developer compiles the code atstep320 and storesexecutable code119 indeployment store330.Executable code119 is the same as that shown inFIG. 1. Atstep340, the developer modifiessymbol file325 and identifies the functions that are cryptographic functions, such as by turning on a new flag that is added to the symbol file that identifies cryptographic functions. Processing stores the modified symbol file, which becomesfunction identifier file117, indeployment store330 atstep350.Function identifier file117 is the same as that shown inFIG. 1. Processing ends at360.
• In one embodiment, a new keyword may be added to a programming language (i.e. Java, C++, C, Pascal, etc.), such as “CryptographicFunction,” which may be used by the developer to identify cryptographic functions by adding the keyword as a qualifier to the function (i.e. either by prefixing the function or using the keyword as a specific “type,” which is applied to the function). In this embodiment, when the application compiles, the compiler automatically generates the symbol file and identifies the cryptographic functions by the “CryptographicFunction” keyword. In this embodiment, when a processor loads the executable code, it also reads the symbol file and detects the functions that are identified as cryptographic functions.
• In another embodiment, a developer adds a new keyword to the programming language. The difference between this embodiment and the previous embodiment is that instead of the compiler producing a separate symbol file, the cryptographic function identification is incorporated into the executable file itself. This eliminates the need for a separate symbol file. In this embodiment, when the processor loads the executable code, it detects that the compiler added a qualifier to the functions that are identified as cryptographic functions and implements the smoothing to those functions.
• In yet another embodiment, in the case of compiled byte code, such as Java, the byte code includes symbol information. In this embodiment, a Java Virtual Machine (JVM) is positioned between the byte code and the processor, which performs further compilations from the Java byte code into the native OS machine code that a processor executes. In this embodiment, the JVM retrieves the cryptographic function identification information included in the byte code and passes the information to the processor during the JVM's byte code compilation.
• FIG. 4 is a flowchart showing steps taken in a function timing smoother identifying cryptographic functions and “smoothing” their respective timing durations. Processing commences at400, whereupon processing retrieves cryptographic function names from function names store180 atstep410. A program developer previously identified the cryptographic functions during application development, and provided the cryptographic names when deploying the application. In turn, the function names are loaded into function names store180 when a processor loads the corresponding application in executable store170 (seeFIG. 3 and corresponding text for further details). Function names store180 andexecutable store170 are the same as that shown inFIG. 1. As one skilled in the art can appreciate, the invention described herein may be applied to smooth function execution times other than just cryptographic functions.
• Atstep415, processing monitors the function execution for instructions included inexecutable store170. A determination is made as to whether a cryptographic function is ready to execute by comparing the functions that are ready to issue with the identified functions in function names store180 (decision420). If a cryptographic function is not executing,decision420 branches to “No”branch422, which loops back to continue to monitor the application code. This looping continues until a cryptographic function is ready to execute, at whichpoint decision420 branches to “Yes”branch428.
• Atstep430, processing retrieves an execution start time that corresponds to a time at which the cryptographic function begins to execute. A determination is made as to whether the executable is returned to the caller (e.g. the cryptographic function is complete) (decision440). If the executable has not returned to the caller,decision440 branches to “No”branch442 which loops back to continue to monitor the cryptographic function progress. This looping continues until the executable is returned to the caller, at whichpoint decision440 branches to “Yes”branch448.
• Atstep450, processing checks whether a “previous execution time” exists intiming store190 that corresponds to the same cryptographic function. The previous execution time is the cryptographic function's execution time during its previous execution. For example, function “encodeword” may have previously taken 10 ms to execute.
• A determination is made as to whether the cryptographic function has previously executed by checking whether a corresponding previous execution time exists (decision460). If a previous execution time does not exist,decision460 branches to “No”branch462, which loops back to compute a “current execution time” and store the current execution time intiming store190 atstep465. The current execution time is computed by subtracting the cryptographic function's ending time from its starting time. In turn, processing loops back to continue to monitor code execution. This looping continues until the second pass of the same cryptographic function, at whichpoint decision460 branches to “Yes”branch468 whereupon processing injects No Operation (NOP) equivalent instructions into the execution pipeline if required in order to increase the amount of execution time to complete the current cryptographic function, which smoothes out the cryptographic function's timing footprint (pre-defined process block470, seeFIG. 7 and corresponding text for further details).
• A determination is made as to whether to continue processing (decision480). If processing should continue,decision480 branches to “Yes”branch482 whereupon processing loops back to monitor code execution. This looping continues until processing should terminate, at whichpoint decision480 branches to “No”branch488 whereupon processing ends at490.
• FIG. 5 is a flowchart showing steps taken in a function timing smoother injecting No Operation (NOP) equivalent instructions as well as random instructions in order to smooth cryptographic function timings.FIG. 5 is similar toFIG. 4 with the exception thatFIG. 5 includes steps to randomly insert filler instructions (e.g., NOP equivalent instructions) while a cryptographic function executes in order to increase the amount of execution time required to complete the function.
• Processing commences at500, whereupon steps510 through530 are the same assteps410 through430 shown inFIG. 4, respectively. Once processing identifies a cryptographic function executing and retrieves a start time, a determination is made as to whether the executable is returned to the caller (e.g. the cryptographic function has ended) (decision540). If the executable has not returned to the caller,decision540 branches to “No”branch442 whereupon processing continues to allow the instruction to execute (step545) and a determination is made as to whether to “pepper inject” filler instructions (decision550). Meaning, instructions are randomly injected into an execution unit in order to increase a cryptographic function's current execution time at a more secure level.
• If processing should not perform pepper injections,decision550 branches to “No”branch552 which loops back to monitor function execution. On the other hand, if processing should perform pepper injections,decision550 branches to “Yes”branch558 whereupon processing computes an in-process execution time atstep560 based upon the cryptographic function's start time and current time. At step565, processing computes a mean function execution time based upon previous execution times (located in timing store190), and calculates the number of instructions to inject based upon the mean function execution time. For example, the mean function execution time may be 12 ms and the in-process execution time is 7 ms. In this example, processing calculates that 5 ms worth of filler NOP instructions should be injected. Processing, atstep570, usesmultiplexer140 to inject instructions intoexecution160.Multiplexer140 andexecution unit160 are the same as that shown inFIG. 1.
• When the cryptographic function ends,decision540 branches to “Yes”branch548 whereupon, atstep575, processing retrieves a previous execution time fromtiming store190 that corresponds to the same cryptographic function. The previous execution time is the amount of time that the cryptographic function required the last time that it executed. For example, function “encodeword” may have taken 10 ms to execute the last time that the function executed.
• A determination is made as to whether the cryptographic function has previously executed by checking whether a corresponding previous execution time exists (decision580). If a previous execution time does not exist,decision580 branches to “No”branch582, which loops back to compute a current execution time and store the execution time intiming store190 atstep585. The current execution time is computed by subtracting the cryptographic function's ending time from its starting time. In turn, processing loops back to continue to monitor code execution. This looping continues until a previous execution time exists (a cryptographic function's second time executing), at whichpoint decision580 branches to “Yes”branch588 whereupon processing injects No Operation (NOP) equivalent instructions into the execution pipeline if required in order to increase the amount of execution time to complete the current cryptographic function (pre-defined process block590, seeFIG. 7 and corresponding text for further details).
• A determination is made as to whether to continue processing (decision595). If processing should continue,decision595 branches to “Yes”branch596 whereupon processing loops back to monitor code execution. This looping continues until processing should terminate, at whichpoint decision595 branches to “No”branch598 whereupon processing ends at599.
• FIG. 6 is a flowchart showing steps taken in a function timing smoother injecting NOP equivalent instructions and adjusting clock speed in order to smooth cryptographic function timings.FIG. 6 is similar toFIGS. 4 and 5 with the exception thatFIG. 6 includes steps to adjust an execution unit's clock timing while a cryptographic function executes in order to increase the amount of execution time required to complete the function.
• Processing commences at600, whereupon steps610 through630 are the same assteps410 through430 shown inFIG. 4, respectively. Once processing identifies a cryptographic function executing and retrieves a start time, a determination is made as to whether the executable is returned to the caller (e.g. the cryptographic function has ended) (decision640). If the executable has not returned to the caller,decision640 branches to “No”branch642 whereupon processing continues to allow the instruction to execute (step645) and a determination is made as to whether to vary an execution unit's timing (decision650).
• If processing should not vary the execution unit's timing,decision650 branches to “No”branch652 which loops back to monitor instruction execution. On the other hand, if processing should vary the execution unit's timing,decision650 branches to “Yes”branch658 whereupon processing computes an in-process execution time atstep660. At step665, processing adjustsexecution unit160's timing usingclock multiplexer155 based upon the cryptographic function's mean function execution time (seeFIG. 5 and corresponding text for further details). In one embodiment, in addition to varying the clock speed, processing may also “pepper inject” instructions (discussed inFIG. 5) in order to add another level of security.Clock multiplexer155 andexecution unit160 are the same as that shown inFIG. 1.
• When the cryptographic function ends,decision640 branches to “Yes”branch648 whereupon, atstep670, processing resetsexecution unit160's clock timing. Atstep675, processing retrieves a previous execution time fromtiming store190 that corresponds to the same cryptographic function. The previous execution time is the amount of time that the cryptographic function required the last time that it executed. For example, function “encodeword” may have taken 10 ms to execute the last time that the function executed.
• A determination is made as to whether the cryptographic function has previously executed by checking whether a corresponding previous execution time exists (decision680). If a previous execution time does not exist,decision680 branches to “No”branch682, which loops back to compute a current execution time and store the execution time intiming store190 at step686. The current execution time is computed by subtracting the cryptographic function's ending time from its starting time. In turn, processing loops back to continue to monitor code execution. This looping continues until the cryptographic function's second execution, at whichpoint decision680 branches to “Yes”branch688 whereupon processing injects No Operation (NOP) equivalent instructions into the execution pipeline, which increases the amount of execution time to complete the current cryptographic function (pre-defined process block690, seeFIG. 7 and corresponding text for further details).
• A determination is made as to whether to continue processing (decision695). If processing should continue,decision695 branches to “Yes”branch696 whereupon processing loops back to monitor code execution. This looping continues until processing should terminate, at whichpoint decision695 branches to “No”branch698 whereupon processing ends at699.
• FIG. 7 is a flowchart showing steps taken in a function timing smoother injecting NOP equivalent instructions in order to smooth a cryptographic function's timing footprint. Processing commences at700, whereupon processing computes a current execution time (step710). The current execution time is the amount of time that the current cryptographic function required to exedute, such as 10 ms.
• A determination is made as to whether the current execution time is less than a previous execution time, which was retrieved inFIG. 4,5, or6 (decision720). The previous execution time is the amount of time that the same cryptographic function took to execute the last time that it executed. For example, if the previous execution time was 9 ms and the current execution time is 10 ms, the current execution time is not less than the previous execution time. If the current execution time is not less than the previous execution time,decision720 branches to “No”branch722, bypassing NOP injection steps.
• On the other hand, if the current execution time is less than the previous execution time,decision720 branches to “Yes”branch728 whereupon processing calculates the number of NOP's to inject to execution unit in order to increase the cryptographic function's current execution time (step730). For example, if the current execution time is 12 ms and the previous execution time is 15 ms, processing calculates the number of NOP equivalent instructions required to consume 3 ms (15 ms−12 ms).
• Atstep740, processing configuresmultiplexer140 to receive NOP equivalent instructions and provide them toexecution unit160. By usingmultiplexer140, processing does not modify the code space or a code pointer for the cryptographic function's application code.
• Processing, atstep750, records the current execution time intiming store190, which, if NOP's were injected, includes the function's execution time and the amount of time for the injected NOP's. This stored timing is used as the “previous execution time” the next time the cryptographic function executes. Processing returns at760.
• FIG. 8 illustratesinformation handling system801 which is a simplified example of a computer system capable of performing the computing operations described herein.Computer system801 includesprocessor800 which is coupled tohost bus802. A level two (L2)cache memory804 is also coupled tohost bus802. Host-to-PCI bridge806 is coupled tomain memory808, includes cache memory and main memory control functions, and provides bus control to handle transfers amongPCI bus810,processor800,L2 cache804,main memory808, andhost bus802.Main memory808 is coupled to Host-to-PCI bridge806 as well ashost bus802. Devices used solely by host processor(s)800, such asLAN card830, are coupled toPCI bus810. Service Processor Interface and ISA Access Pass-through812 provides an interface betweenPCI bus810 andPCI bus814. In this manner,PCI bus814 is insulated fromPCI bus810. Devices, such asflash memory818, are coupled toPCI bus814. In one implementation,flash memory818 includes BIOS code that incorporates the necessary processor executable code for a variety of low-level system functions and system boot functions.
• PCI bus814 provides an interface for a variety of devices that are shared by host processor(s)800 andService Processor816 including, for example,flash memory818. PCI-to-ISA bridge836 provides bus control to handle transfers betweenPCI bus814 andISA bus840, universal serial bus (USB) functionality846, power management functionality866, and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support.Nonvolatile RAM820 is attached toISA Bus840.Service Processor816 includes JTAG and I2C busses822 for communication with processor(s)800 during initialization steps. JTAG/I2C busses822 are also coupled toL2 cache804, Host-to-PCI bridge806, andmain memory808 providing a communications path between the processor, the Service Processor, the L2 cache, the Host-to-PCI bridge, and the main memory.Service Processor816 also has access to system power resources for powering downinformation handling device801.
• Peripheral devices and input/output (I/O) devices can be attached to various interfaces (e.g.,parallel interface862,serial interface864,keyboard interface868, andmouse interface870 coupled toISA bus840. Alternatively, many I/O devices can be accommodated by a super I/O controller (not shown) attached toISA bus840.
• In order to attachcomputer system801 to another computer system to copy files over a network,LAN card830 is coupled toPCI bus810. Similarly, to connectcomputer system801 to an ISP to connect to the Internet using a telephone line connection, modem886 is connected toserial port864 and PCI-to-ISA Bridge836.
• WhileFIG. 8 shows one information handling system that employs processor(s)800, the information handling system may take many forms. For example,information handling system801 may take the form of a desktop, server, portable, laptop, notebook, or other form factor computer or data processing system.Information handling system801 may also take other form factors such as a personal digital assistant (PDA), a gaming device, ATM machine, a portable telephone device, a communication device or other devices that include a processor and memory.
• One of the preferred implementations of the invention is a client application, namely, a set of instructions (program code) in a code module that may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.
• While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, that changes and modifications may be made without departing from this invention and its broader aspects. Therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.

Claims (20)

1. A computer-implemented method comprising:

executing a function included in a program;

in response to the execution, computing a current execution time that corresponds to the amount of time that the function requires to execute;

retrieving a previous execution time, the previous execution time corresponding to the amount of time that the function required during a previous execution;

determining that the current execution time is less than the previous execution time; and

in response to the determination, injecting one or more filler instructions that do not correspond to the program, wherein the injecting increases the current execution time until the current execution time is equal to the previous execution time.

2. The method ofclaim 1 further comprising:

wherein code space corresponding to the program is not modified during the injecting; and

wherein a code pointer corresponding to the program is not modified during the injecting.

3. The method ofclaim 1 further comprising:

computing a mean function execution time using the previous execution time and one or more other previous execution times; and

adjusting a clock speed while the function is executing based upon the mean execution time, wherein the adjusting results in the current execution time being equal to or greater than the previous execution time.

4. The method ofclaim 1 further comprising:

computing a mean function execution time using the previous execution time and one or more other previous execution times;

injecting the filler instructions while the function is executing based upon the mean execution time.

5. The method ofclaim 1 wherein the method is performed in response to determining that the function is a cryptographic function.

6. The method ofclaim 1 further comprising:

developing the program and generating a function identifier file that identifies one or more cryptographic functions included in the program;

detecting, based upon the function identifier file, that the function is the cryptographic function; and

performing, in response to the detecting, the computing, the retrieving, the determining, and the injecting.

7. The method ofclaim 1 wherein the method is performed during advanced encryption standard processing.

8. A computer program product stored on a computer operable media, the computer operable media containing instructions for execution by a computer, which, when executed by the computer, cause the computer to implement a method for smoothing cryptographic function timing footprints, the method comprising:

executing a function included in a program;

in response to the execution, computing a current execution time that corresponds to the amount of time that the function requires to execute;

retrieving a previous execution time, the previous execution time corresponding to the amount of time that the function required during a previous execution;

determining that the current execution time is less than the previous execution time; and

in response to the determination, injecting one or more filler instructions that do not correspond to the program, wherein the injecting increases the current execution time until the current execution time is equal to the previous execution time.

9. The computer program product ofclaim 8 wherein code space corresponding to the program is not modified during the injecting; and

wherein a code pointer corresponding to the program is not modified during the injecting.

10. The computer program product ofclaim 8 wherein the method further comprises:

computing a mean function execution time using the previous execution time and one or more other previous execution times; and

adjusting a clock speed while the function is executing based upon the mean execution time, wherein the adjusting results in the current execution time being equal to or greater than the previous execution time.

11. The computer program product ofclaim 8 wherein the method further comprises:

computing a mean function execution time using the previous execution time and one or more other previous execution times;

injecting the filler instructions while the function is executing based upon the mean execution time.

12. The computer program product ofclaim 8 wherein the method is performed in response to determining that the function is a cryptographic function.

13. The computer program product ofclaim 8 wherein the method further comprises:

developing the program and generating a function identifier file that identifies one or more cryptographic functions included in the program;

detecting, based upon the function identifier file, that the function is the cryptographic function; and

performing, in response to the detecting, the computing, the retrieving, the determining, and the injecting.

14. The computer program product ofclaim 8 wherein the method is performed during advanced encryption standard processing.

15. An information handling system comprising:

one or more processors;

a memory accessible by the processors;

one or more nonvolatile storage devices accessible by the processors; and

a timing footprint smoothing tool for smoothing a cryptographic function's timing footprint, the timing footprint smoothing tool being effective to:

execute a function included in a program that is retrieved from one of the nonvolatile storage devices;

in response to the execution, compute a current execution time that corresponds to the amount of time that the function requires to execute;

retrieve a previous execution time from the memory, the previous execution time corresponding to the amount of time that the function required during a previous execution;

determine that the current execution time is less than the previous execution time; and

in response to the determination, inject one or more filler instructions that do not correspond to the program, wherein the injecting increases the current execution time until the current execution time is equal to the previous execution time.

16. The information handling system ofclaim 15 wherein code space corresponding to the program is not modified during the injecting; and

wherein a code pointer corresponding to the program is not modified during the injecting.

17. The information handling system ofclaim 15 wherein the timing footprint smoothing tool is further effective to:

compute a mean function execution time using the previous execution time and one or more other previous execution times; and

adjust a clock speed while the function is executing based upon the mean execution time, wherein the adjusting results in the current execution time being equal to or greater than the previous execution time.

18. The information handling system ofclaim 15 wherein the timing footprint smoothing tool is further effective to:

compute a mean function execution time using the previous execution time and one or more other previous execution times;

inject the filler instructions while the function is executing based upon the mean execution time.

19. The information handling system ofclaim 15 wherein timing footprint smoothing tool is further effective to determine that the function is a cryptographic function.

20. The information handling system ofclaim 15 wherein the timing footprint smoothing tool is further effective to:

develop the program and generating a function identifier file that identifies one or more cryptographic functions included in the program;

detect, based upon the function identifier file, that the function is the cryptographic function; and

perform, in response to the detecting, the computing, the retrieving, the determining, and the injecting.

Images