Brevet FR3038176A1 — publié le 20161230

FOURNITURE ET GESTION DE PROFILS SUR UN ELEMENT SECURISE, ELEMENT SECURISE ET SERVEUR ASSOCIES DOMAINE DE L'INVENTION L'invention concerne des procédés de fourniture et de gestion de profils dans un élément sécurisé. Elle s'applique, en particulier, à la sécurisation d'un script d'installation d'un profil sous forme de paquets, reçu par un élément sécurisé. CONTEXTE DE L'INVENTION Un élément sécurisé, par exemple une carte à puce, peut être utilisé dans divers équipements ou dispositifs hôtes (terminal mobile, smartphone, tablette numérique, compteur électrique, véhicule, etc.). En particulier, l'élément sécurisé peut être intégré de manière amovible dans le dispositif électronique hôte, ou en variante embarqué (par exemple soudé) dans celui-ci. Dans les deux cas, l'élément sécurisé comprend un processeur qui lui est propre, différent du processeur du dispositif électronique hôte dans lequel il est intégré ou embarqué, et comprend une mémoire non-volatile pour le stockage de programmes d'ordinateurs exécutables par le processeur. Un premier type d'élément sécurisé évoqué est connu sous l'appellation de carte UICC (pour Universel Integrated Circuit Card) visée dans la norme ETSI TS 102 221 et regroupe les cartes à puce classiques amovibles, type carte SIM (ou USIM - pour Universel Subscriber Identity Module), mais également des jetons (token) sécurisés, tous identifiables de manière unique. Un second type d'élément sécurisé évoqué est connu sous l'appellation d'eSE (pour embedded Secure Element) et visé dans la spécification GlobalPlatform Card Specification Version 2.2.1 relative à la technologie GlobalPlatform. Ce second type vise les éléments sécurisés embarqués, c'est-à-dire non amovibles. A titre d'exemple, l'élément sécurisé embarqué peut être une eUICC (pour embedded Universel Integrated Circuit Card) pour carte de circuit intégré universelle et embarquée, telle que visée dans la norme ETSI TS 103 383. Pour pallier le fait que l'utilisateur ne peut pas simplement changer d'identifiant unique en échangeant l'élément sécurisé embarqué dans le dispositif hôte avec un autre élément sécurisé, l'élément sécurisé embarqué peut fonctionner selon 3038176 2 plusieurs profils différents chacun identifié par un identifiant unique, et stockés ou téléchargés sur l'élément sécurisé embarqué. Un élément sécurisé amovible peut toutefois également comprendre plusieurs profils différents. 5 Au sens de la norme GSMA 12FAST.15, un profil est une combinaison d'une structure de fichiers, de données, et/ou d'applications présentes ou téléchargées sur un élément sécurisé, et qui permet, lorsqu'il est activé, d'accéder à une infrastructure de réseau mobile spécifique. Un tel profil comprend par exemple : 10 - un fichier de configuration d'un système d'exploitation comprenant des données relatives à des applications ADF (pour Application Data File), à des MF (pour Management Field) ; - au moins un domaine de sécurité de profil ISD-P (pour lssuer Security Domain Profile) 15 - une ou plusieurs applications Java Card ; - des données et paramètres relatifs à une application de communication NAA (pour Network Access Application) ou une application coopérant avec un serveur distant via un réseau mobile, des clefs de protocole de transport, ou encore des paramètres d'algorithme d'authentification. 20 Ainsi, à titre d'exemple non limitatif, lorsqu'un utilisateur souhaite basculer d'un réseau mobile à un autre, il doit commander la bascule d'un profil (ici, de souscripteur) à un autre. Actuellement, selon les normes GSMA 12FAST.15 et GSMA 12FAST.13, un élément sécurisé peut télécharger un nouveau profil en provenance d'un serveur, 25 dénommé SM pour « Subscription Manager» (soit gestionnaire d'abonnement), avec qui il communique selon un protocole de transport sécurisé, par exemple le protocole Secure Channels SCP8x (e.g. SCP80 et SCP81) ou SCPOx (e.g. SCP03) défini par GlobalPlatform. Ce chargement d'un profil est par exemple décrit aux sections 3.1.3, 30 4.1.3.1 et 5.4.4 de la norme GSMA 12FAST.15. Les données du profil peuvent par exemple être formatées sous forme d'une liste ou script de commandes C-APDU (pour Command Application Protocol Data Unit). L'intégrité du profil est dans ce cas assurée par l'utilisation de ce protocole sécurisé de transport. 3038176 3 Afin d'améliorer l'efficacité du chargement d'un nouveau profil, il peut être intéressant d'ouvrir plusieurs sessions sécurisées de type Secure Channel en parallèle afin d'envoyer le profil, ou plus précisément le script d'installation de ce profil. Le script de commandes est alors segmenté en paquets, chacun d'entre eux étant envoyé 5 indépendamment sur un canal sécurisé. L'intégrité de chaque paquet envoyé est alors garantie par le protocole sécurisé de transport du canal utilisé. Toutefois, il peut arriver que les paquets transportés au cours d'une session sécurisée ne parviennent pas à l'élément sécurisé, par exemple en raison d'un dysfonctionnement du réseau. 10 Dans la pratique, même si les paquets constituant le script d'installation du profil ne sont pas tous reçus, le script d'installation du profil est considéré comme étant également intègre dans sa globalité dès lors que tous les paquets reçus sont intègres. Le script d'installation du profil chargé en mémoire est alors exécuté, installant le profil, et ce dernier est activé pour utilisation. On notera que l'installation du profil vise le 15 chargement du profil sur l'élément sécurisé tandis que son activation vise à sélectionner ce profil comme profil de fonctionnement de l'élément sécurisé. Ainsi, la désactivation d'un profil n'équivaut pas forcément à sa désinstallation ou à la désactivation de tout son domaine de sécurité ISD-P. Or, l'activation d'un profil non-intègre est susceptible de provoquer des 20 dysfonctionnements de l'élément sécurisé. Il existe donc un besoin d'améliorer la sécurité du chargement (ou installation) d'un nouveau profil sur un élément sécurisé, notamment dans des contextes où plusieurs sessions sécurisées sont utilisées pour recevoir, par paquets, le script d'installation du nouveau profil. 25 RESUME DE L'INVENTION La présente invention a ainsi pour objet de pallier au moins un de ces inconvénients. Dans ce contexte, un premier aspect de l'invention concerne un procédé de 30 gestion de profil dans un élément sécurisé. Le procédé de gestion comprend les étapes suivantes, mises en oeuvre par l'élément sécurisé : - réception, sur un canal sécurisé, d'au moins un paquet d'une pluralité de paquets formant un script d'installation d'un profil et d'une information d'intégrité globale du script d'installation ; 3038176 4 - à réception d'un paquet comportant une indication de dernier paquet du script d'installation, vérification, à l'aide de l'information d'intégrité globale reçue, de l'intégrité globale de l'ensemble des paquets reçus, les paquets reçus formant un script d'installation reconstitué ; 5 - exécution du script d'installation reconstitué pour installer le profil dans l'élément sécurisé et activation du profil installé, uniquement lorsque la vérification globale d'intégrité est positive. L'efficacité et la sécurité du chargement du profil sont améliorées par la mise en oeuvre de l'invention. 10 En effet, d'une part, le script d'installation étant sous forme de paquets, il est possible de le recevoir via plusieurs sessions de communication, et donc de façon efficace. D'autre part, l'intégrité de l'ensemble du script d'installation est assurée par la fourniture et l'utilisation de l'information d'intégrité globale de ce script, bien que ce 15 dernier ait été reçu sous forme de paquets envoyés indépendamment les uns des autres. Ainsi, grâce à cette information d'intégrité globale du script d'installation, qui est utilisée, à réception du dernier paquet formant le script de profil, pour vérifier l'intégrité de l'ensemble des paquets reçus, le profil installé grâce au script 20 d'installation n'est alors activé que si l'ensemble des paquets reçus est intègre. On s'assure ainsi que l'ensemble des paquets soit reçu et que chacun de ceux-ci soit intègre, c'est-à-dire que l'ensemble reçu correspond effectivement au script d'installation envoyé. Corrélativement, un deuxième aspect de l'invention concerne un procédé 25 de fourniture d'un profil à un élément sécurisé. Le procédé de fourniture comprend les étapes suivantes, mises en oeuvre au niveau d'un serveur d'un réseau de communication : - partitionnement d'un script d'installation d'un profil en une pluralité de paquets, le dernier paquet de la pluralité comprenant une indication de dernier paquet ; 30 - obtention et transmission, à destination de l'élément sécurisé, d'une information d'intégrité globale du script d'installation ; et - transmission, à destination de l'élément sécurisé, des paquets de sorte que la réception, par l'élément sécurisé, du paquet comportant l'indication de dernier paquet déclenche une vérification globale de l'intégrité des paquets reçus par l'élément 35 sécurisé à l'aide de l'information d'intégrité globale transmise. 3038176 5 Le procédé de fourniture d'un profil présente les mêmes avantages que le procédé gestion de ci-dessus, dès lors que le serveur fournit l'information d'intégrité globale du script à exécuter pour installer le profil et qu'il identifie le dernier paquet déclenchant ladite vérification. 5 D'autres caractéristiques des procédés selon des modes de réalisation de l'invention sont décrites dans les revendications dépendantes. Dans des modes particuliers de réalisation de l'invention, l'étape de vérification de l'intégrité globale comprend les étapes suivantes : - calcul d'un cryptogramme à partir de l'ensemble des paquets reçus ; et 10 - comparaison du cryptogramme calculé avec l'information d'intégrité globale. Dans des modes particuliers de réalisation de l'invention, lequel l'exécution du script d'installation reconstitué n'est effectuée que lorsque la vérification globale d'intégrité est positive, ou seule l'activation du profil installé est effectuée uniquement 15 lorsque la vérification globale d'intégrité est positive. Dans des modes particuliers de réalisation de l'invention, les paquets sont des messages SMS (Short Message Service). Dans des modes particuliers de réalisation de l'invention, l'intégrité de chaque paquet reçu est assurée par l'utilisation d'un protocole de transport sécurisé 20 pour la transmission du paquet à l'élément sécurisé. Dans des modes particuliers de réalisation de l'invention, chaque paquet intègre reçu est stocké dans une zone mémoire de l'élément sécurisé prévue à cet effet, et la vérification globale de l'intégrité comprend la vérification de l'intégrité du script d'installation reconstitué formé par l'ensemble des paquets stockés dans la zone 25 mémoire. Dans des modes particuliers de réalisation de l'invention, le procédé de fourniture comprend une étape de réception, par le serveur, d'un message d'erreur en provenance de l'élément sécurisé en réponse au paquet comportant l'indication de dernier paquet. 30 Dans des modes particuliers de réalisation de l'invention, le procédé de fourniture comprend, en réponse à la réception du message d'erreur, une nouvelle étape de transmission, à destination de l'élément sécurisé, des paquets formant le script d'installation et de l'information d'intégrité globale. Dans des modes particuliers de réalisation de l'invention, le procédé de 35 fourniture comprend une étape de calcul par le serveur d'un cryptogramme à partir du 3038176 6 script d'installation du profil, avant son partitionnement en une pluralité de paquets, l'information d'intégrité globale comprenant le cryptogramme calculé. Dans des modes particuliers de réalisation de l'invention, l'étape de partitionnement comprend le partitionnement du script d'installation du profil en une 5 pluralité de messages SMS (short message service). Un troisième aspect de l'invention concerne un élément sécurisé comportant : - un récepteur configuré pour recevoir, sur un canal sécurisé, au moins un paquet d'une pluralité de paquets formant un script d'installation d'un profil, et une 10 information d'intégrité globale du script d'installation ; - un vérificateur d'intégrité configuré pour vérifier, à réception d'un paquet comportant une indication de dernier paquet du script d'installation et à l'aide de l'information d'intégrité globale reçue, l'intégrité globale de l'ensemble des paquets reçus, les paquets reçus formant un script d'installation reconstitué; et 15 - un processeur configuré pour exécuter le script d'installation reconstitué pour installer le profil dans l'élément sécurisé et activer le profil uniquement lorsque la vérification d'intégrité est positive. Par exemple, l'élément est une carte à circuit intégré universelle et embarquée (eUICC) conforme à la norme ETSI TS 103 383 ou une carte à circuit 20 intégré universelle (UICC) conforme à la norme ETSI TS 102 221. Un quatrième aspect de l'invention concerne un serveur, configuré pour fournir un profil à un élément sécurisé. Le serveur comprend : - un module de partitionnement d'un script d'installation d'un profil en une pluralité de paquets, le dernier paquet de la pluralité comprenant une indication de 25 dernier paquet ; - un module d'obtention d'une information d'intégrité globale du script d'installation ; et - un transmetteur configuré pour transmettre, à destination de l'élément sécurisé, les paquets et l'information d'intégrité globale obtenue, de sorte que la 30 réception, par l'élément sécurisé, du paquet comportant l'indication de dernier paquet déclenche une vérification globale de l'intégrité des paquets reçus par l'élément sécurisé à l'aide de l'information d'intégrité globale transmise. Dans des modes particuliers de réalisation, les différentes étapes des procédés précités sont déterminées par des instructions de programmes d'ordinateurs. 3038176 7 En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un microprocesseur, ce programme comprenant des instructions adaptées à la mise en oeuvre des étapes du procédé tel que mentionné ci-dessus. 5 Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un 10 microprocesseur, et comprenant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un 15 moyen d'enregistrement magnétique, par exemple un disque dur, ou encore une mémoire flash. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens de communication. Le programme selon 20 l'invention peut être en particulier téléchargé sur une plateforme de stockage d'un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. 25 Le support d'informations et le programme d'ordinateur précités présentent des caractéristiques et avantages analogues au procédé qu'ils mettent en oeuvre. BREVE DESCRIPTION DES FIGURES D'autres particularités et avantages de l'invention apparaîtront encore dans 30 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. Sur les figures : - la Figure 1 représente schématiquement un dispositif comprenant un élément sécurisé embarqué conforme à des modes de réalisation de l'invention ; 3038176 8 la Figure 2 illustre, de manière simplifiée, un exemple de système de communication dans lequel des modes de réalisation de la présente invention peuvent être mis en oeuvre ; - la Figure 3 représente, sous forme d'organigramme, des étapes d'un 5 procédé de gestion selon des modes de réalisation de l'invention ; - la Figure 4 représente, sous forme de chronogramme, des étapes d'un procédé de fourniture et d'un procédé de gestion selon des modes de réalisation de l'invention. 10 DESCRIPTION DETAILLEE DE L'INVENTION La Figure 1 représente schématiquement un dispositif hôte 10 comprenant un élément sécurisé 20 conforme à des modes de réalisation de l'invention. Le dispositif hôte 10 est par exemple un terminal mobile, un téléphone portable intelligent (smartphone), une tablette numérique ou encore tout type 15 d'équipement électronique tel qu'un compteur électrique, un véhicule, une machine à café, etc. L'élément sécurisé 20 est incorporé dans le dispositif hôte 10, les deux éléments communiquant par exemple au moyen de commandes APDU (pour Application Protocol Data Unit). Le dispositif hôte 10 comprend notamment un bus de communication 100 20 auquel sont reliées : - une unité de traitement 110 notée CPU (pour Central Processing Unit) et pouvant comporter un ou plusieurs processeurs ; - au moins une mémoire non volatile 120 par exemple ROM (pour Read Only Memory), EEPROM (pour Electrically Erasable Read Only Memory) ou encore 25 Flash; - une mémoire vive 130 ou mémoire cache ou mémoire volatile par exemple RAM (pour Random Access Memory) ; - une interface 140 d'entrées/sorties I/O (pour Input/Output), par exemple un écran, un clavier, une souris ou un autre dispositif de pointage tel qu'un écran tactile 30 ou une télécommande permettant à un utilisateur d'interagir avec le système via une interface graphique ; et - une interface de communication COM 150 adaptée à échanger des données par exemple avec un serveur SM-SR via un réseau, ou une interface de lecture/écriture. 3038176 9 L'élément sécurisé 20 est par exemple une carte à circuit intégré universelle et embarquée (eUICC) conforme à la norme ETSI TS 103 383 ou ETSI 102 221. Il comprend notamment un bus de communication 200 auquel sont reliées : 5 - une unité de traitement 210 -ou microprocesseur- notée CPU (pour Central Processing Unit); - une mémoire non volatile 220 par exemple ROM (pour Read Only Memory), EEPROM (pour Electrically Erasable Read Only Memory) ou encore Flash; - une mémoire vive 230 ou mémoire cache ou mémoire volatile par 10 exemple RAM (pour Random Access Memory) ; et - une interface de communication COM 240 adaptée à échanger des données avec le processeur 110 du dispositif hôte 10 ; de préférence, il s'agit d'une interface ISO 7816. La mémoire vive 230 comprend des registres adaptés à l'enregistrement 15 des variables et paramètres créés et modifiés au cours de l'exécution d'un programme informatique comprenant des instructions pour la mise en oeuvre d'un procédé selon l'invention. Les codes d'instructions du programme stocké en mémoire non-volatile 220 sont chargés en mémoire RAM 230 en vue d'être exécutés par l'unité de traitement CPU 210. 20 La mémoire non-volatile 220 est par exemple une mémoire réinscriptible de type EEPROM ou mémoire Flash pouvant constituer un support au sens de l'invention, c'est-à-dire pouvant comprendre un programme informatique comprenant des instructions pour la mise en oeuvre des procédés selon l'invention. Dans des modes de réalisation, l'élément sécurisé 20 comprend une zone 25 mémoire TAMP réinscriptible dédiée au stockage de paquets de script d'installation de profil. Par exemple, cette zone mémoire réinscriptible TAMP se trouve dans la mémoire non volatile 220, ou éventuellement en mémoire RAM 230. La Figure 2 illustre, de manière simplifiée, un exemple de système de communication dans lequel des modes de réalisation de la présente invention peuvent 30 être mis en oeuvre. Dans cette représentation schématique apparait le dispositif hôte 10 de la Figure 1 embarquant un l'élément sécurisé 20 tel que représenté sur la Figure 1. Le dispositif hôte 10 est par exemple un terminal mobile et l'élément sécurisé 20 qu'il embarque est par exemple une carte eUICC. Bien entendu, un 35 système de communication inclut généralement une pluralité de tels dispositifs hôtes 3038176 10 équipés d'éléments sécurisés embarqués. La présente invention met notamment en oeuvre des opérations particulières dans l'élément sécurisé embarqué. Le système de communication comprend également un réseau de communication 30. Ce réseau 30 est par exemple un réseau de téléphonie mobile 5 comprenant de façon classique des stations de base (non représentées) pour connecter les terminaux mobiles, ainsi qu'une pluralité d'entités (type passerelle GMSC, serveurs HLR, MSC, VLR, etc. non représentées). De manière générale, le réseau 30 comprend un serveur de gestion d'abonnement (SM pour Subscription Manager) représenté ici par deux modules 10 serveur distincts : un serveur de routage sécurisé SM-SR 310 (pour Subscription Manager Secure Routing) et un serveur de préparation de données SM-DP 320 (pour Subscription Manager Data Preparation). Le serveur de préparation de données SM-DP 320 est notamment en charge de la préparation des données de profils et de la gestion de leurs chargement 15 et installation sécurisés sur l'élément sécurisé 20. Le serveur de routage sécurisé SM-SR 310 est notamment en charge de réaliser, de façon sécurisée, le transport des commandes (et donc de scripts de commandes) de gestion de profil aux éléments sécurisés du réseau. Ces deux serveurs sont adaptés à communiquer ensemble au sein de 20 l'entité SM, ainsi qu'avec le dispositif hôte 10 et l'élément sécurisé 20 qu'il incorpore. L'élément sécurisé 20 comprend plusieurs domaines de sécurité 245, 250- 1 et 250-2 tels que définis par la norme Global Platform Card Specification version 2.2.1, et indépendants les uns des autres pour des raisons de sécurité et de confidentialité des données qu'ils mettent en oeuvre. 25 Un domaine de sécurité principal, noté ISD-R 245 (pour lssuer Security Domain Root), est l'entité représentative, dans l'élément sécurisé, du serveur SM-SR 310. Ainsi, l'ISD-R 245 et le serveur SM-SR 310 sont aptes à communiquer via le réseau 30 selon un protocole de transport sécurisé, par exemple selon le protocole SCP80 ou selon le protocole SCP81. En tant que domaine de sécurité principal, 30 l'ISD-R 245 est également en charge de la gestion des autres domaines de sécurité de l'élément sécurisé 20. L'ISD-R 245 a notamment pour fonction de créer un nouveau domaine de sécurité ISD-P (pour lssuer Security Domain Profile) associé à un serveur SM-DP 320 afin de permettre qu'un nouveau profil unique créé par le serveur SM-DP 320 puisse 35 être installé ou chargé conformément à des modes de réalisation de l'invention. 3038176 11 L'ISD-R 245 gère également l'activation et la désactivation des domaines de sécurité ISD-P que l'élément sécurisé peut contenir. En effet, la norme susvisée n'autorise l'activation que d'un seul ISD-P à la fois. L'activation/désactivation de ces domaines a pour effet d'activer/désactiver leurs profils uniques associés. Toutefois, 5 l'ISD-R peut tout à fait désactiver un profil sans que le domaine de sécurité correspondant ne soit lui-même désactivé. En pratique, l'ISD-R 245 reçoit une commande d'activation du serveur SMSM 310 (pour le compte d'un opérateur MNO) afin d'activer un domaine de sécurité ISD-P particulier. Si la commande reçue est acceptable, l'ISD-R 245 l'exécute résultant 10 en l'activation du domaine de sécurité visé et en la désactivation du domaine de sécurité alors actif. Ces mécanismes sont décrits dans la norme GSMA susvisée. Dans des modes de réalisation, afin de faciliter la gestion des profils, l'élément sécurisé 20 comprend un registre de profils (Profile Registry) comprenant une base de données répertoriant un certain nombre d'informations sur les profils 15 comme par exemple leur identifiant respectif. Dans le présent exemple, l'élément sécurisé 20 comprend deux domaines de sécurité ISD-P1 250-1 et ISD-P2 250-2, dans chacun desquels un profil unique (éventuellement en replacement d'un profil précédent) peut être installé conformément à des modes de réalisation de l'invention. Toutefois, la présente invention n'est pas 20 limitée à un nombre donné de domaines de sécurité ISD-P. Par la suite, on vise l'un des domaines de sécurité ISD-P par la référence générique 250. En pratique, le serveur SM-DP 320 est configuré pour préparer les données d'un profil sous forme de script de commandes ou « script d'installation », 25 formé par exemple d'une liste de C-APDU (commandes APDU) définies dans la norme ETSI TS 102 226. Conformément à la norme GSMA 12FAST.15 susvisée, le SM-DP 320 envoie ce script au serveur SM-SR 310 pour transmission. Selon des modes de réalisation de l'invention, le script d'installation est 30 communiqué au serveur SM-SR 310 accompagné d'une commande PLEC (pour Profile Loading Ending Command) qui est associée avec la fin du script d'installation. Ainsi, par exemple, le SM-DP 320 est configuré pour générer la commande PLEC, qui inclut une information d'intégrité globale comprenant par exemple un cryptogramme CRYPTO1 (e.g. signature) basé sur l'ensemble du script d'installation, 35 et calculé par le serveur SM-DP 320. 3038176 12 A titre d'exemple, le cryptogramme CRYPTO1 peut être une signature de l'ensemble du script d'installation du profil, par exemple calculée à partir d'un algorithme de type SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256) ou SHA-3 (pour Secure Hash Algorithm). 5 Un exemple de codage de la commande PLEC incluant le cryptogramme CRYPTO1, est donné ci-dessous à titre indicatif : Code Valeur Signification DGI OxDF6D DGI propriétaire pour l'eUICC Length `ZZ' Longueur des données Command 0x04 Commande PLEC Crypt Tag 0x06 Tag du cryptogramme Lcrypt rYY' Longueur du cryptogramme crypt XX Cryptogramme Selon ces modes de réalisation, l'exécution de cette commande PLEC par l'élément sécurisé 20 aura pour effet de déclencher une vérification de l'intégrité 10 globale du script d'installation tel que reçu par l'élément sécurisé, comme décrit par la suite. Selon des variantes à une commande PLEC contenant l'information d'intégrité globale, l'information d'intégrité globale pourrait être envoyée séparément de la commande PLEC, par exemple avec une portion (les paquets décrits par la suite) du 15 script d'installation autre que la fin dudit script. Le serveur SM-SR 320 est en particulier configuré pour partitionner ou segmenter le script d'installation, à réception de celui-ci, en une pluralité de blocs binaires, par exemple de taille égale, formant des paquets à envoyer à l'élément sécurisé 20. 20 Le serveur SM-SR 320 est également configuré pour associer la commande PLEC reçue avec le dernier paquet formant la pluralité de paquets. De façon générale, puisque la commande PLEC est associée à la fin du script, elle opère comme une indication de dernier paquet pour déclencher la vérification de l'intégrité globale du script d'installation par l'élément sécurisé. 25 De façon classique, le serveur SM-SR 320 est configuré pour communiquer de manière sécurisée avec l'ISD-R 245 à qui il transmet les paquets au cours de sessions sécurisées (protocole sécurisé SCPX). Cette transmission est classique. A réception, l'ISD-R 245 décrypte chaque paquet reçu et le transmet à l'ISD-P 250. Comme déjà mentionné, le dernier paquet du script est envoyé avec la 30 commande PLEC qui indique la fin du script. 3038176 13 Le domaine de sécurité ISD-P 250 est apte à stocker chaque paquet reçu dans une zone mémoire TAMP spécifique de l'élément sécurisé 20 en attente de la vérification de l'intégrité globale selon des modes de réalisation de l'invention. L'exécution de la commande PLEC déclenche la vérification de l'intégrité 5 des paquets alors stockés dans la zone mémoire TAMP prévue à cet effet. Cette vérification d'intégrité, déclenchée par la commande PLEC, utilise l'information d'intégrité globale (comprise dans la commande PLEC ou non). La vérification globale a ici pour finalité de s'assurer que le script d'installation du profil tel que chargé dans la zone mémoire TAMP est intègre, et donc 10 notamment qu'il est complet. Ainsi, l'exécution du script d'installation pour installer le profil en mémoire puis l'activation du profil installé dans l'élément sécurisé peuvent n'être autorisées que lorsque l'ensemble formé par les paquets reçus par l'élément sécurisé est intègre. En variante, l'exécution du script d'installation pour installer le profil en 15 mémoire de l'élément sécurisé peut être systématique à réception de la commande PLEC. En revanche, l'activation du profil ainsi installé peut alors n'être autorisée que lorsque l'ensemble formé par les paquets reçus par l'élément sécurisé est intègre. La Figure 3 représente, sous forme d'organigramme, des étapes d'un procédé de gestion selon des modes de réalisation de l'invention. 20 Ce procédé est typiquement mis en oeuvre dans un élément sécurisé embarqué, tel que l'élément sécurisé 20 apparaissant sur les Figures 1 et 2. En conséquence, et de façon non limitative, la description de cet exemple fait référence à certains éléments des Figures 1 et 2. Le procédé est notamment mis en oeuvre dans l'ISD-P (avec l'aide de l'ISD-R dans les communications avec le SM-SR). 25 Au cours d'une étape E10, l'élément sécurisé 20, en particulier le domaine de sécurité ISD-P reçoit un paquet i (i étant le numéro du paquet reçu, dans un premier temps, i=1 car c'est le premier paquet reçu) d'un script d'installation d'un profil, par exemple un message SMS (pour Short Message Service). En pratique, le paquet est reçu par l'ISD-R via un canal sécurisé de type 30 Secure Channel, établi avec le serveur SM-SR. Le canal sécurisé peut notamment utiliser un protocole de transport sécurisé SCP80, SCP81 (référencés génériquement SCP8x), ainsi qu'un algorithme de type C-MAC (pour block-Cipher-based Message Authentication Code). Puis après décryptage par l'ISD-R du paquet sécurisé reçu, le paquet du script d'installation est transmis à l'ISD-P. 3038176 14 Comme déjà mentionné, le script d'installation du profil est partitionné en une pluralité de paquets, par exemple chacun de la taille d'un message SMS (de 140 octets). Par exemple, le premier paquet reçu est le premier paquet envoyé par le serveur SM-SR. En pratique, les paquets n'arrivent pas nécessairement dans l'ordre 5 dans lequel ils ont été envoyés par le serveur SM-SR, auquel cas un masque représentant une séquence de paquets est utilisé pour replacer les paquets dans l'ordre. D'autres mécanismes permettant d'ordonner les paquets reçus (numérotation des paquets par exemple) peuvent être prévus. Dans le présent exemple, le paquet i a été correctement reçu à l'étape E10 10 conformément au protocole sécurisé, c'est-à-dire que l'ISD-R a pu vérifier l'intégrité du paquet reçu grâce au mécanisme de sécurisation mis en oeuvre sur le canal de transmission. Le paquet intègre est alors chargé (étape E20) dans une zone mémoire réinscriptible TAMP de type EEPROM ou RAM ou encore mémoire Flash de l'élément sécurisé 20 prévue à cet effet, en attendant la réception des autres paquets (ici, des 15 SMS). Dans le cas où le paquet i est reçu sans la commande PLEC (test E30 négatif), signifiant que ce paquet n'est pas le dernier paquet du script d'installation, le procédé continue avec une étape E40 d'envoi, au serveur SM-SR (via l'ISD-R), d'un acquittement (Proof Of Receipt) conforme au format défini dans les normes ETSI 20 102.225 et 102.226. En variante, le paquet reçu peut être chargé dans la zone mémoire TAMP prévue à cet effet (étape E20) seulement après l'envoi E40 de l'acquittement. Ensuite, l'élément sécurisé se met en attente de la réception d'un autre paquet i+1 (E50) à l'occasion d'une nouvelle étape E10. 25 En revanche, si le test E30 est positif signifiant que le paquet i est reçu avec une commande PLEC telle que décrite plus haut, cette commande peut être exécutée (E60) déclenchant une vérification de l'intégrité globale de l'ensemble des paquets reçus par l'élément sécurisé après reconstitution du script par concaténation des paquets tel que stockés dans la zone mémoire TAMP prévue à cet effet. 30 Dans cet exemple, cette commande PLEC inclut l'information d'intégrité globale du script d'installation comprenant le cryptogramme CRYPTO1 généré par le serveur SM-DP suite à la création du profil. Ainsi, dans cet exemple, la réception de l'information d'intégrité globale correspond à la réception du dernier paquet envoyé par le SM-DP avec la commande PLEC. 3038176 15 Au cours de l'étape E60, la commande PLEC est exécutée par l'élément sécurisé 20, ce qui a pour effet de déclencher la vérification de l'intégrité globale de l'ensemble des paquets reçus par l'élément sécurisé, à partir de l'information d'intégrité globale contenue dans celle-ci. 5 En pratique, l'élément sécurisé 20 calcule (étape E70) un cryptogramme CRYPTO2 de type similaire à celui (CRYPTO1) inclus dans la commande PLEC, c'est-à-dire par exemple une signature calculée à partir d'un algorithme de type SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 et SHA-512/256) ou SHA-3 (pour Secure Hash Algorithm), selon l'algorithme utilisé par le serveur SM-DP lors du 10 calcul du cryptogramme CRYPTO1. En particulier, le cryptogramme CRYPTO2 est calculé, par l'élément sécurisé, sur le script reconstitué en mémoire, c'est-à-dire sur l'ensemble des paquets reçus à l'étape E10, puis chargés dans la zone mémoire TAMP prévue à cet effet à l'étape E20, et remis dans l'ordre dans lequel ils ont été envoyés par le SM-SR. 15 Au cours d'un test E80, l'élément sécurisé compare les cryptogrammes CRYPTO1 et CRYPTO2, c'est-à-dire dans cet exemple la signature calculée à l'étape E70 sur les paquets présents dans la zone mémoire TAMP et celle incluse dans la commande PLEC. Si les signatures CRYPTO1 et CRYPTO2 sont égales, cela signifie que le 20 script d'installation reconstitué est intègre, et que tous les paquets qui le composent ont bien été reçus et sont intègres. Le script d'installation du profil est donc intègre dans sa globalité. Dans ce cas, l'élément sécurisé 20 exécute le script d'installation dans le but de charger et installer le profil dans l'ISD-P cible de l'élément sécurisé puis active 25 le profil ainsi installé à l'étape E90a, selon la procédure décrite aux sections 3.1.3, 4.1.3.1 et 5.4.4 de la norme GSMA 12FAST.15. L'activation du profil peut aussi comprendre par exemple le verrouillage du profil pour le rendre impossible à modifier. Dans d'autres modes de réalisation, le script d'installation pour charger et installer le profil dans l'élément sécurisé peut être exécuté avant la vérification de 30 l'intégrité. En d'autres termes, l'étape E90a est formée de deux, sous-étapes, la sous- étape correspondant à l'exécution du script d'installation étant réalisée avant l'étape E80 et la sous-étape correspondant à l'activation du profil installé étant réalisée après l'étape E80. Ainsi, le profil installé par le script d'installation n'est activé que si la vérification d'intégrité permet de conclure que le script d'installation reconstitué est 35 intègre. 3038176 16 Ensuite, au cours d'une étape E100a, l'élément sécurisé 20 envoie un acquittement au serveur SM-SR, similaire à l'acquittement de l'étape E40. En revanche, si le résultat de la vérification globale de l'intégrité de l'étape E80 est négatif car les signatures CRYPTO1 et CRYPTO2 ne sont pas égales, un 5 message d'erreur est transmis (E90b) au serveur SM-SR. Par exemple, le message d'erreur comprend un statut indiquant une erreur dans la signature calculée (CRYPTO2). Par exemple, le message d'erreur est un message SMS comprenant le code 6FD1. L'élément sécurisé peut alors entreprendre la suppression du script 10 reconstitué qui n'est pas intègre, c'est-à-dire la suppression des paquets chargés dans la zone mémoire TAMP prévue à cet effet (étape E100b). En variante, cette étape peut être effectuée pendant ou avant l'envoi du message d'erreur au serveur SM-SR. Optionnellement, à réception du message d'erreur, le serveur SM-SR peut décider de renvoyer le script d'installation du profil par paquets, conduisant à la 15 réexécution de l'algorithme de la Figure 3. Dans l'exemple décrit ci-dessus, l'information d'intégrité globale est incluse dans la commande PLEC. En variante, l'information d'intégrité globale (comprenant par exemple un cryptogramme) peut être reçue séparément de la commande PLEC par exemple dans un message (SMS) indépendant ou encore avec un des paquets du 20 script d'installation, autre que le dernier paquet, auquel cas le cryptogramme serait alors reçu avant la commande PLEC dont la réception déclenche la vérification du cryptogramme tel que décrit ci-avant. La Figure 4 représente, sous forme de chronogramme, des étapes d'un procédé de fourniture et d'un procédé de gestion selon des modes de réalisation de 25 l'invention. Les étapes du procédé de fourniture décrit ci-dessous peuvent être mises en oeuvre conjointement par les serveurs SM-SR 310 et SM-DP 320 mentionnés auparavant en référence à la Figure 2. Les étapes du procédé de gestion décrit ci-dessous peuvent être mises en oeuvre par l'élément sécurisé 20, en particulier via 30 l'ISD-P décrit ci-avant. Dans un premier temps, le serveur SM-DP 320 prépare et envoie (étape E110) au serveur SM-SR 310, un script d'installation de profil ainsi qu'une commande PLEC comprenant l'information d'intégrité globale sous la forme du cryptogramme CRYPTO1 calculé à partir de l'ensemble du script d'installation généré. En variante, 3038176 17 l'information d'intégrité globale, ici le cryptogramme CRYPTO1, peut être envoyée séparément de la commande PLEC. Comme déjà mentionné, le cryptogramme CRYPTO1 comprend par exemple une signature calculée à partir d'un algorithme de type SHA-2 (SHA-224, 5 SHA-256, SHA-384, SHA-512, SHA-512/224 et SHA-512/256) ou SHA-3 (pour Secure Hash Algorithm). A l'étape E115, le serveur SM-SR 310 partitionne le script d'installation du profil reçu du serveur SM-DP 320 à l'étape E110, en une pluralité de paquets, par exemple de la taille d'un SMS de 140 octets. 10 A l'étape E120, le serveur SM-SR transmet un premier paquet à l'élément sécurisé, qui le reçoit (étape similaire à l'étape E10 de la Figure 3). A l'étape E130, le paquet reçu à l'étape E120 est chargé dans une zone mémoire TAMP de l'élément sécurisé 20 prévue à cet effet (étape similaire à l'étape E20 de la Figure 3). 15 A l'étape E140, l'ISD-P transmet un acquittement (Proof Of Receipt) au serveur SM-SR (étape similaire à l'étape E40 de la Figure 3). En variante, le paquet pourrait être chargé dans la zone mémoire TAMP (étape E130) seulement après l'envoi de l'acquittement. A l'étape E150, le serveur SM-SR transmet un second paquet à l'ISD-P, qui 20 le reçoit (étape similaire à l'étape E120). A l'étape E160, le paquet reçu à l'étape E120 est chargé dans la zone mémoire TAMP (étape similaire à l'étape E130). A l'étape E170, l'ISD-P transmet un acquittement (Proof Of Receipt) au serveur SM-SR (étape similaire à l'étape E140). En variante, le paquet pourrait être 25 chargé dans la zone mémoire TAMP (étape E160) seulement après l'envoi de l'acquittement. Le serveur SM-SR transmet d'autres paquets de script à l'ISD-P (étapes non représentées), et des étapes similaires aux étapes E150 à E170 sont mises en oeuvre pour chacun de ces paquets permettant de récupérer progressivement, dans la 30 zone mémoire TAMP, l'ensemble des paquets formant le script d'installation. Le dernier paquet du script est envoyé par le SM-SR à l'étape E180. Conformément à l'invention, ce paquet est envoyé avec la commande PLEC, dont la réception indique à l'ISD-P que le paquet reçu est le dernier du script d'installation. Il est rappelé que dans cet exemple, la commande PLEC inclut une information 35 d'intégrité globale comprenant un cryptogramme. En variante, l'information d'intégrité 3038176 18 globale pourrait être envoyée séparément, par exemple avec un des autres paquets du script. Au cours de l'étape E190, ce dernier paquet est mémorisé dans la zone mémoire TAMP avec les autres paquets déjà reçus (étape similaire aux étapes E130 et 5 E160). L'ISD-P détecte alors la présence de la commande PLEC dans le paquet reçu, déclenchant l'étape E200 durant laquelle la commande PLEC est exécutée. L'ensemble des paquets reçus et stockés dans la zone mémoire TAMP est remis dans l'ordre dans lequel les paquets ont été envoyés par le SM-SR. Puis ces paquets ainsi 10 ordonnés sont concaténés afin de reconstituer le script d'installation. La vérification globale de l'ensemble des paquets reçus est alors déclenchée, de manière similaire aux étapes E60 à E80 de la Figure 3. Cette vérification d'intégrité du script reconstitué se base sur l'information d'intégrité globale reçue, dans cet exemple, dans la commande PLEC. 15 En pratique, un cryptogramme CRYPTO2 de type similaire à celui inclus dans la commande PLEC (CRYPTO1) est calculé par l'ISD-P à partir du script reconstitué. Le cryptogramme ainsi calculé et le cryptogramme inclus dans la commande PLEC sont ensuite comparés. Si les cryptogrammes sont égaux, cela signifie que le script d'installation 20 reconstitué est intègre et conforme au script d'installation fourni par le SM-DR pour transmission. Dans ce cas, l'ISD-P exécute à l'étape E210a le script d'installation dans le but de charger et installer le profil dans l'ISD-P puis d'activer le profil ainsi installé (étape similaire à l'étape E100a de la Figure 3), puis envoie un acquittement (étape E220a) au serveur SM-SR (similaire à l'acquittement de l'étape E90a de la Figure 3). 25 Dans d'autres modes de réalisation, le script d'installation peut être exécuté avant la vérification de l'intégrité. Toutefois, le profil correspondant alors installé n'est activé que si la vérification permet de conclure que le script d'installation reconstitué est intègre. L'acquittement peut aussi être envoyé en même temps que l'exécution du 30 script d'installation par l'ISD-P (comme dans l'exemple représenté sur la Figure 3). En revanche, si les cryptogrammes ne sont pas égaux, cela signifie que le script d'installation reconstitué n'est pas intègre et donc pas conforme au script d'installation initial, par exemple, parce qu'un paquet le composant n'a pas été reçu. Dans ce cas, l'ISD-P supprime les paquets présents dans la zone mémoire TAMP 35 (étape E210b similaire à l'étape E100b de la Figure 3), puis transmet (étape E220b) 3038176 19 un message d'erreur au serveur SM-SR (étape similaire à l'étape E90b de la Figure 3). En variante, la suppression des paquets peut être effectuée pendant ou après l'envoi du message d'erreur au serveur SM-SR (comme dans l'exemple 5 représenté dans la Figure 3). Optionnellement, à réception du message d'erreur, le serveur SM-SR peut lui aussi mettre en oeuvre des actions (étape E240) en conséquence de la vérification négative de l'intégrité. Par exemple, il peut décider de renvoyer le script d'installation du profil par paquets (c'est-à-dire ré-exécuter les étapes E120 à E180), ou encore 10 commander un audit de l'élément sécurisé afin de vérifier l'état de celui-ci. Pour ce faire, une commande 'Audit' telle que définie dans la section 4.1.1.5 de la norme GSMA 12FAST.15 peut être envoyée à l'élément sécurisé pour connaitre l'état de celui-ci et des profils installés. Les exemples qui précèdent ne sont que des modes de réalisation de 15 l'invention qui ne s'y limite pas. Des caractéristiques de ces exemples peuvent être combinées afin de mettre en oeuvre d'autres modes de réalisation couverts par l'invention. REVENDICATIONS1. Procédé de gestion de profil dans un élément sécurisé, ledit procédé comprenant les étapes suivantes, par l'élément sécurisé : - réception (E10), sur un canal sécurisé, d'au moins un paquet d'une pluralité de paquets formant un script d'installation d'un profil et d'une information d'intégrité globale dudit script d'installation ; - à réception d'un paquet comportant une indication de dernier paquet du script d'installation, vérification (E70, E80), à l'aide de ladite information d'intégrité globale reçue, de l'intégrité globale de l'ensemble des paquets reçus, lesdits paquets reçus formant un script d'installation reconstitué ; - exécution du script d'installation reconstitué pour installer ledit profil dans l'élément sécurisé et activation (E90a) dudit profil installé, uniquement lorsque la vérification globale d'intégrité est positive. 2. Procédé de gestion selon la revendication 1, dans lequel l'étape de vérification de l'intégrité globale comprend les étapes suivantes : - calcul (E70) d'un cryptogramme à partir de l'ensemble des paquets reçus ; et - comparaison (E80) du cryptogramme calculé avec ladite information d'intégrité globale. 3. Procédé de gestion selon la revendication 1 ou 2, dans lequel l'exécution dudit script d'installation reconstitué n'est effectuée que lorsque la vérification globale d'intégrité est positive, ou seule l'activation dudit profil installé est effectuée uniquement lorsque la vérification globale d'intégrité est positive. 4. Procédé de gestion selon l'une quelconque des revendications 1 à 3, dans lequel lesdits paquets de la pluralité sont des messages SMS (Short Message Service). 5. Procédé de gestion selon l'une quelconque des revendications 1 à 4, dans lequel l'intégrité de chaque paquet reçu est assurée par l'utilisation d'un protocole de transport sécurisé pour la transmission du paquet à l'élément sécurisé. 3038176 21 6. Procédé de gestion selon la revendication 5, dans lequel chaque paquet intègre reçu est stocké dans une zone mémoire (TAMP) de l'élément sécurisé prévue à cet effet, et ladite vérification globale de l'intégrité comprend la vérification de l'intégrité du script d'installation reconstitué formé par l'ensemble des paquets stockés 5 dans ladite zone mémoire. 7. Procédé de fourniture d'un profil à un élément sécurisé, ledit procédé comprenant les étapes suivantes, au niveau d'un serveur d'un réseau de communication : 10 - partitionnement (E115) d'un script d'installation d'un profil en une pluralité de paquets, le dernier paquet de la pluralité comprenant une indication de dernier paquet ; - obtention (E110) et transmission (E180), à destination de l'élément sécurisé, d'une information d'intégrité globale dudit script d'installation ; et 15 - transmission (E120 ; E150 ; E180), à destination de l'élément sécurisé, desdits paquets de sorte que la réception, par l'élément sécurisé, du paquet comportant l'indication de dernier paquet déclenche (E200) une vérification globale de l'intégrité des paquets reçus par l'élément sécurisé à l'aide de ladite information d'intégrité globale transmise. 20 8. Procédé de fourniture selon la revendication 7, comprenant une étape de réception (E220b), par le serveur, d'un message d'erreur en provenance de l'élément sécurisé en réponse au paquet comportant l'indication de dernier paquet. 25 9. Procédé de fourniture selon la revendication 8, comprenant, en réponse à la réception du message d'erreur, une nouvelle étape de transmission (E240), à destination de l'élément sécurisé, desdits paquets formant le script d'installation et de l'information d'intégrité globale. 30 10. Procédé de fourniture selon l'une quelconque des revendications 7 à 9, comprenant une étape de calcul, par le serveur, d'un cryptogramme à partir dudit script d'installation du profil, avant son partitionnement en une pluralité de paquets, ladite information d'intégrité globale comprenant ledit cryptogramme calculé. 3038176 22 11. Procédé de fourniture selon l'une quelconque des revendications 7 à 10, dans lequel l'étape de partitionnement (E115) comprend le partitionnement du script d'installation dudit profil en une pluralité de messages SMS (short message service). 5 12. Support d'informations lisible par un microprocesseur, comprenant les instructions d'un programme d'ordinateur pour mettre en oeuvre un procédé selon l'une quelconque des revendications 1 à 11. 10 13. Elément sécurisé (20) comportant : - un récepteur configuré pour recevoir, sur un canal sécurisé, au moins un paquet d'une pluralité de paquets formant un script d'installation d'un profil, et une information d'intégrité globale dudit script d'installation ; - un vérificateur d'intégrité configuré pour vérifier, à réception d'un paquet 15 comportant une indication de dernier paquet du script d'installation et à l'aide de ladite information d'intégrité globale reçue, l'intégrité globale de l'ensemble des paquets reçus, lesdits paquets reçus formant un script d'installation reconstitué; et - un processeur configuré pour exécuter le script d'installation reconstitué pour installer ledit profil dans l'élément sécurisé et activer ledit profil uniquement 20 lorsque la vérification d'intégrité est positive. 14. Elément sécurisé (20) selon la revendication 13, consistant en une carte à circuit intégré universelle et embarquée (eUICC) conforme à la norme ETSI TS 103 383 ou une carte à circuit intégré universelle (UICC) conforme à la norme ETSI TS 25 102 221. 15. Serveur (310, 320), configuré pour fournir un profil à un élément sécurisé, ledit serveur comprenant : - un module de partitionnement d'un script d'installation d'un profil en une 30 pluralité de paquets, le dernier paquet de la pluralité comprenant une indication de dernier paquet ; - un module d'obtention d'une information d'intégrité globale dudit script d'installation ; et - un transmetteur configuré pour transmettre, à destination de l'élément 35 sécurisé, lesdits paquets et l'information d'intégrité globale obtenue, de sorte que la 3038176 23 réception, par l'élément sécurisé, du paquet comportant l'indication de dernier paquet déclenche une vérification globale de l'intégrité des paquets reçus par l'élément sécurisé à l'aide de ladite information d'intégrité globale transmise.