Brevet FR3135805A1 — publié le 20231124

L’invention propose un nouveau procédé de gestion de profils de service d’un élément sécurisé, le procédé de gestion étant mis en œuvre par un dispositif centralisé de gestion de profils et comprenant : recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service ; stocker en mémoire des données de profil parmi les données de profil reçues en association avec ledit service ; détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service. Figure pour l’abrégé : Fig.3 Procédé de gestion de profils de service d’un élément sécurisé La présente invention concerne la gestion de profils de service dans un élément sécurisé d’un terminal hôte. Un élément sécurisé, SE, est un composant ou plate-forme matérielle inviolable (typiquement une puce ou une carte à puce) utilisée dans un terminal hôte (typiquement un terminal mobile) et capable d’héberger, de façon sûre, des applications et des données en conformité avec des règles et des exigences de sécurité fixées par des autorités de confiance. Un facteur de forme de plus en plus utilisé du SE est l’élément sécurisé embarqué, eSE (pour « embedded Secure Element »). Cet élément sécurisé embarqué est généralement soudé au terminal hôte. Un facteur de forme plus récent est l’élément sécurisé intégré, iSE (pour « integrated Secure Element »). L’élément sécurisé fait alors partie intégrante du processeur principal (par exemple comme cœur sécurisé en plus d’autres cœurs du processeur). Les éléments sécurisés sont programmés selon les applications souhaitées. À titre d'exemple, un eSE ou iSE peut former l'élément sécurisé nécessaire à de nombreux usages ou services reposant sur une communication NFC (Near Field Communication) mis en œuvre par un terminal mobile hôte. Par exemple, un service de paiement NFC nécessite des informations bancaires secrètes de l'utilisateur qui sont avantageusement stockées dans l'eSE, à l'abri de tout accès intempestif. C’est aussi le cas d’un service de transport public où l’eSE permet d’identifier l’utilisateur auprès de portiques. Un autre exemple d’élément sécurisé est l’UICC embarquée (pour « Universal Integrated Circuit Card », ou « carte de circuit intégré universelle » en français) qui procure les références d’un abonné pour s’authentifier sur un ou plusieurs réseaux de téléphonie mobile, notamment via différents opérateurs. Il s’agit par exemple d’un eSE ou iSE configuré comme une carte SIM (pour « Subscriber Identity Module », ou « module d’identité d’abonné » en français). On parle alors d’eUICC (pour « embedded UICC ») ou iUICC (pour « integrated UICC »). Les principales spécifications d'une carte eUICC sont définies par le groupe GSMA (pour « Global System for Mobile Communications Association ») dans le standard GSMA SGP.02 v3.2 intitulé « Remote Provisioning Architecture for Embedded UICC - Technical Specification - Version 3.2» en date du 27 juin 2017. L’intérêt principal de ces éléments sécurisés est d’offrir plusieurs services à l’aide d’un seul et même élément sécurisé. Plusieurs fournisseurs de service doivent donc charger les données et/ou applications dans le même élément sécurisé permettant à un utilisateur d’accéder à leurs services. Ces données et/ou applications propres à un fournisseur de service pour un utilisateur forment un profil de service (ou simplement « profil » par la suite) mémorisé dans l’élément sécurisé. On connaît notamment les profils au sens de la norme GSMA RSP Technical Specification, Version 2.2 du 01 septembre 2017 (ci-dessous GSMA SGP.22) qui sont associés à des opérateurs mobiles (fournisseurs de service) et contiennent les informations de l’utilisateur lui permettant d’accéder à leurs services de téléphonie mobile. On connaît également les configurations au sens de la norme GlobalPlatform Card Specification (Version 2.3 d’octobre 2015) qui sont associées à des autorités (fournisseurs de service) et contiennent les informations de l’utilisateur lui permettant d’accéder à leurs services respectifs. Selon le standard GSMA, la gestion de ces profils est assurée par une entité appelée LPA (pour « Local Profile Administration », ou « administration des profils locaux » en français). Le LPA est situé dans le système d’exploitation du terminal hôte ou dans l’élément sécurisé du terminal hôte, et réalise l’interface entre l’élément sécurisé et l’entité, sur le réseau de communication, de l’opérateur de gestion de profils (par exemple le serveur de gestion des abonnements SM-DP+, pour « Subscription Manager Data Preparation+ »). Cela permet par exemple à l’utilisateur du terminal hôte d’installer un nouveau profil dans l’élément sécurisé, ou encore d’activer, de désactiver ou de supprimer un profil déjà installé dans l’élément sécurisé. Aujourd’hui, avec le développement de l’internet des objets (ou IoT, pour « Internet of Things », en anglais), qui représente des dizaines voire des centaines de milliers d’appareils connectés comprenant des éléments sécurisés stockant des profils associés à de nouveaux services, il est nécessaire de réfléchir à des solutions pour une gestion à distance efficace de tels profils. Il a notamment été proposé un système conformément à la , dans lequel les fonctions de gestion à distance des profils de service sont mises en œuvre par des dispositifs CLPA i externes au terminal hôte, situés dans le réseau de communication. Plus précisément, la représente un terminal hôte 101 comprenant un élément sécurisé 102, par exemple un eUICC, et un agent de communication 103. Le terminal hôte 101 peut être par exemple un téléphone mobile, un dispositif embarqué dans une voiture et géré à distance par le système d’information du constructeur de la voiture, ou tout autre type d’objet connecté. L’élément sécurisé 102 mémorise typiquement un ou plusieurs profils. L’agent de communication 103 est situé dans le système d’exploitation du terminal hôte 101 ou dans l’élément sécurisé 102 du terminal hôte 101, et réalise l’interface entre l’élément sécurisé 102 et les différents dispositifs externes de gestion de profils CLPA i 105a, 105b, 105c, comme détaillé ci-dessous. Le système de la comprend aussi un serveur SM-DP+ (pour « Subscription Manager Data Preparation », ou serveur de préparation de données et de gestion des abonnements en français) 104 d’un réseau mobile, lequel serveur mémorise ou reçoit plusieurs profils à transmettre à l’élément sécurisé 102. Différents types de serveurs distants peuvent être utilisés, par exemple le serveur SM-DP+ 104 peut être remplacé par deux serveurs SM-DP et SM-SR. La gestion des profils stockés sur l’élément sécurisé 102 est assurée par une pluralité de dispositifs externes de gestion de profils CLPA i 105a, 105b, 105c qui ne sont pas dans le terminal hôte 101, mais sont des dispositifs (ou des serveurs) déportés dans le réseau. À ce titre, les dispositifs externes de gestion de profils CLPA i 105a, 105b, 105c assurent, pour les services qui leur sont respectivement associés, les fonctions de gestion des profils à la place de l’entité LPA définie par exemple dans le standard GSMA SGP.22 v2.0 intitulé « RSP Technical Specification - Version 2.0 » en date du 14 octobre 2016. Chaque dispositif externe de gestion de profils CLPA i 105a, 105b, 105c est ainsi configuré pour communiquer d’une part avec le serveur SM-DP+ 104 et obtenir une (ou plusieurs) commande relative à la gestion d’un profil de l’élément sécurisé 102 (par exemple une commande d’installation ou de suppression d’un profil), et d’autre part avec l’agent de communication 103 du terminal hôte 101 pour lui envoyer ladite commande de gestion de profil. L’agent de communication 103 est en outre configuré pour envoyer à l’élément sécurisé 102 la commande de gestion de profil. Un tel système est décrit de manière détaillée dans la demande FR 3 111 042. Toutefois, au vu du nombre toujours croissant de services associés à un même élément sécurisé, et par conséquent du nombre de plus en plus important de dispositifs externes de gestion de profils, un tel système n’est pas entièrement satisfaisant. En effet, comme les dispositifs externes de gestion de profils communiquent (directement ou par le biais de la plateforme de gestion du terminal) avec le terminal hôte, il est nécessaire, pour sécuriser l’accès à l’élément sécurisé, que les locaux hébergeant les dispositifs externes de gestion de profils soient certifiés par une autorité de certification. Or, de telles certifications représentent un coût non négligeable, dans lequel tous les fournisseurs de service ne veulent pas forcément investir. En outre, ce système ne permet pas de gérer efficacement l’évolution des dispositifs externes de gestion de profils pour un service donné (par exemple, un dispositif externe de gestion de profils hors service, ou non capable de procéder à la mise à jour du profil, le remplacement d’un dispositif externe de gestion de profils par un autre, etc.). Par exemple, pour un service donné, la migration vers un nouveau fournisseur de service s’accompagne d’un changement du dispositif de gestion de profil associé à ce service. L’élément sécurisé n’est pas informé de cette évolution, et n’a pas connaissance de l’adresse du nouveau dispositif de gestion de profil. Aucun mécanisme n’est prévu actuellement pour basculer vers un nouveau dispositif externe de gestion de profils pour un service déjà existant. Il y a donc un besoin pour améliorer la gestion des profils de service stockés dans un élément sécurisé. Un premier aspect de l’invention concerne un procédé de gestion de profils de service d’un élément sécurisé d’un terminal hôte, le procédé de gestion étant mis en œuvre par un dispositif centralisé de gestion de profils externe au terminal hôte. Le procédé peut comprendre : - recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ; - stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ; - détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et - à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service. Par « donnée de profil », il est entendu une ou plusieurs données associées à un profil de service, permettant d’installer ou de mettre à jour un profil sur l’élément sécurisé. Un « dispositif de traitement » peut être un dispositif ou un serveur externe géré par un fournisseur de service, sur lequel sont stockées des données de profil associées à un ou plusieurs services gérés par le fournisseur de service. Par la suite, un dispositif de traitement est aussi appelé « dispositif de gestion de profil ». Par « événement déclencheur d’une mise à jour d’un profil de service », il est entendu tout événement entraînant la recherche et l’envoi d’une donnée de profil parmi les données de profil stockées dans le dispositif centralisé de gestion de profils 206. Par exemple, le dispositif centralisé de gestion de profil peut recevoir une requête d’interrogation de la part de l’élément sécurisé (« mode pull »), ou peut être configuré pour vérifier à des temps prédéterminés si une donnée de profil est disponible et l’envoyer le cas échéant à l’élément sécurisé. Le procédé ci-dessus permet de gérer avantageusement le cas où plusieurs données de profil correspondant à un même service sont reçues d’au moins deux dispositifs de traitement différents, ce qui n’était pas possible avec l’architecture de la . En outre, la présence d’un dispositif de gestion centralisé comme unique entité avec laquelle communique le terminal hôte permet d’éliminer les problématiques de certifications. Dans un ou plusieurs modes de réalisation, la donnée de profil envoyée peut être envoyée par le dispositif centralisé de gestion de profils à un agent de communication du terminal hôte, l’agent de communication étant configuré pour transmettre à l’élément sécurisé ladite donnée de profil. Dans un ou plusieurs modes de réalisation, le dispositif centralisé de gestion de profils peut recevoir en outre d’autres données de profil destinées à au moins un autre élément sécurisé, dans lequel chaque donnée de profil est reçue avec un identifiant d’un élément sécurisé auquel elle est destinée, dans lequel chaque donnée de profil stockée est en outre stockée en association avec l’identifiant de l’élément sécurisé auquel elle est destinée, et dans lequel la donnée de profil la plus récente parmi les données de profil stockées associées audit service est envoyée avec l’identifiant de l’élément sécurisé auquel elle est destinée. En d’autres termes, le dispositif centralisé de gestion de profils peut être configuré pour gérer les profils d’une pluralité d’éléments sécurisés, appartenant ou non au même terminal hôte. Dans ce cas, chaque donnée de profil reçue d’un dispositif de traitement peut comprendre un identifiant de l’élément sécurisé auquel elle est destinée. En outre, chaque donnée de profil stockée peut être respectivement associée à une donnée de version, dans lequel la donnée de version est représentative d’un temps de réception par le dispositif centralisé de gestion de profils ou est un numéro de version d’un profil associé à la donnée de profil, dans lequel la donnée de profil envoyée correspond à la donnée de profil ayant la donnée de version la plus récente parmi les données de profil stockées associées audit service. Dans un ou plusieurs modes de réalisation, chaque donnée de profil peut être reçue avec une donnée d’identification de service respective, et le procédé peut en outre comprendre : - pour chaque donnée de profil reçue et stockée en mémoire, déterminer un service correspondant à partir de la donnée d’identification de service respective reçue avec ladite donnée de profil et stocker la donnée de profil en association avec le service correspondant déterminé. Par exemple, une donnée d’identification de service parmi les données d’identification de service reçues peut être : - un identifiant du dispositif de traitement depuis lequel la donnée de profil a été reçue ; - une adresse réseau du dispositif de traitement depuis lequel la donnée de profil a été reçue ; - un identifiant d’un fournisseur de service gérant un service associé à la donnée de profil reçue ; ou - un identifiant d’un service associé à la donnée de profil reçue. Ainsi, chaque donnée de profil est reçue avec une information permettant de déterminer à quel service elle correspond. Il est ainsi possible d’associer, lors du stockage de la donnée de profil, ladite donnée et le service correspondant. Dans un ou plusieurs modes de réalisation, le procédé peut en outre comprendre, pour chaque donnée de profil associée au service reçue : - déterminer un fournisseur de service associé à la donnée de profil et stocker la donnée de profil en association avec le fournisseur de service déterminé ; - à la détection dudit événement, déterminer, à partir d’une base de données, un fournisseur de service courant associé à l’élément sécurisé pour ledit service ; dans lequel la donnée de profil envoyée est la donnée de profil la plus récente parmi les données de profil stockées associées audit service et au fournisseur de service courant associé à l’élément sécurisé pour ledit service. Par « fournisseur de service courant » il est entendu le fournisseur du service au moment où l’événement déclencheur est détecté. En effet, entre la réception d’au moins une partie des données de profil et la détection de l’événement déclencheur, il se peut que le fournisseur du service concerné ait changé. Dans ce cas, la donnée de profil envoyée au terminal est choisie parmi les données de profil stockées dans le dispositif centralisé de gestion de profil et associée au fournisseur courant du service. Dans un ou plusieurs modes de réalisation, la détection de l’événement déclencheur de la mise à jour du profil de service de l’élément sécurisé peut comprendre : - recevoir, du terminal hôte ou d’une plateforme de gestion du terminal hôte, une requête d’interrogation comprenant une information d’identification dudit service donné. De tels modes de réalisation correspondent à un mode « pull ». Le terminal hôte envoie une requête correspondant à un service donné pour demander si une nouvelle version du profil associé au service est disponible, et la récupérer le cas échéant. Dans le système de la , en cas de changement d’adresse réseau du dispositif de traitement vers lequel la requête d’interrogation est envoyée, cette requête est perdue ou envoyée à la mauvaise entité. En effet, rien n’est prévu pour gérer dynamiquement les changements d’adresses réseau ou de fournisseurs. Dans la présente invention, ce problème ne se pose plus car toutes les requêtes d’interrogation sont envoyées vers une même entité, dont l’adresse réseau est fixe. La requête d’interrogation peut en outre comprendre un identifiant de l’élément sécurisé. Dans un ou plusieurs modes de réalisation, chaque dispositif de traitement parmi la pluralité de dispositifs de traitement peut avoir une première paire de clés asymétriques respective, chaque première paire de clés asymétriques comprenant une clé privée et une clé publique, la clé publique étant partagée entre le dispositif de traitement et le dispositif centralisé de gestion de profils. Chaque donnée de profil reçue peut être signée avec la clé privée du dispositif de traitement émetteur. Le procédé peut en outre comprendre, pour chaque donnée de profil reçue : - vérifier, par le dispositif centralisé de gestion de profils, la signature de la donnée de profil à partir de la clé publique du dispositif de traitement émetteur ; et - stocker en mémoire du dispositif centralisé de gestion de profils la donnée de profil reçue uniquement si la vérification est un succès. Par dispositif de traitement émetteur, il est entendu le dispositif de traitement depuis lequel la donnée de profil a été reçue. Une telle vérification de la signature du dispositif de traitement permet de vérifier que la donnée de profil a bien été émise par une entité autorisée et de confiance, et qu’elle n’a pas été corrompue entre son envoi et sa réception. Dans certains modes de réalisation, la clé publique du dispositif de traitement peut être diffusée au dispositif centralisé de gestion de profil dans un certificat numérique. En outre, le dispositif centralisé de gestion de profils peut avoir une deuxième paire de clés asymétriques, la deuxième paire de clés asymétriques comprenant une clé privée du dispositif centralisé de gestion de profils et une clé publique du dispositif centralisé de gestion de profils, la clé publique de la deuxième paire de clés asymétriques étant partagée entre le dispositif centralisé de gestion de profils et l’élément sécurisé. Pour chaque donnée de profil stockée, ladite donnée de profil peut être signée à l’aide de la clé privée du dispositif centralisé de gestion de profils. Cette signature peut être additionnelle à la première signature ci-dessus. Selon ce mode de réalisation, la donnée de profil est donc doublement signée, d’une part avec la clé privée du dispositif de traitement émetteur, et d’autre part avec la clé privée du dispositif centralisé de gestion de profils. La clé publique de la deuxième paire de clés asymétriques (donc la clé publique du dispositif centralisé de gestion de profils) peut être envoyée à l’élément sécurisé dans un deuxième certificat numérique. Dans ce mode de réalisation, les clés publiques des dispositifs de traitement doivent en outre être communiquées à l’élément sécurisé (par exemple, le certificat de chaque dispositif de traitement peut être envoyé du dispositif centralisé de gestion de profils à l’élément sécurisé, et éventuellement ce certificat peut être signé grâce à la clé privée du dispositif centralisé de gestion de profils). Cela permet à l’élément sécurisé, lorsqu’il reçoit la donnée de profil, de vérifier qu’elle n’a pas été modifiée depuis son envoi par le dispositif de traitement, et de « tracer » son parcours (dispositif de traitement émetteur – dispositif centralisé de gestion de profils – élément sécurisé). Un autre aspect de l’invention concerne un dispositif centralisé de gestion de profils pour gérer des profils de communication d’un élément sécurisé d’un terminal hôte, le dispositif centralisé de gestion de profils étant externe au terminal hôte. Le dispositif centralisé de gestion de profils peut être configuré pour : - recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ; - stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ; - détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et - à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service. Un autre aspect de l’invention concerne un système comprenant un terminal hôte ayant un élément sécurisé, un dispositif centralisé de gestion de profils externe au terminal hôte et une pluralité de dispositifs de traitement, dans lequel le dispositif centralisé de gestion de profils peut être configuré pour : - recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ; - stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ; - détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et - à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service. L’élément sécurisé peut être configuré pour : - recevoir la donnée de profil envoyée par le dispositif centralisé de gestion de profils ; et - mettre à jour le profil de service à partir de la donnée de profil reçue. En outre, chaque dispositif de traitement parmi la pluralité de dispositifs de traitement peut avoir une première paire de clés asymétriques respective, chaque première paire de clés asymétriques comprenant une clé privée et une clé publique, la clé publique étant partagée entre le dispositif de traitement et le dispositif centralisé de gestion de profils. Chaque donnée de profil reçue peut être signée avec la clé privée du dispositif de traitement émetteur, et le dispositif centralisé de gestion de profils peut en outre être configuré pour, pour chaque donnée de profil reçue : - vérifier la signature de la donnée de profil à partir de la clé publique du dispositif de traitement émetteur ; et - stocker en mémoire la donnée de profil reçue uniquement si la vérification est un succès. Dans un ou plusieurs modes de réalisation, le dispositif centralisé de gestion de profils peut avoir une deuxième paire de clés asymétriques, la deuxième paire de clés asymétriques comprenant une clé privée du dispositif centralisé de gestion de profils et une clé publique du dispositif centralisé de gestion de profils, la clé publique de la deuxième paire de clés asymétriques étant partagée entre le dispositif centralisé de gestion de profils et l’élément sécurisé. Pour chaque donnée de profil stockée, ladite donnée de profil peut être signée (éventuellement en plus de la première signature ci-dessus) à l’aide de la clé privée du dispositif centralisé de gestion de profils avant d’être envoyée au terminal hôte. La clé publique de chaque dispositif de traitement parmi la pluralité de dispositifs de traitement peut être partagée avec l’élément sécurisé et l’élément sécurisé peut être configuré pour : - à la réception de la donnée de profil signée, vérifier les signatures associées grâce à la clé publique du dispositif de traitement émetteur de la donnée de profil et à la clé publique du dispositif centralisé de gestion de profils ; et - mettre à jour le profil de service à partir de la donnée de profil reçue uniquement si la vérification est un succès. Un autre aspect de l’invention concerne un produit programme informatique comportant des instructions pour la mise en œuvre du procédé ci-dessus, lorsque ce programme est exécuté par un processeur Un autre aspect de l’invention concerne un support non transitoire lisible par ordinateur stockant un programme qui, lorsqu’il est exécuté par un processeur d’un dispositif centralisé de gestion de profils, amène le dispositif centralisé de gestion de profils à effectuer le procédé tel que défini ci-dessus. Au moins une partie des procédés selon l’invention peut être mise en œuvre par ordinateur. En conséquence, la présente invention peut prendre la forme d’un mode de réalisation entièrement matériel, d’un mode de réalisation entièrement logiciel (comportant les microprogrammes, les logiciels résidents, les microcodes, etc.) ou d’un mode de réalisation combinant des aspects logiciels et matériels qui peuvent tous être globalement appelés ici "circuit", "module" ou "système". De plus, la présente invention peut prendre la forme d’un produit de programme informatique incorporé dans tout support d’expression tangible disposant d’un code de programme utilisable par ordinateur incorporé dans le support. Étant donné que la présente invention peut être mise en œuvre dans un logiciel, la présente invention peut être incorporée sous forme de code lisible par ordinateur pour être fournie à un appareil programmable sur tout support adapté. Un support tangible ou non transitoire peut comprendre un support de stockage tel qu’un lecteur de disque dur, un dispositif de bande magnétique ou un dispositif de mémoire à semi-conducteurs et analogues. Un support transitoire peut comporter un signal tel qu’un signal électrique, un signal électronique, un signal optique, un signal acoustique, un signal magnétique ou un signal électromagnétique, par exemple un signal hyperfréquence ou RF (radiofréquence). D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. La représente un exemple de système de communication de l’état de la technique comprenant des dispositifs externes de gestion de profils. La représente un exemple de système de communication comprenant un dispositif centralisé de gestion de profils selon un ou plusieurs modes de réalisation de l’invention. La représente un exemple d’ordinogramme d’un procédé de gestion d’un profil de service selon un ou plusieurs modes de réalisation de l’invention. La représente des étapes d’un procédé de gestion d’un profil de service selon un mode de réalisation particulier de l’invention. La représente un mode de réalisation alternatif au mode de réalisation présenté à la . La représente un exemple de dispositif centralisé de gestion de profils pour exécuter une transaction selon un ou plusieurs modes de réalisation de l’invention. Procédé de gestion de profils de service d’un élément sécurisé d’un terminal hôte, le procédé de gestion étant mis en œuvre par un dispositif centralisé de gestion de profils externe au terminal hôte et comprenant : - recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ; - stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ; - détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et - à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service. Procédé selon la revendication 1, dans lequel le dispositif centralisé de gestion de profils reçoit en outre d’autres données de profil destinées à au moins un autre élément sécurisé, dans lequel chaque donnée de profil est reçue avec un identifiant d’un élément sécurisé auquel elle est destinée, dans lequel chaque donnée de profil stockée est en outre stockée en association avec l’identifiant de l’élément sécurisé auquel elle est destinée, et dans lequel la donnée de profil la plus récente parmi les données de profil stockées associées audit service est envoyée avec l’identifiant de l’élément sécurisé auquel elle est destinée. Procédé selon l’une des revendications précédentes, dans lequel chaque donnée de profil stockée est respectivement associée à une donnée de version, dans lequel la donnée de version est un temps de réception par le dispositif centralisé de gestion de profils ou un numéro de version d’un profil associé à la donnée de profil, dans lequel la donnée de profil envoyée correspond à la donnée de profil ayant la donnée de version la plus récente parmi les données de profil stockées associées audit service. Procédé selon l’une des revendications précédentes, dans lequel chaque donnée de profil est reçue avec une donnée d’identification de service respective, le procédé comprenant en outre : - pour chaque donnée de profil reçue et stockée en mémoire, déterminer un service correspondant à partir de la donnée d’identification de service respective reçue avec ladite donnée de profil et stocker la donnée de profil en association avec le service correspondant déterminé. Procédé selon la revendication 4, dans lequel une donnée d’identification de service parmi les données d’identification de service reçues est : - un identifiant du dispositif de traitement depuis lequel la donnée de profil a été reçue ; - une adresse réseau du dispositif de traitement depuis lequel la donnée de profil associée a été reçue ; - un identifiant d’un fournisseur de service gérant un service associé à la donnée de profil reçue ; ou - un identifiant d’un service associé à la donnée de profil reçue. Procédé selon l’une des revendications précédentes, comprenant en outre, pour chaque donnée de profil associée au service reçue : - déterminer un fournisseur de service associé à la donnée de profil et stocker la donnée de profil en association avec le fournisseur de service déterminé ; - à la détection dudit événement, déterminer, à partir d’une base de données, un fournisseur de service courant associé à l’élément sécurisé pour ledit service ; dans lequel la donnée de profil envoyée est la donnée de profil la plus récente parmi les données de profil stockées associées audit service et au fournisseur de service courant associé à l’élément sécurisé pour ledit service. Procédé selon l’une des revendications précédentes, dans lequel la détection de l’événement déclencheur de la mise à jour du profil de service de l’élément sécurisé comprend : - recevoir, du terminal hôte ou d’une plateforme de gestion du terminal hôte, une requête d’interrogation comprenant une information d’identification dudit service donné. Procédé selon l’une des revendications précédentes, dans lequel chaque dispositif de traitement parmi la pluralité de dispositifs de traitement a une première paire de clés asymétriques respective, chaque première paire de clés asymétriques comprenant une clé privée et une clé publique, la clé publique étant partagée entre le dispositif de traitement et le dispositif centralisé de gestion de profils, dans lequel chaque donnée de profil reçue est signée avec la clé privée du dispositif de traitement émetteur, le procédé comprenant en outre, pour chaque donnée de profil reçue : - vérifier, par le dispositif centralisé de gestion de profils, la signature de la donnée de profil à partir de la clé publique du dispositif de traitement émetteur ; et - stocker en mémoire du dispositif centralisé de gestion de profils la donnée de profil reçue uniquement si la vérification est un succès. Procédé selon l’une des revendications précédentes, dans lequel le dispositif centralisé de gestion de profils a une deuxième paire de clés asymétriques, la deuxième paire de clés asymétriques comprenant une clé privée du dispositif centralisé de gestion de profils et une clé publique du dispositif centralisé de gestion de profils, la clé publique de la deuxième paire de clés asymétriques étant partagée entre le dispositif centralisé de gestion de profils et l’élément sécurisé, dans lequel, pour chaque donnée de profil stockée, ladite donnée de profil est signée à l’aide de la clé privée du dispositif centralisé de gestion de profils. Dispositif centralisé de gestion de profils pour gérer des profils de communication d’un élément sécurisé d’un terminal hôte, le dispositif centralisé de gestion de profils étant externe au terminal hôte, le dispositif centralisé de gestion de profils étant configuré pour : - recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ; - stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ; - détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; et - à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service. Système comprenant un terminal hôte ayant un élément sécurisé, un dispositif centralisé de gestion de profils externe au terminal hôte et une pluralité de dispositifs de traitement, dans lequel le dispositif centralisé de gestion de profils est configuré pour : - recevoir, d’une pluralité de dispositifs de traitement, des données de profil correspondant à un même service et destinées à l’élément sécurisé ; - stocker en mémoire des données de profil parmi les données de profil reçues, chaque donnée de profil stockée étant stockée en association avec ledit service ; - détecter un événement déclencheur d’une mise à jour d’un profil de service de l’élément sécurisé pour ledit service ; - à la détection dudit événement, envoyer au terminal hôte une donnée de profil la plus récente parmi les données de profil stockées associées audit service ; et dans lequel l’élément sécurisé est configuré pour : - recevoir la donnée de profil envoyée par le dispositif centralisé de gestion de profils ; et - mettre à jour le profil de service à partir de la donnée de profil reçue. Système selon la revendication 11, dans lequel chaque dispositif de traitement parmi la pluralité de dispositifs de traitement a une première paire de clés asymétriques respective, chaque première paire de clés asymétriques comprenant une clé privée et une clé publique, la clé publique étant partagée entre le dispositif de traitement et le dispositif centralisé de gestion de profils, dans lequel chaque donnée de profil reçue est signée avec la clé privée du dispositif de traitement émetteur, dans lequel le dispositif centralisé de gestion de profils est en outre configuré pour, pour chaque donnée de profil reçue : - vérifier la signature de la donnée de profil à partir de la clé publique du dispositif de traitement émetteur ; et - stocker en mémoire la donnée de profil reçue uniquement si la vérification est un succès. Système selon la revendication 11 ou 12, dans lequel le dispositif centralisé de gestion de profils a une deuxième paire de clés asymétriques, la deuxième paire de clés asymétriques comprenant une clé privée du dispositif centralisé de gestion de profils et une clé publique du dispositif centralisé de gestion de profils, la clé publique de la deuxième paire de clés asymétriques étant partagée entre le dispositif centralisé de gestion de profils et l’élément sécurisé, dans lequel, pour chaque donnée de profil stockée, ladite donnée de profil est signée à l’aide de la clé privée du dispositif centralisé de gestion de profils avant d’être envoyée au terminal hôte. Système selon la revendication 12, dans lequel la clé publique de chaque dispositif de traitement parmi la pluralité de dispositifs de traitement est partagée avec l’élément sécurisé, dans lequel l’élément sécurisé est configuré pour : - à la réception de la donnée de profil signée, vérifier les signatures associées grâce à la clé publique du dispositif de traitement émetteur de la donnée de profil et à la clé publique du dispositif centralisé de gestion de profils ; et - mettre à jour le profil de service à partir de la donnée de profil reçue uniquement si la vérification est un succès. Produit programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 1 à 9, lorsque ce programme est exécuté par un processeur.