Method for controlling the execution of a computer program

Abstract

A method for controlling the execution of a program run by a first computer, called the prover, by means of a second computer, called the verifier, wherein: S30) for each traced function (F_i) executed during program execution, from a set of traced functions, the prover detects the execution of the traced function (F_i) and records an identifier (Id_i) of the traced function; S40) the prover transmits to the verifier the identifiers (Id_i) of the traced functions that have been executed, in the same order as the execution order of the corresponding traced functions; S50) the verifier evaluates whether the sequence of traced functions associated with the traced function identifiers it has received constitutes a possible sequence of traced functions; and S90) the verifier triggers an action based on at least one result of the evaluation performed in step S50. Figure for the abstract: Figure 1

Description

Title of the invention: Method for controlling the execution of a computer program. TECHNICAL FIELD OF THE INVENTION

[0001] The invention relates to a method of controlling the execution of a computer program, in particular by remote attestation. STATE OF THE ART

[0002] A number of methods for controlling program execution by remote attestation (from the English 'Remote Attestation', or 'RA') are known. These methods have enabled universities and industry to improve the security of their computer systems.

[0003] However, commercially available products generally only allow the validation of static properties, such as the application footprint, and do not handle execution properties, such as correcting the program execution flow.

[0004] This limitation has led researchers to identify new approaches, including remote execution attestation, in English 'Runtime RA'. These approaches are illustrated for example by the following document Ref.1.

[0005] Ref.l: Toffalini, F., Losiouk, E., Biondo, A., Zhou, J., & Conti, M. (2018). “ScaRR: Scalable Runtime Remote Attestation for Complex Systems. » International Symposium on Recent Advances in Intrusion Detection.

[0006] Remote attestation is a procedure that allows the status of a first computer (the prover) to be verified remotely using a second computer, the verifier. The term 'computer' should be understood here very broadly, and in fact refers to any electronic device capable of executing a computer program. It can be a personal computer, a mobile phone, a machine with computing power (for example, part of the Internet of Things), etc.

[0007] To perform this verification, the verifier first sends a challenge to the prover, who responds with a report. The verifier then analyzes this report to determine whether the prover has been compromised. In known remote attestation methods, which are generally static, verification of the prover allows for the conclusion that specific hardware and software properties are intact (for example, that the prover has actually loaded the intended software).

[0008] However, these methods do not offer defense against attacks occurring during program execution. Among these attacks, control-flow attacks are particularly noteworthy. These attacks aim to modify the program's behavior even during its execution. To detect these attacks, which aim to modify the execution flow of a program run by the proving attacker, researchers have proposed remote execution flow attestation methods.

[0009] The ScaRR method proposed by document Ref.1 proposes such a method.

[0010] This approach advantageously allows, with the help of a remote verifier, the detection of modifications to the execution flow of a program executed by a prover.

[0011] However, this approach requires a specific compiler to modify the program's source code. It leads to adding calls to specific kernel functions that allow the application to signal certain events to the prover. These calls result in additional execution time due to frequent switching between kernel space and user space. The kernel used must be modified to provide these specific functions, which is not always possible on critical systems.

[0012] Finally, when a certificate request is sent, the provider starts executing the program to be certified. Depending on the nature of the program, this approach is not always feasible (for example, if the program is used to control the launch of a missile). Furthermore, sending several intermediate verification reports, while necessary for complex programs, introduces a significant dependence on a stable network connection. This last point cannot be guaranteed in mobile systems, which may be disconnected when the certificate request is received. Description of the invention

[0013] The present invention aims to remedy all or part of the disadvantages of the prior art mentioned above.

[0014] To this end, according to this disclosure, a method for controlling the execution of a program run by a first computer, called the prover, by means of a second computer, called the verifier, is proposed; the program being stored in the user space of the prover; a traced function being a function executable by the prover from among a predetermined set of functions of the prover; a reference bundle being a data structure available to the verifier from which it is possible to determine whether a sequence of traced functions is a possible sequence of traced functions, that is to say, a sequence of traced functions likely to be executed, in particular consecutively, during a conforming execution of the program; wherein the following operations are performed:

[0015] S30) during program execution, by running an application of record stored in kernel space, for each traced function executed during program execution, the prover detects the execution of the traced function and records an identifier of the traced function;

[0016] S40) the prover transmits to the verifier the identifiers of the plotted functions which were executed, in the same order as the order of execution of the corresponding plotted functions;

[0017] S50) using the reference beam, the checker evaluates whether a sequence of The plotted functions associated with the plotted function identifiers it has received, called the received sequence, constitute a possible sequence of plotted functions; and

[0018] S90) the checker triggers an action based on at least one result of the evaluation carried out at stage S50.

[0019] A traced function identifier here refers to any data that allows the identification of a traced function. A conformal program execution refers to a program execution that conforms to the intended or expected course of the program.

[0020] Advantageously, the execution control method defined above makes it possible to ensure that the order (or sequence) in which the plotted functions are executed by the program (and therefore, the elements are recorded) corresponds to what is expected of the program, without imposing any modification whatsoever on the program being executed.

