Asynchronous code execution for improved performance and security measures to protect digital security devices

Abstract

Performance is improved while protecting the computerized digital security device against side channel attacks, fault injection attacks, and timing attacks, the method including executing a first application including identifying asynchronous tasks to be executed by the computerized digital security device by placing the identified asynchronous tasks in an asynchronous task queue, and non-linearizing execution of the application by selecting at least one task from the asynchronous task queue, executing the selected at least one task, and removing the selected at least one task from the asynchronous task queue.

Description

[Technical field]

[0001] The present invention relates generally to digital security devices, and more particularly to measures for protecting digital security devices against side channel, fault injection, and timing attacks. [Background technology]

[0002] Electronic communication and commerce can be a powerful, yet dangerous tool. With the widespread availability of network technologies, such as the Internet, there is an ever-increasing use of online tools for communication and commerce. Each year, more users find it easier or faster to conduct important transactions using computers and computer networks, regardless of the form of communication or commerce.

[0003] Furthermore, digital technologies play an ever-increasing role in identity management, e.g., digital identities and passports.

[0004] Such digital security technologies may involve any of a wide variety of software and hardware techniques, such as encryption, antivirus software, and biometrics. These digital security technologies may be deployed in many types of digital security devices, such as smart cards, USB tokens with embedded smart cards, Subscriber Identity Modules (SIMs) embedded or built into mobile devices, Internet of Things (IoT) devices. Indeed, any computerized device entrusted with protecting secrets, such as private communications, encryption keys, account numbers, health information, may be viewed as a digital security device. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] Mark Randolph and William Diehl, Power Side-Channel Attack Analysis: A Review of 20 Years of Study for the Layman,Cryptography 2020,4,15;doi:10.3390 / cryptography4020015 Summary of the Invention [Problem to be solved by the invention]

[0006] However, there is always a risk that the security of the operations performed by the digital security device may be compromised through eavesdropping by third parties who have no right to participate in the transaction. When a malicious third party gains access to otherwise private transactions and data, there is financial loss, loss of privacy, and even loss of physical safety.

[0007] As an example, consider encryption, one mechanism used to avoid intrusions into electronic transactions and data privacy. Traditionally, both the sender and the recipient of an encrypted message were considered secure. The primary use of encryption was to send an encoded message from the sender to the recipient without fear that an intermediary could decode the message. If an attacker does not have access to the encryption device of the sender or the recipient, the attacker is limited to using the encoded message itself, or possibly the encoded message and the corresponding plaintext message, to determine the encryption key used to encode or decode the message. However, if the attacker has access to the encryption device, the situation changes dramatically, since the attacker can then also analyze artifacts, so-called side channel data, power consumption, etc., to infer the data that was manipulated by the encryption device.

[0008] One mechanism for ensuring that a private key is indeed kept private is to store the private key and associated key material on a secure portable device, such as a smart card or mobile device. A smart card is a small, tamper-resistant computer, often in a package the size and shape of a credit card. Smart cards can be used to store cryptographic keys and cryptographic engines for performing encryption, decryption, and digital signing.

[0009] In one example, a user may receive an encrypted message and use the user's smart card to decrypt the message by first authenticating the smart card and then passing the message to the smart card for decryption. If authentication is successful, the smart card may decrypt the message using an encryption key stored on the card and a corresponding encryption engine and provide the decrypted message to the user. Similarly, if a user wishes to cryptographically sign a message, the user may pass the message to the user's smart card, which will digitally sign the message using the user's encryption key and return the signature to the user, or a third party recipient.

[0010] Although cryptographic mechanisms are extremely difficult, if not impossible, to break from an algorithmic point of view, the implementation of the cryptographic mechanisms on the electronics of a digital security device may be much less secure than algorithmic analysis would suggest. If an attacker has access to a smart card, he may make repeated observations of, for example, the power consumption or electromagnetic emissions during the execution of a cryptographic algorithm and may use such auxiliary information in an attempt to determine secrets stored on the smart card, in particular private cryptographic keys stored on the smart card. One such attack is the so-called side-channel attack.

[0011] Side-channel attacks exploit the program timing, power consumption, and / or electronic emission of a device performing cryptographic computations. The behavior of the device (timing, power consumption, and electronic emission) changes and depends directly on the program and data that is manipulated in the cryptographic algorithms. An attacker can use these changes to infer sensitive data, leading to the recovery of the private key.

