WO2007099224A2 - Method for verifying conformity of the logical content of a computer appliance with a reference content - Google Patents

Abstract

The invention concerns a computer appliance comprising a processor (4), a memory (6) in which the processor can read and write, and an input/output device (8) for interfacing the appliance processor (4) with the outside world. In order to verify the conformity of the logical content of the appliance with the reference content, the method consists in sending (10) to the appliance (2) a request for loading into the memory (6) and executing a verification programme (P). The verification programme is capable or writing data into the memory (6) of the appliance and of reading data in the memory (6) to send them to the input/output device (8). Then, it consists in sending (12) to the appliance a request for executing the programme (P) to saturate the memory (6) available not taken up by the programme (P). Finally, it consists in exchanging (14, 16) messages with the appliance by executing the programme (P). Based on the exchanged messages, the conformity of the logical content of the appliance is verified.

Description

 METHOD FOR VERIFYING THE COMPLIANCE OF THE LOGIC CONTENT OF A COMPUTER APPARATUS WITH REFERENCE CONTENT

The present invention relates to computing devices and more specifically to verifying the compliance of the logical content of a computing device with a reference content.

Computer apparatus is an information processing apparatus, including a processor associated with a storage memory, as well as input-output devices. The processor, the memory, as the input-output devices can be made according to different hardware solutions. Thus, the memory may for example include a memory type EEPROM, EPROM or Flash memory. The apparatus is capable of loading into the processor a program or software contained in the memory, and executing the program or software. The apparatus is capable of communicating with the outside through input-output devices, receiving information from outside or transmitting information to the outside. Included in this definition of computer apparatus are smart cards, payment terminals, digital personal assistants (PDAs), pay TV terminals, and computers. These devices differ in the type of processor, the type of memory, the type of input-output devices as well as their destination. For such an apparatus, the content of the memory - be it executable code, parameters or passive data - is called logical content or logical state.

A problem encountered for computing devices is that of the conformity of the logical content of the device to a reference content. This problem arises when one has a device, which are known hardware specifications, especially the size of the memory and the type of processor. The problem is whether the device we have is in a reference state. The reference state can correspond to a given logical content - some information present in the memory - or to a lack of information in the memory.

This problem arises especially for smart cards and payment terminals; indeed, confidential information is written in the memories of these devices.

Personalization of smart cards (for GSM, payment or identity-based telephony applications) and payment terminals includes a code injection phase executable to these devices. Typically, smart cards with open operating systems (such as those sold as compliant with the "Javacard" standard) allow the addition of programs or extensions executable in the non-volatile memory of the card (typically EEPROM, EPROM or Flash).

Similarly, the initialization of payment terminals such as the one sold under the reference 5100 by the company INGENICO comprises a phase where it is loaded into the non-volatile memory of the terminal (typically EEPROM, EPROM, Flash or RAM saved by battery) a specific application to the financial operator (acquirer) for whom the terminal is intended. The term "application" means executable code, passive parameters and keys.

The injection into the memory of executable code, passive parameters and keys is done in a personalization station, which receives the device. When the device is connected to the personalization station, it is assumed that it is in a reference state, ie in a given logical state.

If we want to preserve the confidentiality of the information injected into the device by the personalization station, it is essential to ensure that the device to be personalized is empty of any malicious application. A malicious application is defined, for the purposes of this patent application, as any executable code and / or passive data different from the reference state in which the device is supposed to be.

We give here some examples of malicious applications in various fields: an empty payment terminal is handled by a malicious employee who loads an application that simulates the behavior of a blank terminal. This application leaves a copy of the secret keys in a readable area of the non-volatile memory. Once the keys are injected, the malicious employee takes possession of the injected keys, thanks to the copy made in a readable area of the memory. Then the malicious employee erases the application that simulates the behavior of a blank terminal and reprograms the keys stolen correctly in a blank terminal it reinserts into the distribution chain; checking the number of terminals does not detect the manipulation. Thus the purchaser will receive a terminal whose keys he believes to be safe while these keys are known to the malicious employee;

- an identity card is manufactured in country A on behalf of a country B. Country B provides the personalization of these cards, by injecting secret keys in an area of the card memory not readable from the outside . The card delivered to B may include a malicious code injected by the authorities of country A before the delivery of the blank cards to country B. This code can simulate vis-à-vis the personalization station a perfect behavior card software blank but save , in a hidden file stored in readable memory, copies of the secret keys injected by B into the identity document. Thus, during an inspection of the identity document by the country A, the malicious code could be activated, the country A could thus recover the keys put in the map by the country B and duplicate the identity document; the procedure for activating the malicious code can be very particular, for example resulting from the writing in a file of a specific data causing the waking of the malicious software; a credit card in which you have to register a Javacard applet with keys can already contain a malicious code, downloaded by a dishonest operator before the personalization of the card. Thus, the operator could recover the card at the end of the customization, reread his keys, erase the malicious code, reload the legitimate code in the card (and the keys he just read) and reinsert the card in the industrial process so that it does not fail in the final count;

- similarly, after formatting a hard drive and installing a Windows XP operating system, it may be useful to make sure that the hard disk contains the image of the official Windows XP CD content. marketed by the company

Microsoft.

The same scenario can occur during the initialization of any device with or without secrets (PC-type computer, PDA or PDA, mobile phone, gaming station, payment terminal, pay-TV decoder, etc.). , or during the injection on such an information device - programs, keys, data of any kind.

It is understood that in all these examples, it is useful to be able to verify that the state of the device is in accordance with a reference state. This verification can be a verification before the injection of information into the device: in the examples of the personalization of a smart card or a payment terminal, the verification aims to prove, before customization , the conformity of the device to the reference state, in particular the absence of malicious application. This verification can be a verification after the injection of information into the device: the verification is then intended to prove that the device is carrying a content (executable code, parameters, passive data) strictly in accordance with a given model. The state of the art offers three types of solutions to ensure that a computer device carries a logical content according to a given model. These solutions can be software, hardware or invasive.

Software solutions assume that the device is designed in such a way that a certain physical action on the device will result in a guaranteed behavior of the device. In the example of a PC-type personal computer, the physical action consisting of pressing the ctrl-alt-del keys, preceded by the insertion of a floppy disk in the reader and the ignition of the machine results in a boot of the operating system. When the BIOS (acronym for the Basic Input / Output System) of a PC detects the presence of a floppy disk in the floppies, he passes the hand to the program on the floppy disk and forces this program to run. Thus, it is possible to reformat a device that has failed or contains malicious code (such as a "virus" or a "rootkit"); this reformatting puts the device back into a given reference state - an initialization state, in which the device is empty of logical content. Such a material solution supposes that the apparatus allows, by such a physical action, a privileged grip.

When it comes to verifying that the device has a given logical content, such a solution assumes that the verifier can write the desired logical content back to the device. This is not always the case. Thus, there are nowadays devices whose memory is not made of ROM (ROM) but non-volatile memory rewritable (such as Flash memory or EEPROM). For example, several component manufacturers offer blank flash chips in which the card manufacturer can download an operating system of their choice; examples of such chips are those sold by the company SST under the reference Emosyn, by the company Atmel under the reference, AT90SC3232, by the Infineon company under the reference SLE88CFX4000P, or by the company Electronic Marin under the reference EMTCG. For such devices, the user has the possibility to load a new operating system on the chip of the card and can not force the device to boot on an external support, these chips do not therefore allow the user to to know if the operating system present aboard the chip of the card is in conformity with a given listing or not.

Invasive solutions assume that the device to be verified has been dismounted and that the element containing the code or data - the physical element providing the memory function - is inspected using an external test device. The external test device makes it possible to read the contents of the memory of the device to be verified, independently of the processor of the device to be verified, and therefore independently of the execution of any malicious application simulating an expected operation. Once you know for sure that the model conforms to the code contained in the disassembled element, the element is reassembled on the machine. By way of example, the software marketed under the reference EnCase by Guidance Software makes it possible to audit the contents of a hard disk outside a machine. Such an invasive solution is often out of reach for the average user or is simply technically impossible; Thus, a smart card or a payment terminal is designed in such a way that it is impossible to detach any element without causing the self-destruction of the device for security reasons. Software solutions consist of dialoguing with the device to be verified. Several approaches are currently used but none gives absolute certainty as to the content of the verified device. In all software approaches it is assumed that the attacker has the right to alter the software state (logic) of the target machine but in no case has he the right to alter the physical structure (eg add memory, unplug a device, replace the disk etc.).

