EP4183098A1 - Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches - Google Patents

Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches

Info

Publication number
EP4183098A1
EP4183098A1 EP21739226.5A EP21739226A EP4183098A1 EP 4183098 A1 EP4183098 A1 EP 4183098A1 EP 21739226 A EP21739226 A EP 21739226A EP 4183098 A1 EP4183098 A1 EP 4183098A1
Authority
EP
European Patent Office
Prior art keywords
data
cryptographic
unencrypted
cryptographic processing
key
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
EP21739226.5A
Other languages
German (de)
English (en)
Inventor
Nicolas CHRUPALLA
Nabil Hamzi
Rémi GERAUD
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Banks and Acquirers International Holding SAS
Original Assignee
Banks and Acquirers International Holding 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 Banks and Acquirers International Holding SAS filed Critical Banks and Acquirers International Holding SAS
Publication of EP4183098A1 publication Critical patent/EP4183098A1/fr
Pending legal-status Critical Current

Links

Classifications

    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • 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

  • TITLE Device, method and program for secure communication between white boxes
  • the invention relates to the field of data protection. More particularly, the invention relates to the field of the protection of the exchange of data during the execution of routines. Even more specifically, the invention relates to the field of the protection of data exchanged between modules for executing cryptographic primitives in the context of the execution of an application within a single data processing device.
  • An object of cryptography is to have algorithms and protocols to protect a communication channel against data capture attempts.
  • Two main types of systems are opposed: the so-called “black box” systems and the so-called “white box” systems. It is considered in a “black box” type system that the "source” of the information and the “destination” of the information are secure: an attacker only has access to the inputs/outputs of the source and/or the destination, but does not have access to the encryption and decryption algorithm itself, which is executed inside a secure object to which the attacker does not have access, called a black box.
  • the main problem is the practical implementation of the techniques resulting from laboratories. Thus, protocols deployed in the wrong context, poorly implemented algorithms, or inappropriate parameters can provide an additional entry point for attackers.
  • Cryptographic white boxes are software components that perform cryptographic operations with an embedded secret key (hardcoded or dynamically transmitted). White boxes are designed in such a way that recovering the secret key is difficult, both in the traditional sense of cryptanalysis, but also in the face of adversaries capable of gaining access to the software's internal components (e.g. memory, cache accesses, source code, etc.) or even modifying the encryption software or its behavior.
  • the software's internal components e.g. memory, cache accesses, source code, etc.
  • a white box attacker potentially has full access to the software implementation of a cryptographic algorithm: the binary is supposed to be visible and modifiable by the attacker and he has full control of the platform execution (CPU calls, memory registers, etc.). Therefore, the implementation of the encryption algorithm constitutes one of the only protection barriers against an attack.
  • software implementations that resist these white-box attacks are referred to as white-box implementations. They constitute the type of applications in which a cryptographic key is used to protect goods or services, such as for example in the field of DRM. In such cases, the attacker may have an interest in reverse-engineering the application and extracting the key from it (hence the usefulness of dynamically provided key white boxes).
  • the invention does not pose the problems previously identified. More particularly, the invention makes it possible to avoid on the one hand by code lifting practices and on the other hand by the exposure of intermediate data.
  • Cryptographic data processing method for implementing a cryptographic function, method implemented within an electronic data processing device comprising a processor, a memory and a clique of cryptographic processing modules, said method comprising , the following steps, implemented by a current cryptographic processing module of the clique of cryptographic processing modules, said current cryptographic processing module belonging to a chain of at least two cryptographic processing modules executed for the implementation of said cryptographic function: reception of incoming data; determination of a decryption key to be applied to said incoming data; decrypting, using the incoming data key, delivering unencrypted incoming data; implementation of at least one cryptographic operation on said unencrypted incoming data, delivering unencrypted outgoing data; optionally determining a next cryptographic processing module to be executed on said unencrypted outgoing data; obtaining an encryption key of said unencrypted outgoing data; encrypting said unencrypted outgoing data using the previously determined encryption key for said outgoing data, delivering said encrypted outgoing data, which may be intermediate
  • the invention makes it possible to prevent the intermediate data which passes between two cryptographic processing modules from being intercepted and used by an attacker.
  • the decryption step which, using the key for the incoming data, delivers unencrypted incoming data comprises a step for combining the incoming data with at least one table of a series of tables integrated into the within said cryptographic processing module.
  • the step of determining a decryption key to be applied to said incoming data comprises a step of deriving said decryption from a master key, said derivation step taking into account a position of said module of common cryptographic processing within the chain of cryptographic processing modules.
  • the step of determining a next cryptographic processing module to be executed on said unencrypted outgoing data comprises:
  • a step of obtaining an identifier of the next cryptographic processing module associated with said next location is obtained.
  • the chaining of the cryptographic processing modules depends on the data which are themselves encrypted and the module is able to determine, potentially alone, what is the next module to execute in the chain based on this data. We therefore have a more complex dynamic routing to analyze for an attacker.
  • the step of obtaining an encryption key for said unencrypted outgoing data comprises a step of deriving said encryption from a master key, said derivation step taking into account a position of said next cryptographic processing module in the chain of cryptographic processing modules.
  • the step of obtaining an encryption key for said unencrypted outgoing data comprises a step of obtaining said encryption key from the identifier of the next cryptographic processing module.
  • the current module can use the identifier of the next module to select a key which it knows a priori that it is suitable for the next module.
  • said method further comprises a step of transmitting encrypted outgoing data to a next cryptographic processing module of said chain of at least two cryptographic processing modules according to at least one routing datum present within incoming data and/or unencrypted incoming data.
  • the current module does not rely on the actuation of a mechanism for returning to a caller the data it has just processed, but on the contrary is able to directly supply the intermediate data to a following module so that these the latter are directly processed. This increases the safety of the whole.
  • the step of implementing at least one cryptographic operation on said unencrypted incoming data, delivering unencrypted outgoing data consists of the application of a cryptographic primitive.
  • the invention takes the form of a cryptographic data processing device for the implementation of a function cryptographic.
  • a cryptographic data processing device for the implementation of a function cryptographic.
  • Such an electronic data processing device comprises a processor, a memory and a clique of cryptographic processing modules.
  • the device comprises implements a current cryptographic processing module of the clique of cryptographic processing modules, said current cryptographic processing module belonging to a chain of at least two cryptographic processing modules executed for the implementation of said cryptographic function , said current cryptographic processing module comprising:
  • Decryption means, using the incoming data key, delivering unencrypted incoming data
  • the various steps of the methods according to the invention are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of an execution device according to the invention and being designed to control the execution of the various steps of the methods, implemented at the level of the communication terminal, of the electronic execution device and/or of the control device, within the framework of a distribution of processing to be performed and determined by scripted source code.
  • the invention also relates to programs capable of being executed by a computer or by a data processor, these programs comprising instructions for controlling the execution of the steps of the methods as mentioned above.
  • a program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention also relates to an information medium readable by a data processor, and comprising instructions of a program as mentioned above.
  • the information carrier can be any entity or device capable of storing the program.
  • the medium may include a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording medium, for example a mobile medium (memory card) or a hard drive or SSD.
  • the information medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • the invention is implemented by means of software and/or hardware components.
  • module may correspond in this document to a software component, a hardware component or a set of hardware and software components.
  • a software component corresponds to one or more computer programs, one or more sub-programs of a program, or more generally to any element of a program or software capable of implementing a function or a set of functions, as described below for the module concerned.
  • Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, set-top-box, router, etc.) and is likely to access the hardware resources of this physical entity (memories, recording media, communication bus, electronic input/output cards, user interfaces, etc.).
  • a hardware component corresponds to any element of a hardware assembly (or hardware) able to implement a function or a set of functions, according to which is described below for the module concerned. It can be a hardware component that can be programmed or has an integrated processor for executing software, for example an integrated circuit, a smart card, a memory card, an electronic card for executing firmware ( firmware), etc
  • FIG. 1 describes a system in which the invention can be implemented
  • FIG. 3 illustrates another example of the method which is the subject of the invention.
  • FIG. 4 describes the different steps of an exemplary embodiment of the method of the invention.
  • FIG. 5 illustrates an architecture of a calling device capable of implementing a processing method of the invention
  • the general principle of the invention consists in providing execution modules with cryptographic primitives, each with an additional layer of encryption at the entry and at the exit of the execution module, within the framework of a chaining of “unitary” module calls to fulfill one or more cryptographic (sub)functions predetermined by the calling application, using a chaining mechanism, some embodiments of which, according to the invention, are described by the following.
  • a typical example of implementation of the technique described in relation to FIG. 1 is carried out in a system comprising a calling computer program (AppA) (such as an application running on an operating system (OS) of the WindowsTM type, MacOS TM, LinuxTM still AndroidTM), itself running on a physical device (DPy).
  • AppA calling computer program
  • OS operating system
  • DPy physical device
  • An electronic device comprises a processor (P), a memory (M), and data transmission means (TRD).
  • These data transmission means (TRD) can take several forms, as explained below. It may also include, depending on the embodiments, (optional) hardware components and/or software for display (Disp), input (KBD) and/or printing (IMP).
  • the application can for example be a music/video player, or even a payment application or even an application managing access to sensitive data stored on the electronic device, an identification or authentication application, etc. .
  • This computer program (AppA) has a need, during its execution, to implement one or more cryptographic functions (F1, F2, F3, etc.). Generally, these functions are not directly integrated into the computer program. Instead, it calls functions that are available within a library (LIB1, LIB2,...) (.lib, .dll, etc. depending on the operating system). This library is loaded by the calling program (AppA), which is responsible for calling the cryptographic function or the cryptographic primitive required in the white box (Fl, F2, F3, etc.), either directly or via the intermediary of the operating system (OS).
  • OS operating system
  • this cryptographic function or this cryptographic primitive is called as it is and when two cryptographic functions or two cryptographic primitives (each in a white box) are called one after the other, the intermediate data Dlnt (ie outputs of the first white box and supplied to the second white box) pass in the clear, as explained above.
  • the proposed technique makes it possible to solve both the problem of transition in plain text of intermediate data while limiting the possibilities of lifting code, by dividing the functions rendered by a white box, by encrypting (masking) the inputs/outputs of the modules and by dynamically routing the execution of the different modules between them, as explained in figure 2.
  • the following definitions are recalled:
  • a cryptographic primitive is a low-level cryptographic algorithm, on the basis of which in particular a security system is built.
  • a cryptographic algorithm can relate to a cryptographic hash function (for example SHA-1, SHA3, etc.) or even an encryption function (for example AES, DES);
  • a cryptographic primitive uses cryptographic operations (permutation, rotations, linear transformations, algebraic operations on integers or bits, additions, multiplication, XOR, etc.);
  • a cryptographic function includes the implementation of one or more cryptographic primitives, according to a chaining (routing) defined by the author of the cryptographic function, according to the destination of the cryptographic function (ie what this function is used for). it, is it intended as part of a security architecture).
  • a mechanism is described in which a cryptographic primitive (Pci) and a cryptographic primitive (Pc2) are used to implement a cryptographic function (F1), by the calling Application (AppA), in the framework of the system of FIG. 1.
  • the cryptographic primitives are each implemented in a dedicated module (M1, M2).
  • the application AppA provides input data (Din) to the module M1, then obtains intermediate data (Dlnt), which are transmitted, as input data, to the module M2, which then uses the intermediate data to produce the output data (DOut).
  • the module M1 comprises an output stage C1, which performs an encryption of the intermediate data (Dlnt) before the communication thereof to the application AppA.
  • the module M2 comprises an input stage D2, which performs a decryption of the intermediate data (Dlnt) before the use thereof within the framework of the primitive PC2.
  • the proposed technique makes it possible to solve, on the one hand, a problem of disclosure of intermediate data when data is exchanged between modules and when this data temporarily leaves the secure environment provided by the module: it could be intercepted by an attacker at this time. precise.
  • the "intermediate data" could be accessible to an attacker when transiting outside the module's environment.
  • an attacker can take a module out of its context and use it (for example as an autonomous decryption primitive) elsewhere.
  • the invention makes it possible to respond to the contradiction generated by the very principle of "white box” and "lifting code”, according to a new axis of implementation: to increase the efficiency of a white box, it is theoretically necessary to group together cryptographic functions within a single white box. To limit the risks due to “code lifting”, on the contrary, cryptographic primitives must be separated as much as possible.
  • a method is proposed to increase security, in particular white box implementations, by securing the data in transit (intermediate data) between the modules, while guaranteeing a correct execution flow (thus protecting for example against attacks by “code-lifting”).
  • a module is implemented in the form of a library (software) or a dedicated component (hardware) and that this module implements, at most, a cryptographic primitive (and possibly only a cryptographic primitive portion).
  • the current module is equipped with a "masking" functionality of the data with the following module.
  • the masking consists of the application of an encryption of the intermediate data before their transmission to the next module, so that these intermediate data are ideally inaccessible and at the very least unusable, even for the calling application. .
  • FIG. 3 Another example comprising four modules (X, Y, Z, T) is described in relation to FIG. 3.
  • the technical solution proposed in the present invention consists in using pairs of corresponding codings between modules. Concretely, this means that in the X module, we add a (simple) encryption capacity (for a KX2 key) and a decryption capacity (for a KX2 key). The same thing is done for the modules Y, Z and T.
  • the intermediate data Dint0 and Dint1 are encrypted (and/or masked).
  • the routing mechanism can be either internal to the modules, carried out according to an input variable or even a header field of the input data (Din) and the intermediate data (DintO and Dintl). Alternatively, the routing mechanism can be implemented by the calling application or else by a specific routing module.
  • the data transmitted between the modules is always encrypted, and therefore not easily accessible, not only for an attacker, but also for the calling application itself; the intermediate data stream cannot be modified (for example by “code-lifting”) otherwise the intermediate data decryption step will not provide an exploitable result (when entering the next white box); the implementation of a "lifting code” on the entire chain of modules cannot be carried out easily, due to the dispersion of the calling logic, this one being in fact distributed between several "actors including the "modules" themselves, which may transmit information to a different caller.
  • the invention in addition to protecting the intermediate data, the invention also makes it possible to protect the execution logic of the cryptographic primitives on the one hand and of the cryptographic functions on the other.
  • One or more modules of the plurality (of the clique) of modules can also implement mechanisms for differentiated calls and for routing intermediate data according to needs. Potentially all modules in the module clique can implement routing mechanisms.
  • the decryption 30 and encryption 60 steps are mutually optional: depending on the position of the module in the chain of modules, it is possible that one or the other of these steps (and their dependent steps obtaining keys) are not implemented. However, at least one of the two (encryption or decryption) is necessarily implemented. More specifically: if the module is the first module in the chain, decryption of the input data is not necessary; if the module is the last module in the chain (delivering final output data, i.e. which is not intermediate), the step of encrypting this output data is optional.
  • KJ decryption key
  • K_0 an encryption key
  • the routing between the modules is performed using a specific field of the incoming data. More specifically, two possibilities are concretely implemented: the first consists in using a header of the incoming data, this header not being encrypted identically to the incoming data. The header is encrypted or masked according to a different process in each module, but whatever the process used, each module is able to decode or decrypt this header.
  • the advantage here is to make it possible to obtain a decryption key for the incoming data encrypted according to the value of the header.
  • the header then has two distinct and complementary functions: an encryption key determination function, which makes it possible to have this key dynamically and a routing function which makes it possible to encrypt the outgoing data with a key, also obtained dynamically, and determining the next module in the data processing chain.
  • the second consists of hiding this field in the encrypted incoming data itself, at a location known to the current module and the previous module. The value of this field is not known until the data is decrypted by the current module.
  • the module knows the decryption key to use to decrypt the incoming data. It is therefore not necessary to determine this key according to the value of the header, and it is thus possible to reduce the size of the binary of the module (and the execution time).
  • the value of the specific field is known.
  • the routing function is then implemented, after application of the cryptographic function of the module, in the same way as previously (ie the value of the field which makes it possible to encrypt the outgoing data with an encryption key, obtained dynamically, and to determine the next module in the data processing chain.
  • a current module at a time "t" is only informed of the minimum required, namely the decryption key for incoming data, the next module to be called and the encryption key for outgoing data corresponding to this next module to be called.
  • the current module only implements an “XOR” type cryptographic operation, the current module:
  • An advantage of such an implementation is to potentially allow the same module of the clique of modules to be called several times for the implementation of a cryptographic primitive (several operations of masking, shifting, etc. ) or a cryptographic function (several calls of the same primitive).
  • each module can, depending on the operational implementation conditions, implement several cryptographic operations (for example, but not only, when cryptographic operations are frequently linked together, or when such groupings are justified).
  • the entry and exit keys are dynamically obtained: the objective is to prevent a key from being permanently integrated into a module, this module then being able to be used as it sees fit by a potential attacker.
  • this way of doing things is not mandatory, because it is recalled that the modules are implemented sequentially or iteratively so as to produce a complete cryptographic function, which may include obtaining one or more encryption, also dynamically.
  • the output encryption and input decryption operations, implemented in the various modules, during the execution of these are ideally simple and fast, so as not to overload the code modules "no necessary" for the effective implementation of the cryptographic primitive or cryptographic operation.
  • the objective is to ensure that the security of incoming and outgoing data is increased without excessively increasing the size of the code on the one hand and without excessively increasing the time necessary for the implementation of the cryptographic function. It is therefore necessary to strike a balance between the interest of protection and the speed of execution.
  • the encryption/decryption can comprise only a few cryptographic operations (two to six for example), implemented on a string of bits or on a string of bytes or an integer, these cryptographic operations being symmetrical: the operations decryption operations are the inverses of the encryption operations and vice versa, for two modules routed with each other.
  • the encryption keys in this case, consist of the sequence (in a sequence), more or less long, of unitary encryption operations.
  • the encryption of the output data includes, in a module X, a permutation (operation SI), followed by an addition (operation S2), followed by a new permutation (operation S3)
  • the decryption of the input data corresponding to these output data, in module Y includes: a permutation (operation El, inverse of operation S3), a subtraction (operation E2, inverse of operation S2), and a new permutation (Operation E3, inverse of operation SI).
  • the encryption key here, is formed of the triplet ⁇ SI;S2;S3 ⁇ and the decryption key is formed of the triplet ⁇ El;E2;E3 ⁇ .
  • the encryption and decryption keys correspond to secret sequences (suites) of unitary encryption operations.
  • the complexity of the operations of encryption of the output data and of encryption of the input data essentially depends on the number of useful cryptographic operations implemented within the module. For example, when the module includes only one or two useful cryptographic operations (a useful cryptographic operation is a cryptographic operation of the module which is used to process the data for the implementation of the cryptographic primitive), the encryption or decryption included in this module are generally simpler and faster. Conversely, if the module implements an entire cryptographic primitive, such as AES or 3DES (and therefore includes many useful cryptographic operations), then the encryption or decryption operations included in this module can be more complex and heavier and understand a complete implementation based on longer and more complex keys.
  • the first module of a chain does not necessarily need encryption and the last module of a chain does not need decryption. (It is possible to encrypt (resp. decrypt) for these steps, but this does not necessarily provide additional protection).
  • the corresponding keys, used in the operations of decryption of the input data and encryption of the output data can be chosen manually or automatically; one way to obtain these keys is to use a key derivation function (such as HKDF) from a master key.
  • a key derivation function such as HKDF
  • the encryption key for module i (which is the decryption key for module i + 1) can be derived as HKDF (seed, i), the seed being for example the key used for the previous module (i-1), an independent master key, an initial parameter, etc.
  • the advantage is also that the master key, initial, can vary with each call of the clique of modules.
  • Other implementations are possible, such as for example in the case of the sequences of unit operations presented previously, a derivation of the following sequence according to the preceding sequence and the identifier of the module.
  • an input variable indicates the key to consider.
  • Such an implementation allows perform intelligent routing, ensuring that in a first given situation, a first encryption (resp. decryption) is used while in a second given situation, a second encryption (resp. decryption) is used.
  • the procedure for encrypting the output data implements all or part of the cryptographic primitive itself, when possible.
  • the objective of a module is to hide the key (and not the implementation of the encryption algorithm itself), this implementation is used, with a different key, to encrypt the output data (resp. decrypt the input data). In this way, the additional code volume is relatively limited.
  • the call and data routing logic between modules can, as explained previously, be implemented by the modules themselves, which as the execution progresses tasks entrusted to them, apply to the data received and processed by them, a data routing. It is also possible, in another exemplary embodiment, to have a specific module (called a routing module), which is responsible, using particular encryption mechanisms, for implementing this routing. It is in this case a gateway module, which is an intermediary between the calling application and the modules fulfilling the cryptographic functions.
  • a routing module which is responsible, using particular encryption mechanisms, for implementing this routing.
  • a gateway module which is an intermediary between the calling application and the modules fulfilling the cryptographic functions.
  • An electronic execution device capable of processing and executing code according to the method described previously is presented.
  • An electronic execution device comprises a memory 51 (and/or possibly secured and/or two separate memories, one secured and the other not), a processing unit 52 equipped for example with a microprocessor (and/or possibly secured and/or two separate processors, one secured and the other not), and controlled by the computer program 53, implementing the method as previously described.
  • the invention is implemented at least partially in the form of an application AppA installed on this device.
  • a cryptographic data processing device for the implementation of cryptographic functions, which comprises a processor (52), a memory (51) and a clique of cryptographic processing modules (53), implemented in a program.
  • the device implements a current cryptographic processing module of the clique of cryptographic processing modules, said current cryptographic processing module belonging to a chain of at least two cryptographic processing modules executed for the implementation of said cryptographic function, said current cryptographic processing module comprising:
  • Decryption means, using the incoming data key, delivering unencrypted incoming data
  • the device also comprises the means for implementing all the steps mentioned above, either in a material form, when specific components are dedicated to these tasks, or in a form software related to one or more firmware executing on one or more processors of the execution device.

Abstract

L'invention se rapporte à un procédé cryptographique de traitement de données pour la mise en œuvre d'une fonction cryptographique, procédé mis en œuvre au sein d'un dispositif électronique de traitement de données comprenant un processeur, un mémoire et une clique de modules de traitement cryptographique, ledit procédé comprenant, les étapes suivantes, mises en œuvre par un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaine d'au moins deux modules de traitement cryptographique exécutés pour la mise en œuvre de ladite fonction cryptographique : - réception (10) de données entrantes (D_A); - détermination (20) d'une clé de déchiffrement (K_I) à appliquer sur lesdites données entrantes (D_A) en fonction d'une clé maitre et d'une position du module de traitement cryptographique courant; - déchiffrement (30), à l'aide de la clé (K_I) des données entrantes (D_A), délivrant des données entrantes non chiffrées (DI_nc); - mise en œuvre (40) d'au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc); - optionnellement détermination (45) d'un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées; - obtention (50) d'une clé de chiffrement (K_O) desdites données sortantes non chiffrées (DO_nc); - chiffrement (60) desdites données sortantes non chiffrées (DO_nc) à l'aide de la clé de chiffrement (K_O) desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées (D_B), qui peuvent être des données intermédiaires.

Description

TITRE : Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches
1. Domaine
L'invention se rapporte au domaine de la protection des données. Plus particulièrement, l'invention se rapporte au domaine de la protection de l'échange de données au cours de l'exécution de routines. Plus spécifiquement encore, l'invention se rapporte au domaine de la protection des données échangées entre des modules d'exécution de primitives cryptographiques dans le cadre de l'exécution d'une application au sein d'un seul dispositif de traitement de données.
2. Art Antérieur
Un objet de la cryptographie est de disposer d'algorithmes et de protocoles pour protéger un canal de communication contre des tentative de captation de données. Deux grands types de systèmes sont opposés : les systèmes dits de « boite noire » et les systèmes dits de « boite blanche ». On considère dans un système de type « boite noire » que la « source » de l'information et la « destination » de l'information sont sûres : un attaquant a seulement un accès aux entrées/sorties de la source et/ou de la destination, mais n'a pas accès à l'algorithme de chiffrement et de déchiffrement lui-même, qui est exécuté à l'intérieur d'un objet sécurisé auquel l'attaquant n'a pas accès, appelé boite noire. Toutefois, du point de vue industriel, le problème principal est la mise en oeuvre pratique des techniques issues de laboratoires. Ainsi, des protocoles déployés dans le mauvais contexte, des algorithmes mal mis en oeuvre, ou des paramètres inappropriés peuvent offrir un point d'entrée supplémentaire pour les attaquants.
Le problème de mise en oeuvre pratique est encore plus complexe lorsque le modèle d'attaque en boîte noire n'est plus satisfait : l'attaquant peut alors avois accès à un certain nombre d'informations sur la manière dont fonctionnent les processus de chiffrement/déchiffrement à l'intérieur de la boite noire. Par ailleurs, avec le déploiement de la cryptographie dans des applications qui sont exécutées sur des appareils ouverts tels que PC, tablettes ou smartphones, sans nécessairement utiliser d'éléments sécurisés, le problème ne se pose plus en termes de boite noire, mais bien en termes de boite blanche.
Les boîtes blanches cryptographiques sont des composants logiciels qui exécutent des opérations cryptographiques avec une clé secrète intégrée (codée en dur ou transmise dynamiquement). Les boîtes blanches sont conçues de telle manière que la récupération de la clé secrète est difficile, à la fois dans le sens traditionnel de la cryptanalyse, mais aussi face à des adversaires capables d'accéder aux composants internes du logiciel (par exemple, la mémoire, les accès au cache, le code source, etc.) ou même de modifier le logiciel de chiffrement ou le comportement de celui-ci.
Ainsi, un attaquant d'une boîte blanche dispose potentiellement d'un accès complet à l'implémentation logicielle d'un algorithme cryptographique : le binaire est supposé être visible et modifiable par l'attaquant et celui-ci a le plein contrôle de la plateforme d'exécution (appels CPU, registres mémoire, etc.). Par conséquent, l'implémentation de l'algorithme de chiffrement constitue l'une des seules barrières de protection contre une attaque. Ainsi, les implémentations logicielles qui résistent à ces attaques en boîte blanche sont dénommées implémentations en boîte blanche (white-box en anglais). Elles constituent la d'applications dans lesquelles une clé cryptographique est utilisée pour protéger des biens ou des services, comme par exemple dans le domaine des DRM. Dans de tels cas, l'attaquant peut avoir un intérêt à rétro-concevoir l'application et à en extraire la clé (d'où l'utilité des boites blanches à clés fournies dynamiquement). Des attaques similaires peuvent se produire à l'encontre de l'intérêt de l'utilisateur, par exemple quand une application bancaire est exécutée sur un dispositif infecté par des logiciels malveillants ou sur un système dans lequel certains utilisateurs ont des privilèges plus élevés que d'autres. Dans de telles situations, lorsque les opérations cryptographiques sont implémentées au travers de bibliothèques cryptographiques standards (connues et documentées) comme OpenSSL ou que les clés cryptographiques sont stockées simplement dans la mémoire, la clé secrète sera découverte, et ce quelle que soit la force de la primitive cryptographique utilisée.
Par ailleurs, même si l'attaquant n'est pas en mesure d'obtenir la clé sécrète, il peut tout de même tenter de tirer partie de la boite blanche en l'utilisant telle qu'elle pour effectuer des opérations de chiffrement ou de déchiffrement, à l'aide d'une attaque appelée « code lifting ». Dans cette attaque, l'attaquant ne cherche pas à extraire la clé secrète à partir de l'implémentation, mais utilise l'ensemble de l'application comme passeport pour la mise en oeuvre de fonctions cryptographiques. Les fonctionnalités de la boite blanche sont directement exploitées en tant que telle. Le « code lifting » peut être combattu dans la pratique en appliquant des codages externes au système original, et notamment les codages annihilant à d'autres endroits dans l'application principale. Il est cependant nécessaire d'utiliser des techniques d'offuscation ou d'isolation de processus dans un environnement sécurisé (au sein du terminal, PC, tablette) afin de s'assurer que les fonctions G et F ne peuvent pas être extraites de la fonction appelante. Par conséquent, il est nécessaire de disposer d'un composant sécurisé, ce qui n'est pas toujours possible.
Par ailleurs, un autre problème réside dans l'enchaînement d'exécution de codes en boite blanche. En effet, a supposé que l'implémentation en boite blanche soit efficacement mise en oeuvre, et qu'un nombre limité de fonctions cryptographiques soit intégré au sein de la boite blanche (idéalement une seule fonction est intégrée au sein d'un boite blanche), il n'en reste pas moins que l'attaquant peut, dans certains cas obtenir des données intermédiaires, c'est-à-dire des données qui constituent la sortie d'une première boite blanche et l'entrée d'une seconde. De cette façon, l'attaquant peut implémenter toute ou partie d'une chaîne de sécurisation, à son propre compte, en modifiant les données intermédiaires, sans qu'il soit nécessaire d'inspecter les fonctionnements des boites blanches.
3. Résumé de l'invention
L'invention ne pose pas les problèmes précédemment identifiés. Plus particulièrement, l'invention permet d'éviter d'une part par les pratiques de code lifting et d'autre part par l'exposition de données intermédiaires.
Procédé cryptographique de traitement de données pour la mise en oeuvre d'une fonction cryptographique, procédé mis en oeuvre au sein d'un dispositif électronique de traitement de données comprenant un processeur, un mémoire et une clique de modules de traitement cryptographique, ledit procédé comprenant, les étapes suivantes, mises en oeuvre par un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaîne d'au moins deux modules de traitement cryptographique exécutés pour la mise en oeuvre de ladite fonction cryptographique : réception de données entrantes ; détermination d'une clé de déchiffrement à appliquer sur lesdites données entrantes ; déchiffrement, à l'aide de la clé des données entrantes, délivrant des données entrantes non chiffrées ; mise en oeuvre d'au moins une opération cryptographique sur lesdites données entrantes non chiffrées, délivrant des données sortantes non chiffrées ; optionnellement détermination d'un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ; obtention d'une clé de chiffrement desdites données sortantes non chiffrées ; chiffrement desdites données sortantes non chiffrées à l'aide de la clé de chiffrement desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées, qui peuvent être des données intermédiaires.
Ainsi, l'invention permet d'éviter que les données intermédiaires qui transitent entre deux modules de traitement cryptographique ne puissent être interceptées et utilisées par un attaquant.
Selon une caractéristique particulière, l'étape de déchiffrement qui, à l'aide de la clé des données entrantes, délivre des données entrantes non chiffrées comprend une étape de combinaison des données entrantes avec au moins une table d'une série de tables intégrée au sein dudit module de traitement cryptographique.
Selon une caractéristique particulière, l'étape détermination d'une clé de déchiffrement à appliquer sur lesdites données entrantes comprend une étape de dérivation de ladite de déchiffrement à partir d'une clé maître, ladite étape de dérivation tenant compte d'une position dudit module de traitement cryptographique courant au sein de la chaîne de modules de traitement cryptographique.
Ainsi, il n'est pas aisé, pour un attaquant, même connaissant une clé maître, de déterminer quelle sera le prochain module de traitement cryptographique utilisé au sein de la chaîne. Car en effet, cette information dépend directement des données (entrantes/sortantes) elles-mêmes, qui sont chiffrées.
Selon une caractéristique particulière, l'étape de détermination d'un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées comprend :
Une étape d'identification, au sein desdites données entrantes non chiffrées, d'une structure de données de routage ;
Une étape de détermination, à partir de ladite structure de données de routage, d'une localisation courante ;
Une étape de détermination, à partir de ladite localisation courante, d'une localisation suivante ;
Une étape d'obtention d'un identifiant du module de traitement cryptographique suivant associé à ladite localisation suivante.
Ainsi, le chaînage des modules de traitement cryptographique dépend des données qui sont elles-mêmes chiffrées et le module est à même de déterminer, potentiellement seul, quel est le prochain module à exécuter dans le chaînage en fonction de ces données. On dispose donc d'un routage dynamique plus complexe à analyser pour un attaquant.
Selon une caractéristique particulière, l'étape d'obtention d'une clé de chiffrement desdites données sortantes non chiffrées comprend une étape de dérivation de ladite de chiffrement à partir d'une clé maître, ladite étape de dérivation tenant compte d'une position dudit module de traitement cryptographique suivant au sein de la chaîne de modules de traitement cryptographique.
Ainsi, il n'est pas aisé, pour un attaquant, même connaissant une clé maître, de déterminer quelle sera le prochain module de traitement cryptographique utilisé au sein de la chaîne. Car en effet, cette information dépend directement des données (entrantes/sortantes) elles-mêmes, qui sont chiffrées.
Selon une caractéristique particulière, l'étape d'obtention d'une clé de chiffrement desdites données sortantes non chiffrées comprend une étape d'obtention de ladite clé de chiffrement à partir de l'identifiant du module de traitement cryptographique suivant.
Ainsi, le module courant peut utiliser l'identifiant du module suivent pour sélectionner une clé dont il sait à priori qu'elle convient au module suivant.
Selon une caractéristique particulière, ledit procédé comprend en outre une étape de transmission des données sortantes chiffrées à un module de traitement cryptographique suivant de ladite chaîne d'au moins deux modules de traitement cryptographique en fonction d'au moins une donnée de routage présente au sein des données entrantes et/ou des données entrantes non chiffrées.
Ainsi, le module courant ne se repose pas sur l'actionnement d'un mécanisme de retour à un appelant des données qu'il vient de traiter, mais au contraire est en mesure de fournir directement les données intermédiaires à un module suivant pour que ces dernières soient directement traitées. On augmente ainsi la sécurité de l'ensemble.
Selon une caractéristique particulière, l'étape de mise en oeuvre d'au moins une opération cryptographique sur lesdites données entrantes non chiffrées, délivrant des données sortantes non chiffrées consiste en l'application d'une primitive cryptographique.
Ainsi, l'exécution d'une telle primitive est mise en oeuvre de manière sécurisée.
Selon un exemple de réalisation particulier, l'invention se présente sous la forme d'un dispositif cryptographique de traitement de données pour la mise en oeuvre d'une fonction cryptographique. Un tel dispositif électronique de traitement de données comprend un processeur, un mémoire et une clique de modules de traitement cryptographique. Le dispositif comprend met en oeuvre un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaîne d'au moins deux modules de traitement cryptographique exécutés pour la mise en oeuvre de ladite fonction cryptographique, ledit module de traitement cryptographique courant comprenant :
Des moyens de réception de données entrantes ;
Des moyens de détermination d'une clé de déchiffrement à appliquer sur lesdites données entrantes ;
Des moyens de déchiffrement, à l'aide de la clé des données entrantes, délivrant des données entrantes non chiffrées ;
Des moyens de mise en oeuvre d'au moins une opération cryptographique sur lesdites données entrantes non chiffrées, délivrant des données sortantes non chiffrées ;
Des moyens optionnels de détermination d'un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ;
Des moyens d'obtention d'une clé de chiffrement desdites données sortantes non chiffrées ;
Des moyens de chiffrement desdites données sortantes non chiffrées à l'aide de la clé de chiffrement desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées, qui peuvent être des données intermédiaires.
Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif d'exécution selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en oeuvre au niveau du terminal de communication, du dispositif électronique d'exécution et/ou du dispositif de contrôle, dans le cadre d'une répartition des traitements à effectuer et déterminés par un codes source scripté.
En conséquence, l'invention vise aussi des programmes, susceptibles d'être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus. Un programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Selon un exemple de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels.
Les différents exemples de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de l'invention.
4. Dessins
D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
[fig 1] la figure 1 décrit un système dans lequel l'invention peut être mise en oeuvre ;
[fig 2] la figure 2 décrit le principe général de la méthode objet de l'invention ;
[fig 3] la figure 3 illustre un autre exemple de la méthode objet de l'invention ;
[fig 4] la figure 4 décrit les différentes étapes d'un exemple de réalisation du procédé de l'invention ;
[fig 5] la figure 5 illustre une architecture d'un dispositif appelant apte à mettre en oeuvre un procédé de traitement de l'invention ;
5. Description détaillée
5.1. Rappel du principe
Comme explicité précédemment, le principe général de l'invention consiste à munir des modules d'exécution de primitives cryptographiques chacun d'une couche additionnelle de chiffrement à l'entrée et à la sortie du module d'exécution, dans le cadre d'un enchaînement d'appels de modules « unitaires » pour remplir une ou plusieurs (sous)fonctions cryptographiques prédéterminées par l'application appelante, à l'aide d'un mécanisme de chaînage dont certains exemples de réalisation, selon l'invention, sont décrits par la suite. Un exemple typique de mise en oeuvre de la technique décrite en relation avec la figure 1 est réalisée dans un système comprenant un programme informatique appelant (AppA) (comme une application fonctionnant sur un système d'exploitation (OS) de type Windows™, MacOS™, Linux™ encore Android™), lui-même fonctionnant sur un dispositif physique (DPy). Un dispositif électronique (DPy) comprend un processeur (P), une mémoire (M), et des moyens de transmission de données (TRD). Ces moyens de transmission de données (TRD) peuvent se présenter sous plusieurs formes, comme cela est explicité par la suite. Il peut également comprendre, en fonction des modes de réalisation, des composants (optionnels) matériels et/ou logiciels d'affichage (Disp), de saisie (KBD) et ou d'impression (IMP).
L'application peut par exemple être un lecteur de musique/de vidéo, ou encore une application de paiement ou encore une application gérant l'accès à des données sensibles enregistrées sur le dispositif électronique, une application d'identification ou d'authentification, etc. Ce programme informatique (AppA) a un besoin, au cours de son exécution, de mettre en oeuvre une ou plusieurs fonctions cryptographiques (Fl, F2, F3, etc). Généralement, ces fonctions ne sont pas directement intégrées dans le programme informatique. A la place, il appelle des fonctions qui sont disponibles au sein d'une bibliothèque (LIB1, LIB2,...) (.lib, .dll, etc. en fonction du système d'exploitation). Cette bibliothèque est chargée par le programme appelant (AppA), qui se charge d'appeler la fonction cryptographique ou la primitive cryptographique requise en boite blanche (Fl, F2, F3, etc.), soit directement soit en passant par l'intermédiaire du système d'exploitation (OS). En règle générale, cette fonction cryptographique ou cette primitive cryptographique est appelée telle qu'elle et lorsque deux fonctions cryptographiques ou deux primitives cryptographiques (chacune en boite blanche) sont appelées l'une après l'autre, les données intermédiaires Dlnt (i.e. sorties de la première boite blanche et fournies à la deuxième boite blanche) transitent en clair, comme explicité précédemment. La technique proposée permet de résoudre à la fois la problématique de transition en clair des données intermédiaire tout en limitant les possibilités de code lifting, en divisant les fonctions rendues par une boite blanche, en chiffrant (masquant) les entrées/sorties des modules et en routant dynamiquement l'exécution des différents modules entre eux, comme explicité en figure2. Afin d'être complet, dans le cadre de la présente, on rappelle les définitions suivantes :
Une primitive cryptographique est un algorithme cryptographique de bas niveau, sur la base duquel est notamment bâti un système de sécurité. Un algorithme cryptographique peut se rapporter à une fonction de hachage cryptographique (par exemple SHA-1, SHA3, etc.) ou encore une fonction de chiffrement (par exemple AES, DES) ;
Une primitive cryptographique utilise des opérations cryptographiques (permutation, rotations, transformations linéaires, opérations algébriques sur les entiers ou binaires, additions, multiplication, XOR, etc.) ; Une fonction cryptographique comprend la mise en oeuvre d'une ou de plusieurs primitives cryptographiques, selon un chaînage (routage) défini par l'auteur de la fonction cryptographique, en fonction de la destination de la fonction cryptographique (i.e. à quoi cette fonction sert-elle, est- elle destinée dans le cadre d'une architecture de sécurisation).
Ainsi, en figure 2, il est décrit un mécanisme dans lequel une primitive cryptographique (Pci) et une primitive cryptographique (Pc2) sont utilisées pour mettre en oeuvre une fonction cryptographique (Fl), par l'Application appelante (AppA), dans le cadre du système de la figure 1. Selon la technique proposée, les primitives cryptographiques sont chacune implémentées dans un module dédié (Ml, M2). L'application AppA fournit des données d'entrée (Din) au module Ml, puis obtient des données intermédiaire (Dlnt), lesquelles sont transmises, en tant que données d'entrée, au module M2, qui ensuite utilise les données intermédiaires pour produire les données de sorties (DOut). Selon l'invention, le module Ml comprend un étage de sortie Cl, lequel effectue un chiffrement des données intermédiaires (Dlnt) avant la communication de celles-ci à l'application AppA. Selon l'invention, le module M2 comprend un étage d'entrée D2, lequel effectue un déchiffrement des données intermédiaires (Dlnt) avant l'utilisation de celles-ci dans le cadre de la primitive PC2.
La technique proposée permet de résoudre d'une part un problème de divulgation de données intermédiaires lorsque des données sont échangées entre des modules et que ces données quittent temporairement l'environnement sécurisé fourni par le module : elles pourraient être interceptées par un attaquant à ce moment précis. Les « données intermédiaires » pourraient être accessibles à un attaquant lorsqu'elles transitent en dehors de l'environnement du module. De plus, comme explicité précédemment, un attaquant peut sortir un module de son contexte et l'utiliser (par exemple comme primitive de déchiffrement autonome) ailleurs.
L'invention permet de répondre à la contradiction générée par le principe même de « boite blanche » et de « code lifting », selon un nouvel axe de mise en oeuvre : pour augmenter l'efficacité d'une boite blanche, il faut théoriquement regrouper les fonctions cryptographiques au sein d'une seule boite blanche. Pour limiter les risques dus au « code lifting », au contraire il faut dissocier au maximum les primitives cryptographiques.
Ainsi, bien qu'en principe il serait possible de regrouper plus d'une primitive cryptographique dans une seule boîte blanche, au lieu de considérer plusieurs boîtes blanches différentes, en pratique, cela n'est, selon les inventeurs, ni faisable ni souhaitable. En effet, le processus de mise en boîte blanche d'un programme augmente sa taille de façon très importante (du fait de la transformation de fonctions en tables), et le regroupement de plusieurs primitives cryptographiques au sein d'une seule boite blanche, outre le fait qu'il pose un problème de sécurité, entraîne une augmentation rapide des bases de code, qui sont dès lors difficiles à gérer. Il peut également arriver que plusieurs technologies de boîte blanche différentes et incompatibles (car provenant d'éditeurs différents par exemple) soient utilisées dans un seul programme ou une même application, auquel cas elles ne peuvent pas être regroupées.
Ainsi, on propose un procédé pour augmenter la sécurité, notamment des implémentations en boites blanches, en sécurisant les données en transit (données intermédiaires) entre les modules, tout en garantissant un flux d'exécution correct (protégeant ainsi par exemple contre les attaques par « code-lifting »). D'une manière générale, ans le cadre de la présente, on considère qu'un module est implémenté sous la forme d'une librairie (logicielle) ou un composant dédié (matériel) et que ce module met en oeuvre, au plus, une primitive cryptographique (et possiblement seulement une portion de primitive cryptographique).
Selon l'invention, au sein d'une application comprenant au moins deux modules en boites blanches, implémentant chacun une partie seulement d'une fonction cryptographique globale de protection de données, le module courant est muni d'une fonctionnalité de « masquage » des données avec le module suivant. Par exemple, lorsque deux modules implémentent une partie de fonctionnalité, qui nécessite la transmission de données intermédiaires entre les deux modules, alors les données intermédiaires sont masquées (i.e. chiffrées par exemple), de sorte que la prise de connaissance de ces données intermédiaires ne permette pas de disposer d'information correctement utilisable. Dans un exemple de réalisation particulier, le masquage consiste en l'application d'un chiffrement des données intermédiaires avant leur transmission au module suivant, de sorte que ces données intermédiaires soient idéalement inaccessibles et à tout le moins inutilisables, même pour l'application appelante.
Un autre exemple comprenant quatre modules (X, Y, Z, T) est décrit en relation avec la figure 3. La solution technique proposée dans la présente invention consiste à utiliser des paires de codages correspondants entre des modules. Concrètement, cela signifie que dans le module X, on ajoute une capacité de chiffrement (simple) (pour une clé KX2) et une capacité de déchiffrement (pour une clé KX2). La même chose est réalisée pour les modules Y, Z et T. Les données intermédiaires DintO et Dintl sont chiffrées (et/ou masquées). Le mécanisme de routage peut être soit interne aux modules, effectués en fonction d'une variable d'entrée ou encore d'un champ d'entête des données d'entrées (Din) et des données intermédiaires (DintO et Dintl). Alternativement, le mécanisme de routage peut être mis en oeuvre par l'application appelante ou bien par un module de routage spécifique.
Cela garantit que : les données transmises entre les modules sont toujours chiffrées, et donc non aisément accessibles, non seulement pour un attaquant, mais également pour l'application appelante elle- même ; le flux de données intermédiaires ne peut pas être modifié (par exemple par « code-lifting ») sinon l'étape de déchiffrement des données intermédiaires ne fournira pas un résultat exploitable (lors de l'entrée dans la boite blanche suivante) ; la mise en oeuvre d'un « code lifting » sur l'intégralité de la chaîne de modules ne peut pas être réalisée facilement, du fait de la dispersion de la logique d'appel, celle-ci étant en effet répartie entre plusieurs « acteurs » différents, dont les « modules » eux-mêmes, qui peuvent transmettre l'information à un appelant différent.
En d'autres termes, selon l'invention, en sus d'une protection des données intermédiaires, l'invention permet également de protéger la logique d'exécution des primitives cryptographiques d'une part et des fonctions cryptographiques d'autre part. Un ou plusieurs modules de la pluralité (de la clique) des modules peuvent en outre mettre en oeuvre des mécanismes d'appels différenciés et de routage des données intermédiaires en fonction des besoins. Potentiellement, tous les modules de la clique de modules peuvent en oeuvre des mécanismes de routage.
Les étapes mises en oeuvre au sein d'un module sont alors les suivantes, présentées en relation avec la figure 4 : réception (10) de données entrantes (D_A) ; détermination (20) d'une clé de déchiffrement (KJ) à appliquer sur lesdites données entrantes (D_A) ; déchiffrement (30), à l'aide de la clé (Kl) des données entrantes (D_A), délivrant des données entrantes non chiffrées (Dl_nc) ; mise en oeuvre (40) d'au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc) ; optionnellement détermination (45) d'un module suivant à exécuter sur lesdites données sortantes non chiffrées (en fonction du mécanisme de routage utilisé) ; obtention (50) d'une clé de chiffrement (K_0) desdites données sortantes non chiffrées (DO_nc) (optionnellement en fonction du module suivant lorsqu'un mécanisme de routage interne est utilisé et qu'une détermination conditionnelle de clé est mises en oeuvre) ; chiffrement (60) desdites données sortantes non chiffrées (DO_nc) à l'aide de la clé de chiffrement (K_0) desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées (D_B), qui peuvent être des données intermédiaires.
Selon l'invention, les étapes de déchiffrement 30 et de chiffrement 60 sont mutuellement optionnelles : en fonction de la position du module dans la chaîne de modules, il est possible que l'une ou l'autre de ces étapes (et leurs étapes dépendantes d'obtention de clés) ne soient pas mises en oeuvre. Cependant, au moins l'une des deux (chiffrement ou déchiffrement) est nécessairement mise en oeuvre. Plus spécifiquement : si le module est le premier module de la chaîne, le déchiffrement des données d'entrée n'est pas nécessaire ; si le module est le dernier module de la chaîne (délivrant des données de sortie finales, i.e. qui ne sont pas intermédiaires), l'étape de chiffrement de ces données de sortie est optionnelle.
Ainsi, selon l'invention, d'une part il est possible de totalement masquer les données qui transitent entre les modules en effectuant un chiffrement de celles-ci, et d'autre part il est possible de déterminer, au sien d'un module courant, quel est le module suivant auquel les données sortantes doivent être transmises et d'utiliser une clé appropriée pour effectuer le chiffrement de ces données avant transmission. Le corollaire d'une telle implémentation selon l'invention est que la mise en oeuvre d'une primitive cryptographique ou d'une fonction cryptographique (comprenant plusieurs primitives cryptographiques) est plus ou moins significativement allongé.
Par ailleurs, la détermination d'une clé de déchiffrement (KJ) et d'une clé de chiffrement (K_0) est mise en oeuvre en fonction des conditions opérationnelles (notamment du besoin de réaliser une telle opération de chiffrement ou de déchiffrement) et est exécutée selon une méthodologie de détermination telles que celles présentées ci-après, par exemple en fonction d'une clé de base, initiale, appelée clé maître, dont la forme varie en fonction des réalisations.
Selon l'invention, dans un exemple de réalisation, le routage entre les modules est effectué en utilisant un champ spécifique des données entrantes. Plus particulièrement, deux possibilités sont concrètement mises en oeuvre : la première consiste à utiliser un entête des données entrantes, cet entête n'étant pas chiffré de manière identique aux données entrantes. L'entête est chiffré ou masqué selon un processus différent dans chaque module, mais quel que soit le processus utilisé, chaque module est en mesure de décoder ou de déchiffrer cet entête.
L'avantage ici est de permettre l'obtention d'une clé de déchiffrement des données entrantes chiffrées en fonction de la valeur de l'entête. L'entête possède alors deux fonctions distinctes et complémentaires : une fonction de détermination de clé de chiffrement, qui permet de disposer de cette clé de manière dynamique et une fonction de routage qui permet de chiffrer les données sortantes avec une clé, également obtenue dynamiquement, et de déterminer le module suivant dans la chaîne de traitement des données.
La deuxième consiste à cacher ce champ dans les données entrantes chiffrées elles-mêmes, à un endroit connu du module courant et du module précédent. La valeur de ce champ n'est pas connue avant que les données soient déchiffrées par le module courant.
L'avantage ici est de ne pas avoir à gérer l'obtention de clés de chiffrement « variables ». Plus particulièrement, le module connaît la clé de déchiffrement à utiliser pour déchiffrer les données entrantes. Il n'est donc pas nécessaire de déterminer cette clé en fonction de la valeur de l'entête, et il est ainsi possible de réduire la taille du binaire du module (et le temps d'exécution). Une fois les données entrantes déchiffrées, la valeur du champ spécifique est connue. La fonction de routage est alors mise en oeuvre, après application de la fonction cryptographique du module, de la même manière que précédemment (i.e. la valeur du champ qui permet de chiffrer les données sortantes avec une clé de chiffrement, obtenue dynamiquement, et de déterminer le module suivant dans la chaîne de traitement des données.
Quelle que soit la manière dont ce champ est utilisé, il permet de transférer les fonctions de routage d'appel des différents modules aux modules eux-mêmes. Dès lors, chaque module est en mesure, potentiellement d'appeler chaque autre module de la clique de modules. C'est une manière astucieuse de procéder au masquage des appels et des données, et ce pour plusieurs raisons.
En effet, dans l'implémentation traditionnelle en boite blanche, l'intégralité des fonctions cryptographiques est mise en oeuvre au sien de la boite blanche, selon un processus connu et ouvert, ouvrant les possibilités de code lifting. Lorsque la boite blanche met en oeuvre plusieurs fonctionnalités de chiffrement et/ou de déchiffrement connues, celles-ci sont câblées, sous une forme ou sous une autre, dans la boite blanche.
L'approche est ici singulièrement différente puisque le flot d'exécution n'est pas connu en avance. C'est la valeur du champ de routage qui permet d'exécuter des primitives cryptographiques ou des opérations cryptographiques portées par des modules dont l'enchaînement n'est pas connu au sein même des modules. Un module courant, à un instant « t » n'est informé que du minimum requis à savoir la clé de déchiffrement des données entrantes, le module suivant à appeler et la clé de chiffrement des données sortantes correspondant à ce module suivant à appeler. Ainsi, par exemple, si le module courant met uniquement en oeuvre une opération cryptographique de type « XOR », le module courant :
Déchiffre les données entrantes fournies ;
Applique l'opération XOR sur ces données entrantes fournies, délivrant les données sortantes ;
Détermine, à partir de la valeur du champ de routage, la clé de chiffrement à appliquer ;
Chiffre les données sortantes ;
Identifie, à partir de la valeur du champ de routage, le module suivant ;
Transmet les données sortantes chiffrées au module suivant.
Ce qui vient d'être décrit pour l'opération XOR est bien évidemment valable pour toute autre opérations cryptographiques, qu'elles soient appliquées sur des chaînes de bits, des chaînes d'octets ou des entiers (permutations fixes ou variables, masquages, décalages, rotation, additions, etc.)
Un avantage d'une telle mise en oeuvre est de permettre potentiellement l'appel d'un même module de la clique de modules à plusieurs reprises pour la mise en oeuvre d'une primitive cryptographique (plusieurs opérations de masquage, de décalage, etc.) ou d'une fonction cryptographique (plusieurs appels d'une même primitive).
Bien que décrit en relation avec la mise en oeuvre d'une seule opération cryptographique, il est évident que chaque module peut, en fonction des conditions de mise en oeuvre opérationnelles, mettre en oeuvre plusieurs opérations cryptographiques (par exemple, mais pas uniquement, lorsque des opérations cryptographiques sont fréquemment liées entre elles, ou bien lorsque de tels groupements se justifient). Avantageusement, les clés d'entrée et de sortie sont dynamiquement obtenues : l'objectif est d'éviter qu'une clé soit intégrée à demeure dans un module, ce module pouvant ensuite être utilisé comme bon lui semble par un potentiel attaquant. Cependant, cette manière de faire n'est pas obligatoire, car on rappelle que les modules sont mis en oeuvre de manière séquentiels ou itérative de manière à produire une fonction cryptographique complète, laquelle pouvant comprendre l'obtention d'une ou de plusieurs clés de chiffrement, également de manière dynamique.
Les opérations de chiffrement des soties et de déchiffrement des entrées, mises en oeuvre dans les différents modules, lors de l'exécution de ceux-ci sont idéalement simples et rapides, afin de ne pas d'une part surcharger les modules de code « non nécessaire » à la mise en oeuvre effective de la primitive cryptographique ou de l'opération cryptographique. L'objectif est de faire en sorte d'augmenter la sécurité des données entrantes et sortantes sans trop augmenter la taille du code d'une part et sans trop augmenter le temps nécessaire à la mise en oeuvre de la fonction cryptographique. Il est donc nécessaire d'effectuer une balance entre l'intérêt d'une protection et la rapidité d'exécution. Ainsi, par exemple, le chiffrement/déchiffrement peut comprendre uniquement quelques opérations cryptographiques (deux à six par exemple), mises en oeuvre sur une chaîne de bits ou sur une chaîne d'octets ou un entier, ces opérations cryptographiques étant symétriques : les opérations de déchiffrement sont les inverses des opérations de chiffrement et vice versa, pour deux modules routés l'un avec l'autre. Les clés de chiffrement, dans ce cas, consistent en l'enchaînement (en une suite), plus ou moins longues d'opérations unitaires de chiffrement.
Par exemple, à titre purement illustratif, si le chiffrement des données de sortie comprend, dans un module X, une permutation (opération SI), suivi d'une addition (opération S2), suivi d'une nouvelle permutation (opération S3) , alors le déchiffrement des données d'entrées correspondant à ces données de sortie, dans le module Y, qui est le suivant dans le routage, comprend : une permutation ( opération El, inverse de l'opération S3), une soustraction (opération E2, inverse de l'opération S2), et une nouvelle permutation (Opération E3, inverse de l'opération SI). La clé de chiffrement, ici, est formée du triplet {SI ;S2 ;S3} et la clé de déchiffrement est formée du triplet {El ;E2 ;E3}. Dans ce cas, les clés de chiffrements et de déchiffrement correspondent à des séquences (suites) secrètes d'opérations unitaires de chiffrement. La complexité des opérations de chiffrement des données de sortie et de chiffrement des données d'entrée dépend essentiellement du nombre d'opérations cryptographiques utiles mises en oeuvre au sein du module. Par exemple, lorsque le module ne comprend qu'une ou deux opérations cryptographiques utiles (une opération cryptographique utile est une opération cryptographique du module qui sert à traiter les données pour la mise en oeuvre de la primitive cryptographique), les opérations de chiffrement ou de déchiffrement inclues dans ce module sont généralement plus simples et rapide. A l'inverse, si le module implémente l'intégralité d'une primitive cryptographique, telle qu'AES ou 3DES (et donc comprend de très nombreuses opérations cryptographiques utiles), alors les opérations de chiffrement ou de déchiffrement inclues dans ce module peuvent être plus complexes et plus lourdes et comprendre une implémentation complète à base de clé plus longues et plus complexes.
En fonction des exemples de réalisation, on note que le premier module d'une chaîne n'a pas nécessairement besoin de chiffrement et le dernier module d'une chaîne n'a pas besoin d'un déchiffrement. (Il est possible de crypter (resp. Décrypter) pour ces étapes, mais cela n'offre pas nécessairement de protection supplémentaire).
Les clés correspondantes, utilisées dans les opérations de déchiffrement des données d'entrée et de chiffrement des données de sortie peuvent être choisies manuellement ou automatiquement ; une façon d'obtenir ces clés est d'utiliser une fonction de dérivation de clé (telle que HKDF) à partir d'une clé maître. Dans une mise en oeuvre de l'invention où une séquence linéaire de modules numérotés [0, 1, 2, 3, ..., n], la clé de chiffrement pour le module i (qui est la clé de déchiffrement du module i + 1) peut être dérivée comme HKDF (graine, i), la graine étant par exemple la clé utilisée pour le module précédent (i-1), une clé maître indépendante, un paramètre initial, etc. L'avantage de cette mise en oeuvre à partir d'une clé maître dérivable est qu'elle est plus simple et plus efficace qu'une sélection arbitraire de clés pour chaque module. De plus, l'avantage est également que la clé maître, initiale, peut varier à chaque appel de la clique de modules. D'autres implémentations sont possibles, comme par exemple dans le cas des suites d'opérations unitaires présentées précédemment, une dérivation de la suite suivante en fonction de la suite précédente et de l'identifiant du module.
Il est également possible, de manière complémentaire ou indépendante des implémentations précédentes, d'utiliser plusieurs clés de chiffrement / déchiffrement par module. Dans ce cas, une variable d'entrée indique la clé à considérer. Une telle mise en oeuvre permet d'effectuer un routage intelligent, en assurant que dans une première situation donnée, un premier chiffrement (resp. déchiffrement) est utilisé tandis que dans une deuxième situation donnée, un deuxième chiffrement (resp. déchiffrement) est utilisé.
Il est également possible d'envisager plusieurs clés de chiffrement différentes, une par module, sans spécifiquement disposer de lien entre la manière dont les clés de chiffrement sont choisies pour chaque module.
Dans un exemple de réalisation particulier, lorsqu'un module intègre l'intégralité d'une primitive cryptographique), la procédure de chiffrement des données de sortie (resp. Déchiffrement des données d'entrée) met en oeuvre toute ou partie de la primitive cryptographique elle-même, lorsque cela est possible. En d'autres termes, comme, selon l'invention, l'objectif d'un module est de cacher la clé (et non pas l'implémentation de l'algorithme de chiffrement en lui- même), on utilise cette implémentation, avec une clé différente, pour chiffrer les données de sortie (resp. déchiffrer les données d'entrée). De cette manière, le surcroît de volume de code est relativement limité.
Comme indiqué précédemment, l'ajout de code supplémentaire pour le chiffrement/déchiffrement entraîne une augmentation de la taille des modules (par rapport à une implémentation standard). Cependant, cet ajout de code compensé, selon l'invention, par un gain de flexibilité et de modularité fourni par la capacité de décomposer en toute sécurité des opérations cryptographiques ou des primitives cryptographiques en utilisant la technique décrite. En outre, il est possible de tirer parti de schémas cryptographiques légers (par exemple Trivium, Simon, etc.) dont la taille de code est très petite et efficace en termes de calcul, pour compenser la surcharge de code due à la mise en oeuvre de la technique proposée.
Dans un exemple de réalisation particulier de l'invention, les logiques d'appels et de routage des données entre modules peuvent, comme exposé précédemment, être mise en oeuvre par les modules eux-mêmes, qui au fur et à mesure de l'exécution des tâches qui leurs sont confiées, appliquent sur les données reçues et traitées par elles, un routage des données. Il est également possible, dans un autre exemple de réalisation, de disposer d'un module spécifique (appelé module de routage), qui se charge, à l'aide de mécanismes de chiffrement particulier, de mettre en oeuvre ce routage. Il s'agit dans ce cas d'un module passerelle, qui est un intermédiaire entre l'application appelante et les modules remplissant les fonctions cryptographiques.
5.2. Autres caractéristiques et avantages On présente, en relation avec la figure 5, une architecture simplifiée d'un dispositif électronique d'exécution apte à effectuer le traitement et l'exécution de code selon le procédé décrit précédemment. Un dispositif électronique d'exécution comprend une mémoire 51 (et/ou éventuellement sécurisée et/ou deux mémoires séparées, une sécurisée et l'autre non), une unité de traitement 52 équipée par exemple d'un microprocesseur (et/ou éventuellement sécurisé et/ou deux processeurs séparés, un sécurisé et l'autre non), et pilotée par le programme d'ordinateur 53, mettant en oeuvre le procédé tel que précédemment décrit. Dans au moins un exemple de réalisation, l'invention est mise en oeuvre au moins partiellement sous la forme d'une application AppA installée sur ce dispositif. On dispose ainsi d'un dispositif cryptographique de traitement de données pour la mise en oeuvre de fonctions cryptographiques, qui comprend un processeur (52), un mémoire (51) et une clique de modules de traitement cryptographique (53), mise en oeuvre dans un programme. Le dispositif met en oeuvre un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaîne d'au moins deux modules de traitement cryptographique exécutés pour la mise en oeuvre de ladite fonction cryptographique, ledit module de traitement cryptographique courant comprenant :
Des moyens de réception de données entrantes ;
Des moyens de détermination d'une clé de déchiffrement à appliquer sur lesdites données entrantes ;
Des moyens de déchiffrement, à l'aide de la clé des données entrantes, délivrant des données entrantes non chiffrées ;
Des moyens de mise en oeuvre d'au moins une opération cryptographique sur lesdites données entrantes non chiffrées, délivrant des données sortantes non chiffrées ;
Des moyens optionnels de détermination d'un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ;
Des moyens d'obtention d'une clé de chiffrement desdites données sortantes non chiffrées ;
Des moyens de chiffrement desdites données sortantes non chiffrées à l'aide de la clé de chiffrement desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées, qui peuvent être des données intermédiaires. Pour l'exécution des fonctions qui lui sont confiés, le dispositif comprend également les moyens de mise en oeuvre de l'ensemble des étapes précédemment mentionnées, soit sous une forme matérielle, lorsque des composants spécifiques sont dédiés à ces tâches, soit sous une forme logicielle en lien avec un ou plusieurs microprogrammes s'exécutant sur un ou plusieurs processeurs du dispositif d'exécution.

Claims

REVENDICATIONS
1. Procédé cryptographique de traitement de données pour la mise en oeuvre d'une fonction cryptographique, procédé mis en oeuvre au sein d'un dispositif électronique de traitement de données comprenant un processeur, un mémoire et une clique de modules de traitement cryptographique, ledit procédé comprenant, les étapes suivantes, mises en oeuvre par un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaîne d'au moins deux modules de traitement cryptographique exécutés pour la mise en oeuvre de ladite fonction cryptographique : réception (10) de données entrantes (D_A) ; détermination (20) d'une clé de déchiffrement (KJ) à appliquer sur lesdites données entrantes (D_A) en fonction d'une clé maître et d'une position du module de traitement cryptographique courant ; déchiffrement (30), à l'aide de la clé (KJ) des données entrantes (D_A), délivrant des données entrantes non chiffrées (Dl_nc) ; mise en oeuvre (40) d'au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc) ; optionnellement détermination (45) d'un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ; obtention (50) d'une clé de chiffrement (K_0) desdites données sortantes non chiffrées (DO_nc) ; chiffrement (60) desdites données sortantes non chiffrées (DO_nc) à l'aide de la clé de chiffrement (K_0) desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées (D_B), qui peuvent être des données intermédiaires.
2. Procédé selon la revendication 1, caractérisé en ce que l'étape de déchiffrement (30), à l'aide de la clé (KJ) des données entrantes (D_A), délivrant des données entrantes non chiffrées (Dl_nc) comprend une étape de combinaison des données entrantes avec au moins une table d'une série de tables intégrée au sein dudit module de traitement cryptographique.
3. Procédé selon la revendication 1, caractérisé en ce que l'étape détermination (20) d'une clé de déchiffrement (KJ) à appliquer sur lesdites données entrantes (D_A) comprend une étape de dérivation de ladite de déchiffrement (KJ) à partir de la clé maître, ladite étape de dérivation tenant compte d'une position dudit module de traitement cryptographique courant au sein de la chaîne de modules de traitement cryptographique.
4. Procédé selon la revendication 1, caractérisé en ce que l'étape de détermination (45) d'un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées comprend :
Une étape d'identification, au sein desdites données entrantes non chiffrées (Dl_nc), d'une structure de données de routage ;
Une étape de détermination, à partir de ladite structure de données de routage, d'une localisation courante ;
Une étape de détermination, à partir de ladite localisation courante, d'une localisation suivante ;
Une étape d'obtention d'un identifiant du module de traitement cryptographique suivant associé à ladite localisation suivante.
5. Procédé selon la revendication 1, caractérisé en ce que l'étape d'obtention (50) d'une clé de chiffrement (K_0) desdites données sortantes non chiffrées (DO_nc) comprend une étape de dérivation de ladite de chiffrement (K_0) à partir d'une clé maître, ladite étape de dérivation tenant compte d'une position dudit module de traitement cryptographique suivant au sein de la chaîne de modules de traitement cryptographique.
6. Procédé selon la revendication 4, caractérisé en ce que l'étape d'obtention (50) d'une clé de chiffrement (K_0) desdites données sortantes non chiffrées (DO_nc) comprend une étape d'obtention de ladite clé de chiffrement (K_0) à partir de l'identifiant du module de traitement cryptographique suivant.
7. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape de transmission des données sortantes chiffrées (D_B) à un module de traitement cryptographique suivant de ladite chaîne d'au moins deux modules de traitement cryptographique en fonction d'au moins une donnée de routage présente au sein des données entrantes (D_A) et/ou des données entrantes non chiffrées (Dl_nc).
8. Procédé selon la revendication 1, caractérisé en ce que l'étape de mise en oeuvre (40) d'au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc) consiste en l'application d'une primitive cryptographique.
9. Dispositif cryptographique de traitement de données pour la mise en oeuvre d'une fonction cryptographique, dispositif comprenant un processeur, un mémoire et une clique de modules de traitement cryptographique, ledit dispositif comprenant un module de traitement cryptographique courant de la clique de modules de traitement cryptographique, ledit module de traitement cryptographique courant appartenant à une chaîne d'au moins deux modules de traitement cryptographique exécutés pour la mise en oeuvre de ladite fonction cryptographique, ledit module de traitement cryptographique courant comprenant : des moyens de réception (10) de données entrantes (D_A) ; des moyens de détermination (20) d'une clé de déchiffrement (KJ) à appliquer sur lesdites données entrantes (D_A) en fonction d'une clé maître et d'une position du module de traitement cryptographique courant ; des moyens de déchiffrement (30), à l'aide de la clé (KJ) des données entrantes (D_A), délivrant des données entrantes non chiffrées (Dl_nc) ; des moyens de mise en oeuvre (40) d'au moins une opération cryptographique sur lesdites données entrantes non chiffrées (Di_nc), délivrant des données sortantes non chiffrées (DO_nc) ; des moyens optionnels de détermination (45) d'un module de traitement cryptographique suivant à exécuter sur lesdites données sortantes non chiffrées ; des moyens d'obtention (50) d'une clé de chiffrement (K_0) desdites données sortantes non chiffrées (DO_nc) ; des moyens de chiffrement (60) desdites données sortantes non chiffrées (DO_nc) à l'aide de la clé de chiffrement (K_0) desdites données sortantes précédemment déterminée, délivrant lesdites données sortantes chiffrées (D_B), qui peuvent être des données intermédiaires.
10. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé cryptographique de traitement de données selon la revendication 1, lorsqu'il est exécuté sur un ordinateur
EP21739226.5A 2020-07-15 2021-07-08 Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches Pending EP4183098A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2007425A FR3112643B1 (fr) 2020-07-15 2020-07-15 Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches
PCT/EP2021/069068 WO2022013072A1 (fr) 2020-07-15 2021-07-08 Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches

Publications (1)

Publication Number Publication Date
EP4183098A1 true EP4183098A1 (fr) 2023-05-24

Family

ID=73497872

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21739226.5A Pending EP4183098A1 (fr) 2020-07-15 2021-07-08 Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches

Country Status (5)

Country Link
US (1) US20230275745A1 (fr)
EP (1) EP4183098A1 (fr)
CA (1) CA3183198A1 (fr)
FR (1) FR3112643B1 (fr)
WO (1) WO2022013072A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9639674B2 (en) * 2014-12-18 2017-05-02 Nxp B.V. Using single white-box implementation with multiple external encodings
KR102311340B1 (ko) * 2015-01-15 2021-10-15 한국전자통신연구원 암호화 장치 및 방법

Also Published As

Publication number Publication date
CA3183198A1 (fr) 2022-01-20
FR3112643B1 (fr) 2024-05-03
FR3112643A1 (fr) 2022-01-21
WO2022013072A1 (fr) 2022-01-20
US20230275745A1 (en) 2023-08-31

Similar Documents

Publication Publication Date Title
EP3010175B1 (fr) Rejeu d'un batch de commandes sécurisees dans un canal sécurisé
EP2520041B1 (fr) Procede de generation de table de correspondance pour une boite blanche cryptographique
EP1234284A1 (fr) Procede de securisation de la phase de pre-initialisation d'un systeme embarque a puce electronique, notamment d'une carte a puce, et systeme embarque mettant en oeuvre le procede
FR3011653A1 (fr) Procedes et dispositifs de masquage et demasquage
FR3030831A1 (fr) Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee
EP2166696B1 (fr) Protection de l'intégrité de données chiffrées en utilisant un état intermédiare de chiffrement pour générer une signature
EP1538508A1 (fr) Procédé et dispositif de chiffrement et dechiffrement à la volée
EP2336931B1 (fr) Procédé de vérification de signature
CA2988357C (fr) Procede de chiffrement, procede de chiffrement, dispositifs et programmes correspondants
EP4183098A1 (fr) Dispositif, méthode et programme pour une communication sécurisée entre boîtes blanches
EP3136283B1 (fr) Dispositif et procédé sécurisation de commandes échangées entre un terminal et circuit intégré
EP3547602A1 (fr) Procédé de mise en oeuvre d'une fonction cryptographique pour une clé secrète
EP3799347B1 (fr) Sécurisation du chiffrement des et du déchiffrement des inverse
FR2985337A1 (fr) Procede de calcul cryptographique resilient aux attaques par injection de fautes, produit programme d'ordinateur et composant electronique correspondant.
WO2024083849A1 (fr) Encodage en boite blanche
WO2008152302A2 (fr) Obtention de valeurs dérivées dépendant d'une valeur maîtresse secrète
FR2865086A1 (fr) Dispositif et procede pour convertir un premier message en un deuxieme message
Lin et al. Ransomware Analysis
FR3106909A1 (fr) Circuit intégré configuré pour réaliser des opérations de chiffrement symétrique avec protection de clé secrète
EP4068679A1 (fr) Authentification d'un dispositif par un traitement cryptographique
EP3948596A1 (fr) Procédé d'exécution de code sécurisé, dispositifs, système et programmes correspondants
FR3096851A1 (fr) Procedes de mise en œuvre et d’obfuscation d’un algorithme cryptographique a cle secrete donnee
EP2075733B1 (fr) Dispositif et un procédé de protection contre la rétro conception
EP2544115A1 (fr) Procédé d'exécution d'un traitement dans un dispositif sécurisé
FR3060804A1 (fr) Procede de configuration d'un programme cryptographique destine a etre execute par un terminal

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20221216

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)