Method of controlling the execution of a computer program

Abstract

Method for controlling the execution of a program executed by a first computer, called the prover, by means of a second computer, called the verifier, in which: S30) for each traced function (F_i) executed during the execution of the program, among 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 which have been executed, in the same order as the order of execution of the corresponding traced functions; S50) the verifier evaluates whether the sequence of traced functions associated with traced function identifiers which it has received constitutes a possible sequence of traced functions; and S90) the verifier triggers an action depending on at least one result of the evaluation carried out in step S50. Figure for 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 for controlling the execution of a computer program, in particular by remote certification. STATE OF THE ART

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

[0003] However, available commercial products generally only allow validation of static properties, such as application fingerprinting, and do not handle runtime properties, such as correctness of program execution flow.

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

[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 very broadly here, 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 means (for example, part of the Internet of Things), etc.

[0007] To perform this verification, the verifier first sends a challenge to the prover, which 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, the verification of the prover allows one to conclude on the integrity of specific hardware and software properties (e.g., the prover actually loaded the intended software).

[0008] However, these methods do not offer any defense against attacks occurring during the execution of a program. Among these latter attacks, we distinguish in particular "control-flow" type attacks which aim to modify the behavior of the program even during its execution. To detect these latter attacks aimed at modifying the execution flow of a program executed by the prover, researchers have proposed methods of remote attestation of execution flow.

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

[0010] This approach advantageously makes it possible, using a remote verifier, to detect 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 cause 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 an attestation request is sent, the prover starts the execution of the program to be attested. Depending on the nature of the program, this approach is not always feasible (one can think for example of the case where the program is used to control the launch of a missile). Finally, sending several intermediate verification reports, although necessary in the context of complex programs, introduces a significant dependency on a stable network connection. This last point cannot be guaranteed in mobile systems, which may be disconnected at the time the attestation request is received. Statement of the invention

[0013] The present invention aims to remedy all or part of the drawbacks of the state of the art cited above.

[0014] For this purpose, according to the present disclosure, a method is proposed for controlling the execution of a program executed by a first computer, called the prover, by means of a second computer, called the verifier; the program being recorded in the user space of the prover; a traced function being a function executable by the prover from a predetermined set of functions of the prover; a reference beam 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 capable of being executed, in particular consecutively, during a compliant execution of the program; in which the following operations are carried out:

[0015] S30) during execution of the program, by executing an application kernel-space-recorded record, 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 traced functions which were executed, in the same order as the execution order of the corresponding traced functions;

[0017] S50) using the reference beam, the verifier evaluates whether a sequence of traced functions associated with traced function identifiers that it has received, called received sequence, constitutes a possible sequence of traced functions; and

[0018] S90) the verifier triggers an action based on at least one result of the assessment carried out in step S50.

[0019] A traced function identifier herein means any data that allows a traced function to be identified. A compliant execution of the program means an execution of the program 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 traced functions are executed by the program (and therefore, the elements are recorded) corresponds to what is expected of the program and this, without imposing the slightest modification of the executed program.

[0021] This method therefore makes it possible to guarantee, to a large extent, that the program execution flow is indeed in accordance with what is expected. In addition, it makes it possible to protect against code reuse attacks (from the English 'Retum Oriented Programming', or ROP) which modify the execution of the program without modifying the source code of the latter. Indeed, if the execution of the program is modified, its execution flow (or execution trace) will be different. Thus, there will be a divergence between the observed execution and the expected execution.

[0022] Furthermore, 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 comprises 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 carried out each time a traced function identifier is received by the verifier (except possibly during the first detection(s) of naturally traced functions, in the case where the small number of detected traced functions does not usefully allow the evaluation step to be carried out). Thus each time a traced function identifier is received by the verifier, in step S50 the latter evaluates whether a received sequence of traced functions corresponds to at least one possible sequence of traced functions. If this verification leads the verifier to conclude that the received sequence does not correspond to any possible sequence, it directly passes 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 was not 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 comprises at most (and preferably) all of the traced functions executed since the launch of the program.

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

[0027] Advantageously, the method according to the present disclosure can be implemented with a standard kernel. In addition, this method does not require the use of a specific processor for the implementation of the invention.

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

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

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

[0031] For example, in the reference beam, an identifier can be the identifier of a system call and include at least one value of a parameter of the system call considered. More precisely, for example, the system call can be a write function. In this case, it is necessary to indicate as input to the traced function, which is therefore the write function, in which file the result must be written: It is therefore necessary to provide to the function as input, as 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 traced functions.

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