A first software solution is to ask the examined device to chop all or part of its memory. Such an approach is insufficient because one could perfectly imagine that the malicious code has compressed the operating system (any executable code is highly redundant and therefore conducive to compression) that it decompresses and chops as and when to answer hash requests from the verifier. Such a solution is for example described in the article "Oblivious Hashing: A Stealthy Software

Integrity Verification Primitive ", by Yuqun Chen, Ramarathnam Venkatesan, Matthew

Cary, Ruoming Pang, Saurabh Sinha and Mariusz H. Jakubowski, Proceedings of 5 ^th

International Workshop on Information Hiding, Noordwijkerhout, The Netherlands, October 2002. Reading Notes in Computer Science, No. 2578, Springer-Verlag, 2003.

A second solution consists in signing by a digital signature algorithm the code initially present on board the device to be checked. This approach assumes that the code already on board the device is trustworthy. This solution is for example recommended by the Trusted Computing Group consortium whose website is https://www.trustedcomputinggroup.org/home.

The invention provides a solution to the problem of verifying the compliance of a computing device with a logical content or reference state. The invention assumes only knowledge of the hardware specifications of the verified device.

In some embodiments, the invention makes it possible to ensure that a given code is loaded exactly on an apparatus whose hardware specifications are known. These embodiments do not assume that the apparatus to be verified contains specific secrets, nor a code already assumed safe; they also do not assume the existence of a hardware mechanism to ensure a privileged grip of the device. In one embodiment, the invention proposes a method of verifying the conformity of the logical content of a computing device with a reference content, the computing device having a processor, a memory in which the processor can read and write, and an input input device allowing a dialogue between the processor of the apparatus and the outside world, the method comprising the following steps

sending to the apparatus a request for loading into the memory and executing a verification program P, the verification program being able to write data into the memory of the apparatus and to read data; in the memory to send them to the input input device; sending a request to execute the program P to saturate the available memory not occupied by the program;

- exchange of messages with the device running the program and verification of the conformity of the logical contents of the device according to the messages exchanged with the device. In other embodiments, the method may have one or more of the following features: the verification of conformity is made according to the content of the messages exchanged with the apparatus; the verification of the conformity is carried out according to the measurement of the timing in the time of the messages exchanged with the apparatus;

- The verification program P includes additional reading instructions, causing increased activity on the input device output;

the method comprises a step of proving the verification of conformity by a backtracking technique applied to the set of instructions executable by the processor; the step of proof of conformity by a backtracking technique comprises the evaluation of the different candidate instructions in a concrete manner;

the step of proof of conformity by a backtracking technique comprises the evaluation of the different candidate instructions in an abstract manner;

the method comprises a step of proving the verification of conformity by an exhaustive search of the possible programs applied to the set of instructions executable by the processor; the load request in the memory includes a request to load the verification program P into the memory from the input input device; the request for loading into the memory includes a request to activate a verification program P contained in the device;

the execution of the program P to saturate the available memory comprises reading stuffing data from the input input device and writing the stuffing data in the memory;

the execution of the program P to saturate the available memory comprises the reading of a problem from the input-output device and the resolution by the verification program P of the problem using the available memory; executing the program P to saturate the available memory includes reading a seed from the input input device and expanding the seed using the available memory;

the message exchange comprises: sending to the apparatus a request for reading data from the memory and receiving from the apparatus data read from the memory, including the code of the verification program;

the verification program is capable of executing a function on data in the memory, and the message exchange comprises: sending to the apparatus a request to execute the function and to read data from Memory; and receiving from the apparatus the result of the function and the code of the verification program read from the memory.

the function performed on the data comprises the hash calculation of the data of the memory other than the code of the verification program; the execution of the program P to saturate the available memory includes reading a problem from the input-output device and solving the problem using the available memory, the message exchange comprising: sending to the device a problem; and receiving from the apparatus the result of the problem and the code of the verification program read from the memory. the code of the verification program includes instructions for reading the code to the input-output device; the execution of the verification program causes the erasure of the memory, excluding the code of the verification program. In another embodiment, the invention provides a method of restoring a computing device having a processor, a memory in which the processor can read and write, and an input input device allowing dialogue between the processor of the processor. apparatus and the outside world, the method comprising the steps of: - saving to the outside world of the data present in the memory;

- checking the conformity of the logical content of the computer device to a reference content, according to the method described above; analysis and where appropriate treatment of the data saved and

- Copy of the analyzed data into the memory of the device. In yet another embodiment, the invention proposes a computing device, comprising a processor, a memory in which the processor can read and write, an input input device allowing a dialogue between the processor of the device and the world. external and a verification program stored in the device, the verification program including instructions adapted to cause, when executed by the processor, - the writing of data in the memory of the device and

reading the data in the memory, including the code of the verification program, to send them to the input input device.

In a final embodiment, the invention provides a computing device, comprising - a first subset having a processor, a memory in which the processor can read and write, and an input input device; a second subassembly, the second subassembly being adapted to interact with the processor of the first subassembly through the input input device and to check the conformity of the logic state of the first subassembly according to the mentioned method upper.

Other characteristics and advantages of the invention will appear on reading the following detailed description of the embodiments of the invention, given by way of example only and with reference to the drawings which show: FIG. 1, a diagrammatic representation a device, which one wishes to check the logical state; FIG. 2 is a flowchart of a first example of implementation of the method of the invention;

- Figure 3, a flow chart of a second example of implementation of the method of the invention. Figure 4 is a flowchart of a method of restoring the state of a computing device; - Figure 5, a block diagram of a device within which is implemented the method of Figure 2 or 3. Figure 1 shows a schematic view of a computer apparatus. As explained above, the apparatus 2 has a processor 4, a memory 6 and an input input device 8. The processor 4 is able to write to the memory 6 and read from this memory. The processor 4 is also capable of executing executable code stored in the memory 6. The processor 4 is still capable of receiving information from the input input device and transmitting information to the outside via the device. enter exit. FIG. 1 only shows the functional elements necessary for the implementation of the invention; in particular, the device may have a specific memory containing the operating system, as in the Flash chips mentioned above as an example; the memory 6 is the memory offered to the user of the device for loading data, parameters or codes executable by the processor.

The different elements of the apparatus of Figure 1 are functional elements, and various hardware solutions can be used to implement them. As for the processor, it is possible to use commercial processors, such as 68HC05 or 80C51, or the Flash chips mentioned above. As far as memory is concerned, Flash memory can be used to store magnetic memory or EEPPROM memory in any form. The particular shape of the input input device is indifferent. In the example of a smart card, the input input device is able to read the signals applied to the serial port of the card; in the example of a contactless smart card, the output input device comprises an antenna and the circuits adapted to decode the signals received on the antenna. In the example of a payment terminal, the various functional elements of FIG. 1 are typically composed of a 32-bit microprocessor, a serial port and a flash memory.

As indicated above, in addition to a smart card or a payment terminal, the apparatus may be a PC-type computer or the like, a personal digital assistant, a pay-TV terminal, or any other device having the schematic structure of the device. Figure 1.

The verification method of the invention assumes known the hardware specifications of the device 2. In the example of Figure 2, it is sufficient to know the capacity of the memory 6 of the device. In the example of FIG. 3, the method also requires to know the time characteristics of the processor of the apparatus, typically the number of clock cycles required to execute each instruction.

Figure 2 is a flow chart of a first embodiment of the method of the invention. In this embodiment, the invention exploits the fact that the execution of a malicious program, which simulates the "normal" operation of the apparatus 2, assumes that memory resources are available. The invention therefore proposes to ask the device to execute a verification program able to interact with the outside world and to saturate the memory of the device before the dialogue. In the absence of a malicious program, the dialogue with the outside world will take place in an expected manner; if a malicious program is present and tries to simulate the execution of the verification program, the absence of memory resources will lead to the dialogue with the outside world not taking place in the expected way.

In step 10, the apparatus 2 is instructed to load in the memory 6 a verification program, noted P in the following, and to execute it. The loading can be carried out via the input-output device, by writing the program in the memory 6. It is also possible to provide a dormant verification program - stored in the device verified elsewhere; in this case, it is not necessary to load it via the input-output device and it is sufficient to go back to the memory 6. The word "loading" must therefore be understood as covering not only a writing in the memory 6 of the program through the input device output 8, but also a writing in the memory 6 of a program already contained in the device 2.