[0021] This method therefore makes it possible to guarantee, to a large extent, that the program execution flow conforms to what is expected. Furthermore, it provides protection against code reuse attacks (from the English 'Retum Oriented Programming', or ROP) which modify the program's execution without altering its source code. Indeed, if the program's execution is modified, its execution flow (or execution trace) will be different. Thus, there will be a discrepancy between the observed execution and the expected execution.

[0022] Moreover, although the method leads to recording the execution trace of the program, it does not require modifying the source code of the program to be observed.

[0023] In certain embodiments, the transmission step S40 includes the transmission of a traced function identifier each time the execution of a traced function has been detected in step S30, and the evaluation step S50 is performed each time a traced function identifier is received by the verifier (except possibly during the first detection(s) of naturally occurring traced functions, in cases where the small number of detected traced functions does not make it useful to perform the evaluation step). Thus, each time a traced function identifier is received by the verifier, in step S50 the verifier evaluates whether a received sequence of traced functions corresponds to at least one possible sequence of traced functions. If this check leads the checker to conclude that the received sequence does not correspond to any possible sequence, he goes directly to step S90.

[0024] If at step S90 the verifier concludes that the received sequence of traced functions does not correspond to any possible sequence (i.e. a sequence of traced functions that corresponds to a compliant execution of the program), the verifier triggers an action based on this conclusion: in general, it interrupts the execution of the program, and / or sends an alert message, and more generally any appropriate action following the detection of the fact that the execution flow of the program has not been compliant with the expected execution.

[0025] The number of traced functions included in the received sequence verified in step S50 may vary. The received sequence verified in step S50 contains at most (and preferably) all the traced functions executed since the program was launched.

[0026] Furthermore, although preferably the transmission of identifiers (step S40) and the evaluation (step S50) are carried out shortly after each detection of the execution of a plotted function, these steps can be carried out at a lower frequency, for example at regular intervals, or even only once, once the execution of the program is finished.

[0027] Advantageously, the method following this disclosure can be implemented with a standard kernel. Furthermore, this method does not require the use of a specific processor for the implementation of the invention.

[0028] In certain embodiments, the predetermined set of functions of the prover includes or consists of functions selected from system call functions, read / write operations in a memory of the prover, and functions for executing code stored in a predetermined area of ​​a memory of the prover.

[0029] The traced functions can thus be system call functions, with / without parameter values, functions of interaction with a communication network to which the prover is connected, write or read operations in memory (possibly in a specific part of memory), execution of a code stored at a specific address, etc.

[0030] The parameter values ​​mentioned above are input data for the execution of the plotted functions.

[0031] For example, in the reference bundle, an identifier can be the identifier of a system call and include at least one value of a parameter of the system call in question. More precisely, for example, the system call can be a write function. In this case, the traced function, which is therefore the write function, must be told as input in which file the result should be written: It is therefore necessary to provide the input function, as a parameter value, the name of the directory in which the result should be written.

[0032] Different structures can be adopted for the reference beam.

[0033] The reference beam can thus simply be a list of possible sequences execution of the plotted functions.

[0034] However, in other embodiments the reference bundle has a graph structure, in which each node is associated with a plotted function.

[0035] In this case, at step S50, the verifier can for example evaluate whether the received sequence constitutes a possible sequence of traced functions by verifying that said received sequence corresponds to a possible path of traversing the reference beam.

[0036] On the other hand, to increase the reliability of the execution control method, it is possible to take into account the input parameters of the plotted functions.

[0037] Thus in certain implementation modes, for at least one plotted function called parameterized plotted function, the identifier of the parameterized plotted function further includes a value of at least one input parameter of said parameterized plotted function.

[0038] It can then be provided, during the evaluation step S50, when the verifier evaluates whether the received sequence constitutes a possible sequence of plotted functions, whether at least one identifier received at step S40 is the identifier of a parameterized plotted function, that the verifier determines whether the value of said at least one input parameter included in the identifier recorded at step S30 for the considered execution of the parameterized plotted function corresponds to the value of said at least one input parameter for the corresponding execution of the parameterized plotted function in the possible sequence of plotted functions.

[0039] In some implementation modes, the method is secured by recording the identifiers in a TPM module.

[0040] A TPM module refers to a Trusted Platform Module. It is a hardware component, such as an electronic chip, used in computer systems to enhance security.

[0041] The TPM module provides various security features, including secure storage of information (such as encryption keys, etc.).

[0042] In certain implementation modes, the TPM module can apply a proof function to sequences of identifiers recorded in step S30, thereby creating proofs of execution of sequences of traced functions, which will serve to verify that these sequences have actually been executed.

[0043] Thus in certain implementation modes, the prover includes a trust platform module, or TPM module; during step S30, the identifiers of traced functions are recorded by the prover in the TPM module;

[0044] The method further comprises the following steps S60, S70 and S80:

[0045] S60) the TPM module, from a sequence of identifiers recorded in the step S30, called the recorded sequence, calculates a sequence proof, called the recorded sequence proof (Prenreg), of said recorded sequence; a sequence proof being a data obtained by a proof calculation function from a sequence of identifiers, the proof calculation function being such that different sequences of identifiers have different proofs;

[0046] S70) the TPM transmits the recorded sequence proof to the verifier;

[0047] S80) the checker calculates a received sequence proof using the function of calculates proof, from the received sequence, and checks whether the received sequence proof is equal to or not the recorded sequence proof.

[0048] In some implementation modes, at step S60, the proof is calculated by applying a hash function to a name or string associated with a traced function.

[0049] In some embodiments, at step S60, the proof is calculated by applying a hash function jointly to a name or string associated with a traced function and to a hash or proof previously calculated.

[0050] In certain embodiments, at step S60, after calculating a first proof, calculated for example from a hash of the binary code of the program, or from the first traced function identifier recorded at step S30, the following proofs are calculated successively from the following traced function identifiers recorded successively at step S30, by applying the hashing function jointly to a name or string of characters associated with the traced function just executed and with the last proof previously calculated.

[0051] In certain implementations, for at least one plotted function, referred to as a parameterized plotted function, the identifier of the parameterized plotted function includes a value of at least one input parameter of said parameterized plotted function. Thus, this value of said at least one input parameter will be used in the proof calculation by the TPM in step S60 and by the verifier in step S80. Consequently, the verification performed in step S90 will include the verification of the equality of the input parameters for the plotted function(s) that are parameterized.

[0052] In some embodiments, the hash of an executable of the program to be deployed on the prover is available to the verifier; before the execution of the program, the prover transmits to the verifier a hash of an executable of the program to be executed; and the method further includes a verification step S10, in which the verifier checks whether the hash of the executable to be executed received from the prover is equal to the hash of the executable to be deployed on the prover.

[0053] By extension, the program execution control method according to this disclosure can be extended to the control of a set of programs, including relatively unreliable programs.

[0054] Thus, a second object of this disclosure relates to a method of controlling a plurality of programs in which:

[0055] A. Each of the programs in said plurality of programs is controlled by implementing a control method as previously described; and

[0056] B. a global control action is triggered based on the control actions triggered respectively for each of the programs of said plurality of programs. BRIEF DESCRIPTION OF THE FIGURES

[0057] Other advantages, purposes and particular features of the present invention will become apparent from the following non-limiting description of at least one particular embodiment of the devices and methods of the present invention, with reference to the accompanying drawings, in which:

[0058] [Fig. 1] is a block diagram schematically representing the implementation of a method according to this disclosure in a program execution control system;

[0059] [Fig.2] is a flowchart showing an example of implementation of methods according to this disclosure;

[0060] [Fig.3] is a schematic representation of a first execution graph of a program;

[0061] [Fig.4] is a schematic representation of the different identifiers, in the form of hashes, calculated during the implementation of a method according to this disclosure; and

[0062] [Fig.5] is a schematic representation of a second program execution graph. DETAILED DESCRIPTION OF THE INVENTION

[0063] Specific implementation methods according to this disclosure will now be presented as non-limiting examples of implementation.

[0064] Figure 1 schematically represents the components of a program execution control system, namely: - a first computer, or prover, on which a program whose correct execution one seeks to verify must be run; and - a second computer, or verifier, usually remote from the first, which is used to verify the conforming execution of the program by implementing the attestation method according to this disclosure.

[0065] In a manner known per se, the memory space of the proofer is divided into a user space and a kernel space. The user space is the portion of virtual memory of the system where the user's programs (applications) run. The kernel space is the portion of memory reserved for the kernel of the operating system—that is, the code that controls direct access to the hardware, manages memory and processes, and more generally, performs the basic functions of the operating system.

[0066] The program whose execution is to be controlled is therefore stored in user space.

[0067] During its execution, this program performs a number of functions. In the method following this disclosure, some of these functions are traceable functions. For example, in the example shown here, system calls are traceable functions. A system call, or "syscall", is a request made by a user-space program to the operating system (OS) to perform a specific action that only the OS kernel can execute.

[0068] During program execution, each time a plotted function is performed, an identifier associated with the plotted function executed is recorded.

[0069] The traced functions depend on the implementation method but generally include system calls, memory read / write operations, and / or the execution of code stored in one or more predetermined memory areas. Thus, the traced functions may include operations that involve information exchange between user space and kernel space.

[0070] The prover includes a TPM module for recording certain information.

[0071] The general framework for implementing the method according to this disclosure is presented schematically in [Fig.1].

[0072] The method according to this disclosure will be presented in the case of a very simple program, by way of example, the code of which is transcribed below in Table 1. This program displays the text "Hello World!" in the console of the prover.

[0073] In this example, system calls are taken as examples of traced functions, but any other function that could be traced in the process according to this disclosure could have been used while remaining within the scope of this disclosure.

