FR3029722A1 - Procede d'emission conditionnelle de donnees d'un serveur a un terminal, terminal et ensemble serveur associes - Google Patents

Abstract

L'invention concerne un procédé d'émission conditionnelle de données d'un serveur à un terminal (T), comprenant les étapes suivantes : - génération d'un défi par un processeur (P) du terminal (T) ; - transmission du défi à un environnement d'exécution sécurisé (C) hébergé par le terminal (T) ; - génération d'un cryptogramme dans l'environnement d'exécution sécurisé (C) par application au défi d'un algorithme cryptographique ; - émission par le terminal (T) du défi et du cryptogramme à destination du serveur (S) via un réseau de télécommunication (I, R) ; - vérification, au niveau du serveur (S), de la concordance du cryptogramme et du défi en vue de l'authentification du terminal (T) ; - lorsque ladite concordance est vérifiée à l'étape de vérification, lancement d'un mécanisme de préparation de données et envoi des données préparées à destination du terminal (T) via ledit réseau de télécommunication (I, R). Un terminal et un ensemble serveur associés sont également proposés.

Description

1 DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne l'authentification d'un terminal par un serveur et la préparation de données destinées au terminal par le serveur. Elle concerne plus particulièrement un procédé d'émission conditionnelle de données d'un serveur à un terminal, ainsi qu'un terminal et un ensemble serveur associés. L'invention s'applique particulièrement avantageusement dans le cas où le terminal héberge un environnement d'exécution sécurisé, par exemple un environnement d'exécution de confiance ou un module sécurisé tel qu'une carte à microcircuit. ARRIERE-PLAN TECHNOLOGIQUE Le document WO 2014/086 652 décrit un procédé d'authentification d'un 15 élément sécurisé par un serveur dans lequel un agent est exécuté dans un environnement distinct de l'élément sécurisé. Selon ce document, l'agent transmet à l'élément sécurisé un défi fourni par le serveur et reçoit en retour un mot de passe à usage unique calculé par l'élément sécurisé d'après le défi et des données secrètes mémorisées dans 20 l'élément sécurisé. OBJET DE L'INVENTION Dans ce contexte, la présente invention propose un procédé d'émission conditionnelle de données d'un serveur à un terminal, comprenant les étapes suivantes : 25 - génération d'un défi par un processeur du terminal ; - transmission du défi à un environnement d'exécution sécurisé hébergé par le terminal ; - génération d'un cryptogramme dans l'environnement d'exécution sécurisé par application au défi d'un algorithme cryptographique ; 30 - émission par le terminal du défi et du cryptogramme à destination du serveur via un réseau de télécommunication ; - vérification, au niveau du serveur, de la concordance du cryptogramme et du défi en vue de l'authentification du terminal ; - lorsque ladite concordance est vérifiée à l'étape de vérification (et dans 3029722 2 ce cas seulement), lancement d'un mécanisme de préparation de données et envoi des données préparées à destination du terminal via ledit réseau de télécommunication. Le terminal peut ainsi préparer les données d'authentification constituées 5 par le cryptogramme de sa propre initiative, sans nécessiter un échange préalable avec le serveur. De son côté, le serveur ne lance le mécanisme de préparation des données (par exemple des commandes destinées au processeur du terminal) que lorsque le terminal est authentifié par vérification de la concordance du 10 cryptogramme et du défi, c'est-à-dire par vérification que le cryptogramme est bien le résultat de l'application au défi de l'algorithme cryptographique précité, ce qui permet d'éviter une préparation inutile des données lorsque le terminal n'est pas authentifié. La transmission du défi à l'environnement d'exécution sécurisé est par exemple réalisée au moyen d'une commande INITIALIZE UPDATE définie dans la spécification GlobalPlatform relative au protocole SCP03 (pour "Secure Channel Protocol 03") ou au moyen d'une commande INITIALIZE UPDATE définie dans la spécification GlobalPlatform relative au protocole SCP02 (pour "Secure Channel Protocol 02"). L'exécution de cette commande par l'environnement d'exécution sécurisé peut alors mettre en oeuvre l'étape précitée de génération du cryptogramme. On utilise ainsi des fonctionnalités usuellement présentes dans un tel environnement d'exécution sécurisé, sans avoir à installer un logiciel dédié dans cet environnement sécurisé. D'autres caractéristiques optionnelles (et donc non limitatives) de l'invention sont les suivantes : - les étapes de génération du défi, de transmission du défi et d'émission du défi et du cryptogramme sont mises en oeuvre du fait de l'exécution d'une application par le processeur ; - le défi est généré par tirage aléatoire ; - l'algorithme cryptographique utilise une clé secrète mémorisée dans l'environnement d'exécution sécurisé ; - l'environnement d'exécution sécurisé est réalisé par un module sécurisé ; - le procédé comprend une étape de transmission du cryptogramme 3029722 3 généré du module sécurisé au processeur (avant émission du défi et du cryptogramme par le terminal) ; - l'environnement d'exécution sécurisé est réalisé par un environnement d'exécution de confiance ; 5 - le terminal est conçu pour fonctionner sélectivement dans un environnement d'exécution polyvalent ou dans ledit environnement d'exécution de confiance ; - l'application précitée est exécutée dans l'environnement d'exécution polyvalent ; 10 - l'étape de vérification est mise en oeuvre par un module matériel de sécurité associé au serveur ; - le procédé comprend une étape de comparaison, au niveau du serveur, du défi reçu et de défis préalablement reçus et mémorisés au niveau du serveur, le mécanisme de préparation de données étant lancé seulement si le défi reçu est 15 différent de chacun des défis préalablement reçus, ce qui permet de vérifier comme expliqué plus loin que le défi reçu n'est pas le rejeu d'un défi précédent ; - ladite préparation de données est une génération d'un script ; - le script généré est un script de personnalisation ou un script de gestion de carte ; 20 - le procédé comprend une étape de chiffrement du script au moyen d'un algorithme cryptographique de chiffrement utilisant une clé de chiffrement obtenue en utilisant le défi ; - les étapes de génération du cryptogramme et de vérification de la concordance sont conformes à un protocole de type SCP02 ou SCP03.

