EP4695939A1 - Procédé et dispositif de génération d'une fonction de sécurité - Google Patents

Procédé et dispositif de génération d'une fonction de sécurité

Info

Publication number
EP4695939A1
EP4695939A1 EP24718485.6A EP24718485A EP4695939A1 EP 4695939 A1 EP4695939 A1 EP 4695939A1 EP 24718485 A EP24718485 A EP 24718485A EP 4695939 A1 EP4695939 A1 EP 4695939A1
Authority
EP
European Patent Office
Prior art keywords
security
function
service
functions
client device
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
EP24718485.6A
Other languages
German (de)
English (en)
Inventor
Jean-Philippe Wary
Chrystel GABER
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.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP4695939A1 publication Critical patent/EP4695939A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • 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/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/67—Risk-dependent, e.g. selecting a security level depending on risk profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • the present invention relates to the generation of security functions intended to secure a service provided by a service provider and used by a client terminal.
  • the present invention relates to the reinforcement of the security level of an existing or so-called "legacy" device by a specific particularization of the device requiring a specific security level.
  • the present invention relates in particular, according to a first aspect, to the generation of a singularization function and, according to a second aspect, to the deployment of a singularization function.
  • the present invention relates to a method for generating a first security function, implemented in a network comprising a plurality of client devices, said security function being intended to secure a service implemented in at least one of said client devices, the method including,
  • the present invention can advantageously resolve this security incompatibility between the level of security required by a service and the level of service offered by the device that wishes to benefit from the service, by the addition of cryptographic components or scrambling functions specific to each instance or variation made available to a user.
  • the present invention can resolve this incompatibility by a functional singularization of the security services made available to a user's device.
  • the method comprises
  • said first security function is obtained by:
  • the method comprises, prior to the security function request, installing in said client device a service provided by a service provider, said service being associated with said level of security to be ensured, said level of security being higher than a level of security available in said client device.
  • said first security function is obtained by
  • the method comprises:
  • V a second security function
  • the method comprises:
  • the first and second security functions are transmitted to said client device and said service provider, respectively.
  • said client device in the form of a set of information enabling said client device and said service provider to construct said function, said set of information comprising:
  • the security function is obtained by composing several mathematical functions on the inputs and/or outputs of a security function in order to scramble them and create a functional variation of said security function.
  • a family of parameterizable security functions comprises a set of cryptographic functions of varying complexity and of identical structure, a family being able to be chosen from:
  • the invention also relates to a terminal in a communication network, comprising an infrastructure operator, said terminal comprising one or more processors configured together or separately to:
  • the invention also relates to a computer program comprising instructions for executing the steps of the method according to the invention when said program is executed by a computer.
  • the invention also relates to a computer-readable recording medium on which is recorded a computer program comprising instructions for executing the steps of the method according to the invention.
  • steps E1 to E4 are steps which are implemented by the network operator and which can be carried out independently of the following steps, upstream of these, for the establishment of a catalogue or a database of security functions.
  • the network operator can therefore advantageously provide a security service for the service providers and provide access to services requiring a higher level of security than that which they have natively, to client terminals present in its network.
  • the service providers can transmit a subscription request to the service, not shown in FIG. 2, in order to benefit from this security service, also called singularization.
  • a service contract can then be concluded between the service providers 1100, 1200, and the network infrastructure operator 100.
  • a client terminal for example the terminal 1201, wishes to benefit from a service offered by one of the service providers 1100 or 1200. It then installs the service on the terminal, in the form of software code, for example an application code. However, during the installation, the service provider can alert the client terminal 1201 that it does not have the required security level to implement said service. It is also possible, without the intervention of the service provider, that the application cannot be installed because the security level of the terminal 1201 is not sufficient.
  • the service is in fact associated with a security level to be guaranteed in order to be able to operate. For example, the application requests secure storage space on the client terminal in order to operate while the client terminal does not have secure storage functions.
  • the client terminal 1201 therefore transmits a request for a singular security function, this request aiming to install a singular security function or to reinforce an existing security function, in order to guarantee a security level of said service that it wishes to install or that it has installed in order to be able to use it, step E6.
  • This request may include several parameters. It may include in particular an identifier of the client terminal 1201 which makes it possible to associate the singularized security function which will be generated with the terminal which requested it.
  • the identifier may already be included in one of the fields of the exchanged messages (this is the case for example of a MAC address) or may be specifically transmitted.
  • This terminal identifier may allow remote communication with this terminal, this identifier may be, but not limited to, an identifier relating to the terminal's operating system and enabling remote communications via the means of the terminal provider, a communication address on the Internet or on a telecommunications network, an identifier linked for example to a security component and to the operators of the underlying infrastructure such as a SIM card and the IMSI (international mobile subscriber identity) / relative MSISDN (number that uniquely identifies a subscription on a GSM or UMTS mobile network), an identifier within a dedicated instance within another security element such as the TEE (English acronym for "Trusted Execution Environment", specified by the GlobalPlatform consortium).
  • an identifier relating to the terminal's operating system and enabling remote communications via the means of the terminal provider, a communication address on the Internet or on a telecommunications network, an identifier linked for example to a security component and to the operators of the underlying infrastructure such as a SIM card and the IMSI (international mobile
  • the security service may also include the security service to be strengthened, for example, mutual authentication of the Service Provider Application, remote authentication of the application, integrity and proof of origin of exchanges between the application and the service provider, but also parameters specific to the required security service. It may also include the level of security to be guaranteed for the application that the client terminal 1201 wishes to install. This level of security to be guaranteed may be expressed in different forms, for example on a scale of 1 to 10. In certain embodiments, these security levels may correspond to the levels defined in the European CyberSecurity Act Directive which defines the following three levels: Basic, Substantial and Strong. [0056] The functions used to secure are more or less complex, for example permutation functions are more complex than XOR functions. Permutation families are therefore preferred when the required security level is high.
  • the request may also include parameters relating to the functional capability of the client device.
  • the infrastructure operator may request them from it, step E7.
  • the infrastructure operator then generates the singular security function dedicated to the client terminal 1201 for the use of the requested service, step E8.
  • the same singularized security function can therefore be generated for terminals having identical functional capacities and wishing to install the same service.
  • the infrastructure operator could guarantee the uniqueness of this singularized function for the requesting user or terminal, thus leading to implicit authentication of said terminal or user.
  • the generated singularized function could therefore be unique.
  • the singularized security function is obtained from at least one of said configurable security functions recorded, during step E4, from said level of security to be guaranteed and from functional capacity parameters of said client device.
  • the singularized security function can be obtained from an automatic or random generation of functions selected from a family of functions meeting the security requirements of the service and the functional capacity of the client device.
  • the security function may consist of adding security to a function already existing in the client device, to to strengthen, or even raise, the existing level of security so as to guarantee the level of security required by the service to be installed on the customer service for its implementation.
  • the safety function can be obtained by composing several mathematical functions on the inputs and/or outputs of a safety function in order to scramble them and create a functional variation of said safety function.
  • the security function can also be a function that is composed entirely by the singularization service, also from the function catalog, for example when the client device does not already have a security function or does not have a security function whose level can be raised sufficiently to reach the level of security to be guaranteed for the implementation of the service.
  • An encryption-type security function can be singled out from a plurality of bijections.
  • the dedicated security function can be obtained from an automatic or random generation of bijections selected from a family of functions, each of said generated functions then being chained upstream or downstream of the encryption function to be singled out.
  • the automatic generation of a bijection can be based on the one hand on the generation of a cryptographic parameter, such as a key, and on the other hand on the random generation of a configuration parameter, for example a set of byte permutations or hash functions.
  • a security function of the authentication or integrity type can be singled out from the same families of functions as those used for the singled out of symmetric encryption functions, supplemented by families of non-bijective functions, families of one-way functions, each of said generated functions then being chained upstream or downstream of the authentication or integrity function to be singled out.
  • This singled out can be obtained from an automatic or random generation of one-way functions or encryption functions selected from a family of functions.
  • An electronic signature type security function can be obtained from secret key based functions.
  • the singulation service may include a singulation strategy manager and a singulation logic manager.
  • the singularization strategy manager is a module, preferably software, having a set of rules allowing it to define a singularization logic based on a required security level and the functional capabilities of the different client devices present.
  • the singularization logic manager is a module, preferably software, which generates a singularized function from a singularization logic. It constitutes this singularized function by selecting functions in a database of functions, as determined during the preceding step E3.
  • a complete singularization function is made up of N functions selected and configured by the automatic generator from among P families of functions available in the database.
  • the automatic generator of singularized function selects an implementation of a function within a code base organized by family of functions and allows to create a scrambling function from a family of functions and a parameterization of one or more configuration parameters and one or more cryptographic parameters.
  • An example of a family of functions is the family of XOR functions. This family consists of a configuration parameter (the position of the bytes of the incoming data where to apply the XOR) and a cryptographic parameter (the value with which to perform the XOR).
  • a configuration parameter the position of the bytes of the incoming data where to apply the XOR
  • a cryptographic parameter the value with which to perform the XOR
  • a scrambling function that can be generated from this family is the function that performs a multiplication (configuration parameter) of an input x with a value Kl (cryptographic parameter) modulo n (configuration parameter).
  • configuration parameter a multiplication
  • Kl encryption parameter
  • n configuration parameter
  • step E3 two families of functions are determined, namely the XOR and the permutation.
  • the family of permutations is more complex than the family of XOR.
  • Each family has 3 codes corresponding to functions of these families.
  • the XOR family has the following functions:
  • XI- a javacardv3.1 code allowing to make an XOR between the first n bytes of the message (configuration parameter) and a value v (cryptographic parameter)
  • X2- a C code allowing to make an XOR of all the first bytes of the message (configuration parameter) and a value v (cryptographic parameter)
  • X3- a javacardv3.1 code functionally equivalent to the XI code but using a defensive development technique, such as adding instructions to obfuscate power consumption patterns.
  • the permutation family has the following codes:
  • the security level required by the service is high, for example at level 8 on a scale from 0 (lowest level) to 10 (highest level) or at the strong level of the European CyberSecurity Act Directive, and the functional capabilities of the client device that requested the installation of the service (for example a smart card) support javacard 3.1.
  • the strategy manager creates a singularization logic indicating to favor high complexity functions with obfuscation and developed for javacard 3.1.
  • the singularization logic manager performs a catalog search based on the determined logic, and receives a list of functions to use: X3, Pl and XI. From there, the manager chooses in which order to compose them, if he combines them to create a new function and how he parameters them to create the singularized function. He can also check that it is unique for the target. For example, in the case of the X3 function described above, n and v are to be parameterized. For the PI function, it will be necessary to parameterize a.
  • a second singularized security function may be transmitted to the service provider that provides the requested service.
  • the first singularized function and said second singularized function collaborating together to encode, decode or verify the security services instantiated between said client device and said service provider during the implementation of the service.
  • the dual function code is not necessarily transmitted as such to the service provider but to a server of the infrastructure that the service provider can query through an interface.
  • the service provider can ask the server to check the value returned by the singularized function in the client terminal. This advantageously makes it possible to limit the distribution of singularized functions.
  • the infrastructure operator records the singularized security functions associated with the client terminal identifier and the service. It may record the functions as such, for example in the form of software code, or information enabling these functions to be obtained, in the same manner as the information transmitted to the client device and the service provider described above.
  • the activation may use challenge/response mechanisms to activate the service.
  • the service provider may create a given challenge for which it knows the expected response. It transmits this challenge, the singularized function is applied to this challenge message and returns a response that the service provider verifies. If the verification shows that the response is indeed the expected response, then the service is activated.
  • the service can be used by the client device because it meets the security level expected for the implementation of the service by the service provider.
  • Figure 3 represents a first embodiment of an implementation of a service for deploying a security function. It represents the exchanges between the devices of the system.
  • An optional first step may include a request REQ_1 from the client device.
  • This request may include a request from the client device for a singularized security function.
  • This device may wish to implement a service provided by one of the service providers, but does not have the level of security required by the service provider for the implementation of the service.
  • the infrastructure operator may not generate a single security function for a client terminal following a request such as the request REQ_1 but may generate one or more security functions for each or more of the client terminals present in the operator's network, without waiting for a request.
  • the infrastructure operator may advantageously have knowledge of all of the client terminals, and generate the security functions for these terminals connected to the network.
  • the operator may generate these security functions by using a singulation service, responsible for generating the security functions.
  • the singulation service illustrated as being a device or module different from the infrastructure operator, for reasons of clarity, may be integrated into it, as mentioned with reference to FIG. 1.
  • the infrastructure operator may offer a singulation service to all service providers and to all client devices.
  • This service may be implemented on demand, or following the establishment of a contract between the service provider who wishes to use the singulation service.
  • customer terminals which could not benefit from the service because they did not have the level security required by the service, can raise their security level and thus implement the service.
  • This service can also be implemented when purchasing the client device or when manufacturing the client device.
  • the infrastructure operator therefore requests from the singling out service one or more security functions G for each of the client devices, request REQ_2. This can be done, as mentioned previously, following a request from the client device but more generally automatically by the infrastructure operator, for example when said client device is connected to the network.
  • the singling out service can generate a security function as described with reference to FIG. 2.
  • the security function(s) G or the parameters making it possible to create or determine or obtain this security function or this plurality of security functions G are transmitted by the singling out device to the operator in a REP_2 message.
  • the infrastructure operator transmits to the client devices the information relating to this or these first security functions, in a TR_SG1 message.
  • the singling out service records the function(s) G.
  • the singularization service can determine one or more singularized security functions V capable of collaborating with the security function(s) transmitted to the client device.
  • collaborating we mean decoding data generated by the at least one first security function or encoding data intended for the at least one first security function.
  • the singularization service records the function(s) V.
  • the first security function and the second security function collaborate together to encode, decode or verify the security service to be secured between the client device and the service provider when implementing the service.
  • the infrastructure operator transmits to the service provider the singularized security function(s) V enabling it to collaborate with the functions G in the message TR_SG2.
  • the infrastructure operator may transmit an identifier of the client device to which the function G is transmitted.
  • This identifier may be an identifier, different from or identical to, the identifier that the infrastructure operator uses to communicate or identify the client terminal in the network.
  • This identifier may be an identifier generated for the communications implemented between the service provider and the client terminal when implementing the service.
  • This identifier may also be a set of data allowing the user device and the component to be identified, for example an IP address, an application identifier such as the AID, a standardized identifier for applications that can be installed on a smart card (AID, English acronym for “application identifier”).
  • the set of information possibly including:
  • the form in which the information transmitted to the client device relating to this or these first security functions in the message TR_SG1 may be different from the form in which the information transmitted to the client service provider relating to this or these second security functions, in the message TR_SG2.
  • the infrastructure operator can transmit to the client device a message giving it rights to use the singularization service, in the OPEN message.
  • This message can for example be transmitted following a request for use, for example the request REQ_1, or following a subscription to the singularization service itself following a service request to the service provider.
  • the infrastructure operator can for example distribute to the service provider a token that can be verified by the user equipment and manifesting the right to consume the singularized function. It is indeed envisaged that the steps of FIG. 3 comprise, prior to the steps indicated in FIG. 3, one or more steps comprising:
  • Activation steps ECH_1 and ECH_2 may be implemented allowing the use of the singularized function G and the inverse function V.
  • the activation steps ECH_1 and ECH_2 may consist of carrying out a first successful exchange between the service provider and the client device. They may be done in a different order from what is illustrated in FIG. 3 (ECH_2 before ECH_1). This activation may use a “challenge-response” type mechanism.
  • the service provider may create a given challenge for which it knows the expected response. It transmits this challenge, the singularized function is applied to this challenge message and returns a response that the service provider verifies. If the verification shows that the response is indeed the expected response, then the service is activated.
  • the singularization service determines two singularized functions G1 and V2 for the client device and G2 and VI for the service provider.
  • G1 and V2 for the client device
  • G2 and VI for the service provider.
  • the functions G and V are bijections and can be used in mirror, that is to say that V can be used to encrypt or scramble and G to decrypt, decrypt or unscramble.
  • Functions G and V may be safety functions in themselves, may be jamming functions added before a safety function and/or after a safety function.
  • G and V comprise one or more jamming functions and a function jammed by the jamming function(s), the function possibly existing in the device.
  • G and V may be security functions entirely created by the singulation service.
  • Figure 4 represents a second embodiment of an implementation of a security function deployment service. It represents the exchanges between the devices of the system.
  • the messages REQ_1, REQ_2, REP_2, TR_SG1, TR_SG2 may be identical to those described with respect to FIG. 3.
  • the service provider would like additional singularization or customization of its service, namely dedicated singularization. For this purpose, it requests a singularization function per service or for all of its services. This singularization or customization is combined with the singularization function linked to the component and described previously. This has the advantage of further strengthening the security of the services.
  • a different singularization is dedicated to each client device that uses the services of a service provider.
  • a client device A that uses a service B1 from a service provider FS1 may benefit from a different singularized function than when it uses a service B2 from a service provider FS2, or
  • a client device A that uses an SI service from a service provider FS1 may benefit from a different singularized function than when it uses an SI service' from the same service provider FS1.
  • the service provider transmits a dedicated secure function request REQ_3 for itself.
  • this dedicated secure function request can be dedicated to one or more, or even all, of the services offered by the service provider.
  • the service provider can transmit a dedicated REQ_3 request for each of its services, it can thus transfer as many requests as there are services it offers. It can also transmit a REQ_3 request for all of its services.
  • the infrastructure operator transmits a singularization request, for the service provider or for a particular service of the service provider, to the singularization service.
  • the singularization service determines a third singularization function G' and a fourth singularization function V'.
  • the singularization service records the functions G' and V'.
  • the third singularization function G' is transmitted to the device, message TR_SG3 and the fourth singularization function V' is transmitted to the service provider, message TR_SG4.
  • the messages TR_SG3 and TR_SG4 may include the fourth singularization function in the form:
  • said set of information possibly including:
  • the service provider and the client device have both client device-specific singularization functions, G and G', and service provider-specific functions, V and V'.
  • the two functions are combined to provide a new singularized security function.
  • the two functions G and G' can be combined simply by applying them one after the other (function G is applied to the result of function G', or vice versa) and similarly for functions V and V', to make encoding and decoding (or encryption/decryption) possible.
  • the security function can be distributed over several entities on a path between the client device and the service provider, respecting conditions pre-established by the infrastructure operator and the service provider.
  • the functions G and G' are distributed, one on the client device, G for example and the other, G', on a gateway located between the client device and the service provider.
  • the functional capabilities of the client device are not sufficient to implement the security level to be guaranteed but sufficient to implement a function G whose security level is lower.
  • the security level to be guaranteed which guarantees the combination of the functions G and G' is then guaranteed by distributing G and G', if the access gateway has the functional capabilities to implement the G' function.
  • the infrastructure operator can transmit to the client device a message giving it rights to use the singularization service, in the OPEN message.
  • the activation steps ECH_1 and ECH_2 can be implemented allowing the use of the singularized function G and the inverse function V.
  • the activation steps ECH_1 and ECH_2 can consist of carrying out a first successful exchange between the service provider and the client device. They can be done in a different order from what is illustrated in FIG. 3 (ECH_2 before ECH_1). This activation can use a “challenge-response” type mechanism.
  • the service provider can create a given challenge for which it knows the expected response. It transmits this challenge, the singularized function is applied to this challenge message and returns a response that the service provider verifies. If the verification shows that the response is indeed the expected response, then the service is activated.
  • Figure 5 represents a third embodiment of an implementation of a security function deployment service. It represents the exchanges between the devices of the system.
  • the infrastructure operator requests from the singularization service several security functions EG for each of the client devices, request REQ_2'.
  • This request can be identical to the request REQ_2 in which the infrastructure operator specifies that it requests several security functions for a single client terminal.
  • This plurality of security functions EG is a set of configurable security functions.
  • the singularization service can determine a set of EV singularized security functions capable of collaborating with the security function(s) transmitted to the client device.
  • collaborating we mean, decoding, decrypting, unscrambling data generated by the at least one first security function or encoding, encrypting, scrambling data intended for the at least one first security function.
  • sets of security functions EG and EV are recorded in the singularization service.
  • the set of singularized security functions EG is transmitted to the client device in a TR_SEG message.
  • the service provider transmits a REQ_PERS request for a dedicated secure function, for itself or for one of its services.
  • this dedicated secure function request can be dedicated to one or more, or even all, of the services offered by the service provider.
  • the service provider can transmit a dedicated REQ_PERS request and for each of its services, it can thus transfer as many requests as there are services it offers. It can also transmit a REQ_PERS request for all of its services.
  • the infrastructure operator transmits a singularization request for the service provider, or for a particular service of the service provider, to the singularization service, REQ_RAF.
  • the singularization service determines the parameters PG' for generating a security function G' at the client device for the use of the service or for the service provider.
  • This security function is generated from the set of functions EG.
  • the singularization service generates the corresponding security function V' capable of collaborating with the function G', as explained previously for the functions G' and V' (or G and V) from the set of functions EV.
  • the singularization service also records the PG' parameters and the V' function.
  • the singularization service transmits, to the infrastructure operator, the function V' in a TR_V' message and the function G' in a TR_G' message.
  • the infrastructure operator transmits the functions G' and V' respectively to the client device and to the service provider in a respective message TR2_G' and TR2_V'.
  • TR2_G' message can include the singularization function in the form:
  • TR2_V' message can include the singularization function in the form:
  • the infrastructure operator can transmit to the client device a message giving it rights to use the singularization service, in the OPEN message.
  • Activation steps ECH_1 and ECH_2 can be implemented allowing the use of the singularized function G' and the inverse function V'.
  • the activation steps ECH_1 and ECH_2 may consist of performing a first successful exchange between the service provider and the client device. They may be done in a different order from what is illustrated in FIG. 3 (ECH_2 before ECH_1). This activation may use a “challenge-response” type mechanism.
  • the service provider may create a given challenge for which it knows the expected response. It transmits this challenge, the singularized function is applied to this challenge message and returns a response that the service provider verifies. If the verification shows that the response is indeed the expected response, then the service is activated.
  • an optional step is envisaged in which the service provider can transmit to the infrastructure operator a level of security required by one or more of its services, for example in the form of a contract.
  • the contract can include indications relating to the levels of security required for the services or applications but also the manner in which the dual singularization functions are made available to the service provider, either by means of a server provided by the infrastructure operator that the service provider can query through an interface and without necessarily having access to the code, or by the transmission or deployment of a code.
  • the contract can also set the manner in which the singularized function is deployed on the component and where potential functions G' or G" can be deployed.
  • the contract can in particular also specify what happens when the functional capabilities of the device are not sufficient to guarantee the required level of service, as indicated above.
  • the service can specify that it wishes either: - ask the service provider to lower the required security level,
  • the client device - distributes the singularized service function, partly on the client device, by providing it with a singularized service function compatible with its functional capabilities and partly on another device located between the client device and the service provider, for example a gateway such as gateways 120, 130 or 140, the two singularized functions in combination making it possible to guarantee the required level of security.
  • a gateway such as gateways 120, 130 or 140
  • the methods described above and their variants as described are implemented in the form of a computer program comprising instructions for executing the steps of the method according to the embodiments of the invention when said program is executed by a computer.
  • these programs are recorded on a computer-readable recording medium.
  • the term “obtain” can be understood to mean determining, creating, or receiving.
  • the present invention also relates to a method for deploying a security function for at least one client device connected to a communication network, said security function being intended to secure a service implemented in said client device, the method being implemented by a device of an infrastructure operator of said communication network, and comprising:
  • the method comprises:
  • the method comprises:
  • said first and third security functions being able to encode, decode or verify, in said client device, in combination, the services of said service provider having transmitted the request to obtain a dedicated security function and said second and fourth security functions being able to decode, encode or verify, in said service provider, in combination, data received from the service implemented in said device.
  • the method comprises:
  • the deployment of the fourth security function comprises:
  • the method comprises:
  • said security functions are selected from one or the other or a combination
  • the generation of at least one first security function (G) for said at least one client device from a security level required by said service, and from functional capabilities of said client device comprises:
  • said first safety function is obtained by: - the selection of one or more functions from one or more families of configurable security functions, the selection being made according to the level of security to be guaranteed and the functional capabilities of said client terminal,
  • said security function is obtained by composing several mathematical functions on the inputs and/or outputs of a security function in order to scramble them and create a functional variation of said security function.
  • said security level is obtained from said service provider.
  • the invention also relates to a device for deploying a security function for at least one client device connected to the device through a communication network, said security function being intended to secure a service implemented in said client device, the deployment device comprising one or more processors configured together or separately to:

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Alarm Systems (AREA)

