Titre de l’invention : Procédé de gestion de profils de service d’un élément sécurisé

Domaine technique

La présente invention concerne la gestion de profils de service dans un élément sécurisé d’un terminal hôte.

Technique antérieure

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 N FC 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’UlCC 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 iUlCC (pour « integrated UICC »). Les principales spécifications d'une carte eUlCC 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 loT, 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 Figure 1 , dans lequel les fonctions de gestion à distance des profils de service sont mises en œuvre par des dispositifs CLPAj externes au terminal hôte, situés dans le réseau de communication. Plus précisément, la Figure 1 représente un terminal hôte 101 comprenant un élément sécurisé 102, par exemple un ellICC, 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 CLPAj 105a, 105b, 105c, comme détaillé ci-dessous.

Le système de la Figure 1 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 CLPAj 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 CLPAj 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 CLPAj 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é.

Exposé de l’invention

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 Figure 1. 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 Figure 1 , 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). Brève description des dessins

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 Figure 1 représente un exemple de système de communication de l’état de la technique comprenant des dispositifs externes de gestion de profils.

La Figure 2 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 Figure 3 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 Figure 4 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 Figure 5 représente un mode de réalisation alternatif au mode de réalisation présenté à la Figure 4.

La Figure 6 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.

Description détaillée

L’invention propose de modifier l’architecture de l’art antérieur pour intégrer un dispositif (ou serveur) externe de gestion des profils configuré pour recevoir, de la part des différents fournisseurs de service, et retransmettre, à un terminal hôte intégrant un élément sécurisé, des données de profil pour installer ou mettre à jour des profils correspondant à différents services de cet élément sécurisé. En d’autres termes, les données de profils ne sont plus directement envoyées des serveurs associés aux différents fournisseurs vers le terminal hôte, mais sont envoyées à un dispositif dit centralisé de gestion de profils, qui en retransmet au moins une partie au terminal hôte. Comme détaillé ci-dessous, une telle architecture permet de gérer efficacement des situations où des données correspondant à un même service sont envoyées par plusieurs serveurs (par exemple dans le cadre d’un changement de fournisseur de service). Le système proposé permet en outre de s’affranchir de la nécessité, pour chaque fournisseur, de disposer d’une certification pour chacun des locaux dans lesquels sont localisés les serveurs. En effet, puisque les données sont envoyées depuis le dispositif centralisé de gestion de profils, seuls les locaux hébergeant ce dernier nécessitent une certification.

La Figure 2 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.

Le système représenté à la Figure 2 comprend un terminal hôte 201 comprenant un élément sécurisé 202, par exemple un eUlCC, et un agent de communication (noté DAG sur la Figure 2) 203. Le terminal hôte 201 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é 202 mémorise typiquement un ou plusieurs profils (appelés aussi « profils de service », ou « abonnements »). Chaque profil est associé à un service fourni par un opérateur appelé « fournisseur de service ». Chaque fournisseur de service peut disposer d’un dispositif (ou serveur) de gestion de profil DPAj 205a, 205b, 205c (DPA pour « Distant Profile Administrator », ou « Administrateur de profil distant » en français, même si toute autre terminologie peut être utilisée), sur lequel sont mémorisés des profils associés à ce service. Par exemple, un dispositif de gestion de profil DPAj 205a, 205b, 205c peut stocker la version la plus récente d’un profil pour le service concerné, et éventuellement des versions antérieures de ce profil (par exemple, chaque nouvelle version disponible du profil de service peut être stockée dans le dispositif de gestion de profil DPAj 205a, 205b, 205c en plus ou à la place de la version précédente).

L’agent de communication 203 est situé dans le système d’exploitation du terminal hôte 201 ou dans l’élément sécurisé 202 du terminal hôte 201 , et réalise l’interface entre l’élément sécurisé 202 et le dispositif centralisé de gestion de profils (noté TS sur la Figure 2) 206 dont les fonctions sont détaillées ci-dessous. Alternativement, le terminal hôte peut être géré par une plateforme distante de gestion du terminal 204 (notée DMP, pour « Device Management Platform » en anglais). Dans ce cas, l’agent de communication 203 réalise l’interface entre l’élément sécurisé 202 et la plateforme distante de gestion du terminal 204.

