+

WO2003012649A2 - Procede pour proteger un logiciel a l'aide de 'variables' contre son utilisation non autorisee - Google Patents

Procede pour proteger un logiciel a l'aide de 'variables' contre son utilisation non autorisee Download PDF

Info

Publication number
WO2003012649A2
WO2003012649A2 PCT/FR2002/002338 FR0202338W WO03012649A2 WO 2003012649 A2 WO2003012649 A2 WO 2003012649A2 FR 0202338 W FR0202338 W FR 0202338W WO 03012649 A2 WO03012649 A2 WO 03012649A2
Authority
WO
WIPO (PCT)
Prior art keywords
execution
unit
protected software
software
executed
Prior art date
Application number
PCT/FR2002/002338
Other languages
English (en)
Other versions
WO2003012649A3 (fr
Inventor
Jean-Christophe Cuenod
Gilles Sgro
Original Assignee
Validy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to UA2004010469A priority Critical patent/UA77186C2/uk
Priority to MXPA04000488A priority patent/MXPA04000488A/es
Priority to CA002454090A priority patent/CA2454090A1/fr
Priority to BR0211374-0A priority patent/BR0211374A/pt
Priority to APAP/P/2004/002958A priority patent/AP2004002958A0/en
Priority to JP2003517758A priority patent/JP3949107B2/ja
Priority to IL15995302A priority patent/IL159953A0/xx
Priority to AU2002325998A priority patent/AU2002325998B2/en
Priority to EA200400057A priority patent/EA005465B1/ru
Application filed by Validy filed Critical Validy
Priority to KR1020047000804A priority patent/KR100940347B1/ko
Priority to HU0400228A priority patent/HUP0400228A2/hu
Priority to EP02760378A priority patent/EP1412861A2/fr
Publication of WO2003012649A2 publication Critical patent/WO2003012649A2/fr
Publication of WO2003012649A3 publication Critical patent/WO2003012649A3/fr
Priority to ZA2004/00348A priority patent/ZA200400348B/en
Priority to HR20040049A priority patent/HRP20040049A2/hr
Priority to NO20040232A priority patent/NO20040232L/no
Priority to TNP2004000012A priority patent/TNSN04012A1/fr
Priority to IS7121A priority patent/IS7121A/is
Priority to HK05102678A priority patent/HK1070155A1/xx

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/123—Restricting unauthorised execution of programs by using dedicated hardware, e.g. dongles, smart cards, cryptographic processors, global positioning systems [GPS] devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/125—Restricting unauthorised execution of programs by manipulating the program code, e.g. source code, compiled code, interpreted code, machine code

Definitions

  • the present invention relates to the technical field of data processing systems in the general sense and it relates, more specifically, to the means for protecting, against its unauthorized use, software running on said data processing systems.
  • the object of the invention relates, more particularly, to the means for protecting software against its unauthorized use, from a storage unit or from a processing and storage unit, such a unit being commonly embodied by a smart card or a hardware key on a USB port.
  • the main drawback concerns the unauthorized use of software by users who have not paid license fees.
  • This unlawful use of software causes obvious damage to software publishers, software distributors and / or any person integrating such software into products.
  • various solutions have been proposed in the state of the art to protect software.
  • a protection solution which consists in implementing a material protection system, such as a physical element called a protection key or "dongle" in English terminology.
  • a protection key should guarantee the execution of the software only in the presence of the key.
  • a malicious person or hacker can, using specialized tools, such as disassemblers, remove the control key control instructions. It then becomes possible to make illegal copies corresponding to modified versions of software that no longer have any protection.
  • this solution cannot be generalized to all software, since it is difficult to connect more than two protection keys on the same system.
  • the object of the invention is precisely to remedy the drawbacks stated above by proposing a method for protecting software against its unauthorized use, from a storage unit or from a processing and processing unit. ad hoc storage, insofar as the presence of such a unit is necessary for the software to be fully functional.
  • the object of the invention relates to a method for protecting, from at least one blank unit comprising at least storage means, vulnerable software against its unauthorized use, said vulnerable software operating on a data processing system.
  • the method according to the invention consists: - in a protection phase:
  • the method according to the invention consists: in the protection phase:
  • the first part of execution is executed in the data processing system and a second part of execution is executed in the unit which also includes processing means,> at least the functionality at least one chosen algorithmic processing is executed by means of the second execution part,
  • commands stages are defined so that during the execution of the protected software, each stage command is executed by the first part of execution and triggers in the unit, the execution by means of the second part of execution , of a step,> and a scheduling of the step commands is chosen from all the schedules allowing the execution of the protected software, - and by producing:
  • the method according to the invention consists: in the protection phase:
  • the first part of execution is executed in the data processing system and a second part of execution is executed in the unit,
  • commands elementary are integrated in the source of the protected software, so that during the execution of the protected software, each elementary command is executed by the first part of execution and triggers in the unit, the execution by means of the second part of execution, of an elementary function,
  • the method according to the invention consists: -> in the protection phase:
  • At least one chosen step is broken down so that during the execution of the protected software, this step is executed by means of the second part of execution, using elementary functions,> for at least one chosen step, commands elementary are integrated into the source of the protected software, so that during the execution of the protected software, each elementary command is executed by the first part of execution and triggers in the unit, the execution by means of the second part of execution, of an elementary function,
  • the second object part of the protected software also containing the operating means, this second object part being such that, after loading into the unit and during the execution of the protected software, the second part of execution appears using from which the elementary functions triggered by the first part of execution are executed, -> and in the use phase:
  • the method according to the invention consists:
  • the second object part of the protected software containing the operating means also using the detection means and the coercion means, this second object part being such that, after loading into the unit and during the execution of the protected software, at least one characteristic of software execution is monitored and non-compliance with a criterion results in information to the data processing system and / or in a modification of the execution of the protected software, and in the use phase: • in the presence of the unit:
  • the method according to the invention consists: -. * In the protection phase:
  • the method according to the invention consists: -> in the protection phase:
  • the method according to the invention consists:
  • the method according to the invention consists:
  • the method according to the invention consists:
  • sequence of instructions - as an execution feature, a desired sequence for the execution of instructions, - as detection means, means making it possible to detect that the sequence of instructions does not correspond to that desired,
  • the method according to the invention consists: -> in the protection phase:
  • detection means means making it possible, during the execution of an instruction, for each operand, when the flag field requires it, to check the equality between the identification field generated corresponding to the register used by this operand, and the expected identification field of the origin of this operand,
  • the method according to the invention consists:
  • the second object part of the protected software containing the operating means also implementing the recovery means, this second object part being such that, after loading into the unit and during the execution of the protected software, the identity of the dependent functions whose execution is triggered by the first part of execution is restored by means of the second part of execution, and the dependent functions are executed by means of the second part of execution, and in the phase d 'use :
  • the method according to the invention consists of: are different,
  • the method according to the invention consists: -> in the protection phase, in defining, for at least one dependent function, a family of algorithmically equivalent dependent functions:
  • the method according to the invention consists: - in the protection phase: • to be defined:
  • the method according to the invention consists: -> in the protection phase:
  • the method according to the invention consists, in the protection phase, of modifying the protected software: - by choosing, in the source of the protected software at least one series of selected conditional connections,
  • the method according to the invention thus makes it possible to protect the use of software by the implementation of a storage unit which has the particularity of containing part of the software being executed. It follows that any version derived from the software trying to operate without the storage unit requires recreating the part of the software contained in the storage unit when execution, under penalty that this version derived from the software is not fully functional.
  • Figs. 10 and 11 are functional block diagrams illustrating the various representations of software respectively unprotected and protected by the method according to the invention.
  • Figs. 20 to 22 illustrate, by way of examples, various embodiments of a device for implementing the method according to the invention.
  • Figs. 30 and 31 are functional block diagrams explaining the general principle of the method according to the invention.
  • Figs. 40 to 43 are diagrams illustrating the protection method according to the invention implementing the principle of protection by variable.
  • Figs. 50 to 54 are diagrams illustrating the protection method according to the invention implementing the principle of protection by temporal dissociation.
  • Figs. 60 to 64 are diagrams illustrating the protection method according to the invention implementing the principle of protection by elementary functions.
  • Figs. 70 to 74 are diagrams illustrating the protection method according to the invention implementing the principle of protection by detection and coercion.
  • Figs. 80 to 85 are diagrams illustrating the protection method according to the invention implementing the principle of protection by renaming.
  • Figs. 90 to 92 are diagrams illustrating the protection method according to the invention implementing the principle of protection by conditional branching.
  • Fig. 100 is a diagram illustrating the different phases of implementation of the subject of the invention.
  • Fig. 110 illustrates an exemplary embodiment of a system allowing the implementation of the stage of construction of the protection phase according to the invention.
  • Fig. 120 illustrates an exemplary embodiment of a pre-personalization unit used in the protection method according to the invention.
  • Fig. 130 illustrates an exemplary embodiment of a system allowing the implementation of the tool-making stage of the protection phase in accordance with the invention.
  • Fig. 140 illustrates an embodiment of a system allowing the implementation of the protection method according to the invention.
  • Fig. 150 illustrates an embodiment of a personalization unit used in the protection method according to the invention.
  • a data processing system 3 is a system capable of executing a program.
  • a storage unit is a unit capable of accepting data supplied by a data processing system 3, of storing the data and of restoring them at the request of the data processing system 3.
  • a processing and storage unit is a unit capable of:
  • a unit 6 is a storage unit or a processing and storage unit implementing 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 information transforming it into a unit 6.
  • a blank unit 60 can possibly become a unit 6 during the execution of software protected by the method according to the invention and become again after execution, a blank unit 60.
  • a pre-personalized unit 66 is a blank unit 60 having received part of the information allowing it, after receiving additional information, to be transformed into a unit 6.
  • the loading of information into a blank unit 60 or a pre-personalized unit 66 corresponds to a transfer of information into the blank unit 60 or the pre-personalized unit 66, and to a storage of said transferred information.
  • the transfer may include a change in information format.
  • a variable, data or function contained in the data processing system 3 will be indicated by a capital letter, while a variable, data or function contained in unit 6 will be indicated by a small letter.
  • Protected software is software that has been protected by at least one protection principle implemented by the process according to the invention.
  • Vulnerable software is software that has not been protected by any protection principle implemented by the process according to the invention.
  • a source representation of software is understood as a representation which, after transformation, gives an object representation.
  • a source representation can be presented at different levels, from an abstract conceptual level to a level executable directly by a data processing system or a processing and storage unit.
  • An object representation of a software corresponds to a level of representation which after transfer to a distribution and then loading into a data processing system or a processing and storage unit, can be executed. This could be, for example, a code binary, interpreted code, etc.
  • a distribution is a physical or virtual medium containing the object representation, this distribution must be made available to the user to enable him to use the software.
  • a dynamic representation corresponds to the execution of the software from its distribution.
  • a portion of software corresponds to any part of software and may, for example, correspond to one or more instructions, consecutive or not, and / or to one or more functional blocks consecutive or not, and / or to one or more functions, and / or one or more subroutines, and / or one or more modules.
  • a portion of software can also correspond to all of this software.
  • Figs. 10 and 11 illustrate the various representations respectively of vulnerable software 2v in the general sense, and of protected software 2p according to the method according to the invention.
  • Fig. 10 illustrates various representations of vulnerable 2v software appearing during its life cycle. Vulnerable 2v software can thus appear under one of the following representations:
  • This distribution can be commonly presented in the form of a physical distribution means such as a CDROM or in the form of files distributed across a network (GSM, Internet, etc.),
  • FIG. 11 illustrates various representations of 2p protected software appearing during its life cycle.
  • Protected 2p software can thus appear under one of the following representations:
  • a 2ps source representation comprising a first source part intended for the data processing system 3 and possibly, a second source part intended for the unit 6, a part of these source parts possibly commonly being contained in common files,
  • a 2po object representation comprising a first object part 2pos intended for the data processing system 3 and possibly, a second object part 2pou intended for the unit 6,
  • this first 2pds distribution part being intended for the data processing system 3 and which can commonly be in the form of a physical distribution means such as a CDROM, or in the form of files distributed across a network (GSM, Internet, 7),
  • pre-personalized unit 66 onto which part of the second object part 2pou has been loaded and for which the user must complete the personalization by loading additional information, in order to obtain a unit 6, these additional information being obtained, for example, by uploading or downloading through a network,
  • This dynamic representation 2pe comprises a first execution part 2pes which is executed in the data processing system 3 and a second execution part 2peu which is executed in the unit 6.
  • the expressions first part of the protected software and second part of the protected software are used.
  • the implementation of the method according to the invention in accordance with the dynamic representation of FIG. 11, uses a device lp comprising a data processing system 3 connected by a link 5 to a unit 6.
  • the data processing system 3 is of all types and comprises, in a conventional manner, at least one processor 4.
  • the system 3 may be a computer or be part, for example, of various machines, devices, fixed or mobile products, or vehicles in the general sense.
  • the link 5 can be made in any possible way, such as for example by a serial line, a USB bus, a radio link, an optical link, a network link or a direct electrical connection on a circuit of the data processing system 3 , etc.
  • the unit 6 can possibly be physically inside the same integrated circuit as the processor 4 of the data processing system 3. In this case, the unit 6 can be considered as a coprocessor with respect to to processor 4 of the data processing system 3 and the link 5 is internal to the integrated circuit.
  • Figs. 20 to 22 show by way of illustration and without implied limitation, various embodiments of the lp device allowing the implementation of the protection method according to the invention.
  • the protection device lp comprises, as a data processing system 3, a computer and, as a unit 6, a smart card 7 and its interface 8 commonly called a card reader.
  • the computer 3 is connected to the unit 6 by a link 5.
  • the first part of execution 2pes which is executed in the computer 3 and the second part of execution 2peu which is executed in the smart card 7 and its interface 8, both must be functional so that the protected software 2p is fully functional.
  • the lp protection device equips a product 9 in the general sense, comprising various members 10 adapted to the function or functions assumed by such a product 9.
  • the lp protection device comprises, on the one hand, a data processing system 3 embedded in the product 9 and, on the other hand, a unit 6 associated with the product 9.
  • the protected software 2p must be fully functional.
  • the first part of execution 2pes which is executed in the data processing system 3 and the second part of execution 2peu which is executed in unit 6, both both must be functional.
  • This 2p protected software therefore makes it possible, indirectly, to protect against unauthorized use, the product 9 or one of its functionalities.
  • the product 9 can be an installation, a system, a machine, a toy, a household appliance, a telephone, etc.
  • the protection device lp includes several computers, as well as part of a communication network.
  • the data processing system 3 is a first computer connected by a network type link 5, to a unit 6 constituted by a second computer.
  • the second computer 6 is used as a license server for 2p protected software.
  • the first part of execution 2pes which is executed in the first computer 3 and the second part of execution 2peu which is executed in the second computer 6, both must be functional so that the protected 2p software is fully functional.
  • Fig. 30 makes it possible to explain more precisely, the protection method according to the invention.
  • vulnerable software 2v is considered to be executed completely in a data processing system 3.
  • the data processing system 3 comprises transfer means 12 connected by the link 5, to transfer means 13 forming part of the unit 6 making it possible to communicate between them, the first part of execution 2pes and the second part of execution 2peu of the protected software 2p.
  • the transfer means 12, 13 are of software and / or hardware nature and are capable of ensuring and, if necessary, optimizing the communication of data between the data processing system 3 and the unit 6.
  • the transfer means 12, 13 are adapted to allow protected software 2p to be available which is preferably independent of the type of link 5 used. These transfer means 12, 13 are not part of the object of the invention and are not described more precisely because they are well known to those skilled in the art.
  • the first part of the 2p protected software includes commands. When performing the protected software 2p, the execution of these commands by the first part of execution 2pes allows the communication between the first part of execution 2pes and the second part of execution 2peu. In the following description, these commands are represented by IN, OUT or TRIG.
  • the unit 6 includes protection means 14. In the case where the unit 6 is a storage unit, the protection means 14 include storage means 15. In the case where the unit 6 is a processing and storage unit, the protection means 14 include storage means 15 and processing means 16.
  • a unit 6 physically present and comprising protection means 14 adapted to the execution of the second execution part 2peu of the protected software 2p is always considered to be present, • a unit 6 physically present but comprising protection means 14 unsuitable, that is to say not allowing the correct implementation of the second part of execution 2peu of the protected software 2p is considered as present, when it functions correctly, and as absent when it does not function correctly , • and a unit 6 physically absent is always considered to be absent.
  • the transfer means 13 are broken down into two parts, one of which is located on the interface 8 and the other of which is located on the smart card 7.
  • the absence of the smart card 7 is considered to be equivalent to the absence of the unit 6.
  • the protection means 14 are not accessible and do not allow therefore not the execution of the second execution part 2peu of the protected software, so that the protected software 2p is not completely functional.
  • the protection method aims to implement a principle of protection known as "variable”, a description of which is given in relation to FIGS. 40 to 43.
  • variable For the implementation of the principle of protection by variable, it is chosen in the source of the vulnerable software 2vs at least one variable which during the execution of the vulnerable software 2v, partially defines the state of this one.
  • state of a software it must be understood all the information, at a given time, necessary for the complete execution of this software, so that the absence of such a chosen variable harms the complete execution of this software. It is also chosen at least a portion of the source of the vulnerable software 2vs containing at least one chosen variable.
  • At least a selected portion of the source of the vulnerable 2vs software is then modified, so as to obtain the source of the protected 2ps software.
  • This modification is such that during the execution of the protected software 2p, at least a portion of the first part of execution 2pes which is executed in the data processing system 3, takes into account that at least one chosen variable or at least one copy of the chosen variable resides in unit 6.
  • unit 6 comprises at least storage means 15.
  • FIG. 40 illustrates an example of execution of a vulnerable software 2v. In this example, it appears during the execution of the vulnerable software 2v in the data processing system 3:
  • Fig. 41 illustrates an example of a first embodiment of the invention for which the variable resides in unit 6.
  • Fig. 42 illustrates an example of a second embodiment of the invention for which a copy of the variable resides in the unit 6.
  • a copy of the variable resides in the unit 6.
  • Fig. 43 illustrates an example of an attempt to execute the protected software 2p, while the unit 6 is absent.
  • the protection method aims to implement a protection principle, known as "temporal dissociation", a description of which is given in relation to FIGS. 50 to 54.
  • the principle of protection by temporal dissociation it is chosen, in the source of the vulnerable software 2vs, at least one algorithmic processing using at least one operand and rendering at least one result. It is also chosen at least a portion of the source of the vulnerable software 2vs containing at least one chosen algorithmic processing.
  • At least a selected portion of the source of the vulnerable 2vs software is then modified, so as to obtain the source of the protected 2ps software.
  • This modification is such that in particular:
  • the second execution part 2peu which is executed in the unit 6, performs at least the functionality of at least one chosen algorithmic processing
  • each algorithmic processing chosen is broken down into several distinct stages, namely: stage 1: the provision of the operand (s) for unit 6, stage 2: the realization in the unit 6, the functionality of the chosen algorithmic processing using this or these operands, and step 3: possibly, the provision by unit 6 for the data processing system 3, of the result of the chosen algorithmic processing,
  • step commands are defined to trigger the execution of the steps, • and a sequencing of the step commands is chosen from among all of the schedules allowing the execution of the protected software 2p.
  • the first 2pe executes execution part of the protected software 2p, which is executed in the data processing system 3, executes the step commands, triggering in the unit 6, the execution by means of the second execution part 2 little, from each of the previously defined steps.
  • the unit 6 comprises storage means 15 and processing means 16.
  • Fig. 50 illustrates an example of execution of vulnerable 2v software.
  • the vulnerable software 2v in the data processing system 3, at a given instant, the calculation of Z - F (X, Y) corresponding to the assignment to a variable Z, of the result of an algorithmic processing represented by a function F and using operands X and Y.
  • Fig. 51 illustrates an example of implementation of the invention for which the algorithmic processing chosen in FIG. 50 is deported to unit 6.
  • the algorithmic processing chosen in FIG. 50 is deported to unit 6.
  • step 1 • at time ti, step 1, namely the execution of a step command CEi triggering the transfer of data X and Y from the data processing system 3 to storage areas respectively x and y located in the storage means 15 of the unit 6, this step command CEi being represented by OUT (x, X), OUT (y, Y),
  • step 2 • at time t 2 , step 2, namely the execution of a step command CE 2 , triggering in unit 6, the execution by means of the second execution part 2peu, of the function f, this function f being algorithmically equivalent to the function F and this step command CE 2 being represented by TRIG (f).
  • step command CE 2 leads to the execution of the function f which uses the content of the storage areas x and y and returns its result in a storage area z of the unit 6 , • and at time t 3 , step 3, namely the execution of a step command CE 3 triggering the transfer of the result of the function f, contained in the storage area z of the unit 6 to the data processing system 3 in order to assign it to the variable Z, this step command CE 3 being represented by IN (z).
  • steps 1 to 3 are carried out successively. It should be noted that two improvements can be made:
  • the first improvement concerns the case where several algorithmic treatments are deported to unit 6 and at least the result of an algorithmic processing is used by another algorithmic processing. In this case, certain transfer steps can possibly be deleted.
  • the second improvement aims to opt for a relevant scheduling of the stage commands among all the scheduling allowing the execution of the protected software 2p.
  • a sequencing of the step commands which temporally dissociates the execution of the steps, by interposing, between them portions of code executed in the data processing system 3 and comprising or not step commands for determining other data.
  • Figs. 52 and 53 illustrate the principle of such an embodiment.
  • Fig. 52 shows an example of execution of vulnerable 2v software. In this example, it appears, during the execution of the vulnerable software 2v, in the data processing system 3, the execution of two algorithmic processing leading to the determination of Z and Z ', such that Z ⁇ - F (X, Y) and Z '- F' (X ',
  • Fig. 53 illustrates an example of implementation of the method according to the invention for which the two algorithmic treatments chosen in FIG. 52 are deported to unit 6.
  • the step commands CEi to CE 3 are not executed consecutively insofar as step commands CE'i to CE ' 3 , as well as other portions of code are interleaved.
  • the following scheduling is thus carried out: CEi, portion of interleaved code, CE 2 , portion of interleaved code, CE'i, portion of interleaved code, CE ' 2 , portion of interleaved code, CE' 3 , portion of intercalated code, CE 3 .
  • Fig. 54 illustrates an example of an attempt to execute the protected software 2p, while the unit 6 is absent.
  • the first 2pes execution part of the protected software 2p is executed in the data processing system 3:
  • the protection method aims to implement a protection principle, known as "elementary functions", a description of which is given in relation to FIGS. 60 to 64.
  • operating means making it possible to transform a blank unit 60 containing storage means 15 and processing means 16 into a unit 6 capable of executing the elementary functions, the execution of these elementary functions being triggered by the execution in the data processing system 3 of elementary commands.
  • the source of the vulnerable software 2vs at least one algorithmic processing using at least one operand and rendering at least one result. It is also chosen at least a portion of the source of the vulnerable software 2vs containing at least one chosen algorithmic processing.
  • At least a selected portion of the source of the vulnerable 2vs software is then modified, so as to obtain the source of the protected 2ps software.
  • This modification is such that in particular:
  • the second execution part 2peu which is executed in the unit 6, performs at least the functionality of at least one chosen algorithmic processing
  • each chosen algorithmic processing is broken down so that during the execution of the protected software 2p, each chosen algorithmic processing is executed, by means of the second execution part 2peu, using elementary functions.
  • each chosen algorithmic processing is broken down into elementary functions fe bombard(with n varying from 1 to N), namely:
  • the first part of execution 2pes of the protected software 2p which is executed in the data processing system 3, executes elementary commands CFE Stamm(with n varying from 1 to N), triggering in unit 6, the execution by means of the second execution part 2peu, of each of the elementary functions fe n previously defined.
  • Fig. 60 illustrates an example of execution of vulnerable 2v software.
  • the vulnerable software 2v in the data processing system 3 at a given instant, the calculation of Z ⁇ - F (X, Y) corresponding to the assignment to a variable Z of the result of a treatment algorithm represented by a function F and using operands X and Y.
  • Fig. 61 illustrates an example of implementation of the invention for which the algorithmic processing chosen in FIG. 60 is deported to unit 6.
  • the algorithmic processing chosen in FIG. 60 is deported to unit 6.
  • the execution of these elementary commands leads to the execution in unit 6, of the elementary functions fe 3 to f ⁇ -i which use the content of the storage areas x, y and render the result in a storage area z of the unit 6, • and at time tN, the execution of an elementary command CFE N triggering in unit 6, the execution by means of the second execution part 2peu, of the elementary function f ⁇ ensuring the transfer of the result of the algorithmic processing, contained in the storage area z of unit 6 to the processing system 3, in order to assign it to variable Z, this elementary command CFE N being represented by IN (z).
  • the elementary commands 1 to N are executed successively. It should be noted that two improvements can be made: • The first improvement concerns the case where several algorithmic treatments are deported to unit 6 and at least the result of an algorithmic processing is used by another algorithmic processing. In this case, some elementary commands used for the transfer, can possibly be deleted.
  • the second improvement aims to opt for a relevant scheduling of elementary orders among all the scheduling allowing the execution of the protected software 2p.
  • Figs. 62 and 63 illustrate the principle of such an embodiment.
  • Fig. 62 shows an example of execution of vulnerable 2v software.
  • Fig. 63 illustrates an example of implementation of the method according to the invention for which the two algorithmic treatments chosen in FIG. 62 are deported to unit 6.
  • the elementary commands CFEi to CFE N are not executed consecutively, insofar as the elementary commands
  • CFE'i to CFE ' M are interspersed.
  • the following scheduling is thus carried out: CFEi, portion of interleaved code, CFE'i, CFE 2 , portion of interleaved code, CFE ' 2 , CFE' 3 , portion of interleaved code,
  • Fig. 64 illustrates an example of an attempt to execute the protected software 2p, while the unit 6 is absent.
  • the execution of an elementary command cannot trigger the execution of the corresponding elementary function, due to the absence of unit 6.
  • the value to be assigned to the variable Z cannot therefore be determined correctly.
  • the protection method aims to implement a protection principle, known as “detection and coercion", a description of which is given in relation to FIGS. 70 to 74.
  • • detection means 17 to be implemented in unit 6 and making it possible to detect that at least one software execution characteristic does not meet at least one associated criterion
  • • and coercion means 18 to be implemented in unit 6 and making it possible to inform the data processing system 3 and / or to modify the execution of a software, when at least one criterion is not respected.
  • Fig. 70 illustrates the means necessary for the implementation of this principle of protection by detection and coercion.
  • the unit 6 comprises the detection means 17 and the coercion means 18 belonging to the processing means 16.
  • the coercion means 18 are informed of the non-compliance with a criterion by the detection means 17.
  • the detection means 17 use information coming from the transfer means 13 and / or the storage means 15 and / or the processing means 16, in order to monitor one or more performance characteristics of software. At least one criterion to be respected is attached to each software execution characteristic.
  • the detection means 17 inform the coercion means 18.
  • These coercion means 18 are adapted to modify, de appropriately, the condition of the unit 6.
  • the first type of software execution characteristic corresponds to a variable for measuring the execution of software and the second type corresponds to a usage profile for software. These two types of characteristics can be used independently or in combination.
  • 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 limit of use of said functionality,
  • the source of the vulnerable software 2vs is then modified, so as to obtain the source of the protected software 2ps, this modification being such that, during the execution of the protected software 2p, the second part of execution 2peu:
  • the detection means 17 inform the coercion means 18 which take a suitable decision to inform the data processing system 3 and / or modify the processing carried out by the processing means 16 making it possible to modify the operation of the portion of the 2p protected software, so that the operation of the 2p protected software is modified.
  • the source of the vulnerable software 2vs is then modified, so as to obtain the source of the protected software 2ps, this modification being such that, during the execution of the protected software 2p, the second part of execution 2peu: • updates the variable of measurement according to the use of said functionality,
  • the unit 6 informs the data processing system 3 directing the protected software 2p to no longer use this functionality . If the 2p protected software continues to use this functionality, the second threshold may be exceeded. In the event that the second threshold is exceeded, the coercion means 18 can render the chosen functionality inoperative and / or render the protected software 2p inoperative.
  • reloading means For the implementation of a second preferred embodiment of the protection by detection and coercion principle using, as a characteristic, a measurement variable, reloading means are defined making it possible to credit at least one additional use for at least one software functionality monitored by a measurement variable.
  • Operating means are also constructed using, in addition to detection means 17, coercion means 18 and updating means, reloading means.
  • At least one measurement variable serving to limit the use of at least one functionality of the software and to which at least one additional use must be able to be credited.
  • the source of the vulnerable software 2vs is then modified, so as to obtain the source of the protected software 2ps, this modification being such that, in a phase known as reloading, at least one additional use of at least one functionality corresponding to a variable of selected measure can be credited.
  • At least one selected measurement variable and / or at least one associated threshold is updated, so as to allow at least one additional use of the corresponding functionality.
  • a software usage profile For the implementation of the principle of protection by detection and coercion using, as a characteristic, a software usage profile, it is defined as a criterion to be respected for this usage profile, at least one performance trait of software.
  • the source of the vulnerable software 2 s is then modified, so as to obtain the source of the protected software 2ps, this modification being such that, during the execution of the protected software 2p, the second part of execution 2peu respects all the features of execution chosen.
  • the unit 6 itself monitors the way in which the second execution part 2peu is executed and can inform the data processing system 3 and / or modify the operation of the protected software 2p, in the case where at least one performance line is not respected.
  • the data processing system 3 is informed thereof and / or the operation of the portion of protected software 2p is modified, so that the operation of the protected 2p software is modified. It is possible to envisage the monitoring of different execution traits, such as for example the monitoring of the presence of instructions comprising a marker or the monitoring of the execution sequence for at least part of the instructions.
  • • detection means 17 making it possible to detect that the sequence of instructions does not correspond to that desired
  • • and coercion means 18 making it possible to inform the data processing system 3 and / or to modify the execution of software when the sequence of instructions does not correspond to that desired. It is also constructed operating means allowing, at unit 6, to also execute the instructions of the instruction set, the execution of these instructions being triggered by the execution in the data processing system 3 of instruction commands.
  • the source of the vulnerable 2vs software is then modified so as to obtain the source of the protected 2ps software, this modification is such that, during the execution of the protected software 2p:
  • the second execution part 2peu executes at least the functionality of the chosen algorithmic processing
  • Fig. 71 illustrates an example of implementation of the principle of protection by detection and coercion using, as an execution trait to respect the monitoring of the execution sequence of at least part of the instructions, in the case where the desired sequence is respected.
  • the instructions each include a part defining the functionality of the instruction and a part making it possible to check the desired sequence for the execution of the instructions.
  • the Cli instruction commands are represented by TRIG (ii) and the desired sequence for the execution of the instructions is i Vietnamese, i n + ⁇ and i n + 2 .
  • the execution in unit 6 of the instruction i n gives the result a and the execution of the instruction i drape+ ⁇ gives the result b.
  • the instruction i dressing+2 uses as operand, the results a and b of instructions i hinge and i drape+ ⁇ and its execution gives the result c. Given that this sequence of instructions executed in unit 6 corresponds to that desired, this results in normal or nominal operation of the protected software 2p.
  • Fig. 72 illustrates an example of implementation of the principle of protection by detection and coercion using, as an execution trait to be observed, monitoring the execution sequence of at least part of the instructions, in the case where the desired sequence is not respected.
  • the desired sequence for the execution of the instructions is always i n , i n + ⁇ and i n + 2-
  • the sequence of execution of the instructions is modified by replacing the instruction i mecanic by the instruction i ' n , so that the sequence actually executed is i' n , i n + ⁇ and i n + 2-
  • the execution of the instruction i ' emphasizes the result a, that is ie the same result as the execution of the instruction i n .
  • the detection means 17 detect that the instruction i ' neighbordoes not correspond to the instruction desired to generate the result used as the operand of the instruction i n +2.
  • the detection means 17 inform the coercion means 18 which consequently modify the operation of the instruction i n + 2 , so that the execution of the instruction i n + 2 gives the result c 'which may be different Dec.
  • the execution of the instruction i ' may also be different from c.
  • Figs. 73 and 74 illustrate a preferred embodiment of the principle of protection by detection and coercion using, as an execution trait to be observed, monitoring of the execution sequence of at least part of the instructions.
  • a set of instructions is defined, at least certain instructions of which work on registers and use at least one operand in order to render a result.
  • a part PF defining the functionality of the instruction
  • a part PE defining the desired sequence for the execution of the instructions.
  • the PF part corresponds to the operation code known to those skilled in the art.
  • the PE part defining the desired sequence includes bit fields corresponding to:
  • the instruction set includes V registers belonging to the processing means 16, each register being named R v , with v varying from 1 to V.
  • R v For each register R v , two fields are defined, namely:
  • This CIG V generated identification field is automatically updated with the content of the instruction identification field
  • the detection means 17 perform the following operations for each operand k:
  • the detection means 17 consider that the sequence of execution of the instructions is not respected.
  • the coercion means 18 make it possible to modify the result of the instructions when the detection means 17 have informed them of a chain of instructions that has not been observed.
  • a preferred embodiment consists in modifying the functional part
  • the protection method aims to implement a protection principle, known as "renaming”, a description of which is given in relation to FIGS. 80 to 85.
  • a setpoint corresponding at least in part to the information transmitted by the first 2pes execution part, to the second 2peu execution part, in order to trigger the execution of the corresponding dependent function, this setpoint in the form of at least one argument of the triggering command,
  • a method for renaming the instructions intended to be implemented when the vulnerable software is modified such a method making it possible to rename the instructions in order to obtain triggering commands with renowned instructions making it possible to conceal the identity of the corresponding dependent functions
  • • and recovery means 20 intended to be implemented in the unit 6 during the use phase and making it possible to find the initial setpoint, from the renamed setpoint, in order to find the dependent function to be executed.
  • each chosen algorithmic processing is broken down by so that during the execution of the protected software 2p, each chosen algorithmic processing is executed, by means of the second execution part 2peu, using dependent functions.
  • each chosen algorithmic processing is broken down into dependent functions fd n (with n varying from 1 to N), namely:
  • the second execution part 2peu executes the dependent functions fd n .
  • the first execution part 2pes of the protected software 2p, executed in the data processing system 3, executes triggering commands with renamed setpoints transferring renamed setpoints to unit 6, and initiating recovery in unit 6 by means recovery means 20, instructions, then execution by means of the second execution part 2peu, of each of the dependent functions fd ⁇ previously defined.
  • the principle of protection by renaming consists in renaming the instructions of the triggering commands, so as to obtain triggering commands with renowned instructions whose execution in the data processing system 3, triggers in the unit 6 , the execution of the dependent functions which would have been triggered by the triggering commands with instructions not renamed, without however that the examination of the protected software 2p does not make it possible to determine the identity of the dependent functions executed.
  • Fig. 80 illustrates an example of execution of a vulnerable 2v software.
  • Figs. 81 and 82 illustrate an example of implementation of the invention.
  • Fig. 81 illustrates the partial implementation of the invention.
  • the first argument of the triggering commands OUT and the argument of the triggering commands TRIG and IN is chosen as a setpoint.
  • the setpoints thus chosen are renamed by the setpoint renaming method.
  • the setpoints of the triggering commands CDi to CD N namely x, y, fd 3 , fd N -i, z are renamed so as to obtain respectively R (x), R (y), R (fd 3 ) ..., R (fd N - ⁇ ), R (z).
  • Fig. 82 illustrates the full implementation of the invention. In this example, during the execution in the data processing system 3, of the first part of execution 2pes of the protected software 2p, and in the presence of the unit 6, it appears:
  • the triggering commands with setpoints renamed 1 to N are executed successively.
  • the first improvement concerns the case where several algorithmic treatments are deported to unit 6 and at least the result of an algorithmic treatment is used by another algorithmic treatment. In this case, certain triggering commands with renowned instructions used for the transfer can be possibly deleted.
  • the second improvement aims to opt for a relevant scheduling of triggering commands with renowned instructions among all the scheduling allowing the execution of the protected software 2p.
  • Figs. 83 and 84 illustrate the principle of such an embodiment.
  • Fig. 83 shows an example of execution of vulnerable 2v software.
  • the execution of two algorithmic processing leading to the determination of Z and Z ' such that Z ⁇ - F (X, Y) and Z ' ⁇ - F' (X ',
  • Fig. 84 illustrates an example of implementation of the method according to the invention for which the two algorithmic treatments chosen in FIG. 83 are deported to unit 6.
  • the triggering commands with renamed setpoints CDCRi to CDCR N are not executed consecutively, insofar as the triggering commands with renamed setpoints CDCR'i to CDCR ' M and other portions of code are interleaved.
  • the following scheduling is thus carried out: CDCRi, portion of interleaved code, CDCR'i, CDCR 2 , portion of interleaved code, CDCR ' 2 , CDCR' 3 , portion of interleaved code, CDCR ', CDCR 3 , CDCRt, ..., CDCRN, CDCR'M-
  • Fig. 85 illustrates an example of an attempt to execute the protected software 2p, while the unit 6 is absent.
  • a dependent function a family of dependent functions algorithmically equivalent but triggered by triggering commands with different renamed setpoints.
  • this algorithmic processing is broken down into dependent functions which for at least one of them is replaced by a dependent function of the same family instead of keeping several occurrences of the same dependent function.
  • triggering commands with renamed setpoints are modified to take account of the replacement of dependent functions by dependent functions of the same family.
  • two dependent functions of the same family have different instructions and therefore triggering commands with different renamed instructions and, it is not possible, on examination of the protected software 2p, to detect that the functions called dependents are algorithmically equivalent.
  • it is defined for at least one dependent function, a family of algorithmically equivalent dependent functions, by concatenating a field of noise to the information defining the functional part of the dependent function to be executed in unit 6.
  • the principle of protection by renaming it is defined as a method for renaming the instructions an encryption method making it possible to encrypt the instructions in order to transform them into renowned instructions. It is recalled that the renaming of the instructions is carried out in the protection phase P.
  • the recovery means 20 are means implementing a decryption method making it possible to decrypt the renowned instructions and thus to restore the identity dependent functions to be executed in unit 6. These recovery means are implemented in unit 6 and can be of software or hardware nature. These recovery means 20 are requested in the use phase U each time a triggering command with a renamed setpoint is executed in the data processing system 3 with the aim of triggering in unit 6, the execution of 'a dependent function.
  • the protection method aims to implement a protection principle known as "conditional connection", the description of which is given in relation to FIGS. 90 to 92.
  • conditional branching For the implementation of the principle of protection by conditional branching, it is chosen in the source of the vulnerable 2vs software, at least one conditional branching BC. It is also chosen at least a portion of the source of the vulnerable software 2vs containing at least one conditional branch BC chosen.
  • At least a selected portion of the source of the vulnerable 2vs software is then modified, so as to obtain the source of the protected 2ps software.
  • This modification is such that in particular during the execution of the protected software 2p: • at least a portion of the first part of execution 2pes, which is executed in the data processing system 3, takes into account that the functionality of at least one conditional branch chosen BC is performed in unit 6,
  • the second execution part 2peu which is executed in the unit 6, executes at least the functionality of at least one conditional connection BC chosen and makes available to the data processing system 3, information allowing the first part of 2pes execution, to continue its execution at the chosen location.
  • the unit 6 comprises storage means 15 and processing means 16.
  • Fig. 90 illustrates an example of execution of vulnerable 2v software.
  • a conditional connection BC indicating to the vulnerable software 2v the place where to continue its unfolding, namely the '' one of the three possible places Bi, B 2 or B 3 .
  • the conditional branch BC takes the decision to continue executing the software at location Bi, B 2 or B 3 .
  • Fig. 91 illustrates an example of implementation of the invention for which the conditional branch chosen to be deported to the unit 6, corresponds to the conditional branch BC.
  • the conditional branch chosen to be deported to the unit 6 corresponds to the conditional branch BC.
  • conditional branching command CBCi triggering in unit 6, the execution by means of the second execution part 2peu, of the remote conditional branching bc algorithmically equivalent to the conditional branching BC, this conditional branching command CBCi being represented by
  • Fig. 92 illustrates an attempt to execute the protected software 2p, while the unit 6 is absent.
  • the object of the invention aims to deport in unit 6, a conditional connection.
  • a preferred embodiment of the invention can consist in deporting in unit 6, a series of conditional branches whose overall functionality is equivalent to all of the functionalities of the conditional branches which have been deported.
  • the execution of the global functionality of this series of deported conditional connections results in the provision, for the data processing system 3, information allowing the first part of 2pes execution of the protected software 2p to continue its execution at the chosen location.
  • the protection method according to the invention is implemented using the principle of protection by variable, possibly associated with one or more other principles of protection.
  • the principle of protection by variable is advantageously supplemented by the principle of protection by temporal dissociation and / or the principle of protection by elementary functions.
  • the principle of protection by variable is supplemented by the principle of protection by time dissociation, supplemented by the principle of protection by elementary functions, supplemented by the principle of protection by detection and coercion, supplemented by the principle of protection by renaming, supplemented by the principle of protection by conditional connection.
  • a protection principle in addition to the protection principle by variable, its description made previously must include, to take account of its combined implementation, the modifications following:
  • This protection method according to the invention involves, as appears more precisely in FIG. 100: • first, a protection phase P during which vulnerable software 2v is modified into protected software 2p,
  • the protection phase P can be broken down into two protection sub-phases Pi and P 2 .
  • the first known as the upstream protection sub-phase Pi, is implemented independently of the vulnerable software 2v to be protected.
  • the second, called downstream protection sub-phase P 2 is dependent on the vulnerable software 2v to be protected.
  • the upstream protection sub-phases Pi and downstream P 2 can be carried out advantageously by two different people or two different teams.
  • the upstream protection sub-phase Pi can be carried out by a person or a company ensuring the development of software protection systems
  • the downstream protection sub-phase P 2 can be carried out by a person or a company ensuring the development of software to be protected.
  • upstream protection sub-phases Pi and downstream P2 can also be carried out by the same person or the same team.
  • the upstream protection sub-phase Pi involves several stages Su, ..., SU for each of which different tasks or works are to be performed.
  • the first stage of this upstream protection sub-phase Pi is called "definition stage Su”. During this Su definition stage:
  • unit 6 • it is chosen: - the type of unit 6, namely in particular a storage unit or a processing and storage unit. By way of illustration, it may be chosen as unit 6, a reader 8 of smart cards and the smart card 7 associated with the reader, - and the transfer means 12, 13 intended to be implemented respectively in the data processing system 3 and in the unit 6, during the use phase U and capable of ensuring the transfer of data between the data processing system 3 and unit 6,
  • detection means 17 to be implemented in unit 6 and making it possible to detect that at least one characteristic of software execution does not meet at least one associated criterion
  • - as a software execution characteristic capable of being monitored, a variable for measuring the use of a software functionality, - as a criterion to be respected, at least one threshold associated with each variable of measured, - and updating means making it possible to update at least one measurement variable,
  • the protection method according to the invention implements a second preferred variant of implementation of the principle of protection by detection and coercion using as characteristic a variable for measuring the execution of the software, it is also defined reloading means making it possible to credit at least one additional use for at least one software functionality monitored by a measurement variable,
  • the protection method according to the invention implements the principle of protection by detection and coercion using as a characteristic a software usage profile, it is also defined: - as an execution characteristic of software likely to be monitored, a software usage profile,
  • detection means 17 means making it possible to detect that the sequence of instructions does not correspond to that desired
  • a CIG V generated identification field in which the identification of the last instruction having rendered its result in this register is automatically stored - as detection means 17, means making it possible, during the execution of an instruction, for each operand, when the flag field CD k requires it, to control the equality between the identification field generated CIG V corresponding to the register used by this operand, and the expected identification field ClP of the origin of this operand,
  • the protection method according to the invention implements a variant of the principle of protection by renaming, it is also defined for at least one dependent function, a family of dependent functions algorithmically equivalent, but triggered by commands triggers whose famous instructions are different,
  • the protection method according to the invention implements one or other of the preferred embodiments of the variant of the principle of protection by renaming, it is also defined for at least one dependent function, a family of algorithmically equivalent dependent functions: - by concatenating a noise field with the information defining the functional part of the dependent function to be executed in unit 6,
  • the definition stage Su is followed by a stage called "construction stage S ⁇ 2 ".
  • the transfer means 12, 13 and possibly the operating means corresponding to the definitions of the definition stage Su are constructed.
  • this stage of construction S 12 it is therefore proceeded:
  • the construction stage S1 2 can be followed by a stage called "pre-personalization stage S ⁇ 3 ".
  • pre-personalization stage S ⁇ 3 At least part of the transfer means 13 and / or the operating means are loaded into at least one blank unit 60 in order to obtain at least one pre-personalized unit 66.
  • part of the operating means once transferred to a pre-personalized unit 66, is no longer directly accessible from outside this pre-personalized unit 66.
  • the transfer of the operating means in a blank unit 60 can be achieved by means of a suitable pre-personalization unit, which is described in the following description in FIG. 120.
  • a pre-personalized unit 66 consisting of a smart card 7 and its reader 8
  • the pre-personalization does not concerns only the smart card 7.
  • stage of making tools S ⁇ are made tools making it possible to help in the generation of protected software or to automate the protection of software.
  • Such tools allow:
  • conditional branch (es) whose functionality is likely to be transferred to unit 6,
  • each tool can take various forms, such as preprocessor, assembler, compiler, etc.
  • the upstream protection sub-phase Pi is followed by a downstream protection sub-phase P2 depending on the vulnerable software 2v to be protected.
  • This downstream protection sub-phase P 2 also involves several stages.
  • the first stage corresponding to the implementation of the principle of protection by variable is called “creation stage S 21 ".
  • This creation stage S 21 the choices made at the definition stage Su are used. Using these choices and possibly tools built at the stage of making S ⁇ tools, the 2p protected software is created: • by choosing from the source of the vulnerable 2vs software:
  • variable according to the invention can be applied directly during the development of new software without requiring the prior production of vulnerable software 2v. In this way, 2p protected software is obtained directly.
  • a "modification stage S22" is implemented.
  • the definitions used at the definition stage Su are used.
  • the protected software 2p is modified to allow the implementation of the protection principles according to one of the arrangements defined above.
  • the first part of execution 2pes is executed in the data processing system 3 and a second part of execution 2peu is executed in the unit 6 which also includes processing means 16 ,
  • step commands are defined so that during the execution of the protected software 2p, each step command is executed by the first part of execution 2pes and triggers in the unit 6, the execution by means of the second execution part 2 bit, of a step,
  • a scheduling of the stage commands is chosen from all the schedules allowing the execution of the protected software 2p, • and by producing:
  • this first part object 2pos being such that during the execution of the protected software 2p, the step commands are executed according to the chosen scheduling, - and a second part object 2pou of the protected software 2p, this second object part 2pou being such that, after loading in the blank unit
  • the second execution part 2peu appears by means of which the steps triggered by the first execution part 2pes are executed.
  • the protected software 2p is modified:
  • elementary commands are integrated in the source of the protected software 2ps, so that during the execution of the protected software 2p, each elementary command is executed by the first part of execution 2pes and triggers in unit 6, the execution by means of the second execution part 2peu, of an elementary function, - and a scheduling of the elementary commands is chosen from all of the schedules allowing the execution of the protected software 2p,
  • this first part object 2pos being such that during the execution of the protected software
  • this second object part 2pou being such that, after loading into the blank unit 60 and during the execution of the protected software 2p, the second part appears of execution 2peu by means of which the elementary functions triggered by the first part of execution 2pes are executed.
  • elementary commands are integrated in the source of the protected software 2ps, so that during the execution of the protected software 2p, each elementary command is executed by the first part of execution 2pes and triggers in the unit 6, the execution by means of the second execution part 2peu, of an elementary function, - and a scheduling of the elementary commands is chosen from all of the schedules allowing the execution of the protected software 2p,
  • this first part object 2pos being such that during the execution of the protected software
  • this second object part 2pou being such that, after loading into the unit 6 and during the execution of the protected software 2p, the second part appears of execution 2peu by means of which the elementary functions triggered by the first part of execution 2pes are executed.
  • the protected software 2p is modified: • by choosing as execution characteristic of software to be monitored, at minus a variable measuring the use of a software functionality,
  • the protected software 2p is modified:
  • At least one chosen measurement variable making it possible to limit the use of a functionality to which at least one additional use must be able to be credited
  • the protected software 2p is modified: "by choosing as an execution characteristic of software to monitor at least one profile software usage,
  • the 2p software is modified: • by choosing triggered commands in the source of the 2ps protected software,
  • this first object part 2pos being such that during the execution of the protected software 2p, the triggering commands with renowned instructions are executed, - and the second object part 2p or of the protected software 2p containing the operating means also implementing the recovery means 20, this second object part 2pou being such that, after loading into the unit 6 and during the execution of the protected software 2p, the identity of the dependent functions whose execution is triggered by the first part of execution 2pes is restored by means of the second execution part 2peu, and the dependent functions are executed by means of the second execution part 2peu.
  • the 2p protected software is modified:
  • the protected software 2p is modified: • by choosing, in the source of the protected software 2ps at least one series of selected conditional connections,
  • the first object part 2pos of the protected software 2p being such that during the execution of the protected software 2p, the functionality of at least one selected series of conditional connections is executed in the unit 6,
  • this second object part 2pou being such that, after loading into the unit 6 and during the 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 branches is performed.
  • the protection principles according to the invention can be applied directly during the development of new software without requiring the prior production of intermediate protected software.
  • the stages of creation S 2 ⁇ and of modification S 22 can be carried out concomitantly so as to obtain the protected software 2p directly.
  • the downstream protection sub-phase P 2 in the case where at least one other protection principle is used in addition to the protection principle by variable, it is implemented after the creation stage S2 1 of the protected software 2p , and possibly after the modification stage S 22 , a stage called "personalization stage S23".
  • the second object part 2pou possibly containing the operating means is loaded into at least one blank unit 60, with a view to obtaining at least one unit 6, or part of the second object part 2pou possibly containing the operating means is loaded into at least one pre-personalized unit 66, with a view to obtaining at least one unit 6.
  • Loading this personalization information makes it possible to make at least one unit 6 operational. note that some of this information, once transferred to a unit 6, is not directly accessible from outside this unit 6.
  • the transfer of personalization information to a blank unit 60 or a pre-personalized unit 66 can be achieved by means of a suitable personalization unit which is described in the following description in FIG. 150. In the case of a unit 6, consisting of a smart card 7 and its reader 8, the personalization only concerns the smart card 7.
  • Fig. 110 illustrates an exemplary embodiment of a system 25 making it possible to implement the construction stage S12 taking into account the definitions intervened at the definition stage Su and during which the transfer means 12, 13 and possibly the means are constructed. operating systems for unit 6.
  • a system 25 includes a program development unit or workstation conventionally in the form of a computer comprising a central unit, a screen, peripherals of the keyboard-mouse type. , and including, in particular, the following programs: file editors, assemblers, preprocessors, compilers, interpreters, debuggers and link editors.
  • Fig. 110 illustrates an exemplary embodiment of a system 25 making it possible to implement the construction stage S12 taking into account the definitions intervened at the definition stage Su and during which the transfer means 12, 13 and possibly the means are constructed. operating systems for unit 6.
  • Such a system 25 includes a program development unit or workstation conventionally in the form of a computer comprising a central unit, a screen, peripherals of the keyboard-mouse type. ,
  • FIG. 120 illustrates an exemplary embodiment of a prepersonalization unit 30 making it possible to at least partially load the transfer means 13 and / or the operating means in at least one blank unit 60 in view to obtain at least one pre-personalized unit 66.
  • This pre-personalization unit 30 includes a reading and writing means 31 making it possible to electrically pre-personalize a blank unit 60, so as to obtain a pre-personalized unit 66 in which the transfer means 13 and / or operating have been loaded.
  • the pre-personalization unit 30 can also include means for physical personalization 32 of the blank unit 60 which can be, for example, in the form of a printer. In the case where the unit 6 is constituted by a smart card 7 and its reader 8, the pre-personalization generally relates only to the smart card 7.
  • Such a system 35 comprises a program development unit or workstation conventionally in the form of a computer comprising a central unit, a screen, peripherals of the keyboard-mouse type, and comprising, in particular, the following programs: file editors, assemblers, pre-processors, compilers, interpreters, debuggers and linkers.
  • Fig. 140 illustrates an embodiment of a system 40 allowing direct creation of 2p protected software or modification of vulnerable 2v software in order to obtain 2p protected software.
  • a system 40 includes a program development unit or workstation conventionally in the form of a computer comprising a central unit, a screen, peripherals of the keyboard-mouse type, and comprising, in particular, the following programs: file editors, assemblers, pre-processors, compilers, interpreters, debuggers and linkers, as well as tools to help generate protected software or to automate software protection.
  • Fig. 150 illustrates an exemplary embodiment of a personalization unit 45 making it possible to load the second object part 2pou in at least one blank unit 60 with a view to obtaining at least one unit 6 or part of the second object part 2pou in at least a pre-personalized unit 66 with a view to obtaining at least one unit 6.
  • This personalization unit 45 comprises a reading and writing means 46 making it possible to electrically personalize at least one blank unit 60 or at least one pre-personalized unit 66, so as to obtain at least one unit 6.
  • a unit 6 includes the information necessary for the execution of the protected software 2p.
  • the personalization unit 45 can also include physical personalization means 47 for at least one unit 6 which can be, for example, in the form of a printer. In the case where a unit 6 is constituted by a smart card 7 and its reader 8, the personalization generally relates only to the smart card 7.
  • the protection method of the invention can be implemented with the following improvements: • Provision may be made for jointly using several processing and storage units in which the second object part 2p or of the protected software 2p is distributed so that their joint use allows the 2p protected software to be executed, the absence of at least one of these processing and storage units preventing the use of the 2p protected software.
  • the part of the second object part 2pou necessary to transform the pre-personalized unit 66 into a unit 6 can be contained in a unit processing and storage used by the personalization unit 45 in order to limit access to this part of the second object part 2pou.
  • this part of the second object part 2pou can be distributed in several processing and storage units so that this part of the second object part 2pou is accessible only when the processing and storage units are used together. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Storage Device Security (AREA)

Abstract

L'objet de l'invention concerne un procédé pour protéger, à partir d'au moins une unité, un logiciel vulnérable contre son utilisation non autorisée, ledit logiciel vulnérable fonctionnant sur un système de traitement de données. Le procédé consiste à créer un logiciel protégé : - en choisissant dans le source du logiciel vulnérable au moins une variable, - en produisant le source du logiciel protégé en modifiant le source du logiciel vulnérable, de sorte que la variable choisie réside dans une unité.

Description

PROCEDE POUR PROTEGER UN LOGICIEL A L'AIDE D'UN PRINCIPE DIT DE « VARIABLE » CONTRE SON UTILISATION NON AUTORISEE
La présente invention concerne le domaine technique des systèmes de traitement de données au sens général et elle vise, plus précisément, les moyens pour protéger, contre son utilisation non autorisée, un logiciel fonctionnant sur lesdits systèmes de traitement de données.
L'objet de l'invention vise, plus particulièrement, les moyens pour protéger un logiciel contre son utilisation non autorisée, à partir d'une unité de mémorisation ou d'une unité de traitement et de mémorisation, une telle unité étant communément matérialisée par une carte à puce ou par une clé matérielle sur port USB. Dans le domaine technique ci-dessus, le principal inconvénient concerne l'emploi non autorisé de logiciels par des utilisateurs n'ayant pas acquitté des droits de licence. Cette utilisation illicite de logiciels cause un préjudice manifeste pour les éditeurs de logiciels, les distributeurs de logiciels et/ou toute personne intégrant de tels logiciels dans des produits. Pour éviter de telles copies illicites, il a été proposé dans l'état de la technique, diverses solutions pour protéger des logiciels.
Ainsi, il est connu une solution de protection consistant à mettre en oeuvre un système matériel de protection, tel qu'un élément physique appelé clé de protection ou "dongle" en terminologie anglo-saxonne. Une telle clé de protection devrait garantir l'exécution du logiciel uniquement en présence de la clé. Or, il doit être constaté qu'une telle solution est inefficace car elle présente l'inconvénient d'être facilement contournable. Une personne mal intentionnée ou pirate peut, à l'aide d'outils spécialisés, tels que des désassembleurs, supprimer les instructions de contrôle de la clé de protection. Il devient alors possible de réaliser des copies illicites correspondant à des versions modifiées des logiciels n'ayant plus aucune protection. De plus, cette solution ne peut pas être généralisée à tous les logiciels, dans la mesure où il est difficile de connecter plus de deux clés de protection sur un même système.
L'objet de l'invention vise justement à remédier aux inconvénients énoncés ci- dessus en proposant un procédé pour protéger un logiciel contre son utilisation non autorisée, à partir d'une unité de mémorisation ou d'une unité de traitement et de mémorisation ad hoc, dans la mesure où la présence d'une telle unité est nécessaire pour que le logiciel soit complètement fonctionnel.
Pour atteindre un tel objectif, l'objet de l'invention concerne un procédé pour protéger, à partir d'au moins une unité vierge comportant au moins des moyens de mémorisation, un logiciel vulnérable contre son utilisation non autorisée, ledit logiciel vulnérable fonctionnant sur un système de traitement de données. Le procédé selon l'invention consiste : - dans une phase de protection :
• à créer un logiciel protégé : - en choisissant dans le source du logiciel vulnérable :
> au moins une variable qui, lors de l'exécution du logiciel vulnérable, définit partiellement l'état de celui-ci,
> et au moins une portion contenant au moins une variable choisie, - en produisant le source du logiciel protégé à partir du source du logiciel vulnérable, en modifiant au moins une portion choisie du source du logiciel vulnérable, cette modification étant telle que lors de l'exécution du logiciel protégé, au moins une variable choisie ou au moins une copie de variable choisie réside dans l'unité vierge qui se transforme ainsi en une unité, - et en produisant une première partie objet du logiciel protégé à partir du source du logiciel protégé, cette première partie objet étant telle que lors de l'exécution du logiciel protégé, apparaît une première partie d'exécution qui est exécutée dans le système de traitement de données et dont au moins une portion prend en compte qu'au moins une variable ou au moins une copie de variable réside dans l'unité,
-> et dans une phase d'utilisation au cours de laquelle est exécuté le logiciel protégé :
• en présence de l'unité, à chaque fois qu'une portion de la première partie d'exécution l'impose, à utiliser une variable ou une copie de variable résidant dans l'unité, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé est complètement fonctionnel,
• et en l'absence de l'unité, malgré la demande d'une portion de la première partie d'exécution d'utiliser une variable ou une copie de variable résidant dans l'unité, à ne pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé n'est pas complètement fonctionnel. Selon une forme préférée de réalisation, le procédé selon l'invention consiste : dans la phase de protection :
• à modifier le logiciel protégé :
- en choisissant dans le source du logiciel protégé :
> au moins un traitement algorithmique qui lors de l'exécution du logiciel protégé, utilise au moins une variable choisie, et permet d'obtenir au moins une variable résultante,
> et au moins une portion contenant au moins un traitement algorithmique choisi,
- en modifiant au moins une portion choisie du source du logiciel protégé, cette modification étant telle que :
> lors de l'exécution du logiciel protégé la première partie d'exécution est exécutée dans le système de traitement de données et une seconde partie d'exécution est exécutée dans l'unité qui comporte aussi des moyens de traitement, > au moins la fonctionnalité d'au moins un traitement algorithmique choisi est exécutée au moyen de la seconde partie d'exécution,
> au moins un traitement algorithmique choisi est décomposé de manière que lors de l'exécution du logiciel protégé, apparaissent, au moyen de la seconde partie d'exécution, plusieurs étapes distinctes, à savoir :
0 la mise à disposition d'au moins une variable pour l'unité, 0 la réalisation dans l'unité, de la fonctionnalité du traitement algorithmique sur au moins cette variable, 0 et éventuellement, la mise à disposition d'au moins une variable résultante, par l'unité pour le système de traitement de données,
> pour au moins un traitement algorithmique choisi, des commandes d'étapes sont définies de manière que lors de l'exécution du logiciel protégé, chaque commande d'étape est exécutée par la première partie d'exécution et déclenche dans l'unité, l'exécution au moyen de la seconde partie d'exécution, d'une étape, > et un ordonnancement des commandes d'étapes est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé, - et en produisant :
> la première partie objet du logiciel protégé, cette première partie objet étant telle que lors de l'exécution du logiciel protégé, les commandes d'étapes sont exécutées selon l'ordonnancement choisi,
> et une seconde partie objet du logiciel protégé, cette seconde partie objet étant telle que, après chargement dans l'unité vierge et lors de l'exécution du logiciel protégé, apparaît la seconde partie d'exécution au moyen de laquelle les étapes déclenchées par la première partie d'exécution sont exécutées,
• et à charger la seconde partie objet dans l'unité vierge, en vue d'obtenir l'unité, - et dans la phase d'utilisation :
• en présence de l'unité et à chaque fois qu'une commande d'étape contenue dans une portion de la première partie d'exécution l'impose, à exécuter l'étape correspondante dans l'unité, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé est complètement fonctionnel,
• et en l'absence de l'unité, malgré la demande d'une portion de la première partie d'exécution de déclencher l'exécution d'une étape dans l'unité, à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé n'est pas complètement fonctionnel.
Selon une autre forme préférée de réalisation, le procédé selon l'invention consiste : dans la phase de protection :
• à définir :
- un jeu de fonctions élémentaires dont les fonctions élémentaires sont susceptibles d'être exécutées dans l'unité qui comporte aussi des moyens de traitement,
- et un jeu de commandes élémentaires pour ce jeu de fonctions élémentaires, ces commandes élémentaires étant susceptibles d'être exécutées dans le système de traitement de données et de déclencher l'exécution dans l'unité, des fonctions élémentaires, • à construire des moyens d'exploitation permettant de transformer l'unité vierge en l'unité capable d'exécuter les fonctions élémentaires dudit jeu, l'exécution de ces fonctions élémentaires étant déclenchée par l'exécution dans le système de traitement de données, de commandes élémentaires,
• à modifier le logiciel protégé: - en choisissant dans le source du logiciel protégé :
> au moins un traitement algorithmique qui lors de l'exécution du logiciel protégé, utilise au moins une variable choisie, et permet d'obtenir au moins une variable résultante,
> et au moins une portion contenant au moins un traitement algorithmique choisi,
- en modifiant au moins une portion choisie du source du logiciel protégé, cette modification étant telle que :
> lors de l'exécution du logiciel protégé la première partie d'exécution est exécutée dans le système de traitement de données et une seconde partie d'exécution est exécutée dans l'unité,
> au moins la fonctionnalité d'au moins un traitement algorithmique choisi est exécutée au moyen de la seconde partie d'exécution,
> au moins un traitement algorithmique choisi est décomposé de manière que lors de l'exécution du logiciel protégé, ce traitement algorithmique est exécuté au moyen de la seconde partie d'exécution, en utilisant des fonctions élémentaires,
> pour au moins un traitement algorithmique choisi, des commandes élémentaires sont intégrées dans le source du logiciel protégé, de manière que lors de l'exécution du logiciel protégé, chaque commande élémentaire est exécutée par la première partie d'exécution et déclenche dans l'unité, l'exécution au moyen de la seconde partie d'exécution, d'une fonction élémentaire,
> et un ordonnancement des commandes élémentaires est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé,
- et en produisant : > la première partie objet du logiciel protégé, cette première partie objet étant telle que lors de l'exécution du logiciel protégé, les commandes élémentaires sont exécutées selon l'ordonnancement choisi,
> et une seconde partie objet du logiciel protégé contenant les moyens d'exploitation, cette seconde partie objet étant telle que, après chargement dans l'unité vierge et lors de l'exécution du logiciel protégé, apparaît la seconde partie d'exécution au moyen de laquelle les fonctions élémentaires déclenchées par la première partie d'exécution sont exécutées, • et à charger la seconde partie objet dans l'unité vierge, en vue d'obtenir l'unité, et dans la phase d'utilisation :
• en présence de l'unité et à chaque fois qu'une commande élémentaire contenue dans une portion de la première partie d'exécution l'impose, à exécuter la fonction élémentaire correspondante dans l'unité, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé est complètement fonctionnel,
• et en l'absence de l'unité, malgré la demande d'une portion de la première partie d'exécution, de déclencher l'exécution d'une fonction élémentaire dans l'unité, à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé n'est pas complètement fonctionnel. Selon une autre forme préférée de réalisation, le procédé selon l'invention consiste : -> dans la phase de protection :
• à définir : - un jeu de fonctions élémentaires dont les fonctions élémentaires sont susceptibles d'être exécutées dans l'unité,
- et un jeu de commandes élémentaires pour ce jeu de fonctions élémentaires, ces commandes élémentaires étant susceptibles d'être exécutées dans le système de traitement de données et de déclencher l'exécution dans l'unité, des fonctions élémentaires,
• à construire des moyens d'exploitation permettant à l'unité, d'exécuter les fonctions élémentaires dudit jeu, l'exécution de ces fonctions élémentaires étant déclenchée par l'exécution dans le système de traitement de données, de commandes élémentaires, • et à modifier le logiciel protégé:
- en choisissant dans le source du logiciel protégé, au moins une étape qui lors de l'exécution du logiciel protégé, réalise la fonctionnalité d'un traitement algorithmique,
- en modifiant au moins une portion choisie du source du logiciel protégé, cette modification étant telle que :
> au moins une étape choisie est décomposée de manière que lors de l'exécution du logiciel protégé, cette étape est exécutée au moyen de la seconde partie d'exécution, en utilisant des fonctions élémentaires, > pour au moins une étape choisie, des commandes élémentaires sont intégrées dans le source du logiciel protégé, de manière que lors de l'exécution du logiciel protégé, chaque commande élémentaire est exécutée par la première partie d'exécution et déclenche dans l'unité, l'exécution au moyen de la seconde partie d'exécution, d'une fonction élémentaire,
> et un ordonnancement des commandes élémentaires est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé,
- et en produisant :
> la première partie objet du logiciel protégé, cette première partie objet étant telle que lors de l'exécution du logiciel protégé, les commandes élémentaires sont exécutées selon l'ordonnancement choisi,
> et la seconde partie objet du logiciel protégé contenant aussi les moyens d'exploitation, cette seconde partie objet étant telle que, après chargement dans l'unité et lors de l'exécution du logiciel protégé, apparaît la seconde partie d'exécution au moyen de laquelle les fonctions élémentaires déclenchées par la première partie d'exécution sont exécutées, -> et dans la phase d'utilisation :
• en présence de l'unité et à chaque fois qu'une commande élémentaire contenue dans une portion de la première partie d'exécution l'impose, à exécuter la fonction élémentaire correspondante dans l'unité, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé est complètement fonctionnel,
• et en l'absence de l'unité, malgré la demande d'une portion de la première partie d'exécution, de déclencher l'exécution d'une fonction élémentaire dans l'unité, à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé n'est pas complètement fonctionnel. Selon une autre forme préférée de réalisation, le procédé selon l'invention consiste :
-> dans la phase de protection :
• à définir :
- au moins une caractéristique d'exécution de logiciel, susceptible d'être surveillée au moins en partie dans l'unité, - au moins un critère à respecter pour au moins une caractéristique d'exécution de logiciel,
- des moyens de détection à mettre en oeuvre dans l'unité et permettant de détecter qu'au moins une caractéristique d'exécution de logiciel ne respecte pas au moins un critère associé,
- et des moyens de coercition à mettre en oeuvre dans l'unité et permettant d'informer le système de traitement de données et/ou de modifier l'exécution d'un logiciel, lorsqu'au moins un critère n'est pas respecté,
• à construire les moyens d'exploitation permettant à l'unité, de mettre aussi en oeuvre les moyens de détection et les moyens de coercition,
• et à modifier le logiciel protégé : - en choisissant au moins une caractéristique d'exécution de logiciel à surveiller, parmi les caractéristiques d'exécution susceptibles d'être surveillées,
- en choisissant au moins un critère à respecter pour au moins une caractéristique d'exécution de logiciel choisie, - en choisissant dans le source du logiciel protégé, des fonctions élémentaires pour lesquelles au moins une caractéristique d'exécution de logiciel choisie, est à surveiller,
- en modifiant au moins une portion choisie du source du logiciel protégé, cette modification étant telle que lors de l'exécution du logiciel protégé, au moins une caractéristique d'exécution choisie est surveillée au moyen de la seconde partie d'exécution, et le non respect d'un critère aboutit à une information du système de traitement de données et/ou à une modification de l'exécution du logiciel protégé,
- et en produisant la seconde partie objet du logiciel protégé contenant les moyens d'exploitation mettant aussi en oeuvre les moyens de détection et les moyens de coercition, cette seconde partie objet étant telle que, après chargement dans l'unité et lors de l'exécution du logiciel protégé, au moins une caractéristique d'exécution de logiciel est surveillée et le non respect d'un critère aboutit à une information du système de traitement de données et/ou à une modification de l'exécution du logiciel protégé, et dans la phase d'utilisation : • en présence de l'unité :
- tant que tous les critères correspondant à toutes les caractéristiques d'exécution surveillées de toutes les portions modifiées du logiciel protégé sont respectés, à permettre le fonctionnement nominal de ces portions du logiciel protégé et par conséquent à permettre le fonctionnement nominal du logiciel protégé,
- et si au moins un des critères correspondant à une caractéristique d'exécution surveillée d'une portion du logiciel protégé n'est pas respecté, à en informer le système de traitement de données et/ou à modifier le fonctionnement de la portion du logiciel protégé, de sorte que le fonctionnement du logiciel protégé est modifié. Selon une variante de réalisation, le procédé selon l'invention consiste : -.* dans la phase de protection :
• à définir : - en tant que caractéristique d'exécution de logiciel susceptible d'être surveillée, une variable de mesure de l'utilisation d'une fonctionnalité d'un logiciel,
- en tant que critère à respecter, au moins un seuil associé à chaque variable de mesure, - et des moyens d'actualisation permettant de mettre à jour au moins une variable de mesure,
• à construire les moyens d'exploitation permettant à l'unité de mettre aussi en œuvre les moyens d'actualisation,
• et à modifier le logiciel protégé : - en choisissant en tant que caractéristique d'exécution de logiciel à surveiller, au moins une variable de mesure de l'utilisation d'une fonctionnalité d'un logiciel,
- en choisissant :
> au moins une fonctionnalité du logiciel protégé dont l'utilisation est susceptible d'être surveillée grâce à une variable de mesure,
> au moins une variable de mesure servant à quantifier l'utilisation de ladite fonctionnalité,
> au moins un seuil associé à une variable de mesure choisie correspondant à une limite d'utilisation de ladite fonctionnalité,
> et au moins une méthode de mise à jour d'une variable de mesure choisie en fonction de l'utilisation de ladite fonctionnalité,
- et en modifiant au moins une portion choisie du source du logiciel protégé, cette modification étant telle que, lors de l'exécution du logiciel protégé, la variable de mesure est actualisée au moyen de la seconde partie d'exécution, en fonction de l'utilisation de ladite fonctionnalité et au moins un dépassement de seuil est pris en compte,
-> et dans la phase d'utilisation, en présence de l'unité, et dans le cas où il est détecté au moins un dépassement de seuil correspondant à au moins une limite d'utilisation, à en informer le système de traitement de données et/ou à modifier le fonctionnement de la portion du logiciel protégé, de sorte que le fonctionnement du logiciel protégé est modifié.
Selon une variante de réalisation, le procédé selon l'invention consiste : - > dans la phase de protection :
• à définir :
- pour au moins une variable de mesure, plusieurs seuils associés, - et des moyens de coercition différents correspondant à chacun de ces seuils,
• et à modifier le logiciel protégé :
- en choisissant dans le source du logiciel protégé, au moins une variable de mesure choisie à laquelle doivent être associés plusieurs seuils correspondants à des limites différentes d'utilisation de la fonctionnalité,
- en choisissant au moins deux seuils associés à la variable de mesure choisie,
- et en modifiant au moins une portion choisie du source du logiciel protégé, cette modification étant telle que, lors de l'exécution du logiciel protégé, les dépassements des divers seuils sont pris en compte, au moyen de la seconde partie d'exécution, de manière différente, -> et dans la phase d'utilisation :
• en présence de l'unité :
- dans le cas où il est détecté le dépassement d'un premier seuil, à enjoindre le logiciel protégé de ne plus utiliser la fonctionnalité correspondante,
- et dans le cas où il est détecté le dépassement d'un deuxième seuil, à rendre inopérante la fonctionnalité correspondante et/ou au moins une portion du logiciel protégé. Selon une variante de réalisation, le procédé selon l'invention consiste :
-> dans la phase de protection :
• à définir des moyens de rechargement permettant de créditer au moins une utilisation supplémentaire pour au moins une fonctionnalité de logiciel surveillée par une variable de mesure, • à construire les moyens d'exploitation permettant aussi à l'unité de mettre en œuvre les moyens de rechargement,
• et à modifier le logiciel protégé :
- en choisissant dans le source du logiciel protégé, au moins une variable de mesure choisie permettant de limiter l'utilisation d'une fonctionnalité à laquelle au moins une utilisation supplémentaire doit pouvoir être créditée,
- et en modifiant au moins une portion choisie, cette modification étant telle que dans une phase dite de rechargement, au moins une utilisation supplémentaire d'au moins une fonctionnalité correspondant à une variable de mesure choisie peut être créditée,
-> et dans la phase de rechargement :
• à réactualiser au moins une variable de mesure choisie et/ou au moins un seuil associé, de manière à permettre au moins une utilisation supplémentaire de la fonctionnalité. Selon une variante de réalisation, le procédé selon l'invention consiste :
- dans la phase de protection : • à définir :
- en tant que caractéristique d'exécution de logiciel susceptible d'être surveillée, un profil d'utilisation de logiciel,
- et en tant que critère à respecter, au moins un trait d'exécution de logiciel,
• et à modifier le logiciel protégé :
- en choisissant en tant que caractéristique d'exécution de logiciel à surveiller au moins un profil d'utilisation de logiciel,
- en choisissant au moins un trait d'exécution qu'au moins un profil d'utilisation choisi doit respecter,
- et en modifiant au moins une portion choisie du source du logiciel protégé, cette modification étant telle que, lors de l'exécution du logiciel protégé, la seconde partie d'exécution respecte tous les traits d'exécution choisis, -> et dans la phase d'utilisation en présence de l'unité, et dans le cas où il est détecté qu'au moins un trait d'exécution n'est pas respecté, à en informer le système de traitement de données et/ou à modifier le fonctionnement de la portion du logiciel protégé, de sorte que le fonctionnement du logiciel protégé est modifié. Selon une variante de réalisation, le procédé selon l'invention consiste :
-> dans la phase de protection :
• à définir :
- un jeu d'instructions dont les instructions sont susceptibles d'être exécutées dans l'unité, - un jeu de commandes d'instructions pour ce jeu d'instructions, ces commandes d'instructions étant susceptibles d'être exécutées dans le système de traitement de données et de déclencher dans l'unité l'exécution des instructions,
- en tant que profil d'utilisation, l'enchaînement des instructions, - en tant que trait d'exécution, un enchaînement souhaité pour l'exécution des instructions, - en tant que moyens de détection, des moyens permettant de détecter que l'enchaînement des instructions ne correspond pas à celui souhaité,
- et en tant que moyens de coercition, des moyens permettant d'informer le système de traitement de données et/ou de modifier le fonctionnement de la portion de logiciel protégé lorsque l'enchaînement des instructions ne correspond pas à celui souhaité,
• à construire les moyens d'exploitation permettant aussi à l'unité d'exécuter les instructions du jeu d'instructions, l'exécution de ces instructions étant déclenchée par l'exécution dans le système de traitement de données, des commandes d' instructions,
• et à modifier le logiciel protégé :
- en modifiant au moins une portion choisie du source du logiciel protégé :
> en transformant les fonctions élémentaires en instructions, > en spécifiant l'enchaînement que doivent respecter au moins certaines des instructions lors de leur exécution dans l'unité,
> et en transformant les commandes élémentaires en commandes d'instructions correspondant aux instructions utilisées,
- et dans la phase d'utilisation, en présence de l'unité, dans le cas où il est détecté que l'enchaînement des instructions exécutées dans l'unité ne correspond pas à celui souhaité, à en informer le système de traitement de données et/ou à modifier le fonctionnement de la portion du logiciel protégé, de sorte que le fonctionnement du logiciel protégé est modifié.
Selon une variante de réalisation, le procédé selon l'invention consiste : -> dans la phase de protection :
• à définir :
- en tant que jeu d'instructions, un jeu d'instructions dont au moins certaines instructions travaillent sur des registres et utilisent au moins un opérande en vue de rendre un résultat, - pour au moins une partie des instructions travaillant sur des registres :
> une partie définissant la fonctionnalité de l'instruction,
> et une partie définissant l'enchaînement souhaité pour l'exécution des instructions et comportant des champs de bits correspondant à :
0 un champ d'identification de l'instruction, 0 et pour chaque opérande de l'instruction : * un champ drapeau,
* et un champ d'identification prévue de l'opérande,
- pour chaque registre appartenant aux moyens d'exploitation et utilisé par le jeu d'instructions, un champ d'identification générée dans lequel est automatiquement mémorisée l'identification de la dernière instruction ayant rendu son résultat dans ce registre,
- en tant que moyens de détection, des moyens permettant, lors de l'exécution d'une instruction, pour chaque opérande, lorsque le champ drapeau l'impose, de contrôler l'égalité entre le champ d'identification générée correspondant au registre utilisé par cet opérande, et le champ d'identification prévue de l'origine de cet opérande,
- et en tant que moyens de coercition, des moyens permettant de modifier le résultat des instructions, si au moins une des égalités contrôlées est fausse.
Selon une autre forme préférée de réalisation, le procédé selon l'invention consiste :
-> dans la phase de protection : • à définir :
- en tant qu'une commande déclenchante, une commande élémentaire ou une commande d'instruction, - en tant qu'une fonction dépendante, une fonction élémentaire ou une instruction,
- en tant qu'une consigne, au moins un argument pour une commande déclenchante, correspondant au moins en partie à l'information transmise par le système de traitement de données à l'unité, afin de déclencher l'exécution de la fonction dépendante correspondante,
- une méthode de renommage des consignes permettant de renommer les consignes afin d'obtenir des commandes déclenchantes à consignes renommées,
- et des moyens de rétablissement destinés à être mis en oeuvre dans l'unité au cours de la phase d'utilisation, et permettant de retrouver la fonction dépendante à exécuter, à partir de la consigne renommée,
• à construire des moyens d'exploitation permettant à l'unité de mettre aussi en oeuvre les moyens de rétablissement,
• et à modifier le logiciel protégé :
- en choisissant dans le source du logiciel protégé, des commandes déclenchantes,
- en modifiant au moins une portion choisie du source du logiciel protégé en renommant les consignes des commandes déclenchantes choisies, afin de dissimuler l'identité des fonctions dépendantes correspondantes, - et en produisant :
> la première partie objet du logiciel protégé, cette première partie objet étant telle que lors de l'exécution du logiciel protégé, les commandes déclenchantes à consignes renommées sont exécutées,
> et la seconde partie objet du logiciel protégé contenant les moyens d'exploitation mettant aussi en oeuvre les moyens de rétablissement, cette seconde partie objet étant telle que, après chargement dans l'unité et lors de l'exécution du logiciel protégé, l'identité des fonctions dépendantes dont l'exécution est déclenchée par la première partie d'exécution est rétablie au moyen de la seconde partie d'exécution, et les fonctions dépendantes sont exécutées au moyen de la seconde partie d'exécution, et dans la phase d'utilisation :
• en présence de l'unité et à chaque fois qu'une commande déclenchante à consigne renommée, contenue dans une portion de la première partie d'exécution l'impose, à rétablir dans l'unité, l'identité de la fonction dépendante correspondante et à exécuter celle-ci, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé est complètement fonctionnel,
• et en l'absence de l'unité, malgré la demande d'une portion de la première partie d'exécution, de déclencher l'exécution d'une fonction dépendante dans l'unité, à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé n'est pas complètement fonctionnel. Selon une variante de réalisation, le procédé selon l'invention consiste : -> dans la phase de protection : « à définir pour au moins une fonction dépendante, une famille de fonctions dépendantes algorithmiquement équivalentes, mais déclenchées par des commandes déclenchantes dont les consignes renommées sont différentes,
• et à modifier le logiciel protégé :
- en choisissant dans le source du logiciel protégé au moins une commande déclenchante à consigne renommée,
- et en modifiant au moins une portion choisie du source du logiciel protégé en remplaçant au moins la consigne renommée d'une commande déclenchante à consigne renommée choisie, par une autre consigne renommée, déclenchant une fonction dépendante de la même famille.
Selon une variante de réalisation, le procédé selon l'invention consiste : -> dans la phase de protection, à définir, pour au moins une fonction dépendante, une famille de fonctions dépendantes algorithmiquement équivalentes :
- en concaténant un champ de bruit à l'information définissant la partie fonctionnelle de la fonction dépendante à exécuter dans l'unité,
- ou en utilisant le champ d'identification de l'instruction et les champs d'identification prévue des opérandes.
Selon une variante de réalisation, le procédé selon l'invention consiste : - dans la phase de protection : • à définir :
- en tant que méthode de renommage des consignes, une méthode de chiffrement pour chiffrer les consignes,
- et en tant que moyens de rétablissement, des moyens mettant en oeuvre une méthode de déchiffrement pour déchiffrer les consignes renommées et rétablir ainsi l'identité des fonctions dépendantes à exécuter dans l'unité.
Selon une autre forme préférée de réalisation, le procédé selon l'invention consiste : -> dans la phase de protection :
• à modifier le logiciel protégé : - en choisissant dans le source du logiciel protégé, au moins un branchement conditionnel effectué dans au moins un traitement algorithmique choisi,
- en modifiant au moins une portion choisie du source du logiciel protégé, cette modification étant telle que lors de l'exécution du logiciel protégé, la fonctionnalité d'au moins un branchement conditionnel choisi, est exécutée, au moyen de la seconde partie d'exécution, dans l'unité,
- et en produisant :
> la première partie objet du logiciel protégé, cette première partie objet étant telle que lors de l'exécution du logiciel protégé, la fonctionnalité d'au moins un branchement conditionnel choisi est exécutée dans l'unité,
> et la seconde partie objet du logiciel protégé, cette seconde partie objet étant telle que, après chargement dans l'unité et lors de l'exécution du logiciel protégé, apparaît la seconde partie d'exécution au moyen de laquelle la fonctionnalité d'au moins un branchement conditionnel choisi est exécutée, -> et dans la phase d'utilisation :
• en présence de l'unité et à chaque fois qu'une portion de la première partie d'exécution l'impose, à exécuter la fonctionnalité d'au moins un branchement conditionnel dans l'unité, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé est complètement fonctionnel, • et en l'absence de l'unité et malgré la demande d'une portion de la première partie d'exécution d'exécuter la fonctionnalité d'un branchement conditionnel dans l'unité, à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que par conséquent, le logiciel protégé n'est pas complètement fonctionnel. Selon une variante de réalisation, le procédé selon l'invention consiste, dans la phase de protection, à modifier le logiciel protégé : - en choisissant, dans le source du logiciel protégé au moins une série de branchements conditionnels choisis,
- en modifiant au moins une portion choisie du source du logiciel protégé, cette modification étant telle que lors de l'exécution du logiciel protégé, la fonctionnalité globale d'au moins une série choisie de branchements conditionnels est exécutée au moyen de la seconde partie d'exécution, dans l'unité,
- et en produisant :
> la première partie objet du logiciel protégé, cette première partie objet étant telle que lors de l'exécution du logiciel protégé, la fonctionnalité d'au moins une série choisie de branchements conditionnels est exécutée dans l'unité,
> et la seconde partie objet du logiciel protégé, cette seconde partie objet étant telle que, après chargement dans l'unité et lors de l'exécution du logiciel protégé, apparaît la seconde partie d'exécution au moyen de laquelle la fonctionnalité globale d'au moins une série choisie de branchements conditionnels est exécutée.
Le procédé selon l'invention permet ainsi de protéger l'utilisation d'un logiciel par la mise en oeuvre d'une unité de mémorisation qui présente la particularité de contenir une partie du logiciel en cours d'exécution. Il s'ensuit que toute version dérivée du logiciel tentant de fonctionner sans l'unité de mémorisation impose de recréer la partie du logiciel contenue dans l'unité de mémorisation lors de l'exécution, sous peine que cette version dérivée du logiciel ne soit pas complètement fonctionnelle.
Diverses autres caractéristiques ressortent de la description faite ci-dessous en référence aux dessins annexés qui montrent, à titre d'exemples non limitatifs, des formes de réalisation et de mise en oeuvre de l'objet de l'invention.
Les fig. 10 et 11 sont des schémas blocs fonctionnels illustrant les diverses représentations d'un logiciel respectivement non protégé et protégé par le procédé conforme à l'invention.
Les fig. 20 à 22 illustrent à titre d'exemples, diverses formes de réalisation d'un dispositif de mise en oeuvre du procédé conforme à l'invention.
Les fig. 30 et 31 sont des schémas blocs fonctionnels explicitant le principe général du procédé conforme à l'invention.
Les fig. 40 à 43 sont des schémas illustrant le procédé de protection selon l'invention mettant en oeuvre le principe de protection par variable. Les fig. 50 à 54 sont des schémas illustrant le procédé de protection selon l'invention mettant en oeuvre le principe de protection par dissociation temporelle.
Les fig. 60 à 64 sont des schémas illustrant le procédé de protection selon l'invention mettant en oeuvre le principe de protection par fonctions élémentaires.
Les fig. 70 à 74 sont des schémas illustrant le procédé de protection selon l'invention mettant en oeuvre le principe de protection par détection et coercition.
Les fig. 80 à 85 sont des schémas illustrant le procédé de protection selon l'invention mettant en oeuvre le principe de protection par renommage.
Les fig. 90 à 92 sont des schémas illustrant le procédé de protection selon l'invention mettant en oeuvre le principe de protection par branchement conditionnel. La fig. 100 est un schéma illustrant les différentes phases de mise en oeuvre de l'objet de l'invention.
La fig. 110 illustre un exemple de réalisation d'un système permettant la mise en oeuvre du stade de construction de la phase de protection conforme à l'invention.
La fig. 120 illustre un exemple de réalisation d'une unité de pré-personnalisation utilisée dans le procédé de protection conforme à l'invention.
La fig. 130 illustre un exemple de réalisation d'un système permettant la mise en oeuvre du stade de confection d'outils de la phase de protection conforme à l'invention.
La fig. 140 illustre un exemple de réalisation d'un système permettant la mise en oeuvre du procédé de protection selon l'invention.
La fig. 150 illustre un exemple de réalisation d'une unité de personnalisation utilisée dans le procédé de protection conforme à l'invention.
Dans la suite de la description, les définitions suivantes seront utilisées :
• Un système de traitement de données 3 est un système capable d'exécuter un programme.
• Une unité de mémorisation est une unité capable d'accepter des données fournies par un système de traitement de données 3, de stocker les données et de les restituer à la demande du système de traitement de données 3.
• Une unité de traitement et de mémorisation est une unité capable :
- d'accepter des données fournies par un système de traitement de données 3, - de restituer des données au système de traitement de données 3,
- de stocker des données au moins en partie de manière secrète et de conserver au moins une partie de celles-ci même lorsque l'unité est hors tension,
- et d'effectuer du traitement algorithmique sur des données, une partie ou la totalité de ce traitement étant secret.
• Une unité 6 est une unité de mémorisation ou une unité de traitement et de mémorisation mettant en oeuvre le procédé selon l'invention.
• Une unité vierge 60 est une unité qui ne met pas en oeuvre le procédé selon l'invention, mais qui peut recevoir des informations la transformant en une unité 6.
• Une unité vierge 60 peut éventuellement devenir une unité 6 lors de l'exécution d'un logiciel protégé par le procédé selon l'invention et redevenir après exécution, une unité vierge 60.
• Une unité pré-personnalisée 66 est une unité vierge 60 ayant reçue une partie des informations lui permettant, après réception d'informations complémentaires, d'être transformée en une unité 6. • Le chargement d'informations dans une unité vierge 60 ou une unité prépersonnalisée 66 correspond à un transfert d'informations dans l'unité vierge 60 ou l'unité pré-personnalisée 66, et à un stockage desdites informations transférées. Eventuellement, le transfert peut comporter un changement de format des informations.
• Une variable, une donnée ou une fonction contenue dans le système de traitement de données 3 sera indiquée par une majuscule, tandis qu'une variable, une donnée ou une fonction contenue dans l'unité 6 sera indiquée par une minuscule. • Un "logiciel protégé", est un logiciel ayant été protégé par au moins un principe de protection mis en oeuvre par le procédé conforme à l'invention.
• Un "logiciel vulnérable", est un logiciel n'ayant été protégé par aucun principe de protection mis en oeuvre par le procédé conforme à l'invention.
• Dans le cas où la différenciation entre un logiciel vulnérable et un logiciel protégé n'a pas d'importance, le terme "logiciel" est utilisé.
• Un logiciel se présente sous diverses représentations selon l'instant considéré dans son cycle de vie :
- une représentation source,
- une représentation objet, - une distribution,
- ou une représentation dynamique.
• Une représentation source d'un logiciel est comprise comme une représentation qui après transformation, donne une représentation objet. Une représentation source peut se présenter selon différents niveaux, d'un niveau conceptuel abstrait à un niveau exécutable directement par un système de traitement de données ou une unité de traitement et de mémorisation.
• Une représentation objet d'un logiciel correspond à un niveau de représentation qui après transfert dans une distribution puis chargement dans un système de traitement de données ou une unité de traitement et de mémorisation, peut être exécuté. Il peut s'agir, par exemple, d'un code binaire, d'un code interprété, etc.
• Une distribution est un support physique ou virtuel contenant la représentation objet, cette distribution devant être mise à disposition de l'utilisateur pour lui permettre d'utiliser le logiciel. • Une représentation dynamique correspond à l'exécution du logiciel à partir de sa distribution.
• Une portion de logiciel correspond à une partie quelconque de logiciel et peut, par exemple correspondre, à une ou plusieurs instructions consécutives ou non, et/ou à un ou plusieurs blocs fonctionnels consécutifs ou non, et/ou à une ou plusieurs fonctions, et/ou un ou plusieurs sous programmes, et/ou un ou plusieurs modules. Une portion d'un logiciel peut correspondre aussi à la totalité de ce logiciel.
Les fig. 10 et 11 illustrent les diverses représentations respectivement d'un logiciel vulnérable 2v au sens général, et d'un logiciel protégé 2p selon le procédé conforme à l'invention.
La fig. 10 illustre diverses représentations d'un logiciel vulnérable 2v apparaissant au cours de son cycle de vie. Le logiciel vulnérable 2v peut ainsi apparaître sous l'une des représentations suivantes :
• une représentation source 2vs, • une représentation objet 2vo,
• une distribution 2vd. Cette distribution peut se présenter communément sous la forme d'un moyen de distribution physique tel qu'un CDROM ou sous la forme de fichiers distribués à travers un réseau (GSM, Internet, ...),
• ou d'une représentation dynamique 2ve correspondant à l'exécution du logiciel vulnérable 2v sur un système de traitement de données 3 de tous types connus, qui comporte de manière classique, au moins un processeur 4. La fig. 11 illustre diverses représentations d'un logiciel protégé 2p apparaissant au cours de son cycle de vie. Le logiciel protégé 2p peut ainsi apparaître sous l'une des représentations suivantes :
• une représentation source 2ps comportant une première partie source destinée au système de traitement de données 3 et éventuellement, une seconde partie source destinée à l'unité 6, une partie de ces parties source pouvant communément être contenue dans des fichiers communs,
• une représentation objet 2po comportant une première partie objet 2pos destinée au système de traitement de données 3 et éventuellement, une seconde partie objet 2pou destinée à l'unité 6,
• une distribution 2pd comportant :
- une première partie de distribution 2pds contenant la première partie objet 2pos, cette première partie de distribution 2pds étant destinée au système de traitement de données 3 et pouvant se présenter communément sous la forme d'un moyen de distribution physique tel qu'un CDROM, ou sous la forme de fichiers distribués à travers un réseau (GSM, Internet, ...),
- et une seconde partie de distribution 2pdu se présentant sous la forme : > d'au moins une unité vierge 60,
> ou d'au moins une unité pré-personnalisée 66 sur laquelle une partie de la seconde partie objet 2pou a été chargée et pour laquelle l'utilisateur doit terminer la personnalisation en chargeant des informations complémentaires, afin d'obtenir une unité 6, ces informations complémentaires étant obtenues, par exemple, par chargement ou téléchargement à travers un réseau,
> ou d'au moins une unité 6 sur laquelle la seconde partie objet 2pou a été chargée,
• ou une représentation dynamique 2pe correspondant à l'exécution du logiciel protégé 2p. Cette représentation dynamique 2pe comporte une première partie d'exécution 2pes qui est exécutée dans le système de traitement de données 3 et une seconde partie d'exécution 2peu qui est exécutée dans l'unité 6.
Dans le cas où la différenciation entre les différentes représentations du logiciel protégé 2p n'a pas d'importance, les expressions première partie du logiciel protégé et deuxième partie du logiciel protégé sont utilisées. La mise en oeuvre du procédé selon l'invention conformément à la représentation dynamique de la fig. 11, utilise un dispositif lp comportant un système de traitement de données 3 relié par une liaison 5 à une unité 6. Le système de traitement de données 3 est de tous types et comporte, de manière classique, au moins un processeur 4. Le système de traitement de données 3 peut être un ordinateur ou faire partie, par exemple, de diverses machines, dispositifs, produits fixes ou mobiles, ou véhicules au sens général. La liaison 5 peut être réalisée de toute manière possible, telle que par exemple par une ligne série, un bus USB, une liaison radio, une liaison optique, une liaison réseau ou une connexion électrique directe sur un circuit du système de traitement de données 3, etc. Il est à noter que l'unité 6 peut éventuellement se trouver physiquement à l'intérieur du même circuit intégré que le processeur 4 du système de traitement de données 3. Dans ce cas, l'unité 6 peut être considérée comme un coprocesseur par rapport au processeur 4 du système de traitement de données 3 et la liaison 5 est interne au circuit intégré. Les fig. 20 à 22 montrent de manière illustrative et à titre non limitatif, diverses formes de réalisation du dispositif lp permettant la mise en oeuvre du procédé de protection conforme à l'invention.
Dans l'exemple de réalisation illustré à la fig. 20, le dispositif de protection lp comporte, en tant que système de traitement de données 3, un ordinateur et, en tant qu'unité 6, une carte à puce 7 et son interface 8 communément appelé lecteur de carte. L'ordinateur 3 est relié à l'unité 6 par une liaison 5. Lors de l'exécution d'un logiciel protégé 2p, la première partie d'exécution 2pes qui est exécutée dans l'ordinateur 3 et la seconde partie d'exécution 2peu qui est exécutée dans la carte à puce 7 et son interface 8, doivent toutes les deux être fonctionnelles afin que le logiciel protégé 2p soit complètement fonctionnel.
Dans l'exemple de réalisation illustré à la fig. 21, le dispositif de protection lp équipe un produit 9 au sens général, comportant divers organes 10 adaptés à la ou les fonctions assumées par un tel produit 9. Le dispositif de protection lp comporte, d'une part, un système de traitement de données 3 embarqué dans le produit 9 et, d'autre part, une unité 6 associée au produit 9. Pour que le produit 9 soit entièrement fonctionnel, le logiciel protégé 2p doit être complètement fonctionnel. Ainsi, lors de l'exécution du logiciel protégé 2p, la première partie d'exécution 2pes qui est exécutée dans le système de traitement de données 3 et la seconde partie d'exécution 2peu qui est exécutée dans l'unité 6, doivent toutes les deux être fonctionnelles. Ce logiciel protégé 2p permet donc de manière indirecte, de protéger contre une utilisation non autorisée, le produit 9 ou l'une de ses fonctionnalités. Par exemple, le produit 9 peut être une installation, un système, une machine, un jouet, un appareil électroménager, un téléphone, etc..
Dans l'exemple de réalisation illustré à la fig. 22, le dispositif de protection lp inclut plusieurs ordinateurs, ainsi qu'une partie d'un réseau de communication. Le système de traitement de données 3 est un premier ordinateur relié par une liaison 5 de type réseau, à une unité 6 constituée par un deuxième ordinateur. Pour la mise en oeuvre de l'invention, le deuxième ordinateur 6 est utilisé comme un serveur de licences pour un logiciel protégé 2p. Lors de l'exécution du logiciel protégé 2p, la première partie d'exécution 2pes qui est exécutée dans le premier ordinateur 3 et la seconde partie d'exécution 2peu qui est exécutée dans le deuxième ordinateur 6, doivent toutes les deux être fonctionnelles afin que le logiciel protégé 2p soit complètement fonctionnel.
La fig. 30 permet d'expliciter de manière plus précise, le procédé de protection conforme à l'invention. Il est à noter qu'un logiciel vulnérable 2v est considéré comme étant exécuté totalement dans un système de traitement de données 3. Par contre, dans le cas de la mise en oeuvre d'un logiciel protégé 2p, le système de traitement de données 3 comporte des moyens de transfert 12 reliés par la liaison 5, à des moyens de transfert 13 faisant partie de l'unité 6 permettant de faire communiquer entre elles, la première partie d'exécution 2pes et la seconde partie d'exécution 2peu du logiciel protégé 2p. II doit être considéré que les moyens de transfert 12, 13 sont de nature logicielle et/ou matérielle et sont aptes à assurer et, éventuellement, à optimiser la communication des données entre le système de traitement de données 3 et l'unité 6. Ces moyens de transfert 12, 13 sont adaptés pour permettre de disposer d'un logiciel protégé 2p qui est, de préférence, indépendant du type de la liaison 5 utilisée. Ces moyens de transfert 12, 13 ne font pas partie de l'objet de l'invention et ne sont pas décrits plus précisément car ils sont bien connus de l'Homme de l'art. La première partie du logiciel protégé 2p comporte des commandes. Lors de l'exécution du logiciel protégé 2p, l'exécution de ces commandes par la première partie d'exécution 2pes permet la communication entre la première partie d'exécution 2pes et la seconde partie d'exécution 2peu. Dans la suite de la description, ces commandes sont représentées par IN, OUT ou TRIG. Tel qu'illustré à la fig. 31, pour permettre la mise en oeuvre de la seconde partie d'exécution 2peu du logiciel protégé 2p, l'unité 6 comporte des moyens de protection 14. Dans le cas où l'unité 6 est une unité de mémorisation, les moyens de protection 14 comportent des moyens de mémorisation 15. Dans le cas où l'unité 6 est une unité de traitement et de mémorisation, les moyens de protection 14 comportent des moyens de mémorisation 15 et des moyens de traitement 16.
Par souci de simplification dans la suite de la description, il est choisi de considérer, lors de l'exécution du logiciel protégé 2p, la présence de l'unité 6 ou l'absence de l'unité 6. En réalité, une unité 6 présentant des moyens de protection 14 inadaptés à l'exécution de la seconde partie d'exécution 2peu du logiciel protégé 2p est aussi considérée comme absente, à chaque fois que l'exécution du logiciel protégé 2p n'est pas correct. En d'autres termes :
• une unité 6 physiquement présente et comportant des moyens de protection 14 adaptés à l'exécution de la seconde partie d'exécution 2peu du logiciel protégé 2p, est toujours considérée comme présente, • une unité 6 physiquement présente mais comportant des moyens de protection 14 inadaptés, c'est-à-dire ne permettant pas la mise en oeuvre correcte de la seconde partie d'exécution 2peu du logiciel protégé 2p est considérée comme présente, lorsqu'elle fonctionne correctement, et comme absente lorsqu'elle ne fonctionne pas correctement, • et une unité 6 physiquement absente est toujours considérée comme absente.
Dans le cas où l'unité 6 est constituée par une carte à puce 7 et son interface 8, les moyens de transfert 13 sont décomposés en deux parties dont l'une se trouve sur l'interface 8 et dont l'autre se trouve sur la carte à puce 7. Dans cet exemple de réalisation, l'absence de la carte à puce 7 est considérée comme équivalente à l'absence de l'unité 6. En d'autres termes, en l'absence de la carte à puce 7 et/ou de son interface 8, les moyens de protection 14 ne sont pas accessibles et ne permettent donc pas l'exécution de la seconde partie d'exécution 2peu du logiciel protégé, de sorte que le logiciel protégé 2p n'est pas complètement fonctionnel.
Conformément à l'invention, le procédé de protection vise à mettre en oeuvre un principe de protection dit par "variable" dont une description est effectuée en relation des fig. 40 à 43.
Pour la mise en oeuvre du principe de protection par variable, il est choisi dans le source du logiciel vulnérable 2vs au moins une variable qui lors de l'exécution du logiciel vulnérable 2v, définit partiellement l'état de celui-ci. Par état d'un logiciel, il doit être compris l'ensemble des informations, à un instant donné, nécessaires à l'exécution complète de ce logiciel, de sorte que l'absence d'une telle variable choisie nuit à l'exécution complète de ce logiciel. Il est aussi choisi au moins une portion du source du logiciel vulnérable 2vs contenant au moins une variable choisie.
Au moins une portion choisie du source du logiciel vulnérable 2vs est alors modifié, de manière à obtenir le source du logiciel protégé 2ps. Cette modification est telle que lors de l'exécution du logiciel protégé 2p, au moins une portion de la première partie d'exécution 2pes qui est exécutée dans le système de traitement de données 3, prend en compte qu'au moins une variable choisie ou au moins une copie de variable choisie réside dans l'unité 6. Pour la mise en oeuvre du principe de protection par variable, l'unité 6 comporte au moins des moyens de mémorisation 15. La fig. 40 illustre un exemple d'exécution d'un logiciel vulnérable 2v. Dans cet exemple, il apparaît au cours de l'exécution du logiciel vulnérable 2v dans le système de traitement de données 3 :
• à l'instant ti, l'affectation de la donnée X à la variable Ni, représentée par Nι<- X, • à l'instant t2, l'affectation de la valeur de la variable Ni à la variable Y, représentée par Y <— Ni,
• et à l'instant t3, l'affectation de la valeur de la variable Ni à la variable Z, représentée par Z <- Nx.
La fig. 41 illustre un exemple d'une première forme de mise en oeuvre de l'invention pour laquelle la variable réside dans l'unité 6. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p , et en présence de l'unité 6, il apparaît :
• à l'instant ti, l'exécution d'une commande de transfert déclenchant le transfert de la donnée X depuis le système de traitement de données 3 vers la variable vi située dans les moyens de mémorisation 15 de l'unité 6, cette commande de transfert étant représentée par OUT(vι, X) et correspondant au final à l'affectation de la donnée X à la variable vi,
• à l'instant t2, l'exécution d'une commande de transfert déclenchant le transfert de la valeur de la variable vi résidant dans l'unité 6 vers le système de traitement de données 3 afin de l'affecter à la variable Y, cette commande de transfert étant représentée par IN(vι) et correspondant au final à l'affectation de la valeur de la variable i à la variable Y,
• et à l'instant t_, l'exécution d'une commande de transfert déclenchant le transfert de la valeur de la variable vi résidant dans l'unité 6 vers le système de traitement de données 3 afin de l'affecter à la variable Z, cette commande de transfert étant représentée par IN(vι) et correspondant au final à l'affectation de la valeur de la variable i à la variable Z.
Il est à noter que lors de l'exécution du logiciel protégé 2p, au moins une variable réside dans l'unité 6. Ainsi, lorsqu'une portion de la première partie d'exécution 2pes du logiciel protégé 2p l'impose, et en présence de l'unité 6, la valeur de cette variable résidant dans l'unité 6 est transférée vers le système de traitement de données 3 pour être utilisée par la première partie d'exécution 2pes du logiciel protégé 2p, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé 2p est complètement fonctionnel.
La fig. 42 illustre un exemple d'une deuxième forme de mise en oeuvre de l'invention pour laquelle une copie de la variable réside dans l'unité 6. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p, et en présence de l'unité 6, il apparaît :
• à l'instant ti, l'affectation de la donnée X à la variable Vi située dans le système de traitement de données 3, ainsi que l'exécution d'une commande de transfert déclenchant le transfert de la donnée X depuis le système de traitement de données 3 vers la variable vi située dans les moyens de mémorisation 15 de l'unité 6, cette commande de transfert étant représentée par OUT(vι, X),
• à l'instant t2, l'affectation de la valeur de la variable Vi à la variable Y, • et à l'instant t3, l'exécution d'une commande de transfert déclenchant le transfert de la valeur de la variable i résidant dans l'unité 6 vers le système de données 3 afin de l'affecter à la variable Z, cette commande de transfert étant représentée par IN(vι).
Il est à noter que lors de l'exécution du logiciel protégé 2p, au moins une copie d'une variable réside dans l'unité 6. Ainsi, lorsqu'une portion de la première partie d'exécution 2pes du logiciel protégé 2p l'impose, et en présence de l'unité 6, la valeur de cette copie de variable résidant dans l'unité 6 est transférée vers le système de traitement de données 3 pour être utilisée par la première partie d'exécution 2pes du logiciel protégé 2p, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé 2p est complètement fonctionnel.
La fig. 43 illustre un exemple de tentative d'exécution du logiciel protégé 2p, alors que l'unité 6 est absente. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé
2p : • à l'instant ti, l'exécution de la commande de transfert OUT(vι, X) ne peut pas déclencher le transfert de la donnée X vers la variable vi, compte tenu de l'absence de l'unité 6,
• à l'instant t2, l'exécution de la commande de transfert IN(vι) ne peut pas déclencher le transfert de la valeur de la variable i vers le système de traitement de données 3, compte tenu de l'absence de l'unité 6,
• et à l'instant t3, l'exécution de la commande de transfert IN(vι) ne peut pas déclencher le transfert de la valeur de la variable i vers le système de traitement de données 3, compte tenu de l'absence de l'unité 6.
Il apparaît donc qu'en l'absence de l'unité 6, au moins une demande d'une portion de la première partie d'exécution 2pes d'utiliser une variable ou une copie de variable résidant dans l'unité 6, ne peut pas être satisfaite correctement, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé 2p n'est pas complètement fonctionnel.
Il est à noter que les transferts de données entre le système de traitement de données 3 et l'unité 6 illustrés dans les exemples qui précèdent n'utilisent que des affectations simples mais que l'Homme de l'Art saura les combiner avec d'autres opérations pour aboutir à des opérations complexes telles que par exemple OUT(vl,
2 * X + 3) ou bien Z <- (5 * vl + v2).
Selon une autre caractéristique avantageuse de l'invention, le procédé de protection vise à mettre en oeuvre un principe de protection, dit par "dissociation temporelle", dont une description est effectuée en relation des fig. 50 à 54.
Pour la mise en oeuvre du principe de protection par dissociation temporelle, il est choisi, dans le source du logiciel vulnérable 2vs, au moins un traitement algorithmique utilisant au moins un opérande et rendant au moins un résultat. Il est aussi choisi au moins une portion du source du logiciel vulnérable 2vs contenant au moins un traitement algorithmique choisi.
Au moins une portion choisie du source du logiciel vulnérable 2vs est alors modifiée, de manière à obtenir le source du logiciel protégé 2ps. Cette modification est telle que notamment :
• lors de l'exécution du logiciel protégé 2p, au moins une portion de la première partie d'exécution 2pes, qui est exécutée dans le système de traitement de données 3, prend en compte que la fonctionnalité d'au moins un traitement algorithmique choisi est exécutée dans l'unité 6,
• lors de l'exécution du logiciel protégé 2p, la seconde partie d'exécution 2peu, qui est exécutée dans l'unité 6, exécute au moins la fonctionnalité d'au moins un traitement algorithmique choisi,
• lors de l'exécution du logiciel protégé 2p, chaque traitement algorithmique choisi est décomposé en plusieurs étapes distinctes, à savoir : étape 1 : la mise à disposition du ou des opérandes pour l'unité 6, étape 2 : la réalisation dans l'unité 6, de la fonctionnalité du traitement algorithmique choisi utilisant ce ou ces opérandes, et étape 3 : éventuellement, la mise à disposition par l'unité 6 pour le système de traitement de données 3, du résultat du traitement algorithmique choisi,
• des commandes d'étapes sont définies pour déclencher l'exécution des étapes, • et un ordonnancement des commandes d'étapes est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé 2p.
La première partie d'exécution 2pes du logiciel protégé 2p, qui est exécutée dans le système de traitement de données 3, exécute les commandes d'étapes, déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, de chacune des étapes précédemment définies. Pour la mise en oeuvre du principe de protection par dissociation temporelle, l'unité 6 comporte des moyens de mémorisation 15 et des moyens de traitement 16.
La fig. 50 illustre un exemple d'exécution d'un logiciel vulnérable 2v. Dans cet exemple, il apparaît, au cours de l'exécution du logiciel vulnérable 2v, dans le système de traitement de données 3, à un instant donné, le calcul de Z — F(X, Y) correspondant à l'affectation à une variable Z, du résultat d'un traitement algorithmique représenté par une fonction F et utilisant des opérandes X et Y.
La fig. 51 illustre un exemple de mise en oeuvre de l'invention pour lequel le traitement algorithmique choisi à la fig. 50 est déporté dans l'unité 6. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p et en présence de l'unité 6, il apparaît :
• à l'instant ti, l'étape 1, à savoir l'exécution d'une commande d'étape CEi déclenchant le transfert des données X et Y depuis le système de traitement de données 3 vers des zones de mémorisation respectivement x et y situées dans les moyens de mémorisation 15 de l'unité 6, cette commande d'étape CEi étant représentée par OUT(x, X), OUT(y, Y),
• à l'instant t2, l'étape 2, à savoir l'exécution d'une commande d'étape CE2, déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, de la fonction f, cette fonction f étant algorithmiquement équivalente à la fonction F et cette commande d'étape CE2 étant représentée par TRIG(f). Plus précisément, l'exécution de la commande d'étape CE2 conduit à l'exécution de la fonction f qui se sert du contenu des zones de mémorisation x et y et rend son résultat dans une zone de mémorisation z de l'unité 6, • et à l'instant t3, l'étape 3, à savoir l'exécution d'une commande d'étape CE3 déclenchant le transfert du résultat de la fonction f, contenu dans la zone de mémorisation z de l'unité 6 vers le système de traitement de données 3 afin de l'affecter à la variable Z, cette commande d'étape CE3 étant représentée par IN(z). Dans l'exemple illustré, les étapes 1 à 3 sont exécutées successivement. Il est à noter que deux améliorations peuvent être apportées :
• La première amélioration concerne le cas où plusieurs traitements algorithmiques sont déportés dans l'unité 6 et au moins le résultat d'un traitement algorithmique est utilisé par un autre traitement algorithmique. Dans ce cas, certaines étapes de transfert peuvent être éventuellement supprimées.
• La deuxième amélioration vise à opter pour un ordonnancement pertinent des commandes d'étapes parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé 2p. A cet égard, il est préférable de choisir un ordonnancement des commandes d'étapes qui dissocie temporellement l'exécution des étapes, en intercalant, entre celles-ci des portions de code exécuté dans le système de traitement de données 3 et comportant ou non des commandes d'étapes servant à la détermination d'autres données. Les fig. 52 et 53 illustrent le principe d'une telle réalisation. La fig. 52 montre un exemple d'exécution d'un logiciel vulnérable 2v. Dans cet exemple, il apparaît, au cours de l'exécution du logiciel vulnérable 2v, dans le système de traitement de données 3, l'exécution de deux traitement algorithmiques aboutissant à la détermination de Z et Z', telles que Z <- F (X, Y) et Z' - F' (X',
Y'). La fig. 53 illustre un exemple de mise en oeuvre du procédé selon l'invention pour lequel les deux traitements algorithmiques choisis à la fig. 52 sont déportés dans l'unité 6. Selon un tel exemple, lors de l'exécution dans le système de traitement de données 3, de la première partie d'exécution 2pes du logiciel protégé 2p, et en présence de l'unité 6, il apparaît, comme expliqué ci-dessus, l'exécution des commandes d'étapes CEi, CE2, CE3 correspondant à la détermination de Z et des commandes d'étapes CE'i, CE'2, CE'3 correspondant à la détermination de Z'. Comme illustré, les commandes d'étapes CEi à CE3 ne sont pas exécutées consécutivement dans la mesure où des commandes d'étapes CE'i à CE'3, ainsi que d'autres portions de code sont intercalées. Dans l'exemple, il est ainsi réalisé l'ordonnancement suivant : CEi, portion de code intercalé, CE2, portion de code intercalé, CE'i, portion de code intercalé, CE'2, portion de code intercalé, CE'3, portion de code intercalé, CE3.
Il est à noter que, lors de l'exécution du logiciel protégé 2p, en présence de l'unité 6, à chaque fois qu'une commande d'étape contenue dans une portion de la première partie d'exécution 2pes du logiciel protégé 2p l'impose, l'étape correspondante est exécutée dans l'unité 6. Ainsi, il apparaît, qu'en présence de l'unité 6, cette portion est exécutée correctement et que, par conséquent, le logiciel protégé 2p est complètement fonctionnel.
La fig. 54 illustre un exemple de tentative d'exécution du logiciel protégé 2p, alors que l'unité 6 est absente. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p :
• à l'instant ti, l'exécution de la commande d'étape OUT(x, X), OUT(y, Y) ne peut pas déclencher le transfert des données X et Y vers les zones de mémorisation respectives x et y compte tenu de l'absence de l'unité 6,
• à l'instant t2, l'exécution de la commande d'étape TRIG(f) ne peut déclencher l'exécution de la fonction f, compte tenu de l'absence de l'unité
6,
• et à l'instant t3, l'exécution de la commande d'étape IN(z) ne peut pas déclencher le transfert du résultat de la fonction f, compte tenu de l'absence de l'unité 6. II apparaît donc qu'en l'absence de l'unité 6, au moins une demande d'une portion de la première partie d'exécution 2pes de déclencher l'exécution d'une étape dans l'unité 6, ne peut pas être satisfaite correctement, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé 2p n'est pas complètement fonctionnel.
Selon une autre caractéristique avantageuse de l'invention, le procédé de protection vise à mettre en œuvre un principe de protection, dit par "fonctions élémentaires", dont une description est effectuée en relation des fig. 60 à 64.
Pour la mise en oeuvre du principe de protection par fonctions élémentaires, il est défini :
• un jeu de fonctions élémentaires dont les fonctions élémentaires sont susceptibles d'être exécutées, au moyen de la seconde partie d'exécution
2peu, dans l'unité 6, et éventuellement de transférer des données entre le système de traitement de données 3 et l'unité 6,
• et un jeu de commandes élémentaires pour ce jeu de fonctions élémentaires, ces commandes élémentaires étant susceptibles d'être exécutées dans le système de traitement de données 3 et de déclencher l'exécution dans l'unité
6, des fonctions élémentaires correspondantes.
Pour la mise en oeuvre du principe de protection par fonctions élémentaires, il est aussi construit des moyens d'exploitation permettant de transformer une unité vierge 60 contenant des moyens de mémorisation 15 et des moyens de traitement 16 en une unité 6 capable d'exécuter les fonctions élémentaires, l'exécution de ces fonctions élémentaires étant déclenchée par l'exécution dans le système de traitement de données 3, de commandes élémentaires.
Pour la mise en œuvre du principe de protection par fonctions élémentaires, il est aussi choisi, dans le source du logiciel vulnérable 2vs, au moins un traitement algorithmique utilisant au moins un opérande et rendant au moins un résultat. Il est aussi choisi au moins une portion du source du logiciel vulnérable 2vs contenant au moins un traitement algorithmique choisi.
Au moins une portion choisie du source du logiciel vulnérable 2vs est alors modifiée, de manière à obtenir le source du logiciel protégé 2ps. Cette modification est telle que notamment :
• lors de l'exécution du logiciel protégé 2p, au moins une portion de la première partie d'exécution 2pes, qui est exécutée dans le système de traitement de données 3, prend en compte que la fonctionnalité d'au moins un traitement algorithmique choisi est exécutée dans l'unité 6,
• lors de l'exécution du logiciel protégé 2p, la seconde partie d'exécution 2peu, qui est exécutée dans l'unité 6, exécute au moins la fonctionnalité d'au moins un traitement algorithmique choisi,
• chaque traitement algorithmique choisi est décomposé de manière que lors de l'exécution du logiciel protégé 2p, chaque traitement algorithmique choisi est exécuté, au moyen de la seconde partie d'exécution 2peu, en utilisant des fonctions élémentaires. De préférence, chaque traitement algorithmique choisi est décomposé en fonctions élémentaires fe„ (avec n variant de 1 à N), à savoir :
- éventuellement une ou plusieurs fonctions élémentaires permettant la mise à disposition d'un ou de plusieurs opérandes pour l'unité 6,
- des fonctions élémentaires dont certaines utilisent la ou les opérandes et qui en combinaison, exécutent la fonctionnalité du traitement algorithmique choisi, utilisant ce ou ces opérandes,
- et éventuellement une ou plusieurs fonctions élémentaires permettant la mise à disposition par l'unité 6, pour le système de traitement de données 3 du résultat du traitement algorithmique choisi, • et un ordonnancement des commandes élémentaires est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé
2p.
La première partie d'exécution 2pes du logiciel protégé 2p, qui est exécutée dans le système de traitement de données 3, exécute des commandes élémentaires CFE„ (avec n variant de 1 à N), déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, de chacune des fonctions élémentaires fen précédemment définies.
La fig. 60 illustre un exemple d'exécution d'un logiciel vulnérable 2v. Dans cet exemple, il apparaît, au cours de l'exécution du logiciel vulnérable 2v dans le système de traitement de données 3, à un instant donné, le calcul de Z <- F(X, Y) correspondant à l'affectation à une variable Z du résultat d'un traitement algorithmique représenté par une fonction F et utilisant des opérandes X et Y.
La fig. 61 illustre un exemple de mise en oeuvre de l'invention pour lequel le traitement algorithmique choisi à la fig. 60 est déporté dans l'unité 6. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p et en présence de l'unité 6, il apparaît :
• aux instants ti, t2, l'exécution des commandes élémentaires CFEi, CFE2 déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, des fonctions élémentaires fei, fe2 correspondantes qui assurent le transfert des données X, Y depuis le système de traitement de données 3 vers des zones de mémorisation respectivement x, y situées dans les moyens de mémorisation 15 de l'unité 6, ces commandes élémentaires CFEi, CFE2 étant représentées respectivement par OUT(x, X), OUT(y, Y),
• aux instants t3 à t]y-ι, l'exécution des commandes élémentaires CFE3 à CFEN-I, déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, des fonctions élémentaires fe3 à fβN-i correspondantes, ces commandes élémentaires CFE3 à CFEN_I étant représentées, respectivement, par TRIG(fe3) à TRIG(feN-ι). La suite des fonctions élémentaires fe3 à fβ -i exécutées en combinaison est algorithmiquement équivalente à la fonction F. Plus précisément, l'exécution de ces commandes élémentaires conduit à l'exécution dans l'unité 6, des fonctions élémentaires fe3 à fβ -i qui se servent du contenu des zones de mémorisation x, y et rendent le résultat dans une zone de mémorisation z de l'unité 6, • et à l'instant tN, l'exécution d'une commande élémentaire CFEN déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, de la fonction élémentaire fβ assurant le transfert du résultat du traitement algorithmique, contenu dans la zone de mémorisation z de l'unité 6 vers le système de traitement de données 3, afin de l'affecter à la variable Z, cette commande élémentaire CFEN étant représentée par IN(z).
Dans l'exemple illustré, les commandes élémentaires 1 à N sont exécutées successivement. Il est à noter que deux améliorations peuvent être apportées : • La première amélioration concerne le cas où plusieurs traitements algorithmiques sont déportés dans l'unité 6 et au moins le résultat d'un traitement algorithmique est utilisé par un autre traitement algorithmique. Dans ce cas, certaines commandes élémentaires servant au transfert, peuvent être éventuellement supprimées.
• La deuxième amélioration vise à opter pour un ordonnancement pertinent des commandes élémentaires parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé 2p. A cet égard, il est préférable de choisir un ordonnancement des commandes élémentaires qui dissocie temporellement l'exécution des fonctions élémentaires, en intercalant, entre celles-ci des portions de code exécuté dans le système de traitement de données 3 et comportant ou non des commandes élémentaires servant à la détermination d'autres données. Les fig. 62 et 63 illustrent le principe d'une telle réalisation. La fig. 62 montre un exemple d'exécution d'un logiciel vulnérable 2v. Dans cet exemple, il apparaît au cours de l'exécution du logiciel vulnérable 2v, dans le système de traitement de données 3, l'exécution de deux traitements algorithmiques aboutissant à la détermination de Z et Z', telles que Z - F (X, Y) et Z' <-F'(X', Y').
La fig. 63 illustre un exemple de mise en œuvre du procédé selon l'invention pour lequel les deux traitements algorithmiques choisis à la fig. 62 sont déportés dans l'unité 6. Selon un tel exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p et en présence de l'unité 6, il apparaît, comme expliqué ci-dessus, l'exécution des commandes élémentaires CFEi à CFEN correspondant à la détermination de Z et l'exécution des commandes élémentaires CFE'i à CFE M correspondant à la détermination de Z'. Comme illustré, les commandes élémentaires CFEi à CFEN ne sont pas exécutées consécutivement, dans la mesure où les commandes élémentaires
CFE'i à CFE'M, ainsi que d'autres portions de code sont intercalées. Dans l'exemple il est ainsi réalisé l'ordonnancement suivant : CFEi, portion de code intercalé, CFE'i, CFE2, portion de code intercalé, CFE'2, CFE'3, portion de code intercalé,
CFE'4, CFE3, CFE4, ..., CFEN, CFE'M.
Il est à noter que, lors de l'exécution du logiciel protégé 2p, en présence de l'unité 6, à chaque fois qu'une commande élémentaire contenue dans une portion de la première partie d'exécution 2pes du logiciel protégé 2p l'impose, la fonction élémentaire correspondante est exécutée dans l'unité 6. Ainsi, il apparaît, qu'en présence de l'unité 6, cette portion est exécutée correctement et que, par conséquent, le logiciel protégé 2p est complètement fonctionnel.
La fig. 64 illustre un exemple de tentative d'exécution du logiciel protégé 2p, alors que l'unité 6 est absente. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3, de la première partie d'exécution 2pes du logiciel protégé 2p, à tous les instants, l'exécution d'une commande élémentaire ne peut pas déclencher l'exécution de la fonction élémentaire correspondante, en raison de l'absence de l'unité 6. La valeur à affecter à la variable Z ne peut donc pas être déterminée correctement.
Il apparaît donc, qu'en l'absence de l'unité 6, au moins une demande d'une portion de la première partie d'exécution 2pes du logiciel protégé 2p, de déclencher l'exécution d'une fonction élémentaire dans l'unité 6 ne peut pas être satisfaite correctement, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé 2p n'est pas complètement fonctionnel.
Selon une autre caractéristique avantageuse de l'invention, le procédé de protection vise à mettre en œuvre un principe de protection, dit par "détection et coercition", dont une description est effectuée en relation des fig. 70 à 74.
Pour la mise en œuvre du principe de protection par détection et coercition, il est défini :
• au moins une caractéristique d'exécution de logiciel susceptible d'être surveillée au moins en partie dans l'unité 6, • au moins un critère à respecter pour au moins une caractéristique d'exécution de logiciel,
• des moyens de détection 17 à mettre en oeuvre dans l'unité 6 et permettant de détecter qu'au moins une caractéristique d'exécution de logiciel ne respecte pas au moins un critère associé, • et des moyens de coercition 18 à mettre en oeuvre dans l'unité 6 et permettant d'informer le système de traitement de données 3 et/ou de modifier l'exécution d'un logiciel, lorsqu'au moins un critère n'est pas respecté.
Pour la mise en oeuvre du principe de protection par détection et coercition, il est aussi construit des moyens d'exploitation permettant de transformer une unité vierge 60 contenant des moyens de mémorisation 15 et des moyens de traitement 16 en une unité 6 mettant au moins en oeuvre les moyens de détection 17 et les moyens de coercition 18.
La fig. 70 illustre les moyens nécessaires à la mise en oeuvre de ce principe de protection par détection et coercition. L'unité 6 comporte les moyens de détection 17 et les moyens de coercition 18 appartenant aux moyens de traitement 16. Les moyens de coercition 18 sont informés du non respect d'un critère par les moyens de détection 17.
D'une manière plus précise, les moyens de détection 17 utilisent des informations en provenance des moyens de transfert 13 et/ou des moyens de mémorisation 15 et/ou des moyens de traitement 16, afin de surveiller une ou plusieurs caractéristiques d'exécution de logiciel. A chaque caractéristique d'exécution de logiciel est fixé au moins un critère à respecter.
Dans le cas où il est détecté qu'au moins une caractéristique d'exécution de logiciel ne respecte pas au moins un critère, les moyens de détection 17 en informent les moyens de coercition 18. Ces moyens de coercition 18 sont adaptés pour modifier, de la manière appropriée, l'état de l'unité 6.
Pour la mise en oeuvre du principe de protection par détection et coercition, il est aussi choisi :
• au moins une caractéristique d'exécution de logiciel à surveiller, parmi les caractéristiques d'exécution susceptibles d'être surveillées, • au moins un critère à respecter pour au moins une caractéristique d'exécution de logiciel choisie,
• dans le source du logiciel vulnérable 2vs, au moins un traitement algorithmique pour lequel au moins une caractéristique d'exécution de logiciel est à surveiller, • et dans le source du logiciel vulnérable 2vs, au moins une portion contenant au moins un traitement algorithmique choisi. Au moins une portion choisie du source du logiciel vulnérable 2vs est ensuite modifiée, de manière à obtenir le source du logiciel protégé 2ps. Cette modification est telle que notamment lors de l'exécution du logiciel protégé 2p :
• au moins une portion de la première partie d'exécution 2pes, qui est exécutée dans le système de traitement de données 3, prend en compte qu'au moins une caractéristique d'exécution de logiciel choisie est à surveiller, au moins en partie dans l'unité 6,
• et la seconde partie d'exécution 2peu, qui est exécutée dans l'unité 6, surveille au moins en partie, une caractéristique d'exécution de logiciel choisie. Lors de l'exécution du logiciel protégé 2p, protégé par ce principe de protection par détection et coercition, en présence de l'unité 6 :
• tant que tous les critères correspondants à toutes les caractéristiques d'exécution surveillées de toutes les portions modifiées du logiciel protégé 2p sont respectés, ces portions modifiées du logiciel protégé 2p fonctionnent de manière nominale et, par conséquent, le logiciel protégé 2p fonctionne de manière nominale,
• et si au moins un des critères correspondant à une caractéristique d'exécution surveillée d'une portion du logiciel protégé 2p n'est pas respecté, le système de traitement de données 3 en est informé et/ou le fonctionnement de la portion du logiciel protégé 2p est modifié, de sorte que le fonctionnement du logiciel protégé 2p est modifié.
Bien entendu, en l'absence de l'unité 6, au moins une demande d'une portion de la première partie d'exécution 2pes du logiciel protégé 2p d'utiliser l'unité 6 ne peut pas être satisfaite correctement de sorte qu'au moins cette portion ne s'exécute pas correctement et que par conséquent le logiciel protégé 2p n'est pas complètement fonctionnel.
Pour la mise en oeuvre du principe de protection par détection et coercition, deux types de caractéristiques d'exécution de logiciel sont utilisées préférentiellement. Le premier type de caractéristique d'exécution de logiciel correspond à une variable de mesure de l'exécution d'un logiciel et le second type correspond à un profil d'utilisation d'un logiciel. Ces deux types de caractéristiques peuvent être utilisées indépendamment ou en combinaison.
Pour la mise en oeuvre du principe de protection par détection et coercition utilisant, comme caractéristique d'exécution, une variable de mesure de l'exécution de logiciel, il est défini : • dans les moyens de mémorisation 15, la possibilité de mémoriser au moins une variable de mesure servant à quantifier l'utilisation d'au moins une fonctionnalité de logiciel,
• dans les moyens de détection 17, la possibilité de surveiller au moins un seuil associé à chaque variable de mesure, « et des moyens d'actualisation permettant de mettre à jour chaque variable de mesure en fonction de l'utilisation de la fonctionnalité à laquelle elle est associée. Il est aussi construit des moyens d'exploitation mettant en oeuvre, en plus des moyens de détection 17 et des moyens de coercition 18, les moyens d'actualisation. II est aussi choisi, dans le source du logiciel vulnérable 2vs :
• au moins une fonctionnalité du logiciel vulnérable 2v dont l'utilisation est susceptible d'être surveillée grâce à une variable de mesure,
• au moins une variable de mesure servant à quantifier l'utilisation de ladite fonctionnalité, • au moins un seuil associé à la variable de mesure correspondant à une limite d'utilisation de ladite fonctionnalité,
• et au moins une méthode de mise à jour de la variable de mesure en fonction de l'utilisation de ladite fonctionnalité.
Le source du logiciel vulnérable 2vs est ensuite modifiée, de manière à obtenir le source du logiciel protégé 2ps, cette modification étant telle que, lors de l'exécution du logiciel protégé 2p, la seconde partie d'exécution 2peu :
• actualise la variable de mesure en fonction de l'utilisation de ladite fonctionnalité,
• et prend en compte au moins un dépassement de seuil. En d'autres termes, lors de l'exécution du logiciel protégé 2p, la variable de mesure est mise à jour en fonction de l'utilisation de ladite fonctionnalité, et lorsque le seuil est dépassé, les moyens de détection 17 en informent les moyens de coercition 18 qui prennent une décision adaptée pour informer le système de traitement de données 3 et/ou modifier les traitements effectués par les moyens de traitement 16 permettant de modifier le fonctionnement de la portion du logiciel protégé 2p, de sorte que le fonctionnement du logiciel protégé 2p est modifié.
Pour la mise en oeuvre d'une première variante préférée de réalisation du principe de protection par détection et coercition utilisant, comme caractéristique, une variable de mesure, il est défini :
• pour au moins une variable de mesure, plusieurs seuils associés, « et des moyens de coercition différents correspondant à chacun de ces seuils.
Il est aussi choisi, dans le source du logiciel vulnérable 2vs :
• au moins une variable de mesure servant à quantifier l'utilisation d'au moins une fonctionnalité du logiciel et à laquelle doivent être associés plusieurs seuils correspondant à des limites différentes d'utilisation de ladite fonctionnalité,
• et au moins deux seuils associés à la variable de mesure.
Le source du logiciel vulnérable 2vs est ensuite modifié, de manière à obtenir le source du logiciel protégé 2ps, cette modification étant telle que, lors de l'exécution du logiciel protégé 2p, la seconde partie d'exécution 2peu : • actualise la variable de mesure en fonction de l'utilisation de ladite fonctionnalité,
• et prend en compte, de manière différente, les dépassements des divers seuils.
En d'autres termes, de manière classique, lors de l'exécution du logiciel protégé 2p, lorsque le premier seuil est dépassé, l'unité 6 informe le système de traitement de données 3 enjoignant le logiciel protégé 2p de ne plus utiliser cette fonctionnalité. Si le logiciel protégé 2p continue d'utiliser cette fonctionnalité, le second seuil pourra être dépassé. Dans le cas où le second seuil est dépassé, les moyens de coercition 18 peuvent rendre inopérante la fonctionnalité choisie et/ou rendre inopérant le logiciel protégé 2p.
Pour la mise en oeuvre d'une deuxième variante préférée de réalisation du principe de protection par détection et coercition utilisant, comme caractéristique, une variable de mesure, il est défini des moyens de rechargement permettant de créditer au moins une utilisation supplémentaire pour au moins une fonctionnalité de logiciel surveillée par une variable de mesure. II est aussi construit des moyens d'exploitation mettant en oeuvre, en plus des moyens de détection 17, des moyens de coercition 18 et des moyens d'actualisation, les moyens de rechargement.
Il est aussi choisi, dans le source du logiciel vulnérable 2vs, au moins une variable de mesure servant à limiter l'utilisation d'au moins une fonctionnalité du logiciel et à laquelle au moins une utilisation supplémentaire doit pouvoir être créditée.
Le source du logiciel vulnérable 2vs est ensuite modifié, de manière à obtenir le source du logiciel protégé 2ps, cette modification étant telle que, dans une phase dite de rechargement, au moins une utilisation supplémentaire d'au moins une fonctionnalité correspondant à une variable de mesure choisie peut être créditée.
Il est procédé, dans la phase de rechargement, à la réactualisation d'au moins une variable de mesure choisie et/ou d'au moins un seuil associé, de manière à permettre au moins une utilisation supplémentaire de la fonctionnalité correspondante. En d'autres termes, il est possible, dans la phase de rechargement, de créditer des utilisations supplémentaires d'au moins une fonctionnalité du logiciel protégé 2p.
Pour la mise en oeuvre du principe de protection par détection et coercition utilisant, comme caractéristique, un profil d'utilisation de logiciel, il est défini en tant que critère à respecter pour ce profil d'utilisation, au moins un trait d'exécution de logiciel.
Il est aussi choisi, dans le source du logiciel vulnérable 2vs :
• au moins un profil d'utilisation à surveiller,
• et au moins un trait d'exécution qu'au moins un profil d'utilisation choisi doit respecter. Le source du logiciel vulnérable 2 s est ensuite modifié, de manière à obtenir le source du logiciel protégé 2ps, cette modification étant telle que, lors de l'exécution du logiciel protégé 2p, la seconde partie d'exécution 2peu respecte tous les traits d'exécution choisis. En d'autres termes, l'unité 6 surveille elle-même la manière dont la seconde partie d'exécution 2peu est exécutée et peut informer le système de traitement de données 3 et/ou modifier le fonctionnement du logiciel protégé 2p, dans le cas où au moins un trait d'exécution n'est pas respecté. Lors de l'exécution du logiciel protégé 2p, protégé par ce principe, en présence de l'unité 6 :
• tant que tous les traits d'exécution de toutes les portions modifiées du logiciel protégé 2p sont respectés, ces portions modifiées du logiciel protégé 2p fonctionnent de manière nominale et, par conséquent, le logiciel protégé 2p fonctionne de manière nominale,
• et si au moins un trait d'exécution d'une portion de logiciel protégé 2p n'est pas respecté, le système de traitement de données 3 en est informé et/ou le fonctionnement de la portion du logiciel protégé 2p est modifié, de sorte que le fonctionnement du logiciel protégé 2p est modifié. II peut être envisagé la surveillance de différents traits d'exécution, comme par exemple la surveillance de la présence d'instructions comportant un marqueur ou la surveillance de l'enchaînement d'exécution pour au moins une partie des instructions.
Pour la mise en oeuvre du principe de protection par détection et coercition utilisant comme trait d'exécution à respecter, la surveillance de l'enchaînement d'exécution pour au moins une partie des instructions, il est défini :
• un jeu d'instructions dont les instructions sont susceptibles d'être exécutées dans l'unité 6,
• un jeu de commandes d'instruction pour ce jeu d'instructions, ces commandes d'instructions sont susceptibles d'être exécutées dans le système de traitement de données 3. L'exécution de chacune de ces commandes d'instructions dans le système de traitement de données 3 déclenche dans l'unité 6, l'exécution de l'instruction correspondante,
• des moyens de détection 17 permettant de détecter que l'enchaînement des instructions ne correspond pas à celui souhaité, • et des moyens de coercition 18 permettant d'informer le système de traitement de données 3 et/ou de modifier l'exécution d'un logiciel lorsque l'enchaînement des instructions ne correspond pas à celui souhaité. Il est aussi construit des moyens d'exploitation permettant, à l'unité 6, d'exécuter aussi les instructions du jeu d'instructions, l'exécution de ces instructions étant déclenchée par l'exécution dans le système de traitement de données 3 des commandes d'instructions.
Il est aussi choisi, dans le source du logiciel vulnérable 2vs, au moins un traitement algorithmique devant être déporté dans l'unité 6 et pour lequel l'enchaînement d'au moins une partie des instructions est à surveiller.
Le source du logiciel vulnérable 2vs est ensuite modifié de manière à obtenir le source du logiciel protégé 2ps, cette modification est telle que, lors de l'exécution du logiciel protégé 2p :
• la seconde partie d'exécution 2peu exécute au moins la fonctionnalité du traitement algorithmique choisi,
• le traitement algorithmique choisi est décomposé en instructions, • l'enchaînement que doivent respecter au moins certaines des instructions lors de leur exécution dans l'unité 6 est spécifié,
• et la première partie d'exécution 2pes du logiciel protégé 2p exécute des commandes d'instructions qui déclenchent l'exécution des instructions dans l'unité 6. Lors de l'exécution du logiciel protégé 2p, protégé par ce principe, en présence de l'unité 6 :
• tant que l'enchaînement des instructions de toutes les portions modifiées du logiciel protégé 2p correspond à celui souhaité, ces portions modifiées du logiciel protégé 2p fonctionnent de manière nominale et, par conséquent, le logiciel protégé 2p fonctionne de manière nominale,
• et si l'enchaînement des instructions d'une portion de logiciel protégé 2p exécutées dans l'unité 6 ne correspond pas à celui souhaité, le système de traitement de données 3 en est informé et/ou le fonctionnement de la portion du logiciel protégé 2p est modifié, de sorte que le fonctionnement du logiciel protégé 2p est modifié.
La fig. 71 illustre un exemple de mise en oeuvre du principe de protection par détection et coercition utilisant, comme trait d'exécution à respecter la surveillance de l'enchaînement d'exécution d'au moins une partie des instructions, dans le cas où l'enchaînement souhaité est respecté.
La première partie d'exécution 2pes du logiciel protégé 2p, exécutée dans le système de traitement de données 3, exécute des commandes d'instructions CI, déclenchant, dans l'unité 6 l'exécution des instructions ij appartenant au jeu d'instructions. Dans le jeu d'instructions, au moins certaines des instructions comportent chacune une partie définissant la fonctionnalité de l'instruction et une partie permettant de vérifier l'enchaînement souhaité pour l'exécution des instructions. Dans cet exemple, les commandes d'instructions Cli sont représentées par TRIG(ii) et l'enchaînement souhaité pour l'exécution des instructions est i„, in+ι et in+ 2. L'exécution dans l'unité 6, de l'instruction in donne le résultat a et l'exécution de l'instruction i„+ι donne le résultat b. L'instruction i„+2 utilise comme opérande, les résultats a et b des instructions i„ et i„+ι et son exécution donne le résultat c. Compte tenu que cet enchaînement des instructions exécutées dans l'unité 6 correspond à celui souhaité, il en résulte un fonctionnement normal ou nominal du logiciel protégé 2p.
La fig. 72 illustre un exemple de mise en oeuvre du principe de protection par détection et coercition utilisant, comme trait d'exécution à respecter, la surveillance de l'enchaînement d'exécution d'au moins une partie des instructions, dans le cas où l'enchaînement souhaité n'est pas respecté.
Selon cet exemple, l'enchaînement souhaité pour l'exécution des instructions est toujours in, in+ι et in+2- Toutefois, l'enchaînement d'exécution des instructions est modifié par le remplacement de l'instruction i„ par l'instruction i'n, de sorte que l'enchaînement effectivement exécuté est i'n, in+ι et in+2- L'exécution de l'instruction i'„ donne le résultat a, c'est-à-dire le même résultat que l'exécution de l'instruction in. Toutefois, au plus tard lors de l'exécution de l'instruction in+2, les moyens de détection 17 détectent que l'instruction i'„ ne correspond pas à l'instruction souhaitée pour générer le résultat a utilisé comme opérande de l'instruction in+2. Les moyens de détection 17 en informent les moyens de coercition 18 qui modifient en conséquence, le fonctionnement de l'instruction in+2, de sorte que l'exécution de l'instruction in+2 donne le résultat c' pouvant être différent de c. Bien entendu, si l'exécution de l'instruction i'„ donne un résultat a' différent du résultat a de l'instruction in, il est clair que le résultat de l'instruction in+2 peut aussi être différent de c.
Dans la mesure où l'enchaînement d'exécution des instructions exécutées dans l'unité 6 ne correspond pas à celui souhaité, il peut donc être obtenu une modification du fonctionnement du logiciel protégé 2p.
Les fig. 73 et 74 illustrent une variante préférée de réalisation du principe de protection par détection et coercition utilisant, comme trait d'exécution à respecter, la surveillance de l'enchaînement d'exécution d'au moins une partie des instructions. Selon cette variante préférée, il est défini un jeu d'instructions dont au moins certaines instructions travaillent sur des registres et utilisent au moins un opérande en vue de rendre un résultat.
Comme illustré à la fig. 73, il est défini pour au moins certaines des instructions travaillant sur des registres, une partie PF définissant la fonctionnalité de l'instruction et une partie PE définissant l'enchaînement souhaité pour l'exécution des instructions. La partie PF correspond au code opération connu de l'Homme de l'art. La partie PE définissant l'enchaînement souhaité, comporte des champs de bits correspondant à :
• un champ d'identification de l'instruction Cil,
• et pour chaque opérande k de l'instruction, avec k variant de 1 à K, et K nombre d'opérandes de l'instruction :
- un champ drapeau CDk, indiquant s'il convient de vérifier la provenance de l'opérande k,
- et un champ d'identification prévue ClPk de l'opérande, indiquant l'identité attendue de l'instruction ayant généré le contenu de l'opérande k.
Comme illustré à la fig. 74, le jeu d'instructions comporte V registres appartenant aux moyens de traitement 16, chaque registre étant nommé Rv, avec v variant de 1 à V. Pour chaque registre Rv, il est défini deux champs, à savoir :
• un champ fonctionnel CFV, connu de l'Homme de l'art et permettant de stocker le résultat de l'exécution des instructions,
• et un champ d'identification générée CIGV permettant de mémoriser l'identité de l'instruction ayant généré le contenu du champ fonctionnel
CFV. Ce champ d'identification générée CIGV est mis à jour automatiquement avec le contenu du champ d'identification de l'instruction
Cil ayant généré le champ fonctionnel CFV. Ce champ d'identification générée CIGV n'est pas accessible, ni modifiable par aucune instruction et sert uniquement aux moyens de détection 17.
Lors de l'exécution d'une instruction, les moyens de détection 17 effectuent pour chaque opérande k les opérations suivantes :
• le champ drapeau CDk est lu, • si le champ drapeau CDk l'impose, le champ d'identification prévue ClPk et le champ d'identification générée CIGV correspondant au registre utilisé par l'opérande k sont lus tous les deux,
• l'égalité des deux champs ClPk et CIGV est contrôlée,
• et si l'égalité est fausse, les moyens de détection 17 considèrent que l'enchaînement d'exécution des instructions n'est pas respecté.
Les moyens de coercition 18 permettent de modifier le résultat des instructions lorsque les moyens de détection 17 les ont informés d'un enchaînement d'instructions non respecté. Une réalisation préférentielle consiste à modifier la partie fonctionnelle
PF de l'instruction en cours d'exécution ou la partie fonctionnelle PF d'instructions ultérieures.
Selon une autre caractéristique avantageuse de l'invention, le procédé de protection vise à mettre en œuvre un principe de protection, dit par "renommage" dont une description est effectuée en relation des fig. 80 à 85.
Pour la mise en œuvre du principe de protection par renommage, il est défini : • un ensemble de fonctions dépendantes, dont les fonctions dépendantes sont susceptibles d'être exécutées, au moyen de la seconde partie d'exécution 2peu, dans l'unité 6, et éventuellement de transférer des données entre le système de traitement de données 3 et l'unité 6, cet ensemble de fonctions dépendantes pouvant être fini ou infini, « un ensemble de commandes déclenchantes pour ces fonctions dépendantes, ces commandes déclenchantes étant susceptibles d'être exécutées dans le système de traitement de données 3 et de déclencher dans l'unité 6, l'exécution de fonctions dépendantes correspondantes,
• pour chaque commande déclenchante, une consigne correspondant au moins en partie à l'information transmise par la première partie d'exécution 2pes, à la seconde partie d'exécution 2peu, afin de déclencher l'exécution de la fonction dépendante correspondante, cette consigne se présentant sous la forme d'au moins un argument de la commande déclenchante,
• une méthode de renommage des consignes destinée à être mise en oeuvre lors de la modification du logiciel vulnérable, une telle méthode permettant de renommer les consignes afin d'obtenir des commandes déclenchantes à consignes renommées permettant de dissimuler l'identité des fonctions dépendantes correspondantes,
• et des moyens de rétablissement 20 destinés à être mis en oeuvre dans l'unité 6 lors de la phase d'utilisation et permettant de retrouver la consigne initiale, à partir de la consigne renommée, afin de retrouver la fonction dépendante à exécuter.
Pour la mise en oeuvre du principe de protection par renommage, il est aussi construit des moyens d'exploitation permettant de transformer une unité vierge 60 contenant des moyens de mémorisation 15 et des moyens de traitement 16 en une unité 6 mettant au moins en oeuvre les moyens de rétablissement 20.
Pour la mise en oeuvre du principe de protection par renommage, il est aussi choisi, dans le source du logiciel vulnérable 2vs :
• au moins un traitement algorithmique utilisant au moins un opérande et rendant au moins un résultat, • et au moins une portion du source du logiciel vulnérable 2vs, contenant au moins un traitement algorithmique choisi. Le source du logiciel vulnérable 2vs est ensuite modifié, de manière à obtenir le source du logiciel protégé 2ps. Cette modification est telle que notamment :
• lors de l'exécution du logiciel protégé 2p, au moins une portion de la première partie d'exécution 2pes, qui est exécutée dans le système de traitement de données 3, prend en compte que la fonctionnalité d'au moins un traitement algorithmique choisi est exécutée dans l'unité 6,
• lors de l'exécution du logiciel protégé 2p, la seconde partie d'exécution 2peu, qui est exécutée dans l'unité 6, exécute au moins la fonctionnalité d'au moins un traitement algorithmique choisi, • chaque traitement algorithmique choisi est décomposé de manière que lors de l'exécution du logiciel protégé 2p, chaque traitement algorithmique choisi est exécuté, au moyen de la seconde partie d'exécution 2peu, en utilisant des fonctions dépendantes. De préférence, chaque traitement algorithmique choisi est décomposé en fonctions dépendantes fdn (avec n variant de 1 à N), à savoir :
- éventuellement une ou plusieurs fonctions dépendantes permettant la mise à disposition d'un ou de plusieurs opérandes pour l'unité 6,
- des fonctions dépendantes dont certaines utilisent la ou les opérandes et qui en combinaison, exécutent la fonctionnalité du traitement algorithmique choisi, utilisant ce ou ces opérandes,
- et éventuellement une ou plusieurs fonctions dépendantes permettant la mise à disposition par l'unité 6, pour le système de traitement de données 3 du résultat du traitement algorithmique choisi,
• lors de l'exécution du logiciel protégé 2p, la seconde partie d'exécution 2peu exécute les fonctions dépendantes fdn,
• lors de l'exécution du logiciel protégé 2p, les fonctions dépendantes sont déclenchées par des commandes déclenchantes à consignes renommées,
• et un ordonnancement des commandes déclenchantes est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé 2p.
La première partie d'exécution 2pes du logiciel protégé 2p, exécutée dans le système de traitement de données 3, exécute des commandes déclenchantes à consignes renommées transférant vers l'unité 6 des consignes renommées, et déclenchant dans l'unité 6 le rétablissement au moyen des moyens de rétablissement 20, des consignes, puis l'exécution au moyen de la seconde partie d'exécution 2peu, de chacune des fonctions dépendantes fdπ précédemment définies. En d'autres termes, le principe de protection par renommage consiste à renommer les consignes des commandes déclenchantes, de manière à obtenir des commandes déclenchantes à consignes renommées dont l'exécution dans le système de traitement de données 3, déclenche dans l'unité 6, l'exécution des fonctions dépendantes qui auraient été déclenchées par les commandes déclenchantes à consignes non renommées, sans toutefois que l'examen du logiciel protégé 2p ne permette de déterminer l'identité des fonctions dépendantes exécutées.
La fig. 80 illustre un exemple d'exécution d'un logiciel vulnérable 2v. Dans cet exemple, il apparaît au cours de l'exécution du logiciel vulnérable 2v dans le système de traitement de données 3, à un instant donné, le calcul de Z f- F(X, Y) correspondant à l'affectation à une variable Z du résultat d'un traitement algorithmique représenté par une fonction F et utilisant les opérandes X et Y.
Les fig. 81 et 82 illustrent un exemple de mise en oeuvre de l'invention.
La fig. 81 illustre la mise en oeuvre partielle de l'invention. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p et en présence de l'unité 6, il apparaît :
• aux instants ti, t2, l'exécution des commandes déclenchantes CDi, CD2 déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, des fonctions dépendantes fdi, fd2 correspondantes qui assurent le transfert des données X, Y depuis le système de traitement de données 3 vers des zones de mémorisation respectivement x, y situées dans les moyens de mémorisation 15 de l'unité 6, ces commandes déclenchantes CDi, CD2 étant représentées respectivement par OUT(x, X), OUT(y, Y),
• aux instants t3 à tjy.i, l'exécution des commandes déclenchantes CD3 à CDjy-i, déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, des fonctions dépendantes fd3 à fdN-i correspondantes, ces commandes déclenchantes CD3 à CDN_I étant représentées, respectivement, par TRIG(fd3) à TRIG(fdN-ι). La suite des fonctions dépendantes fd3 à fdN-i exécutées en combinaison est algorithmiquement équivalente à la fonction F. Plus précisément, l'exécution de ces commandes déclenchantes conduit à l'exécution dans l'unité 6, des fonctions dépendantes fd3 à fd -i qui se servent du contenu des zones de mémorisation x, y et rendent le résultat dans une zone de mémorisation z de l'unité 6,
• et à l'instant ts, l'exécution d'une commande déclenchante CDN déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, de la fonction dépendante fd assurant le transfert du résultat du traitement algorithmique contenu dans la zone de mémorisation z de l'unité 6 vers le système de traitement de données 3, afin de l'affecter à la variable Z, cette commande étant représentée par IN(z).
Dans cet exemple, pour mettre en oeuvre complètement l'invention, il est choisi en tant que consigne, le premier argument des commandes déclenchantes OUT et l'argument des commandes déclenchantes TRIG et IN. Les consignes ainsi choisies sont renommées par la méthode de renommage des consignes. De cette manière, les consignes des commandes déclenchantes CDi à CDN à savoir x, y, fd3, fdN-i, z sont renommées de manière à obtenir respectivement R(x), R(y), R(fd3)..., R(fdN-ι), R(z). La fig. 82 illustre la mise en oeuvre complète de l'invention. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3, de la première partie d'exécution 2pes du logiciel protégé 2p, et en présence de l'unité 6, il apparaît :
• aux instants ti, t2, l'exécution des commandes déclenchantes à consignes renommées CDCRi, CDCR2, transférant vers l'unité 6, les consignes renommées R(x), R(y) ainsi que les données X, Y déclenchant dans l'unité
6 le rétablissement au moyen des moyens de rétablissement 20, des consignes renommées pour rétablir les consignes à savoir l'identité des zones de mémorisation x, y, puis l'exécution au moyen de la seconde partie d'exécution 2peu, des fonctions dépendantes fdi, fd∑ correspondantes qui assurent le transfert des données X, Y depuis le système de traitement de données 3 vers les zones de mémorisation respectivement x, y situées dans les moyens de mémorisations 15 de l'unité 6, ces commandes déclenchantes à consignes renommées CDCRi, CDCR2 étant représentées respectivement par OUT (R(x), X), OUT (R(y), Y), • aux instants t3 à tjy-1, l'exécution des commandes déclenchantes à consignes renommées CDCR3 à CDCRN-I, transférant vers l'unité 6, les consignes renommées R(fd3) à R(fdN-ι), déclenchant dans l'unité 6 le rétablissement au moyen des moyens de rétablissement 20, des consignes, à savoir fd3 à fdN-i, puis l'exécution au moyen de la seconde partie d'exécution 2peu, des fonctions dépendantes fd3 à fd -i, ces commandes déclenchantes à consignes renommées CDCR3 à CDCRN-I étant représentées respectivement par TRIG (R(fd3)) à TRIG (R(fdN- ), • et à l'instant fa, l'exécution de la commande déclenchante à consigne renommée CDCRN transférant vers l'unité 6, la consigne renommée R(z) déclenchant dans l'unité 6 le rétablissement au moyen des moyens de rétablissement 20, de la consigne à savoir l'identité de la zone de mémorisation z, puis l'exécution au moyen de la seconde partie d'exécution 2peu, de la fonction dépendante fd assurant le transfert du résultat du traitement algorithmique contenu dans la zone de mémorisation z de l'unité 6 vers le système de traitement de données 3, afin de l'affecter à la variable Z, cette commande déclenchante à consigne renommée CDCRN étant représentée par IN (R(z)). Dans l'exemple illustré, les commandes déclenchantes à consignes renommées 1 à N sont exécutées successivement. Il est à noter que deux améliorations peuvent être apportées : • La première amélioration concerne le cas où plusieurs traitements algorithmiques sont déportés dans l'unité 6 et au moins le résultat d'un traitement algorithmique est utilisé par un autre traitement algorithmique. Dans ce cas, certaines commandes déclenchantes à consignes renommées servant au transfert, peuvent être éventuellement supprimées. • La deuxième amélioration vise à opter pour un ordonnancement pertinent des commandes déclenchantes à consignes renommées parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé 2p. A cet égard, il est préférable de choisir un ordonnancement des commandes déclenchantes à consignes renommées qui dissocie temporellement l'exécution des fonctions dépendantes, en intercalant, entre celles-ci des portions de code exécuté dans le système de traitement de données 3 et comportant ou non des commandes déclenchantes à consignes renommées servant à la détermination d'autres données. Les fig. 83 et 84 illustrent le principe d'une telle réalisation.
La fig. 83 montre un exemple d'exécution d'un logiciel vulnérable 2v. Dans cet exemple, il apparaît, au cours de l'exécution du logiciel vulnérable 2v, dans le système de traitement de données 3, l'exécution de deux traitement algorithmiques aboutissant à la détermination de Z et Z', telles que Z <- F (X, Y) et Z' <- F' (X',
Y').
La fig. 84 illustre un exemple de mise en œuvre du procédé selon l'invention pour lequel les deux traitements algorithmiques choisis à la fig. 83 sont déportés dans l'unité 6. Selon un tel exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p et en présence de l'unité 6, il apparaît, comme expliqué ci-dessus, l'exécution des commandes déclenchantes à consignes renommées CDCRi à CDCRN correspondant à la détermination de Z et l'exécution des commandes déclenchantes à consignes renommées CDCR'i à CDCR'M correspondant à la détermination de Z'. Comme illustré, les commandes déclenchantes à consignes renommées CDCRi à CDCRN ne sont pas exécutées consécutivement, dans la mesure où les commandes déclenchantes à consignes renommées CDCR'i à CDCR'M ainsi que d'autres portions de code sont intercalées. Dans l'exemple, il est ainsi réalisé l'ordonnancement suivant : CDCRi, portion de code intercalé, CDCR'i, CDCR2, portion de code intercalé, CDCR'2, CDCR'3, portion de code intercalé, CDCR' , CDCR3, CDCRt, ..., CDCRN, CDCR'M-
Il est à noter que, lors de l'exécution d'une portion de la première partie d'exécution 2pes du logiciel protégé 2p, les commandes déclenchantes à consignes renommées exécutées dans le système de traitement de données 3, déclenchent dans l'unité 6 le rétablissement de l'identité des fonctions dépendantes correspondantes puis l'exécution de celles-ci. Ainsi, il apparaît qu'en présence de l'unité 6, cette portion est exécutée correctement et que, par conséquent, le logiciel protégé 2p est complètement fonctionnel. La fig. 85 illustre un exemple de tentative d'exécution du logiciel protégé 2p, alors que l'unité 6 est absente. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p, à tous les instants, l'exécution d'une commande déclenchante à consigne renommée ne peut pas déclencher le rétablissement de la consigne ni l'exécution de la fonction dépendante correspondante, en raison de l'absence de l'unité 6. La valeur à affecter à la variable Z ne peut donc pas être déterminée correctement. II apparaît donc, qu'en l'absence de l'unité 6, au moins une demande d'une portion de la première partie d'exécution 2pes du logiciel protégé 2p, de déclencher le rétablissement d'une consigne et l'exécution d'une fonction dépendante dans l'unité 6 ne peut pas être satisfaite correctement, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé 2p n'est pas complètement fonctionnel.
Grâce à ce principe de protection par renommage, l'examen dans le logiciel protégé 2p des commandes déclenchantes à consignes renommées ne permet pas de déterminer l'identité des fonctions dépendantes devant être exécutées dans l'unité 6. Il est à noter que le renommage des consignes est effectué lors de la modification du logiciel vulnérable 2v en un logiciel protégé 2p.
Selon une variante du principe de protection par renommage, il est défini pour au moins une fonction dépendante, une famille de fonctions dépendantes algorithmiquement équivalentes mais déclenchées par des commandes déclenchantes à consignes renommées différentes. Selon cette variante, pour au moins un traitement algorithmique utilisant des fonctions dépendantes, ce traitement algorithmique est décomposé en fonctions dépendantes qui pour au moins l'une d'entre elles est remplacée par une fonction dépendante de la même famille au lieu de conserver plusieurs occurrences de la même fonction dépendante. A cette fin, des commandes déclenchantes à consignes renommées sont modifiées pour tenir compte du remplacement de fonctions dépendantes par des fonctions dépendantes de la même famille. En d'autres termes, deux fonctions dépendantes de la même famille ont des consignes différentes et par conséquent des commandes déclenchantes à consignes renommées différentes et, il n'est pas possible, à l'examen du logiciel protégé 2p, de déceler que les fonctions dépendantes appelées sont algorithmiquement équivalentes. Selon une première réalisation préférée de la variante du principe de protection par renommage, il est défini pour au moins une fonction dépendante, une famille de fonctions dépendantes algorithmiquement équivalente, en concaténant un champ de bruit à l'information définissant la partie fonctionnelle de la fonction dépendante à exécuter dans l'unité 6.
Selon une deuxième réalisation préférée de la variante du principe de protection par renommage, il est défini pour au moins une fonction dépendante, une famille de fonctions dépendantes algorithmiquement équivalente en utilisant des champs d'identification.
Selon une variante préférée de réalisation du principe de protection par renommage, il est défini comme méthode de renommage des consignes une méthode de chiffrement permettant de chiffrer les consignes pour les transformer en consignes renommées. Il est rappelé que le renommage des consignes est effectué dans la phase de protection P. Pour cette variante préférée, les moyens de rétablissement 20 sont des moyens mettant en oeuvre une méthode de déchiffrement permettant de déchiffrer les consignes renommées et de rétablir ainsi l'identité des fonctions dépendantes à exécuter dans l'unité 6. Ces moyens de rétablissement sont mis en oeuvre dans l'unité 6 et peuvent être de nature logicielle ou matérielle. Ces moyens de rétablissement 20 sont sollicités dans la phase d'utilisation U à chaque fois qu'une commande déclenchante à consigne renommée est exécutée dans le système de traitement de données 3 dans le but de déclencher dans l'unité 6, l'exécution d'une fonction dépendante. Selon une autre caractéristique avantageuse de l'invention, le procédé de protection vise à mettre en œuvre un principe de protection dit par "branchement conditionnel" dont la description est effectuée en relation des fig. 90 à 92.
Pour la mise en œuvre du principe de protection par branchement conditionnel, il est choisi dans le source du logiciel vulnérable 2vs, au moins un branchement conditionnel BC. Il est aussi choisi au moins une portion du source du logiciel vulnérable 2vs contenant au moins un branchement conditionnel BC choisi.
Au moins une portion choisie du source du logiciel vulnérable 2vs est alors modifié, de manière à obtenir le source du logiciel protégé 2ps. Cette modification est telle que notamment lors de l'exécution du logiciel protégé 2p : • au moins une portion de la première partie d'exécution 2pes, qui est exécutée dans le système de traitement de données 3, prend en compte que la fonctionnalité d'au moins un branchement conditionnel BC choisi est exécutée dans l'unité 6,
• et la seconde partie d'exécution 2peu, qui est exécutée dans l'unité 6, exécute au moins la fonctionnalité d'au moins un branchement conditionnel BC choisi et met à la disposition du système de traitement de données 3, une information permettant à la première partie d'exécution 2pes, de poursuivre son exécution à l'endroit choisi.
La première partie d'exécution 2pes du logiciel protégé 2p, exécutée dans le système de traitement de données 3, exécute des commandes de branchements conditionnels, déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, de branchements conditionnels déportés bc dont la fonctionnalité est équivalente à la fonctionnalité des branchements conditionnels BC choisis. Pour la mise en oeuvre du principe de protection par branchement conditionnel, l'unité 6 comporte des moyens de mémorisation 15 et des moyens de traitement 16.
La fig. 90 illustre un exemple d'exécution d'un logiciel vulnérable 2v. Dans cet exemple, il apparaît, au cours de l'exécution du logiciel vulnérable 2v dans le système de traitement de données 3 à un instant donné, un branchement conditionnel BC indiquant au logiciel vulnérable 2v l'endroit où poursuivre son déroulement, à savoir l'un des trois endroits possibles Bi, B2 ou B3. Il doit être compris que le branchement conditionnel BC prend la décision de poursuivre l'exécution du logiciel à l'endroit Bi, B2 ou B3.
La fig. 91 illustre un exemple de mise en oeuvre de l'invention pour lequel le branchement conditionnel choisi pour être déporté dans l'unité 6, correspond au branchement conditionnel BC. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé 2p et en présence de l'unité 6, il apparaît :
• à l'instant ti, l'exécution de la commande de branchement conditionnel CBCi déclenchant dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, du branchement conditionnel déporté bc algorithmiquement équivalent au branchement conditionnel BC, cette commande de branchement conditionnel CBCi étant représentée par
TRIG(bc), • et à l'instant t2, le transfert de l'unité 6 vers le système de traitement de données 3, de l'information permettant à la première partie d'exécution 2pes, de poursuivre son exécution à l'endroit choisi, à savoir l'endroit Bi, B2 ou B3. II est à noter que lors de l'exécution d'une portion de la première partie d'exécution 2pes du logiciel protégé 2p, les commandes de branchements conditionnels exécutées dans le système de traitement de données 3 déclenchent l'exécution des branchements conditionnels déportés correspondants dans l'unité 6. Ainsi, il apparaît qu'en présence de l'unité 6, cette portion est exécutée correctement et que par conséquent, le logiciel protégé 2p est complètement fonctionnel.
La fig. 92 illustre une tentative d'exécution du logiciel protégé 2p, alors que l'unité 6 est absente. Dans cet exemple, lors de l'exécution dans le système de traitement de données 3 de la première partie d'exécution 2pes du logiciel protégé
2p : « à l'instant ti, l'exécution de la commande de branchement conditionnel
CBCi, ne peut déclencher l'exécution du branchement conditionnel déporté bc, compte tenu de l'absence de l'unité 6,
• et à l'instant t2, le transfert de l'information permettant à la première partie d'exécution 2pes de poursuivre à l'endroit choisi échoue compte tenu de l'absence de l'unité 6.
Il apparaît donc qu'en l'absence de l'unité 6, au moins une demande d'une portion de la première partie d'exécution 2pes de déclencher l'exécution d'un branchement conditionnel déporté dans l'unité 6, ne peut pas être satisfaite correctement, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé 2p n'est pas complètement fonctionnel.
Dans la description qui précède en relation des fig. 90 à 92, l'objet de l'invention vise à déporter dans l'unité 6, un branchement conditionnel. Bien entendu, une réalisation préférée de l'invention peut consister à déporter dans l'unité 6, une série de branchements conditionnels dont la fonctionnalité globale est équivalente à l'ensemble des fonctionnalités des branchements conditionnels qui ont été déportés. L'exécution de la fonctionnalité globale de cette série de branchements conditionnels déportés aboutit à la mise à disposition, pour le système de traitement de données 3, d'une information permettant à la première partie d'exécution 2pes du logiciel protégé 2p de poursuivre son exécution à l'endroit choisi.
Dans la description qui précède en relation des fig. 40 à 92, six principes différents de protection d'un logiciel ont été explicités de manière générale indépendamment les uns des autres. Le procédé de protection conforme à l'invention, est mis en oeuvre en utilisant le principe de protection par variable, éventuellement associé à un ou plusieurs autres principes de protection. Dans le cas où le principe de protection par variable est complété par la mise en œuvre d'au moins un autre principe de protection, le principe de protection par variable est complété avantageusement par le principe de protection par dissociation temporelle et/ou le principe de protection par fonctions élémentaires.
Et lorsque le principe de protection par dissociation temporelle est aussi mis en œuvre, celui-ci peut être complété à son tour par le principe de protection par fonctions élémentaires et/ou le principe de protection par branchement conditionnel. Et lorsque le principe de protection par fonctions élémentaires est aussi mis en œuvre, celui-ci peut être complété à son tour par le principe de protection par détection et coercition et/ou le principe de protection par renommage et/ou le principe de protection par branchement conditionnel.
Et lorsque le principe de protection par détection et coercition est aussi mis en œuvre, celui-ci peut être complété à son tour par le principe de protection par renommage et/ou le principe de protection par branchement conditionnel.
Et lorsque le principe de protection par renommage est aussi mis en œuvre, celui-ci peut être complété à son tour par le principe de protection par branchement conditionnel. Selon la variante préférée de réalisation, le principe de protection par variable est complété par le principe de protection par dissociation temporelle, complété par le principe de protection par fonctions élémentaires, complété par le principe de protection par détection et coercition, complété par le principe de protection par renommage, complété par le principe de protection par branchement conditionnel. Dans le cas où un principe de protection est appliqué, en complément du principe de protection par variable, sa description effectuée précédemment doit comporter, pour tenir compte de sa mise en oeuvre combinée, les modifications suivantes :
• la notion de logiciel vulnérable doit être comprise comme logiciel vulnérable vis-à-vis du principe de protection en cours de description. Ainsi, dans le cas où un principe de protection a déjà été appliqué au logiciel vulnérable, l'expression « logiciel vulnérable » doit être interprétée par le lecteur comme l'expression « logiciel protégé par le ou les principes de protection déjà appliqué(s)» ;
• la notion de logiciel protégé doit être comprise comme logiciel protégé vis- à-vis du principe de protection en cours de description. Ainsi, dans le cas où un principe de protection a déjà été appliqué, l'expression « logiciel protégé » doit être interprétée par le lecteur comme l'expression « nouvelle version du logiciel protégé »;
• et le ou les choix effectué(s) pour la mise en oeuvre du principe de protection en cours de description doit(vent) tenir compte du ou des choix effectué(s) pour la mise en oeuvre du ou des principe(s) de protection déjà appliqué(s). La suite de la description permet de mieux comprendre la mise en oeuvre du procédé de protection conforme à l'invention. Ce procédé de protection selon l'invention fait intervenir, comme cela apparaît plus précisément à la fig. 100 : • d'abord, une phase de protection P au cours de laquelle un logiciel vulnérable 2v est modifié en un logiciel protégé 2p,
• ensuite, une phase d'utilisation U au cours de laquelle le logiciel protégé 2p est mis en oeuvre. Dans cette phase d'utilisation U :
- en présence de l'unité 6 et à chaque fois qu'une portion de la première partie d'exécution 2pes exécutée dans le système de traitement de données 3 l'impose, une fonctionnalité imposée est exécutée dans l'unité 6, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé 2p est complètement fonctionnel,
- en l'absence de l'unité 6 et malgré la demande d'une portion de la première partie d'exécution 2pes d'exécuter une fonctionnalité dans l'unité 6, cette demande ne peut pas être honorée correctement, de sorte qu'au moins cette portion n'est pas exécutée correctement et que par conséquent, le logiciel protégé 2p n'est pas complètement fonctionnel,
• et éventuellement une phase de rechargement R au cours de laquelle est créditée au moins une utilisation supplémentaire d'une fonctionnalité protégée par la mise en oeuvre de la deuxième variante préférée de réalisation du principe de protection par détection et coercition utilisant comme caractéristique, une variable de mesure.
La phase de protection P peut être décomposée en deux sous-phases de protection Pi et P2. La première, dite sous-phase de protection amont Pi, est mise en oeuvre indépendamment du logiciel vulnérable 2v à protéger. La deuxième, dite sous-phase de protection aval P2 est dépendante du logiciel vulnérable 2v à protéger.
Il est à noter que les sous-phases de protection amont Pi et aval P2 peuvent être réalisées avantageusement par deux personnes différentes ou deux équipes différentes. Par exemple, la sous-phase de protection amont Pi peut être réalisée par une personne ou une société assurant le développement de systèmes de protection de logiciels, tandis que la sous-phase de protection aval P2 peut être réalisée par une personne ou une société assurant le développement de logiciels devant être protégés.
Bien entendu, il est clair que les sous-phases de protection amont Pi et aval P2 peuvent aussi être réalisées par la même personne ou la même équipe. La sous-phase de protection amont Pi fait intervenir plusieurs stades Su, ..., SU pour chacun desquels différentes tâches ou travaux sont à effectuer.
Le premier stade de cette sous-phase de protection amont Pi est appelé "stade de définitions Su". Lors de ce stade de définitions Su :
• il est choisi : - le type de l'unité 6, à savoir notamment une unité de mémorisation ou une unité de traitement et de mémorisation . A titre illustratif, il peut- être choisi en tant qu'unité 6, un lecteur 8 de cartes à puce et la carte à puce 7 associée au lecteur, — et les moyens de transfert 12, 13 destinés à être mis en oeuvre respectivement dans le système de traitement de données 3 et dans l'unité 6, au cours de la phase d'utilisation U et aptes à assurer le transfert de données entre le système de traitement de données 3 et l'unité 6,
• et dans le cas où le procédé de protection selon l'invention met en oeuvre le principe de protection par fonctions élémentaires, il est aussi défini :
- un jeu de fonctions élémentaires dont les fonctions élémentaires sont susceptibles d'être exécutées dans l'unité 6,
- et un jeu de commandes élémentaires pour ce jeu de fonctions élémentaires, ces commandes élémentaires étant susceptibles d'être exécutées dans le système de traitement de données 3 et de déclencher l'exécution dans l'unité 6, des fonctions élémentaires, « et dans le cas où le procédé de protection selon l'invention met en oeuvre le principe de protection par détection et coercition, il est aussi défini :
- au moins une caractéristique d'exécution de logiciel, susceptible d'être surveillée au moins en partie dans l'unité 6,
- au moins un critère à respecter pour au moins une caractéristique d'exécution de logiciel,
- des moyens de détection 17 à mettre en oeuvre dans l'unité 6 et permettant de détecter qu'au moins une caractéristique d'exécution de logiciel ne respecte pas au moins un critère associé,
- et des moyens de coercition 18 à mettre en oeuvre dans l'unité 6 et permettant d'informer le système de traitement de données 3 et/ou de modifier l'exécution d'un logiciel, lorsqu'au moins un critère n'est pas respecté,
• et dans le cas où le procédé de protection selon l'invention met en oeuvre le principe de protection par détection et coercition utilisant comme caractéristique une variable de mesure de l'exécution du logiciel, il est aussi défini :
- en tant que caractéristique d'exécution de logiciel susceptible d'être surveillée, une variable de mesure de l'utilisation d'une fonctionnalité d'un logiciel, - en tant que critère à respecter, au moins un seuil associé à chaque variable de mesure, - et des moyens d'actualisation permettant de mettre à jour au moins une variable de mesure,
• et dans le cas où le procédé de protection selon l'invention met en oeuvre une première variante préférée de réalisation du principe de protection par détection et coercition utilisant comme caractéristique une variable de mesure de l'exécution du logiciel, il est aussi défini :
- pour au moins une variable de mesure, plusieurs seuils associés,
- et des moyens de coercition différents correspondant à chacun de ces seuils, • et dans le cas où le procédé de protection selon l'invention met en oeuvre une seconde variante préférée de réalisation du principe de protection par détection et coercition utilisant comme caractéristique une variable de mesure de l'exécution du logiciel, il est aussi défini des moyens de rechargement permettant de créditer au moins une utilisation supplémentaire pour au moins une fonctionnalité de logiciel surveillée par une variable de mesure,
• et dans le cas où le procédé de protection selon l'invention met en oeuvre le principe de protection par détection et coercition utilisant comme caractéristique un profil d'utilisation de logiciel, il est aussi défini : - en tant que caractéristique d'exécution de logiciel susceptible d'être surveillée, un profil d'utilisation de logiciel,
- et en tant que critère à respecter, au moins un trait d'exécution de logiciel,
• et dans le cas où le procédé de protection selon l'invention met en oeuvre le principe de protection par détection et coercition utilisant comme trait d'exécution à respecter, la surveillance de l'enchaînement d'exécution, il est aussi défini :
- un jeu d'instructions dont les instructions sont susceptibles d'être exécutées dans l'unité 6, - un jeu de commandes d'instructions pour ce jeu d'instructions, ces commandes d'instructions étant susceptibles d'être exécutées dans le système de traitement de données 3 et de déclencher dans l'unité 6 l'exécution des instructions,
- en tant que profil d'utilisation, l'enchaînement des instructions,
- en tant que trait d'exécution, un enchaînement souhaité pour l'exécution des instructions,
- en tant que moyens de détection 17, des moyens permettant de détecter que l'enchaînement des instructions ne correspond pas à celui souhaité,
- et en tant que moyens de coercition 18, des moyens permettant d'informer le système de traitement de données 3 et/ou de modifier le fonctionnement de la portion de logiciel protégé 2p lorsque l'enchaînement des instructions ne correspond pas à celui souhaité, et dans le cas où le procédé de protection selon l'invention met en oeuvre une variante préférée de réalisation du principe de protection par détection et coercition utilisant comme trait d'exécution à respecter, la surveillance de l'enchaînement d'exécution, il est aussi défini :
- en tant que jeu d'instructions, un jeu d'instructions dont au moins certaines instructions travaillent sur des registres et utilisent au moins un opérande en vue de rendre un résultat,
- pour au moins une partie des instructions travaillant sur des registres : > une partie PF définissant la fonctionnalité de l'instruction,
> et une partie définissant l'enchaînement souhaité pour l'exécution des instructions et comportant des champs de bits correspondant a :
0 un champ d'identification de l'instruction CII, 0 et pour chaque opérande de l'instruction :
* un champ drapeau CDk,
* et un champ d'identification prévue ClPk de l'opérande,
- pour chaque registre appartenant aux moyens d'exploitation et utilisé par le jeu d'instructions, un champ d'identification générée CIGV dans lequel est automatiquement mémorisée l'identification de la dernière instruction ayant rendu son résultat dans ce registre, - en tant que moyens de détection 17, des moyens permettant, lors de l'exécution d'une instruction, pour chaque opérande, lorsque le champ drapeau CDk l'impose, de contrôler l'égalité entre le champ d'identification générée CIGV correspondant au registre utilisé par cet opérande, et le champ d'identification prévue ClP de l'origine de cet opérande,
- et en tant que moyens de coercition 18, des moyens permettant de modifier le résultat des instructions, si au moins une des égalités contrôlées est fausse, • et dans le cas où le procédé de protection selon l'invention met en oeuvre le principe de protection par renommage, il est aussi défini :
- en tant qu'une commande déclenchante, une commande élémentaire ou une commande d'instruction,
- en tant qu'une fonction dépendante, une fonction élémentaire ou une instruction,
- en tant qu'une consigne, au moins un argument pour une commande déclenchante, correspondant au moins en partie à l'information transmise par le système de traitement de données 3 à l'unité 6, afin de déclencher l'exécution de la fonction dépendante correspondante, - une méthode de renommage des consignes permettant de renommer les consignes afin d'obtenir des commandes déclenchantes à consignes renommées,
- et des moyens de rétablissement 20 destinés à être mis en oeuvre dans l'unité 6 au cours de la phase d'utilisation U, et permettant de retrouver la fonction dépendante à exécuter, à partir de la consigne renommée,
• et dans le cas où le procédé de protection selon l'invention met en oeuvre une variante du principe de protection par renommage, il est aussi défini pour au moins une fonction dépendante, une famille de fonctions dépendantes algorithmiquement équivalentes, mais déclenchées par des commandes déclenchantes dont les consignes renommées sont différentes,
• et dans le cas où le procédé de protection selon l'invention met en oeuvre l'une ou l'autre des réalisations préférées de la variante du principe de protection par renommage, il est aussi défini pour au moins une fonction dépendante, une famille de fonctions dépendantes algorithmiquement équivalentes : - en concaténant un champ de bruit à l'information définissant la partie fonctionnelle de la fonction dépendante à exécuter dans l'unité 6,
- ou en utilisant le champ d'identification de l'instruction Cil et les champs d'identification prévue CD?k des opérandes,
• et dans le cas où le procédé de protection selon l'invention met en oeuvre une variante préférée du principe de protection par renommage, il est aussi défini :
- en tant que méthode de renommage des consignes, une méthode de chiffrement pour chiffrer les consignes,
- et en tant que moyens de rétablissement 20, des moyens mettant en oeuvre une méthode de déchiffrement pour déchiffrer les consignes renommées et rétablir ainsi l'identité des fonctions dépendantes à exécuter dans l'unité 6. Lors de la sous-phase de protection amont, le stade de définition Su est suivi par un stade appelé "stade de construction Sι2". Lors d'un tel stade S12, sont construits les moyens de transfert 12, 13 et éventuellement, les moyens d'exploitation correspondant aux définitions du stade de définition Su. Lors de ce stade de construction S12, il est donc procédé:
• à la construction des moyens de transfert 12, 13 permettant, au cours de la phase d'utilisation U, le transfert de données entre le système de traitement de données 3 et l'unité 6,
• et lorsque le principe de protection par fonctions élémentaires est aussi mis en oeuvre, à la construction des moyens d'exploitation permettant à l'unité 6, au cours de la phase d'utilisation U d'exécuter les fonctions élémentaires du jeu de fonctions élémentaires, • et lorsque le principe de protection par détection et coercition est aussi mis en oeuvre, à la construction : des moyens d'exploitation permettant à l'unité 6, au cours de la phase d'utilisation U de mettre aussi en oeuvre les moyens de détection 17 et les moyens de coercition 18, et éventuellement des moyens d'exploitation permettant à l'unité 6, au cours de la phase d'utilisation U de mettre aussi en oeuvre les moyens d'actualisation, - et éventuellement des moyens d'exploitation permettant à l'unité 6, au cours de la phase de rechargement de mettre aussi en oeuvre les moyens de rechargement, - et éventuellement des moyens d'exploitation permettant aussi à l'unité
6, au cours de la phase d'utilisation U d'exécuter les instructions du jeu d'instruction, • et lorsque le principe de protection par renommage est aussi mis en oeuvre, à la construction des moyens d'exploitation permettant à l'unité 6, au cours de la phase d'utilisation U de mettre aussi en oeuvre les moyens de rétablissement. La construction des moyens d'exploitation est réalisée de manière classique, par l'intermédiaire d'une unité de développement de programme en prenant en compte les définitions intervenues au stade de définitions Su. Une telle unité est décrite dans la suite de la description à la fig. 110.
Lors de la sous-phase de protection amont Pi, le stade de construction S12 peut être suivi par un stade appelé "stade de pré-personnalisation Sι3". Lors de ce stade de pré-personnalisation Sι3 au moins une partie des moyens de transfert 13 et/ou les moyens d'exploitation sont chargés dans au moins une unité vierge 60 en vue d'obtenir au moins une unité pré-personnalisée 66. Il est à noter qu'une partie des moyens d'exploitation, une fois transférée dans une unité pré-personnalisée 66, n'est plus directement accessible de l'extérieur de cette unité pré-personnalisée 66. Le transfert des moyens d'exploitation dans une unité vierge 60 peut être réalisé par l'intermédiaire d'une unité de pré-personnalisation adaptée, qui est décrite dans la suite de la description à la fig. 120. Dans le cas d'une unité pré-personnalisée 66, constituée d'une carte à puce 7 et de son lecteur 8, la pré-personnalisation ne concerne que la carte à puce 7.
Lors de la sous-phase de protection amont Pi, il peut être mis en oeuvre, après le stade de définition Su et, éventuellement après le stade de construction S12, un stade appelé "stade de confection d'outils Sι ". Lors de ce stade de confection d'outils Sι sont confectionnés des outils permettant d'aider à la génération de logiciels protégés ou d'automatiser la protection de logiciels. De tels outils permettent :
• d'aider à choisir ou de choisir automatiquement dans le logiciel vulnérable 2v à protéger :
- la ou les variables susceptibles d'être déportées dans l'unité 6, - la ou les portions susceptibles d'être modifiées,
- et lorsque le principe de protection par dissociation temporelle est aussi mis en oeuvre, le ou les traitements algorithmiques susceptibles d'être décomposées en étapes déportables dans l'unité 6,
- et lorsque le principe de protection par fonctions élémentaires est aussi mis en oeuvre, le ou les traitements algorithmiques susceptibles d'être décomposées en fonctions élémentaires déportables dans l'unité 6,
- et lorsque le principe de protection par détection et coercition est aussi mis en oeuvre, la ou les caractéristiques d'exécution à surveiller et, éventuellement, le ou les traitements algorithmiques susceptibles d'être décomposées en instructions déportables dans l'unité 6,
- et lorsque le principe de protection par renommage est aussi mis en oeuvre, le ou les traitements algorithmiques susceptibles d'être décomposées en fonctions dépendantes déportables dans l'unité 6 et pour lesquelles les consignes des commandes déclenchantes peuvent être renommées,
- et lorsque le principe de protection par branchement conditionnel est aussi mis en oeuvre, le ou les branchements conditionnels dont la fonctionnalité est susceptible d'être déportée dans l'unité 6,
• et, éventuellement, d'aider à générer des logiciels protégés ou d'automatiser la protection de logiciels.
Ces différents outils peuvent être réalisés indépendamment ou en combinaison et chaque outil peut prendre diverses formes, comme par exemple préprocesseur, assembleur, compilateur, etc.
La sous-phase de protection amont Pi est suivie par une sous-phase de protection aval P2 dépendante du logiciel vulnérable 2v à protéger. Cette sous-phase de protection aval P2 fait intervenir également plusieurs stades. Le premier stade correspondant à la mise en oeuvre du principe de protection par variable est appelé "stade de création S21". Lors de ce stade de création S21, il est utilisé les choix intervenus au stade de définition Su. A l'aide de ces choix et éventuellement d'outils construits au stade de confection d'outils Sι , il est créé le logiciel protégé 2p : • en choisissant dans le source du logiciel vulnérable 2vs :
- au moins une variable qui, lors de l'exécution du logiciel vulnérable 2v, définit partiellement l'état de celui-ci,
- et au moins une portion contenant au moins une variable choisie,
• en produisant le source du logiciel protégé 2ps à partir du source du logiciel vulnérable 2vs, en modifiant au moins une portion choisie du source du logiciel vulnérable 2vs, cette modification étant telle que lors de l'exécution du logiciel protégé 2p, au moins une variable choisie ou au moins une copie de variable choisie réside dans l'unité vierge 60 qui se transforme ainsi en une unité 6, • et en produisant une première partie objet 2pos du logiciel protégé 2p à partir du source du logiciel protégé 2ps, cette première partie objet 2pos étant telle que lors de l'exécution du logiciel protégé 2p, apparaît une première partie d'exécution 2pes qui est exécutée dans le système de traitement de données 3 et dont au moins une portion prend en compte qu'au moins une variable ou au moins une copie de variable réside dans l'unité 6.
Bien entendu, le principe de protection par variable selon l'invention peut être appliqué directement lors du développement d'un nouveau logiciel sans nécessiter la réalisation préalable d'un logiciel vulnérable 2v. De cette manière, il est obtenu directement un logiciel protégé 2p.
Lors de la sous-phase de protection aval P2, et lorsqu'au moins un autre principe de protection est appliqué en plus du principe de protection par variable, il est mis en oeuvre un "stade de modification S22". Lors de ce stade de modification S22, il est utilisé les définitions intervenues au stade de définitions Su. A l'aide de ces définitions et éventuellement d'outils construits au stade de confection d'outils Sι , le logiciel protégé 2p est modifié pour permettre la mise en oeuvre des principes de protection selon l'un des arrangements définis ci-avant.
Lorsque le principe de protection par dissociation temporelle est mis en oeuvre, le logiciel protégé 2p est modifié :
• en choisissant dans le source du logiciel protégé 2ps : - au moins un traitement algorithmique qui lors de l'exécution du logiciel protégé 2p, utilise au moins une variable choisie, et permet d'obtenir au moins une variable résultante,
- et au moins une portion contenant au moins un traitement algorithmique choisi, « en modifiant au moins une portion choisie du source du logiciel protégé
2ps, cette modification étant telle que :
- lors de l'exécution du logiciel protégé 2p la première partie d'exécution 2pes est exécutée dans le système de traitement de données 3 et une seconde partie d'exécution 2peu est exécutée dans l'unité 6 qui comporte aussi des moyens de traitement 16,
- au moins la fonctionnalité d'au moins un traitement algorithmique choisi est exécutée au moyen de la seconde partie d'exécution 2peu,
- au moins un traitement algorithmique choisi est décomposé de manière que lors de l'exécution du logiciel protégé 2p, apparaissent, au moyen de la seconde partie d'exécution 2peu, plusieurs étapes distinctes, à savoir :
> la mise à disposition d'au moins une variable pour l'unité 6,
> la réalisation dans l'unité 6, de la fonctionnalité du traitement algorithmique sur au moins cette variable, > et éventuellement, la mise à disposition d'au moins une variable résultante, par l'unité 6 pour le système de traitement de données 3,
- pour au moins un traitement algorithmique choisi, des commandes d'étapes sont définies de manière que lors de l'exécution du logiciel protégé 2p, chaque commande d'étape est exécutée par la première partie d'exécution 2pes et déclenche dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, d'une étape,
- et un ordonnancement des commandes d'étapes est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé 2p, • et en produisant :
- la première partie objet 2pos du logiciel protégé 2p, cette première partie objet 2pos étant telle que lors de l'exécution du logiciel protégé 2p, les commandes d'étapes sont exécutées selon l'ordonnancement choisi, - et une seconde partie objet 2pou du logiciel protégé 2p, cette seconde partie objet 2pou étant telle que, après chargement dans l'unité vierge
60 et lors de l'exécution du logiciel protégé 2p, apparaît la seconde partie d'exécution 2peu au moyen de laquelle les étapes déclenchées par la première partie d'exécution 2pes sont exécutées. Lorsque le principe de protection par fonctions élémentaires est mis en oeuvre alors que le principe de protection par dissociation temporelle n'est pas mis en oeuvre, le logiciel protégé 2p est modifié :
• en choisissant dans le source du logiciel protégé 2ps :
- au moins un traitement algorithmique qui lors de l'exécution du logiciel protégé 2p, utilise au moins une variable choisie, et permet d'obtenir au moins une variable résultante,
- et au moins une portion contenant au moins un traitement algorithmique choisi,
• en modifiant au moins une portion choisie du source du logiciel protégé 2ps, cette modification étant telle que :
- lors de l'exécution du logiciel protégé 2p la première partie d'exécution 2pes est exécutée dans le système de traitement de données 3 et une seconde partie d'exécution 2peu est exécutée dans l'unité 6,
- au moins la fonctionnalité d'au moins un traitement algorithmique choisi est exécutée au moyen de la seconde partie d'exécution 2peu, - au moins un traitement algorithmique choisi est décomposé de manière que lors de l'exécution du logiciel protégé 2p, ce traitement algorithmique est exécuté au moyen de la seconde partie d'exécution 2peu, en utilisant des fonctions élémentaires,
- pour au moins un traitement algorithmique choisi, des commandes élémentaires sont intégrées dans le source du logiciel protégé 2ps, de manière que lors de l'exécution du logiciel protégé 2p, chaque commande élémentaire est exécutée par la première partie d'exécution 2pes et déclenche dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, d'une fonction élémentaire, - et un ordonnancement des commandes élémentaires est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé 2p,
• et en produisant :
- la première partie objet 2pos du logiciel protégé 2p, cette première partie objet 2pos étant telle que lors de l'exécution du logiciel protégé
2p, les commandes élémentaires sont exécutées selon l'ordonnancement choisi,
- et une seconde partie objet 2pou du logiciel protégé 2p contenant les moyens d'exploitation, cette seconde partie objet 2pou étant telle que, après chargement dans l'unité vierge 60 et lors de l'exécution du logiciel protégé 2p, apparaît la seconde partie d'exécution 2peu au moyen de laquelle les fonctions élémentaires déclenchées par la première partie d'exécution 2pes sont exécutées.
Lorsque les principes de protection par dissociation temporelle et par fonctions élémentaires sont tous les deux mis en oeuvre, le logiciel protégé 2p est modifié :
• en choisissant dans le source du logiciel protégé 2ps, au moins une étape qui lors de l'exécution du logiciel protégé 2p, réalise la fonctionnalité d'un traitement algorithmique,
• en modifiant au moins une portion choisie du source du logiciel protégé 2ps, cette modification étant telle que : - au moins une étape choisie est décomposée de manière que lors de l'exécution du logiciel protégé 2p, cette étape est exécutée au moyen de la seconde partie d'exécution 2peu, en utilisant des fonctions élémentaires,
- pour au moins une étape choisie, des commandes élémentaires sont intégrées dans le source du logiciel protégé 2ps, de manière que lors de l'exécution du logiciel protégé 2p, chaque commande élémentaire est exécutée par la première partie d'exécution 2pes et déclenche dans l'unité 6, l'exécution au moyen de la seconde partie d'exécution 2peu, d'une fonction élémentaire, - et un ordonnancement des commandes élémentaires est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé 2p,
• et en produisant :
- la première partie objet 2pos du logiciel protégé 2p, cette première partie objet 2pos étant telle que lors de l'exécution du logiciel protégé
2p, les commandes élémentaires sont exécutées selon l'ordonnancement choisi,
- et la seconde partie objet 2pou du logiciel protégé 2p contenant aussi les moyens d'exploitation, cette seconde partie objet 2pou étant telle que, après chargement dans l'unité 6 et lors de l'exécution du logiciel protégé 2p, apparaît la seconde partie d'exécution 2peu au moyen de laquelle les fonctions élémentaires déclenchées par la première partie d'exécution 2pes sont exécutées.
Lorsque le principe de protection par détection et coercition est mis en oeuvre, giciel protégé 2p est modifié :
• en choisissant au moins une caractéristique d'exécution de logiciel à surveiller, parmi les caractéristiques d'exécution susceptibles d'être surveillées,
• en choisissant au moins un critère à respecter pour au moins une caractéristique d'exécution de logiciel choisie, « en choisissant dans le source du logiciel protégé 2ps, des fonctions élémentaires pour lesquelles au moins une caractéristique d'exécution de logiciel choisie, est à surveiller,
• en modifiant au moins une portion choisie du source du logiciel protégé 2ps, cette modification étant telle que lors de l'exécution du logiciel protégé 2p, au moins une caractéristique d'exécution choisie est surveillée au moyen de la seconde partie d'exécution 2peu, et le non respect d'un critère aboutit à une information du système de traitement de données 3 et/ou à une modification de l'exécution du logiciel protégé 2p,
• et en produisant la seconde partie objet 2pou du logiciel protégé 2p contenant les moyens d'exploitation mettant aussi en oeuvre les moyens de détection 17 et les moyens de coercition 18, cette seconde partie objet 2pou étant telle que, après chargement dans l'unité 6 et lors de l'exécution du logiciel protégé 2p, au moins une caractéristique d'exécution de logiciel est surveillée et le non respect d'un critère aboutit à une information du système de traitement de données 3 et/ou à une modification de l'exécution du logiciel protégé 2p. Pour la mise en oeuvre du principe de protection par détection et coercition utilisant comme caractéristique une variable de mesure de l'exécution du logiciel, le logiciel protégé 2p est modifié : • en choisissant en tant que caractéristique d'exécution de logiciel à surveiller, au moins une variable de mesure de l'utilisation d'une fonctionnalité d'un logiciel,
• en choisissant :
- au moins une fonctionnalité du logiciel protégé 2p dont l'utilisation est susceptible d'être surveillée grâce à une variable de mesure,
- au moins une variable de mesure servant à quantifier l'utilisation de ladite fonctionnalité,
- au moins un seuil associé à une variable de mesure choisie correspondant à une limite d'utilisation de ladite fonctionnalité,
- et au moins une méthode de mise à jour d'une variable de mesure choisie en fonction de l'utilisation de ladite fonctionnalité,
• et en modifiant au moins une portion choisie du source du logiciel protégé 2ps, cette modification étant telle que, lors de l'exécution du logiciel protégé 2p, la variable de mesure est actualisée au moyen de la seconde partie d'exécution 2peu, en fonction de l'utilisation de ladite fonctionnalité et au moins un dépassement de seuil est pris en compte.
Pour la mise en oeuvre d'une première variante préférée de réalisation du principe de protection par détection et coercition utilisant, comme caractéristique, une variable de mesure, le logiciel protégé 2p est modifié :
• en choisissant dans le source du logiciel protégé 2ps, au moins une variable de mesure choisie à laquelle doivent être associés plusieurs seuils correspondants à des limites différentes d'utilisation de la fonctionnalité,
• en choisissant au moins deux seuils associés à la variable de mesure choisie,
• et en modifiant au moins une portion choisie du source du logiciel protégé 2ps, cette modification étant telle que, lors de l'exécution du logiciel protégé 2p, les dépassements des divers seuils sont pris en compte, au moyen de la seconde partie d'exécution 2peu, de manière différente. Pour la mise en oeuvre d'une seconde variante préférée de réalisation du principe de protection par détection et coercition utilisant comme caractéristique, une variable de mesure, le logiciel protégé 2p est modifié :
• en choisissant dans le source du logiciel protégé 2ps, au moins une variable de mesure choisie permettant de limiter l'utilisation d'une fonctionnalité à laquelle au moins une utilisation supplémentaire doit pouvoir être créditée,
• et en modifiant au moins une portion choisie, cette modification étant telle que dans une phase dite de rechargement, au moins une utilisation supplémentaire d'au moins une fonctionnalité correspondant à une variable de mesure choisie peut être créditée. Pour la mise en oeuvre du principe de protection par détection et coercition utilisant comme caractéristique, un profil d'utilisation de logiciel, le logiciel protégé 2p est modifié : « en choisissant en tant que caractéristique d'exécution de logiciel à surveiller au moins un profil d'utilisation de logiciel,
• en choisissant au moins un trait d'exécution qu'au moins un profil d'utilisation choisi doit respecter,
• et en modifiant au moins une portion choisie du source du logiciel protégé 2ps, cette modification étant telle que, lors de l'exécution du logiciel protégé 2p, la seconde partie d'exécution 2peu respecte tous les traits d'exécution choisis. Pour la mise en oeuvre du principe de protection par détection et coercition utilisant comme trait d'exécution à respecter, la surveillance de l'enchaînement d'exécution, le logiciel protégé 2p est modifié :
• en modifiant au moins une portion choisie du source du logiciel protégé 2ps :
- en transformant les fonctions élémentaires en instructions,
- en spécifiant l'enchaînement que doivent respecter au moins certaines des instructions lors de leur exécution dans l'unité 6,
- et en transformant les commandes élémentaires en commandes d'instructions correspondant aux instructions utilisées.
Lorsque le principe de protection par renommage est mis en oeuvre, le logiciel 2p est modifié : • en choisissant dans le source du logiciel protégé 2ps, des commandes déclenchantes,
• en modifiant au moins une portion choisie du source du logiciel protégé 2ps en renommant les consignes des commandes déclenchantes choisies, afin de dissimuler l'identité des fonctions dépendantes correspondantes, • et en produisant :
- la première partie objet 2pos du logiciel protégé 2p, cette première partie objet 2pos étant telle que lors de l'exécution du logiciel protégé 2p, les commandes déclenchantes à consignes renommées sont exécutées, - et la seconde partie objet 2pou du logiciel protégé 2p contenant les moyens d'exploitation mettant aussi en oeuvre les moyens de rétablissement 20, cette seconde partie objet 2pou étant telle que, après chargement dans l'unité 6 et lors de l'exécution du logiciel protégé 2p, l'identité des fonctions dépendantes dont l'exécution est déclenchée par la première partie d'exécution 2pes est rétablie au moyen de la seconde partie d'exécution 2peu, et les fonctions dépendantes sont exécutées au moyen de la seconde partie d'exécution 2peu. Pour la mise en oeuvre d'une variante du principe de protection par renommage, le logiciel protégé 2p est modifié :
• en choisissant dans le source du logiciel protégé 2ps au moins une commande déclenchante à consigne renommée,
• et en modifiant au moins une portion choisie du source du logiciel protégé 2ps en remplaçant au moins la consigne renommée d'une commande déclenchante à consigne renommée choisie, par une autre consigne renommée, déclenchant une fonction dépendante de la même famille. Lorsque le principe de protection par branchement conditionnel est mis en oeuvre, le logiciel protégé 2p est modifié :
• en choisissant dans le source du logiciel protégé 2ps, au moins un branchement conditionnel effectué dans au moins un traitement algorithmique choisi, • en modifiant au moins une portion choisie du source du logiciel protégé
2ps, cette modification étant telle que lors de l'exécution du logiciel protégé 2p, la fonctionnalité d'au moins un branchement conditionnel choisi, est exécutée, au moyen de la seconde partie d'exécution 2peu, dans l'unité 6,
• et en produisant : - la première partie objet 2pos du logiciel protégé 2p, cette première partie objet 2pos étant telle que lors de l'exécution du logiciel protégé 2p, la fonctionnalité d'au moins un branchement conditionnel choisi est exécutée dans l'unité 6,
- et la seconde partie objet 2pou du logiciel protégé 2p, cette seconde partie objet 2pou étant telle que, après chargement dans l'unité 6 et lors de l'exécution du logiciel protégé 2p, apparaît la seconde partie d'exécution 2peu au moyen de laquelle la fonctionnalité d'au moins un branchement conditionnel choisi est exécutée. Pour la mise en oeuvre d'une réalisation préférée du principe de protection par branchement conditionnel, le logiciel protégé 2p est modifié : • en choisissant, dans le source du logiciel protégé 2ps au moins une série de branchements conditionnels choisis,
• en modifiant au moins une portion choisie du source du logiciel protégé 2ps, cette modification étant telle que lors de l'exécution du logiciel protégé 2p, la fonctionnalité globale d'au moins une série choisie de branchements conditionnels est exécutée au moyen de la seconde partie d'exécution 2peu, dans l'unité 6,
• et en produisant :
- la première partie objet 2pos du logiciel protégé 2p, cette première partie objet 2pos étant telle que lors de l'exécution du logiciel protégé 2p, la fonctionnalité d'au moins une série choisie de branchements conditionnels est exécutée dans l'unité 6,
- et la seconde partie objet 2pou du logiciel protégé 2p, cette seconde partie objet 2pou étant telle que, après chargement dans l'unité 6 et lors de l'exécution du logiciel protégé 2p, apparaît la seconde partie d'exécution 2peu au moyen de laquelle la fonctionnalité globale d'au moins une série choisie de branchements conditionnels est exécutée.
Bien entendu, les principes de protection selon l'invention peuvent être appliqués directement lors du développement d'un nouveau logiciel sans nécessiter la réalisation préalable de logiciels protégés intermédiaires. De cette façon, les stades de création S2ι et de modification S22 peuvent être effectués concomitamment de manière à obtenir directement le logiciel protégé 2p. Lors de la sous-phase de protection aval P2, dans le cas où au moins un autre principe de protection est utilisé en complément du principe de protection par variable, il est mis en oeuvre après le stade de création S21 du logiciel protégé 2p, et éventuellement après le stade de modification S22, un stade appelé "stade de personnalisation S23". Lors de ce stade de personnalisation S23, la seconde partie objet 2pou contenant éventuellement les moyens d'exploitation est chargée dans au moins une unité vierge 60, en vue d'obtenir au moins une unité 6, ou une partie de la seconde partie objet 2pou contenant éventuellement les moyens d'exploitation est chargée dans au moins une unité pré-personnalisée 66, en vue d'obtenir au moins une unité 6. Le chargement de ces informations de personnalisation permet de rendre opérationnelle au moins une unité 6. Il est à noter qu'une partie de ces informations, une fois transférée dans une unité 6, n'est pas directement accessible de l'extérieur de cette unité 6. Le transfert des informations de personnalisation dans une unité vierge 60 ou une unité pré-personnalisée 66 peut être réalisé par l'intermédiaire d'une unité de personnalisation adaptée qui est décrite dans la suite de la description à la fig. 150. Dans le cas d'une unité 6, constituée d'une carte à puce 7 et de son lecteur 8, la personnalisation ne concerne que la carte à puce 7.
Pour la mise en oeuvre de la phase de protection P, différents moyens techniques sont décrits plus précisément en relation des fig. 110, 120, 130, 140 et 150.
La fig. 110 illustre un exemple de réalisation d'un système 25 permettant de mettre en oeuvre le stade de construction S12 prenant en compte les définitions intervenues au stade de définitions Su et au cours duquel sont construits les moyens de transfert 12, 13 et éventuellement, les moyens d'exploitation destinés à l'unité 6. Un tel système 25 comporte une unité de développement de programme ou station de travail se présentant classiquement sous la forme d'un ordinateur comprenant une unité centrale, un écran, des périphériques du type clavier-souris, et comportant, notamment, les programmes suivants : éditeurs de fichiers, assembleurs, préprocesseurs, compilateurs, interpréteurs, debuggers et éditeurs de liens. La fig. 120 illustre un exemple de réalisation d'une unité de prépersonnalisation 30 permettant de charger au moins en partie les moyens de transfert 13 et/ou les moyens d'exploitation dans au moins une unité vierge 60 en vue d'obtenir au moins une unité pré-personnalisée 66. Cette unité de prépersonnalisation 30 comporte un moyen de lecture et d'écriture 31 permettant de prépersonnaliser de manière électrique, une unité vierge 60, de manière à obtenir une unité pré-personnalisée 66 dans laquelle les moyens de transfert 13 et/ou d'exploitation ont été chargés. L'unité de pré-personnalisation 30 peut aussi comporter des moyens de personnalisation physique 32 de l'unité vierge 60 pouvant se présenter par exemple, sous la forme d'une imprimante. Dans le cas où l'unité 6 est constituée par une carte à puce 7 et son lecteur 8, la pré-personnalisation concerne généralement uniquement la carte à puce 7. La fig. 130 illustre un exemple de réalisation d'un système 35 permettant d'effectuer la confection des outils permettant d'aider à générer des logiciels protégés ou d'automatiser la protection de logiciels. Un tel système 35 comporte une unité de développement de programme ou station de travail se présentant classiquement sous la forme d'un ordinateur comprenant une unité centrale, un écran, des périphériques du type clavier-souris, et comportant, notamment, les programmes suivants : éditeurs de fichiers, assembleurs, pré-processeurs, compilateurs, interpréteurs, debuggers et éditeurs de liens.
La fig. 140 illustre un exemple de réalisation d'un système 40 permettant de créer directement un logiciel protégé 2p ou de modifier un logiciel vulnérable 2v en vue d'obtenir un logiciel protégé 2p. Un tel système 40 comporte une unité de développement de programme ou station de travail se présentant classiquement sous la forme d'un ordinateur comprenant une unité centrale, un écran, des périphériques du type clavier-souris, et comportant, notamment, les programmes suivants : éditeurs de fichiers, assembleurs, pré-processeurs, compilateurs, interpréteurs, debuggers et éditeurs de liens, ainsi que des outils permettant d'aider à générer des logiciels protégés ou d'automatiser la protection de logiciels.
La fig. 150 illustre un exemple de réalisation d'une unité de personnalisation 45 permettant de charger la seconde partie objet 2pou dans au moins une unité vierge 60 en vue d'obtenir au moins une unité 6 ou une partie de la seconde partie objet 2pou dans au moins une unité pré-personnalisée 66 en vue d'obtenir au moins une unité 6. Cette unité de personnalisation 45 comporte un moyen de lecture et d'écriture 46 permettant de personnaliser de manière électrique, au moins une unité vierge 60 ou au moins une unité pré-personnalisée 66, de manière à obtenir au moins une unité 6. A l'issue de cette personnalisation, une unité 6 comporte les informations nécessaires à l'exécution du logiciel protégé 2p. L'unité de personnalisation 45 peut aussi comporter des moyens de personnalisation physique 47 pour au moins une unité 6 pouvant se présenter par exemple, sous la forme d'une imprimante. Dans le cas où une unité 6 est constituée par une carte à puce 7 et son lecteur 8, la personnalisation concerne généralement uniquement la carte à puce 7.
Le procédé de protection de l'invention peut être mis en oeuvre avec les améliorations suivantes : • Il peut être prévu d'utiliser conjointement plusieurs unités de traitement et de mémorisation dans lesquelles est répartie la seconde partie objet 2pou du logiciel protégé 2p de manière que leur utilisation conjointe permette d'exécuter le logiciel protégé 2p, l'absence d'au moins une de ces unités de traitement et de mémorisation empêchant l'utilisation du logiciel protégé 2p.
• De même, après le stade de pré-personnalisation S13 et lors du stade de personnalisation S23, la partie de la seconde partie objet 2pou nécessaire pour transformer l'unité pré-personnalisée 66 en une unité 6 peut être contenue dans une unité de traitement et de mémorisation utilisée par l'unité de personnalisation 45 afin de limiter l'accès à cette partie de la seconde partie objet 2pou. Bien entendu, cette partie de la seconde partie objet 2pou peut être répartie dans plusieurs unités de traitement et de mémorisation de manière que cette partie de la seconde partie objet 2pou soit accessible uniquement lors de l'utilisation conjointe de ces unités de traitement et de mémorisation.