The verification program P, when executed, makes it possible to write data into the memory 6; in the embodiment described with reference to FIG. 2, the writing of the data consists in writing in the memory 6 of the data received on the input-output device 8. Other ways of writing data are given below. in the memory.

The program P also allows, when executed, to read the contents of the memory to send it to the input device output.

At the end of step 10, there is still no certainty that the device has correctly loaded and executed the program P. Such is the case if, in the absence of any malicious program, the device behaves in a "normal" way. The device may have a malicious program trying to simulate "normal" operation: the device, because of this malicious program, may try to behave as if the program P had been loaded but not to load it correctly or to load it only a part or abstain from performing it. In steps 12 to 18, program P is used to undertake a verification protocol with the apparatus. This protocol aims to test the operation of the device to allow to conclude, with certainty that the device is "clean", that is to say that it has no malicious program or to conclude with certainty that the device is infected, that is to say it has a malicious code.

In step 12, the program P is used to saturate the memory 6 of the apparatus, with a block of random or non-random data, denoted R. The saturation consists in filling the memory 6, with the exception of the part of the memory 6 in which the program P is stored. In the example of FIG. 2, this saturation is carried out simply by applying random data, noted R in the following, to the input input of the apparatus 2; the data R is written in the memory 6 because of the execution of the program P. Alternatively, it is not excluded that R consists of fixed and / or non-random data already present within the verified device or data from the outside world.

In steps 14 to 16, messages are exchanged with the device to be verified. Step 14 is the application to the apparatus of a request to execute the program P to read the contents of the memory 6. In step 16, the contents of the memory 6 or data whose value is related to the contents of the memory. We will therefore understand by "memory content" any data whose value is related to and / or equal to the content of the memory.

In step 18, the content of the memory 6 received from the apparatus 2 is compared with the expected random data R and with the code of the program P and more generally with any trace of normal execution that would have resulted from the execution of P if the conditions were normal.

If the content of the memory 6 received from the apparatus corresponds to the data R and the code of the program P, it is concluded in step 20 that the apparatus is "clean" and does not include a malicious program. Conversely, if this is not the case, it is concluded in step 22 that the apparatus is not in a state conformed to the reference state.

The comparison of step 18 is based on the fact that P is the only program capable of:

- to fit in the remaining space in the memory after loading the data R and

- capable of a behavior consisting in returning to the external verifier the data R and the code of P.

This fact results on the one hand from the saturation of the memory 6; a malicious program that would be present on the device to simulate its normal operation should use part of the memory 6; it should simulate the loading in the memory of the data R, and then restore them. But this is all the more difficult as the data R are random, as mentioned above, or pseudo-random. In case the R data would not be random, the verifier should make sure (prove to himself) or make the assumption that a potential malicious program is unable to simulate the correct restitution of these non-random data. This then results from the size of the program P. It is advantageous that the program P has a size as small as possible, to make it impossible in practice to rewrite a program simulating its operation. In the example proposed below, the program P has a size of 23 bytes. A size of less than 50 bytes is in practice a small size, making it extremely difficult or impossible to write a program having the same operation.

Finally, this results from the fact that the exchange of messages with the apparatus also comprises the reading of the code of the program P.

Thus, due to the saturation of the available memory, a malicious program can not have the memory resources necessary to simulate the "normal" operation of the device in the different steps of the method of FIG.

A first example of program P is given below. This program is written in assembler 68HC05.

Example1.asm portA equ $ 80 I / O port rental ddrA equ $ 81 data direction register (ddr) location org $ 0080 program starts at address 0x80 dw $ 0000 initializes ddr in input mode start: clr ddra ddr in input mode reset

Idx portA read command beq read if command is zero then read garlic code out write

Ida portA read byte presented by external world sta portA, X store it at location X bra start ask for next byte read: com ddra if command nozero make portA output

Ll: Ida portA, X load code value, no need to set X = O (done) sta portA send it out incx index index bne Ll from program first byte to last start from program first byte to last org:? LffE dw start point to where program starts

As long as the command applied is null, the program proceeds to read the memory - including the reading of its own code. If the command is not null, the program writes in all available memory, outside the position it occupies. The method of the invention is therefore implemented: - by asking the device to execute to load the program Exemplel .asm above in its memory then to execute it;

by applying a non-zero command and stuffing data in sufficient quantity to fill the available memory (the verifier can avoid such loading from the moment when he verifies that the R data already on board do not allow a malicious program to simulate correct behavior - subject to such proof or assumption of R data already on board may be used); it is recalled here that one is supposed to know the material specifications of the apparatus, in particular the memory size; - By applying a null command to cause the reading of all the data contained in the memory.

At runtime, this program Exemplel. asm will produce the sequence 00FF3F81 BE802706 B680E780 20F43381 E680B780 5C26F920 E9 {random block R} The example proposed above shows that it is possible to generate codes having the required operation and returning the expected information to the reading.

The method described with reference to Figure 2 has the advantage of involving only the knowledge of the capacity of the memory 6 of the device 2, so as to ensure a saturation of the memory. If one also knows the temporal characteristics of the processor 4 of the apparatus, one can also measure the time - in number of clock cycles of the processor - necessary to return the data R as well as the code of the program P.

Thus, the verifier can time the number of clock cycles separating the return of the different bytes composing the returned data "R and the code of P" and conclude that the apparatus M is "clean" only if the bytes of the data " R and P 'code are returned to predictable timing, given the processor specifications of the apparatus M.

Figure 3 shows the corresponding method; Figure 3 is identical to Figure 2, except for step 19, checking the timing of messages exchanged with the device. If the timing of the messages is not that expected, the verifier concludes in step 26 that the logical content of the device does not comply with the expected content. Otherwise, the apparatus is in a logical state in accordance with the reference state (step 28). In the representation of FIG. 3, the step 19 of verifying the timing of the messages exchanged with the apparatus follows step 18. This is only a schematic representation, the order of the verifications being irrelevant. This verification of the timing of the exchanges makes it even more difficult to simulate the behavior of the program P by a malicious program.

In addition, it is possible to prove in a formal way by using a technique known as backtracking (or backtracking in French) that a given code is the only one capable of returning to the verifier R and its own code in a delay and / or a precise rhythm. This backtracking technique is known per se by those skilled in the art and is described for example in: http://www.cis.upenn.edu/~matuszek/cit594-2002/Pages/backtracking.html; it is therefore not described in more detail. While the certainty of conformity is empirical in the method of FIG. 2, the method of FIG. 3 allows a formal demonstration of the impossibility of providing a malicious program simulating the operation of the verification program P.

In order to facilitate this proof, it is advantageous to parse the byte replay loop of additional byte return instructions to further constrain any malicious program, as shown in the following example:

Ll: LDA PORTA, X; LOAD CODE VALUE 4 CYCLES

STA PORTA; SEND IT OUT 4 CYCLES

INCX; INCREMENT INDEX 3 CYCLES

BNE LL 3 CYCLES

The preceding code fragment returns one byte every 14 machine cycles. The formal demonstration that can be used in the method of FIG. 3 consists in proving that no sequence of instructions of at most 14 cycles is capable of generating the expected sequence in time.

To make it even more difficult to carry out a malicious program - or to simplify the formal demonstration - the replay loop can also be sprinkled with feedback operations to reduce the 14-cycle time between sending the characters. successive sequence "R and P code" as much as possible. For example :

Ll: COM PORTA ENHANCEMENT DELAY 5 CYCLES

PORTA LDA, X LOAD CODE VALUE CYCLES

STA PORTA SEND IT OUT CYCLES

INCX INCREMENT INDEX CYCLES

STX PORTA IMPROVEMENT DELAY CYCLES

BNE Ll CYCLES In this example, we note that the malicious program has only 8, 7 or 8 cycles to generate each byte sequence "R and code P". This makes it possible to automatically explore the codes making it possible to generate sequences and to screen these codes one after the other by means of a so-called backtracking process, insofar as one wishes to have a verification formal impossibility of constructing a malicious code.

