METHOD FOR REGULATING THE LEVEL OF PROTECTION OF A SOFTWARE PROGRAM
Patent Information
- Application Number
- FR2020010252
- Authority / Receiving Office
- FR · FR
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2020-10-07
- Publication Date
- 2025-02-14
- Estimated Expiration
- 2040-10-07
Smart Images
Figure 00000031_0000 
Figure 00000032_0000 
Figure 00000033_0000
Abstract
Description
Title of the invention: METHOD FOR REGULATING THE DEGREE OF PROTECTION OF A SOFTWARE PROGRAM FIELD OF THE INVENTION
[0001] The present invention relates to a method for regulating the degree of protection of an executable software program in a computer architecture.
[0002] It relates, in particular, to a generic method for protecting a software program, proposing the deployment of a protection solution in a secure execution environment potentially placed in a hostile zone. The method according to the invention applies to protection techniques aimed at countering reverse engineering attacks, attacks against program modification, attacks aimed at circumventing usage rights management devices and finally attacks exploiting software vulnerabilities. PREVIOUS ART
[0003] Software protection covers different areas and offers technical responses to counter very distinct threats produced in a coordinated or isolated manner.
[0004] In particular, it provides ad-hoc reinforcements of software programs before their deployment, through modifications or additions to them.
[0005] For protection against exploitation of software vulnerabilities, a protection solution may be directly provided in the hostile environment, as a module installed in the software execution environment. When a solution is deployed in the hostile environment, it produces systematic effects for all potentially critical situations, without exception, but without regulation with respect to a loss of performance of the software programs it protects.
[0006] In embodiments, the protection solution is provided before the software programs are compiled. In other embodiments, the protection solution is provided before these programs are deployed by modifying the executable binary code of the program.
[0007] In still other embodiments, the protection solution is not deployed in the hostile execution environment of the software that it protects. It is implemented through a software tool installed either on a server maintained within the protection solution provider and which is made available to user clients, remotely, for example at the developer or publisher of the software program, or on a server installed directly at these user clients.
[0008] For some of the aforementioned protection solutions, the protection solution implements implements proprietary techniques, operating secrets and cryptographic elements. However, exposing these elements in a hostile environment makes it easier for attackers to work, or even allows them to bypass the protection solution permanently.
[0009] It will be noted that the protection therefore intervenes before the deployment of the protected software and fixes a scheme or a degree of protection based on security objectives targeting the entirety or a more sensitive part of the software program as well as on the slowdown of the execution of this software program that is accepted up to a certain level and, necessarily, induced by the protection of the software and, secondarily, on the admissible memory consumption of the protection. These objectives and constraints are defined through execution tests of the protected software as representative as possible of the operating constraints and a typical use of the software.
[0010] However, in practice, the deployment of software programs is subject to a wide variety of situations as well as to a variation over time of the protection objectives. Taking this variety into account before deployment is imprecise and leads to freezing the protection conservatively so that it satisfies the deployment under the most restrictive conditions.
[0011] Regardless of the type of protection, a close equation links the effectiveness of the protection to its cost in terms of machine cycles and therefore slowing down of the protected software. This cost impacts the execution speed of the protected software and those located in the same environment and which share the hardware resources actually available. Beyond the increased need for processing resources by the processor, certain techniques will have an impact on the level of use of RAM, dynamically allocated by the operating system for the execution of the program. For example, remediation solutions against attacks targeting vulnerabilities weakening the integrity of the working memory area of the program, called "heap" in French and more commonly known by the English term "tas" are known to be consuming pages and memory space.
[0012] The real impact on the execution and resource consumption (processor and memory) of software (protected and not) located on the same machine is assessed differently depending on the margin available on the machine which is a function of the number of software programs executed concurrently and the level of demand and resource requirements of each of them. These two parameters vary greatly over time. Thus, if we have to fix a level of protection satisfying the most critical situation (all the software programs are active at the same time and synchronized to be all in their most demanding phase on the machine), the budget allocated to protection will be fixed at the lowest level. This low level of protection is fixed and fixed when the protection is installed and remains constant even under more frequent conditions of use (than that which gave rise to the setting of this level) which would have allowed for higher protection. The level of protection is therefore not optimal since it is defined a priori before the deployment of the software.
[0013] Recalling that protection is always accompanied by a slowdown of the software and, very often, by an increase in the need for RAM, it is ideal, for all software protections, to allow its application on the reduced functional contour identified as being the most exposed to the threat. Depending on the degree of knowledge of the software to be protected by the person in charge of its protection, this reduced contour will be defined more or less precisely. In all cases, and because not all parts of a software have the same impact on the need for resources (processor and memory), it is appropriate to have, at the level of the protection solution, sufficient granularity to allow the degree of protection to be modulated by software components.
[0014] The security objectives of a software program can vary over time and space. For example, it can be considered that the security conditions of the execution environment do not justify strong protection (or even no protection at all), particularly because protection always generates a cost to be paid in terms of resources. Conversely, the same software deployed in a more exposed environment will require its protection. The assessment of the threat can also vary over time and reflect the emergence of signals or new knowledge acquired (new type of attack identified, accentuation of the threat, etc.) requalifying the level of the threat. Depending on this perceived alert level, the security objectives will be set differently, which in practice amounts to varying the level of protection.In particular, this feedback on the threat assessment can target certain parts of the software (function, method, algorithm, parameter management, variable management, etc.) in a differentiated manner from the rest. We can therefore seek to further harden these particular parts through protection. In the state of the art, the modification of the security objectives generates a new protection project which involves the installation of a new version of the software, which obviously brings its operational complications (recording of the software data and variables before its shutdown, shutdown of the software, installation of the newly protected version, new authentication procedure, new launch of the newly protected version with consideration of the software data and variables before its shutdown, etc.).
[0015] The field of application of the invention and the current software protection techniques are presented here, according to the main types of threat.
[0016] Protection against reverse engineering and analysis (without rights and for malicious purposes)
[0017] Here, protection has three distinct objectives: the protection of industrial heritage (intellectual property), protection against the discovery of a flaw or vulnerability that can be exploited and finally in a context of electronic or cyber warfare, protection against the acquisition of intelligence on the operation of a defense, transmission or other system, by an enemy or attacker.
[0018] In his search for knowledge about the software program, the attacker aims to recover the general structure of the program (its functions, its variables and data structures, the sequence of these internal routines and finally its external dependencies). With this objective, the acquisition of the control flow graph, as precise and complete as possible, is a starting point, before carrying out a more in-depth analysis on such or such block of instructions newly identified and perceived as important. The recovery of the graph requires the simultaneous use of different techniques providing complementary information. These are static analysis, dynamic analysis and symbolic execution.
[0019] Different protection techniques are applied in the state of the art. They target specific conditions for carrying out the attack and the attacker's objectives.
[0020] First of all, it is important to know whether the attacker has the software program in the form of its source code (which greatly facilitates the analysis task) or in the form of its compiled assembly version. In fact, the analysis is simplified if the program is in its abstract form (of the target machine), i.e. produced in programming language. If the attacker has the source code, it is appropriate to produce an obfuscation by over-complexification techniques of the source code.
[0021] If the attacker has the program in its executable form (i.e. compiled in assembler of the target machine or a virtual machine of interpreted languages), it is necessary to know if the attacker can have an execution environment allowing him to carry out a dynamic analysis by using a debugger. Dynamic analysis consists of tracing, through the execution of the code, each of the executed instructions, as well as the modifications generated in the memory and the working registers of the processor, when these registers exist. The tool used for this analysis is a debugger. The debugger implements instrumentation of the program, which allows in particular to set up breakpoints in the execution of the software program. It allows to recover the trace of the execution of the code, i.e. the sequence of executed instructions and the states of the working memory of the processor associated with each instruction.
[0022] In practice, the hardware conditions allowing the use of a debugger by the attacker are relatively accessible, which makes obfuscation techniques necessary, the aim of which is to reduce the readability of the execution graph (carrying the structure of the program, its dependencies and the sequence of its own functions) but also to reduce the intelligibility of the processes and algorithms contained in the program's instruction blocks.
[0023] Conversely, if the attacker does not have this execution environment allowing him to carry out this step-by-step tracing, it remains possible to carry out the static analysis of the software program. Static analysis consists of reading and analyzing the software program "flat", that is to say, attempting to recover intelligible blocks from this software program in its executable version, i.e. the version delivered and available to the analyst, and to analyze it. Reading is carried out without resorting to executing the software program. The only tool necessary for the attacker is knowledge of the language of the software in its executable form. This may be the assembler if the analysis is carried out on a native executable, i.e. corresponding to a specific real machine, for example of the Intel™ X86 or ARM™7 type, or a bytecode for an interpreted language corresponding to a virtual machine such as Java™ or .NET™.
[0024] To facilitate static analysis, it is possible to produce transformations in the software program in its executable form in order, for example, to have a more abstract form of this software program and to get closer to the program in its source code form. This is done using a decompiler or through analysis tools exploiting and applying symbolic execution on certain parts of the software or finally by the use of heuristic-based tools to find similarities in the sequences of instructions, more or less long and presenting more or less variation.
[0025] Methods are known that can counter attacks using static analysis of a software program. These methods tend to ensure that the software program is never found "in clear" in memory. The program (its so-called "text" section) is therefore encrypted, as one would encrypt data. However, if the encryption techniques prohibit static analysis, the program will be decrypted for its execution. Code encryption therefore does not provide total defense but only on the stored file of the program and a very relative defense when the program is in its execution environment. Via dynamic analysis, the attacker can point to the state of the memory corresponding to the decrypted file and recover it to produce an analysis of the program then "in clear". Encryption techniques naturally always cause a slowdown in the startup phase but this slowdown is limited to this phase only.
[0026] Methods are also known which make it possible to counter attacks proceeding by dynamic analysis of a software program. However, whatever these methods, it will be noted that, as soon as it is possible to have on the machine a debugger, it is impossible to prohibit such analysis completely. Obfuscation methods have relative objectives in that they allow the level of effort required to be slowed down or made prohibitive. Some methods propose to block the use of debuggers but they are penalizing for legitimate users and ineffective, because they can be circumvented. In practice, to counter dynamic analysis, it is necessary to slow it down sufficiently. We will seek to make the realization of reverse engineering prohibitive by a colossal increase in the size of the code to be traced and, as far as possible, without it being possible to reduce this size by using previously acquired analysis results. To do this, the methods according to the prior art very often propose at least generating a certain variability in the generation of this code.
[0027] Methods using software program obfuscation make static and dynamic analyses much more complex. Some of these methods propose obfuscating the code by producing predefined transformations on it and by substituting sequences of the initial code with more complex sequences. Other methods propose encrypting certain blocks of the executable code. Such methods using partial encryption, however, require that the encrypted code be decrypted before execution. Other code virtualization methods consist of transcribing the original code into a syntax unknown to the attacker and decoded on the fly by a set of interpreters loaded in memory, which by nature leads to a total destructuring of the graph and a massive increase in the number of instructions to be traced by the attacker.Other methods consist of inserting opaque predicates producing results known in advance at the output of a long and complex processing chain. Other methods are known to flatten the execution graph by a series of transformations resulting in a strong graph destructuring or exploiting the principle of return-oriented programming (or jump or call) or to generate code evolving at execution. In all cases, obfuscation methods mechanically cause a slowdown of the software, in particular because their objective is to extend the number of instructions executed for a given function. If the obfuscation technology is well designed, it should result in an increase in the attacker's effort (to achieve sufficient knowledge of the software, all other things being equal) in relation to the number of instructions inserted.
[0028] We know the methods introduced more recently and based in particular (but not only) on new architectural arrangements offered directly on the new processors. In practice, these techniques exploit the encryption applied to memory pages reserved for the remote part of the software and which are not accessible to any other component than the remote part itself. This This exclusion also applies to the operating system managing the software. The attacker will never be able to access these pages to produce his analysis. These latter techniques are promising and achieve a higher level of security at a lower machine cost than obfuscation techniques. Their use remains relatively confidential or in the domain of security experts, in particular because they (for the most emblematic of them: Intel™ SGX enclave and ARM TrustZone™) require the prior acquisition of specific knowledge for their use as well as a modification of the source code by the insertion of new instructions and a new compilation. Furthermore, and above all, these techniques have not been standardized and are distinguished by different (and exclusive) approaches and are incompatible with each other, which imposes a choice of processors for the deployment of the protected software on those who use them.This last factor is highly penalizing.
[0029] Protection against modification (without right and for malicious purposes)
[0030] The protection here aims to detect modifications or obstacles to the implementation of these modifications. The attacker's modifications aim to divert the original operation towards a desired operation. Emblematically, software routines for managing user rights are ideal targets for modification. We will seek to render the rights validity tests they carry out obsolete.
[0031] We know the encryption method which prohibits the production of modifications on the encrypted file (stored on disk or a storage unit). However, this encrypted file will be decrypted when the software is launched and modifications will then be possible, for those who have access to the pages of the active memory of the processor in which the software was loaded before its execution.
[0032] Other techniques are known which consist of modifying the software by the automated insertion of self-checking routines, these routines producing a reading at an address of the memory pages of the loaded software program and where a known a priori result is assumed to be, because corresponding to the original software. The density of these checks, the variability in the sequence of instructions produced from one test to another and their degree of deep integration in the operation of the software are three metrics qualifying the effectiveness of such solutions. The higher the density of these tests, the lower the false negative rate (the modified software is not detected as such) but the higher the loss of performance of the software.
[0033] We know the technique of placing software in a trusted environment, as proposed by processor suppliers. The guarantee of protection against modification is very high, particularly for the most emblematic of these technologies, the Intel™ SGX enclave.
[0034] Finally, we know the techniques that allow us to calculate a hash value ("hash" in English) on the content of the pages of the software program once loaded and to verify, as it is executed, its stability. To avoid replay attacks, these techniques implement a challenge that varies from one verification to another and for which the attacker necessarily lacks cryptographic hardware. It should be noted that the result of these techniques is a simple boolean or a bit of information: the software has not been or has been modified. Between two authentication tests, the software can be modified and then restored to its original state by the attacker. The frequency of these tests and the unpredictable nature of these tests are two conditions for effectiveness. Here again, the frequency of these tests goes hand in hand with the loss of overall performance of the protected software. Protection against unauthorized use
[0035] Verifying the user rights of a software program is based in practice on the insertion of a specific routine performing the necessary checks on various technical criteria such as the recovery on a personal computer, of a token or the machine identification data. This external routine must also be difficult to locate (and present a very large variety in its implementations), be closely linked to the operation of the software and not be simply short-circuited (by modification). The rights management routine, because it is known a priori as a relatively invariant device under the attacker's analysis, must have the highest level of obfuscation and protection against modification. The minimum bias consists of placing this routine at the entry point of the program. However, this is the attacker's first area of analysis.It will be necessary to repeat the insertions and therefore the tests throughout the execution of the software, which can therefore take place anywhere, forcing the attacker to perform a much longer analysis but with the disadvantage of a loss of software performance. Here again, the increase in security goes hand in hand with the loss of performance. Finally, we know the technique of placing a rights management routine in a trusted environment. If the rights management itself will not allow modification, its interface with the software located outside the trusted environment is the weak link. The rights test must not result in binary information (rights are acquired or no rights) which allows modifications to be made to reverse this result passed to the software located outside the trusted environment.For this solution to be effective, it is again necessary to multiply and camouflage the software's uses of the results of these rights tests, thus returning to the general case of ambivalence between efficiency and loss of performance.
[0036] Protection against exploitation of vulnerabilities
[0037] The vulnerabilities consist of coding errors that are essentially concentrated on a poor definition of memory reserves (buffer) for the variables of the software program, and which have, for the most part, originated from the developments in C language whose underlying routines are found in other programming languages. These coding errors would have little effect if current processors did not mix data and instruction addresses in their execution stack. By a simple insertion a priori benign truncated data, the attacker can overflow the buffer and come to write the address of the next instruction to be executed, where a malicious software program will have been previously introduced (virus). Other more elaborate techniques make it possible to avoid resorting to other software and to use duly chosen and chained sequences in the original software program to divert the operation of this program.Vulnerability exploitation is a broad technical field encompassing several fronts (modus operandi of attacks) and remediations (parades). In the vast majority of cases, the attack causes a deviation in the control flow of the original software program, either by modifying the return addresses of the called functions or by modifying the addresses of jumps to functions (internal or external) to the software.
[0038] We know the techniques for verifying the integrity of the control graph consisting of inserting reserves of random size for functions of the software program, either by a device called "tokenization" (allocation of tokens) of the return addresses, or by the insertion of "Canaries" or finally by the insertion of routines for verifying the jump addresses in a list of addresses deemed legitimate. Apart from future hardware techniques (such as "shadow stack" (hidden stack) from Intel™), purely software techniques are always constrained by a loss of performance, increasing with the efficiency of the measurement. All of the very numerous scientific publications on this subject always expose the loss of performance (assumed acceptable by the authors) to attest to the relevance of the innovative techniques exposed in these publications. The loss of performance is shown in this field again to be inseparable from efficiency.Yet here again, no publication reports automated regulation of mechanisms linked to measurements characterizing the execution speed of the protected software program. Note that publications report monitoring of the software at its execution to allow, using several techniques, the detection of an operating anomaly potentially linked to an attack. Monitoring at execution contributes to detection without serving as a lever to regulate it.
[0039] The implementation of the aforementioned methods can be carried out at different stages in the generation chain of the executable program and, in particular, at the stage of development of the source code by the developer, more particularly at the stage of its compilation by means of a specific compiler which produces the obfuscation and generates the sequences of obfuscated code, or at a more advanced stage, where we have the software program itself, in an executable form.
[0040] Furthermore, the implementation of these methods can be carried out for native software program generation chains, i.e. resulting from a binary code structured for a particular processor, or for an interpreted language generation chain such as the Java™ or .NET™ language. Summary of the invention
[0041] Considering the above, a problem that the invention proposes to solve is to provide a method for regulating the degree of protection of an executable software program in a computer architecture, with a view to adjusting the degree of protection of the execution of this software program, according to the observed execution conditions of said program, for example with a view to increasing the execution speed of this program, in the case where this speed is not sufficient or reducing its memory footprint, in the context in which the program is executed.
[0042] The proposed solution of the invention to this problem posed has as its object a method of regulating the degree of protection of an executable software program in a computer architecture comprising the following steps:
[0043] an initial software program, means for protecting said initial software program, and a security module are provided, said module ensuring the regulation of the protection of said software program;
[0044] a static analysis of the initial software program is carried out, said static analysis comprising an identification of components of said software program;
[0045] the initial software program is modified to obtain a modified software program so that the security module collects monitoring data relating to the execution times or frequencies or to a RAM footprint of the components identified during the static analysis of the software program;
[0046] the modified software program is executed in the computer architecture;
[0047] the security module collects monitoring data relating to the execution times or frequencies or the memory footprint of the components identified during the static analysis of the initial software program, during the execution of the modified software program; and
[0048] the security module processes the collected data and dynamically regulates the degree of protection of the modified software program according to the collected and processed monitoring data, during the execution of said modified software program.
[0049] Advantageously, - the modified software program, which is executed in the computer architecture, is a software program which is protected by the protection means prior to its execution or during its execution, according to a degree of given protection, and according to which, after processing the data collected by the security module, the degree of protection is dynamically modified by the security module, according to the monitoring data collected and processed; - the software program is modified by inserting, in said program, monitoring probes, said probes generating the monitoring data collected by the security module; - the software program is modified by intercepting jumps or branches in said program, and pointing to the components identified by their addresses, by a branch or call to the security module; and during the execution of the software program, the security module makes the branches or jumps to the addresses of said components; - a trusted environment is provided, for the secure execution of software programs; the security module is placed in said trusted environment;identified components of the software program are extracted; said components are placed in the trusted environment; and non-extracted components of the software program are executed outside the trusted environment and extracted components of the software program are executed in the trusted environment, under the control of the security module; - the security module dynamically regulates the degree of protection by varying the frequency or the conditions for carrying out the protection of the software program;- the modified software program comprises a plurality of iso-functional components, these iso-functional components being protected according to different degrees of protection or according to their location in or outside a trusted environment, and the security module dynamically regulates the protection by choosing to execute one iso-functional component rather than another according to its degree of protection or its location in or outside a trusted environment; - the iso-functional components protected according to different degrees of protection or according to their location in or outside the trusted execution environment, reside in an encrypted form in the modified program and their decryption is produced by the protection module when they are selected by said module;- the means of protection are means of protection proceeding by obfuscation of components, encryption of components, integrity verification, by emulation of instructions, by insertion of elements making it possible to remedy certain vulnerabilities, by memory segregation and / or by placement of a component in a trusted hardware execution environment; - the means of protection are means proceeding by obfuscation of components; - the method further comprises the following steps according to which: a metadata file is established describing the components identified during the static analysis of the software program; each of the identified components is assigned security level parameters such as protection thresholds or consumption limits in processor cycles or memory size; provides the metadata file to the security module; and the security module dynamically regulates the degree of protection of the software according to the parameters assigned to the components contained in the metadata file; - each of the identified components is assigned an initial protection mode and / or a minimum security level and / or maximum limits for the consumption of processor and / or memory resources; - the static analysis is performed on an uncompiled software program; and the components identified during the static analysis are functions, instruction blocks, routines and / or subroutines of the software program;- the modifications of the initial software program are carried out by software program analysis and modification software, and according to which said software program analysis and modification software is delivered in the hardware or software trusted execution environment associated with the protected software program, in a hostile environment; - the architecture comprises an operating system, said operating system ensuring the management of the software program and integrating the software program analysis and modification software; and - the architecture further comprises machine learning decision-making means, said means being involved in regulating the degree of protection of the software program.
[0050] Thus, and in particular, the method according to the invention makes it possible to ensure that this dynamic regulation cannot, in its implementation, allow targeted attacks on itself with the aim of leading to a reduction in the level of protection on the program. It allows a remote operator, whether human or trained by an automated process, to modify the level of protection, the protection functions, the protection modes to be applied to the program. This dynamic redefinition makes it possible to adapt the protection objectives using knowledge of the state of the threats and their criticality at a given time. It is initiated remotely and implemented in a software protection module, located in the software execution environment.The method is such that the dynamic redefinition of security objectives cannot, through its technical implementation, allow targeted attacks aimed at interfering with the data exchanged or their processing by the protection module. BRIEF DESCRIPTION OF THE FIGURES
[0051] The invention will be better understood on reading the following non-limiting description, drawn up with reference to the appended drawings, in which:
[0052] [Fig. 1A] [Fig. 1A] is an example of a structure of an initial software program in assembler, formed of three blocks of instructions linked by two successive jumps to two addresses pointing to two successive blocks, for the implementation of the method according to the invention;
[0053] [Fig.lB] [Fig.lB] is a diagram which describes an embodiment of the method according to the invention, in which the recovery of the tracking metrics is carried out by inserting probes into the components identified in the code of the software program, the probes communicating said metrics to the protection module during the execution of the software program;
[0054] [Fig.lC] [Fig.lC] illustrates the embodiment of [Fig.lB], showing the various elements involved in this embodiment;
[0055] [Fig. 1D] [Fig. 1D] is a diagram which describes another embodiment of the method according to the invention, in which the recovery of the monitoring metrics is carried out by modifications of addresses of components identified in the software program, the modified addresses pointing to the security module which takes control of the execution flow of the program, that is to say the sequence of the execution of the different components of the program and, consequently, an embodiment in which the recovery of the monitoring metrics by taking control of the management of the execution flow carried out directly in a protection module;
[0056] [Fig.lE] [Fig.lE] illustrates the embodiment of [Fig.lD], by showing the interactions between the protected program and the protection module which produces for each of its calls a jump (return) address corresponding to the correct component in the program;
[0057] [Fig.2A] [Fig.2A] schematizes the initial state of a statistics file which results from the static analysis according to the method according to the invention, capable of identifying the different components by their names (delivered by the symbol file) and / or their relative addresses in the program. At this initial stage, the data on resource consumption and processing time are incomplete as shown in the figure;
[0058] [Fig.2B] [Fig.2B] shows schematically the continuous acquisition - over successive executions - of the statistics file serving as a basis for self-regulation;
[0059] [Fig.3] [Fig.3] schematizes an embodiment of the method according to the invention in which a protection server is placed in a non-hostile environment while the protection module, which performs the self-regulation of the protection, is placed in a hostile environment. The metadata file of the protection project also appears, itself protected for its transfer from the non-hostile environment to the hostile environment. The protection server produces the protected version of the software program and which executes partly in the normal environment and partly in the trusted environment;
[0060] [Fig.4A] [Fig.4A] schematizes an embodiment of the invention in which a protection server is arranged in a hostile environment, but nevertheless placed in a trusted execution environment;
[0061] [Fig.4B] [Fig.4B] schematizes an embodiment of the invention in which the protection server is integrated into the operating system of the system deployed in a hostile environment;
[0062] [Fig.5A] [Fig.5A] schematizes the flow of steps of an embodiment of the method according to the invention in which the protection server is not integrated into the operating system, before and after the deployment and self-regulation of the protection at runtime or by modification of the protection project by the operator;
[0063] [Fig.5B] [Fig.5B] schematizes the flow of steps of an embodiment of the method according to the invention in which the protection server is integrated into the operating system which produces upon receipt of the initial program all the operations of analysis, protection and regulation of the protection during execution, while allowing modification by an external operator of the protection project at any time during the execution of the program;
[0064] [Fig.6A] [Fig.6A] illustrates the distribution of the protected program and its added components - the protection module - between the normal and trusted execution environments, when implementing an embodiment according to the invention. The figure shows the distribution of the execution of the functions or blocks of instructions or components of the program possibly in the two normal and trusted execution environments and their sequencing carried out by the protection module;
[0065] [Fig.6B] [Fig.6B] illustrates the distribution of the protected program and the operating system modules integrating the server and the protection regulation module placed in a trusted environment and which ensures the regulation of the protection and the execution of the program components in one or other normal or trusted execution environment, during the implementation of an embodiment according to the invention;
[0066] [Fig.7A] [Fig.7A] diagrams a software-type trusted environment for implementing an embodiment of the method according to the invention, and specifies what this means for software techniques;
[0067] [Fig.7B] [Fig.7B] schematizes a hardware-type trusted environment for implementing an embodiment of the method according to the invention, and specifies what this means for hardware techniques; and
[0068] [Fig.8] [Fig.8] schematizes the content of a metadata file of a protection project and which includes for each of its components or functions or instruction blocks, the characteristic data of the protection mode and its configuration as well as the thresholds (minimum protection level) and the resource consumption limit for this component. This metadata file contains the critical data on the protection of the software and therefore requires cryptographic protection as schematized by the padlock shown in this figure. DETAILED DESCRIPTION OF THE INVENTION
[0069] The invention relates to a method for regulating the degree of protection of an executable software program in a computer architecture. The purpose of this method is to produce real-time regulation of protection of the execution of the software program, in order to optimize said execution.
[0070] In an exemplary embodiment, the computer architecture is an architecture comprising one or more servers having different physical resources and, in particular, one or more processors, as well as associated RAM, one or more storage memory spaces, for example of the Flash or hard disk type, all being managed by an operating system, a security module, this module being formed by a software component executing by means of the processor and the RAM.
[0071] An initial and / or modified software program is protected by means of protection of the software program according to the invention are means of protection proceeding by obfuscation of components, encryption of components, verification of integrity, by emulation of instructions, by insertion of elements making it possible to remedy certain vulnerabilities, by segregation of memory and / or by placement of a component in a secure hardware execution environment.
[0072] Generally, the method according to the invention comprises the following steps according to which: - an initial software program, means for protecting said software program, and a security module are provided, said module ensuring the regulation of the protection of said software program; - a static analysis of the initial software program is carried out, said static analysis comprising an identification of components of said software program; - the initial software program is modified in order to obtain a modified software program so that the security module collects monitoring data relating to the times or frequencies of execution of the components identified during the static analysis of the software program; - the modified software program is executed in the computer architecture;- the security module collects monitoring data relating to the execution times or frequencies of the components identified during the static analysis of the software program, during the execution of said modified software program; and - the security module processes the collected data and dynamically regulates the degree of protection of the software according to the monitoring data collected and processed, during the execution of said software program.
[0073] Thus, the method according to the invention implements monitoring or, in other words, surveillance of the execution of the modified software program, once protected to allow adjustment of the protection.
[0074] An example of a structure of an initial software program is shown in [Fig.lA]. This program is written in assembler. It is formed of three blocks of instructions linked by two successive jumps to two addresses pointing to two successive blocks.
[0075] For carrying out monitoring, the method according to the invention can be implemented according to different embodiments.
[0076] A first embodiment is illustrated in Figs. 1B and 1C. In this embodiment, the initial software program is modified by inserting monitoring probes into said program. These probes generate monitoring data collected by the security module. In this embodiment, probes placed in the original software program are thus implemented in an ad hoc manner. These probes are placed to enable the emission of a message or data marking each passage during execution in the block of the program in which they are located. These probes are sequences of a few instructions, automatically grafted into the prologues, epilogues or any other part of a function or block of instructions.Two probes can in particular be arranged in a function or a functional block, in particular to enable the execution time of the part considered to be measured, by measuring the difference between the passage times in these two probes.
[0077] The placement of the probes can be carried out in a fully automated manner, according to a rule predefined by the operator, or in a semi-automatic manner. This rule can be, for example, to place a probe at the prologue and a probe at the epilogue of each block of instructions or each function. In particular, if a binary code is available, i.e. in the executable form of the software program, it is possible to directly produce the modifications on this binary for the insertion of these probes at the appropriate locations. The insertion of these probes can be carried out before or after application of the software protection means, on the software in its original or protected version.
[0078] To do this, a static analysis of the binary code is first produced to recover its execution graph. This graph corresponds to the structure of the software in independent functional blocks called successively or conditionally. [Fig.lB] presents a typical graph as recovered by an analysis tool. This division into functional blocks is the structure of the self-regulation, carried out for each of these blocks. In the same way, if the source codes are available, the static analysis of the code and the automatic placement of the probes makes it possible to have an ever greater granularity to allow self-regulation.
[0079] A second embodiment of the method according to the invention is illustrated in Figs. 1D and 1E. In this second embodiment, the initial software program is modified by changing original addresses contained in said program so that that these addresses, which point to components identified in the original software program, are modified by an address of the security module. When executing the software program, the security module then makes the jumps to the original addresses of said components.
[0080] This second mode goes beyond the placement of probes in the original software program. It involves the transfer of the calculation of branch addresses for the block-to-block chaining, this calculation being carried out by the protection module. If the protection does not modify the functionality of the software program in any way, on the other hand, the analysis tools - disassembler-debugger and its execution graph generation tools - can no longer produce the execution graph. The structure of the program as it appears with the original is lost. This second embodiment therefore produces a complementary security function in that it reduces the program graph. As an example, it will be noted that the graph in [Fig.lE] corresponds to the graph after modification. The "verticalization" of the graph in [Fig.lE] results from the fact that all the block jumps converge towards a single address, that of the protection module.
[0081] The protection module is, in this second embodiment, capable of following the execution flow of the software program, block by block, to derive individualized statistics for the independent sub-parts - or identified components - of the program. This information, which is collected monitoring data relating to the times or frequencies of execution of the components or the size of their memory footprint, is then used to measure, in real time, the individual impact of the parts of the software program so as to implement fine and individualized regulation of the degree of protection of the software program.The technique consists of simply intercepting all or part of the branches of the original software program made by conditional or fixed jumps to their individual address, defined in relative or absolute value, by a call to the protection module which can give it the initial value of these addresses, using data acquired during the static analysis of the program and additional ad hoc means implemented for each call. It is then possible, for this security module, to set up increments and a clock making it possible to measure the frequency of calls to a block and the time necessary for its execution, namely the time measured between two successive jumps corresponding to the block of instructions.
[0082] Note that regulating the degree of protection, to be effective, requires obtaining granular information on different components of the software program. This dynamic regulation is produced on real data and no longer defined a priori on estimates. It is produced in a protection module located in the execution environment of the protected program and which interacts with the protected program. Depending on the type of deployment, the protection module directly integrates the protected program.
[0083] With the two embodiments of the method according to the invention set out above, the protection module carries out the collection of these statistical monitoring data and the decision-making on regulation, in a trusted environment.
[0084] The invention therefore exploits the concept of a trusted execution environment, which allows both self-regulation and modification of the remote protection profile to be applied while minimizing the risks associated with circumventing these sensitive points (because they influence the security policy).
[0085] In practice, the method according to the invention is likely to be implemented in two general types of trusted environments. These are software trusted environments and hardware trusted environments. Hardware trusted environments offer, in the current state of knowledge, an increased level of security and form the preferred scheme of the method according to the invention. In this case, the self-regulation decision-making is beyond the reach of the attacker. Software-type trusted environments can be of different natures and result from sophisticated software obfuscation techniques such as, for example, code virtualization or memory segregation type offered by the operating system.Hardware-based trusted environments result directly from encryption and memory access management operations performed by the processor, such as the SGX enclave technology supported by new types of Intel™ processors.
[0086] In addition, the method according to the invention also provides for dealing with attacks by poisoning or deviation of the behavior of the protection regulation. These do not modify the protection module but inject data into it or cause a modification of the behavior of the protected software so that the decision-making is oriented towards a lower level of protection. In order to counter this deviation, the invention provides for allowing the operator to force, for certain more sensitive functions, a maintenance of the protection level at a minimum protection threshold which cannot be reduced by the regulation.
[0087] Another variant of implementation of the method according to the invention proposes that the extraction of statistics and the continuous redefinition of the protection exploits the mechanisms of machine learning and in particular by reinforcement learning. The decision-making involves a reinforced learning device ("reinforcement machine learning" in English). Such a device makes it possible to increase the relevance of the decisions taken by a continuous and increasing acquisition of data collected over the course of the different executions of the program. It makes it possible to to deal with attacks by poisoning or deviation of behavior from the regulation detected and dismissed for some of them, presenting too divergent a character.
[0088] The protection module comprises at least one functionality ensuring the control or tracking of the constituent elements of the execution graph of the protected original program. This functionality ensures self-regulation during execution. It makes it possible to reduce or tighten the strategy, techniques and parameterization of these protection techniques according to measurement points characterizing the degree of demand, namely the frequency of calls, the execution time, the memory reserve of the protected parts or blocks of instructions integrating these protected parts. Figs. 2A and 2B present the statistics file enriched during successive executions.
[0089] In certain variant embodiments of the method according to the invention, a trusted environment is provided for the secure execution of software programs; the security module is placed in said trusted environment; identified components are extracted from the software program; said components are placed in the trusted environment; and non-extracted components of the software program are executed outside the trusted environment and extracted components of the software program are executed in the trusted environment, under the control of the security module.The method according to the invention then implements a step of protecting an initial software program based on sharing the execution of the protected program between its normal execution environment and a trusted execution environment and which comprises both sub-parts of the initial program and at least the protection module, which ensures the regulation of the degree of protection of the software program. The part of the program executing in the trusted environment is, depending on the type of trusted environment, defined, by means of software or hardware techniques, during deployment, either totally preserved or less exposed to reverse engineering, modification or exploitation of vulnerabilities attacks.
[0090] In certain variants of the invention, the analysis, modification for protection and protection regulation functions are directly integrated into the operating system of the host system in which the software is executed. In these variants, the software can thus be deployed without protection. The protection is in fact directly produced by the operating system before or after its launch. In this variant, a metadata file is advantageously provided by a security operator or orchestrator. This metadata file can specify certain characteristics of the protection profile.
[0091] Figs. 3, 4A and 4B show two examples of deployment of these alternative embodiments. In these examples, a protection server and a memory file are provided. tadata. The server performs protection according to a protection project defined either by an operator or by an automated security orchestrator, which can be found in particular in cloud-type environments or in software-defined telecom networks (Software Defined Networks). The protection project results in a version of the protected software program and, in addition, the metadata file characterizing the protection project. Two execution environments collect all or part of the protected program and the protection module.According to the invention, a metadata file is established describing the components identified during the static analysis of the software program; each of the identified components is assigned security level parameters (current or minimum-maximum thresholds) or maximum resource consumption thresholds (processor, memory); the metadata file is provided to the security module; and the security module dynamically regulates the degree of protection of the software according to the parameters assigned to the components contained in the metadata file. Figs. 4A and 4B differ from [Fig. 3] in that the protection server is directly provided in the hardware trust environment, preferably deployed in a hostile environment, where the protected software program is executed.The protection server is directly inserted into the protection module, potentially installed in a hostile environment and replaces and integrates the functions of the protection module (recovery of statistics, self-regulation of security functions). In [Fig.4B], the operating system includes at least the protection server and the protection module, said module possibly being integrated into the protection server.
[0092] In an alternative embodiment, a secure communication channel is established between the protection server and the secure protection environment, enabling secure transmission of data, for example by using the Diffie-Hellmann type key exchange protocol. Via this channel, the “metadata” file can be retrieved, including in particular both data such as the modified parts of the software program and data characterizing the protection settings as well as the protection modes used. This file reflects the protection as implemented in the original version of the protected software program or at any later time corresponding to the consideration of new security objectives defined by the operator.
[0093] Upon receipt of a new metadata file and after having verified its origin and integrity, the data is used by the protection module. Thus, it is possible, in the trusted environment, to modify the protection profile according to the new metadata file received. Depending on the protection modes concerned by these changes, the modification may be produced during the execution of the program or its next launch.
[0094] As illustrated in Figs. 5A and 5B, the method according to the invention comprises the following steps according to which:
[0095] - the original software program is provided in its source or binary version or bytecode for interpreted languages;
[0096] - we produce, at the level of the protection server, the modifications on this program software resulting in the distribution of its execution in the two execution environments, namely the so-called normal environment and the so-called trusted environment, of parts of the program protected or not, and the production of a protection module integrating different security functions external to the program and which is placed in the trusted environment.
[0097] In [Fig.5A], the protection server is not integrated into the operating system, before and after the deployment and self-regulation of the protection at runtime or by the modification of the protection project by the operator. In [Fig.5B], the protection server is integrated into the operating system which produces upon receipt of the initial program all the analysis, protection and regulation operations of the protection at runtime, while allowing modification by an external operator of the protection project at any time during the execution of the program. The preliminary protection phase, which includes the steps of supplying the initial software program, static analysis, and production of the protection project with production of the metadata file, is carried out by the operating system.
[0098] As shown in [Fig. 6A], the distribution of functions in the two types of environment, their levels of protection, vary according to the protection strategies envisaged. At the simplest level, the entire initial program can be placed in the normal environment, having carried out the minimal operations during protection for the insertion of probes or to deport the dynamic management of its control flow in the secure environment. At the other end, at the maximum protection level, all functions will be placed in a hardware trusted environment. As shown in [Fig.6B], the operating system comprises a trusted execution environment, the security module being placed in this trusted environment, for the implementation of the execution flow control, of the routine for extracting statistics such as call frequency statistics or execution duration statistics per function or block of instructions.
[0099] As illustrated in Figs. 7A and 7B, depending on the type of trusted execution environment targeted, namely a software or hardware environment, the protection server generates the trusted protection environment itself, by software techniques of the obfuscation or anti-modification type, an example of which is code virtualization, or segregation, or else, the software intended to integrate a hardware Trusted Execution Environment (TEE). In one example, the TEE leverages hardware techniques based on features of new processors such as Intel™ SGX enclave, ARM™ trustzone, or equivalents offered by other processor vendors or by vendors of hardware frameworks that leverage these features.
[0100] Thus, in an alternative embodiment of the method according to the invention, the secure execution environment uses techniques of obfuscation and / or protection against modification all based exclusively on software techniques of all kinds, such as code virtualization, instruction emulation, transposition of the initial code into an intermediate representation, graph flattening, verification of integrity at execution of parts or of the entirety of the code. The protection means are, in one example, protection means proceeding by obfuscation of components or by placement of a component in a secure execution environment.
[0101] In the case where the trusted execution environment is based on software techniques, the obfuscation techniques implemented offer a very wide range with numerous techniques from the simplest to the most complex. Thus, the trusted environment can be reduced to the implementation of obfuscation techniques on the entirety or certain software parts of the protection module. This implementation of obfuscation techniques constitutes de facto the software trusted execution environment. These techniques must reinforce the security of the protection module.
[0102] Finally, one can also use the memory segregation offered by certain operating systems to place the protection module in a separate and inaccessible memory compartment.
[0103] In the case where the secure execution environment is of the hardware type, the method according to the invention proposes to house, in this environment, the protection module comprising the various security functions and at least the monitoring and self-regulation functionalities, according to the two modes proposed by the invention. In addition to the protection module, some or all of the functions or instruction blocks of the program can be housed in the secure execution environment.
[0104] At the end of its processing, the protection server delivers the protected software in a packaged or separate manner for the two components integrating the normal or trusted execution environments, as well as a metadata file associated with the protected software and including all the descriptive data of the protection scheme. (protected program functions, type of execution environment, protection mode per function, setting of these modes per protected function, admissible resource consumption thresholds, per instruction block, etc.) as well as the data characterizing the program (identification data of functions and functional blocks, identifying instructions involved in the management of the control graph, i.e. jump instructions (conditional or non-conditional) linking the functions (internal or external) together and structural data on the execution graph (addresses of functions or instruction blocks). This metadata file is protected by its signature and the classic authenticity verification mechanism using hash calculation and asymmetric encryption.
[0105] Finally, in the same way, the protection server advantageously delivers a signature of the protected software program and a public key allowing subsequent authentication control and verification of the identity of the version of this protected software program.
[0106] The protected software program is provided in a packaged or split manner of its two components executing in the normal or secure execution environment.
[0107] At runtime, the monitoring and / or control functionality of the program execution graph is capable of dynamically modifying the protection profile by taking into account the elements characterizing the execution of the protected parts. Firstly, the module will be capable of varying the execution frequency of certain protection measures. Depending on the technical characteristics specific to each type of protection, it is possible, either during the execution of the program or a component of the program, or during the next execution of said program or said component, to vary the profile, type, modes, functionalities and parameters applying to a possibly modified perimeter of protected functions of the initial program. Without constituting an exhaustive list, the techniques used for dynamically modifying the protection can be cited, namely:
[0108] - the variation in the frequency of triggering of security operations,
[0109] - the variation of protection parameters (false negative / false positive rate accepted,...) or the variation of the protection mode,
[0110] - branching to a version of a function, routine or instruction block protected at a different level and previously installed (and obscured, camouflaged, encoded or encrypted) in the protected program. Advantageously, the elements allowing this version to be decoded or decrypted can be delivered by the transfer of elements held by the security module,
[0111] - the transfer from one execution environment to another. In particular, but not only, by using the principle of code interpretation, one can transform a sequence of instructions in a data directly transmissible to the other party without modifying the software of this party.
[0112] The launch of the protected software is carried out either in the normal environment or in the trusted execution environment depending on the protection project. The following sequence of operations is implemented in the module running in the trusted execution environment:
[0113] - recovery of the metadata file characterizing the initial protection,
[0114] - authenticity verification using the public key and signature integrated into the metadata file, if a signature has been produced and inserted into the metadata file,
[0115] - decryption or not of this part by the symmetric key contained in the file metadata if the file was encrypted (as indicated in the metadata file),
[0116] - calculation and entry point and launch of the execution which will be distributed in the normal and trusted execution environments of the various software components
[0117] - extraction of statistics on the collected time and frequency data during the execution of these different components and / or the data characterizing the memory consumption of these different components,
[0118] - continuous adjustment of the protection level by processing statistical data and also data from the metadata file specifying the scope of self-regulation and possible exclusions from this system,
[0119] - writing to the metadata file and possible transfer to the server.
[0120] The aforementioned adjustment is based on a variation, positive or negative, of the frequency of the security operations, on a variation, positive or negative, of the parameterization of the security functions, on the modification of the connection of all or part of the instruction sequences to other iso-functional versions of the instruction sequences having a different level of protection and which were initially inserted in the protected program, or on a transfer of the execution of one or more functions or blocks of instructions from one environment (normal, trusted) to the other.
[0121] Ultimately, the invention therefore relates to a wide variety of methods for protecting a software program targeted at different threats (reverse engineering, modification, unauthorized use and exploitation of vulnerabilities). It implements in a trusted execution environment (software or hardware) a protection regulation device using frequency, time and memory usage data collected during the execution of the components of the protected program. To do this, tracking probes are placed in the different subparts of the program or alternatively the program control flow is rerouted. In both cases, a protection module located in a trusted environment has individualized data for each program component collected a posteriori during one or more executions. With this data, this protection module makes decisions (within a possibly restricted framework that the operator can define when the initial protection is installed) to modify the level of protection for each program component, taking into account its real impact and no longer estimated a priori. Because this protection module manages the protection of the software, it is itself secured in a trusted environment.
Claims
Claims
1. A method for regulating the degree of protection of an executable software program in a computer architecture comprising the following steps: providing an initial software program, means for protecting said initial software program, a trusted environment for the secure execution of software programs, and a security module, said security module being placed in the trusted environment and ensuring the regulation of the protection of said software program; performing a static analysis of the initial software program, said static analysis comprising an identification of components of said software program; modifying the initial software program to obtain a modified software program so that the security module collects monitoring data relating to the execution times or frequencies or to a RAM footprint of the components identified during the static analysis of the software program;the modified software program is executed in the computer architecture; the security module collects monitoring data relating to the execution times or frequencies or the memory footprint of the components identified during the static analysis of the initial software program, during the execution of the modified software program; and the security module processes the collected data and dynamically regulates the degree of protection of the modified software program according to the monitoring data collected and processed, during the execution of said modified software program.;
2. The method according to claim 1, wherein the modified software program, which is executed in the computer architecture, is a software program which is protected by the protection means prior to its execution or during its execution, according to a given degree of protection, and wherein, after processing the data collected by the security module, the degree of protection is dynamically modified by the security module, according to the monitoring data collected and processed.
3. The method of either of claims 1 or 2, wherein the software program is modified by inserting, into said program, monitoring probes, said probes generating the monitoring data collected by the security module.
4. The method according to one of claims 1, 2 or 3, according to which: the software program is modified by intercepting jumps or branches in said program, and pointing to the components identified by their addresses, by a branch or call to the security module; and during the execution of the software program, the security module makes the branches or jumps to the addresses of said components.
5. The method according to one of the preceding claims, according to which: identified components are extracted from the software program; said components are placed in the trusted environment; and non-extracted components of the software program are executed outside the trusted environment and extracted components of the software program are executed in the trusted environment, under the control of the security module.
6. The method according to one of the preceding claims, in which the security module dynamically regulates the degree of protection by varying the frequency or the conditions for carrying out the protection of the software program.
7. The method according to one of the preceding claims, in which the modified software program comprises a plurality of iso-functional components, these iso-functional components being protected according to different degrees of protection or according to their location in or outside a trusted environment, and the security module dynamically regulates the protection by choosing to execute one iso-functional component rather than another according to its degree of protection or its location in or outside a trusted environment.
8. The method according to claim 7, in which the isofunctional components protected according to different degrees of protection or according to their location in or outside the trusted execution environment, reside in an encrypted form in the modified program and their decryption is produced by the protection module upon their selection by said module.
9. The method according to one of the preceding claims, according to which the protection means are protection means proceeding by obfuscation of components, encryption of components, verification of integrity, by emulation of instructions, by insertion of elements to address certain vulnerabilities, through memory segregation and / or placement of a component in a hardware trusted execution environment.
10. The method of claim 9, wherein the protection means are means proceeding by obfuscation of the components.
11. The method according to one of the preceding claims, further comprising the following steps: establishing a metadata file describing the components identified during the static analysis of the software program; assigning, to each of the identified components, security level parameters; providing the metadata file to the security module; and the security module dynamically regulates the degree of protection of the software according to the parameters assigned to the components contained in the metadata file.
12. The method according to one of the preceding claims, according to which each of the identified components is assigned an initial protection mode and / or a minimum security level and / or maximum limits for consumption of processor and / or memory resources.
13. The method of any preceding claim, wherein: the static analysis is performed on an uncompiled software program; and the components identified during the static analysis are functions, instruction blocks, routines, and / or subroutines of the software program.
14. The method according to one of the preceding claims, according to which the modifications of the initial software program are carried out by software for analyzing and modifying software programs, and according to which said software for analyzing and modifying software programs is delivered in the hardware or software trusted execution environment associated with the protected software program, in a hostile environment.
15. The method of claim 14, wherein the architecture comprises an operating system, said operating system providing management of the software program and integrating software for analyzing and modifying software programs.
16. The method according to one of the preceding claims, according to which the architecture further comprises decision-making means by machine learning, said means being involved in regulating the degree of protection of the software program.