Claims

REVENDICATIONS :
1 - Procédé pour protéger, à partir d'au moins une unité vierge (60) comportant au moins des moyens de mémorisation (15), un logiciel vulnérable (2v) contre son utilisation non autorisée, ledit logiciel vulnérable (2v) fonctionnant sur un système de traitement de données (3), caractérisé en ce qu'il consiste : - dans une phase de protection (P) :
• à créer un logiciel protégé (2p) :
- en choisissant dans le source du logiciel vulnérable (2vs) : > au moins une variable qui, lors de l'exécution du logiciel vulnérable (2v), définit partiellement l'état de celui-ci, > et au moins une portion contenant au moins une variable choisie,
- en produisant le source du logiciel protégé (2ps) à partir du source du logiciel vulnérable (2vs), en modifiant au moins une portion choisie du source du logiciel vulnérable (2vs), cette modification étant telle que lors de l'exécution du logiciel protégé (2p), au moins une variable choisie ou au moins une copie de variable choisie réside dans l'unité vierge (60) qui se transforme ainsi en une unité (6),
- et en produisant une première partie objet (2pos) du logiciel protégé (2p) à partir du source du logiciel protégé (2ps), cette première partie objet (2pos) étant telle que lors de l'exécution du logiciel protégé (2p), apparaît une première partie d'exécution (2pes) qui est exécutée dans le système de traitement de données (3) et dont au moins une portion prend en compte qu'au moins une variable ou au moins une copie de variable réside dans l'unité (6),
- et dans une phase d'utilisation (U) au cours de laquelle est exécuté le logiciel protégé (2p) :
• en présence de l'unité (6), à chaque fois qu'une portion de la première partie d'exécution (2pes) l'impose, à utiliser une variable ou une copie de variable résidant dans l'unité (6), de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé (2p) est complètement fonctionnel, • et en l'absence de l'unité (6), malgré la demande d'une portion de la première partie d'exécution (2pes) d'utiliser une variable ou une copie de variable résidant dans l'unité (6), à ne pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé (2p) n'est pas complètement fonctionnel. 2 - Procédé selon la revendication 1, caractérisé en ce qu'il consiste : dans la phase de protection (P) : • à modifier le logiciel protégé (2p) :
- en choisissant dans le source du logiciel protégé (2ps) :
> au moins un traitement algorithmique qui lors de l'exécution du logiciel protégé (2p), utilise au moins une variable choisie, et permet d'obtenir au moins une variable résultante, > et au moins une portion contenant au moins un traitement algorithmique choisi,
- en modifiant au moins une portion choisie du source du logiciel protégé (2ps), cette modification étant telle que :
> lors de l'exécution du logiciel protégé (2p) la première partie d'exécution (2pes) est exécutée dans le système de traitement de données (3) et une seconde partie d'exécution (2peu) est exécutée dans l'unité (6) qui comporte aussi des moyens de traitement (16),
> au moins la fonctionnalité d'au moins un traitement algorithmique choisi est exécutée au moyen de la seconde partie d'exécution (2peu),
> au moins un traitement algorithmique choisi est décomposé de manière que lors de l'exécution du logiciel protégé (2p), apparaissent, au moyen de la seconde partie d'exécution (2peu), plusieurs étapes distinctes, à savoir : 0 la mise à disposition d'au moins une variable pour l'unité (6),
0 la réalisation dans l'unité (6), de la fonctionnalité du traitement algorithmique sur au moins cette variable, 0 et éventuellement, la mise à disposition d'au moins une variable résultante, par l'unité (6) pour le système de traitement de données (3), > pour au moins un traitement algorithmique choisi, des commandes d'étapes sont définies de manière que lors de l'exécution du logiciel protégé (2p), chaque commande d'étape est exécutée par la première partie d'exécution (2pes) et déclenche dans l'unité (6), l'exécution au moyen de la seconde partie d'exécution (2peu), d'une étape,
> et un ordonnancement des commandes d'étapes est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé (2p),
- et en produisant : > la première partie objet (2pos) du logiciel protégé (2p), cette première partie objet (2pos) étant telle que lors de l'exécution du logiciel protégé (2p), les commandes d'étapes sont exécutées selon l'ordonnancement choisi,
> et une seconde partie objet (2pou) du logiciel protégé (2p), cette seconde partie objet (2pou) étant telle que, après chargement dans l'unité vierge (60) et lors de l'exécution du logiciel protégé (2p), apparaît la seconde partie d'exécution (2peu) au moyen de laquelle les étapes déclenchées par la première partie d'exécution (2pes) sont exécutées, • et à charger la seconde partie objet (2pou) dans l'unité vierge (60), en vue d'obtenir l'unité (6), et dans la phase d'utilisation (U) :
• en présence de l'unité (6) et à chaque fois qu'une commande d'étape contenue dans une portion de la première partie d'exécution (2pes) l'impose, à exécuter l'étape correspondante dans l'unité (6), de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé (2p) est complètement fonctionnel, • et en l'absence de l'unité (6), malgré la demande d'une portion de la première partie d'exécution (2pes) de déclencher l'exécution d'une étape dans l'unité (6), à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé (2p) n'est pas complètement fonctionnel.
3 - Procédé selon la revendication 1, caractérisé en ce qu'il consiste : dans la phase de protection (P) :
• à définir :
- un jeu de fonctions élémentaires dont les fonctions élémentaires sont susceptibles d'être exécutées dans l'unité (6) qui comporte aussi des moyens de traitement (16),
- et un jeu de commandes élémentaires pour ce jeu de fonctions élémentaires, ces commandes élémentaires étant susceptibles d'être exécutées dans le système de traitement de données (3) et de déclencher l'exécution dans l'unité (6), des fonctions élémentaires,
• à construire des moyens d'exploitation permettant de transformer l'unité vierge (60) en l'unité (6) capable d'exécuter les fonctions élémentaires dudit jeu, l'exécution de ces fonctions élémentaires étant déclenchée par l'exécution dans le système de traitement de données (3), de commandes élémentaires,
• à modifier le logiciel protégé (2p):
- en choisissant dans le source du logiciel protégé (2ps) :
> au moins un traitement algorithmique qui lors de l'exécution du logiciel protégé (2p), utilise au moins une variable choisie, et permet d'obtenir au moins une variable résultante,
> et au moins une portion contenant au moins un traitement algorithmique choisi,
- en modifiant au moins une portion choisie du source du logiciel protégé (2ps), cette modification étant telle que : > lors de l'exécution du logiciel protégé (2p) la première partie d'exécution (2pes) est exécutée dans le système de traitement de données (3) et une seconde partie d'exécution (2peu) est exécutée dans l'unité (6),
> au moins la fonctionnalité d'au moins un traitement algorithmique choisi est exécutée au moyen de la seconde partie d'exécution (2peu),
> au moins un traitement algorithmique choisi est décomposé de manière que lors de l'exécution du logiciel protégé (2p), ce traitement algorithmique est exécuté au moyen de la seconde partie d'exécution (2peu), en utilisant des fonctions élémentaires, > pour au moins un traitement algorithmique choisi, des commandes élémentaires sont intégrées dans le source du logiciel protégé (2ps), de manière que lors de l'exécution du logiciel protégé (2p), chaque commande élémentaire est exécutée par la première partie d'exécution (2pes) et déclenche dans l'unité (6), l'exécution au moyen de la seconde partie d'exécution (2peu), d'une fonction élémentaire,
> et un ordonnancement des commandes élémentaires est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé (2p), - et en produisant :
> la première partie objet (2pos) du logiciel protégé (2p), cette première partie objet (2pos) étant telle que lors de l'exécution du logiciel protégé (2p), les commandes élémentaires sont exécutées selon l'ordonnancement choisi, > et une seconde partie objet (2pou) du logiciel protégé (2p) contenant les moyens d'exploitation, cette seconde partie objet (2pou) étant telle que, après chargement dans l'unité vierge (60) et lors de l'exécution du logiciel protégé (2p), apparaît la seconde partie d'exécution (2peu) au moyen de laquelle les fonctions élémentaires déclenchées par la première partie d'exécution (2pes) sont exécutées, et à charger la seconde partie objet (2pou) dans l'unité vierge (60), en vue d'obtenir l'unité (6), -> et dans la phase d'utilisation (U) :
• en présence de l'unité (6) et à chaque fois qu'une commande élémentaire contenue dans une portion de la première partie d'exécution (2pes) l'impose, à exécuter la fonction élémentaire correspondante dans l'unité (6), de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé (2p) est complètement fonctionnel,
• et en l'absence de l'unité (6), malgré la demande d'une portion de la première partie d'exécution (2pes), de déclencher l'exécution d'une fonction élémentaire dans l'unité (6), à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé (2p) n'est pas complètement fonctionnel. 4 - Procédé selon la revendication 2, caractérisé en ce qu'il consiste : ~> dans la phase de protection (P) :
• à définir :
- un jeu de fonctions élémentaires dont les fonctions élémentaires sont susceptibles d'être exécutées dans l'unité (6),
- et un jeu de commandes élémentaires pour ce jeu de fonctions élémentaires, ces commandes élémentaires étant susceptibles d'être exécutées dans le système de traitement de données (3) et de déclencher l'exécution dans l'unité (6), des fonctions élémentaires,
• à construire des moyens d'exploitation permettant à l'unité (6), d'exécuter les fonctions élémentaires dudit jeu, l'exécution de ces fonctions élémentaires étant déclenchée par l'exécution dans le système de traitement de données (3), de commandes élémentaires,
• et à modifier le logiciel protégé (2p):
- en choisissant dans le source du logiciel protégé (2ps), au moins une étape qui lors de l'exécution du logiciel protégé (2p), réalise la fonctionnalité d'un traitement algorithmique,
- en modifiant au moins une portion choisie du source du logiciel protégé (2ps), cette modification étant telle que :
> au moins une étape choisie est décomposée de manière que lors de l'exécution du logiciel protégé (2p), cette étape est exécutée au moyen de la seconde partie d'exécution (2peu), en utilisant des fonctions élémentaires,
> pour au moins une étape choisie, des commandes élémentaires sont intégrées dans le source du logiciel protégé (2ps), de manière que lors de l'exécution du logiciel protégé (2p), chaque commande élémentaire est exécutée par la première partie d'exécution (2pes) et déclenche dans l'unité (6), l'exécution au moyen de la seconde partie d'exécution (2peu), d'une fonction élémentaire,
> et un ordonnancement des commandes élémentaires est choisi parmi l'ensemble des ordonnancements permettant l'exécution du logiciel protégé (2p), - et en produisant :
> la première partie objet (2pos) du logiciel protégé (2p), cette première partie objet (2pos) étant telle que lors de l'exécution du logiciel protégé (2p), les commandes élémentaires sont exécutées selon l'ordonnancement choisi, > et la seconde partie objet (2pou) du logiciel protégé (2p) contenant aussi les moyens d'exploitation, cette seconde partie objet (2pou) étant telle que, après chargement dans l'unité (6) et lors de l'exécution du logiciel protégé (2p), apparaît la seconde partie d'exécution (2peu) au moyen de laquelle les fonctions élémentaires déclenchées par la première partie d'exécution (2pes) sont exécutées, et dans la phase d'utilisation (U) :
• en présence de l'unité (6) et à chaque fois qu'une commande élémentaire contenue dans une portion de la première partie d'exécution (2pes) l'impose, à exécuter la fonction élémentaire correspondante dans l'unité (6), de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé (2p) est complètement fonctionnel, • et en l'absence de l'unité (6), malgré la demande d'une portion de la première partie d'exécution (2pes), de déclencher l'exécution d'une fonction élémentaire dans l'unité (6), à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé (2p) n'est pas complètement fonctionnel. 5 - Procédé selon la revendication 3 ou 4, caractérisé en ce qu'il consiste : dans la phase de protection (P) :
• à définir : - au moins une caractéristique d'exécution de logiciel, susceptible d'être surveillée au moins en partie dans l'unité (6),
- au moins un critère à respecter pour au moins une caractéristique d'exécution de logiciel,
- des moyens de détection (17) à mettre en oeuvre dans l'unité (6) et permettant de détecter qu'au moins une caractéristique d'exécution de logiciel ne respecte pas au moins un critère associé,
- et des moyens de coercition (18) à mettre en oeuvre dans l'unité (6) et permettant d'informer le système de traitement de données (3) et/ou de modifier l'exécution d'un logiciel, lorsqu'au moins un critère n'est pas respecté,
• à construire les moyens d'exploitation permettant à l'unité (6), de mettre aussi en oeuvre les moyens de détection (17) et les moyens de coercition (18),
• et à modifier le logiciel protégé (2p) : - en choisissant au moins une caractéristique d'exécution de logiciel à surveiller, parmi les caractéristiques d'exécution susceptibles d'être surveillées,
- en choisissant au moins un critère à respecter pour au moins une caractéristique d'exécution de logiciel choisie, - en choisissant dans le source du logiciel protégé (2ps), des fonctions élémentaires pour lesquelles au moins une caractéristique d'exécution de logiciel choisie, est à surveiller,
- en modifiant au moins une portion choisie du source du logiciel protégé (2ps), cette modification étant telle que lors de l'exécution du logiciel protégé (2p), au moins une caractéristique d'exécution choisie est surveillée au moyen de la seconde partie d'exécution (2peu), et le non respect d'un critère aboutit à une information du système de traitement de données (3) et/ou à une modification de l'exécution du logiciel protégé (2p),
- et en produisant la seconde partie objet (2pou) du logiciel protégé (2p) contenant les moyens d'exploitation mettant aussi en oeuvre les moyens de détection (17) et les moyens de coercition (18), cette seconde partie objet (2pou) étant telle que, après chargement dans l'unité (6) et lors de l'exécution du logiciel protégé (2p), au moins une caractéristique d'exécution de logiciel est surveillée et le non respect d'un critère aboutit à une information du système de traitement de données (3) et/ou à une modification de l'exécution du logiciel protégé
(2p),
- et dans la phase d'utilisation (U) : • en présence de l'unité (6) : - tant que tous les critères correspondant à toutes les caractéristiques d'exécution surveillées de toutes les portions modifiées du logiciel protégé (2p) sont respectés, à permettre le fonctionnement nominal de ces portions du logiciel protégé (2p) et par conséquent à permettre le fonctionnement nominal du logiciel protégé (2p), - et si au moins un des critères correspondant à une caractéristique d'exécution surveillée d'une portion du logiciel protégé (2p) n'est pas respecté, à en informer le système de traitement de données (3) et/ou à modifier le fonctionnement de la portion du logiciel protégé (2p), de sorte que le fonctionnement du logiciel protégé (2p) est modifié. 6 - Procédé selon la revendication 5, pour limiter l'utilisation d'un logiciel protégé (2p), caractérisé en ce qu'il consiste : dans la phase de protection (P) :
• à définir :
- en tant que caractéristique d'exécution de logiciel susceptible d'être surveillée, une variable de mesure de l'utilisation d'une fonctionnalité d'un logiciel,
- en tant que critère à respecter, au moins un seuil associé à chaque variable de mesure,
- et des moyens d'actualisation permettant de mettre à jour au moins une variable de mesure, • à construire les moyens d'exploitation permettant à l'unité (6) de mettre aussi en œuvre les moyens d'actualisation,
• et à modifier le logiciel protégé (2p) :
- en choisissant en tant que caractéristique d'exécution de logiciel à surveiller, au moins une variable de mesure de l'utilisation d'une fonctionnalité d'un logiciel,
- en choisissant :
> au moins une fonctionnalité du logiciel protégé (2p) dont l'utilisation est susceptible d'être surveillée grâce à une variable de mesure, > au moins une variable de mesure servant à quantifier l'utilisation de ladite fonctionnalité,
> au moins un seuil associé à une variable de mesure choisie correspondant à une limite d'utilisation de ladite fonctionnalité,
> et au moins une méthode de mise à jour d'une variable de mesure choisie en fonction de l'utilisation de ladite fonctionnalité,
- et en modifiant au moins une portion choisie du source du logiciel protégé (2ps), cette modification étant telle que, lors de l'exécution du logiciel protégé (2p), la variable de mesure est actualisée au moyen de la seconde partie d'exécution (2peu), en fonction de l'utilisation de ladite fonctionnalité et au moins un dépassement de seuil est pris en compte, -τ> et dans la phase d'utilisation (U), en présence de l'unité (6), et dans le cas où il est détecté au moins un dépassement de seuil correspondant à au moins une limite d'utilisation, à en informer le système de traitement de données (3) et/ou à modifier le fonctionnement de la portion du logiciel protégé (2p), de sorte que le fonctionnement du logiciel protégé (2p) est modifié.
7 - Procédé selon la revendication 6, caractérisé en ce qu'il consiste :
- dans la phase de protection (P) :
• à définir :
- pour au moins une variable de mesure, plusieurs seuils associés, - et des moyens de coercition différents correspondant à chacun de ces seuils,
• et à modifier le logiciel protégé (2p) :
- en choisissant dans le source du logiciel protégé (2ps), au moins une variable de mesure choisie à laquelle doivent être associés plusieurs seuils correspondants à des limites différentes d'utilisation de la fonctionnalité,
- en choisissant au moins deux seuils associés à la variable de mesure choisie,
- et en modifiant au moins une portion choisie du source du logiciel protégé (2ps), cette modification étant telle que, lors de l'exécution du logiciel protégé (2p), les dépassements des divers seuils sont pris en compte, au moyen de la seconde partie d'exécution (2peu), de manière différente, -z> et dans la phase d'utilisation (U) : • en présence de l'unité (6) :
- dans le cas où il est détecté le dépassement d'un premier seuil, à enjoindre le logiciel protégé (2p) de ne plus utiliser la fonctionnalité correspondante,
- et dans le cas où il est détecté le dépassement d'un deuxième seuil, à rendre inopérante la fonctionnalité correspondante et/ou au moins une portion du logiciel protégé (2p). 8 - Procédé selon la revendication 6 ou 7, caractérisé en ce qu'il consiste : - dans la phase de protection (P) :
• à définir des moyens de rechargement permettant de créditer au moins une utilisation supplémentaire pour au moins une fonctionnalité de logiciel surveillée par une variable de mesure,
• à construire les moyens d'exploitation permettant aussi à l'unité (6) de mettre en œuvre les moyens de rechargement,
• et à modifier le logiciel protégé (2p) :
- en choisissant dans le source du logiciel protégé (2ps), au moins une variable de mesure choisie permettant de limiter l'utilisation d'une fonctionnalité à laquelle au moins une utilisation supplémentaire doit pouvoir être créditée,
- et en modifiant au moins une portion choisie, cette modification étant telle que dans une phase dite de rechargement, au moins une utilisation supplémentaire d'au moins une fonctionnalité correspondant à une variable de mesure choisie peut être créditée, -> et dans la phase de rechargement :
• à réactualiser au moins une variable de mesure choisie et/ou au moins un seuil associé, de manière à permettre au moins une utilisation supplémentaire de la fonctionnalité.
9 - Procédé selon la revendication 5, caractérisé en ce qu'il consiste : - > dans la phase de protection (P) :
• à définir :
- en tant que caractéristique d'exécution de logiciel susceptible d'être surveillée, un profil d'utilisation de logiciel,
- et en tant que critère à respecter, au moins un trait d'exécution de logiciel,
• et à modifier le logiciel protégé (2p) :
- en choisissant en tant que caractéristique d'exécution de logiciel à surveiller au moins un profil d'utilisation de logiciel,
- en choisissant au moins un trait d'exécution qu'au moins un profil d'utilisation choisi doit respecter,
- et en modifiant au moins une portion choisie du source du logiciel protégé (2ps), cette modification étant telle que, lors de l'exécution du logiciel protégé (2p), la seconde partie d'exécution (2peu) respecte tous les traits d'exécution choisis,
-> et dans la phase d'utilisation (U) en présence de l'unité (6), et dans le cas où il est détecté qu'au moins un trait d'exécution n'est pas respecté, à en informer le système de traitement de données (3) et/ou à modifier le fonctionnement de la portion du logiciel protégé (2p), de sorte que le fonctionnement du logiciel protégé (2p) est modifié.
10 - Procédé selon la revendication 9, caractérisé en ce qu'il consiste : - dans la phase de protection (P) : • à définir :
- un jeu d'instructions dont les instructions sont susceptibles d'être exécutées dans l'unité (6),
- un jeu de commandes d'instructions pour ce jeu d'instructions, ces commandes d'instructions étant susceptibles d'être exécutées dans le système de traitement de données (3) et de déclencher dans l'unité (6) l'exécution des instructions, - en tant que profil d'utilisation, l'enchaînement des instructions,
- en tant que trait d'exécution, un enchaînement souhaité pour l'exécution des instructions,
- en tant que moyens de détection (17), des moyens permettant de détecter que l'enchaînement des instructions ne correspond pas à celui souhaité,
- et en tant que moyens de coercition (18), des moyens permettant d'informer le système de traitement de données (3) et/ou de modifier le fonctionnement de la portion de logiciel protégé (2p) lorsque l'enchaînement des instructions ne correspond pas à celui souhaité, • à construire les moyens d'exploitation permettant aussi à l'unité (6) d'exécuter les instructions du jeu d'instructions, l'exécution de ces instructions étant déclenchée par l'exécution dans le système de traitement de données (3), des commandes d'instructions,
• et à modifier le logiciel protégé (2p) :
- en modifiant au moins une portion choisie du source du logiciel protégé (2ps) :
> en transformant les fonctions élémentaires en instructions,
> en spécifiant l'enchaînement que doivent respecter au moins certaines des instructions lors de leur exécution dans l'unité (6),
> et en transformant les commandes élémentaires en commandes d'instructions correspondant aux instructions utilisées,
-^ et dans la phase d'utilisation (U), en présence de l'unité (6), dans le cas où il est détecté que l'enchaînement des instructions exécutées dans l'unité (6) ne correspond pas à celui souhaité, à en informer le système de traitement de données (3) et/ou à modifier le fonctionnement de la portion du logiciel protégé (2p), de sorte que le fonctionnement du logiciel protégé (2p) est modifié.
11 - Procédé selon la revendication 10, caractérisé en ce qu'il consiste :
- dans la phase de protection (P) :
• à définir :
- en tant que jeu d'instructions, un jeu d'instructions dont au moins certaines instructions travaillent sur des registres et utilisent au moins un opérande en vue de rendre un résultat,
- pour au moins une partie des instructions travaillant sur des registres :
> une partie (PF) définissant la fonctionnalité de l'instruction,
> et une partie définissant l'enchaînement souhaité pour l'exécution des instructions et comportant des champs de bits correspondant à :
0 un champ d'identification de l'instruction (Cil), 0 et pour chaque opérande de l'instruction : * un champ drapeau (CDk), * et un champ d'identification prévue (ClPk) de l'opérande, 49
97
- pour chaque registre appartenant aux moyens d'exploitation et utilisé par le jeu d'instructions, un champ d'identification générée (CIGV) dans lequel est automatiquement mémorisée l'identification de la dernière instruction ayant rendu son résultat dans ce registre, - en tant que moyens de détection (17), des moyens permettant, lors de l'exécution d'une instruction, pour chaque opérande, lorsque le champ drapeau (CDk) l'impose, de contrôler l'égalité entre le champ d'identification générée (CIGV) correspondant au registre utilisé par cet opérande, et le champ d'identification prévue (ClPk) de l'origine de cet opérande,
- et en tant que moyens de coercition (18), des moyens permettant de modifier le résultat des instructions, si au moins une des égalités contrôlées est fausse.
12 - Procédé selon la revendication 3, 4 ou 10 caractérisé en ce qu'il consiste : dans la phase de protection (P) : • à définir :
- en tant qu'une commande déclenchante, une commande élémentaire ou une commande d'instruction,
- en tant qu'une fonction dépendante, une fonction élémentaire ou une instruction,
- en tant qu'une consigne, au moins un argument pour une commande déclenchante, correspondant au moins en partie à l'information transmise par le système de traitement de données (3) à l'unité (6), afin de déclencher l'exécution de la fonction dépendante correspondante, - une méthode de renommage des consignes permettant de renommer les consignes afin d'obtenir des commandes déclenchantes à consignes renommées,
- et des moyens de rétablissement (20) destinés à être mis en oeuvre dans l'unité (6) au cours de la phase d'utilisation (U), et permettant de retrouver la fonction dépendante à exécuter, à partir de la consigne renommée, • à construire des moyens d'exploitation permettant à l'unité (6) de mettre aussi en oeuvre les moyens de rétablissement,
• et à modifier le logiciel protégé (2p) :
- en choisissant dans le source du logiciel protégé (2ps), des commandes déclenchantes,
- en modifiant au moins une portion choisie du source du logiciel protégé (2ps) en renommant les consignes des commandes déclenchantes choisies, afin de dissimuler l'identité des fonctions dépendantes correspondantes, - et en produisant :
> la première partie objet (2pos) du logiciel protégé (2p), cette première partie objet (2pos) étant telle que lors de l'exécution du logiciel protégé (2p), les commandes déclenchantes à consignes renommées sont exécutées, > et la seconde partie objet (2pou) du logiciel protégé (2p) contenant les moyens d'exploitation mettant aussi en oeuvre les moyens de rétablissement (20), cette seconde partie objet (2pou) étant telle que, après chargement dans l'unité (6) et lors de l'exécution du logiciel protégé (2p), l'identité des fonctions dépendantes dont l'exécution est déclenchée par la première partie d'exécution (2pes) est rétablie au moyen de la seconde partie d'exécution (2peu), et les fonctions dépendantes sont exécutées au moyen de la seconde partie d'exécution (2peu), et dans la phase d'utilisation (U) : • en présence de l'unité (6) et à chaque fois qu'une commande déclenchante à consigne renommée, contenue dans une portion de la première partie d'exécution (2pes) l'impose, à rétablir dans l'unité (6), l'identité de la fonction dépendante correspondante et à exécuter celle-ci, de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé (2p) est complètement fonctionnel,
• et en l'absence de l'unité (6), malgré la demande d'une portion de la première partie d'exécution (2pes), de déclencher l'exécution d'une fonction dépendante dans l'unité (6), à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que, par conséquent, le logiciel protégé (2p) n'est pas complètement fonctionnel.
13- Procédé selon la revendication 12, caractérisé en ce qu'il consiste : - > dans la phase de protection (P) :
• à définir pour au moins une fonction dépendante, une famille de fonctions dépendantes algorithmiquement équivalentes, mais déclenchées par des commandes déclenchantes dont les consignes renommées sont différentes,
• et à modifier le logiciel protégé (2p) :
- en choisissant dans le source du logiciel protégé (2ps) au moins une commande déclenchante à consigne renommée,
- et en modifiant au moins une portion choisie du source du logiciel protégé (2ps) en remplaçant au moins la consigne renommée d'une commande déclenchante à consigne renommée choisie, par une autre consigne renommée, déclenchant une fonction dépendante de la même famille.
14 - Procédé selon la revendication 13, caractérisé en ce qu'il consiste : -τ> dans la phase de protection (P), à définir, pour au moins une fonction dépendante, une famille de fonctions dépendantes algorithmiquement équivalentes :
- en concaténant un champ de bruit à l'information définissant la partie fonctionnelle de la fonction dépendante à exécuter dans l'unité (6), - ou en utilisant le champ d'identification de l'instruction (Cil) et les champs d'identification prévue (ClPk) des opérandes.
15 - Procédé selon la revendication 12, 13 ou 14, caractérisé en ce qu'il consiste :
- dans la phase de protection (P) : • à définir :
- en tant que méthode de renommage des consignes, une méthode de chiffrement pour chiffrer les consignes,
- et en tant que moyens de rétablissement (20), des moyens mettant en oeuvre une méthode de déchiffrement pour déchiffrer les consignes renommées et rétablir ainsi l'identité des fonctions dépendantes à exécuter dans l'unité (6).
16 - Procédé selon l'une des revendications 2 à 15, caractérisé en ce qu'il consiste : - dans la phase de protection (P) :
• à modifier le logiciel protégé (2p) : - en choisissant dans le source du logiciel protégé (2ps), au moins un branchement conditionnel effectué dans au moins un traitement algorithmique choisi,
- en modifiant au moins une portion choisie du source du logiciel protégé (2ps), cette modification étant telle que lors de l'exécution du logiciel protégé (2p), la fonctionnalité d'au moins un branchement conditionnel choisi, est exécutée, au moyen de la seconde partie d'exécution (2peu), dans l'unité (6),
- et en produisant :
> la première partie objet (2pos) du logiciel protégé (2p), cette première partie objet (2pos) étant telle que lors de l'exécution du logiciel protégé (2p), la fonctionnalité d'au moins un branchement conditionnel choisi est exécutée dans l'unité (6), et la seconde partie objet (2pou) du logiciel protégé (2p), cette seconde partie objet (2pou) étant telle que, après chargement dans l'unité (6) et lors de l'exécution du logiciel protégé (2p), apparaît la seconde partie d'exécution (2peu) au moyen de laquelle la fonctionnalité d'au moins un branchement conditionnel choisi est exécutée,
-^ et dans la phase d'utilisation (U) : • en présence de l'unité (6) et à chaque fois qu'une portion de la première partie d'exécution (2pes) l'impose, à exécuter la fonctionnalité d'au moins un branchement conditionnel dans l'unité (6), de sorte que cette portion est exécutée correctement et que, par conséquent, le logiciel protégé (2p) est complètement fonctionnel, • et en l'absence de l'unité (6) et malgré la demande d'une portion de la première partie d'exécution (2pes) d'exécuter la fonctionnalité d'un branchement conditionnel dans l'unité (6), à ne pas pouvoir répondre correctement à cette demande, de sorte qu'au moins cette portion n'est pas exécutée correctement et que par conséquent, le logiciel protégé (2p) n'est pas complètement fonctionnel. 17 - Procédé selon la revendication 16, caractérisé en ce qu'il consiste, dans la phase de protection (P), à modifier le logiciel protégé (2p) :
- en choisissant, dans le source du logiciel protégé (2ps) au moins une série de branchements conditionnels choisis,
- en modifiant au moins une portion choisie du source du logiciel protégé (2ps), cette modification étant telle que lors de l'exécution du logiciel protégé (2p), la fonctionnalité globale d'au moins une série choisie de branchements conditionnels est exécutée au moyen de la seconde partie d'exécution (2peu), dans l'unité (6),
- et en produisant : > la première partie objet (2pos) du logiciel protégé (2p), cette première partie objet (2pos) étant telle que lors de l'exécution du logiciel protégé (2p), la fonctionnalité d'au moins une série choisie de branchements conditionnels est exécutée dans l'unité (6), > et la seconde partie objet (2pou) du logiciel protégé (2p), cette seconde partie objet (2pou) étant telle que, après chargement dans l'unité (6) et lors de l'exécution du logiciel protégé (2p), apparaît la seconde partie d'exécution (2peu) au moyen de laquelle la fonctionnalité globale d'au moins une série choisie de branchements conditionnels est exécutée.
18 - Procédé selon l'une des revendications 1 à 17, caractérisé en ce qu'il consiste à décomposer la phase de protection (P) en une sous-phase de protection amont (PI), indépendante du logiciel à protéger et une sous-phase de protection aval (P2), dépendante du logiciel à protéger.
19 - Procédé selon la revendication 18, caractérisé en ce qu'il consiste, lors de la sous-phase de protection amont (PI), à faire intervenir un stade de définitions (SU) dans lequel sont effectuées toutes les définitions.
20- Procédé selon la revendication 19, caractérisé en ce qu'il consiste, après le stade de définitions (SU), à faire intervenir un stade de construction (S12) dans lequel sont construits les moyens d'exploitation.
21 - Procédé selon la revendication 20, caractérisé en ce qu'il consiste, après le stade de construction (S12), à faire intervenir un stade de pré-personnalisation (S13), consistant à charger dans une unité vierge (60), au moins une partie des moyens d'exploitation en vue d'obtenir une unité pré-personnalisée (66).
22 - Procédé selon la revendication 19 ou 20, caractérisé en ce qu'il consiste, lors de la sous-phase de protection amont (PI), à faire intervenir un stade de confection d'outils (S14) dans lequel sont confectionnés des outils permettant d'aider à générer des logiciels protégés ou d'automatiser la protection de logiciels.
23 - Procédé selon les revendications 18 et 21, caractérisé en ce qu'il consiste à décomposer la sous-phase de protection aval (P2), en :
• un stade de création (S21) dans lequel est créé le logiciel protégé (2p), à partir du logiciel vulnérable (2v),
• éventuellement, un stade de modification (S22) dans lequel est modifié le logiciel protégé (2p),
• et éventuellement un stade de personnalisation (S23) dans lequel :
- la seconde partie objet (2pou) du logiciel protégé (2p) contenant éventuellement les moyens d'exploitation est chargée dans au moins une unité vierge (60) en vue d'obtenir au moins une unité (6), ou une partie de la seconde partie objet (2pou) du logiciel protégé (2p) contenant éventuellement les moyens d'exploitation est chargée dans au moins une unité pré-personnalisée (66) en vue d'obtenir au moins une unité (6).
24 - Procédé selon les revendications 22 et 23, caractérisé en ce qu'il consiste, lors du stade de création (S21) et éventuellement du stade de modification (S22), à utiliser au moins l'un des outils d'aide à la génération de logiciels protégés ou d'automatisation de la protection de logiciels.
25 - Système pour la mise en oeuvre du procédé conforme à la revendication 20, caractérisé en ce qu'il comporte une unité de développement de programmes, servant, lors du stade de construction (S12), à effectuer la construction des moyens d'exploitation destinés à l'unité (6), prenant en compte les définitions intervenues au stade de définitions (SU).
26 - Système pour la mise en oeuvre du procédé conforme à la revendication 21, caractérisé en ce qu'il comporte une unité de pré-personnalisation (30) permettant de charger au moins une partie des moyens d'exploitation dans au moins une unité vierge (60), en vue d'obtenir au moins une unité pré-personnalisée (66).
27 - Système pour la mise en oeuvre du procédé conforme à la revendication 22, caractérisé en ce qu'il comporte une unité de développement de programmes, servant à effectuer lors du stade de confection d'outils (S14), la confection d'outils d'aide à la génération de logiciels protégés ou d'automatisation de la protection de logiciels.
28 - Système pour la mise en oeuvre du procédé conforme à la revendication 23 ou 24, caractérisé en ce qu'il comporte une unité de développement de programmes servant à créer ou à modifier un logiciel protégé (2p). 29 - Système pour la mise en oeuvre du procédé conforme à la revendication 23, caractérisé en ce qu'il comporte une unité de personnalisation (45) permettant de charger :
• la seconde partie objet (2pou) dans au moins une unité vierge (60), en vue d'obtenir au moins une unité (6), • ou une partie de la seconde partie objet (2pou) dans au moins une unité prépersonnalisée (66), en vue d'obtenir au moins une unité (6).
30 - Unité pré-personnalisée (66), caractérisée en ce qu'elle est obtenue par le système conforme à la revendication 26.
31 - Unité (6) permettant d'exécuter un logiciel protégé (2p) et d'empêcher son utilisation non autorisée, caractérisée en ce qu'elle contient la seconde partie objet
(2pou) du logiciel protégé (2p) chargée à l'aide d'une unité de personnalisation (45) conforme à la revendication 29. 32 - Ensemble d'unités (6), caractérisé en ce que la seconde partie objet (2pou) du logiciel protégé (2p), chargée à l'aide d'une unité de personnalisation (45) conforme à la revendication 29, est répartie sur plusieurs unités de traitement et de mémorisation de manière que leur utilisation conjointe permette d'exécuter le logiciel protégé (2p).
33 - Ensemble de distribution (2pd) d'un logiciel protégé (2p), caractérisé en ce qu'il comporte :
• une première partie de distribution (2pds) contenant la première partie objet (2pos) et destinée à fonctionner dans un système de traitement de données (3),
• et une seconde partie de distribution (2pdu) se présentant sous la forme :
- d'une unité vierge (60),
- ou d'une unité pré-personnalisée (66) conforme à la revendication 30, capable après chargement d'informations de personnalisation, de se transformer en une unité (6),
- ou d'une unité (6) conforme à la revendication 31.
34 - Ensemble de distribution (2pd) d'un logiciel protégé (2p) selon la revendication 33, caractérisé en ce que la première partie de distribution (2pds) se présente sous la forme d'un moyen de distribution physique, CDROM par exemple, ou sous la forme de fichiers distribués au travers d'un réseau.
35 - Ensemble de distribution (2pd) d'un logiciel protégé (2p) selon la revendication 33, caractérisé en ce que la seconde partie de distribution (2pdu), se présentant sous la forme d'unités vierges (60), d'unités pré-personnalisées (66) ou d'unités (6), comporte au moins une carte à puce (7). 36 - Unité de traitement et de mémorisation caractérisée en ce qu'elle contient la partie de la seconde partie objet (2pou) nécessaire pour transformer une unité prépersonnalisée (66) conforme à la revendication 30 en une unité (6) conforme à la revendication 31.
37 - Ensemble d'unités de traitement et de mémorisation caractérisé en ce que les unités de traitement et de mémorisation utilisées conjointement, contiennent la partie de la seconde partie objet (2pou) nécessaire pour transformer une unité pré- personnalisée (66) conforme à la revendication 30 en une unité (6) conforme à la revendication 31.
PCT/FR2002/002338 2001-07-31 2002-07-04 Procede pour proteger un logiciel a l'aide de 'variables' contre son utilisation non autorisee WO2003012649A2 (fr)