Le système de la Figure 2 comprend en outre un dispositif centralisé de gestion de profils TS 206. Ce dispositif centralisé de gestion de profils 206 est configuré pour recevoir, de la part des dispositifs externes de gestion de profils DPAj 205a, 205b, 205c, des données associées à des profils de service (appelées « données de profil ») préparés par ceux-ci. Les données de profil envoyées par les dispositifs de gestion de profils DPAj 205a, 205b, 205c peuvent être des profils complets (i.e. un ensemble de données constituant un profil), par exemple des nouveaux profils à installer, ou des données pour mettre à jour des profils déjà installés sur l’élément sécurisé 202. Par souci de simplification, le terme « mise à jour » d’un profil est utilisé par la suite pour désigner à la fois l’installation d’un nouveau profil sur l’élément sécurisé 202 ou la mise à jour d’un profil déjà installé sur l’élément sécurisé 202.

Par exemple, chaque dispositif externe de gestion de profils DPAj 205a, 205b, 205c peut envoyer au dispositif centralisé de gestion de profils 206 des données de profil correspondant à un ou plusieurs profils pour les services qu’ils mettent en œuvre.

Dans un ou plusieurs modes de réalisation, les données de profil peuvent être envoyées par les dispositifs de gestion de profils DPAj 205a, 205b, 205c vers le dispositif centralisé de gestion de profils 206 en association avec un identifiant de l’élément sécurisé 202 auquel elles sont destinées. En effet, même si la Figure 2 ne représente qu’un seul élément sécurisé 202, le dispositif centralisé de gestion de profils 206 peut recevoir des données de profil pour les éléments sécurisés de plusieurs terminaux hôtes, et/ou pour plusieurs éléments sécurisés d’un même terminal hôte. Dans ce cas, il est nécessaire pour le dispositif centralisé de gestion de profils 206 de savoir à quel élément sécurisé est destinée une donnée de profil qu’il reçoit.

En outre, dans un ou plusieurs modes de réalisation, une donnée de profil peut être envoyée par un dispositif de gestion de profils DPAj 205a, 205b, 205c vers le dispositif centralisé de gestion de profils 206 en association avec une donnée d’identification de service. Cette donnée d’identification de service permet au dispositif centralisé de gestion de profils 206 de déterminer à quel service la donnée de profil reçue correspond. La donnée d’identification de service peut être par exemple :

- un identifiant du dispositif externe de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été envoyée ;

- une adresse réseau (par exemple une adresse IP) du dispositif externe de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été envoyée ;

- un identifiant de fournisseur de service gérant le dispositif externe de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été envoyée ; ou

- un identifiant du service associé à la donnée de profil reçue.

Dans les trois premiers exemples, le dispositif centralisé de gestion de profils 206 peut en outre avoir accès à une table (par ex. stockée dans une mémoire du dispositif centralisé de gestion de profils 206 ou sur un serveur distant) ou une base de données associant l’identifiant ou l’adresse à un identifiant du service associé à la donnée de profil reçue. À l’aide de cette table, le dispositif centralisé de gestion de profils 206 peut déterminer, à partir de la donnée d’identification de service reçue, le service associé à la donnée reçue. Bien entendu, d’autres exemples que ceux précités sont possibles, dès lors que la donnée d’identification de service permet de déterminer le service associé à la donnée de profil reçue.

Lorsque le dispositif centralisé de gestion de profils 206 reçoit une donnée de profil d’un dispositif de gestion de profils DPAj 205a, 205b, 205c, il la stocke en mémoire, en association avec le service auquel elle est associée. Dans un ou plusieurs modes de réalisation, cette association peut être effectuée à partir de l’identifiant de service.

Il est noté que pour un même service, plusieurs données de profil peuvent être reçues de dispositifs de gestion de profils DPAj 205a, 205b, 205c différents. Une telle situation peut se produire, par exemple, lorsque l’utilisateur change de fournisseur de service. Par exemple, un premier dispositif de gestion de profils (par exemple DPAi 205a) peut envoyer une première donnée de profil associée à un service donné avant le changement de fournisseur, et un deuxième dispositif de gestion de profils (par exemple DPA2 205b) peut envoyer une deuxième donnée de profil associée au même service après le changement de fournisseur.