[0012] In parallel with the development of side-channel analysis attacks, techniques have been developed to protect against attempts to recover keys or other sensitive information from side-channel leakage. These techniques are known as countermeasures and include attempts to hide the operation of a cryptographic device from any side-channel data leakage, for example, by masking the data while it is being manipulated by a cryptographic algorithm, by introducing dummy instructions, by changing the order of instructions, or by manipulating the system clock to introduce jitter in any collected side-channel data.

[0013] There are several different types of side-channel attacks, and conversely, several different types of countermeasures. With respect to side-channel attacks based on the electrical activity of a device, Mark Randolph and William Diehl, Power Side-Channel Attack Analysis: A Review of 20 Years of Study for the Layman, Cryptography 2020, 4, 15; doi:10.3390 / cryptography4020015 (incorporated herein by reference) provides a detailed survey of many of the techniques used, as well as a discussion of countermeasures.

[0014] One form of attack is based on the analysis of execution paths through a security algorithm, e.g., a cryptographic algorithm. Essentially, the attacker monitors, for example, the power consumption or execution time through one path relative to the power consumption or execution time of another path of a sensitive routine to determine which path is executed in response to particular input data.

[0015] Another form of attack, fault injection attacks, seek to manipulate the device through its behavior when some fault is induced, for example by introducing out-of-range power supply voltages or clock manipulation. Fault injection can be used to cause, for example, skipping of instructions, incorrect data or instruction fetches, or failure to correctly write data to memory. The success of a fault injection attack depends on the exact timing of the attack, for example, when a branch and compare instruction is targeted to potentially cause the execution of a particular branch.

[0016] One countermeasure defense against side-channel and fault injection attacks is to desynchronize the execution of each path through a routine so that any given path through a portion of code cannot result in the same power consumption or timing signature. Such desynchronization can be done by introducing dummy routines that intentionally slow down a portion of code, thereby desynchronizing the timing of the execution of sensitive routines, to prevent an attacker from performing a fault injection attack at a precise time or location. Introducing dummy routines can also induce unpredictable power usage profiles for the execution of the portion of code, thereby making side-channel analysis attacks more difficult.

[0017] An alternative solution, uniform branch timing, pads the code execution of sensitive routines so that all possible branches through the sensitive portion have uniform execution time, i.e., the execution time is the same regardless of which conditions apply.

[0018] Both execution desynchronization and uniform branch timing suffer from performance degradation due to the execution of counterproductive operations that are intended to cause unpredictable execution timing or uniform execution of all code branches.

[0019] Moreover, desynchronization and padding are typically implemented in simple and predictable ways, e.g., empty loops or loops performing simple operations. Such behavior can be easily detected through side-channel analysis (e.g., simple power analysis or differential power analysis). Thus, the padding code, by itself, can make sensitive routines vulnerable to attack.

[0020] It should be noted that vulnerability to side-channel analysis is not limited to encryption operations: there are many other operations by computers where sensitive information, e.g., passwords, must be protected, and therefore side-channel analysis is also an issue in such scenarios.

[0021] From the above, it is apparent that there is a need for an improved method for protecting sensitive routines executed by digital security devices against side-channel and fault injection attacks through desynchronization and uniform branching execution, without the wasteful execution of useless code that may be vulnerable to side-channel attacks. [Means for solving the problem]

[0022] According to a first aspect, the techniques described herein provide a method for improving performance while protecting a computerized digital security device against side channel, fault injection, and timing attacks. The method includes executing a first application by identifying asynchronous tasks to be executed by the computerized digital security device, placing the identified asynchronous tasks in an asynchronous task queue, selecting at least one task from the asynchronous task queue, executing the selected at least one task, and removing the selected at least one task from the asynchronous task queue to non-linearize execution of the application.

[0023] The method may further include predicting an execution time for each identified asynchronous task, and the step of selecting at least one task from the asynchronous task queue includes basing the selection of the at least one task from the asynchronous task queue on the predicted execution times of the tasks in the asynchronous task queue.

[0024] The method may further include identifying an execution location to add desynchronization time to and determining how much desynchronization time to add. The step of selecting at least one task may then include selecting at least one task such that a sum of predicted execution times of the selected at least one task is shorter than the determined desynchronization time to add, and executing at least one dummy task such that the execution time is equal to a difference between the determined desynchronization time to add and the sum of predicted execution times of the selected at least one task.

[0025] The method may further include shuffling execution of the first application by selecting at least one task from the asynchronous task queue and executing the selected at least one task before continuing execution of the first application.

