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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=73497872

Family Applications (1)

Country Status (5)

Family Cites Families (2)

• 2020
  • 2020-07-15 FR FR2007425A patent/FR3112643B1/fr active Active
• 2021
  • 2021-07-08 EP EP21739226.5A patent/EP4183098A1/de active Pending
  • 2021-07-08 US US18/016,374 patent/US20230275745A1/en active Pending
  • 2021-07-08 WO PCT/EP2021/069068 patent/WO2022013072A1/fr unknown
  • 2021-07-08 CA CA3183198A patent/CA3183198A1/fr active Pending

Also Published As

Similar Documents

Legal Events