Abstract

L'invention concerne un procédé de génération d'une première fonction de sécurité (G), mis en œuvre dans un réseau comprenant une pluralité de dispositifs clients (1201, 1202, 1300, 1400, 1500), ladite fonction de sécurité (G) étant destinée à sécuriser un service mis en œuvre dans l'un au moins desdits dispositifs clients, le procédé comprenant, - la détermination (E3), d'un ensemble de familles de fonctions de sécurité paramétrables, - l'enregistrement (E4), de l'ensemble des familles de fonctions de sécurité paramétrables, - la réception (E6), d'un dispositif client, d'une requête de demande de sécurisation d'un service afin de garantir un niveau de sécurité associé audit service, - l'obtention (E8) de ladite première fonction de sécurité (G), à partir d'au moins une desdites fonctions de sécurité paramétrables enregistrées, à partir d'un niveau de sécurité à garantir et de paramètres de capacité fonctionnelle dudit dispositif client, -la transmission (E9) de ladite première fonction de sécurité (G) audit dispositif client.

Description

Description
Titre de l'invention: Procédé et dispositif de génération d'une fonction de sécurité
Domaine Technique
[0001] La présente invention concerne la génération de fonctions de sécurité destinées à sécuriser un service fourni par un fournisseur de service et utilisées par un terminal client.
Technique antérieure
[0002] La multiplicité des terminaux électroniques tels les téléphones mobiles, les dispositifs intelligents, « IOTS », les Secure Eléments de type carte SIM ou environnements d'exécution de confiance, appelés encore TEE, acronyme anglais de « Trusted Execution Environment », dont les capacités sont parfois limitées, conduit à avoir sur le marché des dispositifs incompatibles avec le niveau d'exigence de sécurité requis par les fournisseurs de service. En conséquence, ils ne peuvent pas atteindre des niveaux d'assurance élevés tel que le niveau d'assurance des cartes bancaires. Le renouvellement de parcs comprenant des milliers de dispositifs n'ayant pas les niveaux de sécurité requis pour satisfaire de nouveaux besoins en termes de sécurité a un coût trop prohibitif pour être mis en place. Il existe donc un besoin d'élever le niveau de sécurité de certains dispositifs pour permettre à ces dispositifs d'utiliser des services exigeant un niveau de sécurité supérieur à celui disponible dans ces dispositifs.
Exposé de l'invention
[0003] La présente invention concerne le renforcement du niveau de sécurité d'un dispositif existant ou dit « legacy » par une particularisation spécifique au dispositif nécessitant un niveau de sécurité spécifique. La présente invention concerne notamment selon un premier aspect la génération d'une fonction de singularisation et selon un second aspect le déploiement d'une fonction de singularisation.
[0004] A cet effet, la présente invention concerne un procédé de génération d'une première fonction de sécurité, mis en œuvre dans un réseau comprenant une pluralité de dispositifs clients, ladite fonction de sécurité étant destinée à sécuriser un service mis en œuvre dans l'un au moins desdits dispositifs clients, le procédé comprenant,
- l'obtention, d'un ensemble de familles de fonctions de sécurité paramétrables,
- l'enregistrement, de l'ensemble des familles de fonctions de sécurité paramétrables,
- la réception, d'un dispositif client, d'une requête de demande de sécurisation d'un service afin de garantir un niveau de sécurité associé audit service,
- l'obtention de ladite première fonction de sécurité, à partir d'au moins une desdites fonctions de sécurité paramétrables enregistrées, à partir d'un niveau de sécurité à garantir et de paramètres de capacité fonctionnelle dudit dispositif client,
-la transmission de ladite première fonction de sécurité audit dispositif client.
[0005] La présente invention peut avantageusement résoudre cette incompatibilité de sécurité entre le niveau de sécurité requis par un service et le niveau de service offert par le dispositif qui souhaite bénéficier du service, par l'adjonction de composants cryptographiques ou de fonctions de brouillage spécifiques à chaque instance ou déclinaison mis à disposition d'un utilisateur. La présente invention peut résoudre cette incompatibilité par une singularisation fonctionnelle des services de sécurité mis à disposition d'un dispositif d'un utilisateur.
[0006] Selon certains modes de réalisation, le procédé comprend
- la transmission, à un opérateur dudit réseau, d'une requête de demande de première fonction de sécurité pour garantir un niveau de sécurité lors de la mise en œuvre dudit service,
- la réception de la première fonction de sécurité déterminée à partir d'au moins une capacité fonctionnelle du dispositif client et du niveau de sécurité à garantir pour mettre en œuvre le service.
[0007] Selon certains modes de réalisation, ladite première fonction de sécurité est obtenue par :
- la sélection d'une ou plusieurs fonctions parmi une ou plusieurs familles des fonctions de sécurité paramétrables, la sélection étant faite en fonction du niveau de sécurité, à garantir et des capacités fonctionnelles dudit terminal client,
- le paramétrage de la au moins une desdites fonctions de sécurité paramétrables sélectionnées afin d'obtenir ladite première fonction de sécurité.
[0008] Selon certains modes de réalisation, le procédé comprend, préalablement à la requête de demande de fonction de sécurité, l'installation dans ledit dispositif client d'un service fourni par un fournisseur de services, ledit service étant associé audit niveau de sécurité à garantir, ledit niveau de sécurité étant supérieur à un niveau de sécurité disponible dans ledit dispositif client.
[0009] Selon certains modes de réalisation, ladite première fonction de sécurité est obtenue par
- la combinaison d'au moins deux fonctions de sécurité sélectionnées dans au moins une famille de fonctions satisfaisant le niveau de sécurité à garantir et les capacités fonctionnelles du dispositif client, et
- le paramétrage de ladite combinaison de fonctions sélectionnées.
[0010] Selon certains modes de réalisation, le procédé comprend :
- la transmission d'une seconde fonction de sécurité (V) audit fournisseur de service, ladite première fonction et ladite seconde fonction de sécurité collaborant ensemble pour coder ou décoder les communications entre ledit dispositif client et ledit fournisseur de services lors de la mise en œuvre dudit service.
[0011] Selon certains modes de réalisation, le procédé comprend :
- la transmission d'un identifiant dudit dispositif client audit fournisseur de services permettant une association de ladite seconde fonction de sécurité audit dispositif client.
[0012] Selon certains modes de réalisation, les première et seconde fonctions de sécurité sont transmises respectivement audit dispositif client et audit fournisseur de services
- sous la forme de code logiciel de ladite fonction,
- sous la forme d'un ensemble d'informations permettant audit dispositif client et audit fournisseur de service de construire ladite fonction, ledit ensemble d'informations comprenant :
- un identifiant de ladite fonction de sécurité transmise,
- une liste comprenant des fonctions de brouillage utilisées pour lesdites premières et secondes fonctions de sécurité, et l'ordre dans lequel elles sont utilisées.
[0013] Selon certains modes de réalisation, la fonction de sécurité est obtenue en composant plusieurs fonctions mathématiques sur les entrées et ou sorties d'une fonction de sécurité afin de les brouiller et de créer une variation fonctionnelle de ladite fonction de sécurité.
[0014] Selon certains modes de réalisation, une famille de fonctions de sécurité paramétrables comprend un ensemble de fonctions cryptographiques de complexité et de structure identiques, une famille pouvant être choisie parmi:
- une famille de permutations d'octets à octets ou
- une famille constituée d'un tour d'un schéma de Feistel complexifiée par un algorithme de hachage.
- Une famille constituée des opérations arithmétiques modulo 65537.
[0015] L'invention concerne également un terminal dans un réseau de communication, comprenant un opérateur d'infrastructure, ledit terminal comprenant un ou plusieurs processeurs configurés ensemble ou séparément pour :
- transmettre, à un opérateur dudit réseau, une requête de demande de première fonction de sécurité pour garantir un niveau de sécurité lors de la mise en œuvre d'un service,
- recevoir la première fonction de sécurité déterminée à partir d'au moins une capacité fonctionnelle du terminal et du niveau de sécurité à garantir pour mettre en œuvre le service.
[0016] L'invention concerne également un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon l'invention lorsque ledit programme est exécuté par un ordinateur.
[0017] L'invention concerne également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon l'invention.
Brève description des dessins
[0018] [Fig. 1] La figure 1 représente un mode de réalisation d'un système mettant en œuvre des modes de réalisation de la présente invention.
[0019] [Fig. 2] La figure 2 représente un mode de réalisation d'un procédé selon la présente invention.
[0020] [Fig. 3] La figure 3 représente un premier mode de réalisation d'une mise en œuvre d'un service de déploiement d'une fonction de sécurité,
[0021] [Fig. 4] La figure 4 représente un second mode de réalisation d'une mise en œuvre d'un service de déploiement d'une fonction de sécurité,
[0022] [Fig. 5] La figure 5 représente un troisième mode de réalisation d'une mise en œuvre d'un service de déploiement d'une fonction de sécurité.
Description des modes de réalisation [0023] D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexes qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif.
[0024] La présente invention est décrite dans un système comprenant un opérateur d'infrastructure et un fournisseur de service comme illustré sur la figure 1. L'opérateur d'infrastructure 100 peut être typiquement un opérateur d'un réseau de communication ou de service informatique devant gérer des équipements réseaux et/ou informatiques. L'opérateur d'infrastructure 100 possède des équipements d'infrastructure 101 permettant de gérer le système, sous la forme préférentielle d'équipements informatiques tels des serveurs et des bases de données ainsi que différents équipements réseau.
[0025] Plusieurs dispositifs clients 1201, 1202, 1300, 1400 sont connectés au réseau déployé par le fournisseur d'infrastructure, au travers respectivement des passerelles d'accès 120, 130 et 140 fournies par le fournisseur d'infrastructure. Les passerelles d'accès sont généralement connectées à un ou plusieurs dispositifs clients à travers un réseau local de type LAN, filaire ou sans fil. Elles permettent la connexion entre le réseau local et le réseau de l'opérateur d'infrastructure 100. Un dispositif client 1500 est connecté au réseau directement, sans passer par une passerelle.
[0026] Deux fournisseurs de services 1100 et 1200 sont également connectés au réseau de l'opérateur. Cette connexion est soit réalisée directement, soit via l'entremise d'un ou plusieurs opérateurs de communication, tels que mis en œuvre sur Internet. Dans ce cas précis, les fournisseurs de services 1100 et 1200 sont alors connectés au réseau de l'opérateur par la mise en œuvre de techniques de VPN ou des accès plus communs de type SSL, HTTPS, ou tout autre techniques connues de l'homme de l'art pour les interactions sur Internet. Une pluralité de fournisseurs de services peut cohabiter et fournir des services. Un fournisseur de services est typiquement, dans le contexte de la présente invention, un service de paiement ou un fournisseur d'identité, un service de délivrance de biens, de contenus ou de services, de tels services nécessitant des mises en œuvre de protocoles de sécurité robustes.
[0027] Les dispositifs clients 1201, 1202, 1300, 1400 et 1500 peuvent être des dispositifs comprenant des capacités importantes qui leur permettent d'installer et d'utiliser un ou plusieurs services fournis par les fournisseurs de services. Dans certains cas et selon la présente invention, un ou plusieurs de ces dispositifs clients ont des capacités limitées qui ne leur permettent pas d'installer un ou plusieurs services fournis par le ou les fournisseurs de service selon des niveaux de sécurité requis par ces fournisseurs. En effet, certains de ces dispositifs clients, tels des cartes SIM, des équipements de type objets connectés, des éléments de type éléments de sécurité, ne peuvent pas supporter des fonctions cryptographiques avancées ou n'offrent pas de service de sécurité renforcés tels que du stockage sécurisé. En conséquence, ils ne pourraient pas, sans la présente invention, atteindre des niveaux d'assurance élevés au sens critères communs ou selon la Directive Européenne CyberSecurityAct, tel que le niveau de sécurité des cartes bancaires par exemple.
[0028] La présente invention peut permettre à de tels dispositifs clients ne possédant pas les niveaux de sécurité suffisants, d'atteindre des niveaux de sécurité leur permettant d'utiliser des services fournis par les opérateurs de service et requérant des niveaux de sécurité qui à la base n'étaient pas atteints par ces dispositifs ou disponibles dans ces dispositifs, dès lors que ceux-ci permettent l'adjonction de fonctions ou de logiciels additionnels. Avantageusement, ceci peut permettre d'éviter de remplacer les dispositifs clients par de nouveaux dispositifs afin de pouvoir mettre en œuvre ces services nécessitant des fonctions de sécurité élevée pour fonctionner.
[0029] Les dispositifs clients peuvent comprendre un ou plusieurs composants qui mettent en œuvre le service. Un composant est par exemple une carte SIM, un environnement d'exécution de confiance (TEE), un logiciel embarqué d'IoT (internet des objets), une application issue d'une boutique, mais peut être aussi un environnement ou espace de stockage, de calcul et d'exécution dédiés au sein d'une infrastructure virtuelle communément appelée Cloud, des containers, des Machines Virtuelles (VM), des micro services... Dans la suite de la description, on se réfère à un dispositif client mais on peut également comprendre à un composant du dispositif client ou à un ou plusieurs composants du dispositif client.
[0030] Tout au long de la description, la fonction de sécurité peut être dédiée au dispositif client ou à un composant du dispositif client. Ainsi, lorsque l'on évoque une fonction de sécurité pour un dispositif client, il peut s'agir d'une fonction de sécurité pour un composant du dispositif client. De même lorsque l'on évoque une fonction de sécurité pour un composant du dispositif client, il peut s'agir d'une fonction de sécurité pour un dispositif client.
[0031] L'opérateur d'infrastructure accède également à un service de singularisation 102 qui singularise une fonction de sécurité pour un ou plusieurs terminaux clients, selon les modes de réalisation de la présente invention. Le service de singularisation peut être une composante de l'opérateur d'infrastructure 100 ou peut être disjoint de celui-ci. Typiquement, le service de singularisation est un module logiciel comprenant également des moyens de stockage, par exemple un serveur.
[0032] A cet effet, les modes de réalisation décrits ci-après proposent une singularisation d'une fonction de sécurité qui particularise le résultat des calculs de la fonction de sécurité qui va être déployée dans le dispositif client ou un composant de celui-ci pour permettre à celui-ci de mettre en œuvre un service avec un niveau de sécurité requis par l'application. Outre la possibilité pour un composant de mettre en œuvre un service auquel il ne pouvait pas accéder, la présente divulgation rend très difficile l'automatisation d'attaques sur les composants mettant en œuvre cette fonction. En effet, son caractère non uniforme et spécifique à chaque implémentation rend compliqué les automatisations de cyber-attaques en masse.
[0033] Il est possible de singulariser une fonction déjà existante dans un dispositif client en la rendant plus sécurisée pour répondre à un besoin de sécurisation supérieur à celui qu'elle pouvait fournir mais également de fournir une fonction de sécurité singularisée à un dispositif client, par un exemple un dispositif de type loT, dépourvu initialement de fonctions de sécurité, de manière à lui permettre de mettre en œuvre un service demandant un niveau de sécurité.
[0034] L'opérateur d'infrastructure réseau 100 collabore avec le service de singularisation 102 afin de fournir aux dispositifs clients et aux fournisseurs de services des fonctions de sécurité permettant, comme mentionné précédemment, à ceux-ci de mettre en œuvre un service dans le dispositif client, en adaptant le niveau de sécurité du dispositif client pour le rendre apte à mettre en œuvre ledit service selon le niveau de sécurité requis par ledit service.
[0035] La figure 2 représente un mode de réalisation de la génération d'une fonction de sécurité singularisée. L'opérateur d'infrastructure peut établir au fur et à mesure de l'ajout de nouveaux terminaux clients, une liste des terminaux clients présents derrière les passerelles d'accès ou connectés directement au réseau de l'opérateur. A cet effet, il peut mettre en place des mécanismes d'interrogation des passerelles ou des terminaux ou obtenir les informations lors de la connexion des nouveaux terminaux. [0036] Lors de l'étape El, l'opérateur associe aux dispositifs clients une ou plusieurs capacités fonctionnelles en collectant leurs capacités fonctionnelles. Ces données, mettant en relation des identifiants des dispositifs clients ainsi que leurs capacités fonctionnelles respectives, peuvent être enregistrées dans des serveurs de l'infrastructure réseau et mises à jour régulièrement ou lors de l'ajout ou du retrait d'un dispositif client.
[0037] Les identifiants des dispositifs clients peuvent par exemple être une adresse MAC, une adresse IP, un numéro de série, un identifiant relatif à des services comme un IMSI, (identité internationale d'abonné mobile), un MSISDN (numéro qui identifie de manière unique un abonnement sur un réseau mobile GSM ou UMTS) ou une adresse email pour des services de communications, ou un numéro de contrat technique pour des services de délivrance de biens ou contenus...
[0038] Cette étape El est une étape optionnelle dans le sens où l'opérateur d'infrastructure peut disposer de ces informations de différente manière, spontanément sans avoir à les demander aux terminaux clients, pour les besoins de la présente invention.
[0039] Les capacités fonctionnelles peuvent comprendre, de manière non exhaustive, leur possession éventuelle de librairies cryptographiques ou arithmétiques intégrées et si oui, lesquelles, leur espace mémoire disponible, leur système d'exploitation et sa version.
[0040] Les capacités fonctionnelles peuvent permettre de déterminer soit la nature, soit la complexité de fonctions de sécurité que ces dispositifs peuvent implémenter. Autrement dit, les capacités fonctionnelles sont liées au niveau de sécurité de la fonction singularisée qui sera implémentée dans le dispositif client dans la mesure où elles peuvent permettre de déterminer le niveau de sécurité maximal que le dispositif peut implémenter.
[0041] Lorsque les capacités fonctionnelles ne sont pas suffisantes pour supporter le niveau de sécurité requis par le service, il est possible soit :
- de demander au fournisseur de service de diminuer le niveau de sécurité requis,
- de ne pas autoriser le dispositif client à utiliser le service demandé,
- de distribuer la fonction de service singularisée, en partie sur le dispositif client, en lui fournissant une fonction de service singularisée compatible avec ses capacités fonctionnelles et en partie sur au moins un autre dispositif situé entre le dispositif client et le fournisseur de service, par exemple une ou plusieurs passerelles comme les passerelles 120, 130 ou 140 (ou d'autres dispositifs présents dans le réseau), les deux ou plus de deux fonctions singularisées permettant en combinaison de garantir le niveau de sécurité requis.
[0042] L'opérateur d'infrastructure peut également obtenir des niveaux de sécurité requis pour chaque service du fournisseur de service, étape E2. Ces niveaux de sécurité peuvent être obtenus de différentes façons.
[0043] Selon certains modes de réalisation, les fournisseurs de service peuvent transmettre à l'opérateur d'infrastructure les niveaux de sécurité associés aux services qu'il fournit. Ils peuvent être transmis lors du déploiement d'un service ou enregistrés dans une base de données.
[0044] Selon certains modes de réalisation, ces niveaux de sécurité peuvent également répondre à des critères de sécurité standardisés. Par exemple, une application relative à une fonction bancaire peut être associée systématiquement à un niveau de sécurité élevé. Le serveur peut par exemple un obtenir un code de fonction (exemple code de fonction bancaire) et associer un niveau de sécurité connu pour ce code de fonction.
[0045] Selon certains modes de réalisation, le serveur d'infrastructure peut demander au fournisseur de services, un niveau de sécurité requis pour son fonctionnement lorsque le terminal client demande à l'opérateur d'infrastructure l'installation d'une fonction singularisée, suite par exemple à la non installation du service sur le terminal client pour défaut de niveau de sécurité suffisant.
[0046] Selon certains modes de réalisation, le dispositif client peut également transmettre le niveau de sécurité du service qu'il souhaite installer à l'opérateur d'infrastructure.
[0047] Selon certains modes de réalisation, l'opérateur fait une veille des besoins marchés et détermine que pour un équipement donné, il faut que celui-ci ait un niveau de sécurité élevé. Par exemple, si l'opérateur d'infrastructure décide de positionner la carte SIM comme support d'une carte d'identité numérique, ceci nécessite une certification elDAS et CSPN de niveau élevé. 80% des cartes SIM présentes sur le marché ont un niveau suffisant, les 20% restants doivent alors recevoir un traitement pour rendre leur niveau de sécurité compatible à ce niveau élevé. [0048] L'opérateur d'infrastructure obtient un ensemble de familles de fonctions de sécurité paramétrables, étape E3.
[0049] Une famille de fonctions peut être décrite comme un ensemble de fonctions mathématiques de complexité et de structure identiques. On peut citer, non limitativement, la famille des permutations d'octets à octets ou de bits à bits, la famille constituée d'un tour d'un schéma de Feistel complexifiée par un algorithme de type SHA-1, la famille constituée des opérations arithmétiques modulo 65537 mais aussi toute fonction mathématique connue de l'homme de l'art dans le domaine des mathématiques, telles que des opérations d'arithmétique dans l'anneau ( / 55557 ,+,x).
[0050] Les familles de fonction sont enregistrées par l'opérateur réseau 100, étape E4. Elles peuvent être enregistrées dans des serveurs de l'infrastructure 101.
[0051] Elles constituent en quelque sorte une base de données ou un catalogue d'un ensemble de familles de fonctions de sécurité paramétrables et destinées à être singularisées.
[0052] Ces étapes El à E4 sont des étapes qui sont mises en œuvre par l'opérateur réseau et qui peuvent être réalisées indépendamment des étapes suivantes, en amont de celles-ci, pour l'établissement d'un catalogue ou d'une base de données de fonctions de sécurité.
[0053] L'opérateur de réseau peut donc avantageusement fournir un service de sécurisation pour les fournisseurs de service et donner accès à des services demandant un niveau de sécurité supérieur à celui qu'ils ont nativement, à des terminaux clients présents dans son réseau. Ainsi, les fournisseurs de service peuvent transmettre une requête de souscription au service, non représentée sur la figure 2, afin de bénéficier de ce service de sécurisation, encore appelé de singularisation. Un contrat de service peut être alors conclu entre les fournisseurs de services 1100, 1200, et l'opérateur d'infrastructure réseau 100.
[0054] Lors d'une étape E5, un terminal client, par exemple le terminal 1201, souhaite bénéficier d'un service offert par l'un des fournisseurs de service 1100 ou 1200. Il installe alors le service sur le terminal, sous la forme de code logiciel, par exemple un code d'une application. Cependant, lors de l'installation, le fournisseur de service peut alerter le terminal client 1201 qu'il n'a pas de niveau de sécurité requis pour mettre en œuvre ledit service. Il est également possible, sans l'intervention du fournisseur du service, que l'application ne puisse s'installer car le niveau de sécurité du terminal 1201 n'est pas suffisant. Le service est en effet associé à un niveau de sécurité à garantir pour pouvoir fonctionner. L'application demande par exemple un espace de stockage sécurisé sur le terminal client pour fonctionner alors que le terminal client ne dispose pas de fonctions de stockage sécurisées. Le terminal client 1201 transmet donc une requête de fonction de sécurité singularisée, cette requête visant à installer une fonction de sécurité singularisée ou à renforcer une fonction de sécurité existante, afin de garantir un niveau de sécurité dudit service qu’il souhaite installer ou qu’il a installé pour pouvoir l’utiliser, étape E6.
[0055] Cette requête peut comprendre plusieurs paramètres. Elle peut comprendre notamment un identifiant du terminal client 1201 qui permet d'associer la fonction de sécurité singularisée qui sera générée au terminal qui l'a demandé. L'identifiant peut déjà être compris dans l'un des champs des messages échangés (c'est le cas par exemple d'une adresse MAC) ou peut être spécifiquement transmis. Cet identifiant du terminal peut permettre de communiquer à distance avec ce terminal, cet identifiant pouvant être, de manière non exhaustive, un identifiant relatif au système d'exploitation du terminal et permettant des communications à distance via les moyens du fournisseur terminal, une adresse de communication sur Internet ou sur un réseau de télécommunication, un identifiant lié par exemple à un composant de sécurité et aux opérateurs de l'infrastructure sous-jacente comme une carte SIM et les IMSI (identité internationale d'abonné mobile) / MSISDN relatif (numéro qui identifie de manière unique un abonnement sur un réseau mobile GSM ou UMTS), un identifiant au sein d'une instance dédiée au sein d'un autre élément de sécurité comme les TEE (acronyme anglais de « Trusted Execution Environment », spécifié par le consortium GlobalPlatform). Elle peut comprendre également le service de sécurité à renforcer, par exemple, authentification mutuelle Application Fournisseur de service, authentification de l'application à distance, intégrité et preuve d'origine des échanges entre l'application et le fournisseur de service, mais aussi des paramètres spécifiques au service de sécurité requis. Elle peut comprendre également le niveau de sécurité à garantir à l'application que le terminal client 1201 souhaite installer. Ce niveau de sécurité à garantir peut s'exprimer sous différentes formes, par exemple sur une échelle de 1 à 10. Dans certains modes de réalisation, ces niveaux de sécurité peuvent correspondre aux niveaux définis dans la Directive Européenne CyberSecurity Act qui définit les trois niveaux suivants : Basic, Substantiel et Fort. [0056] Les fonctions utilisées pour sécuriser sont plus ou moins complexes, par exemple des fonctions de permutations sont plus complexes que des fonctions de XOR. Les familles de permutations sont donc privilégiées lorsque le niveau de sécurité requis est élevé. On peut donc avoir une sélection de la famille de fonctions ou des familles de fonction en comparant le niveau de sécurité requis et la complexité en terme de fonction des familles et en sélectionnant la famille ou les familles dont les fonctions présentent un niveau de complexité permettant d'obtenir ce niveau de sécurité. Autrement dit, une famille est sélectionnée en fonction du niveau de sécurité requis et de la complexité des fonctions qu'elle contient.
[0057] Dans certains modes de réalisation, la requête peut comprendre également des paramètres relatifs à la capacité fonctionnelle du dispositif client. Dans d'autres modes de réalisation, si l'opérateur d'infrastructure ne dispose pas des capacités fonctionnelles du dispositif client, alors suite à la réception de la requête, il peut les lui demander, étape E7.
[0058] L'opérateur d'infrastructure génère alors la fonction de sécurité singularisée dédiée au terminal client 1201 pour l'utilisation du service demandé, étape E8.
[0059] Selon les modes de réalisation de la présente invention, une même fonction de sécurité singularisée peut donc être générée pour des terminaux présentant des capacités fonctionnelles identiques et souhaitant installer un même service.
[0060] Dans une implémentation renforcée en terme de sécurité, l'opérateur d'infrastructure pourrait garantir l'unicité de cette fonction singularisée pour l'utilisateur ou le terminal requérant, amenant ainsi une authentification implicite dudit terminal ou utilisateur. Selon certains mode de réalisation, la fonction singularisée générée pourrait donc être unique.
[0061] La fonction de sécurité singularisée est obtenue à partir d'au moins une desdites fonctions de sécurité paramétrables enregistrées, lors de l'étape E4, à partir dudit niveau de sécurité à garantir et de paramètres de capacité fonctionnelle dudit dispositif client. La fonction de sécurité singularisée peut être obtenue à partir d'une génération automatique ou aléatoire de fonctions sélectionnées dans une famille de fonctions répondant aux exigences de sécurité du service et à la capacité fonctionnelle du dispositif client.
[0062] Selon certains modes de réalisation, la fonction de sécurité peut consister à rajouter de la sécurité à une fonction déjà existante dans le dispositif client, pour venir renforcer, ou encore élever, le niveau de sécurité existant de manière à garantir le niveau de sécurité requis par le service à installer sur le service client pour sa mise en œuvre.
[0063] La fonction de sécurité peut être obtenue en composant plusieurs fonctions mathématiques sur les entrées et ou sorties d'une fonction de sécurité afin de les brouiller et de créer une variation fonctionnelle de ladite fonction de sécurité.
[0064] Selon certains modes de réalisation, la fonction de sécurité peut également être une fonction qui est composée intégralement par le service de singularisation, à partir également du catalogue de fonction, par exemple lorsque le dispositif client ne dispose pas déjà de fonction de sécurité ou ne dispose pas d'une fonction de sécurité dont le niveau peut être suffisamment relevé pour atteindre le niveau de sécurité à garantir pour la mise en œuvre du service.
[0065] Les fonctions de sécurité pouvant être singularisées sont de différentes natures, on peut citer par exemple :
- les fonctions de sécurité de type chiffrement,
- les fonctions de sécurité de type authentification ou intégrité
- les fonctions de sécurité de type signature électronique.
[0066] Une fonction de sécurité de type chiffrement peut être singularisée à partir d'une pluralité de bijections. La fonction de sécurité dédiée peut être obtenue à partir d'une génération automatique ou aléatoire de bijections sélectionnées dans une famille de fonctions, chacune desdites fonctions générées étant alors chainée en amont ou en aval de la fonction de chiffrement à singulariser. La génération automatique d'une bijection peut reposer d'une part sur la génération d'un paramètre cryptographique, comme une clé, et d'autre part sur la génération aléatoire d'un paramètre de configuration, par exemple un ensemble de permutations d'octets ou de fonctions de hachage.
[0067] Une fonction de sécurité de type authentification ou intégrité peut être singularisée à partir des mêmes familles de fonctions que celles utilisées pour la singularisation des fonctions de chiffrement symétrique, complétées par des familles de fonctions non bijectives, des familles de fonctions à sens unique, chacune desdites fonctions générées étant alors chainée en amont ou en aval de la fonction d'authentification ou d'intégrité à singulariser. Cette singularisation peut être obtenue à partir d'une génération automatique ou aléatoire de fonctions à sens unique ou de fonctions de chiffrement sélectionnées dans une famille de fonctions.
[0068] Une fonction de sécurité de type signature électronique peut être obtenue à partir de fonctions à base de clé secrète.
[0069] Selon certains modes de réalisation, le service de singularisation peut comprendre un gestionnaire de stratégie de singularisation et un gestionnaire de logique de singularisation.
[0070] Le gestionnaire de stratégie de singularisation est un module, logiciel de préférence, disposant d'un ensemble de règles lui permettant de définir une logique de singularisation à partir d'un niveau de sécurité requis et des capacités fonctionnelles des différents dispositifs clients présents.
[0071] Le gestionnaire de logique de singularisation est un module, logiciel de préférence, qui génère une fonction singularisée à partir d'une logique de singularisation. Il constitue cette fonction singularisée en sélectionnant des fonctions dans une base de données de fonctions, telles que déterminées lors de l'étape E3 précédente.
[0072] Une fonction de singularisation complète est constituée de N fonctions sélectionnées et configurées par le générateur automatique parmi P familles de fonctions disponibles dans la base de données.
[0073] Le générateur automatique de fonction singularisée sélectionne une implémentation d'une fonction au sein d'une base de codes organisée par famille de fonctions et permet de créer une fonction de scrambling à partir d'une famille de fonctions et d'un paramétrage d'un ou plusieurs paramètres de configuration et d'un ou plusieurs paramètres cryptographiques. Un exemple de famille de fonctions est la famille des fonctions XOR. Cette famille est constituée d'un paramètre de configuration (la position des octets des données entrantes où appliquer le XOR) et d'un paramètre cryptographique (la valeur avec laquelle effectuer le XOR). De même, dans l'arithmétique dans l'anneau (Z/nZ, +,) x définit l'ensemble des opérations d'arithmétique possibles modulo n. Une fonction de scrambling qui peut être générée à partir de cette famille est la fonction qui effectue une multiplication (paramètre de configuration) d'une entrée x avec une valeur Kl (paramètre cryptographique) modulo n (paramètre de configuration). Dans une famille, on peut avoir des fonctions qui ont le même comportement (ex. permuter le bit 1 et le bit 4) mais un code différent parce qu'on a utilisé un technique de codage particulière.
[0074] Exemples d'obtention d'une fonction singularisée
[0075] Dans cet exemple, lors de l'étape E3, deux familles de fonctions sont déterminées, à savoir le XOR et la permutation. Dans cet exemple, on considère que la famille de permutations est plus complexe que la famille de XOR.
[0076] Chaque famille dispose de 3 codes correspondant à des fonctions de ces familles. Par exemple, la famille XOR dispose des fonctions suivantes :
XI- un code javacardv3.1 permettant de faire un XOR entre les n premiers octets du message (paramètre de configuration) et une valeur v (paramètre cryptographique), X2- un code C permettant de faire un XOR de l'ensemble des premiers octets du message (paramètre de configuration) et une valeur v (paramètre cryptographique), X3- un code javacardv3.1 fonctionnellement équivalent au code XI mais faisant appel à une technique de développement défensif, comme l'ajout d'instructions pour brouiller les motifs de consommation électrique.
[0077] La famille permutation dispose des codes suivants :
PI- le code C d'une permutation pour un vecteur d'entrée de taille 10 et qui permute les octets a (paramètre de configuration < = 10) et 4,
P2- le code javaCard v3.1 obfusqué d'une permutation pour un vecteur de taille 10 et qui effectue des permutations suivant un ordre en paramètre d'entrée (paramètre de configuration),
P3- un code fonctionnellement équivalent au code P2 mais faisant usage de la fonction de permutation embarquée dans l'OS javaCard v2.1
[0078] Dans cet exemple, le niveau de sécurité requis par le service est élevé, par exemple au niveau 8 sur une échelle allant de 0 (niveau le plus faible) à 10 (niveau le plus élevé) ou au niveau fort des Directive Européenne CyberSecurity Act, et les capacités fonctionnelles du dispositif client qui a demandé l'installation du service (par exemple une carte à puce) supportent javacard 3.1.
[0079] Le gestionnaire de stratégie crée une logique de singularisation indiquant de privilégier les fonctions de complexité élevées avec obfuscation et développées pour javacard 3.1.
[0080] Le gestionnaire de logique de singularisation effectue une recherche dans le catalogue basée sur la logique déterminée, et reçoit une liste de fonctions à utiliser: X3, Pl et XI. A partir de là, le gestionnaire choisit dans quel ordre les composer, s'il les combine pour créer une nouvelle fonction et comment il les paramètre pour créer la fonction singularisée. Il peut aussi vérifier que celle-ci est unique pour la cible. Par exemple, dans le cas de la fonction X3 décrite ci-dessus, n et v sont à paramétrer. Pour la fonction PI, il faudra paramétrer a.
[0081] Selon certains modes de réalisation, l'obtention de la fonction de sécurité singularisée comprend le paramétrage d'au moins une des fonctions de sécurité paramétrables sélectionnées en fonction du niveau de sécurité à garantir et de paramètres de capacité fonctionnelle obtenus du dispositif client 1201 afin d'obtenir une première fonction de sécurité singularisée.
[0082] Selon certains modes de réalisation
- la première fonction singularisée de sécurité est obtenue par
- la combinaison d'au moins deux fonctions de sécurité sélectionnées dans au moins une famille de fonctions satisfaisant le niveau de sécurité à garantir et les capacités fonctionnelles du dispositif client, et
- le paramétrage de la combinaison de fonctions sélectionnées.
[0083] La fonction de sécurité singularisée est ensuite transmise au dispositif client 1201 pour être mise en œuvre lors de ou avec l'utilisation du service concerné, étape E9.
[0084] La fonction de sécurité peut être transmise sous différentes formes au dispositif client 1201 :
- sous la forme de code logiciel de ladite fonction,
- sous la forme d’un ensemble d’informations permettant au dispositif client 1201 et audit fournisseur de service de construire ladite fonction, l’ensemble d’informations comprenant :
- un identifiant de la fonction de sécurité transmise,
- une liste LBA.
[0085] L'identifiant de la fonction singularisée transmise peut permettre de distinguer une parmi plusieurs fonctions de sécurité singularisées. En effet, le fournisseur de service ou le terminal peut disposer de plusieurs fonctions singularisées pour un usage spécifique, et peut donc utiliser un identifiant pour les distinguer et savoir quelle fonction singularisée sélectionner pour effectuer le traitement. Cela peut aussi être utile pour gérer le cycle de vie de la fonction (installation / mise à jour / désinstallation). [0086] Selon certains modes de réalisation, l'opérateur d'infrastructure peut transmettre au fournisseur de services ou au dispositif client, un code comprenant plusieurs fonctions de brouillage (« scrambling » en anglais), en remplacement de la transmission du code de la fonction singularisée. Pour chaque fonction singularisée transmise au dispositif client, le fournisseur d'infrastructure transmet au fournisseur de service le moyen de reconstruire la fonction duale de celle instanciée sur l'équipement en indiquant dans la liste LBA quelles fonctions de scrambling sont à activer, dans quel ordre et si elles interviennent avant ou après la fonction de sécurité à singulariser (ex.AES). L'identifiant de la fonction singularisée permet de faire le lien avec la fonction duale dans l'équipement. Il peut également être envisagé de faire de même sur le dispositif client si celui-ci dispose de la capacité mémoire disponible.
[0087] La fonction de sécurité peut être ensuite intégrée au code du service déployé dans le terminal client.
[0088] Comme mentionné précédemment la fonction peut venir sécuriser une fonction déjà existante ou peut constituer une fonction à part entière.
[0089] Selon certains modes de réalisation, la fonction de sécurité peut être intégrée à une application, unité de code, présente sur le dispositif client, comme par exemple une applet sur une carte à puce dans le dispositif client. Le code de l'applet peut être transmis par le dispositif client à l'opérateur qui modifie le code de l'applet en y intégrant la fonction de sécurité singularisée et retransmet le code de l'applet au dispositif client. La fonction de sécurité peut être une applet en elle-même transmise par l'opérateur de service au dispositif client. Selon certains modes de réalisation, le service comprend des APIs lui permettant de consommer la fonction de sécurité singularisé dans l'applet déployée dans le dispositif ou le composant.
[0090] Une seconde fonction de sécurité singularisée, duale de celle installée dans le dispositif client, peut être transmise au fournisseur de services qui fournit le service demandé. La première fonction singularisée et ladite seconde fonction singularisée collaborant ensemble pour coder, décoder ou vérifier les services de sécurité instanciés entre ledit dispositif client et ledit fournisseur de services lors de la mise en œuvre du service.
[0091] Dans certains modes de réalisation, le code de la fonction duale, n'est pas nécessairement transmis en tant que tel au fournisseur de services mais à un serveur de l'infrastructure que le fournisseur de services peut interroger à travers une interface. Le fournisseur de services peut demander au serveur de vérifier la valeur renvoyée par la fonction singularisée dans le terminal client. Ceci permet avantageuseuement de limiter la diffusion des fonctions singularisées.
[0092] Les premières et secondes fonctions de sécurité peuvent par exemple être des fonctions de chiffrement et de déchiffrement. Elles peuvent être des fonctions symétriques, le fournisseur de service et le dispositif client utilisent la même fonction pour chiffrer et pour déchiffrer ou asymétriques et dans ce dernier cas, le fournisseur de service et le dispositif client reçoivent chacun une fonction de sécurité singularisée permettant de déchiffrer les messages de l'autre et une fonction de sécurité singularisée permettant de chiffrer les messages. Ces premières et secondes fonctions peuvent aussi être conçues de façon identiques dans le sens ou les deux entités procèdent au même traitement pour s'assurer par exemple que l'intégrité d'un message est bien maintenu.
[0093] Les modes de réalisation décrits ci-dessous, détaillent des exemples où plusieurs fonctions de sécurité singularisées viennent en collaboration, sécuriser les services à la demande.
[0094] Selon certains modes de réalisation, l'opérateur d'infrastructure enregistre les fonctions de sécurité singularisées associées à l'identifiant du terminal client et au service. Il peut enregistrer les fonctions en tant que telles, par exemple sous la forme de code logiciel, ou des informations permettant d'obtenir ces fonctions, de la même manière que les informations transmises au dispositif client et au fournisseur de service décrites précédemment.
[0095] Une fois la ou les fonctions singularisées de sécurité transmises au dispositif client et au fournisseur de services, des étapes additionnelles d'activation du service peuvent être envisagées. A ce titre, l'activation peut utiliser des mécanismes de challenge/réponse ( en anglais « challenge /response ») pour activer le service. Le fournisseur de services peut créer un défi donné dont il connait la réponse attendue. Il transmet ce défi, la fonction singularisée est appliquée sur ce message de défi et renvoie une réponse que le fournisseur de services vérifie. Si la vérification montre que la réponse est bien la réponse attendue, alors le service est activé. [0096] Une fois activé, le service peut être utilisé par le dispositif client car celui-ci respecte le niveau de sécurité attendu pour la mise en œuvre du service par le fournisseur de service.
[0097] Sur les figures 3, 4 et 5, on utilise les abréviations suivantes :
- FS : fournisseur de service
- OI : opérateur d'infrastructure
- SG : service de singularisation
- Infra : infrastructure réseau
- Client : dispositif client
[0098] La figure 3 représente un premier mode de réalisation d'une mise en œuvre d'un service de déploiement d'une fonction de sécurité. Elle représente les échanges entre les dispositifs du système.
[0099] Une première étape optionnelle peut comprendre une requête REQ_1 de la part du dispositif client. Cette requête peut comprendre une demande du dispositif client d'une fonction de sécurité singularisée. Ce dispositif peut souhaiter mettre en œuvre un service fourni par un des fournisseurs de service, mais ne dispose pas du niveau de sécurité requis par le fournisseur de service pour la mise en œuvre du service.
[0100] Plus généralement, l'opérateur d'infrastructure peut ne pas générer une seule fonction de sécurité pour un terminal client suite à une requête telle la requête REQ_1 mais peut générer une ou plusieurs fonctions de sécurité pour chaque ou plusieurs des terminaux clients présents dans le réseau de l'opérateur, sans attendre de requête. En effet, l'opérateur d'infrastructure peut avantageusement disposer de la connaissance de l'ensemble des terminaux clients, et générer les fonctions de sécurité pour ces terminaux connectés au réseau. L'opérateur peut générer ces fonctions de sécurité en utilisant un service de singularisation, en charge de générer les fonctions de sécurité. Le service de singularisation, illustré comme étant un dispositif ou module différent de l'opérateur d'infrastructure, pour des raisons de clarté, peut être intégré à celui-ci, comme mentionné en référence à la figure 1. L'opérateur d'infrastructure peut proposer un service de singularisation à tous les fournisseurs de service et à tous les dispositifs clients. Ce service peut être mis en œuvre à la demande, ou suite à l'établissement d'un contrat entre le fournisseur de service qui souhaite utiliser le service de singularisation. Ainsi, avantageusement, des terminaux clients qui ne pouvaient pas bénéficier du service car n'ayant pas le niveau de sécurité requis par le service, peuvent élever leur niveau de sécurité et ainsi mettre en œuvre le service. Ce service peut également être mis en œuvre lors de l'achat du dispositif client ou lors de la fabrication du dispositif client.
[0101] L'opérateur d'infrastructure demande donc au service de singularisation une ou plusieurs fonctions de sécurité G pour chacun des dispositifs clients, requête REQ_2. Ceci peut être fait, comme mentionné précédemment, suite à une demande du dispositif client mais plus généralement automatiquement par l'opérateur d'infrastructure, par exemple lors de la connexion dudit dispositif client au réseau. Le service de singularisation peut générer une fonction de sécurité comme décrit en référence à la figure 2. La ou les fonctions de sécurité G ou les paramètres permettant de créer ou déterminer ou obtenir cette fonction de sécurité ou cette pluralité de fonctions de sécurité G, sont transmis par le dispositif de singularisation à l'opérateur lors dans un message REP_2. L'opérateur d'infrastructure transmet aux dispositifs clients les informations relatives à cette ou ces premières fonctions de sécurité, dans un message TR_SG1. Le service de singularisation enregistre la ou les fonctions G.
[0102] Outre la au moins une fonction de sécurité déterminée pour chaque dispositif client, le service de singularisation peut déterminer une ou plusieurs fonction de sécurité singularisées V aptes à collaborer avec la ou les fonctions de sécurité transmises au dispositif client. Par collaborer on peut entendre, décoder des données générées par la au moins une première fonction de sécurité ou coder des données destinées à la au moins une première fonction de sécurité. Le service de singularisation enregistre la ou les fonctions V. Autrement dit, la première fonction de sécurité et la seconde fonction de sécurité collaborent ensemble pour coder, décoder ou vérifier le service de sécurité à sécuriser entre le dispositif client et le fournisseur de services lors de la mise en œuvre du service.
[0103] L'opérateur d'infrastructure transmet au fournisseur de services la ou les fonctions de sécurité singularisées V lui permettant de collaborer avec les fonctions G dans le message TR_SG2. Outre les informations relatives aux fonctions de sécurité singularisées V, l'opérateur d'infrastructure peut transmettre un identifiant du dispositif client à qui la fonction G est transmise. Cet identifiant peut être un identifiant, différent de ou identique à, l'identifiant que l'opérateur d'infrastructure utilise pour communiquer ou identifier le terminal client dans le réseau. Cet identifiant peut être un identifiant généré pour les communications mises en œuvre entre le fournisseur de service et le terminal client lors de la mise en œuvre du service. Cet identifiant peut également être un ensemble de données permettant d'identifier le dispositif utilisateur et le composant, par exemple une adresse IP, un identifiant d'application tel l'AID, identifiant normalisé des applications pouvant être installées sur une carte à puce (AID, acronyme anglais de « application identifier »).
[0104] Comme mentionné précédemment, les informations relatives à ces fonctions de sécurité peuvent être transmises
- sous la forme de code logiciel de la fonction,
- sous la forme d'un ensemble d'informations permettant au dispositif client et au fournisseur de service de construire la fonction, l'ensemble d'informations pouvant comprendre :
- un identifiant de la fonction de sécurité transmise,
- une liste LBA,
- un accès sécurisé à un serveur comprenant le code de la fonction de sécurité transmise.
[0105] On peut noter que la forme sous laquelle les informations transmises au dispositif client relatives à cette ou ces premières fonctions de sécurité dans le message TR_SG1 peut être différente de la forme sous laquelle les informations transmises au fournisseur de service client relatives à cette ou ces secondes fonctions de sécurité, dans le message TR_SG2.
[0106] Optionnellement, l'opérateur d'infrastructure peut transmettre au dispositif client un message lui donnant des droits d'utilisation du service de singularisation, dans le message OPEN. Ce message peut par exemple être transmis suite à une requête d'utilisation, par exemple la requête REQ_1, ou suite à une souscription au service de singularisation faisant elle-même suite à une demande de service au fournisseur de services. L'opérateur d'infrastructure peut par exemple distribuer au fournisseur de service un jeton pouvant être vérifié par l'équipement utilisateur et manifestant le droit de consommer la fonction singularisée II est effectivement envisagé que les étapes de la figure 3 comprennent, préalablement aux étapes indiquées sur la figure 3, une ou plusieurs étapes comprenant :
- une demande du dispositif client au fournisseur de service d'une mise en œuvre (ou utilisation) d'un service,
- une réponse dudit fournisseur de service indiquant audit terminal qu'il ne possède pas le niveau de sécurité requis pour la mise en œuvre du service demandé ou - une réponse dudit fournisseur de service indiquant audit terminal qu'il doit demander à l'opérateur d'infrastructure une activation du service de singularisation pour mettre en œuvre l'application demandée.
[0107] Des étapes d'activation ECH_1 et ECH_2 peuvent être mises en œuvre permettant l'utilisation de la fonction singularisée G et de la fonction inverse V. Les étapes d'activation ECH_1 et ECH_2 peuvent consister en la réalisation d'un premier échange réussi entre le fournisseur de services et le dispositif client. Elles peuvent être faites dans un ordre différent de ce qui est illustré sur la figure 3 (ECH_2 avant ECH_1). Cette activation peut utiliser un mécanisme de type « challenge-response ». Le fournisseur de services peut créer un défi donné dont il connait la réponse attendue. Il transmet ce défi, la fonction singularisée est appliquée sur ce message de défi et renvoie une réponse que le fournisseur de services vérifie. Si la vérification montre que la réponse est bien la réponse attendue, alors le service est activé.
[0108] Dans certains modes de réalisation, le service de singularisation détermine deux fonctions singularisées G1 et V2 pour le dispositif client et G2 et VI pour le fournisseur de service. Avantageusement, ceci permet de renforcer la sécurité en brouillant différemment les messages allant du terminal client vers le fournisseur de services et les messages allant du fournisseur de services vers le terminal client.
[0109] Avantageusement, les fonctions G et V sont des bijections et peuvent être utilisées en miroir, c'est-à-dire que V peut être utilisé pour chiffrer ou crypter ou brouiller et G pour déchiffrer, décrypter ou débrouiller.
[0110] Les fonctions G et V peuvent être des fonctions de sécurité en elles-mêmes, peuvent être des fonctions de brouillage ajoutées avant une fonction de sécurité et/ou après une fonction de sécurité.
[OUI] Ainsi, selon certains modes de réalisation, G et V comprennent une ou plusieurs fonctions de brouillage et une fonction brouillée par celle ou ces fonctions de brouillage, la fonction pouvant être existante dans le dispositif.
[0112] Selon certains modes de réalisation, G et V peuvent être des fonctions de sécurité totalement créées par le service de singularisation.
[0113] La figure 4 représente un second mode de réalisation d'une mise en œuvre d'un service de déploiement d'une fonction de sécurité. Elle représente les échanges entre les dispositifs du système. [0114] Les messages REQ_1, REQ_2, REP_2, TR_SG1, TR_SG2 peuvent être identiques à ceux décrits en regard de la figure 3. Ainsi, une fois la ou les fonctions G et V déployées, le fournisseur de service souhaiterait une singularisation ou personnalisation supplémentaire de son service, à savoir une singularisation dédiée. Il demande à cet effet, une fonction de singularisation par service ou pour l'ensemble de ses services. Cette singularisation ou personnalisation est combinée avec la fonction de singularisation liée au composant et décrite précédemment. Ceci a pour avantage de renforcer davantage la sécurisation des services. Selon la figure 3, une singularisation différente est dédiée à chaque dispositif client qui utilise les services d'un fournisseur de service. Selon la figure 4 :
- Un dispositif client A qui utilise un service B1 d'un fournisseur de service FS1 peut bénéficier d'une fonction singularisée différente que lorsqu'il utilise un service B2 d'un fournisseur de service FS2, ou
- Un dispositif client A qui utilise un service SI d'un fournisseur de service FS1 peut bénéficier d'une fonction singularisée différente que lorsqu'il utilise un service SI' du même fournisseur de service FS1.
[0115] Le fournisseur de services transmet une requête REQ_3 de demande de fonction sécurisée dédiée, pour lui.
[0116] Selon certains modes de réalisation, cette demande de fonction sécurisée dédiée peut être dédiée à un ou à plusieurs, voire tous, les services proposés par le fournisseur de services. Ainsi, le fournisseur de services peut transmettre une requête REQ_3 dédiée pour chacun de ses services, il peut ainsi transférer autant de requêtes que de services qu'il propose. Il peut également transmettre une requête REQ_3 pour l'ensemble de ses services.
[0117] L'opérateur d'infrastructure transmet une demande de singularisation, pour le fournisseur de services ou pour un service particulier du fournisseur de service, au service de singularisation. Le service de singularisation détermine alors une troisième fonction de singularisation G' et une quatrième fonction de singularisation V'. Le service de singularisation enregistre les fonctions G' et V'.
[0118] La troisième fonction de singularisation G' est transmise au dispositif, message TR_SG3 et la quatrième fonction de singularisation V' est transmise au fournisseur de services, message TR_SG4. [0119] Les messages TR_SG3 et TR_SG4 peuvent comprendre la quatrième fonction de singularisation sous la forme :
- de code logiciel de la fonction,
- d'un ensemble d'informations permettant audispositif client et au fournisseur de service de construire la fonction, ledit ensemble d'informations pouvant comprendre :
- un identifiant de la fonction de sécurité transmise,
- une liste LBA,
- un accès sécurisé à un serveur comprenant le code de la fonction de sécurité transmise.
[0120] Ainsi, le fournisseur de services et le dispositif client disposent à la fois de fonctions de singularisation propres au dispositif client, G et G' et propres au fournisseur de services, V et V'. Les deux fonctions sont combinées pour fournir une nouvelle fonction de sécurité singularisée. Les deux fonctions G et G' peuvent être combinées simplement en les appliquant l'une après l'autre (la fonction G est appliquée sur le résultat de la fonction G', ou inversement) et de même pour les fonctions V et V', pour rendre possible le codage et le décodage (ou chiffrement/déchiffrement).
[0121] On peut ainsi avoir comme fonction de sécurité :
[0122] [MATH. 1] V" = VoV' ou V" = VoV
[0123] [MATH. 2] G" = GoG' OU G" = GoG'
[0124] Comme mentionné précédemment, lorsque le composant ou le dispositif client ne dispose pas des capacités fonctionnelles suffisantes pour garantir le niveau de sécurité, alors la fonction de sécurité peut être distribuée sur plusieurs entités sur un chemin entre le dispositif client et le fournisseur de services, respectant des conditions préétablies par l'opérateur d'infrastructure et le fournisseur de services. Selon certains modes de réalisation, on peut alors envisager que les fonctions G et G' sont distribuées, l'une sur le dispositif client, G par exemple et l'autre, G', sur une passerelle située entre le dispositif client et le fournisseur de services. Dans ce mode de réalisation, les capacités fonctionnelles du dispositif client ne sont pas suffisantes pour implémenter le niveau de sécurité à garantir mais suffisantes pour implémenter une fonction G dont le niveau de sécurité est inférieur. Le niveau de sécurité à garantir, que garantit la combinaison des fonctions G et G' est alors garantie en distribuant G et G', si la passerelle 'accès a les capacités fonctionnelles pour implémenter la fonction G'.
[0125] Suite au déploiement des fonctions de sécurité au dispositif et au fournisseur, l'opérateur d'infrastructure peut transmettre au dispositif client un message lui donnant des droits d'utilisation du service de singularisation, dans le message OPEN.
[0126] Les étapes d'activation ECH_1 et ECH_2 peuvent être mises en œuvre permettant l'utilisation de la fonction singularisée G et de la fonction inverse V. Les étapes d'activation ECH_1 et ECH_2 peuvent consister en la réalisation d'un premier échange réussi entre le fournisseur de services et le dispositif client. Elles peuvent être faites dans un ordre différent de ce qui est illustré sur la figure 3 (ECH_2 avant ECH_1). Cette activation peut utiliser un mécanisme de type « challenge-response ». Le fournisseur de services peut créer un défi donné dont il connait la réponse attendue. Il transmet ce défi, la fonction singularisée est appliquée sur ce message de défi et renvoie une réponse que le fournisseur de services vérifie. Si la vérification montre que la réponse est bien la réponse attendue, alors le service est activé.
[0127] La figure 5 représente un troisième mode de réalisation d'une mise en œuvre d'un service de déploiement d'une fonction de sécurité. Elle représente les échanges entre les dispositifs du système.
[0128] Dans ce mode de réalisation, l'opérateur d'infrastructure demande au service de singularisation plusieurs fonctions de sécurité EG pour chacun des dispositifs clients, requête REQ_2'. Cette requête peut être identique à la requête REQ_2 dans laquelle l'opérateur d'infrastructure spécifie qu'il demande plusieurs fonctions de sécurité pour un seul terminal client. Cette pluralité de fonctions de sécurité EG est un ensemble de fonctions de sécurité paramétrables.
[0129] Outre l'ensemble de fonctions de sécurité déterminées pour chaque dispositif client, le service de singularisation peut déterminer un ensemble de fonctions de sécurité singularisées EV aptes à collaborer avec la ou les fonctions de sécurité transmises au dispositif client. Par collaborer on peut entendre, décoder, déchiffrer, débrouiller des données générées par la au moins une première fonction de sécurité ou coder, chiffrer, brouiller des données destinées à la au moins une première fonction de sécurité. Ces ensembles de fonctions de sécurité EG et EV sont enregistrées dans le service de singularisation. [0130] L'ensemble de fonctions de sécurité singularisées EG est transmis au dispositif client dans un message TR_SEG.
[0131] Le fournisseur de service transmet une requête REQ_PERS de demande de fonction sécurisée dédiée, pour lui ou pour l'un de ses services.
[0132] Selon certains modes de réalisation, cette demande de fonction sécurisée dédiée peut être dédiée à un ou à plusieurs, voire tous les services proposés par le fournisseur de services. Ainsi, le fournisseur de services peut transmettre une requête REQ_PERS dédiée et pour chacun de ses services, il peut ainsi transférer autant de requêtes que de services qu'il propose. Il peut également transmettre une requête REQ_PERS pour l'ensemble de ses services.
[0133] L'opérateur d'infrastructure transmet une demande de singularisation pour le fournisseur de services, ou pour un service particulier du fournisseur de service, au service de singularisation, REQ_RAF. Le service de singularisation détermine alors les paramètres PG' permettant de générer une fonction de sécurité G' au dispositif client pour l'utilisation du service ou pour le fournisseur de services. Cette fonction de sécurité est générée à partir de l'ensemble de fonctions EG. Le service de singularisation génère la fonction de sécurité V' correspondante apte à collaborer avec la fonction G', comme expliqué précédemment pour les fonctions G' et V' (ou G et V) à partir de l'ensemble de fonctions EV.
[0134] Le service de singularisation enregistre également les paramètres PG' et la fonction V'.
[0135] Le service de singularisation transmet, à l'opérateur d'infrastructure, la fonction V' dans un message TR_V' et la fonction G' dans un message TR_G'.
[0136] L'opérateur d'infrastructure transmet les fonctions G' et V' respectivement au dispositif client et au fournisseur de service dans un message respectif TR2_G' et TR2_V'.
[0137] Le message TR2_G' peut comprendre la fonction de singularisation sous la forme :
- du code logiciel de G',
- de spécifications permettant au fournisseur de services de reconstituer G',
- d'un accès sécurisé à un serveur comprenant le code de G'. Tl
[0138] Le message TR2_V' peut comprendre la fonction de singularisation sous la forme :
- du code logiciel de V',
- de spécifications permettant au fournisseur de services de reconstituer V',
- d'un accès sécurisé à un serveur comprenant le code de V'.
[0139] Optionnellement, l'opérateur d'infrastructure peut transmettre au dispositif client un message lui donnant des droits d'utilisation du service de singularisation, dans le message OPEN.
[0140] Des étapes d'activation ECH_1 et ECH_2 peuvent être mises en œuvre permettant l'utilisation de la fonction singularisée G' et de la fonction inverse V'.
[0141] Les étapes d'activation ECH_1 et ECH_2 peuvent consister en la réalisation d'un premier échange réussi entre le fournisseur de services et le dispositif client. Elles peuvent être faites dans un ordre différent de ce qui est illustré sur la figure 3 (ECH_2 avant ECH_1). Cette activation peut utiliser un mécanisme de type « challenge-response ». Le fournisseur de services peut créer un défi donné dont il connait la réponse attendue. Il transmet ce défi, la fonction singularisée est appliquée sur ce message de défi et renvoie une réponse que le fournisseur de services vérifie. Si la vérification montre que la réponse est bien la réponse attendue, alors le service est activé.
[0142] Dans les modes de réalisation précédents, il est envisagé une étape optionnelle dans laquelle le fournisseur de service peut transmettre à l'opérateur d'infrastructure un niveau de sécurité requis par un ou plusieurs de ses services, par exemple sous la forme d'un contrat. Le contrat peut comprendre des indications relatives aux niveaux de sécurité requis pour les services ou applications mais aussi la manière dont les fonctions de singularisations duales sont mises à disposition du fournisseur de service , soit par le biais d'un serveur fourni par l'opérateur d'infrastructure que le fournisseur de services peut interroger à travers une interface et sans forcément avoir accès au code, soit par la transmission ou le déploiement d'un code. Le contrat peut également fixer la manière dont la fonction singularisée est déployée sur le composant et où de potentielles fonctions G' ou G" peuvent être déployées. Le contrat peut notamment également préciser ce qui se passe lorsque les capacités fonctionnelles du dispositif ne sont pas suffisantes pour garantir le niveau de service requis, comme indiqué précédemment. Le service peut préciser qu'il souhaite soit : - demander au fournisseur de service de diminuer le niveau de sécurité requis,
- ne pas autoriser le dispositif client à utiliser le service demandé,
- distribuer la fonction de service singularisée, en partie sur le dispositif client, en lui fournissant une fonction de service singularisée compatible avec ses capacités fonctionnelles et en partie sur un autre dispositif situé entre le dispositif client et le fournisseur de service, par exemple une passerelle comme les passerelles 120, 130 ou 140, les deux fonctions singularisées permettant en combinaison de garantir le niveau de sécurité requis.
[0143] Selon certains modes de réalisation, les procédés décrits précédemment et leurs variantes telles que décrites sont mis en œuvre sous la forme de programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon les modes de réalisation de l'invention lorsque ledit programme est exécuté par un ordinateur. Selon certains modes de réalisation, ces programmes sont enregistrés sur un support d'enregistrement lisible par un ordinateur.
[0144] Tout au long de la description, par le terme « obtenir » on peut comprendre déterminer, créer, ou recevoir.
[0145] La présente invention concerne aussi un procédé de déploiement d’une fonction de sécurité pour au moins un dispositif client connecté à un réseau de communication, ladite fonction de sécurité étant destinée à sécuriser un service mis en œuvre dans ledit dispositif client, le procédé étant mis en œuvre par un dispositif d’un opérateur d’infrastructure dudit réseau de communication, et comprenant :
- la génération d’au moins une première fonction de sécurité pour ledit au moins un dispositif client à partir d’un niveau de sécurité requis par ledit service, et de capacités fonctionnelles dudit dispositif client,
- le déploiement de ladite au moins une première fonction de sécurité dans ledit au moins un dispositif client pour garantir la mise en œuvre dudit service.
[0146] Selon certains modes de réalisation, le procédé comprend :
- la génération d’au moins une seconde fonction de sécurité, ladite première fonction de sécurité et ladite seconde fonction de sécurité collaborant ensemble pour coder, décoder ou vérifier des données du service à sécuriser entre ledit dispositif client et un fournisseur de services fournissant ledit service lors de la mise en œuvre du service
- le déploiement de ladite au moins une seconde fonction de sécurité dans ledit service sur un serveur dudit fournisseur de service. [0147] Selon certains modes de réalisation, le procédé comprend :
- une requête par un fournisseur de service d'obtention d'une fonction de sécurité dédiée à l'un ou l'ensemble des services qu'il délivre,
- la génération d'une troisième fonction de sécurité (G') pour ledit dispositif client,
- la génération d'une quatrième fonction de sécurité (V') pour ledit fournisseur de service,
- lesdites première et troisième fonctions de sécurité étant aptes à coder, décoder ou vérifier, dans ledit dispositif client, en combinaison, les services dudit fournisseur de service ayant transmis la requête d'obtention d'une fonction de sécurité dédiée et lesdites seconde et quatrième fonctions de sécurité étant aptes à décoder, coder ou vérifier, dans ledit fournisseur de service, en combinaison, des données reçues du service mis en œuvre dans ledit dispositif.
[0148] Selon certains modes de réalisation, le procédé comprend :
- la génération d'une pluralité de premières fonctions de sécurité (EG) pour ledit au moins un dispositif à partir dudit niveau de sécurité, et desdites capacités fonctionnelles,
- le déploiement de ladite pluralité de premières fonctions de sécurité dans ledit au moins un dispositif,
- l'obtention d'une pluralité de secondes fonctions de sécurité (EV) aptes à décoder, coder ou déchiffrer des données codées, décodées ou déchiffrer par lesdites premières fonctions,
- une requête par un fournisseur de service de paramétrage desdites pluralité de premières et secondes fonctions de sécurité,
- l'obtention d'une pluralité de paramètres (PG') pour
- obtenir une troisième fonction (G') de sécurité à partir de ladite pluralité de premières fonctions de sécurité et
- obtenir une quatrième fonction (V') de sécurité à partir de ladite pluralité de secondes fonctions de sécurité,
- le déploiement de ladite troisième fonction (G') de sécurité dans ledit dispositif,
- le déploiement de ladite quatrième fonction (V') de sécurité dans ledit service chez ledit fournisseur de service ayant transmis la requête de paramétrage.
[0149] Selon certains modes de réalisation, le déploiement de la quatrième fonction de sécurité comprend :
- la transmission d'un identifiant dudit dispositif audit fournisseur de service, - la transmission de ladite quatrième fonction (V') de sécurité en tant que l'un ou l'autre parmi :
- du code logiciel codant ladite quatrième fonction de sécurité,
- des paramètres de la quatrième fonction de sécurité permettant au fournisseur de service de créer ladite quatrième fonction de sécurité,
- un accès sécurisé à un serveur dudit réseau de communication comprenant le code de ladite quatrième fonction de sécurité.
[0150] Selon certains modes de réalisation, le procédé comprend :
- la réception, d'un fournisseur de services, d'une requête de demande de singularisation d'une fonction de sécurité destinée à être utilisée par ledit service dudit fournisseur de service et ledit dispositif, ladite fonction de sécurité étant dédiée pour ledit dispositif lors de l'utilisation dudit service, ladite requête comprenant ledit niveau de sécurité à garantir.
[0151] Selon certains modes de réalisation lesdites fonctions de sécurité sont choisies parmi l'une ou l'autre ou une combinaison
- d'une fonction de chiffrement,
- d'une fonction d'authentification,
- d'une fonction d'intégrité.
[0152] Selon certains modes de réalisation, la génération d'au moins une première fonction de sécurité (G) pour ledit au moins un dispositif client à partir d'un niveau de sécurité requis par ledit service, et de capacités fonctionnelles dudit dispositif client, comprend :
- la détermination, d'un ensemble de familles de fonctions de sécurité paramétrables,
- l'enregistrement, de l'ensemble des familles de fonctions de sécurité paramétrables,
- la génération de ladite première fonction de sécurité, à partir d'au moins une desdites fonctions de sécurité paramétrables enregistrées, à partir du niveau de sécurité requis par ledit service et de paramètres de capacité fonctionnelle dudit dispositif client et
- la génération de ladite seconde fonction de sécurité, à partir d'au moins une desdites fonctions de sécurité paramétrables enregistrées, à partir du niveau de sécurité requis par ledit service et de paramètres de capacité fonctionnelle dudit dispositif client.
[0153] Selon certains modes de réalisation ladite première fonction de sécurité, respectivement ladite seconde fonction de sécurité, est obtenue par : - la sélection d'une ou plusieurs fonctions parmi une ou plusieurs familles des fonctions de sécurité paramétrables, la sélection étant faite en fonction du niveau de sécurité, à garantir et des capacités fonctionnelles dudit terminal client,
- le paramétrage de la au moins une desdites fonctions de sécurité paramétrables sélectionnées afin d'obtenir ladite première fonction de sécurité, respectivement ladite seconde fonction de sécurité.
[0154] Selon certains modes de réalisation, ladite fonction de sécurité est obtenue en composant plusieurs fonctions mathématiques sur les entrées et ou sorties d'une fonction de sécurité afin de les brouiller et de créer une variation fonctionnelle de ladite fonction de sécurité.
[0155] Selon certains modes de réalisation, ledit niveau de sécurité est obtenu dudit fournisseur de service.
[0156] L'invention concerne également un dispositif de déploiement d’une fonction de sécurité pour au moins un dispositif client connecté au dispositif à travers un réseau de communication, ladite fonction de sécurité étant destinée à sécuriser un service mis en œuvre dans ledit dispositif client, le dispositif de déploiement comprenant un ou plusieurs processeurs configurés ensemble ou séparément pour :
- générer au moins une première fonction de sécurité (G) pour ledit au moins un dispositif client à partir d’un niveau de sécurité requis par ledit service, et de capacités fonctionnelles dudit dispositif client,
- déployer ladite au moins une première fonction de sécurité dans ledit au moins un dispositif client pour garantir la mise en œuvre dudit service.

Claims

Revendications
[Revendication 1] Procédé de génération d'une première fonction de sécurité (G), mis en œuvre dans un dispositif réseau comprenant une pluralité de dispositifs clients (1201, 1202, 1300, 1400, 1500), ladite fonction de sécurité (G) étant destinée à sécuriser un service mis en œuvre dans l'un au moins desdits dispositifs clients, le procédé comprenant,
- l'obtention (E3), d'un ensemble de familles de fonctions de sécurité,
- l'enregistrement (E4), de l'ensemble des familles de fonctions de sécurité,
- la réception (E6), d'un dispositif client, d'une requête de demande de sécurisation d'un service afin de garantir un niveau de sécurité associé audit service,
- l'obtention (E8) de ladite première fonction de sécurité (G), à partir d'au moins une desdites fonctions de sécurité enregistrées, en fonction dudit niveau de sécurité à garantir
-la transmission (E9) de ladite première fonction de sécurité (G) audit dispositif client.
[Revendication 2] Procédé de sécurisation d'un service utilisé dans un dispositif client dans un réseau, comprenant
- la transmission (E6), à un opérateur dudit réseau, d'une requête de demande de première fonction de sécurité (G) pour garantir un niveau de sécurité lors de la mise en œuvre dudit service,
- la réception (E9) de la première fonction de sécurité (G) déterminée (E8) en fonction d'au moins un niveau de sécurité à garantir pour mettre en œuvre le service.
[Revendication 3] Procédé selon l'une des revendication 1 ou 2 dans lequel ladite première fonction de sécurité (G) est obtenue par :
- la sélection d'une ou plusieurs fonctions parmi une ou plusieurs familles des fonctions de sécurité, la sélection étant faite en fonction du niveau de sécurité à garantir,
- le paramétrage de la au moins une desdites fonctions de sécurité sélectionnées afin d'obtenir ladite première fonction de sécurité.
[Revendication 4] Procédé selon l'une des revendications précédentes comprenant, préalablement à la requête de demande de fonction de sécurité, l'installation dans ledit dispositif client d'un service fourni par un fournisseur de services, ledit service étant associé audit niveau de sécurité à garantir, ledit niveau de sécurité étant supérieur à un niveau de sécurité disponible dans ledit dispositif client.
[Revendication 5] Procédé selon l'une des revendications précédentes dans lequel ladite première fonction de sécurité (G), est obtenue à partir d'au moins une desdites fonctions de sécurité enregistrées, en fonction dudit niveau de sécurité à garantir et de paramètres de capacité fonctionnelle dudit dispositif client.
[Revendication 6] Procédé selon l'une des revendications précédentes dans lequel ladite fonction de sécurité est obtenue par le paramétrage d'au moins une desdites fonctions de sécurité enregistrées et/ou par une combinaison d'une pluralité de fonctions de sécurité enregistrées, de manière à être unique pour chaque dispositif client.
[Revendication 7] Procédé selon l'une des revendications précédentes dans lequel
- ladite première fonction de sécurité est obtenue par
- la combinaison d'au moins deux fonctions de sécurité sélectionnées dans au moins une famille de fonctions satisfaisant le niveau de sécurité à garantir et les capacités fonctionnelles du dispositif client, et/ou
- le paramétrage de ladite combinaison de fonctions sélectionnées.
[Revendication 8] Procédé selon l'une des revendications précédentes comprenant
- la transmission d'une seconde fonction de sécurité (V) audit fournisseur de service, ladite première fonction et ladite seconde fonction de sécurité collaborant ensemble pour coder ou décoder les communications entre ledit dispositif client et ledit fournisseur de services lors de la mise en œuvre dudit service.
[Revendication 9] Procédé selon la revendication 8 comprenant :
- la transmission d'un identifiant dudit dispositif client audit fournisseur de services permettant une association de ladite seconde fonction de sécurité audit dispositif client.
[Revendication 10] Procédé selon l'une des revendications 8 ou 9 dans lequel lesdites première et seconde fonctions de sécurité sont transmises respectivement audit dispositif client et audit fournisseur de services
- sous la forme de code logiciel de ladite fonction,
- sous la forme d'un ensemble d'informations permettant audit dispositif client et audit fournisseur de service de construire ladite fonction, ledit ensemble d'informations comprenant:
- un identifiant de ladite fonction de sécurité transmise, - une liste comprenant des fonctions de brouillage utilisées pour lesdites premières et secondes fonctions de sécurité, et l'ordre dans lequel elles sont utilisées.
[Revendication 11] Procédé selon l'une des revendications 1 ou 2 dans lequel ladite fonction de sécurité est obtenue en composant plusieurs fonctions mathématiques sur les entrées et ou sorties d'une fonction de sécurité afin de les brouiller et de créer une variation fonctionnelle de ladite fonction de sécurité.
[Revendication 12] Procédé selon l'une des revendications 1, 3 à 10 dans lequel une famille de fonctions de sécurité comprend un ensemble de fonctions cryptographiques de complexité et de structure identiques, une famille pouvant être choisie parmi:
- une famille de permutations d'octets à octets ou
- une famille constituée d'un tour d'un schéma de Feistel complexifiée par un algorithme de hachage.
- Une famille constituée des opérations arithmétiques modulo 65537.
[Revendication 13] Programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon l'une des revendications 1 à 12 lorsque ledit programme est exécuté par un ordinateur.
[Revendication 14] Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon l'une des revendications 1 à 12.
[Revendication 15] Terminal dans un réseau de communication, comprenant un opérateur d'infrastructure, ledit terminal comprenant un ou plusieurs processeurs configurés ensemble ou séparément pour:
- transmettre, à un opérateur dudit réseau, une requête de demande de première fonction de sécurité pour garantir un niveau de sécurité lors de la mise en œuvre d'un service,
- recevoir la première fonction de sécurité déterminée en fonction dudit niveau de sécurité à garantir pour mettre en œuvre le service.
EP24718485.6A 2023-04-14 2024-04-11 Procédé et dispositif de génération d'une fonction de sécurité Pending EP4695939A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2303746A FR3147924A1 (fr) 2023-04-14 2023-04-14 Procédé et dispositif de génération d’une fonction de sécurité
PCT/EP2024/059908 WO2024213672A1 (fr) 2023-04-14 2024-04-11 Procédé et dispositif de génération d'une fonction de sécurité

Publications (1)

Publication Number Publication Date
EP4695939A1 true EP4695939A1 (fr) 2026-02-18

Family

ID=87974453

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24718485.6A Pending EP4695939A1 (fr) 2023-04-14 2024-04-11 Procédé et dispositif de génération d'une fonction de sécurité

Country Status (3)

Country Link
EP (1) EP4695939A1 (fr)
FR (1) FR3147924A1 (fr)
WO (1) WO2024213672A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10033703B1 (en) * 2015-06-16 2018-07-24 Amazon Technologies, Inc. Pluggable cipher suite negotiation

Also Published As

Publication number Publication date
FR3147924A1 (fr) 2024-10-18
WO2024213672A1 (fr) 2024-10-17

Similar Documents

Publication Publication Date Title
EP3568794B1 (fr) Procédés et systèmes pour l&#39;exécution de contrats intelligents dans des environnements sécurisés
EP1683388B1 (fr) Methode de gestion de la sécurité d&#39;applications avec un module de sécurité
EP1687953A2 (fr) Méthode d&#39;authentification d&#39;applications
FR2874295A1 (fr) Procede d&#39;authentification securisee pour la mise en oeuvre de services sur un reseau de transmission de donnees
FR3076423A1 (fr) Procede et systeme d&#39;activation cryptographique d&#39;une pluralite d&#39;equipements
EP3189485A1 (fr) Gestion de ticket électronique
FR3007920A1 (fr) Procede de changement de cle d&#39;authentification
FR3095708A1 (fr) Procédé de transmission securisée de données
EP3238200A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l&#39;intégrité de données mémorisées dans une telle entité électronique sécurisée
EP3136283B1 (fr) Dispositif et procédé sécurisation de commandes échangées entre un terminal et circuit intégré
FR3111038A1 (fr) Traitements cryptographiques pour chiffrer ou déchiffrer des données
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
EP1867189A1 (fr) Communication securisee entre un dispositif de traitement de donnees et un module de securite
EP4695939A1 (fr) Procédé et dispositif de génération d&#39;une fonction de sécurité
WO2024213673A1 (fr) Procédé et dispositif de déploiement d&#39;une fonction de sécurité pour au moins un dispositif client
CA3240055A1 (fr) Procede de controle d&#39;acces a une zone a securiser et procede d&#39;initialisation associe
EP1413158B1 (fr) Procede d&#39;acces a un service specifique propose par un operateur virtuel et carte a puce d&#39;un dispositif correspondant
WO2021123542A1 (fr) Procede d&#39;obtention d&#39;une commande relative a un profil d&#39;acces reseau d&#39;un module de securite de type euicc
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d&#39;un utilisateur et un point d&#39;acceptation
EP3912065B1 (fr) Autorisation du chargement d&#39;une application dans un élément de sécurité
FR3128089A1 (fr) Procédé et dispositif de sélection d’une station de base
FR3161085A1 (fr) Procédé et dispositif de communication sécurisé utilisant un identifiant dérivé de manière déterministe
FR3066346A1 (fr) Procede de securisation en vue d&#39;un appairage hors bande dans la bande
EP3829204A1 (fr) Procédé et système de contrôle d&#39;accès à des objets connectés, procédés associés de distribution et de réception de données, et produit programme d&#39;ordinateur associé
WO2010133459A1 (fr) Procede de chiffrement de parties particulieres d&#39; un document pour les utilisateurs privileges

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: 20251020

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 ME MK MT NL NO PL PT RO RS SE SI SK SM TR