[0026] The method may further include desynchronizing execution of the first application by selecting at least one task from the asynchronous task queue and modifying an execution flow of the first application by executing the selected task before continuing execution of the first application.

[0027] The method may further include identifying at least first and second code branches, where the execution times for the first and second code branches are unequal, and equalizing the execution times for the first and second code branches by selecting at least one task from the asynchronous task queue such that a predicted execution time of the selected at least one task balances the execution times of both code branches.

[0028] The method may further include randomly selecting a task from the asynchronous task queue.

[0029] The method may include adding tasks to an asynchronous task queue, including tasks selected from tasks required by the first application, tasks required by an operating system of the computerized digital security device, and tasks required by applications other than the first application.

[0030] The tasks added to the asynchronous task queue may include tasks selected from the group of: calculation of very large prime numbers, memory defragmentation, non-volatile memory (NVM) page refresh, NVM erase, NVM write, generation of small buffers of random numbers using hardware true random number generation, security sensor checks, memory integrity verification, code execution flow control, data compression, and data decompression.

[0031] In a second aspect, the technology described herein includes a digital security device having a processor and memory and programmed to execute the above-described method for improving performance while protecting the computerized digital security device against side channel attacks, fault injection attacks, and timing attacks.

[0032] In one embodiment, the instructions for non-linearizing the execution of the first application include instructions to a processor: predicting an execution time for each identified asynchronous task; selecting at least one task from the asynchronous task queue, the selecting at least one task from the asynchronous task queue based on predicted execution times of tasks in the asynchronous task queue; The instruction code may include instructions for causing the

[0033] In one embodiment, the instructions for non-linearizing the execution of the first application include instructions to a processor: identifying an execution location for adding a desynchronization time; determining how much desynchronization time to add; The instructions for selecting the at least one task may include instructions for selecting the at least one task such that a sum of predicted execution times of the selected at least one task is less than the determined desynchronization time to add, and the instructions for non-linearizing the execution of the first application may include instructions for causing the processor to: executing at least one dummy task for an execution time equal to a difference between the desynchronization time determined to be added and the sum of the predicted execution times of the at least one selected task; The instruction code may include instructions for causing the

[0034] In one embodiment, the instructions for non-linearizing execution of the first application may include instructions to cause the processor to shuffle execution of the first application by selecting at least one task from an asynchronous task queue and executing the selected at least one task before continuing execution of the first application.

[0035] In one embodiment, the instructions for non-linearizing execution of the first application may include instructions to cause the processor to desynchronize execution of the first application by modifying the execution flow of the first application by selecting at least one task from an asynchronous task queue and executing the selected task before continuing execution of the first application.

[0036] In one embodiment, the instructions for non-linearizing the execution of the first application include instructions to a processor: identifying at least first and second code branches, wherein execution times for the first and second code branches are unequal; Equalizing execution times for the first and second code branches by selecting at least one task from the asynchronous task queue such that a predicted execution time of the selected at least one task balances the execution times of both code branches. This includes instructions to:

[0037] In one embodiment, the instructions for non-linearizing the execution of the first application include instructions to cause the processor to randomly select a task from the asynchronous task queue.

[0038] In one embodiment, the tasks added to the asynchronous task queue include tasks selected from tasks required by the first application, tasks required by an operating system of the computerized digital security device, and tasks required by applications other than the first application.

[0039] In one embodiment, the tasks added to the asynchronous task queue include tasks selected from the group of: calculation of very large prime numbers, memory defragmentation, non-volatile memory (NVM) page refresh, NVM erase, NVM write, generation of small buffers of random numbers using hardware true random number generation, security sensor checks, memory integrity verification, code execution flow control, data compression, and data decompression.

[0040] In a further aspect, the techniques described herein include a non-transitory computer memory having stored thereon instructions that can cause a processor of a digital security device to execute the above-described methods for improving performance while protecting a computerized digital security device against side channel attacks, fault injection attacks, and timing attacks. [Brief description of the drawings]

