Testing method

Abstract

A testing method is provided for testing whether a subject method has a constant processing time. The testing method identifies a plurality of intermediate points in the subject method, wherein portions of the subject method performed between pairs of the intermediate points form a plurality of execution units of the subject method. The testing method executes the subject method a plurality of times and measures execution times at which the subject method reaches each of the identified intermediate points. A statistical test is performed on the measured execution times to determine whether execution times, for a given execution unit of the subject method, is distinguishable between the executions in which the at least one parameter is selected from a first distribution and the executions in which the at least one parameter is selected from a second distribution.

Description

[0001] TESTING METHOD

[0002] Technical Field

[0003] The present invention relates to a testing method for testing whether a subject method has a constant processing time, an information processing apparatus for testing whether a subject method has a constant processing time, and a program.

[0004] Background

[0005] There are several aspects to the security of cryptographic methods. On the one hand it is important that a cryptographic method is constructed with steps that ensure that the cryptographic method is secure against various attacks. On the other hand, when implementing the secure cryptographic method, it is also important that secret information is not leaked due to vulnerabilities in the device performing the cryptographic method. Attacks that are based on how a device performs a method, rather than on the details of the method, are referred to as side-channel attacks.

[0006] One attack vector for side-channel attacks is to measure a processing time for the cryptographic method. If the processing time of a device varies in dependence upon secret parameters used to perform the method, the device may give away information about one or more secret parameters being processed thereby breaking security of the method. Many examples of such attacks have been seen over the last three decades, including attacks on AES (Cache-timing attacks on AES, Daniel Bernstein, 2005), RSA (FLUSH+RELOAD: a High resolution, Low Noise, L3 Cache side-channel attack, Yarom et al, 2014), El Gamal (Last-level Cache Side-Channel Attacks are Practical, Liu et al, 2015), and ECC (Remote Timing Attacks are Still Practical, Brumley et al, 2011).

[0007] The property that a program or device should take the same time to execute regardless of the parameters used is sometimes referred to as a ‘constant runtime’ property.

[0008] While it is desirable that cryptographic methods are performed with a constant runtime, it is also a desirable property for other types of processing such as processes involving sensitive information, such as personally identifiable information or payment credentials. As the question of whether a subject method performs with a constant runtime for a particular parameter varies from device-to-device and program-to-program, improvements in techniques for testing for constant runtime are desirable.

[0009] Summary

[0010] According to a first aspect of the present invention, there is provided a testing method for testing whether a subject method has a constant processing time, wherein the subject method processes at least one parameter to be secured, the testing method comprising: identifying a plurality of intermediate points in the subject method, wherein portions of the subject method performed between adjacent pairs of the intermediate points form a plurality of execution units of the subject method; executing the subject method a plurality of times, wherein the executions of the method include executions in which the at least one parameter to be secured is selected from a first distribution of parameter values and executions in which the at least one parameter to be secured is selected from a second distribution of parameter values, wherein the first distribution of parameter values is different from the second distribution of parameter values; measuring execution times at which the subject method reaches each of the identified intermediate points for each of a plurality of executions of the subject method; and performing a statistical test on the measured execution times to determine whether execution times, for a given execution unit of the subject method, are distinguishable between the executions in which the at least one parameter to be secured is selected from the first distribution and the executions in which the at least one parameter to be secured is selected from the second distribution.

[0011] Executing the subject method a plurality of times may comprise the executions of the method including executions in which the at least one parameter to be secured is additionally selected from one or more further distributions of parameter values.

[0012] In some implementations, the intermediate points are identified so that the execution units exclude or have a lower density in one or more portions of the subject method. The intermediate points may be identified so that the execution units exclude or have a lower density in one or more portions of the subject method in which no parameter to be secured is processed. In some implementations, the at least one parameter to be secured of the subject method may comprise a plurality of parameters. The test method may be repeated for a second parameter of the plurality of parameters to be secured.

