NO333768B1 - Procedure for Protecting a Software, Using a Sacred Detection and Enforcement Principle, against Unauthorized Use of it - Google Patents

Abstract

The invention relates to a method for protecting, from a device, a vulnerable software against unauthorized use thereof, said vulnerable software running in a data processing system. The method comprises defining at least one execution property of the software which can be monitored at least partially in one unit, at least one criterion to comply with for at least one program execution property, a detection device for execution in a unit which makes it possible to detect whether at least one program execution property fails to comply with at least one associated criterion, as well as a coercive device for execution in a device to inform the data processing system and / or change the operation of a software when at least one criterion is not respected.

Description

The present invention relates to the technical area of data processing systems in a general sense, and is more specifically aimed at means for protecting software running on these data processing systems against unauthorized use.

The subject of the invention is particularly directed to means for protecting software against unauthorized use when using a processing and memory unit, such a unit being generally realized in the form of a chip card or a physical key for a USB port.

In the above technical area, the main problem concerns the unauthorized use of software by users who have not paid for the license rights. This illegal use of software causes an obvious loss to software developers, software distributors and/or any person who integrates such software into products. To avoid such illegal copies, various solutions have been proposed to protect software.

US 5,754,646 relates to a method for protecting a publicly distributed software.

WO 99/66387 A1 discloses a method for verifying the execution of a computer program.

FR 2 634 917 describes a method and a device for the protection and generalization of a software.

A protection solution is thus known which uses a hardware-implemented protection system, called a protection key or "security plug". Such a protection key must guarantee that the software only runs if the key is present. However, it must be recognized that this solution is ineffective, because it has the disadvantage that it is easily bypassed. A person with criminal intent or a hacker can, with the help of special tools such as disassemblers, remove the instructions that control the protection key. It is then possible to generate illegal copies corresponding to modified versions of the software capable of running without the protection. Furthermore, this solution cannot be generalized to all software, as it is difficult to connect more than two protection keys to the same system.

The invention specifically aims to provide a solution to the above-mentioned problems by proposing a method for protecting a software against unauthorized use, using an ad hoc processing and memory unit, the presence of such a unit being necessary for the software to be fully functional.

The main features of the invention are indicated in the method according to the independent claim 1. Further features of the invention appear from the non-independent claims.

In order to achieve such an objective, the invention relates to a method for protecting, by using at least one blank unit which at least includes a processing device and a memory device, a vulnerable software against its unauthorized use, said vulnerable software being generated from a source and running in a data processing system. The method according to the invention includes:

during a protection phase:

• defining:

- at least one program execution characteristic that is prone to be monitored at least partially in a device, - at least one criterion to comply with for at least one program execution characteristic, - a detection device for implementation in a device, which makes it possible to detect that at least one program execution property does not comply with at least one associated criterion, - and a coercive device for implementation in a device, which makes it possible to inform the data processing system and/or change the behavior of a software when at least one criterion is not complied with, • produce an exploitation means which makes it possible to transform the blank unit of a unit capable of implementing the detection device and the coercion device,

• generate a protected software by:

- selecting at least one program execution characteristic to monitor among the program execution characteristics that are prone to be monitored, - selecting at least one criterion to comply with for at least one selected program execution characteristic, - selecting at least one algorithmic processing which, during execution of the vulnerable software, applies at least one operand and makes it possible to obtain at least one result, and in connection with which at least one selected

program execution properties must be monitored,

- selecting at least one portion of the source of the vulnerable software containing at least one selected algorithmic processing, - generating the source of the protected software from the source of the vulnerable software by modifying at least one selected portion of the source of the vulnerable software to generate at least one modified part of the source of the protected software, this modification being such that: > during execution of the protected software, a first execution part runs in the data processing system and a second execution part runs in a device, obtained from the blank device after uploading information,

> the second execution part at least performs the functionality of

at least one selected algorithmic processing,

> and that during execution of the protected software, at least one selected program execution property is monitored by the second execution part, and the fact that a criterion is not met leads to a change in the behavior of the protected software,

- and generate:

> a first object part of the protected software from the source of the protected software, said first object part being such that during execution of the protected software, a first execution part appears, which is executed in the data processing system and of which at least a part takes into account that at least one selected program execution property is monitored,

> and a second object part of the protected software, which contains the exploitation means that implements the detection device and the coercion device, said second object part being such that, after uploading to the blank device and during execution of the protected software, the second execution part appears, by means of which at least one selected program execution property

monitored and by means of which the fact that a criterion is not exceeded

held leads to a change in the operation of the protected software,

and uploading the second object part to the blank entity, for the purpose of generating the entity,

and during a use phase during which the Protected Software is executed:

• in the presence of the unit, and:

- as long as all criteria corresponding to all the monitored execution properties of all the modified parts of the protected software are met, make said parts of the protected software able to function nominally and consequently that the protected software can function nominally, - if at least one of the criteria corresponding to a monitored execution property of a portion of the protected software is not observed, inform the data processing system about this and/or change the behavior of the portion of the protected software, so that the behavior of the protected software is changed, • and in the absence of the device, despite the request from a part of the first execution part to trigger execution, in the unit, of the functionality of at least one selected algorithmic processing, not being able to comply with said request in a correct way, so that in any case said part is not executed correctly and that consequently the protected software is not complete g functional.

According to an alternative embodiment, the method according to the invention comprises:

during the protection phase:

defining:

- as a program execution property prone to be monitored, a variable for measuring the use of a functionality in a software, - as a criterion to comply with, at least one threshold associated with each measurement variable, - and an actualization device that makes it possible to update at least one measurement variable, • produce the means of exploitation which enables the unit to also implement the actualization device,

• and modify the Protected Software by:

- select as program execution property to monitor, at least one variable to measure the use of at least one functionality in a software,

- choose:

> at least one functionality in the protected software whose use is

tend to be monitored using a measurement variable,

> at least one measurement variable used to quantify the use of the aforementioned

functionality,

> at least one threshold associated with a selected measurement variable that corresponds to one

restriction on the use of said functionality,

> and at least one method for updating a selected measurement variable depending on the use of said functionality,

- and modifying at least one selected part of the source of the protected software, this modification being such that, during execution of the protected software, the measurement variable is updated by means of the second execution part depending on the use of said functionality, and

that at least one threshold crossing is taken into account,

and during the use phase, in the presence of the device, and if at least one crossing of a threshold corresponding to at least one restriction on use is detected, inform the data processing system of this and/or change the behavior of said part of the protected software, so that the behavior of the protected the software changes.

According to an alternative embodiment, the method according to the invention comprises:

during the protection phase:

• defining:

- for at least one measurement variable, several associated thresholds,

- and various coercive devices corresponding to each of the mentioned thresholds,

• and modify the Protected Software by:

- select, in the source of the protected software, at least one selected measurement variable with which several thresholds must be associated corresponding to different restrictions on the use of the functionality,

- select at least two thresholds associated with the selected measurement variable,

- and modifying at least one selected portion of the source of the protected software, this modification being such that, during execution of the protected software, the crossings of the various thresholds are taken

taken into account in different ways, by means of the second execution part, and during the use phase:

in the presence of the device:

- if crossing a first threshold is detected, instruct the protected software not to use the corresponding functionality any more, - and if crossing a second threshold is detected, disable the corresponding functionality and/or at least one part of the protected software.

According to an alternative embodiment, the method according to the invention comprises:

during the protection phase:

• define refill devices that make it possible to credit at least one program functionality monitored by a measurement variable with at least one additional use, • create the exploitation means that also make it possible for the entity to implement the refill device,

• and modify the Protected Software by:

- select, in the source of the protected software, at least one selected measurement variable which makes it possible to limit the use of a functionality and which must be able to be credited with at least one further use, - and modify at least one selected share, as this the modification is such that during a phase called refill phase, at least one further use of at least one

functionality corresponding to a selected measurement variable can be credited,

and during the refill phase:

update at least one selected measurement variable and/or at least one associated threshold for to allow at least one further use of the functionality.

According to an alternative embodiment, the method according to the invention comprises:

during the protection phase:

• defining:

- as program execution property prone to be monitored, a program usage profile, - and as criterion to comply with, at least one program execution property,

• and modify the Protected Software by:

- select as a program execution characteristic to monitor, at least one program usage profile, - select at least one program execution characteristic that at least one selected usage profile must follow, - and modify at least one selected portion of the source of the protected software, this modification being such that, during execution of the protected the software, the other execution part complies with all

the selected execution properties,

and during the use phase, in the presence of the device, and if it is detected that at least one execution characteristic is not observed, inform the data processing system about this and/or change the behavior of the portion of the protected software, so that the behavior of the protected software is changed.

According to an alternative embodiment, the method according to the invention comprises:

during the protection phase:

defining:

- an instruction set whose instructions are likely to be executed in the device, - a set of instruction commands for said instruction set, said instruction commands being likely to be executed in the data processing system and to trigger execution of the instructions in the device,

- as a usage profile, the chain of instructions,

- as an execution property, an expected chain for executing the instructions, - as a detection device, means that make it possible to detect that the chain of instructions does not correspond to the expected one, - and as a coercion device, means that make it possible to inform the data processing system and/or change the behavior of the part of the protected software when the chaining of the instructions does not correspond to the expected one, • produce the exploitation means which also enables the device to execute the instructions in the instruction set, the execution of said instructions being triggered by the execution, in the data processing system, of the instruction commands,

• and modify the Protected Software by:

- modify at least one selected part of the source for the protected software, this modification being such that: > at least one selected algorithmic processing is divided in such a way that during the execution of the protected software, said algorithmic processing is carried out, using the second execution part, using instructions,

> for at least one selected algorithmic processing, instruction commands are integrated into the source of the protected software in such a way that during execution of the protected software, each instruction command is executed by the first execution part and triggers, in the device, execution, by means of the second execution part , of an instruction,

> a sequence of instruction commands is selected from the set of sequences that enable execution of the protected software,

> and that the chain that at least some of the instructions must follow during their execution in the unit is specified,

and during the use phase, in the presence of the device, if it is detected that the chain of instructions executed in the device does not correspond to the expected one, inform the data processing system about this and/or change the operation of the share

of the Protected Software, so that the behavior of the Protected Software is changed.

According to an alternative embodiment, the method according to the invention comprises:

during the protection phase:

defining:

- as instruction set, an instruction set in which at least some instructions work with registers and use at least one operand for the purpose of returning a result,

- for at least some of the instructions that work with registers:

> a part that defines the functionality of the instruction,

> and a part that defines the expected chain for executing the instructions and that includes bit fields corresponding to:

o an identification field of the instruction,

o and for each operand in the instruction:

■ a flag field,

■ and an expected identification field for the operand,

- for each register belonging to the exploitation means and which is used by the instruction set, a generated identification field in which the identity of the last instruction that has returned its result to said register is automatically stored, - as a detection device, means which make it possible, during the execution of an instruction, for each operand, when the flag field requires it, to check for equality between the generated identification field corresponding to the register used by said operand and the expected identification field for the origin of said operand, - and as a coercive device, means that make it possible to modify the result of the instructions if at least one of the checked similarities is false.

According to a preferred embodiment, the method according to the invention comprises:

during the protection phase:

• modify the protected software by:

- selecting at least one variable, used in at least one selected algorithmic processing, which during execution of the protected software partially defines the state of the protected software, - modifying at least one selected part of the source of the protected software, this modification being such that during execution of the protected software, at least one selected variable or at least one copy of a selected variable resides in the device,

- and generate:

> the first object part of the protected software, said first object part being such that during execution of the protected software, at least one part of the first execution part also takes into account that at least one variable or at least one copy of a variable is located in the device,

> and the second object part of the protected software, said second object part being such that, after uploading to the device and during execution of the protected software, the second execution part appears, by means of which at least one selected variable, or at least one copy of a selected variable is also located in

the unit,

and during the use phase:

• in the presence of the device, whenever a part of the first execution part so requires, apply a variable or a copy of a variable located in the device, so that said part is executed correctly and that consequently the protected software is fully functional, • and in the absence of the entity, despite the request from a portion of the first execution part to use a variable or a copy of a variable located in the entity, not be able to comply with said request in a correct manner, so that in any case, said portion is not executed correctly and that consequently the protected software is not fully functional.

According to another preferred embodiment, the method according to the invention comprises:

-» during the protection phase:

defining:

- as a trigger command, an instruction command,

- as a dependent function, an instruction,

- as an instruction, at least one argument for a trigger command, corresponding at least in part to the information sent by the data processing system to the device to trigger execution of the corresponding dependent function, - a procedure for renaming the instructions that makes it possible to rename the instructions for to obtain trigger commands with renamed instructions, - and a feedback device which is arranged to be applied in the device during the use phase and which enables the recovery of the dependent

function to execute from the renamed instruction, produce an exploit that enables the device to also

implement the return device,

and modify the Protected Software by:

- selecting, in the source of the protected software, trigger commands, - modifying at least one selected portion of the source of the protected software by renaming the instructions in the selected trigger commands to hide the identity of the corresponding dependent functions,

- and generate:

> the first object part of the protected software, said first object part being such that during execution of the protected software, the trigger commands renamed instruction are executed,

