FR 3037167 A1 20161209 FR 1555072 A 20150604 1 PROCEDE DE PROVISIONNEMENT D'UN SCRIPT D'INSTALLATION A UN MODULE SECURISE, MODULE SECURISE ET SERVEUR DE PROVISIONNEMENT Le domaine de l'invention concerne un procédé de provisionnement d'un script d'installation pour un module sécurisé, un module sécurisé et un serveur de provisionnement. Il est connu de sécuriser un module de communication ou un module d'exécution d'applications logicielles au moyen de traitements cryptographiques, reposant par exemple sur l'utilisation de clés ou certificats scellés dans une carte à circuit intégré. Un tel module sécurisé peut être un circuit embarqué sécurisé, connu également par l'acronyme eSE pour « embedded Secure Element, ou une carte de circuit intégré universelle et embarquée eUICC « embedded Universal Integrated Circuit Card ». Sous une autre forme, la carte de circuit intégré et universelle peut être une carte amovible de type UICC, par exemple une carte SIM (« Subscriber Identity Module » pour module d'identité de souscripteur). Lors de sa fabrication, il est courant de provisionner un module sécurisé avec un profil de souscripteur auprès d'un opérateur de services payants et des applications logicielles dites sécurisées. Le provisionnement du profil de souscripteur ou d'une application est opéré par l'exécution d'un script d'installation, correspondant généralement à une séquence de commandes APDU écrivant dans l'espace mémoire non-volatile du module sécurisé, espace scellé et dont l'accès est restreint au moyen de mécanismes d'authentification. Lorsque le souscripteur souhaite modifier son profil ou ses applications logicielles sécurisées, il peut dans le cas d'un circuit intégré amovible remplacer sa carte à circuit intégré. Dans le cas d'un circuit intégré embarqué, il est connu de provisionner un nouveau profil souscripteur ou de nouvelles applications logicielles au moyen d'un serveur distant de provisionnement via un canal de communication sécurisé. On connaît dans l'état de la technique la demande de brevet européen EP2584755A1 décrivant une méthode pour envoyer des applications orientées « Commande » d'un serveur distant à un module sécurisé. On connaît également la demande de brevet américain US20140134981A1 décrivant une méthode pour établir une connexion sécurisée avec un module sécurisé pour le provisionnement d'un profil opérateur à distance. 3037167 2 Il est connu que lors du provisionnement le serveur dirige la transmission des données au module sécurisé. Le serveur transmet les données tandis que le module sécurisé informe le serveur s'il est disponible pour recevoir les données. Lors du provisionnement à distance, il est probable que des coupures de connexion 5 interviennent lors de la communication entre le serveur et le module sécurisé. Cela peut être le cas lorsque l'utilisateur du module sécurisé se déplace dans une zone non desservie par le réseau de télécommunication mobile, par exemple un tunnel ou un espace couvert. La spécification technique GSMA, « Remote Provisioning Architecture for Embedded UICC », version 2.0 du 12 octobre 2014, fournit des spécifications au chapitre 3.1.3 pour la mise en 10 opération du provisionnement à distance entre un serveur et un module sécurisé. Elle prévoit également la procédure à mettre en oeuvre en cas d'erreur lors du provisionnement. Le chapitre 3.1.4 préconise l'effacement de la totalité du script d'installation en cours de provisionnement puis une réinitialisation de la totalité du protocole d'installation lorsque la communication est rétablie. 15 En effet, lors d'une perte de communication le serveur n'est pas en capacité de connaître les parties du script d'installation qui ont été reçues par le module sécurisé. De plus, il est primordial d'empêcher l'écriture de doublons de parties du script d'installation au risque d'entrainer la panne du module sécurisé. De plus, la sécurisation du canal sécurisé selon le protocole SCP03 (pour « Secure 20 Channel Protocol 03» est assurée par le chiffrement des données du script d'installation à base de clés de chiffrement de session et d'un compteur scellés dans le circuit intégré, et dont la rotation du compteur est commandée à chaque commande APDU du script d'installation. Pour sa mise en application, la rotation doit être synchronisée entre le serveur et le module sécurisé. Or, lors d'une perte de communication le serveur ne peut reprendre le chiffrement des 25 données et la transmission et garantir la synchronisation du chiffrement. En cas de désynchronisation le traitement des données du script d'installation par le module sécurisé est rendu impossible. Pour cela, le protocole de gestion des erreurs prévoit l'effacement de toutes les données puis une réinitialisation complète du processus de provisionnement. De plus, le serveur n'est pas informé du stade de traitement des données par le module 30 sécurisé et ne peut donc pas s'assurer du bon traitement par le module sécurisé. 3037167 3 Il existe donc un besoin de palier les problèmes précités. Plus précisément, l'invention concerne un procédé de provisionnement d'un script d'installation préparé par un serveur pour un module sécurisé à communication sans fil. Selon l'invention, le procédé comprend les étapes successives suivantes : 5 - la préparation par le serveur du script d'installation de sorte qu'il soit divisé en une pluralité de blocs d'instructions; - la transmission d'au moins un premier bloc du serveur au module sécurisé via la communication sans fil; - le traitement du premier bloc par le module sécurisé ; 10 - la notification d'un statut du traitement du premier bloc par le module sécurisé au serveur ; - la transmission d'un deuxième bloc du serveur au module sécurisé ou la répétition de la transmission du premier bloc en fonction du statut du traitement du premier bloc ; - la finalisation du provisionnement lorsque le module sécurisé a exécuté avec succès le 15 traitement de la pluralité des blocs. En variante, le procédé comprend en outre une étape de création d'une table de description de la pluralité des blocs de données par le serveur, la transmission de la table du serveur au module sécurisé et la lecture de la table par le module sécurisé pour le traitement d'au moins le premier bloc. 20 Avantageusement, le traitement du premier bloc comprend au moins l'écriture du premier bloc dans une mémoire volatile du module sécurisé. Avantageusement, le procédé comprend en outre une étape préalable de détermination de la capacité de la mémoire volatile du module sécurisé de sorte que lors de la préparation du script d'installation la taille des blocs est dimensionnée pour correspondre à la capacité de la mémoire 25 volatile. Plus précisément, les blocs comprennent chacun une séquence d'instructions de commandes APDU conformes à la norme ISO/IEC 7816-4. 3037167 4 De préférence, le traitement du premier bloc comprend également l'exécution de la séquence de commandes APDU pour l'écriture de données dans une mémoire non-volatile du module sécurisé. De préférence, la notification du statut du traitement du premier bloc comprend au 5 moins le statut de l'exécution de la séquence de commandes APDU. Selon une variante, le procédé comprend en outre une étape de chiffrement de la pluralité des blocs par le serveur pour une vérification d'intégrité et/ou d'une signature par le module sécurisé. Selon une variante, le chiffrement du premier bloc est exécuté au moyen d'une clé de 10 chiffrement et d'une première valeur d'un compteur et le chiffrement du deuxième bloc est exécuté au moyen de la clé de chiffrement et d'une deuxième valeur du compteur. L'invention prévoit également un module sécurisé à communication sans fil pour l'exécution d'un script d'installation préparé par un serveur. Selon l'invention, le module sécurisé comprend : 15 - une interface pour la réception d'un premier bloc d'instructions parmi une pluralité de blocs constituant le script d'installation issu du serveur via la communication sans fil; - un moyen de calcul : a) pour le traitement d'au moins le premier bloc ; b) pour la détermination d'une notification d'un statut du traitement d'au moins le 20 premier bloc à destination du serveur pour autoriser la transmission d'un deuxième bloc et pour finaliser le provisionnement du script lorsque le traitement de la pluralité des blocs par le module sécurisé a été exécuté avec succès. Selon une variante, il comprend un moyen de mémorisation d'une table de description de la pluralité des blocs et le moyen de calcul comprend également un moyen de lecture de la table 25 pour le traitement d'au moins le premier bloc. Selon une variante, il comprend en outre un moyen de mémorisation d'une séquence d'instructions de commandes APDU conformes à la norme ISO/IEC 7816-4 contenue dans au moins le premier bloc. 3037167 5 Le moyen de calcul comprend au moins un moyen d'exécution de la séquence de commandes APDU pour l'écriture de données dans une mémoire non-volatile. Selon une variante, la notification du statut du traitement d'au moins le premier bloc comprend au moins le statut de la mémorisation de la séquence d'instruction de commandes APDU 5 et/ou le statut de l'exécution de la séquence de commandes APDU. De préférence, le moyen de calcul comprend également un moyen de vérification de l'intégrité et/ou d'une signature d'au moins le premier bloc. L'invention prévoit également un serveur de provisionnement d'un script d'installation pour un module sécurisé à communication sans fil comprenant un moyen de préparation du script 10 d'installation et une interface pour la transmission du script au module sécurisé via la communication sans fil. Selon l'invention, le moyen de préparation est apte à préparer le script d'installation de sorte qu'il soit divisé en une pluralité de blocs d'instructions et l'interface comprend un moyen pour autoriser la transmission d'un deuxième bloc en fonction d'une notification de statut de traitement 15 d'un premier bloc émise par le module sécurisé. Selon une variante, le moyen de préparation est apte à créer une table de description de la pluralité des blocs de données par le serveur et l'interface est apte à transmettre la table de description au module sécurisé. De préférence, le serveur comprend en outre un moyen de chiffrement de la pluralité 20 des blocs pour une vérification d'intégrité et/ou d'une signature par le module sécurisé. Selon une variante, le chiffrement du premier bloc est exécuté au moyen d'une clé de chiffrement et d'une première valeur d'un compteur et le chiffrement du deuxième bloc Bj est exécuté au moyen de la clé de chiffrement et d'une deuxième valeur du compteur. Grâce à l'invention, le procédé de provisionnement réduit le temps d'exécution de 25 l'installation d'un applicatif dans le module sécurisé lorsqu'une coupure de connexion ou une erreur intervient, notamment pour la gestion de l'interruption et pour la reprise de l'installation. Le procédé permet par ailleurs de réduire les ressources requises par le serveur et l'exposition à une perte de connexion d'une communication entre le serveur et le module sécurisé. 3037167 6 Il permet également de réduire le temps d'occupation du réseau de communication pour l'installation d'un applicatif Ceci est avantageux lors d'un provisionnement collectif. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description détaillée qui suit comprenant des modes de réalisation de 5 l'invention donnés à titre d'exemples nullement limitatifs et illustrés par les dessins annexés, dans lesquels : - la figure 1 représente les entités électroniques opérant lors du provisionnement et l'exécution d'un script d'installation pour un module sécurisé ; - la figure 2 représente l'entité fonctionnelle d'un serveur en charge de la préparation 10 d'un script d'installation pour un module sécurisé ; - la figure 3 représente l'entité fonctionnelle d'un serveur en charge du transport de données entre un serveur et un module sécurisé ; - la figure 4 représente le module sécurisé destiné à recevoir et exécuter le script d'installation préparé par le serveur ; 15 - la figure 5 représente une première séquence du flux d'étapes du procédé de provisionnement du script d'installation ; - la figure 6 représente une deuxième séquence du flux d'étapes du procédé de provisionnement du script d'installation lorsqu'une coupure de communication intervient entre le serveur et le module sécurisé ; 20 L'invention s'adresse aux systèmes de provisionnement d'applicatifs sécurisés pour un module sécurisé via une communication sans fil. Le provisionnement intervient pour l'installation ou la mise à jour d'un applicatif. On entend par applicatif sécurisé une application logicielle, par exemple de type « APPLET » (terminologie couramment utilisée en langage français et anglais) ou « API » pour « Application Programmable Interface » en anglais (par exemple en langage JAVA), un simple fichier 25 contenant des données, ou un environnement applicatif (par exemple JAVA CARD) destiné à être exécuté dans un module sécurisé de type eUICC, UICC ou eSE. Ces applicatifs sécurisés sont installés dans le module sécurisé au moyen d'un script d'installation préparé dans un serveur distant à partir de données informatives liées au souscripteur, de mécanismes de sécurités propres à l'opérateur du service et de l'applicatif exécutable dans le module sécurisé. 3037167 7 Dans une variante, le script d'installation est un fichier orienté « Commande ». La figure 1 représente un système comprenant un module sécurisé MS et un serveur distant SV pour le provisionnement d'applicatifs sécurisés destinés à être hébergés et exécutés par le module sécurisé MS. Le système de provisionnement opère le provisionnement de fichiers de profils 5 de souscripteur à un service de téléphonie mobile pour un opérateur de téléphonie 14 (couramment appelé MNO pour « Mobile Network Operator » en anglais). Un fichier de profils de souscripteur est installé dans le module sécurisé dans un domaine sécurisé, appelé également par l'acronyme ISD-P conformément à la spécification technique GSMA précitée. On rappelle que l'invention ne se limite pas à l'installation de fichier de souscripteur à 10 un réseau de communication cellulaire. On notera que la spécification technique GSMA « Remote Provisioning Architecture for Embedded UICC », version 2.0 du 12 octobre 2014, fournit des spécifications au chapitre 3.1 pour l'installation d'un profil opérateur dans un module sécurisé. Le module sécurisé MS est une entité électronique par exemple un circuit embarqué 15 sécurisé, une carte de circuit intégré universelle et embarquée eUICC, ou une carte de circuit intégré et universelle amovible de type SIM. Le module sécurisé MS est généralement hébergé dans un terminal, par exemple un lecteur, un téléphone mobile ou tout appareil électronique requérant l'utilisation du module sécurisé pour l'opération de services sécurisés. Dans cette description le module sécurisé MS est une carte de circuit intégré universelle 20 et embarquée eUICC. Le module sécurisé MS est hébergé dans un terminal (non représenté sur la figure 1) comprenant des moyens de communication sans fil 12 pour l'échange des données avec le serveur distant SV. Les moyens de communications sans fil sont par exemple un émetteur/récepteur de signaux de communication de téléphonie cellulaire permettant la communication de messages (SMS 25 pour « Short Message Service » en anglais), la communication à protocole de transfert hypertext (HTTPS pour « Hypertext Transfet Protocol Secure » en anglais) ou la communication à protocole CAT-TP (« Card Application Toolkit Transport Protocol » en anglais). D'autres moyens de communication sans fil entre le module sécurisé et le serveur distant SV sont envisageables, par exemple via un réseau de communication à moyenne distance 30 WIFI selon la norme IEEE 802.11 ou une communication sans fil courte distance de type NFC (« Near 3037167 8 Field Communication » en anglais). Dans ce dernier cas, on peut envisager que le serveur soit connecté à un terminal de provisionnement délocalisé du centre de données à des fins de provisionnement dans un lieu public. Le serveur distant de provisionnement SV comprend un moyen de préparation 10 d'un 5 script d'installation et une interface 11 pour assurer la transmission de données avec le module sécurisé. La figure 2 et la figure 3 représentent respectivement le moyen de préparation 10 du script d'installation et l'interface 11 du serveur SV. La figure 2 décrit le moyen de préparation 10 du script d'installation. Selon la spécification technique GSMA précitée le moyen de préparation 10 est désigné par l'acronyme 10 SM_DP pour « Subscription Manager Data Preparation »). Le moyen de préparation 10 est mis en opération par un calculateur, des mémoires et des fonctions logicielles. Le moyen de préparation 10 prépare les données à transmettre et à installer dans le module sécurisé MS. Le moyen de préparation 10 comprend un moyen 106 pour préparer des scripts d'installation 105 à exécuter dans un module sécurisé MS pour l'installation d'une application telle 15 que mentionnée précédemment. Un script d'installation 105 est par exemple une séquence d'instructions de commandes APDU pour l'échange de données entre le terminal et le module sécurisé MS conformément à la norme ISO/IEC 7816-4. Le script d'installation 105 est un fichier orienté « Commande ». Une commande est par exemple une commande STORE DATA. 20 Dans le cadre de l'invention, le moyen 106 à partir d'informations de configuration provenant de l'opérateur 14 prépare à la volée un script d'installation 101 divisé en une pluralité de blocs d'instructions B1 à Bn pour être transmis au module sécurisé MS. La pluralité de blocs peut être au nombre de deux blocs au minimum ou plus. La quantité de blocs est déterminée en fonction de la taille mémoire du script d'installation 101 et de l'espace de la mémoire tampon du module sécurisé. 25 Le contenu du script d'installation 101 est similaire au script d'installation 105. Il s'agit généralement d'un fichier orienté « commande ». Dans une variante, si le script d'installation est déjà préparé avant la requête de provisionnement, par exemple un script 105 déjà préparé et mémorisé dans le moyen de préparation 10 du serveur SV, le script d'installation 105 est traité de sorte à obtenir un script d'installation 101 30 divisé en la pluralité de blocs d'instructions. Un script d'installation 105 déjà préparé est alors divisé (fragmenté) en une pluralité de blocs d'instructions. 3037167 9 On notera que la taille des blocs est déterminée préalablement à partir d'un fichier d'informations descriptives du module sécurisé connu de l'interface 11 du serveur distant SV. Pour cela, le serveur SV doit être renseigné avec une information décrivant la taille de la mémoire tampon du module sécurisé MS. Cette information est par exemple enregistrée dans le fichier descriptif du 5 module sécurisé (appelée EIS pour « eUICC Information Set » selon la spécification technique GSMA précitée). Par exemple, la taille mémoire maximum d'un bloc peut être déterminée par la commande getElS d'une application d'interface API décrite dans la spécification technique de la norme GSMA précitée. Cette commande intervient pour les communications du serveur, entre le 10 moyen de préparation 10 et l'interface 11 ou entre le moyen de préparation 10 et une autre une entité externe, par exemple un serveur d'opérateur de téléphonie. Le plus souvent, la séquence d'instructions de commandes APDU d'un bloc est dépendante de la séquence du bloc précédent et du bloc suivant. Il est donc prévu que la transmission des blocs suive un ordre prédéterminé par le moyen de préparation 10. 15 Eventuellement, on peut envisager que des blocs indépendants les uns de autres puissent être alternés lors de la transmission durant le provisionnement. De plus, le moyen de préparation 10 comprend un moyen de chiffrement de la pluralité des blocs d'instructions B1 à Bn pour une vérification d'intégrité et/ou d'une signature par le module sécurisé MS. Parallèlement, on prend l'hypothèse que le module sécurisé MS a été chargé lors de sa 20 fabrication avec des certificats nécessaires pour l'exécution des vérifications cryptographiques. Par ailleurs, il est préférable que le moyen de chiffrement opère également un processus d'authentification mutuelle avec le module sécurisé MS pour établir une communication sécurisée avant la transmission d'un bloc de données et opère le chiffrement des blocs d'instructions pour cacher les données à un tiers non autorisé. 25 Par exemple, le moyen de chiffrement est conforme à la spécification technique SCP03 décrite dans le document « Global Platform Card Technology - Secure Channel Protocol 03 - Card Specification V2.2 Amendment D », version 1.1.1, july 2014. Ce processus de chiffrement implique l'utilisation de clés de chiffrement dont la rotation est assurée par un compteur, tous deux scellés dans la carte à circuit intégré du module sécurisé MS. 30 Dans le cadre de l'invention, le chiffrement d'un premier bloc est exécuté au moyen de la clé de 3037167 10 chiffrement et d'une première valeur d'un compteur et le chiffrement d'un deuxième bloc est exécuté au moyen de la clé de chiffrement et d'une deuxième valeur du compteur. De son côté, le module sécurisé MS comprend des moyens de chiffrement permettant de procéder à la vérification des blocs d'instructions issus du serveur SV. Par exemple, ces moyens de 5 chiffrement hébergés par le module sécurisé sont conformes à la spécification technique SCP03 précitée. Il est envisageable en variante que la rotation du chiffrement soit opérée par une fonction de diversification de type pseudo-aléatoire, l'algorithme de diversification pouvant opéré en parallèle de façon synchronisée du côté du serveur et du module sécurisé. 10 Par ailleurs, en parallèle de la préparation du script d'installation 101, on peut envisager que le moyen de préparation 10 comprenne un moyen de création 104 d'une table de description 102 des blocs B1 à Bn formant le script d'installation 101. La table de description 102 est destinée à être transmise au module sécurisé MS pour le traitement des blocs d'instructions B1 à Bn. La table de description 102 peut comprendre tout ou partie des informations suivantes 15 pour chaque bloc : - la liste des blocs B1 à Bn constituant le script d'installation 101; - la taille mémoire d'un bloc; - une adresse d'accès pour demander le provisionnement du bloc (par exemple URL pour « Uniform Resource Locator » en anglais) ; 20 - la position d'un bloc dans la séquence d'instruction des commandes ; - un cryptogramme de sécurité par bloc d'instructions (appelé « Digest » ou « hash » en anglais) pour une vérification d'intégrité et/ou de signature du bloc, ainsi que la méthode de chiffrement utilisée. Dans une variante, on peut également envisager que chaque bloc contienne ces 25 informations descriptives mentionnées ci-avant pour éviter de recourir à la transmission de la table de description 102. 3037167 11 En outre, le serveur 10 comprend des moyens pour communiquer l'ensemble d'installation 103 préparé par le moyen de préparation 10 à l'interface 11, l'ensemble d'installation 103 contenant le script d'installation 101 divisé en blocs et la table de description 102. La figure 3 décrit plus précisément, l'interface 11 du serveur SV. Selon la spécification 5 technique GSMA précitée l'interface 11 est désignée par l'acronyme SM_SR pour « Subscription Manager Secure Routing » en anglais). L'interface assure la transmission du script d'installation 101, divisé en blocs d'instructions prédéterminés par le moyen de préparation 10. L'interface 11 assure le transport des données via la communication sans fil 12 à destination du module sécurisé MS. Dans le cas de la variante du procédé de provisionnement comprenant une étape de 10 création de la table de description 102 des blocs B1 à Bn, l'interface 11 assure la transmission de la table de description 102 au module sécurisé MS. Le script d'installation 101, et la table de description 102 des blocs du script d'installation 101 le cas échéant, est transmis du moyen de préparation 10 à l'interface 11 pour la transmission au module sécurisé MS. 15 On notera que l'interface 11 est renseignée avec des informations spécifiques relatives au module sécurisé MS et on peut envisager que celle-ci soit additionnée par des informations supplémentaires non renseignée dans le moyen de préparation 10. L'interface 11 comprend également des moyens de mémorisation pour l'enregistrement temporaire du script d'installation 101 et la table de description 102 des blocs du script d'installation 20 101 le cas échéant, en attente de l'exécution du procédé de provisionnement. Par ailleurs, l'interface 11 comprend un moyen 111 pour autoriser la transmission d'un bloc en fonction d'une notification 112 de statut de traitement d'un bloc émise par le module sécurisé MS. Il s'agit d'une fonction logicielle de vérification du serveur SV visant à contrôler que le traitement du bloc d'instructions précédemment envoyé au module sécurisé MS a été exécuté avec 25 succès. Le moyen 111 permet au serveur SV d'identifier le dernier bloc d'instruction qui a été traité avec succès, d'une part pour autoriser la transmission du bloc suivant parmi la pluralité de blocs d'instruction B1 à Bn, et d'autre part pour déterminer l'avancement du procédé de provisionnement du script d'installation en cas de perte de connexion. Une fois la connexion 30 revenue, le serveur peut reprendre le procédé de provisionnement au bloc qui est positionné à la 3037167 12 suite du dernier bloc traité avec succès en réponse à une requête de transmission de blocs émise par le module sécurisé MS. Le moyen 111 de vérification du traitement d'un bloc d'instruction par le module sécurisé offre un autre avantage dans le cas particulier d'un script d'installation comprenant les 5 commandes APDU. On notera que le moyen de vérification 111 assure la chronologie de traitement des blocs d'instructions. De plus, le moyen 111 assure la synchronisation d'un compteur du processus de chiffrement des blocs d'instructions entre le serveur SV et le module sécurisé MS. En effet, le processus de chiffrement opère une rotation du compteur lors du provisionnement des blocs 10 d'instruction et le moyen 111 autorise également la rotation du compteur en fonction de la notification 112. En cas de succès du traitement d'un bloc d'instructions par le module sécurisé MS, le moyen 111 déclenche la rotation du compteur ou de la fonction de diversification. Le moyen de préparation 10 et l'interface 11 du serveur SV sont des fonctions logicielles 15 exécutées par la même architecture matérielle, ou dans une autre variante peuvent être opérées dans des entités matérielles distinctes. Des moyens de communications, filaires ou sans fil (HTTPS par exemple), permettent la communication de données de façon sécurisée. Le serveur est une entité électronique à processeur exécutant des fonctions logicielles. Il peut être envisagé dans une variante d'architecture que l'opérateur de téléphonie 20 cellulaire héberge l'ensemble serveur SV et le serveur 14 au sein d'une même entité électronique. La figure 4 représente le module sécurisé MS. Le module sécurisé MS communique avec le serveur SV via une communication sécurisée 12. Le module sécurisé MS est une entité électronique à processeur de calcul et mémoires électroniques, de type UICC, eUICC ou eSE. Le module sécurisé MS comprend une mémoire tampon volatile pour la mémorisation 25 temporaire des blocs d'instructions B1 à Bn du script d'installation 101 en attente de leur exécution et une mémoire non-volatile pour la mémorisation des données résultant de l'exécution du script d'installation, un profil opérateur MNO, ou plus généralement d'un applicatif tel que décrit précédemment. 3037167 13 La mémoire tampon permet en outre la mémorisation d'une séquence d'instructions de commandes APDU conformes à la norme ISO/IEC 7816-4 contenue dans un bloc d'instruction B1 à Bn. Le module sécurisé comprend également un calculateur pour l'exécution d'instructions 5 de commandes, par exemple les commandes APDU. En outre, il comprend une interface 121 pour la réception des blocs d'instructions parmi la pluralité de blocs B1 à Bn constituant le script d'installation 101 issu du serveur SV via la communication sans fil. L'interface 121 du module sécurisé MS est prévue pour collaborer avec l'interface 11 du serveur SV. L'interface 121 est appelée également par l'acronyme ISD-R 10 conformément à la spécification technique GSMA précitée. Le calculateur opère le traitement des blocs B1, Bj, à Bn, ainsi que la détermination de la notification 112 du statut du traitement des blocs à destination du serveur SV pour autoriser la transmission des blocs suivants et pour finaliser le provisionnement du script 101 lorsque le traitement de la pluralité des blocs a été exécuté avec succès. 15 Dans une variante, la fonction de détermination de la notification 112 est une fonction logicielle de contrôle de commande APDU exécutées par le module sécurisé par exemple. Le traitement d'un bloc d'instructions correspond à la mémorisation d'un bloc d'instructions, par exemple une séquence d'instructions de commandes APDU conformes à la norme ISO/IEC 7816-4 contenue dans le bloc. 20 De préférence, le traitement d'un bloc comprend également, en plus de la mémorisation d'un bloc d'instruction, l'exécution des commandes du bloc, par exemple l'exécution de la séquence de commandes APDU pour l'écriture de données dans une mémoire non-volatile. Le module sécurisé comprend par exemple un espace sécurisé 122 pour l'hébergement d'un domaine privatif de l'opérateur, ISD-P selon la norme GSMA précitée. Le traitement comprend 25 l'exécution de commande de type STORE DATA dans le module sécurisé, par exemple, pour l'installation d'un profil opérateur MNO. Pour assurer la sécurisation de l'exécution d'un script d'installation, le moyen de calcul du module sécurisé comprend également un moyen de vérification de l'intégrité et/ou d'une signature d'un bloc d'instruction du script d'installation 101. 3037167 14 Il convient de charger dans le module sécurisé lors de sa fabrication les certificats permettant l'opération de vérification de signatures, et les clés de chiffrement pour l'opération de vérification des « digest » ou « hash », correspondant à la terminologie courante anglaise pour des cryptogrammes de sécurité intervenant dans la vérification d'intégrité de données. 5 Par ailleurs, les moyens de chiffrement du module sécurisé sont aptes à déchiffrer les blocs d'instructions du script d'installation 101 si ceux-ci sont préalablement chiffrés par le serveur, notamment dans le cadre d'un processus de sécurisation de type SCP03. On notera que les vérifications sont réalisées avant le l'exécution des blocs d'instructions par le module sécurisé. 10 Lorsqu'une table de description 102 des blocs d'instructions B1 à Bn est transmise avant la transmission d'un script d'installation 101, celle-ci est mémorisée temporairement dans le module sécurisé. Elle est lue à des fins de vérification de signature et/ou d'intégrité des blocs d'instruction et pour la détermination de la notification 112 du statut du traitement d'un bloc et la notification de fin du provisionnement. 15 La figure 5 représente un flux d'étape du procédé de provisionnement d'un script d'installation 101 d'un serveur SV, comprenant le moyen 10 de préparation du script et l'interface 11, à un module sécurisé MS. Le procédé peut comprendre une première étape de détermination 500 de la capacité de la mémoire volatile du module sécurisé MS de sorte que lors de la préparation du script 20 d'installation la taille des blocs B1 à Bn est dimensionnée pour correspondre à la capacité de la mémoire volatile. Par exemple, les blocs d'instruction ont une taille mémoire d'environ 1 à 2Ko. Le moyen de préparation 10 envoie une requête d'interrogation à l'interface 11 qui est renseignée avec les informations descriptives du module sécurisé (type de processeur/calculateur, quantité de mémoire, interface etc..). Par exemple une requête getElS d'une application d'API peut 25 opérer l'étape de détermination 500. Le procédé procède ensuite à une deuxième étape de préparation 501 par le serveur SV du script d'installation 101 de sorte qu'il soit divisé en une pluralité de blocs d'instructions B1 à Bn. Comme indiqué précédemment dans la description, la préparation peut être exécutée soit à la volée, soit en modifiant la structure d'un script d'installation 105 déjà existant. 3037167 15 Par exemple, les blocs B1 à Bn comprennent chacun une séquence d'instructions de commandes APDU conformes à la norme ISO/IEC 7816-4. Les blocs forment une séquence d'écriture de données pour l'installation ou la mise à jour d'un applicatif sécurisé dans le module sécurisé MS. L'ordre d'exécution des blocs peut être une contrainte. 5 Lors de la préparation 501, il est préférable à des fins de sécurisation du provisionnement que le procédé comprenne en outre une étape de chiffrement de la pluralité des blocs B1 à Bn par le serveur SV pour une vérification d'intégrité et/ou d'une signature par le module sécurisé MS. Il est également préférable que le chiffrement comprenne un traitement 10 cryptographique pour cacher les données des blocs d'instructions lors de la transmission au module sécurisé. Par exemple, le chiffrement est conforme aux spécifications SCP03. On notera dans ce dernier cas que le chiffrement d'un premier bloc B1 est exécuté au moyen d'une clé de chiffrement et d'une première valeur d'un compteur et le chiffrement d'un deuxième bloc Bj est exécuté au moyen de la clé de chiffrement et d'une deuxième valeur du 15 compteur. La rotation du compteur est exécutée lors de la préparation de chacun des blocs B1 à Bn. Dans une variante, le procédé peut prévoir en outre une troisième étape de création 502 d'une table de description 102 de la pluralité des blocs de données par le serveur SV. La table de description 102 contient les informations mentionnées ci-avant dans la description du serveur. Elle peut comprendre une indication temporelle d'exécution des blocs pour respecter la chronologie. 20 Le procédé de provisionnement comprend ensuite une quatrième étape de transmission 503 de la table de description 102 à l'interface 11 du serveur SV. On peut envisager que le procédé comprenne une étape d'ajout par l'interface 11 d'informations descriptives à la table 102, par exemple une adresse d'accès (URL par exemple) à un bloc de d'instruction. 25 A une cinquième étape, le procédé de provisionnement comprend une étape de demande par l'interface 11 du serveur SV d'une ouverture 504 de session d'une communication sécurisée avec le module sécurisé MS. Le déclenchement est opéré via une communication SMS ou HTTPS par exemple. 3037167 16 Ensuite, le procédé comprend une étape de la sollicitation par le module sécurisé MS d'une session de communication sécurisée avec le serveur SV via son interface 11, par exemple via un protocole d'authentification mutuelle prévu dans le processus SCP03. La sollicitation par le module sécurisé comprend une requête d'envoi du premier bloc 5 d'instructions B1 du serveur SV vers le module sécurisé, par exemple à l'adresse URL renseignée dans la table de description 102. Le procédé de provisionnement comprend ensuite une sixième étape 505 opérant la transmission via la communication sans fil 12 du premier bloc B1 du serveur SV au module sécurisé MS. La transmission est par exemple par communication HTTPS, SMS, ou CAT-TP. Le premier bloc est 10 renseigné au niveau de l'interface 11 du serveur SV, ou le cas échéant défini dans la table de description 102. Ensuite, le procédé de provisionnement comprend une septième étape de traitement 506 du premier bloc B1 par le module sécurisé MS. Il est prévu dans le procédé une étape de lecture de la table 102 par le module sécurisé MS pour le traitement 506 du premier bloc si la table de 15 description des blocs a été reçue. Plus précisément, le traitement 506 du premier bloc B1 comprend comprend une étape d'écriture du premier bloc B1 dans une mémoire volatile du module sécurisé MS. La mémoire volatile est la mémoire tampon du module sécurisé MS. Le premier bloc est mémorisé temporairement en attente de l'exécution des instructions. L'exécution est réalisée uniquement lorsque toutes les 20 commandes du bloc sont mémorisées par le module sécurisé MS. Lors du traitement 506, le procédé comprend également une étape de vérification du premier bloc d'intégrité, de la signature le cas échéant au moyen d'un certificat hébergé dans le module sécurisé, et le déchiffrement des données du blocs d'instructions si celles-ci ont été transmises cachées. 25 Dans une variante préférée, le procédé comprend lors du traitement 506, l'étape d'exécution des instructions du premier bloc B1, par exemple l'exécution de la séquence de commandes APDU pour l'écriture de données dans une mémoire non-volatile du module sécurisé MS. Dans une variante, les commandes APDU opèrent l'installation du profil de l'opérateur 30 MNO dans le module MS. Par exemple, selon les spécifications GSMA précitées l'exécution de la 3037167 17 séquence de commande APDU crée un domaine sécurisé 122 dans l'espace mémoire non-volatile appelé ISD-P. Le processus d'installation correspond au chapitre 3.1.3 de la spécification technique GSMA précitée. On notera que si l'espace de la mémoire tampon du module sécurisé le permet, dans 5 une variante du procédé, la pluralité des blocs B1 à Bn est mémorisée dans le module sécurisé puis l'exécution des blocs d'instructions est opérée. La table de description 102 permet de coordonner l'exécution des blocs d'instruction. Dans cette variante, le signal de notification de statut 112 du traitement est élaboré pour vérifier la mémorisation, l'intégrité et la signature de chaque bloc d'instruction. 10 Une fois que le le traitement du premier bloc B1 est opéré avec succès, le procédé de provisionnement comprend une huitième étape de notification 507 du statut du traitement du premier bloc B1 par le module sécurisé MS au serveur SV. Le traitement et la détermination de la notification de statut sont élaborés par le calculateur du module sécurisé MS. La notification 507 à destination du serveur SV permet d'autoriser l'envoi du bloc 15 d'instructions suivant. Le contrôle du provisionnement du script d'installation est ainsi contrôlé et suivi par le module sécurisé MS. On notera que dans la variante correspondant à des blocs d'instruction de commandes APDU, la notification 507 du statut du traitement du premier bloc B1 comprend au moins le statut de l'exécution de la séquence de commandes APDU, par exemple des commandes de type STORE DATA. 20 La notification 507 peut comprendre une adresse d'accès au deuxième bloc d'instruction renseignée dans la table de description, le bloc d'instruction lui même, par exemple une adresse URL ou un numéro d'index que le module sécurisé MS va concaténer à une adresse URL de référence. Ensuite, le procédé prévoit une nouvelle étape de transmission 508 d'un deuxième bloc du serveur SV au module sécurisé MS. L'étape de traitement 506 et l'étape de notification 507 est 25 ensuite répétée pour le deuxième bloc et les blocs suivant tant que le traitement des blocs est exécuté avec succès par le module sécurisé. Enfin, les étapes de transmission 508, de traitement 509 et de notification 510 de statut de traitement des blocs sont exécutées jusqu'au dernier bloc Bn. 3037167 18 Pour terminer, le procédé de provisionnement comprend une étape de finalisation du provisionnement lorsque le module sécurisé MS a exécuté avec succès le traitement de la pluralité des blocs B1 à Bn. Le module sécurisé termine la communication sécurisée avec le serveur. Sur réception de la notification de traitement du dernier bloc, l'interface 11 du serveur 5 renseigne sa base de données avec les informations descriptives des applicatifs sécurisés hébergés dans le module sécurisé MS. Par ailleurs, dans une variante recommandée du procédé le serveur procède à une étape d'effacement du script d'installation de l'applicatif sécurisé une fois reçue la notification de traitement du dernier bloc. 10 On notera également que le procédé comprend une étape de transmission 512, de l'interface 11 au moyen de préparation 10 du serveur SV, d'une notification du statut de l'exécution du provisionnement. La figure 6 représente le flux d'étapes du procédé de provisionnement lorsqu'une perte de communication intervient durant le provisionnement lors de la transmission d'un bloc 15 d'instructions intermédiaire Bj. Les étapes du procédé de provisionnement 500 à 507 sont identiques aux étapes décrites dans la figure 5. La notification 507 correspond à un statut de traitement du bloc d'instructions B1 réussi (mémorisation et exécution dans le module sécurisé MS). A l'étape 601, le procédé comprend une autre étape de transmission d'un bloc 20 d'instructions, le bloc Bj, puis une étape de traitement 602 du bloc Bj du script d'installation 101 par le module sécurisé MS. Dans ce scénario on prend l'hypothèse que durant le traitement 602 la communication entre le serveur SV et le module sécurisé MS est perdue (cas d'un passage de tunnel par exemple). Le bloc Bj n'a donc pas pu être reçu entièrement par l'interface 121 ou n'a pas pu être exécuté. 25 Dans ce cas-ci, lors du retour de la disponibilité de la communication avec le serveur SV (ou après une temporisation prédéterminée avec la perte de communication) le procédé de provisionnement comprend une nouvelle demande d'ouverture 603 de session d'une communication sécurisée par le module sécurisé MS à l'interface 11 du serveur SV. 3037167 19 Il comprend une ensuite une dixième étape de répétition de la transmission 604 du bloc Bj. Le bloc Bj est entièrement retransmis après réception de la requête d'ouverture d'une session de communication avec le serveur SV issu du module sécurisé. Au niveau du serveur SV, en cas de perte de communication avec le module sécurisé 5 MS, une notification a été générée pour indiquer l'échec du traitement du bloc (incluant l'échec de la mémorisation du bloc). La notification d'échec peut avoir été déterminée en fonction d'une temporisation interne du serveur SV ou un statut de la connexion. A une étape 605, le procédé comprend le traitement du bloc Bj, pour lequel dans ce cas-ci le traitement est exécuté avec succès. Le traitement comprend la mémorisation, et le cas échéant 10 l'exécution des instructions du bloc. A une étape 606, le procédé comprend une étape de transmission de la notification de statut de traitement du bloc Bj de sorte à autoriser la transmission du boc suivant. Cette notification comprend également l'adresse d'accès du bloc suivant Les blocs suivants sont ensuite transmis du serveur au module sécurisé, puis traité par le 15 module sécurisé, les uns après les autres jusqu'au dernier bloc d'instruction, tant que la notification de statut du traitement indique un traitement exécuté avec succès. Les étapes finales 508, 509, 510, 511 et 512 sont identiques à la description du procédé de la figure 5. Les fonctions logicielles du procédé de provisionnement sont mises en oeuvre par un 20 produit programme informatique exécuté par un (ou des) calculateur du serveur SV et un calculateur du module sécurisé MS. On rappelle que l'invention s'adresse au provisionnement et l'exécution de scripts d'installation pour tout type d'applicatif sécurisé et destinés à être exécuté par l'environnement opératif du module sécurisé MS hébergé dans un terminal. Les fonctions logicielles de mises en 25 oeuvre du procédé de provisionnement entre le serveur et le module sécurisé opèrent aux moyens d'applicatifs logiciels API. L'invention s'applique aux UICC et eUICC de préférence embarquées dans un terminal. L'environnement opératif est de type JAVA CARD par exemple. L'invention s'applique à la mise à jour et l'installation d'applicatifs sécurisés (par exemple APPLET, fichier profil de souscripteur à un réseau 30 de communication cellulaire). 3037167 20 Le terminal peut être un téléphone cellulaire ou tout système électronique mobile, portable ou installation immobile, notamment dans le cadre d'un système M2M de communication entre machines électroniques (« Machine to Machine » en anglais). 5 REVENDICATIONS1. Procédé de provisionnement d'un script d'installation (101) préparé par un serveur (SV) pour un module sécurisé (MS) à communication sans fil, caractérisé en ce qu'il comprend les étapes successives suivantes : - la préparation (501) par le serveur (SV) du script d'installation (101) de sorte qu'il soit divisé en une pluralité de blocs d'instructions (B1-Bn); - la transmission (505) d'au moins un premier bloc (B1) du serveur (SV) au module sécurisé (MS) via la communication sans fil; - le traitement (506) du premier bloc (B1) par le module sécurisé (MS) ; - la notification (507) d'un statut du traitement du premier bloc (B1) par le module sécurisé (MS) au serveur (SV) ; - la transmission (508) d'un deuxième bloc (Bj) du serveur (SV) au module sécurisé (MS) ou la répétition de la transmission du premier bloc en fonction du statut du traitement du premier bloc ; - la finalisation du provisionnement lorsque le module sécurisé (MS) a exécuté avec succès le traitement de la pluralité des blocs (B1-Bn). 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape de création (502) d'une table de description (102) de la pluralité des blocs de données par le serveur (SV), la transmission de la table (102) du serveur (SV) au module sécurisé (MS) et la lecture de la table (102) par le module sécurisé (MS) pour le traitement (506) d'au moins le premier bloc. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que le traitement (506) du premier bloc (B1) comprend au moins l'écriture du premier bloc (B1) dans une mémoire volatile du module sécurisé (MS). 4. Procédé selon la revendication 3, caractérisé en ce qu'il comprend en outre une étape préalable de détermination (500) de la capacité de la mémoire volatile du module sécurisé (MS) de 3037167 22 sorte que lors de la préparation (501) du script d'installation (101) la taille des blocs (B1-Bn) est dimensionnée pour correspondre à la capacité de la mémoire volatile. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que les blocs (B1-Bn) comprennent chacun une séquence d'instructions de commandes APDU conformes à la 5 norme ISO/IEC 7816-4. 6. Procédé selon la revendication 5, caractérisé en ce que le traitement (506) du premier bloc (B1) comprend également l'exécution de la séquence de commandes APDU pour l'écriture de données dans une mémoire non-volatile du module sécurisé (MS). 7. Procédé selon la revendication 6, caractérisé en ce que la notification (507) du statut 10 du traitement du premier bloc (B1) comprend au moins le statut de l'exécution de la séquence de commandes APDU. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce qu'il comprend en outre une étape de chiffrement de la pluralité des blocs (B1-Bn) par le serveur (SV) pour une vérification d'intégrité et/ou d'une signature par le module sécurisé (MS). 15 9. Procédé selon la revendication 8, caractérisé en ce que le chiffrement du premier bloc (B1) est exécuté au moyen d'une clé de chiffrement et d'une première valeur d'un compteur et le chiffrement du deuxième bloc (Bj) est exécuté au moyen de la clé de chiffrement et d'une deuxième valeur du compteur. 10. Module sécurisé à communication sans fil pour l'exécution d'un script d'installation 20 (101) préparé par un serveur (SV), caractérisé en ce qu'il comprend : - une interface (121) pour la réception d'un premier bloc d'instructions parmi une pluralité de blocs (B1-Bn) constituant le script d'installation (101) issu du serveur (SV) via la communication sans fil; - un moyen de calcul : 25 a) pour le traitement d'au moins le premier bloc (B1) ; b) pour la détermination d'une notification d'un statut du traitement d'au moins le premier bloc (B1) à destination du serveur (SV) pour autoriser la transmission d'un deuxième bloc (Bj) et pour finaliser le provisionnement du script (101) lorsque le traitement de la pluralité des blocs (B1-Bn) par le module sécurisé (MS) a été exécuté avec succès. 3037167 23 11. Module sécurisé selon la revendication 10, caractérisé en ce qu'il comprend un moyen de mémorisation d'une table (102) de description de la pluralité des blocs et en ce que le moyen de calcul comprend également un moyen de lecture de la table (102) pour le traitement (506) d'au moins le premier bloc. 5 12. Module sécurisé selon la revendication 10 ou 11, caractérisé en ce qu'il comprend en outre un moyen de mémorisation d'une séquence d'instructions de commandes APDU conformes à la norme ISO/IEC 7816-4 contenue dans au moins le premier bloc. 13. Module sécurisé selon la revendication 12, caractérisé en ce que le moyen de calcul comprend au moins un moyen d'exécution de la séquence de commandes APDU pour l'écriture de 10 données dans une mémoire non-volatile. 14. Module sécurisé selon la revendication 13, caractérisé en ce que la notification du statut du traitement d'au moins le premier bloc (B1) comprend au moins le statut de la mémorisation de la séquence d'instruction de commandes APDU et/ou le statut de l'exécution de la séquence de commandes APDU. 15 15. Module sécurisé selon l'une quelconque des revendications 10 à 14, caractérisé en ce que le moyen de calcul comprend également un moyen de vérification de l'intégrité et/ou d'une signature d'au moins le premier bloc (B1). 16. Serveur (SV) de provisionnement d'un script d'installation (101) pour un module sécurisé (MS) à communication sans fil (12) comprenant un moyen de préparation (10) du script 20 d'installation (101) et une interface (11) pour la transmission du script (101) au module sécurisé (MS) via la communication sans fil (12), caractérisé en ce que le moyen de préparation (10) est apte à préparer le script d'installation (101) de sorte qu'il soit divisé en une pluralité de blocs d'instructions (B1-Bn) et en ce que l'interface (11) comprend un moyen pour autoriser la transmission d'un deuxième bloc (Bj) en fonction d'une notification (112) de statut de traitement d'un premier bloc 25 (B1) émise par le module sécurisé (MS). 17. Serveur (SV) selon la revendication 16, caractérisé en ce que le moyen de préparation (10) est apte à créer (502) une table de description (102) de la pluralité des blocs de données par le serveur (SV) et en ce que l'interface (11) est apte à transmettre la table de description (102) au module sécurisé (MS). 3037167 24 18. Serveur (SV) selon la revendication 16 ou 17, caractérisé en ce qu'il comprend en outre un moyen de chiffrement de la pluralité des blocs (B1-Bn) pour une vérification d'intégrité et/ou d'une signature par le module sécurisé (MS). 19. Serveur (SV) selon la revendication 18, caractérisé en ce que le chiffrement du 5 premier bloc est exécuté au moyen d'une clé de chiffrement et d'une première valeur d'un compteur et le chiffrement du deuxième bloc Bj est exécuté au moyen de la clé de chiffrement et d'une deuxième valeur du compteur.