[0035] In this case, in 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 travel of 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 traced functions.

[0037] Thus in certain implementation modes, for at least one traced function called parameterized traced function, the identifier of the parameterized traced function further includes a value of at least one input parameter of said parameterized traced 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 traced functions, if at least one identifier received in step S40 is the identifier of a parameterized traced function, that the verifier determines whether the value of said at least one input parameter included in the identifier recorded in step S30 for the execution considered of the parameterized traced function corresponds to the value of said at least one input parameter for the corresponding execution of the parameterized traced function in the possible sequence of traced functions.

[0039] In certain implementations, the method is secured by recording the identifiers in a TPM module.

[0040] A TPM module stands for Trusted Platform Module. It is a hardware component, such as a microchip, that is 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 implementations, 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 be used to verify that these sequences have actually been executed.

[0043] Thus in certain implementation modes, the prover comprises a trusted 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 step S30, called recorded sequence, calculates a sequence proof, called recorded sequence proof (Prenreg), of said recorded sequence; a sequence proof being 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 verifier calculates a received sequence proof using the function of proof calculation, from the received sequence, and checks whether the received sequence proof is equal or not to the stored sequence proof.

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

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

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

[0051] In certain implementations, for at least one traced function called a parameterized traced function, the identifier of the parameterized traced function includes a value of at least one input parameter of said parameterized traced function. Thus, this value of said at least one input parameter will enter into the calculation of the proof by the TPM in step S60 and the verifier in step S80. Consequently, the verification carried out in step S90 will include the verification of the equality of the input parameters, for the one or those of the traced functions which are parameterized.

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

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

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

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

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

[0057] Other advantages, aims and particular characteristics of the present invention will emerge from the following non-limiting description of at least one particular embodiment of the devices and methods which are the subject of the present invention, with reference to the appended drawings, in which:

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

[0059] [Fig.2] is a flowchart showing an example of implementation of methods according to the present 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 the present disclosure; and

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

[0063] Particular modes of implementing methods according to the present disclosure will now be presented as non-limiting exemplary embodiments.

[0064] In [Fig.l] the components of a program execution control system are schematically represented, namely: - a first computer, or prover, on which a program whose correct execution is to be checked must be executed; and - a second computer, or verifier, generally remote from the first, which is used to verify the correct execution of the program by implementing the attestation method according to the present disclosure.

[0065] In a manner known per se, the prover's memory space 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, that ensures the basic functions of the operating system.

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

[0067] When executed, this program performs a number of functions. In the method according to the present disclosure, some of these functions are traced functions. For example, in the example presented here, the system calls are traced 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 operating system kernel can perform.

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

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

[0070] The prover includes a TPM module in order to record certain information there.

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

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

[0073] In this example, the system calls are taken as examples of traced functions, but any other function capable of being traced within the framework of the method according to the present disclosure could have been used while remaining within the framework of the present 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 the present disclosure for certifying 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 beam of this program, beam 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 (eg with strace (registered trademark)), etc.

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

[0085] Therefore, the program has as its call graph the 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 traced functions of the program that correspond to compliant executions of the program. In this case, we can identify only one sequence, consisting successively of the three traced functions (each being a system call): execve, write, and exit.

[0087] The graph of [Fig.3] therefore constitutes a reference beam within the meaning of the present disclosure.

[0088] In the general case, from the reference beam, it is possible to determine a number, sometimes high, of possible sequences of traced functions executed by the program considered during a compliant execution of the latter.

[0089] It should be noted that in the case where the source code of the program to be observed is not available, it may still be possible to generate the reference beam. For example, the program can be run 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 set up for the executable of the program (the executable code) which must be deployed on the prover is calculated and recorded in the verifier. In certain cases, it is also transmitted to the prover, to allow additional verification in step S10 described later.

[0091] After step S0, a preliminary step which possibly takes place a long time before any execution of the program, the execution of the program to be evaluated, the evaluation of its execution, and the launch of an action following this evaluation, then takes place in the following manner.

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