Dans un ou plusieurs modes de réalisation, chaque dispositif de gestion de profils DPAj 205a, 205b, 205c dispose d’une paire respective de clés asymétriques, chaque paire étant composée d’une clé publique KcpA, _P ub,i et d’une clé privée KcpA, _P riv,i. La clé publique KcpA, _P ub,i de chaque dispositif de gestion de profils DPAj 205a, 205b, 205c est partagée avec le dispositif centralisé de gestion de profils 206 (i.e. le dispositif centralisé de gestion de profils 206 connaît la clé publique K _C pA, _P ub,i de chaque dispositif de gestion de profils DPAj 205a, 205b, 205c). Dans certains modes de réalisation, la clé publique KcpA, _P ub,i d’un dispositif de gestion de profils DPAj 205a, 205b, 205c peut être envoyée dans un certificat numérique délivré par un organisme de certification au dispositif de gestion de profils DPAj 205a, 205b, 205c. Un dispositif de gestion de profils DPAj 205a, 205b, 205c peut alors envoyer, au dispositif centralisé de gestion de profils 206, une donnée de profil signée, avec une signature générée à l’aide de la clé privée K _C pA, _P nv,i du dispositif de gestion de profils DPAj 205a, 205b, 205c. Lorsque le dispositif centralisé de gestion de profils 206 reçoit la donnée de profil, il vérifie la signature : il calcule à son tour une signature à partir de cette donnée et de la clé publique KcpA, _P ub,i du dispositif de gestion de profils DPAj 205a, 205b, 205c depuis lequel il a reçu la donnée de profil, puis compare les deux signatures. Si les deux signatures concordent, cela indique que la donnée de profil a bien été envoyée par une entité « autorisée », et la donnée est stockée dans une mémoire du dispositif centralisé de gestion de profils 206. Si les deux signatures ne concordent pas, la donnée de profil est supprimée et n’est pas stockée en mémoire du dispositif centralisé de gestion de profils 206. Cela permet de vérifier l’intégrité et l’origine (traçabilité) des données reçues.

Puis, le dispositif centralisé de gestion de profils 206 peut envoyer une ou plusieurs données de profil parmi les données de profil qu’il a stockées en mémoire, directement à l’agent de communication 203 (par exemple suite à une requête directe de l’agent 203 au dispositif centralisé 206), ou en variante à la plateforme distante de gestion du terminal 204 (qui les transmet à l’agent de communication 203). L’agent de communication 203 transmet alors le ou les données de profil à l’élément sécurisé 202, qui peut installer ou mettre à jour un ou plusieurs profils correspondants. Les données de profil peuvent être envoyées en association avec une donnée d’identification de service (détaillée ci-dessus), afin que l’élément sécurisé puisse déterminer le profil à mettre à jour, et/ou en association avec le dispositif de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été envoyée (cela est particulièrement avantageux lorsque la donnée est signée à l’aide d’une clé privée KcpA, _P nv,i du dispositif de gestion de profils émetteur, comme détaillé ci-dessous, pour que l’élément sécurisé puisse vérifier la signature à l’aide de la clé publique KcpA, _P ub,i du dispositif de gestion de profils émetteur). En alternative ou en complément, les données de profil peuvent être envoyées en association avec un identifiant de l’élément sécurisé (cela est particulièrement avantageux lorsque le terminal comprend plusieurs éléments sécurisés 202, pour que l’agent de communication 203 envoie la donnée à l’élément sécurisé 202 comprenant le profil concerné par la mise à jour).

Comme mentionné ci-dessus, le dispositif centralisé de gestion de profils 206 peut stocker plusieurs données de profil associées à un même service et reçues de plusieurs dispositifs de gestion de profils DPAj 205a, 205b, 205c respectifs. Il peut donc être nécessaire pour le dispositif centralisé de gestion de profils 206 de savoir, pour un service donné, quelle donnée de profil associée à ce service envoyer à l’agent de communication 203 ou à la plateforme distante de gestion du terminal 204. Dans un ou plusieurs modes de réalisation, pour un service donné, c’est la donnée de profil la plus récente parmi les données de profil stockées associées à ce service qui est envoyée. Par exemple, il est possible d’enregistrer, pour chaque donnée de profil stockée, sa date de réception ou toute information représentative de cette date par le dispositif centralisé de gestion de profils 206, et la donnée de profil envoyée est celle ayant la date de réception la plus récente (i.e. la dernière donnée de profil reçue). Alternativement, chaque donnée de profil stockée peut être enregistrée avec un numéro de version du profil correspondant, et la donnée de profil envoyée est celle correspondant à la version la plus récente.