It should be noted that this is not an exhaustive search of all the possible codes because as soon as a code C deviates from the imposed time constraints all the longer codes having C as fragment or prefix are eliminated. For the backtracking verification, it is possible to evaluate the different candidate instructions in a concrete or abstract (symbolic) way. The advantages of a concrete evaluation are a greater ease of programming. The advantages of symbolic verification are greater efficiency despite greater programming complexity. Appendix 1 to this disclosure presents the source code of a code proofing procedure for a backtracking method specifically adapted to the present invention.

Annex 2 to the present description gives, for example program Example 1.asm scattered with additional reading instructions, the expected behavior of the apparatus. Proof of compliance verification may use an exhaustive search applied to the instruction set executable by the verified platform; the set of possible codes having the required size are then determined, and these codes are tested to prove that they are not suitable for providing the messages exchanged with the apparatus; this proof applies to the method of FIG. 2, in which the verification is carried out according to the content of the messages exchanged with the apparatus; this technique is still applicable to the method of FIG. 3, in which the verification is also carried out as a function of the measurement of the temporal timing of the messages exchanged with the apparatus.

Appendices 3 and 4 show the encodings of the different 7-cycle and 8-cycle instructions, which are possible for a set of instructions corresponding to the 68HC05 assembler. These different 7- and 8-cycle instructions can be used for proof of compliance verification by exhaustive search, when the program is sprinkled with replay instructions leading to 7 or 8 cycles available for the malicious program, as in the example proposed above. Annex 5 shows another example of the code for the verification program P; the appendix shows only the part of the program that reads values, the value placement part in the checked memory having been removed for clarity.

The methods proposed with reference to Figures 2 and 3 allow verification of the conformity of the logical content of the device. These methods, however, involve a saturation of the memory, by applying to the input device output data R saturation. Such a solution does not pose any particular problem when the capacity of the memory 6 is sufficiently small compared to the output device of the output device. The methods of Figures 2 and 3 are therefore easily used for devices such as smart cards. If the capacity of the memory is too large - for example a memory in megabytes or in gigabytes on a computer, one of the following solutions for the memory saturation step can advantageously be used.

A first solution is to provide the device, in lieu of saturation data, the statement of a problem to be solved, solving the problem leading to the saturation of the memory. By way of example of such problems, mention may be made of the problems known as SP ACE-COMPLETS. For example such problems are cited in the article "Moderately Hard, Memory-bound Functions" by Martin Abadi, Mike Burrows, Mark Manasse and Ted Wobber or in the article "On Memory-Bound Functions for Fighting Spam" by Cynthia Dwork, Andrew Goldberg and Moni Naor. The problem exploited in the second article involves the computation of collisions, and thus the occupation of a memory capacity whose size can be fixed according to a parameter. The statement of the problem measures only a few bytes. It is understood that the statement of the problem is "short", with regard to the size of the memory 6.

A second solution is to apply to the apparatus a short seed of a data to be expanded by the program P, the expanded data to saturate the memory. The expansion process is preferably such that there is no way to expand the data other than by occupying all of the available memory.

It is also possible to mix the different solutions proposed above and with reference to FIG. 2. A third solution consists in not saturating the memory and working with data already present on board the verified platform (these data being able to be according to the cases , executable code already on board (legitimate application code) and / or legitimate passive data). In this case, the verifier may preferably first prove or assume that the return of these data already present on board the platform verified by the program P during the verification phase can not be simulated by a malicious program (with or without temporal timing constraints). Such proof is always possible to obtain by a backtracking technique.

These solutions make it possible to limit the duration of the stage of saturation of the memory by the program P or to avoid the reloading of data already on board. In cases where saturation data originates, at least initially, from the outside world (problem supply, seed supply), it remains impossible for a malicious program to predict the solution in advance and thus avoid the problem. saturation of the memory. These solutions assume, however, that the program P is more complex than the Examplel .asm program proposed above.

Finally, it should be noted that instead of random data it is also possible to use R instead of fixed and non-confidential data and in this case to prove that the behavior of the platform is unambiguously characterizable.

The methods of Figures 2 and 3 also involve a step 16 of reading the contents of the memory. As for writing in the memory, this solution does not pose any particular problem when the capacity of the memory 6 is sufficiently small, compared to the flow rate of the input input device. One can nevertheless use one of the following solutions to make the exchange between the device and the outside world faster.

A first solution is to proceed, instead of reading the random or pseudo-random saturation data, a hash calculation or a calculation of CRC on these data. Insofar as the data are random or pseudo-random, the compression mentioned in the description of the software solution of the state of the art is impossible or very difficult.

We can also propose the following solution: n random or pseudo-random stuffing blocks are received from the outside world; these data are placed in the memory 6 by the program P. This memory saturation step 12 is followed by an indication by the outside world of a permutation of the n elements and by the return by the program P of the hash of the permutated data. to the outside world. Thus, even if the malicious program knows the type of hash to apply, it is impossible for it to calculate the hash when receiving blocks of jam.

These solutions make it possible to limit the duration of the reading step from the memory by the program P. Since the computation of the CRC, the hash or the calculation of the result implies having saturation data as a whole, it remains impossible for a malicious program to predict in advance the solution and thus avoid the saturation of the memory. The return of information to the outside world is however faster, since it suffices to transmit {the result of the calculation on the data R + the code of P} instead of transmitting {the data R + the code of P}

It is also possible to mix the various solutions proposed above and with reference to FIG. 2. It is also understood that the solutions limiting the duration of writing in the memory and the solutions limiting the duration of reading of the data can be mixed. Memory.

The rest of the verification process and its applications are not described here. In the example of devices to be customized, a device compliance check is followed by customization, while a device that is found to be non-compliant is rejected. Once the device is verified, it is possible to use for personalization the capacity of the program P to write in the memory 6 of the device.

The method of Figures 2 and 3 applies in particular when the memory is not supposed to contain code or when the memory contains a known code that can be restored without problem at the end of the verification process. It can also be provided that the program P begins by erasing all the data present in the memory, excluding its own code, and then starting to receive data from the outside world.

It can also be expected that the program P leaves in place the data present, but communicates them to the verifier who will demonstrate that it is possible to conduct the test without ambiguity with these data instead of random data.

It is also possible to provide, before the memory saturation step, a backup of the data contained in the memory - or part of it - by temporarily transmitting this data to the outside world. The conformity of the saved data can be analyzed outside the device; saved data, if true, can then be restored to the verified device; again, the program P can be used for data restoration after the compliance check. The invention then allows a restoration of a computer apparatus. FIG. 4 shows such a method, applied to an apparatus of the type of FIG. 1: the first step 30 is a step of saving the contents of the memory to the outside world; it is followed by a compliance verification step 32, according to the method described above; in step 34, the exported data are analyzed and, if necessary, processed, for example if they contain a malicious program. If the apparatus is in a state in accordance with the reference state (step 36), the processed data is reinjected (step 38). If the verified device is not in a state in accordance with the reference state, an error is reported (step 40); we can then take the necessary corrective measures (reset or others).

It is also possible to modify or generalize the method described in the present invention in the following ways: A first generalization consists, instead of writing the data R in one go and re-reading it in one go, of alternating writes and reads repeatedly. Thus a first block of data R [I] would be written, a first block R '[l] would be read again, then a second block of data R [2] would be written, a second block R' [2] would be read again and so after. Here R '[i] denotes either a value which must be equal to R [i] or a value which is a function of R [i].

- A second variant may be to repeat the verification protocol with the machine several times and accept the machine as clean only if successful in all sessions of the protocol. Such a repetition aims to exponentially reduce the probability that a malicious application will pass the protocol out of sheer luck.