[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 the program has nevertheless 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 Hbinary_installation hash of this executable.

[0097] If the prover received the binary hash to install from the program executable, the prover then checks that the hash Hbinary_installation is equal to the hash Hbinary_to_install 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 implementations, the hash calculated by the prover, Hbinaire_instaiiation , is passed to the verifier.

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

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

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

[0103] In certain embodiments of the execution control method according to the present disclosure, the verification of the compliant execution of the program is not systematic, and on the contrary is evaluated conditionally.

[0104] In certain cases, for any execution of the program, step S30 is carried out.

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

[0106] In other embodiments, the recording step S30 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 request for verification of execution of the program by the verifier has been previously sent to the prover.

[0107] During program execution, the prover executes the recording application registered 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 traced functions F_i, i=l.. .N are executed successively (A traced function can naturally be executed several times).

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

[0110] In step S30 (which lasts for the entire duration of execution of the program), thanks to the recording application, the prover detects any execution of a traced function. Each time the execution of a traced function F_i is detected, the prover records in the TPM the identifier Id_i of the detected traced function. This identifier is data that makes it possible to identify the traced function.

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

[0112] The identifier Id_i of the traced 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 done in such a way as to retain the information indicating the order in which the traced functions were performed. 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 traced function can take many forms.

[0115] Such an identifier may be, or at least may include for example the name (i.e. any identifier) ​​of the plotted function with 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 the plotted function in question.

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

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

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

[0119] In particular, steps S40 to S90 of the method may be executed either continuously, 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 traced function F_i is executed.

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

[0122] Therefore, in step S40, the transmission of the 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 simplicity in this document, it is essentially mentioned the sending of "identifiers of traced functions" (in the plural). However, it must be understood that sending identifiers of traced functions 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 traced function

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

[0127] In certain implementations, 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] In step S40, the verifier has received the identifiers Id_i of the entire sequence of traced functions which have been detected since the start of the execution of the program.

[0130] Depending on the implementation mode, it then selects all or part of this sequence of traced functions (by applying a selection rule), and thus constitutes a sequence on which the evaluation will be carried out, a sequence which is called the received sequence. The received sequence can be constituted for example by the list of all the 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 presented, 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 that the identifier received has not been modified and indeed comes 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 beam. 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 successively executed during a compliant execution of the program.

[0133] If the verifier does not identify any sequence of traced functions from the reference beam that corresponds to the received sequence, it triggers an error message to signal 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 that the received sequence of traced functions that was taken into account in verification step S50 is indeed the sequence of traced functions that were actually executed. This additional verification is carried out using the TPM.

[0137] Firstly, 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 recorded sequence proof Prenreg. This proof will be 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 which contains the traced functions which were executed by the prover and recorded by the TPM. Thanks to the use of the same selection rule, the sequence of traced functions which serves as the basis for calculating the recorded sequence proof Prenreg by the TPM corresponds to that which serves as the basis for calculating the received sequence proof Prrec by the verifier (this calculation will be presented later).

[0139] Thus, depending on the implementation mode, the calculated proof (Prenreg or Prrec) can take into account a sequence of traced functions executed for a more or less long time. This proof can take into account only the last two recorded traced functions. The verification of successive proofs makes it possible to validate the entire observed sequence of functions executed by the program.

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

[0141] Any type of proof calculation function may 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 plotted function sequences, are different.

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

[0143] In step S70, the TPM transmits the recorded sequence proof to the verifier. Prerecord calculated in step S60.

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

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

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

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

[0148] The verifier then performs the following check to verify that the sequence of operations taken into account to confirm the correct execution of the program in step S50 is indeed the sequence of traced operations that was actually performed by the prover: it verifies that the recorded sequence proof Prenreg calculated by the TPM is indeed equal to the proof Prrec that 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 not correct. A corrective action must therefore be launched. Stage S90 - Final action

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

[0150] In particular, if a difference has been detected in 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, emits a message) to take this observation into account.

[0151] Conversely, if none of the verification steps S50 and S80 led to the detection of an error, the verifier concludes that the program ran normally. It possibly sends a message signaling the correct execution of the program up to the current operation.

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

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

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

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

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

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

[0158] In step S50, the verifier constitutes the received sequence; using the reference beam, it determines whether there exists at least one possible sequence which 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 verifier produces a negative evaluation result.

[0161] If the result of the evaluation 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] When implementing the method, at each execution of a traced function, two proofs are calculated: on the one hand, a recorded sequence proof Prenreg_i is calculated by the TPM in step S60, as a function of the recorded sequence (i.e. as a function, directly or indirectly, of all the identifiers of the traced functions of the recorded sequence); and on the other hand, a received sequence proof Prrec i is calculated by the verifier in step S80 as a function of the received sequence.