[0041] [Figure 1]1 is an illustration of a network in which a user operates a digital security device to perform a number of different sensitive operations, such as encryption operations. [Diagram 2] FIG. 1 is an illustration of a device that can be used to perform side channel analysis and fault injection attacks. [Diagram 3] 1 is a high-level block diagram of an example digital security device. [Figure 4] It is composed of Figures 4A and 4B. [Figure 4A] 4 is a flowchart illustrating high-level steps in an embodiment of a countermeasure mechanism against side channel and fault injection attacks. [Figure 4B] 4 is a flowchart illustrating high-level steps in an embodiment of a countermeasure mechanism against side channel and fault injection attacks. [Diagram 5] Here is a sample code section containing three asynchronous tasks. [Figure 6A] FIG. 2 is a schematic diagram of an asynchronous task queue. [Figure 6B] FIG. 2 is a schematic diagram of an asynchronous task queue. [Figure 6C] FIG. 2 is a schematic diagram of an asynchronous task queue. [Figure 7] FIG. 2 is a timeline diagram illustrating an execution timeline of an application that performs desynchronization. [Figure 8] FIG. 8 is a schematic illustration of the example from FIG. 7 in which the execution timeline is modified according to the mechanisms described herein for utilizing asynchronous tasks to perform desynchronized operations. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] In the following detailed description, reference is made to the accompanying drawings, which show by way of example specific embodiments in which the present invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present invention. It should be understood that the various embodiments of the present invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in relation to one embodiment may be implemented in other embodiments without departing from the spirit and scope of the present invention. In addition, it should be understood that the location and arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the present invention. Therefore, the following detailed description should not be taken in a limiting sense, and the scope of the present invention is defined solely by the appended claims, together with the full scope of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality across the several views.

[0043] The following description includes references to various methods that are performed by a processor of an integrated circuit chip. As is common in the art, there may be phrases herein indicating that these methods or method steps are performed by software instructions or software modules. Those skilled in the art should interpret such descriptions to mean that, in fact, the processor executes the methods, software instructions, and software modules.

[0044] The techniques described herein provide a mechanism for protecting digital security devices against side-channel and fault injection attacks by desynchronizing the execution of sensitive routines in an unpredictable manner with desynchronizing or padding code through the execution of tasks from a queue of tasks that can be executed asynchronously.

[0045] A sensitive operation is an operation that processes or uses a piece of sensitive information that should be protected from being disclosed. Examples of sensitive information include private encryption keys, account numbers, PIN codes and passwords, biometric information, and data transferred in a secure memory transfer operation. Encryption operations are typically sensitive operations. Account access through an account number, PIN, or password is also a sensitive operation, as is an operation that accesses or manipulates biometric information.

[0046] As used herein, an asynchronous task is a task performed by an electronic device that may be performed without being synchronized to the execution of another task. An asynchronous task may be any task that may be performed before or independently of the current operation of an active application process. For example, an asynchronous task may be an operating system function that is not a function of an application being executed, but is performed by the operating system periodically or based on certain conditions. Such operations include memory management functions, such as defragmentation, and non-volatile read and write memory (NVM) page refresh. Asynchronous tasks also include application program operations. For example, for cryptographic applications, these application program operations may include the calculation of large prime numbers, the generation of a buffer of true random numbers using a hardware true random number generation (TRNG).

[0047] FIG. 1 is an illustration of a network 111 in which a user 101 operates a digital security device 103 to perform any of a variety of sensitive operations, e.g., cryptographic operations. Digital security device 103 can be any of a variety of types of tamper-resistant devices, such as a smart card, an electronic identification card, a passport, and a secure USB token. Digital security device 103 may be incorporated into a host device 105, such as a mobile communication device. Alternatively, digital security device 103' may be connected to host device 105' via terminal 107. In yet another alternative, digital security device 103" may be wirelessly connected to host device 105", e.g., via near field communication (NFC), Bluetooth, or WiFi.

[0048] Often, digital security devices 103 are used to perform cryptographic services in connection with services provided by service providers 109 over a network 111, e.g., the Internet. Such cryptographic services include providing cryptographic signatures, encryption, decryption, and authentication. Alternatively, digital security devices are used for other operations involving sensitive information, such as account access via personal identification numbers (PINs), passwords, or biometrics.

[0049] To perform a sensitive operation, for example a cryptographic operation, the digital security device 103 stores therein some sensitive information, for example a cryptographic key, a PIN, or a password.

[0050] In classical cryptography, the sender and receiver of a secret message each possess a key that can be used to encrypt and decrypt the message, respectively. The security of the cryptographic algorithm used depends on the degree of confidence that it is mathematically very difficult to decrypt the message without the correct key, and that it is mathematically very difficult to determine the encryption and decryption keys from the message. Thus, if a message is intercepted on its way to the receiver, the intercepting party cannot deduce the associated plaintext, or the key that was used to encrypt and decrypt the message.