[0074] -----------------

[0075] int puts(const char *s);

[0076] int main(int argc, char *argv[]) {

[0077] puts("hello world");

[0078] return 0;

[0079] }

[0080] Table 1: Pr Program

[0081] The implementation of a method according to this disclosure to attest to the proper execution of this program will now be presented.

[0082] During a preliminary step S0, from the source code of this program, the verifier determines the reference bundle of this program, a bundle which will then be used to verify the correct execution of the program.

[0083] This reference beam can be determined by any appropriate method: for example using a source code analysis tool, or by observing an execution of the program (e.g. with strace (trademark)), etc.

[0084] In the example presented, the execution of the program leads to the successive generation of three system calls: "execve" (triggering the execution of the program), "write" (writing to a file descriptor) and "exit" (end of the execution of the program), which are three traced functions.

[0085] Consequently, the program has the call graph of [Fig.3]. This graph has three nodes execve, write and exit, connected by two directed links, namely from execve to write and from write to exit.

[0086] From this graph, we can deduce all possible sequences of the program's traced functions that correspond to compliant executions of the program. In this case, we can only identify a single sequence, consisting successively of the three traced functions (each being a system call): execve, write, and exit.

[0087] The graph in [Fig.3] therefore constitutes a reference bundle within the meaning of this disclosure.

[0088] In the general case, from the reference bundle, one can determine a number, sometimes large, of possible sequences of traced functions executed by the program considered during a conformal execution of the latter.

[0089] It should be noted that even if the source code of the program to be observed is not available, it may still be possible to generate the reference bundle. For example, the program can be executed on a trusted system, and the various traced functions performed by the program can be recorded.

[0090] Furthermore, in step S0, in the example presented, the binary hash H to be installed for the program executable (the executable code) that is to be deployed on the prover is calculated and stored in the verifier. In some cases, it is also transmitted to the prover to allow for additional verification in step S10 described later.

[0091] After step S0, a preliminary step which may take place long before any execution of the program, the execution of the program to be evaluated, the evaluation of Its execution, and the launching of an action following this evaluation, then take place in the following manner.

[0092] Step S10 (optional) - Verification of the program executable hash

[0093] Step S10 is an optional step that can be performed if the program to execute has not yet been installed on the prover.

[0094] We consider the case where, nevertheless, the program has already been transmitted to the prover, in the form of an executable.

[0095] Before installing this executable, the following preliminary check is carried out.

[0096] The prover first calculates the hash Hbinaire_installation of this executable.

[0097] If the prover has received the Hbinary hash to install from the program executable, the prover then checks that the hash Hbinaire_instauation is equal to the hash HbinaireàinstaUer of the code that was planned to be deployed on the prover.

[0098] If there is a difference between the two hashes, the program installation is not executed. Otherwise, the program is installed.

[0099] In other implementation modes, the hash calculated by the prover, Hhinairejnstaiiation, is transmitted to the verifier.

[0100] It is then the verifier that verifies (or will verify) that the hash Hbinaire_instauation is equal to the hash Hbinaireàinstaner of the code that was planned to be deployed on the prover and that, if there is a difference between the two hashes, will trigger a corrective action at the S90 step described later.

[0101] The program is then executed. Steps S20 to S90 are then carried out.

[0102] Step S20 (optional) - Request for verification by the verifier

[0103] In certain implementation modes of the execution control method according to this disclosure, verification of the program's conforming execution is not systematic, and on the contrary is evaluated conditionally.

[0104] In some cases, for any execution of the program, step S30 is performed.

[0105] In this case, at step S20, if for a given execution of the program the verifier wishes to perform a program execution check, it sends a verification request to the prover. This verification request (step S20) can then take place before, during, or after the program execution; it triggers the execution of steps S40 to S90 of the program.

[0106] In other embodiments, the S30 recording step is only carried out if the verification request (step S20) has been carried out before the execution of the program, i.e. only if the verification request for program execution by the verifier has been previously sent to the prover.

[0107] During program execution, the prover executes the recording application stored in its kernel space. This application is configured to trace (i.e., to detect) the execution of the traced functions, and to record the identifier of each of the traced functions whose execution has been detected.

[0108] It is assumed that during the execution of the program, a certain number of plotted functions F_i, i=l.. .N are executed successively (A plotted function can naturally be executed possibly several times).

[0109] Step S30 - Recording the identifier Id i of the plotted function Fi

[0110] At step S30 (which lasts for the entire duration of program execution), the prover, using the recording application, detects any execution of a traced function. Each time the execution of a traced function F_i is detected, the prover records the identifier Id_i of the detected traced function in the TPM. This identifier is data that allows the traced function to be identified.

[0111] Recording of the traced function identifier may take place immediately after the execution of the function, or be deferred.

[0112] The identifier Id_i of the plotted function F_i is recorded in a file called a 'log file'.