> and the second object part of the protected software containing the exploitation means which also implements the rollback device, said second object part being such that, after uploading to the device and during execution of the protected software, the identity of the dependent functions whose execution is triggered by the first the execution part is restored using the second execution part, and the dependent functions are executed using the second execution part,

and during the use phase:

• in the presence of the unit and each time a trigger command with the name instruction, contained in a share of the first execution part, it imposes, restore, in the unit, the identity of the corresponding dependent function and execute it, so that said part is executed correctly and that consequently the protected software is fully functional, • in the absence of the device, despite the request by a part of the first execution part to trigger the execution of a dependent function in the device, not be able to comply with said request in a correct manner, so that in any case, said portion is not executed correctly and that, consequently, the protected software is not fully functional.

According to an alternative embodiment, the method according to the invention comprises:

during the protection phase:

• define, for at least one dependent function, a family of dependent functions that are algorithmically equivalent but are triggered by trigger commands whose renamed instructions are different,

• and modify the Protected Software by:

- select, in the source of the protected software, at least one trigger command renamed instruction, - and modify at least one selected portion of the source of the protected software by replacing at least the renamed instruction of one selected trigger command renamed instruction with another renamed instruction, which triggers a dependent function from the same family.

According to an alternative embodiment, the method according to the invention comprises: -» during the protection phase, defining, for at least one dependent function, a family of algorithmically equivalent dependent functions by: - adding a noise field to the information that defines the functional part of the dependent function to be executed in the unit, - or use the instruction's identification field and the expected identification fields of the operands.

According to an alternative embodiment, the method according to the invention comprises:

during the protection phase:

defining:

- as a method for renaming the instructions, an encryption method for encrypting the instructions, - and as a recovery device, means implementing a decryption method for decrypting the renamed instructions and thus restoring the identity of the dependent functions to execute in the device.

According to an alternative embodiment, the method according to the invention comprises:

during the protection phase:

modify the Protected Software by:

- selecting, in the source of the protected software, at least one conditional jump which is performed in at least one selected algorithmic processing, - modifying at least one selected portion of the source of the protected software, this modification being such that during execution of the protected software, the functionality in at least one selected conditional jump is executed in the unit, by means of the second execution part,

- and generate:

> the first object part of the protected software, said first object part being such that during execution of the protected software, the functionality in at least one selected conditional jump is executed in the device,

> and the second object part of the protected software, said second object part being such that, after uploading to the device and during execution of the protected software, the second execution part appears, by means of which the functionality in

at least one selected conditional jump is executed,

and during the use phase:

in the presence of the unit and each time a share of the first execution part imposes it, execute the functionality in at least one conditional leap in the device, so that said part is executed correctly and that consequently the protected software is fully functional,

and in the absence of the unit, and despite the request from a portion of the first execution part to perform the functionality in a conditional jump in the unit, not be able to comply with said request in a correct manner, so that at least said portion does not is executed correctly and that, consequently, the protected software is not fully functional.

According to an alternative embodiment, the method according to the invention comprises, during the protection phase, modifying the protected software by: - selecting, in the source for the protected software, at least one series of selected conditional jumps, - modifying at least one selected portion of the source for the protected software, this modification being such that during execution of the protected software, the aggregate functionality of the at least one selected series of conditional jumps is executed in the device, by means of the second execution part,

- and by generating:

> the first object part of the protected software, said first object part being such that during execution of the protected software, the functionality in at least one selected series of conditional jumps is executed in the device,

> and the second object part of the protected software, said second object part being such that, after uploading to the device and during execution of the protected software, the second execution part appears, by means of which the overall functionality of at least one selected series of conditional jumps will be executed.

The method according to the invention thus makes it possible to protect the use of a software by using a processing and memory unit which is characterized by the fact that it contains a part of the software being executed. It follows that any derivative version of the software that attempts to run without the processing and memory unit will have to recreate the part of the software contained in the processing and memory unit during execution, otherwise said derivative version of the software will not be fully functional.

A number of other distinctive features will be apparent from the description given below with reference to the attached figures, which show, in the form of non-limiting examples, embodiments and realizations of the subject of the invention. Figures 10 and 11 are functional block diagrams illustrating the different representations of a software respectively not protected and protected by means of the method according to the invention. Figures 20 to 22 illustrate, as examples, different embodiments of an apparatus that implements the method according to the invention. Figures 30 and 31 are functional block diagrams showing the general principle of the method according to the invention. Figures 40 to 43 are diagrams illustrating the protection process according to the invention, as it implements the principle of variable protection. Figures 70 to 74 are diagrams illustrating the protection process according to the invention, as it implements the principle of protection by detection and coercion. Figures 80 to 85 are diagrams illustrating the protection process according to the invention, as it implements the principle of protection by renaming. Figures 90 to 92 are diagrams illustrating the protection process according to the invention, implementing the principle of conditional jump protection. Figure 100 is a diagram that illustrates the different phases in carrying out the invention. Figure 110 illustrates an embodiment of a system which enables execution of the construction step in the protection phase according to the invention. Figure 120 illustrates an embodiment of a pre-customization unit used in the protection process according to the invention. Figure 130 illustrates an embodiment of a system which enables execution of the tool construction step in the protection phase according to the invention. Figure 140 illustrates an embodiment of a system which enables the protection process according to the invention to be carried out. Figure 150 illustrates an embodiment of a customization unit used in the protection process according to the invention.

In the rest of the description, the following definitions will apply:

• A data processing system 3 is a system capable of executing a program.

• A processing and memory unit is a device capable of:

- receive data provided by a data processing system 3,

- return data to the data processing system 3,

- store data at least partially secretly and remember at least part of said data also when the device is switched off, - and perform algorithmic processing on data, with parts of or all of the result being kept secret. • A unit 6 is a processing and memory unit that implements the method according to the invention. • A blank unit 60 is a unit which does not implement the method according to the invention, but which can receive data which transforms it into a unit 6.

• A pre-customised unit 66 is a blank unit 60 which has received parts of data which means that, after receiving supplementary data, it can be transformed into

a unit 6.

• Uploading information to a blank unit 60 or a pre-customized unit 66 corresponds to the transfer of information to the blank unit 60 or the

pre-customized unit 66 as well as storage of said transmitted information.

The transfer may possibly include a change to the information format.

• A variable, a function or data contained in the data processing system 3 will be indicated in uppercase letters, while a variable, a function or data contained in the unit 6 will be indicated in lowercase letters. • A "protected software" is a software that is protected by at least one of the protection principles implemented by the method according to the invention. • A "vulnerable software" is a software that is not protected by any of the protection principles implemented by the method according to the invention. • Where distinguishing between vulnerable software and protected software is not important, the term "software" will be used. • A software has different representations depending on where in the life cycle it is considered:

- a source representation,

- an object representation,

- a distribution,

- or a dynamic representation.

• A source representation of a software is understood as a representation which, after transformation, results in an object representation. A source representation can offer different levels, from a conceptual, abstract level to a level directly executable by a computing system or a processing and memory device. • An object representation of a software corresponds to a level of representation which, after transformation into a distribution and uploading to a data processing system or a processing and memory unit, can be executed. It can, for example, be binary code, an interpreted code, etc. • A distribution is a physical or virtual carrier that contains the object representation, as said distribution must be made available to the users to enable them to use the software. • A dynamic representation corresponds to the execution of the software from its distribution. • A portion of a piece of software corresponds to any part of the software, and may for example correspond to one or more instructions, consecutive or not, and/or one or more functional blocks, consecutive or not, and/or one or more functions, and/or one or more subprograms and/or one or more modules. A part of a piece of software can also correspond to the whole of said software. Figures 10 and 11 illustrate the different representations respectively of a vulnerable software 2v in a general sense and of a protected software 2p protected according to the method according to the invention. Figure 10 illustrates different representations of a vulnerable software 2v occurring during its life cycle. The vulnerable software 2v can thus appear in any of the following representations:

• a source representation 2vs,

• an object representation 2vo,

• a distribution 2vd. This distribution can usually be in the form of a physical distribution medium, such as a CDROM, or in the form of files distributed over a network (GSM, Internet, etc), • or a dynamic representation 2ve corresponding to the execution of the vulnerable software 2v in a data processing system 3 of any known type, which generally comprises at least one processor 4. Figure 11 illustrates the different representations of a protected software 2p occurring during its life cycle. The protected software 2p can thus appear in any of the following representations: • a source representation 2ps which comprises a first source part intended for the data processing system 3 and a second source part intended for the unit 6, as parts of said source parts can often be contained in common files, • an object representation 2po which comprises a first object part 2pos intended for the data processing system 3 and a second object part 2pou intended for the device 6,

• a distribution 2vd, which includes:

- a first distribution part 2pds which contains the first object part 2pos, said first distribution part 2pds being intended for the data processing system 3 and can usually be in the form of a physical distribution medium, such as a CDROM, or in the form of files distributed over a network (GSM, Internet, etc.),

- a second distribution part 2pdu in the form of:

> at least one pre-customized unit 66 to which a part of the second object part 2pou has been loaded and of which the user has to complete the customization by uploading supplementary data to produce a unit 6, said supplementary data being obtained for example by download over a network,

> or at least one unit 6 to which the second object part 2pou has been loaded,

• or a dynamic representation 2pe corresponding to execution of the protected software 2p. Said dynamic representation 2pe comprises a first execution part 2pes which is executed in computer

the processing system 3 and a second execution part 2peu which is executed in the unit 6.

In cases where the distinction between the different representations of the protected software 2p is not important, the expressions first part of the protected software and second part of the protected software will be used.

The embodiment of the method according to the invention according to the dynamic representation in figure 11 uses an apparatus 1 p which comprises a data processing system 3 connected via a connection 5 to a unit 6. The data processing system 3 is of any type, and generally comprises at least one processor 4. The data processing system 3 can be a computer or, for example, be part of various machines, devices, stationary or mobile products, or tools in a general sense. The connection 5 can be realized in any possible way, for example in the form of a serial port connection, a USB bus, a radio link, an optical link, a network connection or a direct electrical connection to a circuit in the data processing system 3, etc. It should be noted that the device 6 can possibly physically be inside the same integrated circuit as the processor 4 in the data processing system 3.1 in which case the device 6 can be considered a coprocessor associated with the processor 4 in the data processing system 3, and the connection 5 is internal to the integrated circuit .

Figures 20 to 22 show, in an illustrative and non-limiting manner, different embodiments of the apparatus 1 p which enable the protection process according to the invention to be carried out.

In the embodiment illustrated in figure 20, the protection apparatus 1p comprises, as data processing system 3, a computer, and, as unit 6, a chip card 7 and its interface 8, usually called a card reader. The computer 3 is connected to the device 6 via a connection 5. During execution of the protected software 2p, the first execution part 2pes which is executed in the computer 3 and the second execution part 2peu which is executed in the chip card 7 and its interface 8 must both be functional, so that the the protected software 2p is fully functional.

In the embodiment illustrated in Figure 21, the protective device 1p equips a product 9, in a general sense, which comprises various components 10 adapted for the function(s) performed by this product 9. The protective device 1p comprises, on the one hand , a data processing system 3 built into the product 9 and, on the other hand, a device 6 associated with the product 9. For the product 9 to be fully functional, the protected software 2p must be fully functional. During execution of the protected software 2p, the first execution part 2pes which is executed in the data processing system 3 and the second execution part 2peu which is executed in the device 6 must both be functional. Said protected software 2p therefore makes it possible to indirectly protect the product 9 or one of its functionalities against unauthorized use. For example, the product 9 can be an installation, a system, a machine, a toy, a household appliance, a telephone, etc.

In the embodiment illustrated in Figure 22, the protection device 1 p comprises several computers, as well as parts of a communication network. The data processing system 3 is a first computer, which is connected via a network-type connection 5 to a unit 6 comprised by another computer. In this embodiment of the invention, the second computer 6 is used as a license server for a protected software 2p. During execution of the protected software 2p, the first execution part 2pes, which is executed in the first computer 3, and the second execution part 2peu, which is executed in the second computer 6, must both be functional, so that the protected software 2p is fully functional.

Figure 30 makes it possible to explain in more detail the protection process according to the invention. It should be noted that a vulnerable software 2v is assumed to be run in its entirety in a data processing system 3. On the other hand, when implementing a protected software 2p, the data processing system 3 comprises transmission devices 12 which are connected via connection 5 to transmission devices 13 which is part of the device 6, which makes it possible to establish communication between the first execution part 2pes and the second execution part 2peu of the protected software 2p.

It must be taken into account that the transmission devices 12, 13 are realized in software and/or hardware, and are capable of ensuring, and possibly optimizing, the communication of data between the data processing system 3 and the unit 6. Said transmission devices 12, 13 are designed to make it possible to produce a protected software 2p which is preferably independent of the type of connection 5 used. Said transfer devices 12,13 are not part of the subject of the invention, and are not described in more detail as they are well known to the person skilled in the art. The first part of the protected software 2p comprises commands. During execution of the protected software 2p, execution of said commands by the first execution part 2pes enables the communication between the first execution part 2pes and the second execution part 2peu. In the rest of the description, said commands are represented by IN, OUT or TRIG.