[0051] This security relies on the assumption that the execution of the algorithm itself does not provide information that can be used to determine the secret information used in performing the encryption operation, e.g., the decryption operation. If a message is intercepted between the sender and the intended recipient, it is reasonable to assume that the intercepting entity does not have access to the device being used to decrypt the message.

[0052] 1, however, digital security device 103, e.g., an encryption device, may be a mobile device that is somewhat prone to being lost or stolen, and thus may fall into the hands of a person who may wish to determine the sensitive information stored in digital security device 103. In such a case, an entity seeking to determine the sensitive information stored in digital security device 103 may in fact be able to obtain digital security device 103, and thus be able to observe the digital security device as it is performing sensitive operations, e.g., encryption operations.

[0053] When digital security device 103 can be observed while performing a sensitive operation, it is possible to measure various physical characteristics of digital security device 103 that change during the performance of the sensitive operation. For example, power consumption, electromagnetic emissions, timing information, and even noise of digital security device 103 can be recorded and analyzed to determine sensitive information stored in digital security device 103. Collectively, such physical characteristics are referred to herein as side channel data, and the use of such data to determine sensitive information, e.g., cryptographic keys, is referred to as side channel analysis.

[0054] In another form of attack, a fault injection attack, the digital security device 103 may be made to suffer an operational fault condition, e.g., an out-of-range power supply voltage, or a clocking error, to cause a processing error that an attacker can exploit to cause an operation to be performed in a way that can be used by the attacker to determine secret information stored in the digital security device 103.

[0055] FIG. 2 provides an example of equipment that may be used to perform side channel analysis or to perform a fault injection attack. Digital security device 103 may be inserted into reader 201. The reader may be connected to or include an electronic circuit having, for example, a power supply 203 that provides power to the security device and a resistor 205. The power consumption of digital security device 103 may be monitored on a signal capture device 207, for example an oscilloscope connected in parallel with resistor 205. A computer 209 is also connected to reader 201. Computer 209 may be used to alter sensitive information stored in the device under test, i.e., a device that may be manipulated by an attacker, to induce digital security device 103 to perform sensitive operations, for example decryption, digital signing, or authentication. Signal capture device 207 may also be connected to computer 209 such that a digitized power trace generated by signal capture device 207 may be transferred to computer 209 for analysis.

[0056] 2 can also be used to perform fault injection attacks against digital security device 103. In such a case, for example, the supply voltage applied to digital security device 103 can be changed at precise execution times identified through side-channel analysis to trigger a particular execution flow.

[0057] There are many different types of side-channel attacks. These include, but are not limited to, Simple Power Analysis (SPA), Differential Power Analysis (DPA), Template Attack (TA), Correlation Power Analysis (CPA), Mutual Information Analysis (MIA), and Test Vector Leakage Assessment (TVLA). Mark Randolph and William Diehl, Power Side-Channel Attack Analysis: A Review of 20 Years of Study for the Layman,Cryptography 2020,4,15;doi:10.3390 / cryptography4020015. Randolph and Diehl provide a good introduction to the subject of side-channel analysis.

[0058] 3 is a high-level diagram of an example digital security device 103 including a processor 301, a random access memory (RAM) 302, and a non-volatile memory (NVM) 303, e.g., a non-volatile random access memory (NVRAM). The NVM 303 may be used to store programs in a program memory 305 and data in a data memory 307. The programs stored in the program memory 305 provide instructions executable by the processor 301. The programs may include an operating system 309, e.g., a virtual machine. The programs may also include an application 311 that performs at least one sensitive operation, e.g., a cryptographic operation. The data memory 307 includes sensitive information 313, e.g., encryption keys, passwords, and personal identification numbers.

[0059] According to one embodiment, the program memory 305 may also include at least one asynchronous task table 315 for storing information about application program tasks that can be executed asynchronously, i.e. independently of other program flows, which can be used to disrupt the execution timing of the application to thwart attacks based on analysis of the execution timing. The asynchronous task table 315 associated with a particular application 311 is advantageously stored together with the application 311 in the program memory 305. During run-time, the asynchronous task table 315 is used to build a task queue 317 that is stored in the RAM 302. The task manager function of the operating system 309 uses the task queue 317 to schedule tasks during the execution of the application 311 and other applications executing on the digital security device 103. For example, as discussed in more detail below in connection with FIG. 4, the asynchronous execution of such asynchronous tasks can be used to frustrate attacks by randomizing the execution timing of sensitive routines or to uniform different branches through sensitive routines.