[0013] In some embodiments, the executions of the method may include executions in which a second parameter of the at least one parameter to be secured is selected from a third distribution of parameter values and executions in which the second parameter is selected from a fourth distribution of parameter values, wherein the third distribution of parameter values is different from the fourth distribution of parameter values. In such embodiments, at least two parameters are varied during at least some of the plurality of executions.

[0014] In some implementations, the statistical test is performed for each of a plurality of execution units. The statistical test may be separately performed for all identified execution units.

[0015] Identifying the plurality of intermediate points may comprise inserting a code portion at each intermediate point in source code of a program configured to perform the subject method.

[0016] In some implementations, identifying the plurality of intermediate points may comprise inserting a code portion at each intermediate point in binary code of a program configured to perform the subject method. In some such implementations, the code portion may be automatically inserted by a compiler during generation of binary code. The compiler may be configured to insert code portions in positions associated with predefined functions of the source code.

[0017] Identifying the plurality of intermediate points may be performed by a processor during execution of a program configured to perform the subject method. The processor may be configured to measure and record a timing of operations performed by the processor during execution of the program. Such recording of operations by the processor is sometimes referred to as processor tracing. In some implementations, intermediate points may be identified from times of operations recorded in a log after the processor has executed the program.

[0018] In some embodiments, the test method may insert a serialization barrier into binary code that is executed to perform the subject method. During execution of the binary code, the serialization barrier may act to separate execution of at least two of the execution units. The subject method may be performed by a device under test. In such embodiments, identifying the plurality of intermediate points in the subject method may comprise identifying operations that the device under test performs at certain steps of the subject method. Identifying a plurality of intermediate points may comprise adding hardware to the device under test to perform measurements at certain points in the subject method.

[0019] In some implementations, execution of the subject method may comprise simulation of performance of the subject method by a device under test. In some such cases simulation may be performed by describing all of or a portion of a device under test using a hardware description language. Identifying intermediate points may comprise simulating waveforms corresponding to signals from one or more components of a device under test and identifying one or more intermediate points based on the simulated waveforms.

[0020] The first distribution may be a distribution in which the first parameter takes a constant value.

[0021] The second distribution may be a distribution in which the first parameter takes a value that is randomly selected from a range of values that the first parameter can take in the subject method. In some implementations, the second distribution may represent an equal probability that the first parameter may take any value in the range of values that the first parameter can take in the subject method.

[0022] The subject method may be at least one of: a cryptographic method and a machine learning method. Accordingly, the at least one parameter to be secured may comprise at least one of a secret parameter of a cryptographic method, hyperparameters of a machine learning model during training, personally identifiable information, and a payment credential.

[0023] According to a second aspect of the invention there is provided an information processing apparatus for testing whether a subject method has a constant processing time, wherein the subject method processes at least one parameter to be secured, the information processing apparatus configured to: identify a plurality of intermediate points in the subject method, wherein portions of the subject method performed between adjacent pairs of the intermediate points form a plurality of execution units of the subject method; execute the subject method a plurality of times, wherein the executions of the method include executions in which a first parameter of the at least one parameter to be secured is selected from a first distribution of parameter values and executions in which the first parameter is selected from a second distribution of parameter values, wherein the first distribution of parameter values is different from the second distribution of parameter values; measure execution times at which the subject method reaches each of the identified intermediate points for each of a plurality of executions of the subject method; and perform a statistical test on the measured execution times to determine whether execution times, for a given execution unit of the subject method, is distinguishable between the executions in which the first parameter is selected from the first distribution and the executions in which the first parameter is selected from the second distribution.

[0024] According to a third aspect of the present invention there is provided a program that, when executed on an information processing apparatus, causes the information processing apparatus to perform a method according to the first aspect of the invention.

[0025] Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.

[0026] Brief Description of the Drawings

[0027] Figure 1 is a schematic diagram illustrating testing of an algorithm that takes two inputs;

[0028] Figure 2 shows a pair of tables that show illustrative results from testing class 1 and class 2 shown in Figure 1;