[0113] Importantly, the recording in the log file of the traced function identifiers is carried out in such a way as to preserve information indicating the order in which the traced functions were executed. Thus, the sequence of recorded traced function identifiers, or recorded sequence, is representative of the order in which these functions were executed.

[0114] The identifier Id_i of the plotted function can take many different forms.

[0115] Such an identifier may be, or at least may include, for example, the name (i.e. any identifier) ​​of the plotted function to which it is associated. Conversely, any data from which the name or any identifier of a plotted function can be obtained can be used as the identifier of that plotted function.

[0116] Such an identifier may be plain data, or encrypted data, for example in the form of a hash such as a hash of the name of the associated plotted function.

[0117] In the latter case, a person (who must necessarily have the hashing function) can see that the identifier of the traced function is equal to the hash of a specific traced function and thus identify the latter function.

[0118] Depending on the importance attributed to the conforming execution of the program, the method according to this disclosure can be implemented in different ways, by varying the frequency of checks.

[0119] In particular, steps S40 to S90 of the method can be executed either continuously, or periodically, or only once when the execution of the program is complete.

[0120] When these steps are executed continuously, they are executed each time a plotted function F_i is executed.

[0121] When these steps are executed periodically, this generally means that these steps are executed when several plotted functions have been executed. These steps can then be triggered either at regular (time) intervals, or when a certain number of plotted functions have been executed, or when certain specific, predetermined plotted functions are executed, etc.

[0122] Therefore, at step S40, the transmission of traced function identifiers can be done in a single transmission, in grouped transmissions, or 'continuously'. In the latter case, an identifier is transmitted each time the execution of a traced function is detected.

[0123] For the sake of simplicity, this document primarily refers to the sending of "traced function identifiers" (plural). However, it should be understood that sending traced function identifiers may only concern a single identifier.

[0124] We now consider, as an example, the case of 'continuous' execution.

[0125] Step S40 - Transmission to the verifier of the identifier of the plotted function

[0126] At step S40, the prover transmits to the verifier the identifier Id_i of the traced function that has been detected.

[0127] In some implementation modes, to guarantee the authenticity of the transmitted identifiers, the identifier (or identifiers) sent by the TPM is or are signed by one or more private keys recorded in the TPM.

[0128] Step S50 - Conformity evaluation of the received sequence of traced functions

[0129] At step S40, the verifier received the identifiers Id_i of the entire sequence of traced functions that have been detected since the beginning of program execution.

[0130] Depending on the implementation method, it then selects all or part of this sequence of traced functions (by applying a selection rule), thus constituting a sequence on which the evaluation will be performed; this sequence is called the received sequence. The received sequence can consist, for example, of the list of all executed traced functions whose identifier has been received, or only the last N of these functions, or any other suitable list.

[0131] In the example shown, the identifier of the detected traced function is transmitted signed to the verifier. The verifier therefore begins by verifying that the signature associated with the identifier is indeed valid: it deduces from this that the received identifier has not been modified and does indeed originate from the TPM.

[0132] The verifier then evaluates whether the received sequence actually corresponds to a possible sequence of traced functions that can be deduced from the reference bundle. In other words, it verifies whether the identifiers Id_i received from the prover and corresponding to the received sequence can be associated, in the same order, with a sequence of traced functions executed successively during a conforming execution of the program.

[0133] If the checker does not identify any sequence of traced functions from the reference bundle that corresponds to the received sequence, it triggers an error message to signal a non-compliant execution of the program.

[0134] Otherwise, it proceeds to the additional (optional) verification steps S60-S80.

[0135] Step S60 - Calculation and recording of sequence proof by the TPM

[0136] The purpose of the optional additional verification of steps S60-S80 is to ensure The TPM verifies that the received sequence of traced functions, which was taken into account in the S50 verification step, is indeed the sequence of traced functions that were actually executed. This additional verification is performed using the TPM.

[0137] Initially, during step S60, the TPM determines among the identifiers recorded in step S30 those which correspond to the received sequence, by applying the same selection rule as in step S50.

[0138] From these identifiers, the TPM then calculates a Prenreg recorded sequence proof. This proof is used to verify that the received sequence from which the verifier performed its evaluation in step S50 is indeed identical to the corresponding recorded sequence containing the traced functions that were executed by the prover and recorded by the TPM. Using the same selection rule, the sequence of traced functions that serves as the basis for calculating the Prenreg recorded sequence proof by the TPM corresponds to the one used as the basis for calculating the Prrec received sequence proof by the verifier (this calculation will be presented later).

[0139] Thus, depending on the implementation method, the calculated proof (Prenreg or Prrec) can take into account a sequence of executed traced functions of varying length. This proof can also take into account only the last two recorded traced functions. Verification of successive proofs makes it possible to validate the entire observed sequence of functions executed by the program.

[0140] In some implementation modes, the proof is a function of the set of traced functions executed since the program was launched.

[0141] Any type of proof calculation function can be used to perform step S60. The proof calculation function only needs to have the property that the proofs calculated by this function for two different sequences of plotted functions, that is different.