25 L'invention propose également un terminal comprenant un processeur et des moyens de mise en oeuvre d'un environnement d'exécution sécurisé conçu pour générer un cryptogramme par application d'un algorithme cryptographique à un défi, caractérisé en ce qu'une mémoire associée au processeur mémorise une application conçue pour générer le défi, pour transmettre le défi à l'environnement 30 d'exécution sécurisé, pour recevoir le cryptogramme en provenance de l'environnement d'exécution sécurisé et pour émettre le défi et le cryptogramme à destination d'un serveur via un réseau de télécommunication, lorsque l'application est exécutée par le processeur. L'invention propose aussi un ensemble serveur comprenant des moyens 3029722 4 de réception d'un défi et d'un cryptogramme en provenance d'un terminal via un réseau de télécommunication ; des moyens de vérification de la concordance du cryptogramme et du défi en vue de l'authentification du terminal ; et des moyens, activés seulement en cas de vérification de la concordance par les moyens de 5 vérification, pour lancer un mécanisme de préparation de données et envoyer les données préparées à destination du terminal via ledit réseau de télécommunication. On propose en outre un système comprenant un terminal tel qu'exposé ci-dessus et un ensemble serveur comme il vient d'être indiqué.

10 DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. Sur les dessins annexés : 15 - la figure 1 représente un exemple de système dans lequel peut être mise en oeuvre l'invention ; - la figure 2 représente un procédé conforme à l'invention mis en oeuvre au sein du système de la figure 1. La figure 1 représente schématiquement les éléments principaux d'un 20 système dans lequel peut être mise en oeuvre l'invention. Un tel système comprend un terminal T connecté, au moyen d'une infrastructure de réseau R, à un réseau public I, tel que le réseau Internet. Le terminal T est ici un terminal mobile (tel qu'un téléphone cellulaire) et l'infrastructure de réseau R est donc ici une infrastructure de réseau mobile.

25 Le terminal T comprend ici un processeur P (par exemple un microprocesseur) capable d'exécuter des instructions de programme d'ordinateur (mémorisées dans une mémoire non-représentée associée au processeur P) afin de mettre en oeuvre un procédé tel que celui décrit ci-dessous dans le cadre de la figure 2.

