FR3096535A1 - Procédés et dispositifs de sécurisation d’un réseau de périphérie à accès multiple - Google Patents

Abstract

Il est décrit un procédé de sécurisation d’un réseau de périphérie à accès multiple, dans lequel on prévoit un dispositif de sécurité matériel (HSMSOC) agencé pour être connecté à un module hôte (MECH) dudit réseau, et le procédé, mis en œuvre par ledit dispositif de sécurité matériel, comportant:- sur réception (S20) d’une requête de présence du module hôte (Q1) dans le réseau, vérifier si ladite requête de présence comprend une donnée représentative d’un identifiant du module hôte, et, dans ce cas, - émettre (S50) une réponse de présence (R1) à destination du module hôte (MECH) comportant une signature du dispositif de sécurité matériel. Figure de l’abrégé : Figure 5

Description

Description Titre de l'invention : Procédés et dispositifs de sécurisation d'un réseau de périphérie à accès multiple Arrière-plan de l'invention

[0001] La présente description se rapporte au domaine de la sécurisation des réseaux.

Plus précisément, des aspects de la présente description se rapportent à des procédés et des dispositifs pour sécuriser un réseau informatique de périphérie à accès multiples.

[0002] Aujourd'hui, il est attendu que les domaines de la santé, des transports, de l'énergie, de l'industrie du transport constituent des domaines majeurs d'utilisation des standards 5G en télécommunications, ces domaines étant définis à ce titre comme des « verticaux » de la 5G.

[0003] Dans ce contexte, une difficulté couramment rencontrée est de pouvoir garantir une sécurisation et une fiabilité optimale de données récoltées, enregistrées et échangées entre différents partenaires, par exemple entre un propriétaire de données et un fournisseur de services applicables à ces données.

Il convient généralement à ces partenaires de s'accorder pour utiliser des infrastructures réseau communes, les éléments constitutifs de ces infrastructures présentant un niveau de sécurisation qui est à la fois suffisant et commun pour chacun des partenaires.

100041 Par exemple, pour échanger des données confidentielles issues de capteurs localisés en un ou plusieurs sites de production, un fournisseur d'électricité peut faire appel au matériel et aux services fournis par un opérateur partenaire de télécommunications.

Typiquement, deux tels partenaires partagent un jeu commun de clés ou de signatures électroniques, distribuées dans les infrastructures utilisées pour échanger les données, ces clés ou ces signatures pouvant être vérifiées par chacun des partenaires en un instant donné.

100051 Pour ce faire, il est connu des architectures faisant intervenir des réseaux infor- matiques de périphérie à accès multiples, dits réseaux MEC (ou de « Multi-Access Edge Computing », en anglais).

Le groupe ETSI (« European Telecommunications Standards Institute », en anglais) a ainsi défini des spécifications techniques précises et relatives à des architectures réseau compatibles avec les standards de l'informatique de périphérie multi-accès.

100061 Selon ces normes, un réseau MEC fournit un environnement informatique permettant l'hébergement d'applications et de services à un niveau positionné au plus proche des niveaux « utilisateur » (« end user », en anglais), ce qui permet de stocker et de traiter des données avec un temps de réponse plus rapide.

[0007] En outre, un réseau MEC cst conçu pour être compatible avec différents typcs 2 d'accès mobiles ou fixes, ce qui lui permet d'être installé physiquement et directement dans des stations de base ou dans des infrastructures matérielles appartenant à des utilisateurs ou à des industries spécifiques.

Les données collectées ou utilisées peuvent ensuite être communiquées via un réseau supérieur et éventuellement dématérialisé.

[0008] Typiquement, un réseau MEC comporte un module spécifique, dit module hôte de réseau de périphérie à accès multiple.

Ce module fournit un moyen de stockage et de traitement des données du réseau MEC suivant des conditions de disponibilité, de fiabilité et de sécurité établies.

Ces conditions peuvent être associées à une clé ou une signature électronique correspondante, en vue de garantir la sécurisation des données.

[0009] Lorsque plusieurs utilisateurs ou partenaires échangent des données par l'intermédiaire d'un réseau MEC commun, l'architecture correspondante définit un espace d'échange et de contrôle de données conforme à ces conditions.

Dans ce cas, seules les données stockées et traitées par le module hôte conforme à ces conditions seront considérées.

[0010] Toutefois, cette approche présente plusieurs inconvénients.

[0011] Tout d'abord, cette approche nécessite de déployer un grand nombre d'éléments matériels à proximité des niveaux utilisateur, cc qui n'est pas systématiquement possible pour des raisons de coûts et de faisabilité technique.

[0012] De plus, les éléments matériels à déployer sont souvent de types et de fabricants différents, ce qui complique la possibilité de définir un niveau de sécurité et de fiabilité commun.

[0013] Ensuite, les réseaux MEC existants et leurs éléments constitutifs ne sont actuellement pas en mesure de contrôler la présence d'un module hôte de réseau de périphérie à accès multiple à l'intérieur d'un réseau MEC donné.

[0014] En outre, il n'est pas possible de sélectionner un module hôte de réseau de périphérie à accès multiple respectant un niveau de chiffrement et un niveau de signature donnés.

[0015] Les procédés existants ne permettent pas non plus de gérer ni de sélectionner un module hôte de réseau de périphérie à accès multiple de manière suffisamment fiable et sécurisée.

Le déploiement de signatures ou de clés privées correspondantes clans un tel module est également problématique, en particulier dans le cas de réseaux de grande taille.

Objet et résumé de l'invention

[0016] Afin d'améliorer la situation et de répondre à ce ou à ces inconvénients, il est proposé, de façon générale, un procédé de sécurisation d'un réseau de périphérie à accès multiple, dans lequel on prévoit un dispositif de sécurité matériel agencé pour être connecté à un module hôte dudit réseau, et le procédé, mis en oeuvre par ledit dispositif de sécurité matériel, comportant: - sur réception d'une requête de présence du module hôte dans le réseau, vérifier si 3 ladite requête de présence comprend une donnée représentative d'un identifiant du module hôte, et, dans ce cas, - émettre une réponse de présence à destination du module hôte comportant une signature du dispositif de sécurité matériel.

[0017] Dans les présentes, une signature d'un dispositif de sécurité matériel est tout type privé ou public de certificat ou de clé, compatible avec l'architecture et la configuration d'un réseau de périphérie à accès multiple.