Lorsque le dispositif centralisé de gestion de profils 206 gère des profils pour une pluralité d’éléments sécurisés, la donnée de profil peut en outre être stockée en association avec l’identifiant de l’élément sécurisé auquel la donnée de profil est destinée, et la donnée de profil envoyée peut être la donnée de profil la plus récente parmi les données de profil stockées associées à ce service et à l’identifiant de l’élément sécurisé 202. Alternativement, la donnée de profil peut être envoyée avec un identifiant du fournisseur du service associé, et le dispositif centralisé de gestion de profils 206 peut avoir accès à une table ou une base de données qui met en lien un élément sécurisé avec une liste de fournisseurs de service auprès desquels l’utilisateur a souscrit des abonnements. La donnée de profil envoyée peut être la donnée de profil la plus récente parmi les données de profil stockées pour un service donné et fournies par le fournisseur de ce service associé à l’élément sécurisé 202. Selon une autre alternative, la mémoire du dispositif centralisé de gestion de profils 206 peut être partitionnée en zones mémoires selon les fournisseurs de service, chaque zone mémoire correspondant à un fournisseur respectif, et lorsque l’élément sécurisé envoie une requête pour récupérer une mise à jour d’un de ses profils (mode « pull » détaillé ci-dessous), il reçoit en réponse une donnée de profil parmi les données de profil stockées dans les zones mémoires associées aux fournisseurs de services auprès desquels l’utilisateur du terminal hôte 201 a souscrit un abonnement. Pour cela, il est possible d’utiliser des pointeurs qui renvoient vers les adresses respectives des zones mémoires associées aux fournisseurs de services auprès desquels l’utilisateur du terminal hôte 201 a souscrit un abonnement.

Dans un ou plusieurs modes de réalisation, le dispositif centralisé de gestion de profils 206 dispose d’une paire de clés asymétriques, la paire étant composée d’une clé publique K _T s, _P ub et d’une clé privée Kïs.priv. La clé publique Kïs.pub du dispositif centralisé de gestion de profils 206 est partagée avec l’élément sécurisé 202. Dans certains modes de réalisation, la clé publique K _T s, _P ub du dispositif centralisé de gestion de profils 206 peut être envoyée dans un certificat numérique, lequel est délivré par un organisme de certification au dispositif centralisé de gestion de profils 206. Le dispositif centralisé de gestion de profils 206 peut signer à son tour la donnée de profil (éventuellement préalablement signée à l’aide de la clé privée KcpA, _P riv,i du dispositif de gestion de profils DPAj 205a, 205b, 205c émetteur) avec sa clé privée Kïs.priv, et envoyer la donnée signée (éventuellement doublement signée) à la plateforme de gestion du terminal 204 ou à l’agent de communication 203 du terminal 201. Lorsque l’élément sécurisé 202 reçoit la donnée de profil, il vérifie à son tour la signature : il calcule à son tour une signature à partir de cette donnée et de la clé publique Kïs.pub du dispositif centralisé de gestion de profils 206, puis compare les deux signatures. Si celles-ci concordent, le profil concerné de l’élément sécurisé est mis à jour à partir de la donnée reçue. Sinon, le profil n’est pas mis à jour et la donnée de profil reçue est supprimée. En outre, lorsque la donnée reçue par l’élément sécurisé 202 est doublement signée (i.e. à partir de la clé privée K _C pA,priv,i du dispositif de gestion de profils DPAj 205a, 205b, 205c émetteur et de la clé privée KTS.PHV du dispositif centralisé de gestion de profils 206), il est nécessaire que l’élément sécurisé ait également connaissance de la clé publique KcpA.pub.i du dispositif de gestion de profils DPAj 205a, 205b, 205c émetteur. Dans certains modes de réalisation, la clé publique K _C pA,pub,i du dispositif de gestion de profils DPAj 205a, 205b, 205c peut être envoyée par le dispositif centralisé de gestion de profils 206 à l’élément sécurisé 202 (via la plateforme de gestion du terminal 204 ou à l’agent de communication 203 du terminal 201). En outre, cette clé publique KcpA.pub.i du dispositif de gestion de profils DPAj 205a, 205b, 205c peut être envoyée par le dispositif centralisé de gestion de profils 206 dans son certificat numérique éventuellement signé par le dispositif centralisé de gestion de profils 206 à l’aide de sa clé privée KTS.PHV. Lorsque les données sont doublement signées, l’élément sécurisé 202 vérifie les deux signatures, l’une à partir de la clé publique KcpA.pub.i du dispositif de gestion de profils DPAj 205a, 205b, 205c émetteur, et l’autre à partir de la clé publique Kïs.pub du dispositif centralisé de gestion de profils 206. Si les deux vérifications sont des succès, alors le profil concerné de l’élément sécurisé est mis àjour à partir de la donnée reçue. Sinon, le profil n’est pas mis à jour et la donnée de profil reçue est supprimée. Cette double vérification permet d’une part de vérifier que la donnée de profil provient d’une entité « autorisée », et d’autre part qu’elle n’a pas été modifiée depuis son envoi par le dispositif externe de gestion de profils DPAj 205a, 205b, 205c émetteur.

