METHOD TO SECURE WRITING IN MEMORY AGAINST ATTACKS BY
RADIATION OR OTHER MEANS
This invention concerns a method and a device to secure an electronic assembly implementing a program to be protected. More precisely, the purpose of the method is to propose a defence against attacks by radiation, flash, light, laser, glitch or other and more generally against any attack disturbing the execution of the program instructions. These attacks modify the instructions to be executed, resulting in non-execution or incorrect execution of certain parts of the program.
TECHNICAL FIELD
When a program is executed by a microprocessor, attacks for example by injecting faults via laser, glitch or electromagnetic radiation modify the instruction codes executed by the processor: the program instructions may be replaced by instructions producing a different effect. Consequently, a security processing sequence in an operating system for smart cards may be made inoperative by an attacker. Applied during an instruction sequence designed to write in non volatile memory of the card, these attacks may disable security writes used, for example, to count a number of incorrect authentications. Through this type of attack, the attacker also prevents the card from storing security-related events.
Amongst the known defences, one solution consists in setting flags in a byte of the RAM (Random Access Memory) at regular intervals and in checking, at a particular point in the execution of the software, that all flags which should be set have actually been set. Setting up this type of defence is tedious, however, since specific volatile memory areas must be allocated and processing added in the code to be protected, wherever this is required. In addition, since attacks of this type are becoming shorter and more precise, the known solutions are becoming less effective. Firstly, the attack may be too short to have any effect on the setting of flags: the flags in RAM may
indicate to the program that all writes have been made correctly, even if this is not the case. Secondly, the flag verification software may itself be disturbed.
One purpose of this invention is to protect all writes contained in the program.
Another purpose of this invention is to propose efficient protection even for very short attacks.
SUMMARY OF THE INVENTION
This invention concerns a method to secure the write in storage means of an electronic assembly comprising information processing means, said method comprising an atomic write process to write data recorded in a write log, characterised in that it consists in checking a sequence of atomic writes in said storage means by setting in said write log one or more indicators in memory as proof of one of more successive writes recorded in said log.
This invention also concerns an electronic module in which said method is implemented, a card comprising said module and a program to implement said method.
BRIEF DESCRIPTION OF THE DRAWINGS
Other purposes, features and advantages of the invention will appear on reading the description which follows of the implementation of the method according to the invention and of a mode of realisation of an electronic system designed for this implementation, given as a non-limiting example, and referring to the attached drawings in which:
- figure 1 is a diagrammatic representation of an example of a device in which the method according to this invention is implemented;
- figure 2 is a diagrammatic representation of the content of part of the memory of a device in which the known atomic write process is implemented;
- figure 3 is a graph representing the various steps of a known atomic write process;
- figure 4 is a graph representing the various steps of one form of realisation of the method according to this invention;
- figure 5 is a diagrammatic representation of the content of part of the memory of a device according to a first form of realisation in which the method according to this invention is implemented;
- figure 6 is a diagrammatic representation of the content of part of the memory of a device according to a second form of realisation in which the method according to this invention is implemented.
WAY OF REALISING THE INVENTION
The purpose of the method according to the invention is to secure an electronic assembly and for example a portable object such as a smart card implementing a program. The electronic assembly comprises at least processing means such as a processor and storage means such as a memory. The program to be secured is installed in the memory, for example ROM (Read Only Memory) type, of said assembly.
As a non-limiting example, the electronic assembly described below corresponds to an onboard system comprising an electronic module 1 illustrated on figure LThis type of module is generally realised as a monolithic integrated electronic microcircuit, or chip, which once physically protected by any known means can be assembled on a portable object such as for example a smart card, microcircuit or integrated circuit card (microprocessor card, etc.) or other card which can be used in various fields.
The electronic module 1 comprises a microprocessor CPU 3 with a two-way connection via an internal bus 5 to a non volatile memory 7 of type
ROM, EEPROM (Electrical Erasable Programmable Read Only Memory), Flash, FeRam or other containing the program PRO 9 to be executed and a transaction buffer 10 containing a write log used for temporary data storage, a volatile memory 11 of type RAM, input/output means I/O 13 to communicate with the exterior.
The method according to the invention consists in checking that each write in non volatile memory while executing the program 9 is executed correctly.
The method according to the invention consists in checking the atomic write of data in non volatile memory by setting in a write log, when executing a program 9, an indicator in memory as proof of a write. The "write log" means the list of all write operations to be made atomically on the memory, the log containing control data and/or data to be written and/or any other type of information. A sequence of "atomic" writes means all writes recorded in the write log such that, if the log is validated (sequence closed), all the writes are made, even in the event of attack; if the log is not validated, none of said writes is made. According to this invention, writing the indicator in memory is made atomic with the write of the planned data in the write log.
Each write in the log and the indicator are atomic, so the fact that the proof indicator is in memory guarantees that the data has actually been written. By checking that the proof indicator is present, the program ensures a posteriori that the write was made. If the write was not made, various measures can then be taken, such as, for example, triggering by program 9 of a security defence, interruption of program execution or setting of a fraud indicator in non volatile memory 7 to indicate that a fraudulent attack has taken place and for example to prohibit any future use of the operating system.
The methods used to make several atomic writes in the memory and more especially in the non volatile memory 7 of a microprocessor card as an anti-tearing mechanism are known. They use for example, as shown on figure 2, the transaction buffer 10; the transaction buffer 10 is located in the non volatile memory 7 and acts as log for the writes to be made.
The known atomic write process may consist of the following sequence (refer to figure 3):
After opening the atomic session (step A), for each write (step B), the process consists in creating (step C) an entry in the write log of the transaction buffer 10 comprising the control data (Control Data) (address
AdM , Adr2, Adr3 length of useful data, L1 , L2, L3 ) and the useful data (Data) (Datai , Data2, Data3, ...) (see figure 2).
When closing the atomic session (step D)1 the process validates the transaction buffer to indicate that it contains an atomic write sequence. The method then consists in reading (steps E, G) each entry in the log and making, then checking the corresponding write, repeating each incorrect write (step F). Then in step H, the method invalidates the transaction buffer to indicate that it contains no atomic write sequence.
If the writes of the atomic sequence are interrupted, the process resumes at step E as long as the transaction buffer has not been invalidated.
This type of atomic write process protects against an interruption in the atomic session in progress: it guarantees that either the writes recorded in the write log of the transaction buffer are ignored and none of the writes recorded is made if the session has not been closed; or all the writes recorded in the log of the transaction buffer are made if the session has been closed.
However, this type of process does not protect against disturbances in system operation which allow the session to continue: one of the writes planned in the atomic session could be prevented without being detected by the atomicity mechanism.
The method according to this invention therefore consists in combining the known atomic data write process with the write of a write indicator. The indicator is entered in the write log. The data and indicator writes are made atomic...
The mode of realisation of this invention described below and illustrated on figure 4 combines the atomicity process like that described
above and a counter acting as indicator of the successive writes in non volatile memory during a command, and for example a counter of the number of writes which is incremented on each new write.
As shown on figure 5, according to one form of realisation of the invention, the value (Counter) of the write counter (C1 , C2, C3) in EEPROM is included in the block of control data of the write log of the atomicity process (Control Data). According to another form of realisation illustrated on figure 6, the value of the write counter is included in the atomicity data of the write log of the atomicity process (Atomicity Data). For each new write in the atomic session, the counter is incremented (step C- figure 4) and the control and atomicity data are updated in the same block, under the protection of a checksum (CKS1 , CKS2, CKS3 on figure 5 or CKS on figure 6, depending on the form of realisation) on part or all of the data (step C). The counter is incremented on each new write in the atomic session. The atomicity process guarantees that once the atomic session has been closed, all the writes recorded in the log will be made completely. This mode of realisation guarantees that each incrementation of the counter is atomic with the corresponding write in the log. When closing the atomic session in progress, each incrementation of the counter during the atomic session corresponds to a write actually made when closing the atomic session.
As shown on figure 4 therefore, after opening the atomic session, on each new write, i.e. on each new entry in the write log of the transaction buffer 10, the counter is incremented (step C). Depending on the form of realisation, the new value of the counter is written with the control data of the entry concerned (C1 , figure 5) or in the atomicity data (Ci, figure 6). The value of the counter before opening the atomic session is stored in the atomicity data (C, figure 6). When closing the atomic session, the value of the counter is compared with the expected value and if they match and the other checks planned in the known atomic write processes are also correct, the buffer is validated. The value of the counter C before opening the session is then assigned the value of the counter at closure.
This form of realisation implementing a counter provides a means of
checking during program execution and/or when closing the atomic session that the writes planned in the log have been made by comparing the actual value of the counter with the expected value.
The method according to the invention consists in incrementing said counter and making each atomic write simultaneously. If an attack occurs during the write, the write will not be made correctly, the counter will not be incremented and the value of the counter will be different from the expected value; the attack is therefore detected and a specific action is carried out by the program or the processor. Two methods can be used to make the recording of a new write in the write log of the transaction buffer and the incrementation of the write counter in non volatile memory atomic: the counter is placed in the same block as all or some of the control and/or atomicity data and/or the useful data of the atomicity process; and/or the counter and all or some of the control and/or atomicity data and/or the useful data are protected by the same checksum which validates this write, either of the two methods alone is sufficient to guarantee atomicity. The writes in the non volatile memory 7 of type EEPROM generally encountered in smart cards, are made in blocks (usually 64 or 128 bytes). All the bytes programmed in a given block are written simultaneously, making the write of several bytes in the same block atomic. The programming duration is the same, whether for a single byte in the block or for all bytes in the block, of the order of 1 to 5 ms. This duration must be multiplied by the number of blocks to be written.
Atomicity can be achieved by using this intrinsic property of EEPROM. By placing the proof indicator of a write in the same block as the data to be written in the write log, if the proof indicator is present we can be certain that the data has actually been written.
Placing the write counter in the same block as the control and/or atomicity data and/or the useful data of the atomicity process helps improve
the performance of the protection mechanism. No extra block writes are required, which helps to limit the number of writes.
The method according to the invention consists according to the second method in calculating a checksum (CKS1 , CKS2, CKS3 on figure 5, CKS on figure 6) on the value of the counter and on all or some of the control and/or atomicity data and/or the useful data and making the write in the log simultaneously and in writing the value obtained for the checksum in the log. The method according to the invention then consists in verifying the checksum by comparing it with the precalculated value written in memory. Note that the checksum may concern the indicator and all or some of the useful data, and/or one or more items of atomicity data and/or one or more items of control data depending on the form of realisation chosen. The protection of the write counter and of the control data by a checksum guarantees the efficiency of the mechanism with any non volatile memory and for example with memory types other than EEPROM.