[0029] Figure 3 is a schematic diagram illustrating a program that executes over time; Figure 4 is a flow chart showing steps of a test method; and

[0030] Figure 5 is a schematic diagram showing hardware of an information processing apparatus.

[0031] Detailed Description

[0032] Methods and apparatus for testing constant runtime of subject methods will now be described. For convenience, testing of computer programs will be described first and then testing of devices will be described. A common feature of the testing methods is that a plurality of intermediate points in a subject method are identified. This applies both in the case where the subject method is performed by executing a program and where the subject method is performed by a device-under-test (DUT). Portions of the subject method performed between pairs of adjacent intermediate points (and between an intermediate point and an adjacent end point of the method) form a plurality of ‘execution units’ of the subject method.

[0033] A benefit of partitioning the subject method into a plurality of execution units is that an execution unit that does not have a constant runtime may be identified, which allows identification of a sub-portion of the subject method that can be reviewed to identify a cause of possible information leakage. This compares with a method that simply performs a constant runtime test on the entire program, which can make diagnosis of a cause of leakage difficult and time consuming, particularly for larger programs.

[0034] A further benefit of dividing the subject method into a plurality of execution units is that by considering smaller portions of the subject method, the signal -to-noise ratio is increased. As will be explained further below, the complete set of executions units may not span the entire subject method. For example, portions of the subject method that only handle data values that are not sensitive can be omitted from constant runtime testing. Portions of the subject method that do not handle sensitive data may not run with a constant runtime and any leakage of information may not be important. Even if portions of the subject method that do not handle sensitive data do run with a constant runtime, the distribution of runtimes for portions of the method not handling sensitive data will provide noise over which detection of a portions of the subject method that doesn’t run with constant runtime must be detected. By testing a plurality of execution units, the number of operations that may impact a distribution of execution times is reduced, thereby more closely limiting the time measurements to operations in a subject method that need to be constant runtime.

[0035] The test method may measure times at which the subject method reaches each of the identified intermediate points during execution of the subject method. These measurements are performed for each of a plurality of repetitions of the subject method. The repetitions of the method include repetitions in which at least one secret parameter is selected from a first distribution of parameter values and repetitions in which the at least one secret parameter is selected from a second distribution of parameter values. The first distribution of parameter values is different from the second distribution of parameter values. Implementations are not limited to the case in which there are only two distributions, and selection of at least one secret parameter from three or more distributions during testing is possible.

[0036] The statistical test performed on the measured execution times determines whether an execution time for each execution unit of the subject method is distinguishable between the repetitions in which the at least one parameter is selected from the first distribution and repetitions in which the at least one parameter is selected from the second distribution. If the two distributions cannot be distinguished based on the measured execution times, the execution unit of the subject method (whether performed by executing a program or performed by a device under test) is considered to have a constant runtime with respect to a tested parameter.

[0037] The test method may apply the statistical tests in each of the case in which a test is performed on a program being executed on an information processing apparatus or where the subject method is performed on a DUT. The statistical test should determine whether differences between the processing time of each execution unit between two groups of input values selected from the first distribution and the second distribution respectively is statistically significant or not (i. e. whether the two groups of input values can be distinguished implying that information is being leaked). Here it is noted that the test method does not indicate what information is being leaked or provide an attack. The test method indicates whether or not the measured time distributions for an execution unit in connection with a secret parameter are equal. The measured time distributions for an execution unit in connection with a secret parameter should be equal if the execution unit has a constant runtime with respect to the secret parameter being tested.

[0038] The measurements used to form first and second time distributions based on secret parameter values selected from the first distribution and second distribution respectively can include measurements of execution time of the secret parameter being tested in which the secret parameter takes a plurality of different values that span a significant proportion of the values that the secret parameter can take. This allows reasonable confidence after successful completion of the test method that the execution time does not vary across the full range of the parameter being tested.