[0018] Par exemple, pour générer une signature, un demandeur crée une paire de clés, l'une étant publique et l'autre étant privée et gardée secrète.

Une telle signature peut comprendre une demande de signature de certificat, dite demande CSR (pour « Certificatc Signing Request », en anglais), correspondant à un message envoyé depuis un demandeur vers une autorité de certification, pour requérir un certificat d'identité numérique.

Si cette requête est acceptée ultérieurement, l'autorité de certification retourne un certificat d'identité signé numériquement avec la clé privée dont dispose l'autorité de certification.

[0019] Dans les présentes, une signature contient au moins une information d'identification du demandeur ainsi qu'au moins une clé publique choisie par le demandeur.

De préférence, ladite signature ne comprend pas la clé privée correspondant à ladite clé publique, mais celle-ci reste utilisable ultérieurement pour mettre en oeuvre la signature.

[0020] Par exemple, une clé privée correspondante à une clé publique que comprend la signature est utilisable pour signer une demande CSR.

Ladite signature peut aussi être comprendre d'autres informations d'identification ou des preuves d'identité requises par l'autorité de certification.

[0021] Dans les présentes, le dispositif de sécurité matériel comprend au moins un système sur puce configuré pour mettre en oeuvre les étapes d'un procédé de sécurisation selon le procédé ou selon l'une quelconque des réalisations du procédé telles que décrites ci-après.

[0022] Dans une réalisation préférée, ladite requête de présence du module hôte dans le réseau est émise par le module hôte sur réception d'un message de test émis par un gestionnaire de sécurité et de confidentialité au module hôte.

[0023] Dans les présentes, et de manière non limitative, le message de test peut parvenir au module hôte par l'intermédiaire d'un ou de plusieurs autres éléments du réseau, par exemple par l'intermédiaire d'un gestionnaire de plateforme de périphérie à accès multiple ou d'un gestionnaire d'infrastructure de virtualisation.

[0024] Dans les présentes, le gestionnaire de sécurité et de confidentialité est agencé pour être connecté au réseau, par exemple au module hôte ou à d'autres éléments du réseau.

[0025] Dans une réalisation préférée, le procédé comporte en outre une détermination d'un niveau de sécurité du réseau en fonction de ladite réponse de présence.

[0026] Dans les présentes, ledit niveau de sécurité est, en particulier, un niveau de sécurité du module hôte.

[0027] Dans une réalisation, ladite détermination du niveau de sécurité est mise en oeuvre sur réception d'une réponse à un message de test émis par le module hôte.

[0028] Dans une réalisation alternative, la détermination du niveau de sécurité est mise en oeuvre sur réception d'une réponse à une réponse de présence émise par le dispositif dc sécurité matériel.

[0029] Dans une réalisation préférée, la requête de présence et la réponse du dispositif de sécurité matériel sont respectivement reçue et émise une pluralité de fois, respectivement en tant que challenge et réponse dans une opération itérative d'authentification du module hôte que met en oeuvre le dispositif de sécurité matériel.

[0030] Dans les présentes, un challenge et une réponse correspondante définissent ensemble une authentification challenge-réponse (aussi appelée authentification défi-réponse).

De préférence, une authentification challenge-réponse comporte une famille de protocoles dans lesquels une question (le défi) est présentée par une partie à une autre, cette autre partie étant invitée à fournir une réponse valide (la réponse) pour être authentifiée.

Une authentification comprend par exemple l'utilisation dc mots dc passe, et/ou de préférence, l'utilisation de demandes CSR et de paires clés publiques et privées correspondantes, lesdites clés éventuellement gérées par une autorité dc certification prédéfinie.

[0031] Dans une réalisation préférée, à chaque itération de l'opération itérative d'authentification du module hôte, ladite réponse est obtenue dudit challenge respectif par une signature d'un nombre prédéterminé de bits que comprend le challenge respectif au moyen d'une clé de sécurité stockée dans le dispositif de sécurité matériel.

[0032] Dans une réalisation préférée, la requête de présence est vérifiée comme comprenant une donnée représentative d'un identifiant du module hôte lorsqu'il est vérifié que ledit identifiant est compris dans une liste stockée dans une mémoire accessible au dispositif de sécurité matériel.

[0033] Dans une réalisation préférée, la requête de présence comporte au moins une donnée représentative d'un identifiant sélectionné dans le groupe : une preuve d'attachement, une information de connexion, un opérateur, un identifiant du module hôte, une information de fabrication ou encore une preuve de présence du dispositif de sécurité matériel dans le module hôte.

[0034] Dans une réalisation préférée, le procédé comporte en outre un module d'application de sécurité et de confidentialité agencé pour être connecté au module hôte et pour mettre en oeuvre au moins une signature ou une clé de sécurité.

[0035] Dans une réalisation préférée, le procédé comporte en outre, sur réception de la réponse de présence par le module hôte, une mise en oeuvre d'une action, ladite action étant choisie dans le groupe : une vérification de ladite réponse de présence, une instanciation d'un serveur virtuel dans le module hôte ; une installation d'une clé de sécurité dans le module hôte, une désignation d'un dispositif de sécurité matériel distant, une désignation d'un dispositif de sécurité matériel distant, et/ou une désignation d'un serveur virtuel d'un module hôte distant doté d'une clé de sécurité.

[0036] Dans les présentes, une vérification d'une réponse de présence comporte, par exemple, une comparaison entre une signature que comporte le dispositif de sécurité matériel et une signature que comporte le gestionnaire de sécurité et de confidentialité.

En particulier, les signatures comparées ou à comparer peuvent être des clés de sécurité.

[0037] La présente invention vise aussi un dispositif de sécurité matériel pour sécuriser un réseau de périphérie à accès multiple, ledit dispositif étant agencé pour être connecté à un module hôte dudit réseau et comportant un processeur de traitement sécurisé configure pour la mise en oeuvre du procédé selon l'une quelconque des réalisations précédentes du procédé.

[0038] La présente invention vise aussi un programme informatique comportant des ins- tructions pour la mise en oeuvre du procédé selon l'une quelconque des réalisations précédentes du procédé, lorsque ces instructions sont exécutées par un processeur d'un circuit de traitement informatique.

[0039] Dans une réalisation, ledit processeur ou ledit circuit de traitement informatique comprend le système sur puce.