As illustrated in Figure 31, to enable the implementation of the second execution part 2peu of the protected software 2p, the device 6 includes a protection device 14. The protection device 14 includes memory devices 15 and processing devices 16.

For the sake of simplicity, in the rest of the description it has been chosen to consider, when executing the protected software 2p, the presence of the device 6 or the absence of the device 6.1 the reality is a device 6 that provides protection devices 14 which is not arranged for the execution of the second execution part 2peu of the protected software 2p also to be considered absent whenever the execution of the protected software 2p is not correct. In other words: • a device 6 which is physically present and which includes protection devices 14 which are arranged for the execution of the second execution part 2peu of the protected software 2p is always considered to be present, • a device 6 which is physically present, but which includes protection devices 14 that are not adapted, i.e. do not enable the correct implementation of the second execution part 2peu of the protected software 2p, are considered present when they function correctly and as absent when they do not function correctly,

• and a unit 6 that is physically absent is always considered absent.

In the case where the unit 6 consists of a chip card 7 and its interface 8, the transmission devices 13 are divided into two parts, one of which is located in the interface 8 and the other is located in the chip card 7.1 this embodiment, the absence of the chip card 7 is considered equivalent to absence of the device 6. In other words, in the absence of the chip card 7 and/or its interface 8, the protection device 14 is not accessible and does not enable the execution of the second execution part 2peu of the protected software, so that the protected software 2p is not fully functional .

According to the invention, the purpose of the protection process is to implement a protection principle called by "detection and coercion", a description of which is given in connection with figures 70 to 74.

For the implementation of the principle of protection by detection and coercion is defined: • at least one program execution property that is prone to be monitored at least partially in the unit 6, • at least one criterion to comply with for at least one program execution property, • a detection device 17 for implementation in the unit 6 and which makes it possible to detect that at least one program execution property does not comply with at least one associated criterion, • and a forcing device 18 for implementation in the unit 6 and which makes it possible to inform the data processing system 3 and/or change the behavior of a software when at least one criterion is not met.

For implementation of the principle of protection by detection and coercion, exploitation means are also provided which make it possible to transform a blank unit 60 into a unit 6 which at least implements the detection device 17 and the coercive device 18.

Figure 70 illustrates the devices necessary to implement the principle of protection by detection and coercion. The unit 6 comprises the detection device 17 and the enforcement device 18 belonging to the processing device 16. The enforcement device 18 is informed by the detection device 17 that a criterion has not been met.

More precisely, the detection device 17 uses information from the transmission device 13 and/or from the memory device 15 and/or from the processing device 16 to monitor one or more program execution properties. For each program execution property, at least one criterion is set to comply with.

If it is detected that at least one program execution property does not comply with at least one criterion, the detection device 17 informs the enforcement device 18 about this. Said forcing device 18 is arranged to suitably modify the state of the unit 6.

For the implementation of the principle of protection by detection and coercion, the following are also selected:

• at least one program execution property to monitor, from the program execution properties that are prone to be monitored, • at least one criterion to comply with for at least one selected execution property, • in the source of the vulnerable software 2vs, at least one algorithmic processing in connection with which at least one program execution property must be monitored, • and in the source of the vulnerable software 2vs, at least one share containing at least one selected algorithmic processing.

At least one selected portion of the source of the vulnerable software 2vs is then modified to produce the source of the protected software 2ps. This modification is such that, during execution of the protected software 2p, among other things: • at least one portion of the first execution part 2pes, which is executed in the data processing system 3, takes into account that at least one selected program execution property is to be monitored, at least partially in the device 6, • and the second execution part 2peu, which is executed in the unit 6, at least partially monitors a selected program execution property.

During the execution of the protected software 2p, protected by means of the principle of protection by detection and coercion, in the presence of the device 6: • as long as all criteria corresponding to all the monitored program execution characteristics of all the modified portions of the protected software 2p are met, working said modified portions of the protected software 2p nominally, so that said protected software 2p functions nominally, • and if at least one of the criteria corresponding to a monitored execution property of a portion of the protected software 2p is not met, the data processing system 3 is informed of this and/ or the operation of the portion of the protected software 2p is modified, so that the operation of the protected software 2p is changed.

Naturally, in the absence of the device 6, at least one request from a part of the first execution part 2pes of the protected software 2p to use the device 6 will not be able to be correctly complied with, so that at least said part is not executed correctly and that consequently the protected software 2p is not fully functional.

For implementation of the principle of protection by detection and coercion, two types of program execution properties are preferably used.

The first type of program execution property is a measurement variable for the execution of a software, and the second type is a program usage profile. The aforementioned two types of properties can be used independently or in combination.

For the implementation of the principle of protection by detection and coercion using, as an execution property, a measurement variable for program execution is defined: • in the memory device 15, possibility to store at least one measurement variable used to quantify the use of at least one functionality in a software, • in the detection device 17, possibility of monitoring at least one threshold associated with each measurement variable, • and an actualization device that makes it possible to update each measurement variable depending on the use of the functionality with which it is associated.

An exploitation means is also produced which implements, in addition to the detection device 17 and the forcing device 18, the actualization device.

It is also selected, in the source of the vulnerable software 2vs:

• at least one functionality in the vulnerable software 2v whose use is likely to be monitored using a measurement variable, • at least one measurement variable used to quantify the use of said functionality, • at least one threshold associated with the measurement variable corresponding to a restriction on the use of said functionality, • and at least one method for updating the measurement variable depending on the use of said functionality.

The source of the vulnerable software 2vs is then modified to produce the source of the protected software 2ps, this modification being such that, during execution of the protected software 2p, the second execution part 2peu:

• updates the measurement variable depending on the use of said functionality,

• and takes into account at least one threshold crossing.

In other words, during the execution of the protected software 2p, the measurement variable is updated depending on the use of said functionality, and when the threshold is crossed, the detection device 17 informs the enforcement device 18 about this, which makes a customized decision to inform the data processing system 3 and/or change the processing performed by the processing device 16 to cause the change of the operation of the portion of the protected software 2p so that the operation of the protected software 2p is changed.

For the execution of a first preferred alternative embodiment of the principle of protection by detection and coercion using, as a characteristic, a measurement variable, is defined:

• for at least one measurement variable, several associated thresholds,

• and different coercive measures corresponding to each of the mentioned thresholds.

It is also selected, in the source of the vulnerable software 2vs:

• at least one measurement variable used to quantify the use of at least one functionality in the software, and with which several thresholds corresponding to different restrictions on the use of said functionality must be associated

• and at least two thresholds associated with the measurement variable.

The source of the vulnerable software 2vs is then modified to produce the source of the protected software 2ps, this modification being such that, during execution of the protected software 2p, the second execution part 2peu:

• updates the measurement variable depending on the use of said functionality,

• and takes into account, in different ways, the crossing of the different thresholds.

In other words, during the execution of the protected software 2p, when the first threshold is crossed, the device 6 classically informs the data processing system 3, which instructs the protected software 2p not to use said functionality anymore. If the protected software 2p continues to use said functionality, the second threshold could potentially be crossed. If the second threshold is crossed, the enforcement device 18 can disable the selected functionality and/or disable the protected software 2p.

For the implementation of a second preferred alternative embodiment of the principle of protection by detection and coercion using, as a characteristic, a measurement variable, a refill device is defined which makes it possible to credit at least one program functionality monitored by a measurement variable at least one further use.

An exploitation means is also provided which implements, in addition to the detection device 17, the forcing device 18 and the actualization device, the refill device.

At least one measurement variable is also selected, in the source for the vulnerable software 2vs, which is used to limit the use of at least one functionality in the software and which must be able to be credited with at least one further use.

The source of the vulnerable software 2vs is then modified to produce the source of the protected software 2ps, this modification being such that, during a phase called refill phase, at least one additional use of at least one functionality corresponding to a selected measurement variable can be credited .

During the refill phase, updating of at least one selected measurement variable and/or of at least one associated threshold is performed to allow at least one further use of the associated functionality. In other words, it is possible, during the refill phase, to credit additional use of at least one functionality of the protected software 2p.

For the implementation of the principle of protection by detection and coercion with the use of, as a property, a program usage profile, at least one program execution property is defined as the criterion to comply with said usage profile.

It is also selected, in the source of the vulnerable software 2vs:

• at least one usage profile to monitor,

• and at least one execution property that at least one selected usage profile must comply with.

The source of the vulnerable software 2vs is then modified to produce the source of the protected software 2ps, this modification being such that, during execution of the protected software 2p, the second execution part 2peu complies with all the selected program execution characteristics. In other words, the device 6 itself monitors the way in which the second execution part 2peu is executed, and can inform the data processing system 3 and/or change the behavior of the protected software 2p if at least one execution characteristic is not observed.

During the execution of the protected software 2p, protected by means of this principle, in the presence of the device 6: • as long as all the execution characteristics of all the modified portions of the protected software 2p are observed, said modified portions of the protected software 2p operate nominally, as that said protected software 2p works nominally, • and if at least one execution characteristic of a part of the protected software 2p is not observed, the data processing system 3 is informed about this and/or the operation of the part of the protected software 2p is modified, so that the operation of the protected the software 2p changes.

Monitoring various execution characteristics can be considered, such as monitoring the presence of instructions that include a pointer or monitoring the execution chain of at least one part of the instructions.

For the implementation of the principle of protection by detection and coercion using as an execution property to observe monitoring of the execution chain for at least one part of the instructions, define: • an instruction set, whose instructions are likely to be executed in the device 6, • a set of instruction commands for said instruction set, said instruction commands tending to be executed in the data processing system 3. Execution of each of said instruction commands in the data processing system 3 triggers execution of the corresponding instruction in the unit 6, • a detection device 17 which makes it possible to detect that the chain of the instructions do not correspond to the expected, • and a coercive device 18 which makes it possible to inform the data processing system 3 and/or change the operation of a software when the chain of instructions does not correspond to the expected.

An exploitation means is also provided which enables the unit 6 to also execute the instructions in the instruction set, execution of said instructions being triggered by execution in the data processing system 3 of the instruction commands.

There is also selected, in the source for the vulnerable software 2vs, at least one algorithmic processing which must be carried out remotely in the unit 6 and in connection with which the chaining of at least one part of the instructions must be monitored.

The source of the vulnerable software 2vs is then modified to produce the source of the protected software 2ps, this modification being such that, during execution of the protected software 2p: • the second execution part 2peu at least performs the functionality of the selected algorithmic processing,

• the selected algorithmic processing is divided into instructions,

• the chain which at least some of the instructions must follow during its execution in the device 6 is specified, • and the first execution part 2pes of the protected software 2p executes instruction commands that trigger execution of the instructions in the device 6.

During the execution of the protected software 2p, protected by means of this principle, in the presence of the device 6: • as long as the chaining of the instructions in all the modified portions of the protected software 2p executed in the device 6 corresponds to the expected one, said modified works portions of the protected software 2p nominally, so that said protected software 2p functions nominally, • and if the chaining of the instructions in a portion of the protected software 2p executed in the device 6 does not correspond to the expected one, the data processing system 3 is informed of this and/or the operation of the portion of the protected software 2p is modified, so that the operation of the protected software 2p is changed.

Figure 71 illustrates an example of the implementation of the principle of protection by detection and coercion using, as an execution property to comply, monitoring of the execution chain of at least one part of the instructions, in a case where the expected chain is complied with.

The first execution part 2pes of the protected software 2p, which is executed in the data processing system 3, executes instruction commands Ol; which triggers, in the unit 6, execution of the instructions in; associated instruction set. In said instruction set, at least some of the instructions each comprise a part that defines the functionality of the instruction and a part that makes it possible to verify the expected chain for executing the instructions. In this example, the instruction commands are Ol; represented by TRIG(ii), and the expected chain of execution of the instructions is in, in+i and in+2- Execution in unit 6 of the instruction in gives the result a, and execution of the instruction in+ig gives the result b. The instruction in+2 uses as operand the results a and b from the instructions in and in+i, and the execution of this gives the result c.

Since said chaining of the instructions executed in the unit 6 corresponds to the expected one, this results in normal or nominal functioning of the protected software 2p.

Figure 72 illustrates an example of the implementation of the principle of protection by detection and coercion using, as an execution property to comply, monitoring of the execution chain for at least one part of the instructions, in a case where the expected chain is not complied with.

In this example, the expected chain of execution of the instructions is still in, in+i and in+2- However, the execution chain has been changed by replacing the instruction in with the instruction i'n, so that the chain that is actually executed is i' n, in+iog in+2- Execution of the instruction i'n gives the result a, i.e. the same result as execution of the instruction in. At the latest upon execution of the instruction in+2, however, the detection device 17 detects that the instruction i'n does not correspond to the expected instruction to generate the result a used as an operand in the instruction in+2 - The detection device 17 informs the forcing device 18 about this, which modifies the operation of the instruction in +2accordingly, so that execution of the instruction in+2 gives the result c', which may be different from c. Naturally, if execution of the instruction i'n gives a result a' that is different from the result a of the instruction in, it is clear that the result from the instruction in+2 will also be different from c.

As the execution chain of the instructions executed in the device 6 does not correspond to the expected one, therefore a change of the operation of the protected software 2p may occur.