A third variant replaces the backtracking proof with any other form of proof, for example the exhaustive search (or the construction) of the smallest code (let's call it the size of this code) capable of restoring a datum of the size of R minus m bytes. With reference to FIGS. 2 and 3, a verification of an apparatus from the outside world is described with reference to a "verifier" which is not part of the apparatus. The method of the invention also applies within the same device, between two circuits, two subsystems or two components forming part of the device; in this case, one of the two circuits, subsystems or components behaves as the "outside world" or as the "verifier" for the other circuit, subsystem or component. This other circuit, subsystem or component then behaves like the device to be verified described above: it must therefore include a processor, a memory, and an input-output device for dialogue with the other under -together. FIG. 5 shows such a device 50. The elements of the first subset are identified by the reference numerals of FIG. 1, increased by 50. The second subset is referenced 60; it is not described in more detail.

In other words, the method mentioned above is carried out internally in the device. This can be done between two subsets of the device or between more than two subsets, according to desired permutations; the method can be performed invisibly for the user of the device, periodically or under circumstances special. In case of non-compliance, one or more actions may then be caused, such as for example a stop of the functions of the device, or a message to the user or to the outside world.

By way of example, the method of the invention could be used in a multiprocessor machine, such as a PC, a payment terminal, a pay-TV decoder, an electronic element embossed with a weapon or from where military vehicle, each processor constituting the "outside world" for verification of the other processor.

APPENDIX 1 Backtracking algorithm written in Mathematica language

The algorithm explores MSZ size codes = 21 bytes (as an example) and assumes a 68HC05 instruction set restricted to INCA, LDA, STA, and BNE instructions, 0x00 input port, OxOl output port

q: = Function [x, Mod [x 256]]; MSZ = 21; s: = Function [x, Mod [x, MSZ]];

(* this function initializes the state of the memory to -1 (-1 meaning by convention indefinite value) except the port at address 0 which is initialized to 0 *) M = Prepend [Table [-l, { n, 1, MSZ-1), 0];

(* values of 4 opcodes *) BNE = 16 ^ΛΛ 26; LDA = 16 ^ΛΛ B6; INC = 16 ^ΛΛ 4C; STA = 16 ^ΛΛ B7; (^ function returning the contents of a memory box *) RM: = Function [x, M [[s [x] + l]]];

(* function assigning a value to a memory box *) SM: = Function [{x, v}, M [[s [x] + l]] = v];

(* function checking the compatibility of the contents of the machine with a hypothesis of code made by the algorithm of backtracking *)

NC: = Function [{pt, lst}, Sum [If [lst [[d + l]] ≠ RM [s [pt + d]] && RM [s [pt + d]] ≠ -l, l, 0 ], {d, 0, Length [lst] -l}] ≠ 0];

(* function assigning a series of values to the memory *) SetM: = Function [{pt, vl}, For [b = l, b <Length [vl], SM [s [pt + bl], vl [[s [b]]]]; b ++]];

(* function assigning values to the microprocessor registers *) SetRegs: = Function [{va, pt}, A = q [va]; Z = If [A 0, l, 0]; PC = s [pt]; SM [the]]; (* relative address decoding function for the jump instruction *) dec: -Function [j, 2 + j-If [j <16 ^AΛ 7F, ^0,256 ]];

(* function testing if the state of the memory is compatible with the hypothesis of fragment of instructions of the form INCA STA 1 *) INCT ~ Function [U, q [Ex-1] ≠ A || NC [PC, (INC ₅ STA, 1}]]

(* modeling the effect of a INCA STA 1 * instruction fragment)

INCS: = Function [U, SetM [PC, {INC, STA, l}]; A = Ex; Z = If [A 0, 1, 0]; PC = s [PC + 3]; MS [1, A]]

(* same approach as before for a fragment of type LDA m STA 1 *) LDAT: = Function [U,

NC [PC, {LDA, U, STA, 1}] || If [MemberQ [{PC, s [PC + l], s [PC + 2], s [PC + 3]}, s [A]],

Ex ≠ Pick [{LDA, U, STA, l}, {PC, s [PC + 1], s [PC + 2], s [PC + 3]}, s [U]] [[l]],

RM [U] ≠ Ex && RM [U] ≠ -1]];

LDAS: = Function [U ₅

SetM [PC, {LD A ₅ U ₅ STA, 1}]; If [Not [MemberQ [{PC, s [PC + 1], s [PC + 2] ₅ s [PC + 3]} ₅ s [U]]], SM [U ₅ Ex]]; A = RM [U] ₅ Z = If [A 0 ₅ 1.0], PC = s [PC + 4]; SM [I ₅ A];]

(* modeling of the effect of an instruction fragment of BNE type Lable STA 1 *)

BRAT: = Function [L, (Ex ≠ A || NC [PC ₅ (BNE ₅ L)]) ||

If [Z == l ₅ NC [s [PC + 2], (STA, l}], NC [s [PC + dec [L]], {STA ₅ l)] || 16 ^ΛA FE <L <16 ^ΛΛ FF]];

ARM: = Function [L, SetM [PC, (BNE ₅ L)];

SetM [If [Z 1, s [PC + 2], s [PC + dec [L]]] ₅ (STA ₅ I)];

Z = If [A 0, 1, 0]; A = Ex; SM [1, A]; PC = s [PC + If [Z l, 4, dec [L] + 2]]];

(^ modeling of the effect of an STA m STA 1 * instruction fragment)

STAT = Function [U,

NC [PC, (STA ₅ U ₅ STA ₅ I)] || A ≠ Ex || s [U] = l || (s [U] s [PC + 2] && A ≠ STA) || (S [U] s [PC + l] && A ≠ l)]; STAS: = Function [U,

SetM [PC ₅ (STA ₃ U ₅ STA, 1)];

SM [U ₅ Ex]; Z = If [A 0 ₅ 1, 0]; A = Ex; PC = s [PC + 4]; SM [1, Ex];];

(* reading the file containing the expected values of a legitimate platform and their timing in time, file given below *) ExList = Drop [Drop ["file.m, I] ₅ I];

(* read files containing all the fragments whose execution can take 7 or 8 cycles, files given below *)

Try [7] = "try7.txt; Try [8] =" try8.txt; S [8] = Length [Try [8]]; S [7] = Length [Try [7]];

(* Isolation of Expected Values in a Table EV = Expected Values and Timing Values TM = Timing *) TM = Table [ExList [[h, 2]] ₅ (h, l, Length [ExList]}]; EV = Table [ExList [[h ₅ l]] ₅ (h, l, Length [ExList]}];

(* Initialization of a GS list containing the state of the hypothesis explored *) For [h = l, h <Length [ExLi St] ₅ GS [h] = l; PL [h] = 0; h ++]; (* this function generates the state corresponding to a given GS list *) ReRun: = Function [idd, PC = PCx; A = Ax; Z = Zx; M = Prepend [Table [-l, {n, l, MSZ -I}], 0]; For [c = 1, c≤idd, Ex = EV [[c]]; ExecInst [Try [TM [[c]]] [[GS [c]]]]; c ++]]; (* function translating an instruction into a test function *)

TestInst: = Function [hy, Pick [{INCT, LDAT, BRAT, STAT}, {"INC", "LDA", "BRA", "STA"}, hy [[l]]] [[l]] [ hy [[2]]]]

(^ function translating an instruction into an execution function *) ExecInst: = Function [hy, Pick [{INCS, LDAS, ARM, ST AS}, ("INC ₅ ¹¹ LDA ¹¹ Z ¹ BRA ¹¹ Z ¹ STA") , hy [

[T]]] [[s]] [hy [[2]]]]

(* carryover function on code fragment index *)

Uniformize: = Function [, For [h = Length [ExList], h ≠ l, If [GS [h] S [TM [[h]]] + l, GS [hl] ++, GS [h] = l ]; h-]];

(* backtracking loop *)

For [Zx = 1, Zx≤2, For [Ax = 0, Ax <255, For [PCx = 8, PCx <MSZ-I,

PC = PCx; A-Ax; Zx = Z; ID = I; Labelfyyy]; Ex EV = [[ID]]; CY = TM [[ID]]; HY = Try [CY] [[GS [ID]]];

If [Not [TestInst [HYJJ, ExecInst [HY]; ID ++; Goto [yyy]

IfIGS [ID] <S [CY] GS [ID] ++; Goto [yyy]]];

PL [ID-I] ++; GS [ID] = I; GS [ID-I] ++; ID-; Uniformize []; ReRu _n [ID-I]; Goto [yyy]; Labelfzzz];

PCx ++]; Ax ++]; Zx ++];

ANNEX 2 Coding of the behavior expected by the platform (file file.m)

{{0,4}, {0,7} _> {0 _I 7}, {], 7}, {1,8}, {1 _> 7} ₎ {1,7} _> {1,7}, { 2,7}, {2,8}, {2,7}, {183.7} _{{2) 7})} {3,7), {3,8}, {3,7}, {1, 7}, {3,7}, {4,7}, {4,8}, {4,7}, {182,7}, {47}, {5,7}, {5,8}, { 5 _> 7}, {5J} ₎ {5J}, {6,7}, {6,8}, {6,7}, {183 _> 7} W6J}, {7,7}, {7,8} , {7,7}, {1,7}, {7,7}, {8 _r 7}, {8,8}, {8,7}, {182,7}, {8,7}, { 9.7}, {9.81, (9.71, (5.71, (9.7J, {10.7}, {10.8}, {10.7}, {183.7}, { 10,7}, {11,7}, {11,8}, {11,7}, {1,7}, {11,7}, {12,7}, {12,8}, {12, 7}, {76,7}, {12,7}, {13,7}, {13,8}, {13,7}, {183,7}, {13,7}, { ^] 4 ₍ 7) }, {14,8}, {14,7}, {1,7}, {14,7}, {15,7}, {1 ₅ , 8}, {1 ₅ , 7}, {183,7 ), {1 ₅ , 7}, {16,7}, {16,8}, {16,7}, {5,7}, {16,7}, {17,7}, {17,8} , {17,7}, {183,7}, {17,7}, {18,7}, {18,8}, {18,7}, {1,7}, {18,7}, { 19.7}, {19.8}, {19.7}, {38.7}, {19.7}, {20.7}, {20.8}, {20.7}, {237, 7}, {20,7}, {21,7}, {21,8}, {21,7}, {0,7}, {21,7}, {22,7}, {22,8} , {22,7}, {22,7}, {22,7}, {23,7}, {23,8}, {23,7}, {183,7}, {23,7}, { 24.7}, {24.8}, {24.7}, {1.7}, {24.7}, {25.7}, {25.8}, {25.7}, {182, 7}, {25,7}, {26,7}, {26,8}, {26,7}, {26,7}, {26 , 7}, {27,7}, {27,8}, {27,7}, {183,7}, {27,7}, {28,7}, {28,8}, {28,7 }, {1,7}, {28,7}, {29,7}, {29,8}, {29,7}, {182,7}, {29,7}, {30,7}, {30,8}, {30,7}, {5,7}, {30,7}, {31,7}, {31,8}, {31,7}, {183,7}, {31 , 7}, {32,7}, {32,8}, {32,7}, {1,7}, {32,7}, {33,7}, {33,8}, {33,7 }, {76,7}, {33,7}, {34,7}, {34,8}, {34,7}, {183,7}, {34,7}, {35,7}, {35,8}, {35,7}, {1,7}, {35,7}, {36,7}, {36,8}, {36,7}, {183,7}, {36 , 7}, {37,7}, {37,8}, {37,7}, {5,7}, {37,7}, {38,7}, {38,8}, {38,7 }, {183,7}, {38,7}, {39,7}, {39,8}, {39,7}, {1,7}, {39,7}, {40,7}, {40.8}, {40.7}, {38.7}, {40.7} _> {41.7}, {41.8}, {41.7}, {237.7}, {41 , 7}, {42,7}, {42,8}, {42,7}, {0,7}, {42,7}, {43,7}, {43,8}, {43,7 }, {43,7}, {43,7}, {44,7}, {44,8}, {44,7}, {183,7}, {44,7}, {45,7}, {45.8}, {45.7}, {1.7}, {45.7}, {46.7}, {46.8}, {46.7}, {182.7}, {46 , 7}, {47,7}, {47,8}, {47,7}, {47,7}, {47,7}, {48,7}, {48,8}, {48,7 }, {183,7}, {48,7}, {49,7}, {49,8}, {49,7}, {1,7}, {49,7}, {50,7}, {50,8}, {50,7}, {182,7}, {50,7}, {51,7}, {51,8}, {51,7}, {5,7}, { 51.7}, {52.7}, {52.8}, {52.7}, {183.7}, {52.7}, {53.7}, {53.8}, {53, 7}, {1,7}, {53,7}, {54,7}, {54,8}, {54,7}, {76,7}, {54,7}, {55,7} , {55,8}, {55,7}, {183,7}, {55,7}, {56,7}, {56,8}, {56,7}, {1,7}, { 56.7}, {57.7}, {57.8}, {57.7}, {183.7}, {57.7}, {58.7}, {58.8}, {58, 7}, {5,7}, {58,7}, {59,7}, {59,8}, {59,7}, {183,7}, {59,7}, {60,7} , {60,8}, {60,7}, {1,7}, {60,7}, {61,7}, {6i, 8}, {61,7}, {38,7}, { 61.7}, {62.7}, {62.8}, {62.7}, {237.7}, {62.7}, {63.7}, {63.8}, {63, 7}, {0,7}, {63,7), {64,7}, {64,8}, {64,7}, {64,7}, {64,7}, {65,7} , {65,8}, {65,7}, {183,7}, {65,7}, {66,7}, {66,8}, {66,7}, {1,7}, { 66.7}, {67.7}, {67.8}, {67.7}, {182.7), {67.7}, {68.7}, {68.8}, {68, 7}, {68,7}, (68,7),) 69,7), {69,8}, {69,7}, {183,7}, {69,7}, {70,7} , {70,8}, {70,7}, {1,7}, {70,7}, {71,7}, {71,8}, {71,7}, {182,7}, { 71,7}, {72,7}, {72,8}, {72,7}, {5,7}, {72,7}, {73,7}, {73,8}, {73, 7}, {183,7}, {73,7}, {74,7}, {74,8}, {74,7}, {1,7}, {74,7}, {75,7} , {75,8}, {75,7}, {76,7}, {75,7}, {76,7}, {76,8}, {76,7}, {183,7 }, {76,7}, {77,7}, {77,8}, {77,7}, {1,7}, {77,7}, {78,7}, {78,8}, {78,7}, {183,7}, {78,7), {79,7}, {79,8}, {79,7}, {5,7}, {79,7}, {80 , 7}, {80,8}, {80,7}, {183,7}, {80,7}, {81,7}, {81,8}, {81,7}, {1,7 }, {81,7}, {82,7}, {82,8}, {82,7}, {38,7}, {82,7}, {83,7}, {83,8}, {83.7}, {237.7}, (83.7), {84.7}, {84.8}, {84.7}, {0.7}, {84.7}, {85 , 7}, {85,8}, {85,7), {85,7}, {85,7}, {86,7}, {86,8}, {86,7}, {183,7 }, {86,7}, {87,7}, {87,8}, {87,7}, {1,7}, {87,7}, {88,7}, {88,8}, {88,7}, {182,7}, {88,7}, {89,7}, {89,8}, {89,7}, {89,7}, {89,7}, {90 , 7}, {90,8}, {90,7}, {183,7}, {90,7}, {91,7}, {91,8}, {91,7}, (1,7 ), {91.7}, {92.7}, {92.8}, {92.7}, {182.7}, {92.7}, {93.7}, (93.8), {93,7}, {5,7}, {93,7}, {94,7}, {94,8}, {94,7}, {183,7}, {94,7}, {95 , 7}, {95,8}, {95,7}, {1,7}, {95,7}, {96,7}, {96,8}, {96,7}, {76,7} }, {96.7), {97.7}, {97.8}, {97.7}, {183.7}, {97.7}, {98.7}, {98.8}, {98,7}, {1,7}, {98,7}, {99,7}, {99,8}, {99,7}, {183,7}, {99,7}, {100 , 7}, {100,8}, {100, 7), {5,7}, {100,7}, {101,7}, {10), 8}, {101,7} , {183.7}, {101.7), {102.7}, {102.8}, {102.7}, {1.7}, {102.7}, {103.7}, {103, 8}, {103,7}, {38,7}, {103,7}, {104,7}, {104,8}, {104,7}, {237,7}, {104,7} , {105.7}, {105.8}, {105.7}, {0.7}, {105.7}, {106.7}, {106.8}, {106.7}, { 106.7), {106.7}, {107.7}, {I 07.8}, {107.7}, {183.7}, {107.7}, {108.7}, {108 , 8}, {108,7}, {1,7), {108,7}, {109,7}, {109,8}, {109,7}, {182,7}, {109,7} }, {110,7}, {110,8}, {110,7}, {110,7}, {110,7}, {II 1,7}, {111,8}, {111,7} , {183,7}, {111,7}, {112,7}, {112,8}, {112,7}, {1,7), {112,7}, {153,7}, { 1) 3,8}, {113,7}, {182,7}, {113, 7}, {114,7}, {114,8}, {114,7}, {5,7), { 114.7}, {115.7), {115.8), {115.7}, {183.7}, {115.7}, {116.7}, {116.8}, {116 7}, {1,7}, {116,7}, {117,7}, {11,8,8}, {117,7}, {76,7}, {117,7}, {118,7 ), {118.8), {118.7), {183.7), {118.7}, {119.7}, {119.8}, {119.7}, {1.7}, {119,7}, {120,7}, {120,8}, {120,7}, {183,7}, {120,7}, {121,7}, {121,8}, {121 , 7), {5,7}, {121,7}, {122,7}, {122,8}, {122,7}, {183,7}. {122.7}, {123.7}, {123.8}, {123.7}, {1.7}, {123.7}, {124.7}, {124.8}, {124 , 7), {38,7}, {124,7}, {125,7}, {125,8}, {125,7}, {237,7}, {125,7}, {126,7 }, {126,8}, {126,7}, {0,7}, {126,7}, {127,7}, {127,8}, {127,7}, {127,7}, {127,7}, {128,7}, {128,8}, {128,7}, {183,7}, {128,7}, {129,7}, {129,8}, {129} , 7}, {!, 7}, {129,7}, {130,7}, {130,8}, {130,7}, {18 2,7), {130,7}, {131, 7}, {131.8}, {131.7}, {131, 7}, {131.7), {132.7}, {132.8), {132.7}, {183.7} , {132,7}, (133,7), {133,8}, {133,7}, {1,7}, {133,7}, {134,7}, {134,8}, { 134.7), {182.7), {134.7), {135.7), {135.8}, {135.7}, {5.7}, {135.7}, {136, 7}, (136.8), {136.7}, {183.7}, {136.7}, {137.7}, {137, 8), {137.7}, {1.7) , {137,7}, {138,7}, {138,8}, {138,7}, {76,7}, {138,7}, {139,7}, {139,8}, { 139.7}, {183.7}, {139.7}, (140.7), {140.8}, {140.7}, {), 7}, {140.7}, {141, 7}, {141,8}, {141,7}, {183,7}, {141,7}, {142,7}, {142,8}, {142,7}, {5,7} , (142.7), {143.7}, {143.8}, {143.7}, {183.7}, {143.7}, {1 44.7}, {144.8}, {144 , 7}, {1,7}, {144,7}, {145,7), {145, 8}, {145,7}, {38,7}, {145,7}, {146,7}, {146,8}, {146,7}, {237,7}, {146,7} , {147,7}, {147,8}, {147,7}, {0,7}, {147,7}, {148,7}, {148,8}, {148,7}, { 148.7}, {148.7), {149.7}, {149.8}, {149.7}, {183.7}, (149.7), {150.7}, (150, 8), {150,7}, {1,7}, {150,7}, {151,7}, {151,8}, {151,7}, {182,7}, {151,7} , (152.7), {152.8), {152.7}, {152.7), {152.7}, (153.7), {153.8}, (153.7), ( 183.7), {153.7}, {1 54.7), {154.8}, {154.7}, {1.7}, {154.7}, {155.7}, {155.8 ), {155.7}, {182.7}, {155.7), {156.7}, {156.8}, (156.7), {5.7}, {156.7}, {157.7}, {157.8}, {157.7}, {183.7}, {157.7}, {158.7}, {158.8}, {158.7}, {1 , 7), {158,7}, {159,7}, {159,8}, {159,7}, {76,7}, {159,7}, {160,7}, {160,8} }, {160,7}, {183,7}, {160,7}, {161,7}, {161,8}, {161,7}, {1,7}, {161,7}, {162.7}, {162.8}, {162.7}, {183.7}, {162.7}, (163.7}, {163.8}, {163.7}, {5 , 7}, {163,7}, {164,7}, {164,8}, {164,7}, {183,7}, {164,7}, {165,7}, {165,8} }, {165,7}, {1,7}, {165,7}, {166,7}, {166,8}, {166,7}, {38,7}, (166,7), {167.7}, (167.8), {167 , 7}, {237,7}, {167,7}, {168,7}, {168,8}, {168,7}, {0,7}, {168,7}, {169,7} }, {169.8}, {169.7}, {169.7}, {169.7}, {170.7}, {170.8}, {170.7}, {183.7}, {170,7}, {171,7}, {171,8}, {171,7}, {1,7}, {171,7}, {172,7}, {172,8}, {172 , 7}, {182,7}, {172,7}, {173,7}, {173,8}, {173,7}, {173,7}, {173,7}, {174,7} }, {174,8}, {174,7}, {183,7}, {174,7}, {175,7}, {175,8}, {175,7}, {1,7}, {175 _t 7}, {176.7} ₁ {176.8}, {176.7}, {182.7}, {176.7}, {177.7}, {177.8}, {17 7.7}, {5.7}, {177.7}, {178.7}, {178.8}, {178.7}, {183.7}, {178.7}, {179, 7}, {179,8}, {179,7}, {1,7}, {179,7}, {180,7}, {180,8}, {180,7}, {76,7} , {18 0.7}, {181.7}, {181.8}, {181.7}, {183.7}, {181.7}, {182.7}, {182.8}, {182.7}, {1.7}, {182.7}, {183.7}, {183.8}, {183.7}, {183.7}, {183.7}, {184 , 7}, {184,8}, {184,7}, {5,7}, {184,7}, {185,7}, {18 ₅ , 8}, {185,7}, {183, 7}, {185,7}, {186,7}, {186,8}, {186,7}, {1,7}, {186,7}, {187,7}, {187,8} , {187.7}, {38.7}, {187.7}, {188.7}, {188.8}, {188.7}, {237.7}, {188.7}, { 189.7}, {189.8}, {189.7}, {0.7}, {189.7}, { 190.7}, {190.8}, {190.7}, {190.7}, {190, 7}, {191, 7}, {191.8}, {191, 7}, {183, 7}, {191.7}, {192.7}, {192.8}, {192.7}, {1.7}, {192.7}, {193.7}, {193.8} , {193.7}, {182.7}, {193.7}, {194.7}, {1 94.8), {194.7}, {194.7}, {194.7}, {195.7}, {195.8}, {195.7}, {183.7}, {195.7}, {196.7}, {196.8}, {196.7}, {1 , 7}, {196,7}, {197,7}, {197,8}, {197,7}, {182,7}, {197,7}, {198,7}, {198,8 }, {198,7}, {5,7}, {198,7}, {199,7}, {199,8}, {199,7}, {183,7}, {199,7}, {200,7}, {200,8}, {200,7}, {1,7}, {200,7}, {201,7}, {201,8}, {201,7}, {76 , 7}, {201,7}, {202,7}, {202,8}, {202,7}, {183,7}, {202,7}, {203,7}, {203,8 }, {203,7}, {1, 7}, {203,7}, {204,7}, {204, 8}, {204,7}, {183,7}, {204,7}, {205.7}, {205.8}, {205.7}, {5.7}, {205.7}, {206.7}, {206.8}, {206.7}, {183 , 7}, {206,7}, {207,7}, {207,8}, {207,7}, {1,7}, {207,7}, {208,7}, {208,8} }, {208,7}, {38,7}, {208,7}, {209,7}, {209,8}, {209,7}, {237,7}, {209,7}, {210,7}, {210,8}, {210,7}, {0,7}, {210,7}, {211,7}, {211,8}, {211,7}, {211 , 7}, {211,7}, {212,7}, {212.8}, {212.7}, {183.7}, {212.7}, {213.7}, {213.8}, {213.7}, {1, 7}, {213 , 7}, {214,7}, {214,8}, {214,7}, {182,7}, {214,7}, {215,7}, {215,8}, {215,7} }, {215.7}, {215.7}, {216.7}, {216.8}, {216.7}, {183.7}, {216.7}, {217.7}, {217.8}, {217.7}, {1.7}, {217.7}, {218.7}, {218.8}, {218.7}, {182.7}, {218} , 7}, {219,7}, {219,8}, {219,7}, {5,7}, {219,7}, {220,7}, {220,8}, {220,7 }, {183,7}, {220,7}, {221,7}, {221,8}, {221,7}, {1,7}, {221,7}, {222,7}, {222.8}, {222.7}, {76.7}, {222.7}, {223.7}, {223.8}, {223.7}, {183.7}, {223, 7}, {224,7}, {224,8}, {224,7}, {1,7}, {224,7}, {225,7}, {225,8}, {225,7} , {183,7}, {225,7}, {226,7}, {226,8}, {226,7}, {5,7}, {226,7}, {227,7}, { 227.8}, {227.7}, {183, 7}, {227.7}, {228.7}, {228.8}, {228.7}, {1.7}, {228, 7}, {229,7}, {229,8}, {229,7}, {38,7}, {229,7}, {230,7}, {230,8}, {230,7} , {237.7}, {230.7}, {23 1, 7}, {231.8}, {231.7}, {0.7}, {231.7}, {232.7}, {232.8}, {232.7}, {232.7}, {232.7}, {233.7}, {233.8}, {233.7}, {183.7}, {233} , 7}, {234,7}, {234,8}, {234,7}, {1 , 7}, {234,7}, {235,7}, {235,8}, {235,7}, {182,7}, {235,7}, {236,7}, {236,8} }, {236,7}, {236,7}, {236,7}, {237,7}, {237,8}, {237,7}, {183, 7}, {237,7}, {238,7}, {238,8}, {238,7}, {1, 7}, {238,7}, {239,7}, {239,8}. {239,7}, {182,7}, {239,7}, {240,7}, {240,8}, {240,7}, {5,7}, {240,7}, {241} , 7}, {241,8}, {241,7}, {183,7}, {241,7}, {242,7}, {242,8}, {242,7}, {1,7 }, {242,7}, {243,7}, {243,8}, {243,7}, {76,7}, {243,7}, {244,7}, {244,8}, {2 44,7}, {183,7}, {244,7}, {245,7}, {245,8}, {245,7}, {1,7}, {245,7}, { 246.7}, {246.8}, {246.7}, {183.7}, {246.7}, {247.7}, {247.8}, {247, 7}, {5, 7}, {247,7}, {248,7}, {248,8}, {248,7}, {183,7}, {248,7}, {249,7}, {249,8} , {249,7}, {1,7}, {249,7}, {250,7}, {250,8}, {250,7}, {38,7}, {250,7}, { 251.7}, {251, 8}, {251.7}, {237.7}, {251.7}, {252.7}, {252.8}, {252.7}, {0, 7}, {252,7}, {253,7}, {253,8}, {253,7}, {253,7}, {253,7}, {254,7}, {254,8} , {254, 7}, {183,7}, {254,7}, {255,7}, {255,8}, {255,7}, {1,7}, {255,7}, { 0.7}, {0.8}