[0039] Figure 1 is a schematic diagram illustrating a subject method in the form of an algorithm that takes two input parameters. The methods discussed herein are applicable to algorithms with any number of inputs, but the example of two is shown here for ease of explanation. In class 1 of the test method, illustrated in the upper part of Figure 1, both inputs to the algorithm take a fixed input parameter and the algorithm is performed repeatedly using those fixed input parameters. The algorithm has been split into a plurality of execution units as will be described in more detail below. In each repetition, the time taken by each execution unit is measured and recorded. In class two, illustrated in the lower part of Figure 1, one of the input parameters is held constant (in this example, parameter ‘a’) and the input parameter being tested in varied at random within the range that the input parameter can take in the algorithm. Again, at each repetition, the time taken by each execution unit is measured and recorded.

[0040] Figure 2 illustrates a pair of tables that show illustrative results from testing class 1 and class 2 described above. The results from the class 1 test are shown in the table in the upper part of Figure 2 and the results from the class 2 test are shown in the lower portion of Figure 2. Execution times for each of N execution units of the algorithm are recorded and K different execution time measurements are taken for each execution unit, where K is selected to be large enough to allow identification of a statistically significant difference between execution time distributions (distribution of measured execution times), if a difference exists, for any given execution unit based on the class 1 and class 2 measurements. The threshold for what differences are considered statistically significant can be set in accordance with the implementation (it forms a user selectable security parameter). A larger number of repetitions and hence measurements of the execution time of each execution unit will allow identification of smaller differences between the class 1 and class 2 distributions.

[0041] Looking at the illustrative data in Figure 2, (and without performing a detailed statistical analysis) there is a significant difference in the execution times for Execution unit 2 (EU2) between class 1 and class 2. These differences in execution time may indicate that investigation of the performance of Execution unit 2 on the device being tested may be required. To identify whether the measurements of execution times for class 1 and class 2 for an execution unit can be distinguished, a statistical test may be performed. For example, the Welch t-test may be applied to determine whether the distribution of execution times between class 1 and class 2 are statistically different. The use of Welch t-test is optional and other statistical tests such as the box test, sign test, Wilcoxon signed-rank test, Friedman test, etc. may be applied instead. Indeed, any suitable test to discover whether or not the distribution of execution times of an execution unit between class 1 and class 2 are statistically different may be employed.

[0042] In the test example above, parameter ‘b’ was varied while parameter ‘a’ was held constant in class 2. Accordingly, the test determines whether the algorithm runs with a constant runtime with respect to parameter ‘b’. The test can be repeated with parameter ‘b’ held constant and parameter ‘a’ randomly varied to determine whether the algorithm runs with constant runtime with respect to parameter ‘a’.

[0043] In some implementations, the test method may solely be performed with respect to secret or confidential parameters. Accordingly, if an input parameter is a publicly available or a non-sensitive parameter it may not be necessary to test whether that parameter is executed with a constant runtime.

[0044] Software based methods

[0045] Computer programs are commonly written using source code, which is a human-readable set of instructions written in a programming language such as Python, Java or C++. The source code defines what the program does.

[0046] When the source code has been prepared (by a computer programmer, by generative Al, or otherwise) the source code is subject to compilation by a compiler that converts the source code into binary code (sometimes referred to as assembly or machine code) that a processor can execute directly. In some cases, the compiler may read the source code and check for syntax errors in the source code. The compiler may also perform one or more optimization processes. Example optimization processes include unrolling loop commands and removal of code that does not affect the programs output. The purpose of these optimizations is often to generate fast or compact binary code from the source code. Examples of compilers include GCC or Clang (RTM). It is noted that, due to the optimization processes performed by a compiler, source code that appears to be constant runtime may not actually be constant runtime after compilation. In addition, parts of some programs may be prepared (by a computer programmer, generative Al, or otherwise) directly in assembly code. In such implementations, parts of the assembly code are generated without originating from a piece of source code. Accordingly, the testing methods of the software embodiments described herein take time measurements of binary code actually being executed by specific hardware. This allows all technology layers of a given system to be taken into account (e.g. the source code being used, the compiler, and the hardware platform being used to execute the binary code). Testing in this way may avoid accidental information leaks that can occur due to, for example, compilation with a new version of a compiler or execution on a different processor architecture.