Priority Applications (18)

Application Number Priority Date Filing Date Title
UA2004010469A UA77186C2 (en) 2001-07-31 2002-04-07 Method for protecting software against unauthorized use by a controlled variable
CA002454090A CA2454090A1 (fr) 2001-07-31 2002-07-04 Procede pour proteger un logiciel a l'aide d'un principe dit de "variable" contre son utilisation non autorisee
BR0211374-0A BR0211374A (pt) 2001-07-31 2002-07-04 Processo para proteger um software vulnerável contra o seu uso não autorizado; sistema para a implementação do processo; unidade pré-personalizada; unidade que permite executar um software protegido e impedir sua utilização não autorizada; conjunto de unidades; conjunto de distribuição de um software protegido; unidade de processamento e de memorização e conjunto de unidades de processamento e de memorização
APAP/P/2004/002958A AP2004002958A0 (en) 2001-07-31 2002-07-04 Method to protect software against unwanted use with a "variable" principle
JP2003517758A JP3949107B2 (ja) 2001-07-31 2002-07-04 「変数」原理により不正使用に対してソフトウェアを保護する方法
IL15995302A IL159953A0 (en) 2001-07-31 2002-07-04 Method to protect software against unauthorised use with a variable principle
AU2002325998A AU2002325998B2 (en) 2001-07-31 2002-07-04 Method for protecting a software using a so-called variable principle against its unauthorised use
EA200400057A EA005465B1 (ru) 2001-07-31 2002-07-04 Способ защиты программы от её неавторизованного использования при помощи так называемого принципа переменной
KR1020047000804A KR100940347B1 (ko) 2001-07-31 2002-07-04 소위 변수 원리를 사용하여 소프트웨어를 불법사용으로부터 보호하는 방법
MXPA04000488A MXPA04000488A (es) 2001-07-31 2002-07-04 Metodo para proteger un software utilizando un principio llamado de variable contra su uso no autorizado.
HU0400228A HUP0400228A2 (en) 2001-07-31 2002-07-04 Method for protecting a software using a so-called variable principle against its unauthorised use
EP02760378A EP1412861A2 (fr) 2001-07-31 2002-07-04 Procede pour proteger un logiciel a l'aide de "variables" contre son utilisation non autorisee
ZA2004/00348A ZA200400348B (en) 2001-07-31 2004-01-16 Method for protecting a software using a so called variable principle against its unauthorused use
HR20040049A HRP20040049A2 (en) 2001-07-31 2004-01-19 Method for protecting a software using a so-called variable principle against its unauthorised use
NO20040232A NO20040232L (no) 2001-07-31 2004-01-19 Fremgangsmate for a beskytte en programvare, ved a anvende et sakalt variabelt prinsipp mot uautorisert bruk av den
TNP2004000012A TNSN04012A1 (fr) 2001-07-31 2004-01-19 Procede pour proteger un logiciel a l'aide d'un principe dit de "variable" contre son utilisation non autorisee
IS7121A IS7121A (is) 2001-07-31 2004-01-20 Aðferð til að vernda hugbúnað gegn óheimilaðri notkun með því að nota svo kallað breytulögmál
HK05102678A HK1070155A1 (en) 2001-07-31 2005-03-30 Method to protect software against unwanted use with a "variable" principle

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR01/10250 2001-07-31
FR0110250A FR2828305B1 (fr) 2001-07-31 2001-07-31 Procede pour proteger un logiciel a l'aide d'un principe dit de "variable" contre son utilisation non autorisee