[0060] 4 is a flow chart illustrating high-level steps in an embodiment of a mechanism for countering side-channel and fault injection attacks. The method illustrated in FIG. 4 provides a mechanism that provides defensive desynchronization of operations performed by applications having sensitive operations 311 while avoiding the performance of useless operations, thereby improving both the performance and security of the digital security device 103 with respect to side-channel attacks.

[0061] The mechanism shown in Figure 4 can be used as part of a countermeasure strategy that involves altering the execution times of different parts of an application. Such countermeasures include smart desynchronization, i.e., execution timing randomization, and uniform code branch execution. In smart desynchronization, the execution time of an operation or sequence of operations is randomized to avoid revealing to an attacker the location of a particular operation or sequence of operations. In uniform code branch execution, at least two code branches are made to execute with the same execution time to avoid revealing which of the at least two code branches has been executed.

[0062] In the first step, step 401, tasks are identified as tasks that may be executed asynchronously. This step may be performed by code analysis or by a programmer providing comments that flag a preprocessor that a particular section of code may be executed asynchronously.

[0063] Some tasks may be considered asynchronous in nature, such as memory defragmentation. Such tasks may be performed given certain conditions. For example, with respect to memory defragmentation, memory analysis may reveal a threshold level of fragmentation that makes memory defragmentation desirable, and a second threshold level that makes memory defragmentation necessary before application execution can proceed.

[0064] 5 is a sample code section 501 that includes three asynchronous tasks, Alpha 503, Beta 505, and Gamma 507, and several non-asynchronous tasks 509 and 511. The non-asynchronous tasks 509 and 511 must be executed in the correct sequence, whereas the asynchronous tasks 503, 505, and 507 may be executed at any time during the execution of the application to which the code section 501 belongs, or at any time before the results from such asynchronous tasks are needed by the application 501.

[0065] The expected execution times for the tasks are determined in step 403. In one embodiment, the application developer assigns expected execution times to the various asynchronous tasks that the developer has identified as component tasks of the application 311. Application developer tools may provide mechanisms for predicting such execution times.

[0066] In one embodiment, the predicted execution time is used to assign weights to the tasks in step 405. For example, the allowable range of weights may be from 1 to 10. A very fast task is given a weight of 1, whereas a very complex task is given a weight of 10.

[0067] For illustration purposes, Table 1 shows some example tasks, their associated expected execution times, and their weights. - Very large prime calculation, 10+ seconds, weight 10 - Memory defragmentation, 500+ ms, weight 8 - NVRAM page refresh, 10+ ms, weight 5 - Generate a small buffer of random numbers using a hardware True Random Number Generator (TRNG), 5+ ms, weight 3 - Running a small calculation routine, <1 ms, weight 1 Table 1: Example asynchronous tasks, their estimated execution times, and their weights

[0068] Therefore, a relationship such as that shown in Table 2 is assigned between the predicted execution time and the weight.

[0069] [Table 1]

[0070] Table 2 is merely an example. In alternative embodiments, the granularity of the association between execution times and weights may vary depending on the implementation.

[0071] During execution 407 of the application, the application anticipates, in step 409, a future need for tasks that can be executed asynchronously and places such tasks in a task queue 317. The task queue 317 is used by a task scheduler to schedule tasks to be executed, including asynchronous tasks.

[0072] Figure 6 is a more detailed diagram of the asynchronous task queue 317 being processed by the steps of Figure 4. In the first stage shown in Figure 6A, the asynchronous task queue 317a contains several asynchronous tasks available for execution when needed. In this example, these are tasks T1 through T7. Each of these tasks has a certain expected execution time, which in one embodiment can be converted into a weight. Note that 317a, 317b, and 317c are different states of the same asynchronous task queue 317.

[0073] If the application determines at step 405 that there is a future need for a task that can be executed asynchronously, then that task (e.g., task T8) is added at 411 to the asynchronous task queue 317b, as shown in FIG. 6B.

[0074] During the execution of the application, in step 413, the need for desynchronization may be determined. The reasons for such desynchronization are outside the scope of this document. However, as noted, adding delays to the execution of sensitive routines may be used to prevent attackers from performing side-channel attacks, fault injection attacks, and timing attacks. Furthermore, countermeasures against timing attacks are based on balancing the execution times of different branches of a sensitive routine. Thus, countermeasures based on such techniques sometimes determine the need to introduce desynchronization by performing tasks that are unrelated or only slightly related to the execution of the sensitive routine being protected.