Figures 73 and 74 illustrate a preferred alternative embodiment of the principle of protection by detection and coercion using, as execution property to comply, monitoring of the execution chain for at least one part of the instructions. According to this preferred variant, an instruction set is defined in which at least some instructions work with registers and use at least one operand with the intention of returning a result.

As illustrated in Figure 73, for at least some of the functions that work with registers, a part PF that defines the function's functionality and a part PE that defines the expected chain for executing the instructions are defined. The part PF corresponds to the operation code, which is known to the person skilled in the art. The part PE that defines the expected chain comprises bit fields corresponding to:

• an identification field for the instruction CM,

• and for each operand k in the instruction, where k varies from 1 to K and K is the number of operands in the instruction: - a flag field CDk, which indicates whether it is desirable to verify the origin of operand k, - and an expected identification field ClPk for the operand , which indicates the expected identity of the instruction that generated the contents of operand k.

As illustrated in Figure 74, the instruction set V comprises registers belonging to the processing unit 16, each register being named Rv, where v varies from 1 to V. For each register Rv, two fields are defined, namely: • a function field CFV which is known to the person skilled in the art and which makes it possible to save the result from the execution of the instructions, • and a generated identification field CIGV which makes it possible to save the identity of the instruction which has generated the content of the function field CFV. Said generated identification field CIGV is automatically updated with the contents of the identification field of the instruction CM that generated the function field CFV. Said generated identification field CIGVs neither accessible nor modifiable for any of the instructions, and is used only for the detection device 17.

During the execution of a function, the detection device 17 performs the following operations for each operand k:

• reads the flag field CDk,

• if the flag field CDk imposes it, both the expected identification field ClPk and the generated identification field CIGV are read corresponding to the register used by the operand k,

• checks whether the two fields ClP and CIGV are equal,

• and if they are not the same, the detection device 17 assumes that the execution chain for the instructions has not been followed.

The forcing device 18 makes it possible to modify the result from the instructions when the detection device 17 has informed it that an instruction sequence has not been followed. A preferred embodiment is performed by modifying the functional part PF of the instruction being executed or the functional part PF of subsequent instructions.

According to another advantageous feature of the invention, the purpose of the protection process is to implement a protection principle called "variable", a description of which is given in connection with Figures 40 to 43.

For the implementation of the principle of protection by variable, in the source of the vulnerable software 2vs, at least one variable is selected which, during the execution of the vulnerable software 2v, partially defines its state. The state of a software is to be understood as the set of information elements which at a given time are necessary for the complete execution of said software, as the absence of such a selected variable prevents the complete execution of said software. At least one portion of the source for the vulnerable software 2vs that contains at least one selected variable is also selected.

At least one selected portion of the source of the vulnerable software 2vs is then modified to produce the source of the protected software 2ps. This modification is such that during execution of the protected software 2p, at least one part of the first execution part 2pes, which is executed in the data processing system 3, takes into account that at least one selected variable or at least one copy of a selected variable is located in the device 6.

Figure 40 illustrates an example of execution of a vulnerable software 2v. In this example, during the execution of the vulnerable software 2v in the computing system 3, occurs:

at time ti, assignment of the data X to the variable Vi, represented by Vi <-X, • at time t.2, assignment of the value of the variable Vi to the variable Y, represented by Y <- V-i, • and at time t3, assignment of the value of the variable Vi to the variable Z, represented by Z <- V-i. Figure 41 illustrates an example of a first embodiment of the invention where the variable is located in the unit 6.1 this example, during execution in the data processing system 3 of the first execution part 2pes of the protected software 2p, and in the presence of the unit 6, occurs: • at time ten , execution of a transfer command which triggers the transfer of the data X from the data processing system 3 to the variable v-i located in the memory device 15 in the unit 6, said transfer command being represented by OUT(vi, X) and corresponding to the assignment of the data X to the variable vi, • at time t.2, execution of a transfer command which triggers the transfer of the value of the variable v-i located in the unit 6 to the data processing system 3 in order to assign it to the variable Y, said transfer command being represented by IN(vi) and responding to the assignment of the value of the variable vi to the variable Y, • and at time t.3, execution of a transfer command which triggers transfer of the value of the variable v-i located in the unit 6 to the data processing system 3 in order to assign it to the variable Z, said transfer command being represented by IN(vi) and corresponding to the assignment of the value of the variable vi to the variable Z .

It should be noted that during the execution of the protected software 2p, at least one variable is located in the device 6. When a portion of the first execution part 2pes of the protected software 2p imposes it, and in the presence of the device 6, the value of said variable located in the device 6 transferred to the data processing system 3 for use by the first execution part 2pes of the protected software 2p, so that said part is executed correctly and that consequently the protected software 2p is fully functional.

Figure 42 illustrates an example of another embodiment of the invention where a copy of the variable is located in the unit 6.1 this example, during execution in the data processing system 3 of the first execution part 2pes of the protected software 2p, and in the presence of the unit 6, occurs: at time ten, assigning the data X to the variable V1; which is located in the data processing system 3, as well as executing a transfer command that triggers the transfer of the data X from the data processing system 3 to the variable Vi which is located in the memory device 15 in the unit 6, said transfer command being represented by OUT(vi, X),

at time t.2, assignment of the value of the variable Vi to the variable Y,

and at time t.3, execution of a transfer command which triggers transfer of the value of the variable vi located in the unit 6 to the data processing system 3 to assign it to the variable Z, said transfer command being represented by IN(vi) .

It should be noted that during the execution of the protected software 2p, at least one copy of a variable is located in the device 6. Thus, when a portion of the first execution part 2pes of the protected software 2p imposes it, and in the presence of the device 6, the value of said copy of a variable located in the device 6 transferred to the data processing system 3 for use by the first execution part 2pes of the protected software 2p, so that said part is executed correctly and that consequently the protected software 2p is fully functional.

Figure 43 illustrates an example of a preliminary search for execution of the protected software 2p when the device 6 is absent. In this example, upon execution in the data processing system 3 of the first execution part 2pes of the protected software 2p: • at time ten, execution of the transfer command OUT(vi, X) cannot trigger the transfer of the data X to the variable v-i, due to the absence of the device 6, • at time t.2 execution of the transfer command IN(vi) cannot trigger the transfer of the value of the variable v-i to the data processing system 3, as a result of the absence of the unit 6,

and at time t.3, execution of the transfer command IN(vi) cannot trigger the transfer of the value of the variable vi to the data processing system 3, due to the absence of the device 6.

It is thus the case that in the absence of the unit 6, at least one request from a part of the first execution part 2pes to use a variable or a copy of a variable located in the unit 6 cannot be complied with correctly, so that in each if the said share does not execute correctly and that consequently the protected software 2p is not fully functional.

It should be noted that the data transfers between the data processing system 3 and the device 6 illustrated in the previous examples only use simple assignments, but the person skilled in the art will know how to combine them with other operations to achieve complex functions, such as for example OUT(v1,2<* >X + 3) or Z <-(5<*>v1 + v2).

According to another advantageous feature of the invention, the purpose of the protection process is to implement a protection principle called "renaming", a description of which is given in connection with figures 80 to 85.

For the implementation of the principle of protection by renaming, the following is defined:

• a set of dependent functions, which dependent functions are likely to be executed, by means of the second execution part 2peu, in the device 6, and possibly to transfer data between the data processing system 3 and the device 6, said set of dependent functions can be finite or infinite, • a set of trigger commands for said dependent functions, said trigger commands tending to be executed in the data processing system 3 and trigger execution in the unit 6 of corresponding dependent functions, • for each trigger command, an instruction corresponding at least partially to the information transferred from the first execution part 2pes to the second execution part 2peu to trigger execution of the corresponding dependent functions, said instruction being in the form of at least one argument in the trigger command, • a method for renaming the instructions provided to be used when modifying the vulnerable software 2v, as a sli k forward

procedure allows the instructions to be renamed to produce trigger commands with renamed instructions that allow the identity of the corresponding dependent functions to be hidden,

• and a return device 20 which is designed to be used in the unit 6 during the use phase and which makes it possible to restore the original

instruction from the renamed instruction to determine which dependent function to execute.

For implementation of the principle of protection by renaming, an exploitation means is also provided which makes it possible to transform a blank unit 60 into a unit 6 which at least implements the return device 20.

For the implementation of the principle of protection by renaming, in the source of the vulnerable software 2vs: • at least one algorithmic processing that uses at least one operand and returns at least one result is also selected, • and at least one part of the source of the vulnerable software 2vs that contains at least one selected algorithmic processing.

The source of the vulnerable software 2vs is then modified to produce the source of the protected software 2ps. This modification is such that, among other things: • during execution of the protected software 2p, at least one part of the first execution part 2pes, which is executed in the data processing system 3, takes into account that the functionality of at least one selected algorithmic processing is performed in the device 6, • during execution of the protected software 2p, the second execution part 2peu, which is executed in the unit 6, performs at least the functionality of at least one selected algorithmic processing, • each selected algorithmic processing is divided so that during the execution of the protected software 2p, each selected algorithmic processing is performed, by means of the second execution part 2peu, using dependent functions. Preferably, each selected algorithmic processing is divided into elementary functions fdn (with n variable from 1 to N), that is to say: - possibly one or more dependent functions which make it possible to place one or more operands at the unit 6's disposal, - dependent functions, some of which use the operand(s) and in combination perform the functionality of the selected algorithmic processing, using said operand(s), - and optionally one or more dependent functions that make it possible, for the unit 6, to set the result of the selected algorithmic processing at the disposal of the data processing system 3, • during execution of the protected software 2p, the second execution part 2peu executes the dependent functions fdn, • during execution of the protected software 2p, the dependent functions are triggered by trigger commands with renamed instructions, • and that a sequence of the trigger commands is selected from the set of sequences that enable execution vation of the protected software 2p.

The first execution part 2pes of the protected software 2p, which is executed in the data processing system 3, executes trigger commands with renamed instructions that transfer renamed instructions to the device 6 and trigger, in the device 6, recovery, by means of the return device 20, of the instructions and then execution, by using the second execution part 2peu, of each of the previously defined dependent functions fdn.

In other words, the principle of protection by renaming is carried out by renaming the instructions in the trigger commands to obtain trigger commands with renamed instructions whose execution in the data processing system 3 triggers, in the device 6, the execution of the dependent functions that would have been triggered by the unrenamed trigger commands instructions, however, without examining the protected software 2p making it possible to determine the identity of the executed dependent functions. Figure 80 illustrates an example of the execution of a vulnerable software 2v. In this example, during execution of the vulnerable software 2v in the data processing system 3, at a given point in time, calculation of Z <- F(X,Y) corresponding to assigning to a variable Z the result of an algorithmic processing represented by a function is performed F and use of operands X and Y.

Figures 81 and 82 illustrate an example of the embodiment of the invention.

Figure 81 illustrates a partial embodiment of the invention. In this example, during execution in the data processing system 3 of the first execution part 2pes of the protected software 2p, and in the presence of the unit 6, occurs: • at times ti,t.2, execution of the trigger commands CDi, CD2as a trigger, in the unit 6, execution , by means of the second execution part 2peu, of the corresponding dependent functions fdi, fd2 which ensure the transfer of data X, Y from the data processing system 3 respectively to the memory areas x and y in the memory device 15 of the unit 6, said trigger commands CDi, CD2 being respectively represented by OUT( x,X), OUT(y,Y), • at times t.3 to t.N-1, execution of the trigger commands CD3 to CDN-i as a trigger, in unit 6, execution, by means of the second execution part 2peu, of the corresponding dependent functions fd3 to fdN-1, said trigger commands CD3 to CDn-i respectively being represented by TRIG(fd3) to TRIG(fdN-i). The series of dependent functions fd3 to fdN-1 which are executed in combination is algorithmically equivalent to the function F. More precisely, the execution of said trigger commands leads to the execution in unit 6 of the dependent functions fd3 to fdN-i, which apply the contents of the memory areas x, y and return the result of a memory area z in the unit 6, • and at the time tN, execution of a trigger command CDNwhich triggers, in the unit 6, execution, by means of the second execution part 2peu, of the dependent function fdNwhich ensures the transfer of the result of the algorithmic processing contained in the memory area z in the unit 6 of the data processing system 3, to assign it to the variable Z, said trigger command CDner being represented by IN(z).

In this example, to complete the invention, the first argument of the trigger command OUT and the argument of the trigger commands TRIG and IN are selected as instructions. The instructions selected in this way are renamed using the procedure for renaming the instructions. In this way, the instructions in the commands CDito CDn, i.e. x, y, fd3, fdN-1, z are renamed to produce R(x), R(y), R(fd3)..., R(fdN- i), R(z).

Figure 82 illustrates the complete embodiment of the invention. In this example, during execution in the data processing system 3 of the first execution part 2pes of the protected software 2p, and in the presence of the device 6, occurs:

• at times ti, t.2, execution of the trigger commands with the renamed instruction CDCRi, CDCR2 which transfers the renamed instructions R(x), R(y) as well as the data X, Y to the device 6, which triggers, in the device 6, recovery , by means of the return device 20, of the renamed instructions to restore the instructions, i.e. the identity of the memory zones x, y, and then execution, by means of the second execution part 2peu, of the corresponding dependent functions fdi, fd2 which ensure the transfer of data X, Y from the data processing system 3 respectively to the memory areas x and y in the memory device 15 of the unit 6, said trigger commands with renamed instructions CDCR1, CDCR2 respectively being represented by OUT(R(x),X), OUT(R(y),Y) , • at times t.3 to t.N-1, execution of the trigger commands with renamed instructions CDCR3 to CDCRn-i which transfer the renamed instructions R(fd3) to R(fdN-i) to unit 6, which triggers, in unit 6, recovery , wood by means of the feedback device 20, of the instructions, i.e. fd3 to fdN-1, and then execution, by means of the second execution part 2peu, of the dependent functions fd3 to fdN-1, said trigger commands with renamed instructions CDCR3 to CDCRn-1 respectively being represented by TRIG (R(fd3)) to TRIG(R(fdN-i)), • and at time t.N, execution of the trigger command with the renamed instruction CDCRnwhich transfers the renamed instruction R(z) to unit 6, which triggers, in unit 6, recovery , by means of the feedback device 20, of the instruction, i.e. the identity of the memory area z, and then execution, by means of the second execution part 2peu, of the dependent function fdN which ensures the transfer of the result of the algorithmic processing contained in the memory area z in the unit 6 to the data processing system 3 to assign it to the variable Z, said trigger command with the renamed instruction CDCRner represented by IN(R(z)).

In the illustrated example, the trigger commands with renamed instructions 1 through N are executed successively. One should note two possible improvements: The first improvement concerns the case where several algorithmic processings is remotely executed in unit 6 and in any case the result of one algorithmic processing is used by another algorithmic processing. In this case, certain trigger commands with renamed instructions applied to the transfer may be able to be removed.

The second improvement aims to select an appropriate sequence of the trigger commands with renamed instructions from the set of sequences that enable the execution of the protected software 2p. In this regard, it is preferred to select a sequence of the trigger commands with renamed instructions that temporally separates the execution of the dependent functions by inserting portions of code between them that are executed in the data processing system 3 and which include or not trigger commands with renamed instructions used for determination of other data. Figures 83 and 84 illustrate the principle of such an embodiment. Figure 83 shows an example of the execution of a vulnerable software 2v. In this example, during the execution of the vulnerable software 2v, in the data processing system 3, the execution of two algorithmic processes occurs which results in the determination of Z and Z' such that Z <- F(X,Y) and Z' <- F(X ',Y'). Figure 84 illustrates an example of execution of the process according to the invention where the two algorithmic processings selected in Figure 83 are carried out remotely in the unit 6.1 according to this example, during execution in the data processing system 3 of the first execution part 2pes of the protected software 2p and in the presence of unit 6, as explained above, execution of the trigger commands with renamed instructions CDCR to CDCRn corresponding to determination of Z and execution of the trigger commands with renamed instructions CDCR' to CDCR'm corresponding to determination of Z' occurs. As illustrated, the trigger commands with renamed instructions CDCRi, to CDCR are not consecutively executed, as the trigger commands with renamed instructions CDCR'i to CDCR'm, as well as other portions of code, are interleaved. In this example, the following sequence is thus executed: CDCRi, parts of interpolated code, CDCR'i, CDCR2, parts of interpolated code, CDCR'2, CDCR'3, parts of interpolated code, CDCR'4lCDCR3, CDCR4 CDCRn, CDCR'm.

It should be noted that during the execution of a portion of the first execution part 2pes of the protected software 2p, the trigger commands with renamed instructions which are executed in the data processing system 3 trigger, in the device 6, the recovery of the identity of the corresponding dependent functions and then the execution of these. It is thus the case that in the presence of the unit 6, said portion is executed correctly and that consequently the protected software 2p is fully functional.

Figure 85 illustrates an example of an attempt to execute the protected software 2p when the device 6 is absent. In this example, during execution in the data processing system 3 of the first execution part 2pes of the protected software 2p, at no time the execution of a trigger command with the renamed instruction can trigger neither the recovery of the instruction nor the execution of the corresponding dependent function, due to the absence of the unit 6. The value to assign to the variable Z cannot therefore be determined correctly.

It is therefore the case that in the absence of the unit 6, at least one request from a portion of the first execution part 2pes by the protected software 2p to trigger the recovery of an instruction and the execution of a dependent function in the unit 6 cannot be correctly complied with, so that in any case said portion is not executed correctly and that consequently the protected software 2p is not fully functional.

Thanks to this principle of protection by renaming, examination in the protected software 2p of the trigger commands with renamed instructions does not make it possible to determine the identity of the dependent functions that must be executed in the device 6. It should be noted that the renaming of the instructions is carried out during modification of the vulnerable software 2v to a protected software 2p.

According to a variant of the principle of protection by renaming, for at least one dependent function, a family of dependent functions that are algorithmically equivalent but triggered by different trigger commands with renamed instructions are defined. According to this variant, for at least one algorithmic processing that uses dependent functions, said algorithmic processing is divided into dependent functions of which at least one is replaced by a dependent function from the same family instead of keeping multiple instances of the same dependent function. To this end, trigger commands with renamed instructions are modified to take into account the replacement of dependent functions with dependent functions from the same family. In other words, two dependent functions from the same family have different instructions and consequently different trigger commands with renamed instructions, and it is not possible, by examining the proprietary software 2p, to detect that the dependent functions being called are algorithmically equivalent.

According to a first preferred embodiment of the variant of the principle of protection by renaming, for at least one dependent function, a family of algorithmically equivalent dependent functions is defined by adding a noise field to the information defining the functional part of the dependent function to be executed in the device 6.

According to a second preferred embodiment of the variant of the principle of protection by renaming, a family of algorithmically equivalent dependent functions is defined for at least one dependent function using identification fields.

According to an alternative preferred embodiment of the principle of protection by renaming, the method for renaming the instructions is defined as an encryption method which makes it possible to encrypt the instructions to convert them into renamed instructions. Remember that the renaming of the instructions is performed during the protection phase P. In this preferred embodiment, the return device 20 is a device for implementing a decryption method that makes it possible to decrypt the renamed instructions and thus restore the identity of the dependent functions to execute in the device 6. Said feedback device is implemented in the unit 6, and can be in the form of software or hardware. Said return device 20 is invoked during the use phase U every time a trigger command renamed instruction is executed in the data processing system 3 with the intention of triggering the execution of a dependent function in the unit 6.

According to another advantageous feature of the invention, the purpose of the protection process is to implement a protection principle called "conditional jump", a description of which is given in connection with figures 90 to 92.

For the implementation of the principle of protection by conditional jump, in the source of the vulnerable software 2vs at least one conditional jump BC is selected. At least one portion of the source for the vulnerable software 2vs is also selected that contains at least one selected conditional jump.

At least one selected portion of the source of the vulnerable software 2vs is then modified to produce the source of the protected software 2ps. This modification is such that, during execution of the protected software 2p, among other things: • at least one part of the first execution part 2pes, which is executed in the data processing system 3, takes into account that the functionality in at least one conditional jump BC is executed in the device 6, • and that the second execution part 2peu, which is executed in the unit 6, at least performs the functionality of at least one selected conditional jump BC and makes available to the data processing system 3 information that enables the first execution part 2pes to continue its execution at the selected the place.

The first execution part 2pes of the protected software 2p, which is executed in the data processing system 3, executes conditional jump commands which trigger, in the unit 6, execution by means of the second execution part 2peu remotely executed conditional jumps bc whose functionality is equivalent to the functionality of the selected conditional jumps BC. Figure 90 illustrates an example of execution of a vulnerable software 2v. In this example, during the execution of the vulnerable software 2v in the data processing system 3, at a given point in time, a conditional jump BC is performed which indicates for the vulnerable software 2v where it should continue its execution, i.e. one of the three possible locations Bi, B2or B3. It must be understood that the conditional jump BC makes the decision to continue execution of the software at Bi, B2, or B3. Figure 91 illustrates an example of implementation of the invention where the conditional jump selected for remote execution in unit 6 corresponds to the conditional jump BC. In this example, during the execution in the data processing system 3 of the first execution part 2pes of the protected software 2p and in the presence of the device 6 is performed: • at time ten, execution of the conditional jump command CBCisom trigger, in the device 6, execution, by means of the second execution part 2peu, of the remote executed conditional jump bc which is algorithmically equivalent to the conditional jump BC, said conditional jump command CBCier represented by TRIG(bc), • and at time t2, transfer from the unit 6 to the data processing system 3 of the the information which enables the first execution part 2pes to perform its execution at the selected location, i.e. location Bi, B2 or B3.

It should be noted that during the execution of a portion of the first execution part 2pes of the protected software 2p, the conditional jump commands executed in the data processing system 3 trigger the execution of the corresponding remotely executed conditional jumps in the device 6. Thus, in the presence of the device 6, said portion is executed correctly and that consequently the protected software 2p is fully functional.

Figure 92 illustrates an example of an attempt to execute the protected software 2p when the device 6 is absent. In this example, during execution in the data processing system 3 of the first execution part 2pes of the protected software 2p: • at time ten, execution of the conditional jump command CBC cannot trigger execution of the remote executed conditional jump bc, due to the absence of the device 6, • and at time t.2, the transmission of the information which enables the first execution part 2pes to continue at the selected location, due to the absence of the device 6, fails.

It is therefore the case that, in the absence of the unit 6, at least one request from a part of the first execution part 2pes to trigger the execution of a remotely executed conditional jump in the unit 6 cannot be complied with correctly, so that at least the said part does not is executed correctly and that consequently the protected software 2p is not fully functional.

In the description above in connection with figures 90 and 92, the invention aims to remove, in unit 6, a conditional jump. Of course, a preferred embodiment of the invention can be realized by removing, in unit 6, a series of conditional jumps whose overall functionality is equivalent to the entire functionality of the conditional jumps that have been removed. Execution of the overall functionality of said series of remotely executed conditional jumps results in information being made available to the data processing system 3 which enables the first execution part 2pes of the protected software 2p to continue its execution at the selected location.

In the description above in connection with figures 40 to 92, four different principles for program protection have been described largely independently of each other. The protection process according to the invention is carried out using the principle of protection by detection and coercion, possibly in combination with one or more other protection principles. If the principle of protection by detection and coercion is supplemented by at least one other protection principle, the principle of protection by detection and coercion is preferably supplemented by the principle of protection by variable and/or the principle of protection by renaming and/or the principle of protection by conditional jump.

When the principle of protection by renaming is also implemented, it can in turn be supplemented by the principle of protection by conditional jump.

According to the preferred embodiment variant, the principle of protection by detection and coercion is supplemented by the principle of protection by variable and by the principle by protection by renaming, supplemented by the principle by protection by conditional jump.

In cases where a protection principle is applied as a supplement to the principle of protection by detection and coercion, the description given above must include, in order to take account of the combined implementation, the following changes: • the term vulnerable software must be understood as software that is vulnerable towards the protection principle described. In the case where a protection principle has already been applied to the vulnerable software, the expression "vulnerable software" shall thus be interpreted by the reader as "software protected by the protection principle or principles that have already been applied"; • the term protected software must be understood as software that is protected against the protection principle described. Thus, in the case where a protection principle has already been applied, the expression "protected software" shall be interpreted by the reader as "new version of the protected software"; • and the choice(s) made for the implementation of the protection principle described must take into account the choice(s) made for the implementation of the protection principle(s) that have already been applied.

The remainder of the description shall provide a better understanding of the execution of the protection process according to the invention. This protection process according to the invention comprises, as shown more precisely in Figure 100: first a protection phase P during which a vulnerable software 2v is modified to become a protected software 2p, • then, a use phase U during which the protected software 2p is used. During this use phase U: - in the presence of the device 6 and every time a part of the first execution part 2 is executed in the data processing system 3 imposes it, an imposed functionality is executed in the device 6, so that said part is executed correctly and that consequently the protected software 2p is fully functional, - in the absence of the unit 6 and despite the request from a part of the first execution part 2pes to perform a functionality in the unit 6, said request cannot be complied with correctly, so that at least said part does not is executed correctly and that consequently the protected software 2p is not fully functional, • and possibly a refill phase R during which at least one further use of a functionality protected by implementation of the second alternative preferred embodiment of the principle of protection by detection and coercion with the use of a measurement variable as a characteristic.

The protection phase P can be divided into two sub-phases, Pi and P2. The first, called the pre-protection sub-phase Pi, takes place independently of the vulnerable software 2v to be protected. The second phase, called the post-protection subphase P2, depends on the vulnerable software 2v to be protected. It should be noted that the pre-protection sub-phase Pi and the post-protection sub-phase P2 can preferably be carried out by two different people or two different groups. For example, the pre-protection sub-phase Pi can be performed by a person or a company that develops software protection systems, while the post-protection sub-phase P2 can be performed by a person or a company that develops software that requires protection. It is of course clear that the pre-protection sub-phase Pi and the post-protection sub-phase P2 can also be carried out by the same person or group.

The pre-protection sub-phase Pi comprises several steps Sn ..., Su, in each of which different tasks or jobs are to be performed.

The first step of the pre-protection sub-phase Pi is called "definition step Sn". During this step Sn:

• selected:

- the type of unit 6. As an illustrative example, a chip card reader 8 and the chip card 7 associated with the reader can be selected as unit 6, - and the transmission devices 12, 13, respectively arranged to be implemented in the data processing system 3 and in the unit 6 during the use phase U, and capable of providing the transfer of data between the data processing system 3 and the device 6,

defined:

- at least one program execution property that is prone to be monitored at least partially in the unit 6, - at least one criterion to comply with for at least one program execution property, - a detection device 17 for implementation in the unit 6, which makes it possible to detect that at least one program execution property does not comply with at least one associated criterion, - and a coercive device 18 for implementation in the unit 6, which makes it possible to inform the data processing system 3 and/or change the operation

to a software when at least one criterion is not met,

and in the case where the protection process according to the invention implements the principle of protection by detection and coercion using as a property a measurement variable for the program execution, is also defined:

- as a program execution characteristic prone to be monitored, a variable for measuring the use of a functionality in a software, - as a criterion to comply with, at least one threshold associated with each measurement variable, - and an actualization device that makes it possible to update at least one measurement variable,

and in the case where the protection process according to the invention also implements a first preferred alternative embodiment of the principle of protection by detection and coercion using as a property a variable for measuring the program execution, is also defined:

- for at least one measurement variable, several associated thresholds,

- and different coercive devices corresponding to each of the mentioned thresholds, • and in the case where the protection process according to the invention also implements a second preferred alternative embodiment of the principle of protection by detection and coercion using as a feature a variable for measuring the program execution, a refill is also defined device that makes it possible to add at least one additional use of at least one program functionality that is monitored by a measurement variable, • and in the case where the protection process according to the invention implements the principle of protection by detection and coercion with use as a feature a program use profile, also defined: - as program execution property prone to be monitored, a program usage profile, - and as a criterion to comply with, at least one program execution property, • and in the case where the protection process according to the invention implements the principle of protection by detection and coercion with use as an execution property to comply with monitoring of the execution chain, is also defined: - an instruction set whose instructions are likely to be executed in the unit 6, - a set of instruction commands for said instruction set, said instruction commands being likely to be executed in the data processing system 3 and to trigger execution of the instructions in unit 6,

- as a usage profile, the chain of instructions,

- as an execution property, an expected sequence for executing the instructions, - as a detection device 17, means that make it possible to detect that the sequence of instructions does not correspond to the expected one, - and as a forcing device 18, means that make it possible to inform the data processing system 3 and /or modify the behavior of the portion of the protected software 2p when the chaining of the instructions does not correspond to the expected one, and in the case where the protection process according to the invention also implements ter a preferred alternative embodiment of the principle of protection by detection and coercion using as an execution property to comply with monitoring of the execution chain, is also defined:

- as an instruction set, an instruction set in which at least some instructions work with registers and use at least one operand for the purpose of returning a result,

- for at least some of the instructions that work with registers:

> some PF that defines the functionality of the instruction,

> and a part that defines the expected chain for executing the instructions and that includes bit fields corresponding to:

o an identification field of the instruction CM,

o and for each operand in the instruction:

■ a flag field CDk,

■ and an expected identification field CIPk for the operand,

- for each register belonging to the exploitation means and used by the instruction set, a generated identification field CIGVi in which the identity of the last instruction that has returned its result in said said register is automatically stored, - as detection device 17, means that make it possible, during the execution of an instruction, for each operand, when the flag field CDk requires it, to check for equality between the generated identification field CIGcorresponding to the register used by said operand and the expected identification field CIPkfor the origin of said operand, - and as enforcement device 18, means that do so possible to modify resul tated by the instructions if at least one of the checked similarities is false, and in the case where the protection process according to the invention implements the principle of protection by renaming is also defined:

- as a trigger command, an instruction command,

- as a dependent function, an instruction,

- as an instruction, at least one argument in a trigger command, corresponding at least in part to the information sent from the data processing system 3 to the unit 6 to trigger execution of the corresponding dependent function, - a method for renaming the instructions that makes it possible to rename the instructions to obtain trigger commands with renamed instructions, - and a return device 20 which is arranged to be used in the unit 6 during the use phase U and which makes it possible to recover the dependent function to execute from the renamed instruction, • and in the case where the protection process according to the invention implements a variant of the principle of protection by renaming also defines, for at least one dependent function, a family of dependent functions that are algorithmically equivalent but are triggered by trigger commands if renamed

instructions are different,

• and in the case where the protection process according to the invention implements one of the preferred embodiments of the variant of the principle of protection by renaming is also defined, for at least one dependent function, a family of algorithmically equivalent dependent functions by: - adding a noise field to the information that defines the functional part of the dependent function to execute in the unit 6, - or use the identification field of the instruction CM and the expected identification fields ClPktil the operands, • and in the case where the protection process according to the invention implements a preferred variant of the principle of protection by renaming, is also defined: - as method for renaming the commands, an encryption method for encrypting the commands, - and as return device 20, means implementing a decryption method for decrypting the renamed instructions and thereby restoring the identity of the dependent functions to be executed secured in unit 6.

During the pre-protection sub-phase Pi, the definition step Sn is followed by a step called "construction step S12". During this step S12, the transfer devices 12, 13 and the means of exploitation corresponding to the definitions from the definition step Sn-

During this construction step S12, therefore:

• construction of the transfer devices 12, 13 which enable, during the use phase U, the transfer of data between the data processing system 3 and the unit 6,

• construction:

- of the means of exploitation which make it possible for the unit 6, during the use phase U, also to implement the detection device 17 and the forcing device 18, - and optionally of the means of exploitation which make it possible for the unit 6, during the use phase U, also to implement the actualization device, - and optionally of the means of exploitation which makes it possible for the device 6, during the use phase U, to also implement the refill device, - and possibly of the means of exploitation which also makes it possible for the device 6, during the use phase U, to execute the instructions in the instruction set, • and when the principle of protection by renaming is also implemented, construction of the means of exploitation which makes it possible for the unit 6, during the use phase U, to also implement the return device.

The construction of the exploitation means is carried out in the traditional way with the help of a program development unit and taking into account the definitions produced in the definition step Sn. Such a unit is described later in the description in connection with figure 110.

During the pre-protection sub-phase Pi, the construction step S12 may be followed by a step called "pre-customization step S13". During this step S13, at least part of the transfer device 13 and/or the exploitation means is loaded onto at least one blank unit 60 in order to obtain at least one pre-customized unit 66. It should be noted that parts of the exploitation means, when it has been transferred to a pre-customized unit 66, is no longer directly accessible outside said pre-customized unit 66. The transfer of the exploitation means to a blank unit 60 can be carried out by means of an adapted pre-customization unit, which is described later in the description in connection with figure 120. In the case of a pre-customized unit 66 which consists of a chip card 7 and its reader 8, the pre-customization only concerns the chip card 7.

During the pre-protection sub-phase Pi, after the definition step Sn and optionally after the construction step S12, a step called tool construction step SW can be performed. During this step S14, tools are provided that can help generate protected software or automate the protection of software. These tools make it possible to: • help select or automatically select in the vulnerable software 2v to be protected: - the execution property(s) to monitor, and possibly the algorithmic processing(s) that are prone to being split into instructions which can be remotely executed in the device 6,

- the share or shares which are prone to be modified,

- and when the principle of protection by variable is also implemented, the variable(s) that are prone to be moved to unit 6, - and when the principle of protection by renaming is also implemented, the algorithmic processing(s) that are prone to be divided into dependent functions that can be remotely executed in the device 6 and in connection with which the instructions in the trigger commands can be renamed, - and when the principle of protection by conditional jump is also implemented, the conditional jump(s) whose functionality is prone to be remote- performed in the device 6, • and, optionally, help to generate protected software or automate the protection of software.

These different tools can be produced or used independently of each other or in combination, and each tool can take different forms, such as, for example, a preprocessor, an assembler, a compiler, etc.

The pre-protection sub-phase Pi is followed by a post-protection sub-phase P2 which depends on the vulnerable software 2v to be protected. This post-protection sub-phase P2 also includes several steps. The first step, corresponding to the implementation of the principle of protection by detection and coercion, is called "creation step S21". During this step S21, the choices made during definition step Sn are used. By means of said selection, and optionally by tools produced during the tool construction step S14, the protected software 2p is produced by: • choosing at least one program execution property to monitor, among the program execution properties that are prone to be monitored, • choosing at least one criterion to conforming to at least one selected program execution characteristic, • selecting at least one algorithmic processing which, during execution of the vulnerable software 2v, uses at least one operand and makes it possible to obtain at least one result, and in connection with which at least one selected program execution characteristic is to be monitored , • selecting at least one portion of the source of the vulnerable software 2vs containing at least one selected algorithmic processing, • generating the source of the protected software 2ps from the source of the vulnerable software 2vs by modifying at least one selected portion of the source of the vulnerable software 2vs to obtain at least one modified share of the source for that cloud the protected software 2ps, this modification being such that: - during execution of the protected software 2p, a first execution part 2pes runs in the data processing system 3 and a second execution part 2peu runs in a unit 6, obtained from the blank unit 60 after uploading information, - the the second execution part 2peu at least performs the functionality of at least one selected algorithmic processing, - and during execution of the protected software 2p, at least one selected execution characteristic is monitored by means of the second execution part 2peu, and the fact that a criterion is not met leads to a change of the operation of the protected software 2p,

• and generate:

- a first object part 2pos of the protected software 2p from the source of the protected software 2ps, said first object part 2pos being such that during execution of the protected software 2p a first execution part 2pes appears which is executed in the data processing system 3 and of which in at least one proportion takes into account that at least one selected program execution property is monitored,

- and a second object part 2pou of the protected software 2p which contains the exploitation means implementing the detection device 17 and the coercion device 18, said second object part 2pou being such that, after uploading to the blank unit 60 and during execution of the protected software 2p, the second execution part 2peu appears , by means of which at least one selected program execution characteristic is monitored and by means of which the fact that a criterion is not met leads to a change in the behavior of the protected software 2p.

Of course, the principle of protection by detection and coercion according to the invention can be applied directly during the development of new software without it being necessary to first produce a vulnerable software 2v. In this way, a protected software 2p is obtained directly.

For the implementation of the principle of protection by detection and coercion using as a property a measurement variable for the program execution, the protected software 2p is modified by: • choosing as a program execution property to monitor, at least one variable that measures the use of at least one functionality in a software,

• choose:

- at least one functionality in the protected software 2p whose use is likely to be monitored using a measurement variable, - at least one measurement variable used to quantify the use of said functionality, - at least one threshold associated with a selected measurement variable corresponding to a restriction on the use of said functionality, - and at least one method for updating a selected measurement variable depending on the use of said functionality, • and modifying at least one selected portion of the source of the protected software 2ps, this modification being such that, during execution of the protected software 2p, the measurement variable is updated using it

second execution part 2peu depending on the use of said functionality, and that the crossing of at least one threshold is taken into account.

For the implementation of a first preferred alternative embodiment of the principle of protection by detection and coercion using, as a characteristic, a measurement variable, the protected software 2p is modified by: selecting, in the source of the protected software 2ps, at least one selected measurement variable with which several thresholds must be associated corresponding to different restrictions on the use of the functionality,

select at least two thresholds associated with the selected measurement variable,

and modifying at least one selected part of the source of the protected software 2ps, this modification being such that, during execution of the protected software 2p, crossing of the different thresholds is taken into account in a different way, by means of the second execution part 2peu.

For the implementation of a second preferred alternative embodiment of the principle of protection by detection and coercion using, as a characteristic, a measurement variable, the protected software 2p is modified by: • selecting, in the source of the protected software 2ps, at least one selected measurement variable which makes it possible to limit the use of a functionality and which must be able to be credited with at least one further use, • and modify at least one selected share, this modification being such that during a phase called the refill phase, at least one additional use of at least one functionality corresponding to a selected measurement variable can be credited.

For the implementation of the principle of protection by detection and coercion using, as a property, a program usage profile, the protected software 2p is modified by: • selecting as a program execution property to monitor, a program usage profile, • selecting at least one program execution property that at least one selected usage profile must conforming, • and modifying at least one selected portion of the source of the protected software 2ps, this modification being such that, during execution of the protected software 2p, the second execution portion 2peu conforms to all of the selected program execution properties.

For the implementation of the principle of protection by detection and coercion using, as an execution property to comply with, the monitoring of the execution chain, the protected software 2p is modified by: modifying at least one selected part of the source of the protected software 2ps, this modification being such that: - at least one selected algorithmic processing is divided in such a way that during execution of the protected software 2p, said algorithmic processing is carried out by means of the second execution part 2peu, using instructions, - for at least one selected algorithmic processing, instruction commands are integrated into the source of the protected software 2ps in such a way that during execution of the protected software 2p, each instruction command is executed by the first execution part 2pes and triggers, in the unit 6, execution, by means of the second the execution part 2peu, of an instruction, - a sequence of the instruction commands is selected from the set of sequences that enable the execution of the protected software 2p, - and the chain that at least some of the instructions must follow during their execution in the unit 6 is specified.

During the post-protection sub-phase P2, and when at least one other protection principle is applied in addition to the principle of protection by detection and coercion, a "modification step 822" is performed - During this step S22, the definitions produced during the definition step Sn are used. By means of said definitions, and optionally by tools produced during the tool construction step S14, the protected software 2p is modified to enable the implementation of the protection principles according to one of the arrangements defined above.