Publications (2)

Publication Number Publication Date
WO2003012649A2 true WO2003012649A2 (fr) 2003-02-13
WO2003012649A3 WO2003012649A3 (fr) 2003-12-24

Family

ID=8866125

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2002/002338 WO2003012649A2 (fr) 2001-07-31 2002-07-04 Procede pour proteger un logiciel a l'aide de 'variables' contre son utilisation non autorisee

Country Status (29)

Country Link
EP (1) EP1412861A2 (fr)
JP (1) JP3949107B2 (fr)
KR (1) KR100940347B1 (fr)
CN (1) CN1288525C (fr)
AP (1) AP2004002958A0 (fr)
AU (1) AU2002325998B2 (fr)
BR (1) BR0211374A (fr)
CA (1) CA2454090A1 (fr)
CO (1) CO5550508A2 (fr)
CR (1) CR7231A (fr)
EA (1) EA005465B1 (fr)
EC (1) ECSP044951A (fr)
FR (1) FR2828305B1 (fr)
GE (1) GEP20053647B (fr)
HK (1) HK1070155A1 (fr)
HR (1) HRP20040049A2 (fr)
HU (1) HUP0400228A2 (fr)
IL (1) IL159953A0 (fr)
IS (1) IS7121A (fr)
MA (1) MA26126A1 (fr)
MX (1) MXPA04000488A (fr)
NO (1) NO20040232L (fr)
OA (1) OA12699A (fr)
PL (1) PL367366A1 (fr)
TN (1) TNSN04012A1 (fr)
UA (1) UA77186C2 (fr)
WO (1) WO2003012649A2 (fr)
YU (1) YU5404A (fr)
ZA (1) ZA200400348B (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2852415A1 (fr) * 2003-03-11 2004-09-17 Actikey Support de type cle, de controle de l'acces a des donnees et/ou a un logiciel et procede correspondant

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107194212B (zh) * 2017-06-21 2020-04-17 株洲中车时代电气股份有限公司 一种显示器源代码中协议内容的保护方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2634917A1 (fr) * 1988-08-01 1990-02-02 Pionchon Philippe Procede et dispositif de protection d'un logiciel, en particulier contre les copies non autorisees
US5754646A (en) * 1995-07-19 1998-05-19 Cable Television Laboratories, Inc. Method for protecting publicly distributed software
WO1999001815A1 (fr) * 1997-06-09 1999-01-14 Intertrust, Incorporated Techniques d'obscurcissement pour augmenter la securite de logiciels
WO1999066387A1 (fr) * 1998-06-12 1999-12-23 Gemplus Procede de controle de l'execution d'un produit logiciel

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2634917A1 (fr) * 1988-08-01 1990-02-02 Pionchon Philippe Procede et dispositif de protection d'un logiciel, en particulier contre les copies non autorisees
US5754646A (en) * 1995-07-19 1998-05-19 Cable Television Laboratories, Inc. Method for protecting publicly distributed software
WO1999001815A1 (fr) * 1997-06-09 1999-01-14 Intertrust, Incorporated Techniques d'obscurcissement pour augmenter la securite de logiciels
WO1999066387A1 (fr) * 1998-06-12 1999-12-23 Gemplus Procede de controle de l'execution d'un produit logiciel

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2852415A1 (fr) * 2003-03-11 2004-09-17 Actikey Support de type cle, de controle de l'acces a des donnees et/ou a un logiciel et procede correspondant

Also Published As

Publication number Publication date
EA005465B1 (ru) 2005-02-24
MA26126A1 (fr) 2004-04-01
HK1070155A1 (en) 2005-06-10
FR2828305B1 (fr) 2010-09-03
FR2828305A1 (fr) 2003-02-07
EA200400057A1 (ru) 2004-06-24
CA2454090A1 (fr) 2003-02-13
YU5404A (sh) 2006-08-17
UA77186C2 (en) 2006-11-15
PL367366A1 (en) 2005-02-21
JP3949107B2 (ja) 2007-07-25
IL159953A0 (en) 2004-06-20
CN1535410A (zh) 2004-10-06
ECSP044951A (es) 2004-04-28
OA12699A (en) 2006-06-23
KR20040027881A (ko) 2004-04-01
AP2004002958A0 (en) 2004-03-31
BR0211374A (pt) 2004-07-20
HRP20040049A2 (en) 2004-06-30
NO20040232L (no) 2004-03-30
AU2002325998B2 (en) 2008-10-30
HUP0400228A2 (en) 2004-09-28
TNSN04012A1 (fr) 2006-06-01
EP1412861A2 (fr) 2004-04-28
JP2004537806A (ja) 2004-12-16
CN1288525C (zh) 2006-12-06
MXPA04000488A (es) 2005-03-07
IS7121A (is) 2004-01-20
ZA200400348B (en) 2005-03-30
WO2003012649A3 (fr) 2003-12-24
CO5550508A2 (es) 2005-08-31
CR7231A (es) 2005-07-21
KR100940347B1 (ko) 2010-02-04
GEP20053647B (en) 2005-10-25

Similar Documents

Publication Publication Date Title
EP1238340B1 (fr) Dispositif informatique pour l&#39;application de donnees accreditives a un logiciel ou a un service
WO2003012604A2 (fr) Procede pour proteger un logiciel a l&#39;aide de &#39;renommage&#39; contre son utilisation non autorisee de diluant
EP1412862A2 (fr) Procede pour proteger un logiciel a l&#39;aide de &#34;dissociation temporelle&#34; contre son utilisation non autorisee
EP1412861A2 (fr) Procede pour proteger un logiciel a l&#39;aide de &#34;variables&#34; contre son utilisation non autorisee
WO2003012374A2 (fr) Procede pour proteger un logiciel a l&#39;aide de &#39;branchement conditionnel&#39; contre son utilisation non autorisee
EP1412838B1 (fr) Procede pour proteger un logiciel a l&#39;aide de &#34;detection et coercition&#34; contre son utilisation non autorisee
WO2003012605A2 (fr) Procede pour proteger un logiciel a l&#39;aide de &#39;fonctions elementaires&#39; contre son utilisation non autorisee
WO2008084154A2 (fr) Traitement de donnee relative a un service numerique
EP1185914B1 (fr) Procede pour securiser un logiciel d&#39;utilisation a partir d&#39;une unite de traitement et de memorisation d&#39;un secret et systeme en faisant application
WO2022238636A1 (fr) Procédé pour l&#39;exécution d&#39;un programme charge dans la mémoire non volatile d&#39;un microcontrôleur en circuit intégré
FR2781066A1 (fr) Procedure de securisation de donnees dans une machine de test de composants electroniques
EP1185913B1 (fr) Procede pour securiser l&#39;utilisation d&#39;un logiciel a partir d&#39;une unite de traitement et de memorisation d&#39;un secret et systyme en faisant application
EP3923169A1 (fr) Démarrage sécurisé d&#39;un circuit électronique
WO2020193583A1 (fr) Procédé d&#39;exécution de code sécurisé, dispositifs, système et programmes correspondants
WO2009081028A2 (fr) Plateforme et dispositif de gestion et de contrôle des droits d&#39;usage associés à un objet multimédia
CH716276A2 (fr) Procédé de traitement, au sein d&#39;un réseau blockchain et sous enclave, de données informatiques chiffrées au moyen d&#39;une application chiffrée, pour un tiers autorisé.
CH716284A2 (fr) Procédé de traitement distribué, au sein d&#39;un réseau blockchain et sous enclaves, de données informatiques chiffrées avec une clé fragmentée.
CH716277A2 (fr) Procédé de traitement, au sein d&#39;un réseau blockchain et sous enclave, de données informatiques chiffrées au moyen d&#39;une application chiffrée, sous condition de géolocalisation.
FR2910202A1 (fr) Traitement de donnee relative a un reseau de donnees
WO2002003338A1 (fr) Procede et systeme pour limiter la possibilite de transformation de donnees destinees a constituer, notamment, des jetons de pre-paiement
FR2874438A1 (fr) Methode informatique originale permettant de securiser facilement et de maniere transparente un systeme d&#39;exploitation et les logiciels qu&#39;il heberge. (s.o.s : secured operating system)

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: P-54/04

Country of ref document: YU

AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG US UZ VN YU ZA ZM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2234/DELNP/2003

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2003517758

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: DZP2003000324

Country of ref document: DZ

WWE Wipo information: entry into national phase

Ref document number: 2004/00348

Country of ref document: ZA

Ref document number: PA/a/2004/000488

Country of ref document: MX

Ref document number: 1200400052

Country of ref document: VN

Ref document number: 1-2004-500083

Country of ref document: PH

Ref document number: 200400348

Country of ref document: ZA

Ref document number: 2454090

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 1020047000804

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: P20040049A

Country of ref document: HR

Ref document number: 159953

Country of ref document: IL

WWE Wipo information: entry into national phase

Ref document number: 530683

Country of ref document: NZ

Ref document number: 20028146840

Country of ref document: CN

Ref document number: 5431

Country of ref document: GE

Ref document number: 8014

Country of ref document: GE

Ref document number: 200400057

Country of ref document: EA

WWE Wipo information: entry into national phase

Ref document number: 2002760378

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2002325998

Country of ref document: AU

WWP Wipo information: published in national office

Ref document number: 2002760378

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载