[0142] Step S70 - Transmission to the Pr TPM sequence proof verifier

[0143] At step S70, the TPM transmits the recorded sequence proof to the verifier Prenreg calculated at step S60.

[0144] In general, whenever a new plotted function has been identified and a Prenreg recorded sequence proof has been calculated, this Prenreg proof is transmitted without delay to the verifier.

[0145] However, the proofs can be transmitted only at the end of execution, or even in packets; any transmission rate is conceivable.

[0146] Step S 80 - Verification of the sequence by the verifier

[0147] At step S80, the verifier calculates the proof Prrec of the received sequence. It therefore performs the same calculation as that performed by the TPM at step S60, but based on the received identifiers Id_i as input, which may differ from the identifiers recorded by the TPM.

[0148] The verifier then performs the following check to verify that the sequence of operations used to confirm the program's correct execution in step S50 is indeed the traced sequence of operations actually performed by the prover: it verifies that the recorded sequence proof Prenreg calculated by the TPM is equal to the proof Prrec it calculated. If these proofs are not equal, this means that the sequence of identifiers on which the verifier relied in step S50 to perform the verification is incorrect. A corrective action must therefore be initiated. Stage S90 - Final Action

[0149] At step S90, the verifier triggers an action based on a result of the conformity assessment carried out at step S50, taking into account, where applicable, the additional verification carried out at step S80.

[0150] In particular, if a difference has been detected at step S80, the verifier concludes that the received sequence of traced functions is not the one that was actually executed by the prover, and triggers an action (for example, issues a message) to take this finding into account.

[0151] Conversely, if neither of the S50 and S80 verification steps detected an error, the verifier concludes that the program ran normally. It may also send a message indicating that the program executed correctly up to the current operation.

[0152] Implementation of the execution control method using a graph

[0153] In some embodiments, the reference beam has a graph structure.

[0154] The reference bundle preferably has a graph structure in which each node is associated with a plotted function.

[0155] For example, for the program presented above, the reference bundle has the graph structure shown in [Fig.3]. The nodes of this graph are associated respectively with the plotted functions execve, write and exit.

[0156] During program execution, following each execution of a plotted function, steps S40 to S90 are executed.

[0157] At step S30, the identifier Id_i of the executed plotted function F_i is recorded in the TPM. At step S40, it is transmitted to the verifier.

[0158] At step S50, the verifier constructs the received sequence; using the reference beam, it determines whether there is at least one possible sequence that corresponds to the received sequence.

[0159] If at least one such possible sequence is identified, it is assumed that the execution of the function F_i at iteration i is compliant; the result of the verification is positive.

[0160] Conversely, if no possible sequence is identified, the checker produces a negative evaluation result.

[0161] If the evaluation result is positive, the additional verification of steps S60 to S80 is then carried out. An example of a proof calculation is illustrated by [Fig.4].

[0162] During the implementation of the method, at each execution of a traced function, two proofs are calculated: on the one hand, a proof of recorded sequence Prenreg_i is calculated by the TPM at step S60, based on the recorded sequence (i.e. based, directly or indirectly, on all the identifiers of the traced functions of the recorded sequence); and on the other hand, a proof of received sequence Prrec_i is calculated by the verifier at step S80 based on the received sequence.

[0163] The calculated proofs Prenreg_i and Prrec_i are then compared: this verifies that the received sequence of traced functions taken into account by the verifier in step S50 is indeed identical to the recorded sequence of traced functions. This latter sequence, the recorded sequence, is based on the TPM's recordings and is therefore assumed to represent exactly the traced functions that were actually executed during program execution.

[0164] The Prenreg_i and Prrec_i proofs can be calculated in the following manner.

[0165] During the execution of the first plotted function that is executed, proofs The initials Prenreg0 (or resp Prrec0) are calculated. They can be calculated, for example, on the basis of the binary code of the installed program P, or for example from the hash Hbinairejnstaiié of the binary code of the installed program, or something else.

[0166] Then, following each detection of the execution of a traced function F_i, at step S50 the TPM calculates a new proof of recorded sequence Prenregi and at step S70 the verifier calculates a new proof of received sequence Prrec_i.

[0167] Each of these proofs (Prenreg_i, Prrec_i) is a function of both the last calculated proof (Prenreg_i-1, Prrec_i-1) (the proof calculated following the last detection of the execution of a traced function, F_i-1) and the identifier of the traced function F_i.

[0168] Thus, by taking into account successively all the traced functions executed, the algorithm takes into account all the identifiers of the traced functions that have been detected, to construct the proofs, respectively Prenreg_i and PrrPP i, step by step.

[0169] Numerous proof calculation functions are conceivable. For example, for each detection of the execution of a plotted function F_i, the TPM or the verifier respectively concatenates the proof, Prenregi-1 or Prrec_i-1 respectively, calculated during the previous iteration with the identifier Id_i associated with the current iteration i. The TPM (or the verifier respectively) then calculates the hash of this concatenation to obtain the new proof Prenreg_i, or Prrec_i respectively. Thus, following the detection of the execution of the function F_i, the TPM and the verifier respectively obtain:

[0170] Prenreg_i = hash (Concatener(Prenreg_i- IJd i)) and Prrec_i = hash (Concatener(Prreci-1,Id_i))

[0171] where Concatener is the concatenation function.

[0172] In the example shown here, the identifiers (Id_i) are the strings 'execve', 'write' and 'exit' for values ​​i = 1, 2 and 3 respectively.

[0173] The successive proof values ​​are therefore calculated by the algorithm indicated above in the following manner (in the case, for example, of the TPM):

[0174] i=l. For the first identifier Id1: Prenregl = hash(Concatener(Hbinaireinstaué, 'Execve')) because IdLogl = 'Execve'.

[0175] i=2. Prenreg2 = hash (Concatener(Prenregl,'Write')) because Id 2= 'Write'.

[0176] i=3. Prenreg3 = hash (Concatener(Prenreg2,'Exit')) because Id 3= 'Exit'.

[0177] At step S80, the verifier checks that the PrrPP i proof that it calculated corresponds to the Prenreg_i proof calculated by the TPM.

[0178] The procedure presented above leads to successively carrying out the operations of recording, concatenation and hashing which are shown by [Fig.4].

[0179] Advantageously, this procedure allows confirmation of the sequence of traced functions executed during the execution of the program.

[0180] Verification taking into account the parameters of the plotted functions

[0181] An implementation variant of the S50 evaluation step and / or the steps of S60-S80 verification is illustrated by [Fig.5].

[0182] These variants allow for more in-depth control of the program's conformal execution because, at least for some of the traced functions, in addition to the identifiers of these functions, one or more parameter values ​​of these functions are taken into account in the control performed.

[0183] In this embodiment, the reference beam is configured such that, when used to determine whether a sequence of plotted functions is a possible sequence of plotted functions, and whether this sequence includes at least one plotted function that is itself a function of one or more parameters, it is also possible to determine whether a value of said one or more parameters is a normal value for this or these parameters during the execution of the function in question during the execution of the possible sequence of plotted functions in question.

[0184] In this implementation mode, during program execution, at step S30, for each plotted function of one or more parameters, the function identifiers that are recorded contain not only the name of the function, but also contain the value(s) of the input parameter(s) of the function when the plotted function in question was executed.

[0185] In the implementation mode presented here, during the S30 recording step, for each executed plotted function, the recorded identifier for the function contains both the name of the plotted function, and the values ​​of the input parameters of the function when it was executed.

[0186] During the S50 evaluation step, the verifier evaluates whether a received traced function sequence, associated with the received traced function identifiers, corresponds to a possible traced function sequence that can be deduced from the reference bundle.

[0187] To perform this evaluation, in certain embodiments, the verifier assesses whether there exists a possible sequence such that each traced function identifier in the received sequence corresponds to a traced function identifier in the possible sequence. In this evaluation, to determine that a traced function identifier in the received sequence corresponds to a traced function identifier in the possible sequence, the verifier checks not only that the traced function names for the two identifiers match, but also that the recorded parameter values ​​for the two identifiers also match.

[0188] Consequently, the verification of the program execution at step S50 includes the verification, for each of the plotted functions whose parameters are taken into account, that the value(s) of this / these parameter(s) during the execution of the plotted function in question correspond to the value(s) of these same parameters in a possible execution sequence deduced from the reference bundle.

[0189] As an alternative, or in addition, the verification of the values ​​of the input parameters of the executed plotted functions can be done during the verification steps S60-S80.

[0190] In this case, it is sufficient to use a proof calculation function which takes into account, in the identifiers of the executed traced functions, not only the name (or string of characters) identifying the function, but also the value or values ​​of the input parameters of the executed traced functions.

[0191] Thus, the verification of two proofs PrenregJ and PrrecJ at step S80 will only give a positive result if not only do the names of the executed traced functions correspond, but also the values ​​of input parameters, for the considered executions of the executed traced functions, also correspond (are equal).

[0192] A concrete example will now be developed.

[0193] In this example, the first system call made by the program P is the traced function 'execve'. This function takes as input two parameters, namely the name and memory address of the directory where the code of the execve function is stored.

[0194] In the reference bundle, i.e. the graph shown in [Fig.5], not only is the name of the plotted function recorded for each node, but also the associated parameter values.

[0195] Thus, for example, the first node, associated with the function 'execve', which plays the role of the identifier, includes the name of the function 'execve', but also the values ​​that the two parameters, respectively ". / hello" and "0x7ffdff359360", must take during a proper execution of the program.

[0196] When implementing the algorithm presented above to determine whether the observed sequence of plotted functions is a normal sequence of processed functions, these parameters are taken into account, in particular during steps S60-S80.