When the principle of protection by variable is implemented, the protected software 2p is modified by: selecting at least one variable, used in at least one selected algorithmic processing, which during execution of the protected software 2p partially defines the state of the protected software 2p, • modify at least one selected part of the source of the protected software 2ps, this modification being such that during the execution of the protected software 2p, at least one selected variable or at least one copy of a selected variable is located in unit 6,

• and generate:

- the first object part 2pos of the protected software 2p, said first object part 2pos being such that during execution of the protected software 2p, at least one part of the first execution part 2pes also takes into account that at least one variable or at least one copy of a variable is located in the device 6, - and the second object part 2pou of the protected software 2p, said second object part 2pou being such that, after uploading to the device 6 and during execution of the protected software 2p, the second execution part 2peu appears, by means of which at least one selected variable or at least one copy of a selected variable is also located in unit 6.

When the principle of protection by renaming is implemented, the protected software 2p is modified by: selecting, in the source of the protected software 2ps, trigger commands, modifying at least one selected part of the source of the protected software 2ps by renaming the instructions in the selected trigger commands to hide the identity of the corresponding dependent functions,

and generate:

- the first object part 2pos of the protected software 2p, said first object part 2pos being such that during execution of the protected software 2p, the trigger commands with renamed instructions are executed, - and the second object part 2pou of the protected software 2p which contains the exploitation means which also implements the feedback device 20, the said second object part 2pou being such that, after uploading to the unit 6 and during execution of the protected

the software 2p, the identity of the dependent functions whose execution is triggered by the first execution part 2pos is recovered using

of the second execution part 2peu, and the dependent functions are executed by means of the second execution part 2peu.

For the implementation of a variant of the principle of protection by renaming, the protected software 2p is modified by: • selecting, in the source of the protected software 2ps, at least one trigger command with the renamed instruction, • and modifying at least one selected portion of the source for the protected the software 2ps by replacing at least the renamed instruction of one selected trigger command with the renamed instruction with another renamed instruction, which triggers a dependent function from the same family.

When the principle of protection by conditional jump is implemented, the protected software 2p is modified by: • selecting, in the source of the protected software 2ps, at least one conditional jump that is performed in at least one selected algorithmic processing, • modifying at least one selected portion of the source of the protected software 2ps, this modification being such that, during the execution of the protected software 2p, the functionality of at least one selected conditional jump is executed, by means of the second execution part 2peu, in the unit 6,

• and generate:

- the first object part 2pos of the protected software 2p, said first object part 2pos being such that during execution of the protected software 2p, the functionality of at least one selected conditional jump is executed in the unit 6, - and the second object part 2pou of the protected software 2p, in that said second object part 2pou is such that, after uploading to the device 6 and during execution of the protected software 2p, the second execution part 2peu appears, by means of which the functionality in at least one selected conditional jump is executed.

For the implementation of a preferred embodiment of the principle of conditional jump protection, the protected software 2p is modified by: selecting, in the source of the protected software 2ps, at least one series of selected conditional jumps, • modifying at least one selected portion of the source of the protected software 2ps, this modification being such that during execution of the protected software 2p, the overall functionality of at least one selected series of conditional jumps is executed, by means of the other the execution part 2peu, in the unit 6,

• and generate:

- the first object part 2pos of the protected software 2p, said first object part 2pos being such that, during execution of the protected software 2p, the functionality in at least one selected series of conditional jumps is executed in the unit 6, - and the second object part 2pou of the protected software 2p, said second object part 2pou being such that, after uploading to the device 6 and during execution of the protected software 2p, the second execution part 2peu appears, by means of which the overall functionality of at least one selected series of conditional jumps becomes exactly.

Of course, the protection principles according to the invention can be applied directly during the development of new software without it being necessary to first produce intermediate stages of protected software. In this way, the creation step S21 and the modification step S22 can be performed simultaneously to directly produce the protected software 2p.

During the post-protection sub-phase P2, after the creation step S21 of the protected software 2p, and optionally after the modification step S22, a step called "customization step S23" is performed. During this step S23, the second object part 2pou, containing the exploitation means, is uploaded to at least one blank unit 60 for the purpose of producing at least one unit 6, or a part of the second object part 2pou, possibly containing the exploitation means, is uploaded to at least one pre-customized unit 66 for the purpose of producing at least one unit 6. The uploading of this customization information makes it possible to make at least one unit 6 operational. It should be noted that parts of said information, once it has been transferred to a unit 6, are not directly accessible outside said unit 6. The transfer of the customization information to a blank unit 60 or a pre-customized unit 66 can be carried out by means of a this fitted customization unit, which is described later in the description in connection with figure 150.1 the case of a unit 6 which consists of a chip card 7 and its reader 8, the pre-customization concerns only the chip card 7.

For carrying out the protection phase P, various technical devices are described in more detail in connection with figures 110, 120, 130, 140 and 150. Figure 110 illustrates an embodiment of a system 25 which enables the execution of the construction step S12 which takes into account the definitions produced during the definition step Sn and during which the transfer devices 12, 13, and possibly the exploitation means intended for the unit 6, are produced. Such a system 25 comprises a program development unit or workstation which is traditionally in the form of a computer which comprises a system unit, a display unit, peripherals such as a keyboard and mouse, and which includes the following programs: file editors, assemblers, preprocessors , compilers, interpreters, debuggers and link editors. Figure 120 illustrates an embodiment of a pre-customization unit 30 which makes it possible to upload at least partially the transfer device 13 and/or the exploitation means to at least one blank unit 60 for the purpose of obtaining a pre-customized unit 66. Said pre-customization unit 30 comprises a reading and writing device 31 which makes it possible to electrically precustomize a blank unit 60 to obtain a precustomized unit 66 into which the transfer device 13 and/or the exploitation means have been loaded. The pre-customization unit 30 can also comprise a physical customization device 32 for the blank unit 60, which can for example be in the form of a printer. In the case where the device 6 is constituted by a chip card 7 and its reader 8, the pre-customization generally concerns only the chip card 7. Figure 130 illustrates an embodiment of a system 35 that enables the provision of the tools that can help to generate protected software or to automate program protection. Such a system 35 comprises a program development unit or workstation which is traditionally in the form of a computer which comprises a system unit, a display unit, peripheral units, such as a keyboard and mouse, and which includes, among other things, the following programs: file editors, assemblers, preprocessors, compilers , interpreters, debuggers and link editors. Figure 140 illustrates an embodiment of a system 40 which makes it possible to directly generate a protected software 2p or to modify a vulnerable software 2v for the purpose of generating a protected software 2p. Such a thing

system 40 comprises a program development unit or workstation which is traditionally in the form of a computer which comprises a system unit, a display unit, peripheral units, such as a keyboard and mouse, and which includes, among other things, the following programs: file editors, assemblers, preprocessors, compilers, interpretation devices , debuggers and link editors, as well as tools that can help generate protected software or automate program protection.

Figure 150 illustrates an embodiment of a customization unit 45 which makes it possible to upload the second object part 2pou to at least one blank unit 60 for the purpose of producing at least one unit 6 or to upload a part of the second object part 2pou to at least one pre-customized unit 66 for the purpose of producing at least one unit 6. Said customization unit 45 comprises a reading and writing device 46 which makes it possible to electrically customize at least one blank unit 60 or at least one pre-customized unit 66 to produce at least one unit 6. When this customization is completed, a device 6 includes the information necessary for the execution of the protected software 2p. The customization unit 45 can also comprise a physical customization device 47 for at least one unit 6, which can for example be in the form of a printer. In the case where a unit 6 consists of a chip card 7 and its reader 8, the customization generally only concerns the chip card 7.

The protection process according to the invention be carried out with the following improvements: • It can be planned to jointly use several processing and memory units between which the second object part 2pou of the protected software 2p is distributed, so that their simultaneous use enables the execution of the protected software 2p and absence of at least one of said processing and memory units prevents use of the protected software 2p. • Similarly, after the pre-customization step S13 and during the customization step S23, the part of the second object part 2pou which is necessary to convert the pre-customized unit 66 into a unit 6 may be contained in a processing and memory unit used by the customization unit 45 to restrict access to said part of the second object part 2pou. Of course, said part of the second object part 2pou can be distributed between several processing and memory units, so that said part of the second object part 2pou is accessible only during the simultaneous use of said processing and memory units.

Claims (21)