[0040] La présente invention vise aussi un moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des réalisations précédentes du procédé.

[0041] Dans une réalisation, ledit moyen de stockage d'informations est un système sur puce agencé pour être intégré au dispositif de sécurité matériel.

Brève description des dessins

[0042] D'autres caractéristiques, détails et avantages apparaîtront à la lecture de la des- cription détaillée ci-après, et à l'analyse des dessins annexés, sur lesquels :

[0043] [fig.1], la figure 1 représente une vue schématique d'une architecture réseau selon une réalisation;

[0044] [fig.2], la figure 2, représente une vue schématique d'une architecture réseau selon une autre réalisation;

[0045] [fig.3], la figure 3, représente sous forme d'organigramme, des étapes d'un procédé de sécurisation d'un réseau selon une réalisation; 6 100461 Ifie.41, la figure 4, représente sous forme d'organigramme, des étapes d'un procédé de sécurisation d'un réseau selon une autre réalisation;

[0047] [fig.5], la figure 5, représente un diagramme de flux pour des étapes d'un procédé de sécurisation d'un réseau selon une réalisation; et

[0048] [fig.6], la figure 6, représente un bloc-diagramme schématique d'un circuit de traitement informatique selon une réalisation.

[0049] Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.

Description des modes de réalisation

[0050] Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments dc caractère certain.

Ils pourront donc servir à mieux faire comprendre la présente divulgation et à contribuer à sa définition, le cas échéant.

[0051] Il est maintenant fait référence à la figure I, qui représente un exemple d'architecture réseau d'informatique de périphérie multi-accès selon une réalisation.

[0052] Différentes entités fonctionnelles impliquées dans l'architecture d'un réseau MEC sont illustrées.

Ces entités fonctionnelles sont regroupées dans le réseau MEC en trois niveaux ou couches : un niveau système SL correspondant à une couche supérieure, un niveau hôte HL correspondant à une couche intermédiaire, et un niveau dc réseau NL correspondant à une couche inférieure (non représentée).

[0053] Le niveau NL fournit la connectivité de l'architecture du réseau MEC à des réseaux locaux, à des réseaux cellulaires et à des réseaux externes tels que l'Internet.