APPENDIX 3 Coding of the different 7-cycle instructions (file try7.txt)

{{LDA.OMLDAJÎΛLDA ^}, ... (insert here elements of the form {LDA, i}) ..., {LDA, 2 ₅ 1}, {LDA, 2 ₅ 2}, {LDA.253} , {LDA, 2 ₅ 4}, {LDA, 2 ₅₅ }, {BRA, 0}, (BRA ₁ ]} _t {BRA, 2}, ... insert here elements of the form {BRA, i}) ..., {BRA, 2 ₅ 3}, {BRA, 2 ₅ 4}, {BRA, 2 ₅₅ }, {INC, Q)}

APPENDIX 4 Coding of the different 8-cycle instructions (file try8.txt)

{{STA, 1}, {STA, 2J, ... insert here elements of the form {STA, i}) ..., {STA _> 2 ₅ 2}, {STA, 2 ₅ 3}, {STA , 2 ₅ 4), {STA 25 _5}, {STA, 0}}

ANNEX 5

portR equ $ 00; read port location

PortS egu PortR + 1; send port location

org portR dw $ 0000 start: port ports addrl Ida portR sta ports

Ida addrl + 1 sta ports inca sta ports sta addrl + 1 sta ports bne send

org $ lffE dw start

Claims

A method of verifying the conformity of the logical contents of a computing device (2) to a reference content, the computing device having a processor (4), a memory (6) in which the processor can read and write, and an output input device (8) allowing a dialogue between the processor (4) of the apparatus and the outside world, the method comprising the following steps