[0047] It is further noted that the techniques described herein in connection with software testing do not make use of modelling of the execution of software, for example on virtual machines. In contrast to specific hardware modelling (discussed further below) modelling of execution of software to detect constant runtime has typically relied on methods that enumerate the circumstances in which software may leak information and then search for examples of those circumstances. Such approaches may be unreliable because it is difficult to foresee and enumerate all the circumstances in which information leaks may occur.

[0048] Figure 3 is a schematic diagram illustrating a program that executes over time (starting from the bottom / left of Figure 3 and progressing to the top / right). A plurality of intermediate points has been identified in the program and a time measurement is taken when the program reaches each intermediate point. As indicated by ‘EU’, portions of the program between adjacent intermediate points form execution units of the program.

[0049] Time measurements may be relative time measurements that measure a passage of time from a reference point, such as a number of clock cycles based on a timing signal from a clock circuitry that have occurred since the start of execution of the program. Alternatively, in some implementations the time measurement could be an absolute time measurement against a reference clock. No limitation is placed on the duration of the processing of the program which could be very quick for simple programs running in fractions of a second to execution times of minutes, hours, days or even months for large programs such as training large language models.

[0050] The intermediate points may be implemented manually by a programmer inserting code portions into a program. For example, a call to a function may be inserted at various points in the source code. The program may call a function that records the execution time elapsed at that point in execution of the code. This process may be performed by a human programmer and / or may be performed by an automated programmer such as an Al agent or other automated process.

[0051] In some implementations, it may be possible to automatically insert calls to a function at various points in the code during compilation. For example, the compiler may be configured to insert a call to a function to record the time at entry and exit of predetermined functions within the program. In one example, the compiler may insert an intermediate point at the start of each subroutine in a call stack. The functions that generate the calls may be defined by the programmer. An illustrative example of functionality for implementing such calls is ‘instrument-functions’ within the GCC or Clang (RTM) compilers.

[0052] A further method for identifying intermediate points in a program during execution is processor tracing. Processor tracing tools are known for debugging programs and tracking processor performance when executing programs. Processor tracing tools may capture trace data during execution of a program, such as one or more of: instruction information indicating which instructions are executed, timestamps indicating when each instruction was executed, register values that show the contents of processor registers at various times, and event flags showing information about exceptions or interrupts. After execution of a program, the captured trace data, which is typically output in a logfile, can be reviewed and suitable intermediate points identified either manually or by an automated process.

[0053] As noted above, identifying intermediate points may comprise identifying which portions of the subject method process sensitive data and / or parameters and adding intermediate points to those portions of the subject method to form a plurality of execution units corresponding to those portions of the subject method. In contrast, fewer or no intermediate points / execution units may be allocated to portions of a subject method that do not process sensitive data and / or parameters. Some of the above methods may generate a number of intermediate points that is larger than a number that can be practically analysed for constant runtime. Accordingly, there may be a desire to reduce the number of intermediate points, particularly in a case in which the intermediate points have been automatically generated. For example, in some implementations, there may be a desire for the testing procedure to be included in an integrated development process, whereby the tests can be quickly performed on different versions of software being developed by developers.

[0054] To manage the number of intermediate points, various mitigations can be put in place. In some examples, the functions that are identified in the source code and that are used as triggers to automatically add calls to source code during compilation may be reduced or selected to avoid an excessive number of intermediate points / execution units. For example, an additional condition could be added to the compiler so that no intermediate point in the form of a function call is added within a predetermined number of source code lines of a preceding intermediate point. Alternatively, the compiler may include a model that can predict an approximate runtime of a program being compiled. The compiler may be configured to insert a predetermined number of intermediate points in the form of function calls in positions in the binary code that will result in the intermediate points being approximately evenly spaced or not positioned within a predetermined time of each other. In other implementations, the compiler may be configured to only insert intermediate points until a certain stack depth, e.g. only for functions up to a predetermined depth.