[0054] Concernant la couche intermédiaire, le niveau hôte HL comprend un module hôte du réseau de périphérie à accès multiple, dit module hôte MECH (ou « Mobile Edgc Computing [lest », en anglais).

Ce module hôte MECH permet, notamment, de fournir un moyen de stockage et de traitement d'informations.

[0055] Le module hôte MECH comprend une plateforme de périphérie à accès multiple, dite plateforme MEP (ou « Mobile Edgc Platform », en anglais), une infrastructure de virtualisation de réseau virtuel, dite infrastructure VI (ou « Virtual Nctwork Function Infrastructure », en anglais), ainsi qu'au moins une application de périphérie à accès multiple, dites application MEA (ou « Mobile Edge Applications », en anglais).

[0056] Typiquement, une application MEA s'exécute en tant que machine virtuelle sur l'infrastructure VI.

Une application MEA interagit avec la plateforme MEP via au moins un point de référence Mpl, qui est également utilisé pour la mise en oeuvre d'éventuelles procédures de support supplémentaires.

[0057] Une application MEA peut indiquer les besoins en ressources ou en services du 7 module hôte MECH, ainsi que des contraintes relatives à des latences maximales autorisées, par exemple.

[0058] L'infrastructure VI fournit des ressources de calcul, de stockage et de réseau pour des applications MEA.

L'infrastructure VI comprend en outre un plan de commutation, dit plan de données DP (ou « Data Plane », en anglais), configure pour exécuter les règles de transmission reçues par la plateforme MEP.

[0059] Le plan de données DP, qui est généralement compris dans l'infrastructure VI du module hôte MECH, permet, notamment, d'acheminer des données entre les différents services, applications et services associés à l'architecture.

[0060] La plate-forme MEP que comprend le module MECH fournit un ensemble de fonc- tionnalités de base pour exécuter des applications sur une entité hôte et pour permettre à ces applications d'utiliser les services associés.

[0061] Ces fonctionnalités sont utilisées, par exemple, pour organiser le routage de données entre applications, services et réseaux interagissant avec le réseau MEC ou dans celui-ci.

[0062] Le niveau hôte HL comprend en outre d'autres entités externes au module hôte MECH, telles qu'un gestionnaire de plateforme de périphérie à accès multiple de niveau hôte, dit gestionnaire MEPM (ou « Mobile Edgc Platform Manager », en anglais), ou encore un gestionnaire d'infrastructure de virtualisation, dit gestionnaire VIM (ou « Virtual Infrastructure Manager », en anglais).

[0063] Le gestionnaire VIM est relié à l'interface VI par le point de référence Mm7, ce qui permet de gérer les ressources virtualisées du module hôte MECH et/ou pour gérer d'éventuelles instanciations.

Il est également utilisé pour conserver des informations sur les ressources disponibles.

[0064] Le gestionnaire MEPM reçoit les règles de transfert de trafic et gère notamment les cycles de vie des applications de périphérie mobile et des fonctions de gestion.

[0065] Le gestionnaire MEPM est connecté à la plateforme MEP via le point de référence Mm5 qui lui permet de transmettre des instructions.

Ces instructions peuvent être transmises de la plateforme MEP à l'interface VI via le point de référence Mp2.

[0066] La plate-forme MEP prend aussi en charge la configuration d'un éventuel serveur local, par exemple un serveur DNS, qui peut être utilisé pour diriger le trafic utilisateur vers des applications de périphérie souhaitées.

[0067] La plateforme MEP peut aussi communiquer avec d'autres plates-formes, par exemple une autre plateforme MEP2 que comprend un autre module hôte MECH2 du niveau hôte HL.

Cette communication se fait via un point de référence Mp3, qui connecte les modules hôte MECH et MECH2.

[0068] Ceci permet de regrouper plusieurs plateformes, qui forment alors une grille de com- munication. 8

[0069] La couche supérieure, qui correspond au niveau système SL, comprend un système de support d'opérations, dit système OSS (ou « °mations Support System », en anglais), un proxy LCM (ou « Life Cycle Manager». en anglais) et un orchestrateur multi-accès, dit orchestrateur ME0 (ou « Mobile Edge Orchestrator », en anglais), qui est configure pour exécuter des applications de périphérie mobile au sein d'un opérateur réseau.

[0070] L'orchestrateur ME0 est agencé pour communiquer avec des applications installées sur un équipement utilisateur, dites applications UEA (ou « User Equipment Applications », en anglais), ou avec un portail CES (ou « Customer-Facing Service », en anglais) qui sert de point d'entrée pour une application tierce.

[0071] Dans les présentes, une application UEA est une application web, c'est-à-dire une ap- plication manipulable directement en ligne grâce à un navigateur web et ne nécessitant pas d'installation sur une machines cliente.

[0072] Des applications UEA permettent de déplacer des applications entre des réseaux externes, par exemple des réseaux en nuage, et le réseau de périphérie.

En particulier, une application UEA peut être une application de périphérie qui est instanciée dans un élément du niveau hôte HL en réponse à une demande d'un équipement.

[0073] Dans les présentes, le proxy LCM est un proxy de gestion du cycle de vie des ap- plications utilisateur, et permet en outre aux applications de requérir l'intégration, r instanciation, la résiliation d'applications utilisateur ou encore la rclocal isation d'applications utilisateur à l'intérieur et à l'extérieur du réseau de périphérie mobile.

[0074] Au niveau système SL, une exécution d'une application de périphérie mobile peut être initiée par un équipement tiers par l'intermédiaire d'un point de référence, dit point Mx2 (non représenté), situé entre une application UEA et le proxy LCM.

L'exécution d'une telle application peut aussi être initiée par l'intermédiaire d'un autre point de référence, dit point Mx1 (non représenté), situé entre le portail CFS et le système OSS.

[0075] Selon différents exemples, ces différents éléments du niveau SL permettent de mettre en oeuvre une ou plusieurs instanciations d'applications spécifiques dans le module hôte MECH, et en particulier, sur demande d'une ou de plusieurs applications UEA d'un équipement utilisateur.

[0076] L'orchestrateur ME0 joue un rôle important dans le niveau système SL.

Cet or- chestrateur a connaissance de la topologie du réseau MEC, de tous les modules hôte déployés, ainsi que des services et des ressources disponibles dans chaque hôte.

[0077] Le système OSS est quant à lui relié au niveau hôte NL via un point de référence Mm2 le connectant à la plateforme MEPM et conçu pour déclencher l'instanciation et la fermeture d'applications de périphérie mobile du module hôte, par exemple.

[0078] Le point de référence Mm2 peut aussi être utilisé pour la gestion des pannes, de la 9 configuration et des performances de la plateforme MEP.

[0079] L'orchestrateur MEO est connecté à la plateforme MEPM via un point de référence Mm3, et est en outre connecté au gestionnaire VIM via un point de référence Mm4.

[0080] La figure 2 représente un exemple de réalisation d'un réseau sécurisé par une ou plusieurs entités de sécurité.

[0081] L'architecture représentée reprend les différentes entités fonctionnelles de la figure précédente, ainsi que plusieurs entités de sécurisation agencées pour être connectés à l'une ou l'autre de ces entités fonctionnelles.

[0082] Une première de ces entités de sécurisation est un dispositif de sécurité matériel avec système sur puce, dit dispositif de sécurité matériel HSMSOC (ou « Hardware Security Module System-on-Chip », en anglais).

[0083] Dans les présentes, le dispositif de sécurité matériel HSMSOC peut être mis en oeuvre selon au moins l'un des trois agencements suivants.

[0084] Dans un premier agencement, dit « fusionné », le dispositif de sécurité matériel HSMSOC comprend un module de sécurité matériel HSM et un système sur puce SOC, ledit module et ledit système constituant une seule et même entité équivalente au dispositif de sécurité matériel HSMSOC.

[0085] Dans un deuxième agencement, dit « distant », le dispositif de sécurité matériel HSMSOC comprend un module de sécurité matériel HSM et un système sur puce SOC, mais ledit module de sécurité matériel HSM et ledit système sur puce SOC sont séparés en tant que deux entités distinctes, individuelles.

Ces deux entités sont, de préférence, connectées entre elles.

[0086] Dans un troisième agencement, dit « co-localisé », le dispositif de sécurité matériel HSMSOC est une entité comprenant d'une part un module de sécurité matériel HSM et d'autre part un système sur puce SOC, ledit module de sécurité matériel HSM et ledit système sur puce SOC étant distincts et individuels mais tous les deux présents dans le dispositif de sécurité matériel HSMSOC.

[0087] Les présentes ci-dessous décriront de préférence la mise en oeuvre de l'invention sous la forme de ce troisième agencement « co-localisé ».

De manière non limitative, toutefois, l'un ou l'autre des deux agencements « fusionné » et « distant » peuvent être mis en oeuvre de manière similaire.

[0088] Dans tous les cas, le dispositif de sécurité matériel HSMSOC et/ou les éléments qu'il comprend sont agencés pour permettre une connexion avec le module hôte MECH du réseau MEC, par exemple via le plan de données DP que comprend l'interface VI du module hôte MECH ou encore directement par l'interface Mp2.

[0089] Une deuxième de ces entités de sécurisation est un gestionnaire de sécurité et de confidentialité, dit gestionnaire SPM (ou « Security & Privacy Manager », en anglais).

[0090] De préférence, le gestionnaire SPM est agencé pour être embarqué dans la plateforme MEPM.

[0091] Le gestionnaire SPM permet aussi de tester et de sélectionner des modules hôtes MECH qui répondent à des exigences de sécurité prédéterminées.

[0092] Un exemple d'exigence de sécurité est que ledit module hôte MECH permette au moins la délégation du chiffrement ou de la signature auprès du dispositif de sécurité matériel HSMSOC.

[0093] Une troisième de ces entités de sécurisation est une application de sécurité et de confidentialité, dite application SPA (ou « Security & Privacy Application », en anglais).

[0094] L'application SPA est agencée pour être embarquée dans la plateforme MEP ou dans une application MEA.

Avantageusement, une application MEA ne partage pas de clé privée avec la plateforme MEP, et permet d'activer une délégation pour mettre en oeuvre une signature ou un certificat.

[0095] En outre, l'application SPA permet de mettre en oeuvre un ou plusieurs mécanismes de chiffrement, d'échange et de stockage sécurisé de clés pour sécuriser le réseau MEC.

[0096] La figure 3 représente, sous forme d'organigramme, un exemple d'étapes d'un procédé de sécurisation d'un réseau selon une réalisation.

[0097] Une étape 510 concerne la réception d'au moins un message de test QO par le module hôte MECH du réseau MEC.

Ce message de test QO est émis par le gestionnaire SPM et vise à tester la présence, la localisation et/ou les performances du module hôte MECH dans le réseau MEC.

[0098] Une étape S20, qui suit l'étape SIO, concerne la réception d'au moins une requête de présence du module hôte QI, par le dispositif de sécurité matériel HSMSOC.

Une telle requête de présence du module hôte QI est émise par le module hôte MECH avant la mise en oeuvre d'une étape suivante et vise à vérifier la présence du dispositif de sécurité matériel HSMSOC dans le module hôte MECH.

[0099] L'étape S30, qui suit l'étape S20, concerne la réception d'une requête de présence, ladite requête de présence étant reçue en tant que challenge par le module de sécurité matériel HSM.

Un tel challenge est émis par le système sur puce SOC.

[0100] L'étape S40, qui suit l'étape S30, concerne l'émission d'une réponse correspondante à un challenge reçu lors de l'étape 530, ladite réponse à ce challenge étant émise par le module de sécurité matériel HSM et étant à destination du système sur puce SOC.

[0101] Les étapes S30 et S40 visent à authentifier le module hôte et peuvent être répétées de manière itérative pour augmenter la sécurisation d'une telle authentification.

[0102] Ceci permet, entre autres, de vérifier la capacité de calcul du dispositif de sécurité matériel HSMSOC (ou l'un de ses composants), encore de déterminer la distance entre ledit dispositif et d'autres éléments du réseau de périphérie R. 11

[0103] Lorsque le dispositif de sécurité matériel HSMSOC présente un agencement « fusionné », c'est-à-dire que le module de sécurité matériel HSM et le système sur puce SOC constituent une seule et même entité, les étapes 530 et 540 ne sont pas mises en oeuvre entre le module de sécurité matériel HSM et le système sur puce SOC.

[0104] L'étape S50, qui suit l'étape 540 ou qui suit une répétition des étapes S30 et 540, concerne l'émission d'une réponse R1 correspondante à une requête de présence du module hôte Q1 lors de l'étape S20.

La réponse R1 est émise par le système sur puce SOC et est à destination du module hôte MECH.

[0105] L'étape S60, qui suit l'étape 550, concerne l'émission d'une réponse RO corres- pondante à un message dc test QO émis par le gestionnaire SPM lors de l'étape 510.

Cette réponse RO est émise par le module hôte MECH et est à destination du gestionnaire SPM.

En variante, une réponse RO peut être émise par le dispositif de sécurité matériel HSMSOC.

[0106] L'étape S65, qui suit l'étape 560, concerne la vérification de la réponse RO reçue par le gestionnaire SPM.

Cette étape S65 de vérification peut être incluse dans l'étape S60, mettre fin à l'ensemble des étapes précédentes et/ou déclencher une étape d'action ultérieure.

[0107] En particulier, l'une ou l'autre de ces étapes d'action est mise en oeuvre afin de sé- lectionner un module hôte MECH qui respecte un niveau de chiffrement et de signature prédéterminés, et/ou de déployer des clés privées correspondantes dans le réseau.

[0108] En outre, ces étapes d'action ont pour finalité de prouver que l'un ou l'autre des éléments du réseau embarque un tel module hôte MECH et qu'une délégation n'est pas nécessaire.

Si ledit module hôte MECH est absent, ou s'il n'est pas possible d'en prouver la présence, l'une ou l'autre de ces étapes d'action permet de mettre en oeuvre une délégation, comme décrit ci-après en guise d'exemple.

[0109] La figure 4 représente sous forme d'organigramme, un exemple d'étapes d'un procédé de sécurisation d'un réseau selon une autre réalisation.

[0110] Cette réalisation reprend l'exemple précédent d'organigramme, auquel s'ajoutent les étapes S70 et S80.

[0111] L'étape S70, qui suit l'étape S60 ou l'étape S65, concerne la réception d'une commande par un dispositif tiers, et de préférence à destination d'un serveur LURK localisé dans le réseau MEC.

[0112] De préférence, la commande est émise par le gestionnaire SPM et l'action con-es- pondante à cette commande dépend du résultat de la vérification de la réponse RO.

[0113] Dans les présentes, un serveur LURK est un serveur « dissimulé » dans une ar- chitecture existante, c'est-à-dire un serveur agencé pour être ignoré par les processus habituels prenant place dans cette architecture.

Un tel serveur LURK est par exemple 12 un serveur virtuel instancié par le gestionnaire SPM en fonction du contenu de la réponse RO.

[0114] L'étape 580, qui quit l'étape S70 et peut être facultative, concerne l'émission, par le dispositif tiers, d'une réponse à la commande correspondante à l'étape S70.

[0115] Par exemple, cette réponse peut être un message « OK» émis par un serveur LURK qui a été instancié au cours d'une étape précédente.

[0116] Les étapes S70 et S80 seront décrites plus en détail dans la suite de la description.

[0117] La figure 5 représente un diagramme de flux selon une réalisation d'un procédé de sécurisation d'un réseau de périphérie à accès multiple.

[0118] Dans le cas présent, on suppose que le dispositif de sécurité matériel HSMSOC présente un agencement « co-localisé ».

[0119] Lors de l'étape S10, le gestionnaire de sécurité et de confidentialité SPM transmet un message de test QO au module hôte MECH.

[0120] De préférence, le gestionnaire SPM est connecté au point de référence Mm7 pour mettre en oeuvre cette transmission.

[0121] L'étape S10 permet de démarrer l'établissement d'une preuve de co-localisation.

[0122] De préférence, le gestionnaire SPM dispose d'une liste de clés publiques, ces clés publiques pouvant être fournies par un fabricant ou par un utilisateur de dispositifs de sécurité matériel spécifiques.

[0123] La transmission du message de test QO a pour but de tester si le module hôte MECH dispose d'un dispositif de sécurité matériel HSMSOC.

[0124] En particulier, le message de test QO a pour but de vérifier la localisation et/ou les performances dudit dispositif de sécurité matériel HSMSOC.

[0125] De préférence, le gestionnaire SPM est connecté au point de référence Mm7 pour mettre en oeuvre la transmission du message de test QO.

L'étape S10 permet ainsi de démarrer l'établissement d'une preuve de co-localisation.

[0126] Lors de l'étape S20, un challenge est envoyé du module hôte MECH au dispositif de sécurité matériel HSMSOC.

De préférence, ledit challenge est reçu par un système sur puce SOC que comprend HSMSOC.

[0127] Le challenge qui est envoyé du module hôte MECH au dispositif de sécurité matériel HSMSOC comprend une transmission d'un nombre «y » de bits à faire signer par ledit dispositif de sécurité matériel HSMSOC.

[0128] Typiquement, le nombre « y » de bits correspond à un bloc de données à signer au moyen d'un algorithme donné, par exemple au moyen de codes d'authentification de message (ou « Message Authentication Code », MAC, en anglais) ou d'empreinte cryptographique de message avec clé.

[0129] Le nombre « y» de bits correspond à une grande quantité de données, et est par exemple supérieur ou égal à 20, 24, 256 ou 2048 bits.

De préférence, les bits transmis à 13 faire signer ont une taille minimale de 256 bits pour des clés de type ECDSA, et une taille minimale de 2048 bits pour des clés de type RSA.

[0130] De préférence, un exemple d'algorithme utilisé pour effectuer une telle signature est un algorithme de type fonction de hachage cryptographique (ou « Secure Hash Algorithm », SHA, en anglais), en particulier un algorithme SHA-256, qui permet de générer un hachage de 256 bits (32 octets) unique, de taille fixe, et ne pouvant pas être déchiffré.

[0131] Selon un exemple, et sur réception du message de test QO, le module hôte MECH in- crémente un compteur.

L'incrémentation de cc compteur peut aussi être effectuée sur signature du challenge, et en particulier du nombre « y » de bits précités.

[0132] Lors de l'étape S30, le module hôte MECH transmet une requête de présence du module hôte dans le réseau.

Qi, au système sur puce SOC.

En réponse à cette requête Qi, et lors de l'étape S40, le système sur puce SOC renvoie une réponse Ri au module hôte.

La requête de présente et la réponse sont respectivement reçue et émise en tant que challenge Qi et réponse Ri.

La répétition, de manière itérative, des étapes S30 et S40 revient à mettre en oeuvre une opération itérative d'authentification du module hôte.

[0133] Ceci permet, entre autres, de vérifier les performances du module hôte, sa présence ou encore sa distance par rapport à d'autres éléments du réseau.

[0134] En particulier, l'étape 530 comprend une émission d'un challenge local, ledit challenge local étant défini par un opérateur donné du réseau, par exemple.

De préférence, ce challenge con-espond à une requête de signature d'un nombre «n» prédéterminé de bits à signer.

Cette signature peut se faire au moyen d'un ou de plusieurs algorithmes.

[0135] Par exemple, il sera décrit dans la suite des présentes qu'un challenge local peut être émis par la plateforme MEP et/ou par une application MEA en vue d'effectuer une ou plusieurs des actions subséquentes.

[0136] Lorsque le challenge local est émis par la plateforme MEP, la signature est mise en oeuvre au moyen d'une clé privée, ladite clé privée appartenant à un fabricant ou à un opérateur du dispositif de sécurité matériel HSMSOC.

[0137] En variante, lorsque le challenge local est émis par une application MEA, la signature est mise en oeuvre au moyen d'une clé privée appartenant à un fabricant ou à un opérateur du module hôte MECH ou du dispositif de sécurité matériel HSMSOC.

[0138] L'étape 540 comprend un envoi d'une réponse Ri au challenge local Qi de l'étape S30.

De préférence, cette réponse comprend le nombre «n » prédéterminé de bits, signés avec une clé privée, cette clé privée appartenant à l'opérateur précité du réseau.

[0139] Lors des étapes 530 et 540, une pluralité de requêtes de présence et de réponses peuvent être respectivement reçues et émises une pluralité de fois.

A cette pluralité 14 correspond donc un nombre « N» de challenges QI, Q2, QN et de réponses R1, R2, ..., RN émis et reçus de manière itérative afin de mettre en oeuvre une authentification du module hôte MECH.

[0140] Les étapes 530 et 540 permettent, notamment, de mettre en oeuvre une vérification d'un identifiant du module hôte MECH et/ou d'un identifiant du dispositif de sécurité matériel HSMSOC, par exemple son fabricant.

Par exemple, il est possible, lors des étapes 530 et 540, de vérifier simultanément l'identité d'un fabricant du dispositif de sécurité matériel HSMSOC.

Ceci peut se faire en envoyant un challenge à signer par le système sur puce SOC, ledit challenge étant par exemple une demande CSR.

Une vérification peut ensuite être mise en oeuvre au moyen des clés publiques correspondant au fabricant du dispositif de sécurité matériel HSMSOC.

Si la présence de clés privées est détectée, une vérification peut être mise en oeuvre avec les clés publiques qui sont déjà présentes.

[0141] Lors de l'étape S50, le système sur puce 550 émet une réponse de présence R1 à des- tination du module hôte MECH, cette réponse comportant une signature du dispositif de sécurité matériel.

En particulier, la réponse R1 comprend le nombre « y» de bits que comportait initialement la requête de présence du module hôte Ql, ces bits étant signés par au moins une clé privée du système sur puce SOC.

[0142] La réponse R1 peut, en outre, comporter au moins un temps de réponse et/ou au moins une signature dont une clé privée appartient au fournisseur.

[0143] En d'autres termes, les étapes S10 à S60 ou, de manière plus générale, les étapes S20 et S50, permettent au gestionnaire SPM de tester un module hôte MECH, et en particulier de vérifier si ledit module hôte MECH dispose d'un dispositif de sécurité matériel HSMSOC.

[0144] Pour effectuer cette vérification, le gestionnaire SPM dispose d'une liste de clés publiques fournies par le ou les fabricants du dispositif de sécurité matériel HSMSOC.

Lors de la vérification, le gestionnaire SPM transmet un challenge à destination du gestionnaire MEPM.

[0145] Selon un exemple, l'envoi de ce challenge est mis en oeuvre par connexion du ges- tionnaire SPM au gestionnaire MEPM via le point de référence Mm?.

[0146] Avantageusement, l'envoi du challenge via le point de référence Mm7 permet au ges- tionnaire VIM d'interagir avec le dispositif de sécurité matériel HSMSOC, par exemple pour mettre en oeuvre une installation d'une clé ou d'un certificat.

[0147] Le gestionnaire VIM permet ainsi une connexion « dos à dos » (ou « back-to-back connection », en anglais), et notamment, une connexion directe entre une sortie/entrée du module hôte MECH et une entrée/sortie du dispositif de sécurité matériel HSMSOC.

[0148] Selon un autre exemple, la connexion peut être faite via le point de référence Mm5

[0149] Avantageusement, l'envoi du challenge via le point de référence Mm5 permet à la plateforme MEP et/ou à une application MEA d'effectuer une ou plusieurs des actions subséquentes.

[0150] Des exemples de telles actions comprennent, par exemple, une diffusion ou une mise à disposition d'un contenu, notamment via un réseau de diffusion dc contenu CDN (ou « Content Delivery Nctwork », en anglais), une délégation d'une autorisation de signature ou encore une délégation de droits pour un certificat dc type privé ou public.

[0151] Selon encore un autre exemple, la connexion peut être faite via le point dc référence Mm7 et via le point de référence Mm5, simultanément ou successivement.

[0152] Selon différents exemples, ledit challenge comprend un identifiant du module hôte MECH, et une preuve de présence du dispositif de sécurité matériel HSMSOC dans cc module hôte MECH, par exemple au point dc référence Mp2.

La validation de cette preuve de présence permet dc déterminer si le dispositif de sécurité matériel HSMSOC est présent dans cc module hôte MECH, s'il est absent ou s'il est situé ailleurs.

La validation de cette preuve de présence permet aussi de déterminer la distance séparant le module hôte MECH du dispositif de sécurité matériel HSMSOC, ou encore de déterminer un temps de latence associé.

[0153] En outre, le challenge peut comprendre d'autres éléments tels qu'une preuve de co- localisation.

Une telle preuve de co-localisation peut être obtenue via l'incrémentation d'un premier compteur du module hôte MECH et la signature du résultat dans un fichier transmis à destination du système sur puce SOC.

Lorsque le système sur puce SOC reçoit ledit fichier, un deuxième compteur peut être incrémenté, le résultat peut être signé par le système sur puce SOC et être envoyé au module hôte MECH.

[0154] Lors de l'étape S60, la réponse de présence RI est envoyée par le module hôte MECH à destination du gestionnaire SPM.

[0155] Sur réception de la réponse de présence RI, et selon différents exemples, le ges- tionnaire SPM peut mettre en oeuvre différentes actions.

[0156] Par exemple, le gestionnaire SPM peut mettre en oeuvre une étape S65 de véri- fication, au cours de laquelle il en vérifie le contenu.

[0157] En particulier, le gestionnaire SPM peut vérifier un temps de réponse et/ou une signature contenue dans la réponse de présence RI, et en déduire un niveau de performance.

[0158] Par exemple, si une signature est valide et si un temps de réponse est suffisamment court pai- rapport à des conditions prédéteiminées, le niveau de performance peut être défini comme « élevé », ou OK.

[0159] Si une signature n'est pas valide et/ou si un temps de réponse est plus grand que ce qui est attendu de conditions prédéterminées, le niveau de performance peut être défini comme « bas », ou « NOK » car indiquant un faible niveau de sécurisation du réseau. 16

[0160] Le niveau de performance déduit peut être utilisé pour mettre en oeuvre des étapes d'actions, en particulier si celui-ci est « bas ».

[0161] Ainsi, lors de l'étape S70, en fonction de la réponse de présence R1 obtenue du module hôte MECH, une action est mise en oeuvre par le gestionnaire SPM pour augmenter la sécurité de l'architecture lors d'une utilisation ultérieure, ou pour augmenter la protection de clés privées qui seront utilisées ultérieurement.

[0162] Selon différents exemples, et s'il a été testé positivement que le module hôte MECH dispose d'un dispositif de sécurité matériel HSMSOC, le gestionnaire SPM peut mettre en oeuvre différentes actions telles qu'installer une clé privée dans le module hôte MECH.

[0163] En variante, le gestionnaire SPM peut instancicr un serveur, par exemple un serveur LURK, dans le module hôte MECH ou dans une application de sécurité et de confidentialité SPA embarquée dans ledit module hôte MECH.

Il est alors possible de rediriger les éventuelles demandes ultérieures de stockage de clés privées vers ce serveur LURK.

[0164] Selon d'autres exemples, et s'il s'avère que le module hôte MECH ne dispose pas d'un dispositif de sécurité matériel HSMSOC, le gestionnaire SPM peut mettre en oeuvre différentes actions de sorte à ce que le module hôte MECH obtienne des clés, par exemple des clés provenant d'un serveur LURK instancié comme décrit précédemment.

[0165] La figure 6 représente un bloc-diagramme schématique d'un circuit de traitement in- formatique selon un exemple de mise en oeuvre.

[0166] Selon un exemple, ledit circuit de traitement informatique est un processeur.

De préférence, un tel circuit de traitement informatique est un système sur puce 1000 agencé pour mettre en oeuvre un procédé de sécurisation selon l'une ou l'autre des réalisations décrites.

[0167] De manière non limitative, le système sur puce 1000 met en oeuvre un procédé de sé- curisation d'un réseau MEC de périphérie à accès multiple.

Le système sur puce 1000 comporte un bus de communication connecté, par exemple, à une unité centrale de traitement 1010, tel qu'un processeur ou un microprocesseur, et notée CPU.

[0168] Le système sur puce 1000 comporte aussi une mémoire à accès aléatoire 1020, notée RAM, pour mémoriser le code exécutable du procédé de sécurisation ainsi que les registres adaptés à enregistrer des variables et des paramètres nécessaires pour la mise en oeuvre du procédé selon des modes de réalisation, la capacité de mémoire de celui-ci peut être complétée par une mémoire RAM optionnelle connectée à un port d'extension, par exemple.

[0169] En outre, le système sur puce 1000 comporte une mémoire morte 1030, notée ROM, pour stocker des programmes informatiques pour la mise en oeuvre des modes de réa- 17 lisation, ainsi qu'une interface réseau 1040 qui est normalement connectée à un réseau de communication sur lequel des données numériques à traiter sont transmises ou reçues.

[0170] L'interface réseau 1040 peut être une seule interface réseau, ou composée d'un ensemble d'interfaces réseau différentes (par exemple filaire et sans fil, interfaces ou différents types d'interfaces filaires ou sans fil).

[0171] Des paquets de données sont envoyés sur l'interface réseau pour la transmission ou sont lues à partir de l'interface de réseau pour la réception sous le contrôle de l'application logiciel exécuté dans le processeur ou le microprocesseur 1010.

[0172] Par ailleurs, le système sur puce 1000 comporte une interface utilisateur 1050 pour recevoir des entrées d'un utilisateur ou pour afficher des informations à un utilisateur, un support de stockage optionnel 1060 noté HD, et un module d'entrée-sortie 1070, noté IO, pour la réception, l'envoi de données depuis ou vers des périphériques externes tels que disque dur, support de stockage amovible ou autres.

[0173] Dans un exemple présenté ici, le code exécutable peut être stocké dans une mémoire morte 1030, sur le support de stockage 1060 ou sur un support amovible numérique tel que par exemple un disque.

[0174] Selon une variante, le code exécutable des programmes peuvent être reçu au moyen d'un réseau de communication, via l'interface réseau 1040, afin d'être stocké dans le support de stockage 1060, avant d'être exécuté.

[0175] L'unité centrale de traitement 1010 est adaptée pour commander et diriger l'exécution des instructions ou des portions de code logiciel du programme ou des programmes selon l'un des modes de réalisation, instructions qui sont stockées dans l'un des moyens de stockage précités.

Après la mise sous tension, le CPU 1010 est capable d'exécuter des instructions stockées dans la mémoire RAM principale 1020, relatives à une application logicielle, après que ces instructions aient été chargées de la ROM par exemple.

[0176] Dans l'exemple présenté ici, la système sur puce 1000 est un appareil programmable qui utilise un logiciel.

Toutefois, à titre subsidiaire, la présente description peut être mise en oeuvre dans n'importe quel type de matériel (par exemple, sous la forme d'un circuit intégré spécifique ou ASIC).