Il est noté que les dispositifs externes de gestion de profils DPAj 205a, 205b, 205c ne communiquent pas directement avec le terminal hôte 201 ou avec la plateforme de gestion du terminal 204. Les profils sont envoyés des dispositifs externes de gestion de profils DPAj 205a, 205b, 205c au dispositif centralisé de gestion de profils 206, qui les transmet à son tour à destination du terminal hôte 201. Ainsi, le terminal hôte 201 (ou la plateforme distante de gestion du terminal 204) ne reçoit des profils que d’une seule entité, ce qui résout les problèmes de certification mentionnés plus haut et facilite la gestion des changements de fournisseurs de service.

En effet, il n’est plus nécessaire de certifier tous les locaux où sont localisés les dispositifs externes de gestion de profil DPAj 205a, 205b, 205, mais uniquement les locaux où est localisé le dispositif centralisé de gestion de profils 206, puisque c’est la seule entité qui envoie des données à destination de l’élément sécurisé 202.

En outre, selon certains modes de réalisation, l’acquisition de profils se fait en mode « pull », c’est-à-dire à la demande de l’élément sécurisé 202. Dans ces modes de réalisation, l’élément sécurisé 202 envoie, via l’agent de communication 203, une requête d’interrogation pour savoir si une donnée de profil (correspondant à un nouveau profil / une nouvelle version d’un profil) est disponible. Dans le système de la Figure 1 , cette requête est envoyée au dispositif externe de gestion de profil CLPAj 105a, 105b, 105c du fournisseur de service associé au profil concerné. Toutefois, il est possible pour l’utilisateur de changer de fournisseur de service, ou que le fournisseur de service change de dispositif externe de gestion de profil CLPAj 105a, 105b, 105c. Dans de tels cas, il peut arriver que la requête d’interrogation ne soit pas envoyée au dispositif externe de gestion de profil CLPAj 105a, 105b, 105c correct. En effet, il n’est pas prévu de mécanisme pour gérer dynamiquement, dans l’élément sécurisé 202, les changements de fournisseur de service ou d’adresse des serveurs des fournisseurs de service pour un service donné. Dans le système de la Figure 2, ce problème ne se pose plus, puisque la requête d’interrogation est envoyée au dispositif centralisé de gestion de profils 206 (comme détaillé en référence aux Figures 4 et 5), dont l’adresse réseau est fixe. Le changement de fournisseur se fait de manière transparente pour le terminal 201 , et la requête d’interrogation ne peut pas être envoyée à la mauvaise entité.

La Figure 3 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. Lors d’une première étape 301 , le dispositif centralisé de gestion de profils 206 reçoit une donnée de profil pour un service donné.

De manière optionnelle, cette donnée de profil est signée à l’aide de la clé privée KcpA.priv du dispositif de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été reçue, comme détaillé ci-dessus. La signature peut alors être vérifiée (étape 302) à l’aide de la clé publique KcpA, _P ub,i du dispositif de gestion de profils DPAj 205a, 205b, 205c depuis lequel la donnée de profil a été reçue. Si la vérification échoue (étape 302, flèche « K » sur la Figure 3), la donnée est supprimée (étape 303). Si la vérification est un succès (étape 302, flèche « O » sur la Figure 3), la donnée est stockée dans une mémoire du dispositif centralisé de gestion de profils 206 en association avec le service concerné (étape 304). Tant qu’aucun événement déclencheur d’une mise à jour d’un profil de l’élément sécurisé associé au service concerné n’est détecté (étape 305, flèche « N »), le dispositif centralisé de gestion de profils 206 continue de recevoir des données de profil pour le service concerné (étape 301), de les vérifier éventuellement (étape 302) et de les supprimer (étape 303) ou les stocker en mémoire (étape 304). Lorsqu’un événement déclencheur d’une mise à jour d’un profil de l’élément sécurisé associé au service concerné est détecté (étape 305, flèche « Y »), la donnée de profil la plus récente parmi les données de profil stockées associée au service concerné est envoyée à l’agent de communication 203 ou à la plateforme distante de gestion du terminal 204 (étape 307). Optionnellement, la donnée de profil peut être signée à l’aide de la clé privée K _T s, _P nv du dispositif centralisé de gestion de profils 206 (étape 306) avant d’être envoyée à l’étape 307, comme détaillé ci-dessus.