[0055] In some implementations, the execution units do not need to be spread across the entire program and may be provided between selected one or more start points and end points within the program. A start point and / or end point may be a specific function within the program. The start point and / or end point may correspond to generation or loading of a predetermined parameter into the program. A compiler may be configured to automatically add function calls at intermediate points between the specified start and end points.

[0056] In some implementations, a compiler may be configured to exclude a predetermined function or list of functions such that intermediate points / function calls will not be generated by the excluded function or within a predetermined distance (execution time or code position) of the excluded function. The excluded functions are not used by the compiler to insert intermediate points and, accordingly, function calls are not added in association with these functions.

[0057] In some implementations, steps may be taken to improve separation between execution of adjacent execution units. For example, one or more serialization instructions may be added to source code at the boundaries of executions units. An example of a serialization instruction is Ifence on x86 architectures and ISB on Arm architectures. These commands instruct the processor to wait until previous instructions have completed prior to performing the next instruction. Accordingly, by using serialization commands there may be less or no overlap between the operations performed in adjacent execution units, which tends to reduce noise between execution units.

[0058] Hardware-based methods

[0059] The techniques described herein are also applicable to testing devices, referred to as device-under-test (DUT). For example, a subject method may be implemented by application specific circuitry configured to perform a subject method.

[0060] In some implementations the DUT may be simulated using a simulator. For example, the DUT may be described in part or completely using a hardware description language. In one example, a DUT may be subject to Verilog (RTM) simulation. Each individual component of all or a part of the DUT may be modelled. The model may generate waveforms corresponding to simulation of data being processed. In one example, binary data being processed may be modelled by waveforms from various components. The waveforms may be analysed to identify intermediate points. The simulator may record time stamps that are attributed to specific waveform patterns corresponding to particular intermediate points in the processing of the subject method. In some examples, identified intermediate points could be associated with entry into or exit from states in a finite state machine representing the DUT. In some implementations requests on a memory bus, or other identifiable points in the DUT modelling may be used instead of or in addition to states of the DUT as intermediate points.

[0061] In some implementations, dedicated hardware may be added to a DUT to collect timestamps at predefined points in a subject method performed by the DUT. Such hardware may include measurement devices such as an oscilloscope to measure activity in the DUT to identify intermediate points. The dedicated hardware may also include one or more clock or timer to measure the time that an intermediate point is reached and / or time interval between intermediate points.

[0062] Applications and additional description

[0063] Figure 4 is a flow chart showing steps of test methods described above. In a first step 40, the test method identifies a plurality of intermediate points in the subject method. As described above, a portion of the subject method between adjacent identified intermediate points, forms an execution unit of the subject method. A portion between a start point or an end point and an adjacent intermediate point may also form an execution unit.

[0064] In a second step, S41, the test method samples a parameter value for the subject method from one of a first and a second distribution. The parameter value may be a secret parameter value. If the subject method processes more than one parameter, only one parameter at a time may be varied and the other parameters are held constant during the test method. In other implementations, multiple parameters may be varied at the same time. In the latter case, the method will identify whether the subject method is constant time but will not allow identification of which parameter the subject method is not constant time with respect to. Accordingly, varying more than one parameter at a time may or may not be appropriate depending upon context. The first distribution is chosen to be different from the second distribution. One of the first and second distributions may hold the sampled parameter value constant (e.g. it may be a delta function). The other distribution may vary the parameter being tested.

[0065] In a third step, S42, the subject method is executed using the sampled parameter value.

[0066] In a fourth step, S43, a time that the execution of the method reaches each of the identified intermediate points during the execution in step S42 is measured and recorded.