18 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] [Revendication 6]

Claims (1)

1. REVENDICATIONSProcédé de sécurisation d'un réseau de périphérie à accès multiple (MEC), dans lequel on prévoit un dispositif de sécurité matériel (HSMSOC) agencé pour être connecté à un module hôte (MECH) dudit réseau, et le procédé, mis en oeuvre par ledit dispositif de sécurité matériel, comportant: - sur réception (S20) d'une requête de présence du module hôte (Q1) dans le réseau, vérifier si ladite requête de présence comprend une donnée représentative d'un identifiant du module hôte, et, dans ce cas, - émettre (S50) une réponse de présence (R1) à destination du module hôte (MECH) comportant une signature du dispositif de sécurité matériel. Procédé selon la revendication 1, dans lequel ladite requête de présence du module hôte (Q1) dans le réseau est émise par le module hôte (MECH) sur réception (S10) d'un message de test (Q0) émis par un gestionnaire de sécurité et de confidentialité (SPM) au module hôte. Procédé selon l'une quelconque des revendications précédentes, comportant en outre une détermination (S60 ; S65) d'un niveau de sécurité du réseau en fonction de ladite réponse de présence (R1). Procédé selon l'une quelconque des revendications précédentes, dans lequel la requête de présence et la réponse du dispositif de sécurité matériel sont respectivement reçue (S30) et émise (S40) une pluralité de fois, respectivement en tant que challenge (Qi) et réponse (Ri) dans une opération itérative d'authentification du module hôte que met en oeuvre le dispositif de sécurité matériel. Procédé selon la revendication 4, dans lequel, à chaque itération de l'opération itérative d'authentification du module hôte, ladite réponse est obtenue dudit challenge respectif par une signature d'un nombre prédéterminé de bits que comprend le challenge respectif au moyen d'une clé de sécurité stockée dans le dispositif de sécurité matériel (HSMSOC). Procédé selon l'une quelconques des revendications précédentes, dans lequel la requête de présence est vérifiée comme comprenant une donnée représentative d'un identifiant du module hôte lorsqu'il est vérifié que ledit identifiant. est compris dans une liste stockée dans une mémoire accessible au dispositif de sécurité matériel. 19 [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] [Revendication 11] [Revendication 12] Procédé selon l'une quelconques des revendications précédentes, dans lequel la requête de présence comporte au moins une donnée représentative d'un identifiant sélectionné dans le groupe : une preuve d'attachement, une information de connexion, un opérateur, un identifiant du module hôte (MECH), une information de fabrication ou encore une preuve de présence du dispositif de sécurité matériel (HSMSOC) dans le module hôte (MECH). Procédé selon l'une quelconque des revendications précédentes, comportant en outre un module d'application de sécurité et de confidentialité (SPA) agencé pour être connecté au module hôte (MECH) et pour mettre en oeuvre au moins une signature ou une clé de sécurité. Procédé selon l'une quelconque des revendications précédentes, comportant en outre, sur réception de la réponse de présence par le module hôte, une mise en oeuvre d'une action (S70), ladite action étant choisie dans le groupe : une vérification de ladite réponse de présence, une instanciation d'un serveur virtuel (LRK) dans le module hôte, une installation d'une clé de sécurité dans le module hôte, une désignation d'un dispositif de sécurité matériel distant, une désignation d'un dispositif de sécurité matériel distant et/ou une désignation d'un serveur virtuel d'un module hôte distant doté d'une clé de sécurité. Dispositif de sécurité matériel (HSMSOC) pour sécuriser un réseau de périphérie à accès multiple (MEC), ledit dispositif étant agencé pour être connecté à un module hôte (MECH) dudit réseau et configuré pour mettre en oeuvre le procédé selon l'une quelconque des revendications précédentes. Programme informatique comportant des instructions pour la mise en oeuvre du procédé selon l'une des revendications 1 à 9, lorsque lesdites instructions sont exécutées par un processeur d'un circuit de traitement informatique. Moyen de stockage d'informations, amovible ou non, partiellement ou totalement lisible par un ordinateur ou un processeur comportant des instructions de code d'un programme d'ordinateur pour l'exécution de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 9.