sending (10) to the apparatus (2) a request for loading into the memory (6) and executing a verification program (P), the verification program being able to write data into the memory (6) of the apparatus and reading data in the memory (6) to send them to the input input device (8);

sending (12) to the apparatus a program execution request (P) for saturating the available memory (6) not occupied by the program (P); - exchange (14, 16) messages with the device running the program (P) and

- checking (18) of the conformity of the logical contents of the device according to the messages exchanged with the device.

2. The method of claim 1, wherein the verification of compliance is effected according to the content of the messages exchanged with the apparatus.

3. The method of claim 1 or 2, wherein the checking of the conformity is carried out according to the measurement of the timing in time of the messages exchanged with the apparatus.

The method of claim 3, wherein the verification program (P) comprises additional read instructions, causing increased activity on the output input device (8).

The method of one of claims 1 to 4, further comprising a step of proving compliance verification by a backtracking technique applied to the instruction set executable by the processor (4).

The method of claim 5, wherein the step of demonstrating compliance by a backtracking technique comprises evaluating the various candidate instructions in a concrete manner.

The method of claim 5, wherein the step of demonstrating conformance by a backtracking technique comprises evaluating the various candidate instructions in an abstract manner.

The method of one of claims 1 to 4, further comprising a step of proving the compliance check by an exhaustive search of the possible programs applied to the executable instruction set by the processor (4).