[0075] The first step in adding desynchronization is to determine how much execution time should be added at the point where such desynchronization is required, step 415. For example, if one of two branches has an execution time that is a fixed amount of time less than the other branch, the difference is the desired desynchronization time. Conversely, if a particular point in the code is to be desynchronized by adding a random amount of time, the desynchronization time added may be set to a random number.

[0076] Once the required desynchronization time has been determined, in step 419, one or more tasks having combined predicted execution times that meet the required desynchronization time are selected from the asynchronous task queue 317 and these asynchronous tasks are executed.

[0077] The selected task is then removed from the asynchronous task queue in step 421. The updated asynchronous task queue 317c after removal of the executed asynchronous task is shown in Figure 6C, where task T4 has been removed as an example.

[0078] From time to time, an event may occur where an application requires execution of a task placed in the asynchronous task queue 317 before it has been selected for desynchronization work. In such a case, the task is executed based on its execution being required by the application, in step 423. After such a task has been executed, it is removed from the asynchronous task queue, in step 425.

[0079] We now turn our attention to an example of the technique described herein above. Figure 7 shows a conventional desynchronization mechanism as part of a countermeasure against attacks on digital security devices. In addition to computations not shown (shown as white space between blocks), this execution example consists of six tasks executed consecutively: two desynchronized tasks D1 and D2, and four tasks T1, T2, T3, and T4. Meanwhile, as can be seen in the example of Figure 8, tasks T1-T4 can be executed asynchronously with respect to other computations being executed. However, in the example of Figure 7, that property is not exploited. Execution starts with desynchronized task D1 at approximately time=0 and ends with task T4 at time=28. The desynchronized blocks perform dummy computations. Thus, desynchronized blocks D1 and D2 do not produce any useful computations and do not contribute to the results of the application being executed.

[0080] Now contrast the flow of Figure 8, which uses the asynchronous execution techniques described herein above, with the example of Figure 7. An initial decision is made that tasks T1 (weight W=2), T2 (weight W=5), and T3 (weight W=2) are placed in the asynchronous task queue.

[0081] At time T=3, the first desynchronized block (D1) is executed. However, in contrast to the mechanism of FIG. 7, a task from the asynchronous task queue is selected that has a predicted execution time combined with the desired desynchronization time. The desired desynchronization time for D1 corresponds to weight 6. Thus, two blocks whose sum of weights corresponds to an execution time of weight 6 are randomly selected from the asynchronous task queue, in this example tasks T3 (W=3) and T2 (W=5). Note that this is not strictly linear. A task with weight 3 (3 msec≦PET<6 msec) and one with weight 5 (9 msec≦PET<20 msec) correspond to weight 6 (20 msec≦PET<50 msec).

[0082] After desynchronization, the executed task is removed. During the course of continued execution of the application, it is predicted that a new task, T4, will be required. Therefore, T4 is added to the asynchronous task queue.

[0083] Task T1, which has not yet been executed through the desynchronization process, is determined to be necessary for the execution of the application. Therefore, it is executed (at time T=19) and removed from the asynchronous task queue. At time T=22, a second desynchronization is performed. This time, the desynchronization time corresponds to weight W=4. Thus, a task with weight equal to 4 is randomly selected from the asynchronous task queue, with T having weight W=4 in this example, and it is removed from the asynchronous task queue.

[0084] As can be observed from the examples illustrated in Figures 7 and 8, the mechanism of using tasks that are required by an application (or by the operating system) and that can be executed asynchronously to perform desynchronized operations improves the performance of the execution of the application by the digital security device. Furthermore, the execution of such operations that are not simply designed to delay execution, such as dummy routines, becomes more difficult for an attacker to detect by performing a timing analysis of the application as it executes on the digital security device, thereby making the digital security device more secure for the purposes of storing sensitive information and performing sensitive operations.

[0085] From the above, it should be apparent that an efficient and secure mechanism for improving desynchronized operations on digital security devices has been provided.

[0086] While particular embodiments of the present invention have been described and illustrated, the invention is not limited to the specific forms and arrangements of parts so described and illustrated, and is limited only by the scope of the appended claims.

Claims