L’événement déclencheur d’une mise à jour d’un profil de l’élément sécurisé peut être n’importe quel événement entraînant l’envoi de la donnée de profil la plus récente par le dispositif centralisé de gestion de profils 206 vers l’agent de communication 203 ou à la plateforme distante de gestion du terminal 204. Dans certains modes de réalisation, cet événement déclencheur peut être la réception, par le dispositif centralisé de gestion de profils 206, d’une requête d’interrogation de la part de l’élément sécurisé 202 et envoyée via l’agent de communication 203, pour savoir si une donnée de profil associée à un service donné est disponible (une telle requête d’interrogation peut notamment comprendre un identifiant du service concerné). Ces modes de réalisation correspondent à un « mode pull » et des exemples sont détaillés aux Figures 4 et 5. Alternativement, cet événement déclencheur peut correspondre à la réception, de la part du dispositif de gestion de profils DPAj 205a, 205b, 205c qui envoie la donnée, que le profil doit être mis à jour au plus vite ou dès réception de la donnée en provenance du dispositif de gestion de profil DPAj 205a, 205b, 205c. Selon une autre alternative, les événements déclencheurs correspondent à des instants prédéfinis (par exemple de manière périodique) auxquels la mise à jour d’un profil doit être effectuée (par exemple, toutes les semaines, ou à chaque redémarrage du terminal hôte, etc.).

La Figure 4 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.

Ce mode de réalisation correspond à un mode « pull », dans lequel l’agent de communication 203 du terminal hôte 201 est configuré pour envoyer des requêtes d’interrogation au dispositif centralisé de gestion de profils 206 (éventuellement via la plateforme distante de gestion du terminal 204) pour récupérer en retour une donnée de profil afin de mettre à jour un profil de l’élément sécurisé 202 du terminal hôte 201. En outre, dans le mode de réalisation de la Figure 4, il est supposé que le terminal hôte est géré par une plateforme distante de gestion du terminal 204.

À l’étape 401 , un dispositif de gestion de profils DPAj 205a, 205b, 205c envoie (« pousse ») une donnée de profil au dispositif centralisé de gestion de profils 206 (noté TS sur la figure 4). Comme détaillé ci-dessus, cette donnée de profil peut être signée. Dans ce cas, la signature de la donnée de profil peut être vérifiée (étape 402), et stockée en mémoire du dispositif centralisé de gestion de profils 206 uniquement si la vérification est un succès. La donnée de profil est stockée en association avec le service correspondant, et en association avec une donnée de version (numéro de version du profil associé à la donnée de profil reçue ou date de réception de la donnée de profil par exemple). En outre, la donnée de profil peut éventuellement être signée une deuxième fois à l’aide de la clé privée Kïs.priv du dispositif centralisé de gestion de profils 206 (étape 403). La donnée de profil signée / doublement signée est ensuite encapsulée dans un paquet (étape 404), qui est stocké dans le dispositif centralisé de gestion de profils 206. Dans un ou plusieurs modes de réalisation, le paquet peut en outre comprendre une donnée d’identification de service et/ou un identifiant de l’élément sécurisé auquel elle est destinée. A l’étape optionnelle 405, le dispositif centralisé de gestion de profils 206 envoie une notification au dispositif de gestion de profils DPAj 205a, 205b, 205c pour l’informer du résultat du traitement effectué (étapes 402 à 403) sur la donnée de profil préalablement reçue. En quelque sorte, il acquitte la réception et le stockage de la donnée de profil reçue.

Les étapes 401 à 405 peuvent être réitérées pour une pluralité de données de profil reçues de différents dispositifs de gestion de profils DPAj 205a, 205b, 205c et pour différents services. Après quelques itérations des étapes 401 à 405, le dispositif centralisé de gestion de profils 206 peut avoir en mémoire une pluralité de paquets destinés à un même élément sécurisé 202, parmi lesquels au moins deux paquets sont associés à un même service et sont issus de deux dispositifs de gestion de profils DPAj 205a, 205b, 205c différents.

