Brevet FR3125902A1 — publié le 20230203

Une nouvelle méthode de personnalisation d’éléments sécurisés embarqués, eSE, permet une fabrication simplifiée avant intégration dans des équipements hôtes. Un eSE met en œuvre des services exécutés par un système d’exploitation, OS, embarqué lorsqu’il est chargé dans l’eSE. L’eSE non personnalisé comprend un chargeur d’OS et une clé cryptographique maître commune à une pluralité d’éléments sécurisés. Il peut donc être produit en grand nombre. Le chargeur d’OS obtient, d’un serveur, un package de système d’exploitation et l’installe. En réponse à l’installation, le chargeur d’OS génère une clé cryptographique de dérivation par diversification de la clé cryptographique maître, puis l’OS génère des données personnalisées par dérivation de données de pré-personnalisation avec la clé de dérivation. L’eSE, déployé sur le terrain dans un état simple non-personnalisé, est ainsi entièrement personnalisé sans échange de données personnalisées secrètes. Figure pour l’abrégé : Fig. 3 ELEMENT SECURISE PRE-PERSONALISE ET PERSONNALISATION EMBARQUEE La présente invention concerne le domaine des éléments sécurisés. Un élément sécurisé, SE (pour « secure element » en langue anglo-saxonne), 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 sous le contrôle d’un système d’exploitation OS de carte (c’est-à-dire un OS bas niveau ou « firmware »), 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 largement utilisé du SE est l’élément sécurisé embarqué ou intégré, eSE (pour « embedded Secure Element »). Cet élément sécurisé embarqué est généralement soudé au terminal hôte. Les éléments sécurisés sont programmés selon les applications souhaitées. A titre d'exemple, un eSE peut former l'élément sécurisé nécessaire à de nombreux usages ou services reposant sur une communication NFC (pour « Near Field Communication » en langue anglo-saxonne) mis en œuvre par un terminal mobile hôte. Par exemple, un service de paiement NFC nécessite des informations bancaires secrètes de l'utilisateur qui sont avantageusement stockées dans l'eSE, à l'abri de tout accès intempestif. C’est aussi le cas d’un service de transport public où l’eSE permet d’identifier l’utilisateur auprès de portiques. Un autre exemple d’élément sécurisé est l’UICC embarquée (pour « Universal Integrated Circuit Card ») qui procure les références d’un abonné pour s’authentifier sur un réseau de téléphonie mobile. Il s’agit par exemple d’un eSE configuré comme une carte SIM (pour « Subscriber Identity Module » – ou module d’identité d’abonné). On parle alors d’eUICC (pour « embedded Universal Integrated Circuit Card »). Les éléments sécurisés sont fabriqués et ensuite personnalisés, c’est-à-dire chargés avec des données propres au SE et à l’abonné. Certaines données doivent être maintenues secrètes pour des raisons de sécurité, telles que des justificatifs d’identification (aussi connus sous l’appellation anglo-saxonne de « credentials »), des clés cryptographiques ou des données d’identification. D’autres données propres au SE peuvent être moins confidentielles. Aussi, pendant la personnalisation d’un groupe de SEs, des données secrètes sont généralement diversifiées à partir d’une donnée secrète, par exemple une clé cryptographique de dérivation, de manière à ce que chaque SE ait des données secrètes qui lui sont propres, par exemple des clés cryptographiques et justificatifs d’identification. En particulier, la personnalisation est un processus consistant à charger sur chaque SE, son système d’exploitation (ou OS pour « Operating System » en langue anglo-saxonne) et diverses données. Pour des raisons d’optimisation du processus de personnalisation, le processus est décomposé en deux processus distincts : la pré-personnalisation et la personnalisation. La pré-personnalisation consiste à charger, dans le SE, des données communes à tous les SEs d’un même lot. Aussi, tout le lot de SEs peut être pré-personnalisé à l’aide de la même opération. Cette partie commune comporte notamment le chargement en mémoire du système d’exploitation et des données pré-personnalisées, nommées aussi données statiques. La personnalisation est mise en œuvre à la suite de la pré-personnalisation, et consiste à charger dans le SE, des données qui lui sont propres, nommées aussi données dynamiques, incluant donc les données secrètes personnalisées (clés, credentials, etc.). On notera que le terme « personnalisation » est en général compris comme étant celui utilisé couramment par l’homme du métier dans l’industrie des cartes à microcircuit, ou tel que défini par W. Ranki et W. Effing dans le document « Smart Card Handbook , Second Edition, Ed. John Wiley & Sans, Ltd » de la façon suivante : « Le terme personnalisation , dans son sens le plus large, signifie que les données spécifiques à une carte ou à une personne sont entrées dans la carte. Ces données peuvent par exemple être un nom, une adresse, mais aussi des clefs associées à la carte. La seule chose qui importe est que ces données soient spécifiques à cette carte . » Par extension, la pré-personnalisation des SEs consiste en des opérations similaires sauf que les données entrées dans les SEs sont communes à un lot de SEs ou à un type d’entité (par exemple les cartes à puces). Il s’agit par exemple de données de configuration de programmes contenus dans une mémoire non volatile réinscriptible (par exemple de type Flash, EEPROM ou autre) qui visent à déterminer un comportement ou un fonctionnement commun à tous ces SEs du même lot ou du même type d’entité. Aujourd’hui, les SEs sont personnalisés hors du site de fabrication. Par exemple, la personnalisation peut être mise en œuvre dans un site tiers. Les sites de personnalisation doivent donc mettre en place des systèmes de personnalisation selon des procédures strictes et respectant des exigences sécuritaires, notamment au regard des données secrètes personnalisées manipulées. On notera que l’envoi des données de personnalisation au site de personnalisation requiert aussi le respect d’exigences sécuritaires très strictes, notamment la mise en place d’un lien sécurisé (clé de transport, clé de session) entre le système de personnalisation et les SEs. En outre, l’opération de personnalisation est spécifique à chaque SE, exigeant par conséquent des opérations distinctes pour chaque SE avant ou après son intégration physique (soudure pour un eSE) à un dispositif hôte. Aussi, les procédures existantes de personnalisation de SEs sont complexes (en terme de temps et de sécurisation, notamment) et donc coûteuses. Il est donc un besoin d’améliorer cette situation. Dans ce dessein, la présente invention a pour but d’optimiser la personnalisation des éléments sécurisés. Elle propose de générer (par diversification ou « rotation »), au sein même du SE et sur chargement d’un nouveau système d’exploitation, la clé de dérivation utilisée pour la personnalisation du SE et ainsi permettre la dérivation des données de personnalisation également au sein du SE à partir de données pré-personnalisées. Ainsi, des lots de SEs similaires peuvent être fabriqués et vendus sans opération dédiée de personnalisation avant leur vente. Ces SEs ne comportant que des données communes et donc de pré-personnalisation, leur fabrication en grand nombre est simple. Par ailleurs, la personnalisation des SEs peut alors être réalisée ultérieurement sur le terrain, à distance, réduisant donc le temps de la phase de production jusqu’à la vente. Enfin et surtout, l’invention améliore la sécurisation des SEs. D’une part, aucune donnée personnalisée secrète n’est désormais transférée directement sur le SE et donc susceptible d’être interceptée. On s’affranchit ainsi d’un site de personnalisation hautement sécurisé. D’autre part, grâce à la diversification in situ de la clé de dérivation utilisée pour la personnalisation, il est possible de réitérer une telle diversification dans la vie de la carte, réduisant par conséquent les risques de compromission. A cet effet, la présente invention propose un élément sécurisé configuré pour être intégré dans un dispositif hôte et pour mettre en œuvre des services exécutés par un système d’exploitation lorsque le système d’exploitation est chargé dans l’élément sécurisé, l’élément sécurisé comportant un chargeur de système d’exploitation et au moins une clé cryptographique maître. Cette clé est initialement commune à une pluralité d’éléments sécurisés. Le chargeur de système d’exploitation et la clé cryptographique (et éventuellement toute autre donnée de pré-personnalisation commune) sont notamment chargés dans l’élément sécurisé pendant sa fabrication, avant ou après intégration dans le dispositif hôte. Selon l’invention, l’élément sécurisé est configuré pour : - obtenir, d’un serveur, un package de système d’exploitation et installer le système d’exploitation, - en réponse à l’installation du système d’exploitation, faire générer, par le chargeur de système d’exploitation, une clé (cryptographique) de dérivation par diversification de la clé cryptographique maître. Ainsi, la présence du chargeur de système d’exploitation (ou chargeur de firmware ou « firmware loader » en langue anglo-saxonne) dans l’élément sécurisé eSE dès sa fabrication permet de charger à tout moment un système d’exploitation, que ce soit le premier système d’exploitation chargé dans l’eSE ou une version de mise à jour, et de générer localement (« on board ») la clé de dérivation afin de permettre au système d’exploitation de générer (dériver) ses propres données personnalisées. De telles données personnalisées, propres au système d’exploitation et/ou à l’élément sécurisé embarqué, donnent par exemple accès en toute sécurité à des services du système d’exploitation ou externes, par exemple d’un réseau de télécommunications ou bancaire (e.g. appels téléphoniques, services data, authentification auprès d’un serveur, etc.). Un tel élément sécurisé présente l’avantage de ne pas être personnalisé lors de son intégration dans le dispositif hôte. Des éléments sécurisés identiques peuvent donc être fabriqués en grand nombre, tout en permettant une personnalisation embarquée à distance, sur le terrain. Aussi, selon certains modes de réalisation, le package de système d’exploitation comprend des données de pré-personnalisation, éventuellement associées au système d’exploitation, et l’élément sécurisé est configuré pour générer des données personnalisées par dérivation des données de pré-personnalisation avec la clé de dérivation. Grâce à cette dérivation, l’élément sécurisé devient personnalisé. Il est à noter que des données de pré-personnalisation peuvent également être chargées initialement avec le chargeur de système d’exploitation et être utilisées lors de cette diversification pour personnalisation. De même, des données personnalisées peuvent également être chargées de façon concomitante au chargement du système d’exploitation. Dans un mode de réalisation, le chargeur de système d’exploitation est configuré pour générer la clé de dérivation à partir de la clé cryptographique maître, d’un identifiant unique du chargeur de système d’exploitation, d’un identifiant unique du package de système d’exploitation ou du système d’exploitation chargé et installé, et d’un compteur de dérivation mis à jour à chaque génération de la clé de dérivation. Optionnellement, un aléa ou un mot de passe à usage unique (OTP) connu du serveur ou d’un autre serveur peut être ajouté comme paramètre de diversification de la clé cryptographique maître. Cette configuration permet une personnalisation sécurisée de la clé de dérivation, différente d’un élément sécurisé à l’autre et différente d’une diversification à l’autre au sein d’un même eSE. La diversification peut être réalisée directement à partir de la clé cryptographique maître initiale ou à partir de la précédente clé de dérivation obtenue (qui devient la nouvelle clé maître pour la génération suivante). Dans le dernier cas, il peut être envisagé d’écraser l’ancienne clé de dérivation (initialement la clé maître ou racine) par la nouvelle clé de dérivation. Lorsque l’élément sécurisé est fabriqué et avant qu’un système d’exploitation ne soit chargé, le compteur de dérivation présente une valeur initiale, par exemple zéro. La valeur du compteur de dérivation est incrémentée à fur et à mesure que de nouvelles versions du système d’exploitation sont obtenues et installées, et que de nouvelles clés de dérivation sont générées. Selon une caractéristique, l’élément sécurisé est configuré en outre pour, postérieurement à la génération de la clé de dérivation, envoyer à un serveur l’identifiant unique du chargeur de système d’exploitation, l’identifiant unique du package de système d’exploitation ou du système d’exploitation chargé et installé, le compteur de dérivation, et optionnellement un label désignant la clé cryptographique maître. En d’autres termes, il transmet l’ensemble des paramètres utilisés (l’éventuel aléa ou OTP est déjà connu du serveur) pour la génération. Le label de clé est transmis notamment dans le cas où une pluralité de clés serait stockée dans l’élément sécurisé, afin d’identifier la clé servant à la diversification puis à la génération des données personnalisées. Le serveur peut ainsi générer de son côté la clé de dérivation propre à l’eSE pour le système d’exploitation embarqué, et ainsi également générer les données personnalisées propres à cet eSE, sans que des données secrètes soient échangées. Il possède donc, en miroir, les mêmes données personnalisées et secrètes que l’eSE. Un tel serveur est alors en mesure de réaliser des opérations sécurisées d’identification, authentification, etc. avec l’élément sécurisé. Dans un mode de réalisation, l’élément sécurisé est configuré pour envoyer au serveur une requête d’obtention du package de système d’exploitation, la requête comprenant un identifiant unique du chargeur de système d’exploitation et un identifiant unique d’un package de système d’exploitation ou d’un système d’exploitation déjà installé s’il y en a un, et l'obtention du package de système d’exploitation est en réponse à la requête. Chaque lot d’éléments sécurisés dispose, en commun, d’un chargeur de systèmes d’exploitation et d’une clé maître, et de façon unique à chaque eSE, d’un identifiant unique de chargeur. Ainsi, des eSE identiques peuvent être personnalisés de façon distincte et ciblée. Selon une caractéristique, l’élément sécurisé est configuré pour générer la clé de dérivation en réponse à un événement de fin d’installation du système d’exploitation. En variante, l’élément sécurisé est configuré pour générer la clé de dérivation en réponse à un premier démarrage (premier boot) du système d’exploitation installé. Aussi à chaque nouveau chargement d’un système d’exploitation (par exemple mise à jour), une nouvelle clé de dérivation est générée. De façon incidente, de nouvelles données personnalisées sont également générées, par dérivation à partir de cette nouvelle clé. Selon une caractéristique, l’élément sécurisé comprend un drapeau mis à une première valeur d’état non diversifié, lors de l’installation du système d’exploitation et à une seconde valeur d’état diversifié, lors de la génération de la clé de dérivation. Ce drapeau permet ainsi à l’élément sécurisé de savoir si la génération de la clé de dérivation a déjà eu lieu. Cela est utile notamment pour identifier le premier démarrage du système d’exploitation et ainsi éviter des générations intempestives à chaque redémarrage du système d’exploitation. Optionnellement, le drapeau peut être mis à une troisième valeur d’état personnalisé, lors de la génération des données personnalisées. Selon une caractéristique, la clé cryptographique maître est stockée en mémoire sécurisée et accessible par le chargeur de système d’exploitation uniquement. Aussi, les paramètres reçus par le chargeur pour générer la clé de dérivation ne comprennent qu’un label (ou identifiant) de la clé cryptographique maître à utiliser (par exemple pour le cas où plusieurs clés maîtres seraient stockées) pour la génération, et non la clé elle-même. Cela renforce la sécurité. Corrélativement, l’invention propose également un procédé de personnalisation d’un élément sécurisé configuré pour être intégré dans un dispositif hôte et pour mettre en œuvre des services exécutés par un système d’exploitation lorsque le système d’exploitation est chargé dans l’élément sécurisé, l’élément sécurisé comportant un chargeur de système d’exploitation et au moins une clé cryptographique maître (initialement commune à une pluralité d’éléments sécurisés), ledit procédé comportant les étapes suivantes : - obtenir d’un serveur un package de système d’exploitation et installer le système d’exploitation, - en réponse à l’installation du système d’exploitation, faire générer, par le chargeur de système d’exploitation, une clé de dérivation par diversification de la clé cryptographique maître. Le procédé de génération présente des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le circuit intégré. Le procédé peut en outre incorporer des étapes ou caractéristiques facultatives exposées ci-dessus en lien avec des caractéristiques de dispositif (élément sécurisé). D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. La représente, schématiquement, un élément sécurisé dans lequel la présente invention peut être mise en œuvre. La illustre un élément sécurisé en sortie de processus de fabrication lorsqu’il est intégré à un dispositif hôte. La illustre l’élément sécurisé après l’installation d’un nouveau package de système d’exploitation. La illustre l’élément sécurisé après la diversification de la clé maître pour obtenir une clé de dérivation. La illustre l’élément sécurisé après une opération de génération de données personnalisées par dérivation à partir de la clé de dérivation. La illustre schématiquement différentes étapes pour la personnalisation d’un élément sécurisé selon des modes de réalisation de l’invention. Elément sécurisé (100) configuré pour être intégré dans un dispositif hôte (200) et pour mettre en œuvre des services exécutés par un système d’exploitation (122) lorsque le système d’exploitation est chargé dans l’élément sécurisé, l’élément sécurisé comportant un chargeur de système d’exploitation (110) et au moins une clé cryptographique maître (MSK), l’élément sécurisé étant configuré pour : - obtenir, d’un serveur (250), un package de système d’exploitation (120) et installer le système d’exploitation (122), et - en réponse à l’installation du système d’exploitation, faire générer, par le chargeur de système d’exploitation, une clé de dérivation (MSK n ) par diversification de la clé cryptographique maître. Elément sécurisé selon la revendication 1, dans lequel le package de système d’exploitation comprend des données de pré-personnalisation (124), et l’élément sécurisé est configuré pour générer des données personnalisées (130) par dérivation des données de pré-personnalisation avec la clé de dérivation. Elément sécurisé selon la revendication 1 ou 2, dans lequel le chargeur de système d’exploitation est configuré pour générer la clé de dérivation à partir de la clé cryptographique maître (MSK), d’un identifiant unique du chargeur de système d’exploitation (ID loader ), d’un identifiant unique du package de système d’exploitation ou du système d’exploitation chargé et installé (ID package ), et d’un compteur de dérivation (V deriv ) mis à jour à chaque génération de la clé de dérivation. Elément sécurisé selon la revendication 3, configuré en outre pour, postérieurement à la génération de la clé de dérivation, envoyer à un serveur (250) l’identifiant unique du chargeur de système d’exploitation (ID loader ), l’identifiant unique du package de système d’exploitation ou du système d’exploitation chargé et installé (ID package ), le compteur de dérivation (V deriv ) et optionnellement un label désignant la clé cryptographique maître. Elément sécurisé selon l’une des revendications précédentes, configuré en outre pour envoyer, au serveur, une requête (308) d’obtention du package de système d’exploitation, la requête comprenant un identifiant unique du chargeur de système d’exploitation (ID loader ) et un identifiant unique (ID package ) d’un package de système d’exploitation ou d’un système d’exploitation déjà installé s’il y en a un, et l'obtention du package de système d’exploitation est en réponse à la requête. Elément sécurisé selon l’une des revendications 1 à 5, configuré pour générer la clé de dérivation en réponse à un événement de fin d’installation du système d’exploitation. Elément sécurisé selon l’une des revendications 1 à 5, configuré pour générer la clé de dérivation en réponse à un premier démarrage du système d’exploitation installé. Elément sécurisé selon l’une des revendications précédentes, comprenant un drapeau (116) mis à une première valeur d’état non diversifié (E 1 ) lors de l’installation du système d’exploitation et à une seconde valeur d’état diversifié (E 2 ) lors de la génération de la clé de dérivation. Elément sécurisé selon l’une des revendications précédentes, dans lequel la clé cryptographique maître est stockée en mémoire sécurisée et accessible par le chargeur de système d’exploitation uniquement. Procédé de personnalisation d’un élément sécurisé (100) configuré pour être intégré dans un dispositif hôte (200) et pour mettre en œuvre des services exécutés par un système d’exploitation lorsque le système d’exploitation est chargé dans l’élément sécurisé, l’élément sécurisé comportant un chargeur de système d’exploitation (110) et au moins une clé cryptographique maître (MSK), ledit procédé comportant les étapes suivantes : - obtenir (318, 320) d’un serveur (250) un package de système d’exploitation (120) et installer (322) le système d’exploitation (122), - en réponse à l’installation du système d’exploitation, faire générer (328), par le chargeur de système d’exploitation (110), une clé de dérivation (MSK n ) par diversification de la clé cryptographique maître (MSK). Procédé selon la revendication 10, comprenant en outre l’étape suivante : générer (332) des données personnalisées (130) par dérivation de données de pré-personnalisation stockées dans l’élément sécurisé, avec la clé de dérivation.