[0067] Steps S41 to S43 are repeated as shown by the loop in Figure 4. At each repetition, step S41, samples from one of the first distribution and the second distribution. Both distributions are used over the course of multiple different repetitions. After steps S41 to S43 have been repeated a number of times including using sampled parameter values from both the first distribution and the second distribution, in step S44 a statistical test is performed. The statistical test is performed on an execution unit by execution unit basis. The statistical test examines the distribution of execution times measured for a given execution unit to determine whether or not the distribution of execution times for executions made using parameter values sampled from the first distribution can be distinguished from execution times sampled from the second distribution.

[0068] If, for an execution unit of the subject method, the distribution of execution times for executions made using parameter values sampled from the first distribution cannot be distinguished from execution times sampled from the second distribution, then the execution unit of the subject method is determined to be constant time with respect to the parameter sampled in step S41.

[0069] The statistical test in step S44 may be performed for a plurality of execution units. In some cases, it may be performed for all identified execution units. In this way, if an execution unit of the subject method is not determined to be constant time, a potential leak of information regarding the sampled parameter can be detected and isolated to an execution unit within the plurality of execution units within the subject method.

[0070] In some implementations, the method shown in Figure 4 may be repeated. After the method has been performed a first time, if one or more execution unit has been determined not to be constant time, the method may be repeated. In step, S40, the intermediate points are placed in the execution units from the first round that were determined not to be constant time. In this way, the first performance of the test method may provide a ‘coarse’ check of the program and the second (or more than two) performance of the test method provide greater granularity on where the subject method is not constant time. The execution units in the second round are selected at step S40 to subdivide the execution units of the first round that were found not to be constant time.

[0071] The techniques above have application in implementation of cryptographic methods. For example, the methods may be employed to ensure constant runtime of cryptographic algorithms on, for example, computers or mobile devices. The techniques have further application in the realm of machine learning. For example, it may be desirable to make a training time of a machine learning model constant time to prevent leakage of confidential model hyperparameters when implementing machine-leaming-as-a-service. More details of such attacks are described in ‘Cache-Telepathy: Leveraging Shared Resource Attacks to Learn DNN Architectures, Yan et al, 2020’.

[0072] Similarly, it may be desirable that inference performed by a machine learning model is performed with a constant runtime, such as when the machine learning model processes secret parameters.

[0073] Applications of the test method are not limited to cryptography and machine learning and may apply in a wide range of other applications in which secret data is processed. A non-exhaustive list of other applications includes processing of payment related data, processing of biometric data, processing of personally identifiable information, processing of passwords or other access credentials, etc.

[0074] Figure 5 is a schematic diagram showing hardware of an information processing apparatus suitable for performing the methods described above. The information processing unit may comprise one or more processor 50, a storage 51, an I / O unit 52, a network unit 53, and a power unit 54. Other components may be present but not shown as is well known in the art.

[0075] The one or more processors 50 may be configured to perform computations. The processor 50 may consist of one or more a central processing unit (CPU), a graphics processing unit (GPU) and a neural processing unit (NPU). The storage unit 51 may include both volatile (RAM) and non-volatile (ROM, SSD, HDD) memory components. The storage unit 51 may store both the instructions to be executed by the processor 50 and the data on which these instructions operate. The Input / Output Interfaces unit 52 allows the apparatus to communicate with external devices. Input interfaces may include components like a keyboard, mouse, or touchscreen for user interaction, while output interfaces may include a display, printer, or speakers. The network unit 53 may enable the apparatus to connect to networks (e.g., LAN, WAN, Wi-Fi, Bluetooth, etc.) for data exchange. The network unit 53 may include wired or wireless communication modules. The power unit 54 may provide the necessary power for all components of the apparatus. The power unit 54 may be connected to an external power source or include an internal battery for portable use.

[0076] Any steps of the testing method described above (except where explicitly indicated otherwise) may be automated and performed by a computer program. The computer program may be stored on a storage medium, such as a non-transitory computer-readable storage medium. When executed by an information processing apparatus, the program may cause the information processing apparatus to perform a test method as described above.

[0077] It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