À l’étape 406, l’agent de communication 203 du terminal hôte 201 (noté TERM sur la figure 4) envoie une requête d’interrogation vers la plateforme distante de gestion du terminal 204 (noté DMP sur la figure 4), qui est transmise à l’étape 407 au dispositif centralisé de gestion de profils 206. La requête d’interrogation peut, selon les modes de réalisation, comprendre un identifiant de l’élément sécurisé et/ou un identifiant du service pour lequel il est demandé si une mise à jour est disponible. Des requêtes d’interrogation peuvent être, par exemple, envoyées de manière périodique (par exemple chaque semaine) ou suite à l’action d’un utilisateur du terminal hôte 201.

Dans un ou plusieurs modes de réalisation, la requête d’interrogation peut être signée à l’aide d’une clé privée K _S E, _P riv de l’élément sécurisé, la clé privée KsE.priv faisant partie d’une paire de clés asymétriques (K _S E, _P riv, KsE, _P ub) composée d’une clé privée KsE, _P riv et d’une clé publique KsE, _P ub associées à l’élément sécurisé 202. La clé publique KsE, _P ub de l’élément sécurisé 202 peut être partagée avec le dispositif centralisé de gestion de profils 206. À la réception de la requête d’interrogation (étape 407), le dispositif centralisé de gestion de profils 206 peut vérifier la signature de la requête à l’étape 408 avec la clé publique K _S E, _P ub de l’élément sécurisé 202. Si la vérification échoue, la requête d’interrogation est ignorée. Si la vérification est un succès, le dispositif centralisé de gestion de profils 206 envoie à la plateforme distante de gestion du terminal 204 la donnée de profil la plus récente parmi les données de profil stockées sur le dispositif centralisé de gestion de profils 206 et associées au service concerné (étape 409). Le service concerné peut être déterminé, par exemple, à partir d’un identifiant de service compris dans la requête d’interrogation. Alternativement, la requête d’interrogation ne comprend pas d’identifiant de service et à l’étape 409, le dispositif centralisé de gestion de profils 206 envoie, pour chaque service pour lequel il stocke une donnée de profil, la donnée de profil la plus récente associée à ce service. En d’autres termes, le dispositif centralisé de gestion de profils 206 envoie une pluralité de données de profil, chacune étant la donnée de profil la plus récente pour un service donné. À l’étape 410, la ou les données de profil sont envoyées de la plateforme distante de gestion du terminal 204 vers l’agent de communication 203 du terminal 201 , pour être ensuite transmises à l’élément sécurisé 202. L’élément sécurisé peut ensuite mettre à jour le ou les profils correspondant à la ou les données de profil reçues, pour autant que la ou les signatures associées à la ou les données de profil reçues soient valides.

La Figure 5 représente un mode de réalisation alternatif au mode de réalisation présenté à la Figure 4. Selon ce mode de réalisation, le terminal hôte n’est pas géré par une plateforme distante de gestion du terminal 204, et l’agent de communication 203 communique directement avec le dispositif centralisé de gestion de profils 206.

Les étapes 401 à 405 et 408 sont les mêmes qu’à la Figure 4. Les étapes 506 et 509 correspondent respectivement aux étapes 406-407 d’une part, et 409-410 d’autre part de la Figure 4. En d’autres termes, à l’étape 506, la requête d’interrogation est envoyée directement de l’agent de communication 203 du terminal hôte 201 (noté TERM sur la figure 5) vers le dispositif centralisé de gestion de profils 206 (noté TS sur la figure 5), et à l’étape 509, la ou les données de profil sont envoyées directement du dispositif centralisé de gestion de profils 206 vers l’agent de communication 203 du terminal hôte 201. Comme à la Figure 4, la ou les données de profil reçues par l’agent de communication 203 sont ensuite transmises à l’élément sécurisé 202. L’élément sécurisé peut ensuite mettre à jour le ou les profils correspondant à la ou les données de profil reçues, pour autant que la ou les signatures associées à la ou les données de profil reçues soient valides.

La Figure 6 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.

Dans ce mode de réalisation, le dispositif 600 comprend une mémoire 605 (noté MEM sur la figure 6) pour stocker des instructions permettant la mise en œuvre du procédé, les données de profil reçues, et des données temporaires pour réaliser les différentes étapes du procédé tel que décrit précédemment.

Le dispositif comporte en outre un circuit 604 (noté PROC sur la figure 6). Ce circuit peut être, par exemple :