[0163] The calculated proofs Prenreg_i and Prrec_i are then compared: this makes it possible to verify 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 recordings by the TPM and is therefore assumed to represent exactly the traced functions which were actually executed during the execution of the program.

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

[0165] When executing the first traced function that is executed, evidence 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 on the hash Hbinairejnstaiié of the binary code of the installed program, or other.

[0166] Then, following each detection of the execution of a traced function F_i, at step S50 the TPM calculates a new recorded sequence proof Prenregi and at step S70 the verifier calculates a new received sequence proof 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 calculated proof 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 successively taking into account all of the executed traced functions, the algorithm takes into account all of the identifiers of the traced functions which have been detected, to construct the proofs, respectively Prenreg_i and PrrPP i, from one to the next.

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

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

[0171] where Concatener is the concatenation function.

[0172] In the example presented here, the identifiers (Id_i) are the character 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 TPM):

[0174] i=l. For the first identifier Id1: Prenregl = hash(Concatenate(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] In step S80, the verifier verifies that the proof Prrec_i that it calculated corresponds to the proof Prenreg_i calculated by the TPM.

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

[0179] Advantageously, this procedure makes it possible to confirm the sequence of traced functions executed during the execution of the program.

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

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

[0182] These variants allow a more in-depth control of the correct execution of the program 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 carried out.

[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 if this sequence comprises at least one plotted function itself a function of one or more parameters, it is possible to also 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 considered during the execution of the possible sequence of plotted functions considered.

[0184] In this embodiment, during execution of the program, in step S30, for each traced function depending on one or more parameters, the function identifiers which 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 traced function in question was executed.

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

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

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

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

[0189] As an alternative, or in addition, verification of the values ​​of the input parameters of the executed plotted functions may be done during 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 the character string) identifying the function, but also the value(s) of the input parameters of the executed traced functions.

[0191] Thus, the verification of two proofs PrenregJ and PrrecJ at step S80 can only give a positive result if not only 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 two parameters as input, namely the name and the memory address of the directory where the code for the execve function is stored.

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

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

[0196] When implementing the algorithm presented previously 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 in step S80, to calculate the proof Prenreg_l 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(Prenreg 2,'Exit','O')).

[0199] Each of the calculated proofs is therefore a function not only of the names of the executed traced 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 the fact that the values ​​of the input parameters of these functions had values ​​conforming to expectations.

Claims

Claims

1. Method for controlling the execution of a program executed by a first computer, called the prover, by means of a second computer, called the verifier; the program being recorded in the user space of the prover; a traced function (F_i) being a function executable by the prover from a predetermined set of functions of the prover; a reference beam 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 capable of being executed, in particular consecutively, during a compliant execution of the program;wherein the following operations are performed: S30) during a program execution, by executing a recording application recorded 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; 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) 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; and S90) the verifier triggers an action based on at least one result of the evaluation performed in step S50.;

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

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

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

5. An execution control method according to any one of claims 1 to 4, wherein the prover comprises a trusted platform module, or TPM module; in step S30, the traced function identifiers are recorded by the prover in the TPM module; the method further comprises the following steps S60, S70 and S80: S60) the TPM module, from a sequence of identifiers recorded in step S30, called recorded sequence, calculates a sequence proof, called recorded sequence proof (Prenreg), of said recorded sequence; a sequence proof being 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; S 80) 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).

6. The execution control method according to claim 5, wherein in step S60, the proof (Prenreg) is calculated by applying a hash function to a name or character string associated with a traced function.

7. The execution control method according to claim 6, wherein in step S60, the proof (Prenreg) is calculated by applying a hash function together with a name or character string associated with a traced function and a previously calculated hash or proof.

8. An execution control method according to claim 7, wherein in step S60, after a calculation of a first proof, calculated for example from a hash of a binary code of the program, or from the first traced function identifier recorded in step S30, the following proofs are successively calculated from the following traced function identifiers recorded successively in step S30, by applying the hash function together with a name or a character string associated with the traced function just executed and with the last previously calculated proof.

9. Execution control method according to any one of claims 5 to 8, wherein for at least one traced function called parameterized traced function, the identifier of the parameterized traced function includes a value of at least one input parameter of said parameterized traced function.

10. An execution control method according to any one of claims 1 to 9, wherein the hash of an executable of the program which is 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 which is going to be executed; and the method further comprises a verification step S10, in which the verifier checks whether the hash of the executable which is going to be executed received from the prover is equal to the hash of the executable that is to be deployed to the prover.

Images