WO2012140339A1 - Procédé et système de sécurisation d'un logiciel - Google Patents

Procédé et système de sécurisation d'un logiciel Download PDF

Info

Publication number
WO2012140339A1
WO2012140339A1 PCT/FR2012/000143 FR2012000143W WO2012140339A1 WO 2012140339 A1 WO2012140339 A1 WO 2012140339A1 FR 2012000143 W FR2012000143 W FR 2012000143W WO 2012140339 A1 WO2012140339 A1 WO 2012140339A1
Authority
WO
WIPO (PCT)
Prior art keywords
execution
procedures
elements
code
procedure
Prior art date
Application number
PCT/FR2012/000143
Other languages
English (en)
Inventor
Perrot DIDIER
Original Assignee
In-Webo Technologies Sas
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
Application filed by In-Webo Technologies Sas filed Critical In-Webo Technologies Sas
Priority to US14/111,691 priority Critical patent/US20140047555A1/en
Publication of WO2012140339A1 publication Critical patent/WO2012140339A1/fr

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/60—Protecting data
    • 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/14—Protecting executable software against software analysis or reverse engineering, e.g. by obfuscation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2133—Verifying human interaction, e.g., Captcha
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/16—Obfuscation or hiding, e.g. involving white box

Definitions

  • the present invention relates to a method, a system and a computer program product for securing original software implementing a secret.
  • Examples of systems having a marginal cost per low user are those where the authentication and electronic signature means is an application (and / or data) stored on a medium already owned by the user, such as a USB key , a mobile phone, a computer, a player, etc., and executed directly on that medium or on equipment connected to it and having an application execution environment, such as a mobile phone or a computer.
  • a medium already owned by the user such as a USB key , a mobile phone, a computer, a player, etc.
  • Such applications and data can indeed be produced and distributed at a marginal cost that is virtually nil.
  • the major difficulty of this approach is the design of the security devices, since such applications and data are sensitive to many cases of attacks.
  • the storage and execution media are indeed particularly exposed to worms and malicious programs able to take control or read the most hidden information.
  • a second example is the mechanisms of recognizing the storage medium or execution thanks to its unique characteristics (serial number, processor number, network card number, etc.): the reading of these characteristics requires indeed execution - usually local - of a program or a script that is easy to modify and / or circumvent to allow identity theft.
  • a third example is that of one-time password generation applications, whether these applications are executed on the terminal of access to the online service or in another environment, and that these applications are connected or not to the server.
  • authentication Indeed, these applications implement a set of secrets, symmetric or even asymmetrical (private key); access to this set of secrets, sometimes "hidden” but not protected by a material element, makes it possible to impersonate the user; this can usually be done without special expertise through means made available at low cost on the internet.
  • the access respectively to the data, to the application, or to the application and the data is sufficient to circumvent the security of the authentication and electronic signature system.
  • server PIN additional information
  • screen-logging observation of keystrokes or mouse clicks on areas of the screen
  • a method of securing an original software implementing a secret comprises:
  • ⁇ Direction tags controlling the calls of the procedures by each other include:
  • the tags controlling the execution of the elements include calls to elements outside the element containing the call and, in the external elements, destination marks of these calls;
  • the original software being a software implementing a cryptographic method requiring at least one secret
  • the secret is provided by the variable modified by the transformation functions associated with the procedures
  • the transformation functions modify by their executions a second variable, the second variable being a pointer to the dynamic location. ;
  • the transformation functions modify by their executions a third variable, the third variable being used by the software to encrypt and decrypt at least one of the elements;
  • a computer program product includes program code instructions for performing the above procedure when the program is running on a computer.
  • a system for securing original software implementing a secret comprises a computer adapted to perform the method described above.
  • FIG. 1 is a flow chart of a method according to one embodiment of the invention.
  • FIG. 2 is a flow chart of a particular step of the method of FIG.
  • the method P makes it possible to obtain a unique code CF * for each user and environment EE, or for a subset of users, so that by observing the codes CF * available to a significant number of users, the probability that two of these codes are identical or similar is zero or very low.
  • the method P can be implemented by numerous devices ("development tools"), preferably adapted to confer a high degree of automation on the process P.
  • the first step of the method P consists, step 1 of FIG. 1, in defining a random and more or less arbitrary partition of the code CF into segments si, S2, SN where N is an integer strictly greater than 1 randomly drawn.
  • This partition can be performed on the source code of CF or on the executable code by following some rules that will be specified later in this document.
  • the second step 3 of the method P consists of creating the source code of M procedures Sy ,, M being an integer greater than or equal to N.
  • step 5 of FIG. 2 is used to randomly draw a TF matrix with positive or zero integer TFy coefficients, this matrix having as many lines as there are S y functions.
  • the TF3 ⁇ 4 coefficients of TF refer to a library L of functions tf, that is to say that for a given index i, the coefficients TFy denote by their value the functions of the L library that will be used in Syi, zero indicating no function. It should be noted that the library L preferentially contains a much larger number of functions than there are Sy functions. The nature and role of these functions tf will be described below after the end of the process description P.
  • the code of Syi is then constituted, step 7, by combining the code of the procedures tf designated by the coefficients TFij and that of the segment s a ( j) where ⁇ is a permutation of the indices drawn randomly.
  • the third and last step 9, with reference to FIG. 1, of the method P consists in finalizing the code CF * by introducing into the code functions Sy on the one hand the "switching" conditions, that is to say controlling the recursive calls of the functions Sy by each other, on the other hand beacons controlling the execution of the segments 3 ⁇ 4.
  • the role of the beacons consists simply in scheduling these executions, that is to say making sure that Sj be executed once, after su and before Sj + i.
  • it suffices for each execution of Sy to check whether the conditions precedent to the execution of s O (are checked, that is to say if s has already been executed and if s has (i) has not yet been. This check is made preferentially by setting the value of a tag after performing a s ( ⁇ to a value that is a condition of entry to the execution of a $ ( ⁇ ) -
  • control tags are generalized to allow a multiple execution, partial and / or beginner during segment.
  • the value of a beacon is fixed at the end of segment 3 ⁇ 4 or at the point of a call of a segment outside Sj; this tag defines both which segment Sj must be executed and the start point of execution, that is to say the beginning of the segment s j or the destination of the call.
  • the second sufficient condition has been imposed in the definition of o-mc and Ocond-
  • the first sufficient condition is assessed in particular according to the choice of the sequence (U n ) and its first term Uo- Many variants exist, for example choose for (U n ) the following of Syracuse defined by the following recurrence relation:
  • a + i is equal to A / 2 if U n is even
  • U n + i is equal to 3U n + 1 if U n is odd and different from 1
  • U n + i is 1 if U n is 1
  • ⁇ is the probability - assumed uniform - that the condition ⁇ 3 ⁇ 4 is verified and if X denotes the number of steps necessary for the convergence of the sequence (U n ) chosen - if it converges, the number of recursive functions calls Sy is of the order of ((1 + ⁇ ) ⁇ -1) / ⁇ .
  • a "self-adaptive" means of answering the question on the integral execution of CF * is therefore to set the order of magnitude of U 0 such that X is large (preferably at least several tens) and to decrease ⁇ as the segments Sj are executed.
  • the number of Sy function calls potentially remaining to be made is gigantic ( ⁇ 2 *) as long as no segment Sj has been executed, whereas it decreases sharply as the segments are executed and that it becomes lower than X when all the segments have been executed, the total number of calls being of the order of NX
  • This empirical method works for classes of codes CF where one knows a priori a good approximation of the number segments to be executed. When this is not the case, the stop condition of the recursive calls is preferably completed with a tag controlling the end of the execution of CF.
  • the method P described above thus makes it possible to obtain a code CF * functionally at least equivalent to CF, CF * being derived from CF by the random selection of a small number of parameters, mainly N, TF, o " inc, cond, ⁇ 3 ⁇ 4. And the execution control tags of the segments si, ..., S -
  • the combinatorics specific to these parameters make it possible to guarantee, when this is necessary in the context of an implementation of this invention, that the code CF * is derived almost uniquely from CF.
  • the functions tf referred to in the description of the method P are so-called transformation functions. Their role is to modify the value of a variable called RTK for "Run-Time Key".
  • the change made by a function tf to RTK is arbitrary and may depend on execution parameters x; it can for example be an algebraic operation relating to the current value of RTK, x and other constant parameters, an operation on the binary representations (rotations, transpositions, permutations), of a logical operation (AND, OR, OR exclusive, complement), composed of such operations, etc.
  • the library L contains a preferentially important set of such functions tf, implemented in CF * by the method P when they are designated by the coefficients of the matrix TF drawn randomly.
  • RTK results from all the modifications made by the functions tf, and therefore not only of the value of the execution parameters implemented by the functions tf, but especially of which tf functions have been executed.
  • the functions tf executed and the sequence in which they are executed depend on which functions Sy have been called recursively (linked in particular to U 0 , ⁇ ⁇ ⁇ ⁇ >> ⁇ , x), as well as the result of the conditions Q .
  • CF using the method P is that it implements an implicit and unique calculation of an RTK variable.
  • a second important characteristic is that in order to perform the RTK calculation in the same way as the CF * code of a given user, it suffices to know the parameters (N, TF, o mc , CO nd, Q, tags) randomly drawn during of the implementation of the method P having generated CF *.
  • the server that has to check the validity of authentication codes and electronic signatures for multiple users can perform the RTK calculation for each of these users by executing a unique and identical CF * code for all users, in which it At runtime, it inserts the parameters (N, TF, o " j nc , CO nd, Q, tags) specific to each user, but these parameters are not explicitly defined in the CF * code.
  • the application is adapted to use the value of RTK when calculating the signatures provided to the authentication server, in addition to the secrets (stored data, entered PIN code) already used in this calculation. Whether this calculation implements a symmetrical or asymmetric method, the server having made a similar calculation of RTK can then check the validity of the signatures.
  • control points are introduced where some of the execution parameters x are updated; the role of these checkpoints is to help protect the performance of certain parts of the CF code, the principle being that if this part of the code was bypassed or modified, the checkpoint would likely be too and so the value of RTK calculated by the CF * code of the user and that calculated by the server would differ.
  • An example of a part of the CF code that is useful to protect is that ensuring that the secret information entered by the user (PIN code) is actually entered - that is, corresponds to events related to the hardware, keyboard or mouse - and not provided by an automatic script.
  • this implementation of the invention does not cover the cases of attacks where a malicious program relies on CF modeling and not on CF *, nor cases of attacks where a malicious program exports secrets and code CF * for manual analysis purposes. These cases will be treated in the embodiments presented later in this document because the necessary adaptations differ depending on whether or not the application is connected.
  • the method P is adapted so that tf functions dedicated to the calculation of an RTS variable and an RTM variable are inserted in the Sy functions.
  • the code CF * then allows the calculation of an RTS variable for "Run-Time Store” and an RTM variable for "Run-Time Mask” in a similar way to the calculation of the variable RTK.
  • the application is adapted to use the value of RTS (respectively RTM) when calculating the authentication code or the electronic signature. This means that some of the changes in the value of RTS (respectively RTM) by the functions tf are done before the use of RTS (respectively RTM) by the application and that others are after.
  • the server is adapted to provide the application with ARTS information (respectively ARTM) previously - and preferably simultaneously - at the moment when RTS (respectively RTM) is used by the application, such as ARTS (respectively A RT M) or the difference between RTS 0 (respectively RTM 0 ) and TSend (respectively RTM in d), the value obtained during the previous execution and stored by the server.
  • ARTS information previously - and preferably simultaneously - at the moment when RTS (respectively RTM) is used by the application, such as ARTS (respectively A RT M) or the difference between RTS 0 (respectively RTM 0 ) and TSend (respectively RTM in d)
  • difference is understood to mean an injective binary operation.
  • a RT s (respectively A RT M) by the server allows the application to determine the value of RTSend (respectively RTM in d) obtained during the previous execution, this value being correct and not corresponding to the value stored by the server only because the code CF * has actually calculated RTS 0 (respectively RTMo).
  • the server and the application are adapted so that the value Uo is preferentially provided by the server and that the updates of the execution parameters x in the control points are preferably carried out thanks to information provided by the server.
  • the server is also adapted to implement a "point of no return". Starting a calculation of an authentication code or an electronic signature makes it possible to cross this "point of no return", for example when the application asks the server for the value of Uo. Once this point is crossed, the code CF * must terminate correctly and in a short time authentication or electronic signature using RTK, RTS and RTM, failing which the server irreversibly blocks the use of the application.
  • the application and the server are adapted so that the secrets are renewed after each successful authentication or electronic signature.
  • secrets refers to the data stored by the application and not the information entered by the user. The way to renew the secrets under condition of success should preferentially not require the transfer of these secrets between the application and the server.
  • a key sharing method such as Diffie-Hellmann is preferably implemented.
  • the application and the server preferentially exchange an update key (DK) which is applied identically by the application and the server on the existing secrets in order to to produce new ones according to the following operation:
  • DK update key
  • secretSnew H (secrets 0 id * DK) where H is a one-way function (preferably a function derived from a hash function) and * is a binary operator.
  • the RTS variable is used by the CF * code to determine the dynamic storage location of the secrets used by the authentication and electronic signature application.
  • the storage location of the secrets on the storage medium MS is determined by the value of RTSen d -
  • the value of RTS in d obtained during the previous execution designates the current location of the secrets, the value obtained during the current execution is the location of the renewed secrets.
  • the update of the location of storage of the secrets is made only in case of success of the authentication or the electronic signature.
  • An important characteristic of the method P adapted so that the code CF * calculates RTS is that the location of the secrets used for the authentication or the electronic signature can not be known without executing the application.
  • a first example of such a method is to create one or more files in trees related to the operating system of the execution support of the application assumed to be sufficiently large.
  • Another example even more discreet is not to store secrets but to use as secrets the values stored in arbitrary locations of the storage means; the update of the secrets between application and server then consists for the application to indicate to the server the value of the locations designated by the value of RTS.
  • the authentication method based on these secrets is adapted, since it is not possible to guarantee by such a method that the values contained in the locations will not be modified by other tasks or applications accessing the storage means. MS. Authentication is then not on a certainty (equality of secrets) but on a likelihood (degree of similarity of secrets).
  • the RTM variable is used by the application to encrypt and decrypt the executable code of certain segments if a checkpoint has been inserted.
  • the attack carried out by a malicious program exporting the secrets (in particular, the information entered by the user) and the code CF * of the application for the purposes of analysis and manual expertise can not succeed. Indeed, this malicious program could not execute the code CF * before exporting for the reasons recalled in the description of the first implementation of the invention can not know the value of RTS, and therefore not can export some of the necessary secrets.
  • the attacker recovering the code CF * can analyze it and execute it but for that it is obliged to cross the "point of no return".
  • an attack carried out by a malicious program based on the manual reconstruction and analysis of the CF code (invariant) from one or more codes CF * in order to modify certain segments 3 ⁇ 4 in CF * can not succeed.
  • the sensitive elements are encrypted by the value of RTM and contain a control point. Since the value of RTM is not known unless you execute the CF * code and cross a "point of no return", the malicious program can neither selectively disable these sensitive elements, nor circumvent them because they contain points control.
  • An example of sensitive element is the part of the code CF controlling that the input of information by the user is accompanied by many events related to the hardware (typing, mouse click, ).
  • the application is adapted to prevent the automatic execution of the application through a Turing test, for example, implementation of a "captcha" that the user must enter, or a secret known to the user, displayed graphically, always different and not easily recognizable by a program, that the user must recognize among other strings in place of the use of a RTM mask.
  • the Method P is adapted so that tf functions dedicated to calculating an RTS variable and an RTM variable are inserted in the functions Sy.
  • the code CF * then allows the calculation of an RTS variable for "Run-Time Store” and an RTM variable for "Run-Time Mask” in a similar way to the calculation of the variable RTK.
  • the application is adapted to use the value of RTS (respectively RTM) when calculating the authentication code or the electronic signature. This means that some of the changes in the value of RTS (respectively RTM) by the functions tf are done before the use of RTS (respectively RTM) by the application and that others are after.
  • the method P generating the code CF * is adapted as follows: thanks to the control tags, no segment Sj is executed before a configurable number (Y) of recursive calls of the functions Sy. Otherwise, the call of the functions Sy can be done according to two modes “get” (search) or "set” (definition) thanks to the value of a parameter. In “get” mode, the recursive call of the Sy functions stops after the configurable number Y of calls; RTSi (respectively RTM is the value taken by the RTS variable (respectively RTM) at that time and this value is stored by the application.
  • the call of the functions Sy is made a first time in "get” mode with the value of Uo of the previous execution stored by the application, then a second time in "set” mode with the value of U 0 of the current execution.
  • RTSi (respectively RTMi) obtained during the first call is used to determine the storage location of the secrets implemented for the authentication or the electronic signature (respectively to decrypt one or more sensitive areas).
  • RTSi (respectively RTMi) obtained during the second call is used to determine the location where the secrets will be stored after their use (respectively to re-register one or more sensitive zones after their execution).
  • the application is not connected, it is adapted to randomly draw the value of U 0 .
  • the server is adapted to use this value and to control the non-replay.
  • a preferential way of carrying out these adaptations when the authentication application is that described in the patent application FR2937204 is to deduce, in a simple and deterministic manner, the value of Uo from that of the Rand key randomly drawn during the generation of a one-time password.
  • the key Rand is provided to the server because it is short enough to be embedded in the authentication code or the electronic signature generated, and its non-replay is controlled; the transmission of U 0 to the server and its non-replay are therefore provided via those of Rand.
  • the application and the servers are adapted so that the modifications of the execution parameters used in the control points are carried out by the application and similarly by the server without application and server communicating with each other.
  • the adaptations of this embodiment make it possible to counter several types of additional attacks.
  • the attack carried out by a malicious program exporting the secrets (in particular, the information entered by the user) and the code CF * of the application for purposes of analysis and manual expertise can not succeed directly.
  • such an attack is not automatic or industrial for the reasons already presented
  • the export of the code CF * requires that, although the application is not connected, is stored and run on an environment that is connected.
  • the malicious program that could not execute the code CF * before exporting it for the reasons recalled in the description can not know the value of RTS, and therefore can only export part of the secrets.
  • the attacker recovering the CF * code can analyze it and execute it; to calculate a correct RTS value, it must have the value of U 0 in the previous run and perform the attack - after manual analysis of the CF * code - before the CF * code is again executed by the user, as this would change the value of RTS. He can then, knowing RTS, try to obtain the values of the secrets stored at the locations designated by RTS on the MS storage means of the user, which requires on the one hand that the MS means is connected, on the other hand that the malicious program takes the initiative to establish an outgoing connection. Only then, and in the case of the application described in the patent application FR2937204 only if the user has not implemented the authentication means, the attack could succeed. Finally, it should be noted that the installation of a malicious program and its ability to discreetly establish outgoing connections are severely limited on runtime environments such as mobile phones.
  • an attack carried out by a malicious program based on the reconstitution and the manual analysis of the CF code (invariant) from one or more codes CF * in order to modify certain segments if in CF * can not succeed directly .
  • the sensitive elements are encrypted by the value of RTM and contain a control point. Since the value of RTM is not known unless you execute the CF * code, the malicious program can neither selectively disable these sensitive elements, nor circumvent them since they contain checkpoints. It can however - theoretically - modify an unprotected part of the code CF * in order to make the execution of the code CF * relatively discrete and calculate the value of RTM, then on this basis decrypt the protected areas, modify them, and finally execute the complete CF * code.

Abstract

Procédé de sécurisation d'un logiciel originel mettant en œuvre un secret comprenant: partitionner (1) le logiciel en N éléments, N étant un entier strictement supérieur à 1; générer (3) M procédures sécurisées, M étant un entier supérieur ou égal à N, par, pour chaque procédure: tirage aléatoire d'une fonction parmi une bibliothèque de fonctions; sélection d'un des N éléments ou de l'ensemble vide; combinaison de la fonction tirée aléatoirement et de l'élément sélectionné quand la sélection n'est pas l'ensemble vide; de sorte que chaque élément est combiné dans une seule procédure et que tous les éléments sont combinés; modifier chaque procédure par introduction de balises de direction contrôlant les appels des procédures les unes par les autres et de balises contrôlant l'exécution des éléments; concaténer (9) les M procédures en un logiciel sécurisé pour mettre en œuvre le secret.

Description

PROCEDE ET SYSTEME DE SECURISATION D'UN LOGICIEL
La présente invention concerne un procédé, un système et un produit programme d'ordinateur de sécurisation d'un logiciel originel mettant en œuvre un secret.
Le développement des services en ligne au premier rang desquels le paiement rend nécessaire la mise au point de systèmes d'authentification et de signature électronique sûrs et pouvant être mis en œuvre de façon extrêmement économique à très grande échelle.
L'une des approches pour répondre à cet objectif n'est pas technique mais économique : elle consiste à répartir entre « co-accepteurs » les investissements dans des systèmes de sécurité prouvée. De tels systèmes sont, par exemple, des certificats électroniques sur support physique ou des générateurs de mots de passe à usage unique incluant un élément de sécurité matériel (« secure élément »), bien que ces derniers ne permettent pas la signature électronique, ne soient pas immunes à certains types d'attaques (hameçonnage, homme du milieu), et de part leur nature symétrique, nécessitent que chaque co-accepteur fasse confiance à tous les autres (ou à un seul, commun), c'est-à-dire nécessite la mise en place d'un cercle de confiance. Au-delà de la difficulté d'organisation, cette approche économique se heurte à la difficulté de répartir les investissements entre co- accepteurs ; dans le cas général, cette répartition ne se fait pas et le système d'authentification et de signature électronique reste un système 'privé', intégralement financé par un accepteur unique en ayant les moyens, et pour ses seuls besoins.
Une approche alternative est technique. Elle consiste à mettre au point des dispositifs de sécurisation pour des systèmes d'authentification et de signature électronique possédant un coût marginal par utilisateur faible voire nul et pour lesquels il n'y a, par construction, pas de problèmes de répartition des coûts d'équipement des utilisateurs.
Les exemples de systèmes possédant un coût marginal par utilisateur faible sont ceux où le moyen d'authentification et de signature électronique est une application (et / ou des données) stockée sur un support déjà possédé par l'utilisateur, tel qu'une clé USB, un téléphone mobile, un ordinateur, un baladeur, etc., et exécutée directement sur ce support ou sur un équipement lui étant connecté et possédant un environnement d'exécution d'applications, tel qu'un téléphone mobile ou un ordinateur. De telles applications et données peuvent en effet être produites et distribuées à un coût marginal quasiment nul.
La difficulté majeure de cette approche est la conception des dispositifs de sécurisation, puisque de telles applications et données sont sensibles à de nombreux cas d'attaques. Les supports de stockage et d'exécution sont en effet particulièrement exposés à des vers et programmes malicieux capables d'en prendre le contrôle ou d'y lire les informations les mieux dissimulées.
A titre d'exemple, l'utilisation de certificats logiciels stockés dans les navigateurs Internet ou sur un support de stockage non physiquement protégé (disque ou clé de stockage USB, ...) est déconseillée pour l'authentification sur des services bancaires ou de paiement en ligne, les clés privées de tels certificats pouvant être dérobées imperceptiblement par un programme malicieux.
Un second exemple est celui de mécanismes consistant à reconnaître le support de stockage ou d'exécution grâce à ses caractéristiques uniques (numéro de série, numéro de processeur, numéro de carte réseau, etc.) : la lecture de ces caractéristiques nécessite en effet l'exécution - généralement locale - d'un programme ou d'un script qu'il est aisé de modifier et / ou de contourner pour permettre l'usurpation d'identité.
Un troisième exemple enfin est celui d'applications de génération de mots de passe à usage unique, que ces applications soient exécutées sur le terminal d'accès au service en ligne ou dans un autre environnement, et que ces applications soient connectées ou non au serveur d'authentification. En effet, ces applications mettent en œuvre un ensemble de secrets, de façon symétrique voire asymétrique (clé privée) ; l'accès à cet ensemble de secrets, parfois « cachés » mais non protégés par un élément matériel, permet d'usurper l'identité de l'utilisateur ; cela peut généralement être réalisé sans expertise particulière grâce à des moyens rendus disponibles à faible coût sur le réseau internet. Dans ces trois exemples représentatifs de l'état de l'art, l'accès respectivement aux données, à l'application, ou à l'application et aux données, suffit à contourner la sécurité du système d'authentification et de signature électronique. Ces systèmes sont généralement protégés par la saisie d'une information supplémentaire (« code PIN serveur ») par l'utilisateur sur le terminal où est exécutée l'application ; or, cette information n'est pas plus hors de portée que ne le sont l'application et les données, du fait de techniques dites de « key-logging » ou « screen-logging » (observation des frappes clavier ou clic souris sur des zones de l'écran). Par ailleurs, dans le cas d'applications de génération de mots de passe à usage unique de conception classique, l'observation d'un seul mot de passe valide suffit en cas d'accès au support de stockage des données à reconstruire la valeur du code PIN.
Ainsi, les systèmes d'authentification et de signature électronique présentant un coût marginal par utilisateur sont-ils largement vulnérables et ne peuvent-ils être mis en œuvre, pour les services « sensibles » où ils sont rendus nécessaires, sans dispositif de sécurisation convenablement conçu.
Un exemple de tel dispositif de sécurisation est présenté dans la demande de brevet FR2937204 au nom du déposant : il s'agit d'un moyen d'authentification et de signature électronique exécuté sur un autre équipement que le terminal d'accès au service, et par ailleurs non connecté - c'est-à-dire ne communiquant pas avec le serveur. Ce dispositif ne fait pas d'hypothèse sur l'environnement d'exécution hormis qu'il n'est pas accessible à distance, c'est-à-dire que l'on ne peut y lire les secrets mis en œuvre qu'en ayant physiquement accès à son support. Par exemple, une application s'exécutant dans une machine virtuelle sur un environnement 'mono-tâche' d'un téléphone mobile vérifie ces hypothèses de façon satisfaisante, mais ce n'est plus le cas dès lors qu'il s'agit d'une plate-forme Ouverte' ou 'multitâche' comme celle d'un ordinateur ou d'un « smartphone », et encore moins lorsque cette plate-forme est elle-même le terminal d'accès aux services.
Il serait donc particulièrement avantageux de disposer de dispositifs de sécurisation étendant ou complétant ceux mentionnés ci-dessus, permettant l'emploi sûr de systèmes d'authentification et de signature électronique pouvant être mis en œuvre de façon extrêmement économique à grande échelle.
Pour résoudre un ou plusieurs des inconvénients ou insuffisances cités précédemment, un procédé de sécurisation d'un logiciel originel mettant en œuvre un secret, comprend :
• partitionner le logiciel en N éléments, N étant un entier strictement supérieur à 1 ;
• générer M procédures sécurisées, M étant un entier supérieur ou égal à N, par, pour chaque procédure :
· tirage aléatoire d'une fonction parmi une bibliothèque de fonctions ;
• sélection d'un des N éléments ou de l'ensemble vide ;
• combinaison de la fonction tirée aléatoirement et de l'élément sélectionné quand la sélection n'est pas l'ensemble vide ;
de sorte que chaque élément est combiné dans une seule procédure et que tous les éléments sont combinés ;
• modifier chaque procédure par introduction de balises de direction contrôlant les appels des procédures les unes par les autres et de balises contrôlant l'exécution des éléments ;
· concaténer les M procédures en un logiciel sécurisé apte à être installé et exécuté sur une plateforme d'exécution non sécurisée pour mettre en œuvre le secret.
Des caractéristiques ou des modes de réalisation particuliers, utilisables seuls ou en combinaison, sont :
· les balises de direction contrôlant les appels des procédures les unes par les autres comportent :
• pour chaque procédure, une sélection d'une pluralité de procédures appelables en fonction d'un paramètre d'exécution ;
• des conditions non-prédictibles fonctions de paramètre d'exécutions, fixant l'exécution de certaines des procédures sélectionnées ;
• une suite mathématique définie par un premier terme et une fonction de récurrence définissant un argument d'appel de chaque procédure tel que si une procédure a comme argument d'appel l'élément de la suite d'indice n, alors les procédures appelées par celle-ci ont comme argument d'appel l'élément de la suite d'indice n+1 ;
· la suite mathématique est la suite de Syracuse ;
• la sélection des deux procédures appelables est basée sur une fonction uniforme du paramètre d'exécution assurant que la probabilité d'appel pour chaque procédure est substantiellement identique ;
· les balises contrôlant l'exécution des éléments comportent des appels vers des éléments extérieurs à l'élément contenant l'appel et, dans les éléments extérieurs, des repères de destination de ces appels ;
• les fonctions de la bibliothèque de fonction sont des fonctions de transformation modifiant la valeur d'au moins une variable ;
• le logiciel originel étant un logiciel mettant en oeuvre un procédé cryptographique nécessitant au moins un secret, le secret est fourni par la variable modifiée par les fonctions de transformation associées aux procédures ;
· le secret étant pour partie calculé et pour partie dépendant d'un secret non-calculé dont l'emplacement est dynamique et calculé, les fonctions de transformation modifient par leurs exécutions une seconde variable, la seconde variable étant un pointeur vers l'emplacement dynamique ;
· les fonctions de transformation modifient par leurs exécutions une troisième variable, la troisième variable étant utilisée par le logiciel pour crypter et décrypter au moins un des éléments ;
• le premier terme de la suite est calculé à partir d'un nombre aléatoire utilisé lors de la génération d'un mot de passe à usage unique.
Dans un second aspect de l'invention, un produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé ci-dessus lorsque le programme est exécuté sur un ordinateur.
Dans un troisième aspect de l'invention, un système de sécurisation d'un logiciel originel mettant en œuvre un secret, comprend un calculateur adapté pour exécuter le procédé décrit ci-dessus.
L'invention sera mieux comprise à la lecture de la description qui suit, faite uniquement à titre d'exemple, et en référence aux figures en annexe dans lesquelles :
- la figure 1 est un ordinogramme d'un procédé selon un mode de réalisation de l'invention ; et
- la figure 2 est un ordinogramme d'une étape particulière du procédé de la figure 1.
On décrit tout d'abord un procédé P permettant de dériver un code CF* du code CF. Le procédé P permet d'obtenir un code CF* unique pour chaque utilisateur et environnement EE, ou pour un sous-ensemble réduit d'utilisateurs, de telle sorte qu'en observant les codes CF* dont dispose un nombre significatif d'utilisateurs, la probabilité que deux de ces codes soient identiques ou similaires est nulle ou très faible.
Le procédé P peut être implémenté par de nombreux dispositifs (« outils de développement »), de préférence adaptés pour conférer une capacité importante d'automatisation au procédé P.
La première étape du procédé P consiste , étape 1 de la Figure 1 , à définir une partition aléatoire et plus ou moins arbitraire du code CF en segments si, S2, SN OÙ N est un entier strictement supérieur à 1 tiré aléatoirement. Cette partition peut être effectuée sur le code source de CF ou bien sur le code exécutable en respectant quelques règles qui seront précisées dans la suite de ce document.
La seconde étape 3 du procédé P consiste à créer le code source de M procédures Sy,, M étant un entier supérieur ou égal à N.
Pour cela, on procède, étape 5 de la Figure 2, au tirage aléatoire d'une matrice TF à coefficients TFy entiers positifs ou nuls, cette matrice possédant autant de lignes qu'il y a de fonctions Sy. Les coefficients TF¾ de TF font référence à une bibliothèque L de fonctions tf, c'est-à-dire que pour un indice i donné, les coefficients TFy désignent par leur valeur les fonctions de la bibliothèque L qui seront employées dans Syi, zéro indiquant l'absence de fonction. Il convient de noter que la librairie L contient préférentiellement un nombre de fonctions beaucoup plus important qu'il n'y a de fonctions Sy. La nature et le rôle de ces fonctions tf seront décrits ci-dessous après la fin de la description du procédé P.
Le code de Syi est alors constitué, étape 7, en combinant le code des procédures tf désignées par les coefficients TFij et celui du segment sa(j) où σ est une permutation des indices tirée aléatoirement.
La troisième et dernière étape 9, en référence à la Figure 1 , du procédé P consiste à finaliser le code CF* en introduisant dans le code des fonctions Sy d'une part des conditions « d'aiguillage » c'est-à-dire contrôlant les appels récursifs des fonctions Sy les unes par les autres, d'autre part des balises contrôlant l'exécution des segments ¾.
Les appels récursifs, tout d'abord, sont définis et contrôlés par trois types de paramètres :
• deux permutations d'indices, amc et acond tirées aléatoirement et définissant lors de l'exécution quelles fonctions SyainC(i,x) et SyaCond(i,x) sont appelées par Sy*, où x représente des paramètres de l'exécution ; en tant que fonctions de x, σιηο et ocond sont préférentiellement uniformément réparties, c'est-à-dire que la probabilité d'appel est la même pour chaque fonction Sy ;
• une condition q(x) tirée aléatoirement, fonction de paramètres de l'exécution x et définissant lors de l'exécution si SyCTCond(i,x) est effectivement appelée par Syi (appel conditionnel), tandis que l'appel à Sy0inc(i,x) est inconditionnel ;
• une suite mathématique (Un) définie par son premier terme Uo et sa relation de récurrence f définissant U„+i comme f(Un), utilisée de la façon suivante : si Syi a été appelée avec Un comme argument, Sy<,inc(i,x) et SyaC0nd(i,x) sont appelées avec f(Un), c'est-à-dire Un+i comme argument.
Les balises, ensuite, permettent de contrôler l'exécution du segment Sa© dans la fonction Syi. En effet, l'ordre d'exécution des Syi n'est pas prédictible lors de la mise en œuvre du procédé P, d'une part parce que cet ordre dépend de paramètres et conditions d'exécution, d'autre part parce qu'il dépend largement du tirage aléatoire de Uo effectué lors de chaque nouvelle exécution. On conçoit donc aisément qu'il soit nécessaire de contrôler l'exécution des segments de CF, afin qu'en termes de fonctionnalités, CF soit incluse dans CF*, c'est-à-dire que l'exécution de CF* réalise au moins l'authentification ou la signature électronique et/ou les autres fonctionnalités qui sont l'objet de CF.
Dans le cas particulier où l'exécution du code CF peut se faire en exécutant séquentiellement, intégralement, et une seule fois chaque segment ¾, le rôle des balises consiste simplement à ordonnancer ces exécutions, c'est-à-dire faire en sorte que Sj soit exécuté une seule fois, après su et avant Sj+i . Il suffit dans ce cas, lors de chaque exécution de Sy,, de vérifier si les conditions préalables à l'exécution de sO( sont vérifiées, c'est-à-dire si sa(i -i a déjà été exécuté et si sa(i) ne l'a pas encore été. Cette vérification se fait préférentiellement en fixant la valeur d'une balise après exécution de sa(^ à une valeur servant de condition d'entrée à l'exécution de $a(\)-
Dans le cas plus général où l'exécution du code CF nécessite d'exécuter une ou plusieurs fois les segments si, éventuellement partiellement et de façon déterminée en partie par les conditions d'exécution elles-mêmes, les balises de contrôle sont généralisées pour permettre une exécution multiple, partielle et/ou débutant en cours de segment. De la même façon que précédemment, la valeur d'une balise est fixée en fin de segment ¾ ou au point d'un appel d'un segment extérieur à Sj ; cette balise définit à la fois quel segment Sj doit être exécuté et le point de début d'exécution, c'est-à-dire le début du segment sj ou la destination de l'appel. Ces balises sont ainsi une représentation de la structure des appels entre différentes zones de CF et pas uniquement de la partition de CF. L'insertion des balises de contrôle nécessite une adaptation supplémentaire du dispositif implémentant le procédé P.
Il convient de remarquer qu'un élément important dans la mise en œuvre du procédé P pour la génération du code CF* est de garantir que le code CF est intégralement exécuté lorsqu'on exécute CF*. Définir quelles classes de codes CF s'exécutent intégralement, c'est-à-dire ont un début et une fin, est un problème ouvert. On ne se posera donc la question concernant l'exécution intégrale de CF « plongé dans CF* » que si l'on suppose que le code CF lui-même s'exécute intégralement lorsqu'il est exécuté de façon autonome ; remarquons de plus que si l'on restreint l'application aux opérations permettant le calcul d'un code d'authentification ou d'une signature électronique le code CF résultant a bien un début et une fin en un temps fini sous réserve de saisie du code PIN par l'utilisateur.
La question pour un tel code, une fois partitionné en N segments s-,, est de savoir si tous ces segments ou fractions de segments s'exécuteront un nombre suffisant de fois, alors que l'on ne sait pas prédire de façon déterministe l'exécution des fonctions Sy contenant ces segments. Il suffit pour cela que le nombre d'appels récursifs des fonctions Sy entre elles soit suffisamment grand et que toutes les fonctions Sy aient la même probabilité d'être appelées.
La seconde condition suffisante a été imposée dans la définition de o-mc et Ocond- La première condition suffisante s'apprécie notamment selon le choix de la suite (Un) et de son premier terme Uo- De nombreuses variantes existent, par exemple choisir pour (Un) la suite de Syracuse définie par la relation de récurrence suivante :
Un+i vaut Un/2 si Un est pair
Un+i vaut 3Un+1 si Un est impair et différent de 1
Un+i vaut 1 si Un vaut 1
La particularité de cette suite est qu'il existe une conjecture selon laquelle elle converge en un nombre fini d'étapes vers 1 quel que soit le premier terme. Cela permet une condition d'arrêt simple du code CF* : il suffit d'arrêter de nouveaux appels récursifs - et donc de commencer à « remonter » la pile utilisée pour les appels récursifs - dès lors que Un a atteint la valeur 1.
De plus, des estimations du nombre X d'étapes nécessaires selon Uo pour la convergence de cette suite sont disponibles.
Si σ est la probabilité - supposée uniforme - que la condition <¾ soit vérifiée et si X désigne le nombre d'étapes nécessaires pour la convergence de la suite (Un) choisie - si elle converge, le nombre d'appels récursifs de fonctions Sy est de l'ordre de ((1+ε)χ-1)/ε. Un moyen « auto-adaptatif » de répondre à la question sur l'exécution intégrale de CF* est donc de fixer l'ordre de grandeur de U0 tel que X soit important (préférentiellement au moins plusieurs dizaines) et de faire décroître ε au fur et à mesure que les segments Sj sont exécutés. Ainsi, le nombre d'appels de fonctions Sy restant potentiellement à effectuer est gigantesque (~2*) tant qu'aucun segment Sj n'a été exécuté, alors qu'il décroît fortement au fur et à mesure que les segments sont exécutés et qu'il devient inférieur à X lorsque tous les segments ont été exécutés, le nombre total d'appel étant de l'ordre de N.X. Cette méthode empirique fonctionne pour des classes de codes CF où l'on connaît a priori une bonne approximation du nombre de segments devant être exécutés. Lorsque ce n'est pas le cas, la condition d'arrêt des appels récursifs est préférentiellement complétée avec une balise contrôlant la fin de l'exécution de CF.
Enfin pour parachever la mise en œuvre du procédé P, on choisit quelle fonction Sy est initialement appelée.
Le procédé P décrit précédemment permet donc d'obtenir un code CF* fonctionnellement au moins équivalent à CF, CF* étant dérivé de CF par le tirage aléatoire d'un nombre restreint de paramètres, principalement N, TF, o"inc, cond, <¾. et les balises de contrôle d'exécution des segments si, ... , S - La combinatoire propre à ces paramètres permet de garantir lorsque cela est nécessaire dans le cadre d'une implémentation de cette invention que le code CF* est dérivé de façon quasiment unique de CF.
Les fonctions tf dont il était question dans la description du procédé P sont des fonctions dites de transformation. Leur rôle est de modifier la valeur d'une variable appelée RTK pour « Run-Time Key ». La modification apportée par une fonction tf à RTK est arbitraire et peut dépendre de paramètres d'exécution x ; il peut par exemple s'agir d'une opération algébrique portant sur la valeur courante de RTK, de x et d'autres paramètres constants, d'une opération sur les représentations binaires (rotations, transpositions, permutations), d'une opération logique (ET, OU, OU exclusif, complément), de composées de telles opérations, etc. La bibliothèque L contient un ensemble préférentiellement important de telles fonctions tf, mises en œuvre dans CF* par le procédé P lorsqu'elles sont désignées par les coefficients de la matrice TF tirée aléatoirement.
La valeur de RTK résulte de l'ensemble des modifications apportées par les fonctions tf, et donc non seulement de la valeur des paramètres d'exécution mis en œuvre par les fonctions tf, mais surtout de quelles fonctions tf ont été exécutées. A leur tour, les fonctions tf exécutées et la séquence selon laquelle elles sont exécutées dépendent de quelles fonctions Sy ont été appelées récursivement (lié notamment à U0, σίηο σ«>ηά, x), ainsi que du résultat des conditions Q.
Ainsi, une première caractéristique permise par le code CF* dérivé de
CF grâce au procédé P est qu'il implémente un calcul implicite et unique d'une variable RTK. Unique grâce à la combinatoire mise en œuvre par le procédé P ; implicite parce qu'il est impossible de décrire la formule permettant le calcul de RTK autrement que sous une forme équivalente au code CF*, et ce notamment du fait que cette formule dépend de façon non algébrique de la valeur de U0 pour une suite (Un) convenablement choisie.
Une seconde caractéristique importante est que pour réaliser le calcul de RTK de façon identique au code CF* d'un utilisateur donné, il suffit de connaître les paramètres (N, TF, omc, oCOnd, Q, balises) tirés aléatoirement lors de la mise en œuvre du procédé P ayant généré CF*. Cela signifie que le serveur devant contrôler la validité des codes d'authentification et des signatures électroniques pour de multiples utilisateurs peut réaliser le calcul de RTK pour chacun de ces utilisateurs en exécutant un code CF* unique et identique pour tous les utilisateurs, dans lequel il insère lors de l'exécution les paramètres (N, TF, o"jnc, aCOnd, Q, balises) propres à chaque utilisateur. Ces paramètres ne sont en revanche pas explicitement définis dans le code CF*.
On déduit de ces caractéristiques un dispositif de sécurisation de l'application d'authentification et de signature électronique : l'application est adaptée pour utiliser la valeur de RTK lors du calcul des signatures fournies au serveur d'authentification, et ce en complément des secrets (données stockées, code PIN saisi) déjà utilisés dans ce calcul. Que ce calcul mette en œuvre un procédé symétrique ou asymétrique, le serveur ayant fait un calcul similaire de RTK sait alors vérifier la validité des signatures.
Pour ce faire, on adapte l'application de la façon suivante ;
On introduit dans le code CF des « points de contrôle » où certains des paramètres d'exécution x sont mis à jour ; le rôle de ces points de contrôle est de contribuer à protéger l'exécution de certaines parties du code CF, le principe étant que si cette partie du code était contournée ou modifiée, le point de contrôle le serait vraisemblablement aussi et qu'ainsi la valeur de RTK calculée par le code CF* de l'utilisateur et celle calculée par le serveur différeraient. Un exemple de partie du code CF qu'il est utile de protéger est celle s'assurant que l'information secrète saisie par l'utilisateur (code PIN) est réellement saisie - c'est-à-dire correspond à des événements liés au matériel, clavier ou souris - et non fournie par un script automatique.
La sécurisation de l'application d'authentification et de signature électronique apportée par la dérivation de CF* à partir de CF par le procédé P peut être présentée de la façon suivante.
Une attaque réalisée par un programme malicieux accédant aux secrets (données stockées et saisies par l'utilisateur) ne fonctionne pas. En effet, la réussite de l'authentification ou la validité de la signature électronique nécessitent de disposer d'une clé RTK calculée par l'application. Cette clé ne peut pas non plus être simplement volée puisqu'elle n'est jamais stockée et n'est valide que pour l'exécution en cours de l'application.
Une attaque réalisée par un programme malicieux accédant aux secrets (notamment les données saisies par l'utilisateur) et déclenchant l'exécution de l'application en tâche de fond ou en l'absence probable de l'utilisateur, puis saisissant à sa place les informations attendues de l'utilisateur, ne fonctionne pas. En effet, l'application vérifie que ces informations sont réellement fournies par un utilisateur.
Une attaque réalisée par un programme malicieux accédant aux secrets (données stockées et saisies par l'utilisateur) et tentant d'analyser la façon dont la clé RTK est calculée pour la calculer sans exécuter l'application ne fonctionne pas. En effet, le code de CF* réalisant le calcul de RTK ne peut être extrait de façon automatique par un programme : ce code est en effet variable dans sa taille (nombre de fonctions Sy), dans sa structure (présence ou non de fonctions tf, en nombre variable), et dans sa composition (la bibliothèque L contenant beaucoup plus de fonctions tf qu'il n'y a de fonctions tf dans un code CF* et étant extensible ad libitum, il n'est pas possible pour un programme malicieux de connaître toutes les fonctions tf, même en s'appuyant sur l'analyse manuelle et préalable de nombreux codes CF*). Une analyse automatique de CF* pour en extraire les paramètres connus du serveur et suffisants pour le calcul de RTK n'est pas possible de façon automatique car elle nécessite de modéliser le code CF*, ce qui nécessite de s'appuyer sur des motifs connus et stables, en termes de structure comme de contenu.
Cette implémentation de l'invention ne couvre en revanche pas les cas d'attaques où un programme malicieux s'appuie sur une modélisation de CF et non de CF*, ni les cas d'attaques où un programme malicieux exporte les secrets et le code CF* à des fins d'analyse manuelle. Ces cas seront traités dans les variantes de réalisation présentées dans la suite de ce document car les adaptations nécessaires diffèrent selon que l'application fonctionne ou non de façon connectée.
L'invention a été illustrée et décrite en détail dans les dessins et la description précédente. Celle-ci doit être considérée comme illustrative et donnée à titre d'exemple. De nombreuses variantes de réalisation sont possibles.
Dans une première variante de réalisation de cette invention valable pour une application d'authentification ou de signature électronique connectée, c'est-à-dire mettant en œuvre lors de son exécution un protocole bidirectionnel avec le serveur, le procédé P est adapté pour que des fonctions tf dédiées au calcul d'une variable RTS et d'une variable RTM soient insérées dans les fonctions Sy. Le code CF* permet alors le calcul d'une variable RTS pour « Run-Time Store » et d'une variable RTM pour « Run-Time Mask » d'une façon similaire au calcul de la variable RTK.
L'application est adaptée pour utiliser la valeur de RTS (respectivement RTM) lors du calcul du code d'authentification ou de la signature électronique. Cela signifie que certaines des modifications de la valeur de RTS (respectivement RTM) par les fonctions tf se font avant l'emploi de RTS (respectivement RTM) par l'application et que d'autres se font après.
Si l'on désigne par RTS0 (respectivement RTM0) la valeur de RTS (respectivement RTM) au moment de son utilisation par l'application, et par TSend (respectivement RTMend) la valeur lors du franchissement d'un point de référence du code CF (par exemple la fin de l'exécution de CF), le serveur est adapté pour fournir à l'application une information ARTS (respectivement ARTM) préalablement - et préférentiellement simultanément - au moment où RTS (respectivement RTM) est utilisée par l'application, telle que ARTS (respectivement ARTM) soit la différence entre RTS0 (respectivement RTM0) et TSend (respectivement RTMend), la valeur obtenue lors de la précédente exécution et mémorisée par le serveur. On entend ici spécifiquement par «différence» une opération binaire injective. La fourniture de ARTs (respectivement ARTM) par le serveur permet à l'application de déterminer la valeur de RTSend (respectivement RTMend) obtenue lors de la précédente exécution, cette valeur n'étant correcte et ne correspondant à la valeur mémorisée par le serveur que parce que le code CF* a effectivement su calculer RTS0 (respectivement RTMo).
Le serveur et l'application sont adaptés pour que la valeur Uo soit préférentiellement fournie par le serveur et que les mises à jour des paramètres d'exécution x dans les points de contrôle soient préférentiellement réalisées grâce à des informations fournies par le serveur.
Le serveur est par ailleurs adapté pour mettre en œuvre un « point de non retour ». Le fait de démarrer le calcul d'un code d'authentification ou d'une signature électronique permet de franchir ce « point de non retour », par exemple lorsque l'application demande au serveur la valeur de Uo. Une fois ce point franchi, le code CF* doit terminer correctement et dans un bref délai l'authentification ou la signature électronique utilisant RTK, RTS et RTM, à défaut de quoi le serveur bloque irréversiblement l'usage de l'application.
Egalement, l'application et le serveur sont adaptés pour que les secrets soient renouvelés après chaque authentification ou signature électronique réussie. On désigne ici spécifiquement par «secrets» les données stockées par l'application et non l'information saisie par l'utilisateur. La façon de renouveler les secrets sous condition de réussite doit préférentiellement ne pas nécessiter le transfert de ces secrets entre l'application et le serveur. Si les secrets sont mis en oeuvre de façon asymétrique, un procédé de partage de clé tel que Diffie-Hellmann est préférentiellement mis en œuvre. Si les secrets sont mis en œuvre de façon symétrique, l'application et le serveur s'échangent préférentiellement une clé de mise à jour (DK) qui est appliquée de façon identique par l'application et le serveur sur les secrets existants afin d'en produire de nouveaux selon l'opération suivante :
secretSnew = H(secrets0id * DK) où H est une fonction à sens unique (préférentiellement une fonction dérivée d'une fonction de hachage) et * est un opérateur binaire.
La variable RTS est utilisée par le code CF* pour déterminer l'emplacement dynamique de stockage des secrets utilisés par l'application d'authentification et de signature électronique. L'emplacement de stockage des secrets sur le moyen de stockage MS est déterminé grâce à la valeur de RTSend- La valeur de RTSend obtenue lors de l'exécution précédente désigne l'emplacement actuel des secrets, la valeur obtenue lors de l'exécution courante désigne l'emplacement des secrets renouvelés. De la même façon que pour le renouvellement des secrets, la mise à jour de l'emplacement de stockage des secrets n'est faite qu'en cas de réussite de l'authentification ou de la signature électronique.
Une caractéristique importante du procédé P adapté pour que le code CF* calcule RTS est que l'emplacement des secrets utilisés pour l'authentification ou la signature électronique ne peut ainsi être connu sans exécuter l'application.
Il est important de remarquer d'une part que la valeur de l'information saisie par l'utilisateur (PIN) n'intervient pas dans le calcul des variables RTK, RTS ni RTM par le code CF*, n'entraînant ainsi pas de blocage de l'usage de l'application du fait d'une faute de frappe ; d'autre part qu'en cas d'abandon de l'utilisateur, l'application est en mesure de terminer le calcul de RTK, RTS et RTM et d'effectuer une communication avec le serveur s'appuyant sur ces calculs, n'entraînant ainsi pas de blocage en cas d'abandon ou de fermeture prématurée de l'application.
On conçoit aisément que le procédé permettant de déterminer l'emplacement des secrets à partir de la valeur de RTS doive être discret afin de ne pas être simplement contourné, et que l'espace des possibles doive également être suffisamment vaste pour que l'on ne puisse pas être certain que les secrets se trouvent à coup sûr dans une zone limitée du moyen de stockage MS ou dans un ou plusieurs fichiers donnés indexés par le système de gestion de fichiers du moyen MS.
Un premier exemple de tel procédé est de créer un ou plusieurs fichiers dans des arborescences liées au système d'exploitation du support d'exécution de l'application supposé suffisamment vaste. Un autre exemple encore plus discret est de ne pas stocker de secrets mais d'utiliser comme secrets les valeurs stockées dans des emplacements arbitraires du moyen de stockage ; la mise à jour des secrets entre application et serveur consiste alors pour l'application à indiquer au serveur la valeur des emplacements désignés par la valeur de RTS. Le procédé d'authentification à partir de ces secrets est adapté, puisqu'il n'est pas possible de garantir par un tel procédé que les valeurs contenues dans les emplacements ne seront pas modifiées par d'autres tâches ou applications accédant au moyen de stockage MS. L'authentification se fait alors non pas sur une certitude (égalité des secrets) mais sur une vraisemblance (degré de similitude des secrets).
Enfin, la variable RTM est utilisée par l'application pour crypter et décrypter le code exécutable de certains segments si dans lesquels on a inséré un point de contrôle.
Les adaptations de cette variante de réalisation permettent de contrer plusieurs types d'attaques supplémentaires.
Ainsi, l'attaque réalisée par un programme malicieux exportant les secrets (notamment, l'information saisie par l'utilisateur) et le code CF* de l'application à des fins d'analyse et d'expertise manuelle ne peut aboutir. En effet, ce programme malicieux n'ayant pas pu exécuter le code CF* avant de l'exporter pour les raisons rappelées dans la description de la première implémentation de l'invention ne peut pas non plus connaître la valeur de RTS, et donc ne peut exporter une partie des secrets nécessaires. L'attaquant récupérant le code CF* peut l'analyser et l'exécuter mais est pour cela obligé de franchir le « point de non retour ». S'il parvient à effectuer un calcul de RTS et donc à déterminer l'emplacement des secrets sur le moyen de stockage MS de l'utilisateur, il ne dispose pas de leur valeur et n'a qu'une faible probabilité de les obtenir dans les délais, le serveur exigeant une réponse de l'application juste après lui avoir fourni la valeur de ARTS- Cela entraîne un blocage de l'application. Le déblocage de l'application reste possible par l'utilisateur conservant d'autres preuves de son identité auprès du service en ligne mettant en œuvre le système d'authentification, mais ne se fait qu'après distribution d'un nouveau code CF* à l'utilisateur. L'attaquant perd ainsi tout bénéfice de l'attaque qu'il avait entreprise. Par ailleurs, une attaque réalisée par un programme malicieux s'appuyant sur la reconstitution et l'analyse manuelles du code CF (invariant) à partir d'un ou plusieurs codes CF* afin de modifier certains segments ¾ dans CF* ne peut aboutir. En effet, les éléments sensibles sont cryptés par la valeur de RTM et contiennent un point de contrôle. La valeur de RTM n'étant pas connue à moins d'exécuter le code CF* et de franchir un « point de non retour », le programme malicieux ne peut ni désactiver sélectivement ces éléments sensibles, ni les contourner puisqu'ils contiennent des points de contrôle. Un exemple d'élément sensible est la partie du code CF contrôlant que la saisie d'une information par l'utilisateur s'accompagne bien d'événements liés au matériel (frappe clavier, clic souris, ...).
Dans une variante de réalisation de la variante présentée ci-dessus, l'application est adaptée pour empêcher l'exécution automatique de l'application grâce à un test de Turing, par exemple, mise en œuvre d'un « captcha » que l'utilisateur doit saisir, ou d'un secret connu de l'utilisateur, affiché sous forme graphique, de façon toujours différente et non aisément reconnaissable par un programme, que l'utilisateur doit reconnaître parmi d'autres chaînes de caractères en lieu et place de l'emploi d'un masque RTM.
Dans une seconde variante de réalisation valable pour une application d'authentification ou de signature électronique non-connectée, c'est-à-dire mettant en œuvre avec le serveur lors de son exécution un protocole unidirectionnel et constitué d'un seul message, le procédé P est adapté pour que des fonctions tf dédiées au calcul d'une variable RTS et d'une variable RTM soient insérées dans les fonctions Sy. Le code CF* permet alors le calcul d'une variable RTS pour « Run-Time Store » et d'une variable RTM pour « Run-Time Mask » d'une façon similaire au calcul de la variable RTK.
L'application est adaptée pour utiliser la valeur de RTS (respectivement RTM) lors du calcul du code d'authentification ou de la signature électronique. Cela signifie que certaines des modifications de la valeur de RTS (respectivement RTM) par les fonctions tf se font avant l'emploi de RTS (respectivement RTM) par l'application et que d'autres se font après.
Le procédé P générant le code CF* est adapté de la façon suivante : grâce aux balises de contrôle, aucun segment Sj n'est exécuté avant un nombre paramétrable (Y) d'appels récursifs des fonctions Sy. Par ailleurs, l'appel des fonctions Sy peut se faire selon deux modes « get » (recherche) ou « set » (définition) grâce à la valeur d'un paramètre. En mode « get », l'appel récursif des fonctions Sy s'arrête après le nombre paramétrable Y d'appels ; on note RTSi (respectivement RTM la valeur prise par la variable RTS (respectivement RTM) à ce moment-là et cette valeur est mémorisée par l'application.
Lors d'une exécution de l'application et du code CF* ainsi adaptés, l'appel des fonctions Sy est fait une première fois en mode « get » avec la valeur de Uo de l'exécution précédente mémorisée par l'application, puis une seconde fois en mode « set » avec la valeur de U0 de l'exécution courante.
La valeur de RTSi (respectivement RTMi) obtenue lors du premier appel est utilisée déterminer l'emplacement de stockage des secrets mis en œuvre pour l'authentification ou la signature électronique (respectivement pour décrypter une ou plusieurs zones sensibles). La valeur de RTSi (respectivement RTMi) obtenue lors du second appel est utilisée déterminer l'emplacement ou seront stockés les secrets après leur emploi (respectivement pour recrypter une ou plusieurs zones sensibles après leur exécution).
L'application étant non-connectée, elle est adaptée pour tirer aléatoirement la valeur de U0. Le serveur est pour sa part adapté afin d'utiliser cette valeur et d'en contrôler le non-rejeu. Une façon préférentielle de réaliser ces adaptations lorsque l'application d'authentification est celle décrite dans la demande de brevet FR2937204 est de déduire, de façon simple et déterministe, la valeur de Uo de celle de la clé Rand tirée aléatoirement lors de la génération d'un mot de passe à usage unique. Or, la clé Rand est fournie au serveur car elle est suffisamment courte pour être embarqué dans le code d'authentification ou la signature électronique générée, et son non- rejeu est contrôlé ; la transmission de U0 au serveur et son non-rejeu sont donc assurés via ceux de Rand.
De même, l'application et les serveurs sont adaptés afin que les modifications des paramètres de l'exécution utilisés dans les points de contrôle soient effectuées par l'application et similairement par le serveur sans qu'application et serveur ne communiquent entre eux. Les adaptations de cette variante de réalisation permettent de contrer plusieurs types d'attaques supplémentaires.
Ainsi, l'attaque réalisée par un programme malicieux exportant les secrets (notamment, l'information saisie par l'utilisateur) et le code CF* de l'application à des fins d'analyse et d'expertise manuelles ne peut aboutir directement. Remarquons déjà d'une part qu'une telle attaque n'est pas automatique ni industrielle pour les raisons déjà présentées, d'autre part que l'export du code CF* nécessite que, bien que l'application soit non-connectée, elle soit stockée et exécutée sur un environnement qui soit connecté. Le programme malicieux n'ayant pas pu exécuter le code CF* avant de l'exporter pour les raisons rappelées dans la description ne peut pas non plus connaître la valeur de RTS, et donc ne peut exporter qu'une partie des secrets. L'attaquant récupérant le code CF* peut l'analyser et l'exécuter ; pour calculer une valeur correcte de RTS, il doit disposer de la valeur de U0 lors de l'exécution précédente et effectuer l'attaque - après analyse manuelle du code CF* - avant que le code CF* ne soit de nouveau exécuté par l'utilisateur, car cela entraînerait la modification de la valeur de RTS. Il peut alors, connaissant RTS, tenter d'obtenir les valeurs des secrets stockés aux emplacements désignés par RTS sur le moyen de stockage MS de l'utilisateur, ce qui nécessite d'une part que le moyen MS soit connecté, d'autre part que le programme malicieux prenne l'initiative d'établir une connexion sortante. Alors seulement, et dans le cas de l'application décrite dans la demande de brevet FR2937204 uniquement si l'utilisateur n'a pas mis en œuvre le moyen d'authentification, l'attaque pourrait aboutir. Il convient enfin de remarquer que l'installation d'un programme malicieux et sa capacité à établir discrètement des connexions sortantes sont fortement limitées sur des environnements d'exécution tels que des téléphones mobiles.
Par ailleurs, une attaque réalisée par un programme malicieux s'appuyant sur la reconstitution et l'analyse manuelle du code CF (invariant) à partir d'un ou plusieurs codes CF* afin de modifier certains segments si dans CF* ne peut aboutir directement. En effet, les éléments sensibles sont cryptés par la valeur de RTM et contiennent un point de contrôle. La valeur de RTM n'étant pas connue à moins d'exécuter le code CF*, le programme malicieux ne peut ni désactiver sélectivement ces éléments sensibles, ni les contourner puisqu'ils contiennent des points de contrôle. Il peut en revanche - théoriquement - modifier une partie non protégée du code CF* afin de rendre relativement discrète l'exécution du code CF* et de calculer la valeur de RTM, puis sur cette base décrypter les zones protégées, les modifier, et enfin exécuter le code CF* complet. L'application n'étant pas connectée, le programme malicieux devrait alors établir une connexion sortante pour fournir à un attaquant un code d'authentification ou une signature électronique valide calculé par cette attaque. Enfin, dans le cas de l'application décrite dans la demande de brevet FR2937204, ce code d'authentification devrait être utilisé par l'attaquant dans un délai très réduit (typiquement, moins d'une minute après son calcul) et avant que l'utilisateur n'en ait généré un autre. Il convient également de remarquer que l'installation d'un programme malicieux et sa capacité à s'exécuter et à établir une connexion sortante à l'insu de l'utilisateur - sont fortement limitées sur des environnements d'exécution tels que des téléphones mobiles.
Dans les revendications, le mot « comprenant » n'exclut pas d'autres éléments et l'article indéfini « un/une » n'exclut pas une pluralité.

Claims

REVENDICATIONS
Procédé de sécurisation d'un logiciel originel mettant en œuvre un secret, le procédé comprenant:
• partitionner (1) le logiciel en N éléments (si, s2, sN), N étant un entier strictement supérieur à 1 ;
• générer (3) M procédures sécurisées (Svj), M étant un entier supérieur ou égal à N, par, pour chaque procédure :
• tirage aléatoire (5) d'une fonction (tf) parmi une bibliothèque (L) de fonctions ;
• sélection d'un des N éléments ou de l'ensemble vide ;
• combinaison (7) de la fonction tirée aléatoirement et de l'élément sélectionné quand la sélection n'est pas l'ensemble vide ;
de sorte que chaque élément est combiné dans une seule procédure et que tous les éléments sont combinés ;
• modifier chaque procédure par introduction de balises de direction contrôlant les appels des procédures les unes par les autres et de balises contrôlant l'exécution des éléments ;
• concaténer (9) les M procédures en un logiciel sécurisé apte à être installé et exécuté sur une plateforme d'exécution non sécurisée pour mettre en œuvre le secret.
Procédé selon la revendication 1 , caractérisé en ce que les balises de direction contrôlant les appels des procédures les unes par les autres comportent :
• pour chaque procédure, une sélection d'une pluralité de procédures appelables en fonction d'un paramètre d'exécution ;
• des conditions non-prédictibles fonctions de paramètre d'exécutions, fixant l'exécution de certaines des procédures sélectionnées ;
• une suite mathématique définie par un premier terme et une fonction de récurrence définissant un argument d'appel de chaque procédure tel que si une procédure a comme argument d'appel l'élément de la suite d'indice n, alors les procédures appelées par celle-ci ont comme argument d'appel l'élément de la suite d'indice n+1.
3. Procédé selon la revendication 2, caractérisé en ce que la suite mathématique est la suite de Syracuse.
4. Procédé selon la revendication 2 ou 3, caractérisé en ce que la sélection des deux procédures appelables est basée sur une fonction uniforme du paramètre d'exécution assurant que la probabilité d'appel pour chaque procédure est substantiellement identique.
5. Procédé selon la revendication 2, caractérisé en ce que les balises contrôlant l'exécution des éléments comportent des appels vers des éléments extérieurs à l'élément contenant l'appel et, dans les éléments extérieurs, des repères de destination de ces appels.
6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les fonctions de la bibliothèque de fonction sont des fonctions de transformation modifiant la valeur d'au moins une variable.
7. Procédé selon la revendication 6, caractérisé en ce que le logiciel originel étant un logiciel mettant en oeuvre un procédé cryptographique nécessitant au moins un secret, le secret est fourni par la variable modifiée par les fonctions de transformation associées aux procédures.
8. Procédé selon la revendication 7, caractérisé en ce que le secret étant pour partie calculé et pour partie dépendant d'un secret non-calculé dont remplacement est dynamique et calculé, les fonctions de transformation modifient par leurs exécutions une seconde variable, la seconde variable étant un pointeur vers l'emplacement dynamique.
9. Procédé selon la revendication 8, caractérisé en ce que les fonctions de transformation modifient par leurs exécutions une troisième variable, la troisième variable étant utilisée par le logiciel pour crypter et décrypter au moins un des éléments.
10. Procédé selon la revendication 2, caractérisé en ce que le premier terme de la suite est calculé à partir d'un nombre aléatoire utilisé lors de la génération d'un mot de passe à usage unique.
11. Produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution du procédé selon l'une quelconque des revendications 1 à 10 lorsque ledit programme est exécuté sur un ordinateur.
12. Système dé sécurisation d'un logiciel originel mettant en œuvre un secret, le système comprenant un calculateur adapté pour exécuter le procédé selon l'une quelconque des revendications 1 à 10.
PCT/FR2012/000143 2011-04-14 2012-04-13 Procédé et système de sécurisation d'un logiciel WO2012140339A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/111,691 US20140047555A1 (en) 2011-04-14 2012-04-13 Method and system for securing a software program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1153219A FR2974207B1 (fr) 2011-04-14 2011-04-14 Procede et systeme de securisation d'un logiciel
FR1153219 2011-04-14

Publications (1)

Publication Number Publication Date
WO2012140339A1 true WO2012140339A1 (fr) 2012-10-18

Family

ID=46001303

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/000143 WO2012140339A1 (fr) 2011-04-14 2012-04-13 Procédé et système de sécurisation d'un logiciel

Country Status (3)

Country Link
US (1) US20140047555A1 (fr)
FR (1) FR2974207B1 (fr)
WO (1) WO2012140339A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3008837B1 (fr) 2013-07-19 2015-08-07 In Webo Technologies Procede d'authentification forte
US20170076106A1 (en) 2015-09-16 2017-03-16 Qualcomm Incorporated Apparatus and method to securely control a remote operation
US10546138B1 (en) 2016-04-01 2020-01-28 Wells Fargo Bank, N.A. Distributed data security
US11263316B2 (en) * 2019-08-20 2022-03-01 Irdeto B.V. Securing software routines
CN114282076B (zh) * 2022-03-04 2022-06-14 支付宝(杭州)信息技术有限公司 一种基于秘密分享的排序方法和系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5673318A (en) * 1993-04-23 1997-09-30 International Business Machines Corporation Method and apparatus for data authentication in a data communication environment
US20100027796A1 (en) * 2008-08-01 2010-02-04 Disney Enterprises, Inc. Multi-encryption
FR2937204A1 (fr) 2008-10-15 2010-04-16 In Webo Technologies Systeme d'authentification
WO2011041871A1 (fr) * 2009-10-08 2011-04-14 Irdeto Canada Corporation Système et procédé d'auto-modification agressive dans des systèmes d'appels de fonctions dynamiques

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5850450A (en) * 1995-07-20 1998-12-15 Dallas Semiconductor Corporation Method and apparatus for encryption key creation
CA2293650C (fr) * 1997-06-09 2012-09-25 Christian Sven Collberg Techniques d'obscurcissement pour augmenter la securite de logiciels
US7430670B1 (en) * 1999-07-29 2008-09-30 Intertrust Technologies Corp. Software self-defense systems and methods
US7770016B2 (en) * 1999-07-29 2010-08-03 Intertrust Technologies Corporation Systems and methods for watermarking software and other media
CA2305078A1 (fr) * 2000-04-12 2001-10-12 Cloakware Corporation Logiciel infalsifiable - encodage d'information massive
US8266710B2 (en) * 2004-08-09 2012-09-11 Jasim Saleh Al-Azzawi Methods for preventing software piracy
US7587616B2 (en) * 2005-02-25 2009-09-08 Microsoft Corporation System and method of iterative code obfuscation
US7620987B2 (en) * 2005-08-12 2009-11-17 Microsoft Corporation Obfuscating computer code to prevent an attack
US8365286B2 (en) * 2006-06-30 2013-01-29 Sophos Plc Method and system for classification of software using characteristics and combinations of such characteristics
US20090249492A1 (en) * 2006-09-21 2009-10-01 Hans Martin Boesgaard Sorensen Fabrication of computer executable program files from source code
US8041954B2 (en) * 2006-12-07 2011-10-18 Paul Plesman Method and system for providing a secure login solution using one-time passwords
US8130956B2 (en) * 2007-08-02 2012-03-06 International Business Machines Corporation Efficient and low power encrypting and decrypting of data

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5673318A (en) * 1993-04-23 1997-09-30 International Business Machines Corporation Method and apparatus for data authentication in a data communication environment
US20100027796A1 (en) * 2008-08-01 2010-02-04 Disney Enterprises, Inc. Multi-encryption
FR2937204A1 (fr) 2008-10-15 2010-04-16 In Webo Technologies Systeme d'authentification
WO2011041871A1 (fr) * 2009-10-08 2011-04-14 Irdeto Canada Corporation Système et procédé d'auto-modification agressive dans des systèmes d'appels de fonctions dynamiques

Also Published As

Publication number Publication date
FR2974207B1 (fr) 2013-05-24
US20140047555A1 (en) 2014-02-13
FR2974207A1 (fr) 2012-10-19

Similar Documents

Publication Publication Date Title
Plohmann et al. Case study of the miner botnet
CN106063185B (zh) 用于安全地共享数据的方法和装置
EP2614458B1 (fr) Procede d&#39;authentification pour l&#39;acces a un site web
IL203763A (en) A system and method for verifying, transmitting science and protecting against illegal expenditure of a scientist
WO2008008123A2 (fr) Dispositif, procédé et système de stockage à pare-feu
US20080229115A1 (en) Provision of functionality via obfuscated software
EP3022867B1 (fr) Procéde d&#39;authentification forte
WO2012140339A1 (fr) Procédé et système de sécurisation d&#39;un logiciel
US20190147451A1 (en) Collaborate Fraud Prevention
Gupta Security and privacy issues of blockchain technology
Li et al. Double and nothing: Understanding and detecting cryptocurrency giveaway scams
TWI671655B (zh) 用於程式安全保護的系統和方法
Gupta A deep dive into security and privacy issues of blockchain technologies
Duncan et al. Cloud cyber security: finding an effective approach with unikernels
Mayberry et al. Multi-client Oblivious RAM secure against malicious servers
FR3008267A1 (fr) Dispositif, systeme et procede de securisation de transfert de donnees entre un dispositif de stockage de donnees portable source et un systeme informatique destinataire
Boyarchuk et al. Keeping up with the emotets: Tracking a multi-infrastructure botnet
US20190319986A1 (en) System and methods for developing secure platform to deliver end-to-end protection and safety for transactions using multi-dimensional, multi-layered security control
FR3020888A1 (fr) Chiffrement d&#39;une cle de protection de secrets protegeant au moins un element sensible d&#39;une application
FR2997204A1 (fr) Procede de telechargement d&#39;au moins un composant logiciel dans un appareil informatique, produit programme d&#39;ordinateur, appareil informatique et systeme informatique associes
US20240022546A1 (en) Master ledger and local host log extension detection and mitigation of forged authentication attacks
Pham Foundations of Adaptive Cyber Defense against Advanced Persistent Threats
Mehta et al. Decentralized Storage System to Store Data Using Blockchain Technology
Devassy et al. Safeguarding blockchains from adversarial tactics
Parisi et al. Wallet Security

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12716490

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14111691

Country of ref document: US

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: CONSTATATION DE LA PERTE D UN DROIT CONFORMEMENT A LA REGLE 112(1) CBE (OEB FORM 1205A EN DATE DU 31/01/2014)

122 Ep: pct application non-entry in european phase

Ref document number: 12716490

Country of ref document: EP

Kind code of ref document: A1