The method of one of claims 1 to 8, wherein the request for loading into the memory comprises a request to load the verification program (P) into the memory (6) from the input input device ( 8).

The method of one of claims 1 to 8, wherein the request for loading into the memory includes a request to activate a verification program (P) contained in the apparatus.

The method of one of claims 1 to 10, wherein executing the program (P) to saturate the available memory comprises reading stuffing data from the input input device and writing the data of jam in the memory.

The method of one of claims 1 to 11, wherein executing the program (P) to saturate the available memory includes reading a problem from the input input device and the resolution by the program. checking (P) of the problem using the available memory.

The method of one of claims 1 to 12, wherein executing the program (P) to saturate the available memory comprises reading a seed from the input input device and expanding the seed. using available memory.

The method of one of claims 1 to 13, wherein the message exchange comprises: sending (14) to the apparatus a request for reading data from the memory (6); and

- Reception (16) from the device of the data read from the memory (6), including the code of the verification program.

The method of one of claims 1 to 13, wherein the verification program is capable of performing a function on data of the memory, and wherein the message exchange comprises:

sending (14) to the apparatus a request for executing the function and for reading data from the memory (6); and

receiving (16) from the apparatus the result of the function and the code of the verification program read from the memory.

The method of claim 15, wherein the function comprises hashing calculation of the data of the memory other than the code of the verification program.

The method of one of claims 1 to 13, wherein executing the program (P) to saturate the available memory comprises reading a problem from the input-output device and solving the problem using the available memory and wherein the message exchange comprises:

sending (14) to the apparatus a problem; and

receiving (16) from the apparatus the result of the problem and the code of the verification program read from the memory.

18. The method of any one of claims 1 to 17, wherein the verification program code includes instructions for replaying the code to the output input device.

19. The method of one of claims 1 to 18, wherein the execution of the verification program causes the erasure of the memory, excluding the code of the verification program.

20. A method of restoring a computing device having a processor (4), a memory (6) in which the processor can read and write, and an input input device (8) for dialogue between the processor (4). ) of the apparatus and the outside world, the method comprising the steps of - backup (30) to the outside world of the data present in the memory (6);

- checking (32) the conformity of the logical contents of the computing device (2) to a reference content, according to the method of one of claims 1 to 19;

- analysis (34) and if necessary treatment of the saved data and - recopy (38) of the analyzed data in the memory of the device.

21. A computer apparatus, comprising a processor (4), a memory (6) in which the processor can read and write, an output input device (8) for a dialogue between the processor (4) of the apparatus and the outside world and a verification program stored in the apparatus, the verification program including instructions adapted to cause, when executed by the processor,

- the writing of data in the memory (6) of the device and

reading the data in the memory (6), including the code of the verification program, to send them to the input input device (8).

A computing device, comprising - a first subset having a processor, a memory in which the processor can read and write, and an input input device;

a second subset, the second subset being adapted to interact with the processor of the first subset through the input-output device and to verify the conformity of the logic state of the first subset according to the method; of one of claims 1 to 19.