[0197] Thus, at step S80, to calculate the Prenreg_l proof for the first executed traced function, the function 'execve', the verifier concatenates the initialization value Hhinain. itlstaiié. the name of the traced function 'execve', and the parameter values: '. / hello' and '0x7ffdff359360': Prenregl = hash( ConcatcnciîHh,,ENII._,,,.,..,11,-.. 'Execve', . / hello', '0x7ffdff359360')

[0198] The verifier then calculates the following two proofs: Prenreg2 = hash (Concatenate(Prenregl,'Write','hello, World !\n')) and Prenreg3 = hash (Concatenate(Prenreg2,'Exit', '0' )).

[0199] Each of the calculated proofs is therefore a function not only of the names of the executed plotted functions, but of their input parameters.

[0200] Thanks to this, the verification carried out in steps S60-S80 makes it possible to verify not only the execution in the desired order of these functions, but also that the values ​​of the input parameters of these functions had values ​​conforming to expectations.

Claims

1. Demands Method of controlling the execution of a program run by a first computer, called the prover, by means of a second computer, called the verifier; the prover includes a trust platform module, or TPM module; the program being stored in the user space of the prover; a traced function (F_i) being a function executable by the prover from among a predetermined set of functions of the prover; a reference bundle being a data structure available to the verifier from which it is possible to determine whether a sequence of traced functions is a possible sequence of traced functions, that is to say a sequence of traced functions likely to be executed, in particular consecutively, during a conforming execution of the program; in which the following operations are performed: S30) during a program execution, by executing a recording application stored in kernel space, for each traced function (F_i) executed during the program execution, the prover detects the execution of the traced function (F_i) and records an identifier (Id_i) of the traced function in the TPM module; S40) the prover transmits to the verifier the identifiers (Id_i) of the traced functions that have been executed, in the same order as the order of execution of the corresponding traced functions; S50) using the reference beam, the verifier evaluates whether a sequence of traced functions associated with traced function identifiers that it has received, called the received sequence, constitutes a possible sequence of traced functions; S60) the TPM module, from a sequence of identifiers recorded in step S30, called the recorded sequence, calculates a sequence proof, called the recorded sequence proof (Prenreg), of said recorded sequence, a sequence proof being a data obtained by a proof calculation function from a sequence of identifiers, the proof calculation function being such that different sequences of identifiers have different proofs; S70) the TPM transmits the recorded sequence proof to the verifier; S80) the verifier calculates a received sequence proof (Prrec_i) using the proof calculation function, from the received sequence, and checks whether the received sequence proof (Prrec_i) is equal or not to the recorded sequence proof (Prenreg_i); and S90) the verifier triggers an action based on at least one result of the evaluation performed in step S50 and the verification performed in step S80.

2. A method of execution control according to claim 1, wherein the reference bundle has a graph structure, in which each node is associated with a plotted function; and at step S50, the verifier evaluates whether the received sequence constitutes a possible sequence of plotted functions by verifying that said received sequence corresponds to a possible path of traversing the reference bundle.

3. Execution control method according to claim 1 or 2, wherein for at least one plotted function said parameterized plotted function, the identifier of the parameterized plotted function further includes a value of at least one input parameter of said parameterized plotted function; and at evaluation step S50, when the verifier evaluates whether the received sequence constitutes a possible sequence of plotted functions, whether at least one identifier received at step S40 is the identifier of a parameterized plotted function, the verifier determines whether the value of said at least one input parameter included in the identifier recorded at step S30 for the considered execution of the parameterized plotted function corresponds to the value of said at least one input parameter for the corresponding execution of the parameterized plotted function in the possible sequence of plotted functions.

4. A method of execution control according to any one of claims 1 to 3, wherein said predetermined set of provers' functions comprises or consists of functions selected from system call functions, read / write operations in a provers' memory, and functions execution of a code stored in a predetermined area of ​​a memory of the prover.

5. Execution control method according to any one of claims 1 to 4, wherein at step S60, the proof (Prenreg) is calculated by applying a hash function to a name or string associated with a traced function.

6. Execution control method according to claim 5, wherein in step S60, the proof (Prenreg) is calculated by applying a hash function jointly to a name or string associated with a plotted function and a hash or proof previously calculated.

7. Execution control method according to claim 6, wherein at step S60, after a first proof has been calculated, for example from a hash of a binary code of the program, or from the first traced function identifier recorded at step S30, the following proofs are calculated successively from the following traced function identifiers recorded successively at step S30, by applying the hash function jointly with a name or string of characters associated with the traced function just executed and with the last proof previously calculated.

8. A method of execution control according to any one of claims 1 to 7, wherein for at least one plotted function referred to as a parameterized plotted function, the identifier of the parameterized plotted function includes a value of at least one input parameter of said parameterized plotted function.

9. A method of execution control according to any one of claims 1 to 8, wherein the hash of an executable of the program to be deployed on the prover is available to the verifier, prior to execution of the program, the prover transmits to the verifier a hash of an executable of the program to be executed; and the method further comprises a verification step S10, in which the verifier checks whether the hash of the executable to be executed received from the prover is equal to the hash of the executable to be deployed on the prover.

Images