30 Le terminal T reçoit par ailleurs dans un lecteur dédié (non représenté) une carte à microcircuit C. Le lecteur est connecté au processeur P de manière à permettre un échange de données entre la carte à microcircuit C et le processeur P, comme schématiquement représenté par un trait plein en figure 1. La carte à microcircuit C comprend un microprocesseur et une mémoire 3029722 5 (par exemple une mémoire non-volatile réinscriptible). La mémoire mémorise des instructions de programme d'ordinateur qui, lorsqu'elles sont exécutées par le microprocesseur de la carte à microcircuit C permettent la mise en oeuvre de procédés par la carte à microcircuit C, notamment le procédé décrit ci-dessous en 5 référence à la figure 2. La mémoire mémorise également des clés cryptographiques secrètes utilisées comme décrit dans la suite, notamment une première clé statique K-MAC et une seconde clé statique K-ENC. La carte à microcircuit C est ici de type UICC (pour "Universal Integrated 10 Circuit Card'). En variante, il pourrait s'agir d'un autre type de module sécurisé, par exemple un élément sécurisé intégré (ou eSE pour "embedded Secure Element"). La carte à microcircuit C définit un environnement d'exécution sécurisé, avec par exemple un niveau de sécurité conforme aux critères communs EAL 15 (pour "Evaluation Assurance Lever), correspondant à la norme ISO 15408, avec un niveau compris entre 2 et 7, ou à la norme FIPS (pour "Federal Information Processing Standard') 140-2. Dans l'exemple de la figure 1, le terminal T comprend ainsi le processeur P, qui définit un environnement d'exécution à visée générale, et la carte à 20 microcircuit C (avec son propre microprocesseur), qui définit un environnement d'exécution sécurisé. En variante, le terminal T pourrait n'inclure qu'un seul processeur P sur lequel s'exécute sélectivement un système d'exploitation polyvalent (ou "Rich OS") afin de faire fonctionner le terminal T dans un environnement d'exécution 25 polyvalent (ou REE pour "Rich Execution Environment"), ou un système d'exploitation de confiance (ou "Trusted OS") afin de faire fonctionner le terminal T dans un environnement d'exécution de confiance (ou TEE pour "Trusted Execution Environment"). Un tel environnement d'exécution de confiance forme un environnement d'exécution sécurisé (utilisable en lieu et place de la carte à 30 microcircuit C), avec par exemple un niveau de sécurité tel que défini ci-dessus. Le terminal T comprend par ailleurs un module de communication (non représenté) afin d'établir une communication avec l'infrastructure de réseau R (ici avec une station de base de cette infrastructure), ce qui permet au terminal T (et précisément en pratique au processeur P) d'échanger des données avec d'autres 3029722 6 dispositifs électroniques ou ordinateurs connectés sur le réseau public I, notamment comme expliqué plus loin avec un serveur S connecté sur le réseau public I. Un module matériel de sécurité M (ou HSM pour "Hardware Security 5 Module") est relié, ici connecté via un réseau local L, au serveur S. Par ailleurs, un ordinateur de préparation de données D est également connecté sur ce réseau local L. Le module matériel de sécurité M mémorise notamment des données secrètes associées à des cartes à microcircuit utilisées dans des terminaux, en 10 particulier, en association avec un identifiant ID de la carte à microcircuit C, des données secrètes associées à la carte à microcircuit C, telles que la première clé statique K-MAC et la seconde clé statique K-ENC. La figure 2 représente un procédé conforme à l'invention, mis en oeuvre ici au sein du système de la figure 1.

15 Le procédé représenté en figure 2 débute par une étape optionnelle E0 de transmission du serveur S au processeur P d'une instruction de lancement du processus d'authentification décrit ci-après. Cette étape E0 n'est toutefois pas nécessairement mise en oeuvre. En effet, le processeur P peut initier le procédé décrit ci-après (à partir de l'étape E2) 20 sur la base d'un autre évènement, par exemple l'expiration d'un compteur (au sein du terminal T), une action donnée de l'utilisateur (telle que le lancement d'une application particulière au moyen d'une interface homme-machine, non représentée, du terminal T), un appel du procédé par une autre application exécutée par le processeur P.