- un processeur apte à interpréter des instructions sous la forme de programme informatique, ou

- une carte électronique dont les étapes du procédé de l’invention sont décrites dans le silicium, ou encore

- une puce électronique programmable comme une puce FPGA (pour « Field- Programmable Gate Array » en anglais), comme un SOC (pour « System On Chip » en anglais) ou comme un ASIC (pour « Application Specific Integrated Circuit » an anglais).

Les SOC ou système sur puce sont des systèmes embarqués qui intègrent tous les composants d’un système électronique dans une puce unique. Un ASIC est un circuit électronique spécialisé qui regroupe des fonctionnalités sur mesure pour une application donnée. Les ASIC sont généralement configurés lors de leur fabrication et ne peuvent être que simulés par l’utilisateur. Les circuits logiques programmables de type FPGA (Field-Programmable Gate Array) sont des circuits électroniques reconfigurables par l’utilisateur.

Le dispositif 600 comporte au moins une interface d’entrée 603 (noté INP sur la figure 6) pour la réception de données de profil depuis un dispositif de gestion de profils DPAj 205a, 205b, 205c, et une interface de sortie 606 (noté OUT sur la figure 6) pour la fourniture de données de profil à la plateforme de gestion du terminal 204 ou à l’agent de communication 203 du terminal 201. Enfin, le dispositif centralisé peut comporter, pour permettre une interaction aisée avec un utilisateur, un écran 601 et un clavier 602. Bien entendu, le clavier est facultatif, notamment dans le cadre d’un dispositif centralisé ayant la forme d’une tablette tactile, par exemple.

En fonction du mode de réalisation, le dispositif 600 peut être un ordinateur, un réseau d’ordinateurs, un composant électronique, ou un autre appareil comportant un processeur couplé de manière opérationnelle à une mémoire, ainsi que, selon le mode de réalisation choisi, une unité de stockage de données, et d'autres éléments matériels associés comme une interface de réseau et un lecteur de support pour lire un support de stockage amovible et écrire sur un tel support (non représentés sur la figure). Le support de stockage amovible peut être, par exemple, un disque compact (CD), un disque vidéo/polyvalent numérique (DVD), un disque flash, une clé USB, etc.

En fonction du mode de réalisation, la mémoire, l’unité de stockage de données ou le support de stockage amovible contient des instructions qui, lorsqu'elles sont exécutées par le circuit de commande 604, amènent ce circuit de commande 604 à effectuer ou contrôler les parties interface d’entrée 603, interface de sortie 606, stockage de données dans la mémoire 605 et/ou traitement de données des exemples de mise en œuvre du procédé proposé décrits dans les présentes.

Le circuit de commande 604 peut être un composant implémentant le contrôle des unités 603, 605 et 606 du dispositif 600.

En outre, le dispositif 600 peut être mis en œuvre sous forme logicielle, auquel cas il prend la forme d’un programme exécutable par un processeur, ou sous forme matérielle (ou « hardware »), comme un circuit intégré spécifique application (ASIC), un système sur puce (SOC), ou sous forme d'une combinaison d'éléments matériels et logiciels, comme par exemple un programme logiciel destiné à être chargé et exécuté sur un composant électronique décrit ci-avant (ex. FPGA, processeur). Le dispositif 600 peut également utiliser des architectures hybrides, comme par exemple des architectures basées sur un CPU+FPGA, un GPU (Graphics Processing Unit) ou un MPPA (Multi-Purpose Processor Array).

Par ailleurs, le schéma fonctionnel présenté sur la Figure 3 est un exemple typique d’un programme dont certaines instructions peuvent être réalisées auprès du dispositif centralisé de gestion de profils décrit. À ce titre, la Figure 3 peut correspondre à l’organigramme de l’algorithme général d’un programme informatique au sens de l’invention. Bien que la présente invention ait été décrite ci-dessus en référence à des modes de réalisation spécifiques, la présente invention n’est pas limitée à ces modes de réalisation spécifiques, et des modifications, qui se trouvent dans la portée de la présente invention, seront visibles pour un homme du métier. De nombreuses autres modifications et variations s’imposeront à ceux qui sont versés dans l’art en se référant aux modes de réalisation illustratifs ci-dessus, qui ne sont donnés qu’à titre d’exemple et qui ne viennent pas limiter la portée de l’invention, celle-ci étant déterminée uniquement par les revendications annexées. En particulier, les différentes caractéristiques des différents modes de réalisation peuvent être échangées, le cas échéant.