Brevet FR3147924A1 — publié le 20241018

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. Figure pour l’abrégé : Fig. 1. Procédé et dispositif de génération d’une fonction de sécurité 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. 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. 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. 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. 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. 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. 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é. 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. 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. 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. 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. 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. 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é. 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. 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. 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. 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. La représente un mode de réalisation d’un système mettant en œuvre des modes de réalisation de la présente invention. La représente un mode de réalisation d’un procédé selon la présente invention. La 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é, La 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é, La 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é. 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. 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 . 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 IoT, 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é. 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. La 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. Lors de l’étape E1, 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. 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… Cette étape E1 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 eIDAS 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é. L’opérateur d’infrastructure obtient un ensemble de familles de fonctions de sécurité paramétrables, étape E3. 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 ( ℤ/ 65537 ℤ,+,×). 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. 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. Ces étapes E1 à 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é. 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 , 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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é. 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. 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. 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. 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. Une fonction de sécurité de type signature électronique peut être obtenue à partir de fonctions à base de clé secrète. 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. 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. 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. 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. 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 K1 (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. Exemples d’obtention d’une fonction singularisée 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. Chaque famille dispose de 3 codes correspondant à des fonctions de ces familles. Par exemple, la famille XOR dispose des fonctions suivantes : X1- 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 X1 mais faisant appel à une technique de développement défensif, comme l’ajout d’instructions pour brouiller les motifs de consommation électrique. La famille permutation dispose des codes suivants : P1- 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 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 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. 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. 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, P1 et X1. 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 P1, il faudra paramétrer a. 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. 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. 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. 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. 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). 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. La fonction de sécurité peut être ensuite intégrée au code du service déployé dans le terminal client. Comme mentionné précédemment la fonction peut venir sécuriser une fonction déjà existante ou peut constituer une fonction à part entière. 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. 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. 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. 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. 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. 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. 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é. 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. 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 La 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. 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. 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 . 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. 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 . 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. 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. 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 »). 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. 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. 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 Il est effectivement envisagé que les étapes de la comprennent, préalablement aux étapes indiquées sur la , 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. 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 (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é. 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 V1 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. 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. 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é. 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. Selon certains modes de réalisation, G et V peuvent être des fonctions de sécurité totalement créées par le service de singularisation. La 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. Les messages REQ_1, REQ_2, REP_2, TR_SG1, TR_SG2 peuvent être identiques à ceux décrits en regard de la . 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 , une singularisation différente est dédiée à chaque dispositif client qui utilise les services d’un fournisseur de service. Selon la : - 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 S1 d’un fournisseur de service FS1 peut bénéficier d’une fonction singularisée différente que lorsqu’il utilise un service S1’ du même fournisseur de service FS1. Le fournisseur de services transmet une requête REQ_3 de demande de fonction sécurisée dédiée, pour lui. 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. 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’. 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. 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. 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). On peut ainsi avoir comme fonction de sécurité : [MATH. 1] ou [MATH. 2] ou 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’. 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. 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 (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é. La 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. 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. 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. L’ensemble de fonctions de sécurité singularisées EG est transmis au dispositif client dans un message TR_SEG. 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. 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. 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. Le service de singularisation enregistre également les paramètres PG’ et la fonction V’. 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’. 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’. 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’. 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’. 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. 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 (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é. 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. 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. Tout au long de la description, par le terme « obtenir » on peut comprendre déterminer, créer, ou recevoir. 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. 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. 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. 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. 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é. 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. 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é. 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. 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é. 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é. Selon certains modes de réalisation, ledit niveau de sécurité est obtenu dudit fournisseur de service. 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. 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, - l’obtention (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. 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) à partir d’au moins une capacité fonctionnelle du dispositif client et du niveau de sécurité à garantir pour mettre en œuvre le service. 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é 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é. 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. 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 - le paramétrage de ladite combinaison de fonctions sélectionnées. 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. Procédé selon la revendication 6 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. Procédé selon l’une des revendications précédentes 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. 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é. Procédé selon l’une des revendications 1, 3 à 8 dans lequel 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. Programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon l’une des revendications 1 à 10 lorsque ledit programme est exécuté par un ordinateur. 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 à 10. 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.