1. Method for protecting, by using at least one blank unit (60) which at least includes a memory device (15) and a processing device (16), a vulnerable software (2v) against unauthorized use of it, said vulnerable software (2v ) runs in a data processing system (3), where the method comprises the steps of: during a protection phase (P): • defining: - at least one program execution property that is prone to be monitored at least partially in a device (6), - at least one criterion to comply with for at least one program execution property, - a detection device (17) for implementation in a device (6), which makes it possible to detect that at least one program execution property does not comply with at least one associated criterion, - and an enforcement device (18) for implementation in a device (6), which makes it possible to inform the data processing system (3) and/or change the behavior of a software when at least one criterion is not observed, • produce means of exploitation which makes it possible to transform the blank device (60) into a device (6) capable of implementing the detection device (17) and the enforcement device (18), • and generating a protected software (2p) by: - choosing at least one program execution property to monitor among the program execution characteristics that are prone to be monitored, - select at least one criterion to comply with for at least one selected program execution characteristic, - select at least one algorithmic processing which, during execution of the vulnerable software (2v), applies at least one operand and makes it possible to achieve at least one result, and in connection with which at least one selected program execution property is to be monitored, - select at least one portion of the source of the vulnerable software (2vs) containing at least one selected algorithmic processing, - generate the source of the protected software (2ps) from the source of the vulnerable software (2vs) by modifying at least one selected portion of the source of the vulnerable software (2v s) to produce at least one modified part of the source for the protected software (2ps), this modification being such that: > during execution of the protected software (2p), a first execution part (2pes) runs in the data processing system (3) and a second execution part (2peu) runs in a unit (6), obtained from the blank unit (60) after uploading information, > the second execution part (2peu) performs at least the functionality of at least one selected algorithmic processing, > and during execution of the the protected software (2p), at least one selected program execution property is monitored by means of the second execution part (2peu), and the fact that a criterion is not met leads to a change in the behavior of the protected software (2p), - and generate: > a first object part (2pos) of the protected software (2p) from the source of the protected software (2ps), said first object part (2pos) being such that during execution of the protected progr the amware (2p), a first execution part (2pes) appears, which is executed in the data processing system (3) and of which at least a part takes into account that at least one selected program execution property is monitored, > and a second object part (2pou) of the protected the software (2p), which contains the exploitation means implementing the detection device (17) and the coercion device (18), said second object part (2pou) being such that, after uploading to the blank unit (60) and during execution of the protected software (2p), the the second execution part (2peu) appears, by means of which at least one selected program execution property is monitored and by means of which the fact that a criterion is not met leads to a change in the behavior of the protected software (2p), and upload the second object part (2pou) to the blank unit (60), for that for aim to produce the device (6), and during a use phase (U) during which the protected software (2p) is executed: • in the presence of the device (6), and: - as long as all criteria corresponding to all the monitored execution characteristics of all the modified parts of the protected software (2p) are complied with, make said parts of the protected software (2p) able to function nominally and consequently that the protected software (2p) can function nominally, - if at least one of the criteria corresponding to a monitored execution property if part of the protected software (2p) is not complied with, inform the data processing system (3) about this and/or change the operation of the part of the protected software (2p), so that the operation of the protected software (2p) is changed, • and in absence of the unit (6), despite the request from a part of the first execution part (2pes) to trigger execution, in the unit (6), of the functionality of at least one selected algorithmic process ssing, not be able to comply with said request in a correct manner, so that in any case said portion is not executed correctly and that consequently the protected software (2p) is not fully functional. 2. Method according to claim 1, for limiting the use of a protected software (2p), comprising the step of: during the protection phase (P): defining: - as program execution characteristic prone to be monitored, a variable that measures the use of a functionality in a software, - as criterion to comply with, at least one threshold associated with each measurement variable, - and an actualization device that makes it possible to update at least one measurement variable, • produce the exploitation means that makes it possible for the device (6) to also implement the actualization device, • and modify the protected software (2p) by: - choosing as a program execution property to monitor, at least one variable for measuring the use of at least one functionality in a software, - choosing: > at least one functionality in the protected software (2p) whose use is likely to be monitored using a measurement variable, > at least one measurement variable used to quantify the use of said functionality , > at least one threshold associated with a selected measurement variable that corresponds to a restriction on the use of said functionality, > and at least one method for updating a selected measurement variable depending on the use of said functionality, - and modifying at least one selected portion of the source for the the protected software (2ps), this modification being such that, during execution of the protected software (2p), the measurement variable is updated by means of the second execution part (2peu) depending on the use of said functionality, and that at least one threshold crossing is taken into account, and during the use phase (U), in the presence of the device (6), and if at least one crossing of a threshold corresponding to at least one restriction on use is detected, inform the data processing system (3) about this and/or change the operation of said part of the the protected software (2p), so that the behavior of the protected software (2p) is changed. 3. Method according to claim 2, comprising steps of: during the protection phase (P): • defining: - for at least one measurement variable, several associated thresholds, - and different forcing devices (18) corresponding to each of said thresholds, • and modifying the protected the software (2p) by: - selecting, in the source of the protected software (2ps), at least one selected measurement variable with which several thresholds must be associated corresponding to different restrictions on the use of the functionality, - selecting at least two thresholds associated with the selected measurement variable , - and modifying at least one selected part of the source of the protected software (2ps), this modification being such that, during the execution of the protected software (2p), the crossings of the different thresholds are taken into account in different ways, by means of the second execution part (2peu), and during the use phase (U): in the presence of the device (6): - if the crossing of a first threshold is detected, impose the protected software (2p) not to use the corresponding functionality any more, - and if crossing a second threshold is detected, disable the corresponding functionality and/or at least one part of the protected software (2p). 4. Method according to claim 2 or 3, comprising steps of: during the protection phase (P): • defining refill devices that make it possible to credit at least one program functionality monitored by a measurement variable with at least one further use, • producing the exploitation means which also enables the device (6) to implement the refill device, • and to modify the protected software (2p) by: - choosing, in the source of the protected software (2ps), at least one selected measurement variable that makes it possible to limit its use of a functionality and which must be able to be credited with at least one further use, - and modify at least one selected share, this modification being such that during a phase called the refill phase, at least one further use of at least one functionality corresponding to a selected measurement variable may be credited, and during the refill phase: update at least one selected measurement variable and/or at least one associated threshold for to allow at least one further use of the functionality. 5. Method according to claim 1, comprising steps of: during the protection phase (P): • defining: - as program execution property prone to be monitored, a program usage profile, - and as criterion to comply with, at least one program execution property, • and modifying it the protected software (2p) by: - choosing as a program execution property to monitor, at least one program usage profile, - choosing at least one program execution property that at least one selected usage profile must follow, - and modifying at least one selected portion of the source of the protected software (2ps), this modification is such that, during execution of the protected software (2p), the second execution part (2peu) complies with all the selected execution characteristics, and during the use phase (U), in the presence of the device (6), and if it is detected that at least one execution property is not observed, inform the data processing system (3) about this and/or change the operation of the portion of the protected software (2p), such that the behavior of the protected software (2p) is changed. 6. Method according to claim 5, comprising steps of: during the protection phase (P): defining: - an instruction set whose instructions are likely to be executed in the device (6), - a set of instruction commands for said instruction set, said instruction commands being prone to be executed in the data processing system (3) and to trigger the execution of the instructions in the device (6), - as a usage profile, the chaining of the instructions, - as an execution characteristic, an expected chain for the execution of the instructions, - as a detection device (17), means that make it possible to detect that the chain of instructions does not correspond to the expected one, - and as a coercive device (18), means that make it possible to inform the data processing system (3) and/or change the operation of the part of the protected software (2p) when the chain of instructions does not correspond to the expected one, • produce the means of exploitation which also enable the device (6) to execute the instructions in the instruction set, the execution of said instructions being triggered by the execution, in the data processing system (3), of the instruction commands, • and modifying the protected software (2p) by: - modifying at least one selected part of the source of the protected software (2ps), this modification being such that: > at least one selected algorithmic processing is divided in such a way that during execution of the protected software (2p), said algorithmic processing is performed, by means of the second execution part (2peu), using instructions , > for at least one selected algorithmic processing, instruction commands are integrated into the source of the protected software (2p) in such a way that during execution of the protected software (2p), each instruction command is executed by the first execution part (2pes) and triggers, in the unit (6), execution, by means of the second execution part (2peu), of an instruction, > a sequence of instructions the operation commands are selected from the set of sequences that enable the execution of the protected software (2p), > and that the chain that at least some of the instructions must follow during its execution in the unit (6) is specified, and during the use phase (U), in the presence of the unit (6), if it is detected that the chain of instructions executed in the unit (6) does not correspond to the expected one, inform the data processing system (3 ) about this and/or change the behavior of the portion of the protected software (2p), so that the behavior of the protected software (2p) is changed. 7. Method according to claim 6, comprising steps of: during the protection phase (P): defining: - as instruction set, an instruction set in which at least some instructions work with registers and use at least one operand for the purpose of returning a result, - for at least some of the instructions that work with registers: > a part (PF) that defines the functionality of the instruction, > and a part that defines the expected chain for executing the instructions and that includes bit fields corresponding to: o an identification field of the instruction (CM), o and for each operand in the instruction: ■ a flag field (CDk), ■ and an expected identification field (ClPk) for the operand, - for each register belonging to the exploitation tool and used by the instruction set, a generated identification field (CIGV) in which the identity of the last instruction that has returned its result to said register is automatically stored, - as detection device (17), means which make it mu lig, during the execution of an instruction, for each operand, when the flag field (CDk) requires it, to check for equality between the generated identification field (CIGv) corresponding to the register used by said operand and the expected identification field (ClPk) of the origin to said operand, - and as a coercive device (18), means which make it possible to modify the result of the instructions if at least one of the checked similarities is false. 8. Method according to one of claims 1 to 7, comprising steps of: -» during the protection phase (P): modifying the protected software (2p) by: - selecting at least one variable, used in at least one selected algorithmic processing, as under execution of the protected software (2p) partially defines the state of the protected software (2p), - modifying at least one selected portion of the source of the protected software (2ps), this modification being such that during execution of the protected software (2p) , at least one selected variable or at least one copy of a selected variable is located in the unit (6), - and generate: > the first object part (2pos) of the protected software (2p), said first object part (2pos) being such that during execution of the protected software (2p), at least one part of the first execution part (2pes) also takes into account that at least one variable or at least one copy of a variable is located in the unit (6), > and the second object part (2po u) of the protected software (2p), said second object part (2pou) being such that, after uploading to the device (6) and during execution of the protected software (2p), the second execution part (2peu) appears, by means of which at least one selected variable, or at least one copy of a selected variable is also located in the unit (6), and during the use phase (U): • in the presence of the unit (6), whenever a part of the first execution part (2pes) imposes it, apply a variable or a copy of a variable located in the unit (6) to such way that said part is executed correctly and that consequently the protected software (2p) is fully functional, • and in the absence of the device (6), despite the request from a part of the first execution part (2pes) to use a variable or a copy of a variable located in the unit (6), not be able to comply with said request in a correct manner, so that in any case said portion is not executed correctly and that consequently the protected software (2p) is not fully functional . 9. Method according to claim 6, comprising steps of: during the protection phase (P): • defining: - as a trigger command, an instruction command, - as a dependent function, an instruction, - as an instruction, at least one argument for a trigger command, corresponding at least in part to the information sent by the data processing system (3) to the device (6) to trigger execution of the corresponding dependent function, - a method of renaming the instructions which makes it possible to rename the instructions to obtain trigger commands with renamed instructions , - and a return device (20) which is arranged to be used in the unit (6) during the use phase (U) and which enables the recovery of the dependent function to execute from the renamed instruction, • produce exploitation means which enable the unit ( 6) also implementing the rollback device, • and modifying the protected software (2p) by: - selecting, in the source for the protected the software (2ps), trigger commands, - modify at least one selected part of the source of the protected software (2ps) by renaming the instructions in the selected trigger commands to hide the identity of the corresponding dependent functions, - and generate: > the first object part ( 2pos) of the protected software (2p), said first object part (2pos) being such that during execution of the protected software (2p), the trigger commands with the renamed instruction are executed, > and the second object part (2pou) of the protected software ( 2p) which contains the exploitation means which also implements the return device (20), said second object part (2pou) being such that, after uploading to the device (6) and during execution of the protected software (2p), the identity of the dependent functions whose execution is triggered of the first execution part (2pes) is restored by means of the second execution part (2peu), and the dependent functions execu eres by means of the second execution part (2peu), and during the use phase (U): • in the presence of the unit (6) and every time a trigger command with the renamed instruction, contained in a share of the first execution part (2pes), it imposes, restore, in the entity (6), the identity of the corresponding dependent function and execute it, so that said portion is executed correctly and that consequently the protected software (2p) is fully functional, • and in the absence of the entity (6), despite the request from a part of the first execution part (2pes) to trigger the execution of a dependent function in the unit (6), not be able to comply with said request correctly, so that in any case said part is not executed correctly and that consequently the protected software (2p) is not fully functional. 10. Method according to claim 9, comprising steps of: during the protection phase (P): • defining, for at least one dependent function, a family of dependent functions which are algorithmically equivalent but which are triggered by trigger commands whose renamed instructions are different, • and modify the protected software (2p) by: - selecting, in the source of the protected software (2ps), at least one trigger command renamed instruction, - and modifying at least one selected part of the source of the protected software (2ps) by replacing in at least the renamed instruction of one selected trigger command with the renamed instruction with another renamed instruction, which triggers a dependent function from the same family. 11. Method according to claim 10, comprising the step of: -» during the protection phase (P), defining, for at least one dependent function, a family of algorithmically equivalent dependent functions by: - adding a noise field to the information that defines the functional the part of the dependent function to be executed in the unit (6), - or use the identification field of the instruction (ClI) and the expected identification fields (ClPk) of the operands. 12. Method according to claim 9, 10 or 11, comprising steps of: during the protection phase (P): defining: - as a method for renaming the instructions, an encryption method for encrypting the instructions, - and as a return device (20), means that implement a decryption method to decrypt the renamed instructions and thus restore the identity of the dependent functions to execute in the device (6). 13. Method according to one of claims 1 to 12, comprising the step of: during the protection phase (P): modifying the protected software (2p) by: - selecting, in the source of the protected software (2ps), at least one conditional jump which is performed in at least one selected algorithmic processing, - modifying at least one selected part of the source for the protected software (2ps), this modification being such that during execution of the protected software (2p), the functionality in at least one selected conditional jump is executed in the device (6), using the second execution part (2peu), - and generate: > the first object part (2pos) of the protected software (2p), said first object part (2pos) being such that during execution of the protected software (2p), the functionality in at least one selected conditional jump is executed in the unit (6), > and the second object part (2pou) of the protected software (2p), said second object part (2pou) being such that, after uploading t il the device (6) and during execution of the protected software (2p), the second execution part (2peu) appears, by means of which the functionality in at least one selected conditional jump is executed, and during the use phase (U): • in the presence of the device (6) and each time a part of the first execution part (2pes) imposes it, execute the functionality in at least one conditional jump in the unit (6), so that said part is executed correctly and that consequently the protected software (2p) is fully functional, • and in the absence of the unit (6), and despite the request from a part of the first execution part (2pes) to perform the functionality in a conditional jump in the unit (6), not be able to comply with said request correctly way, so that at least the said part is not executed correctly and that consequently the protected software (2p) is not fully functional. 14. Method according to claim 13, comprising the step of, during the protection phase (P), modifying the protected software (2p) by: - selecting, in the source of the protected software (2ps), at least one series of selected conditional jumps, - modifying at least one selected portion of the source of the protected software (2ps), this modification being such that during execution of the protected software (2p), the overall functionality of the at least one selected series of conditional jumps is executed in the device (6), by means of the second execution part (2peu), - and by generating: > the first object part (2pos) of the protected software (2p), said first object part (2pos) being such that during execution of the protected software (2p) , the functionality of at least one selected series of conditional jumps is executed in the device (6), > and the second object part (2pou) of the protected software (2p), said second object part (2pou) being such that, after uploading to the device ( 6 ) and during execution of the protected software (2p), the second execution part (2peu) appears, by means of which the overall functionality of at least one selected series of conditional jumps is executed. 15. Method according to one of claims 1 to 14, comprising the step of dividing the protection phase (P) into a pre-protection sub-phase (P1) which is independent of the software to be protected, and a post-protection sub-phase (P2) which depends on the software to be protected. 16. Method according to claim 15, comprising the step of, during the pre-protection sub-phase (P1), carrying out a definition step (S11) during which all the definitions are entered. 17. Method according to claim 16, comprising the step of, after the definition step (S11), carrying out a construction step (S12) during which the exploitation means is produced. 18. Method according to claim 17, comprising the step of, after the construction step (S12), carrying out a pre-customization step (S13) which includes the step of uploading, to a blank unit (60), at least a part of the exploitation means for the purpose of producing a pre-customized device (66). 19. Method according to claim 16 or 17, comprising the step of, during the pre-protection sub-phase (P1), carrying out a tool construction step (S14) during which tools are generated which help to generate protected software or to automate software protection. 20. Method according to claims 15 and 18, comprising the step of dividing the post-protection sub-phase (P2) into: • a creation step (S21) during which the protected software (2p) is generated from the vulnerable software (2v), • optionally , a modification step (S22) during which the protected program the item (2p) is modified, and a customization step (S23) during which: - the second object part (2pou) of the protected software (2p), which contains the exploitation means, is uploaded to at least one blank unit (60) for the purpose of producing at least one unit (6), - or part of the second object part (2pou) of the protected software (2p), possibly containing the exploitation means, is uploaded to at least one pre-customized unit (66) for the purpose of producing at least one unit (6). 21. Method according to claims 19 and 20, comprising the step of, during the creation step (S21) and optionally during the modification step (S22), using at least one tool which helps to generate protected software or which automates software protection.