25 Comme déjà indiqué plus haut, le procédé mis en oeuvre par le processeur P comme décrit ci-après est réalisé du fait de l'exécution des instructions d'une application (ou programme d'ordinateur) par le processeur P. Dans la variante mentionnée ci-dessus où un environnement d'exécution de confiance est utilisé (au moyen d'un système d'exploitation de confiance exécuté 30 par le processeur P), cette application est exécutée dans le cadre du fonctionnement dans l'environnement d'exécution polyvalent. Le processeur P génère à l'étape E2 un défi ACH, par exemple par tirage aléatoire. On dénommera dans la suite "défi de l'application" ce défi ACH, du fait qu'il est généré par l'application exécutée par le processeur P du terminal T pour 3029722 7 mettre en oeuvre notamment l'étape E2. Le processeur P émet alors à l'étape E4 une instruction de début de processus d'authentification, accompagnée du défi de l'application ACH, à destination de la carte à microcircuit C.

5 Cette instruction de début de processus d'authentification est ici une commande INITIALIZE UPDATE définie dans la spécification GlobalPlatform relative au protocole SCP03 (pour "Secure Channel Protocol 03") ou, en variante, une commande INITIALIZE UPDATE définie dans la spécification GlobalPlatform relative au protocole SCP02 (pour "Secure Channel Protocol 02"). Dans les deux 10 cas, le défi de l'application ACH généré à l'étape E2 est utilisé en lieu et place du défi d'hôte ("Host Challenge") dans la commande INITALIZE UPDATE. On remarque que l'instruction de début de processus d'authentification est générée par le processeur P (du fait de l'exécution de l'application), et ne correspond donc pas à la simple transmission d'une telle instruction reçue de 15 l'extérieur. La carte à microcircuit C détermine à l'étape E6 un cryptogramme de carte CAC et un défi de carte CCH. Ces éléments sont ici déterminés conformément à ce que prévoit la spécification SCP03 précitée ou, dans la variante déjà envisagée, la spécification SCP02. Dans chaque cas, le défi d'hôte 20 ("host challenge") est toutefois remplacé par le défi de l'application ACH. Le défi de carte CCH est par exemple déterminé par tirage aléatoire. En variante, il pourrait être déterminé de manière pseudo-aléatoire, comme décrit dans la spécification relative au protocole SCP03 (ou SCP02 le cas échéant). Le cryptogramme de carte CAC est déterminé par application au défi de 25 l'application ACH (reçu à l'étape E4) d'une fonction cryptographique (ici de cryptographie symétrique) utilisant une clé secrète, par exemple une clé de session (correspondant à la clé S-MAC dans le protocole SCP03) dérivée à partir de la première clé statique K-MAC mémorisée (comme indiqué ci-dessus) dans la mémoire non-volatile de la carte à microcircuit C.

30 Le défi de carte CCH peut éventuellement être utilisé lors de la détermination du cryptogramme de carte CAC, par exemple par concaténation avec le défi de l'application ACH avant application de la fonction cryptographique comme indiqué ci-dessus. La carte à microcircuit C peut alors envoyer à l'étape E8 le 3029722 8 cryptogramme de carte CAC et le défi de carte CCH (en tant que réponse à la commande INITIALIZE UPDATE). Dans certains cas (par exemple dans le cas du mode prédictif du protocole SCP03, ou dans tous les cas de la variante déjà envisagée où le 5 protocole SCP02 est utilisé), la valeur d'un compteur est également transmise de la carte à microcircuit C au processeur P lors de l'étape E8. Le processeur P émet alors à l'étape E10 (du fait de l'exécution par le processeur P de l'application déjà mentionnée) une demande de connexion au serveur S, par exemple sous forme d'une demande de connexion sécurisée de 10 type TLS (pour "Transport Layer Security"). Le serveur S répond à cette demande, ici en acceptant l'établissement d'une connexion sécurisée entre le serveur S et le terminal T (étape E12). Le terminal T émet ensuite à l'étape E14 les données suivantes à destination du serveur S, ici via la connexion sécurisée établie aux étapes E10 et 15 E12 et par exemple au moyen d'une commande HTTP POST : - l'identifiant ID de l'environnement d'exécution sécurisé (ici de la carte à microcircuit C) ; - le défi de l'application ACH généré à l'étape E2 ; - le cryptogramme de carte CAC déterminé à l'étape E6 ; 20 - le défi de carte CCH déterminé à l'étape E6 ; - optionnellement, la valeur du compteur utilisée, comme indiqué ci-dessus, dans le cas du mode prédictif du protocole SCP03 ou dans le cas de la variante où le protocole SCP02 est utilisé. Le serveur S transfère ces données au module matériel de sécurité M à 25 l'étape E16 afin que celui-ci vérifie que le cryptogramme de carte CAC généré à l'étape E6 correspond bien à celui normalement associé au défi de l'application ACH par application de la fonction cryptographique utilisant la clé secrète dérivée à partir de la première clé statique K-MAC mémorisée dans la carte à microcircuit C, ce qui permet d'authentifier la carte à microcircuit C.

30 On remarque que le défi utilisé ici n'a pas été généré côté serveur et qu'il n'est donc pas possible de s'assurer côté serveur que le défi est bien aléatoire et que la réponse ne provient pas d'un rejeu d'une réponse antérieure. Pour remédier à cela, le serveur S peut mémoriser par exemple tous les défis précédemment utilisés et n'authentifier la carte à microcircuit C qu'en présence 3029722 9 d'un nouveau défi (c'est-à-dire un défi différent de chacun des défis antérieurs mémorisés). En pratique, pour effectuer la vérification précitée, au cours de l'étape E18, le module matériel de sécurité M lit, par exemple dans une unité de stockage 5 de ce module M, la première clé statique K-MAC associée à l'identifiant ID de la carte à microcircuit C, dérive la clé de session S-MAC (selon le même processus que ci-dessus à l'étape E6) et applique la fonction cryptographique précitée au défi de l'application ACH, en utilisant la clé de session dérivée S-MAC, ce qui permet d'obtenir le cryptogramme CAC* attendu, normalement associé au défi de 10 l'application ACH. On remarque que l'application de la fonction cryptographique est réalisée conformément à ce que prévoit le protocole SCP03 (ou, dans la variante déjà envisagée, le protocole SCP02), en utilisant le défi de l'application ACH en lieu et place du défi d'hôte ("host challenge"), et utilise donc non seulement le défi de 15 l'application ACH, mais ici en outre le défi de la carte CCH et éventuellement la valeur du compteur. Le module matériel de sécurité M peut ainsi déterminer si le cryptogramme de carte CAC reçu à l'étape E16 est bien identique au cryptogramme attendu CAC*, calculé à l'étape E18.

20 Le module matériel de sécurité M renvoie au serveur S une information représentative du résultat de la vérification (étape E20). Si la vérification a été un échec (c'est-à-dire lorsque le cryptogramme de carte CAC calculé à l'étape E16 par la carte à microcircuit C est différent du cryptogramme attendu CAC*), le serveur S met par exemple en oeuvre un 25 traitement d'erreur (non représenté), par exemple en mettant fin à la connexion avec le terminal T. Si la vérification s'est correctement effectuée, le processus se poursuit comme décrit ci-dessous par la préparation d'un script à exécuter par le microprocesseur de la carte à microcircuit C. On remarque que cette préparation 30 de script n'est ainsi réalisée qu'après authentification de la carte à microcircuit C, ce qui permet d'éviter une préparation inutile de script dans les cas où la carte à microcircuit C ne peut finalement pas s'authentifier. Dans certaines applications, on pourrait utiliser le cryptogramme de carte CAC, associé éventuellement avec le défi d'application ACH, comme mot de 3029722 10 passe à usage unique (ou OTP pour "one-time password') puisque ces éléments sont connus au niveau du serveur S (précisément dans le module matériel de sécurité M associé au serveur S) et au niveau du terminal T (précisément dans la carte à microcircuit C).

5 Ainsi, le cryptogramme CAC pourrait par exemple être utilisé en tant que clé secrète partagée dans le cadre du protocole SSL (en lieu et place de la clé éphémère de Diffie-Hellman), ou de même dans le cadre du protocole TLS, ou encore dans les en-têtes HTTPS. On remarque que ces éléments sont obtenus par l'utilisation de la 10 commande INITIALIZE UPDATE, usuellement disponible dans l'environnement d'exécution sécurisé (ici la carte à microcircuit C), sans qu'il soit nécessaire d'installer une application dédiée dans cet environnement (application couramment dénommée "cardief' dans le cas d'une carte à microcircuit ou "trustler dans le cas d'un environnement d'exécution de confiance).

15 Par ailleurs, les secrets utilisés sont contenus dans l'environnement d'exécution sécurisé, et non dans l'application installée et exécutée par le processeur P pour mettre en oeuvre le procédé effectué par ce processeur P, comme indiqué ci-dessus, ce qui est préférable du fait que cette application n'est pas exécutée dans un environnement d'exécution sécurisé.

20 Dans le cas de la figure 2, la préparation du script est déclenchée par l'émission, par le serveur S, d'une demande de script à destination de l'ordinateur de préparation de données D (étape E22), en annexant à cette demande l'identifiant ID de la carte à microcircuit C ainsi qu'éventuellement la valeur du compteur.

25 L'ordinateur de préparation de données D peut ainsi déterminer, sur la base de l'identifiant ID, quels traitements doivent être lancés au sein de la carte à microcircuit C (par exemple afin de mettre à jour certaines parties de la mémoire non-volatile réinscriptible de la carte à microcircuit C) et génère sur cette base à l'étape E24 un script destiné à la carte à microcircuit C, c'est-à-dire une liste de 30 commandes (ici de type APDU) destinées à la carte à microcircuit C. L'ordinateur de préparation de données D transmet alors à l'étape E26 le script généré au module matériel de sécurité M en vue de son chiffrement (en annexant par exemple l'identifiant ID de la carte à microcircuit C et éventuellement la valeur du compteur).

3029722 11 Le module matériel de sécurité M procède alors à l'étape E28 au chiffrement de chacune des commandes du script (sauf la commande initiale INITIALIZE UPDATE comme expliqué ci-après), par exemple au moyen d'un algorithme cryptographique de chiffrement symétrique utilisant une clé de 5 chiffrement (clé de session S-ENC définie dans le protocole SCP03) dérivée ici (conformément à ce que prévoit le protocole SCP03 ou, en variante, le protocole SCP02) sur la base de la seconde clé statique K-ENC associée à la carte à microcircuit C, du défi de l'application ACH et du défi de la carte CCH reçus à l'étape E18, et éventuellement de la valeur du compteur.

10 On remarque que le module matériel de sécurité M détermine les données à utiliser dans cette étape (clé statique, défi de l'application ACH, défi de la carte CCH, valeur du compteur) sur la base de l'identifiant ID de la carte à microcircuit C reçu à l'étape E26 (la seconde clé statique K-ENC étant comme déjà indiqué préenregistrée dans le module matériel de sécurité M en association 15 avec l'identifiant ID, tandis que les défis ACH, CCH et la valeur du compteur ont été reçus avec cet identifiant ID à l'étape E16 et donc mémorisés à ce moment en association avec l'identifiant ID). Le module matériel de sécurité M renvoie le script chiffré à l'ordinateur de préparation de données D à l'étape E30, qui transmet ce script chiffré au 20 serveur S à l'étape E32. Le serveur S peut ainsi envoyer à l'étape E34 le script chiffré au processeur P, par exemple au sein d'une réponse HTTP à la commande POST émise à l'étape E14 par l'application exécutée sur le processeur P. Le processeur P reçoit ainsi le script chiffré et envoie, une à une, les 25 commandes chiffrées formant ce script à la carte à microcircuit C. Le processeur P envoie ainsi une première commande à l'étape E36, par exemple une commande INITIALIZE UPDATE (telle que définie dans les spécifications précitées). On propose en effet ici d'envoyer à nouveau une commande INITIALIZE UPDATE à la carte à microcircuit C de manière à assurer 30 une initiation correcte du protocole concerné (ici SCP03) car le canal logique mis en place à l'étape E4 peut avoir été interrompu lors de la mise en oeuvre de l'étape E36. Selon une variante envisageable, cette première commande INITIALIZE UPDATE pourrait toutefois être omise. La commande INITIALIZE UPDATE est accompagnée d'un défi d'hôte 3029722 12 HCH' (introduit par exemple dans le script lors de sa génération à l'étape E24). La carte à microcircuit C exécute à l'étape E38 la commande reçue à l'étape E36, ici en mettant en oeuvre un traitement du même type que celui effectué à l'étape E6, ce qui permet d'obtenir un nouveau défi de carte CCH' et un 5 nouveau cryptogramme de carte CAC'. Le processeur P reçoit à l'étape E39 le résultat du traitement effectué à l'étape E38 (ici le nouveau défi de carte CCH' et le nouveau cryptogramme de carte CAC') et émet donc à l'étape E40 la commande suivante (ici la seconde commande) à destination de la carte à microcircuit C, ici une commande 10 EXTERNAL AUTHENTICATE. Une telle commande est accompagnée d'un cryptogramme de l'hôte ("host cryptogram") qui permet à la carte à microcircuit C d'authentifier l'émetteur du script. (On remarque qu'un tel cryptogramme de l'hôte peut être préparé à l'avance en utilisant certains modes de fonctionnement du protocole SCP03, notamment la génération du défi de carte en mode pseudo- 15 aléatoire.) La carte à microcircuit C reçoit la seconde commande, la déchiffre et procède au traitement demandé à l'étape E42, ici en vérifiant le cryptogramme de l'hôte afin d'authentifier l'émetteur du script. Si l'authentification est réussie (comme envisagé en figure 2), la carte à 20 microcircuit C renvoie à l'étape E43 un résultat positif au processeur P et attend la suite des commandes. Le processeur P envoie la troisième commande (ici une commande APDU) à la carte à microcircuit C à l'étape E44. La carte à microcircuit C déchiffre cette troisième commande (et vérifie 25 en outre également un code d'authentification de message pour garantir l'intégrité), puis l'exécute afin d'effectuer le traitement correspondant à l'étape E46 et d'envoyer le résultat de l'exécution au processeur P à l'étape E47. Le processeur P procède ainsi pour toutes les commandes successives jusqu'à la dernière commande : le processeur P envoie la dernière commande (ici 30 une commande APDU) à la carte à microcircuit C à l'étape E48 ; la carte à microcircuit C reçoit et déchiffre cette dernière commande, puis l'exécute afin d'effectuer le traitement correspondant à l'étape E50 et d'envoyer le résultat de l'exécution au processeur P à l'étape E51. Le processeur P envoie à l'étape E52 l'ensemble des résultats des 3029722 13 commandes successives (résultats respectivement reçus de la carte à microcircuit C aux étapes E39, E43, E47 et E51 comme indiqué ci-dessus) au serveur S, par exemple dans une requête HTTP POST. Le serveur S transmet ces données (résultats) à l'ordinateur de 5 préparation de données D. L'ordinateur de préparation de données D peut alors préparer et émettre un nouveau script, lorsque cela est nécessaire pour l'application concernée, selon des étapes similaires aux étapes E24 à E32 décrites ci-dessus. Dans le cas de la figure 2, il n'y a pas de nouveau script à émettre et 10 l'ordinateur de préparation de données D émet à l'étape E56 une réponse indiquant que le traitement est terminé (par exemple une réponse sans donnée annexée) à destination du serveur S. Le serveur S répond alors à l'étape E58 au processeur P avec une indication du même type, par exemple une réponse HTTP comportant le code 15 "204, signifiant que la requête précédemment émise (ici la requête HTTP POST de l'étape E52) a été traitée mais n'a généré aucune donnée en réponse. Le processeur P met alors fin à l'étape E60 à la connexion sécurisée initiée lors des étapes E10 et E12.

Claims (16)

1. REVENDICATIONS1. Procédé d'émission conditionnelle de données d'un serveur (S) à un terminal (T), comprenant les étapes suivantes : - génération (E2) d'un défi (ACH) par un processeur (P) du terminal (T) ; - transmission (E4) du défi (ACH) à un environnement d'exécution sécurisé (C) hébergé par le terminal (T) ; - génération (E6) d'un cryptogramme (CAC) dans l'environnement 10 d'exécution sécurisé (C) par application au défi (ACH) d'un algorithme cryptographique ; - émission (E14) par le terminal (T) du défi (ACH) et du cryptogramme (CAC) à destination du serveur (S) via un réseau de télécommunication (I, R) ; - vérification (E18), au niveau du serveur (S), de la concordance du 15 cryptogramme (CAC) et du défi (ACH) en vue de l'authentification du terminal (T) ; - lorsque ladite concordance est vérifiée à l'étape de vérification (E18), lancement (E22) d'un mécanisme de préparation de données et envoi (E34) des données préparées à destination du terminal (T) via ledit réseau de télécommunication (I, R). 20
2. 2. Procédé d'émission conditionnelle selon la revendication 1, dans lequel les étapes de génération (E2) du défi (ACH), de transmission (E4) du défi (ACH) et d'émission (E14) du défi (ACH) et du cryptogramme (CAC) sont mises en oeuvre du fait de l'exécution d'une application par le processeur (P).
3. 3. Procédé d'émission conditionnelle selon la revendication 1 ou 2, dans 25 lequel le défi (ACH) est généré par tirage aléatoire.
4. 4. Procédé d'émission conditionnelle selon l'une des revendications 1 à 3, dans lequel l'algorithme cryptographique utilise une clé secrète mémorisée dans l'environnement d'exécution sécurisé (C).
5. 5. Procédé d'émission conditionnelle selon l'une des revendications 1 à 30 4, dans lequel l'environnement d'exécution sécurisé est réalisé par un module sécurisé (C) ou par un environnement d'exécution de confiance.
6. 6. Procédé d'émission conditionnelle selon la revendication 5, dans lequel l'environnement d'exécution sécurisé est réalisé par ledit module sécurisé, le procédé comprenant une étape de transmission (E8) du cryptogramme généré 3029722 15 (CAC) du module sécurisé (C) au processeur (P).
7. 7. Procédé d'émission conditionnelle selon la revendication 5, dans lequel le terminal est conçu pour fonctionner sélectivement dans un environnement d'exécution polyvalent ou dans ledit environnement d'exécution de 5 confiance.
8. 8. Procédé d'émission conditionnelle selon l'une des revendications 1 à 7, dans lequel l'étape de vérification (E18) est mise en oeuvre par un module matériel de sécurité (M) associé au serveur (S).
9. 9. Procédé d'émission conditionnelle selon l'une des revendications 1 à 8, comprenant une étape de comparaison, au niveau du serveur (S), du défi reçu (ACH) et de défis préalablement reçus et mémorisés au niveau du serveur, et dans lequel le mécanisme de préparation des données est lancé seulement si le défi reçu est différent de chacun des défis préalablement reçus.
10. 10. Procédé d'émission conditionnelle selon l'une des revendications 1 à 9, dans lequel ladite préparation des données est une génération d'un script.
11. 11. Procédé d'émission conditionnelle selon la revendication 10, dans lequel le script généré est un script de personnalisation ou un script de gestion de carte.
12. 12. Procédé d'émission conditionnelle selon la revendication 10 ou 11, 20 comprenant une étape de chiffrement (E28) du script au moyen d'un algorithme cryptographique de chiffrement utilisant une clé de chiffrement obtenue en utilisant le défi (ACH).
13. 13. Procédé d'émission conditionnelle selon l'une des revendications 1 à 12, dans lequel les étapes de génération du cryptogramme et de vérification de la 25 concordance sont conformes à un protocole de type SCP02 ou SCP03.
14. 14. Procédé d'émission conditionnelle selon l'une des revendications 1 à 13, dans lequel l'étape de transmission du défi est réalisée par une commande de type INITIALIZE UPDATE.
15. 15. Terminal (T) comprenant un processeur (P) et des moyens (C) de 30 mise en oeuvre d'un environnement d'exécution sécurisé conçu pour générer un cryptogramme (CAC) par application d'un algorithme cryptographique à un défi (ACH), caractérisé en ce qu'une mémoire associée au processeur mémorise une application conçue pour générer le défi (ACH), pour transmettre le défi (ACH) 3029722 16 à l'environnement d'exécution sécurisé, pour recevoir le cryptogramme (CAC) en provenance de l'environnement d'exécution sécurisé et pour émettre le défi (ACH) et le cryptogramme (CAC) à destination d'un serveur (S) via un réseau de télécommunication (I, R), lorsque l'application est exécutée par le processeur (P). 5
16. 16. Ensemble serveur comprenant : - des moyens de réception (S) d'un défi (ACH) et d'un cryptogramme (CAC) en provenance d'un terminal (T) via un réseau de télécommunication (I, R) ; - des moyens de vérification (M) de la concordance du cryptogramme (CAC) et du défi (ACH) en vue de l'authentification du terminal (T) ; 10 - des moyens, activés seulement en cas de vérification de la concordance par les moyens de vérification, pour lancer (E22) un mécanisme de préparation de données et envoyer les données préparées à destination du terminal (T) via ledit réseau de télécommunication (I, R). 15