1. A method for improving performance while protecting a computerized digital security device (103) against side channel, fault injection and timing attacks, comprising: Identifying 401 an asynchronous task to be executed by a computerized digital security device; placing (411) the identified asynchronous task in an asynchronous task queue (317); Executing (407) a first application, selecting at least one task from an asynchronous task queue; Executing (423) at least one selected task; removing (425) the at least one selected task from the asynchronous task queue; and executing (407), which includes non-linearizing the execution of the application by executing A method comprising:

2. predicting (403) an execution time for each identified asynchronous task; and wherein the step of selecting at least one task from the asynchronous task queue includes basing the selection of the at least one task from the asynchronous task queue on a predicted execution time of the tasks in the asynchronous task queue.

10. The method of claim 1 for improving performance while protecting a computerized digital security device against side channel, fault injection and timing attacks.

3. identifying an execution location to add desynchronization time; determining 415 how much desynchronization time to add, determining (415), wherein the step of selecting at least one task includes selecting (419) at least one task such that a sum of predicted execution times of the selected at least one task is less than the determined desynchronization time to add; Executing (419) at least one dummy task for an execution time equal to a difference between the determined desynchronization time to be added and the sum of the predicted execution times of the at least one selected task; 3. A method for improving performance while protecting a computerized digital security device against side channel, fault injection and timing attacks as recited in claim 2, comprising:

4. 2. The method of improving performance while protecting a computerized digital security device against side channel, fault injection and timing attacks of claim 1, comprising shuffling execution of a first application by selecting at least one task from an asynchronous task queue and executing the selected at least one task before continuing execution of the first application.

5. 2. The method of improving performance while protecting a computerized digital security device against side channel, fault injection and timing attacks of claim 1, comprising: desynchronizing execution of a first application by modifying the execution flow of the first application by selecting at least one task from an asynchronous task queue and executing the selected task before continuing execution of the first application.

6. identifying at least first and second code branches, wherein execution times for the first and second code branches are not equal; Equalizing the execution times for the first and second code branches by selecting at least one task from the asynchronous task queue such that a predicted execution time of the selected at least one task balances the execution times of both code branches.

2. A method for improving performance while protecting a computerized digital security device against side channel, fault injection and timing attacks as recited in claim 1, comprising:

7. 10. The method of improving performance while protecting a computerized digital security device against side channel, fault injection and timing attacks as recited in claim 1, wherein a task is randomly selected from an asynchronous task queue.

8. 2. A method for improving performance while protecting a computerized digital security device against side channel attacks, fault injection attacks, and timing attacks as described in claim 1, wherein the tasks added to the asynchronous task queue include tasks selected from tasks required by a first application, tasks required by an operating system of the computerized digital security device, and tasks required by applications other than the first application.

9. 2. The method of improving performance while protecting a computerized digital security device against side channel, fault injection and timing attacks of claim 1, wherein the tasks added to the asynchronous task queue include tasks selected from the group of: calculation of very large prime numbers, memory defragmentation, non-volatile memory (NVM) page refresh, NVM erase, NVM write, generation of small buffers of random numbers using hardware true random number generation, security sensor check, memory integrity verification, code execution flow control, data compression, and data decompression.

10. 1. A digital security device having improved performance while being protected against side channel attacks, fault injection attacks, and timing attacks, comprising: A processor; a memory coupled to the processor, the memory including instructions executable by the processor, the processor being configured to: Identifying an asynchronous task to be performed by a computerized digital security device; placing the identified asynchronous task in an asynchronous task queue; executing a first application, selecting at least one task from an asynchronous task queue; executing at least one selected task; removing the at least one selected task from the asynchronous task queue; To execute, to execute 23. A digital security device comprising: instructions for non-linearizing execution of a first application by causing the first application to:

11. A digital security device having improved performance whilst being protected against side channel, fault injection and timing attacks according to claim 10, programmed to carry out the method according to any one of claims 2 to 9.

12. 1. A non-transitory memory comprising instructions for causing a processor of a digital security device to perform a method for improving performance while protecting a computerized digital security device against side channel attacks, fault injection attacks, and timing attacks, the non-transitory memory comprising instructions for causing the processor to: Identifying an asynchronous task to be performed by a computerized digital security device; placing the identified asynchronous task in an asynchronous task queue; executing a first application, selecting at least one task from an asynchronous task queue; executing at least one selected task; removing the at least one selected task from the asynchronous task queue; To execute, to execute a non-transitory memory including instructions for non-linearizing execution of the first application by causing the first application to

13. 13. The non-transitory memory of claim 12 comprising instructions for causing a processor of a digital security device to perform the method of any one of claims 2 to 9.

Images