CLAIMS1. A testing method for testing whether a subj ect method has a constant processing time, wherein the subject method processes at least one parameter to be secured, the testing method comprising:identifying a plurality of intermediate points in the subject method, wherein portions of the subject method performed between adjacent pairs of the intermediate points form a plurality of execution units of the subject method;executing the subject method a plurality of times, wherein the executions of the method include executions in which the at least one parameter to be secured is selected from a first distribution of parameter values and executions in which the at least one parameter to be secured is selected from a second distribution of parameter values, wherein the first distribution of parameter values is different from the second distribution of parameter values;measuring execution times at which the subject method reaches each of the identified intermediate points for each of the plurality of executions of the subject method; andperforming a statistical test on the measured execution times to determine whether execution times, for a given execution unit of the subject method, are distinguishable between the executions in which the at least one parameter to be secured is selected from the first distribution and the executions in which the at least one parameter to be secured is selected from the second distribution.

2. A testing method according to claim 1, wherein the intermediate points are identified so that the execution units exclude or have a lower density in one or more portions of the subject method in which no parameter to be secured is processed.

3. A testing method according to claim 1 or claim 2, wherein identifying the plurality of intermediate points comprises inserting a code portion at each intermediate point in source code of a program configured to perform the subject method.

4. A testing method according to claim 1 or claim 2, wherein identifying the plurality of intermediate points comprises inserting a code portion at each intermediate point in binary code of a program configured to perform the subject method.

5. A method according to claim 3, wherein the code portion is automatically inserted by a compiler during generation of binary code.

6. A method according to claim 1 , wherein identifying the plurality of intermediate points is performed by a processor during execution of a program configured to perform the subject method, wherein the processor is configured to measure and record a timing of operations performed by the processor during execution of the program.

7. A method according to any preceding claim, further comprising inserting a serialization barrier into binary code that is executed to perform the subject method, wherein, during execution of the binary code, the serialization barrier acts to separate execution of at least two of the execution units.

8. A method according to claim 1 or claim 2, wherein the subject method is performed by a device under test, wherein identifying the plurality of intermediate points in the subject method comprises identifying operations that the device under test performs at certain steps of the subject method.

9. A method according to claim 1 or claim 2, wherein execution of the subject method comprises simulation of performance of the subject method by a device under test.

10. A method according to claim 9, wherein identifying intermediate points comprises simulating waveforms corresponding to signals from one or more components of a device under test and identifying one or more intermediate points based on the simulated waveforms.

11. A method according to any preceding claim, wherein the first distribution is a distribution in which the first parameter takes a constant value.

12. A method according to any preceding claim, wherein the second distribution is a distribution in which the first parameter takes a value that is randomly selected from a range of values that the first parameter can take in the subject method.

13. A method according to any preceding claim wherein the subject method is at least one of: a cryptographic method and a machine learning method.

14. A method according to claim 13, wherein the at least one parameter to be secured comprises at least one of a secret parameter of a cryptographic method, hyperparameters of a machine learning model during training, personally identifiable information, and a payment credential.

15. An information processing apparatus for testing whether a subject method has a constant processing time, wherein the subject method processes at least one parameter to be secured, the information processing apparatus configured to:identify a plurality of intermediate points in the subject method, wherein portions of the subject method performed between adjacent pairs of the intermediate points form a plurality of execution units of the subject method;execute the subject method a plurality of times, wherein the executions of the method include executions in which the at least one parameter to be secured is selected from a first distribution of parameter values and executions in which the at least one parameter to be secured is selected from a second distribution of parameter values, wherein the first distribution of parameter values is different from the second distribution of parameter values;measure execution times at which the subject method reaches each of the identified intermediate points for each of the plurality of executions of the subject method; andperform a statistical test on the measured execution times to determine whether execution times, for a given execution unit of the subject method, is distinguishablebetween the executions in which the at least one parameter to be secured is selected from the first distribution and the executions in which the at least one parameter to be secured is selected from the second distribution.

16. A program that, when executed on an information processing apparatus, causes the information processing apparatus to perform a method according to any of claims 1

Images