Brevet FR3160843A1 — publié le 20251003

La présente invention concerne un procédé, un programme informatique (4), un support de données lisible par ordinateur (5), un dispositif utilisateur (2) avec un ensemble de dispositifs (8) sur lequel un élément sécurisé (9), en particulier une eUICC, est installé, et un agencement de configuration (1) pour des dispositifs utilisateurs (2), par exemple des dispositifs utilisateurs mobiles (2) destinés à participer à un réseau de télécommunications, le procédé comprenant les étapes suivantes : spécification d’un ensemble de données de commande (D) avec des commandes de fonctionnement (B) pour le dispositif utilisateur (2) ; vérification d’une liaison (W) entre l’ensemble de dispositifs (8) et l’élément sécurisé (9) ; et le refus d’au moins une des commandes de fonctionnement (B) si la vérification a montré qu’il n’y a aucune liaison (W) autorisée. Figure pour l’abrégé : Fig. 1 Procédé de configuration d’un dispositif utilisateur, ainsi que celui-ci avec un programme informatique, un support de données lisible par ordinateur et un agencement pour sa configuration Domaine de l’invention La présente invention concerne la liaison d’éléments sécurisés intégrés avec des ensembles de dispositifs utilisateurs. L’élément sécurisé intégré peut notamment être une carte de circuit intégré universelle ( embedded Universal Integrated Circuit Card – eUICC). En particulier, l’invention concerne un procédé de configuration d’un dispositif utilisateur, par exemple d’un dispositif utilisateur mobile destiné à participer à un réseau de télécommunications, comprenant un ensemble de dispositifs sur lequel est installé un élément sécurisé, en particulier une eUICC, un programme informatique, un support de données lisible par ordinateur, un dispositif utilisateur, en particulier un dispositif utilisateur mobile destiné à participer à un réseau de communications, et un agencement de configuration pour la configuration de dispositifs utilisateurs. Contexte de l’invention Les procédés de manipulation d’éléments sécurisés intégrés, tels que les eUICC, ainsi que les programmes informatiques, les supports de données lisibles par ordinateur, les dispositifs utilisateurs destinés à participer à des réseaux de communication et les réseaux de communication sont connus de l’état de la technique. Par exemple, sur les eUICC, par exemple sur les dispositifs utilisateurs mobiles tels que les téléphones portables, les smartphones, les tablettes ou similaires, les caractéristiques d’identification des utilisateurs des dispositifs utilisateurs sont gérées. Sur une eUICC, cela prend généralement la forme de modules d’identité d’abonnés intégrés ( embedded Subscriber Identity Module – eSIM) correspondants. Cette procédure est nécessaire pour répondre aux exigences de sécurité nécessaires à la gestion des éléments d’identification. Cela nécessite une instance de confiance (trusted party) qui peut être fournie sur les eUICC et/ou les serveurs, tels que les serveurs de téléchargement eSIM, à partir desquels les ensembles de données eUICC peuvent être obtenus ou gérés en tant que plates-formes de préparation des données du gestionnaire d’abonnement de confiance ( Subscription Manager Data Preparation platform – SM-DP+) tout en répondant aux exigences de sécurité respectives. Les éléments sécurisés ont généralement une structure système avec un système d’exploitation afin qu’ils puissent interagir avec les ensembles de dispositifs des terminaux sur lesquels ils sont implémentés. Le système d’exploitation peut être utilisé pour accéder à des zones de mémoire, généralement de la mémoire non volatile, d’éléments sécurisés et pour manipuler, gérer et interroger les informations qui y sont stockées, telles que les caractéristiques d’identification. Par exemple, cela se fait à l’aide d’éléments de données de protocoles d’application correspondants ( Application Protocol Data Unit – APDU ), qui transmettent des commandes unidirectionnelles aux éléments sécurisés via une interface de connexion, qui sont ensuite exécutées par ceux-ci. Le document EP 4113342 A1 concerne un procédé, une structure de données et un agent de mise à jour pour la mise en œuvre d’un schéma de téléchargement d’une image de système d’exploitation vers un élément sécurisé. L’agent de mise à jour reçoit un package d’installation d’un périphérique externe pour installer un système d’exploitation sur l’élément sécurisé. L’agent de mise à jour demande le contrôle de l’élément sécurisé et charge le système d’exploitation reçu avec le package d’installation dans l’élément sécurisé, après quoi le contrôle de l’élément sécurisé est transféré au système d’exploitation. Le document EP 2862340 B1 concerne une station mobile dotée d’un terminal et d’un élément de sécurité amovible ou implémenté de manière permanente pouvant fonctionner dans le terminal, une liaison étant établie entre le terminal et l’élément de sécurité et pouvant être vérifiée au moyen d’une clé secrète et de la clé de vérification. Le terminal comprend un environnement d’exécution sécurisé et la clé de vérification est stockée dans l’environnement d’exécution sécurisé. D’après le document US 20200382957 A1, un procédé permettant d’établir une connexion sécurisée entre un élément sécurisé d’un dispositif utilisateur et un nœud dans un réseau au moyen d’un échange et d’une vérification de jetons est connu. À l’origine, les modules d’identité pour les dispositifs utilisateurs mobiles étaient mécaniquement interchangeables en tant que cartes d’identité d’abonné (cartes SIM) ou transférables d’un dispositif utilisateur à un autre, dans la mesure où le facteur de forme respectif de la carte SIM le permettait. En intégrant des cartes SIM en tant qu’eSIM sur des eUICC, elles ne peuvent plus être attribuées à un utilisateur et/ou à un fournisseur de services de télécommunications en fonction de leurs caractéristiques externes et peuvent donc être insérées dans un dispositif utilisateur spécifique prévu afin qu’elles puissent développer toute leur gamme de fonctions. Les processus, programmes informatiques, supports de données lisibles par ordinateur, dispositifs utilisateurs et réseaux de communication susmentionnés ne permettent pas une attribution satisfaisante entre l’élément sécurisé et le terminal. L’objet de la présente invention est d’améliorer l’interaction entre les éléments sécurisés et les dispositifs utilisateurs. En particulier, un objet de la présente invention est d’assurer une interaction sécurisée et fonctionnellement fiable entre des éléments sécurisés et un dispositif utilisateur. En outre, un objet de la présente invention est de permettre une attribution spéciale d’éléments sécurisés à certains dispositifs utilisateurs prévus. Cette tâche est résolue par l’objet des revendications indépendantes. Des modes de réalisation exemplaires résultent des revendications dépendantes et de la description suivante. Les caractéristiques décrites ici en ce qui concerne les procédés et les étapes de procédé correspondantes peuvent être mises en œuvre en tant que caractéristiques de dispositif ou vice versa. Les sections de la description relatives au procédé s’appliquent également de manière analogue aux programmes informatiques, aux supports de données lisibles par ordinateur, aux dispositifs utilisateurs destinés à participer à des réseaux de communication et aux réseaux de communication. En particulier, les étapes de procédé et les composants associés mentionnés peuvent être mis en œuvre en tant que fonctions des programmes informatiques, des supports de données lisibles par ordinateur, des dispositifs utilisateurs destinés à participer à des réseaux de communication et des réseaux de communication et toutes les fonctions des programmes informatiques, des supports de données lisibles par ordinateur, des dispositifs utilisateurs destinés à participer à des réseaux de communication et des réseaux de communication peuvent être mises en œuvre en tant qu’étapes de procédé. L’invention concerne un procédé permettant de configurer un dispositif utilisateur, par exemple un dispositif utilisateur mobile destiné à participer à un réseau de télécommunications, avec un ensemble de dispositifs sur lequel est installé un élément sécurisé, en particulier une eUICC, comprenant les étapes suivantes : - spécification d’un ensemble de données de commande contenant des commandes de fonctionnement pour le dispositif utilisateur ; - vérification d’une liaison entre l’ensemble de dispositifs et l’élément sécurisé ; et - refus d’au moins une des commandes de fonctionnement si la vérification a montré qu’il n’y a aucune liaison autorisée. Un dispositif utilisateur, notamment un terminal mobile destiné à participer à un réseau de communication, comprend un programme informatique correspondant stocké sur celui-ci, un support de données lisible par ordinateur correspondant et/ou est configuré pour exécuter un procédé correspondant. Un programme informatique comprend des commandes qui, lorsqu’elles sont exécutées par un dispositif utilisateur, amènent le programme à exécuter un procédé correspondant. Un support de données lisible par ordinateur comprend un programme informatique correspondant stocké sur celui-ci. Un agencement de configuration permettant de configurer des dispositifs utilisateurs comprend un programme informatique correspondant stocké dans celui-ci, un support de données lisible par ordinateur correspondant et/ou est configuré pour exécuter un procédé correspondant. Un ensemble de dispositifs et/ou un élément sécurisé peut comprendre un programme informatique correspondant stocké sur celui-ci et/ou un support de données lisible par ordinateur correspondant et/ou être configuré pour exécuter un procédé correspondant. L’agencement de configuration peut comprendre au moins un dispositif informatique, tel qu’un ordinateur, un serveur ou similaire, configuré pour interagir avec des dispositifs utilisateurs, des ensembles de dispositifs et/ou des éléments sécurisés. L’interaction peut, par exemple, avoir lieu via un réseau de télécommunications. Un réseau de télécommunications comprend au moins un dispositif utilisateur correspondant et/ou un serveur sur lequel est stocké un programme informatique correspondant, un support de données lisible par ordinateur correspondant ou le serveur est configuré pour exécuter un procédé correspondant. Le procédé peut donc être mis en œuvre par un dispositif de traitement de données ou à l’aide d’un ordinateur, qui peut être mis en œuvre comme dispositif utilisateur ou serveur. Un programme informatique peut comprendre des commandes qui, lorsque le programme est exécuté par un dispositif de traitement de données ou un ordinateur, amènent l’ordinateur ou le dispositif à exécuter le procédé. Un support de stockage lisible par ordinateur, un support de données lisible par ordinateur et/ou un signal de support de données peuvent stocker ou transmettre le programme informatique. Un support de données lisible par ordinateur correspondant peut se présenter sous la forme d’un support lisible par ordinateur et/ou d’un signal de support de données. Au moins une des commandes de fonctionnement de l’ensemble de données de commande peut être conçue de manière à être interchangeable entre l’ensemble de dispositifs et l’élément sécurisé. La liaison peut ne pas être présente ou ne pas répondre aux exigences de liaison spécifiées. L’ensemble de dispositifs peut être lié à l’élément sécurisé à l’aide d’une clé de sécurité. La liaison et/ou l’autorisation de la liaison peuvent être initiées à la fois depuis l’ensemble de dispositifs et depuis l’élément sécurisé. La solution selon l’invention présente l’avantage qu’en refusant au moins une des commandes de fonctionnement en l’absence d’une liaison autorisée entre l’ensemble de dispositifs et l’élément sécurisé, une communication potentiellement non sécurisée et/ou fonctionnellement indéterminée entre l’ensemble de dispositifs et donc le dispositif utilisateur d’une part et l’élément sécurisé d’autre part peut être évitée. Par exemple, cela peut impliquer une commande refusée, une fonctionnalité spécifique à l’utilisateur et/ou au fournisseur qui nécessite une liaison autorisée appropriée entre l’ensemble de dispositifs et l’élément sécurisé. Cela permet d’améliorer l’interaction entre les éléments sécurisés et les dispositifs utilisateurs, notamment pour les rendre sûrs et fonctionnellement fiables, et d’attribuer des éléments sécurisés à des dispositifs utilisateurs prédéterminés. La solution ne se limite pas aux eUICC, mais convient généralement aux éléments dits sécurisés (SE), appelés ici cartes de circuits intégrés, par exemple. Ainsi, les éléments sécurisés comprennent, outre les eUICC, les UICC classiques, les UICC intégrées (iUICC) ainsi que tous les éléments sécurisés intégrés d’autres types, tels que les éléments sécurisés intégrés (iSE/eSE), les cartes à puce , les modules d’identité d’abonné, Subscriber Identity Module (SIM) et/ou les SIM virtuelles (vSIM). Le point commun de tous ces éléments sécurisés est que des enregistrements de données utilisateur ou des enregistrements de données eUICC peuvent y être stockés, par exemple sous forme de profils de télécommunication ou « profils » en abrégé, à l’aide desquels les utilisateurs peuvent s’authentifier auprès des réseaux de communication, par exemple en tant qu’abonnés aux réseaux de télécommunication. Les éléments sécurisés se caractérisent par le fait que les informations qui y sont stockées, notamment les profils, sont particulièrement protégées contre les attaques de tiers et ne peuvent pas être facilement manipulées, que ce soit physiquement ou par logiciel. Selon un mode de réalisation, il peut être prévu qu’un mode de fonctionnement restreint soit défini dans lequel au moins une des commandes de fonctionnement de l’ensemble de données de commande est définie comme non exécutable et/ou exécutable. Le mode de fonctionnement restreint peut être activé s’il n’y a pas de liaison autorisée. Cela signifie qu’au moins certaines fonctions, par exemple les fonctions rudimentaires, peuvent être exécutées en mode de fonctionnement restreint. Une fonction du dispositif utilisateur peut être spécifiée en mode de fonctionnement restreint en fonction des exigences respectives. Cela contribue à améliorer encore l’interaction sûre et fonctionnellement fiable entre les ensembles de dispositifs et les éléments sécurisés. Selon un mode de réalisation, il peut être prévu que l’enregistrement de données de commande comprenne au moins un paramètre de commande avec lequel le refus et/ou la libération d’au moins une des commandes de fonctionnement peuvent être spécifiés. Le paramètre de commande peut être utilisé, par exemple, pour définir le mode de fonctionnement restreint ou les commandes qui ne peuvent pas être exécutées et/ou peuvent être exécutées dans celui-ci et pour les adapter aux exigences respectives. Cela contribue à améliorer encore l’interaction sûre et fonctionnellement fiable entre les ensembles de dispositifs et les éléments sécurisés. Selon un mode de réalisation, il peut être prévu que la liaison soit autorisée en fonction d’une condition d’autorisation. Par exemple, la liaison peut être conçue pour être techniquement réalisable d’une part et autorisable liée à une condition d’autorisation d’autre part. Cela permet d’associer la vérification de la liaison avec une vérification d’autorisation au-delà de son existence technique. L’autorisation peut à son tour être effectuée selon des exigences spécifiques, par exemple en conjonction avec une vérification des clés de sécurité, des certificats (d’authenticité) ou similaires. Cela contribue également à améliorer encore l’interaction sûre et fonctionnellement fiable entre les ensembles de dispositifs et les éléments sécurisés. Selon un mode de réalisation, il peut être prévu que la liaison soit autorisée après un nombre prédéterminé d’utilisations d’au moins une commande de fonctionnement et/ou d’au moins une action de fonctionnement du dispositif utilisateur, de l’ensemble de dispositifs et/ou de l’élément sécurisé. La liaison peut devoir être autorisée après réinitialisation du dispositif utilisateur, de l’ensemble de dispositifs et/ou de l’élément sécurisé à un état prédéterminé. Par exemple, l’autorisation peut être requise après chaque réinitialisation, après n commandes/opérations configurées (commandes/opérations arbitraires ou spéciales) et/ou avant des commandes configurées (par exemple, des cas d’utilisation spéciaux peuvent être rejetés avec un code d’erreur spécial qui signale une réauthentification) et/ou après une certaine période de temps. De telles commandes de fonctionnement, actions de fonctionnement et/ou conditions de fonctionnement peuvent être utilisées comme et/ou liées à des conditions d’autorisation. Cela permet d’adapter et de contrôler de manière flexible une interaction sûre et fonctionnellement fiable entre les ensembles de dispositifs et les éléments sécurisés en fonction des exigences respectives. Selon un mode de réalisation, il peut être prévu qu’au moins une des étapes de spécification, de vérification et de refus soit conçue pour être activable et/ou désactivable. En d’autres termes, les étapes du procédé correspondantes peuvent être mises en œuvre mais ne doivent pas nécessairement être activées. Cela permet également d’adapter et de contrôler de manière flexible une interaction sûre et fonctionnellement fiable entre les ensembles de dispositifs et les éléments sécurisés en fonction des exigences respectives. Brève description des figures FIG. 1 La FIG. 1 montre une vue schématique d’un mode de réalisation d’un agencement de configuration selon l’invention avec un dispositif utilisateur et un serveur, qui sont conçus pour mettre en œuvre un procédé de configuration du dispositif utilisateur. FIG. 2 La FIG. 2 montre une vue schématique d’un autre mode de réalisation d’un agencement de configuration selon l’invention avec un appareil utilisateur et un serveur, qui sont conçus pour mettre en œuvre un procédé de configuration du dispositif utilisateur. FIG. 3 La FIG. 3 montre une vue schématique d’un schéma de déroulement d’étapes permettant de vérifier une liaison entre un ensemble de dispositifs et un élément sécurisé d’un dispositif utilisateur dans le cadre d’un procédé de configuration du dispositif utilisateur selon l’invention. FIG. 4 La FIG. 4 montre une vue schématique d’un schéma de déroulement d’étapes permettant d’établir une liaison entre un ensemble de dispositifs et un élément sécurisé d’un dispositif utilisateur dans le cadre d’un procédé de configuration du dispositif utilisateur selon l’invention. FIG. 5 La FIG. 5 montre une vue schématique d’un schéma de déroulement d’étapes permettant de vérifier une autorisation d’une liaison entre un ensemble de dispositifs et un élément sécurisé d’un dispositif utilisateur dans le cadre d’un procédé de configuration du dispositif utilisateur selon l’invention. Description détaillée de modes de réalisation exemplaires Les représentations dans les figures sont schématiques et non à l’échelle. Si les mêmes signes de référence sont utilisés dans différentes figures de la description suivante des figures, ceux-ci désignent des éléments identiques ou similaires. Toutefois, des éléments identiques ou similaires peuvent également être désignés par des signes de référence différents. La FIG. 1 montre une vue schématique d’un système de configuration 1 selon l’invention avec un dispositif utilisateur 2 et un dispositif informatique sous la forme d’un serveur 3. Le dispositif utilisateur 2 et le serveur 3 peuvent mettre en œuvre un procédé selon l’invention à l’aide d’un programme informatique 4 sur la base d’instructions lisibles par ordinateur contenues dans celui-ci. Le programme informatique 4 peut être stocké au moins par sections sur un support de données lisible par ordinateur 5 et peut définir des composants du système de configuration 1 décrit ici ainsi que des paramètres, des identifiants, des valeurs, des clés et/ou des étapes S associés et peut réguler leur génération, leur utilisation et/ou leur manipulation. Le support de données lisible par ordinateur 5 peut se présenter sous la forme d’un support lisible par ordinateur 6 et/ou d’un signal de support de données 7. En particulier, le signal de support de données 7 peut être conçu de manière à pouvoir être transféré entre des dispositifs utilisateurs 2 et/ou le serveur 3 pour une exécution respective sur ceux-ci. Ainsi, le programme informatique 4 et donc un procédé correspondant de configuration du dispositif utilisateur 2 peuvent être exécutés sur le dispositif utilisateur et/ou le serveur 3. Le dispositif utilisateur 2 comprend un ensemble de dispositifs 8 et un élément sécurisé 9, par exemple sous la forme d’une carte de circuit intégré ou eUICC qui peut exécuter le programme informatique 4 et donc les étapes de procédé correspondantes S, au moins par sections. L’ensemble de dispositifs peut être conçu comme un module de communication et/ou une carte mère du dispositif utilisateur 2 ou peut comprendre un tel module ou une telle carte mère. La communication entre l’ensemble de dispositifs 8 et l’élément sécurisé 9 est basée sur des commandes de fonctionnement B, par exemple sous la forme d’éléments de données de protocoles d’application correspondants ( Application Protocol Data Unit – APDU ), qui transmettent des commandes unidirectionnelles aux éléments sécurisés via une interface de connexion, qui sont ensuite exécutées par ceux-ci. De plus, les commandes de fonctionnement B servent à contrôler les fonctions C du dispositif utilisateur 2. Les commandes de fonctionnement B peuvent être gérées dans l’ensemble de données de commande D. L’agencement de configuration 1, le dispositif utilisateur 2, le serveur et/ou l’ensemble de données de commande D peuvent également contenir des paramètres P, tels que des codes d’erreur F, des valeurs limites G, des marquages K, des variables d’exécution T et/ou des variables de comptage Z, qui peuvent être liés aux commandes de fonctionnement B et/ou aux fonctions C ou aux actions M ou aux éventuelles restrictions N, qui à leur tour peuvent être basées sur et/ou liées aux commandes de fonctionnement B. De tels paramètres P peuvent être gérés dans l’ensemble de données de commande D conjointement avec les commandes de fonctionnement B et/ou séparément de celles-ci et dans un procédé selon l’invention et ses étapes S. Dans une première étape de procédé S1, l’ensemble de données de commande D avec les commandes de fonctionnement B et éventuellement les paramètres P est spécifié pour le dispositif utilisateur 2. À cet effet, des données correspondantes peuvent être fournies par le serveur 3 de l’ensemble de dispositifs 8 et/ou de l’élément sécurisé 9 ou mises en œuvre et/ou interrogées sur ceux-ci. Dans une deuxième étape S2, une liaison W entre l’ensemble de dispositifs 8 et l’élément sécurisé 9 peut être initiée, par exemple après une première mise en service de l’ensemble de dispositifs 8 et/ou de l’élément sécurisé 9 ou après l’activation d’une fonction correspondante C. Dans le présent exemple, l’élément sécurisé 9 initie la liaison W en envoyant une demande de liaison Q à l’ensemble de dispositifs 8. Dans une troisième étape S3, la demande de liaison Q peut être confirmée par une confirmation de demande R. Dans cet exemple, l’ensemble de dispositifs 8 envoie la confirmation de demande R à l’élément sécurisé 9. Dans une quatrième étape S4, un échange de clés correspondant peut être initié par la demande d’initiation I pour chiffrer la liaison W à l’aide d’une clé de sécurité H. Dans cet exemple, l’élément sécurisé 9 envoie la requête d’indexation I à l’ensemble de dispositifs 8. L’échange de clés peut être confirmé dans une cinquième étape S5 au moyen d’une confirmation de chiffrement J, qui dans le présent exemple est envoyée par l’ensemble de dispositifs 8 à l’élément sécurisé 9. Dans une sixième étape S6, une demande d’authentification U peut être envoyée pour authentifier la liaison W. Dans cet exemple, l’élément sécurisé 9 envoie la demande d’authentification U à l’ensemble de dispositifs 8. Dans une septième étape S7, l’authentification peut être confirmée. Dans le présent exemple, l’ensemble de dispositifs 8 envoie une confirmation d’authentification V à l’élément sécurisé 9, par exemple à l’aide d’un certificat L correspondant. Dans une huitième étape S8, le processus de liaison est terminé. Si la liaison n’est pas entièrement configurée correctement, au moins une des commandes de fonctionnement B peut être désactivée dans un mode de fonctionnement restreint X. Si la liaison W a été établie avec succès, il est possible de passer à un mode de fonctionnement Y sans restriction dans lequel la totalité ou une plage souhaitée des commandes de fonctionnement B de l’ensemble de données de fonctionnement D peuvent être exécutées. Si l’exécution d’une commande B est généralement autorisée, une variable de comptage Z peut être vérifiée pour voir si elle est supérieure ou inférieure à une certaine limite G pour le nombre d’exécutions autorisées. Par exemple, la variable de comptage Z ou le compteur correspondant peut être réduit d’une valeur de comptage à chaque exécution du programme, et si la valeur de la variable de comptage Z a une valeur de 0 comme valeur limite G, l’exécution peut être refusée. Si tel est le cas, une nouvelle variable de comptage Z devrait être réinitialisée par autorisation. Il est également possible de vérifier, à l’aide d’une source de temps fiable, si une variable d’exécution T dépasse une valeur limite correspondante G. Si tel est le cas, une nouvelle variable de durée de vie T ou une extension de durée de vie devra être fournie par autorisation. En outre, une confirmation de configuration E peut être générée à des fins de confirmation, par exemple sous une forme sécurisée par l’élément sécurisé 9. La confirmation de configuration E peut être utilisée pour signaler au dispositif utilisateur 2 et/ou au serveur 3 que la configuration ou l’établissement de la liaison W a réussi. Le dispositif utilisateur 2 et/ou le serveur 3 peuvent ensuite lancer les étapes appropriées pour terminer le processus de configuration, par exemple en activant et/ou en désactivant toutes les commandes de fonctionnement B restantes dans le mode de fonctionnement sans restriction Y, en ajustant les variables de comptage Z, en stockant ou en enregistrant des notes de configuration, par exemple en générant une blockchain, etc. En d’autres termes, dans l’exemple présent, la liaison W peut être initiée après un premier démarrage/démarrage du dispositif utilisateur 2 sur le terrain. L’élément sécurisé 9 peut reconnaître qu’il a été configuré pour une liaison W et démarre maintenant celle-ci à l’étape S2 en envoyant une commande proactive correspondante sous la forme de la demande de liaison Q à l’ensemble de dispositifs 8 afin de l’informer de la liaison W à réaliser. L’ensemble de dispositifs 8 peut signaler avec un « OK » sous la forme de la confirmation de demande R que la liaison peut être réalisée. L’élément sécurisé envoie ensuite une autre commande proactive sous la forme de la demande d’initiation I pour initier un échange de clés selon l’état de l’art, par exemple d’après Diffie-Hellman. Avec la réponse de l’ensemble de dispositifs 8, une clé de sécurité commune H est partagée par les deux composants. Dans l’étape suivante, cette clé de sécurité partagée H est utilisée pour vérifier une liaison W réussie. Cela peut être réalisé à l’aide d’une fonction de cryptographie de pointe, par exemple un AES-CMAC. Après une authentification réussie, l’élément sécurisé 9 peut être en mode de fonctionnement Y sans restriction, par exemple un « mode opérationnel », c’est-à-dire que toutes les fonctions C et actions M sont disponibles comme d’habitude. La FIG. 2 montre une vue schématique d’un autre mode de réalisation d’un agencement de configuration 1 selon l’invention avec le dispositif utilisateur 2 et le serveur 3, qui sont conçus pour mettre en œuvre un procédé de configuration du dispositif utilisateur 2. Dans un souci de concision et d’efficacité, seules les différences par rapport au mode de réalisation de l’agencement de configuration 1 représenté sur la FIG. 1 seront décrites ci-dessous. Dans le mode de réalisation illustré à la FIG. 2 , dans la deuxième étape S2, l’ensemble de dispositifs 8 envoie la demande de liaison Q. Dans la troisième étape S3, l’élément sécurisé 9 répond avec la confirmation de demande R. Dans la quatrième étape S4, l’ensemble de dispositifs 8 initie l’échange de la clé de sécurité H. Dans la cinquième étape S5, l’élément sécurisé 9 envoie la confirmation de chiffrement J. Dans la sixième étape S6, l’ensemble de dispositifs 8 effectue la demande d’authentification U. Dans la septième étape, l’élément sécurisé 9 envoie la confirmation d’authentification V, par exemple en utilisant le certificat L, après quoi le processus de liaison peut être terminé dans la huitième étape S8. La FIG. 3 montre une vue schématique d’un schéma de déroulement d’étapes S permettant de vérifier une liaison W entre l’ensemble de dispositifs 8 et l’élément sécurisé 9 du dispositif utilisateur 2 dans le cadre d’un procédé de configuration du dispositif utilisateur 2 selon l’invention. Dans une dixième étape S10, une demande peut être lancée si une commande de fonctionnement B, par exemple une APDU, doit être exécutée. Dans une onzième étape S11, on peut se demander s’il existe une restriction N concernant l’exécution de la commande de fonctionnement B. Si la restriction N est présente, une liaison W peut être réalisée et/ou interrogée dans une douzième étape S12, par exemple en passant à l’étape S2, comme illustré sur les figures 1 et 2. Si la liaison W est correcte ou n’est pas requise, le fonctionnement jusqu’à 4 peut être effectué dans une étape S13. La demande peut être terminée à l’étape S14. En d’autres termes, à chaque nouvelle commande de fonctionnement B ou à certaines commandes de fonctionnement B ou commandes, il est possible de vérifier si une liaison W est configurée et nécessaire. Si ce n’est pas le cas, cette commande continuera d’être utilisée. Si une liaison est configurée et nécessaire, un « traitement d’appariement ( pairing process) » est effectué. La FIG. 4 montre une vue schématique d’un schéma de déroulement d’étapes S permettant d’établir la liaison W entre l’ensemble de dispositifs 8 et l’élément sécurisé 9 du dispositif utilisateur 9 dans le cadre d’un procédé de configuration du dispositif utilisateur 2 selon l’invention. Ainsi, dans une vingtième étape S20, une vérification peut être lancée pour déterminer si une commande de fonctionnement B spécifique, par exemple selon une restriction N correspondante, est une commande visant à exécuter la liaison W. Dans une vingt et unième étape S21, on peut se demander s’il s’agit d’une commande de fonctionnement B relative à l’exécution de la liaison W, par exemple la demande d’initiation I, la confirmation de chiffrement J, la demande de liaison Q, la confirmation de demande R, la demande d’authentification U et/ou la confirmation d’authentification V. Si ce n’est pas le cas, dans une vingt-deuxième étape S22, similaire à la onzième étape S11, on peut vérifier si la commande de fonctionnement B est activée ou soumise à une restriction N. S’il n’y a pas de restriction N, la commande de fonctionnement B peut être exécutée dans une vingt-troisième étape S23, similaire à la treizième étape S13. La vérification peut ensuite être terminée dans une vingt-quatrième étape S24. Si une restriction N existe, une erreur avec le code d’erreur correspondant F peut être traitée dans une vingt-cinquième étape S25. Par exemple, il est ensuite possible de passer à une vingt-sixième étape S26 pour effectuer la liaison W, comme dans la douzième étape S12. En variante, s’il s’agit d’une commande de fonctionnement B concernant l’exécution de la liaison W, il est possible de passer directement de la vingt et unième étape S21 à l’exécution de la liaison W, comme illustré sur les figures 1 et 2. En d’autres termes, on peut d’abord vérifier si la commande actuelle est une commande de liaison correspondant à la commande de fonctionnement B. Si ce n’est pas le cas, on vérifie si la commande est autorisée ou interdite en fonction de la configuration actuelle. Si elle est autorisée, elle est traitée ultérieurement. Sinon, elle sera rejetée selon la configuration. S’il s’agit d’une commande de liaison, le processus de liaison est traité ou exécuté comme indiqué dans les figures 1 et 2. La FIG. 5 montre une vue schématique d’un schéma de déroulement d’étapes S permettant de vérifier une autorisation de la liaison W entre l’ensemble de dispositifs 8 et l’élément sécurisé 9 du dispositif utilisateur 2 dans le cadre d’un procédé de configuration du dispositif utilisateur 2 selon l’invention. Dans une trentième étape S30, le contrôle peut être déclenché, par exemple par une condition d’autorisation spécifique A, une action M et/ou une commande de fonctionnement correspondante B, telle que la réinitialisation du dispositif utilisateur 2, de l’ensemble de dispositifs 8 et/ou de l’élément sécurisé 9 à un état de fonctionnement prédéterminé. Dans une trente et unième étape S31, il peut être vérifié si la condition d’autorisation A, l’action M et/ou une commande de fonctionnement correspondante B sont présentes. Si la condition d’autorisation A, l’action M et/ou une commande de fonctionnement correspondante B sont présentes, l’autorisation de la liaison W peut être vérifiée dans une trente-deuxième étape S32, par exemple au moyen d’une demande d’autorisation correspondante U, d’une confirmation d’authentification V et/ou d’un certificat L. En cas d’erreur d’autorisation, le traitement des erreurs peut être effectué dans une trente-troisième étape S33 à l’aide d’un code d’erreur correspondant F, similaire à l’étape S25, par exemple en passant au mode de fonctionnement restreint X. Si l’authentification est réussie, le contrôle peut être terminé dans une trente-quatrième étape S34, par exemple en passant au mode de fonctionnement sans restriction Y. Si aucune condition d’autorisation A, action M et/ou commande de fonctionnement correspondante B n’est présente, alors dans une trente-cinquième étape S35, il peut être vérifié si la commande de fonctionnement B ou une APDU correspondante requiert ou est autorisée à autoriser la liaison W, de manière similaire à la vingt-deuxième étape S22. Si la commande de fonctionnement B est autorisée, elle peut être exécutée dans une trente-sixième étape S36. Si la commande de fonctionnement B n’est pas valide, il est possible de passer au traitement des erreurs à la trente-troisième étape S33. Si la commande de fonctionnement B est autorisée, elle peut être exécutée dans une trente-sixième étape S36. Le contrôle peut ensuite être à nouveau terminé à la trente-quatrième étape S34. En d’autres termes, en fonction du déclencheur, par exemple après une réinitialisation à un état de fonctionnement prédéterminé, l’authentification de la liaison W peut être vérifiée. Tout d’abord, il est possible de vérifier si la commande de fonctionnement actuelle B ou la commande correspondante est une commande d’authentification. Si tel est le cas, l’authentification est vérifiée, par exemple via AES-CMAC. En cas de succès, la commande est acceptée et l’élément sécurisé 9 passe en mode de fonctionnement sans restriction Y. Dans le cas contraire, tous les codes d’erreur F seront affichés en conséquence. En mode de fonctionnement restreint X, l’élément sécurisé ne peut alors autoriser que les commandes de fonctionnement B configurées en conséquence. S’il ne s’agit pas d’une commande d’authentification et qu’aucune authentification réussie n’a été effectuée à ce jour, seules les commandes de fonctionnement B sont autorisées selon la configuration du mode de fonctionnement restreint X. La liaison W elle-même peut être spécifiée et initiée dans une usine dans le cadre d’une personnalisation sécurisée du dispositif utilisateur 2, de l’ensemble de dispositifs 8 et/ou de l’élément sécurisé 9, comme illustré dans les figures 1 et 2. Une fois qu’une liaison W a été établie, l’authentification peut être effectuée aux moments appropriés. Selon la configuration, cette authentification peut être unilatérale ou multilatérale. Dans le cas d’une authentification unilatérale, par exemple, seul le dispositif utilisateur 2 ou l’ensemble de dispositifs 8 doit s’authentifier auprès de l’élément sécurisé 9. Dans le cas d’authentifications multilatérales, l’ensemble de dispositifs 8 et l’élément sécurisé 9 doivent s’authentifier mutuellement. Les moments possibles pour les autorisations peuvent être spécifiés dans le dispositif utilisateur 2, l’ensemble de dispositifs 8 et/ou l’élément sécurisé 9. Les moments possibles peuvent être, par exemple : après chaque réinitialisation (Reset) , après n commandes/opérations configurées (commandes/opérations arbitraires ou spéciales) correspondant à une variable de comptage Z respective, avant les commandes de fonctionnement B configurées ou commandes (par exemple, les cas d’utilisation spéciaux peuvent être rejetés avec un code d’erreur spécial F, qui signale une nouvelle authentification après l’expiration de la variable d’exécution correspondante T, par exemple dans le cadre de certains moments (le dispositif utilisateur 2 envoie une demande d’authentification toutes les x minutes/heures ou l’élément sécurisé 9 demande l’authentification du dispositif utilisateur 2 tous les x événements/commandes (comptes)). Un exemple d’un ensemble de données de commande D possible est présenté dans le tableau suivant : Déclencheur d’authentification / Commande de fonctionnement B Type Nombre Réinitialiser Réinitialisation froid/chaud Z APDU Données APDU Z Fonction C Selon la définition Z Variable d’exécution T Le mode de fonctionnement restreint X peut être mis en œuvre par un format correspondant de l’ensemble de données de commande D. Par exemple, pour certaines commandes de fonctionnement B, une sorte de liste approuvée ou interdite peut être gérée comme synonyme des commandes et/ou fonctions correspondantes C. Par exemple, il est possible de déterminer quels types d’APDU (y compris des informations telles que les octets de données CLA, INS, PI et P2, les données de commande) ou de fonctions sont autorisés. Pour chaque entrée, il est possible de noter si la commande de fonctionnement B correspondante est autorisée ou non. À l’aide de restrictions N et/ou de marquages K appropriés, il est également possible de déterminer si une distinction entre les commandes de fonctionnement B autorisées ou interdites peut être activée via un paramètre de configuration correspondant. Par exemple, un tel paramètre de configuration peut être désactivé à l’état de livraison du dispositif utilisateur 2, de l’ensemble de dispositifs 8 et/ou de l’élément sécurisé 9 et peut être activé ultérieurement, comme le montrent de manière abstraite les représentations tabulaires suivantes d’exemples d’ensembles de données de commande D, où des caractères génériques ou des expressions régulières telles que « ? » etc. peuvent être autorisé(e)s et pris(es) en charge : Commande de fonctionnement B Détails Marquage K APDU Description de la commande Autorisée/non autorisée Fonction C Description de la fonction Autorisée/non autorisée Commande de fonctionnement B Détails Restriction N / Marquage K Commentaire APDU INS=20 Autorisée Toutes les APDU avec INS=20 : autorisées APDU INS=30 & Pl=30 & P2=40 Autorisée Toutes les APDU avec INS=30 et Pl=30 et P2=40 : autorisées APDU CLA=8 & INS=40 Interdite Toutes les APDU avec CLA commençant par « 8 » et INS = 40 sont autorisées APDU NS=A 4 & Données = « AO 00 * » Autorisée Toutes les APDU avec CL=A 4 et les données commençant par « A0 00 * » sont autorisées Fonction C SGP ESlOc.GetProfileslnfo Autorisée Une fonctionnalité appelée « SGP ESlOc.GetProfileslnfo » Fonction C SGP ESlOc.EnableProfile Interdite Une fonctionnalité appelée « SGP ESlOc.EnableProfile » Fonction C « Fonction A* » Autorisée Toutes les fonctionnalités commençant par « Fonction A » sont autorisées Fonction C Liaison SE Activée/désactivée La liaison SE est désactivée/non requise La liaison SE est activée/requise De cette manière, les ensembles de données de commande D peuvent être personnalisés en tant que données individuelles et globales dans le cadre d’une personnalisation sécurisée dans une installation de fabrication des dispositifs utilisateurs 2, des ensembles de dispositifs 8 et/ou des éléments sécurisés 9. Alternativement ou en complément, les ensembles de données de commande D peuvent être étendus sous forme de liste, par exemple dans le cadre d’une personnalisation correspondante. Des commandes ou des modifications peuvent également être ajoutées ou modifiées dans les ensembles de données de commande D pendant le fonctionnement ou ultérieurement sur le terrain. En général, un changement peut nécessiter que les clés de sécurité H soient présentes dans l’élément sécurisé 9 pour un échange de données sécurisé. Cela peut être réalisé, par exemple, via une connexion OTA avec un serveur 3 conçu comme un serveur OTA ou via le dispositif utilisateur 2, par exemple à l’aide de commandes dites Global Platform . Il est possible de dissoudre toutes les liaisons W et/ou de les initier à nouveau. Cela est possible, par exemple, en cas de réinitialisation d’usine lors de la vente du dispositif utilisateur 2 ou de l’ensemble de dispositifs 8. Tout d’abord, le dispositif utilisateur 2 et/ou l’ensemble de dispositifs 8 doivent s’authentifier avec succès, par exemple via des mécanismes SGP ou de plate-forme globale, une authentification mutuelle, etc., et faire une demande correspondante. L’élément sécurisé 9 peut alors supprimer la liaison actuelle W et générer une nouvelle clé de sécurité H. Cette clé de sécurité H peut être échangée avec le dispositif utilisateur 2 ou l’ensemble de dispositifs 8 via un chemin de transport sécurisé (par exemple plate-forme globale/Diffie-Hellmann). Par exemple, après un échange et une vérification réussis des données, cette nouvelle liaison W peut alors être utilisée. Cette nouvelle liaison (rebinding) doit être atomique. Procédé de configuration d’un dispositif utilisateur (2), par exemple d’un dispositif utilisateur mobile (2) destiné à participer à un réseau de télécommunications, avec un ensemble de dispositifs (8) sur lequel est installé un élément sécurisé (9), en particulier une eUICC, comprenant les étapes suivantes : - spécification d’un ensemble de données de commande (D) avec des commandes de fonctionnement (B) pour le dispositif utilisateur (2) ; - vérification d’une liaison (W) entre l’ensemble de dispositifs (8) et l’élément sécurisé (9) ; et - refus d’au moins une des commandes de fonctionnement (B) si la vérification a montré qu’il n’y a aucune liaison (W) autorisée. Procédé selon la revendication 1, caractérisé en ce qu’un mode de fonctionnement restreint (X) est défini dans lequel au moins une des commandes de fonctionnement (B) dans l’ensemble de données de commande (D) est définie comme non exécutable et/ou exécutable. Procédé selon la revendication 1 ou 2, caractérisé en ce que l’ensemble de données de commande (D) contient au moins un paramètre de commande (P) permettant de spécifier le refus et/ou la validation d’au moins une des commandes de fonctionnement (B). Procédé selon au moins l’une des revendications précédentes, caractérisé en ce que la liaison (W) doit être autorisée en fonction d’une condition d’autorisation (A). Procédé selon au moins l’une des revendications précédentes, caractérisé en ce que la liaison (W) doit être autorisée après un nombre prédéterminé d’utilisations d’au moins une commande de fonctionnement (B) et/ou d’au moins une action de fonctionnement du dispositif utilisateur (2), de l’ensemble de dispositifs (8) et/ou de l’élément sécurisé (9). Procédé selon au moins l’une des revendications précédentes, caractérisé en ce qu’au moins une des étapes de spécification, de vérification et de refus est conçue pour être activable et/ou désactivable. Programme informatique (4), caractérisé par des commandes qui, lorsque le programme est exécuté par un dispositif utilisateur (2), provoquent l’exécution d’un procédé selon l’une des revendications 1 à 6. Support de données lisible par ordinateur (5), caractérisé par un programme informatique (4) stocké sur celui-ci selon la revendication 7. Dispositif utilisateur (2), notamment terminal mobile destiné à participer à un réseau de communication, caractérisé par un programme informatique (4) stocké sur celui-ci selon la revendication 7, un support de données lisible par ordinateur (2) selon la revendication 8 et/ou caractérisé en ce que le dispositif utilisateur () est configuré pour mettre en œuvre un procédé selon au moins l’une des revendications 1 à 6. Agencement de configuration (1) pour la configuration de dispositifs utilisateurs (2), caractérisé par un programme informatique (4) stocké sur celui-ci selon la revendication 7, un support de données lisible par ordinateur (5) selon la revendication 8 et/ou caractérisé en ce que l’agencement de configuration (1) est configuré pour mettre en œuvre un procédé selon au moins l’une des revendications 1 à 6.